Docker: Lightweight Linux Containers for Consistent Development and Deployment
There are various ways in which Docker can be integrated into the development and deployment process. Let's take a look at a sample workflow illustrated in Figure 4. A developer in our hypothetical company might be running Ubuntu with Docker installed. He might push/pull Docker images to/from the public registry to use as the base for installing his own code and the company's proprietary software and produce images that he pushes to the company's private registry.
The company's QA environment in this example is running CentOS and Docker. It pulls images from the public and private registries and starts various containers whenever the environment is updated.
Finally, the company hosts its production environment in the cloud, namely on Amazon Web Services, for scalability and elasticity. Amazon Linux is also running Docker, which is managing various containers.
Note that all three environments are running different versions of Linux, all of which are compatible with Docker. Moreover, the environments are running various combinations of containers. However, since each container compartmentalizes its own dependencies, there are no conflicts, and all the containers happily coexist.
Figure 4. Sample Software Development Workflow Using Docker
It is crucial to understand that Docker promotes an application-centric container model. That is to say, containers should run individual applications or services, rather than a whole slew of them. Remember that containers are fast and resource-cheap to create and run. Following the single-responsibility principle and running one main process per container results in loose coupling of the components of your system. With that in mind, let's create your own image from which to launch a container.
Creating a New Docker Image
In the previous example, you interacted with Docker from the command line. However, when creating images, it is far more common to create a "Dockerfile" to automate the build process. Dockerfiles are simple text files that describe the build process. You can put a Dockerfile under version control and have a perfectly repeatable way of creating an image.
For the next example, please refer to the "PHP Box" Dockerfile (Listing 1).
Listing 1. PHP Box
# PHP Box # # VERSION 1.0 # use centos base image FROM centos:6.4 # specify the maintainer MAINTAINER Dirk Merkel, firstname.lastname@example.org # update available repos RUN wget http://dl.fedoraproject.org/pub/epel/6/x86_64/ ↪epel-release-6-8.noarch.rpm; rpm -Uvh epel-release-6-8.noarch.rpm # install some dependencies RUN yum install -y curl git wget unzip # install Apache httpd and dependencies RUN yum install -y httpd # install PHP and dependencies RUN yum install -y php php-mysql # general yum cleanup RUN yum install -y yum-utils RUN package-cleanup --dupes; package-cleanup --cleandupes; ↪yum clean -y all # expose mysqld port EXPOSE 80 # the command to run CMD ["/usr/sbin/apachectl", "-D", "FOREGROUND"]
Let's take a closer look at what's going on in this Dockerfile. The syntax of a Dockerfile is a command keyword followed by that command's argument(s). By convention, command keywords are capitalized. Comments start with a pound character.
The FROM keyword indicates which image to use as a base. This must be
the first instruction in the file. In this case, you will build on top of
the latest CentOS base image. The
MAINTAINER instruction obviously lists
the person who maintains the Dockerfile. The
RUN instruction executes a
command and commits the resulting image, thus creating a new layer. The
RUN commands in the Dockerfile fetch configuration files for additional
repositories and then use Yum to install curl, git, wget, unzip, httpd,
php-mysql and yum-utils. I could have combined the
commands into a single
RUN instruction to avoid successive commits.
EXPOSE instruction then exposes port 80, which is the port on which
Apache will be listening when you start the container.
CMD instruction will provide the default command to run when
the container is being launched. Associating a single process with the
launch of the container allows you to treat a container as a command.
docker build -t php_box . on the command line will now tell
Docker to start the build process using the Dockerfile in the current
working directory. The resulting image will be tagged
will make it easier to refer to and identify the image later.
The build process downloads the base image and then installs Apache
httpd along with all dependencies. Upon completion, it returns a hash
identifying the newly created image. Similar to the MySQL container you
launched earlier, you can run the Apache and PHP image using the
tag with the following command line:
docker run -d -t
Let's finish with a quick example that illustrates how easy it is to layer on top of an existing image to create a new one:
# MyApp # # VERSION 1.0 # use php_box base image FROM php_box # specify the maintainer MAINTAINER Dirk Merkel, email@example.com # put my local web site in myApp folder to /var/www ADD myApp /var/www
This second Dockerfile is shorter than the first and really contains
only two interesting instructions. First, you specify the
"php_box" image as
a starting point using the
FROM instruction. Second,
you copy a local
directory to the image with the
ADD instruction. In this case, it is
a PHP project that is being copied to Apache's DOCUMENT_ROOT folder on
the images. The result is that the site will be served by default when
you launch the image.
Docker's prospect of lightweight packaging and deploying of applications and dependencies is an exciting one, and it is quickly being adopted by the Linux community and is making its way into production environments. For example, Red Hat announced in December support for Docker in the upcoming Red Hat Enterprise Linux 7. However, Docker is still a young project and is growing at breakneck speed. It is going to be exciting to watch as the project approaches its 1.0 release, which is supposed to be the first version officially sanctioned for production environments. Docker relies on established technologies, some of which have been around for more than a decade, but that doesn't make it any less revolutionary. Hopefully this article provided you with enough information and inspiration to download Docker and experiment with it yourself.
As this article was being published, the Docker team announced the release of version 0.8. This latest deliverable adds support for Mac OS X consisting of two components. While the client runs natively on OS X, the Docker dæmon runs inside a lightweight VirtualBox-based VM that is easily managed with boot2docker, the included command-line client. This approach is necessary because the underlying technologies, such as LXC and name spaces, simply are not supported by OS X. I think we can expect a similar solution for other platforms, including Windows.
Version 0.8 also introduces several new builder features and experimental support for BTRFS (B-Tree File System). BTRFS is another copy-on-write filesystem, and the BTRFS storage driver is positioned as an alternative to the AuFS driver.
Most notably, Docker 0.8 brings with it many bug fixes and performance enhancements. This overall commitment to quality signals an effort by the Docker team to produce a version 1.0 that is ready to be used in production environments. With the team committing to a monthly release cycle, we can look forward to the 1.0 release in the April to May timeframe.
Main Docker Site: https://www.docker.io
Docker Registry: https://index.docker.io
Docker Registry API: http://docs.docker.io/en/latest/api/registry_api
Docker Index API: http://docs.docker.io/en/latest/api/index_api
Docker Remote API: http://docs.docker.io/en/latest/api/docker_remote_api
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Tech Tip: Really Simple HTTP Server with Python
- Doing for User Space What We Did for Kernel Space
- Rogue Wave Software's Zend Server
- Parsing an RSS News Feed with a Bash Script
- SuperTuxKart 0.9.2 Released
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide