Docker support

Docker vs virtual machine

Compared to traditional virtual machines, Docker containers are more light-weight. Virtual machines are an abstraction of physical hardware turning one server into many servers. Each virtual machine includes a full copy of the OS, one or more applications, necessary binaries and libraries. As a result, a typical virtual machine image might take up tens of GBs and can be slow to start. Docker containers are an abstraction at the application layer that packages code and dependencies together. Multiple containers can run on the same machine and share the OS kernel with other containers, each running as isolated processes in user space. Containers take less space than virtual machines (container images are typically tens of MBs in size), and can start almost instantly.

Docker principles

Security Verify Access Docker support was implemented with the following Docker principles in mind.

• Containers are supposed to be ephemeral.

  Design them in a way that you can stop and destroy an old container and build a new one with an absolute minimum of set-up and configuration.

• Minimize the images.

  To reduce complexity, dependencies, file sizes, and build times, avoid installing extra or unnecessary packages. For example, do not include a text editor in a database image.

• Single service.

  Decoupling applications into multiple containers makes it much easier to scale horizontally and reuse containers. For instance, a web application stack might consist of three separate containers, each with its own unique image to manage the web application, database, and an in-memory cache in a decoupled manner.

These principles are guidelines from Docker. For more information, see the Best practices for writing Dockerfiles topic on the Docker website.

Docker terms

The following paragraphs explains some of the common Docker terms used throughout this document.

Image

Docker images are the basis of containers. An Image is an ordered collection of root filesystem changes and the corresponding execution parameters for use within a container runtime. An image typically contains a union of layered file systems stacked on top of each other. An image does not have state and it never changes.

Container

A container is a runtime instance of a Docker image. A Docker container consists of:

• A Docker image
• An execution environment
• A standard set of instructions

Volume

A volume is a specially-designated directory within one or more containers that bypasses the Union File System. Volumes are designed to persist data, independent of the container's life cycle. For more details, see https://docs.docker.com/engine/tutorials/dockervolumes/.

For more Docker terms, see the Docker Glossary page on the Docker website.

Docker networking

The Docker host manages the networking of the Docker containers. Docker containers that reside on the same Docker host can communicate with each other using the internal Docker network. If a Docker container wishes to expose a service (or port) to machines that are not located on the same Docker host, they need to utilize the port mapping capabilities of the Docker host. This capability allows a port from the Docker container to be mapped to a port on the Docker host.

You expose ports using the EXPOSE keyword in the Dockerfile or the --expose flag to docker run. Exposing ports is a way of documenting which ports are used, but does not actually map or open any ports. Exposing ports is optional.

You publish ports using the PUBLISH keyword in the Dockerfile or the --publish flag to docker run. This tells Docker which ports to open on the container’s network interface. When a port is published, it is mapped to an available high-order port (higher than 30000) on the host machine, unless you specify the port to map to on the host machine at runtime. You cannot specify the port to map to on the host machine in a Dockerfile, because there is no way to guarantee that the port will be available on the host machine where you run the image.

For more information about Docker networking, see the Docker container networking topic on the Docker website.

Security Verify Access in Docker

The following diagram shows the required elements for Security Verify Access to run in a Docker environment. Each box corresponds to a Docker container.

When Security Verify Access runs in a Docker environment, each container provides a single service, such as configuration, Web Reverse Proxy instance, runtime profile (also known as Advanced Access Control/Federation), and Distributed Session Cache (DSC). The Security Verify Access Image can run as any one of these four containers (shown in green boxes). Smaller and more efficient images are provided as a recommended alternative to using the main Security Verify Access image for the runtime profile (see Docker image for Verify Access Runtime), the Web reverse proxy (see Docker image for Verify Access Web Reverse Proxy) and the distributed session cache (see Docker image for Verify Access Distributed Session Cache).

The environment also requires an external user registry and database for runtime (for example, DB2, Oracle). The runtime database is required only if you use the Advanced Access Control or Federation capabilities. The external user registry is always required. IBM provides some extensions to third party images that can be used to provide these services. These images (ibmcom/verify-access-openldap and ibmcom/verify-access-postgresql) are available for download from Docker Hub.

The configuration container is used as a tool to generate the configuration data. The configuration data is shared with the runtime containers through one of the following methods:

• Using a shared volume that has been mounted to the "/var/shared" directory in the container.
• Manually copying the snapshot to the correct location using the Docker commands (the default snapshot file name is: "/var/shared/snapshots/isva_<release_number>_published.snapshot", for example "/var/shared/snapshots/isva_10.0.0.0_published.snapshot").
• Using the configuration service that has been exposed from the Security Verify Access configuration container. See Configuration service.

Images that include all the necessary services to run Security Verify Access in a Docker environment are provided for download.