 | Nix Milan | 107 Members |
| https://milano.nix.pizza/ | 7 Servers |
| Nix Milan | 107 Members |
| https://milano.nix.pizza/ | 7 Servers |
| Sender | Message | Time |
|---|---|---|
| 31 Oct 2025 | ||
 x71c9 | Ho una domanda per tutti, alla quale immagino ci siano un'infinità di possibili risposte. Vorrei sapere come approccereste il seguente scenario: - Voglio costruire un’applicazione con uno stack, ad esempio, composto da Node.js e MySQL (o tecnologie simili). - Desidero che l’ambiente di sviluppo locale sia il più possibile identico a quello di produzione. - Entrambe le macchine utilizzano NixOS. - Il server di produzione deve includere solo le librerie strettamente necessarie all’esecuzione dell’applicazione (possibilmente eliminare anche gli eseguibili di nixos), mentre la macchina locale può avere già vari servizi in esecuzione. - Gli aggiornamenti dell’applicazione devono essere distribuiti tramite una pipeline di deploy. Come gestireste questa situazione? Quali sono, secondo voi, le migliori praticVhe o gli strumenti più efficaci per affrontarla? | 11:12:26 |
| x71c9 | Avevo letto che per evitare modifiche alla macchina, si potevano eliminare anche i comandi di nix. Ma comunque non è la parte fondamentale. Volevo capire appunto se utilizzare container, come con docker, oppure ci sono soluzioni migliori. | 11:24:32 |
 Alex0 | Cioè se ci può essere del downtime tra gli update intendo O vuoi qualcosa che possa fare tipo blue/green deployment | 11:30:21 |
