Service Catalog Puppet

Service Catalog Puppet diimplementasikan dengan Python dengan menggunakan API Boto3 AWS . Alat ini menawarkan beberapa fitur canggih untuk mengonfigurasi dan menyediakan produk Service Catalog. Pengembang dapat mengonfigurasi informasi penyediaan produk dan portofolio Service Catalog dengan menggunakan templat YAMM yang berfungsi sebagai manifes. Alur kerja penyediaan Boneka Service Catalog mendukung produk yang memerlukan proses penyebaran yang lebih kompleks daripada Service Catalog. Mereka juga mendukung pengoptimalan kinerja untuk menyediakan produk dalam skala besar dalam jangka waktu yang agresif.

Service Catalog Puppet mengakses CloudFormation template Service Catalog untuk penyediaan produk pada saat deployment. Ini memanggil CloudFormation langsung untuk menerapkan tumpukan templat penyediaan untuk suatu produk dan melewati batasan yang diberlakukan oleh proses penyediaan kumpulan tumpukan Katalog Layanan sendiri. Jika template penyediaan menggunakan makro untuk menyertakan CloudFormation skrip lain atau menggunakan skrip bersarang, Anda harus memberikan akses ke CloudFormation skrip tersebut di akun target di bagian bootstrap dari alur kerja penyediaan.

Untuk informasi selengkapnya:

• Lihat dokumentasi dan GitHubrepositori Boneka Service Catalog.

• Jika Anda ingin menggunakan Service Catalog Puppet SDK untuk berinteraksi dengan alat secara terprogram untuk memulai penyediaan produk dan portofolio, lihat dokumentasi SDK.

• GitOpsadalah mekanisme default untuk mengelola lingkungan Service Catalog Puppet.

Service Catalog Puppet cukup mudah dipelajari oleh developer. Diperlukan keakraban CloudFormation untuk mengimplementasikan templat penyediaan produk dan templat YAMAL untuk mengimplementasikan manifes. Ada lokakarya bagus yang tersedia untuk mempercepat pengembang baru, seperti lokakarya mandiri.

Support untuk penyediaan alur kerja

Service Catalog Puppet menggunakan mesin orkestrasi tugas Python Luigi untuk mengimplementasikan alur kerja bootstrap dan penyediaan. Semua langkah dalam alur kerja ini diimplementasikan sebagai tugas alur kerja Luigi. Untuk gambaran umum tentang Luigi dan bagaimana perbandingannya dengan alat alur kerja populer lainnya, lihat Aliran Udara vs Luigi vs Argo vs vs di blog Pendapatan Data. MLFlow KubeFlow

Luigi memungkinkan Service Catalog Puppet untuk mengontrol jumlah pekerja yang terkait dengan tugas alur kerja, dan untuk mengontrol aspek lain dari alur kerja, untuk penskalaan dan kinerja yang lebih baik. Service Catalog Puppet juga menyediakan mekanisme depends_on untuk mengelola dependensi produk dan langkah, dan untuk mengatur penyediaan produk. Fitur ini membantu Anda menerapkan dan mengelola definisi produk berbutir halus dan dependensi kompleks secara operasional.

Mode penyediaan

Service Catalog Puppet mendukung tiga mode eksekusi: hub, spoke, dan async. Ketiga mode menyediakan produk dalam portofolio yang sudah ditentukan dalam Service Catalog. Mereka mengandalkan berbagi produk Service Catalog ke akun target dan menggunakan administrator Service Catalog dan peran peluncuran untuk mewujudkan penyediaan dalam target tersebut. Service Catalog Puppet melakukan langkah-langkah bootstrap dalam organisasi yang sama berdasarkan konfigurasi peran yang disediakan dalam file konfigurasi YAMM. Alat ini juga mendukung penyediaan ke beberapa organisasi dari satu akun hub. Dalam skenario ini, bootstrap harus dilakukan secara manual di organisasi eksternal untuk memungkinkan Service Catalog Puppet melakukan tindakan penyediaan yang diperlukan di akun organisasi eksternal.

