8 Creating application images #
Docker Open Source Engine is designed to allow running multiple separate application environments in parallel, with lower resource use than when using full virtual machines. Several types of applications are suitable for running inside containers: daemons, Web servers, and applications that expose IP ports for communications. You can use Docker Open Source Engine to automate the building and deployment processes by performing the build process inside a container, building an image, and then deploying containers based on the image.
Running an application inside a container has the following advantages:
The image with the application is portable across servers running different Linux host distributions and versions.
You can share the image of the application using a repository.
You can use different versions of software in the container and on the host system, without creating dependency issues.
You can run several instances of the same application that are completely independent from each other.
Using Docker Open Source Engine to build applications has the following advantages:
You can prepare an image of the complete build environment.
The application can run in the same environment it was built in.
Developers can test their code in the same environment as used in production.
The following section provides examples and recommendations on creating container images for applications. Before proceeding, make sure that you have activated your SUSE Linux Enterprise Server base image as described in Section 7.1, “Pulling base SLES images”.
8.1 Running an application with specific package versions #
If your application needs a version of a package different from the package
installed on the system, you can create a container image that includes the
package version the application requires. The following example
Dockerfile
allows building an image based on an
up-to-date version of SUSE Linux Enterprise Server with an older version of the
example
package:
FROM registry.suse.com/suse/sle15 LABEL 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"]
Build the image by running the following command in the directory that the
Dockerfile
resides in:
>
docker build --tag tux_application:latest .
The Dockerfile
example shown above performs the
following operations during the docker build
:
Updates the SUSE Linux Enterprise Server repositories.
Installs the desired version of the
example
package.Copies the application package to the image. The binary RPM must be placed in the build context.
Unpacks the application.
The last two steps run the application after a container is started.
After a successful build of the tux_application
image,
you can start a container based on the new image using the following
command:
>
docker run -it --name application_instance tux_application:latest
Keep in mind that after closing the application, the container exits as well.
8.2 Running applications with a specific configuration #
To run an instance using a different configuration, create a derived image
and include the additional configuration with it. For example, if your
application is called example and can be configured
using the file /etc/example/configuration_example
, you
could use:
FROM registry.suse.com/suse/sle15 1 RUN zypper ref && zypper --non-interactive in example 2 ENV BACKUP=/backup 3 RUN mkdir -p $BACKUP 4 COPY configuration_example /etc/example/ 5 ENTRYPOINT ["/etc/bin/example"] 6
The above example Dockerfile
performs the following
operations:
Pulls the | |
Refreshes repositories and installations of the example. | |
Sets a | |
Creates the directory | |
Copies the | |
Runs the |
You can now build the image. After a successful build, you can run a container based on the image you just created.
8.3 Sharing data between an application and the host system #
Docker Open Source Engine allows sharing data between host and a container by using
volumes. You can specify a mount point directly in the
Dockerfile
. However, you cannot specify a directory on
the host system in the Dockerfile
, as the directory may
not be accessible at build time. Find the mounted directory under
/var/lib/docker/volumes/
on the host system.
After you specify a mount point by using the VOLUME
instruction, all changes made to the directory with the
RUN
instruction are discarded. After the mount point is
specified, the volume becomes a part of a temporary container, which is
removed after a successful build. This means that for certain actions to
take effect, they must be performed before specifying a
mount point. For example, if you need to change permissions, do this before
you specify the directory as a mount point in the Dockerfile
.
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
The -v
option overwrites the VOLUME
instruction if you specify the same mount point in the container.
The following example image contains a Web server that reads Web content
from the host's file system. The Dockerfile
could look
as follows:
FROM registry.suse.com/suse/sles12sp4 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 the
entire configuration to the image. The data
directory is
owned by the admin user and is used as a mount point to
store Web pages.
8.4 Applications running in the background #
If your application needs to run in the background as a daemon, or as an application exposing ports for communication, you can run the container in the background.
An example Dockerfile
for an application exposing a
port looks as follows:
FROM registry.suse.com/suse/sle15 1 LABEL maintainer=tux 2 ADD etc/ /etc/zypp/ 3 RUN zypper refs && zypper refresh 4 RUN zypper --non-interactive in apache2 5 RUN echo "The Web server is running" > /srv/www/htdocs/test.html 6 # COPY data/* /srv/www/htdocs/ 7 EXPOSE 80 8 ENTRYPOINT ["/usr/sbin/httpd"] CMD ["-D", "FOREGROUND"]
Pull the base image as in Section 7.1, “Pulling base SLES images”. | |
Maintainer of the image (optional). | |
The repositories and service files to be copied to
| |
Command to refresh repositories and services. | |
Command to install Apache2. | |
Test line for debugging purposes. This line can be removed if everything works as expected. | |
A | |
The exposed port for the Apache Web server. |
To use port 80, make sure there is no other server software running on this port on the host.
To use the container, proceed as follows:
Prepare the host system for the build process.
Make sure the host system is subscribed to the SUSE Linux Enterprise Server. To view installed modules or install additional modules, open YaST and select .
ofMake sure the SUSE Linux Enterprise images from the SUSE Registry are installed as described in Section 7.1, “Pulling base SLES images”.
Save the
Dockerfile
from Example 8.1, “Building an Apache2 Web server container (Dockerfile
)” into thedocker
directory.Within the container, you need access to software repositories and services that are registered on the host. To make them available, copy repositories and service files from the host to the
docker/etc
directory:>
cd docker>
mkdir etc>
sudo
cp -a /etc/zypp/{repos.d,services.d} etc/Instead of copying all repository and service files, you can also copy only the subset that is required by the container.
Add Web site data (such as HTML files) into the
docker/data
directory. The contents of this directory are copied to the container image and are thus published by the Web server.
Build the container. Set a tag for your image with the
-t
option (in the command below, it istux/apache2
):>
sudo
docker build -t tux/apache2 .Docker Open Source Engine executes the instructions provided in the
Dockerfile
: Pull the base image, copy content, refresh repositories, install the Apache2, etc.Start a container instance from the image created in the previous step:
>
docker run --detach --interactive --tty tux/apache2Docker Open Source Engine returns the container ID, for example:
7bd674eb196d330d50f8a3cfc2bc61a243a4a535390767250b11a7886134ab93
Point a browser to
http://localhost:80/test.html
. You should see the messageThe Web server is running
.To see an overview of running containers, use:
>
docker ps --latest CONTAINER ID IMAGE COMMAND [...] 7bd674eb196d tux/apache2 "/usr/sbin/httpd -..." [...]To stop and delete the container, run the following command:
>
docker rm --force 7bd674eb196d
You can use the resulting container to serve your data with the Apache2 Web server by following these steps:
In the
Dockerfile
:Comment the line starting with
RUN echo
by adding a#
character at its beginning (6 in Example 8.1, “Building an Apache2 Web server container (Dockerfile
)”).Uncomment the line starting with
COPY
by removing the leading#
character (7 in Example 8.1, “Building an Apache2 Web server container (Dockerfile
)”).
Rebuild the image as described in Step 2 of Procedure 8.1.
Run the image in detached mode:
>
docker run --detach --interactive --tty tux/apache2Docker Open Source Engine responds with the container ID, for example:
e43fff4ae9832ecdb7677c058a73039d7610c32145a1d9b6ad0a4ed52b5c4dc7
To view the published data, point a browser at
http://localhost:80/test.html
.
To avoid copying Web site data into the container, share a directory of the host with the container. For more information, see https://docs.docker.com/storage/volumes/ .