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 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.
![](../graphics/container_vm.jpg)
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.
![The graphic shows the docker containers for Runtime services and Security Verify access images.](../graphics/isam_docker.jpg)
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.
Image | Image repository | Image name |
---|---|---|
IBM Security Verify Access | IBM Cloud Container Registry | icr.io/isva/verify-access |
IBM Security Verify Access Runtime | IBM Cloud Container Registry | icr.io/isva/verify-access-runtime |
IBM Security Verify Access Web Reverse Proxy | IBM Cloud Container Registry | icr.io/isva/verify-access-wrp |
IBM Security Verify Access Distributed Session Cache | IBM Cloud Container Registry | icr.io/isva/verify-access-dsc |
OpenLDAP | IBM Cloud Container Registry | icr.io/isva/verify-access-openldap |
PostgreSQL | IBM Cloud Container Registry | icr.io/isva/verify-access-postgresql |