Skip to Content
Last modified by Erik Bakker on 2024/09/03 08:14
From version 3.1
edited by eMagiz
on 2022/11/22 09:23
Change comment: There is no comment for this version
To version 4.1
edited by eMagiz
on 2022/11/22 12:42
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -9,37 +9,28 @@
9 9  
10 10  == 2. Key concepts ==
11 11  
12 -With runtime image we mean the template that is used to create 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 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 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.
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 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 mixes of
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.
17 17  
18 -
19 -
20 -
21 -=== 3.1 Release notes & impact assessment ===
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.
19 +=== 3.1 Overal deployment strategy ===
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.
21 +At the moment when a release is set as active, 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.
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:
23 +=== 3.2 Release notes & impact assessment ===
24 +
25 +Release notes for runtime images can be found [[here>>doc:Main.Release Information.Runtime Images.WebHome||target="blank"]]. Please consult these at regular basis or at the moment when unexpected behavior is observed.
26 +
27 +=== 3.2 Disaster recovery runtimes ===
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.
29 +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.
30 +
31 +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.
32 +
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.
34 -
35 -=== 3.2 Upgrade ===
36 -
37 -Use the designed options in eMagiz to upgrade the flows to the new buildnumber. See the relevant microlearnings for that.
38 -
39 -=== 3.3 Functional changes ===
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.
42 -
43 43  === 3.4 Approach ===
44 44  
45 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.