Docker: Easier, happier, more efficient

Editor's note: With Docker, we can deploy Web applications more easily without having to worry about project dependencies, environment variables, and configuration issues, Docker can quickly and efficiently handle all of this. This is also the main purpose of this tutorial. The following is the author's original:

First we'll learn to run a Python Dewar application using the Docker container, and then step through a cooler development process that covers the continuous integration and release of applications.

Process

completes the application code on the local functional branch. Initiate a pull Request to the master branch on the GitHub. Run the automated tests on the Docker container. If the test passes, manually merge this PR into the master branch. Once the merge succeeds, run the automated test again. If the second test is passed, the application is built on the Docker hub. Once the build is complete, it is automatically deployed to the production environment.

             

This tutorial is based on Mac OS X, and before you start you need to ensure that the following tools are properly configured: Python v2.7.9, Dewar v0.10.1, Docker v1.4.1, Docker Compose, v1.0.0, Boot2docker 1.4.1, Redis v2.8.19

Okay, let's get started. First, introduce some basic concepts in Docker:

The

Dockerfile includes a series of statements that describe the behavior of the mirror. Mirroring is a template that is used to save environment State and create containers. A container can be interpreted as an instantiated mirror and run a series of processes in it.

If you are interested in the details of dockerfile, mirrors, and containers, you can get more detailed information from the official documentation for Docker.

Why is

Docker?

Using Docker means you can seamlessly simulate a production environment on a development machine without worrying about any problems caused by both the environment and configuration differences, and beyond that Docker brings us:

good version control. Publish/Rebuild the entire development environment anytime and easily. A build, run everywhere, is so magical!

Configuration Docker

Since Darwin (OS x kernel) lacks some of the Linux kernel features to run the Docker container, we need to use Boot2docker, a lightweight Linux distribution to run Docker (launch a small virtual machine specifically tailored for running Docker).

First create a directory named "Fitter-happier-docker" for our Dewar project.

Follow the official documentation steps to complete the installation of Docker and Boot2docker.

We can verify that the installation is correct by using the following command:

$ boot2docker versionboot2docker-cli version:v1.4.1git commit:43241cbcompose Up!

Docker compose is the official container business process Framework (the once project name is fig, even in the first draft of this translation is still, the speed of evolution is evident), simply through a simple. YML configuration file, you can complete the construction and operation of multiple container services.

Use the PIP to install the Docker Compose and verify that the installation is correct by using the following command:

$ pip Install docker-compose$ docker-compose--versiondocker-compose 1.1.0 now start our flask+ Redis application (You can get all the source code for the project from this repo), first create a new Docker-compose.yml file under the project root:

web:build:web Volumes:-Web:/code Ports:-"80:5000" Links:-Redis Command:python app.pyredis:image:redis:2.8.19 Ports:-"6,379:6,379"

You can see what we do with the two services that the project contains:

Web: We will build the container in the Web directory and mount it as a volume in the container's subdirectory directory, then start the Dewar application via Python app.py. Finally, the container's 5000 ports are exposed and mapped to the host's 80 port. Redis: We directly use the official mirrors on the Docker hub to provide the required Redis service support, exposing 6379 ports and mapping to the host.

You must have noticed the Dockerfile file located in the Web directory, which is used to instruct Docker how to build our application mirrors (based on Ubuntu) and to ensure complete dependency support.

Build and Run

The next thing you need is a simple line of command, which can be easily done (mirroring builds and container startup runs):

ubuntu$ docker-compose up

This builds the image of the Dewar application based on Dockerfile, pulls Redis mirrors from the official repository, and then runs everything.

Now you can go for a cup of coffee, er, maybe two: First run will take a relatively long time, in fact Docker will be in the build process, dockerfile every step of the operation (more formal said should be layer) cache down, the later build process will therefore speed up a lot, Because only the steps to change will be performed again.

Docker compose will start all containers in parallel, each container will be assigned its own name, and a higher-readable color scheme will be set for the log.

Okay, so are you ready to test?

Open your browser, enter the host Docker_host environment variables corresponding to the IP address, for example, in my case is http://192.168.59.103/(run boot2docker IP commands can be queried to the IP address).

Next you should see the following text in the browser "hello! This page super-delegates been dots 1. ：

                      

Refresh the page, and if everything is OK, the counter variable should be cumulative.

Terminate our application process by CTRL, and then make it run in the background with the following command:

$ docker-compose up-d want to see the running status of the application process? You just need to enter the following command:

$ docker-compose PS Name Command State Ports--------------------------------------------------------------------------------------------------Fitterhappierdocker _redis_1/entrypoint.sh redis-server up 0.0.0.0:6379->6379/tcpfitterhappierdocker_web_1 python app.py up 0.0.0.0:80 ->5000/TCP, 80/tcp

You can see that our two processes are running in different containers, and Docker compose will organize them together!

further

After determining that everything is OK, use the Docker-compose Stop command to terminate our application and then safely shut down the virtual machine by boot2docker down. You can then submit your local modifications to git and push them to GitHub.

So what have we accomplished just now?

We built the local environment, and dockerfile a detailed description of how to build the mirror and started the container based on that image. We use Docker compose to integrate this, including building and container associations, communications (between Dewar and Redis processes).

Next, let's look at a cooler workflow that enables continuous integration of projects by introducing Circleci.

Again, you can get the source code from here.

Docker Hub

