Ia menghampiri Tahun Baru. Kanak-kanak di seluruh negara telah menghantar surat kepada Santa Claus atau membuat hadiah untuk diri mereka sendiri, dan pelaksana utama mereka, salah satu peruncit utama, sedang bersiap untuk apotheosis penjualan. Pada bulan Disember, beban pada pusat datanya meningkat beberapa kali. Oleh itu, syarikat itu memutuskan untuk memodenkan pusat data dan menjalankan beberapa dozen pelayan baharu dan bukannya peralatan yang mencapai penghujung hayat perkhidmatannya. Ini menamatkan kisah berlatar belakangkan kepingan salji yang berputar, dan thriller bermula.

Peralatan tiba di tapak beberapa bulan sebelum kemuncak jualan. Perkhidmatan operasi, sudah tentu, tahu bagaimana dan apa yang perlu dikonfigurasikan pada pelayan untuk membawanya ke dalam persekitaran pengeluaran. Tetapi kami perlu mengautomasikan ini dan menghapuskan faktor manusia. Di samping itu, pelayan telah diganti sebelum penghijrahan set sistem SAP yang penting untuk syarikat.

Pentauliahan pelayan baharu terikat dengan tarikh akhir. Dan memindahkannya bermakna membahayakan penghantaran satu bilion hadiah dan penghijrahan sistem. Malah pasukan yang terdiri daripada Father Frost dan Santa Claus tidak dapat mengubah tarikh - anda boleh memindahkan sistem SAP untuk pengurusan gudang hanya sekali setahun. Dari 31 Disember hingga 1 Januari, gudang besar peruncit itu, secara keseluruhannya bersaiz 20 padang bola, menghentikan kerja mereka selama 15 jam. Dan ini adalah satu-satunya tempoh masa untuk memindahkan sistem. Kami tidak mempunyai ruang untuk ralat semasa memperkenalkan pelayan.

Biar saya jelas: cerita saya mencerminkan alatan dan proses pengurusan konfigurasi yang digunakan oleh pasukan kami.

Kompleks pengurusan konfigurasi terdiri daripada beberapa peringkat. Komponen utama ialah sistem CMS. Dalam operasi perindustrian, ketiadaan salah satu tahap pasti akan membawa kepada keajaiban yang tidak menyenangkan.

Pengurusan pemasangan OS

Tahap pertama ialah sistem untuk menguruskan pemasangan sistem pengendalian pada pelayan fizikal dan maya. Ia mencipta konfigurasi OS asas, menghapuskan faktor manusia.

Menggunakan sistem ini, kami menerima contoh pelayan standard dengan OS yang sesuai untuk automasi selanjutnya. Semasa "menuangkan" mereka menerima set minimum pengguna tempatan dan kunci SSH awam, serta konfigurasi OS yang konsisten. Kami boleh dijamin untuk menguruskan pelayan melalui CMS dan pasti bahawa tiada kejutan "di bawah" pada peringkat OS.

Tugas "maksimum" untuk sistem pengurusan pemasangan adalah untuk mengkonfigurasi pelayan secara automatik dari peringkat BIOS/Perisian tegar ke OS. Banyak di sini bergantung pada peralatan dan tugas persediaan. Untuk peralatan heterogen, anda boleh pertimbangkan API IKAN MERAH. Jika semua perkakasan adalah daripada satu vendor, maka selalunya lebih mudah untuk menggunakan alatan pengurusan siap pakai (contohnya, Penguat ILO HP, DELL OpenManage, dsb.).

Untuk memasang OS pada pelayan fizikal, kami menggunakan Cobbler yang terkenal, yang mentakrifkan satu set profil pemasangan yang dipersetujui dengan perkhidmatan operasi. Apabila menambah pelayan baharu pada infrastruktur, jurutera mengikat alamat MAC pelayan pada profil yang diperlukan dalam Cobbler. Apabila but melalui rangkaian buat kali pertama, pelayan menerima alamat sementara dan OS baharu. Kemudian ia dipindahkan ke pengalamatan VLAN/IP sasaran dan meneruskan kerja di sana. Ya, menukar VLAN memerlukan masa dan memerlukan penyelarasan, tetapi ia memberikan perlindungan tambahan terhadap pemasangan pelayan secara tidak sengaja dalam persekitaran pengeluaran.

Kami mencipta pelayan maya berdasarkan templat yang disediakan menggunakan HashiСorp Packer. Sebabnya adalah sama: untuk mengelakkan kemungkinan ralat manusia semasa memasang OS. Tetapi, tidak seperti pelayan fizikal, Packer menghapuskan keperluan untuk PXE, but rangkaian dan perubahan VLAN. Ini telah menjadikannya lebih mudah dan lebih mudah untuk membuat pelayan maya.

