Pendekatan IaC (Infrastruktur sebagai Kode) tidak hanya terdiri dari kode yang disimpan dalam repositori, tetapi juga orang-orang dan proses yang mengelilingi kode ini. Apakah mungkin untuk menggunakan kembali pendekatan dari pengembangan perangkat lunak hingga pengelolaan dan deskripsi infrastruktur? Sebaiknya ingatlah gagasan ini saat Anda membaca artikel.

Versi Bahasa Inggris

Ini adalah transkrip saya pertunjukan pada DevopsConf 2019-05-28.

Slide dan video

• Versi Bahasa Inggris
• Rusia versi
• Uji coba 2019-04-24 SpbLUG
• Video(RU) dari DevopsConf 2019-05-28
• Video(RU) dari DINS DevOps MALAM 2019-06-20
• Slides

Infrastruktur sebagai sejarah pesta

Misalkan Anda datang ke sebuah proyek baru, dan mereka memberi tahu Anda: “kami sudah Infrastruktur sebagai Kode". Kenyataannya ternyata Infrastruktur sebagai sejarah pesta atau misalnya Dokumentasi sebagai sejarah bash. Ini adalah situasi yang sangat nyata, misalnya kasus serupa dijelaskan oleh Denis Lysenko dalam pidatonya Bagaimana mengganti seluruh infrastruktur dan mulai tidur nyenyak, dia menceritakan bagaimana mereka mendapatkan infrastruktur yang koheren untuk proyek tersebut dari sejarah bash.

Dengan sedikit keinginan, kita bisa mengatakan itu Infrastruktur sebagai sejarah pesta ini seperti kode:

1. reproduktifitas: Anda dapat mengambil riwayat bash, menjalankan perintah dari sana, dan Anda mungkin mendapatkan konfigurasi yang berfungsi sebagai output.
2. pembuatan versi: Anda tahu siapa yang masuk dan apa yang mereka lakukan, sekali lagi, ini bukanlah fakta bahwa ini akan membawa Anda ke konfigurasi keluaran yang berfungsi.
3. sejarah: kisah siapa melakukan apa. hanya saja Anda tidak akan bisa menggunakannya jika kehilangan server.

Apa yang harus dilakukan?

Infrastruktur sebagai Kode

Bahkan kasus aneh seperti Infrastruktur sebagai sejarah pesta Anda bisa menariknya ke telinga Infrastruktur sebagai Kode, tetapi ketika kita ingin melakukan sesuatu yang lebih rumit daripada server LAMP lama yang bagus, kita akan sampai pada kesimpulan bahwa kode ini perlu dimodifikasi, diubah, ditingkatkan. Selanjutnya kita ingin mempertimbangkan persamaan antara keduanya Infrastruktur sebagai Kode dan pengembangan perangkat lunak.

KERING.

Pada proyek pengembangan sistem penyimpanan, terdapat subtugas konfigurasikan SDS secara berkala: kami merilis rilis baru - rilis ini perlu diluncurkan untuk pengujian lebih lanjut. Tugasnya sangat sederhana:

• masuk di sini melalui ssh dan jalankan perintah.
• salin file di sana.
• perbaiki konfigurasi di sini.
• memulai layanan di sana
• ...
• LABA!

Untuk logika yang dijelaskan, bash sudah lebih dari cukup, terutama pada tahap awal proyek, ketika proyek baru saja dimulai. Ini tidak buruk jika Anda menggunakan bash, tetapi seiring berjalannya waktu ada permintaan untuk menerapkan sesuatu yang serupa, tetapi sedikit berbeda. Hal pertama yang terlintas dalam pikiran adalah copy-paste. Dan sekarang kita sudah memiliki dua skrip yang sangat mirip yang melakukan hal yang hampir sama. Seiring waktu, jumlah skrip bertambah, dan kami dihadapkan pada kenyataan bahwa ada logika bisnis tertentu untuk menerapkan instalasi yang perlu disinkronkan antara skrip yang berbeda, ini cukup rumit.

