My Docker Workflow

Why should I even leave Emacs? · April 11, 2020

Ever since finding Docker containers a couple of years ago I've been using them obsessively. Even this blog runs inside of a Docker container. I like many others, could wax poetic on how amazing this technology is. No longer do we need to rebuild entire servers to accomplish simple service configurations! No longer must I fret about a specific server failing and needing to be rebuilt just to hot some web service. I don't even necessarily need to worry about what distribution the host is running if I keep all of my configuration down to the pure minimum needed to run Docker containers, and secure the host server itself. It is absolutely delightful!

To that point, I find myself more often than naught rebuilding containers for long standing projects, such as the CI I run to build Alpine Linux packages. And boy, does it get tedious running docker build -t durrendal/container:tag over and over in various directories. For my APK CI, mrbuildit, I have five different variants alone. One for each of the CPU architectures I typically build packages for. Which means five different directories for specific Docker builds. Five different build & push calls. And 9 times out of 10, I find myself loading the Dockerfile in Emacs just to make sure everything still makes sense before I push it.

A less than ideal workflow, but if I'm already inside of Emacs, can't I just fix that? Just throw together a little bit of elisp, slap it in the old .Emacs file, and voila!

(defun build-and-ship (contname tag)
  (interactive "sEnter Container Name: \nsEnter Container Tag:")
  (switch-to-buffer "Docker Build Status")
  (insert (shell-command-to-string (concat "/usr/bin/docker build -t durrendal/" contname ":" tag " .")))
  (insert (shell-command-to-string (concat "/usr/bin/docker push durrendal/" contname ":" tag)))
  (switch-to-buffer "Docker Build Status"))
(global-set-key (kbd "C-c bs") 'build-and-ship)
  

An easy solution to a self inflicted problem. It would be nice to have a live return of the command output, but getting the build log after the fact works well enough for me. It at very least takes out the drudgery of things, which allows me to better focus on more important things, like compiling SBCL 2.0.3 for Alpine (hopefully this time with arm aarch64 support!).

Even just writing these blog posts, that little snippet of elisp comes in handy. Since the blog is dockerized I usually just cd into the project directory, add my post info into posts.lua and write the post. When I'm all done the push to production is a simple C-c bs lambdacreate latest away.