{"id":2212,"date":"2023-10-12T14:16:13","date_gmt":"2023-10-12T18:16:13","guid":{"rendered":"https:\/\/lowtek.ca\/roo\/?p=2212"},"modified":"2024-01-02T20:03:30","modified_gmt":"2024-01-03T00:03:30","slug":"update-managing-docker-containers-with-makefiles","status":"publish","type":"post","link":"https:\/\/lowtek.ca\/roo\/2023\/update-managing-docker-containers-with-makefiles\/","title":{"rendered":"Update: Managing docker containers with makefiles"},"content":{"rendered":"

I’ve been a bit of an old school “just use docker” vs. “docker-compose”, but it was the other day when I learned that they’ve now baked “compose” into the base docker cli.<\/a> This means there is less reason to avoid using the features of docker compose.<\/p>\n

Still, as previously discussed<\/a>, I like using Makefiles to manage my containers. There is a very good argument to adopt using Watchtower<\/a>, despite it being not recommended<\/a>.<\/p>\n

We do not endorse the use of Watchtower as a solution to automated updates of existing Docker containers. In fact we generally discourage automated updates.<\/p><\/blockquote>\n

Let me go on record that if you’re going to blindly run your update process, you may as well just use Watchtower. This is a good way to automatically break things of course, so maybe don’t auto-update things that you rely on to work (like wireguard or your web server).<\/p>\n

With that out of the way – let me point out one of the downsides to my previous Makefile approach to managing containers: I’d slowly run out of disk space with many old images<\/em>. I had gotten into the habit of running<\/p>\n

$ docker system prune<\/pre>\n
every once in a while. This would get rid of all the containers, and images, that were no longer active. It did have the downside of removing images that were not currently running – so you need to be aware of that if you had assumptions.<\/p>\n
Still my makefile approach<\/a> saved me a few times allowing me to easily re-name \/ re-run the -old<\/code> version of a container and back out of a bad update.<\/p>\n
What I needed to do was make sure that the old, -old<\/code> image was removed. This was where most of the disk space growth was. This turns out to be easier to do than to explain. Here is my update makefile<\/p>\n
#\r\n# comment\r\n# https:\/\/hub.docker.com\/r\/project\/name\r\n#\r\nNAME = containername\r\nREPO = project\/name:latest\r\n#\r\nROOT_DIR:=$(shell dirname $(realpath $(lastword $(MAKEFILE_LIST))))\r\n\r\n# Create the container\r\nbuild:\r\n        docker create \\\r\n                --name=$(NAME) \\\r\n                -p 8000:3000 \\\r\n                -e VARIABLE=true \\\r\n                -v $(ROOT_DIR)\/config\/:\/path\/in\/container\/ \\\r\n                --restart=unless-stopped \\\r\n                $(REPO) \r\n\r\n# Start the container\r\nstart:\r\n        docker start $(NAME)\r\n\r\n# Update the container\r\nupdate:\r\n        docker pull $(REPO)\r\n        $(eval IMAGEID:=$(shell docker container inspect --format '{{.Image}}' $(NAME)-old))\r\n        - docker rm $(NAME)-old\r\n        - docker rmi $(IMAGEID)\r\n        docker rename $(NAME) $(NAME)-old\r\n        make build\r\n        docker stop $(NAME)-old\r\n        make start<\/pre>\n
There are only two new lines. The first is<\/p>\n
$(eval IMAGEID:=$(shell docker container inspect --format '{{.Image}}' $(NAME)-old))<\/pre>\n
This is assigning the variable IMAGEID<\/code> to have the docker image id value from the current -old<\/code> image.<\/p>\n
The second is the obvious removal of the image based on that id.<\/p>\n
- docker rmi $(IMAGEID)<\/pre>\n
I believe that these two additional lines result in nearly no filesystem growth as I update images. Very handy as some of the linuxserver.io<\/a> images pull down ~1GB of data every time, and they are updated weekly.<\/p>\n","protected":false},"excerpt":{"rendered":"
I’ve been a bit of an old school “just use docker” vs. “docker-compose”, but it was the other day when I learned that they’ve now baked “compose” into the base docker cli. This means there is less reason to avoid using the features of docker compose. Still, as previously discussed, I like using Makefiles to … Continue reading “Update:  Managing docker containers with makefiles”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6],"tags":[],"class_list":["post-2212","post","type-post","status-publish","format-standard","hentry","category-computing"],"_links":{"self":[{"href":"https:\/\/lowtek.ca\/roo\/wp-json\/wp\/v2\/posts\/2212","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/lowtek.ca\/roo\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/lowtek.ca\/roo\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/lowtek.ca\/roo\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/lowtek.ca\/roo\/wp-json\/wp\/v2\/comments?post=2212"}],"version-history":[{"count":2,"href":"https:\/\/lowtek.ca\/roo\/wp-json\/wp\/v2\/posts\/2212\/revisions"}],"predecessor-version":[{"id":2214,"href":"https:\/\/lowtek.ca\/roo\/wp-json\/wp\/v2\/posts\/2212\/revisions\/2214"}],"wp:attachment":[{"href":"https:\/\/lowtek.ca\/roo\/wp-json\/wp\/v2\/media?parent=2212"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/lowtek.ca\/roo\/wp-json\/wp\/v2\/categories?post=2212"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/lowtek.ca\/roo\/wp-json\/wp\/v2\/tags?post=2212"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}