Sněhová vločka na mojem serveru

Dakujem za namety, pozriem ale:
> Všechny konfigurační soubory nixového serveru mám v repozitáři git

To mozete priamo aj v adresari /etc spustit 'git init' ziadny velky zazrak

to se pleteš, tady nejde jen o konfiguraci služeb a systému v /etc, ale vlastně i celý samotný systém, nainstalované balíčky, použitý kernel, spouštěné služby, externí integrace a vlastně celý provisioning.

NixOS má schopnost při změně nastavení i celkově změnit FS a definované službu podle nového nastavení, už žádné takové ty staré artefakty a neudržované služby, když v ansiblu prostě něco smažu nebo přestanu nějaký playbook spouštět. NixOS řeší vždy systém jako celek.

Z /etc třeba nejsi schopný nainstalovat potřebné balíčky a odinstalovat nepotřebné, k tomu ti verzování /etc nepomůže. NixOS jde ještě dál, v rámci definice systému může být i komplexní sestavení skoro jakéhokoliv SW, který se rovnou při deploymentu připraví, nemusí být balíček připravený v distribuci dopředu.

Tím to nekončí, celé nastavení a sestavení nového OS mohu dopředu vyzkoušet ve virtuálu a NixOS poskytuje robustní framework na testování systému uvnitř tohoto virtuálu.

Tomu rozumiem ale za nejaky velky zazrak by som to proste nepovazoval. Aj nad kubernet/ansi­ble/helm configurakmi si mozem spustit git init alebo proste nad hocicim cim ovladam nieco.

Nixos je opravdu mnohem robustnější a řeší spoustu věcí, při kterých si člověk jinak docela dost zanadává.

