@@ -30,21 +30,12 @@ The Keycloak Admin Console offers also an easy way to export realms. So why not
#### Brief explanation of the arguments used for exporting realms
*`-Djboss.socket.binding.port-offset`
Specifies port offset which this action will use. We want to run the export on a different port than Keycloak itself. By default, the jboss server in the current setup uses the 9990 port. Therefore, providing e.g. 100 as a value here will result in the command using the 10090 port.
*`-Dkeycloak.migration.action`
Specifies what action should be taken, export or import.
*`-Dkeycloak.migration.provider`
Defines how we want the data. We use `singleFile`, to export all the data into a single file.
*`-Dkeycloak.migration.usersExportStrategy`
Specifies the strategy to export realm users. We use `REALM_FILE` to export the users to the same file as the realm configuration.
*`-Dkeycloak.migration.file`
*`--file`
Defines the file where we want to save the data. Remember to prepend to the filename the exact same value that is used for the volume mapping in the `docker-compose.yml`.
*`--users`
Specifies the strategy to export realm users. We set the value to `realm_file` to export the users to the same file as the realm configuration.
### Importing Realms
...
...
@@ -53,21 +44,20 @@ Having a dockerized Keycloak service that works out of the box and contains an i
#### Brief explanation of the arguments used for importing realms
*`-Djboss.socket.binding.port-offset`
Specifies port offset which this action will use. We want to run the import on a different port than Keycloak itself. By default, the jboss server in the current setup uses the 9990 port. Therefore, providing e.g. 10 as a value here will result in the command using the 10000 port.
*`--file`
Defines the file which we want to import the data from. Remember to prepend to the filename the exact same value that is used for the volume mapping in the `docker-compose.yml`.
*`--override`
Specifies how to proceed when a realm with the same name already exists in the database. We set the value to `false` to avoid overwriting a realm if it already exists.
*`-Dkeycloak.migration.action`
Specifies what action should be taken, export or import.
*`-Dkeycloak.migration.provider`
Defines how we are importing the data. We use `singleFile` to import all the data from a single file.
## Automatic Deployment via GitLab (CI/CD)
The steps provided in [.gitlab-ci.yml](.gitlab-ci.yml) are executed on a configured GitLab runner.
The basic workflow is contained in a separate script [deploy.sh](.gitlab-ci/deploy.sh) and looks like the following:
*`-Dkeycloak.migration.strategy`
Specifies how to proceed when a realm with the same name already exists in the database. We use `IGNORE_EXISTING` to avoid overwriting a realm if it already exists.
*Dump the relevant environment variables (i.e. GitLab variables) to a .env file.
We use a prefix to group the variables so that the resulting .env contains only the ones that are relevant for the deployment. The prefixes used and dumped for the deployment are: `POSTGRES_` for variables relevant to postgres, `KC_` for keycloak, `BACKUP_` for the postgres backups. See the [dump-vars.sh](./scripts/dump-vars.sh) script.
*`-Dkeycloak.profile.feature.upload_scripts`
The ability to enable custom scripts at startup. We use `enabled` since we have a logging script.
**Note**: This feature is deprecated and has been removed from version 18.0 and later on.
* SSH to the configured host and create the provided deployment path if it doesn't exist. Then check if a git repository exists there: clone if not, fetch & checkout if yes.
*`-Dkeycloak.migration.file`
Defines the file which we want to import the data from. Remember to prepend to the filename the exact same value that is used for the volume mapping in the `docker-compose.yml`.
* Secure copy the required files to the configured host (.env and ssl certificates). SSH again to tear down the old deployment and spin up the updated docker containers.
