 | Nix Milan | 111 Members |
| https://milano.nix.pizza/ | 7 Servers |
| Nix Milan | 111 Members |
| https://milano.nix.pizza/ | 7 Servers |
| Sender | Message | Time |
|---|---|---|
| 30 Oct 2025 | ||
 Alex0 | Massì, non voglio tutti i dettagli xD | 20:38:02 |
 Tonio | Parlando di NDA, dovrei chiedere se posso mostrare il setup del monorepo a lavoro. Abbiamo dei nix ninja che hanno messo in piedi comandi singoli che fanno packaging, creano dei systemd service e li terraformano su 10 macchine una alla volta. È stato molto bello fare il mio primo deploy in produzione in questa azienda con 1 solo comando 😊 | 20:39:49 |
 Andrea Ciceri | easy, metti uno swap file nella cartella di google drive e scarica piu' ram | 20:37:30 |
| Andrea Ciceri | io intendevo piu' per la memoria, secondo me almeno 1 giga ci vuole anche solo per valutare hello.outPath | 20:32:45 |
| Andrea Ciceri | e la peppa, cosa stavi rebuildando? | 20:29:52 |
| Andrea Ciceri | Anche me e' successo che scoppiasse ad eval time comunque nixpkgs-review, non ricordo cosa stessi facendo pero' | 20:34:27 |
| Andrea Ciceri | si si chiaro, forse nixpkgs-review sotto usa nix-eval-jobs e stava provando a valutare piu' derivazioni assieme? 18 giga e' comunque tantissimo | 20:33:59 |
| Andrea Ciceri | In reply to Tonioah ecco immaginavo. Tra l'altro probabilmente sono troppo lenti anche per valutare codice nix | 20:25:21 |
| Tonio | In reply to Alex0In effetti non ho dato una panoramica esaustiva. Abbiamo 2 hw engineer che disegnano i caricatori, ma noi facciamo tutta la piattaforma di gestione. Si possono controllare e configurare da remoto e se il tuo operatore di energia partecipa al mercato libero dell'energia puoi fare in modo che questo controlli la schedule di ricarica offrendoti la corrente ad un prezzo più basso. Chiaramente l'accesso remoto lo dobbiamo fornire noi integrando l'energy partner. | 20:28:13 |
| Tonio | È fatto apposta per fare blue/green deployment. Gestiamo il rollout delle macchine nuove, tirandone giù una vecchia e deviando con il load balancer il traffico sulle altre nove, istanziandone una nuova e spostando il traffico anche su quella. Nel caso in cui abbiamo migrazioni di DB schema, topic pulsar o altro che richieda uno stop the world programmiamo un outage. Avere un mercato limitato ad un solo fuso orario è comodo per programmare le cose alle 3 di notte quando hai un picco negativo di utenti connessi. | 20:50:52 |
| Tonio | Appunto :D | 20:52:21 |
| Alex0 | Le migrazioni dei DB sono sempre una rottura farli senza avere downtime | 20:54:20 |
| Alex0 | Si se fa blue/green è apposto | 20:52:05 |
| Alex0 | In reply to TonioSu 10 macchine uno alla volta? Ma non rischi che vadano out of sync? | 20:46:25 |
| 31 Oct 2025 | ||
 Alessandro 🤔➖☀️🖌 | nix shell --help fa un po' pena, se volessi informazioni un po' più dettagliate su cosa fa nix shell o nix env, dove potrei trovarle? | 09:53:22 |
| Alessandro 🤔➖☀️🖌 | in particolare, volevo capire se settava delle variabili d'ambiente, quali, come, perché | 09:53:44 |
| Alex0 | con systemd so che puoi restringere un bel po' di roba, se vuoi farlo bare metal could be a way Ma non è critico questo servizio no? | 11:27:35 |
 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 |