<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>4.3 Additional Labs on Application Migration and Modernization Techlab</title><link>/docs/04.0/additional/</link><description>Recent content in 4.3 Additional Labs on Application Migration and Modernization Techlab</description><generator>Hugo</generator><language>en-us</language><atom:link href="/docs/04.0/additional/index.xml" rel="self" type="application/rss+xml"/><item><title>4.3.1 Operators</title><link>/docs/04.0/additional/operators/operators/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/docs/04.0/additional/operators/operators/</guid><description>&lt;p&gt;Operators are a way to package, deploy and manage Kubernetes-native applications. Kubernetes-native applications are applications that are deployed in Kubernetes/OpenShift and managed via the Kubernetes/OpenShift API (kubectl/oc). Since the introduction of OpenShift 4, OpenShift itself uses several operators to manage the OpenShift cluster.&lt;/p&gt;


&lt;div class="alert alert-primary" role="alert"&gt;
&lt;h4 class="alert-heading"&gt;Note&lt;/h4&gt;

Use the existing Namespace &lt;code&gt;&amp;lt;username&amp;gt;-operator&lt;/code&gt; for this lab.

&lt;/div&gt;

&lt;h2 id="introduction--terms"&gt;Introduction / Terms&lt;/h2&gt;
&lt;p&gt;To understand, what an operator is and how it works, we first look at the so-called controller, because operators are based on its concept.&lt;/p&gt;</description></item><item><title>4.3.2 Requests and Limits</title><link>/docs/04.0/additional/resources-management/requests-limits/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/docs/04.0/additional/resources-management/requests-limits/</guid><description>&lt;p&gt;In this lab, we are going to look at ResourceQuotas and LimitRanges. As OpenShift users, we are most certainly going to encounter the limiting effects that ResourceQuotas and LimitRanges impose.&lt;/p&gt;


&lt;div class="alert alert-primary" role="alert"&gt;
&lt;h4 class="alert-heading"&gt;Note&lt;/h4&gt;

Use the existing Namespace &lt;code&gt;&amp;lt;username&amp;gt;-resources&lt;/code&gt; for this lab.

&lt;/div&gt;

&lt;h2 id="task-4321-check-project-setup"&gt;Task 4.3.2.1: Check project setup&lt;/h2&gt;
&lt;p&gt;We first check that the project is ready for the lab.&lt;/p&gt;
&lt;p&gt;Ensure that the &lt;code&gt;LAB_USER&lt;/code&gt; environment variable is set.&lt;/p&gt;
&lt;div class="highlight"&gt;&lt;pre tabindex="0" style="background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;"&gt;&lt;code class="language-bash" data-lang="bash"&gt;&lt;span style="display:flex;"&gt;&lt;span&gt;&lt;span style="color:#204a87"&gt;echo&lt;/span&gt; &lt;span style="color:#000"&gt;$LAB_USER&lt;/span&gt;
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;If the result is empty, set the &lt;code&gt;LAB_USER&lt;/code&gt; environment variable.&lt;/p&gt;</description></item><item><title>4.3.3 Jobs and Cronjobs</title><link>/docs/04.0/additional/jobs/jobs-and-cronjobs/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/docs/04.0/additional/jobs/jobs-and-cronjobs/</guid><description>&lt;!--

## TODO

* [ ] Testen und durchspielen, allenfalls auf maria
* [ ] eigenes Projekt nehme
* [ ] Lab / Project Setup analog anderer Labs
* [ ] Ressourcen Files nicht in WS Folder ablegen!

--&gt;
&lt;p&gt;Jobs are different from normal Deployments: Jobs execute a time-constrained operation and report the result as soon as they are finished; think of a batch job. To achieve this, a Job creates a Pod and runs a defined command. A Job isn&amp;rsquo;t limited to create a single Pod, it can also create multiple Pods. When a Job is deleted, the Pods started (and stopped) by the Job are also deleted.&lt;/p&gt;</description></item></channel></rss>