I have a confession to make: my Meteor app, in production for more than 2 years, has no tests. So today I embarked on a journey to change that, starting with the basics: unit tests (no integration, no end-to-end yet). Read on if you’re in the same boat!
In the grand JavaScript tradition, we first need to choose our library before we can do anything. I went with Jest, because it seems like the growing consensus according to the State of JavaScript 2018 (plus Facebook, podcasts, zeitgeist, gut feeling, yada yada).
tl;dr: OVH Failover IPs are an essential and cheap part of ensuring your recovery goes well for the users. You just need to add a specific config file to your CoreOS servers
Last Sunday, one of our servers suffered a severe outage, caused by multiple hardware failures at our hosting provider (OVH). We deployed a recovery server, and everything was ready for our users… except their firewall team had only white-listed our (now dead) production server, and it took them half a day to allow access to our second server.
So we set out to solve that issue, and it…
tl;dr: when mounting volumes in Kubernetes, they have to match the dockerfile VOLUME directives exactly, or you’ll regret it later…
I’ve been a happy docker and docker-compose user, mounting host volumes liberally both in development and production to nicely separate data (which I need to backup) from executable code (which is built automatically from git). I’m now migrating my platform from docker-compose on bare metal to a Kubernetes cluster.
The process was pretty easy, except one little “surprise” that cost me many hours. The symptom was simple: I was mounting the same volume on two containers on the same pod…
tl; dr: Traefik dashboard is awesome, but a few steps are required to securely deploy it.
(edit on 2019/06/24: note that the below applies to Traefik v1, the current stable one. Traefik v2, currently in alpha, has a very different configuration.)
A quick bit of context: I recently switched the reverse proxy for my docker-compose stack from nginx to Traefik. This was a breeze, except that the Traefik dashboard is by default accessible to the whole internet, unencrypted. Finding out how to secure it was a surprisingly long journey.
What I started with:
- a docker stack
- with a running Traefik…
tl;dr; for regular development use, buy a 17" gamer laptop (like my own MSI GS73VR 7RG Stealth Pro) not an ultra portable.
At AssetSagacity, we strongly believe you need the best tools to do your best work. So when we started co-working, I went looking for the best laptop to supplement my trusty home-made Linux power desktop.
My requirements were simple:
- I do most of my work in docker, so I needed a Linux laptop.
- My previous experience installing Ubuntu on the desktop was great, except for the WiFi part of it: I tried 3 different adapters on my desktop…
tl;dr: if you use docker with single file volume bindings, you need to instruct your IDE / text editor to save files in-place. Otherwise, your containers won’t see your updates until you restart them.
You’re happily working in your docker environment, for example modifying a local config file and reloading your dockerized servers (say, Apache). Then you notice something strange: your updated configuration has no effect on your server. You add a vhost, reload apache, but nothing happens. Frustrated, you restart your docker containers, and lo and behold, it now works. Then you tweak your file, reload apache, and nothing…
Hey, seems I’m bad at blogging but good at getting (and solving) weird Docker error message, so here goes:
You’re happily developing with docker, but suddenly your docker-compose build commands start giving you errors:
ERROR: Couldn't connect to Docker daemon - you might need to run `docker-machine start default`You know docker is there, you’re using it right now! docker ps works fine, so what gives? Well, it appears you also get this message when you don’t have the permission to read some files in your docker build context! Just run docker build . and you’ll get a clearer error message (hopefully).
If it is indeed unreadable files, then add them to your .dockerignore, or just change their permissions.
Problem solved, back to happy dockering.
Well, this just cost me several hours, and I couldn’t find it anywhere else, so let’s start this blog with a note to self:
- If you’re doing some docker stuff (like building an alpine image) and your docker build fails with some DNS error
- but your host has no issue resolving the names
- and your
/etc/resolv.confin both environments look fine (= they are just a list of nameservers) - then validate each DNS entry:
dig google.com @ip.of.your.nameserver - and remove any non-responding entry!
In my case, my last nameserver entry was incorrect, which my host computer had not issue with, but blew up my docker build process every time.
