Nampaknya pembangun Terraform menawarkan amalan terbaik yang agak mudah untuk bekerja dengan infrastruktur AWS. Hanya ada nuansa. Dari masa ke masa, bilangan persekitaran bertambah, ciri muncul dalam setiap persekitaran. Muncul hampir salinan tindanan aplikasi di rantau jiran. Dan kod Terraform perlu disalin dan diedit dengan teliti mengikut keperluan baharu atau untuk membuat kepingan salji.
Laporan saya adalah mengenai corak dalam Terraform untuk memerangi huru-hara dan rutin manual pada projek besar dan panjang.
Video:
Saya berumur 40 tahun, saya telah berada dalam bidang IT selama 20 tahun. Saya telah bekerja di Ixtens selama 12 tahun. Kami terlibat dalam pembangunan berasaskan e-dagang. Dan saya telah mengamalkan amalan DevOps selama 5 tahun.
Kisah saya akan mengenai pengalaman dalam projek di sebuah syarikat yang namanya tidak saya sebutkan, berselindung di sebalik perjanjian tanpa pendedahan.
Nombor pada slaid diberikan untuk memahami skop projek. Dan semua yang saya akan katakan seterusnya adalah berkaitan dengan Amazon.
Saya menyertai projek ini 4 tahun yang lalu. Dan pemfaktoran semula infrastruktur sedang giat dijalankan, kerana projek itu telah berkembang. Dan corak yang digunakan, mereka tidak lagi sesuai. Dan memandangkan semua pertumbuhan projek yang dirancang, adalah perlu untuk menghasilkan sesuatu yang baru.
Terima kasih kepada Matvey, yang semalam memberitahu kami apa yang berlaku di Dodo Pizza. Inilah yang berlaku di sini 4 tahun yang lalu.
Pemaju datang dan mula membuat kod infrastruktur.
Sebab yang paling jelas mengapa ini diperlukan ialah masa untuk memasarkan. Ia adalah perlu untuk memastikan bahawa pasukan DevOps tidak menjadi halangan apabila dilancarkan. Dan antara lain, Terraform dan Puppet digunakan pada peringkat pertama.
Terraform ialah projek sumber terbuka daripada HashiCorp. Dan bagi mereka yang tidak tahu apa itu, beberapa slaid seterusnya.
Infrastruktur sebagai kod bermakna kami boleh menerangkan infrastruktur kami dan meminta beberapa robot untuk memastikan kami mendapat sumber yang kami nyatakan.
Sebagai contoh, kita memerlukan mesin maya. Kami akan menerangkan, menambah beberapa parameter yang diperlukan.
Selepas itu, kami akan mengkonfigurasi akses kepada Amazon dalam konsol. Dan minta pelan Terraform. Pelan Terraform akan berkata: "Ok, untuk sumber anda, kami boleh melakukan perkara ini." Dan sekurang-kurangnya satu sumber akan ditambah. Dan tiada perubahan dijangka.
Selepas semuanya sesuai dengan anda, anda boleh meminta Terraform memohon dan Terraform akan mencipta contoh untuk anda, dan anda akan mendapat mesin maya dalam awan anda.
Selanjutnya, projek kami berkembang. Kami menambah beberapa perubahan di sana. Kami meminta lebih banyak contoh, kami menambah 53 entri.
Dan kami ulangi. Sila rancang. Kita lihat apa perubahan yang dirancang. Kami memohon. Dan ini adalah bagaimana infrastruktur kami berkembang.
Terraform menggunakan perkara seperti fail negeri. Iaitu, ia menyimpan semua perubahan yang pergi ke Amazon dalam fail, di mana untuk setiap sumber yang anda terangkan, terdapat sumber yang sepadan yang dibuat di Amazon. Oleh itu, apabila menukar perihalan sumber, Terraform mengetahui dengan tepat apa yang perlu diubah di Amazon.
Fail keadaan ini pada asalnya hanyalah fail. Dan kami menyimpannya dalam Git, yang sangat menyusahkan. Sentiasa seseorang terlupa untuk melakukan perubahan, dan terdapat banyak konflik.
Kini adalah mungkin untuk menggunakan bahagian belakang, iaitu Terraform ditentukan dalam baldi mana dan dengan kunci mana fail keadaan harus disimpan. Dan Terraform sendiri akan menguruskan mendapatkan fail keadaan ini, melakukan semua keajaiban dan meletakkan kembali keputusan akhir.
Infrastruktur kami semakin berkembang. Inilah kod kami. Dan kini kami tidak mahu hanya mencipta mesin maya, kami mahu mempunyai persekitaran ujian.
Terraform membolehkan anda membuat perkara sedemikian sebagai modul, iaitu menerangkan perkara yang sama dalam beberapa folder.
Dan, sebagai contoh, dalam ujian, panggil modul ini dan dapatkan perkara yang sama seolah-olah kita sedang menggunakan Terraform dalam modul itu sendiri. Berikut ialah kod untuk ujian.
Untuk pengeluaran, kami boleh menghantar beberapa perubahan ke sana, kerana dalam ujian kami tidak memerlukan contoh besar, dalam pengeluaran contoh besar akan berguna.
Dan kemudian saya akan kembali kepada projek itu. Ia adalah satu tugas yang sukar, infrastruktur telah dirancang dengan sangat besar. Dan entah bagaimana perlu meletakkan semua kod supaya ia mudah untuk semua orang: bagi mereka yang melakukan penyelenggaraan pada kod ini, dan bagi mereka yang membuat perubahan. Dan ia telah dirancang bahawa mana-mana pembangun boleh pergi dan membaiki infrastruktur seperti yang diperlukan untuk bahagian platformnya.
Ini ialah pepohon direktori yang disyorkan oleh HashiCorp jika anda mempunyai projek yang besar dan masuk akal untuk membahagikan keseluruhan infrastruktur kepada beberapa bahagian kecil, dan menerangkan setiap bahagian dalam folder yang berasingan.
Mempunyai perpustakaan sumber yang luas, anda boleh memanggil perkara yang sama dalam ujian dan dalam pengeluaran.
Dalam kes kami, ini tidak sesuai sepenuhnya, kerana timbunan ujian untuk pembangun atau untuk ujian perlu diperoleh dengan cara yang lebih mudah. Dan saya tidak mahu pergi melalui folder dan memohon dalam urutan yang betul, dan bimbang bahawa pangkalan akan meningkat, dan kemudian contoh yang menggunakan pangkalan ini akan meningkat. Oleh itu, semua ujian telah dilancarkan dari satu folder. Modul yang sama dipanggil di sana, tetapi semuanya berjalan dalam satu larian.
Terraform menjaga semua kebergantungan. Dan ia sentiasa mencipta sumber dalam urutan itu supaya anda boleh mendapatkan alamat IP, contohnya, daripada contoh yang baru dibuat, dan mendapatkan alamat IP ini dalam entri route53.
Di samping itu, platformnya sangat besar. Dan menjalankan timbunan ujian, walaupun selama sejam, walaupun selama 8 jam, adalah perniagaan yang agak mahal.
Dan kami telah mengautomasikan perniagaan ini. Dan tugas Jenkins membenarkan timbunan berjalan. Ia adalah perlu untuk melancarkan permintaan tarik di dalamnya dengan perubahan yang ingin diuji oleh pembangun, nyatakan semua pilihan, komponen dan saiz yang diperlukan. Jika dia mahukan ujian prestasi, maka dia boleh mengambil lebih banyak contoh. Jika dia hanya perlu menyemak bahawa beberapa borang dibuka, dia boleh bermula dengan gaji minimum. Dan juga menunjukkan sama ada kluster diperlukan atau tidak, dsb.
Dan kemudian Jenkins menolak skrip shell yang mengubah sedikit kod dalam folder Terraform. Mengalih keluar fail yang tidak diperlukan, menambah fail yang diperlukan. Dan kemudian, dengan satu larian Terraform digunakan, timbunan meningkat.
Dan kemudian ada langkah lain yang saya tidak mahu pergi.
Disebabkan fakta bahawa untuk ujian, kami memerlukan lebih sedikit pilihan daripada dalam pengeluaran, kami terpaksa membuat salinan modul supaya dalam salinan ini kami boleh menambah ciri-ciri yang diperlukan hanya dalam ujian.
Dan kebetulan dalam ujian, nampaknya anda ingin menguji perubahan tersebut yang akhirnya akan pergi ke pengeluaran. Tetapi sebenarnya, satu perkara telah diuji, dan sedikit berbeza digunakan dalam pengeluaran. Dan terdapat sedikit rehat dalam corak bahawa dalam pengeluaran semua perubahan telah digunakan oleh pasukan operasi. Dan kadang-kadang ternyata perubahan yang sepatutnya pergi dari ujian ke pengeluaran, mereka kekal dalam versi lain.
Di samping itu, terdapat masalah sedemikian sehingga perkhidmatan baharu telah ditambah, yang sedikit berbeza daripada perkhidmatan sedia ada. Dan bukannya mengubah suai modul sedia ada, anda perlu membuat salinannya dan menambah perubahan yang diperlukan.
Sebenarnya, Terraform bukanlah bahasa sebenar. Ini adalah pengisytiharan. Jika kita perlu mengisytiharkan sesuatu, maka kita mengisytiharkannya. Dan semuanya berfungsi.
Pada satu ketika, apabila membincangkan salah satu permintaan tarik saya, salah seorang rakan sekerja saya berkata bahawa tidak perlu menghasilkan kepingan salji. Saya tertanya-tanya apa yang dia maksudkan. Terdapat fakta saintifik bahawa di dunia tidak ada dua kepingan salji yang sama, semuanya sedikit, tetapi berbeza. Dan sebaik sahaja saya mendengar ini, saya serta-merta merasakan berat penuh kod Terraform. Kerana apabila ia diperlukan untuk beralih dari versi ke versi, Terraform memerlukan perubahan rantaian terputus, iaitu kod itu tidak lagi serasi dengan versi seterusnya. Dan saya terpaksa membuat permintaan tarik, yang meliputi hampir separuh daripada fail dalam infrastruktur, untuk membawa infrastruktur ke versi Terraform yang seterusnya.
Dan selepas kepingan salji seperti itu muncul, semua kod Terraform yang kami telah bertukar menjadi longgokan salji yang besar dan besar.
Bagi pembangun luar yang berada di luar operasi, ia tidak begitu penting baginya, kerana dia membuat permintaan tarik, sumbernya bermula. Dan itu sahaja, ia bukan kebimbangannya. Dan pasukan DevOps yang memastikan semuanya OK perlu membuat semua perubahan ini. Dan kos perubahan ini meningkat sangat, sangat banyak dengan setiap kepingan salji tambahan.
Terdapat satu cerita tentang bagaimana seorang pelajar di seminar melukis dua bulatan sempurna dengan kapur di papan hitam. Dan guru itu terkejut bagaimana dia berjaya melukis dengan begitu lancar tanpa kompas. Pelajar itu menjawab: "Ia sangat mudah, saya menghidupkan penggiling daging selama dua tahun dalam tentera."
Dan daripada empat tahun saya menjalankan projek ini, saya telah melakukan Terraform selama kira-kira dua tahun. Dan, sudah tentu, saya mempunyai beberapa helah, beberapa petua tentang cara untuk memudahkan kod Terraform, bekerja dengannya seperti bahasa pengaturcaraan dan mengurangkan beban pada pembangun yang mesti memastikan kod ini dikemas kini.
Perkara pertama yang saya ingin mulakan ialah Symlinks. Terraform mempunyai banyak kod berulang. Sebagai contoh, memanggil pembekal di hampir setiap titik di mana kami mencipta sekeping infrastruktur adalah sama. Dan adalah logik untuk meletakkannya dalam ayah yang berasingan. Dan di mana sahaja pembekal dikehendaki membuat Symlinks ke fail ini.
Contohnya, anda menggunakan anggap peranan dalam pengeluaran, yang membolehkan anda mendapatkan hak akses kepada beberapa akaun Amazon luaran. Dan dengan menukar satu fail, semua baki yang ada dalam pepohon sumber akan mempunyai hak yang diperlukan supaya Terraform mengetahui segmen Amazon yang mana untuk diakses.
Di manakah Symlinks gagal? Seperti yang saya katakan, Terraform mempunyai fail negeri. Dan mereka sangat, sangat keren. Tetapi masalahnya ialah Terraform memulakan bahagian belakang di tempat pertama. Dan dia tidak boleh menggunakan sebarang pembolehubah dalam parameter ini; mereka mesti sentiasa ditulis dalam teks.
Dan akibatnya, apabila seseorang membuat sumber baharu, dia menyalin sebahagian kod daripada folder lain. Dan dia boleh membuat kesilapan dengan kunci atau dengan baldi. Contohnya, dia membuat kotak pasir daripada kotak pasir, dan kemudian membuatnya dalam pengeluaran. Oleh itu, mungkin ternyata baldi dalam pengeluaran akan digunakan dari kotak pasir. Sudah tentu, mereka akan menemuinya dengan cepat. Ia akan menjadi mungkin untuk membetulkannya, tetapi ia adalah satu pembaziran masa dan, sedikit sebanyak, sumber.
Apa yang boleh kita lakukan seterusnya? Sebelum bekerja dengan Terraform, anda perlu memulakannya. Pada masa permulaan, Terraform memuat turun semua pemalam. Pada satu ketika, mereka pecah daripada monolit kepada seni bina perkhidmatan mikro yang lebih. Dan anda sentiasa perlu melakukan Terraform init supaya ia menarik semua modul, semua pemalam.
Dan anda boleh menggunakan skrip shell, yang, pertama, boleh mendapatkan semua pembolehubah. Skrip Shell tidak terhad. Dan, kedua, cara. Jika kita sentiasa menggunakan laluan yang ada dalam repositori sebagai kunci kepada fail keadaan, maka, dengan itu, ralat akan dikecualikan di sini.
Di mana untuk mendapatkan data? fail JSON. Terraform membolehkan anda menulis infrastruktur bukan sahaja dalam hcl (Bahasa Konfigurasi HashiCorp), tetapi juga dalam JSON.
JSON mudah dibaca daripada skrip shell. Oleh itu, anda boleh meletakkan fail konfigurasi dengan baldi di beberapa tempat. Dan gunakan baldi ini dalam kod Terraform dan dalam skrip shell untuk permulaan.
Mengapakah penting untuk mempunyai baldi Terraform? Kerana terdapat perkara seperti fail negeri jauh. Iaitu, apabila saya meningkatkan beberapa sumber, untuk memberitahu Amazon: "Sila nyatakan contoh", saya perlu menentukan banyak parameter yang diperlukan.
Dan pengecam ini disimpan dalam beberapa folder lain. Dan saya boleh menerimanya dan berkata: "Terraform, sila jalankan ke fail keadaan sumber itu dan dapatkan saya pengecam ini." Dan dengan itu terdapat sejenis penyatuan antara kawasan atau persekitaran yang berbeza.
Ia tidak selalu boleh menggunakan fail keadaan jauh. Contohnya, anda membuat VPC secara manual. Dan kod Terraform yang mencipta VPC mencipta VPC yang berbeza sehingga ia mengambil masa yang sangat lama dan anda perlu menyesuaikan satu dengan yang lain, supaya anda boleh menggunakan helah berikut.
Iaitu, untuk membuat modul yang, seolah-olah, membuat VPC dan memberi anda pengecam, tetapi sebenarnya terdapat hanya fail dengan nilai berkod keras yang boleh digunakan untuk mencipta contoh yang sama.
Ia tidak semestinya perlu untuk menyimpan fail keadaan dalam awan. Sebagai contoh, semasa menguji modul, anda boleh menggunakan permulaan bahagian belakang, apabila fail akan disimpan hanya pada cakera pada masa ujian.
Sekarang sedikit tentang ujian. Apakah yang boleh diuji dalam Terraform? Mungkin, banyak yang boleh, tetapi saya akan bercakap tentang 4 perkara ini.
HashiCorp mempunyai pemahaman tentang cara memformat kod Terraform. Dan Terraform fmt membolehkan anda memformat kod yang anda edit mengikut kepercayaan itu. Sehubungan itu, ujian mesti semestinya menyemak sama ada pemformatan sepadan dengan apa yang diwariskan oleh HashiCorp, supaya anda tidak perlu menukar lokasi kurungan, dsb.
Yang seterusnya ialah Terraform validate. Ia melakukan lebih sedikit daripada semakan sintaks - ala, adakah semua kurungan berpasangan. Apa yang penting di sini? Kami mempunyai infrastruktur yang sangat nipis. Ia mempunyai banyak folder yang berbeza. Dan dalam setiap anda perlu menjalankan Terraform validate.
Sehubungan itu, untuk mempercepatkan ujian, kami menjalankan beberapa proses secara selari menggunakan selari.
Selari adalah perkara yang sangat keren, gunakannya.
Tetapi setiap kali Terraform dimulakan, ia pergi ke HashiCorp dan bertanya, βApakah pemalam terbaharu? Dan pemalam yang saya ada dalam cache - adakah ia satu atau tidak? Dan ia perlahan pada setiap langkah.
Jika Terraform memberitahu anda di mana pemalam itu berada, Terraform akan berkata: "OK, ini mungkin perkara paling segar yang ada. Saya tidak akan pergi ke mana-mana, saya akan mula mengesahkan kod Terraform anda dengan segera."
Untuk mengisi folder dengan pemalam yang diperlukan, kami mempunyai kod Terraform yang sangat mudah yang hanya perlu dimulakan. Di sini, sudah tentu, anda perlu menentukan semua pembekal yang entah bagaimana mengambil bahagian dalam kod anda, jika tidak, Terraform akan berkata: "Saya tidak mengenali pembekal tertentu kerana ia tiada dalam cache."
Yang seterusnya ialah pelan Terraform. Seperti yang saya katakan, pembangunan adalah kitaran. Kami membuat kod dengan perubahan. Dan kemudian anda perlu mengetahui perubahan yang dirancang untuk infrastruktur.
Dan apabila infrastruktur adalah sangat, sangat besar, anda boleh menukar satu modul, membetulkan beberapa persekitaran ujian atau beberapa wilayah tertentu, dan memecahkan beberapa modul yang berdekatan. Oleh itu, pelan Terraform harus dibuat untuk keseluruhan infrastruktur dan menunjukkan perubahan yang dirancang.
Anda boleh melakukannya dengan cara yang bijak. Sebagai contoh, kami menulis skrip Python yang menyelesaikan kebergantungan. Dan bergantung pada apa yang telah diubah: modul Terraform atau hanya komponen tertentu, ia membuat rancangan untuk semua folder bergantung.
Pelan terraform mesti dilakukan atas permintaan. Sekurang-kurangnya itulah yang kita lakukan.
Ujian, sudah tentu, bagus untuk dilakukan untuk setiap perubahan, untuk setiap komitmen, tetapi rancangan adalah perkara yang agak mahal. Dan kami berkata dalam permintaan tarik: "Sila berikan saya rancangannya." Robot bermula. Dan menghantar kepada ulasan atau untuk melampirkan semua rancangan yang diharapkan daripada perubahan anda.
Pelan adalah perkara yang agak mahal. Ia mengambil masa kerana Terraform pergi ke Amazon dan bertanya, "Adakah contoh ini masih wujud? Adakah skala auto ini mempunyai parameter yang sama?β Dan untuk mempercepatkan ini, anda boleh menggunakan parameter seperti refresh=false. Ini bermakna Terraform akan memuat turun keadaan daripada S3. Dan ia akan percaya bahawa negeri itu akan sepadan dengan apa yang ada di Amazon.
Pelan Terraform sedemikian jauh lebih pantas, tetapi negeri mesti sepadan dengan infrastruktur anda, iaitu, di suatu tempat, kadangkala penyegaran Terraform mesti bermula. Penyegaran Terraform melakukan perkara itu, supaya keadaan sepadan dengan apa yang ada dalam infrastruktur sebenar.
Dan saya mesti katakan tentang keselamatan. Di sinilah ia sepatutnya bermula. Di mana anda menjalankan Terraform dan Terraform berfungsi dengan infrastruktur anda, terdapat kelemahan. Iaitu, anda pada dasarnya melaksanakan kod. Dan jika permintaan tarik mengandungi beberapa jenis kod berniat jahat, maka ia boleh dilaksanakan pada infrastruktur yang mempunyai terlalu banyak akses. Oleh itu, berhati-hati di mana anda melancarkan pelan Terraform.
Perkara seterusnya yang saya ingin bincangkan ialah ujian data pengguna.
Apakah data pengguna? Di Amazon, apabila kami membuat contoh, kami boleh menghantar beberapa jenis surat daripada contoh - data meta. Apabila kejadian dimulakan, biasanya cloud init sentiasa ada pada kejadian tersebut. Cloud init membaca surat ini dan berkata: "OK, hari ini saya pengimbang beban." Dan selaras dengan ajaran ini, dia melakukan beberapa tindakan.
Tetapi, malangnya, apabila kami melakukan pelan Terraform dan Terraform digunakan, data pengguna kelihatan seperti buburan nombor ini. Iaitu, dia hanya menghantar cincang kepada anda. Dan apa yang anda boleh lihat dalam rancangan ialah sama ada akan ada sebarang perubahan atau cincangan akan kekal sama.
Dan jika anda tidak memberi perhatian kepada ini, maka beberapa fail teks yang dipukul mungkin pergi ke Amazon, ke infrastruktur sebenar.
Sebagai alternatif, anda tidak boleh menentukan keseluruhan infrastruktur semasa pelaksanaan, tetapi hanya templat. Dan dalam kod, katakan: "Sila paparkan templat ini untuk saya." Dan sebagai hasilnya, anda boleh mendapatkan cetakan rupa data anda di Amazon.
Pilihan lain ialah menggunakan modul untuk menjana data pengguna. Anda akan menggunakan modul ini. Dapatkan fail pada cakera. Bandingkan dengan rujukan. Oleh itu, jika sesetengah Jun memutuskan untuk membetulkan sedikit data pengguna, maka ujian anda akan berkata: "OK, terdapat beberapa perubahan di sana sini - ini adalah perkara biasa."
Perkara seterusnya yang saya ingin bincangkan ialah Automate Terraform apply.
Sudah tentu, ia cukup menakutkan untuk melakukan Terraform memohon dalam mod automatik, kerana siapa tahu perubahan yang berlaku di sana dan betapa memudaratkannya kepada infrastruktur yang hidup.
Untuk persekitaran ujian, ini semua baik-baik saja. Iaitu, kerja yang mewujudkan persekitaran ujian adalah perkara yang diperlukan oleh semua pembangun. Dan ungkapan seperti "semuanya bekerja untuk saya" bukanlah meme lucu, tetapi bukti bahawa seseorang itu keliru, menaikkan timbunan, melancarkan beberapa ujian pada timbunan ini. Dan dia memastikan semuanya baik-baik saja di sana dan berkata: "OK, kod yang saya keluarkan telah diuji."
Dalam pengeluaran, kotak pasir dan persekitaran lain yang lebih kritikal perniagaan, adalah selamat untuk menggunakan sebahagian sumber kerana ia tidak menyebabkan sesiapa pun mati. Ini ialah: kumpulan autoskala, kumpulan keselamatan, peranan, laluan53 dan di sana senarainya mungkin agak besar. Tetapi perhatikan apa yang berlaku, baca laporan aplikasi automatik.
Jika ia berbahaya atau menakutkan untuk digunakan, contohnya, jika ini adalah beberapa sumber yang berterusan, daripada pangkalan data, maka dapatkan laporan bahawa terdapat perubahan yang tidak digunakan dalam beberapa infrastruktur. Dan jurutera itu sudah diawasi menjalankan kerja untuk memohon atau melakukannya dari konsolnya.
Amazon mempunyai perkara seperti perlindungan Terminate. Dan ia boleh melindungi dalam beberapa kes daripada perubahan yang tidak diperlukan untuk anda. Jadi Terraform pergi ke Amazon dan berkata "Saya perlu membunuh contoh ini untuk membuat satu lagi". Dan Amazon berkata, "Maaf, bukan hari ini. Kami mempunyai perlindungan Terminate.β
Dan aising pada kek adalah pengoptimuman kod. Apabila kita bekerja dengan kod Terraform, kita mesti menghantar sejumlah besar parameter kepada modul. Ini adalah parameter yang diperlukan untuk mencipta beberapa jenis sumber. Dan kod itu bertukar menjadi senarai besar parameter yang perlu dihantar dari modul ke modul, dari modul ke modul, terutamanya jika modul bersarang.
Dan ia sangat sukar untuk dibaca. Sangat sukar untuk mengkaji semula ini. Dan selalunya ternyata beberapa parameter sedang disemak dan ia bukanlah yang diperlukan. Dan ia memerlukan masa dan wang untuk membaikinya kemudian.
Oleh itu, saya cadangkan anda menggunakan perkara sedemikian sebagai parameter kompleks yang merangkumi pokok nilai tertentu. Iaitu, anda memerlukan beberapa jenis folder di mana anda mempunyai semua nilai yang anda ingin miliki pada beberapa jenis persekitaran.
Dan dengan memanggil modul ini, anda boleh mendapatkan pepohon yang dijana dalam satu modul biasa, iaitu, dalam modul biasa yang berfungsi sama untuk keseluruhan infrastruktur.
Dalam modul ini, anda boleh melakukan beberapa pengiraan menggunakan ciri baharu dalam Terraform sebagai penduduk tempatan. Dan kemudian dalam satu output, keluarkan beberapa jenis parameter kompleks, yang mungkin termasuk cincang, tatasusunan, dsb.
Mengenai ini, semua penemuan terbaik yang saya telah tamatkan. Dan saya ingin bercerita tentang Columbus. Apabila dia mencari wang untuk ekspedisinya menemui India (seperti yang dia fikirkan ketika itu), tiada siapa yang mempercayainya dan percaya bahawa ia adalah mustahil. Kemudian dia berkata: "Pastikan telur itu tidak jatuh." Semua bankir, orang yang sangat kaya dan mungkin pintar, cuba meletakkan telur itu dalam beberapa cara, dan ia jatuh sepanjang masa. Kemudian Columbus mengambil telur, menekannya sedikit. Kulitnya renyuk dan telurnya tidak bergerak. Mereka berkata, "Oh, itu terlalu mudah!" Dan Columbus menjawab: "Ya, ia terlalu mudah. Dan apabila saya membuka India, semua orang akan menggunakan laluan perdagangan ini.β
Dan apa yang saya baru beritahu anda mungkin perkara yang agak mudah dan remeh. Dan apabila anda mengetahui tentangnya dan mula menggunakannya, ia mengikut urutan perkara. Jadi gunakannya. Dan jika ini adalah perkara biasa untuk anda, maka sekurang-kurangnya anda tahu cara meletakkan telur supaya ia tidak jatuh.
Mari singkirkan:
- Cuba elakkan kepingan salji. Dan semakin sedikit kepingan salji, semakin sedikit sumber yang anda perlukan untuk membuat sebarang perubahan pada keseluruhan infrastruktur besar anda.
- Perubahan berterusan. Iaitu, apabila beberapa perubahan telah berlaku dalam kod, anda perlu membawa infrastruktur anda selaras dengan perubahan ini secepat mungkin. Tidak sepatutnya ada situasi apabila seseorang datang dalam dua atau tiga bulan untuk melihat Elasticsearch, membuat rancangan Terraform, dan terdapat banyak perubahan yang dia tidak jangkakan. Dan ia memerlukan banyak masa untuk menyusun semula segala-galanya.
- Ujian dan automasi. Lebih banyak kod anda diliputi dengan ujian dan cip, lebih keyakinan anda bahawa anda melakukan semuanya dengan betul. Dan penghantaran automatik akan meningkatkan keyakinan anda berkali-kali ganda.
- Kod untuk persekitaran ujian dan pengeluaran hendaklah hampir sama. Secara praktikal, kerana selepas semua, pengeluaran adalah sedikit berbeza dan masih akan ada beberapa nuansa yang akan melampaui persekitaran ujian. Namun begitu, tambah atau tolak ia boleh disediakan.
- Dan jika anda mempunyai banyak kod Terraform dan memerlukan banyak masa untuk memastikan kod ini dikemas kini, maka masih belum terlambat untuk memfaktorkan semula dan mendapatkannya dalam keadaan yang baik.
- infrastruktur yang tidak berubah. Penghantaran AMI mengikut jadual.
- Struktur untuk route53 apabila anda mempunyai banyak entri dan mahukannya berada dalam susunan yang konsisten.
- Lawan had kadar API. Ini adalah apabila Amazon berkata, "Itu sahaja, saya tidak boleh menerima sebarang permintaan lagi, sila tunggu." Dan separuh daripada pejabat sedang menunggu sehingga ia boleh melancarkan infrastrukturnya.
- contoh spot. Amazon bukan acara murah dan tempat membolehkan anda menjimatkan banyak. Dan di sana anda boleh memberitahu keseluruhan laporan mengenainya.
- Keselamatan dan peranan IAM.
- Mencari sumber yang hilang, apabila anda mempunyai contoh asal yang tidak diketahui di Amazone, mereka makan wang. Walaupun kos kejadian $100-150 sebulan, itu lebih daripada $1 setahun. Mencari sumber sedemikian adalah perniagaan yang menguntungkan.
- Dan contoh terpelihara.
Itu sahaja untuk saya. Terraform sangat sejuk, gunakannya. Terima kasih!
soalan
Terima kasih atas laporan itu! Anda mempunyai fail keadaan dalam S3, tetapi bagaimana anda menyelesaikan masalah yang beberapa orang boleh mengambil fail keadaan ini dan cuba untuk digunakan?
Pertama, kita tidak tergesa-gesa. Kedua, terdapat bendera, di mana kami melaporkan bahawa kami sedang mengerjakan beberapa kod. Iaitu, walaupun pada hakikatnya infrastrukturnya sangat besar, ini tidak bermakna seseorang sentiasa menggunakan sesuatu. Dan apabila terdapat fasa aktif, ini adalah masalah, kami menyimpan fail negeri dalam Git. Ini penting, jika tidak seseorang akan membuat fail keadaan, dan kami perlu mengumpulkannya secara manual dalam timbunan untuk meneruskan lebih jauh. Sekarang tidak ada masalah seperti itu. Secara umum, Terraform menyelesaikan masalah ini. Dan jika sesuatu sentiasa berubah, maka anda boleh menggunakan kunci yang menghalang apa yang anda katakan.
Adakah anda menggunakan sumber terbuka atau perusahaan?
Tiada perusahaan, iaitu semua yang anda boleh pergi dan muat turun secara percuma.
Nama saya Stanislav. Saya mahu membuat tambahan kecil. Anda bercakap tentang ciri Amazon yang membolehkan anda membuat contoh tidak boleh dibunuh. Ini juga dalam Terraform sendiri, dalam blok Life Second, anda boleh menetapkan larangan perubahan, atau larangan kemusnahan.
Adalah terhad dalam masa. Jawapan yang bagus.
Saya juga ingin bertanya dua perkara. Pertama, anda bercakap tentang ujian. Pernahkah anda menggunakan sebarang alat ujian? Saya mendengar tentang pemalam Test Kitchen. Mungkin ada sesuatu yang lain. Dan saya ingin bertanya tentang Nilai Tempatan. Bagaimanakah ia pada asasnya berbeza daripada Pembolehubah Input? Dan mengapa saya tidak boleh meparameterkan sesuatu hanya melalui Nilai Tempatan? Saya cuba menangani topik ini, tetapi entah bagaimana saya tidak memikirkannya sendiri.
Kita boleh bercakap dengan lebih terperinci di belakang dewan ini. Alat ujian adalah buatan kami yang lengkap. Tiada apa-apa di sana untuk diuji. Secara umum, terdapat pilihan apabila ujian automatik meningkatkan infrastruktur di suatu tempat, periksa sama ada ia OK, dan kemudian musnahkan semuanya dengan laporan bahawa infrastruktur anda masih dalam keadaan baik. Kami tidak mempunyai itu kerana susunan ujian berjalan setiap hari. Dan itu sudah cukup. Dan jika sesuatu mula pecah, maka ia akan mula pecah tanpa kita periksa di tempat lain.
Berkenaan Nilai Tempatan, mari kita sambung perbualan di luar khalayak.
helo! Terima kasih atas laporan itu! Sangat bermaklumat. Anda mengatakan bahawa anda mempunyai banyak jenis kod yang sama untuk menerangkan infrastruktur. Pernahkah anda mempertimbangkan untuk menjana kod ini?
Soalan yang bagus, terima kasih! Intinya ialah apabila kami menggunakan infrastruktur sebagai kod, kami menganggap bahawa kami melihat kod tersebut dan memahami infrastruktur yang ada di sebalik kod tersebut. Jika kod dijana, maka kita perlu bayangkan apakah kod yang akan dihasilkan untuk memahami jenis infrastruktur yang akan ada. Sama ada kita menjana kod, melaksanakannya, dan pada dasarnya perkara yang sama berlaku. Jadi kami mengikuti jalan yang kami tulis, kami mendapatnya. Penjana tambahan muncul sedikit kemudian apabila kami mula membuatnya. Dan sudah terlambat untuk berubah.
Pernahkah anda mendengar tentang jsonnet?
No
Lihat, ini adalah perkara yang sangat keren. Saya melihat kes tertentu di mana anda boleh menggunakannya dan menjana struktur data.
Penjana adalah baik apabila anda memilikinya, seperti dalam jenaka tentang mesin pencukur. Iaitu, pertama kali muka berbeza, tetapi setiap orang mempunyai wajah yang sama. Penjana sangat sejuk. Tapi, malangnya, muka kami lain sikit. Ini masalah.
Lihat sahaja. Terima kasih!
Nama saya Maxim, saya dari Sberbank. Anda berkata sedikit bahawa anda cuba membawa Terraform kepada analog bahasa pengaturcaraan. Bukankah lebih mudah untuk menggunakan Ansible?
Ini adalah perkara yang sangat berbeza. Ansible boleh mencipta sumber, dan Puppet boleh mencipta sumber di Amazon. Tetapi Terraform betul-betul diasah.
Adakah anda hanya mempunyai Amazon?
Bukannya kita hanya ada Amazon. Kami hampir hanya mempunyai Amazon. Tetapi ciri utama ialah Terraform ingat. Dalam Ansible, jika anda berkata: "Beri saya 5 contoh," maka ia akan timbul, dan kemudian anda berkata: "Dan sekarang saya memerlukan 3." Dan Terraform akan berkata: "Baiklah, saya akan bunuh 2," dan Ansible akan berkata: "Baiklah, ini 3 untuk anda." Jumlah 8.
hello! Terima kasih atas laporan anda! Sangat menarik untuk mendengar tentang Terraform. Saya ingin segera membuat ulasan kecil tentang fakta bahawa Terraform masih tidak mempunyai keluaran yang stabil, jadi layan Terraform dengan berhati-hati.
Sudu yang bagus untuk makan malam. Iaitu, jika anda memerlukan penyelesaian, maka anda kadang-kadang menangguhkan apa yang tidak stabil, dll., tetapi ia berfungsi dan membantu kami.
Soalannya begini. Anda menggunakan hujung belakang Jauh, anda menggunakan S 3. Mengapa anda tidak menggunakan hujung belakang rasmi?
Rasmi?
Awan Terraform.
Bilakah dia muncul?
4 bulan lepas.
Jika ia telah muncul 4 tahun yang lalu, maka, mungkin, saya akan menjawab soalan anda.
Sudah ada fungsi dan kunci terbina dalam, dan anda boleh menyimpan fail keadaan. Cuba ia. Tetapi saya belum menguji sama ada.
Kami menaiki kereta api besar yang bergerak laju. Dan anda tidak boleh hanya mengambil beberapa kereta dan membuangnya.
Anda bercakap tentang kepingan salji, mengapa anda tidak menggunakan cawangan? Mengapa ia tidak berjaya seperti itu?
Kami mempunyai pendekatan sedemikian sehingga keseluruhan infrastruktur berada dalam satu repositori. Terraform, Puppet, semua skrip yang entah bagaimana berkaitan dengan ini, semuanya berada dalam satu repositori. Dengan cara ini kita boleh memastikan bahawa perubahan tambahan diuji satu demi satu. Jika ia adalah sekumpulan cawangan, maka projek sedemikian hampir mustahil untuk dikekalkan. Enam bulan berlalu, dan mereka menyimpang begitu banyak sehingga ia hanyalah sejenis hukuman. Inilah yang saya mahu lari dari sebelum pemfaktoran semula.
iaitu ia tidak berfungsi?
Ia tidak berfungsi sama sekali.
Di cawangan, saya memotong slaid folder. Iaitu, jika anda lakukan untuk setiap timbunan ujian, sebagai contoh, pasukan A mempunyai ayah sendiri, pasukan B mempunyai ayah sendiri, maka ini juga tidak berfungsi. Kami membuat kod persekitaran ujian bersatu yang cukup fleksibel untuk disesuaikan dengan semua orang. Iaitu, kami menyampaikan satu kod.
hello! Nama saya Yura! Terima kasih atas laporan itu! Soalan tentang modul. Anda mengatakan anda menggunakan modul. Bagaimanakah anda menyelesaikan isu jika perubahan dibuat dalam satu modul yang tidak serasi dengan perubahan orang lain? Entah bagaimana versi modul atau cuba membawa keajaiban untuk memenuhi dua keperluan?
Inilah masalah longgokan salji yang besar. Inilah yang kita alami apabila beberapa perubahan yang tidak berbahaya boleh memecahkan beberapa bahagian infrastruktur. Dan ia akan kelihatan hanya selepas beberapa lama.
Maksudnya, belum diputuskan lagi?
Anda membuat modul universal. Elakkan kepingan salji. Dan semuanya akan berjaya. Separuh kedua laporan adalah tentang bagaimana untuk mengelakkan perkara ini.
helo! Terima kasih atas laporan itu! Saya ingin menjelaskan. Di sebalik tabir terdapat longgokan besar, yang mana saya datang. Bagaimanakah boneka dan pengagihan peranan disepadukan?
Data pengguna.
Iaitu, anda hanya meludahkan fail dan entah bagaimana melaksanakannya?
Data pengguna ialah nota, iaitu apabila kita membuat klon imej, kemudian Daemon bangkit di sana dan cuba mencari tahu siapa dia, membaca nota bahawa dia adalah pengimbang beban.
Iaitu, adakah ia sejenis proses berasingan yang diberikan?
Kami tidak menciptanya. Kami menggunakannya.
hello! Saya cuma ada soalan tentang Pengguna - data. Anda berkata bahawa terdapat masalah di sana, bahawa seseorang mungkin menghantar sesuatu ke tempat yang salah. Adakah terdapat beberapa cara untuk menyimpan data pengguna dalam Git yang sama, supaya sentiasa jelas apa yang dimaksudkan oleh Data Pengguna?
Kami menjana data Pengguna daripada templat. Iaitu, bilangan pembolehubah tertentu digunakan di sana. Dan Terraform menjana hasil akhir. Oleh itu, anda tidak boleh hanya melihat templat dan mengatakan apa yang akan berlaku, kerana semua masalah berkaitan dengan fakta bahawa pembangun berpendapat bahawa dia menghantar rentetan dalam pembolehubah ini, tetapi tatasusunan digunakan di sana. Dan dia - bam dan saya - fulan, fulan, baris seterusnya, dan semuanya pecah. Jika ini adalah sumber baharu dan seseorang mengambilnya dan melihat sesuatu tidak berfungsi, maka ia akan diselesaikan dengan cepat. Dan jika kumpulan autoscale ini dikemas kini, maka pada satu ketika kejadian dalam kumpulan autoscale mula diganti. Dan bang, sesuatu tidak berfungsi. Sakitnya.
Ternyata satu-satunya penyelesaian adalah untuk menguji?
Ya, anda melihat masalahnya, anda menambah langkah ujian di sana. Iaitu, output juga boleh diuji. Mungkin tidak begitu mudah, tetapi anda juga boleh meletakkan beberapa tanda - semak bahawa Data Pengguna dipaku di sini.
Nama saya Timur. Sungguh mengagumkan bahawa terdapat laporan tentang cara mengatur Terraform dengan betul.
Saya tak mula pun.
Saya fikir dalam persidangan akan datang, mungkin akan ada. Saya ada soalan mudah. Mengapakah anda mengekodkan nilai dalam modul berasingan daripada menggunakan tfvars, iaitu modul dengan nilai lebih baik daripada tfvars?
Iaitu, saya harus menulis di sini (slaid: Production/environment/settings.tf): domain = variable, domain vpcnetwork, vpcnetwork variable dan stvars - dapatkan perkara yang sama?
Kami melakukannya dengan tepat. Kami merujuk kepada modul sumber tetapan, sebagai contoh.
Sebenarnya, ini adalah tfvars. Tfvars sangat berguna dalam persekitaran ujian. Saya mempunyai tfvars untuk contoh besar, untuk yang kecil. Dan saya melemparkan satu fail ke dalam folder. Dan mendapat apa yang saya mahu. Apabila kita melihat infrastruktur, kita mahu dapat melihat dan segera memahami segala-galanya. Dan ternyata anda perlu melihat di sini, kemudian lihat dalam tfvars.
Ternyata semuanya berada di satu tempat?
Ya, tfvars ialah apabila anda mempunyai satu kod. Dan ia digunakan di beberapa tempat yang berbeza dengan nuansa yang berbeza. Kemudian anda akan membuang tfvars dan mendapatkan nuansa anda. Dan kami adalah infrastruktur sebagai kod dalam bentuk yang paling tulen. Tengok dan faham.
hello! Pernahkah anda menghadapi situasi di mana pembekal awan mengganggu apa yang anda buat Terraform? Katakan kita mengedit metadata. Terdapat kunci ssh. Dan Google sentiasa meletakkan metadata dan kuncinya di sana. Dan Terraform sentiasa menulis bahawa ia mempunyai perubahan. Selepas setiap larian, walaupun tiada apa-apa perubahan, dia sentiasa mengatakan bahawa dia akan mengemas kini medan ini sekarang.
Dengan kunci, tetapi - ya, sebahagian daripada infrastruktur dipengaruhi oleh perkara sedemikian, iaitu Terraform tidak boleh mengubah apa-apa. Kita juga tidak boleh mengubah apa-apa dengan tangan kita. Selagi kita hidup dengannya.
Iaitu, anda menemui ini, tetapi tidak menghasilkan apa-apa, bagaimana dia melakukannya dan melakukannya sendiri?
Malangnya ya.
hello! Nama saya Stanislav Starkov. Mel. my Kumpulan. Bagaimanakah anda menyelesaikan masalah dengan menghasilkan teg pada ..., bagaimana anda menghantarnya ke dalam? Seperti yang saya faham, melalui data Pengguna, untuk menentukan nama hos, menghasut Boneka? Dan bahagian kedua soalan. Bagaimanakah anda menyelesaikan isu ini dalam SG, iaitu apabila anda menjana SG, seratus contoh daripada jenis yang sama, bagaimana untuk menamakannya dengan betul?
Contoh-contoh yang sangat penting bagi kami, kami menamakannya dengan indah. Mereka yang tidak diperlukan, terdapat nota bahawa ini adalah kumpulan autoskala. Dan secara teori anda boleh melakukannya dan mendapatkan yang baharu.
Bagi masalah dengan tag, tidak ada masalah seperti itu, tetapi ada tugas sedemikian. Dan kami menggunakan tag dengan sangat, sangat berat, kerana infrastrukturnya besar dan mahal. Dan kita perlu melihat ke mana wang itu pergi, jadi tag membolehkan kita memecahkan apa yang pergi ke mana. Dan, sewajarnya, mencari sesuatu yang bermakna banyak wang dibelanjakan di sini.
Apa lagi soalan itu?
Apabila SG mencipta seratus contoh, adakah mereka perlu dibezakan entah bagaimana?
Tidak, jangan. Setiap contoh mempunyai ejen yang memberitahu saya bahawa saya mempunyai masalah. Jika ejen melaporkan, maka ejen itu tahu tentang dia dan, sekurang-kurangnya, alamat IPnya wujud. Anda sudah boleh berlari. Kedua, kami menggunakan Konsul untuk Penemuan, di mana tiada Kubernetes. Dan Konsul juga menunjukkan alamat IP contoh.
Iaitu, anda menyasarkan tepat IP, dan bukan nama hos ?
Adalah mustahil untuk menavigasi dengan nama hos, iaitu terdapat banyak daripada mereka. Terdapat pengecam contoh - AE, dll. Anda boleh menemuinya di suatu tempat, anda boleh membuangnya ke dalam carian.
helo! Saya menyedari bahawa Terraform adalah perkara yang baik, disesuaikan dengan awan.
Bukan sahaja.
Inilah soalan yang menarik minat saya. Jika anda memutuskan untuk berpindah, katakan, ke Bare Metal secara beramai-ramai dengan semua contoh anda? Adakah terdapat sebarang masalah? Atau adakah anda masih perlu menggunakan produk lain, contohnya, Ansible yang sama yang dinyatakan di sini?
Ansible adalah sedikit tentang sesuatu yang lain. Iaitu, Ansible sudah berjalan apabila contoh telah bermula. Dan Terraform berfungsi sebelum contoh bermula. Bertukar kepada Bare Metal tidak.
Bukan sekarang, tetapi perniagaan akan datang dan berkata: "Ayo."
Beralih ke awan lain - ya, tetapi terdapat ciri yang sedikit berbeza di sini. Anda perlu menulis kod Terraform sedemikian rupa sehingga anda boleh beralih ke awan lain dengan kurang pertumpahan darah.
Pada mulanya, tugasnya ialah keseluruhan infrastruktur kami adalah agnostik, iaitu mana-mana awan sepatutnya baik, tetapi pada satu ketika perniagaan itu menyerah dan berkata: βOK, dalam N tahun akan datang kami tidak akan pergi ke mana-mana, anda boleh menggunakan perkhidmatan daripada Amazon".
Terraform membolehkan anda membuat kerja Front-End, mengkonfigurasi PagerDuty, dokumen data, dll. Ia mempunyai banyak ekor. Dia boleh mengawal seluruh dunia.
Terima kasih atas laporan itu! Saya juga telah memutar Terraform selama 4 tahun sekarang. Pada peringkat peralihan yang lancar kepada Terraform, kepada infrastruktur, kepada penerangan perisytiharan, kami berhadapan dengan situasi di mana seseorang melakukan sesuatu dengan tangan, dan anda cuba membuat rancangan. Dan saya mendapat ralat di sana. Bagaimana anda menangani masalah sedemikian? Bagaimanakah anda mencari sumber yang hilang yang ditunjukkan?
Selalunya dengan tangan dan mata kita, jika kita melihat sesuatu yang pelik dalam laporan, maka kita menganalisis apa yang berlaku di sana, atau kita bunuh sahaja. Secara umum, permintaan tarik adalah perkara biasa.
Jika terdapat ralat, adakah anda melakukan rollback? Adakah anda cuba melakukan ini?
Tidak, ini adalah keputusan seseorang pada masa ini apabila dia melihat masalahnya.
Sumber: www.habr.com