1. Oracle Container Runtime for Docker User's Guide
  2. About Oracle Container Runtime for Docker

1 About Oracle Container Runtime for Docker

Oracle Container Runtime for Docker allows you to create and distribute applications across Oracle Linux systems and other operating systems that support Docker. Oracle Container Runtime for Docker consists of the Docker Engine, which packages and runs the applications, and integrates with the Docker Hub and Oracle Container Registry to share the applications in a Software-as-a-Service (SaaS) cloud.

The Docker Engine is designed primarily to run single applications in a similar manner to LXC application containers that provide a degree of isolation from other processes running on a system.

Important:

Oracle Container Runtime for Docker releases 17.03 and later are only available on Oracle Linux 7 (x86_64). Oracle Linux 6 is not supported for Oracle Container Runtime for Docker version 17.03 and later.

The Docker Hub hosts applications as Docker images and provides services that allow you to create and manage a Docker environment. If you register for an account with the Docker Hub, you are able to use it to store your own private images. You do not need an account at Docker to access publicly accessible images on the Docker Hub. The Docker Hub also hosts enterprise-ready applications that are certified as trusted and supported. These applications are made available by the verified publishers. Some applications shipped on the Docker Hub may require payment.

Note:

The Docker Hub is owned and maintained by Docker, Inc. Oracle makes Docker images available on the Docker Hub that you can download and use with the Docker Engine. Oracle does not have any control otherwise over the content of the Docker Hub Registry site or its repositories.

For more information, see https://docs.docker.com.

The Oracle Container Registry contains images for licensed commercial, and open source, Oracle software products. Images may also be used for development and testing purposes. The commercial license covers both production and non-production use. The Oracle Container Registry provides a web interface where customers are able to select Oracle images, and, if required, agree to terms of use, before pulling the images using the standard Docker client software. More information on this service is provided in Pulling Images From the Oracle Container Registry.

Technical Preview Releases

Oracle makes interim releases of Oracle Container Runtime for Docker available as technical previews. These releases are not supported by Oracle and are not intended for production use.

Preview releases can be obtained by subscribing to the ol7_preview repository on the Oracle Linux yum server. You can install the appropriate package to obtain the correct repository configuration before enabling the repository: 

sudo yum install oraclelinux-developer-release-el7
sudo yum-config-manager --enable ol7_preview

The installation and upgrade procedures described in this guide should continue to apply for each preview release.

Notable Updates

Changes to the Docker Engine tend to retain backward compatibility as far as possible. Changes are usually well documented and a detailed changelog is maintained at https://docs.docker.com/release-notes/. In this section, changes that are considered significant, or of interest to users of the Docker Engine on Oracle Linux systems, are highlighted for convenience.

Oracle Container Runtime for Docker 19.03

The current release of Oracle Container Runtime for Docker is based on the upstream Docker 19.03 release and incorporates the changes present in subsequent upstream releases since the previous release. The notable changes in this release are:

  • The docker run and docker create commands now include an option to set the domain name, using the --domainname option.

  • The docker image pull command now includes an option to quietly pull an image, using the --quiet option.

  • Faster context switching using the docker context command.

  • Added ability to list kernel capabilities with --capabilities instead of --capadd and --capdrop.

  • Added ability to define sysctl options with --sysctl list, --sysctl-add list, and --sysctl-rm list.

  • Added inline cache support to builder with the --cache-from option.

  • The IPVLAN driver is now supported and no longer considered experimental.

  • Deprecated image manifest v2 schema 1 in favor of v2 schema 2.

  • Removed v1.10 migrator.

  • CVE-2020-13401 is resolved in the 19.03.11 errata release package.

Oracle Container Runtime for Docker 18.09

This release of Oracle Container Runtime for Docker was based on the upstream Docker 18.09 release and incorporated the changes present in subsequent upstream releases since the 18.03 release.

Notably, multi-registry support is no longer in technical preview and is enabled as a feature within this release. Additionally, Oracle introduces the --default-registry option, which can be used to change the default registry to point to an alternate registry to the standard Docker Hub registry. See Setting Container Registry Options for more information.

This release of Docker introduces an integrated SSH connection helper that allows any Docker client to connect to a remote Docker engine daemon securely over SSH. You can connect to a remote daemon using the -H ssh://user@host syntax. For example: 

docker -H ssh://docker_user@host1.example.com run -it --rm busybox

