Skip to content

Commit

Permalink
quick cleanup on appendix
Browse files Browse the repository at this point in the history
  • Loading branch information
@johnsimcall
johnsimcall committed May 2, 2024
1 parent 0db1a96 commit 44097a1
Show file tree
Hide file tree
Showing 3 changed files with 122 additions and 55 deletions.
133 changes: 100 additions & 33 deletions content/modules/ROOT/pages/appendix01.adoc
View file
Original file line number Diff line number Diff line change
@@ -1,5 +1,93 @@
= Appendix: Lab Details

== Pull Secrets

A **_pull secret_** is JSON-formated data that combines authentication information for one or more Image Registries into a single file.
You can find your own _pull secret_ in the https://console.redhat.com/openshift/install/pull-secret[Red Hat Hybrid Cloud Console,window=_blank].

Connected cluster's, and systems that use `oc-mirror` to download the OpenShift installation images, are required to have valid authentication for the quay.io registry. The other registries in your __pull secret__ allow your OpenShift cluster to build a sample application catalog for your developers, fetch official content from Red Hat, and participate in the Insight monitoring service.

The __pull secret__ of a disconnected cluster is only required to have authentication details for the `mirror-registry` and any other registries that your applications depend upon.

OpenShift provides a __global pull secret__, and allows individual `namespaces` / projects to create their own __pull secrets__. It is not allowed to have multiple authentication for a single registry (e.g. defined in the __global__ and __namespaced pull secrets__.)

The `jq` tool makes it easy to inspect and reformat the contents of a __pull secret__.
And you can add and remove entries in a __pull secret__ using `podman`.

[.lowside,source,bash,role=execute,subs="attributes"]
----
jq . ~/.docker/config.json
----
[.output]
----
{
"auths": {
"cloud.openshift.com": {
"auth": "dXNlcm5hbWU6cGFzc3dvcmQ=",
"email": "groovy@disco.lab"
},
"quay.io": {
"auth": "dXNlcm5hbWU6cGFzc3dvcmQ=",
"email": "groovy@disco.lab"
},
"registry.connect.redhat.com": {
"auth": "dXNlcm5hbWU6cGFzc3dvcmQ=",
"email": "groovy@disco.lab"
},
"registry.redhat.io": {
"auth": "dXNlcm5hbWU6cGFzc3dvcmQ=",
"email": "groovy@disco.lab"
}
}
}
----

[TIP]
--
The __"auth"__ string is base64-encoded data.
If you decode the string you will see that it says `username:password`
--

The `install-config.yaml` file doesn't allow multi-line __pull secrets__.
You can collapse / condense / compact multi-line JSON with `jq -c`

[.highside,source,bash,role=execute,subs="attributes"]
----
cat /run/user/1001/containers/auth.json
jq -c . /run/user/1001/containers/auth.json
----
[.output]
----
{
"auths": {
"mirror-registry.disco.lab:8443": {
"auth": "aW5pdDpkaXNjb3Bhc3M="
}
}
}
{"auths":{"mirror-registry.disco.lab:8443":{"auth":"aW5pdDpkaXNjb3Bhc3M="}}}
----

Add and remove __pull secret_ entries using `podman`

[.highside,source,bash,role=execute,subs="attributes"]
----
podman login mirror-registry.disco.lab:8443
podman logout mirror-registry.disco.lab:8443
----
[.output]
----
Username: init
Password: discopass
Login Succeeded!
Removed login credentials for ip-10-0-52-200.us-west-2.compute.internal:8443
----


== Two ways to `oc-mirror` - Partially Disconnected -vs Fully Disconnected
The `oc-mirror` plugin supports two mirroring scenarios.

Expand All @@ -16,25 +104,7 @@ Another instance of `oc-mirror` will open the .tar file and upload the contents
This is documented as a https://docs.openshift.com/container-platform/4.15/installing/disconnected_install/installing-mirroring-disconnected.html#mirroring-image-set-full[fully disconnected environment,window=_blank].


== Creating an Air Gap

According to the https://www.rfc-editor.org/rfc/rfc4949[Internet Security Glossary], an Air Gap is an interface between two systems at which (a) they are not connected physically and (b) any logical connection is not automated (i.e., data is transferred through the interface only manually, under human control).
In disconnected installations, the air gap exists between the Low Side and the High Side, so it is between these systems where a manual data transfer, or *sneaker net* is required.