| x71c9 | Ah ok, non ci devono essere downtime. | 11:30:46 |
| x71c9 | Cosa intendi per critico? Comunque mi interessa di più sapere il processo di sviluppo per avere facilemente lo stesso sistema sulla macchina locale e sul server di produzione. Posso stare sicuro con nix-shell? Oppure è meglio utilizzare i container? (Scusate l'ignoranza ma sono alle prime armi con Nix) | 11:30:22 |
| Alex0 | Cosa intendi per "eliminare anche gli eseguibili di nixos"? Puoi fare roba con systemd con dynamic user, restringere capabilities, etc, ma dipende cosa ti serve etc Ti serve davvero deployarlo bare-metal? Non puoi usare containers ad esempio? | 11:23:14 |
| x71c9 | Ottimo, grazie | 11:32:07 |
 Francesco | Riguardo a rimuovere gli eseguibili di nixos: puoi specificare nix.enable = false | 11:31:47 |
| Francesco | In reply to x71c9Poi se vuoi disabilitare delle altre robe di default dai un'occhiata a nixos/modules/profiles/minimal.nix su nixpkgs | 11:33:24 |
 Nonno Felice | In reply to x71c9Io ho provato a pacchettizzare un'applicazione Go usando container2nix ed ho avuto un'immagine con la runtime minima per eseguirlo | 11:32:20 |
| x71c9 | E invece utilizzando sempre e solo NixOS, scegliereste i Container OCI o i Container di NixOS? | 11:51:13 |
| Alex0 | In reply to x71c9Per downtime si puo' intendere anche un paio di secondi chiariamo Ecco cosa intendo per "critico" Alcune aziende non possono nemmeno andare down per qualche secondi siccome gli costerebbe tantissimo | 12:02:42 |
| Alex0 | In reply to x71c9Ahh capito Container2nix è un modo per buildare immagini docker se vuoi usare containers In ogni caso nix-shell è usato per la shell di sviluppo, non del "pacchetto" in sé, cosa che in realtà a te in produzione interessa di più (però sì, i pacchetti dentro la nix-build sono in subset solitamente della tua nix-shell) Il problema che potresti avere con il pacchetto è se chiama altri programmi a runtime ad esempio Puoi sempre runnarlo in locale o usare nixos tests per fare tests che puoi usare sia in locale che in ci ad esempio Un'altra cosa che ti consiglio è di pinnare le versioni di nixpkgs o qualsiasi dipendenza su nix che usi (se non stai usando già i flakes) | 11:49:57 |
| Alex0 | In reply to x71c9Dipende tutto da ciò Se hai 1 solo server ed usi systemd (nativo quindi), il servizio verrà restartato quindi finché il servizio non riparte ed inizia ad accettare richieste, there will be downtime Also, se fallisce lo start del servizio rip, there will definitely be downtime Se hai più macchine/vm di nixos puoi fare blue/green deployment (qualcuno ne parlava ieri, se vuoi ti menziono sul messaggio) Se usi containers/kubernetes puoi fare la stessa roba analoga Non so come funziona a livello di setup dichiarativo però | 11:57:51 |
| Alex0 | In reply to Tonio@x71c9 | 11:58:24 |
 Federico T | fortunatamente non si è spaccato niente | 12:13:38 |
| Federico T | In reply to Alex0una volta stavo per fare una attività in una emittente televisiva nazionale il cliente mi chiede se sono sicuro che non ci sarà disservizio, gli dico si certo mi guarda, e mi fa: "in alcuni posti i downtime si misurano in minuti. In altri, in secondi. Noi li misuriamo in fotogrammi persi. Sei sicuro?" | 12:13:30 |
| x71c9 | Credo che proverò i container NixOS | 13:07:24 |
| x71c9 | Vorrei utilizzarlo a lavoro. Sì, direi che “secondi” possa andare bene. Poi immagino dipenda anche dall’applicazione ovviamente. | 13:07:10 |
 Alessandro Bertulli | In reply to Andrea CiceriHo conosciuto i ragazzi di rev.ng, sono una startup del Politecnico | 13:16:03 |
 Lucio | Esatto | 18:53:59 |
| Lucio | Domanda per voi: sarebbe possibile in un flake avere tutti i packages definiti in systemPackages, home.packages e programs come output del flake? L'obbiettivo sarebbe poter eseguire nix run di un singolo pacchetto nix (con o senza configurazione program) tra quelli definiti nel flake senza referenziarli uno a uno come output con devshell o packages. Quindi, ad esempio, potrei fare nix run flakeRemoto#neovim e avere nella shell il mio neovim/nixvim (configurato tramite hm programs) oppure una certa versione di flameshot con overlay. A volte mi capita di eseguire tasks per qualche giorno su dispositivi non miei e questo mi aiuterebbe a fare un porting temporaneo della parte di mia configurazione che serve per quel task (senza riscrivermela o modificarla al momento). | 18:48:11 |
| Lucio | Eh ma non la voglio tutta, perché magari è un sistema con poco spazio e mi servono solo 2-3 programmi | 18:51:49 |
 Marco Turchetto | Magari puoi fare una funzione che prende una config home-manager valutata ed estrae la lista di packages e la mette in flake.packages | 18:52:05 |
| Marco Turchetto | Magari puoi fare una Shell che importa come package la tua config home-manager? | 18:50:51 |
| Marco Turchetto | Per programs è più complicato probabilmente devi creare una Shell, mettere i packages e poi linkare tramite envvar la home e chissà cosa altro... | 18:58:04 |
| Marco Turchetto | Però packages è diverso da programs... Ad esempio per git, avrai la versione di git che vuoi, ma non la config del nome utente e email | 18:53:21 |
| Marco Turchetto | E tu invece vuoi programs? | 18:56:33 |
| Marco Turchetto | Però mentre packages è una lista, programs è un ambiente unico, quindi qua secondo me ti schianti ad avere una shell per program, magari fai un mini HM per queste evenienze? | 19:01:31 |
| 1 Nov 2025 | ||
 Alessandro Candido | Nella shell puoi metterci esattamente quello che vuoi tu, sia in termini di configurazioni che di pacchetti. Tra l'altro, puoi comporle a piacimento. Alla fine Nix e' un linguaggio completo, per cui puoi definirti una o piu' shell base, mixin vari, e generare le combinazioni dinamicamente | 03:16:26 |