Infrastruktur sebagai Kode: Kenalan Pertama

Perusahaan kami sedang dalam proses onboarding tim SRE. Saya membahas keseluruhan cerita ini dari sisi pengembangan. Dalam prosesnya, saya memiliki pemikiran dan wawasan yang ingin saya bagikan dengan pengembang lain. Dalam artikel meditasi ini, saya berbicara tentang apa yang terjadi, bagaimana itu terjadi, dan bagaimana orang lain dapat hidup dengannya.

Kelanjutan dari serangkaian artikel berdasarkan pidato di acara DevForum internal kami :

1. Kucing Schrodinger tanpa kotak: masalah konsensus dalam sistem terdistribusi.
2. Infrastruktur sebagai kode. (Anda disini)
3. Pembuatan kontrak naskah untuk model c #. (Sedang berlangsung ...)
4. Bagaimana server setuju satu sama lain: Algoritma konsensus didistribusikan Raft.
5. Infrastruktur sebagai Kode: bagaimana mengatasi masalah dengan XP.
...

Kami memutuskan untuk membuat tim SRE yang menerapkan ide google sre . Kami merekrut programmer dari pengembang mereka sendiri dan mengirim mereka untuk belajar selama beberapa bulan.

Tim menghadapi tugas pelatihan berikut:

• Jelaskan infrastruktur kami, yang sebagian besar dalam Microsoft Azure dalam bentuk kode (Terraform dan semua yang ada di sekitarnya).
• Ajari pengembang cara bekerja dengan infrastruktur.
• Siapkan pengembang untuk bertugas.

Memperkenalkan konsep Infrastruktur sebagai kode

Dalam model dunia yang biasa (administrasi klasik), pengetahuan tentang infrastruktur ada di dua tempat:

1. Atau dalam bentuk pengetahuan di benak para ahli.
2. Atau informasi ini ada di beberapa mesin tik, beberapa ahli tahu. Tetapi bukan fakta bahwa seseorang dari luar (kalau-kalau seluruh tim kita tiba-tiba mati) akan dapat mengetahui apa dan bagaimana cara kerjanya. Mungkin ada banyak informasi di mesin: pengakses, colokan mahkota, drive (lihat pemasangan disk ) dan hanya daftar tanpa akhir dari apa yang bisa terjadi. Sulit untuk memahami apa yang terjadi dalam kenyataan.

Dalam kedua kasus, kita terjebak, menjadi tergantung:

• atau dari orang yang fana, mudah terserang penyakit, jatuh cinta, perubahan suasana hati dan sekadar pemecatan dangkal;
• atau dari mesin yang berfungsi secara fisik yang juga jatuh, mencuri, menghadirkan hal yang tidak terduga dan tidak nyaman.

Tak perlu dikatakan bahwa idealnya semuanya harus diterjemahkan ke dalam kode tertulis yang dapat dibaca manusia, didukung, berkualitas tinggi.

Dengan demikian, infrastruktur sebagai kode (Incfastructure as Code - IaC) adalah deskripsi seluruh infrastruktur yang tersedia dalam bentuk kode, serta alat terkait untuk bekerja dengannya dan untuk mewujudkan infrastruktur dari itu.

Infrastruktur sebagai masalah kode

Sekarang mari kita lihat contoh bagaimana infrastruktur dapat ditransfer ke dalam kode. Kode ini ditulis dengan baik, berkualitas tinggi, dengan komentar dan indentasi.

Kode sampel dari Terraforma.



Kode sampel dari Ansible.



Tuan-tuan, tetapi jika semuanya begitu sederhana! Kami bersama Anda di dunia nyata, dan dia selalu siap untuk mengejutkan Anda, untuk menghadirkan kejutan, masalah. Bukan tanpa mereka di sini.

1. Masalah pertama adalah bahwa dalam banyak kasus IaC adalah semacam dsl.

Dan DSL, pada gilirannya, adalah deskripsi struktur. Lebih tepatnya, apa yang harus Anda miliki: Json, Yaml, modifikasi dari beberapa perusahaan besar yang datang dengan dsl mereka sendiri (HCL digunakan dalam terraform).

Masalahnya adalah bahwa di dalamnya mungkin tidak ada hal-hal yang akrab bagi kita seperti:

• Variabel
• kondisi;
• di suatu tempat tidak ada komentar, misalnya, di Json, secara default tidak disediakan;
• fungsi
• dan saya tidak berbicara tentang hal-hal tingkat tinggi seperti kelas, warisan, dan semua itu.

