🥇Pendekatan sistematik kepada pembolehubah dalam Ansible

gaya kod devops ansible

Hey! Nama saya ialah Denis Kalyuzhny Saya bekerja sebagai jurutera di bahagian automasi proses pembangunan. Setiap hari, binaan aplikasi baharu dilancarkan pada ratusan pelayan kempen. Dan dalam artikel ini saya berkongsi pengalaman saya menggunakan Ansible untuk tujuan ini.

Panduan ini menawarkan cara untuk mengatur pembolehubah dalam penggunaan. Panduan ini ditujukan untuk mereka yang sudah menggunakan peranan dalam buku permainan mereka dan telah membaca Amalan terbaik, tetapi menghadapi masalah yang sama:

Setelah menemui pembolehubah dalam kod, adalah mustahil untuk segera memahami apa yang bertanggungjawab;
Terdapat beberapa peranan, dan pembolehubah perlu dikaitkan dengan satu nilai, tetapi ia tidak berfungsi;
Menghadapi kesukaran untuk menerangkan kepada orang lain bagaimana logik pembolehubah dalam buku permainan anda berfungsi

Kami menghadapi masalah ini pada projek di syarikat kami, akibatnya kami mendapat peraturan untuk mereka bentuk pembolehubah dalam buku permainan kami, yang sedikit sebanyak menyelesaikan masalah ini.

Pembolehubah dalam peranan

Peranan ialah Objek berasingan sistem penempatan. Seperti mana-mana objek sistem, ia mesti mempunyai antara muka untuk interaksi dengan seluruh sistem. Antara muka sedemikian adalah pembolehubah peranan.

Mari kita ambil, sebagai contoh, peranan api, yang memasang aplikasi Java pada pelayan. Apakah pembolehubah yang mungkin ada?

Peranan boleh ubah boleh dibahagikan kepada 2 jenis mengikut jenis:

1. Свойства
    a) независимые от среды
    б) зависимые от среды
2. Связи
    a) слушатели 
    б) запросы внутри системы
    в) запросы в среду

Sifat boleh ubah adalah pembolehubah yang menentukan tingkah laku sesuatu peranan.

Pembolehubah Pertanyaan - ini adalah pembolehubah yang nilainya digunakan untuk menetapkan sumber di luar peranan.

Pendengar boleh ubah - ini adalah pembolehubah yang nilainya digunakan untuk membentuk pembolehubah permintaan.

Sebaliknya, 1a, 2a, 2b ialah pembolehubah yang tidak bergantung pada persekitaran (perkakasan, sumber luaran, dll.) dan boleh diisi dengan nilai lalai dalam peranan lalai. Walau bagaimanapun, adalah mustahil untuk mengisi pembolehubah jenis 1.b dan 2.c dengan nilai selain daripada 'contoh', kerana ia akan berubah dari dirian ke dirian bergantung pada persekitaran.

Gaya kod

Nama pembolehubah mesti bermula dengan nama peranan. Ini akan memudahkan untuk mengetahui pada masa hadapan dari mana peranan pembolehubah itu dan apa yang ia bertanggungjawab.
Apabila menggunakan pembolehubah dalam peranan, anda mesti pastikan untuk mengikut prinsip enkapsulasi dan menggunakan pembolehubah yang ditakrifkan sama ada dalam peranan itu sendiri atau dalam peranan yang bergantung pada peranan semasa.
Elakkan menggunakan kamus untuk pembolehubah. Ansible tidak membenarkan anda mengatasi nilai individu dengan mudah dalam kamus.

Contoh pembolehubah buruk:
```
myrole_user:
    login: admin
    password: admin
```
Di sini log masuk ialah pembolehubah bebas, dan kata laluan ialah pembolehubah bersandar. Tetapi
kerana ia digabungkan menjadi kamus, anda perlu menentukannya sepenuhnya
Sentiasa. Yang sangat menyusahkan. Lebih baik dengan cara ini:
```
myrole_user_login: admin
myrole_user_password: admin
```

Pembolehubah dalam buku main penggunaan

