Impact of Runtime Image Upgrades
In this microlearning, we'll explore the concept of runtime images and their crucial role in deploying and maintaining eMagiz containers. A runtime image serves as the blueprint for creating container images, encompassing everything from the operating system to necessary libraries and configurations. We'll discuss how updates to these images impact your deployments, strategies for managing these updates, and steps for disaster recovery in case issues arise. Understanding this will help ensure your eMagiz environment remains stable and up-to-date.
If you have any questions, please contact academy@emagiz.com.
1. Prerequisites
- Advanced knowledge of the eMagiz platform
2. Key concepts
With runtime image, we mean the template used to create runtime-specific (docker) images. That image is used to deploy an eMagiz container and contains all required software components to let the eMagiz container function properly. One of the critical requirements is to load the necessary libraries used by runtime flows. A library in this context is a software component that performs a specific, often technical function in the eMagiz runtime. These libraries are based on Java and many open-source frameworks, such as Spring and Artemis. Given that these frameworks also continuously develop, it means that from time to time, we need to upgrade the versions of these underlying frameworks.
3. Assessing the impact of runtime images
As mentioned, the runtime image is a template (i.e., blueprint), meaning all specific eMagiz container images are created from this template. The template holds all the latest software updates and libraries that the integration flows require. eMagiz follows the strategy of updating these required libraries frequently to ensure vulnerabilities can be fixed quickly and new functionality is available on a needed basis. Furthermore, having a single template available allows all eMagiz containers to operate on the same software base across all eMagiz clients. This way, a single mix of libraries can be made available to the community and tested correctly and coherently. There can be no other mix of software components that behave differently (as we had in our legacy runtime architecture).
In essence, any container image consists of multiple layers. The first (foundational) layer comprises the operating system information (i.e., Linux configuration or Windows configuration) and a Java installation (correct JRE). Building on this in the second layer, we see a wide array of open-source code heavenly rooted in the Spring and Java frameworks combined with our proprietary monitoring stack, allowing us to gather information on your model upon which you can monitor. The third layer consists of your collection of flows that should run on a container (i.e., runtime). This layer is built up by the various flow designer components used in your release's flow versions. The fourth layer is the configuration layer in the form of (application) properties, memory configuration, and other configuration elements (i.e., route, deployment location, volumes, runtime settings). Below, you see a picture that illustrates this concept in an abstract form. In eMagiz, as well as in the image, you see that the layers form one construct that facilitates the purpose of the object. For eMagiz, this purpose is handling data via integrations.
This approach allows us to easily provide updates of not only dedicated eMagiz functionality but also of the OS, Java, and open-source frameworks used through a unified approach regardless of whether you deploy in our cloud or on-premises.
3.1 Overal deployment strategy
When the prepare release step is triggered, the runtime image will create specific runtime images to deploy eMagiz containers. When we release a new runtime (base) image, eMagiz will trigger the generation of a new container image for each runtime (i.e., container) captured within the first release created after we release our new runtime image. For more information on when eMagiz creates a new container image, please check out this microlearning.
3.2 Release notes & impact assessment
Release notes for runtime images can be found here. Please consult these regularly or at the moment when unexpected behavior is observed. In the strategy of eMagiz, very frequent updates are made to the Runtime Image so that the delta in the software components is incremental. In this way, the risk of unwanted side effects is minimalized. The risk is also mitigated by all flows inside the runtime adhering to the same version of libraries inside the docker image. All this means that the release notes are relevant to understand an issue better.
3.3 Approach
We strongly advise updating your Test and Acceptance environment before moving to Production. This will avoid potential problems appearing in a Production environment before any other environment. We will inform our customer base along the following timelines to better anticipate when a new runtime image will be released.
- High impact
- As part of the release notes of three releases ahead of us releasing the new runtime image.
- This information is shared with the whole community upfront through this release notes.
- Medium impact
- As part of the release notes of one release ahead of us releasing the new runtime image.
- This information is shared with the whole community upfront through this release notes.
- Low impact
- As part of the release notes for the current release,
- This information is shared upfront with key users.
3.3 Disaster recovery runtimes
In particular cases, a runtime may not function properly after a specific release is done. That means the flows in that runtime are not 100% compatible with the runtime image used to create the container images. As a result, action is needed at eMagiz to update the runtime image or assist you as a client in resolving the issue within the constraints of the new runtime image. This situation is expected to be very exceptional. We at eMagiz need to be informed if you encounter such a situation. As part of our regular process and agreements with our partners and clients, we need a registered ticket from our Support department to act upon this.
4. Key takeaways
- A runtime image is the foundational layer of a container image.
- Based on the assessed impact, we communicate sooner or later.
- Read the release notes for runtime images carefully to assess the impact.