So far we have contacted Dockerfile, mirrors and containers (with the help of Docker compose, of course).

If you are familiar with Git's workflow, then you can interpret the Docker image as Git's repo, and the container is similar to the repo clone, and if this metaphor continues, then the Docker hub is equivalent to GitHub status.

in order to use the Docker Hub, you can use the GitHub account to complete the registration. Add a new auto build, just complete the project repo to join in, everything in accordance with the default options, in addition to the "Dockerfile Location" to "self-help."

Once added, the Docker hub makes an initialization build, making sure everything works.

Docker hub and CI

The Docker hub itself is configured to act as a continuous integration service, which is automatically built after each push git commits.

This means you can't push the mirror directly to the Docker hub (via Docker push). The Docker hub pulls itself from the repo and builds the mirror to ensure that there are no errors throughout the process. Keep this in mind in your workflow as there is no detailed explanation for this in the Docker documentation.

Let's try this by adding the following test cases:

self.assertnotequal (Loko, 5)

Submit and push to GitHub, and then you can see how the Docker hub starts a new build.

Since this is the last line of defense before the project is deployed, we certainly hope that the Docker hub will be able to catch all errors and exceptions before the build is complete. In addition, you certainly want to be able to add your own unit test and integration test to the continuous integration process, which is circleci.

Circleci

Circleci is a continuous integration/release platform that supports testing of Docker containers. All you have to do is provide a dockerfile,circleci that will build the mirror and start a new container and run your tests in it. Remember the workflow we expected? Link now to see how to complete it. Install

CIRCLECI officials provide good introductory guidance.

Use the GitHub account to complete the registration, and then add your github repo to a new project (you will receive an email notification of your success). This adds a hook for the repo that triggers a new build whenever you push a new commit to it.

Next you need to add a configuration file to our repo to guide Circleci to complete the build.

CIRCLE.YML's documentation reads as follows:

machine:services:-dockerdependencies:override:-pip install-r requirements.txttest:override:-Docker-compose run-d--no-deps Web-python web/tests.py

In fact, we built a new mirror, started a new container, and tested it: first, check that the Web application starts running normally, and then unit tests.

You should have noticed that we started the application using the command docker-compose run-d--no-deps web instead of Docker-compose up because Circleci has integrated the available Redis runtime environment. So we just need to start the Web application process.

When the Circle.yml file is modified, it can be pushed to the GitHub to start a new build. Remember, this will also start a build on the Docker hub at the same time.

Everything okay?

Before we go any further, we need to make some adjustments to the workflow because we don't normally want to push the commit directly to the master branch.

Functional Branching Workflow

If you are not familiar with this workflow, you can get an accurate and vivid explanation from here.

Let's take a quick look at an example:

Create a feature branch $ git checkout-b circle-test masterswitched to a new branch ' circle-test ' update application and add a new assertion in texts.py:


Self.assertnotequal (Loko, 6) initiated a pull Request


$ git add web/tests.py$ git commit-m "circle-test" $ git push origin circle-test

Even before you actually initiate PR, CIRCLECI has started the build. After PR is created, just wait for Circleci to pass all the tests, and we can click the merge button to merge into the Master branch. Once the merge succeeds, the Docker hub triggers the corresponding build process.

Reconstruction Workflow

If you go back to the workflow at the beginning of this article, you will find that we actually want the Docker hub to test again on the master branch before starting the build, so let's make some quick adjustments to the existing process:

Open your Docker hub warehouse and select automated build under Settings. Cancels the selected state of "When active we are build when new pushes occur". Save. Select the build triggers that is located under settings. Change status to ON. Copy the following Curl command: $ curl--data "Build=true"-X POST

Add the following code to the end of the Circle.yml file:


deployment:hub:branch:master Commands:-$DEPLOY

Now we will execute the command represented by the $DEPLOY environment variable after the merge to the master branch and pass the test, we need to add the value of this variable to the CIRCLECI environment variable:

Open Project Settings and select environnement variables. Add a new variable named "Deploy" and paste the curl command you just copied into the variable's value.

Now to test the results:

$ git add circle.yml$ git commit-m "circle-test" $ git push origin circle-test

Initiate a new PR that, once it passes through the Cirecleci test, merges it into the master branch, which triggers another build. Once you pass the test again, the Curl command set up before triggers the Docker hub to start a new build, and everything is perfect.

Conclusion

We're running through this. Continuous integration workflow based on Circleci (step 1-6):

completes the application code on the local functional branch. Initiate a pull Request to the master branch on the GitHub. Run the automated tests on the Docker container. If the test passes, manually merge this PR into the master branch. Once the merge succeeds, run the automated test again. If the second test is passed, the application is built on the Docker hub. Once the build is complete, it is automatically deployed to the production environment.

The last piece of the puzzle about the whole process: and automating the release of the application to the VIBE Environment (step 7th), you can get an answer in my other blog. (translation: Li Ming/revisers: Liu Yajon)

Original link: https://realpython.com/blog/python/docker-in-action-fitter-happier-more-productive/%E3%80%91 "translator" : Li Ming (armyiljfe@gmail.com,https://github.com/hydranger), Nicescale front-end program ape, undergraduate, Master of Science is the direction of biology, out of passion for the IT field, have done game development, Interest is more widespread so that there are miscellaneous but not fine, but also need to be diligent, welcome exchanges, guidance. Currently focus on web-related technology, open source software and hardware and other fields.