This is a work in progress.
In the TIER/midPoint_container GitHub project there are artifacts needed to build and deploy dockerized version of midPoint suitable to use within the TIER IdM environment.
This is the status of the work:
Requirement | Description (requirement + optionally solution comments in italics) | State |
---|---|---|
1. Base Linux Image | All TIER containers must be based on the current Centos image. As of March, 2018, this is Centos 7.
| in progress |
2. Servlet Engine | Tomcat will be used whenever a servlet engine is needed. | done |
3. Java Distribution | Zulu should be used. | waiting |
4. Database |
Solution comments: The midPoint repository can be attached to the midPoint server in a flexible way. It can be either deployed in an (alternative) Docker container, or be provided externally either on premises or in the cloud. | done (except that we use a custom-built MariaDB image instead of TIER-maintained one) |
5. Multi-Process Container | Supervisord will be used whenever a container needs more than one process. | waiting |
6. TIER Beacon | Run the TIER Beacon code on a regular interval as specified in the documentation. Unless the component has its own scheduling mechanism for running external code, this requirement will usually result in the need to support cron and run supervisord in the container. | waiting |
7. Container Configuration a) Standard Data |
| ready for comments |
7. Container Configuration b) Secret Data |
| ready for comments (to do: resource passwords) |
8. Container Orchestration |
| currently using docker-compose up command, compatibility with other orchestration frameworks is to be tested |
9. Logging |
| ready for comments |
10. Shibboleth integration | Users can be authenticated to midPoint using Shibboleth. | in progress |
Documentation
Logging feature
Logging is configured by setting the following environment variables: either from the command line or from docker-compose.yml (see commented-out examples in the provided file).
Environment variable | Meaning | Default value |
---|---|---|
COMPONENT | component name | midpoint |
LOGFILE | native log file name | midpoint.log |
ENV | environment (e.g. prod, dev, test) | demo |
USERTOKEN | arbitrary user-supplied token | current midPoint version, e.g. 3.9-SNAPSHOT |
According to the specification, semicolons in these fields are eliminated (replaced by underscores). The same is done for spaces in ENV
and USERTOKEN
.
Repository attachment feature
Repository configuration is done via the following environment variables.
Environment variable | Meaning | Default value |
---|---|---|
REPO_DATABASE_TYPE | Type of the database. Supported values are mariadb , mysql , postgresql , sqlserver , oracle . It is possible to use H2 as well but H2 is inappropriate for production use. | mariadb |
REPO_JDBC_URL | URL of the database. | MariaDB: MySQL: PostgreSQL: SQL Server: Oracle: |
REPO_HOST | Host of the database. Used to construct the URL. | midpoint-data |
REPO_PORT | Port of the database. Used to construct the URL. | 3306 |
REPO_DATABASE | Specific database to connect to. Used to construct the URL. | midpoint |
REPO_USER | User under which the connection to the database is made. | root |
REPO_PASSWORD_FILE | File (e.g. holding a docker secret) that contains the password for the db connection. | /run/secrets/m_database_password.txt |
Docker secrets
As of v3.9devel-578-gb20f43e
(September 10th, 2018), each configuration parameter can be supplied either as a string value or as a file reference. This is to allow using Docker secrets to provide values for sensitive parameters.
Currently, there are two standard places when references to Docker secrets might be used:
Environment variable | Meaning | Default value |
---|---|---|
REPO_PASSWORD_FILE | File that contains the password for the db connection. | /run/secrets/m_database_password.txt |
KEYSTORE_PASSWORD_FILE | File that contains the password for the standard midPoint keystore. | /run/secrets/m_keystore_password.txt |
This is how these file references are used:
If a configuration parameter name (e.g. midpoint.keystore.keystorePassword
) is suffixed by _FILE
, i.e. forming midpoint.keystore.keystorePassword_FILE
, then the value of the configuration parameter is taken from the specified file. As with the regular parameters, the file pointer can be defined either in config.xml
or in the command line, using -D
Java option. So, for example, mapping of REPO_PASSWORD_FILE
and KEYSTORE_PASSWORD_FILE
environment variables is done by the following lines in midPoint Dockerfile
:
ENV REPO_PASSWORD_FILE /run/secrets/m_database_password.txt ENV KEYSTORE_PASSWORD_FILE /run/secrets/m_keystore_password.txt (...) # Execution CMD java -Xmx$MEM -Xms2048M -Dfile.encoding=UTF8 \ (...) -Dmidpoint.repository.jdbcPassword_FILE=$REPO_PASSWORD_FILE \ -Dmidpoint.keystore.keyStorePassword_FILE=$KEYSTORE_PASSWORD_FILE \ (...) -jar $MP_DIR/lib/midpoint.war
If needed, other sensitive information can be provided to midPoint in similar way. In particular, constants are expected to be used here, typical example being resource passwords.
TODO an example
Shibboleth integration
...