Yen infrastruktur IT tuwuh kanthi cepet, sampeyan bakal cepet-cepet ngadhepi pilihan: nambah sumber daya manungsa kanthi linear kanggo ndhukung utawa miwiti otomatisasi. Nganti sawetara titik, kita urip ing paradigma pisanan, banjur dalan dawa menyang Infrastruktur-as-Code diwiwiti.
Mesthine, NSPK dudu wiwitan, nanging atmosfer kaya ngono wis ana ing perusahaan kasebut ing taun-taun pisanan eksistensi, lan iku taun-taun sing menarik banget. jenengku , Aku wis ndhukung infrastruktur Linux kanthi syarat kasedhiyan dhuwur luwih saka 10 taun. Dheweke gabung karo tim NSPK ing Januari 2016 lan, sayangé, ora weruh awal eksistensi perusahaan, nanging teka ing tataran owah-owahan gedhe.
Umumé, kita bisa ujar manawa tim nyedhiyakake 2 produk kanggo perusahaan kasebut. Sing pertama yaiku infrastruktur. Mail kudu bisa, DNS kudu bisa, lan pengontrol domain kudu ngidini sampeyan menyang server sing ora kudu nabrak. Lanskap IT perusahaan gedhe banget! Iki minangka sistem kritis bisnis&misi, syarat kasedhiyan kanggo sawetara yaiku 99,999. Produk kapindho yaiku server dhewe, fisik lan virtual. Sing wis ana kudu dipantau, lan sing anyar kudu dikirim kanthi rutin menyang pelanggan saka akeh departemen. Ing artikel iki, aku pengin fokus babagan carane ngembangake infrastruktur sing tanggung jawab kanggo siklus urip server.
Wiwitane dalan
Ing wiwitan perjalanan, tumpukan teknologi kita katon kaya iki:
OS CentOS 7
Pengontrol Domain FreeIPA
Otomasi - Ansible(+Menara), Tukang Kayu
Kabeh iki ana ing 3 domain, nyebar ing sawetara pusat data. Ing siji pusat data ana sistem kantor lan situs uji, ing liyane ana PROD.
Nggawe server ing sawijining titik katon kaya iki:
Ing cithakan VM, CentOS minimal lan minimal sing dibutuhake kaya /etc/resolv.conf sing bener, liyane liwat Ansible.
CMDB - Excel.
Yen server fisik, tinimbang nyalin mesin virtual, OS diinstal ing nggunakake Cobbler - alamat MAC saka server target ditambahake menyang konfigurasi Cobbler, server nampa alamat IP liwat DHCP, lan banjur OS. ditambahake.
Ing kawitan kita malah nyoba kanggo nindakake sawetara jinis manajemen konfigurasi ing Cobbler. Nanging suwe-suwe, iki wiwit nggawa masalah karo portabilitas konfigurasi menyang pusat data liyane lan kode Ansible kanggo nyiapake VM.
Ing wektu kasebut, akeh sing nganggep Ansible minangka ekstensi Bash sing trep lan ora ngetung desain nggunakake cangkang lan sed. Sakabèhé Bashsible. Iki pungkasanipun mimpin kanggo kasunyatan sing yen playbook sakperangan alesan ora bisa digunakake ing server, iku luwih gampang kanggo mbusak server, ndandani playbook lan mbukak maneh. Ora ana versi skrip, ora ana portabilitas konfigurasi.
Contone, kita pengin ngganti sawetara konfigurasi ing kabeh server:
- Kita ngganti konfigurasi ing server sing ana ing segmen logis / pusat data. Kadhangkala ora ing sawijining dina - syarat aksesibilitas lan hukum nomer akeh ora ngidini kabeh owah-owahan bisa diterapake bebarengan. Lan sawetara owah-owahan bisa ngrusak lan mbutuhake miwiti maneh - saka layanan menyang OS dhewe.
- Ndandani ing Ansible
- Kita ndandani ing Cobbler
- Baleni kaping N kanggo saben segmen logis / pusat data
Supaya kabeh owah-owahan bisa lancar, sampeyan kudu nganggep akeh faktor, lan owah-owahan terus-terusan.
- Refactoring kode ansible, file konfigurasi
- Ngganti praktik paling apik internal
- Owah-owahan adhedhasar asil analisis kedadeyan / kacilakan
- Ngganti standar keamanan, internal lan eksternal. Contone, PCI DSS dianyari karo syarat anyar saben taun
Wutah infrastruktur lan wiwitan lelungan
Jumlah server / domain logis / pusat data tansaya akeh, lan karo wong-wong mau nomer kasalahan ing konfigurasi. Ing sawetara titik, kita teka ing telung arah sing kudu dikembangake manajemen konfigurasi:
- Otomasi. Kesalahan manungsa ing operasi sing bola-bali kudu dihindari sabisane.
- Repeatability. Luwih gampang kanggo ngatur infrastruktur nalika bisa diramal. Konfigurasi server lan alat kanggo nyiapake kudu padha ing endi wae. Iki uga penting kanggo tim produk - sawise tes, aplikasi kasebut kudu dijamin bakal rampung ing lingkungan produksi sing dikonfigurasi padha karo lingkungan tes.
- Kesederhanaan lan transparansi nggawe owah-owahan ing manajemen konfigurasi.
Iku tetep kanggo nambah sawetara alat.
Kita milih GitLab CE minangka gudang kode, paling ora kanggo modul CI/CD sing dibangun.
Vault saka Rahasia - Hashicorp Vault, kalebu. kanggo API gedhe.
Konfigurasi testing lan peran ansible - Molekul + Testinfra. Tes luwih cepet yen sampeyan nyambung menyang mitogen sing bisa. Ing wektu sing padha, kita wiwit nulis CMDB lan orkestra dhewe kanggo panyebaran otomatis (ing gambar ndhuwur Cobbler), nanging iki crita sing beda banget, sing bakal dicritakake karo kancaku lan pangembang utama sistem kasebut ing mangsa ngarep.
Pilihan kita:
Molekul + Testinfra
Ansible + Tower + AWX
World of Servers + DITNET (Pengembangan dhewe)
Tukang ngukir
Gitlab + GitLab runner
Hashicorp Vault
Miturut cara, babagan peran ansible. Kaping pisanan mung ana siji, nanging sawise sawetara refactorings ana 17. Aku banget nyaranake break monolith menyang peran idempotent, kang banjur bisa dibukak dhewe, tambahan, sampeyan bisa nambah tags. Kita dibagi peran miturut fungsi - jaringan, logging, paket, hardware, molekul etc. Umumé, kita tindakake strategi ing ngisor iki. Aku ora nandheske sing iki mung bebener, nanging bisa kanggo kita.
- Nyalin server saka "gambar emas" iku ala!Kerugian utama yaiku sampeyan ora ngerti persis apa negara gambar saiki, lan kabeh owah-owahan bakal teka ing kabeh gambar ing kabeh peternakan virtualisasi.
- Gunakake file konfigurasi gawan kanggo minimal lan setuju karo departemen liyane sing tanggung jawab kanggo file sistem utama, contone:
- Ninggalake /etc/sysctl.conf kosong, setelan mung kudu ing /etc/sysctl.d/. Standar sampeyan ing siji file, khusus kanggo aplikasi ing liyane.
- Gunakake file override kanggo ngowahi unit systemd.
- Cithakan kabeh konfigurasi lan kalebu kabeh; yen bisa, ora ana sed utawa analoge ing playbook
- Refactoring kode sistem manajemen konfigurasi:
- Pecah tugas dadi entitas logis lan tulis ulang monolit dadi peran
- Gunakake linters! Ansible-lint, yaml-lint, lsp
- Ganti pendekatan sampeyan! Ora bashsible. Sampeyan perlu kanggo njlèntrèhaké negara saka sistem
- Kanggo kabeh peran Ansible sampeyan kudu nulis tes ing molekul lan ngasilake laporan sapisan dina.
- Ing kasus kita, sawise nyiapake tes (sing ana luwih saka 100), udakara 70000 kesalahan ditemokake. Butuh sawetara sasi kanggo ndandani.
implementasine kita
Dadi, peran ansible wis siyap, template lan dicenthang kanthi linter. Lan malah git diunggahake ing endi wae. Nanging pitakonan babagan pangiriman kode sing dipercaya menyang macem-macem segmen tetep mbukak. Kita mutusake kanggo nyinkronake karo skrip. Katon kaya mangkene:
Sawise owah-owahan teka, CI diluncurake, server tes digawe, peran diluncurake, lan diuji dening molekul. Yen kabeh iku ok, kode menyang cabang prod. Nanging kita ora aplikasi kode anyar kanggo server ana ing mesin. Iki minangka jinis stopper sing perlu kanggo kasedhiyan sistem kita. Lan nalika prasarana dadi ageng, hukum jumlah gedhe bakal ditindakake - sanajan sampeyan yakin manawa owah-owahan kasebut ora mbebayani, bisa nyebabake akibat sing ala.
Ana uga akeh opsi kanggo nggawe server. Kita pungkasane milih skrip Python khusus. Lan kanggo CI ansible:
- name: create1.yml - Create a VM from a template
vmware_guest:
hostname: "{{datacenter}}".domain.ru
username: "{{ username_vc }}"
password: "{{ password_vc }}"
validate_certs: no
cluster: "{{cluster}}"
datacenter: "{{datacenter}}"
name: "{{ name }}"
state: poweredon
folder: "/{{folder}}"
template: "{{template}}"
customization:
hostname: "{{ name }}"
domain: domain.ru
dns_servers:
- "{{ ipa1_dns }}"
- "{{ ipa2_dns }}"
networks:
- name: "{{ network }}"
type: static
ip: "{{ip}}"
netmask: "{{netmask}}"
gateway: "{{gateway}}"
wake_on_lan: True
start_connected: True
allow_guest_control: True
wait_for_ip_address: yes
disk:
- size_gb: 1
type: thin
datastore: "{{datastore}}"
- size_gb: 20
type: thin
datastore: "{{datastore}}"Iki sing wis kita lakoni, sistem terus urip lan berkembang.
- 17 Peran ansible kanggo nyetel server. Saben peran dirancang kanggo ngrampungake tugas logis sing kapisah (logging, audit, wewenang pangguna, pemantauan, lsp.).
- Tes peran. Molekul + TestInfra.
- Pangembangan dhewe: CMDB + Orchestrator.
- Wektu nggawe server yaiku ~ 30 menit, otomatis lan praktis bebas saka antrian tugas.
- Negara / jeneng infrastruktur sing padha ing kabeh segmen - playbook, repositori, unsur virtualisasi.
- Priksa saben dina status server kanthi ngasilake laporan babagan bedo karo standar.
Muga-muga critaku bisa migunani kanggo wong-wong sing lagi miwiti perjalanan. Apa tumpukan otomatis sampeyan nggunakake?
Source: www.habr.com