Since Atomic Registry was announced as the enterprise, 100% open source private docker registry, we have been responding to feedback from the community to make it great. The Cockpit team has been working hard to improve the console interface and general user experience. The OpenShift team has been tirelessly updating the backend to make the registry more stable, usable, and easier to deploy and maintain.

Some of the feedback we received suggested the deployment method was difficult to understand. As part of OpenShift it pulled in a lot of dependencies that were not essential for running the registry. The OpenShift features are terrific for running clustered container workloads but it can be a barrier to some administrators for just running a standalone registry.

We’ve tried to strike a balance between ease of deployment, configuration and maintenance while retaining architectural flexibility to support scale, distributed configuration and container best practices. We’re doing this using systemd.

Why Systemd?

There are several benefits to managing containers with Systemd.

• Mature process management that supports dependencies, logical restart, etc.
• Ease of configuration that matches a traditional sysadmin experience.
• Native system logging to journald.

With this approach we leverage docker packaging to deliver applications that just work.

Check out the new systemd deployment for Atomic Registry. The unit files and setup script have been packaged as an install container so you can quickly pull it down and try it out.

Open Source. Open Process.

As a Red Hat-sponsored project we see the benefits in practicing open source as well as open process. We committed to this and worked hard to share our public Trello organization. The Atomic Registry roadmap card aggregates all of the planned and in-progress development work. I’ve been excited about progress on these specific items:

• Unauthenticated docker pull. This is essential for the on-premise use case where users want to tightly control who can push images but allow anyone to freely pull images without docker login. Trello card
• Federated image remotes. With the pending image layer federation support ISVs will be able to retain control of their layers without distributing base image layers from another vendor. Trello card
• Image Signing. We’re well along in our development of a simple but robust cryptographic image validation prototype. Trello aggregate card