diff --git a/modules/ch1-microshift/pages/s1-microshift-vs-ocp.adoc b/modules/ch1-microshift/pages/s1-microshift-vs-ocp.adoc index 70b5a1a..0bc9b2b 100644 --- a/modules/ch1-microshift/pages/s1-microshift-vs-ocp.adoc +++ b/modules/ch1-microshift/pages/s1-microshift-vs-ocp.adoc @@ -1,4 +1,4 @@ -:time_estimate: 5 +:time_estimate: 10 = Introduction to MicroShift and Red Hat Device Edge @@ -42,7 +42,7 @@ The following figure compares MicroShift with the smallest edition of Red Hat Op image::s1-microshift-vs-ocp-fig-1.svg[title="MicroShift versus OpenShift"] -It shows that, while both the Red Hat build of MicroShift and Red Hat OpenShift include Kubernetes as their container ochestrator, plus security and a number of cluster services, Red Hat OpenShift includes a larger set of cluster services. The figure also shows that Red Hat OpenShift relies on RHEL CoreOS as its cluster node operating system, while MicroShift relies on plain RHEL and on RHEL services, such as the system journal daemon, for tasks that Red Hat OpenShift would defer to its cluster services. +It shows that, while both the Red Hat build of MicroShift and Red Hat OpenShift include Kubernetes as their container orchestrator, plus security and a number of cluster services, Red Hat OpenShift includes a larger set of cluster services. The figure also shows that Red Hat OpenShift relies on RHEL CoreOS as its cluster node operating system, while MicroShift relies on plain RHEL and on RHEL services, such as the system journal daemon, for tasks that Red Hat OpenShift would defer to its cluster services. A number of components of Red Hat OpenShift are _absent_ from MicroShift, among them: @@ -50,7 +50,7 @@ A number of components of Red Hat OpenShift are _absent_ from MicroShift, among * The Machine Configuration Operator, which manages the configuration of the RHEL CoreOS operating system in OpenShift cluster nodes. * Most Cluster Operators, which manage cluster services like Ingress, OAuth, Monitoring, and Kubernetes control plane components such as Etcd. -It is also expected that Red Hat OpenShift users deploy a number of optional compoents as add-on operators, through the Operator Lifecycle Manager (OLM), such as: +It is also expected that Red Hat OpenShift users deploy a number of optional components as add-on operators, through the Operator Lifecycle Manager (OLM), such as: * OpenShift GitOps * OpenShift Pipelines @@ -60,7 +60,7 @@ It is also expected that Red Hat OpenShift users deploy a number of optional com A number of products certified for OpenShift, including storage and network providers, are also deployed as add-on operators. While you can install the OLM in MicroShift, as an optional component, most add-on operators are not currently tested or supported on MicroShift, and many of them would make no sense. For example, you would run OpenShift Pipelines or Red Hat Ansible Automation Platform in a regular OpenShift cluster to produce system images of Red Hat Device Edge for applications that target MicroShift. That OpenShift instance could even manage the final deployment of the application in actual edge devices, or in OpenShift Virtualization VMs for integration testing of such applications on actual RHEL for Edge system images. -Both Red Hat build of MicroShift and Red Hat OpenShift are https://www.cncf.io/training/certification/software-conformance/#logos[certified kubernetes] distributions, so they are expected to be compatible with the same applications. At least, this is the theory, but the fact is that Kubernetes certification only tests a comprehensive set of core API required to support application workloads, and does _not_ validate the infrastructure nor operational processes for managing Kubernetes clusters. It leaves room for lots of diferentiation between Kubernetes distributions and applications could depend on a number of extension APIs which may not be available or compatible with every distribution of Kubernetes. +Both Red Hat build of MicroShift and Red Hat OpenShift are https://www.cncf.io/training/certification/software-conformance/#logos[certified kubernetes] distributions, so they are expected to be compatible with the same applications. At least, this is the theory, but the fact is that Kubernetes certification only tests a comprehensive set of core API required to support application workloads, and does _not_ validate the infrastructure nor operational processes for managing Kubernetes clusters. It leaves room for lots of differentiation between Kubernetes distributions and applications could depend on a number of extension APIs which may not be available or compatible with every distribution of Kubernetes. MicroShift uses the same container engine (CRI-O) than Red Hat OpenShift and the same container images for components such as the Ingress controller, the OVN network provider, and the LVM Storage operator. @@ -81,7 +81,7 @@ OpenShift includes, since its 3.0 release, a number of extension APIs, and an Op And MicroShift runs its OpenShift API server in the same process and pod as its Kubernetes core components. -MicroShift also includes selected componentes of OpenShift unchanged, by running the same container images that provides those components as Red Hat OpenShift: +MicroShift also includes selected components of OpenShift unchanged, by running the same container images that provides those components as Red Hat OpenShift: * Ingress (and Route) controller * LVM Storage operator and CSI provider @@ -91,13 +91,13 @@ MicroShift also includes selected componentes of OpenShift unchanged, by running A few components of Red Hat OpenShift can also be installed in MicroShift from RPM packages, also using the same container images as Red Hat OpenShift, among them: -* OpenShift GitOps with a pull agent -* Multus seconday networks +* OpenShift GitOps pull agent +* Multus secondary networks * Operator Lifecycle Manager -NOTE: The OpenShift GitOps package for MicroShift is _not_ a complete OpenShift GitOps operator. It cointains only an ArgoCD pull agent to fetch manifests from Git repositories and does not include features such as Argo Rollouts or multi-cluster capabilities. Some features might be included but not tested with MicroShift. +NOTE: The OpenShift GitOps package for MicroShift is _not_ a complete OpenShift GitOps operator. It contains only an ArgoCD pull agent to fetch manifests from Git repositories and does not include features such as Argo Rollouts or multi-cluster capabilities. Some features might be included but not tested with MicroShift. -Red Hat OpenShift is designed to be compatible with a large number of certified third-party components, from storage and network providers to security agents and DevOps tools. MicroShift is designed to work with a more restricted and oppinionated set of components, but also to enable adding optional components, such as GPU enablement, from either RPM packages or add-on operators. +Red Hat OpenShift is designed to be compatible with a large number of certified third-party components, from storage and network providers to security agents and DevOps tools. MicroShift is designed to work with a more restricted and opinionated set of components, but also to enable adding optional components, such as GPU enablement, from either RPM packages or add-on operators. The goal of MicroShift to provide sufficient compatibility with Red Hat OpenShift that applications developed and tested on OpenShift can move to edge deployments unchanged, using the same container images and Kubernetes manifests. @@ -105,14 +105,14 @@ If you wish, you can package those applications as Helm charts or add-on operato == MicroShift Cluster Management -You manage Red Hat OpenShift almost entirely from Kuberentes APIs, using either custom resources from OpenShift cluster operators or from add-on operators. Even the operating system on OpenShift cluster nodes is managed using Kubernetes APIs. OpenShift cluster administrators, especially when running OpenShift in IaaS clouds, may never see the need to run Linux command on their OpenShift cluster nodes. They are advised to *NOT* open SSH sessions to these nodes for day-to-day tasks. +You manage Red Hat OpenShift almost entirely from Kubernetes APIs, using either custom resources from OpenShift cluster operators or from add-on operators. Even the operating system on OpenShift cluster nodes is managed using Kubernetes APIs. OpenShift cluster administrators, especially when running OpenShift in IaaS clouds, may never see the need to run Linux command on their OpenShift cluster nodes. They are advised to *NOT* open SSH sessions to these nodes for day-to-day tasks. Managing MicroShift, on the other hand, requires using traditional RHEL tools, such as the DNF package manager, Systemd, and SSH. Red Hat OpenShift is a complete application platform by itself, which provides a cloud-like experience, while MicroShift is closer to "just" running Kubernetes on top of RHEL. Finally, MicroShift clusters are always single node. If you need HA, you have to either consider RHEL HA services, such as Pacemaker, or switch to Red Hat OpenShift. If you need horizontal scalability among multiple nodes, or vertical scalability to larger servers, you should also consider Red Hat OpenShift. On the other hand, MicroShift integrates well with other features of RHEL for Edge, for example the Greenboot capability of rolling back system upgrades to a previously known good image. -You can run MicroShift in cloud instances, if you wish, but MicroShift lacks the integration components to use cloud auto-scaling, cloud storage, and cloud load balancers. It is really designed for small physical edge devices, and provides all componentes required by those devices as an integrated product, while upstream Kubernetes would require that you add, configure, and integrate a number of third-party componentes such as network providers, storage providers, ingress controllers, service discovery, and more. +You can run MicroShift in cloud instances, if you wish, but MicroShift lacks the integration components to use cloud auto-scaling, cloud storage, and cloud load balancers. It is really designed for small physical edge devices, and provides all components required by those devices as an integrated product, while upstream Kubernetes would require that you add, configure, and integrate a number of third-party components such as network providers, storage providers, ingress controllers, service discovery, and more. == What's Next -There first activities in this course prepare the virtual labs environment for air-gappend deployment of MicroShift using either package-based RHEL or RHEL for Edge. It should provide enough information for you to replicate the activities on your own environment, if you prefer, or trying a simpler deployment, not air-gapped. +There first activities in this course prepare the virtual labs environment for air-gaped deployment of MicroShift using either package-based RHEL or RHEL for Edge. It should provide enough information for you to replicate the activities on your own environment, if you prefer, or trying a simpler deployment, not air-gaped. diff --git a/modules/ch1-microshift/pages/s2-prepare-lab.adoc b/modules/ch1-microshift/pages/s2-prepare-lab.adoc index 9fed60a..cacea57 100644 --- a/modules/ch1-microshift/pages/s2-prepare-lab.adoc +++ b/modules/ch1-microshift/pages/s2-prepare-lab.adoc @@ -1,4 +1,4 @@ -:time_estimate: 5 +:time_estimate: 9 = Lab: Prepare a Test Environment for Red Hat Device Edge @@ -34,7 +34,7 @@ In the course environment, the `classroom` VM, with the `materials` alias, is yo If you are using the same course enviroment where you performed the activities from the https://redhatquickcourses.github.io/rhde-build/rhde-build/1/index.html[Building Red Hat Device Edge Images] quick course, you should have some requirements already set up. They are listed here anyway, for learners that are starting this course in a new course environment. -NOTE: It should be possible to perform all activities in this course using a https://developers.redhat.com/products/rhel/download[free Red Hat Developers free subscrition], which gives you access to installation media, RPM packages, and container images for RHEL and Red Hat OpenShift. If you ignore the requirements for air-gapped installation of MicroShift, you could use a single RHEL VM and adapt the steps to your own environment. +NOTE: It should be possible to perform all activities in this course using a https://developers.redhat.com/products/rhel/download[free Red Hat Developers free subscrition], which gives you access to installation media, RPM packages, and container images for RHEL and Red Hat OpenShift. If you ignore the requirements for air-gaped installation of MicroShift, you could use a single RHEL VM and adapt the steps to your own environment. == Instructions @@ -42,7 +42,7 @@ NOTE: It should be possible to perform all activities in this course using a htt + If something goes wrong while performing these steps and you need troubleshooting aid, please refer to the activities from the https://redhatquickcourses.github.io/rhde-build/rhde-build/1/ch1-build/s4-install-lab.html[first course] which focus on deploying Image Builder and RPM-OSTree. -.. Install the RPM packages for the Image Builder service and its CLI. Notice that RPM-OSTree pacakges are also installed, as dependencies. +.. Install the RPM packages for the Image Builder service and its CLI. Notice that RPM-OSTree packages are also installed, as dependencies. + [source,subs="verbatim,quotes"] -- @@ -80,14 +80,14 @@ $ *sudo firewall-cmd --reload* success -- -.. Grant your unpriviged user (the `student` user) with access to the Image Builder service. +.. Grant your unprivileged user (the `student` user) with access to the Image Builder service. + [source,subs="verbatim,quotes"] -- $ *sudo usermod -a -G weldr student* -- -.. Configure your unpriviged user with Bash command autocompletion for the Image Builder CLI. +.. Configure your unprivileged user with Bash command autocompletion for the Image Builder CLI. + [source,subs="verbatim,quotes"] -- @@ -201,7 +201,7 @@ NOTE: Later in this course you will configure additional package sources for pac 3. Configure your _development machine_ with the Libvirt tools. It should be ready if you already performed the activities from the first course on the same course environment. + -If something goes wrong while performing these steps and you need troubleshooting aid, please refer to the activities from tue https://redhatquickcourses.github.io/rhde-build/rhde-build/1/ch3-test/s2-boot-lab.html[first course] which focus deploying Libvirt and using KVM virtualization. +If something goes wrong while performing these steps and you need troubleshooting aid, please refer to the activities from the https://redhatquickcourses.github.io/rhde-build/rhde-build/1/ch3-test/s2-boot-lab.html[first course] which focus deploying Libvirt and using KVM virtualization. .. Install the Libvirt tools. + diff --git a/modules/ch1-microshift/pages/s3-air-gapped-lab.adoc b/modules/ch1-microshift/pages/s3-air-gapped-lab.adoc index b32d86d..58406de 100644 --- a/modules/ch1-microshift/pages/s3-air-gapped-lab.adoc +++ b/modules/ch1-microshift/pages/s3-air-gapped-lab.adoc @@ -1,4 +1,4 @@ -:time_estimate: 5 +:time_estimate: 9 = Lab: Prepare a Test Environment for MicroShift @@ -6,7 +6,7 @@ _Estimated reading time: *{time_estimate} minutes*._ Objective:: -Prepare a test environment for air-gapped deploment of MicroShift in both package-based RHEL and RHEL for Edge. +Prepare a test environment for air-gaped deployment of MicroShift in both package-based RHEL and RHEL for Edge. WARNING: Work In Progress @@ -32,7 +32,7 @@ IMPORTANT: Be sure you execute each step on the correct machine. If a step is no In the course environment, the `classroom` VM, with the `materials` alias, is your _package server machine_ but you are _not_ expected to start SSH sessions nor perform any activity on it. -NOTE: It should be possible to perform all activities in this course using a https://developers.redhat.com/products/rhel/download[free Red Hat Developers free subscrition], which gives you access to installation media, RPM packages, and container images for RHEL and Red Hat OpenShift. If you ignore the requirements for air-gapped installation of MicroShift, you could use a single RHEL VM and adapt the steps to your own environment. +NOTE: It should be possible to perform all activities in this course using a https://developers.redhat.com/products/rhel/download[free Red Hat Developers free subscrition], which gives you access to installation media, RPM packages, and container images for RHEL and Red Hat OpenShift. If you ignore the requirements for air-gaped installation of MicroShift, you could use a single RHEL VM and adapt the steps to your own environment. == Instructions @@ -129,7 +129,7 @@ $ *sudo cp /var/quay/quay-rootCA/rootCA.pem /var/www/html/quay-rootCA.pem* 2. Configure your _development machine_ to access your mirror registry. + -We will install MicroShift with common assumptions of air-gapped environments, where MicroShift should only pull contrainer images that were previouslly vetted and only from private container registries, which in the course environment is the mirror registry.. +We will install MicroShift with common assumptions of air-gaped environments, where MicroShift should only pull container images that were previously vetted and only from private container registries, which in the course environment is the mirror registry. .. Add the CA certificate of the mirror registry to your system trusted certificates. + @@ -161,7 +161,7 @@ WARNING: You will later copy this file to your MicroShift instances, so it is im .. Download a file system copy of all images from the classroom server. + -NOTE: When outside of the course environment, follow the instructions from product docs to extract a list of MicroShoft release images from the `microshift` RPM package and download them to a staging directory. In the course environment, we provide you with a backup of the staging directory to avoid the need for internet access and save on cloud bandwidth fees. +NOTE: When outside of the course environment, follow the instructions from product docs to extract a list of MicroShift release images from the `microshift` RPM package and download them to a staging directory. In the course environment, we provide you with a backup of the staging directory to avoid the need for internet access and save on cloud bandwidth fees. + [source,subs="verbatim,quotes"] -- @@ -190,7 +190,7 @@ $ *wget -q https://raw.githubusercontent.com/RedHatQuickCourses/rhde-build-sampl $ *sh upload-microshift.sh* -- + -NOTE: OpenShift release images, which are reused by MicroShift, are not identified by a tag. You must reffer to them by hash, so they look like different builds of the same `openshift-release-dev/ocp-v4.0-art-dev` image but they are actually completely different images. +NOTE: OpenShift release images, which are reused by MicroShift, are not identified by a tag. You must refer to them by hash, so they look like different builds of the same `openshift-release-dev/ocp-v4.0-art-dev` image but they are actually completely different images. .. You can check that the upload process worked by listing all images in the mirror registry. + @@ -235,11 +235,11 @@ servera.lab.example.com:8443/flozanorht/php-ubi servera.lab.example.com:8443/ubi9/ubi -- -.. Alternativelly, you can open the web GUI of Red Hat Quay at `https://servera.lab.example.com:8443/` and browse the images available in your mirror registry. +.. Alternatively, you can open the web GUI of Red Hat Quay at `https://servera.lab.example.com:8443/` and browse the images available in your mirror registry. + -NOTE: The mirror registry for Red Hat OpenShift only supports a subset of the features of Red Hat Quay and it is not configured for realiability and high availability. +NOTE: The mirror registry for Red Hat OpenShift only supports a subset of the features of Red Hat Quay and it is not configured for reliability and high availability. -5. Check that your _package server machine_ is already set up with all artifacts required for air-gapped installation of MicroShift. These steps are required for _both_ kinds of MicroShift deployment: on package-based RHEL and on RHEL for Edge system images. +5. Check that your _package server machine_ is already set up with all artifacts required for air-gaped installation of MicroShift. These steps are required for _both_ kinds of MicroShift deployment: on package-based RHEL and on RHEL for Edge system images. + NOTE: In production environments, it is recommended that you deploy Red Hat Satellite to mirror RPM package repositories from Red Hat products, but the course environment uses an Apache Web Server. @@ -247,7 +247,7 @@ NOTE: In production environments, it is recommended that you deploy Red Hat Sate .. Open `http://content.example.com/rhde/rpms/` in a web browser. This directory contains a copy of the Red Hat OpenShift and Fast Datapath for RHEL repositories, created using the `reposync` command. -You now have your _mirror registry machine_ and your _package server machine_ ready to support air-gapped deployment of MicroShift in both package-based RHEL and in RHEL for Edge images. +You now have your _mirror registry machine_ and your _package server machine_ ready to support air-gaped deployment of MicroShift in both package-based RHEL and in RHEL for Edge images. == What's Next diff --git a/modules/ch1-microshift/pages/s4-summary.adoc b/modules/ch1-microshift/pages/s4-summary.adoc index f1746b6..ba860ff 100644 --- a/modules/ch1-microshift/pages/s4-summary.adoc +++ b/modules/ch1-microshift/pages/s4-summary.adoc @@ -2,14 +2,14 @@ In this chapter, you learned: -* MicroShift rebuilds selected components of an OpenShift control plane as a single process, managed by Systemd. +* MicroShift rebuilds selected components of the OpenShift control plane as a single process, managed by Systemd. * MicroShift runs selected components of OpenShift, such as its Ingress controller and LVM Storage operator, using the same container images as Red Hat OpenShift. -* You can install optional componments of MicroShift from RPM packages, including the Operator Lifecycle Manager (OLM), which then enables you to install add-on operators that are tested and supported on MicroShift. +* You can install optional components of MicroShift from RPM packages, including the Operator Lifecycle Manager (OLM), which then enables you to install add-on operators that are tested and supported on MicroShift. * Unlike Red Hat OpenShift, where you perform almost all day-to-day management of clusters and applications using Kubernetes APIs, deploying and managing MicroShift instances requires using common RHEL tools and processes. * If your edge deployment requires High Availability (HA), horizontal scalability to multi-node Kubernetes, or vertical scalability to server-class machines, consider the many editions and deployment factors of Red Hat OpenShift. -* MicroShift should run most applications developmed and tested on Red Hat OpenShift unchanged, from the same container images, manigests, helm charts, and add-on operators. \ No newline at end of file +* MicroShift should run most applications developed and tested on Red Hat OpenShift unchanged, from the same container images, manifests, helm charts, and add-on operators. \ No newline at end of file