Ternyata ada praktek seperti D.R.Y. (Jangan Ulangi Diri Sendiri). Idenya adalah menggunakan kembali kode yang ada. Kedengarannya sederhana, tetapi kami tidak langsung membahasnya. Dalam kasus kami, itu adalah ide yang dangkal: memisahkan konfigurasi dari skrip. Itu. logika bisnis tentang bagaimana instalasi diterapkan secara terpisah, konfigurasi secara terpisah.

PADAT. untuk CFM

Seiring waktu proyek ini berkembang dan kelanjutan alami adalah munculnya Ansible. Alasan utama kemunculannya adalah karena ada keahlian dalam tim dan bash tidak dirancang untuk logika yang rumit. Ansible juga mulai mengandung logika yang kompleks. Untuk mencegah logika kompleks berubah menjadi kekacauan, terdapat prinsip pengorganisasian kode dalam pengembangan perangkat lunak PADAT. Juga, misalnya, Grigory Petrov dalam laporannya “Mengapa seorang spesialis TI membutuhkan merek pribadi” mengajukan pertanyaan bahwa seseorang dirancang sedemikian rupa sehingga lebih mudah baginya untuk beroperasi dengan beberapa entitas sosial, dalam pengembangan perangkat lunak ini adalah objek. Jika kita menggabungkan kedua ide ini dan terus mengembangkannya, kita akan menyadari bahwa kita juga dapat memanfaatkannya PADAT. untuk mempermudah pemeliharaan dan modifikasi logika ini di masa mendatang.

Prinsip Tanggung Jawab Tunggal

Setiap kelas hanya melakukan satu tugas.

Tidak perlu mencampur kode dan membuat monster spageti ilahi yang monolitik. Infrastrukturnya harus terdiri dari batu bata sederhana. Ternyata jika Anda membagi buku pedoman Ansible menjadi bagian-bagian kecil, membaca peran Ansible, maka peran tersebut akan lebih mudah dipertahankan.

Prinsip Terbuka Tertutup

Prinsip terbuka/tertutup.

• Terbuka untuk ekstensi: berarti perilaku suatu entitas dapat diperluas dengan membuat tipe entitas baru.
• Tertutup untuk diubah: Sebagai akibat dari perluasan perilaku suatu entitas, tidak ada perubahan yang dilakukan pada kode yang menggunakan entitas tersebut.

Awalnya, kami menerapkan infrastruktur pengujian pada mesin virtual, namun karena fakta bahwa logika bisnis penerapannya terpisah dari implementasi, kami menambahkan peluncuran ke baremetall tanpa masalah apa pun.

Prinsip Substitusi Liskov

Prinsip substitusi Barbara Liskov. objek dalam suatu program harus dapat diganti dengan instance subtipenya tanpa mengubah eksekusi program yang benar

Jika dilihat lebih luas, itu bukanlah fitur proyek tertentu yang bisa diterapkan di sana PADAT., umumnya tentang CFM, misalnya, pada proyek lain perlu untuk menyebarkan aplikasi Java dalam kotak di atas berbagai Java, server aplikasi, database, OS, dll. Dengan menggunakan contoh ini, saya akan mempertimbangkan prinsip-prinsip lebih lanjut PADAT.

Dalam kasus kami, ada kesepakatan dalam tim infrastruktur bahwa jika kami telah menginstal peran imbjava atau Oraclejava, maka kami memiliki biner Java yang dapat dieksekusi. Hal ini diperlukan karena Peran upstream bergantung pada perilaku ini; mereka mengharapkan java. Pada saat yang sama, hal ini memungkinkan kita untuk mengganti satu implementasi/versi Java dengan yang lain tanpa mengubah logika penerapan aplikasi.

Masalahnya di sini terletak pada kenyataan bahwa hal ini tidak mungkin diterapkan di Ansible, akibatnya muncul beberapa kesepakatan dalam tim.

Prinsip Pemisahan Antarmuka

Prinsip pemisahan antarmuka: “Banyak antarmuka khusus klien lebih baik daripada satu antarmuka tujuan umum.

Awalnya, kami mencoba memasukkan semua variabilitas penerapan aplikasi ke dalam satu pedoman yang mungkin, tetapi sulit untuk mendukungnya, dan pendekatannya ketika kami memiliki antarmuka eksternal yang ditentukan (klien mengharapkan port 443), maka infrastruktur dapat dirakit dari individu batu bata untuk implementasi tertentu.

Prinsip Inversi Ketergantungan

Prinsip inversi ketergantungan. Modul di tingkat yang lebih tinggi tidak boleh bergantung pada modul di tingkat yang lebih rendah. Kedua jenis modul harus bergantung pada abstraksi. Abstraksi tidak boleh bergantung pada detail. Detailnya harus bergantung pada abstraksi.

Di sini contohnya akan didasarkan pada antipattern.

1. Salah satu pelanggan memiliki cloud pribadi.
2. Kami memesan mesin virtual di dalam cloud.
3. Namun karena sifat cloud, penerapan aplikasi terikat pada hypervisor tempat VM berada.

Itu. Logika penerapan aplikasi tingkat tinggi mengalir dengan ketergantungan ke tingkat hypervisor yang lebih rendah, dan ini berarti masalah saat menggunakan kembali logika ini. Jangan lakukan dengan cara ini.

Interaksi

Infrastruktur sebagai kode tidak hanya tentang kode, tetapi juga tentang hubungan antara kode dan manusia, tentang interaksi antar pengembang infrastruktur.

Faktor bus

Anggaplah Anda memiliki Vasya di proyek Anda. Vasya tahu segalanya tentang infrastruktur Anda, apa jadinya jika Vasya tiba-tiba menghilang? Ini situasi yang sangat nyata, karena dia bisa saja tertabrak bus. Terkadang itu terjadi. Jika hal ini terjadi dan pengetahuan tentang kode, strukturnya, cara kerjanya, tampilan dan kata sandi tidak didistribusikan di antara tim, Anda mungkin menghadapi sejumlah situasi yang tidak menyenangkan. Untuk meminimalkan risiko ini dan mendistribusikan pengetahuan dalam tim, Anda dapat menggunakan berbagai pendekatan

Pengembangan Pasangan

Ini tidak seperti sebagai lelucon, bahwa admin minum bir, mengubah kata sandi, dan analog dari pemrograman berpasangan. Itu. dua insinyur duduk di depan satu komputer, satu keyboard, dan mulai menyiapkan infrastruktur Anda bersama: menyiapkan server, menulis peran yang Mungkin, dll. Kedengarannya bagus, tapi itu tidak berhasil bagi kami. Namun kasus khusus dari praktik ini berhasil. Seorang karyawan baru datang, mentornya mengambil tugas nyata bersamanya, bekerja dan mentransfer pengetahuan.

Kasus khusus lainnya adalah panggilan insiden. Selama suatu masalah, sekelompok orang yang bertugas dan mereka yang terlibat berkumpul, seorang pemimpin ditunjuk, yang berbagi layarnya dan menyuarakan alur pemikiran. Peserta lain mengikuti pemikiran pemimpin, memata-matai trik dari konsol, memeriksa apakah mereka tidak melewatkan satu baris pun di log, dan mempelajari hal-hal baru tentang sistem. Pendekatan ini lebih sering berhasil.

Review Kode

Secara subyektif, menyebarkan pengetahuan tentang infrastruktur dan cara kerjanya akan lebih efektif menggunakan tinjauan kode:

• Infrastruktur dijelaskan oleh kode di repositori.
• Perubahan terjadi di cabang terpisah.
• Selama permintaan penggabungan, Anda dapat melihat delta perubahan pada infrastruktur.

Yang menarik di sini adalah para reviewer dipilih satu per satu, sesuai jadwal, yaitu. dengan tingkat kemungkinan tertentu Anda akan memasuki infrastruktur baru.

