Hacker News Reader

Comment by jhardy54 | Hacker News Reader

> I believe a tool like asdf would also achieve this (correct me if I'm wrong).

This is true for very simple applications, where you’re just running `npm ci` or `pip install`, but breaks down as soon as you have sophisticated dependencies with system / library requirements or dependencies (e.g. databases, caches, message brokers, queues) that are beyond the scope of asdf.

Also, since you’re probably deploying containers to production, it’s useful to have a similar environment for local development so that you know what will actually happen in production.

View on HN

Best dev setup I've seen has been to use Docker compose for all of those dependencies, but just use asdf for the main application development. You get all the dependency wins of Docker for the peripherals but with the faster native local dev experience.

> since you’re probably deploying containers to production

Citation needed I feel - I’d wager the number of containerized deployments pales in comparison to the number of binaries scp’d into a production host.

I’d also be interested to know the answer!

I said “probably” because the vast majority of deployments I’ve done over the past decade have been containerized, but I have no trouble believing that my experience isn’t indicative of the average.

Absolutely.

Docker is NOT about local dev, it's about deployment.

We forgot this...

> Docker is NOT about local dev, it's about deployment.

I mean... if Vagrant can be about local development, I don't see why Docker can't be about local development too.

It can be anything you want it to be, especially inside the confines of your own setup.

Do you want to quickly debug some software that relies on an older version of Postgres 9 but you don't want to clutter your host machine? Just run the following command to fetch and start an instance. With --rm flag it's going to be removed as soon as you terminate it:

docker run --rm -p 5432:5432 postgres:9

It can be.

But that was never the primary purpose of Docker. Like I can use Mac Minis as door stops, etc.

Docker runs best on top of Linux. As in actually run a Linux host , everything else in my experience is a hack. As long as you have internet access, spinning up an ec2 instance to test stuff shouldn't be too hard.

> Also, since you’re probably deploying containers to production, it’s useful to have a similar environment for local development so that you know what will actually happen in production.

This such a complete and utter lie and I'm surprised people in 2022 still believe it.

You do know what's happening when you run Docker on your Macbook, right? Right?

Ignoring your tone, here’s a concrete example: I was debugging a HTML-to-PDF service that was crashing for some payloads, but I couldn’t reproduce the problem locally.

I used Docker to run the application using the exact same image that was deployed to production, and was able to replicate the issue.

Why? Because the PDF renderer depended on loads of finicky dependencies (e.g. linked libraries), and it turns out that the default fonts in our base image didn’t support the Unicode code points in the example payload. I couldn’t replicate this outside of Docker because I have a completely different set of linked libraries and don’t stack.

Happy to answer any questions you have.

you always have that option though and i assumed it was a fairly common debug thing to have to do if you use docker enough. not just for the times it works (ie you find a bug between the layers) but for all the times it isn't the culprit.

the other post mentioned setup, so i thought he meant they imposed presetup containers for developers to use?

> You do know what's happening when you run Docker on your Macbook, right?

A Linux vm spawns a process with new namespaces - which is often exactly what happens in production as well.

Reply on news.ycombinator.com