nasi. 1. Menguruskan pemasangan sistem pengendalian.

Menguruskan rahsia

Mana-mana sistem pengurusan konfigurasi mengandungi data yang harus disembunyikan daripada pengguna biasa, tetapi diperlukan untuk menyediakan sistem. Ini adalah kata laluan untuk pengguna tempatan dan akaun perkhidmatan, kunci sijil, pelbagai Token API, dll. Ia biasanya dipanggil "rahsia".

Jika anda tidak menentukan dari awal lagi di mana dan bagaimana untuk menyimpan rahsia ini, maka, bergantung pada keterukan keperluan keselamatan maklumat, kaedah penyimpanan berikut mungkin:

• terus dalam kod kawalan konfigurasi atau dalam fail dalam repositori;
• dalam alatan pengurusan konfigurasi khusus (contohnya, Bilik Kebal Ansible);
• dalam sistem CI/CD (Jenkins/TeamCity/GitLab/dll.) atau dalam sistem pengurusan konfigurasi (Ansible Tower/Ansible AWX);
• rahsia juga boleh dipindahkan "secara manual". Sebagai contoh, ia dibentangkan di lokasi tertentu, dan kemudian ia digunakan oleh sistem pengurusan konfigurasi;
• pelbagai kombinasi di atas.

Setiap kaedah mempunyai kelemahan tersendiri. Yang utama ialah kekurangan dasar untuk akses kepada rahsia: adalah mustahil atau sukar untuk menentukan siapa yang boleh menggunakan rahsia tertentu. Kelemahan lain ialah kekurangan pengauditan akses dan kitaran hayat penuh. Bagaimana untuk menggantikan dengan cepat, sebagai contoh, kunci awam yang ditulis dalam kod dan dalam beberapa sistem yang berkaitan?

Kami menggunakan storan rahsia berpusat HashiCorp Vault. Ini membolehkan kami:

• simpan rahsia dengan selamat. Mereka disulitkan, dan walaupun seseorang mendapat akses kepada pangkalan data Vault (contohnya, dengan memulihkannya daripada sandaran), mereka tidak akan dapat membaca rahsia yang disimpan di sana;
• mengatur dasar untuk akses kepada rahsia. Hanya rahsia "diperuntukkan" kepada mereka tersedia untuk pengguna dan aplikasi;
• akses audit kepada rahsia. Sebarang tindakan dengan rahsia direkodkan dalam log audit Vault;
• mengatur "kitaran hayat" sepenuhnya untuk bekerja dengan rahsia. Ia boleh dibuat, dibatalkan, menetapkan tarikh tamat tempoh, dsb.
• mudah untuk disepadukan dengan sistem lain yang memerlukan akses kepada rahsia;
• dan juga menggunakan penyulitan hujung ke hujung, kata laluan sekali untuk OS dan pangkalan data, sijil pusat yang dibenarkan, dsb.

Sekarang mari kita beralih kepada sistem pengesahan dan kebenaran pusat. Ia boleh dilakukan tanpa itu, tetapi mentadbir pengguna dalam banyak sistem berkaitan adalah terlalu tidak penting. Kami telah mengkonfigurasikan pengesahan dan kebenaran melalui perkhidmatan LDAP. Jika tidak, Vault perlu terus mengeluarkan dan menjejaki token pengesahan untuk pengguna. Dan memadam dan menambah pengguna akan bertukar menjadi pencarian "adakah saya membuat/memadam akaun pengguna ini di mana-mana?"

Kami menambah satu lagi tahap pada sistem kami: pengurusan rahsia dan pengesahan/kebenaran pusat:

nasi. 2. Pengurusan rahsia.

Pengurusan konfigurasi

Kami sampai ke inti - sistem CMS. Dalam kes kami, ini adalah gabungan Ansible dan Red Hat Ansible AWX.

Daripada Ansible, Chef, Puppet, SaltStack boleh digunakan. Kami memilih Ansible berdasarkan beberapa kriteria.

• Pertama, ia adalah serba boleh. Satu set modul siap sedia untuk kawalan ia mengagumkan. Dan jika anda tidak mempunyainya yang mencukupi, anda boleh mencari di GitHub dan Galaxy.
• Kedua, tidak perlu memasang dan menyokong ejen pada peralatan terurus, membuktikan bahawa mereka tidak mengganggu beban, dan mengesahkan ketiadaan "penanda halaman".
• Ketiga, Ansible mempunyai halangan yang rendah untuk masuk. Seorang jurutera yang cekap akan menulis buku main kerja secara literal pada hari pertama bekerja dengan produk.

