<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>9.2 OpenShift build types on Application Migration and Modernization Techlab</title><link>/docs/additional/build-types/</link><description>Recent content in 9.2 OpenShift build types on Application Migration and Modernization Techlab</description><generator>Hugo</generator><language>en-us</language><atom:link href="/docs/additional/build-types/index.xml" rel="self" type="application/rss+xml"/><item><title>9.2.1 Source to Image</title><link>/docs/additional/build-types/s2i/s2i/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/docs/additional/build-types/s2i/s2i/</guid><description>&lt;h2 id="9211-lab"&gt;9.2.1.1 Lab&lt;/h2&gt;
&lt;!--
## TODO Lab

* [ ] Proxy Setzen beschreiben

--&gt;
&lt;p&gt;Source-to-Image (S2I) builds are a special way to inject application source code into a builder image and assembling a new runnable image. There are several builder image available, each for its own framework or language.&lt;/p&gt;
&lt;p&gt;The main reasons to use this build strategy are.&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;Speed&lt;/strong&gt; - The assemble process where the source code is injected into the image is a single Docker layer. This reduce the build time and resources. Furthermore S2I allows incremental builds.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Security&lt;/strong&gt; - Dockerfiles are usually running as root and having access to the container network. This is a possible security risk. S2I Images allow more control what permissions and privileges are available to the builder image since the build launches only a single container. OpenShift allows cluster administrator tightly control what privileges developers have at build time.&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id="setup"&gt;Setup&lt;/h2&gt;
&lt;p&gt;First we define the username and project name as environment variables. We&amp;rsquo;re going to use them later for the Template parameters.&lt;/p&gt;</description></item><item><title>9.2.2 Binary Deployment</title><link>/docs/additional/build-types/binary/binary-deployment/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/docs/additional/build-types/binary/binary-deployment/</guid><description>&lt;h2 id="9221-lab"&gt;9.2.2.1 Lab&lt;/h2&gt;
&lt;!-- ## TODO Lab
* [x] DeploymentConfig, Service, Route auch noch via oc apply erstellen und dann entsprechend die App aufrufen
* [ ] Hinweis eigenes Build Image verwenden, falls in ext. privater Registry -&gt; Proxy Einstellungen
 --&gt;


&lt;div class="alert alert-primary" role="alert"&gt;


Binary builds require content from the local file system. Therefore automatic triggering a build is not possible.

&lt;/div&gt;

&lt;h3 id="uses-cases-of-binary-builds"&gt;Uses cases of binary builds&lt;/h3&gt;
&lt;ul&gt;
&lt;li&gt;Build and test code local&lt;/li&gt;
&lt;li&gt;Bypass the SCM&lt;/li&gt;
&lt;li&gt;Build images with artifacts from different sources&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;We first check that the project is ready for the lab.&lt;/p&gt;</description></item><item><title>9.2.3 Docker Build</title><link>/docs/additional/build-types/docker/docker-build/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/docs/additional/build-types/docker/docker-build/</guid><description>&lt;h2 id="9231-lab"&gt;9.2.3.1 Lab&lt;/h2&gt;
&lt;p&gt;The Docker build strategy was already used in &lt;a href="http://localhost:8081/docs/02.0/2.1/containerize/" target="_blank" rel="noopener"&gt;Lab 2&lt;/a&gt;
. We don&amp;rsquo;t repeat it here. The Docker Strategy expects a &lt;code&gt;Dockerfile&lt;/code&gt; at the root of the Project. For every Build it invokes the Docker build command and produces a runnable Image.&lt;/p&gt;</description></item><item><title>9.2.4 Image Deployment</title><link>/docs/additional/build-types/image/image-deployment/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>/docs/additional/build-types/image/image-deployment/</guid><description>&lt;h2 id="9241-lab"&gt;9.2.4.1 Lab&lt;/h2&gt;
&lt;!--
## TODO Lab

* [X] keine Buildconfig sondern direkt DeploymentConfig und ImageStream
* [ ] Beschreiben: Imagestream und polling / scheduling von neuen Images, damit image stream trigger funktioniert.
* [ ] Hinweis: per Default polling nur für latest Tag
* [ ] Beschreiben: Private Registry wie und wo muss man das pull secret angeben.
--&gt;
&lt;p&gt;In this section we cover how to deploy an existing Docker Image from an private image registry. Besides we show how to create a ImageStream to track changes on the deployed image and trigger an update on the deployment.&lt;/p&gt;</description></item></channel></rss>