Apakah layak beralih dari Powershell DSC ke Ansible dan bagaimana melakukannya

Sedikit yang ditulis tentang IaC di bawah Windows, karena DevOps / SRE dikaitkan terutama dengan Linux dan Kubernetes. Kami memutuskan untuk memperbaiki situasi ini dan membandingkan alat yang dapat digunakan untuk mengelola IaC berbasis Windows. Artikel ini akan berguna bagi pengembang yang bekerja dengan infrastruktur Windows dan memilih metode manajemen, dan bagi mereka yang telah menerapkan Powershell DSC atau Ansible, tetapi ragu tentang keputusan mereka. Di bawah ini kami akan membagikan pengalaman kami dan memberi tahu Anda:

• cara kerja Powershell DSC dan perbedaannya dengan Ansible saat mengelola infrastruktur di Windows;
• mengapa kami beralih ke Ansible;
• masalah apa yang mereka hadapi dan bagaimana pemecahannya;
• bagaimana harapan dan kenyataan dibandingkan setelah beralih ke Ansible;
• siapa yang harus memilih Powershell DSC dan siapa yang harus memilih Ansible.

Mengapa PowerShell DSC awalnya dipilih

Mindbox memiliki budaya DevOps / SRE yang berkembang, meskipun infrastruktur utamanya adalah Windows: Hyper-V, IIS, MS SQL Server. Dan meskipun perusahaan secara bertahap pindah ke Linux dan Open Source, Windows masih tetap berlaku.



Untuk mengelola infrastruktur ini, mereka berencana menggunakan kode infrastruktur: tulis, simpan ke repositori, lalu gunakan beberapa alat untuk mengubah kode menjadi infrastruktur nyata. Meskipun Ansible adalah alat manajemen infrastruktur berbasis kode yang paling populer, Ansible secara tradisional dikaitkan dengan dunia Linux. Kami menginginkan sesuatu yang asli dan khusus Windows, jadi kami memilih PowerShell DSC.

Bagaimana Powershell DSC Bekerja

PowerShell Desired State Configuration (DSC) adalah layanan yang disertakan dengan Windows di luar kotak dan membantu Anda mengelola infrastruktur melalui file konfigurasi. Ia menerima kode infrastruktur di PowerShell sebagai masukan, dan secara internal mengubahnya menjadi perintah yang mengkonfigurasi sistem. Selain operasi yang sepele, seperti menginstal komponen Windows, mengubah kunci registri, membuat file, atau mengonfigurasi layanan, ini dapat melakukan banyak hal yang biasanya dilakukan skrip PowerShell. Misalnya, siklus penuh konfigurasi DNS atau contoh MS SQL Server yang sangat tersedia.







Tautan yang berguna ke diagram:

Contoh konfigurasi sederhana untuk dokumen DSC

Cara menggunakan file data

SQL Server- Windows Server 2019

DSC pull server SQL Windows Server 2019

DSC Ansible

, DSC

Harapan dari DSC tidak terpenuhi dalam segala hal. Selain itu, selama bekerja, muncul kebutuhan baru yang tidak dapat dipenuhi dengan bantuan DSC.



Pengembang tidak dapat menggunakan alat ini sendiri tanpa bantuan SRE. Meskipun hampir setiap tim memiliki SRE, alat IaC harus cukup sederhana sehingga pengembang dapat menggunakannya dan menghabiskan tidak lebih dari setengah jam untuk itu. DSC memungkinkan Anda untuk menggunakan tidak hanya kode deklaratif, tetapi juga konstruksi Powershell apa pun. Ini berarti ada kemungkinan besar pembuatan kode yang akan sulit untuk dipertahankan atau yang akan menyebabkan kegagalan infrastruktur. Misalnya, menerapkan aplikasi dengan parameter yang salah ke lingkungan yang salah.



Tidak dapat melewati konfigurasi uji coba sebelum bergulir,untuk melihat dengan tepat perubahan mana yang akan diterapkan dan mana yang tidak.



Sulit bagi DSC untuk mengatur pemeriksaan sintaks dan gaya kode. Ada beberapa alat validasi dan tidak diperbarui. Kami telah melakukan ini untuk Ansible.



