As you may know, the Axon Ivy Engine is available as a Windows installation, Linux installation and for Linux also as a Debian package. Since Axon Ivy 8.0, the Axon Ivy Engine is also available as a Docker container via the official Docker Hub.
https://hub.docker.com/r/axonivy/axonivy-engine
Already 1M+ pulls 🙂
In Axon Ivy 8.0, we have moved the Axon Ivy Engine configurations from the system database to ivy.yaml
. This enables the automated setup of the Axon Ivy Engine specifically in a container environment. At runtime, application-specific configurations (such as variables or rest clients) could be overwritten in app.yaml
. With Axon Ivy 10.0, however, we have also completely removed these configurations from the system database and now only use the configurations directly from the project and the app.yaml
at runtime.
Why should you favor containers instead of the traditional installers?
Reason 1: Provisioning
The provisioning of containers is God-given. You don't have to worry about how the Docker image gets to the host. A single command is enough for the Docker image to be fetched from a Docker registry, unpacked on the system and an executable container created for it. In any other case, you have to go to a download page, decide on a distribution, download, unpack and install. You also have to set up an operating system-specific service and much more.
Reason 2: Documentation
If you run the Axon Ivy Engine as a container, the installation and its configuration are directly documented. For example, with Docker and Docker Compose, this is available in compose.yaml
. All configurations and changes compared to the official Axon Ivy Engine container are specified there. For example, you can see directly which version you are using and which ports the Axon Ivy Engine is available via. You can also see that you have made configurations in ivy.yaml
, installed a license, received patches from our 3rd level support and other extensions that are installed. Say goodbye to the hundred-page manual installation instructions. Your new installation guide is complete and always up-to-date.
Reason 3: Fast and reliable updates
Fast and secure updates are easy in the container world. All you have to do is shut down the container, increase the version number and start it up again. If this fails, for example because there is a new error in the platform, you can stop the container again, reset the version number and start it up again. This is also done very quickly and reproducibly on different staging environments and is less prone to errors.
P.S. Minor or Major Updates needs additional migration tasks.
Reason 4: Security
Sometimes updates have to be installed very quickly. Perhaps because there is a critical security gap in the platform or because a supplied library has a security leak. We remember the Log4j1 vulnerability. It is therefore important to install updates continuously. This ensures that you are able to update quickly and securely by gaining experience. In addition, new errors can be reported back to the platform at an early stage and a quick update to a security-critical version is possible.
Reason 5: Portability
Containers work the same on all platforms. I can define a setup on Windows, hand it over to my friend on MAC and run it in production with Linux. A target system can often simply be booted on a developer computer. Changing the host operating system from Windows to Linux, for example, is quick and easy.
Conclusion
Start using containers over traditional installations today. The added value is clear for all the reasons mentioned above. If you find an environment that already has a mature container orchestration platform like Kubernetes, deploy the Axon Ivy Engine into it. If you only get a Linux or Windows server, still use docker with docker-compose. Microsoft has now eliminated the last concerns about performance on Windows itself with the Windows Subsystem for Linux (WSL).
Containerize now!