Gaya Kode

Seiring berjalannya waktu, pertengkaran mulai muncul saat peninjauan, karena... pengulas memiliki gayanya sendiri dan rotasi pengulas menumpuknya dengan gaya berbeda: 2 spasi atau 4, camelCase atau ular_case. Hal ini tidak dapat segera dilaksanakan.

• Ide pertama adalah merekomendasikan penggunaan linter, karena semua orang adalah insinyur, semua orang pintar. Tapi editor yang berbeda, OS, tidak nyaman
• Ini berkembang menjadi bot yang menulis ke slack untuk setiap penerapan yang bermasalah dan melampirkan keluaran linter. Namun dalam kebanyakan kasus, ada hal-hal yang lebih penting yang harus dilakukan dan kodenya tetap tidak diperbaiki.

Ahli Pembangunan Ramah Lingkungan

Waktu berlalu, dan kami sampai pada kesimpulan bahwa komitmen yang tidak lulus tes tertentu tidak dapat diizinkan masuk ke master. Voila! Kami menemukan Green Build Master, yang telah lama dipraktikkan dalam pengembangan perangkat lunak:

• Pengembangan sedang berlangsung di cabang terpisah.
• Pengujian sedang berjalan di thread ini.
• Jika pengujian gagal, kode tidak akan masuk ke master.

Membuat keputusan ini sangat menyakitkan, karena... menimbulkan banyak kontroversi, tapi itu sepadan, karena... Tinjauan mulai menerima permintaan merger tanpa perbedaan gaya, dan seiring waktu jumlah area masalah mulai berkurang.

Pengujian IaC

Selain pemeriksaan gaya, Anda dapat menggunakan hal lain, misalnya, untuk memeriksa apakah infrastruktur Anda benar-benar dapat diterapkan. Atau periksa apakah perubahan infrastruktur tidak akan menyebabkan hilangnya uang. Mengapa hal ini mungkin diperlukan? Pertanyaannya rumit dan filosofis, lebih baik menjawab dengan cerita bahwa entah bagaimana ada penskala otomatis di Powershell yang tidak memeriksa kondisi batas => lebih banyak VM yang dibuat daripada yang diperlukan => klien menghabiskan lebih banyak uang daripada yang direncanakan. Ini sangat tidak menyenangkan, tetapi sangat mungkin untuk mengetahui kesalahan ini pada tahap awal.

Mungkin ada yang bertanya, mengapa membuat infrastruktur yang kompleks menjadi semakin kompleks? Pengujian infrastruktur, seperti halnya pengujian kode, bukan tentang penyederhanaan, namun tentang mengetahui cara kerja infrastruktur Anda.

Piramida Pengujian IaC

Pengujian IaC: Analisis Statis

Jika Anda menerapkan seluruh infrastruktur sekaligus dan memeriksa apakah infrastruktur tersebut berfungsi, Anda mungkin mendapati bahwa hal tersebut memerlukan banyak waktu dan memerlukan banyak waktu. Oleh karena itu, basisnya haruslah sesuatu yang bekerja dengan cepat, jumlahnya banyak, dan mencakup banyak tempat yang primitif.

Bash itu rumit

Mari kita lihat contoh sepele. pilih semua file di direktori saat ini dan salin ke lokasi lain. Hal pertama yang terlintas dalam pikiran:

for i in * ; do 
    cp $i /some/path/$i.bak
done

Bagaimana jika ada spasi pada nama file? Baiklah, kami pintar, kami tahu cara menggunakan tanda kutip:

for i in * ; do cp "$i" "/some/path/$i.bak" ; done

Bagus sekali? TIDAK! Bagaimana jika tidak ada apa pun di direktori, mis. globbing tidak akan berhasil.

find . -type f -exec mv -v {} dst/{}.bak ;

Sudah selesai dengan baik sekarang? Tidak... Lupa apa isi nama filenya n.

