Skip to content

Instantly share code, notes, and snippets.

@dezman
Last active September 21, 2019 00:10
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save dezman/59588cb70ffdf6f3dc3d144012fd8f97 to your computer and use it in GitHub Desktop.
Save dezman/59588cb70ffdf6f3dc3d144012fd8f97 to your computer and use it in GitHub Desktop.

Glossary

https://docs.docker.com/glossary/

container:

A container is a runtime instance of a docker image. A Docker container consists of

  • A Docker image
  • An execution environment
  • A standard set of instructions

image:

Docker images are the basis of containers. An Image is an ordered collection of root filesystem changes and the corresponding execution parameters for use within a container runtime. An image typically contains a union of layered filesystems stacked on top of each other. An image does not have state and it never changes.

build:

Build is the process of building Docker images using a Dockerfile. The build uses a Dockerfile and a “context”. The context is the set of files in the directory in which the image is built.

Dockerfile:

A Dockerfile is a text document that contains all the commands you would normally execute manually in order to build a Docker image. Docker can build images automatically by reading the instructions from a Dockerfile.

layer:

In an image, a layer is modification to the image, represented by an instruction in the Dockerfile. Layers are applied in sequence to the base image to create the final image. When an image is updated or rebuilt, only layers that change need to be updated, and unchanged layers are cached locally. This is part of why Docker images are so fast and lightweight. The sizes of each layer add up to equal the size of the final image.

Compose / docker-compose:

Compose is a tool for defining and running complex applications with Docker. With Compose, you define a multi-container application in a single file, then spin your application up in a single command which does everything that needs to be done to get it running.

Commands

https://docs.docker.com/engine/reference/commandline/docker/

docker ps

Lists all of your running containers.

docker info

Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 0
Server Version: 17.12.0-ce
Storage Driver: overlay2
...

docker run <imagename> [-p <publishedport>:<containerport>]

Download an image from Docker Hub and run it in a container.

docker build -t=<tagname> .

Build a new docker image from a Dockerfile with a tag of tagname, in the current directory (.).

docker container ls --all

List all of your running and non-running docker containers. Remove --all to only show running containers.

docker image ls

List all of your built docker images.

docker stop <containername>

Stops a container.

docker start <containername>

Starts a container.

docker rm <containername>

Deletes a container.

docker rmi <imagename>

Deletes an image.

docker exec [OPTIONS] CONTAINER COMMAND [ARG...]

https://docs.docker.com/engine/reference/commandline/exec/

Run a command in a running container: e.x. docker exec -it <containername> bash

Dockerfile commands

https://docs.docker.com/engine/reference/builder/

FROM<image>:<tag>

The base image to build your new image off of. FROM must be the first non-comment instruction in the Dockerfile.

WORKDIR

The WORKDIR instruction sets the working directory for any RUN, CMD, ENTRYPOINT, COPY and ADD instructions that follow it in the Dockerfile. If the WORKDIR doesn’t exist, it will be created even if it’s not used in any subsequent Dockerfile instruction.

COPY [--chown=<user>:<group>] <src>... <dest>

The COPY instruction copies new files or directories from and adds them to the filesystem of the container at the path .

RUN

Has 2 forms:

  • RUN (shell form, the command is run in a shell, which by default is /bin/sh -c on Linux)
  • RUN ["executable", "param1", "param2"] (exec form)

The RUN instruction will execute any commands in a new layer on top of the current image and commit the results. The resulting committed image will be used for the next step in the Dockerfile.

Layering RUN instructions and generating commits conforms to the core concepts of Docker where commits are cheap and containers can be created from any point in an image’s history, much like source control.

EXPOSE

Informs Docker that the container should listen on the specified network port(s) at runtime. EXPOSE does not make the ports of the container accessible to the host.

The EXPOSE instruction does not actually publish the port. It functions as a type of documentation between the person who builds the image and the person who runs the container, about which ports are intended to be published. To actually publish the port when running the container, use the -p flag on docker run to publish and map one or more ports, or the -P flag to publish all exposed ports and map them to high-order ports.

ENV <key> <value>

Sets the environment variable to the value . This value will be in the environment for all subsequent instructions in the build stage and can be replaced inline in many as well.

CMD

