Hari yang baik
Kami memiliki beberapa cluster cloud dengan sejumlah besar mesin virtual di masing-masingnya. Semua bisnis ini di-host di Hetzner'e. Di setiap cluster, kami memiliki satu mesin master, sebuah snapshot diambil darinya dan didistribusikan secara otomatis ke semua mesin virtual di dalam cluster.
Skema ini tidak memungkinkan kita untuk menggunakan gitlab-pelari secara normal, karena banyak masalah muncul ketika banyak pelari terdaftar yang identik muncul, yang mendorong kita untuk mencari solusi dan menulis artikel / manual ini.
Ini mungkin bukan praktik terbaik, tetapi solusi ini tampak senyaman dan sesederhana mungkin.
Untuk tutorialnya, saya minta kucing.
Paket yang diperlukan pada mesin master:- ular sanca
- git
- file dengan kunci ssh
Prinsip umum penerapan tarikan usus otomatis pada semua mesin virtual adalah bahwa Anda memerlukan mesin tempat Ansible akan diinstal. Dari mesin ini, ansible akan mengirimkan perintah git pull dan memulai kembali layanan yang telah diperbarui. Kami menciptakan mesin virtual terpisah di luar cluster untuk tujuan ini, dan diinstal di atasnya:
- ular sanca
- mungkin
- gitlab-runner
Dari masalah organisasi - Anda perlu mendaftar gitlab-runner, membuat ssh-keygen, letakkan kunci ssh publik dari mesin ini di
.ssh/authorized_keys pada mesin master, buka port 22 untuk memungkinkan pada mesin master.
Sekarang konfigurasikan yang mungkin
Karena tujuan kami adalah untuk mengotomatiskan segala sesuatu yang mungkin. Dalam file
/etc/ansible/ansible.cfg kita batalkan komentar pada baris
host_key_checking = False sehingga tidak memungkinkan untuk meminta konfirmasi mesin baru.
Selanjutnya, Anda perlu secara otomatis membuat file inventaris untuk suatu kemungkinan, dari mana ia akan mengambil ip dari mesin yang Anda butuhkan untuk melakukan git pull.
Kami membuat file ini menggunakan Hetzner API, tetapi Anda dapat mengambil daftar host dari AWS, Asure, database Anda (Anda memiliki API di suatu tempat untuk menampilkan mesin Anda yang sedang berjalan, bukan?).
Struktur file inventaris sangat penting bagi Ansible, penampilannya harus sebagai berikut:
[] ip- ip- [2] ip- ip-
Untuk menghasilkan file seperti itu, mari buat skrip sederhana (sebut saja
vm_list ):
Saatnya untuk memeriksa apakah ansible berfungsi dan berteman dengan penerima alamat ip:
/etc/ansible/./vm_list && ansible -i /etc/ansible/cloud_ip -m shell -a 'hostname' group
Keluaran harus menerima nama host dari mesin di mana perintah dieksekusi.
Beberapa kata tentang sintaks:
- /etc/ansible/./vm_list - buat daftar mesin
- -i - path absolut ke file inventaris
- -m - beri tahu yang mungkin menggunakan modul shell
- -a adalah argumen. Setiap tim dapat dimasukkan di sini.
- grup adalah nama kluster Anda. Jika perlu Anda lakukan pada semua cluster, ubah grup menjadi semua
Silakan - coba lakukan git pull pada mesin virtual kami:
/etc/ansible/./vm_list && ansible -i /etc/ansible/cloud_ip -m shell -a 'cd /path/to/project && git pull' group
Jika kita melihat sudah up to date atau membongkar dari repositori di output, maka semuanya berfungsi.
Sekarang untuk apa semua itu dimaksudkan
Kami mengajarkan skrip kami untuk dieksekusi secara otomatis ketika melakukan di cabang master di gitlab
Pertama, kita akan membuat skrip kita lebih indah dan meletakkannya di file yang dapat dieksekusi (sebut saja exec_pull) -
Kami pergi ke gitlab kami dan dalam proyek kami membuat file
.gitlab-ci.ymlDi dalam kami menempatkan yang berikut:
variables: GIT_STRATEGY: none VM_GROUP: group stages: - pull - restart run_exec_pull: stage: pull script: - /etc/ansible/exec_pull 'cd /path/to/project/'$CI_PROJECT_NAME' && git pull' $VM_GROUP only: - master run_service_restart: stage: restart script: - /etc/ansible/exec_pull 'your_app_stop && your_app_start' $VM_GROUP only: - master
Semuanya sudah siap. Sekarang -
- membuat komitmen
- bersukacitalah bahwa semuanya bekerja
Saat porting .yml ke proyek lain, Anda hanya perlu mengubah nama layanan untuk restart dan nama cluster di mana perintah yang mungkin dijalankan.