Restore disconnected workshop content.

Signed-off-by: James Blair <mail@jamesblair.net>
This commit is contained in:
2024-05-29 11:54:45 +12:00
parent 4f225728ba
commit 9769fefa79
9 changed files with 1005 additions and 262 deletions

View File

@ -1,102 +1,214 @@
---
title: Installing the windows machine config operator
title: Preparing our low side
exercise: 2
date: '2024-05-26'
tags: ['openshift','windows','kubernetes','containers']
date: '2023-12-18'
tags: ['openshift','containers','kubernetes','disconnected']
draft: false
authors: ['default']
summary: "Preparing our cluster for windows machines."
summary: "Downloading content and tooling for sneaker ops 💾"
---
A disconnected OpenShift installation begins with downloading content and tooling to a prep system that has outbound access to the Internet. This server resides in an environment commonly referred to as the **Low side** due to its low security profile.
In this first hands on excercise we will prepare our cluster for running Windows nodes by installing an operator and configuring it.
[Operators](https://docs.openshift.com/container-platform/4.15/operators/index.html) are among the most important components of OpenShift Container Platform. Operators are the preferred method of packaging, deploying, and managing additional cluster services or application.
To install Operators on OpenShift we use Operator Hub. A simplistic way of thinking about Operator Hub is as the "App Store" for your OpenShift cluster.
<Zoom>
|![workshop](/workshops/static/images/windows/operator-hub.png) |
|:-----------------------------------------------------------------------------:|
| *OpenShift Operator Hub* |
</Zoom>
In this exercise we will be creating a new [AWS ec2 instance](https://aws.amazon.com/ec2) in our **Low side** that we will carry out all our preparation activities on.
## 2.1 - Enable hybrid networking
## 2.1 - Creating a security group
Before installing the windows machine config operator our first step as a cluster administrator is configure a our OpenShift cluster network to allow Linux and Windows nodes to host Linux and Windows workloads, respectively.
We'll start by creating an [AWS security group](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html) and collecting its ID.
This requires enabling a feature called **[hybrid overlay networking](https://docs.openshift.com/container-platform/4.15/networking/ovn_kubernetes_network_provider/configuring-hybrid-networking.html#configuring-hybrid-ovnkubernetes)**.
We're going to use this shortly for the **Low side** prep system, and later on in the workshop for the **High side** bastion server.
To configure hybrid overlay networking, run the following command in your bastion host terminal:
Copy the commands below into your web terminal:
```bash
oc patch networks.operator.openshift.io cluster --type=merge \
-p '{
"spec":{
"defaultNetwork":{
"ovnKubernetesConfig":{
"hybridOverlayConfig":{
"hybridClusterNetwork":[
{
"cidr": "10.132.0.0/14",
"hostPrefix": 23
}
]
}
}
}
}
}'
# Obtain vpc id
VPC_ID=$(aws ec2 describe-vpcs | jq '.Vpcs[] | select(.Tags[].Value=="disco").VpcId' -r)
echo "Virtual private cloud id is: ${VPC_ID}"
# Obtain first public subnet id
PUBLIC_SUBNET=$(aws ec2 describe-subnets | jq '.Subnets[] | select(.Tags[].Value=="Public Subnet - disco").SubnetId' -r)
# Create security group
aws ec2 create-security-group --group-name disco-sg --description disco-sg --vpc-id ${VPC_ID} --tag-specifications "ResourceType=security-group,Tags=[{Key=Name,Value=disco-sg}]"
# Store security group id
SG_ID=$(aws ec2 describe-security-groups --filters "Name=tag:Name,Values=disco-sg" | jq -r '.SecurityGroups[0].GroupId')
echo "Security group id is: ${SG_ID}"
```
<Zoom>
|![workshop](/workshops/static/images/windows/hybrid-networking.gif) |
|![workshop](/workshops/static/images/disconnected/security-group.gif) |
|:-----------------------------------------------------------------------------:|
| *Patching an OpenShift cluster network to enable hybrid networking* |
| *Creating aws ec2 security group* |
</Zoom>
## 2.2 - Install the windows machine config operator
## 2.2 - Opening ssh port ingress
If you have a running OpenShift cluster and have enabled hybrid overlay networking, you can then install the optional **Windows Machine Config Operator**. This operator will configure any Windows machines we add to the cluster, enabling Windows container workloads to be run within your OpenShift cluster.
We will want to login to our soon to be created **Low side** aws ec2 instance remotely via `ssh` so let's enable ingress on port `22` for this security group now:
Windows instances can be added either by creating a `MachineSet`, or by specifying existing instances through a `ConfigMap`. The operator will do all the necessary steps to configure the instance so that it can join the cluster as a worker node.
Follow the steps below to install the operator:
1. Navigate to **Operators** > **OperatorHub** in the left menu.
2. Search for `Windows`.
3. Click on **Windows Machine Config Operator** provided by Red Hat and click **Install**.
4. Leave all settings as the default and click **Install** once more.
<Zoom>
|![workshop](/workshops/static/images/windows/operator-install.gif) |
|:-----------------------------------------------------------------------------:|
| *Installing the windows machine config operator* |
</Zoom>
> Note: The operator installation may take several minutes to complete. Wait for the status of `✅ succeeded` before continuing with the following step.
>
## 2.3 - Create configuration secrets
The windows machine config operator expects a secret to be present in its namespace called `cloud-private-key` containing a private key. This private key will be used to log into the soon to be provisioned Windows machine and set it up as an OpenShift node.
Run the commands below from your bastion host to create the required secret.
1. Generate a new ssh key with `ssh-keygen -t rsa -f ${HOME}/.ssh/winkey -q -N ''`
2. Run the command below to create the required secret from the public key you just created.
> Note: We're going to allow traffic from all sources for simplicity (`0.0.0.0/0`), but this is likely to be more restrictive in real world environments:
```bash
oc create secret generic cloud-private-key \
--from-file=private-key.pem=${HOME}/.ssh/winkey \
--namespace openshift-windows-machine-config-operator
aws ec2 authorize-security-group-ingress --group-id $SG_ID --protocol tcp --port 22 --cidr 0.0.0.0/0
```
<Zoom>
|![workshop](/workshops/static/images/windows/create-secret.gif) |
|![workshop](/workshops/static/images/disconnected/ssh-port-ingress.gif) |
|:-----------------------------------------------------------------------------:|
| *Create a private key secret* |
| *Opening ssh port ingress* |
</Zoom>
Once your network configuration, operator installation and secret creation are complete you're ready to move on to the next exercise 🎉
## 2.3 - Create prep system instance
Ready to launch! 🚀 We'll use the `t3.micro` instance type, which offers `1GiB` of RAM and `2` vCPUs, along with a `50GiB` storage volume to ensure we have enough storage for mirrored content:
> Note: As mentioned in [OpenShift documentation](https://access.redhat.com/documentation/en-us/openshift_container_platform/4.14/html/installing/disconnected-installation-mirroring) about 12 GB of storage space is required for OpenShift Container Platform 4.14 release images, or additionally about 358 GB for OpenShift Container Platform 4.14 release images and all OpenShift Container Platform 4.14 Red Hat Operator images.
Run the command below in your web terminal to launch the instance. We will specify an Amazon Machine Image (AMI) to use for our prep system which for this lab will be the [Marketplace AMI for RHEL 8](https://access.redhat.com/solutions/15356#us_east_2) in `us-east-2`.
```bash
aws ec2 run-instances --image-id "ami-092b43193629811af" \
--count 1 --instance-type t3.micro \
--key-name disco-key \
--security-group-ids $SG_ID \
--subnet-id $PUBLIC_SUBNET \
--associate-public-ip-address \
--tag-specifications "ResourceType=instance,Tags=[{Key=Name,Value=disco-prep-system}]" \
--block-device-mappings "DeviceName=/dev/sdh,Ebs={VolumeSize=50}"
```
<Zoom>
|![workshop](/workshops/static/images/disconnected/launch-prep-ec2.gif) |
|:-----------------------------------------------------------------------------:|
| *Launching a prep rhel8 ec2 instance* |
</Zoom>
## 2.4 - Connecting to the low side
Now that our prep system is up, let's `ssh` into it and download the content we'll need to support our install on the **High side**.
Copy the commands below into your web terminal. Let's start by retrieving the IP for the new ec2 instance and then connecting via `ssh`:
> Note: If your `ssh` command times out here, your prep system is likely still booting up. Give it a minute and try again.
```bash
PREP_SYSTEM_IP=$(aws ec2 describe-instances --filters "Name=tag:Name,Values=disco-prep-system" | jq -r '.Reservations[0].Instances[0].PublicIpAddress')
echo $PREP_SYSTEM_IP
ssh -i disco_key ec2-user@$PREP_SYSTEM_IP
```
<Zoom>
|![workshop](/workshops/static/images/disconnected/connect-prep-ec2.gif) |
|:-----------------------------------------------------------------------------:|
| *Connecting to the prep rhel8 ec2 instance* |
</Zoom>
## 2.5 - Downloading required tools
For the purposes of this workshop, rather than downloading mirror content to a USB drive as we would likely do in a real SneakerOps situation, we will instead be saving content to an EBS volume which will be mounted to our prep system on the **Low side** and then subsequently synced to our bastion system on the **High side**.
Once your prep system has booted let's mount the EBS volume we attached so we can start downloading content. Copy the commands below into your web terminal:
```bash
sudo mkfs -t xfs /dev/nvme1n1
sudo mkdir /mnt/high-side
sudo mount /dev/nvme1n1 /mnt/high-side
sudo chown ec2-user:ec2-user /mnt/high-side
cd /mnt/high-side
```
With our mount in place let's grab the tools we'll need for the bastion server - we'll use some of them on the prep system too. Life's good on the low side; we can download these from the internet and tuck them into our **High side** gift basket at `/mnt/high-side`.
There are four tools we need, copy the commands into your web terminal to download each one:
1. `oc` OpenShift cli
```bash
curl https://mirror.openshift.com/pub/openshift-v4/clients/ocp/stable/openshift-client-linux.tar.gz -L -o oc.tar.gz
tar -xzf oc.tar.gz oc && rm -f oc.tar.gz
sudo cp oc /usr/local/bin/
```
2. `oc-mirror` oc plugin for mirorring release, operator, and helm content
```bash
curl https://mirror.openshift.com/pub/openshift-v4/clients/ocp/stable/oc-mirror.tar.gz -L -o oc-mirror.tar.gz
tar -xzf oc-mirror.tar.gz && rm -f oc-mirror.tar.gz
chmod +x oc-mirror
sudo cp oc-mirror /usr/local/bin/
```
3. `mirror-registry` small-scale Quay registry designed for mirroring
```bash
curl https://mirror.openshift.com/pub/openshift-v4/clients/mirror-registry/latest/mirror-registry.tar.gz -L -o mirror-registry.tar.gz
tar -xzf mirror-registry.tar.gz
rm -f mirror-registry.tar.gz
```
4. `openshift-installer` The OpenShift installer cli
```bash
curl https://mirror.openshift.com/pub/openshift-v4/clients/ocp/stable/openshift-install-linux.tar.gz -L -o openshift-installer.tar.gz
tar -xzf openshift-installer.tar.gz openshift-install
rm -f openshift-installer.tar.gz
```
<Zoom>
|![workshop](/workshops/static/images/disconnected/download-tools.gif) |
|:-----------------------------------------------------------------------------:|
| *Downloading required tools with curl* |
</Zoom>
## 2.6 - Mirroring content to disk
The `oc-mirror` plugin supports mirroring content directly from upstream sources to a mirror registry, but since there is an air gap between our **Low side** and **High side**, that's not an option for this lab. Instead, we'll mirror content to a tarball on disk that we can then sneakernet into the bastion server on the **High side**. We'll then mirror from the tarball into the mirror registry from there.
> Note: A pre-requisite for this process is an OpenShift pull secret to authenticate to the Red Hat registries. This has already been created for you to avoid the delay of registering for individual Red Hat accounts during this workhop. You can copy this into your newly created prep system by running `scp -pr -i disco_key .docker ec2-user@$PREP_SYSTEM_IP:` in your web terminal. In a real world scenario this pull secret can be downloaded from https://console.redhat.com/openshift/install/pull-secret.
Let's get started by generating an `ImageSetConfiguration` that describes the parameters of our mirror. Run the command below to generate a boilerplate configuration file, it may take a minute:
```bash
oc mirror init > imageset-config.yaml
```
> Note: You can take a look at the default file by running `cat imageset-config.yaml` in your web terminal. Feel free to pause the workshop tasks for a few minutes and read through the [OpenShift documentation](https://docs.openshift.com/container-platform/4.14/updating/updating_a_cluster/updating_disconnected_cluster/mirroring-image-repository.html#oc-mirror-creating-image-set-config_mirroring-ocp-image-repository) for the different options available within the image set configuration.
To save time and storage, we're going to remove the operator catalogs and mirror only the release images for this workshop. We'll still get a fully functional cluster, but OperatorHub will be empty.
To complete this, remove the operators object from your `imageset-config.yaml` by running the command below in your web terminal:
```
cat << EOF > imageset-config.yaml
kind: ImageSetConfiguration
apiVersion: mirror.openshift.io/v1alpha2
storageConfig:
local:
path: ./
mirror:
platform:
channels:
- name: stable-4.14
type: ocp
additionalImages:
- name: registry.redhat.io/ubi8/ubi:latest
helm: {}
EOF
```
Now we're ready to kick off the mirror! This can take 5-15 minutes so this is a good time to go grab a coffee or take a short break:
> Note: If you're keen to see a bit more verbose output to track the progress of the mirror to disk process you can add the `-v 5` flag to the command below.
```bash
oc mirror --config imageset-config.yaml file:///mnt/high-side
```
Once your content has finished mirroring to disk you've finished exercise 2! 🎉