Satu pendekatan IaC (Infrastruktur sebagai Kod) bukan sahaja terdiri daripada kod yang disimpan dalam repositori, tetapi juga orang dan proses yang mengelilingi kod ini. Adakah mungkin untuk menggunakan semula pendekatan daripada pembangunan perisian kepada pengurusan dan penerangan infrastruktur? Adalah idea yang baik untuk menyimpan idea ini semasa anda membaca artikel.

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

Slaid dan video

Versi Bahasa Inggeris
Versi Rusia
Larian kering 2019-04-24 SpbLUG
Video(RU) daripada DevopsConf 2019-05-28
Video(RU) daripada DINS DevOps PETANG 2019-06-20
Slaid

Infrastruktur sebagai sejarah bash

Katakan anda datang ke projek baharu, dan mereka memberitahu anda: “kami ada Infrastruktur sebagai Kod". Pada hakikatnya ternyata Infrastruktur sebagai sejarah bash atau sebagai contoh Dokumentasi sebagai sejarah bash. Ini adalah situasi yang sangat nyata, sebagai contoh, kes serupa telah diterangkan oleh Denis Lysenko dalam ucapan Bagaimana untuk menggantikan keseluruhan infrastruktur dan mula tidur dengan nyenyak, dia memberitahu bagaimana mereka mendapat infrastruktur yang koheren untuk projek itu daripada sejarah bash.

Dengan sedikit keinginan, kita boleh mengatakannya Infrastruktur sebagai sejarah bash ini seperti kod:

kebolehulangan: Anda boleh mengambil sejarah bash, jalankan arahan dari sana, dan anda mungkin, dengan cara itu, mendapatkan konfigurasi yang berfungsi sebagai output.
pembuatan versi: anda tahu siapa yang masuk dan apa yang mereka lakukan, sekali lagi, ini bukan fakta bahawa ini akan membawa anda ke konfigurasi yang berfungsi di pintu keluar.
Sejarah: kisah siapa buat apa. cuma anda tidak akan dapat menggunakannya jika anda kehilangan pelayan.

Apa yang perlu dilakukan?

Infrastruktur sebagai Kod

Malah kes pelik seperti Infrastruktur sebagai sejarah bash anda boleh menariknya dengan telinga Infrastruktur sebagai Kod, tetapi apabila kami ingin melakukan sesuatu yang lebih rumit daripada pelayan LAMP lama yang baik, kami akan membuat kesimpulan bahawa kod ini perlu diubah suai, diubah, diperbaiki. Seterusnya kami ingin mempertimbangkan persamaan antara Infrastruktur sebagai Kod dan pembangunan perisian.

D.R.Y.

Pada projek pembangunan sistem storan, terdapat subtugas mengkonfigurasi SDS secara berkala: kami mengeluarkan keluaran baharu - ia perlu dilancarkan untuk ujian selanjutnya. Tugasnya sangat mudah:

log masuk di sini melalui ssh dan laksanakan arahan.
salin fail di sana.
betulkan konfigurasi di sini.
mulakan perkhidmatan di sana
...
KEUNTUNGAN!

Untuk logik yang diterangkan, bash adalah lebih daripada mencukupi, terutamanya pada peringkat awal projek, apabila ia baru bermula. ini tidak salah anda menggunakan bash, tetapi dari masa ke masa terdapat permintaan untuk menggunakan sesuatu yang serupa, tetapi sedikit berbeza. Perkara pertama yang terlintas di fikiran ialah copy-paste. Dan kini kami sudah mempunyai dua skrip yang hampir sama yang melakukan perkara yang hampir sama. Dari masa ke masa, bilangan skrip bertambah, dan kami berhadapan dengan hakikat bahawa terdapat logik perniagaan tertentu untuk menggunakan pemasangan yang perlu disegerakkan antara skrip yang berbeza, ini agak rumit.

Ternyata ada amalan seperti D.R.Y. (Jangan Ulangi Sendiri). Ideanya adalah untuk menggunakan semula kod sedia ada. Bunyinya mudah, tetapi kami tidak melakukannya dengan segera. Dalam kes kami, ia adalah idea cetek: untuk memisahkan konfigurasi daripada skrip. Itu. logik perniagaan tentang cara pemasangan digunakan secara berasingan, konfigurasi secara berasingan.

S.O.L.I.D. untuk CFM

