Hacker News Reader

Comment by ahmedalsudani | Hacker News Reader

Allow me to offer a counterpoint.

Docker is useful for reasons besides scale. It allows you to (kind of) declaratively define your environment and spin it up in any number of different scenarios.

It allows you to ship all your dependencies with your app and not worry about getting the host machine properly configured beyond setting up Docker and/or Kubernetes.

Have other apps you want to host on the same set of machines? No problem.

When you you pair that with something like alpine Linux, you’re getting a whole lot almost for free.

View on HN

Python apps have worse performance, bigger image size and longer build times on Alpine Linux:

https://pythonspeed.com/articles/alpine-docker-python/

For running applications in production, Alpine Linux is harmful and should be avoided. Getting a smaller container image is not worth trading mucl for glibc.

To a Docker outsider, to me this implies that Alpine for testing and non-Alpine for production is not harmful. Is that right? Wasn't having a unified environment half the point of using Docker? Doesn't two different base systems just open you up to a load of headaches? If so, then isn't it more of a "Alpine Linux as a Docker base is harmful" situation?

Thank you for sharing that! It has never occurred to me but that makes sense.

For my Go/Haskell binaries, I usually do need to make changes in order to get them working. The smaller image size is essential in my use case though so I pay that penalty.

How many scenarios do you typically need to spin up your environment in?

I achieve the same (defining the environment) by pinning Python dependencies via requirements.txt and virtual environments. And I have an installation script, like a Dockerfile but just an executable bash script, that installs PostgreSQL etc, pulls the code from GitHub and starts up the server. I can upload this to a clean Debian installation to set up the server, with a well-defined stack, in minutes.

> Have other apps you want to host on the same set of machines

I don't. I just use one $5 per month Linode for each SaaS. (Or bigger Linodes as the projects get more users. My biggest single box currently serves ~100,000 users.)

> I don't. I just use one $5 per month Linode for each SaaS

Well then you're basically using VMs as your containerization mechanism, with install scripts replacing Dockerfiles.

So from your perspective, don't think of Docker as a really fat binary. Think of it as a stripped-down VM that doesn't cost a minimum of $5 per instance, and comes in a standardized format with a standardized ecosystem around it (package registries, monitoring dashboards, etc.)

It's a really fat binary that adds unnecessary layers in both dev and prod. In dev, it's faster to run tests and easier to debug without Docker. And in prod, why use a vm inside a vm?

> In dev, it's easier to debug without Docker. And in prod, why use a vm inside a vm?

On the contrary, it's easier to debug with Docker - it eliminates dangling system level libraries / old dependencies / cache, and everything is self-contained. If you have the problem in dev, you'll have it in prod as well.

Docker is not a VM, it's basically a big wrapper around chroot and cgroups, the performance hit is minimal. The advantage is that, again, it's self-contained, so there's little risk some OS / dangling library muddies the waters ( especially in Python that's a great risk -OS level python library installations are a thing, and many a Python library depend on C libraries on the system level, which you can't manage through Python tooling). It's also idempotent ( thus making rollbacks easier) and declarative.

I've never encountered this "dangling libraries" problem you describe in the past 7 years of developing web apps. I suspect you are working in different, maybe more specialised, environments than me. For me, it usually is really just pretty standard libraries and dependencies.

This is wrong. Docker is a VM on Windows at least.

Nobody is talking about Docker on Windows or Mac for production use.

Don't you think Mac are not used in Prod?

Containerisation software adds so much more than just a binary with layers of indirection.

Easy fine grain control of individual application memory, namespace isolation (container to container communication on a need to know basis), A-B testing, ease of on-boarding, multi-os development, CD pipelines, ease of container restarting etc.

I use Ansible instead Docker. It make no sense to use Docker at all. Ansible take care of all.

This is absolutely the case. IMO the main benefit provided by containerization is reproducibility. Scaling and other positives are just a product of this.

Reply on news.ycombinator.com