Docker

One thing has always bothered me while writing tests is the lack of a real datasource to run tests against. Most projects I’ve worked with in the past have either mocked responses from a datastore or used a “common” datastore to perform tests against. While mocks are good for quick unit tests, I still prefer using a “real” datasource, especially for integration tests. While taking Bill Kennedy’s Ultimate Go training a while ago, I saw Bill recommend a testing approach which involved “spinning up” a database container right from within your test code, run your tests, and clean-up. See this for reference. I love this approach. It provides a wonderful way to do everything from within go test without meddling with external scripts, thereby providing much greater interoperability. My only gripe with this is the fact that it uses os.exec to command communicate with the docker daemon. The approach is sound, however, I find forking out to use docker-cli to be a bit clunky. Docker’s client for go is pretty good and offers imho, a better way to achieve the same. It adds a dependency to the code, however, I believe that is a good thing. The real dependency here is the daemon on the underlying system. Taking a dependency in Go code, makes the management of the API easier and offers more control than relying on the cli api silently. Moreover, if you only use the dependency in your _test.go files, it won’t impact the final build binary (or that’s my understanding atleast, someone correct me if I’m wrong). In most cases the exec approach is perhaps good enough and the right thing to do, but I have an alternative. ...

So then, here is the deal. I write tiny microservices that may or may not serve any purpose. Despite how meaningless they might be, I give them the perfect operations treatment. ...

This one is a gamechanger. It really is. On a recent Golang obsessed Github browsing spree, I read the following project description: “Fast, cross-platform HTTP/2 web server with automatic HTTPS”. I’ve read that before, and more often than not ended up disappointing myself and resorting to hacks like [this] (https://blog.tux-sudo.com/posts/letsencrypt-nginx-docker/) to create an automatic TLS system for my websites. There are other ways, but almost all of them were semi-automatic in the long run (yay cron!). I decided to try out [Caddy] (https://caddyserver.com/). ...

I like nginx. I like docker. I like SSL. I also like not paying for SSL certificates. If you, like me are operating a small time website, you probably don’t want to dish out a few hundred dollars for an SSL certificate.Thankfully, LetsEncrypt provides free ssl certificates and is now trusted by most major browsers. However, integrating certbot to automatically configure my nginx inside a docker container has been a pain. In the past, I generated the standalone cert with –cert-only and then linked my docker container to use it but this was a far from usable solution given the horrid automation code I had to write. Recently, I tried to come up with a more automation friendly solution and ended up with the following: ...