<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>2.3 Additional Labs on Application Migration and Modernization Techlab</title><link>/docs/02.0/additional/</link><description>Recent content in 2.3 Additional Labs on Application Migration and Modernization Techlab</description><generator>Hugo</generator><language>en-us</language><atom:link href="/docs/02.0/additional/index.xml" rel="self" type="application/rss+xml"/><item><title>2.3.1 OpenShift image requirements</title><link>/docs/02.0/additional/ocp-image-requirements/openshift-images/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/docs/02.0/additional/ocp-image-requirements/openshift-images/</guid><description>&lt;h2 id="task-2311-additional-requirements"&gt;Task 2.3.1.1: Additional requirements&lt;/h2&gt;
&lt;p&gt;OpenShift has additional security features enabled in comparison to Docker or a vanilla Kubernetes plattform.
The most relevant mechanism are prevention of root user, &lt;a href="https://de.wikipedia.org/wiki/SELinux" target="_blank" rel="noopener"&gt;SELinux&lt;/a&gt;
 enabled and arbitrary user ids.&lt;/p&gt;
&lt;p&gt;This adds additional requirements to the container images that will be deployed to OpenShift. This lab shows how to deal with them.&lt;/p&gt;
&lt;h2 id="task-2312-demo-application"&gt;Task 2.3.1.2: Demo application&lt;/h2&gt;
&lt;p&gt;We use a Go application running a HTTP server listening on port 8080. Every request is logged with the actual time and the client IP address. The log file is placed under &lt;code&gt;/home/golang/hello-go.log&lt;/code&gt;.&lt;/p&gt;</description></item><item><title>2.3.2 Best practices</title><link>/docs/02.0/additional/container-best-practices/bestpractice/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/docs/02.0/additional/container-best-practices/bestpractice/</guid><description>&lt;div class="alert alert-primary" role="alert"&gt;


Here you find best practices. It is not a lab to play through.

&lt;/div&gt;

&lt;h2 id="best-practices-for-container-in-general"&gt;Best practices for container in general&lt;/h2&gt;
&lt;p&gt;&lt;a href="https://docs.docker.com/develop/develop-images/dockerfile_best-practices/" target="_blank" rel="noopener"&gt;Best practices for writing Dockerfiles&lt;/a&gt;
&lt;/p&gt;
&lt;h3 id="one-process-per-container"&gt;One process per container&lt;/h3&gt;
&lt;p&gt;It is recommended to start only one process per container. This simplifies the following things.&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Docker can recognize if your container failed and restart it if needed&lt;/li&gt;
&lt;li&gt;Reduce Image size and startup time&lt;/li&gt;
&lt;li&gt;Signal handling flows are clearer&lt;/li&gt;
&lt;li&gt;Reusable Images and looser coupling&lt;/li&gt;
&lt;/ul&gt;
&lt;h3 id="instructions-order"&gt;Instructions order&lt;/h3&gt;
&lt;p&gt;The order of the Docker instruction matters. When a single Layer becomes invalid, because of changing files or modifying lines in the Dockerfile, the subsequent layers become invalid too. As a rule of thumb: Order your steps from least to most frequently changing steps to optimize caching.&lt;/p&gt;</description></item></channel></rss>