Docker Registry

The Docker Registry implementation has completely changed from the previous version mentioned in the earlier edition of this book. Docker Registry 2.0 is the new implementation for storing and distributing Docker images. It supersedes the previous Docker Registry implementation (https://github.com/docker/docker-registry). The new implementation is available at https://github.com/docker/distribution. This is open source under the Apache license. The registry is a stateless, highly scalable server-side application that stores and lets you distribute Docker images. The Docker Registry index is deprecated in the new release. Previously, the Docker Registry used index internally to authenticate the user.

Docker Registry 2.0 is completed, new, and implemented in Go and supports the Docker Registry HTTP API v2. The current Docker Hub (https://hub.docker.com) is based on the new Docker Registry 2.0 with Docker Engine 1.6 or above. This makes it more reliable and transparent to its users. All cloud providers have adopted this new Docker Registry including AWS and IBM.

The new registry implementation provides the following benefits:

  • Faster push and pull
  • Secure and efficient implementation
  • Simplified deployment
  • Pluggable storage backend
  • Webhook notifications

The general architecture of Docker Registry shows, as in the following image, how it is integrated with Nginx at frontend and storage at backend:

The salient features of the registry are as follows:

  • The registry is compatible with Docker Engine version 1.6.0 or higher.
  • The default storage driver is the local POSIX filesystem, which is suitable for development or small deployments. It also supports different storage backends (S3, Microsoft Azure, OpenStack Swift, and Aliyun OSS).
  • It natively supports TLS and basic authentication.
  • In the new version, the registry also supports a robust notification system. The registry supports sending Webhook notifications in response to events happening within the registry. Notifications are sent in response to manifest pushes and pulls and layer pushes and pulls. These actions are serialized into events. The events are queued into a registry-internal broadcast system, which queues and dispatches events to endpoints (https://docs.docker.com/registry/notifications/#endpoints).

The latest Docker Registry releases two options:

  • Docker Trusted Registry
  • Docker Registry

Let's talk about the two options in detail:

  • Docker Trusted Registry (DTR): This is the enterprise grade solution from Docker. DTR supports high availability and is installed on the Docker Universal Control Plane (UCP) cluster. The details are available at the following website:
    https://docs.docker.com/docker-trusted-registry/.

DTR supports image management and it has built-in security and access control. It can also be integrated with LDAP and Active Directory (AD) and supports Role Based Access Control (RBAC).

The general architecture of DTR is shown in the following diagram:

DTR has a built-in authentication mechanism. DTR running on a node consists of the following containers:

  • dtr-api-<replica_id>: Executes the DTR business logic. It serves the DTR web application, and API.
  • dtr-garant-<replica_id>: Manages DTR authentication.
  • dtr-jobrunner-<replica_id>: Runs cleanup jobs in the background.
  • dtr-nautilusstore-<replica_id>: Stores security scanning data.
  • dtr-nginx-<replica_id>: Receives HTTP and HTTPS requests and proxies them to other DTR components. By default it listens to ports 80 and 443 of the host.
  • dtr-notary-server-<replica_id>: Receives, validates, and serves content trust metadata, and is consulted when pushing or pulling to DTR with content trust enabled.
  • dtr-notary-signer-<replica_id>: Performs server-side timestamp and snapshot signing for content trust metadata.
  • dtr-registry-<replica_id>: Implements the functionality for pulling and pushing Docker images. It also handles how images are stored.
  • dtr-rethinkdb-<replica_id>: A database for persisting repository metadata.

DTR uses the following internal named volumes for persistence of data:

  • dtr-ca: The private keys and certificates are stored here
  • dtr-etcd: This is used by etcd for storing DTR internal configurations
  • dtr-registry: This is the volume where images are stored
  • dtr-rethink: This is used by RethinkDB to persist DTR data, such as users and repositories

By default, DTR stores the images on the local filesystem of the host machine. For highly available installations of DTR, it supports cloud storage or network filesystems also. DTR can be configured to support Amazon S3, OpenStack Swift, and Microsoft Azure.

  • Docker Registry: The registry is a stateless, highly scalable server-side application that stores and distributes Docker images. The registry is open source, under the permissive Apache License (http://en.wikipedia.org/wiki/Apache_License).

In this book, we will focus on the second option of the open source Docker Registry.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset