jmhbnz/workshops
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Restore disconnected workshop content.

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

55
data/windows/exercise1.mdx Normal file
View File

@ -0,0 +1,55 @@
---
title: Understanding the workshop environment
exercise: 1
date: '2024-05-26'
tags: ['openshift','windows','kubernetes','containers']
draft: false
authors: ['default']
summary: "Let's get underway with the workshop."
---
Welcome to the OpenShift Windows Containers Workshop! Here you'll have a chance to build your windows container prowess.
With a Red Hat subscription, you can get support for running Windows workloads in OpenShift Container Platform.
For this workshop you'll be given a fresh OpenShift 4 cluster which currently only runs linux containers. You will complete a series of exercises to transform the cluster to be capable to run Windows containers.
**Let's get started!**
## 1.1 - Obtaining your environment
To get underway open your web browser and navigate to the following link to reserve yourself a user https://demo.redhat.com/workshop/98b7pu. You can reserve an environment by entering any email address along with the password provided by your workshop facilitator.
<Zoom>
|![workshop](/workshops/static/images/windows/workshop.png) |
|:-----------------------------------------------------------------------------:|
| *Obtaining a workshop environment* |
</Zoom>
## 1.2 - Logging into your cluster console
After entering an email and the provided password you'll be presented with a console url and login credentials for your OpenShift cluster.
Open the console url and login.
<Zoom>
|![workshop](/workshops/static/images/windows/login.gif) |
|:-----------------------------------------------------------------------------:|
| *Obtaining a workshop environment* |
</Zoom>
## 1.3 - Logging into your bastion host
Along with the cluster web console we will also use the command line during this workshop. You've been allocated a bastion host that you can ssh to as part of step 1.1.
Follow the steps below to connect to your environment bastion host:
1. Open your preferrred terminal application.
2. Enter `ssh lab-user@<bastion-hostname>` replacing `<bastion-hostname>` with the hostname listed in your **Bastion Access** environment details page.
3. Enter `yes` if you receive a host key verification prompt. This only appears as it is the first time you have connected to this host.
4. When prompted enter the password mentioned under **Bastion Access** in your environment details page.
Congratulations, you're now ready to proceed with the next exercise 🎉.

102
data/windows/exercise2.mdx Normal file
View File