Lama kelamaan projek itu berkembang dan kesinambungan semula jadi ialah kemunculan Ansible. Sebab utama penampilannya ialah terdapat kepakaran dalam pasukan dan bash itu tidak direka untuk logik yang kompleks. Ansible juga mula mengandungi logik yang kompleks. Untuk mengelakkan logik kompleks daripada bertukar menjadi huru-hara, terdapat prinsip untuk mengatur kod dalam pembangunan perisian S.O.L.I.D. Juga, sebagai contoh, Grigory Petrov dalam laporannya "Mengapa pakar IT memerlukan jenama peribadi" menimbulkan persoalan bahawa seseorang itu direka sedemikian rupa sehingga lebih mudah baginya untuk beroperasi dengan beberapa entiti sosial, dalam pembangunan perisian ini. adalah objek. Jika kita menggabungkan kedua-dua idea ini dan terus mengembangkannya, kita akan perasan bahawa kita juga boleh menggunakannya S.O.L.I.D. untuk memudahkan pengekalan dan pengubahsuaian logik ini pada masa hadapan.

Prinsip Tanggungjawab Tunggal

Setiap kelas menjalankan satu tugas sahaja.

Tidak perlu mencampur kod dan membuat raksasa spageti ketuhanan monolitik. Infrastruktur harus terdiri daripada bata mudah. Ternyata jika anda membahagikan buku permainan Ansible kepada kepingan kecil, baca peranan Ansible, maka ia lebih mudah untuk dikekalkan.

Prinsip Tertutup Terbuka

Prinsip terbuka/tertutup.

Terbuka kepada sambungan: bermakna gelagat entiti boleh dilanjutkan dengan mencipta jenis entiti baharu.
Ditutup kepada perubahan: Akibat melanjutkan gelagat entiti, tiada perubahan harus dibuat pada kod yang menggunakan entiti tersebut.

Pada mulanya, kami menggunakan infrastruktur ujian pada mesin maya, tetapi disebabkan oleh fakta bahawa logik penggunaan perniagaan adalah berasingan daripada pelaksanaan, kami menambah pelancaran ke baremetall tanpa sebarang masalah.

Prinsip Penggantian Liskov

Prinsip penggantian Barbara Liskov. objek dalam program mesti boleh digantikan dengan contoh subjenisnya tanpa mengubah pelaksanaan program yang betul

Jika anda melihatnya secara lebih luas, ia bukanlah ciri mana-mana projek tertentu yang boleh digunakan di sana S.O.L.I.D., ia secara amnya mengenai CFM, sebagai contoh, pada projek lain adalah perlu untuk menggunakan aplikasi Java berkotak di atas pelbagai Java, pelayan aplikasi, pangkalan data, OS, dll. Menggunakan contoh ini, saya akan mempertimbangkan prinsip selanjutnya S.O.L.I.D.

Dalam kes kami, terdapat perjanjian dalam pasukan infrastruktur bahawa jika kami telah memasang peranan imbjava atau oraclejava, maka kami mempunyai java binary executable. Ini perlu kerana Peranan huluan bergantung pada tingkah laku ini; mereka mengharapkan java. Pada masa yang sama, ini membolehkan kami menggantikan satu pelaksanaan/versi java dengan yang lain tanpa mengubah logik penggunaan aplikasi.

Masalahnya di sini terletak pada hakikat bahawa adalah mustahil untuk melaksanakannya dalam Ansible, akibatnya beberapa perjanjian muncul dalam pasukan.

Prinsip Pengasingan Antara Muka

Prinsip pemisahan antara muka: "Banyak antara muka khusus pelanggan adalah lebih baik daripada satu antara muka tujuan umum.

Pada mulanya, kami cuba meletakkan semua kebolehubahan penggunaan aplikasi ke dalam satu buku main Ansible, tetapi sukar untuk disokong, dan pendekatan apabila kami mempunyai antara muka luaran yang ditentukan (pelanggan menjangkakan port 443), maka infrastruktur boleh dipasang daripada individu. batu bata untuk pelaksanaan tertentu.

Prinsip Inversi Ketergantungan

Prinsip penyongsangan kebergantungan. Modul pada tahap yang lebih tinggi seharusnya tidak bergantung pada modul pada tahap yang lebih rendah. Kedua-dua jenis modul mesti bergantung pada abstraksi. Abstraksi tidak boleh bergantung pada butiran. Butiran mesti bergantung pada abstraksi.

Di sini contoh akan berdasarkan antipattern.

Salah seorang pelanggan mempunyai awan peribadi.
Kami memesan mesin maya di dalam awan.
Tetapi disebabkan oleh sifat awan, penggunaan aplikasi terikat dengan hipervisor yang digunakan VM.

