spellcheck on ch1

modules/ch1-build/pages/index.adoc

@@ -3,6 +3,8 @@
 Goal:: 
 Build RHEL for Edge images using RHEL Image Builder and Cockpit
 
+WARNING: Pending SME Review & Proofreading
+
 == Introduction
 
 This chapter explains how edge devices differ from traditional servers in data centers and cloud providers and introduces the features from Red Hat Enterprise Linux (RHEL) designed to meet the needs of edge devices, such as the RHEL image builder tool and the OSTree technology, collectively known as RHEL for Edge.

modules/ch1-build/pages/s1-devices-old.adoc

@@ -0,0 +1,114 @@
+== DO NOT USE THIS
+
+
+== Managing Edge Systems Versus Tradictional RHEL Systems
+
+Regular images from Image Builder work the same as if you deploy RHEL from its installation media: they are package-based systems. After you install a physical system or boot a VM from these images, you manage it exactly the same way as if you installed the system from RHEL installation media.
+
+Edge images, in contrast, are image-based systems. They assume most customizations are predefined in the system image, and that software updates are performed by installing another complete system image.
+
+Consider the scenario of updating a system to mitigate a CVE vulnerability with the Apache Web Server. You would act differently on image-based systemas compared to traditional package-based systems:
+
+* On regular RHEL, which is a package-based system, you would SSH into the system and use `dnf` to update the `httpd-server` package and its dependencies.
+
+* On RHEL for Edge, which is an image-based system, you would use Image Build to build a new system image that includes the updated `httpd-server` package and dependencies, and them deploy the new system image on the system.
+
+
+
+Installing and updating RHEL for Edge systems requires different approaches and operational procedures compared to traditional RHEL systems. Good news, this does not have to affect application development and testing. Because RHEL for Edge is RHEL, edge devices have compatibility with applications and hardware with traditional RHEL. You can develop and test applications using traditional RHEL and later depeloy them in RHEL for Edge systems.
+
+An added benefit of RHEL for Edge is a consequence of the fact that RPM-OSTree keeps multiple system images side-by-side in a system, so downloading updates does not affect a running system -- constrast that with RPM package updates, which can alter files which are in use by running processes and produce unpredictable results. And, if the switch to the updated system image fails, the previous working system image is still unchanged in your edge devices, and you can roolback to it quickly.
+
+== RPM-OSTree, OpenShift, and Red Hat CoreOS
+
+The typical RHEL system administrator may not be used to manage image-based systems nor to using the RPM-OSTree technology, but can rest assured that these techologies are already mature, being used in large production deployments of OpenShift 4 for many years already.
+
+Red Hat CoreOS is Red Hat Enterprise Linux, but deployed as an image-based system by the Red Hat OpenShift installer and updated by the OpenShift Machine Operator. The binaries for the Linux Kernel, device drivers, and system services are the same as from regular RHEL, as they are with RHEL for Edge.
+
+Red Hat CoreOS is also designed to be managed by OpenShift, in the sense that you would not log in on OpenShift cluster nodes and change system settings, but would apply those changes using the OpenShift Machine Operator. RHEL for Edge, in constrast, is designed to be managed using regular RHEL tools, such as Ansible and Secure Shell.
+
+RHEL for Edge makes the RPM-OSTree techonology and image-based systems available for edge devices and edge servers, whithout the need to use OpenShift and learn its deployment and management workflows. It is a ligher transition for the RHEL system administrator.
+
+== The Future: RHEL Image Mode and Bootc
+
+If you wonder that image-based operating system deployments and updates are very similar to containerised application deployment and management, you are right. In fact, there's an ongoing engineering effort to integrate workflows from the Linux container world with the image-based operating systems world. This will become a new feature set of RHEL, called RHEL Image Mode, and it is based on a new tool called Bootc.
+
+You will be able to use either Image Builder or traditional Linux container tools, such as Podman and Buildah, to build operating system images and distribute them as OCI container images, which eases integration with cloud-native application development tools and CI/CD processes.
+
+The first incarnations of RHEL Image Mode still depend on the the RPM-OStree foundation, and, if it ever comes the time it replaces OSTree with something else, RHEL Image Mode is expected to continue relying long-tem on Green Boot, FDO, and other technologies from RHEL for Edge. 
+
+In essense, RHEL Image Mode will expand the RHEL for Edge feature set for better integration with containerized application development workflows instead of replacing it entirely with a new set of technologies.
+
+== What is an Edge Device
+
+Edge devices come in varying shapes and forms. RHEL for Edge is not designed to support any kind of edge device, it is designed to run in devices which are close in hardware architecture to standard personal computers and servers. It benefits from the large ecosystem of software and hardware certified for RHEL and the fact that the economy of edge devices got to a point where a "standard computer" is cost-effective and brings a lot more flexibility and power than a custom processor and interface design.
+
+For example you cannot run RHEL directly in a surveilance camera, even if some security cameras do indeed run Linux. Like an Android cell phone also runs Linux but it's a very different flavor of Linux than RHEL, and cannot run the same applications that RHEL does. But you could run RHEL in edge devices that monitor the video feed from a surveilance camera (or from multiple cameras) to detect potential security threads and fire an alarm.
+
+A similar edge device could use a video camera to perform quality control in a factory, identifying defective pieces and reducing the need for human inspection, and reroute the defective pieces for disposal or recycling.
+
+Now imagine that the same edge device controls a robotic arm with a spray gun: instead being pre-programmed with a fixed path for only a few pieces, an edge device could adapt optime the paint process based on the specific piece it sees.
+
+Edge devices where you deploy RHEL for Edge could look like standard computers, even standard desktop computers, maybe in a rugged and smaller form factory, which connect to varying kinds of sensors and machinery. Or you could use custom hardware kits which integrate sensors and other kinds machinery with an Intel or ARM computer in the same box, and may not look, from the outside, anything like a "personal computer" despite being built on the same basic architecture, chipsets, and peripheral busses as a standard desktop computer or server.
+
+Another way of describing edge devices, which also helps undestanding their need for distinct technical features, is by comparing them with standard workstations and servers in typical corporations:
+
+Traditional physical servers and cloud instances exist in strictly controlled datacenter environments and are maintained by an army of highly skilled IT operations personel such as Systems Administrators and Site Reliability Engineers. They tend do be large machines, not necessarily in size but in capacity, as measured in CPU cores and RAM, which require sophisticated power supply and cooling.
+
+Edge devices, in contrast, may exist in hazard environments, subject to eletromagnetic fields, dust, and heat. They are likely accessible by end users and the general public, instead of being protected in a locked server room. Edge devices tend to be deployed and maintained by a floating team of less skilled IT staff which moves from site to site according to need. It should be possible to deploy and maintain edge devices without a Red Hat Certified System Administrator on site or acessing remotelly.
+
+// use slide #62 ? https://docs.google.com/presentation/d/1j2WQN3mdrM1bviqrK2Qyy6-JvRzqxKGi3wfymhsyy_E/edit#slide=id.g135f6d1eb60_1_824
+
+[ figure of edge devices/servers vs datacente/cloud servers (and office workstations?) ]
+
+Edge devices are usually small machines, not just on form factor, but also on capacity, so they do not require special cooling and power. Some of these machines are very similar to end user workstations, while others may be unrecognizable as standard "Personal Computers" (PCs). They tipically include non-standard hardware, at least not common for office workers, such as barcode scanners and programable logic controllers (PLCs).
+
+NOTE: RHEL for Edge uses the same kernel and device-drivers as RHEL, and certifies the same hardware. While there are many edge systems certified for RHEL, including a number of rugged computers and ARM systems, you cannot run RHEL in custom computer kits similar to Rasperry PIs.
+
+Edge servers, as supporting infrastructure for edge devices and edge workstations, range from very close to edge devices to very similar to datacenter servers. You may deploy and manage edge servers using tools and strategies from either traditional RHEL or RHEL for Edge.
+
+Edge sites, as the locations where you deploy edge devices, vary from having no IT infrastructure at all to being connected to a local area network with dedicated servers and networking gear that would rival with the IT of a support a small business. Nowdadays it's very hard to imagine an edge site that is completely disconnected from corporate IT all the time, but edge sites may have low bandwidth, high latency connectivity which is spotty, so applications and management cannot depend on being online.
+
+[ Figure of the progression from central IT to near edge to far edge, as an illustration, I'm not trying to explain all those terms and concepts ]
+
+Those constraints of size, capacity, environment, users, and infrastructure require different strategies for deployment and management, as compared to the world of corporate datacenters and cloud instances. RHEL for Edge was desiged for those constraints and, though it is the same RHEL software you run elsewhere, it may not feel nor look like the RHEL you know.
+
+Edge is about variability and automation. You may find that, for a particular edge scenario, a traditional subscription from RHEL and OpenShift provides a better return of investiment, or that your hardware is too big to qualify for Red Hat Devie Edge subscriptions, but the tools and processes from RHEL for Edge still bring significant benefits.
+
+[ Figure of edge scenarios using RHDE vs traditional RHEL and OCP ]
+
+Consider recent incidents such as the CrowdStrike failure, that effectively shut down large business for hourses because they couldn't operate check-in booths at airports and radiology equipment in hospitals, as a warning sign that you should NOT plan and manage edge sites the same way you used to plan and manage traditional office and datacenter IT. 
+
+== Image-Based Operating System Deployment
+
+The main strategy for edge device and edge server management is deploying and updating their operating system and applications as a single prebuilt system image. That means you install an edge device and perform minimal on-site configuration (or no configuration at all) and the device is ready for its intended application. Compare that with the multi-step process you would follow for a traditional datacenter server or cloud instance:
+
+. Install the operating system from standard installation image or cloud image.
+. Install additional packages and software.
+. Configure operating system services and third-party applications.
+
+[ figure of day-0, day-1, and day2 of deploying and configuring a package-based system ]
+
+Each of the previous steps is, by itself, another multi-step process, which takes time, and can be performed with small or large variation each time, requiring specialized skills, and is prone to error.
+
+While you can prevent human erros and enforce reproducibility and consistency with automation, you woud be, in essense, emulating a human user performing all those steps at day-2. What happens if you lose connectivity to an edge device in the middle of one of those multi-step subprocesses?
+
+Image-based deployments work on the premise that most steps are performed at day-0, as part of image building, so that that systems are as close to ready as possible at day-1 and require only minimal maintenance on day-2.
+
+[ Figure of day-0+1+2 of deploying and configuring an image-based system ]
+
+Building system images with preconfigured operating systemas and applications is not a new concept. It started with low-level server disk cloning software and evolved to different automation strategies. You can find many preconfigured machine images in large IaaS cloud provider marketplaces and many organizations use golden images to deploy applications consistently into multiple regional datacenter and cloud provider regions. But not all system images are designed to be edge images.
+
+== Image-Based Updates
+
+The key to image-based deployments for edge devices and edge servers is to use image-based deployments on day-2 also, when updating applications and system configuration. Instead of logging in to each server to install software patches or change local configurations, following another multi-step process which may fail at any point, and also requires and good connectivity to multiple remote resources, you build a new image that includes those patches and configuration changes. Then you deploy the new image as a single step on the target systems.
+
+[ Figure of incomplete provision or updating a package-based system which ends in an uncertain state ]
+
+The biggest advantege of performing image-based dployments on day-2 is that those deployments are easy to rollback to a last known good configuration. Because you update the entire system image, instead of individual software packages and configuration files, there's always a known good system image with a known state. You never wonder if some dependency was updated or not, nor if a configuration change was reversed or not. You do not worry if there was a power outage in the middle of a system update and your systems are at an undeternined state.
+
+Your worst case scenario, with image-based deployments, is either restarting the update process, as if nothing happened, or rollback to before the update and wait until central IT sends you a new system image which fixed whatever issue is preventing the update. And you can perform such rollback at any time after completing the system update, if you find out during the day that the new image is not performing as expected.
+
+[ figure of updating an image-based system and rollback to last known good]
+
+Image-based deployments are consistent with the IT trend of "shift left" security and hardening to earlier steps of the application development life cycle, and also with cloud-native trends of managing systems and applications as throwaway instances which are easy to recreate and replicate, or as "cattle" instead of "pets".