Ask an OpenShift Admin Office Hour - Disconnected deep dive

What is a disconnected OpenShift installation and why would you need one? Disconnected installations of OpenShift are used when the OpenShift cluster is not connected to the Internet, but there are a few other differences that come into play as well. 

During this stream, we discuss and show how to mirror images and disconnected Operators, and learn whether a cluster actually needs to be disconnected to install disconnected. We'll also examine the ImageContentSourcePolicy and how to reconnect a detached cluster. All of this culminates in doing a disconnected single-node OpenShift (SNO) deployment using a static IP!

If you’ve been curious about disconnected and how it works, then this is the stream for you!

During the stream we showed a lot of CLI commands. If you want to recreate the process we followed, you can see all of the commands in this GitHub Gist. We used this Gist for some steps on how to deploy single node OpenShift.

As always, please see the list below for additional links to specific topics, questions, and supporting materials for the episode!

If you’re interested in more streaming content, please subscribe to the Red Hat livestreaming calendar to see the upcoming episode topics and to receive any schedule changes. If you have questions or topic suggestions for the Ask an OpenShift Admin Office Hour, please contact us via Discord, Twitter, or come join us live, Wednesdays at 11am EDT / 1500 UTC, on YouTube and Twitch.

Episode 48 recorded stream:

Use this link to jump directly to where we start talking about today’s topic. 

This week’s top of mind topics:

• Did you notice that the docs interface has changed recently? They made some significant changes to navigation which make it much easier to find where you want to go in the docs.
• OpenShift Service Mesh 2.1 was recently released as generally available. This added many new features and fixes - if you’re a Service Mesh user, or think it might be useful for you - please give the blog post a read.
• Another important feature of OpenShift recently celebrated another release: OpenShift Virtualization 4.9! There’s many changes and updates here, we talked about a few of them during the stream, but get the full details from the blog post!

Questions answered and topics discussed during the stream:

• We talked about disconnected before, in episode 13, if you want to go back and see the state of things a year ago it’s a great episode to watch!
• A viewer asked about the difference between full support and maintenance support for OpenShift releases. We talked about this during the stream, including reviewing the lifecycle page and the recent changes to the EUS policy for OpenShift releases.
• The first step to a disconnected install is to mirror the images. We review the documentation, begin our demo, and get hands on at this point during the stream.
• The first step to mirroring the images is to do a dry run. The dry run will tell us, among other things, the amount of storage we need for the images and provide the ImageContentSourcePolicy to be used with the disconnected cluster. The bash script we used can be viewed here.
• The second step is to mirror the images from quay.io to your local disk. This process will probably take some time depending on the speed of your network and storage. You can view the bash script we used here.
• Before moving the OpenShift images to the disconnected network, there are a few other tools and binaries you’ll want to download. We discuss them here, but they include things like the RHCOS images and CLI tools.
• One of our viewers asked about a built-in registry in future installers. There won’t be anything integrated into the installer, but there are some plans on the horizon to simplify the mirroring process using OpenShift Mirror Registry. This isn’t ready for production use yet, but we’ll be sure to feature it on the stream when it is!
• After moving the data to the disconnected network, we’ll need a registry instance to upload the images to. During the stream we discuss some options, including using Docker registry with certificates signed by the organization so that we can secure and verify the endpoints.
• With the data on the disconnected network and a registry available for us to use, we can upload the images so that they can be used by OpenShift during the install process. The bash script we used to show this process can be seen here.
• With the images uploaded, we’re ready to start the install process. This is, more or less, the same as a “connected” install, but we need to provide the ImageContentSourcePolicy and, if needed, the CA bundle for the registry’s certificate in the install-config.yaml. We review the contents of the install-config.yaml here during the stream.
• During the stream we’re doing a single node OpenShift (SNO) installation with a static IP. If you’re curious about how that’s done, we go into detail about it here.
• Starting at this point during the stream, we follow the steps for doing a SNO deployment from this gist. We did make some modifications, discussed previously, for disconnected, but the overall process is the same.
• Installing SNO with a static IP address means that we need to provide the network configuration information at boot time. We do this during the stream, including appending the kernel parameters and allowing it to boot normally after that. Remember that there is an additional setting used in the install-config.yaml to persist those IP settings to the installed node too.
• Once the install process kicks off, we verify that it’s retrieving the images from the disconnected registry and use the standard “wait-for bootstrap-complete” method to monitor the install progress.
• We also connect directly to the node to monitor and review the install process here. Jonny shares some great insight into what’s happening and how to troubleshoot different aspects of the install during this segment.
• While the install proceeds, we move on to mirroring Operator catalogs. Just as with the install image mirroring process, we start by reviewing the documentation.
• Pruning the catalog is an important step to reduce the amount of data that needs to be mirrored. We show how to do the pruning here.
• Once the catalog has been pruned and the images mirrored, we need to import them the same as before. The output of the previous commands will also include the CatalogSource and ImageContentSourcePolicy objects needed for the disconnected cluster to access the mirrored resources.
• ImageContentSourcePolicy objects modify each of the RHCOS nodes’ registries.conf file to redirect image pulls. If you’re interested to see what that looks like, see here in the stream.