Docker support
Security Verify Access can run in a Docker environment.
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 we 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. 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.
We 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.
We 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 we specify the port to map to on the host machine at runtime. We cannot specify the port to map to on the host machine in a Dockerfile, because there is no way to guarantee the port will be available on the host machine where you run the image.
For 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 ISAM to run in a Docker environment. Each box corresponds to a Docker container.
When ISAM 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).
The environment also requires an external user registry and database for runtime (for example, DB2, Oracle). The runtime database is required only if we 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:
- Use 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").
- Use the configuration service that has been exposed from the ISAM configuration container. See Configuration service.
Images that include all the necessary services to run ISAM in a Docker environment are provided for download.
Image Image repository Image name IBM Security Verify Access Docker Hub ibmcom/verify-access OpenLDAP Docker Hub ibmcom/verify-access-openldap PostgreSQL Docker Hub ibmcom/verify-access-postgresql
- Docker image for ISAM
- Docker image for PostgreSQL support
- Docker image for OpenLDAP support
- Scenarios
- Orchestration
- CLI in a Docker environment
- Distributed Session Cache in Docker environment
Parent topic: Appliance administration