-
Section 1 - Creating RHEL Images the GitOps way
- Open Gitea and review the
device-edge-images
repository files - Open Gitea webhook settings
- Open "Jobs" page in AAP and keep it visible
- Push
production-image-definition.yml
andproduction-kickstart.ks
files with the Microshift values in theexamples
directory - Show the "New Edge Device Image" Workflow at the AAP
- Open the Image Builder Cockpit Web console and check that the image is being created
- Describe the
production-image-definition.yml
andproduction-kickstart.ks
that you used to create the image - Show the Slack notification saying that the Workflow is waiting for approval
- Go to the "New Edge Device Image" workflow in AAP and Approve the Image Publishing
- Show the Slack notification saying that the workflow was approved an that the image was published
- Open the ostree-repo contents published, including
student-kickstarts
and thestudent-repos
directories.
- Open Gitea and review the
-
Section 2 - Automated device onboarding
- Open the "Jobs" page in the AAP and keep it visible while performing the following steps.
- Boot the edge server from Network and select the right Image in the PXE menu
- Wait until the server bootsand review the Workflow Jobs in AAP
- SSH into the edge device and explain how AAP auto-registration is done
-
Section 3 - Consistent edge device configuration at scale
-
Configuration consistency across all devices
- Show that sudo is not asking for a password by running
sudo cat /etc/hosts
on the edge device - Open "Jobs" page in AAP and keep it visible while performing the next step
- Change the
device-edge-configs/OS/sudoers
file in Gitea to force sudo to ask for a password - Review Jobs running in AAP
- Check that
/etc/sudoers
in the edge device has the desired configuration - Show how now
sudo cat /etc/hosts
command ask for a password
- Show that sudo is not asking for a password by running
-
Preventing manual configuration overwrite
- Open an SSH Terminal in the edge device as root user and keep the "Jobs" page in AAP visible while performing the next step
- Overwrite manually the
/etc/sudoers
file and remove password authentication again - Show how the "Configure Edge Device" Workflow Job is being launched automatically in AAP
- Run
cat /etc/sudoers
in the edge device to check that you have the "right" configuration back - Show the Python script that monitors file changes in
/etc/
withcat /usr/local/bin/watch_etc.py
-
-
Section 4 - Edge computing APPs lifecycle management
-
APPs with Podman and Systemd
-
Serverless APP with Podman and Systemd
- Run
podman ps
on the edge device - Run
watch podman ps
on the edge device - Visit
http://<edge device IP>:8080
from your laptop - Show what happened in the
watch podman ps
terminal - Wait 90 seconds and show how the Container is stopped automatically
- Run
-
Podman container image auto-update
- Open
http:<edge device ip>:8081
in your laptop - Show the image load problem in the APP
- Show the binding betwen
prod
andv1
tags in Quay.io for the 2048 continer image - Show the issue introduced in container image
v2
- Run the
watch 'podman auto-update --dry-run; echo ""; podman ps'
- Move the
prod
container image tag tov2
in Quay.io - Show how the new image is detected and deployed but how Podman rollback to the previous version due to the issue
- Move the
prod
container image tag tov3
where the image locad problem is solved and show the fixed app in your Browser
- Open
-
Deploying an APP in Podman in a declarative way
- Show
device-edge-configs/APPs/podman/quadlet
folder in Gitea - Run the "Create Quadlet APP" Template in AAP
- Run
podman ps
on the device - Show the APP by visiting
http:<edge device IP>:<configured port>
- Change something in the
device-edge-configs/APPs/podman/quadlet/app_fuxa_scada.container
file and see the change in the APP
- Show
-
-
APPs with Microshift
-
Deploy an APP on Microsift from Manifest files on Gitea
- Show manifests located in
device-edge-configs/APPs/microshift/manifest
in Gitea. - Run
watch "oc --kubeconfig /var/lib/microshift/resources/kubeadmin/kubeconfig get pod --all-namespace"
as root - Launch the "Microshift APP Deploy - Manifest" Template in AAP
- Open
http://frontend-game2048.apps.<edge device ip>.nip.io
in your laptop - Open "Jobs" in AAP and keep it visible along with the
watch
on the CLI - Change image version to
v3
indevice-edge-configs/APPs/microshift/manifest/2-deployment.yml
- Check the
watch
command and wait until the new POD is running - Open
http://frontend-game2048.apps.<edge device ip>.nip.io
in your laptop and show the 2048 app with the image loaded
- Show manifests located in
-
Deploy an APP on Microsift with external Helm repo and vars file on Gitea
- Open "Jobs" in AAP and
watch "oc --kubeconfig /var/lib/microshift/resources/kubeadmin/kubeconfig get pod --all-namespace"
- Show
device-edge-configs/APPs/microshift/helm/wordpress_vars.yml
in Gitea - Run the "Microshift APP Deploy - Helm" Template manually in the AAP
- Visit
http://wordpress-wordpress.apps.<edge device ip>.nip.io
in your laptop when the PODs are running - Open
device-edge-configs/APPs/microshift/helm/wordpress_vars.yml
and change thereplicaCount
number - Wait and see how that number of replicas is deployed on Microshift
- Open "Jobs" in AAP and
-
-
-
Section 5 - Bulletproof system upgrades
- Check that there are no pending upgrades with
watch "rpm-ostree upgrade --preview"
- Modify the
builder_compose_pkgs
in the image definition by removingpython-inotify
and addingzsh
- Show the Image Creation Workflow in AAP
- Explain Greenboot meanwhile the image is created and show the
01-check-packages.sh
script - Publish the new image in AAP
- Check the upgrade availability with
rpm-ostree upgrade --preview
in the edge system - Perform the upgrade by either running
rpm-ostree upgrade
and rebooting using the CLI or by launching the " OSTree Upgrade" Job Template in AAP - Watch the system console while the edge device tries to boot the new system image (and how to finally it fallbacks to the previous image)
- Show the "Upgrade Failed" message in Slack
- SSH to the edge device and review Greenboot and Journal messages
- Show with
rpm-ostree upgrade --check
that we still have pending the upgrade - Create and publish the new Image by modifying the Image description in Gitea adding again the
python-inotify
package. - Perform again the upgrade and check that this time the system is able to complete it.
- Check that there are no pending upgrades with