Skip to content

Commit 61b6e8b

Browse files
authored
Merge pull request #75415 from EricPonvelle/OSDOCS-8400_Migrate-OpenShift-Concepts
OSDOCS#8400: Migrated "OpenShift Concepts" tutorial
2 parents 3957a24 + 1bebede commit 61b6e8b

File tree

2 files changed

+168
-0
lines changed

2 files changed

+168
-0
lines changed

_topic_maps/_topic_map_rosa.yml

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -147,6 +147,8 @@ Topics:
147147
File: cloud-experts-getting-started-what-is-rosa
148148
- Name: ROSA with AWS STS explained
149149
File: cloud-experts-rosa-sts-explained
150+
- Name: OpenShift concepts
151+
File: cloud-experts-getting-started-openshift-concepts
150152
- Name: Deploying a cluster
151153
Dir: cloud-experts-getting-started-deploying
152154
Topics:
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,166 @@
1+
:_mod-docs-content-type: ASSEMBLY
2+
[id="cloud-experts-getting-started-openshift-concepts"]
3+
= Tutorial: OpenShift concepts
4+
include::_attributes/attributes-openshift-dedicated.adoc[]
5+
:context: cloud-experts-getting-started-openshift-concepts
6+
7+
toc::[]
8+
9+
//rosaworkshop.io content metadata
10+
//Brought into ROSA product docs 2024-01-19
11+
12+
[id="cloud-experts-getting-started-openshift-concepts-s2i"]
13+
== Source-to-Image (S2I)
14+
Source-to-Image (S2I) is a toolkit and workflow for building reproducible container images from source code. S2I produces ready-to-run images by inserting source code into a container image and letting the container prepare the source code. By creating self-assembling builder images, you can version and control your build environments exactly like you use container images to version your runtime environments.
15+
16+
[role="_additional-resources"]
17+
.Additional resources
18+
* link:https://github.com/openshift/source-to-image[Source-to-Image (S2I) upstream project]
19+
// This isn't in the ROSA Topic map
20+
//* xref:../../openshift_images/create-images-images-create-guidelines_create-images[Creating Images]
21+
22+
[id="cloud-experts-getting-started-openshift-concepts-s2i-how"]
23+
=== How it works
24+
25+
For a dynamic language such as Ruby, the build time and run time environments are typically the same. Assuming that Ruby, Bundler, Rake, Apache, GCC, and all other packages needed to set up and run a Ruby application are already installed, a builder image performs the following steps:
26+
27+
. The builder image starts a container with the application source injected into a known directory.
28+
29+
. The container process transforms that source code into the appropriate runnable setup. For example, it installs dependencies with Bundler and moves the source code into a directory where Apache has been preconfigured to look for the Ruby configuration file.
30+
31+
. It then commits the new container and sets the image entrypoint to be a script that will start Apache to host the Ruby application.
32+
33+
For compiled languages such as C, C++, Go, or Java, the necessary dependencies for compilation might outweigh the size of the runtime artifacts. To keep runtime images small, S2I enables a multiple-step build process, where a binary artifact such as an executable file is created in the first builder image, extracted, and injected into a second runtime image that simply places the executable program in the correct location.
34+
35+
For example, to create a reproducible build pipeline for Tomcat and Maven:
36+
37+
. Create a builder image containing OpenJDK and Tomcat that expects to have a WAR file injected.
38+
39+
. Create a second image that layers on top of the first image Maven and any other standard dependencies, and expects to have a Maven project injected.
40+
41+
. Start S2I using the Java application source and the Maven image to create the desired application WAR.
42+
43+
. Start S2I a second time using the WAR file from the earlier step and the initial Tomcat image to create the runtime image.
44+
45+
By placing build logic inside of images and combining the images into multiple steps, the runtime environment is close to the build environment without requiring the deployment of build tools to production.
46+
47+
[id="cloud-experts-getting-started-openshift-concepts-s2i-benefits"]
48+
=== S2I benefits
49+
50+
Reproducibility::
51+
Allow build environments to be tightly versioned by encapsulating them within a container image and defining a simple interface of injected source code for callers. Reproducible builds are a key requirement for enabling security updates and continuous integration in containerized infrastructure, and builder images help ensure repeatability and the ability to swap run times.
52+
53+
Flexibility::
54+
Any existing build system that can run on Linux can run inside of a container, and each individual builder can also be part of a larger pipeline. The scripts that process the application source code can be injected into the builder image, allowing authors to adapt existing images to enable source handling.
55+
56+
Speed::
57+
Instead of building multiple layers in a single Dockerfile, S2I encourages authors to represent an application in a single image layer. This saves time during creation and deployment and allows for better control over the output of the final image.
58+
59+
Security::
60+
Dockerfiles are run without many of the normal operational controls of containers. They usually run as root and have access to the container network. S2I can control what permissions and privileges are available to the builder image since the build is launched in a single container. In concert with platforms like OpenShift, S2I allows administrators to control what privileges developers have at build time.
61+
62+
== Routes
63+
An OpenShift route exposes a service at a hostname so that external clients can reach it by name. When a `Route` object is created on OpenShift, it gets picked up by the built-in HAProxy load balancer to expose the requested service and make it externally available with the given configuration.
64+
65+
Similar to the Kubernetes `Ingress` object, Red Hat created the concept of route to fill a need and then contributed the design principles behind it to the community, which heavily influenced the `Ingress` design. A route does have some additional features as can be seen in the following chart:
66+
67+
[cols="1,1,1"]
68+
|===
69+
|Feature | Ingress on OpenShift | Route on OpenShift
70+
71+
|Standard Kubernetes object
72+
| **X**
73+
|
74+
75+
|External access to services
76+
| **X**
77+
| **X**
78+
79+
|Persistent (sticky) sessions
80+
| **X**
81+
| **X**
82+
83+
|Load-balancing strategies (e.g. round robin)
84+
| **X**
85+
| **X**
86+
87+
|Rate-limit and throttling
88+
| **X**
89+
| **X**
90+
91+
|IP whitelisting
92+
| **X**
93+
| **X**
94+
95+
|TLS edge termination for improved security
96+
| **X**
97+
| **X**
98+
99+
|TLS re-encryption for improved security
100+
|
101+
| **X**
102+
103+
|TLS passhtrough for improved security
104+
|
105+
| **X**
106+
107+
|Multiple weighted backends (split traffic)
108+
|
109+
| **X**
110+
111+
|Generated pattern-based hostnames
112+
|
113+
| **X**
114+
115+
|Wildcard domains
116+
|
117+
| **X**
118+
|===
119+
120+
[NOTE]
121+
====
122+
DNS resolution for a hostname is handled separately from routing. Your administrator might have configured a cloud domain that will always correctly resolve to the router or modify your unrelated hostname DNS records independently to resolve to the router.
123+
====
124+
125+
An individual route can override some defaults by providing specific configurations in its annotations.
126+
127+
[role="_additional-resources"]
128+
.Additional resources
129+
130+
* xref:../../networking/routes/route-configuration.adoc#nw-route-specific-annotations_route-configuration[Route-specific annotations]
131+
132+
[id="cloud-experts-getting-started-openshift-concepts-imagestreams"]
133+
== Image streams
134+
An image stream stores a mapping of tags to images, metadata overrides that are applied when images are tagged in a stream, and an optional reference to a Docker image repository on a registry.
135+
136+
[id="cloud-experts-getting-started-openshift-concepts-imagestreams-benefits"]
137+
=== Image stream benefits
138+
Using an image stream makes it easier to change a tag for a container image. Otherwise, to manually change a tag, you must download the image, change it locally, then push it all back. Promoting applications by manually changing a tag and then updating the deployment object entails many steps.
139+
140+
With image streams, you upload a container image once and then you manage its virtual tags internally in OpenShift. In one project you might use the developer tag and only change a reference to it internally, while in production you might use a production tag and also manage it internally. You do not have to deal with the registry.
141+
142+
You can also use image streams in conjunction with deployment configs to set a trigger that will start a deployment as soon as a new image appears or a tag changes its reference.
143+
144+
[role="_additional-roles"]
145+
.Additional resources
146+
* link:https://blog.openshift.com/image-streams-faq/[Red Hat Blog: How to Simplify Container Image Management in Kubernetes with OpenShift Image Streams]
147+
148+
[id="cloud-experts-getting-started-openshift-concepts-builds"]
149+
== Builds
150+
A build is the process of transforming input parameters into a resulting object. Most often, the process is used to transform input parameters or source code into a runnable image. A `BuildConfig` object is the definition of the entire build process.
151+
152+
OpenShift Container Platform leverages Kubernetes by creating Docker-formatted containers from build images and pushing them to a container image registry.
153+
154+
Build objects share common characteristics:
155+
156+
* Inputs for a build
157+
* Requirements to complete a build process
158+
* Logging the build process
159+
* Publishing resources from successful builds
160+
* Publishing the final status of the build
161+
162+
Builds take advantage of resource restrictions, specifying limitations on resources such as CPU usage, memory usage, and build or pod execution time.
163+
164+
[role="_additional-roles"]
165+
.Additional resources
166+
* link:https://docs.openshift.com/container-platform/latest/cicd/builds/understanding-image-builds.html[Understanding image builds]

0 commit comments

Comments
 (0)