New around here? You may want to catch up:
Before switching to OS X, I was running Ubuntu codename whatever and had my
local system built out as close to my production environment as possible.
I would install nginx, Apache, MySQL, Redis, Memcached, PHP and whatever the
hell else I needed to be functional. It was very painless as everything was a
sudo apt-get install ... away.
One of my contingencies for moving to OS X was that I would be able to develop
locally in the same way I did on Linux. There was no way I would develop inside
of a virtual machine.
There was a small bit of a learning curve since I was quite the OS X newbie. I
figured out how to get things up and running with Homebrew, but for the most
part is was painless.
That said, Homebrew is a piece of shit and I missed apt every time I had to
use it. Don’t get me started on Apple making changes to OS X that would fuck up
Homebrew.
Moving back to Linux, I assumed I would be able to revert to my old ways and be
back in action. This was only sort of true.
In the time since I switched away from Linux, some libraries ended up being
updated. Specifically lib-curl which ended up causing me problems with one of
the projects I hack on.
The issue is that an older npm package, node-curl, which the
project relied on was coded against an older version of lib-curl.
No big deal, fork it, fix it, get back to work.
This got me thinking, this will probably happen again in the future and I need a
better way to work on projects that rely on older libraries.
At the time I was having issues, macOS Sierra was fairly new any the folks that
had upgraded to it weren’t having any issues with the project dependencies the
way I was. That was until we onboarded a new developer.
As a new developer, he needed to set things up from scratch and did not have the
core of our codebase built yet. Upon doing so, he ran into the same issue I did
and fortunately my fork of node-curl worked for him.
Building the entire system isn’t something we do regularly, so it’s not
surprising that folks that had upgraded to Sierra hadn’t run into issues. Now my
fleeting thoughts of tomorrow’s problems were my main focus.
What’s a guy to do? Mess with all the things, of course!
I messed with Docker (in a un-Docker-like way) but wasn’t really sold on it.
Then I messed with Vagrant and was even less sold on it. Then I decided to drink
the Docker-aid and go about things the way Docker intended.
When I say I went about Docker in an un-Docker-like way, I am referring to
attempting to build out a single container that did it all. Web server,
database, cache datastore all in one container. This resulted in needing to get
systemd working in the container.
This ended up being a clusterfuck and a half considering I didn’t have much
experience with Docker and was learning as I went.
Reapproaching things with an open mind about needing to have multiple
containers, I was able to get things up and running fairly easy. There are still
things that I wish Docker did, like being able to mount a volume during the
container build, but otherwise, smooth sailing.
What’s been great about Docker is that I can better match my containers to the
production environments. Those dependency issues I talked about earlier are no
more.
I have since converted a few other projects of mine to use Docker. Not all of
them though, for somethings it’s just overkill and I’m cool with just running
stuff locally. This blog, which runs on Jekyll and is hosted on GitHub Pages, is
a good example of a project that I don’t want to pollute with Docker.
Even though I am now using Docker for some of my more complex projects, I still
have absolutely no desire to run Docker in production. It just doesn’t make
sense to me as I can run older LTS releases of Ubuntu and avoid dependency
issues.
In scenarios where production doesn’t match my local system, Docker will
absolutely be a part of my toolchain for local development.
Until something better comes along, of course 😉
Next: Part 5: The Conclusion
