Ini adalah transkrip pidatonya ΠΈ .
Ini adalah kisah tentang proyek yang menggunakan sistem manajemen konfigurasi yang ditulis sendiri dan mengapa perpindahan ke Ansible memakan waktu 18 bulan.
Hari No. -Π₯Π₯Π₯ : Sebelum permulaan
Awalnya, infrastruktur terdiri dari banyak host terpisah yang menjalankan Hyper-V. Membuat mesin virtual memerlukan banyak langkah: meletakkan disk di tempat yang tepat, mendaftarkan DNS, memesan DHCP, meletakkan konfigurasi VM di repositori git. Proses ini sebagian dilakukan secara mekanis, tetapi misalnya, VM didistribusikan antar host dengan tangan. Namun, misalnya, pengembang dapat memperbaiki konfigurasi VM di git dan menerapkannya dengan me-reboot VM.
Solusi Manajemen Konfigurasi Kustom
Ide awalnya, saya kira, dikandung sebagai IaC: banyak VM tanpa kewarganegaraan yang menyetel ulang statusnya ke nol saat di-boot ulang. Apa yang dimaksud dengan manajemen konfigurasi VM? Secara skematis terlihat sederhana:
- MAC statis telah dipasang untuk VM.
- ISO dengan CoreOS dan boot disk terhubung ke VM.
- CoreOS meluncurkan skrip penyesuaian dengan mengunduhnya dari server WEB berdasarkan IP-nya.
- Skrip mengunduh konfigurasi VM melalui SCP berdasarkan alamat IP.
- Footcloth dari file unit systemd dan footcloth dari skrip bash diluncurkan.
Solusi ini jelas memiliki banyak masalah:
- CoreOS ISO sudah tidak digunakan lagi.
- Banyak tindakan dan keajaiban otomatis yang kompleks saat memigrasi/membuat VM.
- Kesulitan dalam memperbarui dan kapan versi perangkat lunak tertentu diperlukan. Lebih menyenangkan lagi dengan modul kernel.
- VM tidak diperoleh tanpa data, mis. VM muncul dengan disk dengan data pengguna tambahan terpasang.
- Seseorang terus-menerus mengacaukan dependensi unit systemd dan CoreOS akan terhenti saat melakukan boot ulang. Sulit untuk mengetahui hal ini menggunakan alat yang tersedia di CoreOS.
- Manajemen rahasia.
- Tidak ada CM. Ada konfigurasi bash dan YML untuk CoreOS.
Untuk menerapkan konfigurasi VM, Anda perlu melakukan boot ulang, tetapi mungkin tidak melakukan boot ulang. Sepertinya masalah yang jelas, tetapi tidak ada disk persisten - tidak ada tempat untuk menyimpan log. Baiklah, mari kita coba menambahkan opsi pemuatan kernel agar log dapat dikirim. Tapi tidak, betapa rumitnya semua ini.
Hari #0: Kenali masalahnya
Itu adalah infrastruktur pengembangan biasa: jenkins, lingkungan pengujian, pemantauan, registri. CoreOS dirancang untuk menghosting cluster k8s, mis. masalahnya adalah bagaimana CoreOS digunakan. Langkah pertama adalah memilih tumpukan. Kami memutuskan:
- CentOS sebagai distribusi dasar, karena Ini adalah distribusi yang paling dekat dengan lingkungan produksi.
- Mungkin untuk manajemen konfigurasi, karena ada pemeriksaan ekstensif terhadapnya.
- Jenkins sebagai kerangka untuk mengotomatisasi proses yang ada, karena itu telah digunakan secara aktif untuk proses pembangunan
- Hyper-V sebagai platform virtualisasi. Ada sejumlah alasan yang melampaui cakupan cerita, namun singkatnya - kita tidak bisa menggunakan cloud, kita harus menggunakan perangkat keras kita sendiri.
Hari No. 30: Memperbaiki perjanjian yang ada - Perjanjian sebagai Kode
Ketika tumpukan sudah bersih, persiapan untuk perpindahan dimulai. Memperbaiki perjanjian-perjanjian yang sudah ada dalam bentuk kode (Perjanjian sebagai Kode!). Transisi kerja manual -> mekanisasi -> otomatisasi.
1. Konfigurasikan VM
Ansible melakukan pekerjaan ini dengan baik. Dengan gerakan tubuh minimal, Anda dapat mengontrol konfigurasi VM:
- Buat repositori git.
- Kami menempatkan daftar VM di inventaris, konfigurasi di buku pedoman, dan peran.
- Kami sedang menyiapkan budak jenkins khusus tempat Anda dapat menjalankan Ansible.
- Kami membuat pekerjaan dan mengkonfigurasi Jenkins.
Proses pertama sudah siap. Perjanjiannya sudah pasti.
2. Buat VM baru
Segala sesuatu di sini sangat tidak nyaman. Sangat tidak nyaman membuat VM di Hyper-V dari Linux. Salah satu upaya untuk memekanisasi proses ini adalah:
- Ansbile terhubung melalui WinRM ke host windows.
- Ansible menjalankan skrip PowerShell.
- Skrip Powershell membuat VM baru.
- Menggunakan Hyper-V/ScVMM, saat membuat VM di OS tamu, nama host dikonfigurasi.
- Saat memperbarui sewa DHCP, VM mengirimkan nama hostnya.
- Integrasi ddns & dhcp standar di sisi Pengontrol Domain mengonfigurasi catatan DNS.
- Anda dapat menambahkan VM ke inventaris Anda dan mengonfigurasinya dengan Ansible.
3.Buat templat VM
Mereka tidak menemukan apa pun di sini - mereka mengambil sebuah pengepakan.
- Tambahkan pengemas, mulai konfigurasi ke repositori git.
- Menyiapkan budak jenkins khusus dengan hyper-v dan Packer.
- Kami membuat pekerjaan dan mengkonfigurasi Jenkins.
Cara kerja tautan ini:
- Packer membuat VM kosong dan mengambil ISO.
- VM melakukan booting, Packer memasukkan perintah ke dalam bootloader untuk menggunakan file kickstart kami dari floppy disk atau http.
- Anaconda diluncurkan dengan konfigurasi kami, dan konfigurasi OS awal selesai.
- Packer menunggu VM tersedia.
- Pengemas di dalam VM dapat dijalankan dalam mode lokal.
- Ansible menggunakan peran yang persis sama dengan yang berfungsi pada langkah #1.
- Packer mengekspor templat VM.
Hari #75: Perbaiki perjanjian tanpa melanggar = Uji kemungkinan + Uji dapur
Menangkap konvensi dalam kode mungkin tidak cukup. Lagi pula, jika dalam seluk beluk proses Anda ingin mengubah sesuatu, Anda bisa merusak sesuatu. Oleh karena itu, dalam kasus infrastruktur, pengujian terhadap infrastruktur ini muncul. Untuk menyinkronkan pengetahuan dalam tim, kami mulai menguji peran yang mungkin. Saya tidak akan membahasnya secara mendalam karena... ada artikel yang menjelaskan peristiwa pada saat itu (spoiler ini bukan versi final dan kemudian semuanya menjadi lebih rumit ).
Hari #130: Mungkin CentOS+ansible tidak diperlukan? mungkin shift terbuka?
Kita harus memahami bahwa proses pengenalan infrastruktur bukanlah satu-satunya proses dan ada subproyek sampingan. Misalnya, datang permintaan untuk meluncurkan aplikasi kita secara openshift dan ini menghasilkan penelitian selama lebih dari satu minggu yang memperlambat proses perpindahan. Hasilnya ternyata openshift tidak mencakup semua kebutuhan; Anda memerlukan perangkat keras nyata, atau setidaknya kemampuan untuk bermain-main dengan kernel.
Hari #170: Openshift tidak cocok, mari kita coba dengan Windows Azure Pack?
Hyper-V tidak terlalu ramah, SCVMM tidak membuatnya lebih baik. Namun ada yang namanya Windows Azure Pack, yang merupakan tambahan pada SCVMM dan meniru Azure. Namun kenyataannya, produk tersebut terlihat terbengkalai: dokumentasinya memiliki tautan yang rusak dan sangat jarang. Namun sebagai bagian dari studi tentang opsi untuk menyederhanakan kehidupan cloud kami, mereka juga mempertimbangkannya.
Hari #250: Paket Windows Azure tidak terlalu bagus. Kami tetap di SCVMM
Windows Azure Pack tampak menjanjikan, namun diputuskan untuk tidak membawa WAP dengan kompleksitasnya ke dalam sistem demi fitur yang tidak perlu dan tetap menggunakan SCVMM.
Hari #360: Memakan gajah sepotong demi sepotong
Hanya setahun kemudian platform untuk pindah sudah siap dan proses pindahan pun dimulai. Untuk tujuan ini, tugas SMART telah ditetapkan. Kami memeriksa semua VM dan mulai mencari tahu konfigurasinya satu per satu, mendeskripsikannya di Ansible, dan menutupinya dengan pengujian.
Hari #450: Sistem seperti apa yang Anda dapatkan?
Prosesnya sendiri tidak menarik. Hal ini rutin, dapat dicatat bahwa sebagian besar konfigurasi relatif sederhana atau isomorfik dan menurut prinsip Pareto, 80% konfigurasi VM memerlukan 20% waktu. Dengan prinsip yang sama, 80% waktu dihabiskan untuk mempersiapkan perpindahan dan hanya 20% untuk perpindahan itu sendiri.
Hari #540: Terakhir
Apa yang terjadi dalam 18 bulan?
- Perjanjian tersebut menjadi sebuah kode.
- Kerja manual -> Mekanisasi -> Otomasi.
Link
Sumber: www.habr.com