←back to thread

302 points Bogdanp | 2 comments | | HN request time: 0.001s | source
Show context
ahartmetz ◴[] No.44390744[source]
That person seems to be confused. Installing a single, statically linked binary is clearly simpler than managing a container?!
replies(3): >>44390794 #>>44390802 #>>44391204 #
hu3 ◴[] No.44390794[source]
From the article, the goal was not to simplify, but rather to modernize:

> So instead, I'd like to switch to deploying my website with containers (be it Docker, Kubernetes, or otherwise), matching the vast majority of software deployed any time in the last decade.

Containers offer many benefits. To name some: process isolation, increased security, standardized logging and mature horizontal scalability.

replies(4): >>44390824 #>>44391487 #>>44391938 #>>44392268 #
adastra22 ◴[] No.44390824[source]
So put the binary in the container. Why does it have to be compiled within the container?
replies(1): >>44390937 #
hu3 ◴[] No.44390937[source]
That is what they are doing. It's a 2 stage Dockerfile.

First stage compiles the code. This is good for isolation and reproducibility.

Second stage is a lightweight container to run the compiled binary.

Why is the author being attacked (by multiple comments) for not making things simpler when that was not claimed that as the goal. They are modernizing it.

Containers are good practice for CI/CD anyway.

replies(3): >>44391150 #>>44391169 #>>44392765 #
1. MobiusHorizons ◴[] No.44391150[source]
That’s a reasonable deployment strategy, but a pretty terrible local development strategy
replies(1): >>44392368 #
2. taberiand ◴[] No.44392368[source]
Devcontainers are a good compromise though - you can develop within a context that can be very nearly identical to production; with a bit of finagling you could even use the same dockerfile for the devcontainer, and the build image and the deployed image