Peralatan tersebut tiba di lokasi beberapa bulan sebelum puncak penjualan. Layanan pemeliharaan, tentu saja, tahu bagaimana dan apa yang harus diatur pada server untuk memperkenalkan mereka ke dalam lingkungan produksi. Tapi kami perlu mengotomatiskan ini dan menghilangkan faktor manusia. Selain itu, server diganti sebelum migrasi satu set sistem SAP yang penting bagi perusahaan.
Komisioning server baru terikat erat dengan tenggat waktu. Dan untuk memindahkannya akan membahayakan pengiriman miliaran hadiah dan migrasi sistem. Bahkan tim yang terdiri dari Sinterklas dan Sinterklas tidak dapat mengubah tanggal - sistem SAP untuk manajemen gudang hanya dapat ditransfer setahun sekali. Dari 31 Desember hingga 1 Januari, gudang besar pengecer, total 20 lapangan sepak bola, berhenti bekerja selama 15 jam. Dan ini adalah satu-satunya periode waktu bagi sistem untuk bergerak. Kami tidak berhak membuat kesalahan dengan memasuki server.
Izinkan saya menjelaskan langsung: cerita saya mencerminkan alat dan proses manajemen konfigurasi yang digunakan tim kami.
Kompleks manajemen konfigurasi terdiri dari beberapa level. Komponen utamanya adalah sistem CMS. Dalam eksploitasi industri, ketiadaan salah satu level pasti akan menyebabkan keajaiban yang tidak menyenangkan.
Manajemen instalasi OS
Tingkat pertama adalah sistem untuk mengelola instalasi sistem operasi pada server fisik dan virtual. Ini menciptakan konfigurasi OS dasar, menghilangkan faktor manusia.
Dengan bantuan sistem ini, kami menerima standar dan cocok untuk contoh otomatisasi lebih lanjut dari server dengan OS. Saat dilemparkan, mereka menerima sekumpulan minimal pengguna lokal dan kunci SSH publik, serta konfigurasi OS yang konsisten. Kami dijamin dapat mengelola server melalui CMS dan yakin bahwa tidak ada kejutan "di bawah", di tingkat OS.
Target maksimum untuk sistem manajemen instalasi adalah mengkonfigurasi server secara otomatis dari tingkat BIOS / Firmware ke OS. Banyak hal tergantung pada perangkat keras dan tugas konfigurasi. Untuk peralatan yang berbeda, pertimbangkan API REDFISH... Jika semua perangkat keras berasal dari satu vendor, maka seringkali lebih nyaman menggunakan alat manajemen yang sudah jadi (misalnya, HP ILO Amplifier, DELL OpenManage, dll.).
Untuk menginstal OS pada server fisik, kami menggunakan Cobbler yang terkenal, yang mendefinisikan sekumpulan profil instalasi yang dikoordinasikan dengan layanan pemeliharaan. Saat menambahkan server baru ke infrastruktur, teknisi akan mengikat alamat MAC server ke profil yang diperlukan di Cobbler. Pada boot pertama melalui jaringan, server menerima alamat sementara dan OS baru. Kemudian ditransfer ke pengalamatan VLAN / IP target dan terus bekerja di sana. Ya, mengubah VLAN membutuhkan waktu dan memerlukan koordinasi, tetapi ini memberikan perlindungan tambahan terhadap penginstalan server yang tidak disengaja dalam lingkungan produksi.
Kami membuat server virtual berdasarkan template yang disiapkan menggunakan HashiCorp Packer. Alasannya sama: untuk mencegah kemungkinan kesalahan manusia saat menginstal OS. Namun, tidak seperti server fisik, Packer memungkinkan Anda untuk tidak menggunakan PXE, boot jaringan, dan perubahan VLAN. Ini mempermudah dan mempermudah pembuatan server virtual.
Angka: 1. Manajemen instalasi sistem operasi.
Manajemen rahasia
Setiap sistem manajemen konfigurasi berisi data yang harus disembunyikan dari pengguna biasa, tetapi diperlukan untuk menyiapkan sistem. Ini adalah sandi pengguna lokal dan akun layanan, kunci sertifikat, berbagai Token API, dll. Biasanya disebut "rahasia".
Jika sejak awal tidak ditentukan di mana dan bagaimana menyimpan rahasia ini, maka, tergantung pada tingkat keparahan persyaratan IS, metode penyimpanan berikut mungkin:
- tepat di kode manajemen konfigurasi atau di file di repositori;
- dalam alat manajemen konfigurasi khusus (misalnya, Ansible Vault);
- dalam sistem CI / CD (Jenkins / TeamCity / GitLab /, dll.) atau dalam sistem manajemen konfigurasi (Ansible Tower / Ansible AWX);
- juga rahasia dapat ditransfer ke "kontrol manual". Misalnya, mereka diletakkan di tempat yang disepakati, dan kemudian digunakan oleh sistem manajemen konfigurasi;
- berbagai kombinasi di atas.
Setiap metode memiliki kekurangannya sendiri. Yang utama adalah tidak adanya kebijakan untuk mengakses rahasia: tidak mungkin atau sulit untuk menentukan siapa yang dapat menggunakan rahasia tertentu. Kerugian lainnya adalah kurangnya audit akses dan siklus hidup yang penuh. Bagaimana cara cepat mengganti, misalnya, kunci publik, yang tertulis dalam kode dan di sejumlah sistem terkait?
Kami menggunakan HashiCorp Vault terpusat. Ini memungkinkan kami untuk:
- jaga rahasia tetap aman. Mereka dienkripsi, dan bahkan jika seseorang memperoleh akses ke database Vault (misalnya, dengan memulihkannya dari cadangan), mereka tidak akan dapat membaca rahasia yang disimpan di sana;
- . «» ;
- . Vault;
- « » . , , . .
- , ;
- , , ..
Sekarang mari beralih ke sistem otentikasi dan otorisasi pusat. Anda dapat melakukannya tanpa itu, tetapi mengelola pengguna di banyak sistem terkait terlalu sepele. Kami telah mengonfigurasi otentikasi dan otorisasi melalui layanan LDAP. Jika tidak, Vault yang sama harus terus mengeluarkan dan menyimpan catatan token autentikasi untuk pengguna. Dan menghapus serta menambahkan pengguna akan berubah menjadi misi "Apakah saya telah membuat / menghapus UZ ini di mana-mana?"
Kami menambahkan satu level lagi ke sistem kami: manajemen rahasia dan otentikasi / otorisasi pusat:
Angka: 2. Pengelolaan rahasia.
Manajemen konfigurasi
Kami sampai pada intinya - ke sistem CMS. Dalam kasus kami, ini adalah sekumpulan Ansible dan Red Hat Ansible AWX.
Chef, Puppet, SaltStack dapat bertindak sebagai pengganti Ansible. Kami memilih Ansible karena beberapa kriteria.
- Pertama, keserbagunaan. Kumpulan modul siap pakai untuk kontrol sangat mengesankan . Dan jika Anda tidak memiliki cukup, Anda dapat mencari di GitHub dan Galaxy.
- Kedua, tidak perlu menginstal dan memelihara agen pada peralatan yang dikontrol, untuk membuktikan bahwa mereka tidak mengganggu beban, dan untuk mengkonfirmasi tidak adanya "bookmark".
- Ketiga, Ansible memiliki penghalang masuk yang rendah. Seorang insinyur yang kompeten akan menulis pedoman kerja secara harfiah pada hari pertama bekerja dengan produk.
Tetapi Ansible saja tidak cukup bagi kami di lingkungan industri. Jika tidak, akan ada banyak masalah dengan pembatasan akses dan audit tindakan administrator. Bagaimana cara membedakan akses? Lagi pula, setiap divisi perlu mengelola (baca - jalankan buku pedoman Ansible) kumpulan server "nya". Bagaimana saya hanya mengizinkan karyawan tertentu untuk menjalankan buku pedoman yang Mungkin? Atau bagaimana cara melacak siapa yang meluncurkan pedoman tanpa menjalankan banyak KM lokal di server dan perangkat keras yang memungkinkan?
Red Hat Ansible Tower , atau proyek hulu sumber terbuka Ansible AWX, memecahkan sebagian besar masalah tersebut . Oleh karena itu, kami lebih memilihnya untuk pelanggan.
Dan satu sentuhan lagi untuk potret sistem CMS kami. Playbook yang memungkinkan harus disimpan dalam sistem manajemen repositori kode. Kami memiliki GitLab CE ini .
Jadi, konfigurasinya sendiri dikelola oleh bundel dari Ansible / Ansible AWX / GitLab (lihat Gambar 3). Tentu saja, AWX / GitLab terintegrasi dengan sistem otentikasi terpadu, dan buku pedoman Ansible terintegrasi dengan HashiCorp Vault. Konfigurasi memasuki lingkungan produksi hanya melalui Ansible AWX, di mana semua "aturan permainan" ditetapkan: siapa dan apa yang dapat dikonfigurasi, di mana mendapatkan kode manajemen konfigurasi untuk CMS, dll.
Angka: 3. Manajemen konfigurasi.
Manajemen tes
Konfigurasi kami disajikan sebagai kode. Oleh karena itu, kami dipaksa untuk bermain dengan aturan yang sama seperti pengembang perangkat lunak. Kami perlu mengatur proses pengembangan, pengujian berkelanjutan, pengiriman, dan penerapan kode konfigurasi ke server produksi.
Jika ini tidak segera dilakukan, maka peran tertulis untuk konfigurasi akan berhenti dipertahankan dan dimodifikasi, atau akan berhenti berjalan dalam produksi. Obat untuk rasa sakit ini diketahui, dan itu terbayar dalam proyek ini:
- setiap peran dicakup oleh tes unit;
- tes dijalankan secara otomatis setiap kali ada perubahan dalam kode manajemen konfigurasi;
- perubahan dalam kode manajemen konfigurasi memasuki lingkungan produksi hanya setelah berhasil melewati semua tes dan tinjauan kode.
Pengembangan kode dan manajemen konfigurasi lebih tenang dan lebih dapat diprediksi. Untuk mengatur pengujian berkelanjutan, kami menggunakan toolkit GitLab CI / CD, dan kami menggunakan Ansible Molecule sebagai kerangka kerja untuk mengatur pengujian .
Untuk setiap perubahan dalam kode manajemen konfigurasi, GitLab CI / CD memanggil Molekul:
- itu memeriksa sintaks kode,
- mengangkat kontainer Docker,
- menerapkan kode yang dimodifikasi ke penampung yang dihasilkan,
- memeriksa peran idempotensi dan menjalankan pengujian untuk kode ini (perincian di sini berada pada tingkat peran yang memungkinkan, lihat Gambar 4).
Kami mengirimkan konfigurasi ke lingkungan produksi menggunakan Ansible AWX. Para insinyur operasional menerapkan perubahan konfigurasi melalui templat yang telah ditentukan sebelumnya. AWX secara independen "meminta" versi kode terbaru dari cabang master GitLab setiap kali digunakan. Dengan cara ini kami mengecualikan penggunaan kode yang belum teruji atau kedaluwarsa di lingkungan produksi. Secara alami, kode masuk ke cabang master hanya setelah pengujian, peninjauan, dan persetujuan.
Angka: 4. Pengujian otomatis peran dalam GitLab CI / CD.
Ada juga masalah yang terkait dengan pengoperasian sistem produksi. Dalam kehidupan nyata, sangat sulit untuk membuat perubahan konfigurasi hanya melalui kode CMS. Situasi abnormal muncul ketika seorang insinyur harus mengubah konfigurasi "di sini dan sekarang" tanpa menunggu pengeditan kode, pengujian, persetujuan, dll.
Akibatnya, karena perubahan manual, perbedaan muncul dalam konfigurasi pada jenis peralatan yang sama (misalnya, pada node cluster HA konfigurasi yang berbeda dari pengaturan sysctl). Atau konfigurasi sebenarnya pada perangkat keras berbeda dari yang ditetapkan dalam kode CMS.
Oleh karena itu, selain pengujian berkelanjutan, kami memeriksa lingkungan produksi untuk mengetahui perbedaan konfigurasi. Kami memilih opsi paling sederhana: menjalankan kode konfigurasi CMS dalam mode "uji coba", yaitu, tanpa menerapkan perubahan, tetapi dengan pemberitahuan tentang semua perbedaan antara konfigurasi yang direncanakan dan yang sebenarnya. Kami telah menerapkan ini dengan menjalankan semua buku pedoman Ansible secara berkala dengan opsi "--check" di server produksi. Ansible AWX, seperti biasa, bertanggung jawab atas peluncuran dan relevansi pedoman tersebut (lihat Gambar 5):
Angka: 5. Memeriksa perbedaan konfigurasi di Ansible AWX.
Setelah pemeriksaan, AWX mengirimkan laporan ketidaksesuaian ke administrator. Mereka mempelajari konfigurasi masalah dan kemudian memperbaikinya melalui pedoman yang disesuaikan. Dengan cara ini kami menjaga konfigurasi di lingkungan produksi dan CMS selalu diperbarui dan disinkronkan. Ini menghilangkan "keajaiban" yang tidak menyenangkan ketika kode CMS diterapkan pada server "produksi".
Kami sekarang memiliki lapisan pengujian penting yang terdiri dari Ansible AWX / GitLab / Molecule (Gambar 6).
Angka: 6. Manajemen pengujian.
Keras? Saya tidak membantah. Tetapi kompleks manajemen konfigurasi seperti itu telah menjadi jawaban komprehensif untuk banyak pertanyaan yang berkaitan dengan otomatisasi konfigurasi server. Sekarang pengecer selalu memiliki konfigurasi yang ditentukan secara ketat untuk server standar. CMS, tidak seperti seorang insinyur, tidak akan lupa untuk menambahkan pengaturan yang diperlukan, membuat pengguna dan melakukan puluhan atau ratusan pengaturan yang diperlukan.
Tidak ada "pengetahuan rahasia" dalam pengaturan server dan lingkungan saat ini. Semua fitur yang diperlukan tercermin dalam pedoman. Tidak ada lagi kreativitas dan instruksi yang tidak jelas: “ letakkan seperti Oracle biasa, tetapi di sana Anda perlu mendaftarkan beberapa pengaturan sysctl, dan menambahkan pengguna dengan UID yang diperlukan. Tanya orang-orang dari operasi, mereka tahu . "
Kemampuan untuk mendeteksi perbedaan dalam konfigurasi dan memperbaikinya terlebih dahulu memberikan ketenangan pikiran. Tanpa CMS, ini biasanya terlihat berbeda. Masalah menumpuk sampai suatu hari mereka "ditembak" dalam produksi. Kemudian pembekalan dilakukan, konfigurasi diperiksa dan diperbaiki. Dan siklusnya berulang lagi
Dan tentu saja, kami telah mempercepat peluncuran server dalam produksi dari beberapa hari menjadi beberapa jam.
Nah, pada Malam Tahun Baru itu sendiri, ketika anak-anak dengan senang hati membuka bungkus kado dan orang dewasa mengucapkan doa, teknisi kami memigrasi sistem SAP ke server baru. Bahkan Sinterklas akan mengatakan bahwa mukjizat terbaik adalah yang dipersiapkan dengan baik.
PS Tim kami sering dihadapkan pada kenyataan bahwa pelanggan ingin menyelesaikan masalah manajemen konfigurasi semudah mungkin. Idealnya, seolah-olah sulap - dengan satu alat. Namun dalam hidup, semuanya lebih rumit (ya, sekali lagi, peluru perak tidak terkirim): Anda harus membuat seluruh proses menggunakan alat yang nyaman bagi tim pelanggan.
Penulis: Sergey Artemov, arsitek departemen solusi DevOps di Jet Infosystems