Cloud Hosting

With Docker container images being the second most popular ecosystem in GitHub Packages, GitHub has decided to give them their own designated registry.

GitHub Container Registry is now available as a public beta. Microsofts 2018 acquisition seems to be aiming the new offering mainly at organisations, since major features like fine-grained access control and promoting a standard way of doing things arent really crafted for single users.

This doesnt mean, however, that the latter wont be able to profit from the registry, since it also answers the call for anonymous image access, allowing for anonymous pulls of public images the same way the platform lets anyone download public repo content. For packages, users had to at least sign in to be able to get content.

Since container registries can be found on most cloud platforms and from various providers these days (Google, Red Hat, and GitLab, just to name a few), the appeal of GitHubs offering surely boils down to the proximity to the popular repository management service and the associated easy integration into existing workflows. Compared to predecessor GitHub Packages, Container Registry also shines with the decoupling of registry and repository permissions, which opens it up for more usage scenarios when compared to competing offers.

Through this, teams can keep their code private, while sharing images publicly or within their organisation for example. Administrators are also able to grant access permissions separate from those at organisation or repo level, giving single persons and teams either read, write, or admin privileges for images.

Out of the box, a container images visibility is set to private. This can be changed via the package settings, though admins have to enable package creation before anything along those lines can be done. Users have to be aware though, that once the decision for going public has been made, the image cant be made private again.

According to the documentation, storage and bandwidth are free during the beta phase. Afterwards it is meant to use the rates of GitHub Packages, implying no cost for public images. Those using the registry for private packages meanwhile can do so for free until theyve hit a limit which depends on the product theyre using (Free/Pro/Team/Enterprise Cloud). Once thats exhausted, costs currently amount to $0.25 USD per GB of storage and $0.50 USD per GB of data transfer.

GitHub Actions to include the new registry into existing workflows are already available, as is a migration guide for those making use of the Packages Docker registry. To make the switch, authentication with the base URL ghcr.io (which doesnt seem to be available at the time of writing) is necessary and packages have to be republished, which will require a bit of manual work.

Docker Engines and Docker Desktop are meant to seamlessly work with the new registry. Docker of course has its own way of sharing container images, Docker Hub, but says that portability and choice have always been core to the Docker experience, which is presumably why it is so excited about GitHubs move.

GitHub doesnt seem to plan to stick to Docker, though, and has plans to support more open standards for cloud-native development, including Helm 3 charts for Kubernetes applications and using Container Registry for universal storage.

The last item on the list specifically might pique the interest of some Microsoft sceptics, since the GitHub parent deals in cloud storage, amongst other things. It also counts Docker registry Azure Container Registry among its portfolio, so it remains to be seen if a connection to any of that will be revealed at some point.

See the original post:
Why not open our own Container Registry, muses GitHub as it gives orgs a hand at resource-sharing DEVCLASS - DevClass