To configure a client to use the same remote daemon always, you can set the DOCKER_HOST environment variable to contain the appropriate SSH URI. The SSH connection helper respects SSH options set for a host within the user's local SSH configuration file.

The Docker client application can now be installed as an independent package, docker-cli, so that the Docker engine daemon does not need to be installed on a system that may be used to manage a remote Docker daemon instance. The client package is automatically installed as a dependency when you install the Docker engine daemon package.

Docker 18.09 also introduces BuildKit, an overhaul of the build architecture used to build Docker images. The BuildKit mode is backward compatible with legacy build architecture, so that the Dockerfile format used to build previous images can continue to be used. BuildKit can be enabled on a system by setting the DOCKER_BUILDKIT environment variable to the value of 1. BuildKit build output is enhanced to include progress and build times and many build processes can be run in parallel to greatly enhance performance and build time. The new Docker build architecture also includes improvements to security, including options to pass secret information to builds in a more secure manner. See the upstream documentation at https://docs.docker.com/develop/develop-images/build_enhancements/ for more information. This feature is available as a technical preview in this release of Oracle Container Runtime for Docker.

Docker 18.09 uses a new version of containerd, version 1.2.0. This version of the containerd package includes many enhancements for greater compatibility with the most recent Kubernetes release.

Oracle Container Runtime for Docker 18.03

This release of Oracle Container Runtime for Docker was based on the upstream Docker 18.03 release and incorporated the changes present in subsequent upstream releases since the 17.06 release.

Most notably, Oracle has implemented multi-registry support that makes it possible to run the daemon with the --add-registry flag, to include a list of additional registries to query when performing a pull operation. This functionality, enables Oracle Container Runtime for Docker to use the Oracle Container Registry as the default registry to search for container images, before falling back to alternate registry sources such as a local mirror, the Docker Hub. Other functionality available in this feature includes the --block-registry flag which can be used to prevent access to a particular Docker registry. Registry lists ensure that all images are prefixed with their source registry automatically, so that a listing of Docker images always indicates the source registry from which an image was pulled. See Setting Container Registry Options for more information.

Important:

Docker registry list functionality is available as a technology preview and is not supported. As a technology preview, this feature is still under development but is made available for testing and evaluation purposes.

The --insecure-registry option is also included in this release and allows use of a registry over HTTPS without certificate-based authentication. This can be useful when working in development or testing environments, but should not be used in production.

Docker 18.03 introduces enhancements that allow for better integration with Kubernetes orchestration as an alternative to Docker Swarm, including changes to follow namespace conventions used across a variety of other containerization projects.

The --chown option is now supported for the ADD and COPY commands in a Dockerfile, giving users more control over file ownership when building images.

The Dockerfile can also now exist outside of the build-context, allowing you to store Dockerfiles together and to reference their paths in the docker build command on stdin.

Several improvements to logging and access to docker logs have been added, including the --until flag to limit the log lines to those that occurred before the specified timestamp.

Experimental Docker trust management commands have been added to better handle trust management on Docker images. See the docker trust command for more information.

Docker Swarm changes and improvements have gone into this release. Customers are reminded that Docker Swarm remains in technical preview in this release.

The deprecated --enable-api-cors daemon flag, which allowed cross-origin resource sharing to expose the API, has been removed in favor of the --api-cors-header option, which takes a string value to set the Access Control Allow Origin headers for the API and to determine access control for cross-origin resource sharing.

The deprecated docker daemon command, which was kept for backward compatibility, has been removed in this release.

Oracle Container Runtime for Docker 17.06

This release disables communication with legacy registries, running the v1 protocol, by default. While it is possible to allow communication using this version of the protocol by setting the --disable-legacy-registry=false daemon option, you should be aware that support for this is deprecated.

The --graph daemon option is also deprecated in favor of the --data-root option, as this is more descriptive and less confusing. The option indicates the path of the parent directory that contains data for images, volumes, containers, networks, swarm cluster state and swarm node certificates.

One of the most significant changes in this release is the addition of support for multi-stage builds. This allows users to create Dockerfiles that pull intermediate build images that may be used to compile the final image, but which do not need to be included in the final image, itself. This can help to reduce image sizes and improve load times and performance of running containers. More information on multi-stage builds can be found in Creating Multi-Stage Docker Image Builds.

Other changes to the build environment include the ability to use build-time arguments in the form of ARG instructions in a Dockerfile, which allows you to pass environment variables into each image. FROM instructions support variables defined in ARG instructions that precede them in the Dockerfile.

