MidPoint In Container

Last modified 12 Mar 2024 17:07 +01:00

Quick Start

The containers are the easiest and the fastest way how to start working with midPoint. In case this is your the fist contact with midPoint, please see the Quick Start page, where you can find basic and useful information.

Benefits of midPoint in container

  • Dependency under full control
    The container is created with the required Java version.

  • Cloud friendly
    The container can be run both locally (e.g. docker, podman) or even in the cloud (e.g. kubernetes, aws, Azure, Google cloud).

  • The starting state is guaranteed
    Anytime, you can easily start the new environment in many scenarios in fully controlled way.

  • Pre-configured environment
    Basic configuration is available. The environment is almost ready to run - only small specific setting is needed. All requirements to initialize the repository are available.
    The image can be easily Customized by the configuration to cover the most of the expected usage.

Image is based on standards from OCI (Open Container Initiative). The documentation is focused on Docker or vanilla Kubernetes usage.
You can use any other compatible environment. In that case, the following content is still valid for you. Small customization of the configuration for the specific environment may be needed.

Deployment

For the regular operation the repository (relation DB) is needed. The native repository schema, which is available for postgreSQL is required. As long as we are in container environment, this is covered by additional container with PostgreSQL instance.

The structure (schema) has to be initiated in advance. Once the correct schema version is ready, the midPoint checks the initial object (content) and push it if necessary.

There is a generic repository implementation available, which also covers other than PostgreSQL DB. This repository schema is deprecated. The available feature set is limited and no new features are available with this repository schema. In case you are historically using this repository schema, we strongly recommend to migrate to native repository.

The availability of deprecated generic repository schema may require the active subscription.

containerized env
Figure 1. Schema of the containerized environment (base setup)

In basic setup there are 3 containers needed.

  • midPoint instance - midpoint_server in the diagram
    Once the environment is ready the midPoint itself can be started.

    Image : evolveum/midpoint
    Tag : <released version> (e.g. 4.8.2-alpine )

  • Initialization of the environment - data_init in the diagram
    This container handles all the requirements for the environment, which have to be prepared before the midPoint instance will start.

    The requirement is to use the same version of the image as for container with midPoint to ensure the correct version of definition is used.

    • Repository init
      The process uses ninja application to connect to the database as a client. If needed, the repository structure (schema) is created.
      In the diagram this communication is shown as Network data.

    • Configuration init
      The process uses ninja application to prepare basic native repository configuration. All additional information like DB URI is updated afterward via environment variable(s) on the container.
      In the diagram this communication is shown as Storage data.

      In the complex installation the init phase can be skipped by the design. In that case the environment is initialized separately as explicit process during the build of the environment.
      The provided configuration counts with the situation that the environment is prepared directly during the first run.

  • Repository - midpoint_data in the diagram
    For the repository we only need a running instance of PostgreSQL server, where it is possible to connect from the midPoint container. All the rest is handled from client side of the connection

    Image : postgres
    Tag : see release notes for recommended version (e.g. 16-alpine)

For more information see the dedicated subpage:

Build the container

We build the images in our jenkins infrastructure. After basic tests (e.g. the environment can be started) the images are pushed to the public Docker hub repository. All the necessary resources for the docker image build are publicly available like other our resources on GitHub.

Structure of the image name

The name consists of the image name and the tag. The name is "stable" in form evolveum/midpoint. The tag differs depending on the version and base OS used for the image.

Currently we are using following Base OSs

Table 1. Used based OSs for the image and their tag suffixes
BaseOS suffix for the tag

Alpine

-alpine

Rocky Linux

-rockylinux

Ubuntu

Currently the Ubuntu based image is default - without suffix. We are planning the switch to the apline as the default base OS.

Table 2. example of the tags
Version Base Os image

4.8 release

Ubuntu

evolveum/midpoint:4.8

4.8 release

Rocky Linux

evolveum/midpoint:4.8-rockylinux

4.8-support (snapshot)*

Alpine

evolveum/midpoint:4.8-support-alpine

latest dev build

Alpine

evolveum/midpoint:latest-alpine

latest dev build

Ubuntu

evolveum/midpoint:latest
evolveum/midpoint

Support branch / support build is build of the working code. It is used to cumulate the bug fixes between the releases. If you are looking for some fix (e.g. the ticket is closed with code update ) the support build contains the fix with the first following build. It is a rolling tag so in it is changing in time. Check for update of the image from time to time.

Was this page helpful?
YES NO
Thanks for your feedback