Your search did not match any results.
We suggest you try the following to help find what you're looking for:
OCIR or Oracle Cloud Infrastructure Registry is a Docker v2 compatible Docker image registry.
OCIR is best used to store Docker images you will utilize in Containerized Applications, such as those that you deploy with Container Engine for Kubernetes.
It's easy, just create an Auth Token via your user settings and login with the Docker CLI. See the registry documentation.
Docker users are familiar with short urls to push and pull images. Other cloud providers also use shortened URLs. We wanted to make sure that usage of OCIR conforms to these user expectations.
Yes, each of the regional instances are distinct. You communicate with each independently. Best practice suggests you use the regional instance closest to where you are deploying your containers.
The regional URLs align with the nearby airports. phx.ocir.io; iad.ocir.io; lhr.ocir.io; fra.ocir.io.
Yes, you need to specify the entire path, in this format: .ocir.io///:tag, for example: phx.ocir.io/tenancy-foo/project01/nginx:latest.
Docker users are used to a repository based structure for their container registries. Administrators can limit access to a particular repo path, both for read-only (pull only) and push/pull. Adding compartments would add an unnecessary level of complexity to this simple concept.
Quotas are 500 repos total and 500 images per repo PER region.
Yes, an administrator of the tenancy can make any repo public. This means that if a user has the complete path to the image, they can pull it, with no authentication needed. Note, that the user will not be able to see the Oracle Cloud Infrastructure console page, they will just be able to pull the image.
Yes, with our auto-cleanup feature, you can set retention policies, so for example, if an image is not pulled in x days, it is automatically deleted.
Yes, create a user for that service account and an "Auth Token" (formerly Swift Password), which can be revoked at any time. Put that user in a group that supports your use case, via policy, such as read only and limited to a particular repo path. See Policies to Control Repository Access documentation.