Has 3 forms:

  • CMD ["executable","param1","param2"] (exec form, this is the preferred form)
  • CMD ["param1","param2"] (as default parameters to ENTRYPOINT)
  • CMD command param1 param2 (shell form)

There can only be one CMD instruction in a Dockerfile. If you list more than one CMD then only the last CMD will take effect.

The main purpose of a CMD is to provide defaults for an executing container. These defaults can include an executable, or they can omit the executable, in which case you must specify an ENTRYPOINT instruction as well.

VOLUME

Creates a mount point with the specified name and marks it as holding externally mounted volumes from native host or other containers. The value can be a JSON array, VOLUME ["/var/log/"], or a plain string with multiple arguments, such as VOLUME /var/log or VOLUME /var/log /var/db.

The docker run command initializes the newly created volume with any data that exists at the specified location within the base image.

docker-compose.yml file reference

https://docs.docker.com/compose/compose-file/

The Compose file is a YAML file defining services, networks and volumes. The default path for a Compose file is ./docker-compose.yml.

Service definitions within the compose file contain configuration that is applied to each container started for that service, much like passing command-line parameters to docker container create. Likewise, network and volume definitions are analogous to docker network create and docker volume create.

build

Configuration options that are applied at build time.

build can be specified either as a string containing a path to the build context:

version: "3.7"
services:
  webapp:
    build: ./dir

Or, as an object with the path specified under context and optionally Dockerfile and args:

version: "3.7"
services:
  webapp:
    build:
      context: ./dir
      dockerfile: Dockerfile-alternate
      args:
        buildno: 1

There are many options you can pass, for example command: bundle exec thin -p 3000 would override the default Dockerfile CMD

ports

Expose ports. Either specify both ports (HOST:CONTAINER), or just the container port (an ephemeral host port is chosen).

ports:
 - "3000"
 - "49100:22"

volumes

Mount host paths or named volumes, specified as sub-options to a service.

You can mount a host path as part of a definition for a single service, and there is no need to define it in the top level volumes key.

But, if you want to reuse a volume across multiple services, then define a named volume in the top-level volumes key. Use named volumes with services, swarms, and stack files.

This example shows a named volume (mydata) being used by the web service, and a bind mount defined for a single service (first path under db service volumes). The db service also uses a named volume called dbdata (second path under db service volumes), but defines it using the old string format for mounting a named volume. Named volumes must be listed under the top-level volumes key, as shown.

version: "3.7"
services:
  web:
    image: nginx:alpine
    volumes:
      - type: volume
        source: mydata
        target: /data
        volume:
          nocopy: true
      - type: bind
        source: ./static
        target: /opt/app/static

  db:
    image: postgres:latest
    volumes:
      - "/var/run/postgres/postgres.sock:/var/run/postgres/postgres.sock"
      - "dbdata:/var/lib/postgresql/data"

volumes:
  mydata:
  dbdata:

Note: See Use volumes and Volume Plugins for general information on volumes.

SHORT SYNTAX Optionally specify a path on the host machine (HOST:CONTAINER), or an access mode (HOST:CONTAINER:ro).

You can mount a relative path on the host, that expands relative to the directory of the Compose configuration file being used. Relative paths should always begin with . or ...

volumes:
  # Just specify a path and let the Engine create a volume
  - /var/lib/mysql

  # Specify an absolute path mapping
  - /opt/data:/var/lib/mysql

  # Path on the host, relative to the Compose file
  - ./cache:/tmp/cache

  # User-relative path
  - ~/configs:/etc/configs/:ro

  # Named volume
  - datavolume:/var/lib/mysql

Docker Compose shell commands

https://docs.docker.com/compose/reference/overview/

docker-compose up

https://docs.docker.com/compose/reference/up/

Builds, (re)creates, starts, and attaches to containers for a service.

Unless they are already running, this command also starts any linked services.

The docker-compose up command aggregates the output of each container (essentially running docker-compose logs -f). When the command exits, all containers are stopped. Running docker-compose up -d starts the containers in the background and leaves them running.

docker-compose down

Stops containers and removes containers, networks, volumes, and images created by up.

docker-compose ps

Lists containers.

docker-compose exec

This is the equivalent of docker exec. With this subcommand you can run arbitrary commands in your services (defined in your docker-compose.yml. Commands are by default allocating a TTY, so you can use a command such as docker-compose exec web sh to get an interactive prompt.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment