laravel项目的CI / CD如何使其稳定

I'd like to use jenkins for my laravel project.

I use pipeline for that. As you know, laravel doesn't need build step. I also don't use tests. I just want to have a stage('deploy'). When making push to repository, jenkins host gets notified, pulls the project and runs the jenkins pipeline resided in laravel project. As i have jenkins host and laravel api host different from each other, this is where I am facing issues.

As I said, I don't have build and test stages. so only deploy in pipeline. but to run laravel project, before using jenkins, i had bash script which had 10 lines of code in it. such as (changing permissions, making current user as my user, running composer install, running docker-compose and so on).As I have another host for Laravel , I have 2 options:

1) in stage('deploy') I can transfer build.sh file from jenkins host to laravel api host. and then making ssh into that laravel api host and running that file there. The thing I don't like about this is that what if setting permissions or other stuff that I have in that build.sh file go wrong in halfway which will get my project in an undesired state and I won't even get notified and I will have the broken project in production.

2) I can do all the stuff in stage('build') running 'composer install and other stuff, after that making dockerfile from it(including vendor folder) and then after getting the image (which contains vendor too), uploading this docker image into dockerhub, then in stage('deploy') i can notify remote host about that and pass the script file from jenkins to that laravel remote hosts which contains the code which pulls the latest image from dockerhub and run it. this way I won't have undesired state as that image already contains vendor folder, it already got permissions and all that stuff. The issue with this is that making image will take lots of hard-disk. and imagine creating images for every push on the repository.

What do you suggest I should do?

展开翻译

译文

我想将jenkins用于我的laravel项目。</ p>

I 为此使用管道。 如您所知,laravel不需要构建步骤。 我也不使用测试。 我只想要一个阶段('deploy')。</ code>当推送到存储库时, jenkins </ code>主机得到通知,拉动项目并运行驻留在 laravel </ code>项目。 因为我的 jenkins主机</ code>和 laravel api </ code>主机彼此不同,所以这就是我面临的问题。</ p>

正如我所说 ,我没有 build </ code>和 test </ code>阶段。 所以只在管道</ code>中 deploy </ code>。 但是要运行 laravel </ code>项目,在使用 jenkins </ code>之前,我有 bash </ code>脚本,里面有10行代码。 例如(更改权限,使当前用户成为我的用户,运行composer install,运行docker-compose等)</ code>。由于我有另一个Laravel主机,我有2个选项:</ p>

1)在阶段('deploy')</ code>我可以将build.sh文件从jenkins主机传输到laravel api主机。 然后将ssh放入laravel api主机并在那里运行该文件。 我不喜欢这样的事情是,如果设置权限或我在该build.sh文件中的其他东西在中途出错,这将使我的项目处于不受欢迎的状态,我甚至不会得到通知,我 生产中将有破碎的项目。</ p>

2)我可以在 stage('build')</ code>中运行'composer install等所有东西 东西</ code>,之后从它(包括供应商文件夹)制作 dockerfile </ code>,然后在获取图像(也包含供应商)之后,将此docker映像上传到dockerhub,然后在阶段('deploy ')我可以通知远程主机,并将脚本文件从jenkins传递到laravel远程主机,其中包含从dockerhub获取最新映像并运行它的代码。 这样我就不会有不受欢迎的状态,因为该图像已经包含供应商文件夹,它已经获得了权限和所有这些东西。 这个问题是制作图像会占用大量硬盘。 并想象为存储库中的每次推送创建图像。</ p>

您建议我应该做什么?</ p>
</ div>

1个回答

Standard practice is your option 2, to make a new image for every build. Generally in Docker you don’t independently copy source code around at all; you build images and deal only with those images. (The “Docker for development” pattern of building and image and then replacing all of its contents with your local source tree is not at all how Docker is generally used in a production environment.)

You should make sure you give every image a unique identifier, like the timestamp of the build or some sort of source control commit ID. This is all but required for some higher-level automation systems (Kubernetes, for example), and it makes it very easy to roll back a broken build.

In the workflow you’ve described, you can package up pretty much any sort of files into an image and send them off to be run. There’s a great deal of value in having some sort of validation phase to make sure that an embarrassing typo doesn’t result in an image that never starts at all. By which I mean...write tests :-)

展开翻译

译文



标准练习是您的选项2,为每个构建创建一个新图像。 通常在Docker中,您根本不会独立复制源代码; 您构建图像并仅处理这些图像。 (构建和映像的“Docker for development”模式,然后用本地源代码树替换它的所有内容,根本不是Docker在生产环境中的使用方式。)</ p>

您应该确保为每个映像提供唯一标识符,例如构建的时间戳或某种源控件提交ID。 对于某些更高级别的自动化系统(例如Kubernetes)来说,这几乎是必需的,并且它可以很容易地回滚破坏的构建。</ p>

在您描述的工作流程中 ,您可以将几乎任何类型的文件打包成图像并将其发送出去运行。 在进行某种验证阶段以确保令人尴尬的拼写错误不会导致图像永远不会启动时,有很大的价值。 我的意思是......写测试: - )</ p>
</ div>

dongqin5604
dongqin5604 所以你喜欢我的选择2.制作图像(安装包,运行composer安装,然后将我的源代码与供应商文件夹一起移动到该图像中)并将该图像推送到docker hub? 并使系统修剪? 你喜欢这样吗? 如果答案是肯定的,那么docker hub呢? 如果我每天第100次推送到github存储库,想象一个月,我在docker hub中有3000个图像。 想象一年。
7 个月之前 回复
dqlk31541
dqlk31541 一旦你的docker将你的图像推送到存储库,你就可以安全地将系统修剪停靠到回收空间。
7 个月之前 回复
dongmeiran609914
dongmeiran609914 谢谢回答。 但我不明白你的意思“标准练习是你的选择2,为每个版本创建一个新的图像。通常在Docker你根本不能独立复制源代码;你构建图像并只处理 那些图像。(“开发者的开发”模式的构建和图像,然后用你的本地源代码树替换它的所有内容,根本不是如何在生产环境中使用Docker。)“。 如果我为存储库中的每次推送制作构建映像,我的jenkins主机将是超级巨大的并且无缘无故 - 我不在这里运行项目
7 个月之前 回复
Csdn user default icon
上传中...
上传图片
插入图片
抄袭、复制答案,以达到刷声望分或其他目的的行为,在CSDN问答是严格禁止的,一经发现立刻封号。是时候展现真正的技术了!