OpenShift CI/CD Concepts TODEPLETE: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
No edit summary
No edit summary
Line 27: Line 27:


Also see {{Internal|Docker - Start a Container Automatically|Start a Container Automatically}}
Also see {{Internal|Docker - Start a Container Automatically|Start a Container Automatically}}
=Dockerfile=
A Dockerfile defines how a container should look at build time, and it contains all the steps that are required to create the [[#Layered_Image|image]]. Each command in the Dockerfile generates a new layer in the [[#Layered_Image|image]]. The Dockerfile is an argument (possibly implicit, if present in the directory the command is run from) of the [[docker build|build]] command. For more details, see: {{Internal|Dockerfile|Dockerfile}}
=.dockerignore=
Contains files and directories that won't be uploaded to the docker host when the image is built.
=Backends=
==Storage Backend==
Containers and the images they are created from are stored in Docker’s ''storage back end''. The Docker server's storage backend communicates with the underlying Linux filesystem to build and manage the multiple [[#Layered_Image|image layers]] that combine into a single [[#Container_Image|image]]. The storage backend provides a fast CoW (copy-on-write) system for image management.
Backends:
* [[Docker AUFS Storage Backend|AUFS]]
* [[Docker BTRFS Storage Backend|BTRFS]]
* [[Docker device-mapper Storage Backend|device-mapper]]
* [[Docker overlayfs Storage Backend|overlayfs]]
==Loopback Storage==
The default loopback storage, while appropriate for proof of concept environments, it isn't for production.
=Mounted Volumes=
Defined by the Dockerfile [[Dockerfile#VOLUME|VOLUME]] directive.

Revision as of 22:59, 4 December 2017

Container

  • Physically, a container is a reference to a layered filesystem image and some metadata about configuration (environment variables, for example). A running container has a name and a tag. The tag is generally used to identify a particular release of an image.
  • A specific container can only exist once.
  • Privileged container.
  • Any output directed to stdout in a running container is captured in a log file that can be viewed with docker logs command.
  • Containers are ephemeral. Any in-memory state is lost when the container stops. When a container is deleted, any data written to the container’s file system is deleted as well.

Restart Policy

The container's restart policy specifies how container are restarted when the docker server is restarted. It is maintained in /var/lib/docker/containers/<container-id>/hostconfig.json as:

{ ... "RestartPolicy":{"Name":"no","MaximumRetryCount":0}, ... }

Note that the json file must not be edited directly. If the restart policy has to be changed, that must be done with docker update.

The policy for a specific container can be retrieved with docker inspect.

Also see

Start a Container Automatically



Dockerfile

A Dockerfile defines how a container should look at build time, and it contains all the steps that are required to create the image. Each command in the Dockerfile generates a new layer in the image. The Dockerfile is an argument (possibly implicit, if present in the directory the command is run from) of the build command. For more details, see:

Dockerfile

.dockerignore

Contains files and directories that won't be uploaded to the docker host when the image is built.


Backends

Storage Backend

Containers and the images they are created from are stored in Docker’s storage back end. The Docker server's storage backend communicates with the underlying Linux filesystem to build and manage the multiple image layers that combine into a single image. The storage backend provides a fast CoW (copy-on-write) system for image management.

Backends:

Loopback Storage

The default loopback storage, while appropriate for proof of concept environments, it isn't for production.


Mounted Volumes

Defined by the Dockerfile VOLUME directive.