touch x
mv x  "$(printf "foonbar")"
find . -type f -print0 | xargs -0 mv -t /path/to/target-dir

Alat analisis statis

Masalah pada langkah sebelumnya bisa saja terjadi ketika kita lupa tanda petiknya, untuk itu ada banyak solusi yang bersifat alami Periksa cangkang, secara umum ada banyak sekali, dan kemungkinan besar Anda dapat menemukan linter untuk tumpukan Anda di bawah IDE Anda.

Bahasa
Alat Bantu

menampar
Periksa cangkang

Rubi
Rubocop

ular sanca
pylint

ansible
Serat yang Mungkin

Pengujian IaC: Tes Unit

Seperti yang kita lihat dari contoh sebelumnya, linter tidak mahakuasa dan tidak dapat menunjukkan semua area masalahnya. Selanjutnya, dengan analogi pengujian dalam pengembangan perangkat lunak, kita dapat mengingat pengujian unit. Yang langsung terlintas dalam pikiran adalah shunt, juni, spesifikasi, uji coba. Tapi apa yang harus dilakukan dengan ansible, chef, saltstack, dan lainnya yang sejenis?

Pada awalnya kami berbicara tentang PADAT. dan bahwa infrastruktur kita harus terdiri dari batu bata kecil. Waktunya telah tiba.

1. Infrastruktur dibagi menjadi batu bata kecil, misalnya peran yang mungkin.
2. Beberapa jenis lingkungan diterapkan, baik itu buruh pelabuhan atau VM.
3. Kami menerapkan peran Ansible kami pada lingkungan pengujian ini.
4. Kami memeriksa apakah semuanya berfungsi seperti yang kami harapkan (kami menjalankan pengujian).
5. Kita putuskan oke atau tidak oke.

Pengujian IaC: Alat Pengujian Unit

Pertanyaannya, apa itu tes CFM? Anda cukup menjalankan skrip, atau menggunakan solusi siap pakai untuk ini:

CFM
Alat Bantu

Mungkin
Tesinfra

Koki
Inspeksi

Koki
Spesifikasi server

tumpukan garam
Goss

Contoh untuk testinfra, memeriksa pengguna itu test1, test2 ada dan berada dalam kelompok sshusers:

def test_default_users(host):
    users = ['test1', 'test2' ]
    for login in users:
        assert host.user(login).exists
        assert 'sshusers' in host.user(login).groups

Apa yang harus dipilih? Pertanyaannya rumit dan ambigu, berikut contoh perubahan proyek di github 2018-2019:

Kerangka Pengujian IaC

Timbul pertanyaan: bagaimana cara menggabungkan semuanya dan meluncurkannya? Bisa ambillah dan lakukan sendiri jika jumlah insinyur mencukupi. Atau Anda dapat mengambil solusi yang sudah jadi, meskipun jumlahnya tidak banyak:

CFM
Alat Bantu

Mungkin
Molekul

Koki
Dapur Uji

Terraform
terberat

Contoh perubahan project di github tahun 2018-2019:

Molekul vs. dapur uji

Awalnya kami mencoba menggunakan testkitchen:

1. Buat VM secara paralel.
2. Terapkan peran yang mungkin.
3. Jalankan inspeksi.

Untuk peran 25-35, waktu yang dibutuhkan adalah 40-70 menit, dan itu adalah waktu yang lama.

Langkah selanjutnya adalah transisi ke jenkins/docker/ansible/molekul. Secara ideologis semuanya sama

1. Buku pedoman serat.
2. Sejajarkan peran.
3. Luncurkan wadah
4. Terapkan peran yang mungkin.
5. Jalankan testinfra.
6. Periksa idempotensi.

Linting untuk 40 peran dan tes untuk selusin mulai memakan waktu sekitar 15 menit.

Apa yang harus dipilih bergantung pada banyak faktor, seperti tumpukan yang digunakan, keahlian dalam tim, dll. di sini setiap orang memutuskan sendiri bagaimana menutup pertanyaan pengujian Unit

