Shulou(Shulou.com)06/03 Report--

This article mainly explains the steps of deploying Git under the Docker container. The content of the article is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn the steps of deploying Git under the Docker container.

The old way

I really can't simulate a completely real environment locally, but we just have to look at the time it takes to start a virtual machine:

$time vagrant up Bringing machine 'default' up with' virtualbox' provider... [default] Importing base box 'squeeze64-ruby193'... ... [default] Booting VM... [default] Waiting for VM to boot. This can take a few minutes. ... Real 1m32.052s

It took more than a minute and a half to activate an image. What should I do if I simply modify the configuration? Then I have to verify the feasibility, do I have to restart it again? It's been another minute and a half.

This is clearly a cruel punishment.

Use Docker

Just how lightweight is Docker? When you run a process in Docker container, you may even forget that the process is not running directly on the host. In the following example, I run an image called "rails" in Docker container, where is a Rails App (Dockerfile):

Root@precise64:~# docker run rails 2013-08-26 20 no user in config file 21 WARN Included extra file 14603 WARN Included extra file "/ srv/docker-rails/Supervisorfile" during parsing 2013-08-26 20 20 WARN Included extra file 14736 INFO RPC interface 'supervisor' initialized 2013-08-26 20 no user in config file 2114 14740 CRIT Server' unix_http_server' running without any HTTP authentication checking 2013-08-26 20 no user in config file 2114754 INFO supervisord started with pid 1 2013-08-26 20 INFO success 21 INFO success 15783 INFO spawned: 'rails' with pid 10 2013-08-26 20 Fringe 21 INFO success: rails entered RUNNING state Process has stayed up for > than 1 seconds (startsecs)

It only took 2 seconds to start container and start supervisor (this is the one responsible for starting Rails app)

In short, Docker is perfectly capable of virtualizing a complete production environment on your development computer, and very quickly. Since it's so simple, come on, let's do it: I'm going to test it thoroughly.

Building an image is so convenient and fast-long live the cache!

Old method

If you want to script the build process from an empty mirror to a functional image (for example, how to install a Rails stack on Ubuntu), if you don't do this often, getting all the streams correctly will definitely be a painful job. Take a look at installing dependencies for Ruby:

$time apt-get install-y-Q ruby1.9.1 ruby1.9.1-dev rubygems1.9.1 irb1.9.1 build-essential libopenssl-ruby1.9.1 libssl-dev zlib1g-dev Reading package lists... Building dependency tree... The following extra packages will be installed:.... Setting up libalgorithm-merge-perl (0.08-2). Processing triggers for libc-bin... Ldconfig deferred processing now taking place real 1m22.470s

Then, you want to install NodeJS dependencies, but forget to add sources to apt:

$apt-get install-y nodejs... E: Unable to locate package nodejs

After you have solved the source problem, you need to make sure that your script will have a problem in the new image. Then you need to reinstall Ruby. Well, another 82 seconds will be wasted. It's the annoyance.

Use Docker

In Docker, you put the steps of building the image into Dockerfile. Dockerfiles is very easy to read because you don't need to learn DSL at all-these are the basic commands you write down as you type. * it will be a bit troublesome to install Ruby each time, but let's see what happens when we use Dockerfile to build the remaining images:

FROM ubuntu:12.04

RUN apt-get update

# # MYSQL

RUN apt-get install-y-Q mysql-client libmysqlclient-dev

# # RUBY

RUN apt-get install-y-Q ruby1.9.1 ruby1.9.1-dev rubygems1.9.1 irb1.9.1 build-essential libopenssl-ruby1.9.1 libssl-dev zlib1g-dev

Root@precise64:/# time docker build-t = "dlite/appserver". Uploading context 92160 bytes Step 1: FROM ubuntu:12.04-> 8dbd9e392a96 Step 2: RUN apt-get update-> Using cache-> b55e9ee7b959 Step 3: RUN apt-get install-y-Q mysql-client libmysqlclient-dev-- > Using cache-> dc92be6158b0 Step 4: RUN apt-get install-y-Q ruby1.9.1 ruby1.9.1-dev rubygems1.9.1 irb1.9.1 build-essential libopenssl-ruby1.9.1 libssl-dev zlib1g- Dev-- > Using cache-> 7038022227c0 Successfully built 7038022227c0 real 0m0.848s

Deploy the image, do not update the underlying environment

The old way

