Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nix is the ultimate DevOps toolkit

tech.channable.com

Post reply on HN
Print view View original

21–30 of 243 posts

Re: Nix is the ultimate DevOps toolkit

#21

Post by microtonal »

candiddevmike wrote: post #17

The gotcha I have with Nix is it's too much abstraction. I have to look at the upstream documentation, then try and map it to Nix's config syntax, then hope everything works. Also, regarding DevOps, the tooling around Nix makes it a little brittle for anything event based--rapidly changing configurations on the fly due to network conditions (Consul, Ansible, etc). This is where configuration management is heading, an…

The gotcha I have with Nix is it's too much abstraction. I have to look at the upstream documentation, then try and map it to Nix's config syntax, then hope everything works.

For me, the big benefit is that even though I have to read the upstream documentation, I can use the same syntax for everything and do not have to learn and use N different configuration file syntaxes.

Re: Nix is the ultimate DevOps toolkit

#22

Post by kevincox »

bennyp101 wrote: post #2

As an aside, I've just started trying to move my laptop to NixOS this past week, so far it seems pretty nice. I have a Macbook as well, and I think I should be able to share the Nix stuff with that - which would be cool. As for the article, I hadn't actually considered using it as a replacement for Ansible etc - but I could see why it might work better. I could pin packages etc to the versions, and get the exact same…

I use NixOS on my laptop as well and like it. This is where the lack of polish hurts a little because desktop environments require a lot of polish to be wired up smoothly. That being said I use GNOME and the basics just work.

But on the server is where I think Nix really shines today. The biggest thing for me is that every deploy is "clean" and can be rolled back. Systems like Ansible (and basically every other config management system) only modify the part of the system that they know about and mutate global state. This means that your service might just happen to work because of a library that just happens to be installed by another service, or even on that is still installed from a service that used to run on the system. Unless you excercise Perfect Constant Vigilance and update configs to delete things instead of just removing the config to install them your configs will soon be be broken and depend on the current state of the system. I remember thinking that setting up a new VPS would be trivial since I was using Puppet (or whatever at that time) but just about every service depended on some feature that was (no longer) specified in my configs so I needed to fix my configs as I deployed the new VPS.

I wrote a blog post on each of server NixOS and desktop NixOS if you want more of my thoughts.

https://kevincox.ca/2015/12/13/nixos-managed-system/

https://kevincox.ca/2020/09/06/switching-to-desktop-nixos/

Re: Nix is the ultimate DevOps toolkit

#23

Post by duijf »

candiddevmike wrote: post #17

The gotcha I have with Nix is it's too much abstraction. I have to look at the upstream documentation, then try and map it to Nix's config syntax, then hope everything works. Also, regarding DevOps, the tooling around Nix makes it a little brittle for anything event based--rapidly changing configurations on the fly due to network conditions (Consul, Ansible, etc). This is where configuration management is heading, an…

> Also, regarding DevOps, the tooling around Nix makes it a little brittle for anything event based--rapidly changing configurations on the fly due to network conditions (Consul, Ansible, etc). This is where configuration management is heading, and due to the static nature of Nix, delegating dynamic changes is hard/anti pattern.

Channable uses Consul, Vault, etc. for dynamic configuration and it works with Nix just fine.

You don't have to use static configuration files with Nix. Either fetch dynamic stuff using the Consul, Vault, etc. APIs at runtime or use a tool like vaultenv [1] or similar if you don't want this logic in your application code.

Put those tools in your systemd service before launching your app, and you're good to go.

(NB: I was DevOps teamlead at Channable while a part of this work was being done. Sad that I haven't seen the final picture. I imagine it's lovely compared to what we had before)

[1]: https://github.com/channable/vaultenv

Re: Nix is the ultimate DevOps toolkit

#27

Post by microtonal »

alrs wrote: post #11

The merges-straight-to-master give me the willies. https://botsin.space/@complainingaboutmastercommits

Those counts seem to be wrong. Looking at the code, they seem to count the number of merge commits (commits with >1 parent). However, some nixpkgs committers also use GitHub's rebase merge option. This means the change went through a regular PR + review, but is merged without generating a merge commits. Secondly, some PRs have multiple commits, so even if everything is merged through a merge commit, the number of non-merge and merge commits may not be balanced.

Re: Nix is the ultimate DevOps toolkit

#28

Post by b0afc375b5 »

bennyp101 wrote: post #4
leetrout wrote: post #3

I am very much looking forward to trying Nix I just haven’t made the time. That being said the article jogged my memory on some related thoughts... If you’re building deb packages for your own apt repo aptly is a great tool for powering it https://www.aptly.info/ If you haven’t tried asdf for managing versions of tools it generally does what you’d expect and does it well https://asdf-vm.com/#/ It uses pyenv under the…

asdf is awesome and if you combine it with direnv you can just cd into your project and have the versions ready to go (You can do the same with nix and direnv asdf - althrough I havent got that far yet)

What's your use case for direnv? I've been using asdf and love it, but I'm not sure what to use direnv for. Is the purpose to replace .env files?

Re: Nix is the ultimate DevOps toolkit

#29

Post by bennyp101 »

candiddevmike wrote: post #17

The gotcha I have with Nix is it's too much abstraction. I have to look at the upstream documentation, then try and map it to Nix's config syntax, then hope everything works. Also, regarding DevOps, the tooling around Nix makes it a little brittle for anything event based--rapidly changing configurations on the fly due to network conditions (Consul, Ansible, etc). This is where configuration management is heading, an…

You can just point to config files as normal (which is what I do for my home files) or set them as symlinks as well - then not use the nix config.

I guess it depends on how full on nix you want to go

Re: Nix is the ultimate DevOps toolkit

#30

Post by madjam002 »

Has anyone explored CD tooling with Nix? And I don't mean the deployment of NixOS machines themselves (NixOps, deploy-rs, etc), I mean actually using Nix for deployment tooling and orchestrating deployments using the Nix language.

I am yet to find any posts about this or any tools, but have had great success with a small hand rolled tool that essentially lets me decoratively describe cloud resources, parts of my application, deployment "end state", and run the tools required to materialise that (Terraform, nixos-rebuild, etc) similar to GitHub Actions. Hydra is distributed CI for nix-build but does not handle CD or is designed to handle jobs with side effects AFAIK.

NixOS is great, but for me this is even more valuable, as I now have an introspect-able view of my entire deployed real estate, and can essentially `nix run ...` to deploy any part of my application in its entirety along with any dependencies.

Post reply on HN