Tetapi Ansible sahaja dalam persekitaran pengeluaran tidak mencukupi untuk kami. Jika tidak, banyak masalah akan timbul dengan menyekat akses dan mengaudit tindakan pentadbir. Bagaimana untuk menyekat akses? Lagipun, setiap jabatan perlu mengurus (baca: menjalankan buku permainan Ansible) set pelayan "sendiri". Bagaimana untuk membenarkan hanya pekerja tertentu menjalankan buku permainan Ansible tertentu? Atau bagaimana untuk mengesan siapa yang melancarkan buku main tanpa menyediakan banyak pengetahuan tempatan pada pelayan dan peralatan yang menjalankan Ansible?

Bahagian terbesar isu sedemikian diselesaikan oleh Red Hat Menara Ansible, atau projek huluan sumber terbukanya Ansible AWX. Itulah sebabnya kami memilih untuk pelanggan.

Dan satu lagi sentuhan pada potret sistem CMS kami. Buku permainan yang boleh dipercayai harus disimpan dalam sistem pengurusan repositori kod. Kami ada GitLab CE.

Jadi, konfigurasi itu sendiri diuruskan oleh gabungan Ansible/Ansible AWX/GitLab (lihat Rajah 3). Sudah tentu, AWX/GitLab disepadukan dengan sistem pengesahan tunggal dan buku permainan Ansible disepadukan dengan HashiCorp Vault. Konfigurasi memasuki persekitaran pengeluaran hanya melalui Ansible AWX, di mana semua "peraturan permainan" ditentukan: siapa yang boleh mengkonfigurasi apa, di mana untuk mendapatkan kod pengurusan konfigurasi untuk CMS, dsb.

nasi. 3. Pengurusan konfigurasi.

Pengurusan ujian

Konfigurasi kami dibentangkan dalam bentuk kod. Oleh itu, kami terpaksa bermain dengan peraturan yang sama seperti pembangun perisian. Kami perlu mengatur proses pembangunan, ujian berterusan, penghantaran dan penggunaan kod konfigurasi kepada pelayan pengeluaran.

Jika ini tidak dilakukan dengan segera, maka peranan yang ditulis untuk konfigurasi akan sama ada tidak lagi disokong dan diubah suai, atau akan berhenti dilancarkan dalam pengeluaran. Penawar untuk kesakitan ini diketahui, dan ia telah membuktikan dirinya dalam projek ini:

• setiap peranan dilindungi oleh ujian unit;
• ujian dijalankan secara automatik apabila terdapat sebarang perubahan dalam kod yang menguruskan konfigurasi;
• perubahan dalam kod pengurusan konfigurasi dikeluarkan ke dalam persekitaran pengeluaran hanya selepas berjaya melepasi semua ujian dan semakan kod.

Pembangunan kod dan pengurusan konfigurasi telah menjadi lebih tenang dan lebih mudah diramal. Untuk mengatur ujian berterusan, kami menggunakan kit alat GitLab CI/CD, dan mengambil Molekul Ansible.

Setiap kali terdapat perubahan dalam kod pengurusan konfigurasi, GitLab CI/CD memanggil Molecule:

• ia menyemak sintaks kod,
• menaikkan bekas Docker,
• menggunakan kod yang diubah suai pada bekas yang dibuat,
• menyemak peranan untuk idempotensi dan menjalankan ujian untuk kod ini (butiran di sini adalah pada tahap peranan boleh, lihat Rajah 4).

Kami menghantar konfigurasi kepada persekitaran pengeluaran menggunakan Ansible AWX. Jurutera operasi menggunakan perubahan konfigurasi melalui templat yang dipratentukan. AWX secara bebas "meminta" versi terkini kod daripada cawangan induk GitLab setiap kali ia digunakan. Dengan cara ini kami mengecualikan penggunaan kod yang belum teruji atau lapuk dalam persekitaran pengeluaran. Sememangnya, kod itu memasuki cawangan induk hanya selepas ujian, semakan dan kelulusan.

nasi. 4. Ujian automatik peranan dalam GitLab CI/CD.

Terdapat juga masalah yang berkaitan dengan operasi sistem pengeluaran. Dalam kehidupan sebenar, sangat sukar untuk membuat perubahan konfigurasi melalui kod CMS sahaja. Situasi kecemasan timbul apabila jurutera mesti menukar konfigurasi "di sini dan sekarang", tanpa menunggu pengeditan kod, ujian, kelulusan, dsb.

