Pada salah satu pertemuan komunitas St. Petersburg .Net dari pengembang Komunitas SpbDotNet, kami melakukan percobaan dan memutuskan untuk berbicara tentang bagaimana Anda dapat menerapkan pendekatan yang telah lama menjadi standar di dunia Linux untuk mengotomatisasi infrastruktur Windows. Tetapi untuk tidak membawa semuanya ke titik menandai bendera Ansible, diputuskan untuk menunjukkan ini dengan contoh penggelaran aplikasi ASP.Net.
Aleksey Chernov, Pengembang Senior tim yang mengembangkan perpustakaan komponen UI untuk proyek kami, mengajukan diri untuk menjadi pembicara. Dan ya, menurut Anda itu tidak terlihat: seorang pengembang JavaScript berada di depan audiensi .Net.
Siapa pun yang tertarik pada hasil percobaan seperti itu, selamat datang, di bawah potongan untuk decoding.
Hai) Mereka sudah sedikit manja dan mengatakan bahwa saya seorang ujung depan, jadi Anda sudah bisa menyimpang =) Nama saya Alexey, saya sudah melakukan segala macam hal tentang pengembangan web untuk beberapa waktu. Saya mulai dengan Perl, lalu ada PHP, sedikit RoR, sedikit, sedikit itu. Dan kemudian JavaScript muncul dalam hidup saya, dan sejak itu saya telah melakukan hampir semua ini.
Selain JS, akhir-akhir ini saya telah menulis cukup banyak autotest (apalagi di JS yang sama), dan karena itu saya harus berurusan dengan otomatisasi penyebaran bangku tes dan infrastruktur untuk mereka.
Latar belakang
Dua tahun lalu, saya berakhir di Veeam, tempat mereka mengembangkan produk untuk Windows. Pada saat itu saya sangat terkejut, tetapi ternyata itu terjadi =). Tapi yang paling penting saya terkejut dengan tingkat otomatisasi yang sangat rendah dari segala sesuatu yang berhubungan dengan penyebaran, dengan penyebaran aplikasi, dengan pengujian, dll.
Kami, mereka yang mengembangkan untuk Linux, telah lama terbiasa dengan kenyataan bahwa semuanya harus ada di Docker, ada Kubernetes, dan semuanya terungkap dengan satu klik. Dan ketika saya berakhir di lingkungan di mana semua ini tidak ada, itu mengejutkan. Dan ketika saya mulai melakukan tes otomatis, saya menyadari bahwa ini hanya 20% sukses, dan yang lainnya sedang mempersiapkan infrastruktur untuk mereka.
Perasaan saya pada awalnya
Kondisi saat ini
Saya akan memberi tahu Anda sedikit tentang bagaimana semuanya diatur bersama kami, apa yang harus kamiotomatiskan dan apa yang kami lakukan.
Kami memiliki banyak produk yang berbeda, kebanyakan dari mereka di bawah Windows, ada beberapa di bawah Linux, dan bahkan sesuatu di bawah Solaris. Cukup banyak build dikumpulkan setiap hari untuk semua produk. Oleh karena itu, perlu untuk meluncurkan semuanya di laboratorium uji, baik untuk QA dan untuk pengembang itu sendiri, sehingga mereka dapat memeriksa integrasi aplikasi. Semua ini membutuhkan infrastruktur besar dari banyak server besi dan mesin virtual. Dan kadang-kadang kita melakukan pengujian kinerja, ketika kita perlu segera meningkatkan seribu mesin virtual dan melihat seberapa cepat aplikasi kita akan bekerja.
Masalahnya
Tentu saja, pada tahap pertama (baca, dulu sekali), ketika mencoba mengotomatisasi semuanya secara langsung, PowerShell digunakan. Alat ini sangat kuat, tetapi skrip penerapan sangat rumit. Masalah lain adalah kurangnya manajemen terpusat dari proses ini. Beberapa skrip dijalankan secara lokal oleh pengembang, beberapa di mesin virtual dibuat kembali di era mammoth, dll. Akibatnya: sulit untuk mendapatkan hasil tunggal dan memahami apa yang berhasil dan yang tidak. Anda mulai bekerja, buka browser - server tidak tersedia. Mengapa tidak tersedia, apa yang terjadi, di mana ia rusak - itu sama sekali tidak jelas. Tidak ada titik masuk tunggal, dan saya harus mencari kebenaran di ruang obrolan, dan ada baiknya jika seseorang menjawab.
Masalah lain, tidak begitu jelas, adalah pemula. Itu sulit bagi mereka. Minggu pertama kerja, mereka baru saja menyelidiki apa yang sedang terjadi. Kita terbiasa hidup dengan ini, meyakinkan diri kita sendiri bahwa hidup adalah hal yang sulit dan kita harus tahan dengannya. Memahami dan memaafkan, begitu juga berbicara.
Tetapi pada titik tertentu mereka menemukan kekuatan batin untuk mengatasinya dan melihat-lihat. Mungkin entah bagaimana Anda bisa mengatasinya.
Langkah pertama menuju penyelesaian masalah adalah menerimanya.
Pemilihan solusi
Ketika Anda tidak tahu apa yang harus dilakukan, lihat apa yang dilakukan orang lain.
Dan sebagai permulaan, kami membuat daftar persyaratan untuk apa yang ingin kami dapatkan di akhir.
- Basis kode terpadu. Semua skrip penerapan harus di tempat yang sama. Ingin menyebarkan sesuatu atau melihat bagaimana hal itu terungkap: inilah repositori untuk Anda, buka di sana.
- Semua orang tahu cara kerjanya. Pertanyaan seharusnya hilang a "Saya tidak mengerti bagaimana cara menyebarkannya, jadi hari kedua saya tidak bisa menutup bug."
- Kemampuan untuk memulai dengan tombol. Kita harus bisa mengendalikan penyebaran. Misalnya, beberapa jenis antarmuka web, ke mana Anda pergi, tekan tombol, dan produk yang diinginkan digunakan untuk host yang diinginkan.
Setelah memastikan bahwa daftar ini mencakup persyaratan minimum yang diperlukan dan cukup untuk kebahagiaan kita, kami mulai mencoba. Secara tradisional, hal pertama yang mereka coba selesaikan adalah metode serangan frontal. Apakah kita memiliki banyak skrip PowerShell? Jadi mari kita gabungkan mereka ke dalam satu repositori. Tetapi masalahnya bukan karena ada terlalu banyak skrip, tetapi tim yang berbeda melakukan hal yang sama dengan skrip yang berbeda. Saya berjalan di sekitar tim yang berbeda, mendengarkan persyaratan mereka, mengumpulkan skrip yang sama, mencoba menyisir dan membuat parameter mereka entah bagaimana, dan kemudian menempatkannya dalam satu repositori.
Gagal: Upaya gagal. Pertama, kami mulai banyak berdebat tentang mengapa kami melakukan ini dan tidak seperti itu. Mengapa metode ini digunakan, dan bukan yang lain, dll. Dan sebagai hasilnya, ada banyak yang ingin mengulang semuanya "sebagaimana mestinya," dengan prinsip "Aku akan bercabang dan menulis ulang segalanya untukmu." Dan, tentu saja, tidak mungkin untuk menggabungkan cabang dengan pendekatan ini.
Mencoba nomor dua: itu seharusnya mengambil server CI kami (TeamCity), membuat beberapa templat di atasnya dan, menggunakan warisan, tutup masalah utama dari upaya pertama. Tetapi, seperti yang mungkin sudah Anda duga, Fail juga menunggu kami : Anda dapat menggunakan templat hanya untuk versi terbaru, yang berarti kami tidak akan mencapai versi yang diperlukan. Dan konsekuensi dari sejumlah besar tim - templat menjadi sangat banyak, menjadi lebih sulit untuk mengelolanya, dan di cakrawala rawa baru terlihat jelas.
Lelah jatuh tertelungkup dalam upaya untuk lepas landas, diputuskan untuk duduk lagi dan berpikir keras. Jadi, kami memiliki banyak skrip ps di satu sisi dan sejumlah besar virtual di sisi lain. Tapi kami salah, karena itu bukan akar masalahnya. Masalahnya adalah selalu ada seseorang di antara hal-hal ini. Tidak masalah apakah itu pengembang, penguji, atau orang lain, rantai logis berikut selalu terjadi di kepala:
- Jadi, saya perlu mesin virtual untuk tes
- Ya, di sini kita memiliki host pool
- Dan inilah skrip yang saya butuhkan, sekarang saya akan menjalankannya, dan semuanya akan terjadi
Dengan terwujudnya hal yang tampaknya sederhana, masalah umum mulai bermain dengan warna-warna baru. Ternyata semua rasa sakit kami berasal dari kurangnya satu deskripsi infrastruktur kami. Dalam benak orang-orang yang menciptakannya, mereka duduk di departemen yang berbeda, tidak berusaha mendokumentasikannya, dan pada umumnya masing-masing hidup dalam keadaannya sendiri yang terpisah.
Pada saat ini, kami sampai pada kesimpulan bahwa jawaban untuk semua masalah kami adalah:
Infrastruktur sebagai kode
Justru seluruh infrastruktur kita harus dijelaskan dalam kode dan terletak di repositori. Semua mesin virtual, semua parameternya, semua yang diinstal di sana - semuanya perlu dijelaskan dalam kode.
Muncul pertanyaan yang sah - mengapa?
Kami menjawab: pendekatan ini akan memberi kami kesempatan untuk menerapkan praktik terbaik dari dunia pembangunan, yang membuat kami semua sangat terbiasa:
- Kontrol versi. Kami selalu dapat memahami apa dan kapan telah berubah. Tidak ada lagi host yang datang entah dari mana atau tidak ke mana-mana. Akan selalu jelas siapa yang membuat perubahan.
- Ulasan Kode. Kami akan dapat mengontrol proses penyebaran sehingga beberapa tidak melanggar yang lain.
- Integrasi berkelanjutan.
Pemilihan alat
Seperti kita ketahui, ada banyak alat manajemen konfigurasi. Kami memilih Ansible, karena berisi serangkaian fitur yang kami butuhkan.
Pertama-tama, kami ingin dari sistem otomasi untuk tidak menjalankan installer, sesuatu untuk dimigrasi ke suatu tempat, dll. Pertama-tama, dari sistem seperti itu kami ingin bahwa setelah menekan satu tombol kita akan melihat UI aplikasi yang kita butuhkan.
Karena itu, fitur utama bagi kami adalah idempotensi. Tidak masalah apa yang terjadi sebelumnya. Setelah memulai buku pedoman yang diinginkan, kami selalu mendapatkan hasil yang sama. Ini sangat penting ketika Anda mengatakan tidak "Instal IIS", tetapi "Harus ada IIS", dan Anda tidak perlu berpikir apakah dia ada di sana sebelumnya atau tidak. Sangat sulit untuk mencapai ini dengan skrip, dan buku pedoman yang memungkinkan memberikan kesempatan seperti itu.
Juga layak disebutkan adalah agenlessness dari Ansible. Sebagian besar sistem otomasi bekerja melalui agen. Ini memiliki banyak keuntungan - misalnya, kinerja terbaik - tetapi penting bagi kami bahwa tidak ada agen sehingga sistem tidak harus dipersiapkan tambahan.
PowerShell:
$url = "http://buildserver/build.msi" $output = "$PSSscriptRoot\build.msi" Invoke-WebRequest -Uri $url -OutFile $output
Mungkin:
name: Download build hosts: all tasks: name: Download installer win_get_url: url: "http://buildserver/build.msi" dest: "build.msi" force: no
Di sini kita melihat bahwa dalam contoh dasar, skrip-ps akan lebih ringkas daripada buku pedoman yang dimungkinkan. 3 baris skrip versus 7 baris playbook untuk mengunduh file.
Tapi, Petka, ada nuansa. Segera setelah kami ingin mengamati prinsip idempotensi dan, misalnya, untuk memastikan bahwa file di server tidak berubah dan Anda tidak perlu mengunduhnya, Anda harus menerapkan permintaan KEPALA dalam skrip, yang menambahkan sekitar 200 baris. Dan dalam buku pedoman - satu. Modul win_get_url Ansible, yang melakukan semua pemeriksaan untuk Anda, berisi 257 baris kode yang tidak harus Anda masukkan ke dalam setiap skrip.
Dan ini hanyalah satu contoh dari tugas yang sangat sederhana.
Dan jika Anda memikirkannya, kita perlu idempotensi di mana-mana:
- Verifikasi keberadaan mesin virtual. Dalam hal skrip, kita berisiko menghasilkan jumlah yang tak terbatas, atau skrip akan macet di awal.
- Paket msi apa yang ada pada mesin? Dalam kasus terbaik, tidak ada yang akan jatuh di sini, dalam terburuk, mesin akan berhenti bekerja secara memadai.
- Apakah saya perlu mengunduh artefak pembuatan lagi? Baik jika bangunan Anda memiliki berat selusin megabyte. Dan bagaimana dengan mereka yang memiliki beberapa gigabytes?
Dan contoh-contoh lain, di mana jalan keluarnya adalah mengembang skrip dengan percabangan tanpa henti dari ifs yang tidak dapat didebug secara memadai dan tidak mungkin untuk dikelola.
Di antara hal-hal lain yang penting bagi kami, Ansible tidak menggunakan agen untuk mengelola host dan mesin Anda. Di Linux, tentu saja, ini berjalan pada ssh, sedangkan untuk Windows, WinRM digunakan. Karena itu konsekuensi yang jelas: Ansible adalah cross-platform. Ini mendukung sejumlah platform yang fantastis, hingga peralatan jaringan.
Dan yang terakhir, tetapi yang tidak kalah penting, adalah format rekaman konfigurasi YAML. Semua orang terbiasa dengannya, mudah dibaca, dan mudah untuk mengetahui apa yang terjadi di sana.
Tapi tidak semuanya begitu manis, ada masalah:
- Masalahnya meragukan: untuk menjalankan playbook, Anda masih membutuhkan mesin Linux, bahkan jika seluruh infrastruktur Anda hanya Windows. Meskipun ini bukan masalah besar di dunia modern, karena pada Windows 10 sekarang ada WSL, di mana Anda dapat menjalankan Ubuntu, di mana untuk mengarahkan buku pedoman.
- Terkadang playbook sangat sulit di-debug. Ansible ditulis dalam python, dan hal terakhir yang ingin saya lihat adalah tumpukan stack python lima layar. Dan salah ketik nama modul
Bagaimana cara kerjanya?
Pertama, kita membutuhkan mesin Linux. Dalam terminologi Ansible, ini disebut Mesin Kontrol.
Playbook akan mulai dari itu, dan semua keajaiban terjadi padanya.
Pada mesin ini kita perlu:
- Python dan pip manajer paket python. Banyak distribusi yang ada di luar kotak, jadi tidak ada kejutan di sini.
- Instal Ansible via pip, sebagai cara paling universal: pip install ansible
- Tambahkan modul winrm untuk masuk ke mesin Windows: pip install pywinrm [credssp]
- Dan pada mesin yang ingin kita kontrol, kita perlu mengaktifkan winrm, karena tidak aktif secara default. Ada banyak cara untuk melakukan ini, dan semuanya dijelaskan dalam dokumentasi Ansible. Tetapi yang paling sederhana adalah dengan mengambil skrip yang sudah jadi dari repositori Ansible dan menjalankannya dengan opsi otorisasi yang diperlukan: ConfigureRemotingForAnsible.ps1 -EnableCredSSP
Bagian terpenting yang kami butuhkan untuk menghentikan penderitaan dengan skrip ps adalah Inventory. File YAML (dalam kasus kami), yang menggambarkan infrastruktur kami dan di mana Anda selalu dapat melihat untuk memahami di mana itu dikerahkan. Dan, tentu saja, buku pedoman itu sendiri. Di masa depan, pekerjaan itu seperti meluncurkan buku pedoman dengan file inventaris yang diperlukan dan parameter tambahan.
all: children: webservers: hosts: spbdotnet-test-host.dev.local: dbservers: hosts: spbdotnet-test-host.dev.local: vars: ansible_connection: winrm ansible_winrm_transport: credssp ansible_winrm_server_cert_validation: ignore ansible_user: administrator ansible_password: 123qweASD
Semuanya sederhana di sini: grup root adalah semua dan dua subkelompok, webserves, dan dbservers. Segala sesuatu yang lain adalah intuitif, tetapi saya akan menarik perhatian Anda pada kenyataan bahwa Ansible secara default percaya bahwa Linux ada di mana-mana, jadi untuk Windows Anda harus menentukan winrm dan jenis otorisasi.
Tentu saja, Anda tidak perlu menyimpan kata sandi dalam bentuk yang jelas di buku pedoman, ini hanya sebuah contoh. Kata sandi dapat disimpan, misalnya, di Ansible-Vault. Kami menggunakan TeamCity untuk ini, yang meneruskan rahasia melalui variabel lingkungan dan tidak memecat apa pun.
Modul
Segala sesuatu yang Ansible lakukan, ia lakukan dengan bantuan modul. Modul untuk Linux ditulis dengan python, untuk Windows di PowerShell. Dan penghormatan untuk idempotensi: hasil dari modul selalu datang dalam bentuk file json, yang menunjukkan apakah ada perubahan pada host atau tidak.
Dalam kasus umum, kami akan menjalankan konstruksi dari daftar modul file inventaris grup host yang dimungkinkan:
Buku pedoman
Playbook adalah deskripsi tentang bagaimana dan di mana kita akan menjalankan modul Ansible.
- name: Install AWS CLI hosts: all vars: aws_cli_download_dir: c:\downloads aws_cli_msi_url: https://s3.amazonaws.com/aws-cli/AWSCLI32PY3.msi tasks: - name: Ensure target directory exists win_file: path: "{{ aws_cli_download_dir }}" state: directory - name: Download installer win_get_url: url: "{{ aws_cli_msi_url }}" dest: "{{ aws_cli_download_dir }}\\awscli.msi" force: no - name: Install AWS CLI win_package: path: "{{ aws_cli_download_dir }}\\awscli.msi" state: present
Dalam contoh ini, kami memiliki tiga tugas. Setiap tugas adalah panggilan modul. Di buku pedoman ini, pertama-tama kita membuat direktori (pastikan ada), lalu unduh AWS CLI di sana dan instal menggunakan modul win_packge.
Dengan menjalankan buku pedoman ini, kami mendapatkan hasil ini.
Laporan menunjukkan bahwa empat tugas berhasil diselesaikan dan tiga dari empat membuat beberapa perubahan pada tuan rumah.
Tetapi apa yang terjadi jika Anda menjalankan buku pedoman ini lagi? Kami belum menulis di mana pun bahwa kami harus membuat direktori, mengunduh file installer dan menjalankannya. Kami cukup memeriksa ketersediaan setiap item dan melewati jika ada.
Ini adalah idempoten yang tidak bisa kami raih dengan PowerShell.
Berlatih
Ini adalah contoh yang sedikit disederhanakan, tetapi, pada prinsipnya, inilah yang kami lakukan setiap hari.
Kami akan menyebarkan aplikasi yang terdiri dari layanan Windows dan aplikasi web di bawah IIS.
- name: Setup App hosts: webservers tasks: - name: Install IIS win_feature: name: - Web-Server - Web-Common-Http include_sub_features: True include_management_tools: True state: present register: win_feature - name: reboot if installing Web-Server feature requires it win_reboot: when: win_feature.reboot_required
Pertama, kita perlu melihat apakah ada IIS di host, dan instal jika tidak. Dan alangkah baiknya untuk segera menambahkan alat manajemen dan semua fitur yang tergantung. Dan sangat bagus jika host di-reboot jika perlu.
Tugas pertama yang kami selesaikan adalah modul win_feature, yang bergerak dalam mengelola fitur Windows. Dan di sini untuk pertama kalinya kami memiliki variabel lingkungan Ansible, dalam item register. Ingat, saya mengatakan bahwa tugas selalu mengembalikan objek json? Sekarang, setelah menyelesaikan tugas Instal IIS, output dari modul win_feature terletak pada variabel win_feature (permisi untuk tautologi).
Dalam tugas selanjutnya, kita memanggil modul win_reboot. Tapi kami tidak perlu me-restart server kami setiap saat. Kami akan memuatnya kembali hanya jika modul win_feature mengembalikan persyaratan ini kepada kami dalam bentuk variabel.
Langkah selanjutnya adalah menginstal SQL. Sejuta cara telah diciptakan untuk melakukan ini. Saya menggunakan modul win_chocolatey di sini. Ini adalah manajer paket untuk Windows. Ya, itulah tepatnya yang biasa kami gunakan di Linux. Modul didukung oleh masyarakat, dan sekarang sudah ada lebih dari enam ribu di antaranya. Saya sangat menyarankan Anda untuk mencoba.
- name: SQL Server hosts: dbservers tasks: - name: Install MS SQL Server 2014 win_chocolatey: name: mssqlserver2014express state: present
Jadi, kami menyiapkan tuan rumah untuk meluncurkan aplikasi, mari kita gunakan!
- name: Deploy binaries hosts: webservers vars: myapp_artifacts: files/MyAppService.zip myapp_workdir: C:\myapp tasks: - name: Remove Service if exists win_service: name: MyAppService state: absent path: "{{ myapp_workdir }}\\MyAppService.exe"
Untuk berjaga-jaga, hal pertama yang kami lakukan adalah menghapus layanan yang ada.
- name: Delete old files win_file: path: "{{ myapp_workdir }}\\" state: absent - name: Copy artifacts to remote machine win_copy: src: "{{ myapp_artifacts }}" dest: "{{ myapp_workdir }}\\" - name: Unzip build artifacts win_unzip: src: "{{ myapp_workdir }}\\MyAppService.zip" dest: "{{ myapp_workdir }}"
Langkah selanjutnya adalah mengunggah artefak baru ke host. Playbook ini menyiratkan bahwa ia berjalan pada server build, semua arsip ada di folder yang terkenal, dan kami menunjukkan path ke sana dengan variabel. Setelah menyalin (win_copy), arsip dibongkar (win_unzip). Kemudian kita hanya mendaftarkan layanan, katakan path ke exe dan itu harus dimulai.
- name: Register and start the service win_service: name: ReporterService start_mode: auto state: started path: "{{ myapp_workdir }}\\MyAppService.exe"
Selesai!?
Tampaknya layanan kami siap untuk bekerja dan bertahan, namun, ada satu "tetapi" - kami tidak mematuhi prinsip idempotensi. Kami selalu menghapus kode yang ada dan kemudian menggunakan yang baru.
Dan itu masalahnya. Jika kami menghapus layanan out-of-service lama, dan setelah beberapa jenis kesalahan terjadi dan playbook tidak menyelesaikan pekerjaannya, kami akan mendapatkan host yang rusak. Atau, misalnya, kami menggunakan beberapa aplikasi secara bersamaan, yang salah satunya tidak berubah, maka kami tidak perlu menggunakannya juga.
Apa yang bisa dilakukan? Atau, Anda dapat memeriksa checksum artefak kami dan membandingkannya dengan yang ada di server.
- name: Get arifacts checksum stat: path: "{{ myapp_artifacts }}" delegate_to: localhost register: myapp_artifacts_stat - name: Get remote artifacts checksum win_stat: path: "{{ myapp_workdir }}\\MyAppService.zip" register: myapp_remote_artifacts_stat
Kami menggunakan modul stat, yang menyediakan semua jenis informasi tentang file, termasuk checksum. Selanjutnya, menggunakan register directive yang sudah dikenal, kami menulis hasilnya menjadi variabel. Dari menarik: delegate_to menunjukkan bahwa ini harus dilakukan pada mesin lokal tempat playbook dimulai.
- name: Stop play if checksums match meta: end_play when: - myapp_artifacts_stat.stat.checksum is defined - myapp_remote_artifacts_stat.stat.checksum is defined - myapp_artifacts_stat.stat.checksum == myapp_remote_artifacts_stat.stat.checksum
Dan menggunakan modul meta, kami mengatakan bahwa Anda harus menyelesaikan buku pedoman jika checksum dari artefak pada mesin lokal dan jarak jauh cocok. Inilah bagaimana kami mengamati prinsip idempotensi.
- name: Ensure that the WebApp application exists win_iis_webapplication: name: WebApp physical_path: c:\webapp site: Default Web Site state: present
Sekarang mari kita lihat aplikasi web kami. Kami menghilangkan bagian tentang menyalin file, langsung ke intinya. Server build kami membuat penerbit, mengunggah semua file yang lepas ke host dan menggunakan modul bawaan untuk bekerja dengan aplikasi IIS. Dia akan membuat aplikasi dan menjalankannya.
Penggunaan kembali kode
Salah satu tugas yang kami tetapkan adalah: untuk memungkinkan setiap insinyur di perusahaan untuk dengan mudah meluncurkan penempatan. Dia menulis buku pedomannya dari modul yang sudah jadi, mengatakan bahwa dia perlu menjalankan produk ini dan itu pada host ini dan itu.
Untuk ini, Ansible memiliki Peran. Ini pada dasarnya adalah sebuah konvensi. Kami membuat folder / peran / di server dan memasukkan peran kami ke dalamnya. Setiap peran adalah sekumpulan file konfigurasi: deskripsi perangkat, variabel, file layanan, dll. Biasanya beberapa entitas yang terisolasi membuat peran. Menginstal IIS adalah contoh yang bagus jika kita tidak hanya perlu menginstalnya, tetapi juga mengkonfigurasi atau memeriksanya dengan tugas tambahan. Kami membuat peran yang terpisah dan dengan demikian mengisolasi semua buku pedoman terkait IIS di folder peran. Di masa mendatang, kami cukup memanggil peran ini dengan directive include_role% role_name%.
Secara alami, kami membuat peran untuk semua aplikasi, meninggalkan peluang bagi insinyur untuk menyesuaikan proses menggunakan parameter konfigurasi.
- name: Run App hosts: webservers tasks: - name: "Install IIS" include_role: name: IIS - name: Run My App include_role: name: MyAppService vars: myapp_artifacts: ./buld.zip
Dalam contoh ini, peran Jalankan Aplikasi Saya memiliki kemampuan untuk mentransfer beberapa jalur ke artefak.
Di sini Anda harus memasukkan kata tentang Ansible Galaxy - repositori solusi standar yang umum tersedia. Seperti biasa dalam masyarakat yang baik, banyak masalah telah diselesaikan sebelum kita. Dan jika ada perasaan bahwa sekarang kita akan mulai menemukan kembali roda, maka pertama-tama Anda perlu melihat daftar modul bawaan, dan kemudian mempelajari Ansible Galaxy. Kemungkinan buku pedoman yang Anda butuhkan sudah dibuat oleh orang lain. Ada sejumlah besar modul di sana, untuk semua kesempatan.
Lebih banyak fleksibilitas
Tetapi bagaimana jika tidak ada modul bawaan atau peran yang sesuai di Galaxy? Ada dua opsi: apakah kita melakukan sesuatu yang salah, atau kita benar-benar memiliki tugas yang unik.
Dalam hal opsi kedua, kita selalu dapat menulis modul kita. Seperti yang saya tunjukkan pada Anda di awal, Ansible memungkinkan untuk menulis modul paling sederhana dalam 10 menit, dan ketika Anda masuk lebih dalam, dokumentasi yang cukup terperinci akan membantu Anda, mencakup banyak pertanyaan.
Ci
Di departemen kami, kami sangat menyukai TeamCity, tetapi mungkin ada server CI lain yang Anda pilih. Mengapa kita perlu membagikannya?
Pertama, kita selalu dapat memeriksa sintaks playbook kita. Sementara YAML menganggap tab sebagai kesalahan sintaksis, ini adalah fitur yang sangat berguna.
Juga di server CI kami menjalankan annot-lint. Ini adalah penganalisa statis dari konfigurasi yang memungkinkan, yang memberikan daftar rekomendasi.
Sebagai contoh, di sini dia mengatakan bahwa kita memiliki ruang ekstra di akhir baris, dan untuk satu tugas tidak ada nama yang diberikan. Ini penting karena nama modul dapat muncul beberapa kali dalam buku pedoman yang sama, dan semua tugas harus dinamai.
Tentu saja, Anda masih bisa menulis tes untuk buku pedoman. Kita tidak bisa melakukan ini karena kami akan menyebar ke lingkungan pengujian dan tidak ada hal penting yang akan terjadi. Tetapi jika Anda menyebarkan ke prod, maka akan lebih baik untuk memeriksa semuanya. Manfaat ansible memungkinkan Anda untuk menguji tidak hanya buku pedoman, tetapi juga modul individual. Jadi pastikan untuk memperhatikannya.
Dan alasan utama kedua untuk menggunakan server CI adalah untuk meluncurkan buku pedoman. Ini adalah tombol ajaib yang sama "Lakukan dengan baik", yang memberi kita TeamCity. Kami hanya membuat beberapa konfigurasi sederhana untuk produk yang berbeda, di mana kami katakan: ansible-playbook reporter_vm.yml -i inventory.yml -vvvv dan dapatkan tombol Deploy.
Kenyamanan bonus: Anda dapat membangun build tergantung pada build. Segera setelah sesuatu terkonsolidasi, TeamCity memulai proses penempatan ulang, setelah itu kita hanya bisa melihat log jika ada sesuatu yang tiba-tiba pecah.
Total
- Skrip PowerShell yang bingung dan berbeda kami ganti dengan YAML-configs.
- Kami mengganti berbagai implementasi dari masalah yang sama dengan peran umum yang dapat digunakan kembali. Repositori telah dibuat di mana peran itu berada. Jika peran itu cocok untuk Anda, Anda cukup menggunakannya. Jika tidak sesuai dengan Anda, Anda cukup mengirim permintaan kumpulan, dan itu cocok untuk Anda =)
- Anda sekarang dapat memverifikasi keberhasilan penyebaran di satu tempat.
- Semua orang tahu di mana mencari log.
- Masalah komunikasi juga diselesaikan melalui repositori bersama dan TeamCity. Semua orang yang tertarik tahu di mana buku pedoman berada dan bagaimana cara kerjanya.
PS Semua contoh dari artikel dapat diambil di github .