OpenShift CI/CD Concepts TODEPLETE: Difference between revisions
No edit summary |
|||
Line 1: | Line 1: | ||
=tmp= | |||
=Container= | =Container= | ||
Line 27: | Line 29: | ||
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= | =Dockerfile= |
Revision as of 23:19, 4 December 2017
tmp
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
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:
.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.