Geus ngadeukeutan Taun Anyar. Barudak di sakumna nagara parantos ngirim surat ka Santa Claus atanapi ngadamel hadiah pikeun diri, sareng pelaksana utamana, salah sahiji pangecér utama, nyiapkeun apotheosis penjualan. Dina bulan Désémber, beban dina pusat datana ningkat sababaraha kali. Ku alatan éta, pausahaan mutuskeun pikeun modernisasikeun puseur data sarta nempatkeun kana operasi sababaraha belasan server anyar tinimbang alat-alat nu geus ngahontal tungtung hirup layanan na. Ieu mungkas dongéng ngalawan latar tukang swirling snowflakes, sareng thriller dimimitian.

Parabot dugi ka situs sababaraha bulan sateuacan puncak penjualan. Ladenan operasi, tangtosna, terang kumaha sareng naon anu kedah dikonpigurasikeun dina server supados tiasa dibawa ka lingkungan produksi. Tapi urang kedah ngajadikeun otomatis ieu sareng ngaleungitkeun faktor manusa. Salaku tambahan, server diganti sateuacan migrasi sakumpulan sistem SAP anu kritis pikeun perusahaan.

The commissioning of server anyar ieu mastikeun dihijikeun ka deadline a. Sareng mindahkeun éta hartosna ngabahayakeun kiriman samilyar hadiah sareng migrasi sistem. Malah tim anu diwangun ku Bapa Frost sareng Santa Claus henteu tiasa ngarobih tanggalna - anjeun tiasa nransfer sistem SAP pikeun manajemén gudang ngan sakali sataun. Ti 31 Désémber nepi ka 1 Januari, gudang gedé pangecér, jumlahna aya 20 lapangan maén bal, ngeureunkeun padamelanna salami 15 jam. Sareng ieu mangrupikeun hiji-hijina waktos pikeun mindahkeun sistem. Urang teu boga rohangan pikeun kasalahan nalika ngenalkeun server.

Hayu atuh jadi jelas: carita kuring ngagambarkeun parabot jeung prosés manajemén konfigurasi nu tim urang ngagunakeun.

Kompléks manajemén konfigurasi diwangun ku sababaraha tingkatan. Komponén konci nyaéta sistem CMS. Dina operasi industri, henteuna salah sahiji tingkat inevitably bakal ngakibatkeun miracles pikaresepeun.

manajemén instalasi OS

Tingkat kahiji nyaéta sistem pikeun ngatur pamasangan sistem operasi dina server fisik sareng virtual. Éta nyiptakeun konfigurasi OS dasar, ngaleungitkeun faktor manusa.

Ngagunakeun sistem ieu, kami narima instansi server baku kalawan OS cocog pikeun automation salajengna. Salila "tuang" aranjeunna nampi set minimum pamaké lokal sarta konci SSH publik, kitu ogé konfigurasi OS konsisten. Kami dijamin pikeun ngatur server ngaliwatan CMS sareng yakin yén teu aya kejutan "handap" dina tingkat OS.

Tugas "maksimum" pikeun sistem manajemen instalasi nyaéta ngonpigurasikeun server otomatis tina tingkat mios / Firmware ka OS. Seueur di dieu gumantung kana alat sareng tugas pangaturan. Pikeun alat hétérogén, Anjeun bisa mertimbangkeun REDFISH API. Upami sadaya hardware tina hiji padagang, maka sering langkung gampang ngagunakeun alat manajemén anu siap-siap (contona, HP ILO Amplifier, DELL OpenManage, jsb.).

Pikeun masang OS dina server fisik, kami nganggo Cobbler anu terkenal, anu netepkeun sakumpulan profil pamasangan anu sapuk sareng jasa operasi. Nalika nambihan server énggal kana infrastruktur, insinyur ngahubungkeun alamat MAC server kana profil anu diperyogikeun dina Cobbler. Nalika nga-boot jaringan pikeun kahiji kalina, server nampi alamat samentawis sareng OS énggal. Lajeng ieu dibikeun ka VLAN target / alamat IP sarta nuluykeun karya dinya. Sumuhun, ngarobah VLAN butuh waktu sarta merlukeun koordinasi, tapi nyadiakeun panyalindungan tambahan ngalawan instalasi teu kahaja tina server di lingkungan produksi.

Kami nyiptakeun server virtual dumasar kana témplat anu disiapkeun nganggo HashiСorp Packer. Alesanna sami: pikeun nyegah kamungkinan kasalahan manusa nalika masang OS. Tapi, teu sapertos server fisik, Packer ngaleungitkeun kabutuhan PXE, booting jaringan, sareng parobihan VLAN. Ieu ngagampangkeun sareng langkung saderhana pikeun nyiptakeun server virtual.

