CaaS Platform

As of MongoDB version 4.4.4 all members of a Replica Set must authenticate themselves internally. This also affects Replica Sets with only one member and thus the Docker stack. The Docker stack configuration has now been modified to ensure this. All changes must be transferred manually to your configuration, otherwise the stack will not start.

Fixed the values for the _JAVA_OPTIONS variable in docker-compose.yml. To use this improvement in existing installations, the modifications must be transferred manually to the configuration.

There have been changes to the Rest-API configuration for the Docker stack. To use this improvement in existing installations, the modifications must be transferred manually to the configuration.

The credentials.caasSecureTokenEncryptionKey parameter has been added to the default configuration of the Helm chart. The value of this parameter must be overwritten in a custom-values.yaml in the same way as all other credentials.

For all newly set up Docker stacks from version 2.17 on, the JSON schema is automatically imported and activated for the apikeys collection. For existing installations, this has to be done manually. Please refer to the current version of bootstrap.sh for this. Alternatively replace the existing installation with a new installation.

After updating MongoDB to version 4.4, the parameter featureCompatibilityVersion is now also set to 4.4. In the Kubernetes stack the configuration is fully automated, but in the Docker stack this must be done manually.

Once the CaaS is running in version 2.16, please execute the following command:

Of course, please replace the placeholders with the credentials you have configured.

For more information, see the MongoDB documentation.

In general, you should check that all applications accessing the CaaS can handle the MongoDB compatibility changes in version 4.4. For a detailed listing of these changes, see the MongoDB documentation.

After updating the CaaS to 2.15, the MongoDB will run in version 4.4 and with the parameter featureCompatibilityVersion set to the value 4.2. The update to the new MongoDB version and updating the featureCompatibilityVersion are kept separate on purpose. This value will be set to 4.4 in a subsequent release in order to be able to perform the update properly without downtime in the Kubernetes stack. More information can be found here:

Authentication and Authorization in Rest-API are no longer located in a separate component (security proxy). It is no longer possible to disable the security proxy.

After updating MongoDB to version 4.2, the parameter featureCompatibilityVersion is now also set to 4.2. In the Kubernetes stack the configuration is fully automated, but in the Docker stack this must be done manually.

Once the CaaS is running in version 2.13, please execute the following command:

Of course, please replace the placeholders with the credentials you have configured.

For more information, see the MongoDB documentation.

In general, you should check that all applications accessing the CaaS can handle the MongoDB compatibility changes in version 4.2. For a detailed listing of these changes, see the MongoDB documentation.

After updating the CaaS to 2.12, the MongoDB will run in version 4.2 and with the parameter featureCompatibilityVersion set to the value 4.0. The update to the new MongoDB version and updating the featureCompatibilityVersion are kept separate on purpose. This value will be set to 4.2 in a subsequent release in order to be able to perform the update properly without downtime in the Kubernetes stack. More information can be found here:

It is no longer possible to configure the MongoDB metrics endpoint via the Helm Chart. Specifically, the configuration items 'mongo.metrics.port', 'mongo.metrics.path' and 'mongo.metrics.socketTimeout' have been removed. The metrics are now permanently accessible under /metrics on port 9216.

Starting with this version, it is necessary that MongoDB is run as replica set and no longer in standalone mode. To achieve this, the Docker Compose stack must be rebuilt. Kubernetes installations are not affected.

You can do so by removing the stack and simply running the setup steps again for the stack. Please keep in mind that the Docker Compose stack is no longer supported for any other situation than development work. New setups using the Docker Compose stack will already be set up correctly.

The Healthcheck endpoint URL has changed from /_logic/metrics/healthcheck to /_logic/healthcheck.

It is no longer possible to use a custom logback.xml for log configuration. The components use INFO log level by default.

Authentication and Authorization have been extracted from the Rest-API and are now located in a separate component. While this should not have any impact on users of CaaS, it is important to be aware of this for failure analysis and operations. URLs do not change.

