{"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 al top","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Abbiamo sviluppato DevOps come potevamo. Eravamo 8 persone e Vasya era il migliore su Windows. Improvvisamente Vasya se n'\u00e8 andato e ho dovuto affrontare il compito di avviare un nuovo progetto per la fornitura di sviluppo Windows. Quando ho messo sul tavolo tutto il stack di sviluppo Windows, mi sono reso conto che la situazione era critica...<\/p>\n

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

\".NET
\n
\nCome \u00e8 facile e senza sforzo consegnare un progetto in RPM, utilizzando TFS, Puppet, Linux .NET core? Come mantenere il versionamento del database di un progetto se gli sviluppatori sentono per la prima volta parole come Postgres e Flyway, e la scadenza \u00e8 dopodomani? Come integrare con Docker? Come motivare gli sviluppatori .NET ad abbandonare Windows e i frullati a favore di Puppet e Linux? Come risolvere i conflitti ideologici quando non ci sono n\u00e9 forze n\u00e9 desiderio n\u00e9 risorse per mantenere Windows in produzione? Di questo, oltre a Web Deploy, testing, CI, pratiche di utilizzo di TFS in progetti esistenti, e ovviamente di stampelle rotte e soluzioni funzionanti, parler\u00e0 la relazione di Alexander.
\n<\/a><\/noindex>
\n

\r\n \"Guarda\r\n
<\/div>\r\n <\/div><\/center>
\nDunque, Vasya \u00e8 andato, il compito \u00e8 mio e gli sviluppatori attendono con le forche impazienti. Quando ho finalmente realizzato che non avrei potuto riportare Vasya, mi sono messo al lavoro. Per prima cosa ho valutato la percentuale di VM Windows nel nostro parco. I risultati non erano a favore di Windows.<\/p>\n

\".NET
\n
\nPoich\u00e9 stiamo sviluppando attivamente DevOps, ho capito che era necessario cambiare approccio per l'implementazione di una nuova applicazione. La decisione \u00e8 stata chiara: se possibile, trasferire tutto su Linux. Google mi ha aiutato: a quel tempo .Net era gi\u00e0 stato portato su Linux e ho capito che era questa la soluzione!<\/p>\n

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

\nCi sono state diverse ragioni. Tra \"pagare\" e \"non pagare\" la maggior parte sceglie la seconda opzione, come me. Una licenza per MSDB costa circa 1.000 $, mentre il mantenimento di un parco di macchine virtuali Windows si traduce in centinaia di dollari. Per una grande azienda, sono spese significative. Perci\u00f2 il risparmio\u00a0<\/b>\u2014 \u00e8 la prima ragione<\/b>. Non la pi\u00f9 importante, ma certamente una delle pi\u00f9 significative.<\/p>\n

Le macchine virtuali Windows richiedono 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 semplicemente nel CI esistente<\/b>. Ci consideriamo sviluppatori DevOps all'avanguardia, utilizziamo Bamboo, Jenkins e GitLab CI, pertanto gran parte del nostro lavoro si basa su Linux.<\/p>\n

L'ultima ragione \u00e8 la facilit\u00e0 di supporto. <\/b>Dovevamo abbattere la soglia di ingresso per i \"supporters\" \u2013 ragazzi che comprendono la parte tecnica, garantiscono la continuit\u00e0 e gestiscono i servizi di secondo livello. Erano gi\u00e0 familiari con il stack Linux, quindi per loro \u00e8 molto pi\u00f9 semplice comprendere il nuovo prodotto, supportarlo e assisterlo piuttosto che spendere risorse aggiuntive per capire una funzionalit\u00e0 analoga del software per la piattaforma Windows.<\/p>\n

Requisiti<\/h2>\n

\nPrima di tutto la praticit\u00e0 di una nuova soluzione per gli sviluppatori<\/b>. Non tutti si sono mostrati pronti ai cambiamenti, soprattutto dopo aver sentito la parola Linux. Gli sviluppatori vogliono il loro amato Visual Studio, TFS con test automatici sui build e smoothie. Come avviene la consegna in produzione non \u00e8 importante per loro. Pertanto, abbiamo deciso di non cambiare il processo abituale e mantenere tutto invariato per lo sviluppo su Windows. <\/p>\n

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

Semplicit\u00e0 di supporto e funzionamento<\/b>, come condizione per una soglia minima di ingresso per tutti i nuovi partecipanti provenienti dai diversi reparti e dal dipartimento di supporto.<\/p>\n

Il termine ultimo era ieri<\/b>.<\/p>\n

Il gruppo di sviluppo Win<\/h2>\n

\nCon cosa lavorava quindi il team di Windows?<\/p>\n

\".NET
\n
\nOra posso dire con certezza che IdentityServer4<\/b>\u00a0\u00e8 una fantastica alternativa gratuita ad ADFS con funzionalit\u00e0 simili, oppure che Entity Framework Core<\/b>\u00a0\u00e8 un paradiso per gli sviluppatori, dove si pu\u00f2 smettere di preoccuparsi di scrivere script SQL e descrivere le query nel database in termini di OOP. Ma allora, nella discussione sul piano d'azione, guardavo a questo stack come se fosse una scrittura cuneiforme sumera, riconoscendo solo PostgreSQL e Git.<\/p>\n

A quel tempo utilizzavamo attivamente Puppet<\/b> come sistema di gestione della configurazione. Nella maggior parte dei nostri progetti applicavamo GitLab CI<\/b>, Elastic<\/b>, bilanciavamo i servizi altamente caricati con l'aiuto di HAProxy,<\/b> tutte le osservazioni venivano fatte usando Zabbix<\/b>, la combinazione Grafana<\/b> e\u00a0Prometheus<\/b>, Jaeger<\/b>, e tutto ci\u00f2 girava su dei macchinari\u00a0HP<\/b> c\u00a0ESXi<\/b> in\u00a0VMware<\/b>. \u00c8 conosciuto da tutti \u2013 un classico del genere.<\/p>\n

\".NET
\n
\nVediamo e cerchiamo di capire cosa stava succedendo prima che avessimo intrapreso tutti questi interventi.<\/p>\n

Cosa c'era<\/h2>\n

\nTFS \u00e8 un sistema piuttosto potente che non solo distribuisce il codice dallo sviluppatore alla macchina di produzione finale, ma offre anche un set per una integrazione molto flessibile con vari servizi, al fine di garantire CI a livello cross-platform.<\/p>\n

\".NET
\nIn passato c'erano solo finestre. TFS utilizzava diversi agenti di Build, sui quali erano raccolti molti progetti. In ogni agente c'erano 3-4 worker per parallelizzare i task e ottimizzare il processo. Poi, secondo i piani di rilascio, TFS consegnava il Build appena sfornato su un server Windows per applicazioni.<\/p>\n

A cosa volevamo arrivare<\/h2>\n

\nPer la consegna e lo sviluppo utilizziamo TFS, mentre l'applicazione viene eseguita su un server applicativo Linux, e tra di loro c'\u00e8 una sorta di magia. Questa Magic Box<\/b> \u00e8 il fulcro del lavoro futuro. Prima di esaminare i dettagli, mi permetto una digressione per dire un paio di parole sull'applicazione.<\/p>\n

Progetto<\/h2>\n

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

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

Cliente<\/h3>\n

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

HAProxy<\/h3>\n

\nSuccessivamente, la richiesta del cliente arrivava a HAProxy, che svolgeva i seguenti compiti:<\/p>\n