Itu. Logik penggunaan aplikasi peringkat tinggi mengalir dengan kebergantungan ke tahap hipervisor yang lebih rendah, dan ini bermakna masalah apabila menggunakan semula logik ini. Jangan lakukan dengan cara ini.

Interaksi

Infrastruktur sebagai kod bukan sahaja mengenai kod, tetapi juga tentang hubungan antara kod dan orang, tentang interaksi antara pemaju infrastruktur.

Faktor bas

Mari kita anggap bahawa anda mempunyai Vasya pada projek anda. Vasya tahu segala-galanya tentang infrastruktur anda, apa yang akan berlaku jika Vasya tiba-tiba hilang? Ini adalah situasi yang sangat nyata, kerana dia boleh dilanggar bas. Kadang-kadang ia berlaku. Jika ini berlaku dan pengetahuan tentang kod, strukturnya, cara ia berfungsi, penampilan dan kata laluan tidak diedarkan di kalangan pasukan, maka anda mungkin menghadapi beberapa situasi yang tidak menyenangkan. Untuk meminimumkan risiko ini dan mengedarkan pengetahuan dalam pasukan, anda boleh menggunakan pelbagai pendekatan

Memasang Pasangan

Ia tidak seperti sebagai gurauan, bahawa pentadbir minum bir, menukar kata laluan dan analog pengaturcaraan pasangan. Itu. dua jurutera duduk di satu komputer, satu papan kekunci dan mula menyediakan infrastruktur anda bersama-sama: menyediakan pelayan, menulis peranan Ansible, dsb. Bunyinya bagus, tetapi ia tidak berkesan untuk kami. Tetapi kes khas amalan ini berjaya. Seorang pekerja baru datang, mentornya menjalankan tugas sebenar bersama-sama dengannya, bekerja dan memindahkan pengetahuan.

Satu lagi kes istimewa ialah panggilan insiden. Semasa masalah, sekumpulan mereka yang bertugas dan mereka yang terlibat berkumpul, seorang pemimpin dilantik, yang berkongsi skrinnya dan menyuarakan pemikiran. Peserta lain mengikuti pemikiran ketua, mengintip helah dari konsol, pastikan mereka tidak terlepas satu baris dalam log, dan mempelajari perkara baharu tentang sistem. Pendekatan ini bekerja lebih kerap daripada tidak.

Semakan Kod

Secara subjektif, adalah lebih berkesan untuk menyebarkan pengetahuan tentang infrastruktur dan cara ia berfungsi menggunakan semakan kod:

Infrastruktur diterangkan oleh kod dalam repositori.
Perubahan berlaku di cawangan yang berasingan.
Semasa permintaan gabungan, anda boleh melihat delta perubahan dalam infrastruktur.

Sorotan di sini ialah penyemak telah dipilih satu demi satu, mengikut jadual, i.e. dengan beberapa tahap kebarangkalian anda akan memanjat ke dalam infrastruktur baharu.

Gaya Kod

Lama kelamaan, pertengkaran mula muncul semasa tinjauan, kerana... pengulas mempunyai gaya mereka sendiri dan penggiliran pengulas menyusunnya dengan gaya yang berbeza: 2 ruang atau 4, sarung unta atau sarung ular. Ia tidak mungkin untuk melaksanakan ini dengan segera.

Idea pertama adalah mengesyorkan menggunakan linter, lagipun, semua orang adalah jurutera, semua orang bijak. Tetapi editor yang berbeza, OS, tidak mudah
Ini berkembang menjadi bot yang menulis untuk mengendur untuk setiap komitmen yang bermasalah dan melampirkan output linter. Tetapi dalam kebanyakan kes terdapat perkara yang lebih penting untuk dilakukan dan kod itu kekal tidak dibetulkan.

Guru Binaan Hijau

Masa berlalu, dan kami telah sampai pada kesimpulan bahawa komit yang tidak lulus ujian tertentu tidak boleh dibenarkan masuk ke dalam master. Voila! Kami mencipta Green Build Master, yang telah diamalkan dalam pembangunan perisian untuk masa yang lama:

Pembangunan sedang dijalankan di cawangan berasingan.
Ujian sedang dijalankan pada urutan ini.
Jika ujian gagal, kod itu tidak akan menjadi induk.

Membuat keputusan ini sangat menyakitkan, kerana... menimbulkan banyak kontroversi, tetapi ia berbaloi, kerana... Ulasan mula menerima permintaan untuk penggabungan tanpa perbezaan gaya, dan dari masa ke masa bilangan kawasan masalah mula berkurangan.

