Initial commit

.github/workflows/gh-pages.yml

@@ -0,0 +1,48 @@
+name: github pages
+
+on:
+  workflow_dispatch:
+  push:
+    branches: [main]
+    paths-ignore:
+      - "README.adoc"
+      - ".gitignore"
+
+permissions:
+  pages: write
+  id-token: write
+
+concurrency:
+  group: gh-pages
+  cancel-in-progress: false
+
+jobs:
+  build:
+    runs-on: ubuntu-latest
+    steps:
+      - name: checkout
+        uses: actions/checkout@v4
+      - name: configure pages
+        uses: actions/configure-pages@v5
+      - name: setup node
+        uses: actions/setup-node@v4
+        with:
+          node-version: 20.13.1
+      - name: install antora
+        run: npm install --global @antora/[email protected] @antora/[email protected]
+      - name: antora generate
+        run: antora generate default-site.yml --stacktrace
+      - name: upload pages artifact
+        uses: actions/upload-pages-artifact@v3
+        with:
+          path: www
+  deploy:
+    needs: build
+    environment:
+      name: github-pages
+      url: ${{ steps.deployment.outputs.page_url }}
+    runs-on: ubuntu-latest
+    steps:
+      - name: deploy github pages
+        id: deployment
+        uses: actions/deploy-pages@v4

.gitignore

@@ -0,0 +1,38 @@
+# Ignore macOS system files
+.DS_Store
+
+# Ignore node_modules directory
+node_modules/
+
+# Ignore build output
+www/
+.cache/
+
+# Ignore IDE and editor files
+.vscode/
+.idea/
+
+# Ignore logs and temporary files
+*.log
+*.tmp
+
+# Ignore environment-specific files
+.env
+.env.local
+.env.*.local
+
+# Ignore sensitive or private information
+secrets.json
+
+# Ignore compiled binaries or executables
+*.exe
+*.dll
+*.so
+*.dylib
+*.core
+
+# Ignore package-lock.json for npm
+package-lock.json
+
+# Ignore yarn.lock for Yarn
+yarn.lock

README.adoc

@@ -0,0 +1,16 @@
+=== Getting Started
+
+This template is designed to be used as a base for your showroom lab guides.
+
+In order to test and develop on your local machine, you can use a specially built container with Podman or Docker as follows.
+
+[source,sh]
+----
+podman run --rm --name antora -v $PWD:/antora -p 8080:8080 -i -t ghcr.io/juliaaano/antora-viewer
+----
+
+If you make changes to the content, all you need is to kill the container and run it again.
+
+Live-reload is not supported.
+
+The content is built using Antora, a static site generator for creating documentation sites from AsciiDoc documents.

content/antora.yml

@@ -0,0 +1,15 @@
+name: modules
+title: Default Title
+version: main
+nav:
+  - modules/ROOT/nav.adoc
+
+asciidoc:
+  attributes:
+    lab_name: "I'm the lab_name var"
+    page-pagination: true
+    my_var: "foo"
+    guid: my-guid
+    ssh_user: devops
+    ssh_password: devops
+    ssh_command: ssh devops@bastion.{guid}.example.opentlc.com

content/modules/ROOT/nav.adoc

@@ -0,0 +1,7 @@
+* xref:module-01.adoc[1. RPM Native Container]
+** xref:module-01.adoc#repositories[Repositories]
+** xref:module-01.adoc#software[Software]
+
+* xref:module-02.adoc[2. GitHub Sourced Container]
+** xref:module-02.adoc#prerequisites[Install Prerequisites]
+** xref:module-02.adoc#container[Enable Container]

content/modules/ROOT/pages/index.adoc

@@ -0,0 +1,43 @@
+= Welcome to Showroom
+
+The `lab_name` var, known as an asciidoc attribute, above was set in `./content/antora.yml` and can be used to set the lab_name or title of your content.
+You are both free to change its value and if you prefer to use a different var name, you can change the value of `lab_name`, for example to `title` in `./content/antora.yml` and then reference it in your content as `\{title}`. +
+
+image::rhel-logo-black.jpg[rhel-logo-black,55%,55%]
+
+== Variables
+
+Other vars can also be set there, such as `ssh_user` and `ssh_password`, and referenced inline in the lab content by using the `\{foo}` syntax.
+
+This is another var, or asciidoc attribute, from `./content/antora.yml` {my_var}
+
+== Writing your lab
+
+Whatever type of content you are writing we'll refer to your *content* as "your lab" in this document.
+
+=== 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.

content/modules/ROOT/pages/module-01.adoc

@@ -0,0 +1,149 @@
+= Building an Application with rpms
+
+== Downloading the UBI
+
+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" " )
+----