Pendekatan IaC (Infrastruktur minangka Kode) ora mung kalebu kode sing disimpen ing gudang, nanging uga wong lan proses sing ngubengi kode kasebut. Apa bisa nggunakake maneh pendekatan saka pangembangan piranti lunak menyang manajemen infrastruktur lan deskripsi? Iku apik kanggo mbudidaya gagasan iki nalika maca artikel.

Iki minangka transkrip sandi pagelaran ing DevopsConf 2019-05-28.

Slide lan video

Versi Inggris
versi Rusian
Dry run 2019-04-24 SpbLUG
Video(RU) saka DevopsConf 2019-05-28
Video(RU) saka DINS DevOps EVENING 2019-06-20
slides

Infrastruktur minangka sejarah bash

Upamane sampeyan teka ing proyek anyar, lan dheweke ngandhani: "Kita duwe Infrastruktur minangka Kode". Ing kasunyatan iku dadi metu Infrastruktur minangka sejarah bash utawa contone Dokumentasi minangka riwayat bash. Iki minangka kahanan sing nyata, contone, kasus sing padha diterangake dening Denis Lysenko ing pidato Carane ngganti kabeh infrastruktur lan miwiti turu kanthi tentrem, dheweke ngandhani carane entuk infrastruktur sing koheren kanggo proyek kasebut saka sejarah bash.

Kanthi sawetara kepinginan, kita bisa ngomong Infrastruktur minangka sejarah bash iki kaya kode:

reproducibility: Sampeyan bisa njupuk sajarah bash, mbukak printah saka ing kono, lan sampeyan bisa uga, dening cara, njaluk konfigurasi digunakake minangka output.
versi: sampeyan ngerti sing teka lan apa padha nindakake, maneh, iku ora kasunyatan sing iki bakal mimpin sampeyan menyang konfigurasi digunakake ing metu.
sejarah: critane sapa sing nindakake apa. mung sampeyan ora bakal bisa nggunakake yen ilang server.

Apa aku kudu?

Infrastruktur minangka Kode

Malah kasus aneh kaya Infrastruktur minangka sejarah bash sampeyan bisa narik kuping Infrastruktur minangka Kode, nanging nalika kita arep kanggo nindakake soko luwih rumit saka server LAMP lawas apik, kita bakal teka menyang kesimpulan sing kode iki kudu piye wae diowahi, diganti, apik. Sabanjure kita pengin nimbang paralel antarane Infrastruktur minangka Kode lan pangembangan piranti lunak.

GARING

Ing proyek pangembangan sistem panyimpenan, ana subtask periodik ngatur SDS: kita ngeculake release anyar - iku perlu kanggo mbalek metu kanggo testing luwih. Tugas kasebut gampang banget:

mlebu ing kene liwat ssh lan nglakokake perintah kasebut.
nyalin file ing kono.
mbenerake konfigurasi ing kene.
miwiti layanan ana
...
Bathi!

Kanggo logika sing diterangake, bash luwih saka cukup, utamane ing tahap awal proyek, nalika lagi diwiwiti. Iki ora salah yen sampeyan nggunakake bash, nanging liwat wektu ana panjalukan kanggo masang soko padha, nanging rada beda. Wangsulan: Bab ingkang pisanan teka ing atine iku copy-paste. Lan saiki kita wis duwe rong skrip sing meh padha. Swara wektu, nomer Tulisan tansaya akeh, lan kita padha ngadhepi karo kasunyatan sing ana logika bisnis tartamtu kanggo deploying instalasi sing kudu diselarasake antarane Tulisan beda, iki cukup rumit.

Pranyata ana laku kaya GARING (Aja Baleni Dhewe). Ide iki kanggo nggunakake maneh kode sing wis ana. Iku muni prasaja, nanging kita ora teka iki langsung. Ing kasus kita, iki minangka gagasan banal: misahake konfigurasi saka skrip. Sing. logika bisnis carane instalasi disebarake dhewe, configs dhewe.

SOLID kanggo CFM