Changes and improvements for Docker logging and networking are largely focused on improving Docker Swarm functionality. Numerous Docker Swarm changes and improvements have gone into this release. Customers are reminded that Docker Swarm remains in technical preview in this release.

In this release, the overlay2 storage driver is supported in conjunction with SELinux. In previous releases, the Docker Engine did not start when SELinux was enabled and an overlay file system was in use. This check has been dropped as newer kernels have support for this combination and the packages for SELinux support have been updated.

Also included in this release is the docker-storage-config utility, that can be used to help new users correctly set up Docker storage for a new installation, so that the configuration follows Oracle guidelines. See Configuring Docker Storage Automatically for more information.

Docker 17.03

Changes to the upstream Docker release cycle bring about a new versioning scheme that uses date variables (YY.MM) in the version name to indicate when a version was released upstream.

The 17.03 release includes bug fixes for the 1.13 release and does not include any major feature changes. There are several improvements to the Docker Swarm functionality.

SELinux must be set to permissive mode or disabled when running the Docker Engine while using the overlay2 storage driver.

Note that on XFS-formatted file systems, where dtype support is disabled, the default storage driver in this release is overridden from overlay2 and is set to devicemapper for compatibility reasons. Storage driver override is only implemented on fresh installations of Docker and only where the underlying file system is detected as XFS without dtype support. See Configuring Docker Storage for more information.

The upstream default storage driver for Docker was changed from devicemapper to overlay2. This change can cause problems on systems where overlay is used in conjunction with a file system that does not have dtype support enabled. Since the root partition on Oracle Linux 7 is automatically formatted with -n ftype=0 (disabling dtype support), where XFS is selected as the file system, the package installer checks the filesystem for dtype support and if this is not enabled the default storage driver is set to use devicemapper. This ensures that Docker is ready-to-use on newly installed systems and is achieved by setting the storage driver in the storage options in /etc/sysconfig/docker-storage.

It is possible to reconfigure Docker to use an alternate storage driver, by using the --storage-driver flag when running the Docker Engine daemon, or by setting the storage-driver option in the daemon.json configuration file. Oracle recommends that you use dedicated storage, formatted using Btrfs, for Docker. If you intend to use the overlay2 storage driver with an XFS-formatted file system, you must ensure that dtype support is enabled. See Configuring Docker Storage for more information. Remember that if you wish to change the storage driver from devicemapper, you must remove the option set in /etc/sysconfig/docker-storage.

Other improvements were made to the Docker remote API and to the Docker client to add consistency to the command set. Also runtime improvements were made to the Docker Engine. Further developments on Docker Swarm mode are also noted.

Docker 1.12

The focus of this release was to simplify and improve container orchestration, providing facilities such as load-balancing, service discovery, high availability and scalability out of the box. Features to handle multi-host and multi-container orchestration have been built right into the Docker Engine to allow administrators to deploy and manage applications on a group of Docker Engines called a swarm. Docker swarm mode provides much of the functionality included in the original standalone Docker Swarm service that ran separately to the Docker Engine itself and includes additional features such as built-in load-balancing. By integrating this technology into the Docker Engine, deployment of a high availability clustering technology is simplified and these features are unified within a single API and CLI. All communications within the Docker swarm are encrypted using Transport Layer Security (TLS) and cluster nodes are protected using cryptographic node fingerprint key technology to prevent node spoofing.

Important:

The Docker Swarm functionality is released as a technology preview for Oracle Linux. As a technology preview, this feature is still under development but is made available for testing and evaluation purposes.

The Docker Engine has been rearchitected to run on top of a combination of the docker-containerd and docker-runc binaries. While this change is transparent and docker commands continue to work as they did in previous releases, the underlying technology further modularizes the Docker architecture in line with the Open Container Initiative (OCI) specification. These changes open up new possibilities for container execution backends and container management, including the potential to perform engine restarts and upgrades without the need to restart running containers.

Other notable changes in this version of the Docker Engine are:

  • Experimental support for the MacVlan and IPVLAN network drivers to take advantage of existing VLAN networking infrastructure

  • Support for AAAA Records (aka IPv6 Service Discovery) in embedded DNS Server, which allows for IPv6 queries to be resolved locally without being forwarded to external servers

  • Multiple A/AAAA records from embedded DNS Server for DNS Round robin to facilitate load-balancing between containers.

  • Source the forwarded DNS queries from the container net namespace

  • Better handling of low disk space to allow the device mapper to fail more gracefully in the case where there is insufficient disk space.