Sangu. 1. Ngatur pamasangan sistem operasi.

Ngatur rusiah

Sagala sistem manajemen konfigurasi ngandung data nu kudu disumputkeun ti pamaké biasa, tapi diperlukeun pikeun nyiapkeun sistem. Ieu kecap akses pikeun pangguna lokal sareng akun jasa, konci sertipikat, rupa-rupa Tokens API, jsb. Biasana disebut "rahasia."

Upami anjeun henteu nangtukeun ti mimiti dimana sareng kumaha cara nyimpen rahasia ieu, maka, gumantung kana parah syarat kaamanan inpormasi, metode panyimpen di handap ieu kamungkinan:

• langsung dina kode kontrol konfigurasi atanapi dina file dina gudang;
• dina parabot manajemén konfigurasi husus (contona, Ansible Vault);
• dina sistem CI / CD (Jenkins / TeamCity / GitLab / jsb) atanapi dina sistem manajemen konfigurasi (Menara Ansible / Ansible AWX);
• Rahasia ogé tiasa ditransfer "sacara manual". Contona, aranjeunna diteundeun kaluar dina lokasi nu tangtu, lajeng aranjeunna dipaké ku sistem manajemen konfigurasi;
• rupa-rupa kombinasi di luhur.

Unggal métode boga kalemahan sorangan. Anu utama nyaéta kurangna kawijakan pikeun aksés ka rusiah: mustahil atanapi sesah pikeun nangtoskeun saha anu tiasa nganggo rusiah anu tangtu. Karugian anu sanésna nyaéta kurangna aksés auditing sareng siklus hirup anu lengkep. Kumaha gancang ngagentos, contona, konci umum anu ditulis dina kode sareng dina sababaraha sistem anu aya hubunganana?

Kami nganggo gudang rahasia terpusat HashiCorp Vault. Ieu ngamungkinkeun urang:

• ngajaga Rahasia aman. Éta énkripsi, komo lamun batur gains aksés ka database Kolong (Contona, ku malikkeun tina cadangan), aranjeunna moal bisa maca Rahasia nu disimpen di dinya;
• ngatur kawijakan pikeun aksés ka Rahasia. Ngan rusiah "dialokasikeun" pikeun aranjeunna sayogi pikeun pangguna sareng aplikasi;
• aksés Inok kana Rahasia. Sakur lampah sareng rusiah kacatet dina log audit Vault;
• ngatur hiji full-fledged "siklus hirup" gawé bareng Rahasia. Éta tiasa diciptakeun, dicabut, nyetél tanggal béakna, jsb.
• gampang pikeun ngahijikeun sareng sistem sanés anu peryogi aksés kana rusiah;
• sarta ogé ngagunakeun enkripsi tungtung-to-tungtung, hiji-waktos kecap akses pikeun OS na database, sertipikat ti puseur otorisasi, jsb.

Ayeuna hayu urang ngaléngkah ka auténtikasi sentral sareng sistem otorisasina. Ieu mungkin mun ngalakukeun tanpa eta, tapi administering pamaké dina loba sistem patali teuing non-trivial. Kami parantos ngonpigurasi auténtikasi sareng otorisasina ngalangkungan jasa LDAP. Upami teu kitu, Vault kedah terus ngaluarkeun sareng ngalacak token auténtikasi pikeun pangguna. Sareng mupus sareng nambihan pangguna bakal janten quest "naha kuring nyiptakeun / ngahapus akun pangguna ieu dimana-mana?"

Kami nambihan tingkat anu sanés kana sistem kami: manajemén rahasia sareng auténtikasi / otorisasi pusat:

Sangu. 2. manajemén Rahasia.

Manajemén konfigurasi

Urang ngagaduhan kana inti - sistem CMS. Dina kasus urang, ieu mangrupikeun kombinasi Ansible sareng Red Hat Ansible AWX.

Gantina Ansible, Chef, Wayang, SaltStack tiasa dianggo. Kami milih Ansible dumasar kana sababaraha kriteria.