This version of the CaaS-Platform eliminates the deployments of kube-state-metrics, Prometheus, Alertmanager and Grafana. Therefore, the example monitoring stack previously included is no longer available. Instead, CaaS expects a monitoring environment set up with Prometheus operator into which it integrates automatically. For more information please consult the CaaS documentation.

By default, CaaS-Platform is configured to automatically integrate into a monitoring stack installed by using Prometheus operator. CaaS-Platform achieves this by including labels for ServiceMonitors and Alerts that match the labels used by Prometheus in its default configuration. If you use a custom Prometheus configuration, please adapt the CaaS-Platform configuration accordingly to be picked up by Prometheus. Likewise for Grafana dashboards: the CaaS-Platform labels match the default labels used by the Grafana Sidecar container. The adaption of the CaaS-Platform labels is required if you used custom labels values.

The integration of additional dashboards using the helm chart is no longer supported. Please use the default Grafana Sidecar container to integrate custom dashboards.

After updating MongoDB to version 4.0, the parameter featureCompatibilityVersion is now also set to 4.0. In the Kubernetes stack the configuration is fully automated, but in the Docker stack this must be done manually.

Once the CaaS is running in version 2.9, please execute the following command:

Of course, please replace the placeholders with the credentials you have configured.

For more information, see the MongoDB documentation.

In general, you should check that all applications accessing the CaaS can handle the MongoDB compatibility changes in version 4.0. For a detailed listing of these changes, see the MongoDB documentation.

After updating the CaaS to 2.8, the MongoDB will run in version 4.0 and with the parameter featureCompatibilityVersion set to the value 3.6. The update to the new MongoDB version and updating the featureCompatibilityVersion are kept separate on purpose. This value will be set to 4.0 in a subsequent release in order to be able to perform the update properly without downtime in the Kubernetes stack. More information can be found here:

Please check before the update that the parameter featureCompatibilityVersion is set to 3.6. For more information about this requirement, see the official MongoDB documentation.

After updating MongoDB to version 3.6, the parameter featureCompatibilityVersion is now also set to 3.6. In the Kubernetes stack the configuration is fully automated, but in the Docker stack this must be done manually.

Once the CaaS is running in version 2.7, please execute the following command:

Of course, please replace the placeholders with the credentials you have configured.

For more information, see the MongoDB documentation.

If you use this endpoint, you can switch to using the metrics endpoint /_metrics instead.

In general, you should check that all applications accessing the CaaS can handle the MongoDB compatibility changes in version 3.6. For a detailed listing of these changes, see the MongoDB documentation.

After updating the CaaS to 2.6, the MongoDB will run in version 3.6 and with the parameter featureCompatibilityVersion set to the value 3.4. The update to the new MongoDB version and updating the featureCompatibilityVersion are kept separate on purpose. This value will be set to 3.6 in a subsequent release in order to be able to perform the update properly without downtime in the Kubernetes stack. More information can be found here:

Please check before the update that the parameter featureCompatibilityVersion is set to 3.4. For more information about this requirement, see the official MongoDB documentation.

The use of remote projects makes it possible to reference elements in a project without having to generate them. For example, mainly static media can be maintained in a separate project and generated using a separate job.

Referencing projects can use the static content and generate it much more often because their jobs are now more resource-efficient.

In the past, resource-conserving setup with CaaS generation was not possible and, e.g. media deployment into a CDN was not feasible because remote content was always generated as well.

Choosing between classic FirstSpirit deployment and CaaS media deployment now enables the implementation of the scenarios listed above and meets the flexibility and efficiency requirements of a modern FirstSpirit project.

The use of remote projects in a CaaS generation is now also identical to common FirstSpirit projects.

If you use media in the project that is referenced from a remote project, these must now be made available in a place by the remote project, which can be reached by the application using the CaaS. In the remote project configuration the same URL Creator must be used that is also used in the remote project. The "paths prefix" must be set so that the application using the CaaS can resolve the media.