Cloud Readiness
The goal of this epic, Cloud Readiness, is to enhance the operational experience of running the Axon Ivy Engine in cloud environments—particularly within containerized setups. While the Axon Ivy Engine already performs well in the cloud, certain challenges remain when operating in clustered environments, which this initiative aims to address.
We have introduced a new health check endpoint, which can be used to detect if the Axon Ivy Engine is available. The Axon Ivy Engine is returning HTTP Status Code 200 if everything is fine (http://localhost/system/health). This endpoint is working even if there are licence problems according to public urls, this was the tricky part for our customers, because they often need to call the Axon Ivy Engine under addresses which are not licensed and do dynamically change.
One key improvement targets configuration management. When configurations are changed directly on the file system, the Engine is expected to automatically reload them. However, this behavior relies on file systems that support inotify notifications—a feature not commonly available on network file systems such as AWS EFS. To mitigate this limitation, we’ve added new controls in the Cockpit UI that allow users to manually trigger the reloading of both system and application configurations as a fallback.
Additionally, a new REST endpoint has been introduced, enabling automated reloading of system and application configurations. This is especially useful for deployments on file systems that do not support automatic change detection. The new REST Endpoint is available under http://localhost/system/api/config/reload.
Lastly, we resolved a bug that affected the detection of configuration changes (e.g., updates to app.yaml) for newly created applications. Previously, a full restart of the Axon Ivy Engine was required for the changes to take effect. This is no longer necessary.
When it comes to logging, it's recommended to use a centralized logging service such as AWS CloudWatch. To make logs easier to parse and analyze, it's best to format them as structured JSON. You can achieve this by updating your logging configuration to output logs in JSON format.
Audience
Value
- Smoother operating the Axon Ivy Engine in the Cloud
Version
Discussion
- Any questions or feedback?
Next steps
- Proper handling of configuration changes across all cluster nodes
- Proper handling of cms cache across all cluster nodes
- Identity Provider for Engine Cockpit
- Improve automatically node discovery for container based cluster environments
- Revise completely Deployment
Screenshots / Code
<?xml version="1.0" encoding="UTF-8"?>
<Configuration>
<!--
Add here your custom configuration which will be merged with the default configuration of ivy
See http://logging.apache.org/log4j/2.x/manual/configuration.html#CompositeConfiguration
For more information see: @engine.guide.url@/monitoring/logging.html
And the default logging file: @engine.guide.url@/configuration/files/log4j2-xml.html
-->
<!-- Example: Change the log level of a specific Logger to debug -->
<!--
<Loggers>
<Logger name="ch.ivyteam.ivy.security.internal.session.SessionEventLogger" level="debug" />
</Loggers>
-->
<!-- Example: Change the output format of the ConsoleLog and IvyLog Appender to JSON -->
<!-- see https://logging.apache.org/log4j/2.x/manual/json-template-layout.html -->
<Appenders>
<Console name="ConsoleLog" target="SYSTEM_OUT">
<JsonTemplateLayout eventTemplateUri="classpath:EcsLayout.json" />
<ThresholdFilter level="debug" />
</Console>
<RollingRandomAccessFile name="IvyLog" fileName="logs/ivy.json" filePattern="logs/ivy-%d{yyyy-MM-dd}.json.gz" ignoreExceptions="false">
<JsonTemplateLayout eventTemplateUri="classpath:EcsLayout.json" />
<TimeBasedTriggeringPolicy />
</RollingRandomAccessFile>
</Appenders>
</Configuration>
