Managing the Docker Engine Service

Configuring the Docker Engine Service

It is possible to configure the Docker Engine runtime options in a variety of ways. Where possible, Oracle recommends using the /etc/docker/daemon.json file to configure these options. For more information on the format and options for this configuration file, see https://docs.docker.com/engine/reference/commandline/dockerd/#daemon-configuration-file.

In rare instances, some runtime configuration options may not have an equivalent option that can be set in /etc/docker/daemon.json. Oracle previously allowed users to set these runtime options by editing variables in /etc/sysconfig/docker, /etc/sysconfig/docker-network and /etc/sysconfig/docker-storage. While these files can still be used for this purpose, they may be deprecated in future releases. Oracle recommends creating an alternate drop-in unit for the Docker Systemd service where you may need to specify alternate runtime options when loading the Docker Engine.

For example, you can create /etc/docker/daemon.json to contain the following content:

{
  "selinux-enabled": true
}

When you have finished editing the configuration file, reload to scan for new or changed units:

sudo systemctl daemon-reload

Finally, restart the Docker Engine service:

sudo systemctl restart docker

Reloading or Restarting the Docker Engine

If you change the Docker Engine configuration while the docker service is running, you must reload the service configuration to make the changes take effect.

To reload the docker service configuration, enter the following command:

sudo systemctl daemon-reload

If you do not reload the service configuration, systemd continues to use the original, cached configuration.

If you need to restart the docker service itself, enter the following command:

sudo systemctl restart docker

Enabling Non-root Users to Run Docker Commands

Attention:

Users who can run Docker commands have effective root control of the system. Only grant this privilege to trusted users.

To enable users other than root and users with sudo access to be able to run Docker commands:

Create the docker group, if it does not already exist:

sudo groupadd docker

Restart the docker service:
```
sudo systemctl restart docker
```
The UNIX socket /var/run/docker.sock is now readable and writable by members of the docker group.
Add the users that should have Docker access to the docker group:
```
sudo usermod -a -G docker user1
```

Configuring User Namespace Remapping

To force processes running in Docker containers to run with an alternate user namespace mapping on the host system,use the userns-remap option as a startup parameter for the Docker Engine. This functionality provides an additional layer of security to the host system. The processes that are running in each container are run with the UIDs and GIDs of a subordinate mapping defined in /etc/subuid and /etc/subgid. The shadow-utils project provides subordinate user mappings, which are a function of user namespaces within the Linux kernel. For more information, see https://docs.docker.com/engine/security/userns-remap/.

To implement user namespace remapping:

Create and edit the /etc/subuid file.

Although the Docker documentation suggests that this file is created and populated automatically, this function is dependent on code available in the usermod command, not currently included in Oracle Linux. Create the file manually if it does not yet exist, and populate it with the user mapping that you require.
```
user:start_uid:uid_count
```
Add an entry for the dockremap user if you plan to configure default user namespace remapping. Alternately, add an entry for the unprivileged user that you are going to use for this purpose. For example:
```
dockremap:100000:65536
```
In the example above, dockremap represents the unprivileged system user that is used for the remapping. 100000 represents the first UID in the range of available UIDs that processes within the container may run with. 65536 represents the maximum number of UIDs that may be used by a container. Based on this example entry, a process running as the root user within the container is launched so that on the host system it runs with the UID 100000. If a process within the container is run as a user with UID 500, on the host system it would run with the UID 100500.
Create and edit the /etc/subgid file. The same principles apply to group ID mappings as to user ID mappings.

Add an entry for the dockremap group if you plan to configure default user namespace remapping. Alternately, add an entry for the group that you are going to use for this purpose. For example:
```
dockremap:100000:65536
```
Configure the docker service to run with the userns-remap parameter enabled. Create or edit /etc/docker/daemon.json.

If you are creating this file from scratch, it should look like this:
```
{
  "userns-remap": "default"
}
```
When userns-remap is set to default, Docker automatically creates a user and group named dockremap. Entries for the dockremap user and group must exist in /etc/subuid and /etc/subgid. Alternately, set the userns-remap option to run using another unprivileged user and group that already exist on the system. If you select to do this, replace the dockremap user in the /etc/subuid and /etc/subgid files with the appropriate user name and group name.

If this file already exists and contains other entries, be careful that adding a line for the storage-driver configuration variable conforms with typical JSON formatting.

