Jika infrastruktur TI Anda tumbuh terlalu cepat, cepat atau lambat Anda akan dihadapkan pada pilihan: meningkatkan sumber daya manusia secara linear untuk mendukungnya atau memulai otomatisasi. Sampai titik tertentu, kita hidup dalam paradigma pertama, dan kemudian jalan panjang menuju Infrastruktur sebagai Kode dimulai.
Tentu saja NSPK bukanlah sebuah startup, namun suasana seperti itu menyelimuti perusahaan pada tahun-tahun pertama keberadaannya, dan itu adalah tahun-tahun yang sangat menarik. Nama saya adalah , Saya telah mendukung infrastruktur Linux dengan persyaratan ketersediaan tinggi selama lebih dari 10 tahun. Ia bergabung dengan tim NSPK pada bulan Januari 2016 dan sayangnya, ia tidak melihat awal mula keberadaan perusahaan tersebut, namun ia berada pada tahap perubahan besar.
Secara umum dapat dikatakan bahwa tim kami memasok 2 produk untuk perusahaan. Yang pertama adalah infrastruktur. Mail seharusnya berfungsi, DNS harus berfungsi, dan pengontrol domain akan membiarkan Anda masuk ke server yang tidak akan mogok. Lanskap TI perusahaan sangat besar! Ini adalah sistem penting bisnis & misi, persyaratan ketersediaan untuk beberapa di antaranya adalah 99,999. Produk kedua adalah server itu sendiri, fisik dan virtual. Yang sudah ada perlu dipantau, dan yang baru harus dikirimkan secara rutin ke pelanggan dari banyak departemen. Dalam artikel ini saya ingin fokus pada bagaimana kami mengembangkan infrastruktur yang bertanggung jawab atas siklus hidup server.
Awal perjalanan
Pada awal perjalanan kami, tumpukan teknologi kami terlihat seperti ini:
OS CentOS 7
Pengontrol Domain FreeIPA
Otomatisasi - Kemungkinan(+Menara), Tukang Sepatu
Semua ini terletak di 3 domain, tersebar di beberapa pusat data. Di satu pusat data terdapat sistem perkantoran dan lokasi pengujian, sisanya ada PROD.
Membuat server pada satu titik terlihat seperti ini:
Dalam template VM, CentOS minimal dan minimum yang diperlukan seperti /etc/resolv.conf yang benar, sisanya datang melalui Ansible.
CMDB - Unggul.
Jika server bersifat fisik, maka alih-alih menyalin mesin virtual, OS diinstal di dalamnya menggunakan Cobbler - alamat MAC dari server target ditambahkan ke konfigurasi Cobbler, server menerima alamat IP melalui DHCP, dan kemudian OS telah ditambahkan.
Awalnya kami bahkan mencoba melakukan semacam manajemen konfigurasi di Cobbler. Namun seiring berjalannya waktu, hal ini mulai menimbulkan masalah pada portabilitas konfigurasi baik ke pusat data lain maupun pada kode Ansible untuk menyiapkan VM.
Pada saat itu, banyak dari kita menganggap Ansible sebagai perpanjangan Bash yang nyaman dan tidak berhemat pada desain yang menggunakan shell dan sed. Secara keseluruhan Bashsible. Hal ini pada akhirnya mengarah pada fakta bahwa jika playbook karena alasan tertentu tidak berfungsi di server, akan lebih mudah untuk menghapus server, memperbaiki playbook, dan menjalankannya kembali. Pada dasarnya tidak ada versi skrip, tidak ada portabilitas konfigurasi.
Misalnya, kami ingin mengubah beberapa konfigurasi di semua server:
- Kami mengubah konfigurasi pada server yang ada di segmen logis/pusat data. Terkadang tidak dalam satu hari - persyaratan aksesibilitas dan hukum jumlah besar tidak mengizinkan semua perubahan diterapkan sekaligus. Dan beberapa perubahan berpotensi merusak dan memerlukan memulai ulang sesuatu - mulai dari layanan hingga OS itu sendiri.
- Memperbaikinya di Ansible
- Kami memperbaikinya di Cobbler
- Ulangi N kali untuk setiap segmen logis/pusat data
Agar semua perubahan berjalan lancar, banyak faktor yang harus diperhitungkan, dan perubahan terjadi terus-menerus.
- Memfaktorkan ulang kode yang memungkinkan, file konfigurasi
- Mengubah praktik terbaik internal
- Perubahan berdasarkan hasil analisis kejadian/kecelakaan
- Mengubah standar keamanan, baik internal maupun eksternal. Misalnya, PCI DSS diperbarui dengan persyaratan baru setiap tahun
Pertumbuhan infrastruktur dan awal perjalanan
Jumlah server/domain logis/pusat data bertambah, dan seiring dengan itu, jumlah kesalahan dalam konfigurasi. Pada titik tertentu, kami sampai pada tiga arah di mana manajemen konfigurasi perlu dikembangkan:
- Otomatisasi. Kesalahan manusia dalam operasi berulang harus dihindari sebisa mungkin.
- Pengulangan. Mengelola infrastruktur akan jauh lebih mudah jika hal tersebut dapat diprediksi. Konfigurasi server dan alat untuk persiapannya harus sama di semua tempat. Hal ini juga penting bagi tim produk - setelah pengujian, aplikasi harus dijamin berada di lingkungan produksi yang dikonfigurasi serupa dengan lingkungan pengujian.
- Kesederhanaan dan transparansi dalam melakukan perubahan pada manajemen konfigurasi.
Masih menambahkan beberapa alat.
Kami memilih GitLab CE sebagai tempat penyimpanan kode kami, terutama untuk modul CI/CD bawaannya.
Gudang rahasia - Hashicorp Vault, termasuk. untuk API yang hebat.
Menguji konfigurasi dan peran yang memungkinkan – Molekul+Testinfra. Pengujian berjalan lebih cepat jika Anda terhubung ke mitogen yang memungkinkan. Pada saat yang sama, kami mulai menulis CMDB dan orkestrator kami sendiri untuk penerapan otomatis (pada gambar di atas Cobbler), tetapi ini adalah cerita yang sama sekali berbeda, yang akan diceritakan oleh rekan saya dan pengembang utama sistem ini di masa mendatang.
Pilihan kita:
Molekul + Testinfra
Kemungkinan + Menara + AWX
Dunia Server + DITNET (Pengembangan sendiri)
Tukang sepatu
Pelari Gitlab + GitLab
Gudang Hashicorp
Berbicara tentang kemungkinan peran. Awalnya hanya ada satu, tapi setelah beberapa kali refactoring ada 17. Saya sangat menyarankan untuk memecah monolit menjadi peran idempoten, yang kemudian dapat diluncurkan secara terpisah; selain itu, Anda dapat menambahkan tag. Kami membagi peran berdasarkan fungsionalitas - jaringan, logging, paket, perangkat keras, molekul, dll. Secara umum, kami mengikuti strategi di bawah ini. Saya tidak bersikeras bahwa ini adalah satu-satunya kebenaran, tetapi ini berhasil bagi kami.
- Menyalin server dari “gambar emas” itu jahat!Kerugian utamanya adalah Anda tidak tahu persis keadaan gambar saat ini, dan semua perubahan akan terjadi pada semua gambar di semua kumpulan virtualisasi.
- Gunakan file konfigurasi default seminimal mungkin dan sepakati dengan departemen lain bahwa Anda bertanggung jawab atas file sistem utama, misalnya:
- Biarkan /etc/sysctl.conf kosong, pengaturannya hanya boleh di /etc/sysctl.d/. Default Anda di satu file, khusus untuk aplikasi di file lain.
- Gunakan file override untuk mengedit unit systemd.
- Templat semua konfigurasi dan sertakan seluruhnya; jika memungkinkan, tidak ada sed atau analognya dalam buku pedoman
- Memfaktorkan ulang kode sistem manajemen konfigurasi:
- Bagi tugas menjadi entitas logis dan tulis ulang monolit menjadi peran
- Gunakan linter! Serat yang mungkin, serat yaml, dll
- Ubah pendekatan Anda! Tidak bisa dihancurkan. Hal ini diperlukan untuk menggambarkan keadaan sistem
- Untuk semua peran yang memungkinkan, Anda perlu menulis tes dalam molekul dan membuat laporan sekali sehari.
- Dalam kasus kami, setelah persiapan pengujian (yang jumlahnya lebih dari 100), ditemukan sekitar 70000 kesalahan. Butuh beberapa bulan untuk memperbaikinya.
Implementasi kami
Jadi, peran yang memungkinkan telah siap, dibuat templatenya, dan diperiksa oleh linter. Dan bahkan git pun muncul di mana-mana. Namun pertanyaan tentang pengiriman kode yang andal ke berbagai segmen tetap terbuka. Kami memutuskan untuk melakukan sinkronisasi dengan skrip. Sepertinya itu:
Setelah perubahan terjadi, CI diluncurkan, server pengujian dibuat, peran diluncurkan, dan diuji oleh molekul. Jika semuanya baik-baik saja, kode masuk ke cabang prod. Namun kami tidak menerapkan kode baru ke server yang ada di mesin. Ini adalah semacam penghenti yang diperlukan untuk ketersediaan tinggi sistem kami. Dan ketika infrastruktur menjadi sangat besar, hukum jumlah besar pun mulai berlaku - bahkan jika Anda yakin bahwa perubahan tersebut tidak berbahaya, hal ini dapat menimbulkan konsekuensi yang mengerikan.
Ada juga banyak pilihan untuk membuat server. Kami akhirnya memilih skrip Python khusus. Dan untuk CI memungkinkan:
- 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 kami capai, sistem terus hidup dan berkembang.
- 17 Kemungkinan peran untuk menyiapkan server. Masing-masing peran dirancang untuk menyelesaikan tugas logis yang terpisah (logging, audit, otorisasi pengguna, pemantauan, dll.).
- Pengujian peran. Molekul + TestInfra.
- Pengembangan sendiri: CMDB + Orchestrator.
- Waktu pembuatan server ~30 menit, otomatis dan praktis tidak bergantung pada antrian tugas.
- Status/penamaan infrastruktur yang sama di semua segmen - pedoman, repositori, elemen virtualisasi.
- Pemeriksaan harian status server dengan pembuatan laporan tentang ketidaksesuaian dengan standar.
Semoga cerita saya bermanfaat bagi mereka yang sedang berada di awal perjalanannya. Tumpukan otomatisasi apa yang Anda gunakan?
Sumber: www.habr.com