MidPoint In Container
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. |
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. |
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.9-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 connectionImage : postgres
Tag : see release notes for recommended version (e.g. 16-alpine)
For more information see the dedicated subpage:
-
docker compose related page
-
kubernetes page
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
BaseOS | suffix for the tag |
---|---|
Alpine |
-alpine |
Rocky Linux |
-rockylinux |
Ubuntu |
-ubuntu |
Currently the Ubuntu based image is default - without suffix (alias to -ubuntu). We are planning the switch to the alpine as the default base OS. |
Since 4.8.3 the images are published for AMD64 and ARM64 platforms. The images are published with multiplatform manifest. You are requesting simply the tag and the proper platform is automatically selected. No extra step is needed. |
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:devel-alpine |
latest dev build |
Ubuntu |
evolveum/midpoint:devel-ubuntu |
last released version (4.9) |
Alpine |
evolveum/midpoint:latest-alpine |
last released version (4.9) |
Ubuntu |
evolveum/midpoint:latest |
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. |