Quickly Disaster-proof your Oracle Container Registry (OCIR) Images
RackWare SWIFT provides a quick and easy solution to migrate data to and from various image registries. Once your policy is set, SWIFT will take timely backups of your image registry and prevent image data loss.
You can set up a Disaster proof policy to sync images between Oracle Container Registry (OCIR) and any of the following image registries:
Docker Hub
Azure Container Registry (ACR)
Amazon Container Registry (ECR
Google Container Registry (GCR)
This blog will cover how to make you OCIR registry disaster proof in a few simple steps.
Step 1:
On your Oracle marketplace RackWare DR subscriptions page, you can get a quick overview of how DR policy would work on a subscription basis.
Configure the compartment and the region in which you want to launch your DR subscription and select on ‘create.’
Step 2:
After this step SWIFT will be installed. Once you have your SWIFT up and running, access the SWIFT server and set password for admin user. sudo swiftcli user modify admin --password <password>
Now you can access the SWIFT dashboard using the URL ‘https://<host-ip>/swift/dashboard/.’
Enter the username and password that was set with the above command and click on ‘Login.’
Step 3:
Under the ‘Image Registries’ tab on the right panel, click on the ‘Add’ option to discover a new registry.
Here provide all the necessary details for your source OCIR registry which you would like to make disaster proof.
Note: Data can be synced from one region to another in OCIR, by giving different regions while discovering the registry.
Repeat this step for the target registry as well, to which you would like to sync your images.
Step 2:
A DR policy can be initiated directly as shown in Step 6 - part 2, but to validate if the replication is working as per expectations, a manual replication is preferred to be executed first. This same replication can later be attached to your DR policy. To replicate your images from your source registry to your target, you can find the ‘All Replications’ tag under the ‘Sync Administration’. To start our new replication, click on the ‘New’ button and select ‘Registry Replication’.
Step 3:
Choose the appropriate options as required for your migration depending on whether you want to sync all repositories or selective repositories.
Repository mapping in case of OCIR:
In case your target registry is an OCIR registry and the repository name you wish to replicate from the source is present in any compartment of the target registry, the repository cannot be created for the need to have unique repository names across compartments. Hence in this case to avoid failure of sync, you may rename this repository using the repository mapping options provided.
Another case where repository mapping is mandatory would be if you wish to replicate images in the same OCIR registry. Intra-registry replication is one where the source and target registry names are the same, hence providing an alternative name for each source repository to be synced is necessary.
Repository mapping in case of docker hub as the target:
Docker doesn’t allow backslash in its repository name. Hence if your source repository from OCIR contains ‘/’ in its name, one of two things will happen:
Provide an alternative name using repository mapping
If not provided SWIFT will auto convert the backslash to an underscore in the source repository name
For Example: ‘demo/repo1’ -> ‘demo_repo1’
Step 4:
Now to make your registry disaster proof you will need to first create a DR policy by selecting ‘DR Policies’ under ‘Business Continuity & DR’ and create a ‘New’ DR Policy.
Step 5:
Configure the parameters of the DR policy with a ‘passthrough’ sync type and the time intervals at which you would like to take your back up for your registry and then click on ‘CREATE’.
The various scheduling options that you can apply to your DR policy are as follows:
By schedule – Either daily or weekly at some specific time of day. Along with this, you can exclude days that you don’t want replications to run on.
By frequency – This option allows to run replications continuously at a specific frequency of some minutes/hours. Along with this, you can exclude time slots in which you don’t want replications to run on.
Once – This option gives the user the liberty to run a replication only once on a decided date and time.
Continuous – This option indicates that there will be replications that will run continuously after the former is completed.
Step 6:
The last step would be to apply your replication to your DR policy. Once you select the DR policy click on the ‘Apply’ button and select ‘Registry Replication’.
There are 3 ways to apply a DR policy:
Select ‘Existing replications’ and select the registry replication performed by steps 2 & 3.
After steps 2 & 3, you can go to the ‘All replications’ page, and click on the “Apply” next to your replication.
Next, select your DR policy and choose to either start it immediately or later at some specific time.
You can skip steps 2 & 3 and select ‘New Replication’ to directly configure the replication performed in step 3.
Once these steps are complete a replication will be triggered and can be seen as below
With these steps your Oracle Container Registry will be periodically backed up at your destination registry and make it disaster proof.
Oracle target registry before replication:
Oracle target registry after replication:
Failover and Fallback:
SWIFT also offers two more features, failover and fallback, to help secure your registry images in case of a disaster. You can access them with these arrows:
Failover:
When a DR event occurs and the source site is down, the DR side needs to come in to picture. In such a case, you may execute the ‘failover command’ to make the DR side operational. After a failover operation is performed, the state of the DR policy will be changed to ‘FailedOver’ and the subsequent scheduling of syncs will be paused.
You may choose which operations you want to apply the failover to – all or only some.
The Drill Mode is only to check if the failover operation would work correctly in the event of a mishap. It will not actually sync any images over to the destination registry.
Fallback:
In a case when the source registry is down and the user wants to bring it back, a fallback operation can be performed. All the options of a fallback are like those of the failover operation.
Note: A Fallback operation can only be performed after a failover operation.