Dalam mode dorong DSC, tidak ada cara mudah untuk melacak status tugas. Jika konfigurasi diterapkan dengan kesalahan, tindakan tambahan harus diambil untuk diagnostik: jalankan perintah untuk mendapatkan status aplikasi konfigurasi, lihat log peristiwa. Jika kesalahan terjadi di beberapa server, itu memakan waktu.



Mode tarik tidak pernah menjadi keuntungan.Di dalamnya, konfigurasi diterapkan secara asinkron - tidak mungkin untuk mengetahui secara pasti kapan aplikasi konfigurasi baru selesai tanpa tali dan kruk.



Penggunaan dua alat IaC berbeda yang mengkonfigurasi server secara berlebihan . Ansible dapat melakukan hal yang sama seperti DSC, dan kami telah menggunakan Ansible untuk mengonfigurasi host Linux dan peralatan jaringan.

Bagaimana Anda berencana untuk beralih dari DSC ke Ansible

Awalnya, tugas itu tampak sederhana, sekitar satu bulan. Kami telah mengidentifikasi tiga tahap pekerjaan:

• pelajari cara menyambung ke host Windows menggunakan Ansible;
• menulis ulang konfigurasi DSC menggunakan modul Ansible;
• menghapus server tarik DSC, database dan artefak lainnya.

Inilah alur kerja di DSC, dan bagaimana kami berencana untuk mengaturnya di Ansible:









Struktur standar peran di Ansible



On Ansible, kami berencana untuk memisahkan kode kompleks yang mengonfigurasi dan menginstal sesuatu ke dalam kode peran dan membagi peran menjadi terpisah repositori. Di repositori Ansible utama, hanya panggilan ke peran, penggantian parameter peran, dan daftar server menurut grup yang harus tetap ada. Jadi tidak hanya SRE, tetapi juga setiap pengembang dapat menerapkan peran tersebut ke server yang diperlukan atau mengubah parameter tanpa mempelajari logika kode infrastruktur. Pengembang dapat memperbaiki kode peran hanya setelah tinjauan SRE.

Kesulitan apa yang Anda hadapi saat beralih ke Ansible dan cara mengatasinya

Ketika pekerjaan dimulai, kami menyadari bahwa kami salah: tugas itu tidak mudah. Tidak ada masalah hanya dengan repositori, dan dalam hal lain saya harus banyak meneliti dan meningkatkan perkembangan.

WinRM atau SSH

Kejutan pertama adalah pilihan jenis koneksi. Dalam kasus Windows, ada dua di antaranya - WinRM dan SSH. Ternyata Ansible lambat dijalankan melalui WinRM. Karena itu, Ansible tidak merekomendasikan penggunaan OpenSSH di luar kotak untuk Windows Server 2019. Dan kami menemukan solusi baru:

1. Bercabang dan dibuat ulang peran dari Galaxy.
2. Kami menulis buku pedoman yang hanya menantang peran ini. Ini adalah satu-satunya pedoman yang terhubung ke host melalui WinRM.
3. Prometheus Blackbox Exporter memonitor port 22 / tcp dan versi OpenSSH sebagai alat standar :
   
   
   
   - alert: SSHPortDown

  expr: probe_success{job=~".*-servers-ssh",instance!~".*domain..ru"} == 0

  for: 1d

  annotations:

   summary: "Cannot reach {{`{{ $labels.instance }}`}} with SSH"
   
   
   
   
4. LDAP- , Windows- :
   
   
   
   plugin: ldap_inventory

domain: 'ldaps://domain:636'

search_ou: "DC=domain,DC=ru"

ldap_filter: "(&(objectCategory=computer)(operatingSystem=*server*)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))"

validate_certs: False

exclude_hosts:

 - db-

account_age: 15

fqdn_format: True
   
   
   
   
5. OpenSSH , Windows- SSH .
6. OpenSSH . Packer, Ansible:
   
   
   
   "type": "shell-local",

"tempfile_extension": ".ps1",

"execute_command": ["powershell.exe", "{{.Vars}} {{.Script}}"],