Ujian IaC

Selain semakan gaya, anda boleh menggunakan perkara lain, contohnya, untuk menyemak sama ada infrastruktur anda sebenarnya boleh digunakan. Atau semak bahawa perubahan dalam infrastruktur tidak akan membawa kepada kehilangan wang. Mengapa ini mungkin diperlukan? Persoalannya rumit dan berfalsafah, lebih baik untuk menjawab dengan cerita bahawa entah bagaimana terdapat penskala automatik pada Powershell yang tidak menyemak syarat sempadan => lebih banyak VM dicipta daripada yang diperlukan => pelanggan membelanjakan lebih banyak wang daripada yang dirancang. Ini tidak begitu menyenangkan, tetapi agak mungkin untuk menangkap ralat ini pada peringkat awal.

Seseorang mungkin bertanya, mengapa menjadikan infrastruktur yang kompleks menjadi lebih kompleks? Ujian untuk infrastruktur, sama seperti untuk kod, bukan tentang pemudahan, tetapi tentang mengetahui cara infrastruktur anda harus berfungsi.

Piramid Pengujian IaC

Ujian IaC: Analisis Statik

Jika anda menggunakan keseluruhan infrastruktur sekali gus dan menyemak sama ada ia berfungsi, anda mungkin mendapati ia memerlukan banyak masa dan memerlukan banyak masa. Oleh itu, asas mestilah sesuatu yang berfungsi dengan cepat, terdapat banyak, dan ia meliputi banyak tempat primitif.

Bash adalah rumit

Mari kita lihat contoh remeh. pilih semua fail dalam direktori semasa dan salin ke lokasi lain. Perkara pertama yang terlintas di fikiran:

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

Bagaimana jika terdapat ruang dalam nama fail? Baiklah, ok, kami bijak, kami tahu cara menggunakan petikan:

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

Bagus? Tidak! Bagaimana jika tiada apa-apa dalam direktori, i.e. globbing tidak akan berfungsi.

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

Syabas sekarang? Tidak... Lupa apa yang boleh ada dalam nama fail n.

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

Alat analisis statik

Masalah dari langkah sebelumnya boleh ditangkap apabila kita terlupa petikan, untuk ini terdapat banyak remedi secara semula jadi Shellcheck, secara amnya terdapat banyak daripadanya, dan kemungkinan besar anda boleh mencari linter untuk timbunan anda di bawah IDE anda.

Bahasa
Alat

menampar
Shellcheck

Ruby
RuboCop

ular sawa
Paip

ansible
Ansible Lint

Ujian IaC: Ujian Unit

Seperti yang kita lihat dari contoh sebelumnya, linters tidak mahakuasa dan tidak dapat menunjukkan semua kawasan masalah. Selanjutnya, dengan analogi dengan ujian dalam pembangunan perisian, kita boleh mengingati ujian unit. Apa yang segera terlintas di fikiran ialah sunit, junit, rspec, pytest. Tetapi apa yang perlu dilakukan dengan ansible, chef, saltstack dan lain-lain seperti mereka?

Pada awalnya kami berbincang S.O.L.I.D. dan bahawa infrastruktur kita harus terdiri daripada batu-bata kecil. Masa mereka telah tiba.

Infrastruktur dibahagikan kepada batu bata kecil, sebagai contoh, peranan Ansible.
Beberapa jenis persekitaran digunakan, sama ada docker atau VM.
Kami menggunakan peranan Ansible kami pada persekitaran ujian ini.
Kami menyemak sama ada semuanya berfungsi seperti yang kami jangkakan (kami menjalankan ujian).
Kita tentukan ok atau tidak ok.

Pengujian IaC: Alat Pengujian Unit

Soalan, apakah ujian untuk CFM? Anda hanya boleh menjalankan skrip, atau anda boleh menggunakan penyelesaian sedia untuk ini:

CFM
Alat

Ansible
Testinfra

Chef
Inspek

Chef
Spesifikasi pelayan

timbunan garam
Goss

Contoh untuk testinfra, menyemak pengguna itu test1, test2 wujud dan berada dalam satu kumpulan 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 perlu dipilih? Persoalannya rumit dan samar-samar, berikut ialah contoh perubahan dalam projek di github untuk 2018-2019:

Rangka kerja Ujian IaC

Persoalannya timbul: bagaimana untuk meletakkan semuanya bersama-sama dan melancarkannya? boleh ambil dan buat sendiri jika terdapat bilangan jurutera yang mencukupi. Atau anda boleh mengambil penyelesaian siap pakai, walaupun tidak banyak daripada mereka:

