(Estratto da un articolo di Sage Weil: https://ceph.io/ceph-management/introducing-cephadm)
Negli anni è emersa un'ampia varietà di strumenti di distribuzione Ceph con l'obiettivo di rendere lo storage Ceph più facile da installare e gestire. La maggior parte di questi ha sfruttato strumenti già esistenti come Ansible, Puppet e Salt, portando con sé un ecosistema esistente di utenti e un'opportunità per allinearsi a un investimento esistente da parte di un'organizzazione che utilizza un particolare strumento. Di conseguenza, tuttavia, l'investimento della comunità di Ceph è stato frammentato in molti sforzi diversi, i nuovi utenti devono affrontare una difficile scelta di strumenti all'inizio e i tentativi di semplificare l'esperienza e l'integrazione con Ceph stesso sono stati difficili.
Come molti altri, mi sono personalmente attaccato al datato strumento ceph-deploy, che ha il vantaggio di essere estremamente semplice da usare e capire (almeno per qualcuno che ha familiarità con Ceph), e ha la bella proprietà di non richiedere un investimento iniziale nell'installazione e nell'apprendimento di un altro strumento. Tuttavia, oggigiorno il ceph-deploy non è più manutenuto e non funziona nemmeno con alcune distribuzioni più recenti come RHEL / CentOS 8.
Soprattutto, tuttavia, nessuno di questi strumenti ha svolto un ottimo lavoro nel risolvere il problema principale: rendere Ceph molto facile da installare per un nuovo utente e rendere un cluster Ceph facile da manutenere nel tempo grazie alla perfetta integrazione con Ceph CLI e GUI . Una nuova API dell'orchestrator è stata introdotta per la prima volta in Ceph Nautilus per fornire un modo generico a Ceph - la CLI e il dashboard - di interagire con il suo ambiente di distribuzione, sia che si tratti di Rook o ceph-ansible o DeepSea, ma solo con Octopus questo ha raggiunto un livello di maturità in cui fornisce un'astrazione significativa su più backend: Rook per gli ambienti Kubernetes e Cephadm per tutti gli altri.
L'obiettivo di Cephadm è fornire un livello di installazione e gestione completo, robusto e ben manutenuto che può essere utilizzato per chiunque non utilizzi Ceph in Kubernetes. Gli obiettivi che ci siamo prefissati includono:
L'obiettivo con tutto ciò è quello di focalizzare l'attenzione degli sviluppatori Ceph e della comunità degli utenti su due sole piattaforme per la distribuzione e la gestione di Ceph - Cephadm per le implementazioni "bare metal" e Rook per l'esecuzione di Ceph in Kubernetes - e per fornire una simile esperienza di gestione per entrambi.
Con la versione iniziale di Octopus, Cephadm ha un solido supporto per i servizi Ceph principali: RADOS, CephFS, RBD e RGW. Un certo numero di servizi secondari sono in fase di sviluppo attivo, incluso il supporto per gateway NFS e iSCSI, e il supporto CIFS (tramite Samba) dovrebbe seguire dopo. Tutte queste modifiche verranno trasferite su Octopus non appena saranno completate.
Nel frattempo, ci aspettiamo anche di migliorare la robustezza e l'intelligenza dell'algoritmo di "pianificazione" che decide dove eseguire i servizi. In questo momento, Cephadm distribuisce semplicemente i daemon di servizio tra gli host, ma (per impostazione predefinita) sceglie questi host a caso. Vorremmo migliorare questo impostando limiti di risorse sui contenitori di daemon (ad esempio, CPU e memoria) e scegliendo la posizione dei daemon in modo intelligente in base alle risorse disponibili su ciascun host.
Infine, ci aspettiamo di dedicare molto tempo nel prossimo ciclo di sviluppo a far emergere più funzionalità dell'orchestrator attraverso la dashboard Ceph per semplificare l'esperienza utente complessiva, in particolare per operazioni comuni come la distribuzione iniziale, l'espansione del cluster e la sostituzione di dispositivi di archiviazione guasti.
Se hai ricercato applicazioni e tecnologie native per il cloud, probabilmente ti sei imbattuto nella mappa a questo link
è la mappa del mondo del cloud. La sua complessità non è incoraggiante: tante categorie e tante tecnologie.
Cerchiamo oggi di definire qualche linea guida per dare un senso a tutto ciò.
Come per qualsiasi altra cosa, se lo scomponi e lo analizzi un pezzo alla volta, scoprirai che non è così complesso e ha molto senso.
In effetti, la mappa è ben organizzata per funzionalità e, una volta capito cosa rappresenta ciascuna categoria, la navigazione diventa molto più semplice.
Innanzitutto, eliminiamo tutte le singole tecnologie dal panorama e esaminiamo le categorie.
Esistono diverse "righe" che riflettono i livelli architettonici, ciascuna con il proprio insieme di sottocategorie.
Nel primo livello ci sono gli strumenti per il provisioning dell'infrastruttura, che è la base.
Quindi si passa ad aggiungere gli strumenti necessari per eseguire e gestire app, livelli di runtime e orchestrazione.
Nella parte superiore ci sono gli strumenti per definire e sviluppare la tua applicazione, come i database, creazione di immagini e strumenti CI / CD (Continuous Integration and Deployment).
Il provisioning si riferisce agli strumenti coinvolti nella creazione e nel rafforzamento delle basi su cui sono costruite le applicazioni cloud native.
Copre tutto, dall'automazione della creazione, gestione e configurazione dell'infrastruttura alla scansione, firma e archiviazione delle immagini dei contenitori.
Il provisioning si estende alla sfera della sicurezza fornendo strumenti che consentono di impostare e applicare policies, creare autenticazione e autorizzazione nelle app e piattaforme e gestire la distribuzione delle chiavi.
Nel livello di provisioning, troverai:
Questi strumenti consentono agli ingegneri di codificare tutte le specifiche dell'infrastruttura, in modo che il sistema possa attivare o disattivare nuovi ambienti a seconda delle necessità, assicurando che siano coerenti e sicuri.
Runtime è uno di quei termini che possono creare confusione. Non esiste una definizione rigorosa e può essere utilizzato in modo diverso, a seconda del contesto.
A.In senso stretto, il runtime è una sandbox su una macchina specifica preparata per eseguire un'app, il minimo indispensabile di cui un'app ha bisogno.
B.In senso più ampio, il runtime è qualsiasi strumento di cui l'app necessita per girare.
C.Nel mondo delle app cloud native la definizione di runtime è una via di mezzo, si concentra sui componenti che contano per le app containerizzate: ciò di cui hanno bisogno per eseguire, ricordare e comunicare.
Questi includono:
Dopo aver automatizzato il provisioning dell'infrastruttura seguendo gli standard di sicurezza e conformità (livello di provisioning) e impostato gli strumenti che l'app deve eseguire (livello di runtime), gli ingegneri devono capire come orchestrare e gestire le loro app.
Il livello di orchestrazione e gestione si occupa del modo in cui tutti i servizi containerizzati (componenti dell'app) vengono gestiti come un gruppo.
Devono identificare altri servizi, comunicare tra loro e coordinarsi. Le app cloud native intrinsecamente scalabili si basano sull'automazione e sulla resilienza, abilitate da questo livello.
In questo livello troverai:
Ora passiamo al livello superiore. Come suggerisce il nome, la definizione dell'applicazione e il livello di sviluppo si concentrano sugli strumenti che consentono agli ingegneri di creare app e consentono loro di funzionare. Tutto quanto discusso sopra era relativo alla creazione di un ambiente affidabile e sicuro e alla fornitura di tutte le dipendenze delle app necessarie.
Sotto questa categoria vedrai:
Tornando alla panoramica delle categorie (immagine iniziale), esploriamo le due colonne che attraversano tutti i livelli.
L'osservabilità e l'analisi sono strumenti che monitorano tutti i livelli.
Le piattaforme, d'altra parte, raggruppano più tecnologie all'interno di questi livelli in un'unica soluzione, inclusa l'osservabilità e l'analisi.
Per limitare le interruzioni del servizio dovrai monitorare e analizzare ogni aspetto della tua applicazione in modo che qualsiasi anomalia venga rilevata e corretta immediatamente. I guasti si verificheranno inevitabilmente in ambienti complessi e questi strumenti contribuiscono a renderli meno impattanti aiutando a identificare e risolvere i guasti il più rapidamente possibile. Poiché questa categoria attraversa e monitora tutti i livelli, si trova sul lato e non è incorporata in un livello specifico.
Qui troverai:
Come abbiamo visto, ciascuno di questi moduli risolve un problema particolare. Lo storage da solo non fornisce tutto ciò di cui hai bisogno per gestire la tua app.
Avrai bisogno di uno strumento di orchestrazione, runtime del contenitore, rilevamento dei servizi, networking, gateway API e così via. Coprendo più livelli, le piattaforme raggruppano diversi strumenti insieme per risolvere un problema più ampio.
Configurare e mettere a punto diversi moduli in modo che siano affidabili e sicuri e garantire che tutte le tecnologie che sfrutta siano aggiornate e che le vulnerabilità siano corrette non è un compito facile. Con le piattaforme, gli utenti non devono preoccuparsi di questi dettagli: un vero valore aggiunto.
Probabilmente noterai che tutte le categorie ruotano attorno a Kubernetes. Questo perché Kubernetes, sebbene sia solo un pezzo del puzzle, è al centro dello stack del native cloud. Il CNCF, tra l'altro, è stato creato con Kubernetes come primo progetto di seeding; tutti gli altri progetti sono seguiti in seguito.
Le piattaforme possono essere classificate in quattro gruppi:
In ogni categoria, ci sono diversi strumenti volti a risolvere problemi uguali o simili. Alcune sono tecnologie native pre-cloud adattate alla nuova realtà, mentre altre sono completamente nuove. Le differenze risiedono nella loro implementazione e approcci progettuali. Non esiste una tecnologia perfetta che controlli tutte le scatole. Nella maggior parte dei casi la tecnologia è limitata dal design e dalle scelte architettoniche: c'è sempre un compromesso.
Quando si seleziona lo stack, gli ingegneri devono considerare attentamente ogni capacità e compromesso per identificare l'opzione migliore per il loro caso d'uso.
Sebbene ciò comporti ulteriore complessità, non è mai stata possibile come oggi la scelta di uno storage dei dati, della gestione dell'infrastruttura, del sistema di messaggistica, ecc. che meglio si adattano alle esigenze dell'applicazione.
L'architettura dei sistemi oggi è molto più semplice che in un mondo pre-cloud. E, se progettate in modo appropriato, le tecnologie cloud native offrono la grande e necessaria flessibilità di cui c’è bisogno.
Nell’ecosistema tecnologico in rapida evoluzione dei nostri tempi, questa è probabilmente una delle capacità più importanti.
Ci auguriamo che questa rapida panoramica sia stata utile.
Articolo liberamente tradotto da
https://thenewstack.io/an-introduction-to-the-cloud-native-landscape/
Un'introduzione al paesaggio nativo del cloud - a cura di Catherine Paganini
