> docker version > docker images > docker images -a > docker container ls > docker ps > docker network ls > docker network inspect bridge
docker pull image:tag, e:g:
docker pull postgres:12-alpine
docker build -t <tagname> .
: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-portis a port number in the real world
c-portis the port number in container-world.
--env-file*allows you to pass env keys via the resident .env file in your project directory
-dmeans 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.
docker run --rm <container> <cmd> <arg1> <arg2>...
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
To attach to an already-running, detached container:
docker attach <container>
Detach (and leave the container running):
CTRL + (p, q)
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.
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
> docker container stop <c1> <c2> ... > docker container rm <c1> <c2> ... > docker network rm <network>
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 up > docker compose down > docker compose ps # ps lists containers related to images declared in docker-compose file .