Saat itu mendekati Tahun Baru. Anak-anak di seluruh negeri telah mengirim surat kepada Sinterklas atau membuat hadiah untuk diri mereka sendiri, dan pelaksana utama mereka, salah satu pengecer besar, sedang mempersiapkan pendewaan penjualan. Pada bulan Desember, beban pada pusat datanya meningkat beberapa kali lipat. Oleh karena itu, perusahaan memutuskan untuk memodernisasi pusat data dan mengoperasikan beberapa lusin server baru alih-alih peralatan yang sudah mencapai akhir masa pakainya. Ini mengakhiri kisah dengan latar belakang kepingan salju yang berputar-putar, dan film thriller pun dimulai.
Peralatan tersebut tiba di lokasi beberapa bulan sebelum puncak penjualan. Layanan operasi, tentu saja, mengetahui bagaimana dan apa yang harus dikonfigurasi di server untuk membawanya ke lingkungan produksi. Namun kami perlu mengotomatiskan hal ini dan menghilangkan faktor manusia. Selain itu, server diganti sebelum migrasi serangkaian sistem SAP yang penting bagi perusahaan.
Pengoperasian server baru sangat terikat pada tenggat waktu. Dan memindahkannya berarti membahayakan pengiriman satu miliar hadiah dan migrasi sistem. Bahkan tim yang terdiri dari Pastor Frost dan Santa Claus tidak dapat mengubah tanggal - Anda hanya dapat mentransfer sistem SAP untuk manajemen gudang setahun sekali. Dari tanggal 31 Desember hingga 1 Januari, gudang besar milik pengecer, yang totalnya berukuran 20 lapangan sepak bola, berhenti bekerja selama 15 jam. Dan ini adalah satu-satunya jangka waktu untuk memindahkan sistem. Kami tidak mempunyai ruang untuk kesalahan saat memperkenalkan server.
Biar saya perjelas: cerita saya mencerminkan alat dan proses manajemen konfigurasi yang digunakan tim kami.
Kompleks manajemen konfigurasi terdiri dari beberapa tingkatan. Komponen kuncinya adalah sistem CMS. Dalam operasi industri, tidak adanya salah satu level pasti akan menimbulkan 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 menggunakan sistem ini, kami menerima contoh server standar dengan OS yang cocok untuk otomatisasi lebih lanjut. Selama "penuangan" mereka menerima set minimum 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.
Tugas "maksimum" untuk sistem manajemen instalasi adalah mengkonfigurasi server secara otomatis dari tingkat BIOS/Firmware hingga OS. Banyak hal di sini bergantung pada peralatan dan tugas pengaturan. Untuk peralatan heterogen, Anda dapat mempertimbangkan . Jika semua perangkat keras berasal dari satu vendor, seringkali lebih mudah menggunakan alat manajemen yang sudah jadi (misalnya, HP ILO Amplifier, DELL OpenManage, dll.).
Untuk menginstal OS di server fisik, kami menggunakan Cobbler yang terkenal, yang mendefinisikan serangkaian profil instalasi yang disetujui dengan layanan operasi. Saat menambahkan server baru ke infrastruktur, teknisi mengikat alamat MAC server ke profil yang diperlukan di Cobbler. Saat booting melalui jaringan untuk pertama kalinya, server menerima alamat sementara dan OS baru. Kemudian ditransfer ke alamat VLAN/IP target dan melanjutkan pekerjaan di sana. Ya, mengubah VLAN memerlukan waktu dan koordinasi, namun memberikan perlindungan tambahan terhadap instalasi server yang tidak disengaja di lingkungan produksi.
Kami membuat server virtual berdasarkan templat yang disiapkan menggunakan HashiСorp Packer. Alasannya sama: untuk mencegah kemungkinan kesalahan manusia saat menginstal OS. Namun, tidak seperti server fisik, Packer menghilangkan kebutuhan akan PXE, booting jaringan, dan perubahan VLAN. Ini menjadikannya lebih mudah dan sederhana untuk membuat server virtual.
Beras. 1. Mengelola instalasi sistem operasi.
Mengelola rahasia
Setiap sistem manajemen konfigurasi berisi data yang harus disembunyikan dari pengguna biasa, namun diperlukan untuk mempersiapkan sistem. Ini adalah kata sandi untuk pengguna lokal dan akun layanan, kunci sertifikat, berbagai Token API, dll. Biasanya disebut “rahasia”.
Jika Anda tidak menentukan sejak awal di mana dan bagaimana menyimpan rahasia ini, maka, tergantung pada tingkat keparahan persyaratan keamanan informasi, kemungkinan besar metode penyimpanan berikut akan digunakan:
- langsung di kode kontrol 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);
- rahasia juga dapat ditransfer “secara manual”. Misalnya, mereka diletakkan di lokasi tertentu, dan kemudian digunakan oleh sistem manajemen konfigurasi;
- berbagai kombinasi di atas.
Setiap metode memiliki kelemahannya masing-masing. Yang utama adalah kurangnya kebijakan untuk akses terhadap 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 penyimpanan rahasia terpusat HashiCorp Vault. Hal ini memungkinkan kami:
- menjaga 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;
- mengatur kebijakan untuk akses ke rahasia. Hanya rahasia yang “dialokasikan” kepada mereka yang tersedia bagi pengguna dan aplikasi;
- mengaudit akses ke rahasia. Setiap tindakan yang mengandung rahasia dicatat dalam log audit Vault;
- mengatur “siklus hidup” penuh dalam bekerja dengan rahasia. Mereka dapat dibuat, dicabut, menetapkan tanggal kedaluwarsa, dll.
- mudah diintegrasikan dengan sistem lain yang memerlukan akses ke rahasia;
- dan juga menggunakan enkripsi ujung ke ujung, kata sandi satu kali untuk OS dan database, sertifikat dari pusat resmi, dll.
Sekarang mari kita beralih ke sistem otentikasi dan otorisasi pusat. Itu mungkin dilakukan tanpanya, tetapi mengelola pengguna di banyak sistem terkait adalah hal yang terlalu sepele. Kami telah mengkonfigurasi otentikasi dan otorisasi melalui layanan LDAP. Jika tidak, Vault harus terus menerbitkan dan melacak token autentikasi untuk pengguna. Dan menghapus dan menambahkan pengguna akan berubah menjadi pertanyaan “apakah saya membuat/menghapus akun pengguna ini di mana saja?”
Kami menambahkan level lain ke sistem kami: manajemen rahasia dan otentikasi/otorisasi pusat:
Beras. 2. Manajemen rahasia.
Manajemen konfigurasi
Kami sampai pada intinya - sistem CMS. Dalam kasus kami, ini adalah kombinasi Ansible dan Red Hat Ansible AWX.
Alih-alih Ansible, Chef, Puppet, SaltStack dapat digunakan. Kami memilih Ansible berdasarkan beberapa kriteria.
- Pertama, ini adalah keserbagunaan. Satu set modul siap pakai untuk kontrol . Dan jika Anda belum memiliki cukup, Anda dapat mencari di GitHub dan Galaxy.
- Kedua, tidak perlu memasang dan mendukung agen pada peralatan yang dikelola, membuktikan bahwa mereka tidak mengganggu beban, dan memastikan tidak adanya “bookmark”.
- Ketiga, Ansible memiliki hambatan masuk yang rendah. Seorang insinyur yang kompeten akan menulis pedoman kerja secara harfiah pada hari pertama bekerja dengan produk.
Namun Ansible saja dalam lingkungan produksi tidak cukup bagi kami. Jika tidak, banyak masalah akan timbul dalam membatasi akses dan mengaudit tindakan administrator. Bagaimana cara membatasi akses? Lagi pula, setiap departemen perlu mengelola (baca: menjalankan buku pedoman Ansible) kumpulan server “sendiri”. Bagaimana cara mengizinkan hanya karyawan tertentu untuk menjalankan pedoman Ansible tertentu? Atau bagaimana cara melacak siapa yang meluncurkan pedoman tanpa menyiapkan banyak pengetahuan lokal di server dan peralatan yang menjalankan Ansible?
Sebagian besar masalah tersebut diselesaikan oleh Red Hat , atau proyek hulu sumber terbuka miliknya . Itu sebabnya kami lebih memilihnya untuk pelanggan.
Dan satu sentuhan lagi pada potret sistem CMS kami. Buku pedoman yang memungkinkan harus disimpan dalam sistem manajemen repositori kode. Kami memilikinya .
Jadi, konfigurasinya sendiri dikelola oleh kombinasi Ansible/Ansible AWX/GitLab (lihat Gambar 3). Tentu saja, AWX/GitLab terintegrasi dengan sistem otentikasi tunggal, dan buku pedoman Ansible terintegrasi dengan HashiCorp Vault. Konfigurasi memasuki lingkungan produksi hanya melalui Ansible AWX, di mana semua "aturan permainan" ditentukan: siapa yang dapat mengonfigurasi apa, di mana mendapatkan kode manajemen konfigurasi untuk CMS, dll.
Beras. 3. Manajemen konfigurasi.
Manajemen tes
Konfigurasi kami disajikan dalam bentuk kode. Oleh karena itu, kami dipaksa untuk mengikuti aturan yang sama seperti pengembang perangkat lunak. Kami perlu mengatur proses pengembangan, pengujian berkelanjutan, pengiriman dan penerapan kode konfigurasi ke server produksi.
Jika hal ini tidak segera dilakukan, maka peran yang ditulis untuk konfigurasi tersebut akan berhenti didukung dan dimodifikasi, atau akan berhenti diluncurkan dalam produksi. Obat untuk rasa sakit ini telah diketahui, dan telah terbukti dalam proyek ini:
- setiap peran dicakup oleh pengujian unit;
- pengujian dijalankan secara otomatis setiap kali ada perubahan pada kode yang mengelola konfigurasi;
- perubahan dalam kode manajemen konfigurasi dilepaskan ke lingkungan produksi hanya setelah berhasil melewati semua pengujian dan peninjauan kode.
Pengembangan kode dan manajemen konfigurasi menjadi lebih tenang dan dapat diprediksi. Untuk mengatur pengujian berkelanjutan, kami menggunakan toolkit GitLab CI/CD, dan mengambil .
Setiap kali ada perubahan dalam kode manajemen konfigurasi, GitLab CI/CD memanggil Molecule:
- itu memeriksa sintaks kode,
- memunculkan wadah Docker,
- menerapkan kode yang dimodifikasi ke wadah yang dibuat,
- memeriksa peran untuk 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. Insinyur operasi menerapkan perubahan konfigurasi melalui templat yang telah ditentukan sebelumnya. AWX secara independen “meminta” versi terbaru kode dari cabang master GitLab setiap kali digunakan. Dengan cara ini kami mengecualikan penggunaan kode yang belum teruji atau ketinggalan jaman di lingkungan produksi. Biasanya, kode tersebut masuk ke cabang master hanya setelah pengujian, peninjauan, dan persetujuan.
Beras. 4. Pengujian otomatis peran di 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 darurat muncul ketika seorang insinyur harus mengubah konfigurasi “di sini dan saat ini”, tanpa menunggu pengeditan kode, pengujian, persetujuan, dll.
Akibatnya, karena perubahan manual, perbedaan muncul dalam konfigurasi pada jenis peralatan yang sama (misalnya, pengaturan sysctl dikonfigurasi secara berbeda pada node cluster HA). Atau konfigurasi sebenarnya pada peralatan berbeda dengan yang ditentukan dalam kode CMS.
Oleh karena itu, selain pengujian berkelanjutan, kami memeriksa lingkungan produksi untuk mengetahui adanya perbedaan konfigurasi. Kami memilih opsi paling sederhana: menjalankan kode konfigurasi CMS dalam mode "dry run", yaitu, tanpa menerapkan perubahan, tetapi dengan pemberitahuan semua perbedaan antara konfigurasi yang direncanakan dan konfigurasi sebenarnya. Kami menerapkan ini dengan menjalankan semua buku pedoman Ansible secara berkala dengan opsi “—check” di server produksi. Seperti biasa, Ansible AWX bertanggung jawab untuk meluncurkan dan menjaga agar pedoman tetap mutakhir (lihat Gambar 5):
Beras. 5. Memeriksa perbedaan konfigurasi di Ansible AWX.
Setelah pemeriksaan, AWX mengirimkan laporan ketidaksesuaian ke administrator. Mereka mempelajari konfigurasi yang bermasalah dan kemudian memperbaikinya melalui pedoman yang disesuaikan. Ini adalah cara kami menjaga konfigurasi di lingkungan produksi dan CMS selalu terbarui dan tersinkronisasi. Ini menghilangkan “keajaiban” yang tidak menyenangkan ketika kode CMS digunakan pada server “produksi”.
Kami sekarang memiliki lapisan pengujian penting yang terdiri dari Ansible AWX/GitLab/Molecule (Gambar 6).
Beras. 6. Manajemen tes.
Sulit? Saya tidak membantah. Namun manajemen konfigurasi yang sedemikian kompleks telah menjadi jawaban komprehensif atas banyak pertanyaan terkait otomatisasi konfigurasi server. Sekarang server standar pengecer selalu memiliki konfigurasi yang ditentukan secara ketat. CMS, tidak seperti seorang insinyur, tidak akan lupa menambahkan pengaturan yang diperlukan, membuat pengguna dan melakukan lusinan 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: “Instal seperti Oracle biasa, tetapi Anda perlu menentukan beberapa pengaturan sysctl dan menambahkan pengguna dengan UID yang diperlukan. Tanyakan kepada orang-orang yang bertugas, mereka tahu'.
Kemampuan untuk mendeteksi perbedaan konfigurasi dan memperbaikinya secara proaktif memberikan ketenangan pikiran. Tanpa sistem manajemen konfigurasi, hal ini biasanya terlihat berbeda. Masalah menumpuk hingga suatu hari mereka “menembak” ke dalam produksi. Kemudian dilakukan pembekalan, konfigurasi diperiksa dan diperbaiki. Dan siklus itu berulang lagi
Dan tentu saja, kami mempercepat peluncuran server ke dalam operasi dari beberapa hari menjadi beberapa jam.
Nah, pada Malam Tahun Baru, ketika anak-anak dengan gembira membuka bungkus kado dan orang dewasa mengucapkan permohonan saat lonceng berbunyi, teknisi kami memigrasikan sistem SAP ke server baru. Bahkan Sinterklas akan berkata bahwa mukjizat terbaik adalah mukjizat yang dipersiapkan dengan baik.
PS Tim kami sering menghadapi kenyataan bahwa pelanggan ingin menyelesaikan masalah manajemen konfigurasi sesederhana mungkin. Idealnya, seperti sulap - dengan satu alat. Namun dalam hidup, segalanya menjadi lebih rumit (ya, solusi terbaik tidak diberikan lagi): Anda harus membuat keseluruhan proses menggunakan alat yang nyaman bagi tim pelanggan.
Penulis: Sergey Artemov, arsitek departemen "Sistem Info Jet"
Sumber: www.habr.com
