How to implement portable application deployment with Linux container

Docker is an Open-source tool that runs applications in Linux containers, a lightweight virtual machine. In addition to running applications, Docker also provides tools to simplify the deployment of complex applications by distributing applications for containerization with Docker index or its own managed Docker registry.

I'll describe the challenges that the company faces today when deploying complex systems, how to address this problem effectively, and other use cases for Docker Docker.

The challenges of deployment

Deployment of server applications has become increasingly complex. It is no longer the time to copy several Perl scripts to the correct directory to complete the installation of the server application. Today's software has many types of requirements:

Dependencies on installed software and libraries ("Python version is higher than 2.6.3, using Django 1.2")

relies on running services ("requires a MySQL 5.5 database and a rabbitmq queue")

dependent on a specific operating system ("build, test on 64-bit Ubuntu Linux 12.04")

Resource requirements:

Minimum available memory ("Requires 1GB of available memory")

Can bind specific ports ("Bind 80 and 443 ports")

Let's look at a relatively simple deployment of applications: Wordpress. The installation of WordPress usually requires:

Apache 2

PHP 5

Mysql

WordPress Source

A wordpress mysql database, configure WordPress to use the database

Apache Configuration:

Load PHP Module

Supports URL rewriting and. htaccess files

Point to WordPress source DocumentRoot

To deploy and run such a system on a server, we may experience the following problems and challenges:

Isolation: If we have deployed different sites on this server, existing sites can only run on Nginx, and WordPress relies on Apache, then we have trouble: they all listen on port 80. It is OK to run two Web sites at the same time, but you need to adjust the configuration (modify the listening port), set the reverse proxy, etc. There will be similar conflicts at the library level, and if you still want to run an old application that still relies on PHP4, it will be problematic because WordPress no longer supports PHP4, while running PHP4 and PHP5 is very difficult. Applications running on the same server are not isolated from each other (at the file system level and at the network level), so they may conflict with each other.

Security: WordPress's security record is not very good. So create a sandbox for it, at least the hacker will not interfere with the application of other operations.

Upgrades, downgrades: Upgrade applications typically overwrite existing files. What happens during the upgrade process? Is the system going to shut down? What if the upgrade fails, or does it not? How do we quickly fall back to the previous version?

Snapshots, backups: Once all of the content is set up, create a "snapshot" of the system so that you can back up the snapshot, or even move it to another server to start again, or copy it to multiple servers for a rainy time.

Repeatability: After a new version of the system, it is better to automatically deploy and test on the test infrastructure before releasing it to the production system. You will typically use tools such as Chef, Puppet, and so on to automatically install a heap of packages on the server, and then run the same deployment script on the production system when everything is ready. This is not a problem in 99%. With 1% exceptions, the packages you rely on are updated in the package warehouse and the new version is incompatible between the time span of deployment to the test environment and the production environment. As a result, the production environment is set up differently from the test environment, and it is possible to disrupt the production system. If you don't control every aspect of your deployment (such as hosting your own apt or Yum warehouse), it is difficult to continue to build exactly the same system over multiple phases, such as testing, staging, and production environments.

Resource limitations: What if our WordPress consumes CPU resources and consumes all CPU cycles, causing other applications to do nothing? What if it ran out of all the available memory? Or crazy write log blocking disk? It is convenient to limit the resources available to the application, such as CPU, memory, and disk space.

Easy to install: it may have Debian or centos packages, or it can automate all the complex steps and install WordPress's chef recipes. But these recipes are difficult to stabilize because they need to consider possible system configurations on the target system. In many cases, these recipes can only be run on a clean system. Therefore, you are less likely to change your own bag or chef recipes. In this way, installation is a complex system engineering, not the things that can be done during the lunch break.

Easy to remove: The software should be easily and cleanly removed without leaving traces. However, deployment applications typically adjust existing profiles, settings (MySQL database data, logs), and complete removal of applications becomes less easy.

So how do we solve these problems?

Virtual machine!