Docker recipes

Posted: June 8, 2020 Category: backendTagged: docker

poking around

> docker version
> docker images
> docker images -a
> docker container ls
> docker ps
> docker network ls
> docker network inspect bridge

pull a standard image (eg from dockerhub)

Basically: docker pull image:tag, e:g:

docker pull postgres:12-alpine

build an image

docker build -t <tagname> .

run a container

:pencil: What the following is actually doing, is running the container with it’s default command … i.e. the last CMD directive in it’s origin dockerfile:

docker run -p <rw-port>:<c-port> --env-file .env -d <tagname>

In the above:

  • rw-port is a port number in the real world
  • c-port is the port number in container-world.
  • --env-file* allows you to pass env keys via the resident .env file in your project directory
  • -d means run in detached mode (in the background).
  • --name (not shown in example) a handy way of naming the running container so that you’re not staring at a sea of meaningless ids when working with many containers.
  • --add-host (also not show in the example, but you can use this to add a host to the containers /etc/hosts file so it knows how to reach that host)

(*) You can also pass a single env key via -e EK to just pass through a key-val pair from your .env file, or -e "EK=foo123" to explicity set a key-val pair.


run a specific command, immediately destroy container afterwards

docker run --rm <container> <cmd> <arg1> <arg2>...

run a container interactively

Most common use case is to get in via an interactive terminal and get yourself a bash prompt for noodling about:

docker exec -it <container-id> /bin/bash

attach to a container

To attach to an already-running, detached container:

docker attach <container>

Detach (and leave the container running): CTRL + (p, q)


Create a user-defined bridge network

First off, you should read: https://docs.docker.com/network/

docker network create --driver bridge <network-name>

⚠️ When you create a user-defined network and then map ports like eg pppp:nnnn where nnnn is the port inside the container. You actually still have to use the internal ports for inter-container communication!! That’s right! pppp is only for the outside world and your docker host for reaching a container. The containers themselves must chatter away on their equivalents of nnnn.


Sanity-checking a container

You probably will want to run each of these as a way of poking around and verifying that your container is still anchored in whatever portions of the real world it needs to be. :-)

> cat /etc/hosts
> ping <external-host> -c2
> printenv

killing things and mopping up afterward

> docker container stop <c1> <c2> ...
> docker container rm <c1> <c2> ...
> docker network rm <network>

so xargs came to me like a waking dream: some reptilian, ancient memory of a unix command flickered into consciousness and yielded this:

docker images --filter "dangling=true" -q | xargs docker rmi --force

oh my god it’s so beautiful I could cry! If xargs returns null tho (e.g. when thare are no dangling images left), it will faceplant. Sorry, but my ‘nix skills don’t extend far enough to account for that, lol… update silly me: docker rmi --force $(<filter-command-here>) also does the trick.

docker compose

> docker compose up
> docker compose down
> docker compose ps # ps lists containers related to images declared in docker-compose file .