2. Masalah kedua dengan kode ini paling sering adalah lingkungan yang heterogen . Biasanya Anda duduk dan bekerja dengan C #, yaitu dengan satu bahasa, satu tumpukan, satu ekosistem. Dan di sini Anda memiliki beragam teknologi.

Ini adalah situasi yang sangat nyata ketika sebuah bash dengan python memulai beberapa proses di mana Json tergelincir. Anda menganalisanya, kemudian generator lain menghasilkan 30 file lainnya. Untuk semua ini, variabel input dari Azure Key Vault masuk, yang ditarik bersama oleh plugin untuk drone.io yang ditulis dalam Go, dan variabel-variabel ini melewati yaml, yang diperoleh sebagai hasil dari generasi dari mesin templat jsonnet. Sangat sulit untuk memiliki kode yang dijelaskan dengan baik ketika Anda memiliki lingkungan yang beragam.

Pengembangan tradisional dalam kerangka satu tugas dilengkapi dengan satu bahasa. Di sini kami bekerja dengan sejumlah besar bahasa.

3. Masalah ketiga adalah tuling . Kami terbiasa mendinginkan editor (Ms Visual Studio, Jetbrains Rider) yang melakukan segalanya untuk kami. Dan bahkan jika kita tumpul, mereka akan mengatakan bahwa kita salah. Tampaknya normal dan alami.

Tetapi di suatu tempat di dekatnya ada VSCode, di mana ada beberapa plugin yang entah bagaimana diinstal, didukung atau tidak didukung. Versi baru dirilis dan tidak didukung. Transisi dangkal ke implementasi fungsi (bahkan jika ada) menjadi masalah yang kompleks dan non-sepele. Mengubah nama sederhana dari suatu variabel adalah replay dalam proyek selusin file. Beruntung jika itu adalah sesuatu yang perlu diperbaiki. Tentu saja, ada cahaya latar di beberapa tempat, ada kompilasi otomatis, di suatu tempat ada format (meskipun saya tidak memulai pada Windows dalam terraform).

Pada saat penulisan, plugin vscode-terraform belum dirilis untuk mendukung versi 0.12, meskipun sudah dirilis selama 3 bulan.

Saatnya melupakan ...

1. Debugging
2. Alat refactoring.
3. Penyelesaian otomatis.
4. Mendeteksi kesalahan kompilasi.

Ini lucu, tetapi juga meningkatkan waktu pengembangan dan meningkatkan jumlah kesalahan yang pasti terjadi.

Yang terburuk adalah kita dipaksa untuk tidak memikirkan bagaimana mendesain, mendekomposisi file ke dalam folder, menguraikan, membuat kode dapat didukung, dapat dibaca, dll. Tetapi tentang bagaimana saya akan menulis perintah ini dengan benar, karena saya entah bagaimana menulisnya dengan salah .

Sebagai pemula, Anda mencoba mempelajari terraform, dan IDE sama sekali tidak membantu Anda. Ketika ada dokumentasi - mereka masuk, melihat. Tetapi jika Anda memasukkan bahasa pemrograman baru, maka IDE akan menyarankan bahwa ada jenis seperti itu, tetapi tidak ada. Setidaknya pada level int atau string. Ini sering bermanfaat.

Tapi bagaimana dengan tesnya?

Anda bertanya: "Bagaimana dengan tes, tuan-tuan programmer?" Orang-orang serius sedang menguji segala sesuatu pada prod, dan itu sulit. Berikut ini adalah contoh pengujian unit untuk modul terraform dari situs web Microsoft .



Mereka memiliki dokumentasi yang bagus. Saya selalu menyukai Microsoft karena pendekatannya pada dokumentasi dan pelatihan. Tetapi Anda tidak perlu menjadi Paman Bob untuk memahami bahwa ini bukan kode yang ideal. Perhatikan validasi yang diberikan ke kanan.

Masalah dengan tes unit adalah bahwa Anda dan saya dapat memverifikasi kebenaran output Json. Saya melempar 5 parameter, saya diberi Json footcloth untuk 2000 baris. Saya dapat menganalisis apa yang terjadi di sini, memvalidasi hasil tes ...

Sulit untuk mem-parsing Json di Go. Dan Anda perlu menulis di Go, karena terraforms on Go adalah praktik yang baik dari apa yang Anda uji dalam bahasa tempat Anda menulis. Pengaturan kode sangat lemah. Pada saat yang sama, ini adalah perpustakaan terbaik untuk pengujian.