Apabila menyusun buku main penggunaan (selepas ini dirujuk sebagai buku main), kami mematuhi peraturan bahawa ia harus diletakkan dalam repositori yang berasingan. Sama seperti peranan: masing-masing dalam repositori git sendiri. Ini membolehkan anda memahami bahawa peranan dan buku main ialah objek bebas yang berbeza bagi sistem penempatan, dan perubahan dalam satu objek tidak seharusnya menjejaskan operasi objek yang lain. Ini dicapai dengan menukar nilai lalai pembolehubah.

Apabila menyusun buku permainan, untuk meringkaskan, adalah mungkin untuk mengatasi nilai lalai pembolehubah peranan di dua tempat: dalam pembolehubah buku permainan dan dalam pembolehubah inventori.

mydeploy                        # Каталог деплоя
├── deploy.yml                  # Плейбук деплоя
├── group_vars                  # Каталог переменных плейбука
│   ├── all.yml                 # Файл для переменных связи всей системы
│   └── myapi.yml               # Файл переменных свойств группы myapi
└── inventories                 #
    └── prod                    # Каталог окружения prod
        ├── prod.ini            # Инвентори файл
        └── group_vars          # Каталог для переменных инвентори
            └── myapi           #
                ├── vars.yml    # Средозависимые переменные группы myapi
                └── vault.yml   # Секреты (всегда средозависимы) *

* - Pembolehubah dan Bilik Kebal

Perbezaannya ialah pembolehubah playbook sentiasa digunakan apabila memanggil playbook yang terletak pada tahap yang sama dengannya. Ini bermakna pembolehubah ini bagus untuk menukar nilai lalai pembolehubah bebas persekitaran. Sebaliknya, pembolehubah inventori hanya akan digunakan untuk persekitaran tertentu, yang sesuai untuk pembolehubah khusus persekitaran.

Adalah penting untuk ambil perhatian bahawa keutamaan pembolehubah tidak akan membenarkan anda mengatasi pembolehubah terlebih dahulu dalam pembolehubah buku main dan kemudian secara berasingan dalam satu inventori.

Ini bermakna bahawa sudah pada peringkat ini adalah perlu untuk memutuskan sama ada pembolehubah itu bergantung kepada persekitaran atau tidak dan meletakkannya di tempat yang sesuai.

Sebagai contoh, dalam satu projek, pembolehubah yang bertanggungjawab untuk mendayakan SSL adalah bergantung kepada persekitaran untuk masa yang lama, kerana kami tidak dapat mendayakan SSL atas sebab di luar kawalan kami di salah satu gerai. Selepas kami membetulkan masalah ini, ia menjadi bebas persekitaran dan berpindah ke pembolehubah buku permainan.

Pembolehubah Harta untuk Kumpulan

Mari kembangkan model kami dalam Rajah 1 dengan menambah 2 kumpulan pelayan dengan aplikasi Java yang berbeza, tetapi dengan tetapan yang berbeza.

Mari bayangkan bagaimana rupa buku permainan dalam kes ini:

- hosts: myapi
  roles:
    - api

- hosts: bbauth
  roles:
    - auth

- hosts: ghauth
  roles:
    - auth

Kami mempunyai tiga kumpulan dalam buku main, jadi anda disyorkan serta-merta untuk mencipta bilangan fail kumpulan yang sama dalam pembolehubah inventori group_vars dan pembolehubah buku permainan. Satu fail kumpulan dalam kes ini ialah perihalan satu komponen aplikasi di atas dalam buku main. Apabila anda membuka fail kumpulan dalam pembolehubah buku permainan, anda serta-merta melihat semua perbezaan daripada kelakuan lalai peranan yang dipasang pada kumpulan. Dalam pembolehubah inventori: perbezaan dalam tingkah laku kumpulan dari pendirian ke pendirian.

Gaya Kod

Cuba untuk tidak menggunakan pembolehubah host_vars sama sekali, kerana mereka tidak menerangkan sistem, tetapi hanya kes khas, yang pada masa hadapan akan membawa kepada soalan: "Mengapa hos ini berbeza daripada yang lain?", jawapan yang tidak sentiasa mudah dicari.

Pembolehubah Komunikasi

Walau bagaimanapun, itulah yang dimaksudkan dengan pembolehubah sifat, tetapi bagaimana pula dengan pembolehubah komunikasi?
Perbezaan mereka ialah mereka harus mempunyai makna yang sama dalam kumpulan yang berbeza.