Dalam semua mode penyediaan, Service Catalog Puppet mengimplementasikan penyediaan produk secara langsung tanpa memanggil proses penyediaan Service Catalog. Anda dapat mengonfigurasi manifes penyediaan untuk menggunakan peran dan spesifikasi akun target dalam batasan set tumpukan Service Catalog yang ada. Service Catalog Puppet menggunakan informasi ini untuk melakukan penyediaannya sendiri dengan alur kerja Luigi.

Anda dapat menentukan target untuk penyediaan portofolio produk berdasarkan pendekatan penandaan akun, selain menentukan OUs atau akun secara langsung. Dalam penyediaan berbasis tag akun, produk portofolio disediakan ke semua akun yang memiliki semua tag dalam set tag penyediaan manifes yang ditentukan. Misalnya, jika Anda ingin menerbitkan produk portofolio ke semua akun produksi institusional di Wilayah Timur AS, Anda dapat menentukan tagtype:prod, partition:us-east, danscope:institutional-client. Anda juga dapat mendeklarasikan pengecualian akun dan OU untuk melarang penyediaan OUs atau akun yang memiliki tag yang Anda tentukan, atau ke akun yang merupakan anggota target yang ditentukan OU. Untuk informasi selengkapnya tentang penandaan akun, lihat dokumentasi Alat Katalog Layanan.

Modus hub

Dalam mode penyediaan hub, semua alur kerja Luigi untuk akun spoke dikelola dari akun hub pusat yang ditunjuk. Akun hub mengasumsikan peran IAM yang memungkinkannya melakukan tindakan dalam akun spoke, tetapi pengelolaan tugas terjadi dari dalam akun hub. Akun hub menunggu secara sinkron hingga semua tugas penyediaan akun spoke selesai, baik berhasil maupun tidak berhasil. Kemudian melaporkan status akhir. Mode akun hub adalah mode penyediaan tertua dan paling matang. Namun, banyak pengguna telah pindah ke mode penyediaan bicara untuk mencapai konkurensi dan kecepatan penyediaan yang lebih besar.

Mode bicara

Dalam mode spoke, akun hub Service Catalog memulai alur kerja Luigi untuk berjalan di akun spoke bootstrap yang ditunjuk. Akun hub diberi tahu saat alur kerja spoke selesai. Kegagalan dalam akun spoke naik ke akun hub. Akun hub melakukan polling pada akun spoke untuk melihat apakah sudah selesai dan untuk menentukan status.

Mode bicara paling tidak mungkin memerlukan peningkatan Layanan AWS kuota karena hampir semuanya berjalan di akun spoke terpisah. Mode Spoke juga memberikan konkurensi yang jauh lebih besar daripada mode hub sambil mempertahankan kontrol pusat. Ini dapat meningkatkan kecepatan penyediaan hingga 800 persen melalui mode hub. Mode Spoke mendukung rantai produk melalui DependsOn hubungan antar produk, yang memastikan bahwa produk yang bergantung pada telah disediakan. Produk yang terdiri dari produk berantai juga dapat menyediakan produk rantai komponen. Anda juga dapat menggunakan panggilan AWS Lambda fungsi khusus untuk melakukan langkah-langkah yang diperlukan. Kesalahan dalam satu pembicaraan diisolasi dari jari-jari lain.

Mode Spoke digunakan oleh perusahaan yang memiliki lebih dari 980 akun hingga 7 Wilayah. Perusahaan-perusahaan ini umumnya dapat menyediakan produk ke semua Wilayah dan akun di infrastruktur mereka dalam waktu satu jam.

catatan

Hasil ini dapat bervariasi berdasarkan faktor-faktor seperti infrastruktur jaringan, beban kerja, dan kuota yang ada untuk hub AWS organisasi dan akun bicara. Mereka juga bergantung pada sumber daya produk yang sedang disediakan, waktu penciptaan yang melekat, dan ketergantungan mereka pada sumber daya lain.

Modus Aysnc

Mode asinkron memulai penyediaan alur kerja di akun spoke, tetapi tidak menunggu atau menerima tanggapan penyelesaian dari jari-jari.

