Changes for page Impact of Runtime Image Upgrades

Summary

• Page properties (2 modified, 0 added, 0 removed)

Details

Page properties

Author

...	...	@@ -1,1 +1,1 @@
1		-XWiki.eMagiz
	1	+XWiki.ebakker

Content

...	...	@@ -1,5 +1,5 @@
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 the helping you to assess the impact of upgrading to a new image.
3	3
4	4	Should you have any questions, please get in touch with [[academy@emagiz.com>>mailto:academy@emagiz.com]].
5	5
...	...	@@ -9,47 +9,50 @@
9	9
10	10	== 2. Key concepts ==
11	11
12		-With runtime image we mean the template that is used when creating runtime specific 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 that are part of that runtime.
	12	+With runtime image we mean the template that is 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 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 based on Java as well as a multitude of open-source frameworks such as Spring and Artemis. Given that these frameworks also continously 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 images that are created
17		-
18		-
19		-
20		-
21		-=== 3.1 Release notes & impact assessment ===
	16	+As mentioned the runtime image is a template (i.e. blueprint) which effectively means that all specific eMagiz container 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 eMagiz containers 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 (as we had in our legacy runtime architecture).
22	22
23		-These can be found [[here>>doc:Main.Release Information.Build numbers.WebHome||target="blank"]]. Once the release notes are properly read, assess the impact. This effectively means that the key notes around the model components can be used.
	18	+In essence any container image consists of three layers. The first (foundational) layer comprises of a wide array of open source code heavenly rooted in the Spring and Java frameworks. The secondary layer consist 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 that are used in the flow versions in your release. 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 three layers form one construct that facilitates the purpose of the object. For eMagiz is that the handling of data via integrations.
24	24
25		-You see often a list of libraries that are updated, and when these are the only notes that means that the impact is slim to none. Then make sure to read the notes above around the model components touched. These will help to asses the impact. Some model components have additional capability, and some have a limited capability or a fix.
	20	+[[image:Main.Images.Microlearning.WebHome@advanced-lifecycle-management-impact-of-runtime-image-upgrades--runtime-layers.png]]
26	26
27		-**Example**
28		-Flows containing a Jetty server (support object), primarily used to host REST and SOAP web services, require some special attention when deploying because not all combinations of build number 50 (and higher) and 48 (and lower) flows will work correctly:
	22	+=== 3.1 Overal deployment strategy ===
29	29
30		-* After installing any build 50 (or higher) flow, build 48 (or lower) flows containing a Jetty server on the same runtime cannot be started anymore. If it is really necessary to still install/start a build 48 (or lower) Jetty server flow: uninstall all build 50 (or higher) flows on that runtime first, then install/start the build 48 (or lower) Jetty server flow, and finally re-install the build 50 (or higher) flows.
31		-* When deploying a flow containing a Jetty server, the infra flow of that runtime must have a matching build number, that is: if the the Jetty server flow is build 48 (or lower) the infra needs to be build 48 (or lower) as well, if the Jetty server flow is build 50 (or higher) the infra needs to be 50 (or higher) as well.
	24	+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 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) that is captured within your first release you activate **after** we release the new runtime (base) 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"]].
32	32
33		-**Impact**: review the runtimes that have flows with a Jetty component and ensure that matching buildnumbers are inside these runtimes for all flows.
	26	+=== 3.2 Release notes & impact assessment ===
	27	+
	28	+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 this means that the release notes are relevant to better understand an issue.
34	34
35		-=== 3.2 Upgrade ===
	30	+{{info}}Should an issue occur we want to be informed of this so we can 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}}
36	36
37		-Use the designed options in eMagiz to upgrade the flows to the new buildnumber. See the relevant microlearnings for that.
	32	+=== 3.3 Approach ===
38	38
39		-=== 3.3 Functional changes ===
	34	+We strongly advice to update your Test and Acceptance environment first before moving to Production. This to 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.
40	40
41		-Before an environment is updates to the flows with the latest releases, it is adviced to first check which flows have functional changes. These flows need to be tested and put into production first so that you can isolate issues in case they occur. Once these flows are tested and live, only then move the flows with the new buildnumbers from test to production.
	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 through this release notes with the whole community upfront.
	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 through this release notes with the whole community upfront.
	42	+* Low impact
	43	+** As part of the release notes of the current release.
	44	+** This information is shared upfront with key users.
42	42
43		-=== 3.4 Approach ===
	46	+=== 3.3 Disaster recovery runtimes ===
44	44
45		-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.
	48	+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 container images. One example for which 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 as delivered by eMagiz is incompatible with the flows in that runtime. As a result an action is needed at eMagiz to update the runtime image or to assist you as a client in resolving the issue within the constraints of the new runtime image. This situation is expected to be very expectional. If you encounter such a situation we, as eMagiz, need to be informed. As part of our regular process and agreements with our partners and clients we need a registered ticket with our Support department to act upon this.
	49	+
	50	+Should this situation occur, you can navigate to the Deploy architecture of your model. 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 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]]
46	46
47		-== 4. Assignment ==
	54	+== 4. Key takeaways ==
48	48
49		-Take a look at the release notes in the eMagiz Portal to ensure you know where to look.
50		-
51		-== 5. Key takeaways ==
52		-
53	53	* Keep as close to the latest buildnumber as possible for the entire environment
54	54	* The best option is to have the entire environment run on the same buildnumber
55	55	* A mix of buildnumbers in a runtime is not a good plan - conflicting behaviors may occur.
...	...	@@ -56,10 +56,6 @@
56	56	* Read the release notes for builnumbers carefully to assess the impact - in case the impact is minimal proceed with the upgrade
57	57	* Make the buildnumber upgrades planable so the release schedule takes these actions into account.
58	58
59		-== 6. Suggested Additional Readings ==
	62	+== 5. Suggested Additional Readings ==
60	60
61		-If you are interested in this topic and want more information on it, please read the release notes provided by eMagiz
62		-
63		-== 7. Silent demonstration video ==
64		-
65		-There is no video available as this is more a theoretical microlearning.)))((({{toc/}}))){{/container}}{{/container}}
	64	+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}}