Announcing: New Registry UX and Test Workflows

The Replicated Proxy Registry provides a performant, secure way for vendors to distribute images to their end customers without needing to push images to multiple locations or perform out-of-band credential management for end users. It could be described as an “Authenticating Mirror” that takes a license file from an end customer, validates the license, and dynamically replaces the HTTP Authentication header with vendor-configured registry credentials. The proxy registry then proxies that request upstream to wherever an application’s images are stored securely.

You may have seen image paths like [.inline] proxy.replicated.com/proxy/my-kots-app/quay.io/my-org/api [.inline] in Replicated applications - these will be translated to [.inline] quay.io/my-org/api [.inline] by the proxy, as long as the license key sent for authentication is valid, and the vendor has configured a single credential set for quay.io in the Replicated vendor portal. If you’re using the recent Custom Domains feature, you may see a path like [.inline] images.myapp.com [.inline] instead of [.inline] proxy.replicated.com [.inline].

 Today, we’re announcing new updates to the Proxy Registry experience that will allow for:

1. Testing of configured registries directly in the vendor portal
2. Easier configuration of different registry types

Registry Testing

Until the launch of the new registry workflow, the only way to test a registry once it was configured was to go through a lengthy feedback loop of:

1. Connect the registry in the vendor portal
2. Create a release referencing an image in the registry
3. Promote that release to a channel
4. Install that new release into a development customer/instance environment
5. Inspect the application status and verify there are no “ErrImagePull” or “ImagePullBackoff” events.

‍

Furthermore, when the upstream registry was configured incorrectly, errors were not always propagated down to the kubelet/CRI client pulling the image. For example, authentication or rate limit errors could sometimes be swallowed by generic HTTP 500 errors. This difficulty in debugging, coupled with the long feedback loop, made it difficult to configure and test these registry integrations. We’ve now tightened this feedback loop by adding testing directly into the vendor portal when configuring a new registry.

You can also test images for an already-configured registry.

The CLI supports image testing as well, making it easy to check new images from the terminal during your development workflow or in CI/CD.

[.pre]docker build -t 429188331526.dkr.ecr.us-east-1.amazonaws.com/my-app/my-image:1.0.1 .
docker push 429188331526.dkr.ecr.us-east-1.amazonaws.com/my-app/my-image:1.0.1
replicated registry test 429188331526.dkr.ecr.us-east-1.amazonaws.com  \
--image 429188331526.dkr.ecr.us-east-1.amazonaws.com/my-app/my-image:1.0.1
Registry conection appears ok [.pre]

Guided Registry Onboarding

Configuring the proxy was further complicated by the fact that vendor users had to know the intricacies of each registry’s authentication protocols in order to configure a registry. For example:

1. AWS Elastic Container Registry (ECR) integration requires an access key and secret, and required a specific IAM configuration to be able to properly pull images
2. The Google Container Registry (GCR) integration requires the username  [.inline] _json_key [.inline] and a “password” containing service account JSON
3. The GitHub Container Registry (GHCR) integration requires a GitHub access token for authentication

These different requirements could be hard to learn and keep track of, and so we’ve added clear guidance in the Vendor Portal UI for a few popular registry types. 

Other registry types are supported via the “Other” option - having trouble configuring your registry? We’d love to help you out. 

Recommendations

Adding the Proxy to your Workflow

If you’re not using the proxy registry today, there may be one or more reasons for this

1. Your application images may all be publicly available
2. You may be already sharing per-customer registry credentials with end users as part of your distribution process

Many teams who are already distributing Helm Charts or K8s apps when they migrate to Replicated are often in the business of sharing credentials out-of-band as in (2). The proxy can provide a handy way to skip a step and reduce the number of different credentials your team members (and end users) need to manage. Check out the overview documentation and the docs for using the proxy with Helm Installations and the Replicated SDK.

‍Note - If you already have registries connected, there’s not much to do here. However, whenever you change or update registry settings, these new features can help you with verification.

Testing images in CI/CD

If an image can’t be pulled by the Replicated Proxy, then it can’t be pulled by end users. While registry/image integrations don’t often break, sometimes images can be pushed to new paths that the proxy’s credentials can’t access. Proxy credentials may expire periodically. For these and other reasons, we recommend testing images in your app via the replicated registry test command. Every time you are preparing to make a release, run this command for each image in your app, to double-check that it will be pullable by the proxy and your end customers. Below is an example bash script suitable for use in CI. It uses helm-images to list the images in the chart, and then tests each one against one of two configured registries. This is an oversimplified example, but should demonstrate the concept well.

[.pre] # Test that all images in the helm chart can be pulled via the proxy.
‍
for image in $(helm images get my-release my-chart.tgz | grep ecr.us-east-1.amazonaws.com); do
     replicated registry test 42918331426.dkr.ecr.us-east-1.amazonaws.com --image $image
done

for image in $(helm images get my-release my-chart.tgz | grep ghcr.io); do
     replicated registry test ghcr.io/my-repo --image $image
done [.pre]

What’s Next

As we continue to improve the vendor registry, we’re actively looking for your feedback. One of the things we’re interested in exploring is if we can scalably surface registry usage and pull logs for your team to review and monitor end customer usage.

Also, if you’re actively using the vendor registry, and want to pull images from your own domain instead of proxy.replicated.com, check out our recently launched Custom Domains feature that easily lets you CNAME the registry to a domain you control.

‍