Mewakili infrastruktur sebagai kod dalam format teks yang boleh diulang ialah amalan terbaik yang mudah untuk sistem yang tidak memerlukan mengutak-atik tetikus. Amalan ini mempunyai nama - , dan setakat ini terdapat dua alat popular untuk melaksanakannya, terutamanya dalam AWS: ΠΈ .
Membandingkan pengalaman dengan Terraform dan CloudFormation
Sebelum datang ke (Aka ) Saya kerja dan menggunakan Terraform selama tiga tahun. Di tempat baharu, saya juga menggunakan Terraform dengan sekuat tenaga saya, dan kemudian syarikat itu mendorong peralihan kepada segala-galanya ala Amazon, termasuk CloudFormation. Saya telah bersungguh-sungguh membangunkan amalan terbaik untuk kedua-duanya, dan telah menggunakan kedua-dua alatan dalam aliran kerja seluruh organisasi yang sangat kompleks. Kemudian, selepas menimbang dengan teliti implikasi perpindahan daripada Terraform ke CloudFormation, saya menjadi yakin bahawa Terraform mungkin pilihan terbaik untuk organisasi.
Terraform Mengerikan
perisian beta
Terraform masih belum mengeluarkan versi 1.0 lagi, yang merupakan alasan yang baik untuk tidak menggunakannya. Ia telah banyak berubah sejak saya mula mencuba sendiri, tetapi ketika itu terraform apply sering rosak selepas beberapa kemas kini atau hanya selepas beberapa tahun penggunaan. Saya akan mengatakan bahawa "semuanya berbeza sekarang," tetapi... itulah yang dikatakan semua orang, bukan? Terdapat perubahan yang tidak serasi dengan versi sebelumnya, walaupun ia sesuai, malah rasanya seperti sintaks dan abstraksi kedai sumber kini adalah apa yang kita perlukan. Alat itu nampaknya telah menjadi lebih baik, tetapi... :-0
Sebaliknya, AWS telah melakukan kerja yang baik untuk mengekalkan keserasian ke belakang. Ini mungkin kerana perkhidmatan mereka sering diuji secara menyeluruh dalam organisasi dan hanya kemudian, dinamakan semula, diterbitkan. Jadi "mereka berusaha keras" adalah pernyataan yang meremehkan. Mengekalkan keserasian ke belakang dengan API untuk sistem yang pelbagai dan kompleks seperti AWS adalah amat sukar. Sesiapa sahaja yang terpaksa mengekalkan API awam yang digunakan secara meluas harus memahami betapa sukarnya untuk melakukannya selama bertahun-tahun. Tetapi tingkah laku CloudFormation, dalam ingatan saya, tidak pernah berubah selama ini.
Jumpa kaki... ia adalah peluru
Setahu saya, padamkan sumber itu orang luar Timbunan CloudFormation daripada timbunan CF anda tidak boleh dilakukan. Perkara yang sama berlaku dengan Terraform. Ia membolehkan anda mengimport sumber sedia ada ke dalam timbunan anda. Fungsinya boleh dikatakan hebat, tetapi dengan kuasa yang besar datang tanggungjawab yang besar. Anda hanya perlu menambah sumber pada tindanan dan semasa anda bekerja dengan tindanan anda, anda tidak boleh memadam atau menukar sumber ini. Suatu hari ia menjadi bumerang. Pada suatu hari di Twitch, seseorang secara tidak sengaja mengimport kumpulan keselamatan AWS orang lain ke dalam timbunan Terraform mereka sendiri sementara tidak melakukan sebarang kerosakan. Saya memasukkan beberapa arahan dan... kumpulan keselamatan (bersama-sama trafik masuk) hilang.
Terraform Hebat
Pemulihan daripada keadaan yang tidak lengkap
Kadangkala CloudFormation gagal untuk beralih sepenuhnya dari satu keadaan ke keadaan lain. Pada masa yang sama, dia akan cuba kembali ke yang sebelumnya. Sayang sekali ini tidak selalu dapat dilaksanakan. Ia boleh menjadi agak menakutkan untuk menyahpepijat perkara yang berlaku kemudian - anda tidak tahu sama ada CloudFormation akan gembira kerana ia digodam - walaupun hanya untuk membetulkannya. Sama ada ia akan menjadi mungkin atau tidak untuk kembali ke keadaan sebelumnya, dia benar-benar tidak tahu bagaimana untuk menentukan dan, secara lalai, tergantung selama berjam-jam menunggu keajaiban.
Terraform, sebaliknya, cenderung pulih daripada peralihan yang gagal dengan lebih anggun dan menawarkan alat penyahpepijatan lanjutan.
Perubahan yang lebih jelas kepada keadaan dokumen
βBaiklah, pengimbang beban, awak sedang menukar. Tetapi bagaimana?"
βjurutera yang cemas, bersedia untuk menekan butang βterimaβ.
Kadangkala saya perlu melakukan beberapa manipulasi dengan pengimbang beban dalam timbunan CloudFormation, seperti menambah nombor port atau menukar kumpulan keselamatan. ClouFormation memaparkan perubahan dengan teruk. Saya, pada pin dan jarum, semak semula fail yaml sepuluh kali untuk memastikan bahawa saya tidak memadamkan apa-apa yang perlu dan tidak menambah apa-apa yang tidak perlu.
Terraform adalah lebih telus dalam hal ini. Kadang-kadang dia terlalu telus (baca: annoying). Nasib baik, versi terkini termasuk paparan perubahan yang lebih baik supaya anda kini boleh melihat dengan tepat apa yang berubah.
Fleksibiliti
Tulis perisian ke belakang.
Secara terang-terangan, ciri yang paling penting bagi perisian tahan lama ialah keupayaan untuk menyesuaikan diri dengan perubahan. Tulis sebarang perisian ke belakang. Selalunya saya membuat kesilapan dengan menggunakan perkhidmatan "mudah", dan kemudian mula menjejalkan segala-galanya ke dalam satu timbunan CloudFormation atau Terraform. Dan sudah tentu, beberapa bulan kemudian ia telah mendedahkan bahawa saya telah memahami segala-galanya salah, dan perkhidmatan itu sebenarnya tidak mudah! Dan sekarang saya perlu memecahkan timbunan besar kepada komponen kecil. Apabila anda bekerja dengan CloudFormation, ini hanya boleh dilakukan dengan mencipta semula timbunan sedia ada dahulu, dan saya tidak melakukannya dengan pangkalan data saya. Terraform, sebaliknya, membolehkan untuk membedah timbunan dan memecahkannya kepada bahagian yang lebih kecil yang lebih mudah difahami.
Modul dalam git
Berkongsi kod Terraform merentas berbilang tindanan adalah lebih mudah daripada berkongsi kod CloudFormation. Dengan Terraform, anda boleh meletakkan kod anda dalam repositori git dan mengaksesnya menggunakan kawalan versi semantik. Sesiapa sahaja yang mempunyai akses kepada repositori ini boleh menggunakan semula kod kongsi. Setara CloudFormation ialah S3, tetapi ia tidak mempunyai faedah yang sama, dan tidak ada sebab mengapa kita harus meninggalkan git memihak kepada S3 sama sekali.
Organisasi itu berkembang dan keupayaan untuk berkongsi susunan biasa mencapai tahap kritikal. Terraform menjadikan ini semua mudah dan semula jadi, manakala CloudFormation akan membuat anda melompat melalui gelung sebelum anda boleh mendapatkan sesuatu seperti ini berfungsi.
Operasi sebagai kod
"Mari kita skrip dan okey."
βseorang jurutera 3 tahun sebelum mencipta basikal Terraform.
Apabila ia datang kepada pembangunan perisian, Go atau program Java bukan hanya kod.
Kod sebagai Kod
Terdapat juga infrastruktur di mana ia berfungsi.
Infrastruktur sebagai Kod
Tetapi dari mana dia? Bagaimana untuk memantaunya? Di manakah kod anda tinggal? Adakah pembangun memerlukan kebenaran akses?
Operasi sebagai Kod
Menjadi pembangun perisian bukan sahaja bermakna menulis kod.
AWS bukan satu-satunya: anda mungkin menggunakan penyedia lain. SignalFx, PagerDuty atau Github. Mungkin anda mempunyai pelayan Jenkins dalaman untuk CI/CD atau papan pemuka Grafana dalaman untuk pemantauan. Infra as Code dipilih atas sebab yang berbeza, dan setiap satu adalah sama penting untuk semua yang berkaitan dengan perisian.
Apabila saya bekerja di Twitch, kami mempercepatkan perkhidmatan dalam sistem terbenam campuran dan AWS Amazon. Kami menghasilkan dan menyokong banyak perkhidmatan mikro, meningkatkan kos operasi. Perbincangan berjalan seperti ini:
- Π―: Sial, itu banyak gerak isyarat untuk overclock satu perkhidmatan mikro. Saya perlu menggunakan sampah ini untuk membuat akaun AWS (kami pergi ke 2 akaun pada perkhidmatan mikro), kemudian yang ini untuk menyediakan makluman, yang ini untuk repositori kod, dan yang ini untuk senarai e-mel, dan yang ini...
- Memimpin: Mari kita skrip dan okay.
- Π―: Baiklah, tetapi skrip itu sendiri akan berubah. Kami memerlukan satu cara untuk memastikan semua gizmos Amazon terbina dalam ini adalah terkini.
- Memimpin: Bunyinya bagus. Dan kami akan menulis skrip untuk ini.
- Π―: Hebat! Dan skrip mungkin masih perlu menetapkan parameter. Adakah dia akan menerima mereka?
- Memimpin: Biarkan dia mengambil tempat dia pergi!
- Π―: Proses mungkin berubah dan keserasian ke belakang akan hilang. Beberapa jenis kawalan versi semantik akan diperlukan.
- Memimpin: Idea bernas!
- Π―: Alat boleh ditukar secara manual, di dalam antara muka pengguna. Kami memerlukan cara untuk menyemak dan membetulkan perkara ini.
β¦ 3 tahun kemudian:
- Memimpin: Dan kami mendapat terraform.
Moral cerita itu ialah: walaupun anda kepala atas tumit dalam segala-galanya Amazon, anda masih menggunakan sesuatu yang bukan daripada AWS, dan perkhidmatan ini mempunyai keadaan yang menggunakan bahasa konfigurasi untuk memastikan keadaan itu segerak.
CloudFormation lambda vs git modul terraform
lambda ialah penyelesaian CloudFormation kepada isu logik tersuai. Dengan lambda anda boleh atau . Pendekatan ini memperkenalkan kerumitan tambahan yang tidak terdapat dalam versi semantik modul git Terraform. Bagi saya, masalah yang paling mendesak ialah mengurus kebenaran untuk semua lambda pengguna ini (dan ini adalah berpuluh-puluh akaun AWS). Satu lagi masalah penting ialah masalah "apa yang datang dahulu, ayam atau telur?": ia berkaitan dengan kod lambda. Fungsi ini sendiri adalah infrastruktur dan kod, dan ia sendiri memerlukan pemantauan dan kemas kini. Paku terakhir dalam keranda ialah kesukaran untuk mengemas kini perubahan kod lambda secara semantik; kami juga perlu memastikan bahawa tindakan tindanan tanpa arahan langsung tidak berubah antara larian.
Saya masih ingat pernah saya ingin mencipta penggunaan kenari untuk persekitaran Elastic Beanstalk dengan pengimbang beban klasik. Perkara paling mudah untuk dilakukan ialah membuat penggunaan kedua untuk EB bersebelahan dengan persekitaran pengeluaran, mengambil langkah lebih jauh: menggabungkan kumpulan penggunaan kenari penskalaan automatik dengan LB penggunaan ke dalam persekitaran pengeluaran. Dan sejak Terraform menggunakan , ini memerlukan 4 baris kod tambahan dalam Terraform. Apabila saya bertanya sama ada terdapat penyelesaian yang setanding dalam CloudFormation, mereka menunjukkan saya kepada repositori git keseluruhan dengan saluran paip penggunaan dan segala-galanya, semuanya demi apa yang boleh dilakukan oleh 4 baris kod Terraform yang lemah.
Ia mengesan drift dengan lebih baik
Pastikan realiti sepadan dengan jangkaan.
ialah operasi yang sangat berkuasa sebagai ciri kod kerana ia membantu memastikan realiti sepadan dengan jangkaan. Ia tersedia dengan CloudFormation dan Terraform. Tetapi apabila timbunan pengeluaran berkembang, mencari drift dalam CloudFormation menghasilkan lebih banyak pengesanan palsu.
Dengan Terraform anda mempunyai cangkuk kitaran hayat yang lebih maju untuk pengesanan hanyut. Sebagai contoh, anda memasukkan arahan terus dalam definisi tugas ECS jika anda ingin mengabaikan perubahan pada definisi tugas tertentu tanpa mengabaikan perubahan pada keseluruhan penggunaan ECS anda.
CDK dan masa depan CloudFormation
CloudFormation sukar diurus secara besar-besaran, skala merentas infrastruktur. Banyak daripada kesukaran ini diiktiraf dan alat itu memerlukan perkara seperti itu , rangka kerja untuk menentukan infrastruktur awan dalam kod dan menjalankannya melalui AWS CloudFormation. Menarik untuk melihat masa depan aws-cdk, tetapi ia akan menghadapi masa yang sukar untuk bersaing dengan kekuatan lain Terraform; untuk mengemas kini CloudFormation, perubahan global akan diperlukan.
Supaya Terraform tidak mengecewakan
Ini adalah "infrastruktur sebagai kod", dan bukan "sebagai teks".
Tanggapan pertama saya terhadap Terraform agak teruk. Saya rasa saya tidak faham pendekatannya. Hampir semua jurutera secara tidak sengaja menganggapnya sebagai format teks yang perlu ditukar kepada infrastruktur yang dikehendaki. JANGAN LAKUKAN CARA INI.
Kebenaran pembangunan perisian yang baik juga digunakan untuk Terraform.
Saya telah melihat banyak amalan yang digunakan untuk mencipta kod yang baik diabaikan dalam Terraform. Anda telah belajar selama bertahun-tahun untuk menjadi seorang pengaturcara yang baik. Jangan lepaskan pengalaman ini hanya kerana anda bekerja dengan Terraform. Kebenaran pembangunan perisian yang baik digunakan untuk Terraform.
Bagaimanakah kod itu tidak boleh didokumenkan?
Saya telah melihat susunan Terraform yang besar tanpa dokumentasi sama sekali. Bagaimanakah anda boleh menulis kod dalam halaman - tanpa dokumentasi sama sekali? Tambah dokumentasi yang menerangkan anda kod Terraform (penekanan pada perkataan "kod"), mengapa bahagian ini sangat penting, dan perkara yang anda lakukan.
Bagaimanakah kita boleh menggunakan perkhidmatan yang pernah menjadi satu fungsi utama() yang besar?
Saya telah melihat susunan Terraform yang sangat kompleks dibentangkan sebagai satu modul. Mengapa kita tidak menggunakan perisian dengan cara ini? Mengapa kita membahagikan fungsi besar kepada yang lebih kecil? Jawapan yang sama digunakan untuk Terraform. Jika modul anda terlalu besar, anda perlu memecahkannya kepada modul yang lebih kecil.
Adakah syarikat anda tidak menggunakan perpustakaan?
Saya telah melihat bagaimana jurutera, memutarkan projek baharu menggunakan Terraform, dengan bodohnya menyalin-tampal sebahagian besar daripada projek lain ke dalam projek mereka sendiri, dan kemudian mengutak-atiknya sehingga ia mula berfungsi. Adakah anda akan bekerja seperti ini dengan kod "pertempuran" dalam syarikat anda? Kami bukan hanya menggunakan perpustakaan. ya, tetapi di manakah kita tanpa perpustakaan bersama pada dasarnya?!
Adakah anda tidak menggunakan PEP8 atau gofmt?
Kebanyakan bahasa mempunyai skema pemformatan standard yang diterima. Dalam Python ini adalah PEP8. Dalam Go - gofmt. Terraform mempunyai sendiri: terraform fmt. Nikmati untuk kesihatan anda!
Adakah anda akan menggunakan React tanpa mengetahui JavaScript?
Modul Terraform boleh memudahkan beberapa bahagian infrastruktur kompleks yang anda cipta, tetapi ini tidak bermakna anda tidak boleh bermain-main dengannya sama sekali. Ingin menggunakan Terraform dengan betul tanpa memahami sumber? Anda ditakdirkan: masa akan berlalu, dan anda tidak akan pernah menguasai Terraform.
Adakah anda mengekod dengan singleton atau suntikan pergantungan?
Suntikan kebergantungan ialah amalan terbaik yang diiktiraf untuk pembangunan perisian dan lebih diutamakan berbanding individu tunggal. Bagaimanakah ini berguna dalam Terraform? Saya telah melihat modul Terraform yang bergantung pada keadaan jauh. Daripada menulis modul yang mendapatkan keadaan jauh, tulis modul yang mengambil parameter. Dan kemudian hantar parameter ini ke modul.
Adakah perpustakaan anda melakukan sepuluh perkara dengan baik atau satu perkara yang hebat?
Perpustakaan yang berfungsi paling baik ialah perpustakaan yang menumpukan pada satu tugasan yang mereka lakukan dengan baik. Daripada menulis modul Terraform besar yang cuba melakukan segala-galanya sekaligus, bina bahagian modul tersebut yang melakukan satu perkara dengan baik. Dan kemudian gabungkan mereka mengikut keperluan.
Bagaimanakah anda membuat perubahan pada perpustakaan tanpa keserasian ke belakang?
Modul Terraform biasa, seperti perpustakaan biasa, perlu menyampaikan perubahan kepada pengguna tanpa serasi ke belakang. Ia menjengkelkan apabila perubahan ini berlaku dalam perpustakaan, dan ia sama menjengkelkan apabila perubahan tidak serasi ke belakang dibuat dalam modul Terraform. Adalah disyorkan untuk menggunakan tag git dan semver apabila menggunakan modul Terraform.
Adakah perkhidmatan pengeluaran anda berjalan pada komputer riba anda atau di pusat data?
Hashicorp mempunyai alatan seperti untuk menjalankan terraform anda. Perkhidmatan berpusat ini memudahkan untuk mengurus, mengaudit dan meluluskan perubahan bentuk.
Adakah anda tidak menulis ujian?
Jurutera menyedari bahawa kod itu perlu diuji, tetapi mereka sendiri sering lupa tentang ujian apabila bekerja dengan Terraform. Untuk infrastruktur, ini penuh dengan detik-detik berbahaya. Nasihat saya ialah untuk "menguji" atau "membuat tindanan contoh" menggunakan modul yang boleh digunakan dengan betul untuk ujian semasa CI/CD.
Terraform dan perkhidmatan mikro
Kehidupan dan kematian syarikat perkhidmatan mikro bergantung pada kelajuan, inovasi dan gangguan susunan kerja perkhidmatan mikro baharu.
Aspek negatif yang paling biasa dikaitkan dengan seni bina perkhidmatan mikro, dan yang tidak boleh dihapuskan, adalah berkaitan dengan kerja, bukan kod. Jika anda menganggap Terraform hanya sebagai satu cara untuk mengautomasikan hanya sisi infrastruktur seni bina perkhidmatan mikro, maka anda kehilangan manfaat sebenar sistem. Sekarang sudah .
Sumber: www.habr.com