5 ms·
As a guy who is in no way a sysadmin but has devops experience, I thought he nailed it pretty well. Take Ansible. It is declarative: you write down the list of
by mercurial 12y ago
As a guy who is in no way a sysadmin but has devops experience, I thought he nailed it pretty well. Take Ansible. It is declarative: you write down the list of packages you expect to find on the target machine(s), and Ansible will install any that is missing. Now, you remove one of these packages from your playbook. Is it magically uninstalled from the targets? Absolutely not. Because the playbook doesn't describe the "state of the world" in its entirety. A NixOS file does that. Remove postgresql from a master NixOS configuration file? Update and no more Postgres. Because everything that NixOS manages is described (installed software, configuration, etc) (1).
1: Actually, last time I looked at NixOS, you could also install things the imperative way, but that's a silly thing to do.
- josteink 12y ago> Actually, last time I looked at NixOS, you could also install things the imperative way, but that's a silly thing to do. Actually not, because if you do, you will find these changes added to a file declaratively describing all the changes you have committed to the system (or user-context) as a whole. It's a good way to build a config if you're not fully comfortable with nix-syntax. I don't remember where the file ends up, but it is there.
- mercurial 12y ago(I'll admit that it doesn't address the point you were trying to raise rather ungraciously, namely, how well NixOS deployment tooling scale to really large deployments, which is a good question to ask).
- gfxmonk 12y agoThat's a fair question. I'll let you know if I find out ;) My hunch is that it could scale well, but would require some integration work in order to use it nicely with existing orchestration tools. I don't know exactly what that would look like, or if it would be worth the effort of going off the beaten track.
- falcolas 12y agoActually, the point is not that Nix is bad (though there are reports of packages installing things you didn't want because someone thought a dependency of the root package might need it). It's that the author doesn't have enough experience as a sysamin to speak on Nix actual strengths and weaknesses when compared to tools they don't appear to understand very well. This article is fluff because of this lack of experience; it honestly reads as another "looks at this cool thing I know nothing about!"
- mSparks 12y agoI don't get it. Stick in the CentOS CD, click install, add the root user account and password And you're done. Server up and running. done about 20 of them in the last twelve months. What's all this "package" stuff about? what's wrong with yum?
- bojo 12y agoIt's not just about installing a few packages with the package manager. You have system specific configuration, ranging from services to users to file systems and more, sometimes at odds with the state of a security patched/updated machine at any point in time. The way you configured the state of a machine 12 months ago might not be reflected when you build, update, and configure a machine today. This disconnect between installs gets compounded when you have to randomly log in and make minor tweaks to keep up with your ever-changing application specs (tweaks which rarely get documented), causing you or your successor to scratch their head wondering what steps are missing compared to before when doing a new build. This gets even more complicated when you build large clusters meant to scale, and can't afford to spend the time it takes to individually configure each machine. Orchestration aims at fixing this by giving you a way to bring the state of a freshly installed machine to the correct state of your production environment in an (ideally) consistent and repeatable manner, which is the whole point of all these fancy new products we're seeing these days.
- drinchev 12y agoYeah that's what I was doing for almost 5 years before I found Ansible. Now I even don't bother to put a CD. I go to my VPS provider and add a VPS then add my key and run an ansible playbook, which installs whatever I want, the way I wanted it. The thing with package managers is that it get's boring to do everything all over again for a large amount of servers. Also your brain memory does not have a reliable version control. You need to keep why and how you do certain stuff on your server somewhere else. First thing that comes to your mind is a shell script and people are already using something better ( ansible, puppet, etc. ). Now, with this article, I see that there is something even better than this.
- xorcist 12y agoOne reason is because there is more than one of you. By using Puppet, I never have to read my colleagues custom setup script because store it there. By checking in everything to version control, I see who has done what by reading the changelog. If you are only managing your own servers and keep a strict discipline you will see less of the benefits.
- curun1r 12y agoHe did forget to mention Terraform, a tool that suffers from none of the problems he mentioned. And I'm sure there are other DevOps tools that handle state management. All these tools have to deal with the problem of state. Most of them choose to handle it implicitly...the state of the system is the state and the tool tries to determine it at runtime. This strategy has all the problems listed in the article. Other tools attempt to keep a record of the state. This solves the issues from the article but has it's own set of issues (mostly state management and state corruption). Neither approach is objectively right and both have their tradeoffs. I honestly agree with the original, down-voted, poster...the article is a bit preachy without much insight. The rise of DevOps has turned system administration into a CS problem. And, like most other CS problems these days, it all boils down to managing state. And just like there are many approaches to state management in application architecture (RDBMS, NoSQL, Paxos/Raft, etc) where no solution is objectively right, there will be many approaches to state management in DevOps where no solution is objectively right. The author obviously has his preferences, but his analysis is biased and incomplete and should be called out as such.
- gfxmonk 12y agoOP here. I've heard of terraform, although I've not investigated it much further than that. It sounds like it's mostly a provisioning tool, and doesn't really help with configuration management once your machines exist. From the "terraform vs chef / puppet" page: > Terraform enables any configuration management tool to be used to setup a resource once it has been created. Terraform focuses on the higher-level abstraction of the datacenter and associated services [...] So it sounds like like a very nice provisioning tool, but doesn't really compete with NixOS itself. Perhaps you could even use it to provision NixOs machines?