Container support

Container vs virtual machine

Compared to traditional virtual machines, 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. 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.

Container principles

Verify Identity Access Container support was implemented with the following container 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.

Container terms

The following paragraphs explain some of the common container terms that are used throughout this document.

Image

Container 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 container image. A container consists of:

• A Container 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 container terms, see the Docker Glossary page on the Docker website.

Container networking

The container host manages the networking of the containers. Containers that reside on the same container host can communicate with each other using the internal container network. If a container wants to expose a service or port to servers that are not on the same container host, they need to use the port-mapping capabilities of the container host. This capability allows a port from the container to be mapped to a port on the container host.

You expose ports by using the EXPOSE keyword in the Containerfile, or Dockerfile, or the --expose flag to container 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 Containerfile, or Dockerfile, or the --publish flag to podman run. This keyword tells the container runtime 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 Containerfile, or 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 container networking, see the Docker container networking topic on the Docker website.

Verify Identity Access in containers

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

When Verify Identity Access runs in a container 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 Verify Identity 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 Verify Identity Access image for the runtime profile (see container image for Verify Identity Access Runtime), the web reverse proxy (see container image for Verify Identity Access Web Reverse Proxy) and the distributed session cache (see Container image for Verify Identity Access Distributed Session Cache).

The environment also requires an external database for runtime (for example, DB2, Oracle). The runtime database is required only if you use the Advanced Access Control or Federation capabilities. IBM provides some extensions to a third-party image that can be used to provide this service. The image (icr.io/ivia/ivia-postgresql) is 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 appropriate container runtime commands. The default snapshot file name is "/var/shared/snapshots/isva_<release_number>_published.snapshot". For example, "/var/shared/snapshots/isva_11.0.2.0_published.snapshot".
• Using the configuration service that was exposed from the Verify Identity Access configuration container. See con_container_image_config.html.

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