CFM
Alat

Ansible
Molekul

Chef
Dapur Uji

Terraform
Terratest

Contoh perubahan dalam projek di github untuk 2018-2019:

Molekul lwn. Dapur uji

Pada mulanya kita cuba guna testkitchen:

Buat VM secara selari.
Gunakan peranan Ansible.
Jalankan pemeriksaan.

Untuk 25-35 peranan ia bekerja 40-70 minit, yang panjang.

Langkah seterusnya ialah peralihan kepada jenkins/docker/ansible/molekul. Secara idiologi semuanya sama

Buku permainan lin.
Selaraskan peranan.
Pelancaran bekas
Gunakan peranan Ansible.
Jalankan testinfra.
Semak mati pucuk.

Linting untuk 40 peranan dan ujian untuk sedozen mula mengambil masa kira-kira 15 minit.

Perkara yang perlu dipilih bergantung pada banyak faktor, seperti susunan yang digunakan, kepakaran dalam pasukan, dsb. di sini semua orang memutuskan sendiri bagaimana untuk menutup soalan ujian Unit

Ujian IaC: Ujian Integrasi

Langkah seterusnya dalam piramid ujian infrastruktur ialah ujian integrasi. Mereka serupa dengan ujian Unit:

Infrastruktur dibahagikan kepada batu-bata kecil, contohnya peranan Ansible.
Beberapa jenis persekitaran digunakan, sama ada docker atau VM.
Untuk persekitaran ujian ini terpakai banyak Peranan yang boleh dipertanggungjawabkan.
Kami menyemak sama ada semuanya berfungsi seperti yang kami jangkakan (kami menjalankan ujian).
Kita tentukan ok atau tidak ok.

Secara kasarnya, kami tidak menyemak prestasi elemen individu sistem seperti dalam ujian unit, kami menyemak cara pelayan dikonfigurasikan secara keseluruhan.

Ujian IaC: Ujian Akhir ke Akhir

Di bahagian atas piramid kita disambut oleh ujian End to End. Itu. Kami tidak menyemak prestasi pelayan berasingan, skrip berasingan atau bata berasingan infrastruktur kami. Kami menyemak sama ada banyak pelayan disambungkan bersama, infrastruktur kami berfungsi seperti yang kami harapkan. Malangnya, saya tidak pernah melihat penyelesaian kotak siap pakai, mungkin kerana... Infrastruktur selalunya unik dan sukar untuk ditemplat dan mencipta rangka kerja untuk ujian. Akibatnya, setiap orang mencipta penyelesaian mereka sendiri. Ada permintaan, tetapi tiada jawapan. Oleh itu, saya akan memberitahu anda apa yang ada untuk mendorong orang lain untuk berfikir atau menggosok hidung saya dalam fakta bahawa segala-galanya telah dicipta lama dahulu sebelum kita.

Projek dengan sejarah yang kaya. Ia digunakan dalam organisasi besar dan mungkin setiap daripada anda secara tidak langsung telah bersilang dengannya. Aplikasi ini menyokong banyak pangkalan data, integrasi, dll. Mengetahui rupa infrastruktur itu ialah banyak fail karang docker, dan mengetahui ujian yang hendak dijalankan dalam persekitaran Jenkins.

Skim ini berfungsi untuk masa yang agak lama, sehingga dalam rangka kerja penyelidikan kami belum cuba memindahkan ini ke Openshift. Bekas tetap sama, tetapi persekitaran pelancaran telah berubah (hello D.R.Y. sekali lagi).

Idea penyelidikan pergi lebih jauh, dan dalam anjakan terbuka mereka menemui perkara seperti APB (Ansible Playbook Bundle), yang membolehkan anda membungkus pengetahuan tentang cara menggunakan infrastruktur ke dalam bekas. Itu. terdapat titik pengetahuan yang boleh diulang dan boleh diuji tentang cara menggunakan infrastruktur.

Semua ini terdengar baik sehingga kami menghadapi infrastruktur heterogen: kami memerlukan Windows untuk ujian. Akibatnya, pengetahuan tentang apa, di mana, cara untuk digunakan, dan ujian ada dalam jenkins.

Kesimpulan

Infrastruktur sebagai Kod adalah

Kod dalam repositori.
Interaksi manusia.
Ujian infrastruktur.

link

Sumber: www.habr.com

Apa yang Saya Belajar daripada Menguji 200 Baris Kod Infrastruktur