Akeh wong sing ngerti lan nggunakake Terraform ing karya saben dinane, nanging praktik paling apik kanggo iku durung dibentuk. Saben tim kudu nggawe pendekatan lan metode dhewe.
Prasarana sampeyan meh mesthi diwiwiti kanthi gampang: sawetara sumber daya + sawetara pangembang. Sajrone wektu, tuwuh ing kabeh arah. Apa sampeyan nemokake cara kanggo nglumpukake sumber menyang modul Terraform, ngatur kode menyang folder, lan apa maneh sing bisa salah? (tembung pungkasan sing misuwur)
Wektu liwati lan sampeyan rumangsa infrastruktur sampeyan minangka pet anyar, nanging kenapa? Sampeyan kuwatir babagan owah-owahan sing ora bisa diterangake ing infrastruktur, sampeyan wedi ndemek infrastruktur lan kode - minangka asil, sampeyan nundha fungsi anyar utawa nyuda kualitas ...
Sawise telung taun ngatur koleksi modul komunitas Terraform kanggo AWS ing Github lan pangopènan jangka panjang Terraform ing produksi, Anton Babenko siap nuduhake pengalamane: carane nulis modul TF supaya ora lara ing mangsa ngarep.
Ing pungkasan pirembagan, peserta bakal luwih ngerti prinsip manajemen sumber daya ing Terraform, praktik paling apik sing ana gandhengane karo modul ing Terraform, lan sawetara prinsip integrasi terus-terusan sing ana gandhengane karo manajemen infrastruktur.
wewaler: Aku nyathet yen laporan iki tanggal November 2018-2 taun wis liwati. Versi Terraform 0.11 sing dibahas ing laporan kasebut ora didhukung maneh. Sajrone 2 taun kepungkur, 2 rilis anyar wis dirilis, sing ngemot akeh inovasi, perbaikan lan owah-owahan. Mangga digatekake lan priksa dokumentasi kasebut.
Cathetan:
- +
- - kode format otomatis lan dokumentasi
- - generator modul Terraform (WIP)
- - Generator kode Terraform saka diagram visual (WIP)
- www.terraform-best-practices.com
- (Kiriman anyar ana ing situs web pribadiku www.antonbabenko.com/)
- @antonbabenko - Twitter, lan akeh Slacks sing beda
Jenengku Anton Babenko. Sawetara sampeyan mbokmenawa nggunakake kode sing daktulis. Saiki aku bakal ngomong babagan iki kanthi luwih yakin tinimbang sadurunge, amarga aku duwe akses menyang statistik.
Aku kerja ing Terraform lan wis dadi peserta aktif lan kontributor kanggo akeh proyek open source sing ana hubungane karo Terraform lan Amazon wiwit 2015.
Wiwit iku aku wis nulis cukup kode kanggo sijine iku ing cara menarik. Lan aku bakal nyoba nyritakake babagan iki saiki.
Aku bakal pirembagan bab intricacies lan spesifik nggarap Terraform. Nanging iku dudu subyek HighLoad. Lan saiki sampeyan bakal ngerti sebabe.
Swara wektu, aku miwiti nulis modul Terraform. Pangguna nulis pitakonan, aku nulis maneh. Banjur aku nulis macem-macem keperluan kanggo format kode nggunakake pancing pra-komit, etc.
Ana akeh proyek menarik. Aku kaya generasi kode amarga aku seneng komputer kanggo nindakake liyane lan liyane karya kanggo kula lan programmer, aku saiki digunakake ing generator kode Terraform saka diagram visual. Mbok menawa sawetara saka sampeyan wis weruh. Iki kothak ayu karo panah. Lan aku apik yen sampeyan bisa ngeklik tombol "Ekspor" lan entuk kabeh minangka kode.
Aku saka Ukraina. Aku wis manggon ing Norwegia kanggo akèh taun.
Uga, informasi kanggo laporan iki diklumpukake saka wong sing ngerti jenengku lan nemokake aku ing jaringan sosial. Aku meh tansah duwe julukan padha.
Kaya sing dakkandhakake, aku minangka pangurus utama modul Terraform AWS, sing minangka salah sawijining repositori paling gedhe ing GitHub ing ngendi kita dadi tuan rumah modul kanggo tugas sing paling umum: VPC, Autoscaling, RDS.
Lan apa sing sampeyan krungu saiki sing paling dhasar. Yen sampeyan mangu-mangu ngerti apa Terraform, luwih becik nglampahi wektu ing papan liya. Bakal ana akeh istilah teknis ing kene. Lan aku ora ragu-ragu nyatakake tingkat laporan sing paling dhuwur. Iki tegese aku bisa ngomong nggunakake kabeh istilah sing bisa tanpa panjelasan akeh.
Terraform muncul ing 2014 minangka sarana sing ngidini sampeyan nulis, ngrancang lan ngatur infrastruktur minangka kode. Konsep utama ing kene yaiku "infrastruktur minangka kode."
Kabeh dokumentasi, kaya sing dakkandhakake, ditulis ing . Muga-muga akeh wong ngerti babagan situs iki lan wis maca dokumentasi kasebut. Yen mangkono, sampeyan ana ing panggonan sing bener.
Iki minangka file konfigurasi Terraform biasa, ing ngendi kita nemtokake sawetara variabel.
Ing kasus iki kita nemtokake "aws_region".
Banjur kita njlèntrèhaké apa sumber daya kita arep kanggo nggawe.
Kita mbukak sawetara prentah, utamane "terraform init" kanggo mbukak dependensi lan panyedhiya.
Lan kita mbukak printah "terraform apply" kanggo mriksa apa konfigurasi kasebut cocog karo sumber daya sing digawe. Amarga kita durung nggawe apa-apa sadurunge, Terraform njaluk kita nggawe sumber daya kasebut.
We konfirmasi iki. Mangkono kita nggawe ember sing disebut seasnail.
Ana uga sawetara utilitas sing padha. Akeh sing nggunakake Amazon ngerti AWS CloudFormation utawa Google Cloud Deployment Manager utawa Azure Resource Manager. Saben wong duwe implementasine dhewe kanggo ngatur sumber daya ing saben panyedhiya awan umum kasebut. Terraform utamane migunani amarga ngidini sampeyan ngatur luwih saka 100 panyedhiya. (Rincian liyane )
Tujuan sing wis ditindakake Terraform wiwit wiwitan:
- Terraform nyedhiyakake tampilan siji sumber daya.
- Ngidini sampeyan ndhukung kabeh platform modern.
- Lan Terraform dirancang wiwit wiwitan minangka sarana sing ngidini sampeyan ngganti infrastruktur kanthi aman lan bisa ditebak.
Ing 2014, tembung "diprediksi" muni banget ora biasa ing konteks iki.
Terraform minangka sarana universal. Yen sampeyan duwe API, sampeyan bisa ngontrol kabeh:
- Sampeyan bisa nggunakake luwih saka 120 panyedhiya kanggo ngatur kabeh sing dikarepake.
- Contone, sampeyan bisa nggunakake Terraform kanggo njlèntrèhaké akses menyang repositori GitHub.
- Sampeyan malah bisa nggawe lan nutup kewan omo ing Jira.
- Sampeyan bisa ngatur metrik New Relic.
- Sampeyan bisa malah nggawe file ing dropbox yen sampeyan pengin.
Iki kabeh digayuh nggunakake panyedhiya Terraform, sing duwe API mbukak sing bisa diterangake ing Go.
Ayo dadi ngomong kita miwiti nggunakake Terraform, maca sawetara dokumentasi ing situs, mirsani sawetara video, lan miwiti nulis main.tf, kaya aku nuduhake ing minger sadurungé.
Lan kabeh apik, sampeyan duwe file sing nggawe VPC.
Yen sampeyan pengin nggawe VPC, sampeyan nemtokake kira-kira 12 baris kasebut. Nerangake ing wilayah ngendi sampeyan pengin nggawe, cidr_block alamat IP sing arep digunakake. Mekaten.
Alami, proyek kasebut bakal tuwuh kanthi bertahap.
Lan sampeyan bakal nambah akeh barang anyar ing kana: sumber daya, sumber data, sampeyan bakal nggabungake karo panyedhiya anyar, dumadakan sampeyan pengin nggunakake Terraform kanggo ngatur pangguna ing akun GitHub, lsp. Sampeyan bisa uga pengin nggunakake panyedhiya DNS beda , nglintasi kabeh. Terraform ndadekake iki gampang.
Ayo deleng conto ing ngisor iki.
Sampeyan mboko sithik nambah internet_gateway amarga sampeyan pengin sumber daya saka VPC duwe akses internet. Iki minangka ide sing apik.
Asil iki main.tf:
Iki minangka bagéan ndhuwur main.tf.
Iki bagean ngisor main.tf.
Banjur sampeyan nambah subnet. Nalika sampeyan pengin nambah gateway NAT, rute, tabel rute lan akeh subnet liyane, sampeyan ora bakal duwe 38 garis, nanging kira-kira 200-300 garis.
Tegese, file main.tf sampeyan saya suwe saya mundhak. Lan asring wong sijine kabeh ing siji file. 10-20 Kb katon ing main.tf. Bayangna 10-20 Kb isi teks. Lan kabeh disambungake karo kabeh. Iki mboko sithik dadi angel digarap. 10-20 Kb minangka kasus pangguna sing apik, kadhangkala luwih akeh. Lan wong ora tansah mikir sing iki ala.
Kaya ing pemrograman biasa, dudu infrastruktur minangka kode, kita wis biasa nggunakake macem-macem kelas, paket, modul, klompok. Terraform ngidini sampeyan nindakake perkara sing padha.
- Kode kasebut tuwuh.
- Ketergantungan antarane sumber daya uga saya akeh.
Lan kita duwe kabutuhan gedhe lan gedhe. Kita ngerti manawa kita ora bisa urip kaya iki maneh. Kode kita dadi gedhe banget. 10-20 Kb, mesthi, ora jembar banget, nanging kita mung ngomong babagan tumpukan jaringan, yaiku sampeyan mung nambah sumber daya jaringan. Kita ora ngomong babagan Application Load Balancer, penyebaran ES cluster, Kubernetes, lan liya-liyane, ing ngendi 100 Kb bisa gampang dirajut. Yen sampeyan nulis kabeh iki, sampeyan bakal ngerti yen Terraform nyedhiyakake modul Terraform.
Modul Terraform minangka konfigurasi Terraform mandhiri sing dikelola minangka grup. Iku kabeh sampeyan kudu ngerti babagan modul Terraform. Dheweke ora pinter, ora ngidini sampeyan nggawe sambungan rumit gumantung saka apa wae. Iki kabeh ana ing pundhak para pangembang. Yaiku, iki mung sawetara jinis konfigurasi Terraform sing wis sampeyan tulis. Lan sampeyan mung bisa nelpon minangka grup.
Dadi, kita nyoba ngerti carane ngoptimalake kode 10-20-30 Kb. Kita mboko sithik nyadari yen kita kudu nggunakake sawetara modul.
Jinis modul pisanan sing sampeyan temoni yaiku modul sumber daya. Dheweke ora ngerti apa prasarana sampeyan, apa bisnis sampeyan, ing ngendi lan apa kahanane. Iki persis modul sing aku, bebarengan karo komunitas open source, ngatur, lan sing kita maju minangka blok bangunan wiwitan kanggo infrastruktur sampeyan.
Tuladha modul sumber daya.
Nalika kita nelpon modul sumber daya, kita nemtokake saka path kita kudu mbukak isi.
Kita nuduhake versi sing pengin didownload.
We pass Bunch saka bantahan ana. Mekaten. Mekaten ingkang kedah kita mangertosi nalika ngginakaken modul punika.
Akeh wong sing mikir yen nggunakake versi paling anyar, kabeh bakal stabil. Nanging ora. Infrastruktur kasebut kudu diversi; kita kudu mangsuli kanthi jelas versi apa iki utawa komponen kasebut dipasang.
Punika kode sing ana ing modul iki. Modul klompok keamanan. Ing kene gulung menyang baris 640th. Nggawe sumber keamanan-croup ing Amazon ing saben konfigurasi sing bisa ditindakake minangka tugas sing ora pati penting. Ora cukup mung nggawe grup keamanan lan ngandhani aturan apa sing kudu ditindakake. Iku bakal banget prasaja. Ana yuta watesan beda ing Amazon. Contone, yen sampeyan nggunakake Titik pungkasan VPC, dhaptar awalan, macem-macem API lan nyoba kanggo gabungke kabeh iki karo kabeh liyane, banjur Terraform ora ngidini sampeyan nindakake iki. Lan API Amazon uga ora ngidini iki. Mulane, kita kudu ndhelikake kabeh logika elek iki ing modul lan menehi kode pangguna sing katon kaya iki.
Pangguna ora perlu ngerti carane digawe ing njero.
Jinis modul kapindho, sing kalebu modul sumber daya, wis ngrampungake masalah sing luwih ditrapake kanggo bisnis sampeyan. Asring iki minangka papan sing minangka extension kanggo Terraform lan nyetel sawetara nilai kaku kanggo tag, kanggo standar perusahaan. Sampeyan uga bisa nambah fungsi ana sing Terraform saiki ora ngidini sampeyan nggunakake. Iki saiki. Saiki versi 0.11, sing bakal dadi barang sing kepungkur. Nanging isih, preprocessors, jsonnet, cookiecutter lan akeh liyane minangka mekanisme tambahan sing kudu digunakake kanggo karya lengkap.
Sabanjure aku bakal nuduhake sawetara conto iki.
Modul infrastruktur diarani kanthi cara sing padha.
Sumber saka ngendi kanggo ngundhuh isi dituduhake.
Akeh nilai sing diterusake lan diterusake menyang modul iki.
Sabanjure, ing modul iki, akeh modul sumber daya diarani nggawe VPC utawa Application Load Balancer, utawa nggawe grup keamanan utawa kanggo kluster Layanan Kontainer Elastis.
Ana rong jinis modul. Iki penting dimangerteni amarga umume informasi sing aku kumpulake ing laporan iki ora ditulis ing dokumentasi.
Lan dokumentasi ing Terraform saiki cukup masalah amarga mung ngandika ana fitur iki, sampeyan bisa nggunakake. Nanging dheweke ora ngomong carane nggunakake fitur iki, kok iku luwih apik kanggo nggunakake. Mulane, akeh banget wong nulis soko sing ora bisa manggon karo.
Ayo dipikirake carane nulis modul kasebut sabanjure. Banjur kita bakal weruh carane nelpon lan cara nggarap kode kasebut.
Registry Terraform -
Tip #0 yaiku ora nulis modul sumber daya. Umume modul iki wis ditulis kanggo sampeyan. Kaya sing dakkandhakake, dheweke mbukak sumber, ora ngemot logika bisnis sampeyan, ora duwe nilai hardcode kanggo alamat IP, sandhi, lsp. Modul kasebut fleksibel banget. Lan wis paling kamungkinan wis ditulis. Ana akeh modul kanggo sumber daya saka Amazon. Udakara 650. Lan akeh-akehe kualitase apik.
Ing conto iki, ana wong sing marani sampeyan lan ujar, "Aku pengin bisa ngatur database. Nggawe modul supaya aku bisa nggawe database." Wong kasebut ora ngerti rincian implementasine saka Amazon utawa Terraform. Dheweke mung ujar: "Aku pengin ngatur MSSQL." Yaiku, tegese bakal nelpon modul kita, ngliwati jinis mesin ana, lan nuduhake zona wektu.
Lan wong ora kudu ngerti manawa kita bakal nggawe rong sumber daya ing modul iki: siji kanggo MSSQL, sing liya kanggo kabeh liyane, mung amarga ing Terraform 0.11 sampeyan ora bisa nemtokake nilai zona wektu minangka opsional.
Lan ing metu saka modul iki, wong bakal mung bisa nampa alamat. Dheweke ora bakal ngerti saka database endi, saka sumber apa kita nggawe kabeh iki sacara internal. Iki minangka unsur sing penting banget kanggo ndhelikake. Lan iki ditrapake ora mung kanggo modul sing umum ing open source, nanging uga kanggo modul sing bakal sampeyan tulis ing proyek lan tim sampeyan.
Iki minangka argumen kapindho, sing penting banget yen sampeyan wis nggunakake Terraform kanggo sawetara wektu. Sampeyan duwe gudang ing ngendi sampeyan sijine kabeh modul Terraform kanggo perusahaan sampeyan. Lan cukup normal yen suwene proyek iki bakal tuwuh nganti ukuran siji utawa rong megabyte. Iki apik.
Nanging masalahe yaiku carane Terraform nelpon modul kasebut. Contone, yen sampeyan nelpon modul kanggo nggawe saben pangguna individu, Terraform bakal mbukak kabeh repositori dhisik banjur navigasi menyang folder ing ngendi modul kasebut dumunung. Kanthi cara iki sampeyan bakal ngundhuh siji megabyte saben wektu. Yen sampeyan ngatur 100 utawa 200 pangguna, sampeyan bakal ngundhuh 100 utawa 200 megabyte, banjur pindhah menyang folder kasebut. Dadi, sampeyan ora pengin ndownload akeh barang saben sampeyan mencet "Terraform init".
Ana rong solusi kanggo masalah iki. Kaping pisanan yaiku nggunakake jalur relatif. Kanthi cara iki sampeyan nuduhake ing kode sing folder lokal (./). Lan sadurunge sampeyan miwiti apa wae, sampeyan nggawe klon Git saka repositori iki sacara lokal. Kanthi cara iki sampeyan nindakake sapisan.
Ana, mesthi, akeh kekurangane. Contone, sampeyan ora bisa nggunakake versi. Lan iki kadhangkala angel kanggo urip.
Solusi kapindho. Yen sampeyan duwe akeh submodul lan sampeyan wis duwe sawetara jinis pipa sing diadegake, mula ana proyek MBT, sing ngidini sampeyan ngumpulake macem-macem paket saka monorepository lan diunggah menyang S3. Iki cara sing apik banget. Mangkono, file iam-user-1.0.0.zip mung bakal bobote 1 Kb, amarga kode kanggo nggawe sumber daya iki cilik banget. Lan bakal bisa luwih cepet.
Ayo dadi pirembagan bab apa ora bisa digunakake ing modul.
Kenapa iki ala ing modul? Sing paling awon yaiku nganggep pangguna. Anggap pangguna minangka pilihan otentikasi panyedhiya sing bisa digunakake dening wong liya. Contone, kita kabeh bakal assimilate peran. Iki tegese Terraform bakal njupuk peran iki. Banjur kanthi peran iki bakal nindakake tumindak liyane.
Lan ala yen Vasya seneng nyambung menyang Amazon kanthi cara siji, umpamane, nggunakake variabel lingkungan standar, lan Petya seneng nggunakake kunci sing dienggo bareng, sing ana ing papan rahasia, mula sampeyan ora bisa nemtokake loro-lorone. Terraform. Lan supaya ora ngalami kasangsaran, ora perlu kanggo nunjukake blok kasebut ing modul kasebut. Iki kudu dituduhake ing tingkat sing luwih dhuwur. Yaiku, kita duwe modul sumber daya, modul infrastruktur lan komposisi ing ndhuwur. Lan iki kudu dituduhake ing papan sing luwih dhuwur.
Kadurjanan ingkang kaping kalih inggih punika panyedhiya. Ing kene, ala ora pati penting, amarga yen sampeyan nulis kode lan bisa digunakake kanggo sampeyan, sampeyan bisa uga mikir yen bisa, mula kenapa ngganti.
Sing ala yaiku sampeyan ora tansah ngontrol kapan provisioner iki bakal diluncurake, pisanan. Lan kaping pindho, sampeyan ora ngontrol apa tegese aws ec2, yaiku saiki kita ngomong babagan Linux utawa Windows. Dadi sampeyan ora bisa nulis soko sing bakal bisa digunakake ing sistem operasi beda utawa kanggo kasus pangguna beda.
Conto sing paling umum, sing uga dituduhake ing dokumentasi resmi, yaiku yen sampeyan nulis aws_instance lan nemtokake akeh argumen, mula ora ana sing salah yen sampeyan nemtokake provisioner "local-exec" ing kana lan mbukak ansible- buku dolanan.
Nyatane, ya ora ana sing salah. Nanging secara harfiah, sampeyan bakal ngerti manawa iki lokal-eksekusi ora ana, contone, ing launch_configuration.
Lan nalika sampeyan nggunakake launch_configuration, lan sampeyan pengin nggawe grup autoscaling saka siji conto, banjur ing launch_configuration ora ana konsep "provisioner". Ana konsep "data pangguna".
Mulane, solusi sing luwih universal yaiku nggunakake data pangguna. Lan bakal diluncurake ing conto dhewe, nalika instance diuripake, utawa ing data pangguna sing padha, nalika grup autoscaling nggunakake launch_configuration iki.
Yen sampeyan isih pengin mbukak provisioner, amarga iku komponen gluing, nalika siji sumber digawe, ing wayahe sampeyan kudu mbukak provisioner, printah Panjenengan. Ana akeh kahanan kaya ngono.
Lan sumber daya sing paling bener kanggo iki diarani null_resource. Null_resource minangka sumber palsu sing ora tau digawe. Ora ndemek apa-apa, ora API, ora ana autoscaling. Nanging ngidini sampeyan kanggo ngontrol nalika kanggo mbukak printah. Ing kasus iki, printah kasebut ditindakake nalika nggawe.
link
Ana sawetara pratandha. Aku ora bakal njlentrehake kabeh pratandha kanthi rinci. Ana artikel babagan iki. Nanging yen sampeyan wis kerjo karo Terraform utawa nggunakake modul wong liya, sampeyan wis kerep weruh sing akeh modul, kaya paling kode ing open source, ditulis dening wong kanggo kabutuhan dhewe. Ana wong nulis lan ngrampungake masalahe. Aku macet ing GitHub, supaya urip. Bakal urip, nanging yen ora ana dokumentasi lan conto, mula ora ana sing bakal nggunakake. Lan yen ora ana fungsi sing ngidini sampeyan ngatasi tugas tartamtu, mula ora ana sing bakal nggunakake. Ana akeh cara kanggo ilang pangguna.
Yen sampeyan pengin nulis soko supaya wong bakal nggunakake, banjur aku nyaranake tindakake pratandha iki.
Iki minangka:
- Dokumentasi lan conto.
- Fungsi lengkap.
- Default sing cukup.
- Kode resik.
- Tes.
Tes minangka kahanan sing beda amarga cukup angel kanggo nulis. Aku luwih percaya karo dokumentasi lan conto.
Dadi, kita ndeleng carane nulis modul. Ana rong argumen. Pisanan, sing paling penting, ora nulis yen sampeyan bisa, amarga akeh wong sing wis nindakake tugas kasebut sadurunge sampeyan. Lan kapindho, yen sampeyan isih mutusake, coba aja nggunakake panyedhiya ing modul lan provisioner.
Iki minangka bagean abu-abu saka dokumentasi. Saiki sampeyan bisa uga mikir: "Ana sing ora jelas. Ora percoyo." Nanging kita bakal weruh ing nem sasi.
Saiki ayo ngomong babagan carane nelpon modul kasebut.
Kita mangertos bilih kode kita mundhak saka wektu. Kita ora duwe siji file maneh, kita wis duwe 20 file. Kabeh mau ana ing siji folder. Utawa mungkin limang folder. Mungkin kita wiwiti ngrusak miturut wilayah, kanthi sawetara komponen. Banjur kita ngerti yen saiki kita duwe sawetara dhasar sinkronisasi lan orkestrasi. Tegese, kita kudu ngerti apa sing kudu ditindakake yen kita ngganti sumber daya jaringan, apa sing kudu kita lakoni karo sumber daya liyane, kepiye nyebabake dependensi kasebut, lsp.
Ana rong ekstrem. Ekstrem pisanan kabeh dadi siji. Kita duwe file master siji. Saiki, iki minangka praktik paling apik ing situs web Terraform.
Nanging saiki wis ditulis minangka ora digunakake lan dibusak. Sajrone wektu, komunitas Terraform nyadari yen iki adoh saka praktik paling apik, amarga wong wiwit nggunakake proyek kasebut kanthi cara sing beda-beda. Lan ana masalah. Contone, nalika kita dhaptar kabeh dependensi ing sak panggonan. Ana kahanan nalika kita klik "rencana Terraform" lan nganti Terraform nganyari negara kabeh sumber daya, akeh wektu bisa liwat.
Akeh wektu, contone, 5 menit. Kanggo sawetara iki wektu akeh. Aku wis ndeleng kasus sing butuh 15 menit. API AWS ngginakaken 15 menit nyoba kanggo mangerteni apa kedados karo negara saben sumber. Iki wilayah sing amba banget.
Lan, mesthi, masalah sing gegandhengan bakal katon nalika sampeyan pengin ngganti soko ing sak panggonan, banjur ngenteni 15 menit, lan menehi kanvas sawetara owah-owahan. Sampeyan ngidoni, nulis "Ya", lan ana sing salah. Iki minangka conto sing nyata banget. Terraform ora nyoba nglindhungi sampeyan saka masalah. Yaiku, nulis apa sing dikarepake. Bakal ana masalah - masalah sampeyan. Nalika Terraform 0.11 ora nyoba mbantu sampeyan kanthi cara apa wae. Ana sawetara papan sing menarik ing 0.12 sing ngidini sampeyan ujar: "Vasya, sampeyan pengin iki, apa sampeyan bisa ngerti?"
Cara kapindho yaiku nyuda wilayah iki, yaiku, telpon saka siji panggonan bisa kurang nyambung saka panggonan liya.
Masalah mung sampeyan kudu nulis kode liyane, yaiku sampeyan kudu njlèntrèhaké variabel ing jumlah file sing akeh lan nganyari iki. Sawetara wong ora seneng. Iki normal kanggo kula. Lan sawetara wong mikir: "Napa nulis iki ing macem-macem papan, aku bakal nyelehake kabeh ing sak panggonan." Iki bisa, nanging iki ekstrem kapindho.
Sapa sing duwe kabeh iki manggon ing sak panggonan? Siji, loro, telu, yaiku, ana sing nggunakake.
Lan sing nelpon siji komponen tartamtu, siji blok utawa siji modul infrastruktur? Lima nganti pitung wong. Iki keren.
Jawaban sing paling umum ana ing tengah. Yen proyek gedhe, sampeyan bakal kerep duwe kahanan sing ora ana solusi sing cocog lan ora kabeh bisa ditindakake, mula sampeyan bakal dadi campuran. Ora ana sing salah karo iki, anggere sampeyan ngerti yen loro-lorone duwe kaluwihan.
Yen ana sing diganti ing tumpukan VPC lan sampeyan pengin ngetrapake owah-owahan kasebut ing EC2, yaiku sampeyan pengin nganyari grup autoscaling amarga sampeyan duwe subnet anyar, mula aku nelpon orkestrasi dependensi iki. Ana sawetara solusi: sing nggunakake apa?
Aku bisa menehi saran apa solusi sing ana. Sampeyan bisa nggunakake Terraform kanggo nindakake sihir, utawa sampeyan bisa nggunakake makefiles kanggo nggunakake Terraform. Lan weruh yen ana sing wis diganti, sampeyan bisa miwiti ing kene.
Kepiye sampeyan seneng karo keputusan iki? Apa ana sing percaya yen iki minangka solusi sing apik? Aku weruh eseman, ketoke mangu-mangu wis nyusup.
Mesthi, aja nyoba iki ing omah. Terraform ora tau dirancang kanggo mbukak saka Terraform.
Ing sawijining laporan, dheweke kandha marang aku: "Ora, iki ora bakal bisa." Intine iku kudune ora bisa. Sanajan katon apik banget nalika sampeyan bisa miwiti Terraform saka Terraform, banjur Terraform, sampeyan ora kudu nglakoni. Terraform kudu diwiwiti kanthi gampang.
Yen sampeyan butuh orkestrasi telpon nalika ana owah-owahan ing sak panggonan, banjur ana Terragrunt.
Terragrunt minangka sarana, tambahan kanggo Terraform, sing ngidini sampeyan koordinasi lan ngatur telpon menyang modul infrastruktur.
File konfigurasi Terraform khas katon kaya iki.
Sampeyan nemtokake modul tartamtu sing pengin ditelpon.
Apa dependensi modul duwe?
Lan apa bantahan modul iki nampa. Iku kabeh sing kudu dingerteni babagan Terragrunt.
Dokumentasi kasebut ana, lan ana 1 bintang ing GitHub. Nanging ing umume kasus iki sampeyan kudu ngerti. Lan iki gampang banget kanggo dileksanakake ing perusahaan sing lagi miwiti nggarap Terraform.
Dadi orkestrasi yaiku Terragrunt. Ana pilihan liyane.
Saiki ayo ngomong babagan cara nggarap kode kasebut.
Yen sampeyan kudu nambahake fitur-fitur anyar menyang kode, umume iki gampang. Sampeyan nulis sumber anyar, kabeh iku prasaja.
Yen sampeyan duwe sawetara sumber daya sing digawe sadurunge, contone, sampeyan sinau babagan Terraform sawise sampeyan mbukak akun AWS lan pengin nggunakake sumber daya sing wis sampeyan duwe, banjur bakal cocog kanggo ngluwihi modul sampeyan kanthi cara iki, supaya iku ndhukung nggunakake sumber daya ana.
Lan ndhukung nggawe sumber daya anyar nggunakake sumber pamblokiran.
Ing output kita tansah ngasilake id output gumantung saka apa sing digunakake.
Masalah nomer loro sing penting banget ing Terraform 0.11 nggarap dhaptar.
Kangelan iku yen kita duwe dhaftar kuwi kedhaftar.
Lan nalika kita nggawe pangguna iki nggunakake sumber pamblokiran, banjur kabeh dadi apik. Kita mbukak kabeh dhaptar, nggawe file kanggo saben. Kabeh apik. Banjur, contone, user3, sing ana ing tengah, kudu dibusak saka kene, banjur kabeh sumber daya sing digawe sawise dheweke bakal digawe maneh amarga indeks bakal diganti.
Nggarap dhaptar ing lingkungan stateful. Apa lingkungan stateful? Iki minangka kahanan ing ngendi nilai anyar digawe nalika sumber daya iki digawe. Contone, AWS Access Key utawa AWS Secret Key, yaiku nalika nggawe pangguna, kita nampa Akses utawa Kunci Rahasia anyar. Lan saben-saben kita mbusak pangguna, pangguna iki bakal duwe kunci anyar. Nanging iki dudu feng shui, amarga pangguna ora pengin kekancan karo kita yen nggawe pangguna anyar kanggo dheweke saben wong ninggalake tim kasebut.
Iki solusine. Iki kode sing ditulis ing Jsonnet. Jsonnet minangka basa template saka Google.
Printah iki ngidini sampeyan nampa cithakan iki lan minangka output ngasilake file json sing digawe miturut cithakan sampeyan.
Cithakan katon kaya iki.
Terraform ngidini sampeyan nggarap HCL lan Json kanthi cara sing padha, dadi yen sampeyan duwe kemampuan kanggo ngasilake Json, sampeyan bisa mlebu menyang Terraform. Berkas mawa ekstensi .tf.json bakal kasil diundhuh.
Banjur kita nggarap kaya biasane: terraform init, terramorm ditrapake. Lan kita nggawe rong pangguna.
Saiki kita ora wedi yen ana sing ninggalake tim. Kita mung bakal ngowahi file json. Vasya Pupkin kiwa, Petya Pyatochkin tetep. Petya Pyatochkin ora bakal nampa kunci anyar.
Nggabungake Terraform karo alat liyane dudu tugas Terraform. Terraform digawe minangka platform kanggo nggawe sumber daya lan kabeh iku. Lan kabeh sing kedadeyan mengko ora dadi perhatian Terraform. Lan ora perlu kanggo nenun ing kono. Ana Ansible, sing nindakake kabeh sing dibutuhake.
Nanging ana kahanan nalika kita pengin ngluwihi Terraform lan nelpon sawetara printah sawise soko wis rampung.
Cara pisanan. Kita nggawe output ing ngendi kita nulis printah iki.
Banjur kita nelpon printah iki saka output shell terraform lan nemtokake nilai sing dikarepake. Mangkono, printah kasebut dieksekusi karo kabeh nilai sing diganti. Iku banget nyaman.
Cara kapindho. Iki nggunakake null_resource gumantung saka owah-owahan ing infrastruktur kita. Kita bisa nelpon padha lokal-exe sanalika ID sawetara owah-owahan sumber.
Alami, iki kabeh lancar ing kertas, amarga Amazon, kaya kabeh panyedhiya umum liyane, duwe akeh kasus pinggiran dhewe.
Kasus pinggiran sing paling umum yaiku nalika sampeyan mbukak akun AWS, penting wilayah sing sampeyan gunakake; apa fitur iki aktif ing kono; Mungkin sampeyan mbukak sawise Desember 2013; Mungkin sampeyan nggunakake standar ing VPC etc. Ana akeh Watesan. Lan Amazon kasebar ing saindhenging dokumentasi.
Ana sawetara bab sing aku nyaranake nyingkiri.
Kanggo miwiti, supaya kabeh bantahan non-rahasia ing rencana Terraform utawa Terraform CLI. Kabeh iki bisa dilebokake menyang file tfvars utawa menyang variabel lingkungan.
Nanging sampeyan ora perlu ngeling-eling kabeh perintah sihir iki. rencana Terraform - var lan mati kita pindhah. Variabel pisanan var, variabel kapindho var, katelu, papat. Prinsip infrastruktur sing paling penting minangka kode sing paling kerep digunakake yaiku mung kanthi ndeleng kode kasebut, aku kudu duwe pangerten sing jelas babagan apa sing disebar ing kono, ing negara apa lan apa nilai. Dadi aku ora kudu maca dokumentasi utawa takon marang Vasya apa paramèter sing digunakake kanggo nggawe kluster kita. Aku mung kudu mbukak file karo extension tfvars, kang asring cocog lingkungan, lan katon ing kabeh ana.
Uga, aja nggunakake argumen target kanggo nyuda ruang lingkup. Kanggo iki luwih gampang nggunakake modul infrastruktur cilik.
Uga, ora perlu mbatesi lan nambah paralelisme. Yen aku duwe 150 sumber daya lan aku pengin nambah paralelisme Amazon saka standar 10 nganti 100, mesthine ana sing salah. Utawa bisa uga saiki, nanging nalika Amazon ujar manawa sampeyan nelpon akeh banget, sampeyan bakal nemoni masalah.
Terraform bakal nyoba miwiti maneh akeh masalah kasebut, nanging meh ora entuk apa-apa. Paralelisme = 1 iku penting kanggo nggunakake yen sampeyan kesandhung ing sawetara bug ing API AWS utawa ing panyedhiya Terraform. Banjur sampeyan kudu nemtokake: paralelisme = 1 lan ngenteni nganti Terraform rampung siji telpon, banjur kaloro, banjur katelu. Dheweke bakal mbukak siji-siji.
Wong-wong kerep takon, "Apa aku mikir yen ruang kerja Terraform ala?" Aku pracaya prinsip infrastruktur minangka kode kanggo ndeleng apa infrastruktur wis digawe lan karo apa nilai.
Ruang kerja ora digawe dening pangguna. Iki ora ateges pangguna nulis ing masalah GitHub sing ora bisa urip tanpa ruang kerja Terraform. Ora kaya iki. Terraform Enterprise minangka solusi komersial. Terraform saka HashiCorp mutusake yen kita butuh ruang kerja, mula diajukake. Aku luwih gampang kanggo nyelehake ing folder kapisah. Banjur bakal ana file sing luwih cilik, nanging bakal luwih jelas.
Kepiye cara nggarap kode? Nyatane, nggarap dhaptar mung rasa nyeri. Lan njupuk Terraform luwih gampang. Iki dudu perkara sing bakal nindakake kabeh sing apik kanggo sampeyan. Ora perlu nyurung kabeh sing ditulis ing dokumentasi ana.
Topik laporan kasebut ditulis "kanggo masa depan." Aku bakal ngomong babagan iki kanthi ringkes. Kanggo mangsa ngarep, iki tegese 0.12 bakal dirilis rauh.
0.12 minangka ton barang anyar. Yen sampeyan teka saka program biasa, sampeyan bakal kantun kabeh jinis pamblokiran dinamis, puteran, operasi comparison bener lan kondisional, ngendi sisih kiwa lan tengen ora diwilang bebarengan, nanging gumantung ing kahanan. Sampeyan kantun banget, supaya 0.12 bakal ngrampungake kanggo sampeyan.
Nanging! Yen sampeyan nulis kurang lan luwih gampang, nggunakake modul siap-siap lan solusi pihak katelu, sampeyan ora kudu ngenteni lan ngarep-arep yen 0.12 bakal teka lan ndandani kabeh kanggo sampeyan.
Matur nuwun kanggo laporan! Sampeyan ngomong babagan infrastruktur minangka kode lan secara harfiah ujar siji tembung babagan tes. Apa tes dibutuhake ing modul? Tanggung jawabe sapa iki? Apa aku kudu nulis dhewe utawa tanggung jawab modul kasebut?
Ing taun sabanjuré bakal kapenuhan laporan sing wis mutusaké kanggo nyoba kabeh. Apa sing kudu dites minangka pitakonan paling gedhe. Ana akeh dependensi, akeh watesan saka panyedhiya sing beda. Nalika sampeyan lan aku ngomong lan sampeyan kandha: "Aku butuh tes," banjur aku takon: "Apa sing bakal sampeyan tes?" Sampeyan ujar manawa sampeyan bakal nyoba ing wilayah sampeyan. Banjur aku ujar manawa iki ora bisa digunakake ing wilayahku. Tegese, kita ora bakal bisa setuju babagan iki. Ora kanggo sebutno ana akeh masalah teknis. Tegese, carane nulis tes kasebut supaya cukup.
Aku aktif nliti topik iki, yaiku carane nggawe tes kanthi otomatis adhedhasar infrastruktur sing sampeyan tulis. Yaiku, yen sampeyan nulis kode iki, mula aku kudu mbukak, adhedhasar iki aku bisa nggawe tes.
iku salah siji saka perpustakaan paling kerep kasebut sing ngijini sampeyan kanggo nulis tes integrasi kanggo Terraform. Iki minangka salah sawijining sarana. Aku luwih seneng jinis DSL, contone, rspec.
Anton, matur nuwun kanggo laporan! Jenengku Valery. Ayo kula takon pitakonan filosofis sethitik. Ana, kondisional, provisioning, ana penyebaran. Penyediaan nggawe infrastrukturku, ing penyebaran kita ngisi karo sing migunani, contone, server, aplikasi, lan liya-liyane. ngidini sampeyan nginstal nginx, Postgres. Nanging ing wektu sing padha, Ansible katon ngidini nyedhiyakake, contone, sumber daya Amazon utawa Google. Nanging Terraform uga ngidini sampeyan masang sawetara piranti lunak nggunakake modul kasebut. Saka sudut pandang sampeyan, ana sawetara wates sing ana ing antarane Terraform lan Ansible, ing ngendi lan apa sing luwih apik digunakake? Utawa, umpamane, apa sampeyan mikir yen Ansible wis dadi sampah, sampeyan kudu nyoba nggunakake Terraform kanggo kabeh?
Pitakonan sing apik, Valery. Aku percaya yen Terraform ora owah saka tujuane wiwit taun 2014. Iki digawe kanggo infrastruktur lan mati kanggo infrastruktur. Kita isih duwe lan bakal mbutuhake manajemen konfigurasi Ansible. Tantangan yaiku ana data pangguna ing launch_configuration. Lan ana sampeyan narik Ansible, etc. Iki minangka prabédan standar sing paling aku seneng.
Yen kita ngomong babagan infrastruktur sing apik, mula ana utilitas kaya Packer sing ngumpulake gambar iki. Banjur Terraform nggunakake sumber data kanggo nemokake gambar iki lan nganyari launch_configuration. Tegese, kanthi cara iki saluran pipa yaiku kita narik Tracker, banjur narik Terraform. Lan yen mbangun ana, banjur owah-owahan anyar dumadi.
Hello! Matur nuwun kanggo laporan! Jenengku Misha, perusahaan RBS. Sampeyan bisa nelpon Ansible liwat provisioner nalika nggawe sumber daya. Ansible uga nduweni topik sing diarani inventaris dinamis. Lan pisanan sampeyan bisa nelpon Terraform, banjur nelpon Ansible, sing bakal njupuk sumber daya saka negara lan nglakokake. Apa sing luwih apik?
Wong nggunakake loro karo sukses witjaksono. Iku misale jek kula sing inventaris dinamis ing Ansible iku trep, yen kita ora ngomong bab autoscaling grup. Amarga ing grup autoscaling kita wis duwe toolkit dhewe, sing diarani launch_configuration. Ing launch_configuration, kita ngrekam kabeh sing kudu diluncurake nalika nggawe sumber daya anyar. Mulane, karo Amazon, nggunakake inventaris dinamis lan maca file Terraform ts, ing mratelakake panemume, overkill. Lan yen sampeyan nggunakake alat liyane sing ora ana konsep "grup autoscaling", umpamane, sampeyan nggunakake DigitalOcean utawa sawetara panyedhiya liyane sing ora ana grup autoscaling, banjur ana sampeyan kudu narik API kanthi manual, golek alamat IP, nggawe file inventaris dinamis, lan Ansible bakal ngumbara liwat. Yaiku, kanggo Amazon ana launch_configuration, lan kanggo kabeh liyane ana persediaan dinamis.
Source: www.habr.com