Swara wektu project tansaya lan tutugan alam ana emergence saka Ansible. Alesan utama penampilane yaiku ana keahlian ing tim lan bash kasebut ora dirancang kanggo logika rumit. Ansible uga wiwit ngemot logika kompleks. Kanggo nyegah logika rumit dadi kekacauan, ana prinsip organisasi kode ing pangembangan piranti lunak SOLID Uga, contone, Grigory Petrov ing laporan "Napa spesialis IT mbutuhake merek pribadi" wungu pitakonan sing wong dirancang ing kuwi cara sing luwih gampang kanggo wong kanggo operate karo sawetara entitas sosial, ing pangembangan piranti lunak iki. yaiku obyek. Yen kita gabungke loro gagasan iki lan terus berkembang, kita bakal sok dong mirsani sing uga bisa digunakake SOLID kanggo nggawe luwih gampang kanggo njaga lan ngowahi logika iki ing mangsa.

Prinsip Tanggung Jawab Tunggal

Saben kelas mung nindakake siji tugas.

Ora perlu nyampur kode lan nggawe monster spageti gaib monolitik. Infrastruktur kasebut kudu kalebu bata sing prasaja. Pranyata yen sampeyan pamisah playbook Ansible dadi potongan cilik, maca peran Ansible, mula luwih gampang dijaga.

Prinsip Open Closed

Prinsip mbukak / ditutup.

Bukak kanggo ekstensi: tegese prilaku entitas bisa ditambah kanthi nggawe jinis entitas anyar.
Ditutup kanggo owah-owahan: Minangka asil ngluwihi prilaku entitas, ora ana owah-owahan ing kode sing nggunakake entitas kasebut.

Kaping pisanan, kita masang infrastruktur test ing mesin virtual, nanging amarga kasunyatan sing logika bisnis panyebaran kapisah saka implementasine, kita ditambahaké Rolling metu kanggo baremetall tanpa masalah.

Prinsip Substitusi Liskov

Prinsip substitusi Barbara Liskov. obyek ing program kudu diganti karo conto subtipe tanpa ngganti eksekusi program sing bener.

Yen sampeyan ndeleng luwih akeh, iku dudu fitur saka proyek tartamtu sing bisa ditrapake ing kana SOLID, iku umume babagan CFM, contone, ing project liyane perlu kanggo masang aplikasi Jawa kothak ing ndhuwur macem-macem Jawa, server aplikasi, database, OS, etc. Nggunakake conto iki, aku bakal nimbang prinsip luwih SOLID

Ing kasus kita, ana persetujuan ing tim infrastruktur yen kita wis nginstal peran imbjava utawa oraclejava, banjur kita duwe eksekusi biner java. Iki perlu amarga Peran hulu gumantung marang prilaku iki; Ing wektu sing padha, iki ngidini kita ngganti siji implementasi / versi java karo liyane tanpa ngganti logika panyebaran aplikasi.

Masalah ing kene dumunung ing kasunyatan manawa ora bisa dileksanakake ing Ansible, minangka asil saka sawetara persetujuan katon ing tim kasebut.

Prinsip Segregasi Antarmuka

Prinsip pamisahan antarmuka: "Akeh antarmuka khusus klien luwih apik tinimbang antarmuka tujuan umum.

Kaping pisanan, kita nyoba nglebokake kabeh variasi penyebaran aplikasi dadi siji playbook Ansible, nanging angel didhukung, lan pendekatan nalika kita duwe antarmuka eksternal sing ditemtokake (klien ngarepake port 443), banjur infrastruktur bisa dirakit saka individu. bata kanggo implementasine tartamtu.

Prinsip Inversi Dependensi

Prinsip inversi dependensi. Modul ing tingkat sing luwih dhuwur ngirim ora gumantung ing modul ing tingkat ngisor. Loro-lorone jinis modul kudu gumantung saka abstraksi. Abstraksi ngirim ora gumantung ing rincian. Rincian kudu gumantung saka abstraksi.

Ing kene conto bakal adhedhasar antipattern.

Salah sawijining pelanggan duwe awan pribadi.
We dhawuh mesin virtual nang awan.
Nanging amarga sifat awan, panyebaran aplikasi disambungake karo hypervisor VM sing aktif.

