We recently had a prospect that wanted to test our image and application recover capabilities, in a multi-cloud architecture. Currently they were using an internal OpenShift image registry to store their images, and they wanted/needed to migrate all their applications to a new cluster, and also wanted to use Red Hat’s quay.io to store the images from now on.
This proved a very easy task for Trilio, as when we protect applications, we also protect the images. And at restore time, we have an easy to use option in the UI, to restore images to a new image registry. This implies a complete migration from using one registry, to use the new one moving forward.
After images are restored, the applications are started in the new cluster, pulling the images from the new Image Registry. In this blog post I am going to show you step by step, how to do the whole process…
Why should you be concerned about granularly protecting your container images?
I know at least four reasons where you would need to follow this process:
Image Registry Unavailable: If your company’s image registry becomes unavailable due to technical issues or outages, it will hinder your ability to deploy new applications. Restoring your applications, including the images they rely on, to a new image registry can help you overcome this obstacle and resume normal operations.
Auditing Purposes: Restoring a backup from three months ago can be crucial for auditing purposes. However, the images used in that backup may not be readily available in your production image registry. To perform the restore, you’ll need to first retrieve the missing images from the backup.
Application Relocation: When migrating or recovering an application to a different Kubernetes cluster, you may encounter a situation where the required images don’t exist in the destination cluster’s image registry. In this scenario, restoring the images from the backup can ensure that the application can run smoothly in the new environment.
Registry Migration with Application Transformation: Some companies may need to migrate from one image registry to another. While tools like skopeo can help transfer images, restoring and migrating applications simultaneously can be more efficient and streamlined. Additionally, image restoration allows for potential transformations to be applied to application components, such as DNS configurations, routes, storage infrastructure, and configmaps. This adaptability can be valuable when migrating between environments with varying configurations.
The step by step process will show you how to restore images to repos in quay.io, but it could be any image registry you can set up quickly like Harbor or even some OpenShift internal image registry in another OpenShift cluster, or any public image registry if you have connectivity.
Quay.io configuration
2 – Then go to each repo, click on settings:
3 – Then click on your username, and then on create a robot account:
4 – When you finish creating the robot, you should give proper permissions to push images. You should see something like this when you finish…
5 – In “view credentials” you will be able to download the credentials you have to provide later in a secret in the Trilio UI. Click on Options…as you see on the next screenshot:
6 – Download the json file…selecting “Docker Configuration” like in the next image…
You have now all you need to be able to push images to quay.io
Trilio Recovery process
Let’s go to the Trilio UI, to restore an app with its images…
In the destination cluster, you will browse the backup target (S3 or NFS), search for the backup you want to restore (be it a namespace backup, a helm chart backup or any backup), and start the recovery/migration process:
1 – First, you go to list the backup targets, in the cluster where you want to restore. Click on Targets, like in the following screenshot:
2 – Then you click on Launch Browser, in the menu in the right, like you see in the next image:
3 – Next, you can for example filter by the cluster you want to restore applications from, in the search box in the left, like in this example:
4 – Now that you only see backups from the cluster named DC2, you can choose the application you want to restore, in this case jeff-ns-backup namespace backup, and click on it, like in the next screenshot:
5 – You will be presented with the list of backups available to restore. In this case we select the latest one:
6 – Next, we select the first one, and then click Restore, like in the next example:
7 – Now, we enter a descriptive name for the restore process, just in case we need to identify it later, and enter what namespace we want to restore to ( we can always create a new namespace). It will look like this:
8 – Next, we have to tell Trilio that we also need to restore images, it’s not enabled by default. Enable the flag where it says “ImageRestore”:
9 – You have to enable the restore image flag, and enter these details. /rodolfo_casas is the namespace/user in quay.io, where your repos are present, like in the next image.
10 – Those credentials you downloaded earlier from quay.io, you will have to create a new secret, and upload the json file you downloaded previously. After you start the backup, you can check that the secret exists in the NS where you are restoring to. It will look like this in the Trilio UI:
If nothing else needs to be done concerning your application restore, you are good to go.
Confirm you are creating the secret in the same namespace where you are restoring your app.
Conclusion
We can migrate an application to another cluster, and if needed we can restore images that were backed up in the source cluster. Those images will be restored in the image registry you want to.
The best documentation I could find about skopeo syncing images between image registries is here. It also gives you many other options to have fun with it, it’s a great tool.
File: skopeo-sync.1.md
