Skip to content

Commit

Permalink
module 1&2
Browse files Browse the repository at this point in the history
  • Loading branch information
@mrobson
mrobson committed Nov 15, 2024
1 parent ef51d32 commit b8db3f8
Show file tree
Hide file tree
Showing 4 changed files with 141 additions and 251 deletions.
12 changes: 6 additions & 6 deletions content/modules/ROOT/nav.adoc
View file
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
* xref:module-01.adoc[1. RPM Native Container]
** xref:module-01.adoc#repositories[Repositories]
** xref:module-01.adoc#software[Software]
* xref:module-01.adoc[1. How to use omc]
** xref:module-01.adoc#omcintro[It's just like oc, but on a must-gather!]
* xref:module-02.adoc[2. GitHub Sourced Container]
** xref:module-02.adoc#prerequisites[Install Prerequisites]
** xref:module-02.adoc#container[Enable Container]
* xref:module-02.adoc[2. vSphere IPI - I can not scale up any new nodes]
** xref:module-02.adoc#checknodes[Check the nodes and the machines]
** xref:module-02.adoc#checkmachineapi[Check the Machine API]
** xref:module-02.adoc#checkserver[Check the Server]
21 changes: 1 addition & 20 deletions content/modules/ROOT/pages/index.adoc
View file
Original file line number Diff line number Diff line change
Expand Up @@ -4,29 +4,10 @@ Welcome to Red Hat One 2025 and this exciting, hand-on lab experience. Throughou

image::openshift-logo.svg[openshift-logo,100%,100%]

=== Lab structure
== Lab structure

Wether you are writing a lab

* First, we will build a monolithic application already compiled as RPM packages and put it into a container. This will allow us to deploy the application, copy it between machines, and update it separately from the operating system. This process affords us a portable and easily maintained component instead of tightly coupling the application with your operating system maintenance.

* In closing we will build a second container on a different operating system version that makes an application not packaged into RPMs. This will be similar to a web application deployment, positioning the correct files at the right locations. To do this, we will pull a project from GitHub and position the component files within our container image. The purpose of this is to achieve a portable application container that can deploy on several different versions of Red Hat Enterprise Linux. This also provides the benefit of decoupling your application maintenance, which would all happen by building new containers versus operating system maintenance. The container is no longer reliant on the operating system installed on the machine where the application is deployed.

. Now let's examine this cluster a bit more by describing the cluster (the `$GUID` environment variable is already set for you so you can immediately describe your individual cluster):
+
[source,sh,role=execute]
----
podman ps
----
+
.Sample Output
[source,texinfo,subs="attributes"]
----
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
2dcfee9e50c4 docker.io/library/httpd:2.4 httpd-foreground 3 hours ago Up 3 hours 0.0.0.0:8080->80/tcp showroom-httpd
----

=== Lab Access

The terminal window to your right is *already* logged into the lab environment as the `{ssh_user}` user via `ssh`.
All steps of this lab are to be completed as the `{ssh_user}` user.
150 changes: 3 additions & 147 deletions content/modules/ROOT/pages/module-01.adoc
View file
Original file line number Diff line number Diff line change
@@ -1,149 +1,5 @@
= Building an Application with rpms
= How to use omc

== Downloading the UBI
[#omcintro]
== It's just like oc, but on a must-gather!

In this lab, you will be installing software into the container
image running as an interactive application. To do this you will
need `yum`, but do not need `systemd` for managing services within the
container environment. For that reason, you will be using the *Standard*
UBI image (as opposed to the Minimal or Multi-service images).

Using the "buildah from" command will download and meld the container image. This particular image we are using is the Red Hat Universal Base Image or UBI. From the ourput of the command, you will notice that we are pulling down the latest one, which is for RHEL 9.

. Execute the download the Standard UBI
image from Red Hat's registry.

+
[source,sh,role=execute]
----
buildah from registry.access.redhat.com/ubi9/ubi
----

[#repositories]
== Installing Repositories
In this lab, you are going to containerize a software package that is already
packaged in RPM format and stored in the Extra Packages for Enterprise Linux
(EPEL) repository.

Software often has requirements for prerequisite software that must be installed
on the machine for it to work properly. `yum` will resolve those
dependencies for you, as long as it can locate the required packages in
repositories defined on the machine. The Red Hat Universal Base Image (UBI)
downloaded in the previous step has access to some Red Hat Enterprise Linux
repositories. However, the target package for the lab is from EPEL.

. In the command below, `buildah` is going to run a command on the
`ubi-working-container` image. The `--` indicates that the command should be
executed from within the container, which means the results will be applied into
the container image. Lastly, you are providing the `yum` command to install a
package that defines all of the repositories from EPEL, `epel-release-latest-9`.

+
[source,bash]
----
buildah run ubi-working-container -- yum -y install https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm
----


. You can verify that the above command did not install the RPM on the host system.

+
[source,bash]
----
rpm -q epel-release
----

NOTE: If your repository configurations are not distributed as an RPM, but instead as
individual `.repo` files, you could use the `buildah copy` command to copy
files from the host operating system into the container image. You will see
an example of using `buildah copy` later in this lab.

[#software]
== Installing Software


. Now that the yum repositories are defined within the container, execute
another `yum install`, within the container, to install the target
software: `moon-buggy`.

+
[source,bash]
----
buildah run ubi-working-container -- yum -y install moon-buggy
----


== Committing the Container Image

. At this point, the container is configured. It is time to transition from a
working container into a committed image. In the command below, you will use
the `buildah` command to commit the working container to an image called:
`moon-buggy`.

+
[source,bash]
----
buildah commit ubi-working-container moon-buggy
----

+
. The output of `podman image list` should confirm the image was created.

+
[source,bash]
----
podman image list
----


== Deploy the Container

Now the software has been installed and a new container image created. It is
time to spawn a runtime of the container image and validate the software. The
software we are using is a command line command.

. When you `run` the container,
it will be in interactive (`-it`) mode, based on the `moon-buggy` container
image and the command run interactively will be `/usr/bin/moon-buggy`.

+
[source,bash]
----
podman run -it moon-buggy /usr/bin/moon-buggy
----

+
[source,textinfo]
----
<<< OUTPUT ABRIDGED >>>
MM MM OOOOO OOOOO NN N
M M M M O O O O N N N
M M M M O O O O N N N
M M M O O O O N N N
M M O O O O N N N
M M OOOOO OOOOO N NN
BBBBBB U U GGGGG GGGGG Y Y
B B U U G G G G Y Y
BBBBBB U U G G Y Y
B B U U G GGG G GGG Y
B B U U G G G G Y
BBBBBB UUUUU GGGGG GGGGG YY
<<< OUTPUT ABRIDGED >>>
----

. You can now play the Moon Buggy game, which is a text-based version of the
popular Moon Patrol. When you are finished, use the `q` command to quit the
game, which will terminate the container.

+
Alternatively, you can use `podman` to kill the running container from
*Terminal 2*.

+
[source,bash]
----
podman kill $(podman ps | grep -v CONTAINER | cut -f1 -d" " )
----
Loading

0 comments on commit b8db3f8

Please sign in to comment.