Sing. Logika penyebaran aplikasi tingkat dhuwur mili karo dependensi menyang tingkat hypervisor sing luwih murah, lan iki nyebabake masalah nalika nggunakake logika iki maneh. Aja kaya ngono.

interaksi

Infrastruktur minangka kode ora mung babagan kode, nanging uga babagan hubungan antarane kode lan wong, babagan interaksi antarane pangembang infrastruktur.

Faktor bus

Ayo nganggep yen sampeyan duwe Vasya ing proyek sampeyan. Vasya ngerti kabeh babagan infrastruktur sampeyan, apa sing bakal kelakon yen Vasya tiba-tiba ilang? Iki pancen nyata banget, amarga dheweke bisa ditabrak bis. Kadhangkala kedadeyan. Yen kedadeyan kasebut lan kawruh babagan kode, strukture, cara kerjane, penampilan lan sandhi ora disebarake ing antarane tim, mula sampeyan bisa nemokake sawetara kahanan sing ora nyenengake. Kanggo nyilikake risiko kasebut lan nyebarake kawruh ing tim, sampeyan bisa nggunakake macem-macem pendekatan

Pasangan Devopsing

Iku ora kaya minangka guyon, sing admin ngombe bir, ngganti tembung sandhi, lan analog saka program pasangan. Sing. loro engineers njagong mudhun ing komputer siji, siji keyboard lan miwiti nyiyapake infrastruktur bebarengan: nyetel server, nulis peran Ansible, etc. Iku muni apik, nanging ora bisa kanggo kita. Nanging kasus khusus saka praktik iki makarya. Pegawe anyar teka, mentor njupuk tugas nyata bebarengan karo wong, karya lan transfer kawruh.

Kasus khusus liyane yaiku telpon kedadeyan. Sajrone masalah, klompok sing tugas lan sing melu ngumpul, siji pimpinan diangkat, sing nuduhake layar lan voices Sepur pikiran. Peserta liyane ngetutake pikirane pimpinan, ndelok trik saka konsol, priksa manawa dheweke ora kejawab garis ing log, lan sinau babagan sistem kasebut. Pendekatan iki luwih kerep digunakake tinimbang ora.

Tinjauan Kode

Secara subyektif, luwih efektif nyebarake kawruh babagan infrastruktur lan cara kerjane nggunakake review kode:

Infrastruktur kasebut diterangake kanthi kode ing repositori.
Owah-owahan dumadi ing cabang sing kapisah.
Sajrone panjalukan gabungan, sampeyan bisa ndeleng delta saka owah-owahan ing infrastruktur.

Sorotan ing kene yaiku para pamawas dipilih siji-siji, miturut jadwal, yaiku. karo sawetara jurusan kamungkinan sampeyan bakal menek menyang Piece anyar saka infrastruktur.

Kode Gaya

Swara wektu, squabbles wiwit katon nalika review, amarga ... reviewers wis gaya dhewe lan rotasi reviewers dibandhingke karo gaya beda: 2 spasi utawa 4, camelCase utawa snake_case. Iku ora bisa kanggo ngleksanakake iki langsung.

Ide pisanan yaiku nyaranake nggunakake linter, sawise kabeh, kabeh wong insinyur, kabeh wong pinter. Nanging editor beda, OS, ora trep
Iki berkembang dadi bot sing nulis kanggo slack kanggo saben komitmen masalah lan nempelake output linter. Nanging ing sawetara kasus, ana prekara sing luwih penting sing kudu ditindakake lan kode kasebut ora tetep.

Ijo Mbangun Master

Wektu liwati, lan kita wis teka menyang kesimpulan sing nindakake sing ora lulus tes tartamtu ora bisa diijini menyang master. Voila! Kita nemokke Green Build Master, sing wis dipraktekke ing pangembangan piranti lunak suwene suwe:

Pangembangan ditindakake ing cabang sing kapisah.
Tes mlaku ing thread iki.
Yen tes gagal, kode kasebut ora bakal dadi master.

Nggawe keputusan iki pancen nglarani, amarga ... nyebabake akeh kontroversi, nanging worth iku, amarga ... Tinjauan wiwit nampa panjalukan kanggo gabung tanpa beda gaya, lan suwe-suwe jumlah wilayah masalah wiwit suda.

Pengujian IaC

