Wis nyedhak Taun Anyar. Anak-anak ing saindenging negara wis ngirim layang menyang Santa Claus utawa menehi hadiah kanggo awake dhewe, lan pelaksana utama, salah sawijining pengecer utama, nyiapake apotheosis penjualan. Ing Desember, beban ing pusat data mundhak kaping pirang-pirang. Mulane, perusahaan mutusaké kanggo modernisasi pusat data lan sijine menyang operasi sawetara rolas server anyar tinimbang peralatan sing wis tekan mburi urip layanan. Iki mungkasi crita kanthi latar mburi salju sing swirling, lan thriller diwiwiti.
Peralatan kasebut teka ing situs kasebut sawetara wulan sadurunge puncak penjualan. Layanan operasi, mesthi ngerti carane lan apa sing kudu diatur ing server supaya bisa digawa menyang lingkungan produksi. Nanging kita kudu ngotomatisasi iki lan ngilangi faktor manungsa. Kajaba iku, server diganti sadurunge migrasi set sistem SAP sing kritis kanggo perusahaan.
Komisioning server anyar diikat kanthi tenggat wektu. Lan obah tegese mbebayani kiriman milyar hadiah lan migrasi sistem. Malah tim sing dumadi saka Rama Frost lan Santa Claus ora bisa ngganti tanggal - sampeyan bisa nransfer sistem SAP kanggo manajemen gudang mung sapisan taun. Saka 31 Desember nganti 1 Januari, gudang gedhe pengecer, kanthi total ukuran 20 lapangan bal-balan, mandheg kerjane sajrone 15 jam. Lan iki mung wektu kanggo mindhah sistem. Kita ora duwe ruang kanggo kesalahan nalika ngenalake server.
Ayo kula jelasake: critaku nggambarake alat lan proses manajemen konfigurasi sing digunakake tim kita.
Komplek manajemen konfigurasi kasusun saka sawetara tingkat. Komponen utama yaiku sistem CMS. Ing operasi industri, ora ana salah sawijining tingkat mesthi bakal nyebabake keajaiban sing ora nyenengake.
Manajemen instalasi OS
Tingkat pisanan yaiku sistem kanggo ngatur instalasi sistem operasi ing server fisik lan virtual. Nggawe konfigurasi OS dhasar, ngilangi faktor manungsa.
Nggunakake sistem iki, kita nampa kedadean server standar karo OS cocok kanggo otomatisasi luwih. Sajrone "tuang" dheweke nampa set minimal pangguna lokal lan kunci SSH umum, uga konfigurasi OS sing konsisten. Kita bisa dijamin ngatur server liwat CMS lan yakin manawa ora ana kejutan "mudhun ing ngisor" ing tingkat OS.
Tugas "maksimum" kanggo sistem manajemen instalasi yaiku kanthi otomatis ngatur server saka tingkat BIOS / Firmware menyang OS. Kathah ing kene gumantung ing peralatan lan tugas persiyapan. Kanggo peralatan heterogen, sampeyan bisa nimbang . Yen kabeh hardware saka siji vendor, iku asring luwih trep kanggo nggunakake piranti manajemen siap-digawe (contone, HP ILO Amplifier, DELL OpenManage, etc.).
Kanggo nginstal OS ing server fisik, kita nggunakake Cobbler sing kondhang, sing nemtokake set profil instalasi sing disepakati karo layanan operasi. Nalika nambah server anyar kanggo infrastruktur, engineer disambungake alamat MAC server menyang profil sing dibutuhake ing Cobbler. Nalika boot liwat jaringan kanggo pisanan, server nampa alamat sauntara lan OS anyar. Banjur ditransfer menyang alamat VLAN / IP target lan terus kerja ing kana. Ya, ngganti VLAN mbutuhake wektu lan mbutuhake koordinasi, nanging menehi perlindungan tambahan marang instalasi server sing ora disengaja ing lingkungan produksi.
Kita nggawe server virtual adhedhasar template sing disiapake nggunakake HashiСorp Packer. Alesane padha: kanggo nyegah kesalahan manungsa nalika nginstal OS. Nanging, ora kaya server fisik, Packer ngilangi PXE, booting jaringan, lan owah-owahan VLAN. Iki wis luwih gampang lan luwih gampang kanggo nggawe server virtual.
Gabah. 1. Ngatur panginstalan sistem operasi.
Ngatur rahasia
Sembarang sistem manajemen konfigurasi ngemot data sing kudu didhelikake saka pangguna biasa, nanging perlu kanggo nyiapake sistem. Iki minangka sandhi kanggo pangguna lokal lan akun layanan, kunci sertifikat, macem-macem Token API, lan liya-liyane. Biasane kasebut "rahasia."
Yen sampeyan ora nemtokake saka wiwitan ing ngendi lan carane nyimpen rahasia kasebut, mula, gumantung saka keruwetan syarat keamanan informasi, kemungkinan cara panyimpenan ing ngisor iki:
- langsung ing kode kontrol konfigurasi utawa ing file ing gudang;
- ing alat manajemen konfigurasi khusus (contone, Ansible Vault);
- ing sistem CI/CD (Jenkins/TeamCity/GitLab/etc.) utawa ing sistem manajemen konfigurasi (Ansible Tower/Ansible AWX);
- rahasia uga bisa ditransfer "kanthi manual". Contone, padha ditata ing lokasi sing ditemtokake, banjur digunakake dening sistem manajemen konfigurasi;
- macem-macem kombinasi saka ndhuwur.
Saben cara duwe kekurangan dhewe. Sing utama yaiku kekurangan kabijakan kanggo ngakses rahasia: ora mungkin utawa angel kanggo nemtokake sapa sing bisa nggunakake rahasia tartamtu. Kerugian liyane yaiku kekurangan audit akses lan siklus urip sing lengkap. Kepiye carane cepet ngganti, contone, kunci umum sing ditulis ing kode lan ing sawetara sistem sing gegandhengan?
Kita nggunakake panyimpenan rahasia terpusat HashiCorp Vault. Iki ngidini kita:
- njaga rahasia aman. Lagi ndhelik, lan malah yen wong entuk akses menyang database Vault (Contone, mulihake saka serep), padha ora bisa maca rahasia sing disimpen ana;
- ngatur kawicaksanan kanggo akses kanggo rahasia. Mung rahasia "diparengake" kanggo wong-wong mau kasedhiya kanggo pangguna lan aplikasi;
- akses audit kanggo rahasia. Sembarang tumindak kanthi rahasia dicathet ing log audit Vault;
- ngatur "siklus urip" lengkap nggarap rahasia. Bisa digawe, dicabut, nyetel tanggal kadaluwarsa, lsp.
- gampang digabungake karo sistem liyane sing mbutuhake akses menyang rahasia;
- lan uga nggunakake enkripsi end-to-end, sandhi siji-wektu kanggo OS lan database, sertifikat pusat sah, etc.
Saiki ayo pindhah menyang sistem otentikasi lan wewenang pusat. Bisa ditindakake tanpa, nanging ngatur pangguna ing pirang-pirang sistem sing gegandhengan banget ora pati penting. Kita wis ngatur otentikasi lan wewenang liwat layanan LDAP. Yen ora, Vault kudu terus ngetokake lan nglacak token otentikasi kanggo pangguna. Lan mbusak lan nambah pangguna bakal dadi pitakon "apa aku nggawe / mbusak akun pangguna iki ing endi wae?"
Kita nambah level liyane ing sistem kita: manajemen rahasia lan otentikasi / wewenang pusat:
Gabah. 2. Manajemen Rahasia.
Manajemen konfigurasi
Kita entuk inti - sistem CMS. Ing kasus kita, iki minangka kombinasi Ansible lan Red Hat Ansible AWX.
Tinimbang Ansible, Chef, Puppet, SaltStack bisa digunakake. Kita milih Ansible adhedhasar sawetara kritéria.
- Kaping pisanan, iku versatility. A pesawat saka modul siap-digawe kanggo kontrol . Lan yen sampeyan ora duwe cukup, sampeyan bisa nelusuri ing GitHub lan Galaxy.
- Kapindho, ora perlu nginstal lan ndhukung agen ing peralatan sing dikelola, mbuktekake manawa ora ngganggu beban, lan konfirmasi ora ana "tetenger".
- Katelu, Ansible nduweni alangan sing sithik kanggo mlebu. Insinyur sing kompeten bakal nulis buku pedoman kerja kanthi harfiah ing dina pisanan nggarap produk kasebut.
Nanging Ansible mung ing lingkungan produksi ora cukup kanggo kita. Yen ora, akeh masalah bakal muncul nalika mbatesi akses lan ngawasi tumindak para pangurus. Carane matesi akses? Sawise kabeh, iku perlu kanggo saben departemen kanggo ngatur (maca: mbukak playbook Ansible) "dhewe" pesawat saka server. Carane ngidini mung karyawan tartamtu kanggo mbukak playbooks Ansible tartamtu? Utawa carane trek sing dibukak playbook tanpa nyetel akeh kawruh lokal ing server lan peralatan mlaku Ansible?
Sing paling gedhe babagan masalah kasebut dirampungake dening Red Hat , utawa proyek hulu open-source . Mulane kita luwih milih kanggo pelanggan.
Lan siji tutul maneh kanggo potret sistem CMS kita. Playbook ansible kudu disimpen ing sistem manajemen repositori kode. Kita duwe .
Dadi, konfigurasi dhewe dikelola kanthi kombinasi Ansible/Ansible AWX/GitLab (pirsani Gambar 3). Mesthi, AWX/GitLab digabungake karo sistem otentikasi siji, lan playbook Ansible digabungake karo HashiCorp Vault. Konfigurasi mlebu ing lingkungan produksi mung liwat Ansible AWX, ing ngendi kabeh "aturan game" ditemtokake: sing bisa ngatur apa, ing ngendi entuk kode manajemen konfigurasi kanggo CMS, lsp.
Gabah. 3. Manajemen konfigurasi.
Manajemen tes
Konfigurasi kita ditampilake ing wangun kode. Mulane, kita dipeksa kanggo muter dening aturan padha pangembang software. Kita kudu ngatur proses pangembangan, tes terus-terusan, pangiriman lan aplikasi kode konfigurasi menyang server produksi.
Yen iki ora langsung rampung, peran sing ditulis kanggo konfigurasi bakal mandheg didhukung lan diowahi, utawa ora bakal diluncurake ing produksi. Obat kanggo nyeri iki wis dingerteni, lan wis kabukten ing proyek iki:
- saben peran dijamin dening tes unit;
- tes ditindakake kanthi otomatis nalika ana owah-owahan ing kode sing ngatur konfigurasi;
- owah-owahan ing kode Manajemen konfigurasi dirilis menyang lingkungan produksi mung sawise kasil ngliwati kabeh tes lan review kode.
Pengembangan kode lan manajemen konfigurasi wis dadi luwih tenang lan bisa ditebak. Kanggo ngatur testing terus, kita nggunakake GitLab CI/CD toolkit, lan njupuk .
Yen ana owah-owahan ing kode manajemen konfigurasi, GitLab CI/CD nelpon Molekul:
- iku mriksa sintaks kode,
- mundhakaken wadhah Docker,
- ngetrapake kode sing diowahi menyang wadhah sing digawe,
- mriksa peran kanggo idempotensi lan mbukak tes kanggo kode iki (granularity kene ing tingkat peran ansible, ndeleng Fig. 4).
Kita ngirim konfigurasi menyang lingkungan produksi nggunakake Ansible AWX. Insinyur operasi ngetrapake owah-owahan konfigurasi liwat cithakan sing wis ditemtokake. AWX independen "njaluk" versi paling anyar saka kode saka cabang master GitLab saben-saben digunakake. Kanthi cara iki, kita ngilangi panggunaan kode sing durung tes utawa lawas ing lingkungan produksi. Alami, kode kasebut mlebu cabang master mung sawise nyoba, mriksa lan disetujoni.
Gabah. 4. Tes otomatis peran ing GitLab CI / CD.
Ana uga masalah sing ana gandhengane karo operasi sistem produksi. Ing urip nyata, angel banget kanggo nggawe owah-owahan konfigurasi liwat kode CMS piyambak. Kahanan darurat muncul nalika insinyur kudu ngganti konfigurasi "kene lan saiki", tanpa ngenteni panyuntingan kode, tes, persetujuan, lsp.
Akibaté, amarga owah-owahan manual, bedo katon ing konfigurasi ing jinis padha saka peralatan (Contone, setelan sysctl diatur beda ing kelenjar HA). Utawa konfigurasi nyata ing peralatan beda-beda saka siji kasebut ing kode CMS.
Mulane, saliyane kanggo tes terus-terusan, kita mriksa lingkungan produksi kanggo bedo konfigurasi. Kita milih pilihan sing paling gampang: mbukak kode konfigurasi CMS ing mode "dry run", yaiku, tanpa ngganti owah-owahan, nanging kanthi kabar kabeh bedo antarane konfigurasi sing direncanakake lan nyata. Iki ditindakake kanthi rutin mbukak kabeh playbook Ansible kanthi pilihan "-priksa" ing server produksi. Kaya biasane, Ansible AWX tanggung jawab kanggo mbukak lan njaga playbook nganti saiki (pirsani Fig. 5):
Gabah. 5. Priksa bedo konfigurasi ing Ansible AWX.
Sawise mriksa, AWX ngirim laporan bedo menyang administrator. Padha sinau konfigurasi masalah lan banjur ndandani liwat playbooks diatur. Iki carane kita njaga konfigurasi ing lingkungan produksi lan CMS tansah anyar lan diselarasake. Iki ngilangi "ajaib" sing ora nyenengake nalika kode CMS digunakake ing server "produksi".
Saiki kita duwe lapisan pangujian penting sing kalebu Ansible AWX/GitLab/Molecule (Gambar 6).
Gabah. 6. Manajemen tes.
angel? Aku ora mbantah. Nanging kompleks manajemen konfigurasi kasebut wis dadi jawaban lengkap kanggo akeh pitakonan sing ana gandhengane karo otomatisasi konfigurasi server. Saiki server standar pengecer mesthi duwe konfigurasi sing ditemtokake. CMS, ora kaya insinyur, ora bakal lali nambah setelan sing dibutuhake, nggawe pangguna lan nindakake puluhan utawa atusan setelan sing dibutuhake.
Ora ana "kawruh rahasia" ing setelan server lan lingkungan saiki. Kabeh fitur sing perlu dibayangke ing playbook. Ora ana kreatifitas lan instruksi sing ora jelas: "Instal kaya Oracle biasa, nanging sampeyan kudu nemtokake sawetara setelan sysctl lan nambah pangguna karo UID sing dibutuhake. Takon wong-wong sing operasi, padha ngerti".
Kemampuan kanggo ndeteksi bedo konfigurasi lan mbenerake kanthi proaktif menehi katentreman atine. Tanpa sistem manajemen konfigurasi, iki biasane katon beda. Masalah nglumpukake nganti sawijining dina "tembak" dadi produksi. Banjur debriefing ditindakake, konfigurasi dicenthang lan didandani. Lan siklus mbaleni maneh
Lan mesthi, kita nyepetake peluncuran server menyang operasi saka sawetara dina nganti jam.
Inggih, ing Eve Taun Anyar dhewe, nalika bocah-bocah padha bungah-bungah mbukak hadiah lan wong diwasa padha njaluk wishes nalika lonceng disabetake, engineers kita migrasi sistem SAP menyang server anyar. Malah Santa Claus bakal ujar manawa mukjijat sing paling apik yaiku sing disiapake kanthi apik.
PS Tim kita asring nemoni kasunyatan manawa pelanggan pengin ngatasi masalah manajemen konfigurasi kanthi gampang. Saenipun, kaya sihir - kanthi siji alat. Nanging ing urip, kabeh luwih rumit (ya, peluru perak ora dikirim maneh): sampeyan kudu nggawe kabeh proses nggunakake alat sing trep kanggo tim pelanggan.
Pengarang: Sergey Artemov, arsitek departemen "Sistem Info Jet"
Source: www.habr.com