Celou tu konfiguraci mám sice v gitu, ale o tom to vůbec není. Používám git skoro na vše, třeba i na smlouvy a dopisy úřadům. Beru git jako samozřejmost a ano, dávám do gitu i /etc/*.

Nixos je takový zázrak, spustíš a máš server a nebo aspoň víš, kde máš chybu. Je to příjemné jako když máš dobrý vývojový devstack.

Vadí mi v zásadě dvě věci, které postupně překonávám.

- ten jazyk nix je dost neobvyklý, je to pro mě pořád cizí území, kde našlapuju opatrně

- a celé je to takový zázrak, že se sice raduju jak to skvěle jde, ale s troškou nedůvěry si říkám, co se tam na pozadí vlastně děje. A tam se děje spousta věcí a děje se to úplně jinak, než v každým jiným normálním linuxu. V tom článku jsem dal odkaz na nix pills https://nixos.org/guides/nix-pills/ kde se jde do hloubky. Nakonec jsem to nestudoval až do posledního detailu, ale v zásadě jsem pochopil, jak třeba z helloworld v céčku uděláš nix balíček. Zabalit něco pro aur, nebo i pro debian je pro mě pořád snažší, ale ty balíčky v nixu dělají mnohem víc.

s nixem pracuji 4 roky a jsem v něm dnes schopný psát skoro normální programy. Je to ale neobvyklý jazyk, postupně jsem si ho ale docela oblíbil a přepsal různé bashové scripty přímo do nixu. Integrace se systemd je skvělá, rád třeba využívám sidecar servicy, kde mi teraform připraví celou službu před/při startu. Mohu snadno pro každou službu mít integrovaný bootstrap se získáváním tajemství z vaultu aniž bych musel každou službu upravovat, prostě to v přes nix injectují do těch servicech. Skvělé.

To balíčkování a způsob práce třeba s flake dává obrovské možnosti. Mohu třeba velice snadno a iterativně zkoušet různé verze závislostí, generovat různé varianty sestaveního toho stejné. To celé mohu udělat ve virtuálním klonu produkce dopředu a hledat regrese.

Výsledek mohu uložit do sdílené cache a jednotlivé stanice už si nemusí nic kompilovat, dostanou sestavení jaké potřebují. Mohu takhle kombinovat na jedné platformě několik různých verzí nástrojů, nepotřebuji pro každý jazyk používat speciální vyhýbku, abych mohl mít více jav, pythonů, nodů. Vždy byl porod do nějakého projektu aplikovat patche, s nix s jeho buildtooly to jde naprosto snadno.

Vlastně díky nixu (dnes už mám asi 90 % osobní infrastruktury na nixu, stejně tak desítky malých společností jsem postupně zmigroval na nix), mám virtualizovaný celý produkční stack a jakékoliv zásahy mohu dopředu vyzkoušet, což s běžnou distribucí je občas peklo. Výrazně se mi snížily nároky na údržbu, dříve jsem na to potřeboval několik lidí, dnesk to zvládnou dva lidi.

ale tady nejde o verzování konfigurace, ale její aplikaci. Jakpak se svým gitem uděláš checkout, naistalují se ti nové balíčky a restartují služby?

Nad kubernetom ano.

A potom zistite, ze git neriesi prava, ownerov, symlinky ...

Vůbec to nastavení nixos nemusí být v gitu. Já si to dal do gitu jen proto, protože jsem na to zvyklý, ale stejně ten git nepoužívám jak bych měl. Parkrát mě git zachránil a parkrát taky ne, protože jsem necomitnul co jsem comitnout měl.

Nastavenie nixos v gite byt moze, tam problem nie je. Reagoval som na git priamo v /etc, to je velmi nestastny napad.

@tb - souhlasím s tvou myšlenkou, jen dvě drobnosti:

- git v /etc je super nápad, bez etckeeperu bych nenixový server spravovat nechtěl.
- git umí trackovat symlinky, práva jen omezeně (pouze +x), uživatele a skupiny ne

Osobně jsem k tomu šla spíš z druhé strany a na Nixu mi momentálně běží desktop, soukromý laptop a pracovní laptop.

Super je, že všechny stroje jsou instalované ze stejného gitu kde jsou i secrets, balíky které na pracovní laptop nepatří jsou definované separátně a vybírají se podle hostname a na pracovní laptop se ještě separátně nastavuje intune.

Docela fajn je nastudovat a brzo po instalaci přejít na nix flakes, je to budoucnost Nixu a přináší spoustu výhod (v případě instalace víc strojů třeba reprodukovatelnost díky lock file)

Nix je super na definici vývojového prostředí. Každý projekt má svou flake, jakmile vlezu do jeho adresáře, nainstalujou a nastaví se všechny balíky které jsou potřeba k sestavení a testům (a díky lock files všude stejné, takže je jistota stabilního vývojového prostředí), navíc jde ten package manager nainstalovat všude včetně macu, takže kolegové s macem můžou v pohodě stáhnout projekt který napíšu a nic neřešit. Stejné prostředí mi pak běží v CI, a flake projektu pak celou věc sestaví a vrátí minimalistický OCI kontejner.

Chystám se přejít na NixOS i na serveru, ale přesunout všechno co mám teď na CentOS bude docela fuška, tak to krapet odkládám :D

přesouval jsem to postupně, ty legacy věci v rhel jsem zabalil do docker containeru (z počátku dokonce po spuštění jsem spustil ansible, který ten conteiner doinstaloval) a spouštěl přes virtualisation.oci-containers.

Časem mi ale naprosto ubylo množství věcí, které mám mimo nix. Pro testy a klientské věci pak používám klasické virtuálky s plnou distribucí, opět řízeny a nasazovány přes nixOS, což je na tom skvělé, mít deklarativně nastavené virtuály je bomba.

Celkom by ma zaujímalo ako sa vám podarilo spojazdniť Intune na pracovnom laptope. Neviem sa dopátrať funkčného riešenia.

Proč sem dá redakce blogový zápisek, který má chybu už v nadpisu?

Velmi děkujeme za tvůj hodnotný příspěvek do diskuze, seš opravdu borec.

> Bývá zvykem mít zvlášť htpp server, zvlášť databázový server a ještě předtím nějaký proxy server, často se používá haproxy. Když už je však konfigurace v nixos tak pohodlná, napadlo mě vykašlat se na toto tradiční dělení a mít vše v jedné vps.

Tak mat haproxy na jednom zeleze asi nema velky zmysel. Celkovo to delenie sa robi koli inym veciam ako je bezpecnost, rozdelenie vykonu, ... nie koli jednoduchosti alebo komplikovanosti konfiguracie.

Jasně. Bezpečnost a škálovatelnost, rozdělení výkonu, vím.

Mám zkušenost, už staršího data, že když neoddělíš hned na začátku zvlášť http server a db server, tak si docela zavaříš.

No, ale s nixos to jako problém nevidím. Asi záleží na situaci a úhlu pohledu, ale kdybych měl třeba měnit nastavení přístupu k databázi u desítek webů v jejich konfiguracích, často v těch php scriptech a jako alternativa k tomu dobře napsaný nixos konfigurace a změnit to na jednom místě a přebuildit - tak třeba tohle je rozdíl mezi otročinou na dlouho a úpravou na pár minut.

To jsou prostě takové ty situace, kdy člověk potřebuje něco vyzkoušet a teď stojí před komplexností svý infrastruktury a říká si, abych tohle vyzkoušel a nerozbil tamto. A když to vyzkouším na nějakém testovacím serveru a pak to dám na ostrý, tak s překvapením zjistím, že jsem zapomněl zase na tamto a ono to kvůli tomu nefunguje.

Ale jasně, vždy je spousta možných cest a třeba pomocí ansiblu lez v podstatě dosáhnu téhož cíle.

Pořád řešíme rovnici o x neznámých a výsledkem vždy bude množina možných řešení. Nixos je jen jedním z možných řešení. Nebo vzhledem k tomu, že i s nixos se dá dělat různě, tak je to nejspíš zase množina dalších řešení jak tu infrastrukturu vybudovat.

Sám jsem zvědavý, co v podaní nixos znamená to slovo "reprodukovatelný", kterým s etak zašťituje. Zatím myslím, že to znamená opravdu hodně a že to funguje.

Na to aby si nastavil server cez ssh netreba nic nikam kopirovat rsyncom:

nixos-rebuild switch \
  --build-host $ssh_url \
  --target-host $ssh_url \
  --use-remote-sudo \
  --flake .#$target_hostname

Inak dobre vyladeny Ansible tiez nie je na zahodenie. Jedna vec ktora mi pride v Nixe ako achylova pata je sprava secrets. Su na to kdejake nastroje a podobne, ale ansible-vault je v tomto IMO omnoho lepsie.

Cize je to ako so vsetkym. Right tool for the job. Niektore veci su v Nixe extremne jednoduche (v porovnani napriklad s tym Ansible) ine extremne narocne.

https://nixos.wiki/wiki/Agenix je fajn a celkem pohodlný :)

Agenix poznam, je to celkom dobre riesenie, ale proste nix principialne riesi niektore veci inak a dosledok toho je ze je praca s credentials obcas vyrazne zlozitejsia alebo vyzaduje nie celkom idealne riesenie.

Napriklad Tailscale. V Ansible je pomerne jednoduche pocas aplikovania konfiguracie vygenerovat docasny auth key - kludne s platnostou par minut a pri konfiguracii servera ho automaticky registrovat v tailnet. Vysledok je server ktory je automaticky pripojeny do VPN bez toho aby server samotny musel mat niekde ulozeny auth key alebo dokonca bez toho aby vobec nejaky platny auth key po ukonceni ansible existoval.

Naproti tomu nixos toto riesi tak, ze ma extra systemd service ktory vykona tailscale up a ten kluc je potom vo vysledku potrebny priamo na stroji. Tiez je velmi neprakticke aby to bol nejaky short-lived token, pretoze agenix tak proste nefunguje. Cize vo vysledku je na serveri dlhodobo platny token.

Agenix je dobry na situacie kedy je cielom aby samotne hesla boli priamo niekde na serveri a aj tam si dovolim tvrdit, ze je to extremne kostrbate riesenie v porovnani s Ansible - napriklad ak jeden potrebuje vlozit heslo do konfiguracneho suboru. To co sa v ansible riesi pomerne priamociarym (a velmi flexibilnym) template systemom musi jeden s Agenix riesit rucne.

A takychto prikladov je vela.

Okrem Agenix je vela dalsich rieseni a v podstate vsetky obchadzaju nix nejakym sposobom - casto sposobom kedy je velmi lahke omylom mat secrets roztrusene niekde v nix store alebo commitnute plaintext v gite.

Na druhej strane su veci ktore su v Ansible extremne zlozite, zatial co v Nix je to trivialna zalezitost. Cize netvrdim, ze je jedno lepsie ako druhe, obe pouzivam (aj v kombinacii) ale konkretne sprava hesiel a inych tajnych udajov mi pride v nixe vyrazne zlozitejsia.

ty secrets v nixu jsou nešikovné, ale je to možná tím, že od toho čekáš víc. Používám hashicorp vault, pro službu, která potřebuje credentials generuje before další službu s vaultem, který secrets připraví buď přes šablonu nebo jako environments a až pak se spustí daná službu. Stejně mám řešené aktualizace, přes reload/restart. Něco na způsob https://github.com/DeterminateSystems/nixos-vault-service, ale napsal jsem si to trochu jinak.

Pro offline instalace mám vault server jako službu přímo na daném stroji, teraform jí nastaví při spuštění stejně jako mám nastavený produkční cluster a přes agenix (či něco podobného) tam vložím šifrovaný dump s hesly pro import do vaultu.

Pokud je potřeba služby konfigurovat externě, používám v definici něco jako condition file exists a služba se nespustí dokud někdo externí tam nevloží data. Pak je možné (třeba v rámci CI) jedním příkazem zavolat deploy přes nix a druhým spustit ansible, který to nakonfiguruje a služby spustí. Nebo dokonce deployment přes nix může být součástí ansible playbooku, waitovat na to, až bude ssh ready a pak tam klasicky naspouštět zbylé úlohy. Beru nixos jako generátor stavu OS, ale runtime věci, monitoring a provoz si stejně musím řešit sám.

Ansible používám skoro od počátku, ale musím říct, že mě už pěkně štve. Postupně jsem hodně věcí zmigroval do teraformu, lépe se mi tam řeší clusterové závislosti a konfigurace služeb na více serverech zároveň.

Ano podobne to riesim aj ja. Niektore veci sa daju relativne rozumne riesit aj cez systemd-creds. Ale proste niekedy je to sialene vela prace pre nieco co v Ansible riesi vault.

Asi najblizsie sa k tomu dostava sops-nix, ale tiez plati ze tam jeden musi riesit rovnatka na ohybaky aby to fungovalo.

Pouzivam ako Ansible, tak Terraform a tiez Nix. Vsetko je dobre na nieco ine. Terraform je urcite skvely na infrastrukturu. Nix je fajn na dev shell a aj NixOS samotny je celkom fajn. Ansible je skvele hlavne tam kde nemusis riesit zmeny v case a kde vzdy vsetko zostavujes "od nuly" - napriklad testovacia infrastruktura, pripadne rovno seria testov, tvorba images v kombinacii s Packerom a podobne.

A niekde na hranici tychto vyuziti su tie trecie plochy.

V Nix je to sprava hesiel. A vseobecne problem s tym, ked cast stavu systemu nie je riadena Nix-om. (klasicky priklad pre Nix je Steam, alebo iny externy package manager, Terraform ma tiez s tym problem napriklad pri sprave objektov v k8s)

V Terraform fakt ze musis niekde bezpecne a zdielatelne udrziavat state. A vobec vseobecne sprava state - terraform donedavna nemal moved a removed block, jeden to musel riesit rucne alebo externymi nastrojmi.

Ansible zas neprinasa idempotenciu "out of the box" a casom ti hrozi konfiguracny drift. Tiez casto nie je uplne zjavne co sa stane ked zbehne playbook. Jeden musi mat pomerne slusny test coverage aby sa na Ansible vedel spolahnut.

Kazde ma svoje miesto. Kazde ma svoje problemy.

NixOS je fajn. GuixOS je podobný avšak lepší https://guix.gnu.org/
Už nejaké dva roky používam Guix ako môj main OS.