For more information on the format and options for this configuration file, see https://docs.docker.com/engine/reference/commandline/dockerd/#daemon-configuration-file.
Check that the --userns-remap option is not being invoked as a command line switch when starting the Docker Engine daemon.

You should check that this option does not appear in the /etc/sysconfig/docker file. This file is deprecated and may be removed in future releases. If this file contains any other configuration parameters, consider whether you could move these into /etc/docker/daemon.json to future-proof your configuration.

Also check that this option does not appear in any systemd drop-in files in /etc/systemd/system/docker.service.d/. While this is a supported configuration option, it is preferable to keep all Docker Engine configuration in the same place, where possible.
Reload the docker service in systemd to activate changes to the service configuration:
```
sudo systemctl daemon-reload                     
```
If you need to restart the docker service itself, enter the following command:
```
sudo systemctl restart docker                     
```
The Docker Engine applies the same user namespace remapping rules to all containers, regardless of who runs a container or who executes a command within a container.

Enabling Live Restore for Containers

Docker has a live-restore option that can be used to keep containers running even if the Docker Engine daemon becomes unavailable. This option can help reduce container downtime due to crashes, planned outages and upgrades. To enable this facility you must edit /etc/docker/daemon.json and set the "live-restore" parameter to true. For more information on this facility, see https://docs.docker.com/config/containers/live-restore/.

Setting Container Registry Options

Oracle Container Runtime for Docker contains a number of configuration options that can be applied to the Docker Engine to control and customize the handling of commands to access a Docker registry.

Adding Registries

Oracle Container Runtime for Docker provides the option to connect to multiple registries to pull container images by configuring a registry list. By default, the Docker Engine is configured to pull images directly from the Docker Hub if no additional registries have been defined. You can configure a registry list to specify multiple registries that can be queried sequentially to pull an image. This can be used to configure the Docker Engine to first attempt to pull an image from a local registry and then fall back to an alternate registry, such as the Oracle Container Registry, before finally using the configured default registry. This is achieved by setting the add-registry option in /etc/docker/daemon.json.

...
  "add-registry": [
    "container-registry.oracle.com"
  ],
...

If you are creating this file from scratch with just the add-registry option, it would look like this:

{
  "add-registry": [
    "container-registry.oracle.com"
  ]
}

You can add multiple registries by appending the domain or domains you would like to add to the same list:

...
  "add-registry": [
    "container-registry.oracle.com",
    "registry.example.com"
  ],
...

Restart the Docker Engine service to apply your change:

sudo systemctl restart docker

Blocking Registries

Oracle Container Runtime for Docker provides the option to prevent access to specified registries when attempting to pull container images. This can be used to prevent users from pulling images from specific external registries. This is achieved by setting the block-registry option in /etc/docker/daemon.json.

...
  "block-registry": [
    "docker.io"
  ],
...

You can disable multiple registries by appending the domain or domains you would like to block to the same line:

...
  "block-registry": [
    "docker.io",
    "registry.example.com"
  ],
...

When you have finished editing /etc/docker/daemon.json, restart the Docker Engine service:

sudo systemctl restart docker

Setting the Default Registry

By default, the Docker Engine is configured to pull images directly from the Docker Hub if no additional registries have been defined.

It is possible to change the default registry by setting the default-registry option in /etc/docker/daemon.json.

...
  "default-registry": "test.registry.com",
...

Finally, restart the Docker Engine service:

sudo systemctl restart docker

When the default registry is changed, image references within the Docker Engine for images that have been pulled from the Docker Hub are updated to correctly display the docker.io prefix. For example nginx:latest is updated to reflect docker.io/nginx:latest. Images from the new default registry are displayed without a prefix.

The default registry determines the last possible registry that Docker Engine checks when you search for or pull an image. If you have configured multiple registries using the add-registry option then those registries are checked in sequential order, and if an image is not found in any of the other registries that you have been configured then the default registry is always used as the final option.

Adding Insecure Registries

Oracle Container Runtime for Docker provides the option to enable a registry that delivers containers over HTTPS but without any certificate validation, such as when using self-signed certificates for testing purposes, or to enable the use of registry that only uses HTTP. This is achieved using the insecure-registry option in /etc/docker/daemon.json.

...
  "insecure-registries" : ["insecure-registry.example.com"],
...

The insecure-registry option allows Docker to attempt an HTTPS connection to the registry, without any validation of the certificates presented by the registry. If the registry is not accessible via HTTPS, Docker falls back to attempt the connection using HTTP.

Restart the Docker Engine service to apply your changes:

sudo systemctl restart docker