== Preparing the Low Side

A disconnected installation begins with downloading content and tooling to a system we will refer to as the *jump* that has outbound access to the Internet.
This server resides in a network environment commonly referred to as the *Low Side* due to its low security profile.
Compliance requirements usually prevent the low side from housing sensitive data or private information.

== Preparing the High Side

We then provision a system we refer to as *highside* which has no Internet access and resides in a network environment commonly referred to as the *High Side* due to its high security profile.
It is in the high side where sensitive data and production systems (like the cluster we're about to provision) live.
During this phase, we'll transfer the content and tooling from the low side to the high side, a process which may entail use of a VPN or physical media like a DVD or USB.
Once our transfer is complete, we'll start a *mirror registry* on the highside system which will supply the container images needed for our OpenShift installation, since our installer can't reach out to quay.io or registry.redhat.io directly from here.

=== Proxy
== Proxy

The high side protects outbound traffic with a http://www.squid-cache.org/[Squid proxy] running on the `nat system`.
The `nat system / proxy` prevents any egress traffic not listed in its `/etc/squid/whitelist.txt` file.
Expand All @@ -57,13 +127,21 @@ There may be situations where you wish to add more exceptions here, such as cont
Now that our air gap is in place, let's start prepping the low side.


== Preparing the Installation
== `openshift-install` details

The OpenShift installation process is initiated from the *highside* server.
There are a handful of different ways to install OpenShift, but for this lab we're going to be using installer-provisioned infrastructure (IPI).
By default, the installation program acts as an installation wizard, prompting you for values that it cannot determine on its own and providing reasonable default values for the remaining parameters.
We'll then customize the `install-config.yaml` file that is produced to specify advanced configuration for our disconnected installation.
The installation program then provisions the underlying infrastructure for the cluster.
After the wizard portion of `openshift-install` completes, you then customize the `install-config.yaml` file that was produced to specify the disconnected pieces.
With the standard values and the disconnected values added to the `install-config.yaml` file, `openshift-install` can automatically provisions the underlying infrastructure for the cluster.

Examples of the __underlying infrastructure__ include:

* Virtual Machines / Cloud instances
* DNS records
* Firewall / Security Groups
* Load Balancers
* IAM permissions that allow the cluster to scale and self-heal

[TIP]
You may notice that nodes are provisioned through a process called _Ignition_.
Expand All @@ -82,14 +160,3 @@ Once configuration has been completed, we can kick off the OpenShift Installer a
Here's a diagram describing everything we've discussed so far:

image::disco-1.svg[disco diagram,800]

== Accessing the Cluster

Since the cluster we'll produce is in a disconnected environment, it won't be publicly accessible via the Internet.
In many cases, cluster access is restricted to hosts that reside in the high side network.
In our lab, we'll use the *jump* system to access the cluster running in the high side network.

== Planning Ahead

Once the cluster is up, what comes next?
This lab ends when the cluster is installed, but there are many more considerations to made for how you manage things like upgrades, operators, patches, and more.
2 changes: 1 addition & 1 deletion content/modules/ROOT/pages/lab02.adoc
View file
Original file line number Diff line number Diff line change
Expand Up @@ -161,7 +161,7 @@ Now that the mirroring and installation tools have been downloaded and extacted,
A **_pull secret_** is JSON-formated data that combines authentication information for one or more Image Registries into a single file.
You can find your own _pull secret_ in the https://console.redhat.com/openshift/install/pull-secret[Red Hat Hybrid Cloud Console,window=_blank].

More information about _pull secrets_ can be found in the xref:appendix01.adoc[Appendix].
More information about _pull secrets_ can be found in the xref:appendix01.adoc#pull-secrets[Appendix].

This workshop provides a generic _pull secret_ in order to avoid delays and frustrations using `vi` or `nano`.
--
Expand Down
42 changes: 21 additions & 21 deletions content/modules/ROOT/pages/lab05.adoc
View file
Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@
= Logging in to your OpenShift Cluster
= Post-Install Configuration

**Congratulations** you've successfully created an OpenShift cluster in a disconnected environment!

Expand All @@ -7,17 +7,20 @@
Or, perhaps, your cluster will finish installing in the next ~30 minutes. 😸

Don't worry!
Your workshop environment also includes a previously-built disconnected **Salsa** cluster.
Your workshop environment also includes a previously-built disconnected **Salsa cluster**.
You can complete this lab using either cluster.

image::disco-4.svg[disco diagram,800]

//TODO - more highlighting for the [.salsa] objects???

== Are we done yet?

Installing OpenShift in a disconnected environment concludes the "day 1" tasks.
Installing OpenShift in a disconnected environment concludes the __"day 1"__ tasks.
However, a disconnected cluster is more useful when you make a few simple configuration changes.
These are commonly referred to as "day 2" tasks.
These are commonly referred to as __"day 2"__ tasks.

Here are a few suggested "day 2" tasks that will improve your experience.
Here are a few suggested __"day 2"__ tasks that will improve your experience.

{counter:overview}. Disable the default app / Operator `CatalogSources`

Expand All @@ -27,7 +30,8 @@ Here are a few suggested "day 2" tasks that will improve your experience.

{counter:overview}. Update OpenShift from a disconnected _Update Server_

* You may not have enough time in the Summit 2024 lab break-out to complete this task
[INFO]
You may not have enough time during the Summit 2024 lab session to complete the __Update Server__ task.

== Accessing your cluster

Expand Down Expand Up @@ -60,12 +64,12 @@ Password: fKLcS-EuJDs-SfrVD-nbbvA
--
The pre-built **salsa.lab** cluster credentials are `admin` / `admin`.

There is also a non-admin user available with `user` / `user`.
There is also a non-admin user available as `user` / `user`.
--

Now you can click the *Desktop* button on the right-hand side and use Firefox to login to the OpenShift __Web Console__.
The __Web Console__ is the very last part of OpenShift to come online.
If you are trying to connect to your [.highside]#disco.lab# cluster, and see an "**Application is not available**" message, it means the installation has completed yet.
If you are trying to connect to your [.highside]#disco.lab# cluster, and see an "**Application is not available**" message, it means the installation hasn't completed yet.

Your workshop environment includes a Firefox bookmark to quickly connect with the __Web Console__.

Expand Down Expand Up @@ -98,23 +102,19 @@ svc/kubernetes - 172.30.0.1:443 -> 6443
View details with 'oc describe <resource>/<name>' or list resources with 'oc get all'.
----

There's much work to be done after the initial installation.
As a cluster administrator, you need to be mindful of how to manage operators, upgrades, patching, configuration, and much more.
Now that you're logged in via the command-line or the _Web Console_ we can proceed with the __"day 2"__ tasks.


== Post-Install Cluster Configuration
== Post-Install Cluster Configurations

Now that we have a cluster up and running (or we are using the pre-made salsa.lab cluster) we can perform some
post-install steps that are specific to a disconnected environment.

image::disco-4.svg[disco diagram,800]

First, lets log in to our cluster

[cols="a,a",options="header"]
|===
| Using the pre-baked `salsa.lab`
| Using the lab-provisioned `disco.lab`
| Using the pre-built `salsa.lab` cluster
| Using your own `disco.lab` cluster

**Note to self** - do we want to use `ssh`? I would suggest doing `oc login` from the [.lowside]#jump system#.

|
[source,bash,role=execute]
Expand All @@ -137,12 +137,12 @@ oc login https://api.disco.lab:6443
* *Password:* admin
|===

== Add our custom catalog source
=== Add our custom catalog source
// https://docs.openshift.com/container-platform/4.14/installing/installing_aws/installing-restricted-networks-aws-installer-provisioned.html#olm-restricted-networks-operatorhub_installing-restricted-networks-aws-installer-provisioned

TODO

== Deploy a operator
=== Deploy a operator

TODO

Expand All @@ -152,6 +152,6 @@ TODO
// == Remove default samples operator
// https://docs.openshift.com/container-platform/4.14/openshift_images/configuring-samples-operator.html#configuring-samples-operator

== Update cluster
=== Update cluster

TODO

0 comments on commit 44097a1

Please sign in to comment.