Service Catalog Puppet

Service Catalog Puppet è implementato in Python utilizzando AWS l'API Boto3. Questo strumento offre diverse potenti funzionalità per la configurazione e il provisioning dei prodotti Service Catalog. Gli sviluppatori possono configurare le informazioni sul provisioning di prodotti e portfolio di Service Catalog utilizzando modelli YAML che fungono da manifesti. I flussi di lavoro di provisioning di Service Catalog Puppet supportano prodotti che richiedono processi di distribuzione più complessi rispetto a Service Catalog. Supportano inoltre l'ottimizzazione delle prestazioni per fornire prodotti su larga scala entro finestre temporali aggressive.

Service Catalog Puppet accede ai CloudFormation modelli di Service Catalog per la fornitura del prodotto al momento della distribuzione. Richiama CloudFormation direttamente per implementare lo stack di modelli di provisioning per un prodotto e aggira le restrizioni imposte dal processo di provisioning del set di stack di Service Catalog. Se il modello di provisioning utilizza macro per includere altri CloudFormation script o utilizza script annidati, è necessario fornire l'accesso a tali CloudFormation script nell'account di destinazione nella parte di avvio del flusso di lavoro di provisioning.

Per ulteriori informazioni:

• Consulta la documentazione e l'GitHubarchivio di Service Catalog Puppet.

• Se desideri utilizzare Service Catalog Puppet SDK per interagire con lo strumento a livello di codice per avviare il provisioning di prodotti e portfolio, consulta la documentazione SDK.

• GitOpsè il meccanismo predefinito per la gestione dell'ambiente Service Catalog Puppet.

Service Catalog Puppet è abbastanza facile da imparare per gli sviluppatori. Richiede dimestichezza con l'implementazione dei modelli CloudFormation di provisioning dei prodotti e dei modelli YAML per implementare i manifesti. Sono disponibili ottimi workshop per avvicinare i nuovi sviluppatori, ad esempio workshop personalizzati.

Support per i flussi di lavoro di provisioning

Service Catalog Puppet utilizza il motore di orchestrazione delle attività Python Luigi per implementare i flussi di lavoro di bootstrap e provisioning. Tutti i passaggi di questi flussi di lavoro sono implementati come attività del flusso di lavoro Luigi. Per una panoramica di Luigi e del suo confronto con altri strumenti di workflow più diffusi, consulta Airflow vs. Luigi vs. Argo vs. MLFlow sul blog Data Revenue. KubeFlow

Luigi consente a Service Catalog Puppet di controllare il numero di lavoratori associati alle attività del flusso di lavoro e di controllare altri aspetti dei flussi di lavoro, per una migliore scalabilità e prestazioni. Service Catalog Puppet fornisce anche un meccanismo depends_on per la gestione delle dipendenze tra prodotti e fasi e per orchestrare il provisioning del prodotto. Questa funzionalità consente di implementare e gestire in modo operativo definizioni di prodotto dettagliate e dipendenze complesse.

Modalità di provisioning

Service Catalog Puppet supporta tre modalità di esecuzione: hub, spoke e async. Tutte e tre le modalità forniscono prodotti all'interno di portafogli già definiti in Service Catalog. Si affidano alla condivisione dei prodotti di Service Catalog con gli account di destinazione e utilizzano i ruoli di amministratore e di lancio di Service Catalog per realizzare il provisioning in tali destinazioni. Service Catalog Puppet esegue i passaggi di bootstrap all'interno della stessa organizzazione in base alle configurazioni dei ruoli fornite nei file di configurazione YAML. Lo strumento supporta anche il provisioning a più organizzazioni da un unico account hub. In questo scenario, il bootstrap deve essere eseguito manualmente nelle organizzazioni esterne per consentire a Service Catalog Puppet di eseguire le azioni di provisioning richieste negli account dell'organizzazione esterna.

In tutte le modalità di provisioning, Service Catalog Puppet implementa direttamente il provisioning del prodotto senza richiamare il processo di provisioning di Service Catalog. È possibile configurare un manifesto di provisioning per utilizzare le specifiche del ruolo e dell'account di destinazione in un vincolo di set di stack Service Catalog esistente. Service Catalog Puppet utilizza queste informazioni per eseguire autonomamente il provisioning con i flussi di lavoro Luigi.

È possibile definire obiettivi per la fornitura del portafoglio di prodotti sulla base di un approccio di etichettatura degli account, oltre a specificare direttamente i nostri account. OUs Nel provisioning basato su tag di account, un prodotto di portafoglio viene fornito a tutti gli account che hanno tutti i tag del set di tag di provisioning manifesto specificato. Ad esempio, se desiderate emettere un prodotto in portafoglio per tutti gli account di produzione istituzionali nelle regioni orientali degli Stati Uniti, potete specificare i tag type:prod e. partition:us-east scope:institutional-client È inoltre possibile dichiarare esclusioni di account e unità organizzative per vietare l'approvvigionamento verso gli account con i tag specificati dall'utente OUs o per gli account che fanno parte degli obiettivi specificati dall'unità organizzativa. Per ulteriori informazioni sull'etichettatura degli account, consulta la documentazione di Service Catalog Tools.

modalità Hub

In modalità hub provisioning, tutti i flussi di lavoro Luigi per gli account spoke sono gestiti dall'account hub centrale designato. L'account hub assume un ruolo IAM che gli consente di eseguire azioni in un account spoke, ma la gestione delle attività avviene dall'interno dell'account hub. L'account hub attende in modo sincrono il completamento di tutte le attività di provisioning degli account spoke, con esito positivo o negativo. Quindi riporta lo stato finale. La modalità account hub è la modalità di provisioning più vecchia e matura. Tuttavia, molti utenti sono passati alla modalità di provisioning Spoke per ottenere una maggiore velocità e velocità di provisioning.

