// Module included in the following assemblies:
//
// windows_containers/enabling-windows-container-workloads.adoc

:_mod-docs-content-type: CONCEPT
[id="wmco-disconnected-cluster_{context}"]
= Using Windows containers with a mirror registry

[role="_abstract"]
When using the Windows Machine Config Operator (WMCO), your Windows workloads can pull images from a registry mirror rather than from a public registry by using an `ImageDigestMirrorSet` (IDMS) or `ImageTagMirrorSet` (ITMS) object to configure your cluster to pull images from the mirror registry.

A mirror registry has the following benefits: 

* Avoids public registry outages 
* Speeds up node and pod creation
* Pulls images from behind your organization's firewall

A mirror registry can also be used with a {product-title} cluster in a disconnected, or air-gapped, network. A _disconnected network_ is a restricted network without direct internet connectivity. Because the cluster does not have access to the internet, any external container images cannot be referenced.

Using a mirror registry requires the following general steps:

* Create the mirror registry, using a tool such as {quay}.
* Create a container image registry credentials file.
* Copy the images from your online image repository to your mirror registry.

For information about these steps, see "About disconnected installation mirroring."

After creating the mirror registry and mirroring the images, you can use an `ImageDigestMirrorSet` (IDMS) or `ImageTagMirrorSet` (ITMS) object to configure your cluster to pull images from the mirror registry without needing to update each of your pod specs. The IDMS and ITMS objects redirect requests to pull images from a repository on a source image registry and have it resolved by the mirror repository instead. 

If changes are made to the IDMS or ITMS object, the WMCO automatically updates the appropriate `hosts.toml` file on your Windows nodes with the new information. Note that the WMCO sequentially updates each Windows node when mirror settings are changed. As such, the time required for these updates increases with the number of Windows nodes in the cluster.

Because Windows nodes configured by the WMCO rely on the containerd container runtime, the WMCO ensures that the containerd configuration files are up-to-date with the registry settings. For new nodes, these files are copied to the instances upon creation. For existing nodes, after activating the mirror registry, the registry controller uses SSH to access each node and copy the generated configuration files, replacing any existing files.

You can use a mirror registry with machine set or Bring-Your-Own-Host (BYOH) Windows nodes.

When using an IDMS or ITMS object to mirror container images on Windows nodes, take note of the following behaviors that differ from Linux nodes:

* Mirroring on Windows nodes works on the registry level, rather than on the image level used by Linux nodes. As such, Windows images mirrored by using IDMS or ITMS objects have specific naming requirements. 
+
--
include::snippets/wmco-mirror-naming-requirements.adoc[]
--

* A Windows node takes the ITMS object and uses it to configure registry-wide mirrors. In the following example, configuring `quay.io/remote-org/image` to mirror to `quay.io/my-org/image` results in the Windows node using that mirror for all images from `quay.io/remote-org`. As such, `quay.io/remote-org/image:tag` uses the `quay.io/my-org/image:tag` image, as expected, but another container using `quay.io/remote-org/different-image:tag`
would also try to use the `quay.io/remote-org/different-image:tag` mirror. This can cause unintended behavior if it is not accounted for.
+
For this reason, specify container images using a digest by an IDMS object instead of an ITMS object. Using a digest can prevent the wrong container image from being used, by ensuring that the image the container specifies and the image being pulled have the same digest.
