generated from RedHatQuickCourses/template-showroom-rh12025
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #1 from RedHatQuickCourses/initial-commit-ashishks
Content repo initialized
- Loading branch information
Showing
5 changed files
with
73 additions
and
269 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,7 +1,11 @@ | ||
| * 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. Break-fix scenario 1] | ||
| ** xref:module-01.adoc#repositories[Break-Fix Activity] | ||
| ** xref:module-01.adoc#software[Guided steps] | ||
| * 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. Break-fix scenario 2] | ||
| ** xref:module-02.adoc#prerequisites[Break-Fix Activity] | ||
| ** xref:module-02.adoc#container[Guided steps] | ||
| * xref:module-03.adoc[3. Break-fix scenario 3] | ||
| ** xref:module-03.adoc#prerequisites[Break-Fix Activity] | ||
| ** xref:module-03.adoc#container[Guided steps] |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,149 +1,29 @@ | ||
| = Building an Application with rpms | ||
| = Break-fix scenario 1 | ||
|
|
||
| == Downloading the UBI | ||
| FIXME: short description | ||
|
|
||
| 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). | ||
| == Break-fix activity | ||
|
|
||
| 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. | ||
| FIXME | ||
|
|
||
| . Execute the download the Standard UBI | ||
| image from Red Hat's registry. | ||
| . Describe the problem scenario | ||
| . List the success criteria | ||
| . Provide steps for | ||
| . Implementing the break | ||
| . Grading the work | ||
| . Cleaning up the environment | ||
|
|
||
| + | ||
| [source,sh,role=execute] | ||
| ---- | ||
| buildah from registry.access.redhat.com/ubi9/ubi | ||
| FIXME: Use this syntax to write the commands to be executed in the lab | ||
| ---- | ||
|
|
||
| [#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. | ||
| == Guided Steps | ||
|
|
||
| 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. | ||
| FIXME | ||
|
|
||
| . 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] | ||
| [source,sh,role=execute] | ||
| ---- | ||
| podman kill $(podman ps | grep -v CONTAINER | cut -f1 -d" " ) | ||
| FIXME: Use this syntax to write the commands to be executed in the lab | ||
| ---- |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,138 +1,29 @@ | ||
| = Managing an Application from GitHub | ||
| = Break-fix scenario 2 | ||
|
|
||
| In the first half of this workshop, we packaged an application into this portable container format manually using rpms. | ||
| In the second half, we will consider that you may want to manage software from GitHub or some kind of software versioning application. | ||
| Rather than installing rpms, we have individual software files and pull them out of that version control into a group of systems. | ||
| FIXME: short description | ||
|
|
||
| == Install RHEL 8 UBI | ||
| == Break-fix activity | ||
|
|
||
| In this lab, we will be using a different Red Hat Enterprise Linux version in my container. | ||
| FIXME | ||
|
|
||
| . Verify the host system release | ||
| . Describe the problem scenario | ||
| . List the success criteria | ||
| . Provide steps for | ||
| . Implementing the break | ||
| . Grading the work | ||
| . Cleaning up the environment | ||
|
|
||
| + | ||
| [source,bash] | ||
| [source,sh,role=execute] | ||
| ---- | ||
| cat /etc/redhat-release | ||
| FIXME: Use this syntax to write the commands to be executed in the lab | ||
| ---- | ||
| + | ||
| NOTE: The `bastion` system is Red Hat Enterprise Linux 9, and when you built the previous container, you used the UBI9 image. This means both the image and the container were built off the same Red Hat Enterprise Linux packages. | ||
|
|
||
| . As we did previously in this lab, Use `buildah from` to pull down the Red Hat Enterprise Linux 8 UBI. | ||
| [#repositories] | ||
| == Guided Steps | ||
|
|
||
| + | ||
| [source,bash] | ||
| ---- | ||
| buildah from registry.access.redhat.com/ubi8/ubi | ||
| ---- | ||
|
|
||
| NOTE: Because you already pulled one image named `ubi-working-container` this one is called `ubi-working-container-1`. | ||
|
|
||
| [#prerequisites] | ||
| == Install Prerequisites | ||
|
|
||
| Now that you have a working container, you will use the same process as before installing all the prerequisites, changing config files, and manipulating the contents of this container to be in the desired state. | ||
|
|
||
| The software you will install is a JavaScript-based game that runs on a web browser. As before in the lab, use dnf to install software inside the container. | ||
|
|
||
| . Use `buildah run` and install Apache (`httpd`) into the `ubi-working-container-1` container. | ||
| + | ||
| [source,bash] | ||
| ---- | ||
| buildah run ubi-working-container-1 -- dnf -y install httpd | ||
| ---- | ||
|
|
||
| == Enable Service | ||
|
|
||
| The next thing to do is to use a systemctl to enable the service. The ubi-init provides full systemd service to the container. | ||
| This will start up any of the services that are enabled. | ||
|
|
||
| . Enable the `httpd` service using `buildah run` | ||
| FIXME | ||
|
|
||
| + | ||
| [source,bash] | ||
| [source,sh,role=execute] | ||
| ---- | ||
| buildah run ubi-working-container-1 -- systemctl enable httpd | ||
| FIXME: Use this syntax to write the commands to be executed in the lab | ||
| ---- | ||
|
|
||
| NOTE: The UBI standard image doesn't have systemd installed on it by default. The `ubi-init` container image does include systemd. Plan accordingly to which image you use to build applications. | ||
|
|
||
| == Explore Source Materials | ||
|
|
||
| A GitHub repository has already been synchronized to `/home/devops/clumsy-bird/` This repository contains the configurations for your application. | ||
|
|
||
| . Verify the repository is cloned inside the `/home/devops/` directory | ||
| + | ||
| [source,bash] | ||
| ---- | ||
| cd /home/devops/ | ||
| ---- | ||
|
|
||
| + | ||
| [source,bash] | ||
| ---- | ||
| git clone https://github.com/ellisonleao/clumsy-bird | ||
| ---- | ||
| + | ||
| NOTE: The output states that the software has already been checked out. | ||
| + | ||
| . Explore the JavaScript contents, index files, and everything else that we need for this web-based JavaScript software. | ||
| + | ||
| [source,bash,role=execute] | ||
| ---- | ||
| ls clumsy-bird | ||
| ---- | ||
|
|
||
| == Add Source Materials to Container | ||
|
|
||
| . Now that you have verified the source materials exist, you will put the software inside of my container image using the `buildah copy` command. | ||
| + | ||
| [source,bash] | ||
| ---- | ||
| buildah copy ubi-working-container-1 clumsy-bird /var/www/html | ||
| ---- | ||
|
|
||
| [#container] | ||
| == Enable Container in Background | ||
|
|
||
| In the previous section of this lab, you ran the game natively through interactive mode. Because you are now building a web application you will need to run the container in the background and access it through a web address. | ||
|
|
||
| . Execute `buildah config` to specify a port and initialize the container. | ||
|
|
||
| + | ||
| [source,bash] | ||
| ---- | ||
| buildah config --port 80 --cmd "/usr/sbin/init" ubi-working-container-1 | ||
| ---- | ||
|
|
||
| NOTE: The command makes a configuration change to this container. I'm configuring this container to accept connections to its port 80. When the container starts up, it should run the init command, which, in this case, is going to be the Apache daemon right from earlier when I enabled it. | ||
|
|
||
| == Commit Container and Deploy | ||
|
|
||
| . Now that we have a container in a working configured state, it is time to make that permanent by committing it to a container image called `clumsy-bird` | ||
| + | ||
| [source,bash] | ||
| ---- | ||
| buildah commit ubi-working-container-1 clumsy-bird | ||
| ---- | ||
|
|
||
| . Verify that the image was created with `podman` | ||
| + | ||
| [source,bash] | ||
| ---- | ||
| podman images | ||
| ---- | ||
| + | ||
| . Run the container Now it's time to run the container. | ||
| + | ||
| [source,bash] | ||
| ---- | ||
| podman run -d -p 8500:80 clumsy-bird | ||
| ---- | ||
|
|
||
| == Verify Application | ||
|
|
||
| Verify that the application is running by navigating to | ||
|
|
||
| http://bastion.{guid}.example.opentlc.com:8500 | ||
|
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,29 @@ | ||
| = Break-fix scenario 3 | ||
|
|
||
| FIXME: short description | ||
|
|
||
| == Break-fix activity | ||
|
|
||
| FIXME | ||
|
|
||
| . Describe the problem scenario | ||
| . List the success criteria | ||
| . Provide steps for | ||
| . Implementing the break | ||
| . Grading the work | ||
| . Cleaning up the environment | ||
|
|
||
| [source,sh,role=execute] | ||
| ---- | ||
| FIXME: Use this syntax to write the commands to be executed in the lab | ||
| ---- | ||
|
|
||
| [#repositories] | ||
| == Guided Steps | ||
|
|
||
| FIXME | ||
|
|
||
| [source,sh,role=execute] | ||
| ---- | ||
| FIXME: Use this syntax to write the commands to be executed in the lab | ||
| ---- |