- Getting and Starting a Private Docker Registry
- Configuring a Private Docker Registry
- Understanding the Docker Image Namespace
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Configuring a Private Docker Registry
The default registries that come in the docker-registry package or the registry container are fine if you just want to try out a Docker registry. If you want to use a registry in a production environment, however, you need a deeper understanding of how to configure your Docker registry to better suit your needs.
The following sections describe how to modify the Docker registry software for both the docker-registry package and using the registry container.
Configuring the docker-registry Package
To better understand how the docker-registry package software works, start with how the registry is set to run by default. When the docker-registry service starts up in Fedora or Red Hat Enterprise Linux, it runs the gunicorn process. There is one main gunicorn process and four additional gunicorn workers running, by default, to provide the service.
From a full ps output the gunicorn processes; you can see the options set for them:
# ps -ef | grep gunicorn 00:00:00 /usr/bin/python /usr/bin/gunicorn --access-logfile - --max-requests 100 --graceful-timeout 3600 -t 3600 -k gevent -b 0.0.0.0:5000 -w 4 docker_registry.wsgi:application
Here’s what you can learn from this command line:
- --access-logfile: Access to the docker-registry service is logged to any file you set. In this case, however, the log file is set to a single hyphen (-), so access messages are simply sent to standard output (where they are picked up by the systemd journal and can be viewed by the journalctl command).
- --max-requests 100: Sets the maximum number of requests that a gunicorn daemon can accept to 100. After that, the worker is restarted.
- --graceful-timeout 3600: Gives the gunicorn worker 3600 seconds (6 minutes) to finish handling a request once it has been sent a restart signal. If it has not completed what it is doing by that time, it is killed.
- -t 3600: If the gunicorn worker is silent for more than 3600 seconds (6 minutes), it is killed and restarted.
- -k gevent: Sets the type of gunicorn worker to gevent (an asynchronous type of worker based on Greenlets).
- -b 0.0.0.0:5000: Sets the worker to bind on all IP addresses on the system (0.0.0.0) on port 5000. This allows docker clients to connect to the Docker registry through any external network interface on the system via TCP port 5000.
- -w 4: Sets the number of worker processes to 4 (above the original gunicorn process).
- docker_registry.wsgi:application: Runs the process with the Docker registry wsgi application.
To change the behavior of the docker-registry service, you can edit the /etc/sysconfig/docker-registry file. Here is how that file is set by default in Fedora:
# The Docker registry configuration file DOCKER_REGISTRY_CONFIG=/etc/docker-registry.yml # The configuration to use from DOCKER_REGISTRY_CONFIG file SETTINGS_FLAVOR=local # Address to bind the registry to REGISTRY_ADDRESS=0.0.0.0 # Port to bind the registry to REGISTRY_PORT=5000 # Number of workers to handle the connections GUNICORN_WORKERS=4
In the docker-registry file, you can do such things as have the Docker registry listen only on a particular IP address (by default, REGISTRY_ADDRESS=0.0.0.0 listens on all addresses). You can change the port of the service to something other than TCP port 5000 or set the number of gunicorn workers to something other than 4.
The /etc/docker-registry.yml file is set as the Docker registry config file. SETTINGS_FLAVOR=local tells the config file to include common variables and then set the directory /var/lib/docker-registry for local storage use. In the /etc/sysconfig/docker-registry file, the common variables you can set include the following:
- LOGLEVEL: By default, the log level is set to info. This can also be set to debug, notice, warning, warn, err, error, crit, alert, emerg, or panic.
- DEBUG: Set to either true or false to have debugging turned on or off.
- STANDALONE: If set to true (the default), the registry acts as a standalone registry and doesn’t query the Docker index.
- INDEX_ENDPOINT: If the local registry is not set to run in standalone, the default, the index endpoint is set to https://index.docker.io.
- STORAGE_REDIRECT: By default, this is disabled.
- DISABLE_TOKEN_AUTH: If the service is not in standalone, this variable is enabled to allow token authentication.
- PRIVILEGED_KEY: By default, no privileged key is set.
- SEARCH_BACKEND: By default, there is no search backend.
- SQLALCHEMY_INDEX_DATABASE: By default, the SQLite search backend database is set to: sqlite:////tmp/docker-registry.db.
If you want to use a setting flavor other than local, look in the /etc/docker-registry.yml file. Different setting flavors can be used for Ceph Object Gateway configuration, Google Cloud Storage configuration, OpenStack Swift Storage, and others.
Other variables you can set that can be picked up by the gunicorn process, include the following. Notice that some of these values show up on the gunicorn command line:
- GUNICORN_GRACEFUL_TIMEOUT: Sets the timeout for gracefully restarting workers (in seconds).
- GUNICORN_SILENT_TIMEOUT: Sets the timeout for restarting workers that have gone silent (in seconds).
- GUNICORN_USER: Runs the gunicorn process as the user set here, instead of running it with root user privileges.
- GUNICORN_GROUP: Runs the gunicorn process as the group set here, instead of running it with root group privileges.
- GUNICORN_ACCESS_LOG_FILE: Sets the name of the log file to direct messages to those that are related to clients trying to access the service. By default, messages are sent to the systemd journal through standard output.
- GUNICORN_ERROR_LOG_FILE: Sets the name of the log file to direct messages to those that are related to error conditions. By default, messages are sent to the systemd journal through standard output.
- GUNICORN_OPTS: Identifies any extra options you want to pass to the gunicorn process.
After you set or change /etc/sysconfig/docker-registry file variables, restart the docker-registry service for these features to take effect.
Configuring the registry Container
Instead of trying to configure the registry container image by modifying the contents of the running container, the creators of that container image suggest you rebuild the registry container image yourself. In particular, you probably want to add security measures to your registry and more flexible storage features.
So far, this book has not yet introduced you to the concepts you need to build your own containers. However, after you have become familiar with the process, if you decide you want to build a custom version 1 registry container, I recommend you refer to the docker-registry GitHub page:
From the docker-registry GitHub page, you can find information on how to build a version 1 registry image and links to the Dockerfile used to build it (https://github.com/docker/docker-registry/blob/master/Dockerfile).
By the time you read this, Docker registry version 2 may be ready to use. Refer to the Docker registry 2.0 page (https://docs.docker.com/registry) for details on how to deploy and configure this newer version of the Docker registry.