blog

InvoiceNinja and Docker: An unexpected challenge

I’ve been delving into Docker more and more, and recently, the internal bridge networking that docker supports. This generally allows containers to have their own IP address while communicating with other containers internally, the outside network externally. Most docker-related posts and setups don’t delve too deep into this aspect of docker (that’ll be another post), but the process for me has brought on some challenges. Today, I’ll show you one.

There I was, with a license key in hand, seemingly working installation of InvoiceNinja, but the app would not activate. What gives here? As with some problems, searching on Google will only take you so far. It’s a skill to weed out the advice that will work or propel you further, versus the advice that wastes your time.

Looking deeper, I opened a terminal directly inside the container (making sure I was root in the session): docker exec -u 0 -it invoiceninja /bin/bash _ found the logs (found, relatively, in ./storage/logs/laravel-error.log) and determined that the web app was connecting to app.invoiceninja.com. Ok, so then I pinged that host and it obviously didn’t work. Pinging google.com did work, however. The hostnames were resolving, but I could not ping.

Back to the docker host machine, I did the same two pings and the same result. Why wouldn’t this machine connect? Then it dawned on me. Sometimes the answers stare you in the face.

app.invoiceninja.com resolves to 172.64.84.127 – and I had built my docker setup on the 172.64.0.0 network. Given that this was a local network internally to my container, it was not going to route outside unless I set up a new route.

Looking at my mistake here, I realized what went wrong. Docker has an internal bridge network that uses 172.17.0.0/16 – well within the standard private IP range of 172.16.0.0 – 172.31.255.255. In my haste at the time, or just not looking it up, the network I took it past 17.31 to 17.64. Outside of 17.31, I was bound to run into something out there, and clearly, it was InvoiceNinja. I was left with 18 containers running on a network that I shouldn’t be using. So I did what made sense and move all my containers on a new network.

In some cases, to help in migrating, containers would run on but networks simultaneously. Very useful for the MySQL container while others were moving and working.

After migrating all containers I was able to activate InvoicNInja’s White Label license and it was operating normally. Over the next little while, I expect to write more about this accounting tool. it’s been something I’ve worked with, fought with, and managed to get working reasonably well.