Neo Kobo

Data-only Containers Container volumes are containers that store and can share data, either exclusively as with data-only containers or as a side-benefit of regular containers with mounted volumes. Data-only containers take up no more resources than needed to provide storage services. They are instantiated via docker create or the VOLUME instruction in a Dockerfile. Use docker volume create to create a volume at the command line: $ docker volume create --name vol44   The volume can be attach to a container at run-time: $ docker run --rm -it -v vol44:/cvol44 alpine sh   Volumes can also be created via the VOLUME instruction in a Dockerfile : FROM alpine VOLUME /data55 Describe the intent of the following commands: $ docker build -t vol45:01 . $ docker images   $ docker inspect b159452444cb $ docker run

Container Data Volumes Docker data volumes allow data to: persist after the container is exited, removed or deleted be shared between the host and the Docker container be shared with other Docker containers It allows directories of the host system, managed by Docker, to be mounted by one or more containers. It's simple to setup as you don't need to pick a specific directory on the host system A use-case for Volumes is as a way to share directories across containers Simple example: $ docker run --rm -i -t -v /data/vol01 debian bash This creates a volume /data/vol01 and makes it available to the container The container volume, /data/vol01 , maps to a directory on the host file system. You can get the location via the $ docker inspect command. Look in the Mount section for the Source name/value pair:

Mount host directory as a Data Volume Docker allows you to mount a directory from the Docker host into a container. Using the -v option, host directories can be mounted in two ways: using an existing host volume , e.g. /home/john/app01, or a new auto-generated volume on the host, e.g. /var/lib/docker/volumes/53404f432f0…. Mount an existing host volume in the container: $ docker run -v /home/john/app01:/app01 -i -t busybox In this example, the -v parameters are: /home/john/app01 -- Docker host volume : -- a single colon /data -- container path where the host volume will be mounted Any existing files in the host volume (/home/john/app01) are automatically available in the container mount point, /app01 To maintain portability, you cannot map a host directory to a container via the Dockerfile, as this specific directory may not be available on another host where the Dockerfile is

Named Volumes: Host and Container Data Volumes Docker does not support persistent data by default, i.e. container filesystem changes do not persist across container restarts. A named volume is a mechanism for decoupling persistent data needed by your container from the image used to create the container and from the host. Named volumes persists even when no container is currently using it. Data in named volumes can be shared between a container and the host machine, as well as between multiple containers. Docker uses a storage driver to create, manage, and mount volumes. Volumes enable persistent data storage in a container environment Volumes are directories that are stored outside of the container’s filesystem and hold reusable and shareable data that persists even after a container is terminated. There are three ways to create volumes with Docker: Map a host directory as a volume to a container

Storage Driver A storage driver is how docker implements a Union File System File System choices include: AUFS (default on Ubuntu), Device Mapper (default on Red Hat and Centos), btrfs, OverlayFS, VFS, ZFS,… AUFS AUFS is a unification filesystem AUFS stacks multiple directories on a single Linux host and exposes them as a single unified view through a single mount point To achieve this, AUFS uses a union mount. The directories in the stack, and the union mount point, all must exist on the same Linux host AUFS refers to each directory in the stack as a branch. AUFS supports the copy-on-write (CoW) technology oldest driver, default for Ubuntu, file level operation (CoW operations copy entire files) runs at native speeds, leverages memory sharing and scales well not well suited for working with large files (databases, logs, etc.)

Union File System (or UnionFS) A file system that amalgamates a collection of different file systems and directories (called branches) into a single logical file system. It allows files and directories of separate file systems, to be transparently overlaid, forming a single coherent file system Docker uses Union File System (UnionFS) to combine multiple layers that make up an image into a single Docker image Enables implementation of a modular image, that can be de/constructed as needed, as opposed to a monolithic image Layers are always read top-to-bottom. If an object is found in a top layer and subsequent lower layer, only the top layer object is used supports copy-on-write and read-only or read-write branches Variants of the Union File System includes: AUFS (Advanced multi layered Unification File System), btrfs, VFS, DeviceMapper References https://en.wikipedia.org/wiki/UnionFS

Copy on Write In the Copy-on-Write (CoW) strategy, system processes that need the same data can share the single instance rather than creating their own copies. If one process needs to modify a file in the shared data, the storage driver makes a copy exclusively for that process. The other processes continue to use the original data. A key benefit of the CoW strategy is optimizing image disk space usage and container start times. Provides a link to the original data (in a read-only layer), on modification the data is first copied to the current (read-write) layer. If a change is made to the file system, a copy of the affected file/directory is "copied up" from the 1st read-only data it is found in, into the container read-write layer. A copy-up operation can incur a noticeable performance overhead: large files, lots of layers, and deep directory trees can make the impact more noticeable

Docker Tag A tag is simply an alphanumeric identifier attached to the image, and used to distinguish one image from another A tag name must be valid ASCII and contain lower or uppercase letters, digits, underscores, periods and dashes The nginx repository on the official Docker registry contains multiple images. Note that the same image may have multiple tags, e.g. the alpine stable image has three tags (:1.10.3, :stable, :1.10) that all point to the same image. One way to verify that two or more images are identical is if they have the same SHA256 digest. All three tags of the alpine stable image have the same SHA256 digest: f829870f13c0b5471083fb59375fd914cf2597d814175bf1b7e868e191be210b Note: if you run $ docker pull nginx you get the “ latest ” image, which happens to be in the mainline tree. I.e. the above command does the equivalent of $ docker pull nginx:latest The latest tag applie

Identifiers A Docker Container can be identified in three ways: long form UUID  (Universally Unique Identifier), a short form UUID and by  Name . Identifiers help prevent naming conflicts and facilitate automation. UUID U niversally U nique Id entifier Assigned to a container on creation. UUIDs come in two forms: a 64 character long form , e.g. “f78375b1c487e03c9438c729345e54db9d20cfa2ac1fc3494b6eb60872e74778” an abbreviated 12 character short form , e.g. “f78375b1c487” automatically generated and applied by the Docker daemon Identifiers are commonly displayed in a truncated 12-character form Name A container name is generated and automatically assigned Generated name format: <adjective>_<notable names> On the left a list of strings, approximately 90 adjectives On the right a list of approximately 150 "notable" scientists and hackers M

Docker Registry A service that hosts repositories and provides an HTTP API to a distribution service for image upload and download Can be public or private, can be Cloud or server based Docker Hub A registry of Docker images A repository of available Docker images API used to upload and download images and implements version control Official site is hub.docker.com Here's an example of downloading (pulling down) the alpine image from the Docker Hub via the command line: Docker Store A Registry of official Docker images Self-service portal where Docker partners publish images and users deploy them the next-generation Docker hub Official site is store.docker.com Private Registry Local repository Third-Party Registry Providers may provide their own registry sites, e.g. the one by Red Hat References Docker Hub/ Docker Store/ https://access.redhat.com/c

Layers Docker images are read-only templates from which Docker containers are instantiated. Each image consists of a series of layers . Docker uses a union file system to combine these layers to form a runnable file, referred to as a Docker image . Layers are discrete entities, promoting modularity and reuse of resources. Each layer results from an instruction in the Dockerfile . Layers represent filesystem differences The Docker storage driver is responsible for stacking these layers and providing a single unified view. Note: Image layer IDs are cryptographic hashes, while the container ID is a randomly generated UUID. Each instruction in the Dockerfile creates a new layer. Note: only non-zero layers and layers that do not already exist on the system are downloaded with the docker run command. Below is repo information for this nginx image on GitHub . There are