Saliyane mriksa gaya, sampeyan bisa nggunakake barang liyane, contone, kanggo mriksa manawa infrastruktur sampeyan bisa digunakake. Utawa priksa manawa owah-owahan ing infrastruktur ora bakal nyebabake mundhut dhuwit. Yagene iki bisa uga dibutuhake? Pitakonan iki rumit lan filosofis, luwih apik kanggo njawab karo crita sing piye wae ana auto-scaler ing Powershell sing ora mriksa kahanan wates => luwih VM digawe saka perlu => klien ngginakaken dhuwit luwih saka ngrancang. Iki ora nyenengake, nanging bisa uga bisa nyekel kesalahan iki ing tahap awal.

Bisa uga ana sing takon, kenapa infrastruktur kompleks dadi luwih kompleks? Tes kanggo infrastruktur, kaya kanggo kode, ora babagan nyederhanakake, nanging babagan ngerti carane infrastruktur sampeyan kudu bisa digunakake.

Piramida Pengujian IaC

Pengujian IaC: Analisis Statis

Yen sampeyan masang kabeh prasarana bebarengan lan priksa manawa bisa digunakake, sampeyan bisa nemokake manawa mbutuhake wektu akeh lan mbutuhake wektu akeh. Mulane, basis kudu soko sing bisa cepet, ana akeh, lan isine akèh panggonan primitif.

Bash iku angel

Ayo deleng conto sing ora pati penting. pilih kabeh file ing direktori saiki lan salin menyang lokasi liyane. Bab pisanan sing dipikirake:

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

Apa yen ana spasi ing jeneng berkas? Inggih, ok, kita pinter, kita ngerti carane nggunakake kuotasi:

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

Inggih rampung? Ora! Apa yen ora ana apa-apa ing direktori, i.e. globbing ora bakal bisa.

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

Saiki rampung? Ora... Kelalen apa sing bisa ana ing jeneng file n.

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

Alat analisis statis

Masalah saka langkah sadurunge bisa kejiret nalika kita kelalen kuotasi, amarga iki ana akeh obat ing alam. Shellcheck, ing umum ana akeh, lan paling kamungkinan sampeyan bisa nemokake linter kanggo tumpukan ing IDE Panjenengan.

Language
alat

bash
Shellcheck

Ruby
RuboCop

python
pylint

ansible
Ansible Lint

Tes IaC: Tes Unit

Kaya sing kita deleng saka conto sadurunge, linters ora omnipotent lan ora bisa nuduhake kabeh wilayah masalah. Salajengipun, kanthi analogi karo tes ing pangembangan piranti lunak, kita bisa ngelingi tes unit. Sing langsung kepikiran yaiku sunit, junit, rspec, pytest. Nanging apa sing kudu dilakoni karo ansible, chef, saltstack lan liya-liyane?

Ing awal banget kita ngomong babagan SOLID lan infrastruktur kita kudu kalebu bata cilik. Wektune wis teka.

Infrastruktur dipérang dadi bata cilik, contone, peran Ansible.
Sawetara jinis lingkungan disebarake, dadi docker utawa VM.
Kita aplikasi peran Ansible kanggo lingkungan test iki.
Kita priksa manawa kabeh bisa ditindakake kaya sing dikarepake (kita tes).
Kita mutusake ok utawa ora ok.

Pengujian IaC: Alat Pengujian Unit

Pitakonan, apa tes kanggo CFM? Sampeyan mung bisa mbukak skrip, utawa sampeyan bisa nggunakake solusi sing wis siap kanggo iki:

CFM
alat

Ansible
Testinfra

sirah
Inspeksi

sirah
Spesifikasi server

tumpukan uyah
Gosip

Conto kanggo testinfra, mriksa sing kedhaftar test1, test2 ana lan ana ing klompok 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 sing kudu dipilih? Pitakonan kasebut rumit lan ambigu, iki minangka conto owah-owahan ing proyek ing github kanggo 2018-2019:

kerangka Pengujian IaC

Pitakonan muncul: carane sijine kabeh bebarengan lan miwiti? Saget njupuk lan nindakaken dhewe yen ana jumlah insinyur sing cukup. Utawa sampeyan bisa njupuk solusi sing wis siap, sanajan ora akeh banget:

CFM
alat

Ansible
Molekul

sirah
Test Pawon

Terraform
Terrates

Conto owah-owahan ing proyek ing github kanggo 2018-2019:

Molekul vs. pawon tes

Wiwitane kita nyoba nggunakake testkitchen:

Nggawe VM ing podo karo.
Aplikasi peran Ansible.
Run inspeksi.

Kanggo 25-35 peran, kerjane 40-70 menit, sing dawa.

Langkah sabanjure yaiku transisi menyang jenkins / docker / ansible / molekul. Idiologis kabeh padha

Buku dolanan linting.
Line up peran.
Wadhah peluncuran
Aplikasi peran Ansible.
Mbukak testfra.
Priksa idempotensi.

Linting kanggo 40 peran lan tes kanggo rolas wiwit njupuk bab 15 menit.

Apa sing kudu dipilih gumantung saka akeh faktor, kayata tumpukan sing digunakake, keahlian ing tim, lsp. ing kene saben wong mutusake dhewe carane nutup pitakonan testing Unit

Tes IaC: Tes Integrasi

Langkah sabanjure ing piramida tes infrastruktur bakal dadi tes integrasi. Padha padha karo tes Unit:

Infrastruktur dipérang dadi bata cilik, contone peran Ansible.
Sawetara jinis lingkungan disebarake, dadi docker utawa VM.
Kanggo lingkungan test iki ditrapake Bunch saka Peran sing bisa ditindakake.
Kita priksa manawa kabeh bisa ditindakake kaya sing dikarepake (kita tes).
Kita mutusake ok utawa ora ok.

Kira-kira, kita ora mriksa kinerja unsur individu saka sistem kaya ing tes unit, kita mriksa carane server dikonfigurasi sacara sakabehe.

Tes IaC: Tes Pungkasan nganti Pungkasan

Ing ndhuwur piramida kita disambut dening End to End tes. Sing. Kita ora mriksa kinerja server kapisah, skrip kapisah, utawa bata kapisah saka infrastruktur kita. Kita mriksa manawa akeh server sing disambungake bebarengan, infrastruktur kita bisa digunakake kaya sing dikarepake. Sayange, aku durung nate ndeleng solusi kotak sing wis siap, mungkin amarga ... Infrastruktur asring unik lan angel kanggo cithakan lan nggawe framework kanggo testing. Akibaté, saben wong nggawe solusi dhewe. Ana panjaluk, nanging ora ana jawaban. Mulane, aku bakal pitutur marang kowe apa ana kanggo push liyane kanggo muni pikirane utawa gosok irung ing kasunyatan sing kabeh wis nemokke biyen sadurunge kita.

A project karo sajarah sugih. Iki digunakake ing organisasi gedhe lan bisa uga saben sampeyan ora langsung ngliwati dalan kasebut. Aplikasi ndhukung akeh database, integrasi, etc. Ngerti apa prasarana bisa uga katon kaya akeh file docker-compose, lan ngerti tes sing bakal ditindakake ing lingkungane Jenkins.

Skema iki makarya kanggo dangu, nganti ing framework riset kita wis ora nyoba kanggo nransfer iki kanggo Openshift. Wadhah tetep padha, nanging lingkungan peluncuran wis diganti (halo DRY maneh).

Ide riset kasebut luwih maju, lan ing openshift, dheweke nemokake APB (Ansible Playbook Bundle), sing ngidini sampeyan ngemas kawruh babagan cara nyebarake infrastruktur menyang wadhah. Sing. ana titik kawruh sing bisa diulang, bisa diuji babagan cara nyebarake infrastruktur kasebut.

Kabeh iki muni apik nganti kita mlayu menyang infrastruktur heterogen: kita mbutuhake Windows kanggo tes. Akibaté, kawruh apa, ngendi, carane nyebarke, lan test ana ing jenkins.

kesimpulan

Infrastruktur minangka Kode punika

Kode ing repositori.
Interaksi manungsa.
Pengujian infrastruktur.

pranala

Source: www.habr.com

Apa Aku Sinau saka Nguji 200 Baris Kode Infrastruktur