Appliance architecture

IAM appliance is based on a publicly available Linux operating system CentOS. Several locally installed services run in this environment (administration console, container daemon, monitoring, firewall, etc.). Furthermore, containerized services run in the environment as well (CzechIdM, access manager CAS, LDAP, etc.).

Each service that is available to users is containerized. Services used to configure the appliance itself are installed locally.

The usual way of distributing software into the appliance are RPM packages and Docker container images.

Local services

Services which are locally installed in the appliance are not available to non-privileged users or client applications.

These services are used for managing and monitoring of the environment, and are thus used by the appliance administrators but not administrators of the applications running in the appliance!

Examples of local services are: SSHd daemon, Cockpit, monitoring, log aggregators, Docker daemon, firewall, etc.

Services are installed and configured using RPM packages. These services are not containerized.

Containerized services

Each service has its own RPM package with which it is installed. Names of these packages start with iam-app-.

The RPM package usually consists of:

  1. A list of local directories on the appliance filesystem which are mounted into Docker container with the application.

  2. Docker Compose YAML file with service configuration.

  3. Secrets, certificates and generally all information needed to run the service. These components are not usually a fixed part of the package but are generated during the package installation in the environment. This ensures that secrets are unique.

  4. Other files such as modules, graphics, branding, etc. These are always seen as static files on the appliance filesystem and are used by the containerized applications.

  5. Additional configuration for setting up a service inside the appliance - systemd units, log redirects and rotation, etc.

The goal of the RPM package is to prepare everything what the containerized application needs to run. If, for example, two containers need the same secret, the RPM package ensures the transfer of the secret between container configurations during its installation.

The package also ensures the registration of a specific container as an operating system service. The service can then be controlled using systemctl.

Running a containerized service

After the RPM package installation, the service is ready to be started. Some services may require further configuration before their first start, for example to configure hostnames.

Configured service can be started by command systemctl start SERVICE. After calling this command, the specific docker-compose-SERVICE.yml configuration file is deployed into the Docker daemon.

  1. If the container image is not locally available, it will be automatically downloaded. This can take several minutes.

  2. It the image is locally available, the container is instantiated and started. The time needed to start the service depends on the application and can be in the order of seconds or minutes.

Running a containerized service

The rules and processes of running a service are determined by the service.

Service vs. container vs. container image

These terms may seem interchangeable but they are not. The list below notes the basic differences between them.

  • Container image

    • The way of distributing software in the IAM appliance.

    • Static binary image. After its instantiation (completing the settings) a container is created.

    • One image can be instantiated into multiple containers.

  • Container

    • An instance of image in which the application is run (e. g., CzechIdM).

    • The container can be removed and recreated from an image at any moment. All persistent data of the container are saved in the appliance filesystem and are mounted into the container.

    • Container makes up the main part of the service but not the entire service.

  • Service

    • It is distributed in an RPM package.

    • It contains reference to a container image and further configuration. This information is used during the start of the service to instantiate the container.

    • It container further data - program modules, branding, etc., which are mounted into the container.

    • It contains additional configuration.

      • Redirection of container logs to the appliance filesystem.

      • Log rotation.

      • Scheduled tasks (e. g., backup, if a database runs in the container).

      • Shared directories if the service gives data to or receives data from another service.

Optional services

The appliance allows the installation of optional services, e. g., connector server, data exchangers, etc. These services are used in the same way as other containerized services.

Optional services are not installed in the appliance by default but can be installed using an RPM package. After installing the RPM package, the operating system monitors available updates of the package using its standard tools.

Optional services can have explicit dependencies on the version of the appliance or its components. The mandatory services never depend on optional services.