Vlákno názorů ke článku Sněhová vločka na mojem serveru od mprasil - Na to aby si nastavil server cez ssh...

  • 21. 2. 2024 17:31

    mprasil

    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.

  • 22. 2. 2024 10:58

    mprasil

    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.

  • 22. 2. 2024 15:49

    Uncaught ReferenceError:

    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ň.

  • 23. 2. 2024 15:13

    mprasil

    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.