Microsoft sendiri menulis modulnya, mengujinya dengan cara ini. Tentu saja, ini adalah Open Source. Semua yang saya bicarakan tentang Anda dapat datang dan memperbaiki. Saya bisa duduk dan memperbaiki semuanya dalam seminggu, membuka plugin VS-code, terraforms, membuat plugin rider. Mungkin menulis beberapa alat analisa, memutar sekrup, menyalin perpustakaan untuk pengujian. Saya bisa melakukan semuanya. Tetapi saya tidak harus melakukan ini.

Infrastruktur Praktik Terbaik sebagai kode

Kita melangkah lebih jauh. Jika tidak ada tes di IaC, buruk dengan IDE dan tuning, maka harus ada setidaknya praktik terbaik. Saya baru saja pergi ke Google analytics dan membandingkan dua permintaan pencarian: Praktik terbaik Terraform dan praktik terbaik c #.



Apa yang kita lihat Statistik kejam tidak mendukung kami. Dengan jumlah material - hal yang sama. Dalam pengembangan C #, kami hanya mandi bahan, kami memiliki praktik super-terbaik, ada buku yang ditulis oleh para ahli, dan juga buku yang ditulis pada buku oleh para ahli lain yang mengkritik buku-buku itu. Lautan dokumentasi resmi, artikel, kursus pelatihan, sekarang juga pengembangan sumber terbuka.

Adapun permintaan IaC: di sini Anda sedikit demi sedikit mencoba mengumpulkan informasi dari laporan highload atau HashiConf, dari dokumentasi resmi dan berbagai masalah di github. Bagaimana Anda menyebarkan modul-modul ini, apa yang harus dilakukan dengan mereka? Tampaknya ini adalah masalah nyata ... Ada sebuah komunitas, tuan-tuan, di mana Anda akan diberikan 10 komentar pada github untuk pertanyaan apa pun. Tetapi ini tidak akurat.

Sayangnya, pada titik waktu ini, para ahli baru mulai muncul. Meskipun jumlahnya terlalu sedikit. Dan komunitas itu sendiri tergantung pada tingkat primordia.

Kemana perginya dan apa yang harus dilakukan

Anda dapat menjatuhkan semuanya dan kembali ke C #, ke dunia pengendara. Tapi tidak. Mengapa Anda melakukan ini jika Anda tidak menemukan solusi. Selanjutnya, saya memberikan kesimpulan subyektif saya. Anda bisa berdebat dengan saya di komentar, itu akan menarik.

Secara pribadi, saya memakai beberapa hal:

1. Pengembangan di bidang ini sangat cepat. Saya memberikan jadwal permintaan untuk DevOps.
   
   
   
   Mungkin topiknya hype, tetapi fakta bahwa bola berkembang memberi kita harapan.
   
   Jika sesuatu tumbuh begitu cepat, maka orang pintar pasti akan muncul siapa yang akan mengatakan bagaimana melakukannya, dan bagaimana tidak. Peningkatan popularitas mengarah pada fakta bahwa mungkin seseorang akan memiliki waktu untuk akhirnya menambahkan plugin jsonnet untuk vscode, yang akan memungkinkan kita untuk melanjutkan ke implementasi fungsi, daripada mencarinya melalui ctrl + shift + f. Ketika semuanya berkembang, lebih banyak bahan muncul. Buku google yang sama tentang SRE adalah contoh yang bagus.
2. Ada teknik dan praktik yang dikembangkan dalam pengembangan konvensional yang berhasil kami terapkan di sini. Ya, ada nuansa dengan pengujian dan lingkungan yang heterogen, penyetelan tidak mencukupi, tetapi sejumlah besar praktik telah terakumulasi yang dapat berguna dan membantu.
   
   Contoh sepele: kolaborasi melalui pemrograman pasangan. Ini sangat membantu untuk mencari tahu. Ketika Anda memiliki tetangga di dekatnya yang juga mencoba memahami sesuatu, bersama-sama Anda akan memahami dengan lebih baik.
   
   Memahami bagaimana refactoring dilakukan membantu memproduksinya bahkan dalam situasi seperti itu. Artinya, Anda tidak dapat mengubah semuanya sekaligus, tetapi mengubah penamaan, lalu mengubah lokasi, lalu dapat menyorot beberapa bagian, oh, tetapi tidak ada cukup komentar.

Kesimpulan

Terlepas dari kenyataan bahwa alasan saya mungkin tampak pesimistis, saya menantikan masa depan dan dengan tulus berharap bahwa kami (dan Anda) akan berhasil.

Berikutnya adalah bagian kedua artikel . Di dalamnya, saya berbicara tentang bagaimana kami menggunakan praktik pemrograman ekstrem untuk meningkatkan proses pembelajaran kami dan bekerja dengan infrastruktur.