Nix does not do distributed deployment (multi-host) [of applications/containers], I use Kubernetes for that. So I use Nix for the host (servers, workstation), development environment and containers. But not for deployment beyond a single host.
I run NixOS on my desktop and laptop and I like it a lot, but I'm not comfortable enough with the Nix language to really use it effectively for building my own packages and environments yet, it has quite a steep learning curve.
@sligit oh yeah. It has a very steep learning curve if you want to go beyond simple use cases. For me it works well since I'm not building packages or doing anything "fancy". I use it almost exclusively as ephemeral ebbs for tooling (not apps).
Viktor - your use case is the exact same use case I have had teaching students and nix has become a foundation in the platform I am building. Love hearing your experience!
Nix is amazing good. I have been using to synchronize all my 24 hosts, host K3s, and to generate containers. Yes! Nix generates containers that are equal bit by bit no matter in what environment. And in a declarative manner!
Nix unifies the software stack. The dependency chain is same be it on a host, server and containers. Nix builds once. Then, you can re-use the artifact/cache everywhere. Also supports Musl. It can generate container images smaller than Alpine when using NixNG.
Nix is awesome, switched to NixOS on everything, doing local dev with Nix and custom modules, doing CI with Nix and Gitlab through a custom module, etc. I want Nix everywhere, it's extremely nice as a developer to be able to configure and "program" everything, like writing custom modules etc.
nice video. I've been using nixOS for a few months now and as a developer it simplifies my workflow significantly and for all of the languages and frameworks I use. no more worry about version conflicts. one thing I was going to mention about nix and build environments in containers, I would absolutely reduce the size of all ontainers by volume mounting the nix store.
Nix has it's own CI called Hydra for continuously building Nix packages. Hydra can upload to a S3 storage, then you consume Nix packages from binary cache (S3, etc). Hydra is a bit more clever when building packages because it sends individual packages to cache instead of doing full builds and only then sending to cache. This is helpful when having lots of builders building simultaneously. It is possible to re-use cache early. I'm unsure if Nix without Hydra does that too.
At work we use nix flakes in each repo defining tools (and specific versions) required for deploying and working on what's in the repo, e.g. terragrunt, terraform, kubectl, etc. Overall it's been handy, We've considered moving to containers instead for that use case, but since it works it's not a high priority, and doubtless there are pain points we'd run into.
There is a lot of work still to be done on making every development environment work well with Nix But the great thing is that once you get something setup and working, it is very easy to publish that code so others can use it too.
Wow this is insane! I do some contracting on the side and often have to download various software to work on different projects (I cant imagine how much random clutter I have rn), this can greatly simplify my workflow for different clients. Then once the project is done clean up is super simple!
That's my primary usage of Nix. Spin up what I need when I need it and destroy it once I'm done. Since everything I work on is in a Git repo, I just keep `shell.nix` in each and start my working session with `nix-shell`.
❤ Wow, very nicely done and what a great find! I can tell you times when my world changed, VMWare, docker, lambda, python virtual environments, and now NIX shell! This is indeed, a game changer, thank you for making this video and sharing it with all of us! I am now subscribed to your channel with notifications, enabled, and of course, thumbs up! Thank you, Ernie in Pennsylvania
I was talking with my team about Nix right before this video went up. It's an incredible piece of tech. I'm exploring how to separate runtime dependencies and build artifacts using nix flakes; this might also make a good video. Well done.
Thanks for another great video! Generally speaking I find this approach good whenever you want to have your tools with you to do something ephemeral, the CrossPlane course example is nicely fitting here. In that case the container approach may be overkilling. I even think that there are similarities here with the container based approach, like you have to install nix on the host, you still have a local cache of what you install, and so on. My preference still goes to containers whenever you're able to define a set of tools that you always use for some reason, for example when preparing a develoment environment. Containers in my opinion are great to enable remote development with tecnologies I use, like devcontainers and DevPod. Certainly I woudn't use them to run pipelines locally!
I agree. When working remotely, containers are a better choice. But, when local work is in wurstion, i switched fully to nix, except for the apps themselves.
Leaving a lot of comments on your vids lately.. I’m really getting into Nix and ephemeral shells and environments because of your videos and it’s a great solution for a problem that has existed like forever. Why is nobody using it? I quickly pitched it to a team of devs I’m working with and some were interested and others just made fun of it… I’ll slowly adopt it further until I find the reason why nobody else is using it 😅
I'm not sure that "nobody" is using Nix. I feel that the number of Nix users is steadily growing. I might not be as mainstream as, let's say, Kubernetes, but it's getting there.
Nix makes it totally easy to make portable OS agnostic development environments everywhere as well. I have a folder where I'm teaching myself GoLang by building a web CMS app/framework and I can use my Mac or Windows (running WSL) or even in a NixOS VM. So whenever I have some free time, Just pop into one of the environments, do a git sync, tinker and code, git sync and done!
I've been using this for a while now for work stuff. The other important thing can be to get everyone using the same versions of things. You can do this with flakes. The file is flake.nix, inside you define one or more devenvs, and the command is nix develop. The first time you do this you get a lock file that specifies the versions.
Amazing content! Thank you for sharing! I recently started exploring nix and I think this is pretty exciting for the reason you mentioned in the beginning - keep the mac virgin and lightweight. I am curious about mixing nix with tmux and nvim.
This was the best Nix tutorial I have seen so far, and I have given up on a couple of them. I was really excited until I saw Windows requires WSL2. As a minority linux user I often want to share my TTPs with my majority Windows colleagues but if they have to install WSL I might as well stick to containers.
I think that WSL is a must, no matter whether one uses Nix or not. Most of what we do is on Linux and being able to be in a similar environments as production is important. On top of that, trainings, tutorials, scripts, etc. (almost) always assume that one is using Linux or Unix . MacOS is essentially a UI on top of Unix. There are many other reasons but it all boils down to Linux/Unix being a standard. WSL is, in my opinion, the most important addition to Windows. P.S. I rarely use Windows myself so I might be completely wrong on that one.
@@DevOpsToolkit WSL + the 'Windows Terminal' store app. But people are so lazy or so hard to make make a change of what they are used to... I'm tired talking colleagues into start using WSL, tired of seeing someone going VS Code + PS for terminal - it's beyond me why it's so big of a hesitation for most people ..
@@DevOpsToolkit WSL + the "Windows Terminal" app from the store! Mentioning it here as I know some people have never heard of it, and IMO this is the closest you can get to a real Linux multitab terminal. WSL also pairs nicely with VSC with the WSL extension which is another "a must" .
Nix is first and foremost a language of the functional kind, which just so happens to be able to build and install packages. Now cover flakes, you'll love them, honestly. Reusable Nix.
I like to think of nix as being primarily a software deployment model. As per Eeclo’s thesis. The nix language is just a (partial) means of realising this model. You could create and build derivations without using nix language at all. tweag’s blog post: “NIX - TAMING UNIX WITH FUNCTIONAL PROGRAMMING” is a good, and relatively short exposition of the core ideas
In the context of local development, sure you may not need containers. But I think you'll agree that containers are still very much desirable for other things.
Absolutely. All my apps run as containers in production and since i ephemeral environments to be as close to production as possible, apps are always in containers. I do not use Nix to run my apps. I use it to get the tooling required to work on a project.
I would not compare it with immutable infrastructure. I use Nix to generate local environments, mostly focused on tools I need. My apps are still running in containers which are running in Kubernetes in one of the hyperscalers.
Great video, though I wanted to know, what do I do if I want to install a tool of a specific version? For example if I want my shell to have go version 1.20 (not the latest), how do I specify that?
You can specify versions but, before you do, I strongly suggest checking devbox (there is a video on this channel). It greatly simplifies versioning and quite a few other things related to nix packages.
Wow this changes everything! BUT....there is 1 major flaw. I started setting up my configs and immediately noticed that there is no real way to specify the package version. For example, I need an older version of the Velero cli to match the version of Velero running on the cluster, however nix does not seem to have anything like velero:1.9.4. And no, I don't want to go to lazamar and specify the tar hash in my configs for each package.
so if you take a look at the nix package repository in a lot of cases you'll see the mainline package having a bare name, "python" for example which is currently at version 3.11 and different versions having different package names, like "python312" for the release candidate version. when you're building your shell.nix obviously you can use those packages, but if your needed version doesn't exist, then you may need to create your own nix repository. then it becomes as simple as copying one of the other build expressions, updating the source location and hash (which nix-build does for you) and giving it a package name that matches the version. then all you have to do is specify that channel in your nix shell script and you're good to go. it's really not as bad as it sounds
Nix is awesome and there is a newer way of doing this (different, not specifically better) using just the `nix` command. However, it might be an issue for your purposes because by default the commands are not enabled.
The idea is cool, cgroups and namespaces should be enough to have an isolated and reproducible ci. Also LXD containers. But they're still not useful for a mature CI environment where you need to integrate with an IDE for building and debugging code, export artifacts like reports, security scanning and signing immutable layers. Are they going in this direction with Nixos?
Assuming that you're talking about local IDE, Nix Shell works like any other Shell and everything you're normally using in an IDE should still work. P.S. That video is all about Nix Shell, not NixOS.
I'm not sure I understood. Why would you use an IDE in pipelines (CI)? Independently of that... If you do use Nix in Pipelines, it is effectivelly a replacement for containers (for tools, not apps).
@@DevOpsToolkit I mean we need the same tool with same settings to be available as in the ci pipeline as in the development process ( integrated with the Ide possibly) as we do today with docker. I don't know if today this is already possible to replace with nix ecosystem.
@alessandro-affinito you're right. If everything needs to be exactly the same, you need to choose one of those (Nix or containers) and use them everywhere. That will also mean that you will not be able to use IDE for any tasks. If everything needs to be exactly the same and given that IDEs are silly to use in pipelines, they are out as well. Personalky, I think those are extremes that are not beneficial.
My fear of using this shiny new ways of installing packages/environments is that I never know if I'm stalling a compromised version of the package. I still prefer to install something the way the producer recommends rather than a more practical, well intentionned packager. But maybe I'm just paranoide. Containers at least are a little bit sepparate from your OS, nix shell looks like python virtual environments, a workaround with PATH. Anyway, thanks for the video.
I don't think that this has been stated explicitly...nix provides truly reproducible build environments (which containers typically don't/can't). Nix is not a deployment tool. It can produce a Docker image without needing a Dockerfile. Then you deploy with k8s or podman (or docker itself if you must ;-) Docker and nix are different tools for different purposes. Nix is for consistent builds and dev environment.
My recommendation would be to do neither. Build images with what you need and use them in pipelines. They are well equiped to use containers. Switch to nix if that is not an option (which is rarely the case).
Struggling to understand something - I see how nix-shell can standardize development environments across developers (awesome) but then when it comes time to replicate the same environment on production machines, how would one do this without also running prod in nix (likely not great / isolation etc?) Very interested in this tool - thank you.
I do not use Nix to create environments where apps are running. I use Kubernetes, preferably remote, for that. My use case for Nix is to standardize tooling I need for developement. For example, the project I'm working on right now, needs `gum`, `git`, `gh`, `helm`, `kubectl`, `kind`, `yq`, `jq`, `bat`, `buildpack`, and `aws`. Instead of having all those permanently installed on my laptop, I just enter the directory with the repo and execute `nix-shell` which picks up those tools from the `shell.nix` file in that same directory. On top of those, it is, at least for me, extremely useful when experimenting. Instead of constantly accumulating new CLIs instelled with `brew` and, probably, left on my laptop forever not matter whether I use them or not, I just pull them into `nix-shell` session and `exit` when finished. In other words, `nix-shell`, in my case, is not a replacement for app environments but, rather, a temporary env. that brings me all the tools I need. On top of that, anyone who wants to work with me on the same project can just start a `nix-shell` session without having to worry whether he or she has the tools I use.
@@DevOpsToolkit thanks for keeping me on the rails. We've struggled for long enough with unification of development environments and runtime environments that my brain didn't recognize the contrast between the tooling bits and the runtime bits. I can see how this would be extremely valuable for that. Presently we use docker to handle rt environment but do nothing for tooling. I'll be considering that now that I'm presently and consciously aware of that divide. Thanks again
Hi Viktor. I'm curious about something in your demo. You were using "kind" in your nix-shell, but I didn't see you also add Docker to the package list for the nix-shell environment. Does nix-shell install Docker as a dependency to "kind"?
I've been hearing about Nix for a while now and love the appeal. However, I see a lot of similarities to cloud- init. Not necessarily the ephemeral stuff, but more the reproducibility via a central config. It seems you can create ephemeralility via a cow file system with snapshotting capabilities but of course would have to roll up the solution yourself to leverage cloud-init. Curious what your thoughts are. Have been really appreciating your channel and videos. Also heard you as a guest on the Dev-Ops Podcast. Thanks for your content!
I tried nixos 4 years ago and was basically just confused. I got kubernetes to work on it but due to it not using standard paths longhorn didn't work. So I put it away. But now there's a lot more tutorials available for it and I'll try again to daily drive it.
Longhorn works fine in NixOS. The solution for that problem is simple: Just extend PATH environment variable this way: "PATH: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/run/wrappers/bin:/nix/var/nix/profiles/default/bin:/run/current-system/sw/bin" I usually use Kyverno for that.
@@SuperHeroINTJ that's cool, this workaround wasn't available then - but I switched to Talos for K8S deployment now already, which just recently got longhorn support :)
there's a fundamental aspect completely missing in your video: versioning... does nix-shell support package versioning? How can i use a fixed nodejs or java or anything else version? at work we use various script with asdf to allow this kind of setup, with specific versions based on the directory you go into, thanks to direnv... and we had to take care of fixing the asdf azure-cli plugin because it didn't work anymore after python update to 3.11, for example...
One of nix's strengths is the granularity of it's pinning... not only version level but commit level. Dockerfiles are convenient but don't ensure true reproducibility while building a Docker image with nix does (no apt install/update stuff...)
I know Nix and I've always wondered if we should use a Nix-based container image, or a scratch-based container image with a static nix-shell (if that's even a thing), for example for pipelines. I still have no solid conclusion
I really like nix containers for some uses, but I'm still new to them - can nix environments block access to the computer, I'm more and more using containers and have zero dev tools on my host because I can't trust the package maintainers to not be crooked or get hacked. Especially with the npm/node.js ecosystem, my new dev box has zero node.js /npm/yarn etc on the host.
You need to trust someone or something. If you're using containers as a way to install tools, you still have packages either through base images or by adding `apk install` or whatever you might be using. Unless you are using Linux on your laptop, those containers are running in VMs which is isolated but you are probably mounting volumes and processes so it's not bullet proof either. At the end of the day, you need to trust something unless you're willing to inspect the code of whatever you're using.
@@DevOpsToolkit I've been a long time linux user, for 30 years or so. So I know the foundations of trusting trust. I'm careful about what to trust and NPM/Node.js have proven to me, that they are not trustworthy at a rate that is high enough to just give them access to my machine. I expect that docker and the container ecosystem that is powered by the linux kernel to be robust enough to prevent the random arbitrary code from encrypting the entirety of my harddrive and returning it for the cool sum of a single bitcoin. I know that it will not stop an exfiltration bot or a crypto miner from running I never allow the docker socket to be mounted, so they cant use that to elevate privileges and I'm aware there could be bugs that get exploited overall I don't mind random code running on my machine so much as I just don't want it to screw over my day. I'm just worried about the liability of lost productivity due to something malicious happening to the data on my computer. The policy of 'default to everything open' was design of the past, and should be considered deprecated at some cost but not all costs.
I love the concept of Nix. But for some reason I personally struggle with getting everything working as I want. Probably because I’m so used to Arch, and recall much from Debian and Red Hat, and Nix is a total departure from those. Maybe one day I’ll get good with Nix. It does in fact appear to be superior.
You can specify a version so instead of `normalPackages.nodejs` you can set it to `normalPackages.nodejs-12_x`. As for how up-to-date packages are... It depends on maintainers of a specific package (just as anything else in open source depends on maintainers). My personal experience is that packages are up-to-date most of the time, sometimes one version behind, and rarely old.
so I'm assuming that Nix would only be able to handle stuff that is command line driven in nature, it won't be able to do stuff with like GUI IDEs, correct? Say for example if I was using PyCharm and I wanted to use Nix to install a whole bunch of tools, there wouldn't be anyway to get PyCharm to use those tools installed by Nix? Like a specific version of Python say or c compilers etc.?
In my very limited experience with Nix, I solved this by installing my IDE in the nix shell and then running it from the nix shell itself. I don't know if a better option exists.
How do you compare Nix versus DevContainers? Can Nix help with the problem of enabling repo maintainers to declaratively set the development environment for anyone who cloned and attempts to build the repo source?
Nix excels at this. By using a shared nix config all developers are ensured the EXACT same environment, fully provisioned, with a simple command. Docker containers are good for deployment/distribution and can be used to share dev environments but that's what nix is best at. You used the word "declare" which hits the nail on the head: nix is declarative while containers are imperative.
I tried Guix after using Nix for about a year, and it turns out that at least for me that guix was a gateway drug to more lisp. 7 years on guix now, and I'm addicted.
What about networking? nix or guix solves development environmenk in terms of libraries and dependencies, but one of containers appeal that you can create complicated stacks with private networking for dev, test, production environments....
For me, Nix can never replace app environments simply because they need to mimic production as much as possible and that means either kubernetes or cloud services like Google Cloud Run. The part of nix that i am using is related to tooling using for development but does not go to production.
I'm still not convinced that this can replace containers. I see in this video that I can come up with a file that gives the users a set of programs that are required in the environment. What I don't see is how the configuration of those programs can be used as well. Your statement about "oh-my-zsh" custom prompt tells me that the base operating system's configuration is used in the nix shell. What should I do if I want the environment to have its own zshrc file without bothering the user's configuration?
I don't think it is replacing containers for running apps but, rather, for tools needed locally or in pipelines. Also, I would recommend devbox instead of using nix directly.
I decided against using devbox. I was looking for an alternative to using a container. I'm not sure how janky the solution is but what worked for me is setting the $HOME variable to the directory that runs the nix shell. I had to do it shellHook.
@@DevOpsToolkit I did not. When I loooked into devbox, it just seemed like an addiitonal layer over nix that doesn't immeidately address my initial concern with Nix itself so I just explored a solution without it.
Looks very interesting. You say it will allow windows, macOS and Linux devs to work on the same repo in the same env, but what about a repo that uses symlinks?
A case (for me) of using symlinks would be one repo with one directory for front-end and one for backend and then having shared types files between them
As far as the pipelines goes, why not just have your pipeline cache/restore that nix cache? Then you have a really clean setup that replicates your local dev without having to potentially manage both solutions depending on the context.
I think I have a better solution which I'll explore in a video in a couple of weeks 🙂 What i was trying to say is that I'm not sure that rewriting pipelines to nix provides enough return of investment. For new ones it is a good option.
Very interesting, haven't dug into Nix yet, thanks for the intro. On a separate subject, I'm hoping you'll be talking about Apple's new Pkl language and how it compares with Cue for managing Kubernetes manifests. I've been meaning to dig into Cue, based on your past recommendations, but now I'm curious whether it makes more sense to look at Pkl. It sounds quite promising.
That is indeed one of the big difference. Personally, i prefer CUE immutability but I also recognize that is one of the reasons for CUEs steeper learning curve.
Going in, I'm hoping you will compare nix to what I would naturally turn to: devcontainer and devpod. (Is nix the emacs of k8s?) After watching, it will be interesting, for me at least, to find out how wrong I was going in. Nix runs as non-root with seccomp restrictions?
Nix is many things but, in my case, it is first and foremost a way to start a shell with all the tools i need without installing any of them on my machine. Devpod is, essentially, a VM.
You said don't use nix for CI/CD pipelines, use containers. Agreed. You should rebuild those. But couldn't you just use nix in the container build? That way your dev and CI/CD environments use the same setup?
@@DevOpsToolkit lol. After writing that comment, I saw your devbox video and have spent the last 24 hours rebuilding all my workspaces with devbox. I think I'm in love. I haven't tried the devcontainer/codespaces stuff yet but that will be huge.
This doesn’t address the problem of differing or missing library versions, which is why containers are a thing. If anything the ephemeral-ness of containers is a problem.
Assuming that you're referring to tools we're using while developing and not libraries in app code (as what I shown in the video), you can pin them to any version you need.
I would not recommend nix as a destination for your apps. Use kubernetes for that. I use Nix as ephemeral environments for the tools i need, not for the apps.
@@DevOpsToolkit I think you should explore Nix for building containers. That is a very valid use case. And common too. And dependencies can be shared with shell. So it is less work than having to double package it for Dockerfile & Alpine.
@@DevOpsToolkit Sorry, I meant what is the nix way of setting up ssh or secrets to access other resources from a nix shell. For example does my ssh config used for github or a bastion host persist across nix shells?
@hambroman yes it does persist. I think you're mixing OS with Shell. If i would create a new VM with NixOS, if would need new keys and what so not. However, I was just switching from one Shell, from zsh, to another, to nix-shell.
Assuming that you are using windows or macos, containers are running in a VM and that complicates things like, for example access to binaries you already have installed, filesystem, local network, etc. Nix Shell is just a shell like bash or ish with the additional abilities to temporarily install additional packages.
Ok but file systems and local networks can be mounted/exposed in containers. Access to other binaries on the system kind of goes against the notion of "isolated environments" as well.@@DevOpsToolkit
@shazmailz you're right, but i think we're talking about different types of environments. I guess you're referring to preview environments like those you would spin up when creating a PR while I'm talking about a way to create an ephemeral environment that will bring me all the tools i need while working in my laptop. In that case, i am not concerned about isolation and i still run my apps as containers one way or another. What i was talking about is s way to bring in all the tooling i need (e.g. kubectl, jq, yq, g loud, etc.) in a way that is not permanent. I got sick of having thousands of random binaries/CLIs floating around my laptop, many of them to be used sporadically, some even never again. When i execute brew list, I do not even recognize more than half of the output.
I'm still confused as to the difference/advantages. This is exactly how I use a Dockefile that can be built according to local context, filesystem mounted, run interactively or truly ephemerally (one command at a time), using just what is needed from the host environment, and deployed to pipeline. Requires the same number of prerequisites on every host system (including WSL on Windows). And you can deoloy the same image to CI/CD, no duplication. I see no effective difference but I know i must be missing something.
@BDnevernind I'm was not talking about the pipelines but the tools (CLIs) you need while working (e.g. kubectl, yq, jq, helm, nodes, etc.). Are you spinning containers for those while working on your laptop?
I'm confused ... Isn't nix a stand-alone OS? How'd you install it? You create a virtual machine with nixOS installed? obviously, not. Cause, I'd be easier to install docker and be given a container. Got to be missing something.
One of the confusing things about nix is what the hell it is 😊. Nix is both a package management system and a scripting language which can be installed on any OS. NixOS is an operating system built with nix but you don't need to run NixOS to use nix.
Nix is indeed very confusing. It has a very steep learning curve and, as you said, it is too many things at once. Personally, I use it only as a package manager where those packages can be installed anywhere and are ephemeral in natuve. I don't use it directly but through Devbox (video is coming up tomorrow).
Going to the website to create repos always annoyed me. With the CLI I can just `"git repo create" and I don't have to open my browser. Plus other conveniences.
What do you think of Nix? Can it replace containers on your laptop (for tools, not apps)?
Nix does not do distributed deployment (multi-host) [of applications/containers], I use Kubernetes for that. So I use Nix for the host (servers, workstation), development environment and containers. But not for deployment beyond a single host.
I run NixOS on my desktop and laptop and I like it a lot, but I'm not comfortable enough with the Nix language to really use it effectively for building my own packages and environments yet, it has quite a steep learning curve.
@SuperHeroINTJ I do not use Nix to run apps. That's where kubernetes excels. I use it as ephemeral environments for tools i need.
@sligit oh yeah. It has a very steep learning curve if you want to go beyond simple use cases. For me it works well since I'm not building packages or doing anything "fancy". I use it almost exclusively as ephemeral ebbs for tooling (not apps).
@@DevOpsToolkit Yeah it's great for that.
I'm loving the fact that someone is finally speaking about this! ❤
Viktor - your use case is the exact same use case I have had teaching students and nix has become a foundation in the platform I am building. Love hearing your experience!
Nix is amazing good. I have been using to synchronize all my 24 hosts, host K3s, and to generate containers. Yes! Nix generates containers that are equal bit by bit no matter in what environment. And in a declarative manner!
Nix unifies the software stack. The dependency chain is same be it on a host, server and containers. Nix builds once. Then, you can re-use the artifact/cache everywhere. Also supports Musl. It can generate container images smaller than Alpine when using NixNG.
A video which addresses more Nix features would be awesome.
Nix is awesome, switched to NixOS on everything, doing local dev with Nix and custom modules, doing CI with Nix and Gitlab through a custom module, etc.
I want Nix everywhere, it's extremely nice as a developer to be able to configure and "program" everything, like writing custom modules etc.
nice video. I've been using nixOS for a few months now and as a developer it simplifies my workflow significantly and for all of the languages and frameworks I use. no more worry about version conflicts. one thing I was going to mention about nix and build environments in containers, I would absolutely reduce the size of all ontainers by volume mounting the nix store.
Please pin this
Nix has it's own CI called Hydra for continuously building Nix packages. Hydra can upload to a S3 storage, then you consume Nix packages from binary cache (S3, etc). Hydra is a bit more clever when building packages because it sends individual packages to cache instead of doing full builds and only then sending to cache. This is helpful when having lots of builders building simultaneously. It is possible to re-use cache early. I'm unsure if Nix without Hydra does that too.
Finally, an explanation of Nix package manager that I can understand. Thank you so much for this video.
At work we use nix flakes in each repo defining tools (and specific versions) required for deploying and working on what's in the repo, e.g. terragrunt, terraform, kubectl, etc. Overall it's been handy, We've considered moving to containers instead for that use case, but since it works it's not a high priority, and doubtless there are pain points we'd run into.
Thank you for the amazing video. Your ability to showcase the tool while teaching how to use it is truly a superpower!
There is a lot of work still to be done on making every development environment work well with Nix But the great thing is that once you get something setup and working, it is very easy to publish that code so others can use it too.
Wow this is insane! I do some contracting on the side and often have to download various software to work on different projects (I cant imagine how much random clutter I have rn), this can greatly simplify my workflow for different clients. Then once the project is done clean up is super simple!
That's my primary usage of Nix. Spin up what I need when I need it and destroy it once I'm done. Since everything I work on is in a Git repo, I just keep `shell.nix` in each and start my working session with `nix-shell`.
Also kinda nice to use the nix dockertools to build your container images.
❤ Wow, very nicely done and what a great find! I can tell you times when my world changed, VMWare, docker, lambda, python virtual environments, and now NIX shell!
This is indeed, a game changer, thank you for making this video and sharing it with all of us!
I am now subscribed to your channel with notifications, enabled, and of course, thumbs up!
Thank you,
Ernie in Pennsylvania
I was talking with my team about Nix right before this video went up. It's an incredible piece of tech. I'm exploring how to separate runtime dependencies and build artifacts using nix flakes; this might also make a good video. Well done.
Very interesting. I really like that they are solving this problem. Thank you for sharing!
Thanks for another great video! Generally speaking I find this approach good whenever you want to have your tools with you to do something ephemeral, the CrossPlane course example is nicely fitting here. In that case the container approach may be overkilling.
I even think that there are similarities here with the container based approach, like you have to install nix on the host, you still have a local cache of what you install, and so on.
My preference still goes to containers whenever you're able to define a set of tools that you always use for some reason, for example when preparing a develoment environment.
Containers in my opinion are great to enable remote development with tecnologies I use, like devcontainers and DevPod.
Certainly I woudn't use them to run pipelines locally!
I agree. When working remotely, containers are a better choice. But, when local work is in wurstion, i switched fully to nix, except for the apps themselves.
@@DevOpsToolkit sorry I didn't notice that you already wrote "except for the app themselves" before! I agree this is a better approach
From experience, nix in theory works great, in practice most Nix users spend their weekends configuring/fixing Nix.
Leaving a lot of comments on your vids lately.. I’m really getting into Nix and ephemeral shells and environments because of your videos and it’s a great solution for a problem that has existed like forever. Why is nobody using it? I quickly pitched it to a team of devs I’m working with and some were interested and others just made fun of it… I’ll slowly adopt it further until I find the reason why nobody else is using it 😅
I'm not sure that "nobody" is using Nix. I feel that the number of Nix users is steadily growing. I might not be as mainstream as, let's say, Kubernetes, but it's getting there.
Nix makes it totally easy to make portable OS agnostic development environments everywhere as well. I have a folder where I'm teaching myself GoLang by building a web CMS app/framework and I can use my Mac or Windows (running WSL) or even in a NixOS VM. So whenever I have some free time, Just pop into one of the environments, do a git sync, tinker and code, git sync and done!
That's my favorite use case. Put nix shell file into a repo and everything i need to work on it is there.
I've been using this for a while now for work stuff. The other important thing can be to get everyone using the same versions of things. You can do this with flakes. The file is flake.nix, inside you define one or more devenvs, and the command is nix develop. The first time you do this you get a lock file that specifies the versions.
This great video rekindled my interest in Nix. Thank you so much!
Amazing content! Thank you for sharing! I recently started exploring nix and I think this is pretty exciting for the reason you mentioned in the beginning - keep the mac virgin and lightweight. I am curious about mixing nix with tmux and nvim.
Nix looks like a great tool for ex2 based automations.
This was the best Nix tutorial I have seen so far, and I have given up on a couple of them.
I was really excited until I saw Windows requires WSL2. As a minority linux user I often want to share my TTPs with my majority Windows colleagues but if they have to install WSL I might as well stick to containers.
I think that WSL is a must, no matter whether one uses Nix or not. Most of what we do is on Linux and being able to be in a similar environments as production is important. On top of that, trainings, tutorials, scripts, etc. (almost) always assume that one is using Linux or Unix . MacOS is essentially a UI on top of Unix. There are many other reasons but it all boils down to Linux/Unix being a standard. WSL is, in my opinion, the most important addition to Windows.
P.S. I rarely use Windows myself so I might be completely wrong on that one.
@@DevOpsToolkit WSL + the 'Windows Terminal' store app. But people are so lazy or so hard to make make a change of what they are used to... I'm tired talking colleagues into start using WSL, tired of seeing someone going VS Code + PS for terminal - it's beyond me why it's so big of a hesitation for most people ..
@@DevOpsToolkit WSL + the "Windows Terminal" app from the store! Mentioning it here as I know some people have never heard of it, and IMO this is the closest you can get to a real Linux multitab terminal. WSL also pairs nicely with VSC with the WSL extension which is another "a must" .
Nix is first and foremost a language of the functional kind, which just so happens to be able to build and install packages. Now cover flakes, you'll love them, honestly. Reusable Nix.
I like to think of nix as being primarily a software deployment model. As per Eeclo’s thesis. The nix language is just a (partial) means of realising this model. You could create and build derivations without using nix language at all. tweag’s blog post: “NIX - TAMING UNIX WITH FUNCTIONAL PROGRAMMING” is a good, and relatively short exposition of the core ideas
Nix is very good, and Nix Shell is a killer feature. Wish more OSS supported it to make contributing easier to get started with.
I would love to see this catch on.
I've been running nixos on one of my machines for a month/so and I love the implications on sscm this ecosystem has
In the context of local development, sure you may not need containers. But I think you'll agree that containers are still very much desirable for other things.
Absolutely. All my apps run as containers in production and since i ephemeral environments to be as close to production as possible, apps are always in containers. I do not use Nix to run my apps. I use it to get the tooling required to work on a project.
@@DevOpsToolkit it's just that the title made it seem like one doesn't need containers at all :)
@ekolteenarp true. I should change it.
fantastic video and explanation, many thanks.
Great Vid. Would love to hear more about why Docker was a no go VS nix pkg mgr vs Distrobox
Thanks for this!
big nix fan
Nix is great, Nixos is even better
it's like virtual environment but for the shell .. very nice. this seems to be a great tool for managed/hosted development environments.
First time viewer, recommended by the algorithm. I subscribed :)
The nix hash bang thing is the killer feature here... Love that!
Odlican video i kanal, ne znam kako tek sad nailazim na njega! Pozdrav :)
Very keen to know your thoughts on comparing this approach with immutable infrastructure. Great video by the way!
I would not compare it with immutable infrastructure. I use Nix to generate local environments, mostly focused on tools I need. My apps are still running in containers which are running in Kubernetes in one of the hyperscalers.
That intro goes way harder than expected
Love your work, can you please share your advice on a backup strategy for kubernetes ? I’m hearing good things about Velero.
Adding it to my to-do list...
Great video. Thanks
Great video, though I wanted to know, what do I do if I want to install a tool of a specific version? For example if I want my shell to have go version 1.20 (not the latest), how do I specify that?
You can specify versions but, before you do, I strongly suggest checking devbox (there is a video on this channel). It greatly simplifies versioning and quite a few other things related to nix packages.
Wow this changes everything! BUT....there is 1 major flaw. I started setting up my configs and immediately noticed that there is no real way to specify the package version. For example, I need an older version of the Velero cli to match the version of Velero running on the cluster, however nix does not seem to have anything like velero:1.9.4. And no, I don't want to go to lazamar and specify the tar hash in my configs for each package.
so if you take a look at the nix package repository in a lot of cases you'll see the mainline package having a bare name, "python" for example which is currently at version 3.11 and different versions having different package names, like "python312" for the release candidate version. when you're building your shell.nix obviously you can use those packages, but if your needed version doesn't exist, then you may need to create your own nix repository. then it becomes as simple as copying one of the other build expressions, updating the source location and hash (which nix-build does for you) and giving it a package name that matches the version. then all you have to do is specify that channel in your nix shell script and you're good to go. it's really not as bad as it sounds
Nix is awesome and there is a newer way of doing this (different, not specifically better) using just the `nix` command.
However, it might be an issue for your purposes because by default the commands are not enabled.
thank you for the very informative video!
The idea is cool, cgroups and namespaces should be enough to have an isolated and reproducible ci. Also LXD containers.
But they're still not useful for a mature CI environment where you need to integrate with an IDE for building and debugging code, export artifacts like reports, security scanning and signing immutable layers.
Are they going in this direction with Nixos?
Assuming that you're talking about local IDE, Nix Shell works like any other Shell and everything you're normally using in an IDE should still work.
P.S. That video is all about Nix Shell, not NixOS.
@@DevOpsToolkit sry I meant nix shell for the CI and nix Flakes for the CD
I'm not sure I understood. Why would you use an IDE in pipelines (CI)? Independently of that... If you do use Nix in Pipelines, it is effectivelly a replacement for containers (for tools, not apps).
@@DevOpsToolkit I mean we need the same tool with same settings to be available as in the ci pipeline as in the development process ( integrated with the Ide possibly) as we do today with docker.
I don't know if today this is already possible to replace with nix ecosystem.
@alessandro-affinito you're right. If everything needs to be exactly the same, you need to choose one of those (Nix or containers) and use them everywhere. That will also mean that you will not be able to use IDE for any tasks. If everything needs to be exactly the same and given that IDEs are silly to use in pipelines, they are out as well.
Personalky, I think those are extremes that are not beneficial.
My fear of using this shiny new ways of installing packages/environments is that I never know if I'm stalling a compromised version of the package. I still prefer to install something the way the producer recommends rather than a more practical, well intentionned packager. But maybe I'm just paranoide. Containers at least are a little bit sepparate from your OS, nix shell looks like python virtual environments, a workaround with PATH. Anyway, thanks for the video.
I don't think that this has been stated explicitly...nix provides truly reproducible build environments (which containers typically don't/can't). Nix is not a deployment tool. It can produce a Docker image without needing a Dockerfile. Then you deploy with k8s or podman (or docker itself if you must ;-)
Docker and nix are different tools for different purposes. Nix is for consistent builds and dev environment.
Very nice! Would you suggest using nix when building pipeline containers vs doing apt-get installs and lots of other makeshift things?
My recommendation would be to do neither. Build images with what you need and use them in pipelines. They are well equiped to use containers. Switch to nix if that is not an option (which is rarely the case).
Quality content
Struggling to understand something - I see how nix-shell can standardize development environments across developers (awesome) but then when it comes time to replicate the same environment on production machines, how would one do this without also running prod in nix (likely not great / isolation etc?)
Very interested in this tool - thank you.
I do not use Nix to create environments where apps are running. I use Kubernetes, preferably remote, for that. My use case for Nix is to standardize tooling I need for developement. For example, the project I'm working on right now, needs `gum`, `git`, `gh`, `helm`, `kubectl`, `kind`, `yq`, `jq`, `bat`, `buildpack`, and `aws`. Instead of having all those permanently installed on my laptop, I just enter the directory with the repo and execute `nix-shell` which picks up those tools from the `shell.nix` file in that same directory. On top of those, it is, at least for me, extremely useful when experimenting. Instead of constantly accumulating new CLIs instelled with `brew` and, probably, left on my laptop forever not matter whether I use them or not, I just pull them into `nix-shell` session and `exit` when finished.
In other words, `nix-shell`, in my case, is not a replacement for app environments but, rather, a temporary env. that brings me all the tools I need. On top of that, anyone who wants to work with me on the same project can just start a `nix-shell` session without having to worry whether he or she has the tools I use.
@@DevOpsToolkit thanks for keeping me on the rails. We've struggled for long enough with unification of development environments and runtime environments that my brain didn't recognize the contrast between the tooling bits and the runtime bits.
I can see how this would be extremely valuable for that.
Presently we use docker to handle rt environment but do nothing for tooling. I'll be considering that now that I'm presently and consciously aware of that divide.
Thanks again
Actually starts at 5:00.
Wondered when you would cover this :)
Hi Viktor. I'm curious about something in your demo. You were using "kind" in your nix-shell, but I didn't see you also add Docker to the package list for the nix-shell environment. Does nix-shell install Docker as a dependency to "kind"?
It does not work with Docker. I do not use Nix Shell for any non-cli app like VSCode, Slack, or Docker, but only for CLIs.
@@DevOpsToolkit I see. So, to use Kind while in a nix-shell, you also need to install Docker separately (outside of nix-shell) on the host, right?
@easmithdev i think so. I haven't tried to run docker through nix so i might be wrong.
I've been hearing about Nix for a while now and love the appeal. However, I see a lot of similarities to cloud- init. Not necessarily the ephemeral stuff, but more the reproducibility via a central config. It seems you can create ephemeralility via a cow file system with snapshotting capabilities but of course would have to roll up the solution yourself to leverage cloud-init. Curious what your thoughts are. Have been really appreciating your channel and videos. Also heard you as a guest on the Dev-Ops Podcast. Thanks for your content!
I tried nixos 4 years ago and was basically just confused. I got kubernetes to work on it but due to it not using standard paths longhorn didn't work.
So I put it away. But now there's a lot more tutorials available for it and I'll try again to daily drive it.
Longhorn works fine in NixOS. The solution for that problem is simple: Just extend PATH environment variable this way: "PATH: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/run/wrappers/bin:/nix/var/nix/profiles/default/bin:/run/current-system/sw/bin" I usually use Kyverno for that.
NixOS K3s has been well maintained. @euank did good work there.
@@SuperHeroINTJ that's cool, this workaround wasn't available then - but I switched to Talos for K8S deployment now already, which just recently got longhorn support :)
What about kernel and os arch type bindings? More on shift left / true devops point of view
there's a fundamental aspect completely missing in your video: versioning...
does nix-shell support package versioning? How can i use a fixed nodejs or java or anything else version?
at work we use various script with asdf to allow this kind of setup, with specific versions based on the directory you go into, thanks to direnv... and we had to take care of fixing the asdf azure-cli plugin because it didn't work anymore after python update to 3.11, for example...
Yes it does support versioning.
One of nix's strengths is the granularity of it's pinning... not only version level but commit level. Dockerfiles are convenient but don't ensure true reproducibility while building a Docker image with nix does (no apt install/update stuff...)
Nice tool! really eager to start using it and see use cases. It would work with packages that requires sudo priviledges?
Yeah. It's essentially a (more powerful) Shell.
I know Nix and I've always wondered if we should use a Nix-based container image, or a scratch-based container image with a static nix-shell (if that's even a thing), for example for pipelines. I still have no solid conclusion
I really like nix containers for some uses, but I'm still new to them - can nix environments block access to the computer, I'm more and more using containers and have zero dev tools on my host because I can't trust the package maintainers to not be crooked or get hacked.
Especially with the npm/node.js ecosystem, my new dev box has zero node.js /npm/yarn etc on the host.
You need to trust someone or something. If you're using containers as a way to install tools, you still have packages either through base images or by adding `apk install` or whatever you might be using. Unless you are using Linux on your laptop, those containers are running in VMs which is isolated but you are probably mounting volumes and processes so it's not bullet proof either. At the end of the day, you need to trust something unless you're willing to inspect the code of whatever you're using.
@@DevOpsToolkit I've been a long time linux user, for 30 years or so. So I know the foundations of trusting trust. I'm careful about what to trust and NPM/Node.js have proven to me, that they are not trustworthy at a rate that is high enough to just give them access to my machine.
I expect that docker and the container ecosystem that is powered by the linux kernel to be robust enough to prevent the random arbitrary code from encrypting the entirety of my harddrive and returning it for the cool sum of a single bitcoin.
I know that it will not stop an exfiltration bot or a crypto miner from running
I never allow the docker socket to be mounted, so they cant use that to elevate privileges and I'm aware there could be bugs that get exploited overall
I don't mind random code running on my machine so much as I just don't want it to screw over my day.
I'm just worried about the liability of lost productivity due to something malicious happening to the data on my computer.
The policy of 'default to everything open' was design of the past, and should be considered deprecated at some cost but not all costs.
I love the concept of Nix. But for some reason I personally struggle with getting everything working as I want. Probably because I’m so used to Arch, and recall much from Debian and Red Hat, and Nix is a total departure from those.
Maybe one day I’ll get good with Nix. It does in fact appear to be superior.
You can also make a video on devbox which uses nix for dev environments.
Adding it to my TODO list... :)
you've beaten me to it 😅
Done: ua-cam.com/video/WiFLtcBvGMU/v-deo.html
How does Nix handle pinning versions of packages? And how up-to-date are the packages?
You can specify a version so instead of `normalPackages.nodejs` you can set it to `normalPackages.nodejs-12_x`.
As for how up-to-date packages are... It depends on maintainers of a specific package (just as anything else in open source depends on maintainers). My personal experience is that packages are up-to-date most of the time, sometimes one version behind, and rarely old.
@@DevOpsToolkit thank you!
Hmm. Very interesting. But how much reliable is this? I will try it anyway...
direnv could be even simpler as you can select cource for separate gcp azure aws
I'm using Charm Gum scripts so that people can choose and provide info interactively.
There are a few tools in this space including, asdf, mise/rtx moonrepo proto, devbox.
so I'm assuming that Nix would only be able to handle stuff that is command line driven in nature, it won't be able to do stuff with like GUI IDEs, correct? Say for example if I was using PyCharm and I wanted to use Nix to install a whole bunch of tools, there wouldn't be anyway to get PyCharm to use those tools installed by Nix? Like a specific version of Python say or c compilers etc.?
Not sure... I use it almost exclusively to setup CLIs since i tend to work trom a terminal most of the time (excluding editing and observability).
In my very limited experience with Nix, I solved this by installing my IDE in the nix shell and then running it from the nix shell itself. I don't know if a better option exists.
How do you compare Nix versus DevContainers? Can Nix help with the problem of enabling repo maintainers to declaratively set the development environment for anyone who cloned and attempts to build the repo source?
I prefer using it for local development. For remote stuff containers are a better choice.
Nix excels at this. By using a shared nix config all developers are ensured the EXACT same environment, fully provisioned, with a simple command. Docker containers are good for deployment/distribution and can be used to share dev environments but that's what nix is best at. You used the word "declare" which hits the nail on the head: nix is declarative while containers are imperative.
I started Nix 2 months ago. My biggest regret is that I didn't start earlier.
And if you like LISP, you might find Guix amusing. Based on (idea of) Nix, kinda 🙂
I tried Guix after using Nix for about a year, and it turns out that at least for me that guix was a gateway drug to more lisp. 7 years on guix now, and I'm addicted.
What about networking? nix or guix solves development environmenk in terms of libraries and dependencies, but one of containers appeal that you can create complicated stacks with private networking for dev, test, production environments....
For me, Nix can never replace app environments simply because they need to mimic production as much as possible and that means either kubernetes or cloud services like Google Cloud Run. The part of nix that i am using is related to tooling using for development but does not go to production.
I'm still not convinced that this can replace containers. I see in this video that I can come up with a file that gives the users a set of programs that are required in the environment. What I don't see is how the configuration of those programs can be used as well.
Your statement about "oh-my-zsh" custom prompt tells me that the base operating system's configuration is used in the nix shell. What should I do if I want the environment to have its own zshrc file without bothering the user's configuration?
I don't think it is replacing containers for running apps but, rather, for tools needed locally or in pipelines. Also, I would recommend devbox instead of using nix directly.
@@DevOpsToolkit Thanks. I will try to look more into devbox to see if it will fit my needs.
I decided against using devbox. I was looking for an alternative to using a container. I'm not sure how janky the solution is but what worked for me is setting the $HOME variable to the directory that runs the nix shell. I had to do it shellHook.
@homfes have you tried creating a container image with devbox?
@@DevOpsToolkit I did not. When I loooked into devbox, it just seemed like an addiitonal layer over nix that doesn't immeidately address my initial concern with Nix itself so I just explored a solution without it.
Looks very interesting. You say it will allow windows, macOS and Linux devs to work on the same repo in the same env, but what about a repo that uses symlinks?
I haven't tried it with symlinks, but i guess it should work.
@@DevOpsToolkit i just asked Bing chat and it said that would still be an issue 😢
A case (for me) of using symlinks would be one repo with one directory for front-end and one for backend and then having shared types files between them
I haven't tried that but it should be easy to verify.
Which most lightweight, nixshell or container docker?
I prefer Nix for tools and containers for apps.
As far as the pipelines goes, why not just have your pipeline cache/restore that nix cache? Then you have a really clean setup that replicates your local dev without having to potentially manage both solutions depending on the context.
I think I have a better solution which I'll explore in a video in a couple of weeks 🙂
What i was trying to say is that I'm not sure that rewriting pipelines to nix provides enough return of investment. For new ones it is a good option.
Very interesting, haven't dug into Nix yet, thanks for the intro.
On a separate subject, I'm hoping you'll be talking about Apple's new Pkl language and how it compares with Cue for managing Kubernetes manifests. I've been meaning to dig into Cue, based on your past recommendations, but now I'm curious whether it makes more sense to look at Pkl. It sounds quite promising.
I'm still in the process of experimenting with pkl. I need a bit more time before i start working on the material.
The problem I have with Pkl is that it is built on an inheritance based model whereas CUE is explicitly immutable.
That is indeed one of the big difference. Personally, i prefer CUE immutability but I also recognize that is one of the reasons for CUEs steeper learning curve.
Here it goes: ua-cam.com/video/Nm1ioWPRRVQ/v-deo.html
Going in, I'm hoping you will compare nix to what I would naturally turn to: devcontainer and devpod. (Is nix the emacs of k8s?) After watching, it will be interesting, for me at least, to find out how wrong I was going in. Nix runs as non-root with seccomp restrictions?
Nix is many things but, in my case, it is first and foremost a way to start a shell with all the tools i need without installing any of them on my machine. Devpod is, essentially, a VM.
After watching, I wonder which (PSS) admission policies I need to disable on my namespace before I can run nix.
@joebowbeer i never tried running it in kubernetes (assuming that's what you meant by namespaces). I don't see it being of any use there.
@@DevOpsToolkit oh! I was thinking the title referred to k8s ephemeral containers. sorry for not tracking.
@joebowbeer that's my bad. I should have explained it better.
what about security/isolation like firejail?
I haven't used firejail so I can't comment on it.
You said don't use nix for CI/CD pipelines, use containers. Agreed. You should rebuild those. But couldn't you just use nix in the container build? That way your dev and CI/CD environments use the same setup?
I started doing that, but with Devbox instead of Nix directly.
@@DevOpsToolkit lol. After writing that comment, I saw your devbox video and have spent the last 24 hours rebuilding all my workspaces with devbox. I think I'm in love. I haven't tried the devcontainer/codespaces stuff yet but that will be huge.
This doesn’t address the problem of differing or missing library versions, which is why containers are a thing. If anything the ephemeral-ness of containers is a problem.
Assuming that you're referring to tools we're using while developing and not libraries in app code (as what I shown in the video), you can pin them to any version you need.
How is this different from something like Fedora CoreOS or Tumbleweed
To begin with, it works on every OS. I, for example, am a Mac user who i not planning to ditch macOS for CoreOS.
Combining what you demonstrated with direnv which makes it even more convenient.
It's also a rather minimal use case for what Nix provides.
how network work inside a nix shell ? can i access a service running on the host ?
I would not recommend nix as a destination for your apps. Use kubernetes for that. I use Nix as ephemeral environments for the tools i need, not for the apps.
@@DevOpsToolkit I think you should explore Nix for building containers. That is a very valid use case. And common too. And dependencies can be shared with shell. So it is less work than having to double package it for Dockerfile & Alpine.
yes, its for a tool that connect to database to exec some sql script
@@DevOpsToolkit
Isn't it just a fancy flatpak?
To begin with, Flatpack is a package manager for Linux while Nix packages work everywhere...
cube-cuttle or cube-control?
I tend to say cube-cuttle but i heard others saying at least 5 variations of it.
How does Nix work with secrets and authentication. If I start a Nix shell do I need to reconfigure ssh for example?
Nix Shell is a shell just as sh or zsh or bash so there's no need to SSH into it.
@@DevOpsToolkit Sorry, I meant what is the nix way of setting up ssh or secrets to access other resources from a nix shell. For example does my ssh config used for github or a bastion host persist across nix shells?
@hambroman yes it does persist. I think you're mixing OS with Shell. If i would create a new VM with NixOS, if would need new keys and what so not. However, I was just switching from one Shell, from zsh, to another, to nix-shell.
Maybe you can also do a follow up video on nix flakes
Adding it to my TODO list... :)
Does nix run on windows yet? No wsl2 doesn't count
It doesn't (without WSL).
Not clear to me how this is better than a writing a "Dockerfile" with the packages you need installed inside.
Assuming that you are using windows or macos, containers are running in a VM and that complicates things like, for example access to binaries you already have installed, filesystem, local network, etc. Nix Shell is just a shell like bash or ish with the additional abilities to temporarily install additional packages.
Ok but file systems and local networks can be mounted/exposed in containers. Access to other binaries on the system kind of goes against the notion of "isolated environments" as well.@@DevOpsToolkit
@shazmailz you're right, but i think we're talking about different types of environments. I guess you're referring to preview environments like those you would spin up when creating a PR while I'm talking about a way to create an ephemeral environment that will bring me all the tools i need while working in my laptop. In that case, i am not concerned about isolation and i still run my apps as containers one way or another. What i was talking about is s way to bring in all the tooling i need (e.g. kubectl, jq, yq, g loud, etc.) in a way that is not permanent. I got sick of having thousands of random binaries/CLIs floating around my laptop, many of them to be used sporadically, some even never again. When i execute brew list, I do not even recognize more than half of the output.
I'm still confused as to the difference/advantages. This is exactly how I use a Dockefile that can be built according to local context, filesystem mounted, run interactively or truly ephemerally (one command at a time), using just what is needed from the host environment, and deployed to pipeline. Requires the same number of prerequisites on every host system (including WSL on Windows). And you can deoloy the same image to CI/CD, no duplication. I see no effective difference but I know i must be missing something.
@BDnevernind I'm was not talking about the pipelines but the tools (CLIs) you need while working (e.g. kubectl, yq, jq, helm, nodes, etc.). Are you spinning containers for those while working on your laptop?
I think everyone who knows a certain amount of Nix would love to use it for deployments... AND YET...
The way to do this seems forever non-obvious
I'm confused ... Isn't nix a stand-alone OS? How'd you install it? You create a virtual machine with nixOS installed? obviously, not. Cause, I'd be easier to install docker and be given a container. Got to be missing something.
Nix is quite a few things. I explored in that video only Nox Shell, not the OS.
One of the confusing things about nix is what the hell it is 😊. Nix is both a package management system and a scripting language which can be installed on any OS. NixOS is an operating system built with nix but you don't need to run NixOS to use nix.
Nix is indeed very confusing. It has a very steep learning curve and, as you said, it is too many things at once. Personally, I use it only as a package manager where those packages can be installed anywhere and are ephemeral in natuve. I don't use it directly but through Devbox (video is coming up tomorrow).
seems to have issues with selinux.
And now onto nix flakes? :D
Correct
Why gh and not git?
gh Has some GitHub specific commands like, for example, to fork a repo or to create it.
Going to the website to create repos always annoyed me. With the CLI I can just `"git repo create" and I don't have to open my browser. Plus other conveniences.
I use VS Code with Dev Containers.
I like the prospect of nix. But the installation and removal of nix itself makes it a hard sell for my team members
1:46 bye! keep on blabbering.