6 Creating Docker Images of Applications #
Docker Open Source Engine is a technology that can help you to minimize resources used to run or build your applications. There are several types of applications that are suitable to run inside a Docker container like daemons, Web pages or applications that expose ports for communication. You can use Docker Open Source Engine to automate building and deployment processes by adding the build process into a Docker image, then building the image and then running containers based on that image.
Running your application inside a Docker container provides you with the following advantages:
You can minimize the runtime environment of the application as you can add to the Docker image of the application just the required processes and applications.
The image with your application is portable across machines also with different Linux host systems.
You can share the image of your application by using a repository.
You can use different versions of required packages in the container than the host system uses without having problems with dependencies.
You can run several instances of the same application that are completely independent from each other.
Using Docker Open Source Engine for building of applications provides the following features:
You can prepare a complete building image.
Your build always runs in the same environment.
Your developers can test their code in the same environment as used in production.
You can set up an automated building process.
The following section provides you with examples and tips on how to create Docker images of your applications. Prior to reading further, make sure that you have activated your SLES base Docker image as described in Section 5.1, “Obtaining Base SLES Images”.
6.1 Running an Application with Specific Package Versions #
You may face a problem that your application uses a specific version of a package that is different from the package installed on the system that should run your application. You can modify your application to work with another version or you may create a Docker image with that particular package version. The following example of a Dockerfile
shows an image based on a current version of SLES but with an older version of the example
package
FROM registry.suse.com/suse/sles12sp4:latest MAINTAINER Tux RUN zypper ref && zypper in -f example-1.0.0-0 COPY application.rpm /tmp/ RUN zypper --non-interactive in /tmp/application.rpm ENTRYPOINT ["/etc/bin/application"] CMD ["-i"]
Now you can build the image by running in the same directory as the Dockerfile
resides:
docker build --tag tux_application:latest .
The Dockerfile
example shown above
performs the following operations during the docker
build
:
Updates the SLES repositories.
Installs the desired version of the
example
package.Copies your application package to the image. The source RPM must be placed in the build context.
Unpacks your application.
The last two steps run your application after a container is started.
After a successful build of the tux_application
image, you can start a container based on your new image:
docker run -it --name application_instance tux_application:latest
You have created a container that runs a single instance of your application. Bear in mind that after closing the application, the Docker container exits as well.
6.2 Running Applications with Specific Configuration #
You may need to run an application that is delivered in a standard package accessible through SLES repositories but you may need to use a different configuration or use specific environment variables. In case you would like to run several instances of the application with non-standard configuration, you can create your own image that will pass the custom configuration to the application.
An example with the example application follows:
FROM registry.suse.com/suse/sles12sp4:latest RUN zypper ref && zypper --non-interactive in example ENV BACKUP=/backup RUN mkdir -p $BACKUP COPY configuration_example /etc/example/ ENTRYPOINT ["/etc/bin/example"]
The above example Dockerfile
results in the following operations:
Refreshing of repositories and installation of the example.
Sets a
BACKUP
environment variable (the variable persists to containers started from the image). You can always overwrite the value of the variable with a new one while running the container by specifying a new value.Creates the directory
/backup
.Copies the
configuration_example
to the image.Runs the example application.
Now you can build the image and after a successful build, you can run a container based on your image.
6.3 Sharing Data between an Application and the Host System #
You may run an application that needs to share data between the application's container and the host file system. Docker Open Source Engine enables you to do data sharing by using volumes. You can declare a mount point directly in the Dockerfile
. But you cannot specify a directory on the host system in the Dockerfile
as the directory may not be accessible at the build time. You can find the mounted directory in the /var/lib/docker/volumes/
directory on the host system.
After you declare a mount point by using the VOLUME
instruction, all your changes performed (by using the RUN
instruction) to the directory will be discarded. After the declaration, the volume is part of a temporary container that is then removed after a successful build. In case you need to e.g. change permissions, perform the change before you declare the directory as a mount point in the Dockerfile
.
You can specify a particular mount point on the host system when running a container by using the -v
option:
docker run -it --name testing -v /home/tux/data:/data sles12sp4:latest /bin/bash
Using the -v
option overwrites the VOLUME
instruction if you specify the same mount point in the container.
Now let's create an example image with a Web server that will read Web content from the host's file system. The Dockerfile
could look as follows:
FROM registry.suse.com/suse/sles12sp4:latest RUN zypper ref && zypper --non-interactive in apache2 COPY apache2 /etc/sysconfig/ RUN chown -R admin /data EXPOSE 80 VOLUME /data ENTRYPOINT ["apache2ctl"]
The example above installs the Apache Web server to the image and copies all your configuration to the image. The data
directory will be owned by the admin user and will be used as a mount point to store your web pages.
6.4 Applications Running in the Background #
Your application may need to run in the background as a daemon or as an application exposing ports for communication. In that case a typical Docker Open Source Engine container may be run in background. An example Dockerfile
for an Apache2 server exposing a port looks as follows:
Dockerfile
for an Apache2 Web Server #FROM registry.suse.com/suse/sles12sp4:latest 1 MAINTAINER tux 2 RUN zypper ref -s && zypper --non-interactive in apache2 RUN echo "The Web Server is running" > /srv/www/htdocs/test.html 3 # COPY data/* /srv/www/htdocs/ 4 EXPOSE 80 5 ENTRYPOINT ["/usr/sbin/httpd"] CMD ["-D", "FOREGROUND"]
Base image, taken from Section 5.1, “Obtaining Base SLES Images”. | |
Optional maintainer of the image. | |
The test line for debugging purposes; can be removed if everything works as expected. | |
The copy instruction to copy your own data to the server's directory. Currently, this line is disabled due to the hash mark in the first column. | |
The exposed port for the Apache Web server. |
Make sure that you do not have any Apache2 server instances running on your host. The Docker container would not serve any data if you have a host Apache2 server running. Remove or stop any Apache2 servers on your host.
To use the container, proceed as follows:
Prepare for the build process:
Make sure you have installed the SUSE Linux Enterprise images as described in Section 5.1, “Obtaining Base SLES Images”.
Save the
Dockerfile
from Example 6.1, “Dockerfile
for an Apache2 Web Server” to a directorydocker
.Create your HTML files inside
docker/data
. Anything you put in this directory is copied to the Docker image and as such exposed on your Web server.
Build the container. Set a tag for your image with the
-t
option (heretux/apache2
, but you can use any name you want):sudo docker build -t tux/apache2 .
Docker Open Source Engine refreshes repositories and installs the Apache2 server as it is not installed by default in the SLES Docker image.
Run the image in “detached” mode:
docker run --detach --interactive --tty tux/apache2
Docker Open Source Engine responds with the container ID, for example:
7bd674eb196d330d50f8a3cfc2bc61a243a4a535390767250b11a7886134ab93
Open a Web browser and enter in the text field
http://localhost:80/test.html
. You should see the outputThe Web Server is running
.
With the last procedure, you have built an image which was used to test the build process and the Apache2 Web server. If everything was successful, use the following steps to serve your data through the Apache2 Web server:
Stop and remove the previous container with:
docker ps --latest CONTAINER ID IMAGE COMMAND [...] afee0124a0c7 tux/apache2 "/usr/sbin/httpd -..." [...] docker rm --force afee0124a0c7
Remove or disable the echo line 3 in Example 6.1, “
Dockerfile
for an Apache2 Web Server” and remove the hash character in the first column of the copy line 4.Rebuild the image as described in Step 2 of Procedure 6.1.
Run the image in “detached” mode:
docker run --detach --interactive --tty tux/apache2
Docker Open Source Engine responds with the container ID, for example:
e43fff4ae9832ecdb7677c058a73039d7610c32145a1d9b6ad0a4ed52b5c4dc7
You can now access your data at http://localhost:80
.
If you do not want to copy your data into the Docker container,
share a specific directory on your host. Refer to
https://docs.docker.com/storage/volumes/
for more information.