Pembuatan cache

Mekanisme lain yang digunakan Service Catalog Puppet untuk mengoptimalkan kecepatan alur kerja adalah dengan menyimpan tugas umum yang mewakili langkah-langkah dalam alur kerja. Ketika tugas yang di-cache selesai, ia menulis outputnya ke Amazon Simple Storage Service (Amazon S3). Lain kali tugas dipanggil dalam sesi yang sama dengan parameter yang sama, Service Catalog Puppet menggunakan nilai cache alih-alih menjalankan ulang tugas. Untuk informasi selengkapnya, lihat Caching di dokumentasi Service Catalog Puppet.

DevSecOps dukungan siklus hidup

Service Catalog Puppet mencakup dukungan untuk mengelola DevSecOps pipa. Anda dapat menggunakan tindakan Alat Katalog Layanan (seperti yang diilustrasikan dalam ikhtisar Boneka Service Catalog) untuk mengotomatiskan pengujian dan mempromosikan produk di seluruh akun AWS siklus hidup Anda, termasuk akun kenari yang direkomendasikan. Untuk informasi selengkapnya, lihat Mengelola lingkungan Anda dalam dokumentasi Boneka Service Catalog.

Untuk memastikan bahwa setiap masalah yang terkait dengan perubahan produk terdeteksi sebelum penggunaan produksi secara luas, Service Catalog Puppet memerlukan setidaknya satu akun kenari untuk penyebaran awal. Setelah Anda menguji dan mendapatkan kepercayaan pada rilis baru, Anda dapat mempromosikannya ke akun produksi non-kenari. Jika Anda mengidentifikasi masalah apa pun, Anda dapat memutar rilis kembali dan memperkenalkannya kembali saat masalah teratasi. Saat Anda menggunakan pendekatan ini, masalah produksi mungkin terjadi jika Anda merilis versi kenari yang memiliki masalah pada akun produksi. Sebagai pendekatan alternatif, Anda dapat menjalankan tes regresi penuh untuk setiap perubahan produk sebelum merilis perubahan ke produksi. Ini memperkenalkan overhead tambahan dalam proses CI/CD tetapi membantu menghindari masalah produksi. Adalah tanggung jawab DevSecOps administrator untuk menentukan skenario rilis fitur terbaik dan pendekatan untuk tim pengembangan mereka.

Service Catalog Puppet memungkinkan beberapa tim untuk mengembangkan dan menguji penyediaan solusi produk Service Catalog secara bersamaan. Sebagai praktik terbaik, produk tidak boleh diubah oleh banyak pengembang pada saat yang bersamaan. Sebagai gantinya, Anda dapat memecah produk menjadi komponen berbutir halus untuk modifikasi terpisah dan simultan.

Service Catalog Puppet juga membantu mengotomatisasi pengujian melalui pernyataan pernyataan yang menyediakan kemampuan statis dan pengujian unit. Anda dapat menguji kebijakan kontrol layanan (SCPs) dan kebijakan IAM dengan menggunakan simulator kebijakan. Ini adalah end-to-end tes teknis tetapi dapat digunakan dalam lingkungan pengujian integrasi sistem (SIT). Untuk informasi selengkapnya, lihat Menggunakan simulasi kebijakan dan Menerapkan kebijakan kontrol layanan dalam dokumentasi Boneka Service Catalog.

Kedewasaan, kelengkapan, dan dukungan

Meskipun Service Catalog Puppet tidak didukung secara resmi Layanan AWS, itu telah diadopsi secara luas. Alat ini telah digunakan oleh organisasi besar selama beberapa tahun terakhir untuk secara sukses dan terpusat menyediakan produk ke ratusan akun OU dalam jendela waktu penyediaan yang diinginkan. Ini telah terbukti memberikan penyediaan produk yang toleran terhadap kesalahan dalam skala besar. Pengguna yang mengalami masalah apa pun dengan Service Catalog Puppet dapat mencatatnya di GitHub repositori untuk diselesaikan oleh kontributor solusi Labs ini. AWS