{"id":3619,"date":"2023-09-10T07:01:58","date_gmt":"2023-09-10T13:01:58","guid":{"rendered":"https:\/\/www.mooreds.com\/wordpress\/?p=3619"},"modified":"2023-09-10T07:01:58","modified_gmt":"2023-09-10T13:01:58","slug":"docker-thoughts","status":"publish","type":"post","link":"https:\/\/www.mooreds.com\/wordpress\/archives\/3619","title":{"rendered":"Docker thoughts"},"content":{"rendered":"

Docker is amazing tech for developer productivity.<\/p>\n

You can package up the dependencies for your application into one file (a Dockerfile) or more than one file (a docker-compose file). You might use the former for an application or service and the latter if your application depends on a database, cache, or other external architectural component.<\/p>\n

I am definitely late to the Docker party, as I remember Eric Norlin interviewing Solomon Hykes in the early 2010s at Gluecon. In 2018 I used it to stand up some consulting projects, but wondered at the value and the required investment.<\/p>\n

I’ve recently been using it extensively at work to set up quickstarts. These tutorials let folks stand up our software quickly for evaluation purposes. Docker is a fantastic fit for this use case.<\/p>\n

I’ve been a big fan of detailed documentation<\/a> and readmes for setting up development environments, but Docker takes all that documentation (including tedious things like ‘install python 3.8.12. 3.8.11 doesn’t work’) and puts it into code that is accessible with single command.<\/p>\n

I have a foggy memory of detailed readmes, hours of setup and dependency hell, but Docker removes all of that. Doesn’t mean your Docker images\/compose files can’t get stale and won’t need love and attention, but it does mean you can control when you test and upgrade such dependencies, rather than discovering it when a new developer comes on the team and can’t get their environment set up.<\/p>\n

Shipping software to production via containers (Docker or otherwise) has operational benefits, but I’m less familiar with those. One of the nice things about developer relations is you’re separated a bit from operations. (It’s one of the downsides as well.) I haven’t recently worked with a production system where containers were used, but I have read nice things about the approach. Here’s an article from Google which covers the technical benefits<\/a>.<\/p>\n

What about the licensing<\/a>? This business model change rocked the world of happy Docker users, but when you take funding<\/a>, you have to make money. Actually, if you want to survive as a company, you have to make money, but if you take funding, you have to try to make a LOT of money. That’s the game, make sure you know before you start to play. But that’s a different post.<\/p>\n

As far as Docker licensing, as a Docker user, you have two options:<\/p>\n