Docker

Docker is a type of virtualization for Gnu\Linux that allows processes to share similar resources, without having a full OS for each image.

General Tips

It always helps to read a book on a subject, and then keep it as a Reference. I have read Using Docker By Adrian Mouat. It is a decent book. Not bad. In fact, if you should be reading books on any subject that interests you. Physical paper books, too.

Docker is 64 bit only for i386 architecture. ARM has a separate build. There is no 32 bit i386, unfortunately.

You will want 'some' RAM. I had 1GB on a P4 machine, and that was not enough. 4GB was enough. This means go with the RPI4 2 or 4GB models.

You should always use docker compose. If you read the book above, you will understand why. Docker is possible to run on the command line (commands are somewhat complex for each container), but with a compose file, you can write everything down in a much simpler fashion. Use compose. It's a separate install, currently. Install it. Seriously, just ignore the docker command lines. I consider them useless. More of a red herring for rookies.

One of the benefits of docker, is its simplicity. There are essentially two commands you will ever need to know to use docker. Both must be run as root. One is

#docker (e.g. docker restart container\_name\_here)

. The other is docker-compose (e.g. \

#docker-compose up -d

I think I ripped this saying from what they purport of ZFS, but it applies here as well...

Docker Commands

Here are commands you need to know. Just the necessary ones.

docker-compose up -d 

Starts the containers in the docker compose file, if they aren't already started. the -d detaches from the stdout logging. You don't need to use stdout logging, you can use docker logs, but its there if you want it.

docker ps 

Lists containers running. If one fails to start, you'll see it missing from here

docker logs <containername> 

Gives you some logging output from the container. Often enough to troubleshoot.

docker exec -it <containername> /bin/bash

This will get you in a shell in the docker container. From here you can do what you need to. Most are debian, and need apt-get install less nano or whatever program you are missing. Ping is missing from possibly all containers, so if you want to test via ping, you'll have to apt-get it.

docker-compose restart 

This will restart all containers. However, I don't recommend it. Initting containers can get corrupted this way, and also its much easier to restart a single faulty container via...

docker restart <containername> 

This will restart one single container.

docker cp <containername>:/dir/to/file dest 

You can copy files from local machine to docker, or vice versa with this. Extremely useful.

Restarting Containers

Less often, you might want to know docker kill <containername> and docker rmi -f <imagename>. The first will stop a container, the second will remove an image. If you corrupt the install of a container, the second will save you. The force switch (-f) is required. Alternatively, you can just install a container of the same type with a new container name. This is a good way to test that your containers are built in a reproducible way. If you are able to rebuild them by deleting everything, then you likely won't have trouble down the road.

Specific Tips

YAML is space sensitive

When you edit the .yml file for docker-compose, you have to hit spaces in a certain pattern (tabs not allowed). This is absurd, but just be aware. The errors are cryptic, and its often just because the spacing doesn't stick to what it expects.

If you restart a containers namesake process, it will probably restart / reset the container

So if you are troubleshooting an apache container, you edit some files, then /etc/init.d/apache2 restart, uh oh... You just undid all the edits you made, if they aren't in a permanent volume. You can shell in, make edits, and then exit the shell, but a service restart often resets the container.

Consider a single reverse proxy, to handle multiple websites

There are many ways to do this. I use an nginx proxy from scratch. You can also use some containers that are built for this purpose (I personally think it's bloated but a lot of people use Jason Wilder's proxy) https://web.archive.org/web/https://github.com/jwilder/nginx-proxy - A lot of people swear by this, but I think it's straying too far to the high level.

If you use a single reverse proxy, Lets Encrypt can be done easy

In this case scenario you would have certbot on the host and a local volume that the proxy has access to which is the webroot of the Lets Encrypt scripts. The nginx proxy entry look something like this:

location ^~ /.well-known {
     alias /var/www/html/.well-known/;
      autoindex on;
    }

And this is put in every server declaration of nginx.conf. Real simple, real easy. The docker compose of the nginx proxy is something like:

nginx:
    image: nginx:latest
    container_name: custom_name_for_my_proxy
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf
      - /etc/letsencrypt/:/etc/letsencrypt/
      - ./webroot/:/var/www/html/

The volumes section is extremely simple, don't be scared. There are two entries. Local and remote. You specify what folder will be the local directory which will be cloned to the host at the remote path you specify. So, the host runs certbot at /etc/letsencrypt, and this folder is cloned to the nginx proxy container, at the same location. Finally, webroot must be set in certbot, but it prompts you for this. And if you forget or get it wrong, it can be configured somewhere in /etc/letsencrypt. it's a one liner text entry).

Give every Container a Containername

This makes it easier to refer to them later. All you need to do in the compose file is include container\_name: something. Much better than the gibberish they give these names if you don't include it.

Beware of Interrupting Initting Containers

When you first build a container, it might take 30-60 or more seconds to do whatever it needs to do. If, before then, you restart it... It may get corrupted. This has happened to me more than once. When you are testing a new container, and it doesn't seem to work for some inexplicable reason, create a container with a new name (it will create a new one), or delete the first one, and start it again.

Put Apache or Program logs from the Container in a volume that is locally accessible

This means you want a volume something like ./containerA\_files/logs:/var/www/log/apache2/ so that you can monitor the logs from your host machine easily. docker logs doesn't have everything.

Only Restart Containers you need to Restart

You can restart everything with docker-compose restart, but it's faster, and less prone to break initting containers, if you docker restart containername. Do the latter.

Volumes Mounting Over Existing Directories

As discussed here: https://web.archive.org/web/https://github.com/moby/moby/issues/4361, if you add a volume to an existing container, it will seem to delete the folder's contents. I've seen mixed behaviour with this. Sometimes it deletes it even if you start a new container with the folder... Other times it has not. In any case, just docker cp the files to the folder, then add the volume mount. This may not be the most graceful solution for upgrades, but it will work. Best practices would be here (See: dbxt commented Dec 14, 2014): https://web.archive.org/web/https://github.com/docker-library/wordpress/issues/10

If you edit a docker-compose file you must restart the container with Docker-compose

If you make a change in docker compose, you must docker stop service, then docker-compose up -d service. Otherwise the changes will not take effect. The mistake here, would be thinking that you could just docker stop service, then docker start service... That doesn't work.