"env_var_format": "$env:%s=\"%s\"; ",

"environment_vars": [

"packer_directory={{ pwd }}",

"ldap_machine_name={{user `ldap_machine_name`}}",

"ldap_username={{user `ldap_username`}}",

"ldap_password={{user `ldap_password`}}",

"ansible_playbooks={{user `ansible_playbooks`}}",

"github_token={{user `github_token`}}"

],

"script": "./scripts/run-ansiblewithdocker.ps1"


   
   
   
   

Saat kami menulis ulang kode untuk Ansible, kami secara berkala mengalami duplikasi kode. Misalnya, hampir semua konfigurasi DSC berisi pengaturan windows_exporter. Satu-satunya hal yang berbeda adalah kolektor yang harus digunakan eksportir:







Untuk menghilangkan kode duplikat, kami memindahkan windows_exporter ke dalam peran Ansible yang terpisah, dan parameter pengaturan ini - ke dalam variabel grup host.

Otentikasi hop kedua

Mungkin, otentikasi hop kedua adalah masalah paling umum yang dihadapi oleh mereka yang mulai menggunakan Ansible di Windows: Desain ini menyebabkan kesalahan Access Denied karena fakta bahwa secara default tidak mungkin mendelegasikan kredensial untuk otorisasi pada sumber daya jauh tanpa pengaturan tambahan. Untuk mengatasi error tersebut, misalnya, new_credentials membantu. Namun kami lebih suka memanfaatkan fakta bahwa Ansible dapat memanggil resource DSC melalui modul win_dsc. Kami menyebut resource File DSC, yang secara default berjalan di bawah akun komputer. Delegasi Kerberos tidak diperlukan dalam kasus ini:



- name: Custom modules loaded into module directory

   win_copy:

    src: '\\share\dsc\modules'

    dest: 'C:\Program Files\WindowsPowerShell\Modules'

    remote_src: yes











- name: Custom modules loaded into module directory

   win_dsc:

    resource_name: File

    SourcePath: '\\share\dsc\modules'

    DestinationPath: 'C:\Program Files\WindowsPowerShell\Modules'

    Type: Directory

    Recurse: true

    Force: true

    MatchSource: true







Pada saat yang sama, tidak ada kontradiksi dalam mengabaikan DSC, tetapi menggunakan sumber dayanya jika mereka memecahkan masalah dengan lebih baik daripada modul Ansible. Tujuan utamanya adalah berhenti menggunakan konfigurasi DSC, karena ekosistem DSC-lah yang tidak sesuai dengan kami, dan bukan resource itu sendiri. Misalnya, jika Anda perlu membuat sakelar Hyper-V virtual, Anda harus menggunakan sumber daya DSC - Ansible belum memiliki alat untuk mengelola konfigurasi Hyper-V.

Putus jaringan

Beberapa tugas menyebabkan pemutusan jaringan (putuskan sambungan) pada server yang dapat dikonfigurasi. Misalnya, membuat sakelar virtual Hyper-V dari contoh di atas: Masalahnya adalah bahwa di DSC panggilan seperti itu berfungsi, tetapi di Ansible itu gagal karena host yang dikelola telah terputus. Ini karena Windows selalu terputus saat membuat sakelar eksternal virtual. Solusinya adalah dengan menambahkan argumen async ke tugas : Beginilah cara Ansible mengirim tugas ke host, menunggu waktu yang ditentukan dan baru kemudian menanyakan statusnya.



- name: External switch present

   win_dsc:

     resource_name: xVMSwitch

     Ensure: 'Present'

     Name: 'Virtual Network'

     Type: 'External'

     NetAdapterName: 'TEAM_LAN'

     AllowManagementOS: True











async: 10

Infrastruktur melayang

Ketika kami mulai mem-port kode, kami menemukan penyimpangan konfigurasi. Ini adalah perbedaan sebenarnya antara apa yang dijelaskan dalam kode dan konfigurasi sebenarnya dari server atau perangkat lunak. Alasannya adalah bahwa dalam beberapa kasus DSC hanya melakukan sebagian dari pekerjaan, dan sisanya dilakukan baik dengan skrip atau secara manual sesuai dengan instruksi.



