Jika infrastruktur IT anda berkembang terlalu cepat, lambat laun anda akan berhadapan dengan pilihan: meningkatkan sumber manusia secara linear untuk menyokongnya atau memulakan automasi. Sehingga satu ketika, kami hidup dalam paradigma pertama, dan kemudian jalan panjang untuk Infrastructure-as-Code bermula.
Sudah tentu, NSPK bukan permulaan, tetapi suasana seperti itu memerintah dalam syarikat pada tahun-tahun pertama kewujudannya, dan itu adalah tahun-tahun yang sangat menarik. Nama saya ialah , saya telah menyokong infrastruktur Linux dengan keperluan ketersediaan tinggi selama lebih 10 tahun. Beliau menyertai pasukan NSPK pada Januari 2016 dan, malangnya, tidak melihat permulaan kewujudan syarikat itu, tetapi datang pada tahap perubahan besar.
Secara umum, kami boleh mengatakan bahawa pasukan kami membekalkan 2 produk untuk syarikat. Yang pertama ialah infrastruktur. Mel harus berfungsi, DNS harus berfungsi dan pengawal domain harus membenarkan anda masuk ke pelayan yang tidak seharusnya ranap. Landskap IT syarikat sangat besar! Ini adalah sistem kritikal perniagaan&misi, keperluan ketersediaan untuk sesetengahnya ialah 99,999. Produk kedua ialah pelayan itu sendiri, fizikal dan maya. Yang sedia ada perlu dipantau, dan yang baharu mesti dihantar secara berkala kepada pelanggan dari banyak jabatan. Dalam artikel ini saya ingin menumpukan pada cara kami membangunkan infrastruktur yang bertanggungjawab untuk kitaran hayat pelayan.
Bermula perjalanan
Pada permulaan perjalanan kami, timbunan teknologi kami kelihatan seperti ini:
OS CentOS 7
Pengawal Domain FreeIPA
Automasi - Ansible(+Menara), Tukang kasut
Semua ini terletak dalam 3 domain, tersebar di beberapa pusat data. Dalam satu pusat data terdapat sistem pejabat dan tapak ujian, selebihnya terdapat PROD.
Mencipta pelayan pada satu ketika kelihatan seperti ini:
Dalam templat VM, CentOS adalah minimum dan minimum yang diperlukan adalah seperti /etc/resolv.conf yang betul, selebihnya datang melalui Ansible.
CMDB - Excel.
Jika pelayan adalah fizikal, maka bukannya menyalin mesin maya, OS telah dipasang padanya menggunakan Cobbler - alamat MAC pelayan sasaran ditambahkan pada konfigurasi Cobbler, pelayan menerima alamat IP melalui DHCP, dan kemudian OS ditambah.
Pada mulanya kami juga cuba melakukan beberapa jenis pengurusan konfigurasi dalam Cobbler. Tetapi dari masa ke masa, ini mula membawa masalah dengan mudah alih konfigurasi ke pusat data lain dan kepada kod Ansible untuk menyediakan VM.
Pada masa itu, ramai di antara kita menganggap Ansible sebagai sambungan Bash yang mudah dan tidak berhemat pada reka bentuk menggunakan shell dan sed. Bashsible Keseluruhan. Ini akhirnya membawa kepada fakta bahawa jika buku main atas sebab tertentu tidak berfungsi pada pelayan, lebih mudah untuk memadamkan pelayan, membetulkan buku main dan menjalankannya semula. Pada asasnya tiada versi skrip, tiada mudah alih konfigurasi.
Sebagai contoh, kami ingin menukar beberapa konfigurasi pada semua pelayan:
- Kami menukar konfigurasi pada pelayan sedia ada dalam segmen logik/pusat data. Kadang-kadang tidak dalam satu hari - keperluan kebolehaksesan dan undang-undang bilangan besar tidak membenarkan semua perubahan digunakan sekaligus. Dan beberapa perubahan berpotensi merosakkan dan memerlukan memulakan semula sesuatu - daripada perkhidmatan kepada OS itu sendiri.
- Membetulkannya dalam Ansible
- Kami membetulkannya di Cobbler
- Ulang N kali untuk setiap segmen logik/pusat data
Agar semua perubahan berjalan lancar, adalah perlu untuk mengambil kira banyak faktor, dan perubahan berlaku secara berterusan.
- Pemfaktoran semula kod ansible, fail konfigurasi
- Mengubah amalan terbaik dalaman
- Perubahan berdasarkan hasil analisis kejadian/kemalangan
- Menukar piawaian keselamatan, dalaman dan luaran. Contohnya, PCI DSS dikemas kini dengan keperluan baharu setiap tahun
Pertumbuhan infrastruktur dan permulaan perjalanan
Bilangan pelayan/domain logik/pusat data bertambah, dan dengannya bilangan ralat dalam konfigurasi. Pada satu ketika, kami sampai ke tiga arah di mana pengurusan konfigurasi perlu dibangunkan:
- Automasi. Kesilapan manusia dalam operasi berulang harus dielakkan sebaik mungkin.
- Kebolehulangan. Ia lebih mudah untuk mengurus infrastruktur apabila ia boleh diramalkan. Konfigurasi pelayan dan alatan untuk penyediaannya hendaklah sama di mana-mana sahaja. Ini juga penting untuk pasukan produk - selepas ujian, aplikasi mesti dijamin berakhir dalam persekitaran pengeluaran yang dikonfigurasikan sama dengan persekitaran ujian.
- Kesederhanaan dan ketelusan membuat perubahan pada pengurusan konfigurasi.
Ia kekal untuk menambah beberapa alat.
Kami memilih GitLab CE sebagai repositori kod kami, tidak kurang untuk modul CI/CD terbina dalamnya.
Bilik kebal rahsia - Bilik Kebal Hashicorp, termasuk. untuk API yang hebat.
Menguji konfigurasi dan peranan ansible β Molekul+Testinfra. Ujian berjalan lebih cepat jika anda menyambung kepada mitogen ansible. Pada masa yang sama, kami mula menulis CMDB dan orkestra kami sendiri untuk penggunaan automatik (dalam gambar di atas Cobbler), tetapi ini adalah cerita yang sama sekali berbeza, yang akan diceritakan oleh rakan sekerja saya dan pemaju utama sistem ini pada masa hadapan.
Pilihan kami:
Molekul + Testinfra
Ansible + Menara + AWX
Dunia Pelayan + DITNET (Pembangunan sendiri)
Tukang Cendawan
Pelari Gitlab + GitLab
Bilik Kebal Hashicorp
Ngomong-ngomong, tentang peranan yang boleh dipercayai. Pada mulanya hanya terdapat satu, tetapi selepas beberapa pemfaktoran semula terdapat 17 daripadanya. Saya amat mengesyorkan pecahkan monolit kepada peranan idempoten, yang kemudiannya boleh dilancarkan secara berasingan, selain itu, anda boleh menambah tag. Kami membahagikan peranan mengikut fungsi - rangkaian, pembalakan, pakej, perkakasan, molekul dll. Secara umum, kami mengikuti strategi di bawah. Saya tidak menegaskan bahawa ini adalah satu-satunya kebenaran, tetapi ia berkesan untuk kami.
- Menyalin pelayan daripada "imej emas" adalah jahat!Kelemahan utama ialah anda tidak tahu dengan tepat keadaan imej itu sekarang, dan semua perubahan akan datang kepada semua imej dalam semua ladang virtualisasi.
- Gunakan fail konfigurasi lalai pada tahap minimum dan bersetuju dengan jabatan lain bahawa anda bertanggungjawab untuk fail sistem utama, sebagai contoh:
- Biarkan /etc/sysctl.conf kosong, tetapan seharusnya hanya dalam /etc/sysctl.d/. Lalai anda dalam satu fail, tersuai untuk aplikasi dalam fail lain.
- Gunakan fail ganti untuk mengedit unit sistem.
- Templat semua konfigurasi dan masukkannya sepenuhnya; jika boleh, tiada sed atau analognya dalam buku permainan
- Memfaktorkan semula kod sistem pengurusan konfigurasi:
- Pecahkan tugas kepada entiti logik dan tulis semula monolit ke dalam peranan
- Gunakan linters! Ansible-lint, yaml-lint, dsb
- Ubah pendekatan anda! Tidak boleh bashsible. Ia adalah perlu untuk menerangkan keadaan sistem
- Untuk semua peranan Ansible anda perlu menulis ujian dalam molekul dan menjana laporan sekali sehari.
- Dalam kes kami, selepas menyediakan ujian (yang terdapat lebih daripada 100), kira-kira 70000 ralat ditemui. Ia mengambil masa beberapa bulan untuk membaikinya.
Pelaksanaan kami
Oleh itu, peranan yang boleh dipertanggungjawabkan telah sedia, templat dan disemak secara bersiri. Dan malah git dinaikkan di mana-mana. Tetapi persoalan penghantaran kod yang boleh dipercayai kepada segmen berbeza tetap terbuka. Kami memutuskan untuk menyegerakkan dengan skrip. Nampak macam tu:
Selepas perubahan tiba, CI dilancarkan, pelayan ujian dibuat, peranan dilancarkan dan diuji oleh molekul. Jika semuanya ok, kod pergi ke cawangan prod. Tetapi kami tidak menggunakan kod baharu pada pelayan sedia ada dalam mesin. Ini adalah sejenis penyumbat yang diperlukan untuk ketersediaan tinggi sistem kami. Dan apabila infrastruktur menjadi besar, undang-undang bilangan besar akan dimainkan - walaupun anda pasti bahawa perubahan itu tidak berbahaya, ia boleh membawa kepada akibat yang teruk.
Terdapat juga banyak pilihan untuk membuat pelayan. Kami akhirnya memilih skrip Python tersuai. Dan untuk 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}}"Inilah yang telah kami sampaikan, sistem ini terus hidup dan berkembang.
- 17 Peranan yang boleh dilaksanakan untuk menyediakan pelayan. Setiap peranan direka bentuk untuk menyelesaikan tugas logik yang berasingan (pengelogan, pengauditan, kebenaran pengguna, pemantauan, dll.).
- Ujian peranan. Molekul + TestInfra.
- Pembangunan sendiri: CMDB + Orchestrator.
- Masa penciptaan pelayan ialah ~30 minit, automatik dan boleh dikatakan bebas daripada baris gilir tugas.
- Keadaan/penamaan infrastruktur yang sama dalam semua segmen - buku permainan, repositori, elemen virtualisasi.
- Semakan harian status pelayan dengan penjanaan laporan mengenai percanggahan dengan standard.
Saya harap cerita saya akan berguna kepada mereka yang berada di awal perjalanan mereka. Apakah tindanan automasi yang anda gunakan?
Sumber: www.habr.com