Skip to Content
Last modified by Erik Bakker on 2024/09/03 08:14
From version 8.1
edited by Erik Bakker
on 2023/04/17 14:44
Change comment: There is no comment for this version
To version 15.1
edited by Erik Bakker
on 2024/06/24 14:16
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -1,7 +1,7 @@
1 1  {{container}}{{container layoutStyle="columns"}}(((
2 -In this microlearning, we will focus on the helping you to assess the impact of upgrading to new buildnumbers.
2 +In this microlearning, we will focus on helping you to assess the impact of upgrading to a new image.
3 3  
4 -Should you have any questions, please get in touch with [[academy@emagiz.com>>mailto:academy@emagiz.com]].
4 +If you have any questions, please contact [[academy@emagiz.com>>mailto:academy@emagiz.com]].
5 5  
6 6  == 1. Prerequisites ==
7 7  
... ... @@ -9,48 +9,54 @@
9 9  
10 10  == 2. Key concepts ==
11 11  
12 -With runtime image we mean the template that is used to create runtime specific docker images. That image is used to spin up docker containers and contains all required software components to let the docker container function properly. One of the key requirements is to load the required libraries that are used by flows of a runtime. A library in this context is a software component that performs a specific, often technical function in the eMagiz runtime. These libraries are Java based and different versions exist of these libraries.
12 +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.
13 13  
14 14  == 3. Assessing the impact of runtime images ==
15 15  
16 -As mentioned the runtime image is a template which effectively means that all specific docker images that are created from this template. The template holds all latest software updates and libraries that the integration flows require. eMagiz follows the strategy to update these required libraries on a frequent basis to ensure vulnerabilities can be fixed quickly and new functionality is available on a needed basis. Furthermore, by having a single template available all runtime are operating on exactly the same software base across all eMagiz clients. This way, a single mix of libraries can be made available to the community that is tested properly and coherent. There can be no other mix of software components that behave each differently.
16 +As mentioned, the runtime image is a template (i.e., blueprint), which effectively means that 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).
17 17  
18 +In essence, any container image consists of three layers. The first (foundational) layer comprises a wide array of open-source code heavenly rooted in the Spring and Java frameworks. The secondary 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 third 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.
19 +
20 +[[image:Main.Images.Microlearning.WebHome@advanced-lifecycle-management-impact-of-runtime-image-upgrades--runtime-layers.png]]
21 +
18 18  === 3.1 Overal deployment strategy ===
19 19  
20 -At the moment when the prepare release step is triggered, the runtime image will be used to create specific runtime images that are used to deploy Docker containers. Effectively that means that for every release, a specific docker image is created and that docker image will be used at the moment when the deployment plan is run. That also means that at each and every deployment, all docker containers will be replaced with a new docker container based on that docker image created of the release.
24 +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>>doc:Main.eMagiz Academy.Microlearnings.Crash Course.Crash Course Platform.crashcourse-platform-deploy-execute-deployment-plan-gen3.WebHome||target="blank"]].
21 21  
22 22  === 3.2 Release notes & impact assessment ===
23 23  
24 -Release notes for runtime images can be found [[here>>doc:Main.Release Information.Runtime Images.WebHome||target="blank"]]. Please consult these at a regular basis 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 are incremental. In this way, risk of unwanted side effects is minimalized. The risk is also mitigated by the fact that all flows inside the runtime will adhere to the same version of libraries inside the docker image. All and all this means that the release notes are relevant to better understand an issue. At that moment, the option below is available to deal with this specific scenario.
25 -
26 -=== 3.2 Disaster recovery runtimes ===
28 +Release notes for runtime images can be found [[here>>doc:Main.Release Information.Runtime Images.WebHome||target="blank"]]. 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.
27 27  
28 -In very specific cases, a runtime may not function properly after a specific release is done. That means that the flows in that runtime are not 100% compatible with the runtime image used to create the docker images from. This may happen in cases when there hasn't been a deployment for many months, and the new runtime images will contain large changes. Effectively that means that the Runtime Image as delivered by eMagiz is incompatible with the flows in that runtime. And action is needed on eMagiz side to update the runtime image. This situation is expected to be very expectional. It requires that a ticket is to be opened with the Support department of eMagiz or Partner Support team.
29 -
30 -Whenever this situation occurs, a user can navigate to the Deploy architecture of the model. The details of the specific runtime (right-click option) can be opened and a release can be selected. That release should be the previous release where the runtime was operating normally. Once selected, press Save and choose the Deploy Runtime option (right-click option) on machine level. This will force that specific runtime to load the previous docker image.
31 -
32 -[[image:Main.Images.Microlearning.WebHome@assessing_impact_runtime_images_disaster_recovery.png]]
33 -
34 -=== 3.4 Approach ===
30 +{{info}}Should an issue occur, we want to be informed of this to take action. If it turns out that a rollback is needed to an earlier image, you can facilitate this via our "disaster recovery" mechanism described below.{{/info}}
35 35  
36 -It is usually best to update the test and acceptance environment first and leave that running for a certain grace period. So that in case potential issues can be fixed still.
32 +=== 3.3 Approach ===
37 37  
38 -== 4. Assignment ==
34 +We strongly advise updating your Test and Acceptance environment first before moving to Production. This will avoid potential problems appearing in a Production environment before any other environment. To better anticipate when a new runtime image will be released, we will inform our customer base along the following timelines.
39 39  
40 -Take a look at the release notes in the eMagiz Portal to ensure you know where to look.
36 +* High impact
37 +** As part of the release notes of **three** releases ahead of us releasing the new runtime image.
38 +** This information is shared with the whole community upfront through this release notes.
39 +* Medium impact
40 +** As part of the release notes of **one** release ahead of us releasing the new runtime image.
41 +** This information is shared with the whole community upfront through this release notes.
42 +* Low impact
43 +** As part of the release notes for the current release,
44 +** This information is shared upfront with key users.
41 41  
42 -== 5. Key takeaways ==
46 +=== 3.3 Disaster recovery runtimes ===
43 43  
44 -* Keep as close to the latest buildnumber as possible for the entire environment
45 -* The best option is to have the entire environment run on the same buildnumber
46 -* A mix of buildnumbers in a runtime is not a good plan - conflicting behaviors may occur.
47 -* Read the release notes for builnumbers carefully to assess the impact - in case the impact is minimal proceed with the upgrade
48 -* Make the buildnumber upgrades planable so the release schedule takes these actions into account.
48 +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. One example of this can happen is when there hasn't been a deployment for many months, and the new runtime images will contain significant changes. Effectively, that means that the Runtime Image delivered by eMagiz is incompatible with the flows in that runtime. 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.
49 +
50 +Should this situation occur, you can navigate to your model's Deploy architecture. The details of the specific runtime (right-click option) can be opened, and on the "Basic" tab, you can select an older release. That release should be the previous release where the runtime was operating normally. Once selected, press Save and choose the Deploy Runtime option (right-click option) on the machine level. This will force that specific runtime to load the previous docker image.
51 +
52 +[[image:Main.Images.Microlearning.WebHome@assessing_impact_runtime_images_disaster_recovery.png]]
49 49  
50 -== 6. Suggested Additional Readings ==
54 +== 4. Key takeaways ==
51 51  
52 -If you are interested in this topic and want more information on it, please read the release notes provided by eMagiz
56 +* A runtime image is the foundational layer of a container image.
57 +* Based on the assessed impact, we communicate sooner or later.
58 +* Read the release notes for runtime images carefully to assess the impact.
53 53  
54 -== 7. Silent demonstration video ==
60 +== 5. Suggested Additional Readings ==
55 55  
56 -There is no video available as this is more a theoretical microlearning.)))((({{toc/}}))){{/container}}{{/container}}
62 +If you are interested in this topic and want more information on it, please read the [[release notes>>doc:Main.Release Information.Runtime Images.WebHome||target="blank"]] provided by eMagiz.)))((({{toc/}}))){{/container}}{{/container}}