How to realize continuous deployment of JAVA projects through Docker (just four simple steps), namely: developers upload code through git push, and cooperate with Git and Jenkins to automatically complete program deployment and release, without the need for operation and maintenance personnel to participate in the whole process.
This is a true container-level implementation, and the benefits of this are not only efficiency improvements, but also a change: * For the first time, developers are truly responsible for their own code - finally can skip operation and maintenance And the test department, which independently maintains the operating environment (first the test/development environment).
This article is the text version of the second lecture of the cSphere Docker practical video. The co-author of this article @张春源 (working at Xiyun cSphere) is the video speaker. For more series of videos, please refer to here .
Welfare: Click on the "Actual Combat Video" at the end of the article to enjoy the actual combat video corresponding to this article on your mobile phone.
Those who are difficult will not, those who will meet are not difficult. With 4 simple configurations, continuous deployment can be achieved gracefully. This article is listed in the directory as usual, 1. Technical ideas of continuous deployment2. Effect display3. Configure Git and Jenkins linkage4. Configure Jenkins to automatically update the code5. Detailed explanation of the effect picture and text6. FAQ
Alright, let's get started.
1. The technical idea of continuous deployment
In this example, assume the name of our JAVA project is hello. A brief technical idea is as follows.
In this case, it is assumed that the code is hosted on git.oschina.com, and Jenkins and Docker Registry (similar to the yum source) each run in a Docker container. The JAVA project itself also runs separately in a container called hello. The continuous deployment solution adopted in this article is to pull code from the private Docker Reistry. Some workarounds are to put the code on the host and let the container read it through the volume group map. The reason this approach is not recommended is that splitting the code out of the container goes against Docker's container principles:
This also leads to increased loading and unloading complexity. From the perspective of freight workers, the whole is the most economical. Only in this way can real container-level migration be realized. In other words, in the container era, it is the right way to abandon the idea of file distribution in the past. More on this in the Q&A at the end of this article. A container is a process. The reason and significance of using the above solution for Docker continuous deployment is also here. The life cycle of a container should be much shorter than that of a virtual machine. If there is a problem with a container, it should be killed immediately instead of trying to recover.
2. Effect display
How amazing is the final effect of this article? And see the demo below.
2.1 The effect before the program code update
We use timestamps to concisely and explicitly represent program updates.
2.2 Submit program code update
In this example, we changed the timestamp of the home page from 201506181750 to 201506191410 (see below).
2.3 Upload new code to Git
Perform the following operations in sequence, and enter the correct git account password.
and then? Then do nothing. Grab a cup of tea (if you don't like coffee), wait quietly for the auto-deployment to happen, and watch a series of processes that are automatically triggered and go into motion like a robot (more on that later).
Why does it take 3~5 minutes? Just because of the JAVA project in this case, the Maven package needs to be downloaded from abroad for Jenkins to call and compile JAVA. In the formal application environment, the Maven source can be placed in the domestic or computer room. If you only need to do continuous deployment of PHP projects, it will be faster.
2.4 View the effect of the code update
After waiting quietly for a few minutes, the new code has indeed been deployed automatically.
So how did all this happen? Is it complicated? otherwise. Just follow the steps below and you can do it quickly.
3. Configure Git and Jenkins linkage
This process is not difficult for those who are difficult, and not difficult for those who meet. It is mainly divided into the following three steps.
3.1 Jenkins configure Git source
Create a new project java-app in Jenkins and configure to pull program code from Git. details as follows:
3.2 Jenkins configure remote build
The token is configured in Jenkins for use when git is called remotely.
3.3 Git open hook
How to make Git pass messages and tasks to Jenkins after receiving the user's updated code? This is also very simple to configure with the help of Git's hook function, as follows.
4. Configure Jenkins to automatically update code
After receiving the message from Git, Jekins triggers a remote build (to the target server), performs a series of jobs, rebuilds the container, etc. according to the predefined task list. See below for details:
We excerpted the most critical Shell script content.
5. Detailed explanation of effect pictures and texts
In chapter 2.3, we did the following, the purpose was to submit updated code to Git.
At that time, I did not elaborate on what happened next. Since the principle has been clearly explained above, we can talk about what actually happened next.
5.1 Upload code to Git
Here it seems that the whole process has been completed and exited smoothly. In fact, the background work has only just begun.
At this time, the Git server will be triggered to send an operation request to the corresponding Jenkins server. This work is too fast, and there is nothing to say. We will see what Jenkins does next.
5.2 Wonderful interaction by Jenkins
1) Jenkins will automatically "pop up" a build task.
2) Let's click in to see the specific operation log. Yes, accepting tasks from Git.
3) Download Maven related packages (that is, this process is slow).
4) After the download is complete, start using the new hello project package of maven BUILD.
5) Then rebuild the Maven container, build a new Image and push it to the Docker private library.
6) Finally, pull up the Docker container again. Thus, it was born again. Ha ha
6. FAQ
Question 1: Is it because the project is based on JAVA that such a relatively complicated method is adopted (instead of putting the update code on the host machine and then the volume group mapping); whether the PHP project can use the update code on the host machine and then the volume group mapping? Way?
Answer 1: Splitting the code out of the container violates the container principle. This leads to increased loading and unloading complexity. From the perspective of freight workers, the whole is the most economical. Everything is versioned. Ditch the file distribution of the past. This is the right way. As for the file size, the large war package is only 50M or 100M, which is not a problem under the existing network, and the performance problem is best optimized. It is also recommended to pay attention to docker 2 docker, p2p transmission.
问题2：如果整体代码超过500m或者1g以上，整体集装箱是否就不太好了？如果容器与代码分离，镜像就100m左右（2层，base+服务），然后代码的话，是放到共享存储里，每个代码有更新，比如svn的代码，可以直接在共享存储里进行svn update就可以控制版本
回答2：如果你的代码500M，那只能说明业务开发该打板子了。
问题3：如果测试环境使用您提供的完整集装箱服务还行，但在生产环境，集群里运行docker做应用，如果每个容器都是有完整的代码，是否有点臃肿，不如每个集群节点里就运行基础服务镜像，通过卷组功能绑定共享存储里的代码，加上Crontab、Python和Shell脚本，这样每次代码更新就1次就行了。
回答3：环境一致性，在过去从来没有解决好。10年前我们做PaaS时，和这个做法类似。不是说不好，时代变了，用脚本东拼西凑，终究难有好的系统。不能只考虑现在的方便，容器技术和vm如果类比，我觉得会让自己下决定时很纠结。
补充3：脚本一般是典型的运维工程师思维，quick & dirty。一般很难做成一个产品或者系统。整体考虑和扩展性考虑都比较少。现在做docker的难点在于到底怎么看待它。到底是拿它做调度的基本单位，还是部署的基本单位考虑清楚，再聊方案。
http://www.csdn.net/article/2015-07-21/2825266