Pengujian IaC: Tes Integrasi

Langkah selanjutnya dalam piramida pengujian infrastruktur adalah pengujian integrasi. Mereka mirip dengan tes Unit:

1. Infrastruktur dibagi menjadi beberapa batu bata kecil, misalnya peran yang mungkin.
2. Beberapa jenis lingkungan diterapkan, baik itu buruh pelabuhan atau VM.
3. Untuk lingkungan pengujian ini berlaku banyak Peran yang mungkin.
4. Kami memeriksa apakah semuanya berfungsi seperti yang kami harapkan (kami menjalankan pengujian).
5. Kita putuskan oke atau tidak oke.

Secara kasar, kami tidak memeriksa kinerja elemen individual sistem seperti dalam pengujian unit, kami memeriksa bagaimana server dikonfigurasi secara keseluruhan.

Pengujian IaC: Pengujian Ujung ke Ujung

Di puncak piramida kita disambut oleh tes End to End. Itu. Kami tidak memeriksa kinerja server terpisah, skrip terpisah, atau bagian terpisah dari infrastruktur kami. Kami memeriksa bahwa banyak server yang terhubung bersama, infrastruktur kami berfungsi sesuai harapan. Sayangnya, saya belum pernah melihat solusi kotak yang siap pakai, mungkin karena... Infrastrukturnya sering kali unik dan sulit untuk dibuat template serta dibuat kerangka kerja untuk pengujian. Akibatnya, setiap orang menciptakan solusinya sendiri. Ada permintaan, tapi tidak ada jawaban. Oleh karena itu, saya akan memberi tahu Anda apa yang ada untuk mendorong orang lain agar berpikiran sehat atau menggosok hidung saya dengan kenyataan bahwa segala sesuatu telah ditemukan jauh sebelum kita.

Sebuah proyek dengan sejarah yang kaya. Ini digunakan dalam organisasi besar dan mungkin Anda masing-masing secara tidak langsung pernah menggunakannya. Aplikasi ini mendukung banyak database, integrasi, dll. Mengetahui seperti apa infrastrukturnya adalah banyak file yang dibuat oleh buruh pelabuhan, dan mengetahui pengujian mana yang harus dijalankan di lingkungan mana adalah Jenkins.

Skema ini berjalan cukup lama, hingga dalam kerangka tersebut penelitian kami belum mencoba mentransfer ini ke Openshift. Kontainernya tetap sama, tetapi lingkungan peluncurannya telah berubah (halo D.R.Y. lagi).

Ide penelitiannya melangkah lebih jauh, dan dalam openshift mereka menemukan sesuatu seperti APB (Ansible Playbook Bundle), yang memungkinkan Anda mengemas pengetahuan tentang cara menerapkan infrastruktur ke dalam sebuah container. Itu. terdapat pengetahuan yang dapat diulang dan diuji mengenai cara menerapkan infrastruktur.

Semua ini terdengar bagus sampai kami menemukan infrastruktur yang heterogen: kami memerlukan Windows untuk pengujian. Hasilnya, pengetahuan tentang apa, di mana, bagaimana menerapkan, dan menguji ada di jenkins.

Kesimpulan

Infrastruktur sebagai Kode

• Kode di repositori.
• Interaksi Manusia.
• Pengujian infrastruktur.

link

• Versi Bahasa Inggris
• Posting silang dari blog pribadi
• Uji coba 2019-04-24 SpbLUG
• Video(RU) dari DevopsConf 2019-05-28
• Video(RU) dari DINS DevOps MALAM 2019-06-20
• Pembelajaran dari Menulis Lebih dari 300,000 Baris Kode Infrastruktur & versi teks
• Mengintegrasikan Infrastruktur sebagai Kode ke dalam Saluran Pengiriman Berkelanjutan
• Menguji infrastruktur sebagai kode
• Pengembangan dan pemeliharaan peran Ansible yang efektif
• Kemungkinan bukan bash!

Sumber: www.habr.com