Pada mulanya ia adalah idea gunakan pembinaan yang dahsyat seperti:
hostvars[groups['bbauth'][0]]['auth_bind_port'], tetapi mereka segera menolaknya
kerana ia mempunyai kelemahan. Pertama, bulkiness. Kedua, pergantungan pada hos tertentu dalam kumpulan. Ketiga, sebelum memulakan penggunaan, adalah perlu untuk mengumpul fakta daripada semua hos jika kita tidak mahu mendapatkan ralat pembolehubah yang tidak ditentukan.

Akibatnya, ia telah memutuskan untuk menggunakan pembolehubah komunikasi.

Pembolehubah Komunikasi - ini adalah pembolehubah yang dimiliki oleh buku main dan diperlukan untuk menyambungkan objek sistem.

Pembolehubah komunikasi diisi dalam pembolehubah sistem umum group_vars/all/vars dan dibentuk dengan mengalih keluar semua pembolehubah pendengar daripada setiap kumpulan, dan menambah nama kumpulan dari mana pendengar telah dialih keluar ke permulaan pembolehubah.

Ini memastikan keseragaman dan tidak bertindih nama.

Mari cuba untuk mengikat pembolehubah dari contoh di atas:

Mari kita bayangkan bahawa kita mempunyai pembolehubah yang bergantung antara satu sama lain:

# roles/api/defaults:
# Переменная запроса
api_auth1_address: "http://example.com:80"
api_auth2_address: "http://example2.com:80"

# roles/auth/defaults:
# Переменная слушатель
auth_bind_port: "20000"

Mari kita masukkan ke dalam pembolehubah biasa group_vars/all/vars semua pendengar, dan tambahkan nama kumpulan pada tajuk:

# group_vars/all/vars
bbauth_auth_bind_port: "20000"
ghauth_auth_bind_port: "30000"

# group_vars/bbauth/vars
auth_bind_port: "{{ bbauth_auth_bind_port }}"

# group_vars/ghauth/vars
auth_bind_port: "{{ ghauth_auth_bind_port }}"

# group_vars/myapi/vars
api_auth1_address: "http://{{ bbauth_auth_service_name }}:{{ bbauth_auth_bind_port }}"
api_auth2_address: "http://{{ ghauth_auth_service_name }}:{{ ghauth_auth_bind_port }}"

Sekarang, dengan menukar nilai penyambung, kami akan memastikan bahawa permintaan akan pergi ke tempat yang sama di mana pelabuhan itu terletak.

Gaya Kod

Oleh kerana peranan dan kumpulan adalah objek sistem yang berbeza, mereka perlu mempunyai nama yang berbeza, maka pembolehubah pautan akan menunjukkan dengan tepat bahawa mereka tergolong dalam kumpulan pelayan tertentu, dan bukan peranan dalam sistem.

Fail bergantung kepada persekitaran

Peranan boleh menggunakan fail yang berbeza dari persekitaran ke persekitaran.

Contoh fail tersebut ialah sijil SSL. Simpannya dalam bentuk teks
dalam pembolehubah tidak begitu mudah. Tetapi adalah mudah untuk menyimpan laluan kepada mereka di dalam pembolehubah.

Sebagai contoh, kita menggunakan pembolehubah api_ssl_key_file: "/path/to/file".

Memandangkan adalah jelas bahawa sijil utama akan berubah dari persekitaran ke persekitaran, ini adalah pembolehubah yang bergantung kepada persekitaran, yang bermaksud ia harus terletak dalam fail
group_vars/myapi/vars inventori pembolehubah, dan mengandungi nilai 'sebagai contoh'.

Cara yang paling mudah dalam kes ini ialah meletakkan fail utama dalam repositori playbook di sepanjang laluan
files/prod/certs/myapi.key, maka nilai pembolehubah ialah:
api_ssl_key_file: "prod/certs/myapi.key". Kemudahannya terletak pada fakta bahawa orang yang bertanggungjawab untuk menggunakan sistem pada pendirian tertentu juga mempunyai ruang khusus mereka sendiri dalam repositori untuk menyimpan fail mereka. Pada masa yang sama, masih mungkin untuk menentukan laluan mutlak ke sijil pada pelayan, sekiranya sijil dibekalkan oleh sistem lain.

Berbilang berdiri dalam satu persekitaran