Akibatnya, disebabkan oleh perubahan manual, percanggahan muncul dalam konfigurasi pada jenis peralatan yang sama (contohnya, tetapan sysctl dikonfigurasikan secara berbeza pada nod kelompok HA). Atau konfigurasi sebenar pada peralatan berbeza daripada yang dinyatakan dalam kod CMS.

Oleh itu, sebagai tambahan kepada ujian berterusan, kami menyemak persekitaran pengeluaran untuk percanggahan konfigurasi. Kami memilih pilihan yang paling mudah: menjalankan kod konfigurasi CMS dalam mod "lari kering", iaitu, tanpa menggunakan perubahan, tetapi dengan pemberitahuan semua percanggahan antara konfigurasi yang dirancang dan sebenar. Kami melaksanakan ini dengan menjalankan semua buku permainan Ansible secara berkala dengan pilihan "—semak" pada pelayan pengeluaran. Seperti biasa, Ansible AWX bertanggungjawab untuk melancarkan dan memastikan buku main dikemas kini (lihat Rajah 5):

nasi. 5. Semak percanggahan konfigurasi dalam Ansible AWX.

Selepas semakan, AWX menghantar laporan percanggahan kepada pentadbir. Mereka mengkaji konfigurasi bermasalah dan kemudian membetulkannya melalui buku permainan yang dilaraskan. Beginilah cara kami mengekalkan konfigurasi dalam persekitaran pengeluaran dan CMS sentiasa terkini dan disegerakkan. Ini menghapuskan "keajaiban" yang tidak menyenangkan apabila kod CMS digunakan pada pelayan "pengeluaran".

Kami kini mempunyai lapisan ujian penting yang terdiri daripada Ansible AWX/GitLab/Molecule (Rajah 6).

nasi. 6. Pengurusan ujian.

Sukar? Saya tidak membantah. Tetapi pengurusan konfigurasi yang kompleks telah menjadi jawapan yang komprehensif kepada banyak soalan yang berkaitan dengan automasi konfigurasi pelayan. Kini pelayan standard peruncit sentiasa mempunyai konfigurasi yang ditetapkan dengan ketat. CMS, tidak seperti jurutera, tidak akan lupa untuk menambah tetapan yang diperlukan, mencipta pengguna dan melaksanakan berpuluh-puluh atau beratus-ratus tetapan yang diperlukan.

Tiada "pengetahuan rahsia" dalam tetapan pelayan dan persekitaran hari ini. Semua ciri yang diperlukan ditunjukkan dalam buku permainan. Tiada lagi kreativiti dan arahan yang tidak jelas: “Pasangnya seperti Oracle biasa, tetapi anda perlu menentukan beberapa tetapan sysctl dan menambah pengguna dengan UID yang diperlukan. Tanya lelaki yang beroperasi, mereka tahu'.

Keupayaan untuk mengesan percanggahan konfigurasi dan membetulkannya secara proaktif memberikan ketenangan fikiran. Tanpa sistem pengurusan konfigurasi, ini biasanya kelihatan berbeza. Masalah terkumpul sehingga satu hari mereka "menembak" ke dalam pengeluaran. Kemudian taklimat dijalankan, konfigurasi disemak dan diperbetulkan. Dan kitaran berulang lagi

Dan sudah tentu, kami mempercepatkan pelancaran pelayan beroperasi dari beberapa hari ke jam.

Nah, pada Malam Tahun Baru itu sendiri, apabila kanak-kanak sedang bergembira membuka bungkusan hadiah dan orang dewasa mendoakan ketika bunyi lonceng melanda, jurutera kami memindahkan sistem SAP ke pelayan baharu. Malah Santa Claus akan mengatakan bahawa keajaiban terbaik adalah yang disediakan dengan baik.

PS Pasukan kami sering menghadapi hakikat bahawa pelanggan ingin menyelesaikan masalah pengurusan konfigurasi semudah mungkin. Sebaik-baiknya, seolah-olah dengan sihir - dengan satu alat. Tetapi dalam kehidupan semuanya lebih rumit (ya, peluru perak tidak dihantar lagi): anda perlu membuat keseluruhan proses menggunakan alat yang sesuai untuk pasukan pelanggan.

Pengarang: Sergey Artemov, arkitek jabatan Penyelesaian DevOps "Sistem Maklumat Jet"

Sumber: www.habr.com