3 ms·

> This can be already solved with either full system configuration (Nixos) or containers (docker-compose does pretty much that). Those are sane and structured a

> This can be already solved with either full system configuration (Nixos) or containers (docker-compose does pretty much that). Those are sane and structured as well and they're available now. Honestly, this seems like the "right" answer here. While I haven't used NixOS, I've actually described OCI containers a bit like installing apps on Android in the past - each has all of the dependencies bundled, a common API to interact with all of them, things like port configuration or just setting environment variables as well as storage with a unified mechanism, including even resource limits! Docker, Docker Compose, Docker Swarm, Hashicorp Nomad and Kubernetes (including K0s, K3s etc.), as well as more recent efforts like Podman all feel like a step in this direction, depending on what your exact needs are and how much complexity you can deal with. > Probably the closest to "just put some blocks together" you can get now are the iot fleet management services OSes like balena and others. I already run almost all of my own software in containers and so far it's amazing - I don't even care too much whether the node itself is running Ubuntu, CentOS/Rocky Linux, or even something like Alpine Linux on the server directly (which some might actually consider, because of the simplicity and lightweight nature). Throw in Ansible or something like that for making sure that the configuration is similar across all of the nodes (or groups of nodes) that you want and there's surprisingly little to worry about in the long term. Edit: though maybe I'm only able to say this because building OCI containers (say, with Docker) is actually easy, to the point where I build everything apart from databases myself, like dev images for Java/.NET/Node/Python/Ruby/PHP and the resulting software etc.

piva00 3y ago
> or even something like Alpine Linux on the server directly (which some might actually consider, because of the simplicity and lightweight nature). You are going to eventually run into the same issue most people trying to use Alpine Linux just because of simplicity and being lightweight run: musl is not a completely ABI-compatible seamless replacement to glibc and might cause issue with statically linked binaries, and other annoying issues you won't foresee. Had this "pleasure" in the past in one of my infrastructure-heavy positions.
- KronisLV 3y ago
  > You are going to eventually run into the same issue most people trying to use Alpine Linux just because of simplicity and being lightweight run: musl is not a completely ABI-compatible seamless replacement to glibc and might cause issue with statically linked binaries, and other annoying issues you won't foresee. Well, if all you need is the server to run Docker/Podman, SSH and some other limited amount of packages, it shouldn't be too bad. Of course, there are also horror stories of Alpine resulting in way worse performance in select use cases: https://github.com/docker-library/python/issues/509 https://github.com/docker-library/python/issues/509 and there's the fact that Alpine might be popular inside of containers, but way less so outside. Also, because of the short EOL cycle, I personally ditched Debian on servers (and Alpine in containers) myself for Ubuntu everywhere: https://blog.kronis.dev/articles/using-ubuntu-as-the-base-for-all-of-my-containers https://blog.kronis.dev/articles/using-ubuntu-as-the-base-fo... A bit of a polarizing move (though RPM distros aren't much better at the moment), but it seems to have worked out for me in the end. Doesn't mean that someone can't try, though, maybe their use case is suitable for Alpine.

piva00 3y ago

> or even something like Alpine Linux on the server directly (which some might actually consider, because of the simplicity and lightweight nature). You are going to eventually run into the same issue most people trying to use Alpine Linux just because of simplicity and being lightweight run: musl is not a completely ABI-compatible seamless replacement to glibc and might cause issue with statically linked binaries, and other annoying issues you won't foresee. Had this "pleasure" in the past in one of my infrastructure-heavy positions.

KronisLV 3y ago
> You are going to eventually run into the same issue most people trying to use Alpine Linux just because of simplicity and being lightweight run: musl is not a completely ABI-compatible seamless replacement to glibc and might cause issue with statically linked binaries, and other annoying issues you won't foresee. Well, if all you need is the server to run Docker/Podman, SSH and some other limited amount of packages, it shouldn't be too bad. Of course, there are also horror stories of Alpine resulting in way worse performance in select use cases: https://github.com/docker-library/python/issues/509 https://github.com/docker-library/python/issues/509 and there's the fact that Alpine might be popular inside of containers, but way less so outside. Also, because of the short EOL cycle, I personally ditched Debian on servers (and Alpine in containers) myself for Ubuntu everywhere: https://blog.kronis.dev/articles/using-ubuntu-as-the-base-for-all-of-my-containers https://blog.kronis.dev/articles/using-ubuntu-as-the-base-fo... A bit of a polarizing move (though RPM distros aren't much better at the moment), but it seems to have worked out for me in the end. Doesn't mean that someone can't try, though, maybe their use case is suitable for Alpine.