Selalunya terdapat keperluan untuk menggunakan beberapa tempat berdiri yang hampir sama dalam persekitaran yang sama dengan perbezaan yang minimum. Dalam kes ini, kami membahagikan pembolehubah bergantung kepada persekitaran kepada pembolehubah yang tidak berubah dalam persekitaran ini dan pembolehubah yang berubah. Dan kami memindahkan yang terakhir terus ke fail inventori itu sendiri. Selepas manipulasi ini, anda boleh membuat inventori lain secara langsung dalam direktori persekitaran.

Ia akan menggunakan semula inventori group_vars, dan juga akan dapat mentakrifkan semula beberapa pembolehubah secara langsung untuk dirinya sendiri.

Struktur direktori akhir untuk projek penempatan:

mydeploy                        # Каталог деплоя
├── deploy.yml                  # Плейбук деплоя
├── files                       # Каталог для файлов деплоя
│   ├── prod                    # Католог для средозависимых файлов стенда prod
│   │   └── certs               # 
│   │       └── myapi.key       #
│   └── test1                   # Каталог для средозависимых файлов стенда test1
├── group_vars                  # Каталог переменных плейбука
│   ├── all.yml                 # Файл для переменных связи всей системы
│   ├── myapi.yml               # Файл переменных свойств группы myapi
│   ├── bbauth.yml              # 
│   └── ghauth.yml              #
└── inventories                 #
    ├── prod                    # Каталог окружения prod
    │   ├── group_vars          # Каталог для переменных инвентори
    │   │   ├── myapi           #
    │   │   │   ├── vars.yml    # Средозависимые переменные группы myapi
    │   │   │   └── vault.yml   # Секреты (всегда средозависимы)
    │   │   ├── bbauth          # 
    │   │   │   ├── vars.yml    #
    │   │   │   └── vault.yml   #
    │   │   └── ghauth          #
    │   │       ├── vars.yml    #
    │   │       └── vault.yml   #
    │   └── prod.ini            # Инвентори стенда prod
    └── test                    # Каталог окружения test
        ├── group_vars          #
        │   ├── myapi           #
        │   │   ├── vars.yml    #
        │   │   └── vault.yml   #
        │   ├── bbauth          #
        │   │   ├── vars.yml    #
        │   │   └── vault.yml   #
        │   └── ghauth          #
        │       ├── vars.yml    #
        │       └── vault.yml   #
        ├── test1.ini           # Инвентори стенда test1 в среде test
        └── test2.ini           # Инвентори стенда test2 в среде test

Menjumlahkan

Selepas mengatur pembolehubah mengikut artikel: setiap fail pembolehubah bertanggungjawab untuk tugas tertentu. Dan kerana fail itu mempunyai tugas tertentu, ia menjadi mungkin untuk menetapkan seseorang yang bertanggungjawab untuk ketepatan setiap fail. Sebagai contoh, pembangun penggunaan sistem bertanggungjawab untuk mengisi pembolehubah buku permainan yang betul, manakala pentadbir yang pendiriannya diterangkan dalam inventori bertanggungjawab secara langsung untuk mengisi inventori pembolehubah.

Peranan menjadi unit pembangunan mereka sendiri dengan antara muka mereka sendiri, membolehkan pembangun peranan membangunkan keupayaan dan bukannya menyesuaikan peranan dengan sistem. Masalah ini terutamanya melibatkan peranan umum untuk semua sistem dalam kempen.

Pentadbir sistem tidak perlu lagi memahami kod penggunaan. Apa yang diperlukan daripada mereka untuk penggunaan yang berjaya ialah mengisi fail pembolehubah yang bergantung kepada persekitaran.

Kesusasteraan

Dokumentasi

Pengarang

Kalyuzhny Denis Alexandrovich

Sumber: www.habr.com

Pendekatan sistem kepada pembolehubah dalam Ansible

Pembolehubah dalam peranan

Gaya kod

Pembolehubah dalam buku main penggunaan

Pembolehubah Harta untuk Kumpulan

Gaya Kod

Pembolehubah Komunikasi

Gaya Kod

Fail bergantung kepada persekitaran

Berbilang berdiri dalam satu persekitaran

Struktur direktori akhir untuk projek penempatan:

Menjumlahkan

Kesusasteraan

Pengarang

Tambah komen Batal reply