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 that turns 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 server and share the OS kernel with other containers. Each runs as isolated processes in the 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.

  By decoupling applications into multiple containers, you can 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 explain some of the common Docker terms that are used throughout this document.

Image

Docker images are the basis of containers. An Image is an ordered collection of root file system changes and the corresponding execution parameters for use within a container runtime. An image typically contains a union of layered file systems that are 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 lifecycle. For more information, 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 wants to expose a service or port to servers that are not on the same Docker host, they need to use 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 by 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 map or open any ports. Exposing ports is optional.

You publish ports by using the PUBLISH keyword in the Dockerfile or the --publish flag to docker run. This keyword 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 server at run time. You cannot specify the port to map to on the host machine in a Dockerfile because no way exists to guarantee that the port can be available on the host server 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 (icr.io/isva/verify-access-openldap and icr.io/isva/verify-access-postgresql) are available for download from IBM Cloud Container Registry.

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 was mounted to the "/var/shared" directory in the container.
• Manually copying the snapshot to the correct location by 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 was exposed from the Security Verify Access configuration container. See con_docker_file_isam.html.

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