• Anu mimiti, éta versatility. Hiji set modul siap-dijieun pikeun kontrol éta impressive. Sareng upami anjeun henteu cekap, anjeun tiasa milarian dina GitHub sareng Galaxy.
• Bréh, aya teu kudu masang sarta ngarojong agén dina parabot junun, ngabuktikeun yén maranéhna teu ngaganggu beban, sarta mastikeun henteuna "téténggér".
• Katilu, Ansible ngagaduhan halangan anu rendah pikeun asup. Insinyur anu kompeten bakal nyerat playbook kerja sacara harfiah dina dinten munggaran damel sareng produk.

Tapi Ansible nyalira dina lingkungan produksi henteu cekap pikeun urang. Upami teu kitu, seueur masalah bakal timbul nalika ngawatesan aksés sareng ngaudit tindakan pangurus. Kumaha ngawatesan aksés? Barina ogé, éta diperlukeun pikeun tiap departemén pikeun ngatur (baca: ngajalankeun playbook Ansible) "sorangan" susunan server. Kumaha ngawenangkeun ngan karyawan tangtu ngajalankeun playbooks Ansible husus? Atawa kumaha carana ngalacak saha dibuka playbook nu tanpa nyetel loba pangaweruh lokal dina server jeung alat ngajalankeun Ansible?

Bagian singa tina masalah sapertos direngsekeun ku Red Hat Menara Ansible, atawa proyék hulu open source na Ansible AWX. Éta sababna kami langkung milih pikeun palanggan.

Sareng hiji deui sentuhan kana potret sistem CMS kami. Playbook ansible kedah disimpen dina sistem manajemen gudang kode. Simkuring gaduh eta GitLab CE.

Ku kituna, konfigurasi sorangan diurus ku kombinasi Ansible / Ansible AWX / GitLab (tingali Gbr. 3). Tangtosna, AWX / GitLab terpadu sareng sistem auténtikasi tunggal, sareng playbook Ansible diintegrasikeun sareng HashiCorp Vault. Konfigurasi asup ka lingkungan produksi ngan ngaliwatan Ansible AWX, nu sagala "aturan kaulinan" dieusian: anu bisa ngonpigurasikeun naon, dimana meunang kodeu manajemén konfigurasi pikeun CMS, jsb.

Sangu. 3. Manajemén konfigurasi.

Manajemén tés

Konfigurasi kami dibere dina bentuk kode. Kituna, urang kapaksa maén ku aturan sarua salaku pamekar software. Urang kedah ngatur prosés pangwangunan, uji kontinyu, pangiriman sareng aplikasi kode konfigurasi ka server produksi.

Upami ieu henteu langsung dilakukeun, maka peran anu ditulis pikeun konfigurasi bakal lirén dirojong sareng dirobih, atanapi bakal lirén diluncurkeun dina produksi. Ubar pikeun nyeri ieu dipikanyaho, sareng parantos ngabuktikeun sorangan dina proyék ieu:

• unggal peran katutupan ku tés unit;
• tés dijalankeun sacara otomatis iraha waé aya parobahan dina kode anu ngatur konfigurasi;
• parobahan dina kode manajemén konfigurasi dileupaskeun ka lingkungan produksi ngan sanggeus hasil lulus sagala tés jeung review kode.

Ngembangkeun kode sareng manajemén konfigurasi parantos langkung tenang sareng langkung tiasa diprediksi. Pikeun ngatur tés kontinyu, kami nganggo toolkit GitLab CI / CD, sareng nyandak Molekul Ansible.

Iraha waé aya parobahan dina kode manajemén konfigurasi, GitLab CI/CD nyauran Molekul:

• éta pariksa sintaksis kode,
• ngangkat wadah Docker,
• nerapkeun kodeu anu dirobih kana wadah anu diciptakeun,
• mariksa peran pikeun idempotency tur ngajalankeun tés pikeun kode ieu (granularity dieu nyaeta dina tingkat peran ansible, tingali Gbr. 4).

Urang dikirimkeun konfigurasi ka lingkungan produksi maké Ansible AWX. Insinyur operasi nerapkeun parobahan konfigurasi ngaliwatan témplat anu tos siap. AWX bebas "dipénta" versi panganyarna tina kode ti cabang master GitLab unggal waktos eta dipaké. Ku cara ieu urang ngaluarkeun pamakean kode anu teu acan teruji atanapi katinggaleun jaman di lingkungan produksi. Alami, kode asup kana cabang master ngan sanggeus nguji, review sarta persetujuan.

Sangu. 4. Uji otomatis tina peran dina GitLab CI / CD.

Aya ogé masalah anu aya hubunganana sareng operasi sistem produksi. Dina kahirupan nyata, éta hésé pisan nyieun parobahan konfigurasi ngaliwatan kode CMS nyalira. Kaayaan darurat timbul nalika insinyur kedah ngarobih konfigurasi "di dieu sareng ayeuna", tanpa ngantosan éditan kode, uji, persetujuan, jsb.