Untuk mempermudah bekerja dengan IaC, kami telah mengumpulkan semua skrip dan dokumen dan membuat instruksi seragam yang tidak ambigu. Selain itu, kami mengatur prosesnya agar tidak ada yang membuat perubahan yang tidak disengaja pada Ansible. Kami menyimpan semua kode infrastruktur di GitHub, dan menetapkan tugas kepada teknisi melalui Proyek GitHub, sehingga kami memiliki kemampuan untuk mengaitkan perubahan pada kode infrastruktur (permintaan tarik) dengan tugas. Jadi kita bisa melihat perubahan untuk setiap tugas yang diselesaikan. Jika tugas tidak memiliki perubahan apa pun, maka itu tidak akan diterima dan akan dikembalikan untuk revisi.

Fakta Mengumpulkan Bug

Tidak seperti DSC, Ansible mengumpulkan fakta tentang host yang dikelola saat startup sehingga pengembang dapat menentukan perilaku tugas bergantung pada status host. Saat mengumpulkan fakta dari host Windows, Ansible mungkin membuat kesalahan karena kode modul yang salah. Untuk memperbaikinya, Anda perlu menghubungkan koleksi ansible.windows. Pipeline untuk Ansible, sebelum meluncurkan setiap playbook, memeriksa keberadaan file Requirement.yml dengan daftar peran dan koleksi yang diperlukan, lalu menginstalnya. Di sinilah kami menambahkan koleksi ansible.windows. Koleksi



[WARNING]: Error when collecting bios facts: New-Object : Exception calling ".ctor" with "0" argument(s): "Index was out of range. Must be non-negative and less than the size of the collection. Parameter name: index" At line:2

char:21 + ... $bios = New-Object -TypeName













Merupakan konsep pengembangan baru untuk Ansible. Jika sebelumnya hanya peran yang didistribusikan di Galaxy, sekarang di sana Anda dapat menemukan koleksi berbagai plugin dan modul, buku pedoman, dan peran.

Tes

Sebelum menyerahkan toolkit IaC kepada developer, kami ingin memastikan bahwa kode Ansible dapat diandalkan dan tidak merusak apapun. Dalam kasus DSC, tidak ada pengujian khusus, meskipun ada kerangka kerja khusus untuk tugas ini. Konfigurasi biasanya divalidasi pada server penahapan, yang kegagalannya tidak menyebabkan kerusakan.



Ansible biasanya diuji menggunakan alat molekul . sebagai pembungkus untuk menjalankan pengujian. Ini adalah alat yang berguna untuk peran Linux, tetapi ada masalah dengan Windows. Sebelumnya, molekul tersebut mampu meningkatkan infrastruktur itu sendiri, tetapi sekarang para pengembang telah menghilangkan peluang ini. Sekarang infrastruktur sedang ditingkatkan baik dengan bantuan molekul di Docker, atau di luar molekul. Menguji peran Windows di Docker paling sering tidak mungkin: Hyper-V dan sebagian besar fitur Windows lainnya tidak akan diinstal di kontainer Docker. Kita harus menggunakan infrastruktur untuk pengujian di luar molekul dan menggunakan penggerak yang didelegasikan di dalam molekul.



Kami belum memecahkan masalah ini, tetapi kami telah menemukan alat yang akan mendeteksi kesalahan yang paling jelas:

Bagaimana Ansible bekerja

Setelah kami menerapkan Ansible dan mengatasi semua kesulitan, proses tindakan insinyur dan peluncuran otomatis terbentuk:

1. , Linux-. , , pull request GitHub-, .
2. pull request GitHub Actions, . Linux-, . , , .
3. pull request. , -, .
4. . requirements.yml, GitHub- . — . . , Ansible, . pull request, .
5. pull request GitHub Actions, Octopus Deploy. .
6. Octopus Deploy . , ansible-playbook: --tags, --limit --extra-vars.
7. , , . , .

Ansible

: DSC Ansible

Evgeny Berendyaev, insinyur SRE