@ -0,0 +1,102 @@
---
title: Installing the windows machine config operator
exercise: 2
date: '2024-05-26'
tags: ['openshift','windows','kubernetes','containers']
draft: false
authors: ['default']
summary: "Preparing our cluster for windows machines."
---
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>
## 2.1 - Enable hybrid networking
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.
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)**.
To configure hybrid overlay networking, run the following command in your bastion host 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
}
]
}
}
}
}
}'
```
<Zoom>
|![workshop](/workshops/static/images/windows/hybrid-networking.gif) |
|:-----------------------------------------------------------------------------:|
| *Patching an OpenShift cluster network to enable hybrid networking* |
</Zoom>
## 2.2 - Install the windows machine config operator
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.
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.
```bash
oc create secret generic cloud-private-key \
--from-file=private-key.pem=${HOME}/.ssh/winkey \
--namespace openshift-windows-machine-config-operator
```
<Zoom>
|![workshop](/workshops/static/images/windows/create-secret.gif) |
|:-----------------------------------------------------------------------------:|
| *Create a private key secret* |
</Zoom>
Once your network configuration, operator installation and secret creation are complete you're ready to move on to the next exercise 🎉

135
data/windows/exercise3.mdx Normal file
View File

@ -0,0 +1,135 @@
---
title: Provisioning a windows worker node
exercise: 3
date: '2024-05-26'
tags: ['openshift','windows','kubernetes','containers']
draft: false
authors: ['default']
summary: "Auto scaling nodes with machine sets!"
---
Now that our cluster is ready to support Windows nodes lets provision one through the Machine API.
The Machine API is a combination of primary resources that are based on the upstream [Cluster API](https://github.com/kubernetes-sigs/cluster-api) project and custom OpenShift Container Platform resources.
The two primary resources are:
**1. Machines**
> A fundamental unit that describes the host for a Node. A machine has a providerSpec, which describes the types of compute nodes that are offered for different cloud platforms. For example, a machine type for a worker node on Amazon Web Services (AWS) might define a specific machine type and required metadata.
**2. MachineSets**
> Groups of machines. MachineSets are to machines as ReplicaSets are to Pods. If you need more machines or must scale them down, you change the **replicas** field on the MachineSet to meet your compute need.
## 3.1 Create a single replica machineset
In this exercise we will create a `MachineSet`. Once created this will automatically begin provisoning a Windows machine and adding it to our cluster as a worker node.
Below is a YAML snippet we will use as base to create our `MachineSet`:
```yaml
apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
name: cluster-<id>-windows-ap-southeast-<zone>
namespace: openshift-machine-api
labels:
machine.openshift.io/cluster-api-cluster: cluster-<id>
spec:
replicas: 1
selector:
matchLabels:
machine.openshift.io/cluster-api-cluster: cluster-<id>
machine.openshift.io/cluster-api-machineset: cluster-<id>-worker-ap-southeast-<zone>
template:
metadata:
labels:
machine.openshift.io/cluster-api-cluster: cluster-<id>
machine.openshift.io/cluster-api-machine-role: worker
machine.openshift.io/cluster-api-machine-type: worker
machine.openshift.io/cluster-api-machineset: cluster-<id>-worker-ap-southeast-<zone>
machine.openshift.io/os-id: Windows
spec:
lifecycleHooks: {}
metadata:
labels:
node-role.kubernetes.io/worker: ''
providerSpec:
value:
userDataSecret:
name: windows-user-data
placement:
availabilityZone: ap-southeast-<zone>
region: ap-southeast-1
credentialsSecret:
name: aws-cloud-credentials
instanceType: m5a.4xlarge
metadata:
creationTimestamp: null
blockDevices:
- ebs:
iops: 0
kmsKey: {}
volumeSize: 120
volumeType: gp2
securityGroups:
- filters:
- name: 'tag:Name'
values:
- cluster-<id>-worker-sg
kind: AWSMachineProviderConfig
metadataServiceOptions: {}
tags:
- name: kubernetes.io/cluster/cluster-<id>
value: owned
deviceIndex: 0
ami:
id: ami-0e76083a67107f741
subnet:
filters:
- name: 'tag:Name'
values:
- cluster-<id>-private-ap-southeast-<zone>
apiVersion: awsproviderconfig.openshift.io/v1beta1
iamInstanceProfile:
id: cluster-<id>-worker-profile
```
There are ten references to `<id>` in the sample that we need to find & replace with the actual cluster id for the cluster we have been allocated for the workshop and five references to the availability `<zone>` for our cluster nodes that we also need to update with our actual zone in use.
Run the following command in your bastion host terminal session to find your cluster id and zone:
```bash
name=$(oc get machineset -A -o jsonpath={.items[0].metadata.name})
echo "Cluster id is: ${name:8:11}"
echo "Cluster availability zone is: ${name:40:2}"
```
After retrieving your cluster id and zone update the sample `MachineSet` using your preferred text editor, then select and copy all of the text to clipboard.
Within OpenShift you can then click the ➕ button in the top right hand corner, paste in your yaml and click **Create**.
<Zoom>
|![workshop](/workshops/static/images/windows/create-machineset.gif) |
|:-----------------------------------------------------------------------------:|
| *Create a windows machineset* |
</Zoom>
## 3.2 Verify windows machine status
After creating the `MachineSet` a new Windows machine will be automatically provisioned and added to our OpenShift cluster, as we set our desired replicas in the YAML to `1`.
<Zoom>
|![workshop](/workshops/static/images/windows/check-machine.gif) |
|:-----------------------------------------------------------------------------:|
| *Check the status of the new windows machine* |
</Zoom>
Creating, provisioning and configuring a new Windows host can be a lengthy process taking 15-30 minutes so now is a good time to take a break ☕.
You can keep an eye on the status of your Machine in the OpenShift web console. Once it reaches the **✅ Provisioned as node** status you are ready to proceed to the next exercise.

90
data/windows/exercise4.mdx Normal file
View File

@ -0,0 +1,90 @@
---
title: Deploying a windows workload
exercise: 4
date: '2024-05-26'
tags: ['openshift','windows','kubernetes','containers']
draft: false
authors: ['default']
summary: "Putting our new cluster windows node to work 🚀"
---
With our cluster now having both Windows and Linux worker nodes, let's deploy a hybrid workload that will make use of both.
**The NetCandy Store**
You will be deploying a sample application stack that delivers an eCommerce site, The NetCandy Store. This application is built using Windows Containers working together with Linux Containers.
This application consists of:
1. Windows Container running a .NET v4 frontend, which is consuming a backend service.
2. Linux Container running a .NET Core backend service, which is using a database.
3. Linux Container running a MSSql database 🤯.
<Zoom>
|![workshop](/workshops/static/images/windows/mixed-workloads.png) |
|:-----------------------------------------------------------------------------:|
| *Mixed workload architecture diagram* |
</Zoom>
## 4.1 Add helm repository
In this exercise we will deploy the NetCandy Store application using `helm`. You can deliver your Windows workloads in the same way you deliver your Linux workloads. Since everything is just YAML, the workflow is the same. Whether that be via Helm, an Operator, or via Ansible.
We'll get started by creating a project and adding a helm repository that our application helm chart will be sourced from.
Follow the steps below to add the repository:
1. Switch from **Administrator** to **Developer** view in the top left web console dropdown menu.
2. Click on **+Add** in the left menu.
3. Click on the **Project** dropdown at the top and click **Create Project**
4. Enter the name `netcandystore` and click **Create**.
5. Click on **Helm Chart repositories**.
6. Enter the name `redhat-demos` and url `https://redhat-developer-demos.github.io/helm-repo` then click **Create**.
This will allow us to deploy any helm charts available in this repository.
<Zoom>
|![workshop](/workshops/static/images/windows/add-helm-repo.gif) |
|:-----------------------------------------------------------------------------:|
| *Creating a project and adding a helm repository* |
</Zoom>
## 4.2 Deploy candystore helm chart
With our helm chart repository added, let's deploy our application! This is as simple as following the three steps below to create a helm release.
1. Search for `candy` on the **Helm charts** screen.
2. Click on **Netcandystore** and then click **Create**.
3. Review the chart settings and click **Create** once more.
<Zoom>
|![workshop](/workshops/static/images/windows/deploy-application.gif) |
|:-----------------------------------------------------------------------------:|
| *Create mixed archiecture application via helm* |
</Zoom>
> Note: The application can take a few minutes to complete deploying, time for another coffee ☕.
## 4.3 Review deployed windows application
After creating our helm release we can see the status of the application from the **Topology** screen in the **Developer** view.
We can verify our Windows Container is running by:
1. Clicking on the **netcandystore** frontend Windows Container.
2. Selecting the **Resources** tab on the right hand panel and clicking on the pod name.
3. Clicking the **Terminal** tab and verifying that a Windows command prompt displays.
4. Returning to the **Topology** screen and opening the URL for the **netcandystore** application to confirm the application is running.
> Note: You may need to change from `https://` to `http://` in your browser address bar when opening the application URL as some browsers now automatically attempt to redirect to HTTPS, however this application route is currently only served as HTTP.
<Zoom>
|![workshop](/workshops/static/images/windows/confirm-application.gif) |
|:-----------------------------------------------------------------------------:|
| *Confirm Windows container status* |
</Zoom>
Congratulations! You've taken an existing OpenShift 4 cluster, set it up for running Windows workloads, then deployed a Windows app 🎉.