3 ms·
That's a huge win -- has your team written about or spoke on this anywhere?
by stealthybox 2y ago
That's a huge win -- has your team written about or spoke on this anywhere?
- JasonSage 2y agoNo but I'd be happy to (I maintained the docker-compose stack, our CLI, and did the transition to Nix).
- adamdecaf 2y agoI’d like to learn more about switching compose to nix. We will hit a wall with compose at some point.
- stealthybox 2y agoI'm curious about the # of svc's / stack / company / team size -- if you have your own blog -- would love to read it when you publish could be a cool lightning talk (or part of something longer) maybe it's a good piece for https://nixinthewild.com/ https://nixinthewild.com/ ? I'm @capileigh on twitter and hachyderm.io if you wanna reach out separately -- here is good tho too
- JasonSage 2y agoHey, I plan to reach out when I get some time :) I can see there’s interest in the topic.
- stealthybox 2y agosounds good! it's a cool anecdote :)
- codethief 2y agoHi Jason! Like many others here I'm looking forward to that blog post! :-) For now, could you elaborate on what exactly you mean by transitioning from docker-compose to Nix? Did you start using systemd to orchestrate services? Were you still using Docker containers? If so, did you build the images with Nix? Etc.
- JasonSage 2y agoWhen we used docker-compose we had a CLI tool which developers put in their PATH which was able to start/stop/restart services using the regular compose commands. This didn’t accomplish much at the time other than being easy to remember and not requiring folks to know where their docker-compose files were located. It also took care of layering in other compose files for overriding variables or service definitions. Short version of the Nix transition: the CLI tool would instead start services using nix-shell invocations behind pm2. So devs still had a way to start services from anywhere, get logs or process status with a command… but every app was running 100% natively. At the time I was there, containers weren’t used in production (they were doing “App” deploys still) so there was no Docker target that was necessary/useful outside of the development environment. Besides the performance benefit, microservices owning their development environment in-repo (instead of in another repo where the compose configs were defined) was a huge win.
- stealthybox 2y agothe pm2 thing via a custom cli is interesting several nixy devtools do some process management now something we're trying in Flox is per-project services run /w process-compose. they automatically shutdown when all your activated shells exit, and it feels really cool
- codethief 2y agoThanks for elaborating! By pm2 you mean https://www.npmjs.com/package/pm2 https://www.npmjs.com/package/pm2 ?
- JasonSage 2y agoYep!