2 ms·
i'm not really in the workstation provisioning industry so i can't comment on the article, but i've used salt, puppet, etc in provisioning servers and have foun
by kbar13 6y ago
i'm not really in the workstation provisioning industry so i can't comment on the article, but i've used salt, puppet, etc in provisioning servers and have found that declarative configuration management is surprisingly complex and has a lot of pitfalls and is deceptively hidden behind the "look how simple it is to install a package". declarative languages for config management imo was a mistake, because in order for it to be truly declarative, every part of the system (including preinstalled software) needs to be managed by the config management tool. otherwise stuff like "i pushed a diff to remove the block where i asserted this package to be installed but the package is still installed on the hosts" will continue to surprise newish users. stuff like cdk works because, as stated earlier, it asserts the desired state of every piece of infrastructure it manages
a better alternative would instead be something akin to Dockerfiles where you assert what packages you want to be installed on top of a base system, and if you want anything changed you update the dockerfile and rebuild the whole shebang.
i'm imagining a system where the local filesystem is more or less immutable and work is saved to separate filesystem. but having worked from computer labs in schools, i know how less than ideal that is when i need to use a program that isn't preinstalled to do my work, so maybe this all doesn't work and saltstack is a necessary evil
- outworlder 6y ago> a better alternative would instead be something akin to Dockerfiles where you assert what packages you want to be installed on top of a base system, and if you want anything changed you update the dockerfile and rebuild the whole shebang. Something like Packer? You are right that there are hidden pitfalls. But they shouldn't be a great deal if servers are cattle. A lot of corner cases are related to trying to manage servers that live forever. This shouldn't really be done in 2021 except in rare cases. > i'm imagining a system where the local filesystem is more or less immutable and work is saved to separate filesystem CoreOS worked like that. Immutable filesystem for the system itself. It also had a secondary "mirror" of this filesystem that was used for upgrades (and as a fallback in case boot failed). New stuff would either come when the instance first booted up (cloud-init), or via system upgrades. They were acquired and so my experience with them ended there. There's also https://nixos.org/ https://nixos.org/