Modalità Spoke

In modalità spoke, l'account dell'hub Service Catalog avvia i flussi di lavoro Luigi da eseguire negli account spoke bootstrap designati. L'account hub riceve una notifica quando i flussi di lavoro spoke vengono completati. I guasti in un account spoke si ripercuotono sull'account hub. L'account hub interroga l'account spoke per vedere se è terminato e per determinarne lo stato.

È meno probabile che la modalità Spoke richieda aumenti di Servizio AWS quota perché quasi tutto viene eseguito negli account spoke separati. La modalità Spoke offre inoltre una concorrenza molto maggiore rispetto alla modalità hub, pur mantenendo il controllo centralizzato. Può migliorare la velocità di provisioning dell'800% rispetto alla modalità hub. La modalità Spoke supporta la concatenazione dei prodotti attraverso DependsOn le relazioni tra i prodotti, il che garantisce che un prodotto da cui dipende sia già stato fornito. Un prodotto che comprende prodotti concatenati può fornire anche un prodotto concatenato a componenti. È inoltre possibile utilizzare chiamate di AWS Lambda funzioni specializzate per eseguire i passaggi richiesti. I guasti di un raggio sono isolati dagli altri raggi.

La modalità Spoke viene utilizzata dalle aziende con oltre 980 account in un massimo di 7 regioni. Queste aziende sono generalmente in grado di fornire un prodotto a tutte le regioni e a tutti gli account della loro infrastruttura entro un'ora.

Nota

Questi risultati potrebbero variare in base a fattori quali l'infrastruttura di rete, il carico di lavoro e le quote previste per gli account AWS Organization Hub and Spoke. Dipendono anche dalle risorse del prodotto che vengono fornite, dai tempi di creazione intrinseci e dalla loro dipendenza da altre risorse.

Modalità asincronica

La modalità asincrona avvia i flussi di lavoro di provisioning negli account spoke, ma non attende né riceve risposte di completamento dagli spoke.

Caching

Un altro meccanismo utilizzato da Service Catalog Puppet per ottimizzare la velocità dei flussi di lavoro consiste nel memorizzare nella cache le attività comuni che rappresentano le fasi del flusso di lavoro. Quando un'attività memorizzata nella cache è completa, scrive il suo output su Amazon Simple Storage Service (Amazon S3). La volta successiva che l'attività viene richiamata nella stessa sessione con gli stessi parametri, Service Catalog Puppet utilizza i valori memorizzati nella cache anziché eseguire nuovamente l'attività. Per ulteriori informazioni, consulta la sezione Caching nella documentazione di Service Catalog Puppet.

DevSecOps supporto per il ciclo di vita

Service Catalog Puppet include il supporto per la gestione della DevSecOps pipeline. Puoi utilizzare le azioni di Service Catalog Tools (come illustrato nella panoramica di Service Catalog Puppet) per automatizzare i test e promuovere i prodotti nei tuoi account del AWS ciclo di vita, incluso l'account Canary consigliato. Per ulteriori informazioni, consulta Gestire gli ambienti nella documentazione di Service Catalog Puppet.

Per garantire che eventuali problemi relativi a una modifica del prodotto vengano rilevati prima dell'uso diffuso in produzione, Service Catalog Puppet richiede almeno un account Canary per la distribuzione iniziale. Dopo aver testato e acquisito fiducia nella nuova versione, puoi promuoverla presso account di produzione diversi da Canary. Se identificate dei problemi, potete ripristinare la release e reintrodurla quando i problemi saranno risolti. Quando si utilizza questo approccio, potrebbero verificarsi problemi di produzione se si rilascia una versione di Canary che presenta problemi agli account di produzione. Come approccio alternativo, è possibile eseguire test di regressione completi per ogni modifica del prodotto prima di rilasciare la modifica alla produzione. Ciò comporta un sovraccarico aggiuntivo nel processo CI/CD, ma aiuta a evitare problemi di produzione. È responsabilità dell' DevSecOps amministratore determinare gli scenari e gli approcci di rilascio delle funzionalità migliori per i propri team di sviluppo.

Service Catalog Puppet consente a più team di sviluppare e testare contemporaneamente la fornitura di soluzioni di prodotto Service Catalog. Come best practice, un prodotto non dovrebbe essere modificato da più sviluppatori contemporaneamente. Puoi invece suddividere i prodotti in componenti più dettagliati per modifiche separate e simultanee.

Service Catalog Puppet aiuta anche ad automatizzare i test tramite una dichiarazione di asserzione che fornisce funzionalità statiche e di unit test. È possibile testare le policy di controllo dei servizi (SCPs) e le policy IAM utilizzando simulatori di policy. Si tratta di end-to-end test tecnici, ma possono essere utilizzati in ambienti di test di integrazione di sistemi (SIT). Per ulteriori informazioni, vedere Utilizzo delle simulazioni delle politiche e Applicazione delle politiche di controllo del servizio nella documentazione di Service Catalog Puppet.

Maturità, completezza e supporto

Sebbene Service Catalog Puppet non sia supportato ufficialmente Servizio AWS, è stato ampiamente adottato. Questo strumento è stato utilizzato da grandi organizzazioni negli ultimi anni per fornire con successo e centralmente i prodotti a centinaia di account di unità organizzative entro le finestre temporali di provisioning desiderate. Ha dimostrato di fornire prodotti con tolleranza ai guasti su larga scala. Gli utenti che riscontrano problemi con Service Catalog Puppet possono registrarli nel GitHub repository per la risoluzione da parte dei collaboratori di questa AWS soluzione Labs.