Like many other deployments, Scout uses long-running virtual machines. We update the underlying environment through Puppet, but this is often more painful than we think:

If we want to update stack, Puppet will run the virtual machine and then update. This will take a long time-even if only a small portion of the stack needs to be updated, Puppet still checks all.

There may also be problems during deployment. If we are installing Memcached and suddenly the network is down for a while, then the instructions of apt-get install memcached may be invalid.

Rollback major changes, which is often not as smooth as expected (like updating the Ruby version).

These are the problems with Puppet's-tools like Puppet or Chef are very important, especially if you have long-running virtual machines that may be inconsistent over time.

Use Docker

Deployment image-there is no need to modify the existing virtual machine. You can be 100% sure that whatever runs locally, the corresponding production environment will run.

But the mirror image is very big, isn't it? Don't remember the whole Docker- that containers doesn't run on its own operating system, and that we use a federated file system. When we make changes to the mirror, we just need to add a new layer to it.

For example, we install Memcached on the app server. We built a new mirror image. I will mark asdlite/appserver-memcached,dliteis as my index.docker.io user name, which is based on the dite/appserver image.

Root@precise64:/# time docker build-t = "dlite/appserver-memcached". Uploading context 92160 bytes Step 1: FROM appserver-> 8dbd9e392a96 Step 2: RUN apt-get update-> Using cache-> b55e9ee7b959 Step 3: RUN apt-get install-y-Q memcached-> Running in 2a2a689daee3 Reading package lists... Building dependency tree... ... Starting memcached: memcached. Processing triggers for libc-bin... Ldconfig deferred processing now taking place-> 2a2a689daee3 Successfully built 2a2a689daee3 real 0m13.289s user 0m0.132s

It takes only 13 seconds to install Memcached, because the previous Dockerfile is cached, and I love the speed.

I will upload and submit these:

Root@precise64:/# time docker push dlite/appserver-memcached The push refers to a repository [dlite/appserver-memcached] (len: 1) Processing checksums Sending image list Pushing repository dlite/appserver-memcached (1 tags) Pushing 8dbd9e392a964056420e5d58ca5cc376ef18e2de93b5cc90e868a1bbc8318c1c Image 8dbd9e392a964056420e5d58ca5cc376ef18e2de93b5cc90e868a1bbc8318c1c already pushed, skipping... Pushing tags for rev [ad8f8a3809afcf0e2cff1af93a8c29275a847609b05b20f7b6d2a5cbd32ff0d8] on {https://registry-1.docker.io/v1/repositories/dlite/appserver-memcached/tags/latest} real 0m28.710s

On a machine in a production environment, I downloaded the image:

Root@prod:/# time docker pull dlite/appserver-memcached Pulling repository dlite/appserver-memcached Pulling image ad8f8a3809afcf0e2cff1af93a8c29275a847609b05b20f7b6d2a5cbd32ff0d8 (latest) from dlite/appserver-memcached real 0m15.749s

It took only 15 seconds to get dlite/appserver-memachedimage. Note that the image is only the size of 10MB and uses the app server image as the base image:

Root@precise64:~# docker images REPOSITORY TAG ID CREATED SIZE appserver latest 7038022227c0 3 days ago 78.66 MB (virtual 427.9 MB) appserver-memcached latest 77dc850dcccc 16 minutes ago 10.19 MB (virtual 438.1 MB)

There is no need to download the entire Memcached image, just add the changes in the Memcached image to the dlite/appserver image.

Most of the time, the changes we make are much smaller. So it will be faster to download a new image.

These can make a big difference:

It is very fast to start a new Docker containers

Upload + download new Docker images should be lightweight

Instead of changing the running virtual machine, we just start the new containers and stop the old containers.

What a shock! This means I don't need to worry about consistency-we won't modify the running virtual machine, just start a new containers. This means it can be rolled back easily! Memcached failed? Stop running dlite/appserver-memcached 's container and start a new container to run the dlite/appserver image.

shortcomings

Working on a short containers can lead to a series of new problems-distributed configuration / orchestration and service discovery:

When a new app server containers starts, how do we update the HAProxy configuration?

When a new database container starts, how should the app server communicate with the data container?

How to communicate across Docker host machines?

Thank you for reading, the above is the "steps to deploy Git under the Docker container", after the study of this article, I believe you have a deeper understanding of the steps of deploying Git under the Docker container, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

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.