{"id":32217,"date":"2019-10-31T21:45:43","date_gmt":"2019-10-31T18:45:43","guid":{"rendered":"https:\/\/prohoster.info\/blog\/net-core-na-linux-devops-na-kone\/"},"modified":"2019-10-31T21:45:43","modified_gmt":"2019-10-31T18:45:43","slug":"net-core-na-linux-devops-na-kone","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/net-core-na-linux-devops-na-kone","title":{"rendered":".NET Core su Linux, DevOps a cavallo","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Abbiamo sviluppato DevOps come meglio potevamo. Eravamo in 8 persone, e Vasya era il migliore per Windows. Improvvisamente, Vasya se n'\u00e8 andato e mi \u00e8 stata affidata la responsabilit\u00e0 di lanciare un nuovo progetto per lo sviluppo su Windows. Quando ho riversato sul tavolo l'intero stack per lo sviluppo su Windows, ho capito che la situazione era critica...<\/p>\n

Cos\u00ec inizia la storia Aleksandr Sinchinov<\/b> con DevOpsConf<\/a><\/noindex>. Quando il nostro principale esperto di Windows ha lasciato l'azienda, Aleksandr si \u00e8 chiesto cosa fare ora. Passare a Linux, naturalmente! Aleksandr racconter\u00e0 come \u00e8 riuscito a creare un precedente e a trasferire parte dello sviluppo Windows su Linux con l'esempio di un progetto implementato per 100.000 utenti finali.<\/p>\n

\".NET
\n
\nCome \u00e8 facile e informale distribuire un progetto in RPM utilizzando TFS, Puppet, Linux .NET core? Come mantenere la versioning del database del progetto, se gli sviluppatori sentono per la prima volta le parole Postgres e Flyway, mentre la scadenza \u00e8 dopodomani? Come integrarsi con Docker? Come motivare gli sviluppatori .NET a rinunciare a Windows e smoothie a favore di Puppet e Linux? Come risolvere i conflitti ideologici se non ci sono n\u00e9 forze n\u00e9 voglia n\u00e9 risorse per gestire Windows in produzione? Di questo, cos\u00ec come di Web Deploy, testing, CI, delle pratiche di utilizzo di TFS in progetti esistenti, e naturalmente delle stampelle rotte e delle soluzioni funzionanti, ne parler\u00e0 la trascrizione della presentazione di Alexander.
\n<\/a><\/noindex>
\n

\r\n \"Riproduci\r\n
<\/div>\r\n <\/div><\/center>
\nQuindi, Vasya se n'\u00e8 andato, il compito \u00e8 su di me, gli sviluppatori aspettano con i forconi con impazienza. Quando ho finalmente realizzato che non potevo riportare Vasya, mi sono messo al lavoro. Per prima cosa, ho valutato la percentuale di VM Windows nel nostro parco. Il conteggio non era a favore di Windows.<\/p>\n

\".NET
\n
\nPoich\u00e9 stiamo attivamente sviluppando DevOps, ho capito che dovevo cambiare qualcosa nell'approccio alla distribuzione di una nuova applicazione. La soluzione era una sola: trasferire tutto su Linux, se possibile. Google mi ha aiutato: a quel tempo .Net era gi\u00e0 stato portato su Linux, e ho capito che questa era la soluzione!<\/p>\n

Perch\u00e9 .NET core in combinazione con Linux?<\/h2>\n

\nCi sono diverse ragioni. Tra \"pagare\" e \"non pagare\", la maggior parte sceglier\u00e0 la seconda opzione, proprio come ho fatto io. Una licenza per MSDB costa circa 1.000 $, e la manutenzione di un parco di macchine virtuali Windows si traduce in centinaia di dollari. Per una grande azienda, sono costi significativi. Perci\u00f2 risparmio\u00a0<\/b>\u2014 prima ragione<\/b>. Non \u00e8 la pi\u00f9 importante, ma \u00e8 una delle pi\u00f9 rilevanti.<\/p>\n

Le macchine virtuali Windows consumano pi\u00f9 risorse rispetto ai loro equivalenti Linux - sono pesanti<\/b>. Considerando le dimensioni di una grande azienda, abbiamo scelto Linux.<\/p>\n

Il sistema si integra facilmente con il CI esistente<\/b>. Ci consideriamo DevOps all'avanguardia, utilizziamo Bamboo, Jenkins e GitLab CI, quindi gran parte delle nostre operazioni si svolgono su Linux.<\/p>\n

L'ultima ragione - facile manutenzione. <\/b>Avevamo bisogno di abbassare la soglia d'ingresso per i \"manutentori\" - le persone che comprendono la parte tecnica, garantiscono la continuit\u00e0 e gestiscono i servizi di secondo livello. Loro conoscevano gi\u00e0 lo stack Linux, quindi per loro \u00e8 molto pi\u00f9 facile capire il nuovo prodotto, supportarlo e mantenerlo, piuttosto che spendere risorse aggiuntive per orientarsi in funzionalit\u00e0 analoghe di software per la piattaforma Windows.<\/p>\n

Requisiti<\/h2>\n

\nPrima di tutto - la comodit\u00e0 della nuova soluzione per gli sviluppatori<\/b>. Non tutti erano pronti per i cambiamenti, specialmente dopo aver sentito la parola Linux. Gli sviluppatori vogliono Visual Studio, TFS con autotest sui build e smoothie. Non importa come avviene la consegna in produzione. Pertanto, abbiamo deciso di non cambiare il processo abituale e di mantenere tutto invariato per lo sviluppo su Windows. <\/p>\n

Un nuovo progetto deve essere integrato nel CI esistente<\/b>. I binari erano gi\u00e0 presenti e tutto il lavoro doveva essere svolto tenendo conto delle impostazioni del sistema di gestione della configurazione, degli standard di consegna adottati e dei sistemi di monitoraggio.<\/p>\n

Semplicit\u00e0 nella manutenzione e operativit\u00e0<\/b>, come condizione per una soglia minima di ingresso per tutti i nuovi partecipanti provenienti da diversi reparti e dal settore di supporto.<\/p>\n

La scadenza \u00e8 ieri<\/b>.<\/p>\n

Gruppo di sviluppo Win<\/h2>\n

\nCon cosa ha lavorato quindi il team Windows?<\/p>\n

\".NET
\n
\nOra posso dire con certezza che IdentityServer4<\/b>\u00a0\u00e8 un'ottima alternativa gratuita a ADFS con funzionalit\u00e0 simili, o che Entity Framework Core<\/b>\u00a0\u2014 un paradiso per gli sviluppatori, dove non bisogna preoccuparsi di scrivere script SQL, ma piuttosto di descrivere le query nel database in termini di OOP. Tuttavia, durante la discussione del piano d'azione, guardavo a questo stack come se fosse un cuneo sumero, riconoscendo solo PostgreSQL e Git.<\/p>\n

A quel tempo, usavamo attivamente Puppet<\/b> come sistema di gestione della configurazione. In gran parte dei nostri progetti, utilizzavamo GitLab CI<\/b>, Elastic<\/b>, bilanciando i servizi ad alta richiesta con HAProxy,<\/b> monitorando tutto con Zabbix<\/b>, una combinazione di Grafana<\/b> e\u00a0Prometheus<\/b>, Jaeger<\/b>, e tutto ci\u00f2 girava su hardware\u00a0HP<\/b> c\u00a0ESXi<\/b> con\u00a0VMware<\/b>. \u00c8 noto a tutti \u2014 un classico del settore.<\/p>\n

\".NET
\n
\nDiamo un'occhiata e cerchiamo di capire cosa stesse succedendo prima che iniziassimo tutti questi interventi.<\/p>\n

Cosa era<\/h2>\n

\nTFS \u00e8 un sistema piuttosto potente, che non solo consegna il codice dallo sviluppatore alla macchina di produzione finale, ma ha anche un insieme di strumenti per un'integrazione molto flessibile con diversi servizi \u2014 per garantire CI a livello di cross-platform.<\/p>\n

\".NET
\nIn passato, si trattava di semplici finestre. TFS utilizzava diversi agenti di build su cui venivano raccolti numerosi progetti. Ogni agente aveva 3-4 worker per parallelizzare i compiti e ottimizzare il processo. Successivamente, secondo i piani di rilascio, TFS inviava il build freschissimo su un server Windows per applicazioni.<\/p>\n

A cosa volevamo arrivare<\/h2>\n

\nPer la distribuzione e lo sviluppo utilizziamo TFS, mentre l'applicazione viene eseguita su un server Linux Application, e tra di loro c'\u00e8 una sorta di magia. Questa Magic Box<\/b> \u00e8 il cuore del lavoro a venire. Prima di smontarlo pezzo per pezzo, far\u00f2 un passo indietro e dir\u00f2 due parole sull'applicazione.<\/p>\n

Progetto<\/h2>\n

\nL'applicazione fornisce funzionalit\u00e0 per gestire carte prepagate. <\/p>\n

\".NET
\n<\/p>\n

Client<\/h3>\n

\nC'erano due tipi di utenti. Primo<\/b> accedeva autenticandosi tramite certificato SSL SHA-2. Un\u00a0secondo<\/b> aveva accesso tramite nome utente e password.<\/p>\n

HAProxy<\/h3>\n

\nSuccessivamente, la richiesta del cliente arrivava a HAProxy, che gestiva le seguenti operazioni:<\/p>\n