Ramai orang tahu dan menggunakan Terraform dalam kerja harian mereka, tetapi amalan terbaik untuknya masih belum terbentuk. Setiap pasukan perlu mencipta pendekatan dan kaedah tersendiri.
Infrastruktur anda hampir pasti bermula dengan mudah: beberapa sumber + beberapa pembangun. Dari masa ke masa, ia tumbuh dalam pelbagai arah. Adakah anda mencari cara untuk mengumpulkan sumber ke dalam modul Terraform, menyusun kod ke dalam folder, dan apa lagi yang mungkin salah? (kata-kata terakhir yang terkenal)
Masa berlalu dan anda merasakan infrastruktur anda adalah haiwan peliharaan baharu anda, tetapi mengapa? Anda bimbang tentang perubahan yang tidak dapat dijelaskan dalam infrastruktur, anda takut untuk menyentuh infrastruktur dan kod - akibatnya, anda menangguhkan fungsi baharu atau mengurangkan kualiti...
Selepas tiga tahun menguruskan koleksi modul komuniti Terraform untuk AWS pada Github dan penyelenggaraan jangka panjang Terraform dalam pengeluaran, Anton Babenko bersedia untuk berkongsi pengalamannya: cara menulis modul TF supaya ia tidak menyakitkan pada masa hadapan.
Menjelang akhir ceramah, peserta akan lebih biasa dengan prinsip pengurusan sumber dalam Terraform, amalan terbaik yang dikaitkan dengan modul dalam Terraform dan beberapa prinsip penyepaduan berterusan yang dikaitkan dengan pengurusan infrastruktur.
Penafian: Saya ambil perhatian bahawa laporan ini bertarikh November 2018β2 tahun telah pun berlalu. Versi Terraform 0.11 yang dibincangkan dalam laporan tidak lagi disokong. Sepanjang 2 tahun yang lalu, 2 keluaran baharu telah dikeluarkan, yang mengandungi banyak inovasi, penambahbaikan dan perubahan. Sila beri perhatian kepada perkara ini dan semak dokumentasi.
Rujukan:
- +
- β kod pemformatan automatik dan dokumentasi
- β penjana modul Terraform (WIP)
- β Penjana kod terraform daripada gambar rajah visual (WIP)
- www.terraform-best-practices.com
- (Siaran baharu ada di laman web peribadi saya www.antonbabenko.com/)
- @antonbabenko - Twitter, dan sekumpulan Slacks yang berbeza
Nama saya Anton Babenko. Sesetengah daripada anda mungkin menggunakan kod yang saya tulis. Saya kini akan bercakap tentang perkara ini dengan lebih yakin berbanding sebelum ini, kerana saya mempunyai akses kepada statistik.
Saya bekerja di Terraform dan telah menjadi peserta aktif dan penyumbang kepada sejumlah besar projek sumber terbuka yang berkaitan dengan Terraform dan Amazon sejak 2015.
Sejak itu saya telah menulis kod yang cukup untuk meletakkannya dalam cara yang menarik. Dan saya akan cuba memberitahu anda tentang perkara ini sekarang.
Saya akan bercakap tentang selok-belok dan spesifik bekerja dengan Terraform. Tetapi itu sebenarnya bukan subjek HighLoad. Dan sekarang anda akan faham mengapa.
Lama kelamaan, saya mula menulis modul Terraform. Pengguna menulis soalan, saya menulis semula. Kemudian saya menulis pelbagai utiliti untuk memformat kod menggunakan cangkuk pra-komit, dsb.
Terdapat banyak projek yang menarik. Saya suka penjanaan kod kerana saya suka komputer melakukan lebih banyak kerja untuk saya dan pengaturcara, jadi saya sedang mengusahakan penjana kod Terraform daripada gambar rajah visual. Mungkin sebahagian daripada anda pernah melihatnya. Ini adalah kotak yang cantik dengan anak panah. Dan saya fikir ia bagus jika anda boleh mengklik butang "Eksport" dan mendapatkan semuanya sebagai kod.
Saya dari Ukraine. Saya telah tinggal di Norway selama bertahun-tahun.
Juga, maklumat untuk laporan ini dikumpulkan daripada orang yang mengetahui nama saya dan mencari saya di rangkaian sosial. Saya hampir selalu mempunyai nama panggilan yang sama.
Seperti yang saya nyatakan, saya adalah penyelenggara utama modul Terraform AWS, yang merupakan salah satu repositori terbesar di GitHub di mana kami mengehoskan modul untuk tugas yang paling biasa: VPC, Autoscaling, RDS.
Dan apa yang anda dengar sekarang adalah yang paling asas. Jika anda meragui bahawa anda memahami apa itu Terraform, maka lebih baik anda luangkan masa anda di tempat lain. Akan ada banyak istilah teknikal di sini. Dan saya tidak teragak-agak untuk mengisytiharkan tahap laporan itu adalah yang tertinggi. Ini bermakna saya boleh bercakap menggunakan semua istilah yang mungkin tanpa banyak penjelasan.
Terraform muncul pada tahun 2014 sebagai utiliti yang membolehkan anda menulis, merancang dan mengurus infrastruktur sebagai kod. Konsep utama di sini ialah "infrastruktur sebagai kod."
Semua dokumentasi, seperti yang saya katakan, ditulis dalam . Saya harap kebanyakan orang tahu tentang laman web ini dan telah membaca dokumentasi. Jika ya, maka anda berada di tempat yang betul.
Beginilah rupa fail konfigurasi Terraform biasa, di mana kita mula-mula menentukan beberapa pembolehubah.
Dalam kes ini kami mentakrifkan "aws_region".
Kemudian kami menerangkan sumber yang ingin kami cipta.
Kami menjalankan beberapa arahan, khususnya "terraform init" untuk memuatkan kebergantungan dan pembekal.
Dan kami menjalankan perintah "terraform apply" untuk menyemak sama ada konfigurasi yang ditentukan sepadan dengan sumber yang kami buat. Memandangkan kami belum mencipta apa-apa sebelum ini, Terraform menggesa kami untuk mencipta sumber ini.
Kami mengesahkan ini. Oleh itu, kami mencipta baldi yang dipanggil seasnail.
Terdapat juga beberapa utiliti yang serupa. Ramai daripada anda yang menggunakan Amazon mengetahui AWS CloudFormation atau Pengurus Penerapan Awan Google atau Pengurus Sumber Azure. Setiap daripada mereka mempunyai beberapa jenis pelaksanaan sendiri untuk mengurus sumber dalam setiap penyedia awan awam ini. Terraform amat berguna kerana ia membolehkan anda mengurus lebih 100 pembekal. (Maklumat lanjut )
Matlamat yang telah diusahakan oleh Terraform dari awal lagi:
- Terraform menyediakan satu pandangan sumber.
- Membolehkan anda menyokong semua platform moden.
- Dan Terraform telah direka sejak awal sebagai utiliti yang membolehkan anda menukar infrastruktur dengan selamat dan boleh diramalkan.
Pada tahun 2014, perkataan "boleh diramal" terdengar sangat luar biasa dalam konteks ini.
Terraform ialah utiliti sejagat. Jika anda mempunyai API, maka anda boleh mengawal segala-galanya:
- Anda boleh menggunakan lebih daripada 120 pembekal untuk mengurus semua yang anda mahukan.
- Sebagai contoh, anda boleh menggunakan Terraform untuk menerangkan akses kepada repositori GitHub.
- Anda juga boleh membuat dan menutup pepijat dalam Jira.
- Anda boleh mengurus metrik New Relic.
- Anda juga boleh membuat fail dalam dropbox jika anda benar-benar mahu.
Ini semua dicapai menggunakan penyedia Terraform, yang mempunyai API terbuka yang boleh diterangkan dalam Go.
Katakan kami mula menggunakan Terraform, membaca beberapa dokumentasi di tapak, menonton beberapa video dan mula menulis main.tf, seperti yang saya tunjukkan pada slaid sebelumnya.
Dan semuanya hebat, anda mempunyai fail yang mencipta VPC.
Jika anda ingin mencipta VPC, maka anda tentukan lebih kurang 12 baris ini. Terangkan di rantau mana yang anda ingin buat, cidr_block alamat IP yang hendak digunakan. Itu sahaja.
Sememangnya, projek itu akan berkembang secara beransur-ansur.
Dan anda akan menambah satu tan bahan baharu di sana: sumber, sumber data, anda akan menyepadukan dengan penyedia baharu, tiba-tiba anda akan mahu menggunakan Terraform untuk mengurus pengguna dalam akaun GitHub anda, dsb. Anda mungkin mahu menggunakan pembekal DNS yang berbeza , silangkan segala-galanya. Terraform memudahkan ini.
Mari kita lihat contoh berikut.
Anda menambah internet_gateway secara beransur-ansur kerana anda mahu sumber daripada VPC anda mempunyai akses internet. Ini adalah idea yang baik.
Hasilnya ialah main.tf ini:
Ini ialah bahagian atas main.tf.
Ini ialah bahagian bawah main.tf.
Kemudian anda menambah subnet. Pada masa anda ingin menambah get laluan NAT, laluan, jadual penghalaan dan sekumpulan subnet lain, anda tidak akan mempunyai 38 baris, tetapi lebih kurang 200-300 baris.
Iaitu, fail main.tf anda secara beransur-ansur berkembang. Dan selalunya orang meletakkan segala-galanya dalam satu fail. 10-20 Kb muncul dalam main.tf. Bayangkan 10-20 Kb ialah kandungan teks. Dan semuanya berkaitan dengan segala-galanya. Ini secara beransur-ansur menjadi sukar untuk ditangani. 10-20 Kb ialah kes pengguna yang baik, kadangkala lebih. Dan orang tidak selalu berfikir bahawa ini buruk.
Seperti dalam pengaturcaraan biasa, iaitu bukan infrastruktur sebagai kod, kami biasa menggunakan sekumpulan kelas, pakej, modul, kumpulan yang berbeza. Terraform membolehkan anda melakukan banyak perkara yang sama.
- Kod semakin berkembang.
- Kebergantungan antara sumber juga semakin meningkat.
Dan kita mempunyai keperluan yang besar dan besar. Kami faham bahawa kami tidak boleh hidup seperti ini lagi. Kod kami menjadi besar. 10-20 Kb, sudah tentu, tidak begitu luas, tetapi kita hanya bercakap tentang timbunan rangkaian, iaitu anda hanya menambah sumber rangkaian. Kami tidak bercakap tentang Pengimbang Beban Aplikasi, kelompok ES penempatan, Kubernetes, dsb., di mana 100 Kb boleh dijalin dengan mudah. Jika anda menulis semua ini, anda akan mengetahui bahawa Terraform menyediakan modul Terraform.
Modul Terraform ialah konfigurasi Terraform serba lengkap yang diuruskan sebagai satu kumpulan. Itu sahaja yang anda perlu tahu tentang modul Terraform. Mereka tidak bijak sama sekali, mereka tidak membenarkan anda membuat sebarang sambungan kompleks bergantung pada sesuatu. Ini semua terletak di bahu pemaju. Iaitu, ini hanyalah beberapa jenis konfigurasi Terraform yang telah anda tulis. Dan anda boleh memanggilnya sebagai kumpulan.
Jadi kami cuba memahami cara kami akan mengoptimumkan kod 10-20-30 Kb kami. Kami secara beransur-ansur menyedari bahawa kami perlu menggunakan beberapa modul.
Jenis modul pertama yang anda temui ialah modul sumber. Mereka tidak memahami tentang infrastruktur anda, tentang perniagaan anda, di mana dan apa syaratnya. Ini betul-betul modul yang saya, bersama-sama komuniti sumber terbuka, tadbir, dan yang kami kemukakan sebagai blok binaan awal untuk infrastruktur anda.
Contoh modul sumber.
Apabila kami memanggil modul sumber, kami menentukan dari laluan mana kami harus memuatkan kandungannya.
Kami menunjukkan versi yang ingin kami muat turun.
Kami meluluskan banyak hujah di sana. Itu sahaja. Itu sahaja yang perlu kita ketahui apabila kita menggunakan modul ini.
Ramai yang beranggapan jika menggunakan versi terkini, semuanya akan stabil. Tetapi tidak. Infrastruktur mesti versi; kita mesti menjawab dengan jelas versi mana komponen ini atau komponen itu digunakan.
Berikut ialah kod yang terdapat di dalam modul ini. Modul kumpulan keselamatan. Di sini skrol pergi ke baris ke-640. Mencipta sumber keselamatan-croup di Amazon dalam setiap konfigurasi yang mungkin adalah tugas yang sangat tidak remeh. Tidak cukup dengan hanya mencipta kumpulan keselamatan dan memberitahunya peraturan yang perlu diluluskan kepadanya. Ia akan menjadi sangat mudah. Terdapat satu juta sekatan berbeza di dalam Amazon. Sebagai contoh, jika anda menggunakan Titik akhir VPC, senarai awalan, pelbagai API dan cuba menggabungkan semua ini dengan semua yang lain, maka Terraform tidak membenarkan anda melakukan ini. Dan API Amazon juga tidak membenarkan ini. Oleh itu, kita perlu menyembunyikan semua logik yang mengerikan ini dalam modul dan memberikan kod pengguna yang kelihatan seperti ini.
Pengguna tidak perlu tahu bagaimana ia dibuat di dalam.
Jenis modul kedua, yang terdiri daripada modul sumber, sudah menyelesaikan masalah yang lebih sesuai untuk perniagaan anda. Selalunya ini adalah tempat yang merupakan lanjutan untuk Terraform dan menetapkan beberapa nilai tegar untuk teg, untuk piawaian syarikat. Anda juga boleh menambah kefungsian di sana yang Terraform tidak membenarkan anda gunakan pada masa ini. Ini sekarang. Kini versi 0.11, yang akan menjadi perkara yang ketinggalan. Namun begitu, prapemproses, jsonnet, cookiecutter dan sekumpulan perkara lain adalah mekanisme tambahan yang mesti digunakan untuk kerja sepenuhnya.
Seterusnya saya akan menunjukkan beberapa contoh ini.
Modul infrastruktur dipanggil dengan cara yang sama.
Sumber dari mana untuk memuat turun kandungan ditunjukkan.
Sekumpulan nilai dihantar dan dihantar ke dalam modul ini.
Seterusnya, di dalam modul ini, sekumpulan modul sumber dipanggil untuk mencipta VPC atau Pengimbang Beban Aplikasi, atau untuk mencipta kumpulan keselamatan atau untuk kluster Perkhidmatan Bekas Elastik.
Terdapat dua jenis modul. Ini penting untuk difahami kerana kebanyakan maklumat yang saya kumpulkan dalam laporan ini tidak ditulis dalam dokumentasi.
Dan dokumentasi dalam Terraform sekarang agak bermasalah kerana ia hanya mengatakan terdapat ciri-ciri ini, anda boleh menggunakannya. Tetapi dia tidak menyatakan cara menggunakan ciri ini, mengapa lebih baik menggunakannya. Oleh itu, sebilangan besar orang menulis sesuatu yang mereka tidak boleh hidup dengannya.
Mari kita lihat cara menulis modul ini seterusnya. Kemudian kita akan melihat cara memanggil mereka dan cara bekerja dengan kod tersebut.
Pendaftaran Terraform -
Petua #0 adalah untuk tidak menulis modul sumber. Kebanyakan modul ini telah pun ditulis untuk anda. Seperti yang saya katakan, ia adalah sumber terbuka, ia tidak mengandungi sebarang logik perniagaan anda, ia tidak mempunyai nilai kod keras untuk alamat IP, kata laluan, dll. Modul ini sangat fleksibel. Dan kemungkinan besar ia telah ditulis. Terdapat banyak modul untuk sumber dari Amazon. Kira-kira 650. Dan kebanyakannya adalah berkualiti.
Dalam contoh ini, seseorang datang kepada anda dan berkata, "Saya mahu dapat mengurus pangkalan data. Buat modul supaya saya boleh mencipta pangkalan data." Orang itu tidak mengetahui butiran pelaksanaan sama ada Amazon atau Terraform. Dia hanya berkata: "Saya mahu menguruskan MSSQL." Iaitu, kami maksudkan bahawa ia akan memanggil modul kami, lulus jenis enjin di sana, dan menunjukkan zon waktu.
Dan seseorang tidak sepatutnya tahu bahawa kami akan mencipta dua sumber berbeza di dalam modul ini: satu untuk MSSQL, yang kedua untuk semua yang lain, hanya kerana dalam Terraform 0.11 anda tidak boleh menentukan nilai zon waktu sebagai pilihan.
Dan apabila keluar dari modul ini, seseorang hanya boleh menerima alamat. Dia tidak akan tahu dari pangkalan data mana, dari sumber mana kami mencipta semua ini secara dalaman. Ini adalah elemen penyembunyian yang sangat penting. Dan ini terpakai bukan sahaja kepada modul yang terbuka dalam sumber terbuka, tetapi juga kepada modul yang akan anda tulis di dalam projek dan pasukan anda.
Ini adalah hujah kedua, yang agak penting jika anda telah menggunakan Terraform untuk seketika. Anda mempunyai repositori di mana anda meletakkan semua modul Terraform anda untuk syarikat anda. Dan ia adalah perkara biasa bahawa dari masa ke masa projek ini akan berkembang kepada saiz satu atau dua megabait. Ini baik.
Tetapi masalahnya ialah bagaimana Terraform memanggil modul ini. Contohnya, jika anda memanggil modul untuk mencipta setiap pengguna individu, Terraform akan memuatkan keseluruhan repositori dahulu dan kemudian menavigasi ke folder di mana modul khusus tersebut berada. Dengan cara ini anda akan memuat turun satu megabait setiap kali. Jika anda menguruskan 100 atau 200 pengguna, maka anda akan memuat turun 100 atau 200 megabait, dan kemudian pergi ke folder itu. Jadi sememangnya anda tidak mahu memuat turun sekumpulan barangan setiap kali anda menekan "Terraform init".
Terdapat dua penyelesaian untuk masalah ini. Yang pertama ialah menggunakan laluan relatif. Dengan cara ini anda menunjukkan dalam kod bahawa folder itu adalah setempat (./). Dan sebelum anda melancarkan apa-apa, anda melakukan klon Git repositori ini secara tempatan. Dengan cara ini anda melakukannya sekali.
Sudah tentu, terdapat banyak keburukan. Sebagai contoh, anda tidak boleh menggunakan versi. Dan ini kadang-kadang sukar untuk hidup.
Penyelesaian kedua. Jika anda mempunyai banyak submodul dan anda sudah mempunyai beberapa jenis saluran paip yang telah ditetapkan, maka terdapat projek MBT, yang membolehkan anda mengumpul banyak pakej berbeza dari monorepositori dan memuat naiknya ke S3. Ini adalah cara yang sangat baik. Oleh itu, fail iam-user-1.0.0.zip hanya akan mempunyai berat 1 Kb, kerana kod untuk mencipta sumber ini adalah sangat kecil. Dan ia akan berfungsi lebih cepat.
Mari kita bercakap tentang apa yang tidak boleh digunakan dalam modul.
Mengapa kejahatan ini dalam modul? Perkara yang paling teruk ialah menganggap pengguna. Andaikan pengguna ialah pilihan pengesahan pembekal yang boleh digunakan oleh orang yang berbeza. Sebagai contoh, kita semua akan mengasimilasikan peranan. Ini bermakna Terraform akan mengambil alih peranan ini. Dan kemudian dengan peranan ini ia akan melakukan tindakan lain.
Dan kejahatannya ialah jika Vasya suka menyambung ke Amazon dalam satu cara, contohnya, menggunakan pembolehubah persekitaran lalai, dan Petya suka menggunakan kunci kongsinya, yang dia ada di tempat rahsia, maka anda tidak boleh menentukan kedua-duanya dalam Terraform. Dan supaya mereka tidak mengalami penderitaan, tidak perlu menunjukkan blok ini dalam modul. Ini mesti ditunjukkan pada tahap yang lebih tinggi. Iaitu, kami mempunyai modul sumber, modul infrastruktur dan komposisi di atas. Dan ini harus ditunjukkan di tempat yang lebih tinggi.
Kejahatan kedua ialah pemberi rezeki. Di sini kejahatan tidak begitu remeh, kerana jika anda menulis kod dan ia berfungsi untuk anda, maka anda mungkin berfikir bahawa jika ia berfungsi, maka mengapa mengubahnya.
Perkara buruknya ialah anda tidak sentiasa mengawal bila penyedia ini akan dilancarkan, pertama sekali. Dan kedua, anda tidak mengawal maksud aws ec2, iaitu adakah kita bercakap tentang Linux atau Windows sekarang. Jadi anda tidak boleh menulis sesuatu yang akan berfungsi sama pada sistem pengendalian yang berbeza atau untuk kes pengguna yang berbeza.
Contoh yang paling biasa, yang juga ditunjukkan dalam dokumentasi rasmi, ialah jika anda menulis aws_instance dan menentukan sekumpulan hujah, maka tidak ada salahnya jika anda menentukan penyedia "local-exec" di sana dan menjalankan ansible anda- buku permainan.
Sebenarnya, ya, tidak ada yang salah dengan itu. Tetapi tidak lama lagi anda akan menyedari bahawa perkara local-exec ini tidak wujud, sebagai contoh, dalam launch_configuration.
Dan apabila anda menggunakan launch_configuration, dan anda ingin mencipta kumpulan autoscaling dari satu contoh, maka dalam launch_configuration tidak ada konsep "penyedia". Terdapat konsep "data pengguna".
Oleh itu, penyelesaian yang lebih universal ialah menggunakan data pengguna. Dan ia akan dilancarkan sama ada pada tika itu sendiri, apabila tika itu dihidupkan, atau dalam data pengguna yang sama, apabila kumpulan penskalaan automatik menggunakan konfigurasi_pelancaran ini.
Jika anda masih mahu menjalankan pembekal, kerana ia adalah komponen gluing, apabila satu sumber dicipta, pada masa itu anda perlu menjalankan pembekal anda, arahan anda. Terdapat banyak situasi sedemikian.
Dan sumber yang paling betul untuk ini dipanggil null_resource. Null_resource ialah sumber tiruan yang sebenarnya tidak pernah dibuat. Ia tidak menyentuh apa-apa, tiada API, tiada penskalaan automatik. Tetapi ia membolehkan anda mengawal masa untuk menjalankan arahan. Dalam kes ini, arahan dijalankan semasa penciptaan.
Link
Terdapat beberapa tanda. Saya tidak akan membincangkan semua tanda dengan terperinci. Terdapat artikel mengenai perkara ini. Tetapi jika anda telah bekerja dengan Terraform atau menggunakan modul orang lain, maka anda sering menyedari bahawa banyak modul, seperti kebanyakan kod dalam sumber terbuka, ditulis oleh orang untuk keperluan mereka sendiri. Seorang lelaki menulisnya dan menyelesaikan masalahnya. Saya menyimpannya dalam GitHub, biarkan ia hidup. Ia akan hidup, tetapi jika tiada dokumentasi dan contoh di sana, maka tiada siapa yang akan menggunakannya. Dan jika tiada fungsi yang membolehkan anda menyelesaikan lebih sedikit daripada tugas khususnya, maka tiada siapa yang akan menggunakannya sama ada. Terdapat banyak cara untuk kehilangan pengguna.
Jika anda ingin menulis sesuatu supaya orang akan menggunakannya, maka saya sarankan untuk mengikuti tanda-tanda ini.
Ini adalah:
- Dokumentasi dan contoh.
- Fungsi penuh.
- Lalai yang munasabah.
- Kod bersih.
- Ujian.
Ujian adalah situasi yang berbeza kerana ia agak sukar untuk ditulis. Saya lebih percaya pada dokumentasi dan contoh.
Jadi, kami melihat cara menulis modul. Terdapat dua hujah. Yang pertama, yang paling penting, adalah jangan menulis jika anda boleh, kerana sekumpulan orang telah melakukan tugas-tugas ini sebelum anda. Dan kedua, jika anda masih membuat keputusan, maka cuba untuk tidak menggunakan pembekal dalam modul dan pembekal.
Ini ialah bahagian kelabu dokumentasi. Anda kini mungkin berfikir: βSesuatu yang tidak jelas. Tidak yakin." Tetapi kita akan lihat dalam enam bulan.
Sekarang mari kita bincangkan tentang cara memanggil modul ini.
Kami faham bahawa kod kami berkembang dari semasa ke semasa. Kami tidak lagi mempunyai satu fail, kami sudah mempunyai 20 fail. Mereka semua dalam satu folder. Atau mungkin lima folder. Mungkin kita mula memecahnya mengikut wilayah, oleh beberapa komponen. Kemudian kami faham bahawa kini kami mempunyai beberapa asas penyegerakan dan orkestrasi. Iaitu, kita mesti memahami apa yang perlu kita lakukan jika kita menukar sumber rangkaian, apa yang perlu kita lakukan dengan sumber kita yang lain, cara menyebabkan kebergantungan ini, dsb.
Terdapat dua keterlaluan. Ekstrem pertama adalah semua dalam satu. Kami mempunyai satu fail induk. Buat masa ini, ini adalah amalan terbaik rasmi di tapak web Terraform.
Tetapi kini ia ditulis sebagai tidak digunakan dan dialih keluar. Lama kelamaan, komuniti Terraform menyedari bahawa ini jauh daripada amalan terbaik, kerana orang ramai mula menggunakan projek itu dengan cara yang berbeza. Dan ada masalah. Sebagai contoh, apabila kita menyenaraikan semua kebergantungan di satu tempat. Terdapat situasi apabila kita mengklik "Pelan Terraform" dan sehingga Terraform mengemas kini keadaan semua sumber, banyak masa boleh berlalu.
Banyak masa, sebagai contoh, 5 minit. Bagi sesetengah orang ini adalah banyak masa. Saya telah melihat kes yang mengambil masa 15 minit. API AWS menghabiskan 15 minit cuba memikirkan perkara yang berlaku dengan keadaan setiap sumber. Ini adalah kawasan yang sangat luas.
Dan, secara semula jadi, masalah berkaitan akan muncul apabila anda ingin menukar sesuatu di satu tempat, kemudian anda menunggu 15 minit, dan ia memberi anda kanvas beberapa perubahan. Anda meludah, menulis "Ya", dan sesuatu telah berlaku. Ini adalah contoh yang sangat nyata. Terraform tidak cuba melindungi anda daripada masalah. Iaitu, tulis apa yang anda mahu. Akan ada masalah - masalah anda. Walaupun Terraform 0.11 tidak cuba membantu anda dalam apa jua cara. Terdapat tempat menarik tertentu dalam 0.12 yang membolehkan anda berkata: "Vasya, anda benar-benar mahukan ini, bolehkah anda sedar?"
Cara kedua ialah mengurangkan kawasan ini, iaitu panggilan dari satu tempat boleh kurang berhubung dari tempat lain.
Satu-satunya masalah ialah anda perlu menulis lebih banyak kod, iaitu anda perlu menerangkan pembolehubah dalam sejumlah besar fail dan mengemas kini ini. Sesetengah orang tidak menyukainya. Ini adalah perkara biasa bagi saya. Dan sesetengah orang berfikir: "Mengapa menulis ini di tempat yang berbeza, saya akan meletakkan semuanya di satu tempat." Ini mungkin, tetapi ini adalah ekstrem kedua.
Siapa yang mempunyai semua ini tinggal di satu tempat? Satu, dua, tiga orang, iaitu ada yang menggunakannya.
Dan siapa yang memanggil satu komponen tertentu, satu blok atau satu modul infrastruktur? Lima hingga tujuh orang. Ini hebat.
Jawapan yang paling biasa adalah di suatu tempat di tengah. Jika projek itu besar, maka anda akan sering mengalami situasi di mana tiada penyelesaian yang sesuai dan tidak semuanya berfungsi di luar sana, jadi anda berakhir dengan campuran. Tidak salah dengan ini, asalkan anda faham bahawa kedua-duanya mempunyai kelebihan.
Jika sesuatu berubah dalam VPC tindanan dan anda mahu menggunakan perubahan ini pada EC2, iaitu anda ingin mengemas kini kumpulan penskalaan automatik kerana anda mempunyai subnet baharu, maka saya panggil orkestra pergantungan jenis ini. Terdapat beberapa penyelesaian: siapa yang menggunakan apa?
Saya boleh cadangkan apa penyelesaian yang ada. Anda boleh menggunakan Terraform untuk melakukan sihir, atau anda boleh menggunakan makefiles untuk menggunakan Terraform. Dan lihat jika sesuatu telah berubah di sana, anda boleh melancarkannya di sini.
Bagaimanakah anda menyukai keputusan ini? Adakah sesiapa percaya ini adalah penyelesaian yang hebat? Saya melihat senyuman, rupa-rupanya keraguan telah menyelinap masuk.
Sudah tentu, jangan cuba ini di rumah. Terraform tidak pernah direka bentuk untuk dijalankan daripada Terraform.
Pada satu laporan mereka memberitahu saya: "Tidak, ini tidak akan berfungsi." Intinya ialah ia tidak sepatutnya berfungsi. Walaupun ia kelihatan sangat mengagumkan apabila anda boleh melancarkan Terraform daripada Terraform, dan kemudian Terraform, anda tidak sepatutnya berbuat demikian. Terraform hendaklah sentiasa bermula dengan mudah.
Jika anda memerlukan orkestrasi panggilan apabila sesuatu telah berubah di satu tempat, maka terdapat Terragrunt.
Terragrunt ialah utiliti, tambahan kepada Terraform, yang membolehkan anda menyelaras dan mengatur panggilan ke modul infrastruktur.
Fail konfigurasi Terraform biasa kelihatan seperti ini.
Anda tentukan modul tertentu yang ingin anda panggil.
Apakah kebergantungan yang ada pada modul?
Dan apakah hujah yang diterima oleh modul ini. Itu sahaja yang perlu diketahui tentang Terragrunt.
Dokumentasi ada di sana, dan terdapat 1 bintang di GitHub. Tetapi dalam kebanyakan kes inilah yang anda perlu tahu. Dan ini sangat mudah untuk dilaksanakan dalam syarikat yang baru mula bekerja dengan Terraform.
Jadi orkestrasi adalah Terragrunt. Terdapat pilihan lain.
Sekarang mari kita bercakap tentang cara bekerja dengan kod.
Jika anda perlu menambah ciri baharu pada kod anda, dalam kebanyakan kes ini adalah mudah. Anda sedang menulis sumber baharu, semuanya mudah.
Jika anda mempunyai beberapa sumber yang anda buat lebih awal, sebagai contoh, anda mempelajari tentang Terraform selepas anda membuka akaun AWS dan ingin menggunakan sumber yang anda sudah ada, maka adalah wajar untuk melanjutkan modul anda dengan cara ini, supaya ia menyokong penggunaan sumber sedia ada.
Dan menyokong penciptaan sumber baharu menggunakan sumber blok.
Pada output kami sentiasa mengembalikan id output bergantung pada apa yang digunakan.
Masalah kedua yang sangat penting dalam Terraform 0.11 adalah berfungsi dengan senarai.
Kesukarannya ialah jika kita mempunyai senarai pengguna sedemikian.
Dan apabila kami mencipta pengguna ini menggunakan sumber blok, maka semuanya berjalan lancar. Kami meneliti keseluruhan senarai, mencipta fail untuk setiap satu. Semuanya baik-baik sahaja. Dan kemudian, sebagai contoh, pengguna3, yang berada di tengah, harus dialih keluar dari sini, maka semua sumber yang dicipta selepasnya akan dicipta semula kerana indeks akan berubah.
Bekerja dengan senarai dalam persekitaran stateful. Apakah persekitaran stateful? Ini ialah situasi di mana nilai baharu dicipta apabila sumber ini dicipta. Contohnya, Kunci Akses AWS atau Kunci Rahsia AWS, iaitu apabila kami mencipta pengguna, kami menerima Akses atau Kunci Rahsia baharu. Dan setiap kali kami memadamkan pengguna, pengguna ini akan mempunyai kunci baharu. Tetapi ini bukan feng shui, kerana pengguna tidak akan mahu berkawan dengan kita jika kita mencipta pengguna baharu untuknya setiap kali seseorang meninggalkan pasukan.
Ini adalah penyelesaiannya. Ini adalah kod yang ditulis dalam Jsonnet. Jsonnet ialah bahasa templat daripada Google.
Perintah ini membolehkan anda menerima templat ini dan sebagai output ia mengembalikan fail json yang dibuat mengikut templat anda.
Templat kelihatan seperti ini.
Terraform membolehkan anda bekerja dengan kedua-dua HCL dan Json dengan cara yang sama, jadi jika anda mempunyai keupayaan untuk menjana Json, maka anda boleh memasukkannya ke dalam Terraform. Fail dengan sambungan .tf.json akan berjaya dimuat turun.
Dan kemudian kami bekerja dengannya seperti biasa: terraform init, terramorm apply. Dan kami mencipta dua pengguna.
Sekarang kami tidak takut jika seseorang meninggalkan pasukan. Kami hanya akan mengedit fail json. Vasya Pupkin pergi, Petya Pyatochkin kekal. Petya Pyatochkin tidak akan menerima kunci baharu.
Mengintegrasikan Terraform dengan alatan lain bukanlah tugas Terraform sebenarnya. Terraform telah dicipta sebagai platform untuk mencipta sumber dan itu sahaja. Dan semua yang timbul kemudian bukanlah kebimbangan Terraform. Dan tidak perlu menganyamnya di sana. Terdapat Ansible, yang melakukan semua yang anda perlukan.
Tetapi situasi timbul apabila kita ingin melanjutkan Terraform dan memanggil beberapa arahan selepas sesuatu selesai.
Cara pertama. Kami mencipta output di mana kami menulis arahan ini.
Dan kemudian kita memanggil arahan ini daripada keluaran shell terraform dan nyatakan nilai yang kita mahu. Oleh itu, arahan itu dilaksanakan dengan semua nilai yang digantikan. Ia sangat selesa.
Cara kedua. Ini ialah penggunaan null_resource bergantung pada perubahan dalam infrastruktur kami. Kami boleh memanggil local-exe yang sama sebaik sahaja ID beberapa sumber berubah.
Sememangnya, ini semua lancar di atas kertas, kerana Amazon, seperti semua penyedia awam lain, mempunyai sekumpulan kes kelebihannya sendiri.
Kes kelebihan yang paling biasa ialah apabila anda membuka akaun AWS, kawasan yang anda gunakan adalah penting; adakah ciri ini didayakan di sana; mungkin anda membukanya selepas Disember 2013; mungkin anda menggunakan lalai dalam VPC dll. Terdapat banyak sekatan. Dan Amazon menyebarkannya sepanjang dokumentasi.
Terdapat beberapa perkara yang saya cadangkan untuk mengelak.
Untuk memulakan, elakkan semua hujah bukan rahsia dalam pelan Terraform atau CLI Terraform. Semua ini boleh dimasukkan sama ada ke dalam fail tfvars atau ke dalam pembolehubah persekitaran.
Tetapi anda tidak perlu menghafal keseluruhan perintah sihir ini. Pelan terraform β var dan kami pergi. Pembolehubah pertama ialah var, pembolehubah kedua ialah var, ketiga, keempat. Prinsip infrastruktur yang paling penting sebagai kod yang paling kerap saya gunakan ialah hanya dengan melihat kod, saya harus mempunyai pemahaman yang jelas tentang apa yang digunakan di sana, dalam keadaan apa dan dengan nilai apa. Oleh itu, saya tidak perlu membaca dokumentasi atau bertanya kepada Vasya parameter apa yang dia gunakan untuk membuat kluster kami. Saya hanya perlu membuka fail dengan sambungan tfvars, yang sering sepadan dengan persekitaran, dan melihat segala-galanya di sana.
Juga, jangan gunakan hujah sasaran untuk mengurangkan skop. Untuk ini, lebih mudah untuk menggunakan modul infrastruktur kecil.
Juga, tidak perlu mengehadkan dan meningkatkan keselarian. Jika saya mempunyai 150 sumber dan saya ingin meningkatkan keselarian Amazon daripada lalai 10 kepada 100, maka kemungkinan besar sesuatu akan berlaku. Atau ia mungkin berjalan lancar sekarang, tetapi apabila Amazon mengatakan anda membuat terlalu banyak panggilan, anda akan menghadapi masalah.
Terraform akan cuba memulakan semula kebanyakan masalah ini, tetapi anda tidak akan mencapai apa-apa. Parallelism=1 ialah perkara penting untuk digunakan jika anda terjumpa beberapa pepijat di dalam API AWS atau di dalam penyedia Terraform. Dan kemudian anda perlu menentukan: parallelism=1 dan tunggu sehingga Terraform menyelesaikan satu panggilan, kemudian yang kedua, kemudian yang ketiga. Dia akan melancarkannya satu demi satu.
Orang sering bertanya kepada saya, "Mengapa saya rasa ruang kerja Terraform jahat?" Saya percaya prinsip infrastruktur sebagai kod adalah untuk melihat infrastruktur yang telah dibuat dan dengan nilai apa.
Ruang kerja tidak dicipta oleh pengguna. Ini tidak bermakna pengguna menulis dalam isu GitHub bahawa kita tidak boleh hidup tanpa ruang kerja Terraform. Tidak tidak seperti ini. Terraform Enterprise ialah penyelesaian komersial. Terraform daripada HashiCorp memutuskan bahawa kami memerlukan ruang kerja, jadi kami memfailkannya. Saya mendapati lebih mudah untuk meletakkannya dalam folder yang berasingan. Kemudian akan ada lebih banyak fail, tetapi ia akan menjadi lebih jelas.
Bagaimana untuk bekerja dengan kod? Malah, bekerja dengan senarai adalah satu-satunya kesakitan. Dan ambil Terraform dengan lebih mudah. Ini bukan perkara yang akan melakukan segala-galanya yang hebat untuk anda. Tidak perlu menolak semua yang tertulis dalam dokumentasi di sana.
Topik laporan itu ditulis "untuk masa depan." Saya akan bercakap tentang ini secara ringkas. Untuk masa hadapan, ini bermakna 0.12 akan dikeluarkan tidak lama lagi.
0.12 adalah satu tan barangan baharu. Jika anda datang dari pengaturcaraan biasa, maka anda terlepas semua jenis blok dinamik, gelung, operasi perbandingan yang betul dan bersyarat, di mana bahagian kiri dan kanan tidak dikira secara serentak, tetapi bergantung pada keadaan. Anda sangat merinduinya, jadi 0.12 akan menyelesaikannya untuk anda.
Tetapi! Jika anda menulis kurang dan lebih ringkas, menggunakan modul siap pakai dan penyelesaian pihak ketiga, maka anda tidak perlu menunggu dan berharap bahawa 0.12 akan datang dan membetulkan segala-galanya untuk anda.
Terima kasih atas laporan itu! Anda bercakap tentang infrastruktur sebagai kod dan secara literal mengatakan satu perkataan tentang ujian. Adakah ujian diperlukan dalam modul? Tanggungjawab siapa ini? Adakah saya perlu menulisnya sendiri atau adakah ia tanggungjawab modul?
Tahun depan akan dipenuhi dengan laporan bahawa kami telah memutuskan untuk menguji segala-galanya. Apa yang hendak diuji adalah soalan terbesar. Terdapat banyak kebergantungan, banyak sekatan daripada pembekal yang berbeza. Apabila anda dan saya bercakap dan anda berkata: "Saya memerlukan ujian," maka saya bertanya: "Apa yang akan anda uji?" Anda mengatakan bahawa anda akan menguji di rantau anda. Kemudian saya mengatakan bahawa ini tidak berfungsi di rantau saya. Iaitu, kita tidak akan dapat bersetuju mengenai perkara ini. Apatah lagi terdapat banyak masalah teknikal. Iaitu, bagaimana untuk menulis ujian ini supaya ia mencukupi.
Saya sedang aktif menyelidik topik ini, iaitu cara menjana ujian secara automatik berdasarkan infrastruktur yang anda tulis. Iaitu, jika anda menulis kod ini, maka saya perlu menjalankannya, berdasarkan ini saya boleh membuat ujian.
ialah salah satu perpustakaan yang paling kerap disebut yang membolehkan anda menulis ujian penyepaduan untuk Terraform. Ini adalah salah satu utiliti. Saya lebih suka jenis DSL, contohnya, rspec.
Anton, terima kasih atas laporan itu! Nama saya Valery. Izinkan saya bertanya sedikit soalan falsafah. Ada, dengan syarat, peruntukan, ada penempatan. Peruntukan mencipta infrastruktur saya, dalam penggunaan kita mengisinya dengan sesuatu yang berguna, contohnya, pelayan, aplikasi, dsb. Dan dalam fikiran saya, Terraform lebih kepada peruntukan, dan Ansible lebih kepada penggunaan, kerana Ansible juga untuk fizikal Infrastruktur membolehkan anda memasang nginx, Postgres. Tetapi pada masa yang sama, Ansible nampaknya membenarkan peruntukan, sebagai contoh, sumber Amazon atau Google. Tetapi Terraform juga membenarkan anda menggunakan beberapa perisian menggunakan modulnya. Dari sudut pandangan anda, adakah terdapat beberapa jenis sempadan yang berjalan antara Terraform dan Ansible, di mana dan apa yang lebih baik untuk digunakan? Atau, sebagai contoh, adakah anda fikir Ansible sudah menjadi sampah, anda harus cuba menggunakan Terraform untuk segala-galanya?
Soalan yang bagus, Valery. Saya percaya bahawa Terraform tidak berubah dari segi tujuan sejak 2014. Ia dicipta untuk infrastruktur dan mati untuk infrastruktur. Kami masih mempunyai dan akan memerlukan pengurusan konfigurasi Ansible. Cabarannya ialah terdapat data pengguna di dalam launch_configuration. Dan di sana anda tarik Ansible, dsb. Ini adalah perbezaan standard yang paling saya suka.
Jika kita bercakap tentang infrastruktur yang indah, maka terdapat utiliti seperti Packer yang mengumpul imej ini. Dan kemudian Terraform menggunakan sumber data untuk mencari imej ini dan mengemas kini launch_configurationnya. Iaitu, dengan cara ini saluran paip ialah kita mula-mula tarik Tracker, kemudian tarik Terraform. Dan jika binaan berlaku, maka perubahan baru berlaku.
hello! Terima kasih atas laporan itu! Nama saya Misha, syarikat RBS. Anda boleh menghubungi Ansible melalui penyedia semasa membuat sumber. Ansible juga mempunyai topik yang dipanggil inventori dinamik. Dan anda boleh mula-mula memanggil Terraform, dan kemudian memanggil Ansible, yang akan mengambil sumber dari negeri dan melaksanakannya. Apa yang lebih baik?
Orang menggunakan kedua-duanya dengan kejayaan yang sama. Nampaknya pada saya inventori dinamik dalam Ansible adalah perkara yang mudah, jika kita tidak bercakap tentang autoscaling kumpulan. Kerana dalam kumpulan autoscaling kita sudah mempunyai toolkit kita sendiri, yang dipanggil launch_configuration. Dalam launch_configuration kami merekodkan semua yang perlu dilancarkan apabila kami mencipta sumber baharu. Oleh itu, dengan Amazon, menggunakan inventori dinamik dan membaca fail Terraform ts, pada pendapat saya, adalah berlebihan. Dan jika anda menggunakan alat lain yang tiada konsep "kumpulan penskalaan automatik", sebagai contoh, anda menggunakan DigitalOcean atau beberapa pembekal lain di mana tiada kumpulan penskalaan automatik, maka di sana anda perlu menarik API secara manual, mencari alamat IP, mencipta fail inventori dinamik , dan Ansible sudah pun mengembara melaluinya. Iaitu, untuk Amazon terdapat launch_configuration, dan untuk semua yang lain terdapat inventori dinamik.
Sumber: www.habr.com