Hasilna, alatan parobahan manual, discrepancies némbongan dina konfigurasi dina tipe sarua pakakas (Contona, setélan sysctl ngonpigurasi béda dina titik klaster HA). Atanapi konfigurasi saleresna dina alat-alatna béda ti anu dijelaskeun dina kode CMS.

Ku alatan éta, salian ti nguji kontinyu, urang pariksa lingkungan produksi pikeun discrepancies konfigurasi. Urang milih pilihan pangbasajanna: ngajalankeun kodeu konfigurasi CMS dina mode "garing ngajalankeun", nyaeta, tanpa nerapkeun parobahan, tapi kalayan bewara ngeunaan sagala discrepancies antara konfigurasi rencanana tur sabenerna. Urang ngalaksanakeun ieu ku périodik ngajalankeun sagala playbooks Ansible kalawan pilihan "-check" dina server produksi. Sakumaha biasa, Ansible AWX tanggung jawab pikeun ngaluncurkeun sareng ngajaga playbook dugi ka ayeuna (tingali Gbr. 5):

Sangu. 5. Cék pikeun discrepancies konfigurasi dina Ansible AWX.

Saatos cék, AWX ngirimkeun laporan bédana ka pangurus. Aranjeunna diajar konfigurasi masalah lajeng ngalereskeun eta ngaliwatan playbooks disaluyukeun. Ieu kumaha urang ngajaga konfigurasi di lingkungan produksi jeung CMS sok up to date jeung nyingkronkeun. Ieu ngaleungitkeun "kaajaiban" anu teu pikaresepeun nalika kode CMS dianggo dina server "produksi".

Urang ayeuna boga hiji lapisan nguji penting diwangun ku Ansible AWX / GitLab / Molekul (Gambar 6).

Sangu. 6. Manajemén tés.

Hese? Abdi henteu ngabantah. Tapi kompleks manajemén konfigurasi sapertos kitu parantos janten jawaban anu komprehensif pikeun seueur patarosan anu aya hubunganana sareng otomatisasi konfigurasi server. Ayeuna server standar pangecér salawasna gaduh konfigurasi anu didefinisikeun sacara ketat. CMS, teu sapertos insinyur, moal hilap nambihan setélan anu diperyogikeun, nyiptakeun pangguna sareng ngalaksanakeun puluhan atanapi ratusan setélan anu diperyogikeun.

Henteu aya "pangaweruh rusiah" dina setélan pangladén sareng lingkungan ayeuna. Sadaya fitur anu diperyogikeun ditingalikeun dina playbook. Henteu aya deui kréatipitas sareng petunjuk anu samar: "Pasang sapertos Oracle biasa, tapi anjeun kedah netepkeun sababaraha setélan sysctl sareng tambahkeun pangguna nganggo UID anu diperyogikeun. Tanya guys di operasi, maranéhna terang".

Kamampuhan pikeun ngadeteksi discrepancies konfigurasi sareng ngabenerkeunana sacara proaktif nyayogikeun katenangan pikiran. Tanpa sistem manajemen konfigurasi, ieu biasana béda. Masalah ngumpulkeun dugi ka hiji dinten aranjeunna "némbak" kana produksi. Teras debriefing dilaksanakeun, konfigurasi dipariksa sareng dilereskeun. Jeung siklus nu repeats deui

Sareng tangtosna, urang ngagancangkeun peluncuran server kana operasi ti sababaraha dinten ka jam.

Nya, dina Hawa Taun Anyar sorangan, nalika murangkalih anu gumbira ngabuka kado sareng déwasa nyarioskeun hajat nalika lonceng, insinyur urang migrasi sistem SAP ka server énggal. Malah Santa Claus bakal nyarios yén mujijat anu pangsaéna nyaéta anu disiapkeun ogé.

PS Tim kami mindeng encounters kanyataan yén konsumén hayang ngajawab masalah manajemén konfigurasi sasederhana mungkin. Ideally, saolah-olah ku magic - kalawan hiji alat. Tapi dina kahirupan sagalana leuwih pajeulit (enya, pélor pérak teu dikirimkeun deui): Anjeun kudu nyieun hiji sakabéh prosés ngagunakeun parabot anu merenah pikeun tim customer urang.

Panulis: Sergey Artemov, arsiték departemén Solusi DevOps "Sistem Info Jet"

sumber: www.habr.com