Syarikat kami sedang dalam proses untuk memasukkan pasukan SRE. Saya datang ke keseluruhan cerita ini dari sisi pembangunan. Dalam proses itu, saya menghasilkan pemikiran dan pandangan yang ingin saya kongsikan dengan pembangun lain. Dalam artikel refleksi ini saya bercakap tentang apa yang sedang berlaku, bagaimana ia berlaku, dan bagaimana semua orang boleh terus hidup dengannya.
Kesinambungan siri artikel yang ditulis berdasarkan ucapan di majlis dalaman kami :
2. Infrastruktur sebagai kod. (Kamu di sini)
3. Penjanaan kontrak TypeScript menggunakan model C#. (Sedang berjalan...)
4. Pengenalan kepada algoritma konsensus Raft. (Sedang berjalan...)
...
Kami memutuskan untuk mewujudkan pasukan SRE, melaksanakan idea . Mereka merekrut pengaturcara daripada kalangan pemaju mereka sendiri dan menghantar mereka untuk berlatih selama beberapa bulan.
Pasukan ini mempunyai tugas latihan berikut:
- Terangkan infrastruktur kami, yang kebanyakannya terdapat dalam Microsoft Azure dalam bentuk kod (Terraform dan segala-galanya di sekeliling).
- Ajar pembangun cara bekerja dengan infrastruktur.
- Sediakan pemaju untuk bertugas.
Kami memperkenalkan konsep Infrastruktur sebagai kod
Dalam model biasa dunia (pentadbiran klasik), pengetahuan tentang infrastruktur terletak di dua tempat:
- Ataupun dalam bentuk ilmu di kepala para ahli.
- Atau maklumat ini ada pada beberapa mesin taip, beberapa daripadanya diketahui oleh pakar. Tetapi bukan fakta bahawa orang luar (sekiranya seluruh pasukan kami tiba-tiba mati) akan dapat mengetahui perkara yang berfungsi dan cara ia berfungsi. Terdapat banyak maklumat tentang mesin: aksesori, cronjob, terintimidasi (lihat. ) cakera dan hanya senarai tidak berkesudahan yang boleh berlaku. Sukar untuk memahami apa yang sebenarnya berlaku.
Dalam kedua-dua kes, kita mendapati diri kita terperangkap dalam menjadi bergantung:
- atau daripada seseorang yang fana, tertakluk kepada penyakit, jatuh cinta, perubahan mood dan pemberhentian biasa;
- atau daripada mesin yang berfungsi secara fizikal, yang juga jatuh, dicuri, dan memberikan kejutan dan kesulitan.
Sudah semestinya segala-galanya harus diterjemahkan ke dalam kod yang boleh dibaca manusia, boleh diselenggara, dan ditulis dengan baik.
Oleh itu, infrastruktur sebagai kod (Incfastructure as Code - IaC) ialah perihalan keseluruhan infrastruktur sedia ada dalam bentuk kod, serta alat yang berkaitan untuk bekerja dengannya dan melaksanakan infrastruktur sebenar daripadanya.
Mengapa menterjemahkan semuanya ke dalam kod?Orang bukan mesin. Mereka tidak boleh mengingati segala-galanya. Reaksi seseorang dan mesin adalah berbeza. Apa-apa perkara yang diautomatikkan berpotensi lebih pantas daripada apa-apa yang dilakukan oleh manusia. Perkara yang paling penting ialah satu sumber kebenaran.
Dari mana datangnya jurutera SRE baharu?Jadi, kami memutuskan untuk mengupah jurutera SRE baharu, tetapi dari mana untuk mendapatkannya? Buku dengan jawapan yang betul () memberitahu kami: daripada pemaju. Lagipun, mereka berfungsi dengan kod, dan anda mencapai keadaan ideal.
Kami mencari banyak untuk masa yang lama untuk mereka di pasaran kakitangan di luar syarikat kami. Tetapi kami harus mengakui bahawa kami tidak menemui sesiapa yang sesuai dengan permintaan kami. Saya terpaksa mencari di kalangan orang saya sendiri.
Masalah Infrastruktur sebagai kod
Sekarang mari kita lihat contoh cara infrastruktur boleh dikodkan ke dalam kod. Kod ini ditulis dengan baik, berkualiti tinggi, dengan komen dan lekukan.
Contoh kod daripada Terraforma.
Contoh kod daripada Ansible.
Tuan-tuan, jika ia adalah begitu mudah! Kami berada di dunia nyata, dan ia sentiasa bersedia untuk mengejutkan anda, memberikan anda kejutan dan masalah. Tidak boleh melakukannya tanpa mereka di sini juga.
1. Masalah pertama ialah dalam kebanyakan kes IaC adalah sejenis dsl.
Dan DSL pula ialah perihalan struktur. Lebih tepat lagi, perkara yang anda patut ada: Json, Yaml, pengubahsuaian daripada beberapa syarikat besar yang menghasilkan dsl mereka sendiri (HCL digunakan dalam terraform).
Masalahnya ialah ia mungkin tidak mengandungi perkara biasa seperti:
- pembolehubah;
- syarat;
- di suatu tempat tiada komen, contohnya, dalam Json, secara lalai mereka tidak disediakan;
- fungsi;
- dan saya tidak bercakap pun tentang perkara peringkat tinggi seperti kelas, warisan dan semua itu.
2. Masalah kedua dengan kod sedemikian ialah paling kerap ia adalah persekitaran yang heterogen. Biasanya anda duduk dan bekerja dengan C#, i.e. dengan satu bahasa, satu timbunan, satu ekosistem. Dan di sini anda mempunyai pelbagai jenis teknologi.
Ia adalah situasi yang sangat nyata apabila bash dengan python melancarkan beberapa proses di mana Json dimasukkan. Anda menganalisisnya, kemudian beberapa penjana lain menghasilkan 30 fail lagi. Untuk semua ini, pembolehubah input diterima daripada Azure Key Vault, yang ditarik bersama oleh pemalam untuk drone.io yang ditulis dalam Go, dan pembolehubah ini melalui yaml, yang dijana hasil penjanaan daripada enjin templat jsonnet. Agak sukar untuk mempunyai kod yang diterangkan dengan baik apabila anda mempunyai persekitaran yang pelbagai.
Pembangunan tradisional dalam rangka satu tugas datang dengan satu bahasa. Di sini kami bekerja dengan sejumlah besar bahasa.
3. Masalah ketiga ialah penalaan. Kami digunakan untuk menyejukkan editor (Ms Visual Studio, Jetbrains Rider) yang melakukan segala-galanya untuk kami. Dan walaupun kita bodoh, mereka akan mengatakan bahawa kita salah. Nampak biasa dan natural.
Tetapi di suatu tempat berdekatan terdapat VSCode, di mana terdapat beberapa pemalam yang entah bagaimana dipasang, disokong atau tidak disokong. Versi baharu keluar dan tidak disokong. Peralihan cetek untuk melaksanakan fungsi (walaupun ia wujud) menjadi masalah yang kompleks dan bukan remeh. Nama semula mudah pembolehubah ialah ulang tayang dalam projek sedozen fail. Anda akan bertuah jika dia meletakkan apa yang anda perlukan. Sudah tentu, terdapat lampu latar di sana sini, terdapat auto-lengkap, di suatu tempat terdapat pemformatan (walaupun ia tidak berfungsi untuk saya dalam terraform pada Windows).
Pada masa penulisan ini masih belum dikeluarkan untuk menyokong versi 0.12, walaupun ia telah dikeluarkan selama 3 bulan.
Sudah tiba masanya untuk melupakan...
- Menyahpepijat
- Alat pemfaktoran semula.
- Penyiapan automatik.
- Mengesan ralat semasa penyusunan.
Ia lucu, tetapi ini juga meningkatkan masa pembangunan dan meningkatkan bilangan ralat yang tidak dapat dielakkan berlaku.
Perkara yang paling teruk ialah kita terpaksa berfikir bukan tentang cara mereka bentuk, menyusun fail ke dalam folder, mengurai, menjadikan kod itu boleh diselenggara, boleh dibaca, dan sebagainya, tetapi tentang bagaimana saya boleh menulis arahan ini dengan betul, kerana saya entah bagaimana menulisnya dengan salah .
Sebagai seorang pemula, anda cuba mempelajari terraform, dan IDE tidak membantu anda sama sekali. Apabila ada dokumentasi, masuk dan lihat. Tetapi jika anda memasuki bahasa pengaturcaraan baharu, IDE akan memberitahu anda bahawa terdapat jenis sedemikian, tetapi tidak ada perkara sedemikian. Sekurang-kurangnya pada tahap int atau rentetan. Ini selalunya berguna.
Bagaimana dengan ujian?
Anda bertanya: "Bagaimana dengan ujian, tuan-tuan pengaturcara?" Lelaki yang serius menguji segala-galanya pada pengeluaran, dan ia sukar. Berikut ialah contoh ujian unit untuk modul terraform daripada tapak web .
Mereka mempunyai dokumentasi yang baik. Saya sentiasa menyukai Microsoft kerana pendekatannya terhadap dokumentasi dan latihan. Tetapi anda tidak perlu menjadi Uncle Bob untuk memahami bahawa ini bukan kod yang sempurna. Perhatikan pengesahan di sebelah kanan.
Masalah dengan ujian unit ialah anda dan saya boleh menyemak ketepatan output Json. Saya melemparkan 5 parameter dan diberi alas kaki Json dengan 2000 baris. Saya boleh menganalisis perkara yang berlaku di sini, mengesahkan keputusan ujian...
Sukar untuk menghuraikan Json dalam Go. Dan anda perlu menulis dalam Go, kerana terraform dalam Go ialah amalan yang baik untuk menguji dalam bahasa yang anda tulis. Organisasi kod itu sendiri sangat lemah. Pada masa yang sama, ini adalah perpustakaan terbaik untuk ujian.
Microsoft sendiri menulis modulnya, mengujinya dengan cara ini. Sudah tentu ia adalah Sumber Terbuka. Semua yang saya cakap tentang awak boleh datang dan betulkan. Saya boleh duduk dan membetulkan semuanya dalam seminggu, pemalam kod VS sumber terbuka, terraform, membuat pemalam untuk penunggang. Mungkin menulis beberapa penganalisis, menambah linter, menyumbang perpustakaan untuk ujian. Saya boleh buat semuanya. Tetapi bukan itu yang sepatutnya saya lakukan.
Amalan terbaik Infrastruktur sebagai kod
Jom teruskan. Jika tiada ujian dalam IaC, IDE dan penalaan adalah buruk, maka sekurang-kurangnya perlu ada amalan terbaik. Saya baru sahaja pergi ke Analitis Google dan membandingkan dua pertanyaan carian: Amalan terbaik Terraform dan amalan terbaik c#.
Apa yang kita nampak? Statistik kejam tidak memihak kepada kami. Jumlah bahan adalah sama. Dalam pembangunan C#, kami hanya dibanjiri bahan, kami mempunyai amalan terbaik, terdapat buku yang ditulis oleh pakar, dan juga buku yang ditulis pada buku oleh pakar lain yang mengkritik buku tersebut. Lautan dokumentasi rasmi, artikel, kursus latihan, dan kini juga pembangunan sumber terbuka.
Bagi permintaan IaC: di sini anda cuba mengumpul maklumat sedikit demi sedikit daripada laporan muat tinggi atau HashiConf, daripada dokumentasi rasmi dan banyak isu pada Github. Bagaimana untuk mengedarkan modul ini secara umum, apa yang perlu dilakukan dengannya? Nampaknya ini masalah sebenarnya... Ada komuniti tuan-tuan, di mana untuk sebarang pertanyaan anda akan diberikan 10 komen di Github. Tetapi ia tidak betul-betul.
Malangnya, pada masa ini, pakar baru mula muncul. Terdapat terlalu sedikit daripada mereka setakat ini. Dan komuniti itu sendiri melepak di peringkat asas.
Di mana semua ini pergi dan apa yang perlu dilakukan
Anda boleh menggugurkan semuanya dan kembali ke C#, ke dunia penunggang. Tetapi tidak. Mengapa anda perlu bersusah payah melakukan ini jika anda tidak dapat mencari penyelesaian. Di bawah ini saya membentangkan kesimpulan subjektif saya. Anda boleh berhujah dengan saya dalam komen, ia akan menjadi menarik.
Secara peribadi, saya bertaruh pada beberapa perkara:
- Pembangunan di kawasan ini berlaku dengan sangat pantas. Berikut ialah jadual permintaan untuk DevOps.
Topik itu mungkin gembar-gembur, tetapi hakikat bahawa sfera itu berkembang memberi sedikit harapan.Jika sesuatu berkembang begitu cepat, maka orang pintar pasti akan muncul yang akan memberitahu anda apa yang perlu dilakukan dan apa yang tidak boleh dilakukan. Peningkatan populariti membawa kepada fakta bahawa mungkin seseorang akan mempunyai masa untuk akhirnya menambah pemalam ke jsonnet untuk vscode, yang akan membolehkan anda meneruskan untuk melaksanakan fungsi itu, dan bukannya mencarinya melalui ctrl+shift+f. Apabila perkara berkembang, lebih banyak bahan muncul. Pengeluaran buku daripada Google tentang SRE adalah contoh terbaik untuk ini.
- Terdapat teknik dan amalan yang dibangunkan dalam pembangunan konvensional yang boleh kami gunakan dengan jayanya di sini. Ya, terdapat nuansa dengan ujian dan persekitaran yang heterogen, peralatan yang tidak mencukupi, tetapi sejumlah besar amalan telah terkumpul yang boleh berguna dan membantu.
Contoh remeh: kerjasama melalui pengaturcaraan pasangan. Ia banyak membantu untuk memikirkannya. Apabila anda mempunyai jiran berdekatan yang juga cuba memahami sesuatu, bersama-sama anda akan lebih memahami.
Memahami cara pemfaktoran semula dilakukan membantu melaksanakannya walaupun dalam situasi sedemikian. Iaitu, anda tidak boleh menukar semuanya sekaligus, tetapi menukar penamaan, kemudian menukar lokasi, kemudian anda boleh menyerlahkan beberapa bahagian, oh, tetapi tidak ada komen yang mencukupi di sini.
Kesimpulan
Walaupun pada hakikatnya penaakulan saya mungkin kelihatan pesimis, saya melihat masa depan dengan harapan dan sangat berharap segala-galanya akan berjaya untuk kami (dan anda).
Bahagian kedua artikel sedang disediakan seterusnya. Di dalamnya, saya akan bercakap tentang cara kami cuba menggunakan amalan pembangunan tangkas untuk meningkatkan proses pembelajaran kami dan bekerja dengan infrastruktur.
Sumber: www.habr.com