Shulou(Shulou.com)05/31 Report--

This article mainly introduces "what is the technology of continuous deployment of Docker". In daily operation, I believe that many people have doubts about the technology of continuous deployment of Docker. The editor consulted all kinds of materials and sorted out simple and easy-to-use methods of operation. I hope it will be helpful to answer the doubts of "what is the technology of continuous deployment of Docker?" Next, please follow the editor to study!

1. Technical ideas of continuous deployment

In this example, suppose the name of our JAVA project is hello. The brief technical ideas are as follows.

In this case, it is assumed that the code is hosted on git.oschina.com, with Jenkins and Docker Registry (similar to the yum source) each running in a Docker container. The JAVA project itself runs in a separate container called hello.

The continuous deployment solution adopted in this article is to pull the code from the private Docker Reistry. Some workarounds are to put the code on the host and let the container read through the volume group mapping. The reason why this approach is not recommended is to split the code out of the container, which violates Docker's container principle:

This also leads to an increase in loading and unloading complexity. From the point of view of freight workers, the whole is the most economical. Only in this way can the true container-level migration be realized.

In other words, in the container era, abandoning the idea of document distribution in the past is the right way. There is more explanation on this in the last question and answer session of this article.

The container is the process. This is also the reason and significance for us to adopt the above scheme for the continuous deployment of Docker. The life cycle of the container should be much shorter than that of the virtual machine. If there is a problem with the container, it should be killed immediately rather than trying to restore it.

two。 Effect display

How amazing is the effect achieved in the end of this article? Let's see the following demonstration.

2.1 effect before program code update

We use timestamps to express program updates succinctly and explicitly.

2.2 submit program code updates

In this example, we changed the timestamp of the home page from 201506181750 to 201506191410 (see below).

2.3 upload new code to Git

Do the following in order to enter the correct password for your git account.

And?

And you don't have to do anything. Serve a cup of tea (if you don't like coffee), quietly wait for automatic deployment to happen, watch a series of processes that are automatically triggered, and run like a robot (please describe it later).

Why does it take 3-5 minutes? Just because of the JAVA project in this case, you need to download Maven the package from abroad for Jenkins to call and compile JAVA. In the formal application environment, the Maven source can be placed in the country or in the computer room. It is even faster if you only need to make a continuous deployment of the PHP project.

2.4 View the effect of the updated code

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. As long as you follow the following steps, you can quickly achieve it.

3. Configure Git and Jenkins linkage

This process is also difficult for those who do not know, and those who meet are not difficult. 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 the program code from Git. The details are as follows:

3.2 Jenkins configuration remote build

Token is configured in Jenkins for use by git remote calls.

3.3 Git Open Hook

How do you get Git to 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 the code

After receiving the message from Git, Jekins triggers a remote build (to the target server), performs a series of tasks according to the predefined task list, rebuilds the container, and so on. For details, see as follows:

Let's extract the contents of the most critical Shell scripts.

5. Detailed explanation of effect picture and text

In this section, we did the following, which was to submit the updated code to Git.

At that time, we did not elaborate on what happened next, and now that the principle has been clearly explained above, we can talk about what actually happened.

5.1 upload code to Git

Here it seems that the whole process has been completed and successfully exited. In fact, the backstage work has just begun.

This will trigger the Git server to send an operation request to the corresponding Jenkins server, this work is too fast, there is nothing to say, let's see what the Jenkins does.

5.2 wonderful interaction with Jenkins

1) Jenkins will automatically pop up a build task.

2) Let's click in to see the specific operation log. Yes, I'm taking a mission from Git.

3) download Maven-related software packages (this is a slow process).

4) after the download is complete, start taking advantage of maven BUILD's new hello project package.

5) then rebuild the Maven container, build a new Image and Push it into the Docker private library.

6) finally, pull up the Docker container again. In this way, he is a freshman again. He he

6. FAQ

Question 1: is such a relatively complex approach (instead of putting the update code on the host and then volume group mapping) because the project is based on PHP? can the Java project adopt the method of placing the update code on the host and then volume group mapping?

Answer 1: splitting the code out of the container violates the container principle. It leads to the increase of loading and unloading complexity. From the point of view of freight workers, the whole is the most economical. Everything is versioned. Discard past document distribution. This is the right way. As for the file size, the large war package is only 50m or 100m, which is not a problem in the existing network, and the performance problem is best optimized. It is also recommended to pay attention to the docker 2 docker,p2p transport.

Question2: if the overall code is more than 500m or 1g, is the overall container not very good? If the container is separated from the code, the image is about 100m (layer 2, base+ service), and then the code is placed in shared storage. Each code has updates, such as svn code, and you can control the version by svn update directly in the shared storage.

Answer 2: if your code is 500m, it only means it's time for business development to hit the board.

Question 3: if the test environment uses the complete container service provided by you, but in the production environment, if docker is run in the cluster to make applications, if each container has complete code, is it a bit bloated? why not run the basic service image in each cluster node, bind the code in the shared storage through the volume group feature, and add Crontab, Python and Shell scripts, so that the code can be updated once each time.

Answer 3: environmental consistency has never been resolved in the past. When we did paas 10 years ago, it was similar to this. It is not that bad, times have changed, using scripts to cobble together, after all, it is difficult to have a good system. You can't just think about the current convenience, container technology and vm. If you make an analogy, I think it will be very difficult for me to make a decision.

Supplement 3: the script is generally a typical operation and maintenance engineer thinking, quick & dirty. It is generally difficult to make a product or system. Overall considerations and scalability considerations are relatively small. The difficulty of doing docker now lies in how to treat it. Consider clearly whether to use it as the basic unit of scheduling or the basic unit of deployment, and then talk about the plan.

At this point, the study on "what is the technology for continuous deployment of Docker" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.