Saya juga mengalami masalah ini, sepertinya vars diurai dan dilampirkan ke host daripada tetap bersama grup.

Langkah Untuk Mereproduksi:

File host:

[aaa]
host1
host2

[bbb]
host2
host3

[aaa:vars]
foo=aaa

[bbb:vars]
foo=bbb

Jalankan perintah di setiap grup:

$ ansible -i hosts aaa -m shell -a "echo {{ foo }}"
host1 | success | rc=0 >>
aaa

host2 | success | rc=0 >>
bbb

$ ansible -i hosts bbb -m shell -a "echo {{ foo }}"
host2 | success | rc=0 >>
bbb

host3 | success | rc=0 >>
bbb

Hasil yang diharapkan:

Variabel foo=aaa dipisahkan ke grup aaa dan harus dikeluarkan saat menjalankan perintah terhadap grup aaa

Hasil nyata:

host2 mengeluarkan variabel dari grup bbb

Punya masalah yang sama.

Contoh:

./group_vars/group1:

---
name: group1

./group_vars/group2

---
name: group2-default

file host:

[group1]
host1

[group2]
host1

Jadi, ketika saya mencoba menjalankan playbook untuk group1 saja, saya mendapatkan hasil ini:
Variabel " name " memiliki nilai " group2-default " tetapi diharapkan memiliki nilai " group1 ".

Apakah ada solusi untuk ini?

inventaris vars digabungkan bahkan jika Anda tidak menggunakan grup itu, grup terakhir
kemenangan gabungan

Brian Coca

@bcoca Mengapa cara kerjanya seperti itu? Apakah ini perilaku yang diharapkan, atau bug yang sebenarnya?

Anda dapat memiliki file vars / service (1,2,3, ...)

Dan lulus layanan = 1 sebagai vars ekstra

Kemudian untuk host yang menargetkan Anda di pedoman, gunakan variabel layanan,
serta file vars mana yang Anda impor

Kami melakukan hal serupa untuk mengimpor vars berdasarkan lingkungan extra var
Pada 26 Nov 2014 15:12, "arianitu" [email protected] menulis:

@bcoca https://github.com/bcoca Mengapa demikian? Apakah ini
perilaku yang diharapkan, atau bug yang sebenarnya?

-
Balas email ini secara langsung atau lihat di GitHub
https://github.com/ansible/ansible/issues/9065#issuecomment -64718173.

Saya memiliki masalah yang sama di 1.8.4 hari ini.
Akhirnya, apakah ini perilaku yang benar atau tidak?
Apakah ada yang tahu kemajuannya?

Hmm. Sepertinya tag 'bug_report' salah di sini. Ini bukan bug tapi .. fitur :-)
Jadi ya, itu perilaku yang benar.

Seperti yang dikatakan @hashnz , "vars diurai dan dilampirkan ke host daripada tinggal dengan grup" yang sepenuhnya benar.

Variabel dalam grup berbeda di mana host yang sama adalah anggotanya, hanya masuk akal jika grup tersebut berada dalam relasi orang tua-anak, anak menang, dan varsnya diterapkan. Jika kelompok berada pada level yang sama, sebenarnya tidak ada cara deterministik mana yang akan menang.

Pada waktu pedoman, menargetkan grup sebenarnya hanya menentukan host mana yang sedang dijalankan, itu tidak mengubah apa pun pada tingkat variabel.

Cara yang memungkinkan di sini adalah dengan mengatur host database dan port dalam daftar, dan mengulanginya dalam tugas.

@bcoca @ jimi-c Saya rasa masalah ini bisa ditutup.

@srvg Terima kasih banyak! Saya mendapatkannya. Saya akan mencoba tanpa menggunakan group_vars.

menutup karena ini bukan bug tetapi dengan desain, vars grup diratakan per host dan tidak bervariasi karena cara Anda memilih host

Adakah yang punya solusi untuk ini?

kami tidak dapat menggunakan variabel statis di playbook, karena kami perlu membedakan antara lingkungan yang berbeda (ditangani oleh file inventaris yang berbeda) dan perlu menjalankan dengan variabel yang berbeda, tergantung pada grup yang dijalankan, meskipun mereka dijalankan pada host yang sama dengan kelompok lain

Gunakan CNAME untuk nama host yang sama atau alamat IP. Ini satu-satunya
solusi yang saya temukan. Masalah muncul saat Anda menggunakan Ansible Tower,
karena Anda menyia-nyiakan lisensi dengan CNAME semacam itu. Mungkin tidak mau
perbaiki bug ini dengan menyebutnya sebagai "fitur", tetapi sebenarnya itu bug nyata yang harus
diperbaiki.
28 Апр 2015 г. 17:16 пользователь "SkaveRat" [email protected]
написал:

Adakah yang punya solusi untuk ini?

kami tidak dapat menggunakan vars statis dalam pedoman, karena kami perlu membedakan
antara lingkungan yang berbeda (ditangani oleh file inventaris yang berbeda) dan
perlu dijalankan dengan variabel yang berbeda, tergantung pada grup yang dijalankan, bahkan
sulit mereka dijalankan pada tuan rumah yang sama dengan kelompok lain

-
Balas email ini secara langsung atau lihat di GitHub
https://github.com/ansible/ansible/issues/9065#issuecomment -97077453.

Sudah diperbaiki tapi ditolak. https://github.com/ansible/ansible/pull/6666

Hal yang menjengkelkan adalah bahwa pemandu yang memungkinkan memang merekomendasikan untuk mengelompokkan mereka berdasarkan peran

http://docs.ansible.com/playbooks_best_practices.html

Disarankan agar Anda menentukan grup berdasarkan tujuan tuan rumah (peran) dan juga lokasi geografi atau pusat data (jika berlaku)

Tetapi jika host yang sama memiliki banyak peran dengan variabel yang sama, Anda tidak dapat menggunakan variabel grup karena Anda tidak tahu variabel mana yang akan digunakan.

Saya masih tidak mengerti cara mengikat variabel ke host tertentu untuk buku pedoman tertentu. Saya ingin kemampuan untuk menggunakan template yang sama, tetapi dengan nilai konfigurasi yang berbeda tergantung pada lingkungan tempat saya menerapkan.

Kami telah mengikuti http://docs.ansible.com/ansible/playbooks_best_practices.html#staging -vs-production, dengan membuat inventaris berbeda untuk lingkungan kami yang berbeda

Mengapa ini tampak sangat sulit dengan Ansible? Apakah Ansible hanya buruk dalam melakukan penerapan berbasis lingkungan?

Berikan contoh lengkap, karena "Cara yang memungkinkan di sini adalah menyetel host database dan port dalam daftar, dan mengulanginya dalam tugas." tidak masuk akal bagi saya. Dimana lingkungan ditentukan di sini?

Misalnya, saya memiliki layanan otentikasi yang memiliki variabel bernama authentication_db_host: 127.0.0.1 untuk panggung, dan authentication_db_host: 192.168.2.4 untuk siaran langsung. Apakah Anda ingin saya memiliki 2 variabel?

authentication_db_host_stage: 127.0.0.1
authentication_db_host_live: 192.168.2.4

Sekarang sulit bagi saya untuk memasukkannya ke file template umum. Saya perlu menambahkan jika lagi memeriksa seluruh file j2 saya (dan kami pergi ke jalur itu, tetapi itu terlalu banyak duplikasi dan kami menyingkirkannya.)

Saya belum menemukan dokumentasi yang menangani kasus ini, dan sepertinya hal itu tidak akan sulit untuk dilakukan.

Inilah cara kami melakukannya:

Instans AWS diberi tag sebagai:

someapi: prod

pedoman someapi.yml

• host: tag_someapi _ {{env}}
  gathering_facts: true
  pengguna: ec2-user
  vars_files:

  • vars / aws _ {{env}}

  tugas:

  • gagal: msg = "Env harus ditentukan"
    when: env tidak ditentukan
    peran:
  • someapi
    ...

Eksekusi dengan vars ekstra

ansible-playbook -vv someapi.yml -e "env = prod"

peran / someapi / tugas / main.yml

• name: Sertakan vars khusus hanya untuk someapi.
  include_vars: someapi _ {{env}}. yml
• name: Place config
  template: src = config.j2
  dest = {{someapi_install_directory}} / configuration.properties
  ...

peran / someapi / vars / someapi_prod.yml

otentikasi_db_host: 192.168.2.4

peran / someapi / vars / someapi_stag.yml

authentication_db_host: 127.0.0.1
...

role / someapi / templates / config.j2

authentication_db_host = {{authentication_db_host}}
...

HTH,

Iain Wright

Pesan email ini bersifat rahasia, hanya ditujukan untuk penerima
disebutkan di atas dan mungkin berisi informasi yang dilindungi hak istimewa, dikecualikan dari
pengungkapan di bawah hukum yang berlaku. Jika Anda bukan penerima yang dituju, lakukan
tidak mengungkapkan atau menyebarkan pesan kepada siapa pun kecuali yang dimaksudkan
penerima. Jika Anda telah menerima pesan ini karena kesalahan, atau tidak bernama
penerima, harap segera beri tahu pengirim melalui email balasan, dan
hapus semua salinan pesan ini.

Pada hari Jumat, 16 Okt 2015 pukul 12.42, arianitu [email protected] menulis:

Saya masih tidak mengerti cara mengikat variabel ke host tertentu untuk a
pedoman tertentu. Saya ingin kemampuan untuk menggunakan template yang sama, tetapi dengan
nilai konfigurasi yang berbeda tergantung pada lingkungan yang saya terapkan
untuk.

Kami sudah mengikuti
http://docs.ansible.com/ansible/playbooks_best_practices.html#staging -vs-production,
dengan membuat inventaris berbeda untuk lingkungan kita yang berbeda

Mengapa ini tampak sangat sulit dengan Ansible? Apakah Mungkin buruk dalam melakukan
penyebaran berbasis lingkungan?

Berikan contoh lengkap, karena "Cara yang mungkin di sini adalah ke
setel host database dan port dalam daftar, dan lakukan iterasi di atasnya dalam tugas. "
tidak masuk akal bagi saya. Dimana lingkungan ditentukan di sini?

Misalnya, saya memiliki layanan otentikasi yang memiliki variabel yang disebut authentication_db_host:
127.0.0.1 untuk Tahap, dan authentication_db_host: 192.168.2.4 untuk live. Melakukan
Anda ingin saya memiliki 2 variabel?

authentication_db_host_stage: 127.0.0.1
otentikasi_db_host_live: 192.168.2.4

Sekarang sulit bagi saya untuk memasukkannya ke file template umum. saya butuh
untuk menambahkan jika lain memeriksa seluruh file j2 saya (dan kami pergi ke jalur itu,
tetapi itu terlalu banyak duplikasi dan kami menyingkirkannya.)

Saya belum menemukan dokumentasi yang menangani kasus ini, dan sepertinya
seperti hal yang seharusnya tidak sulit dilakukan.

-
Balas email ini secara langsung atau lihat di GitHub
https://github.com/ansible/ansible/issues/9065#issuecomment -148816278.

Variabel dalam grup berbeda di mana host yang sama adalah anggotanya, hanya masuk akal jika grup tersebut berada dalam relasi orang tua-anak, anak menang, dan varsnya diterapkan. Jika kelompok berada pada level yang sama, sebenarnya tidak ada cara deterministik mana yang akan menang.

Dapatkah Ansible mendeteksi kasus seperti itu dan membuat peringatan dengan petunjuk solusi yang memungkinkan?

Jika saya memahami dengan benar cara kerjanya - untuk pembaca masa depan seperti saya yang berjuang untuk memahami:

1. Grup host dalam file inventaris menentukan grup host. Variabel grup menentukan variabel apa yang harus disetel untuk host di grup ini.
2. Ketika saya menentukan grup yang akan digunakan untuk memainkan pedoman, ini berarti mengambil semua host yang termasuk dalam grup itu.
3. Setiap permainan dimainkan secara terpisah untuk setiap pembawa acara - tidak ada konteks grup mana yang sedang digunakan. Grup digunakan untuk mengelompokkan host dan variabel grup - untuk menyetel variabel umum ke host tersebut.
4. Jadi, jika sebuah host disebutkan dalam beberapa grup dan grup ini memiliki variabel yang sama dengan nilai yang berbeda, host tersebut diberitahu bahwa karena ia termasuk dalam grup pertama - variabel untuk itu ditetapkan ke nilai grup; kemudian karena host milik grup lain, variabel yang sama dengan nilai yang berbeda ditetapkan membayangi nilai sebelumnya.

Masalah utamanya adalah bahwa variabel dapat digabungkan bahkan dari grup yang tidak saya miliki
ingin bermain sekarang. Saya tidak perlu memeriksa variabel dari grup Saya bukan
bermain saat ini. Mungkin, solusi semi-nya adalah memeriksa variabel
hanya kelompok itu, yang dijadwalkan menjalankan pedoman.

вс, 17 Янв 2016, 20:00, Victor Varvaryuk [email protected] :

Jika saya mengerti benar cara kerjanya - untuk pembaca masa depan seperti saya
yang berjuang untuk memahami:

1. Grup host dalam file inventaris menentukan grup host. Kelompok
   Variabel menentukan variabel apa yang harus diatur untuk host dalam hal ini
   kelompok.
2. Ketika saya menentukan grup yang akan digunakan untuk memainkan pedoman, ini berarti
   ambil semua host yang termasuk dalam grup itu.
3. Setiap permainan dimainkan secara terpisah untuk setiap pembawa acara - tidak ada konteks
   grup mana yang sedang diterapkan. Grup digunakan untuk mengelompokkan host dan grup
   vars - untuk menyetel variabel umum ke host tersebut.
4. Jadi jika sebuah host disebutkan dalam beberapa grup dan grup ini memiliki
   variabel yang sama dengan nilai yang berbeda, tuan rumah diberitahu itu karena itu
   milik grup pertama - variabel untuk itu ditetapkan ke grup
   nilai; kemudian karena tuan rumah milik kelompok lain variabel yang sama
   dengan nilai yang berbeda diatur membayangi nilai sebelumnya.

-
Balas email ini secara langsung atau lihat di GitHub
https://github.com/ansible/ansible/issues/9065#issuecomment -172353019.

Ini tampaknya sangat kontra-intuitif.

Saya memiliki inventaris yang hanya memiliki kotak Gelandangan saya di setiap grup untuk tujuan pengujian.

Tetapi bahkan ketika saya menjalankan buku pedoman yang hanya mereferensikan satu grup, Ansible juga menarik variabel dari grup lain yang melanggar pengujian saya.

Pada 28 April 2016 pukul 17:55, Philip Wigg [email protected] menulis:

Ini tampaknya sangat kontra-intuitif.

Itu karena model mental yang Anda gunakan untuk melihat inventaris bukanlah
yang benar.

Saya memiliki inventaris yang hanya memiliki kotak Gelandangan saya di setiap grup
tujuan pengujian.

Tetapi bahkan saat saya menjalankan pedoman yang hanya mereferensikan satu grup,
Ansible juga menarik variabel dari grup lain yang melanggar
pengujian saya.

Jangan melihat inventaris yang terkait erat dengan pedoman. Inventaris
cukup banyak hal yang terpisah, di mana

• host dapat menjadi anggota dari beberapa grup, dan dengan demikian menjadi target dari
  ansible (ad-hoc) atau ansible-playbook (playbooks) dengan menunjuk ke salah satu file
  grup tempat tuan rumah adalah anggotanya.
• menyelesaikan variabel dilakukan di seluruh inventaris, apakah Anda menargetkan a
  grup tertentu, atau grup 'semua' yang ada di dalam allmighty, tidak mengubah itu
  variabel dan diwarisi, diselesaikan dan dihitung dengan melihat semua
  definisi grup dan semua variabel grup yang ada di inventaris.

HTH,

Serge

Aku juga mengalami ini. Dalam kasus saya, saya memiliki peran yang menginstal vhosts. Saya mengatur detail untuk beberapa vhost sebagai array dalam inventaris saya untuk grup server, dengan kata lain setiap grup dapat memiliki beberapa vhost. Ini berfungsi dengan baik, saya mendefinisikan vhost untuk setiap grup dan semuanya tampak rapi dan rapi. Masalah muncul ketika host berada di lebih dari satu grup, dalam hal ini array vhost di inventaris ditimpa dan grup terakhir menang, jadi hanya setengah vhost saya yang akhirnya disediakan.

Alternatifnya adalah meletakkan vhost di host daripada di grup, tetapi itu tampaknya tidak bersih karena saya harus menduplikasi untuk semua server yang berada di grup yang sama.

Adakah yang bisa mengarahkan saya ke cara yang lebih baik untuk melakukan ini atau untuk mengatasinya? Saya merasa seperti saya mungkin menyalahgunakan konsep peran atau inventaris dengan meminta peran "vhosts" saya menerima serangkaian vhosts (vhost sebenarnya bukan "peran" dalam arti bahwa Anda tidak mengatakan ke server "Anda adalah vhost "). Adakah yang bisa menawarkan cara yang lebih baik untuk melakukannya atau berbagi pemikiran?

Ngomong-ngomong, @srvg , terima kasih telah meluangkan waktu untuk menanggapi saya - kami sangat menghargai dan memperjelas pemahaman saya.

Solusi saya adalah.

[layanan1]
host1 ansible_ssh_user = host1.com

[layanan2]
host2 ansible_ssh_user = host1.com

Ini sangat bodoh. Saya hanya menghabiskan berjam-jam mencoba men-debug masalah variabel, hanya untuk menemukan bahwa itu karena beberapa filosofi desain yang bodoh (ini). Setidaknya, harus ada peringatan ketika beberapa file group_var dimuat untuk host yang sama.

Ini saya sangat anoying untuk memiliki group_vars dimuat secara acak. Itu membuat tidak mungkin untuk memiliki warisan dalam kasus seperti itu all> datacenter> environment (integ, devel, prod)> application> host

Ini sangat mudah dilakukan dengan boneka hiera tetapi mungkin itu merepotkan, dan, ketika Anda memiliki> 100 buku pedoman / peran untuk dipelihara, memuat variabel secara eksplisit tidak harus dimiliki karena Anda harus mempertahankan file vars_file + file group_vars untuk fungsi yang sama .
Mungkin memiliki tag di file (vars_priority) atau menggunakan nama file untuk memperbaiki urutan pemuatan bisa bagus (seperti apache misalnya), misalnya

• all.yml
• 10_datacenter_a.yml
• 10_datacenter_b.yml
• 20_env_production.yml
• 40_app_gitlab.yml

lalu gitlab memuat vars grup per nama, di sini pusat data, setelah env, dan terakhir aplikasi.

Saya sangat senang melihat bahwa saya tidak sendirian dalam omong kosong ini! Variabel grup harus berlaku untuk grup host periode HIS. Bagaimana seharusnya --limit directive dijelaskan daripada? Cara berpikir alami adalah: oke, saya "membatasi" buku pedoman ini untuk menjadi tuan rumah di grup ITU sehingga grup vars ITU dapat mengambilnya !!!! Bukan variabel yang ditentukan dalam grup lain untuk host yang sama, itu tidak masuk akal!

Saya harap ini diperbaiki dan sementara itu, saya mundur untuk menggunakan beberapa entri DNS untuk host yang sama.

Hanya menghabiskan beberapa jam membenturkan kepala saya ke meja mencoba untuk mengatasi masalah ini. Dengan banyaknya obrolan masalah ini membuat saya benar-benar terkejut Ansible (atau Red Hat) membiarkan ini berlanjut.

Mengapa mengandalkan abstraksi group_vars untuk menggabungkan vars dan menentukan apa itu
dibutuhkan di tempat pertama?

Saya tidak dapat memikirkan alasan yang baik untuk tidak secara eksplisit mendefinisikan dan menyertakan vars
(contoh paling sederhana disertakan di atas di utas)

Iain Wright

Pesan email ini bersifat rahasia, hanya ditujukan untuk penerima
disebutkan di atas dan mungkin berisi informasi yang dilindungi hak istimewa, dikecualikan dari
pengungkapan di bawah hukum yang berlaku. Jika Anda bukan penerima yang dituju, lakukan
tidak mengungkapkan atau menyebarkan pesan kepada siapa pun kecuali yang dimaksudkan
penerima. Jika Anda telah menerima pesan ini karena kesalahan, atau tidak bernama
penerima, harap segera beri tahu pengirim melalui email balasan, dan
hapus semua salinan pesan ini.

Pada Selasa 27 Sep 2016 jam 11:53, Jason Hane [email protected]
menulis:

Hanya menghabiskan beberapa jam membenturkan kepalaku ke meja mencoba berkeliling
masalah ini. Dengan banyaknya obrolan masalah ini semakin saya dapatkan
terkejut Ansible (atau Red Hat) membiarkan ini terus berlanjut.

-
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung, lihat di GitHub
https://github.com/ansible/ansible/issues/9065#issuecomment -249961581,
atau nonaktifkan utasnya
https://github.com/notifications/unsubscribe-auth/AATjccSt7D7FJfzdA8r86kb1GQvxLBnaks5quWY4gaJpZM4Cjyd4
.

Sebagian dari masalahnya adalah tidak segera jelas bagaimana Ansible mem-parsing variabel. Orang akan berpikir (sebagaimana dibuktikan dengan jumlah orang yang mengalami masalah ini) bahwa menugaskan sebuah host ke sebuah grup, dan hanya menjalankan grup itu, akan mewarisi variabel hanya untuk grup itu dan bukan dari semua grup yang menjadi host.

Menjalankan semua host adalah cerita yang berbeda, tetapi setidaknya itu harus menjadi asumsi yang jelas bahwa Ansible akan mengambil semua variabel untuk semua grup tempat host berada. Ansible harus melakukan pekerjaan yang lebih baik untuk memperjelas asumsi tersebut atau memberikan tanda yang memungkinkan perilaku ini .

Mengapa mengandalkan abstraksi group_vars untuk menggabungkan vars dan menentukan apa itu
dibutuhkan di tempat pertama?

Itulah TEPATNYA inti dari sebuah abstraksi! Jika alat memungkinkan saya mengabstraksi lingkungan saya dalam kelompok yang berbeda dan kemudian dengan menerapkan aturan inferensi yang jelas menyimpulkan variabel mana yang harus digunakan, mengapa tidak menggunakannya?!? Jadi ada 2 masalah di sini: Aturannya tidak jelas atau abstraksinya tidak berfungsi. Jika tidak, jelaskan saya tujuan groups_vars jika saya perlu secara eksplisit mendefinisikan dan menyertakan vars?

Saya harus mengatakan bahwa dokumentasi tidak menyebutkan kasus spesifik dari host yang sama ini telah disertakan dalam beberapa group_vars. Tetapi kasus ini sangat nyata pada host di mana terdapat beberapa contoh layanan (mis. Apache). Saya sangat berharap masalah ini segera teratasi.

Kami telah menemukan cara untuk memecahkan masalah app / env kami dengan pewarisan variabel dengan menentukan variabel antar grup menggunakan awalan.
sebagai contoh

app_collectd.yml
collectd_host: "{{env_collectd_host}}"

env_production.yml
env_collectd_host: 1.1.1.1

maka sekarang bukan masalah, kami memiliki variabel aplikasi yang jelas + variabel env menggunakan variabel panggilan silang

Saya berasal dari negeri Wayang di mana melakukan abstraksi dan penggunaan kembali kode itu sederhana dan jelas. Mungkin saya tidak mengerti dengan benar bagaimana Ansible mendekati ini jadi jika ada cara yang lebih baik yang tidak melibatkan group_vars, saya mendengarkan. Apa yang tidak ingin saya lakukan adalah mempertahankan set variabel lain untuk setiap host atau grup untuk menentukan di mana ia harus mendapatkan variabelnya. Bagi saya itu harus menjadi tanggung jawab kerangka kerja. Inilah Indahnya Hiera dalam Wayang Orang.

@bayu_joo

Solusi saya adalah.

[layanan1]
host1 ansible_ssh_user = host1.com

[layanan2]
host2 ansible_ssh_user = host1.com

bisakah kamu menjelaskannya secara detail?

Saya mengujinya seperti ini, tidak sama dengan milik Anda, tetapi berhasil!

[service1]
host1 ansible_host=192.168.0.10

[service2]
host2 ansible_host=192.168.0.10

Satu korban lagi di sini.

Adakah yang menemukan solusi yang baik untuk skenario berikut?

Katakanlah saya memiliki daftar aplikasi web (app-a, app-b, app-c). Dan ada 4 host di 2 DC untuk DR / Load-balancing. Saya ingin menggunakan ansible untuk menyederhanakan penerapan.

Insting pertama saya adalah menggunakan vars grup, jelas saya gagal, tetapi alternatif apa yang Ansible sediakan?

inventaris

[dc1]
host1
host2

[dc2]
host3
host4

[cluster:children]
dc1
dc2

[app-a:children]
cluster

[app-b:children]
cluster

[app-c:children]
cluster

groups_vars
aplikasi-a

http_port: 8081

aplikasi-b

http_port: 8082

aplikasi-c

http_port: 8083

playbook pada dasarnya mengharapkan host yang diteruskan melalui commandline:

- host: {{app-name}}
- tasks: 
  # deploy application with given {{http_port}}....

Inilah yang saya lakukan untuk menyiasatinya

- hosts: "{{ app-name }}"

vars_files:
    - "vars/{{ app-name }}.yml"

@hanej Terima kasih, itu pasti menunjuk ke arah yang tidak saya sadari.
Namun, saya sekarang lebih cenderung menggunakan peran untuk penggunaan ulang kode, dan mendeklarasikan variabel secara langsung di buku pedoman. Meskipun itu berarti saya akan memiliki satu buku pedoman per aplikasi, tetapi dengan mendeklarasikan variabel tepat di sebelah peran yang akan menggunakannya, membuat seluruh konfigurasi lebih mudah dipahami.

@hanej Terima kasih, solusi ini brilian. Kamu menyelamatkanku.

@hanej Genius!

Saya sangat terkejut bahwa ini bahkan menjadi masalah. Saya mengalaminya karena saya memiliki peran tunggal yang saya gunakan dengan beberapa grup inventaris yang memiliki file group_var terkait. Di QA / Prod, ini bukan masalah, karena setiap grup inventaris memiliki server yang berbeda. Tetapi untuk lingkungan tingkat integrasi, kami cenderung menghancurkan semuanya bersama-sama ke satu server (itulah sebabnya saya melihat masalah ini).

Mengikuti saran hanej, saya memodifikasi playbook saya yml menjadi hanya memuat file group_var secara eksplisit:

hosts: publish
vars_files:
  - group_vars/publish.yml

"Ini sangat bodoh. Saya hanya menghabiskan berjam-jam mencoba men-debug masalah variabel, hanya untuk mengetahui bahwa itu karena beberapa filosofi desain yang bodoh (ini). Setidaknya, harus ada peringatan ketika beberapa file group_var dimuat untuk host yang sama. "

Hanya untuk memperbarui "MASALAH" / "LIMITATION" ini
Oke, kita bisa menggunakan solusi untuk menghilangkan konflik, (dengan host memungkinkan atau cara lain)
tetapi cara terbaik adalah menggunakan variabel tujuan di ansible.cfg untuk mendefinisikan:
"lampirkan group_vars" atau "gabungkan group_vars"

Saya tidak dapat menggunakan group_vars hanya karena alasan ini. Kami memiliki host dalam beberapa grup (DC, lingkungan, aplikasi, dll) dan kami tidak memiliki kendali atas bagaimana variabel dibaca. Datang dari Wayang menggunakan Hiera, ini adalah masalah besar. Menurut pendapat saya, Ansible harus mengadopsi sesuatu seperti Hiera menggunakan pola "peran dan profil" di mana Anda dapat menentukan urutan bagaimana variabel dikonsumsi berdasarkan fakta atau grup. Saya melakukan ini sekarang dengan menggunakan pendekatan di atas.

Misalnya, jika Anda memiliki host dengan peran yang disebut "/ Linux Hosts / Applications / Java / Website", Anda seharusnya dapat mewarisi variabel dari Host Linux (variabel level global seperti sysctl, DNS, NTP, dll), Applications (global variabel tingkat aplikasi), Java (variabel khusus java seperti versi JDK, JAVA_HOME, dll), dan Situs Web (variabel yang terkait secara khusus dengan aplikasi situs web). Semakin jauh Anda turun dalam hierarki, semakin spesifik variabelnya, yang dapat menggantikan variabel yang lebih tinggi.

Menggunakan Ansible untuk event driven atau adhoc run sangat bagus dan bekerja dengan sangat baik, namun saya menemukan bahwa menggunakan Ansible untuk manajemen konfigurasi tidak sebersih atau mudah digunakan seperti Puppet dan Hiera sebagian besar karena alasan ini.

2 tahun kemudian, saya masih menerima aliran email yang stabil tentang masalah ini (ini juga salah satu masalah yang paling banyak dikomentari di github ini.) Apakah pengelola yang Mungkin masih merasa perilaku saat ini benar, meskipun itu sangat tidak intuitif?

Kalian harus benar-benar mendokumentasikan bagaimana melakukan manajemen konfigurasi dengan Ansible karena siapa pun yang mencoba melakukan penerapan aplikasi dengan proyek ini mengalami kesulitan.

Kami telah memutuskan untuk berhenti menggunakan Ansible sepenuhnya. Itu menyebalkan pada manajemen konfigurasi, titik.

Semoga berhasil dengan proyek ini.

Ya, baru saja mengalami masalah yang sama saat mengonfigurasi proses penerapan untuk file konfigurasi untuk lingkungan yang berbeda, saat menguji di host yang sama. Saya akan mengadopsi seluruh metode {{app-name}} - {{env}}. Yml yang diusulkan oleh @hanej , tetapi saya ingin perilaku group_vars setidaknya dapat dikonfigurasi.

Senang saya menemukan masalah ini setelah membenturkan kepala saya ke dinding selama berjam-jam ... Dan saya sangat terkejut dengan sikap meremehkan pengelola terkait bug ini dengan menyebutnya sebagai "fitur", itu bodoh tak bisa dikenali.

Saya mencoba menyiapkan buku pedoman / peran penerapan umum menggunakan inventaris dinamis. Output inventaris terlihat seperti ini:

{
  "resource-service_ci": {
    "vars": {
      "nginxpool": "resource_pool",
      "httpport": "8800"
    },
    "hosts": ["host1.example.com", "host2.example.com"]
  },
  "example-service_ci": {
    "vars": {
      "nginxpool": "example_pool",
      "httpport": "8100"
    },
    "hosts": ["host1.example.com","host3.example.com"
    ]
  }
}

Sayangnya, mungkin ada beberapa aplikasi pada satu host. Seluruh poin dengan menggunakan inventaris dinamis menguap jika variabel grup 'secara acak' dihancurkan dan dikembalikan alih-alih mewarisi variabel hanya untuk grup yang saya jalankan - batas dengan

Saya mencoba solusi @hanej dengan menerapkan json seperti ini:

_ "host": ["host1 ansible_host = host1.example.com", "host2 ansible_host = host2.example.com"] _

tapi Ansible jelas tidak mengerti bahwa mencoba ssh ke host1 ansible_host = host1.example.com

Adakah orang lain yang menghadapi masalah yang sama, dan jika demikian memiliki solusi yang mungkin?

Saya bisa meneruskan variabel port dan pool pada baris perintah karena mereka diutamakan, tetapi kemudian saya harus melakukan pencarian yang buruk sebelumnya.

Bersenang-senang dengan Ansible sampai menemukan bug ini.

Saya memiliki abstraksi sempurna yang memungkinkan konfigurasi aplikasi yang sama pada lingkungan multi-tingkat, dan juga pada lingkungan pengujian all-in-one - sayangnya, saya salah.

Apa yang tampak sebagai salah satu fitur terkuat dari Ansible tidak berfungsi seperti yang diharapkan semua orang.

Tolong, mari kita perbaiki ini.

Menghabiskan waktu berjam-jam membenturkan kepalaku ke meja mencoba untuk mengatasi masalah ini. Harap perbaiki masalah ini.

"Fitur" ini menyia-nyiakan sebagian besar hari saya. Tidak terhibur.

@hanej Terima kasih atas solusi yang agak elegan. Kami sekarang menetapkan env variabel di kami environment/group_vars/all file dengan nama lingkungan.

Dalam buku pedoman kami, kami kemudian melakukan ini:

- hosts: group
  vars_files:
    - "{{ env }}/group_vars/group.yml
  roles:
    - ...

Saya tahu bahwa sudah 2,5 tahun dan Ansible mungkin tidak akan pernah melihat ini, tetapi saya hanya akan menambahkan rasa frustrasi saya dengan ini. Mengapa mengizinkan pengguna untuk menempatkan host di beberapa grup jika Anda tidak dapat menggunakan grup secara terpisah?

Mengapa memungkinkan pengguna untuk menempatkan host dalam beberapa grup

Itu masalah saya dengan Ansible devs. Sepertinya mereka hanya memikirkan diri sendiri. Mereka setidaknya bisa mencoba mengurangi frustrasi dengan mengeluarkan beberapa peringatan. Mereka malah lebih suka meludah.

Kami memfilter masalah tertutup dan tidak melihat komentar tentangnya, tetapi seseorang mem-ping saya untuk menanggapi beberapa pertanyaan ini. Jika Anda menginginkan perhatian dari pengembang, milis atau IRC adalah saluran yang lebih baik daripada tiket tertutup.

Ansible melihat grup sebagai properti dari sebuah host. Misalnya, Anda dapat membuat host menjadi bagian dari grup server web (untuk menginstal permintaan server web) dan bagian dari grup east_datacenter (sehingga Anda tahu gateway jaringan, server ntp dan dns yang harus disetel) juga bagian dari dev_group untuk menginstal alat dev dan arahkan ke database non-produksi, dll, dll.

Anda BISA menggunakan grup sebagai cara untuk menargetkan host tetapi itu tidak berarti 'properti host' lainnya menghilang. Saya berada di grup 'pria' dan di grup 'programmer', hanya karena Anda 'memilih saya' sebagai programmer, saya tidak berhenti menjadi pria.

Pada akhirnya, ini adalah keputusan desain (bukan bug) tentang cara menangani grup, cara untuk mengklasifikasikan dan menambahkan properti ke host. Saya tahu alat lain menggunakannya secara berbeda tetapi itu bukan alasan untuk mengubah cara kerjanya di Ansible, karena tidak ada cara yang seragam SEMUA alat lain menggunakan grup, banyak yang melihatnya seperti ini, banyak yang tidak.

Ini memiliki batasan karena tidak dapat menggunakan kembali nama variabel dan hanya memiliki 'grup saat ini berlaku' tetapi memiliki keuntungan karena selalu melihat gambaran yang lebih besar tentang bagaimana host didefinisikan dan membuat konflik mudah dikenali atau diselesaikan. Dalam sebagian besar kasus di atas, penggunaan vars_files atau include_vars tampaknya lebih tepat daripada menyiapkan sebagai grup, ketika berbicara tentang variabel khusus aplikasi.

Melakukan include_vars pada group_vars ... yah itu bukan cara kami mendesainnya, tetapi jika itu berhasil untuk Anda ... peringatannya adalah Anda 'memuat ganda' karena group_vars secara otomatis ditarik, ini dapat menyebabkan masalah kinerja pada umumnya persediaan. Kami merekomendasikan yang lebih spesifik, vars_files: vars/app1.vars.yml atau serupa dengan include_vars.

Saya harap ini menjelaskan mengapa grup bekerja dengan cara yang mereka lakukan di Ansible dan mengapa itu berbeda dari 'alat khusus lain', beri tahu saya jika ada yang bisa saya tambahkan ke dokumen kami http://docs.ansible.com/ansible/ intro_inventory.html untuk memperjelas dan menghindari frustrasi.

Saya akan senang untuk mengakomodasi cara kerja semua orang, Ansible sangat fleksibel di beberapa area, tetapi tidak dalam hal ini dan saya tidak melihat cara yang baik untuk melakukannya atau cara yang waras untuk berbagi buku pedoman setelahnya.
Jika saya salah, saya menantikan permintaan penarikan Anda.

@bcoca dapatkah mendeteksi kasus ketika vars grup digunakan dengan cara yang aneh (maaf, tidak dapat merumuskan ini lebih baik - sudah lama tidak menggunakannya) dan membuat peringatan untuk membantu pengguna menghemat waktu mereka?

@bcoca Apa yang tidak jelas bagi saya, dan saya pikir sebagian besar komentator lainnya tentang masalah ini, adalah nilai yang ingin dipertahankan oleh tim Ansible dengan menjaga prioritas / resolusi group_var sebagaimana adanya.

Dapatkah Anda memberikan contoh kasus yang dipenuhi dengan baik oleh solusi saat ini tetapi akan berhenti demikian jika, katakanlah, group_vars hanya dimuat / dipertimbangkan untuk grup yang dipilih untuk permainan tertentu, bukan untuk seluruh inventaris?

Tampaknya cukup mudah untuk memberikan contoh-contoh yang rusak seperti sekarang ini.

Saya memahami maksud @bcoca karena kami juga menggunakannya. Rasa frustrasi terbesar saya dengan Ansible adalah sebagian besar berfungsi baik untuk manajemen konfigurasi atau alur kerja ad-hoc. Itu tidak melakukan pekerjaan dengan baik tetapi itu menjadi lebih baik dan memiliki dukungan plugin yang menurut saya akan saya gunakan untuk membuat masalah lain yang saya miliki dengannya lebih baik. Hampir setiap hari saya masih merindukan Wayang hanya untuk manajemen konfigurasi ...

Mungkin kasus penggunaan terbaik untuk group_vars adalah beberapa pusat data. Misalkan file inventaris Anda terlihat seperti ini:

[dc1]
host1
host2

[dc2]
host3
host4

[app1]
host1
host3

[app2]
host2
host4

Anda bisa menggunakan group_vars untuk mengatur variabel spesifik pusat data yang akan diwarisi oleh semua host di pusat data itu.

group_vars/
    dc1.yml
    dc2.yml
    app1.yml
    app2.yml

dc1.yml

---
ntp_servers:
  - 10.10.10.10
  - 10.10.10.11

dc2.yml

---
ntp_servers:
  - 10.11.10.10
  - 10.11.10.11

Menggunakan group_vars seperti ini baik-baik saja sampai Anda perlu menggabungkan atau mengganti variabel di file group_var lain. Ini adalah kasus lain di mana group_vars rusak. Tidak ada cara untuk mengatur urutan pembacaan variabel di group_vars. Tata letak hierarki (seperti Hiera) yang dapat ditentukan oleh fakta dan bukan oleh kelompok untuk hal-hal seperti variabel lingkungan muncul di benak saya di sini, tetapi saya ngelantur.

Dari sudut pandang saya, kasus penggunaan ini sebagian besar baik untuk manajemen konfigurasi langsung tetapi tidak begitu bagus dalam penerapan atau skrip ad-hoc. Inilah mengapa saya ingin melihat tombol untuk menonaktifkan fitur ini untuk buku pedoman tertentu di mana Anda tidak ingin melakukan ini.

@hanej Saya tidak yakin bagaimana contoh itu rusak oleh perubahan desain yang saya sarankan dalam komentar saya sebelumnya?

Mengingat inventaris yang Anda daftarkan, jika saya ansible-playbook -i /my-inventory -v some_playbook.yml -l dc1:&app2 Apa pun some_playbook.yml Anda tuliskan terhadap inventaris itu harus dibuat-buat agar dapat rusak ketika variabel dari dc1.yml dan app1.yml hanya dimuat.

Saya setuju bahwa penerapan adalah suatu masalah. Penerapan multi-tenant, khususnya.

Saya memiliki dua kekhawatiran tentang cara kerja sekarang:

Pertama, kurangnya konfigurasi namespacing. Secara khusus, jika saya mempertahankan konfigurasi untuk beberapa aplikasi dalam lingkungan multi-tenant, bagaimana cara memastikan bahwa seseorang yang memelihara aplikasi berbeda yang berjalan pada mesin yang sama tidak akan menambahkan nama variabel yang bertentangan dengan milik saya, atau bahwa saya tidak akan menambahkan yang bertentangan dengan mereka?

Kedua, kasus yang terus dibicarakan semua orang di sini. Saya berharap bahwa dengan inventaris di bawah ini, saya tidak akan pernah berakhir dengan file yang ditulis menjadi /data/prod ketika saya menjalankan ansible-playbook -i inventory -v data_deploy.yml -l app1_staging , dan file tersebut tidak akan pernah ditulis menjadi /data/staging ketika saya menjalankan ansible-playbook -i inventory -v data_deploy.yml -l app1_prod

Kedua masalah ini sendiri sudah cukup buruk, tetapi di perusahaan besar di mana banyak orang di zona waktu yang berbeda mungkin mengedit inventaris yang sama, solusi saat ini tampaknya lebih dari sedikit berisiko.

Contoh inventaris.

[dc1]
host1
host2

[dc2]
host3
host4

[app1_staging]
host1
host2
host3
host4

[app1_prod]
host1
host2
host3
host4

app1_staging.yml:

---
  data_path: /data/staging

app1_prod.yml:

---
  data_path: /data/prod

Tidak tahu apakah edit berfungsi untuk menyesuaikan notifikasi, komentar terakhir saya dimaksudkan untuk diarahkan ke @hanej.

@benjamincburns Anda meminta contoh penggunaan group_vars yang memenuhi metode pemuatan saat ini tetapi berhenti jika hanya menggunakan grup langsung. Saya menyediakannya dengan contoh datacenter. Jika Ansible tidak memuat variabel untuk semua grup, maka Anda tidak dapat mengatur variabel, misalnya, di tingkat pusat data.

Saya yakin ini harus menjadi toggle di ansible.cfg atau pada baris perintah sehingga Anda dapat menentukan cara memuat group_vars sehingga tidak merusak kasus penggunaan yang ada. Kami memiliki lingkungan multi-tenant di sini dan dulu mendapatkan sedikit ini sampai saya berhenti menggunakan group_vars.

Saya tidak yakin apakah Anda pernah mendengar tentang peran dan pola profil tetapi itu benar-benar bacaan yang bagus dan saya sangat merekomendasikan pendekatan ini jika Anda menggunakan alat manajemen konfigurasi apa pun. Itu ditulis untuk Wayang tetapi berlaku untuk semua alat. Anda mungkin tidak akan menggunakan ini untuk penerapan atau hal-hal ad-hoc tetapi untuk manajemen konfigurasi langsung, ini bagus.

http://www.craigdunn.org/2012/05/239/

Saya menggunakan host buruh pelabuhan sehingga sangat normal untuk memiliki contoh wadah yang berbeda di lingkungan berbeda yang tersebar di seluruh host dan ini menggigit saya.

Terima kasih kepada @hanej untuk solusinya dan saya juga akan menambahkan vars grup tidak berfungsi seperti yang diiklankan dan tampaknya rusak oleh desain.

Solusi saya adalah mendefinisikan drama sebagai berikut:

- hosts: "{{ group }}"
  vars_files:
    - "vars/{{ group }}.yml" 
  roles:
    - role1 etc

Letakkan direktori vars di direktori playbook dengan group1.yml, group2.yml di sana.

Akan sangat buruk jika konfigurasi Anda berubah hanya karena _diakses secara berbeda_. Coba pikirkan pengaruh yang akan terjadi pada upaya arsitektur konvergen. 1 untuk tim Ansible untuk menjaga variabel sekonsisten mungkin.

Pertanyaan yang lebih menarik adalah bagaimana Anda dapat menerapkan peran yang sama beberapa kali, berbagi beberapa konfigurasi di seluruh host sementara _extending_ (dan tidak mengganti) lainnya. Saya pikir ketergantungan peran memungkinkan itu, yaitu dengan:

• Buat "peran pembungkus" yang menyertakan peran yang ingin Anda perluas sebagai dependensi.
• Tentukan allow_duplicates: true dalam meta/main.yml pembungkus Anda.
• Teruskan ekstensi konfigurasi Anda ke deklarasi peran (lihat di bawah).
• Setel konfigurasi bersama dan stabil di group/host_vars .

Jadi intinya, peran pembungkus Anda akan menyertakan meta.yml seperti:

---
# roles/my-app/meta.yml
allow_duplicates: true
dependencies:
  - role: nginx
    nginx_servers:
      - name: server-myapp
        contents: |
          ...

Saat Anda menerapkan peran pembungkus, hanya konfigurasi "dapat diperpanjang" yang benar-benar berubah. Beban ada pada pengembang untuk merancang peran mereka dengan cara yang mendukung pola ini.

Tim yang mungkin: apakah ini maksud Anda tentang bagaimana peran akan digunakan? Sejujurnya saya belum melihat kasus penggunaan yang lebih baik untuk dependensi; segala sesuatu tampaknya mengarah ke sup kode.

Saya baru saja bergabung dengan daftar korban hari ini setelah 1 jam debugging dan cukup beruntung untuk menemukan posting ini.
Menurut saya ini hanya masalah dokumentasi, tidak akan ada yang mengeluh jika dicantumkan dengan jelas di sini:
http://docs.ansible.com/ansible/intro_inventory.html#group -variables
fakta bahwa variabel dikaitkan dengan host, dan grup hanyalah cara mudah untuk mengatur variabel ke semua host miliknya. Variabel akan diganti jika host yang sama digunakan dalam beberapa grup.

+1 Masalah ini memengaruhi tim perangkat lunak kami.

Sayangnya kami juga mengalami masalah ini hari ini. Cerita yang sama, Meskipun kami memiliki rol "kucing jantan" generik, kami memvariasikan variabel seperti nomor port berdasarkan grup yang digunakan.
Namun beberapa instance tomcat dapat diterapkan ke server fisik yang sama, jadi kami membuat beberapa grup dalam inventaris yang berisi kumpulan server yang sama.

Namun pendekatan ini tampaknya tidak berhasil. Saya belum tahu bagaimana mendesain ini. Saya tidak dapat membuat peran pembungkus yang memiliki variabel karena beberapa variabel sebenarnya khusus untuk inventaris. Pikirkan misalnya database kata sandi oid.

Saya baru-baru ini menemukan ini yang mengurangi rasa sakit saya dengan masalah ini:
https://github.com/leapfrogonline/ansible-merge-vars

Ini memungkinkan penggabungan variabel di mana pun mereka didefinisikan, sehingga Anda dapat menggabungkan dua dicts / daftar dalam dua kelompok yang berbeda, misalnya, sebagai lawan dari satu kelompok yang memenangkan dan menimpa variabel yang ditentukan dalam kelompok lain seperti perilaku saat ini. Plugin hanya bekerja dengan Ansible 2+.

Artikel bagus yang menjelaskan konsep dan kasus penggunaan dapat ditemukan di sini .

Kami baru-baru ini juga mengalami masalah ini. Kami memiliki beberapa aplikasi yang berjalan pada satu host sebagai pengguna yang berbeda . Misalnya:

[group_a]
host1

[group_b]
host1

Kami tidak memiliki cara untuk menentukan ansible_user dengan vars dengan benar, baik dengan host_vars maupun group_vars . Definisi terbaru selalu menang dalam kedua kasus tersebut.

Solusi kami saat ini adalah menentukan beberapa permainan dengan ansible_user di buku pedoman:

- hosts: group_a
  ansible_user: user_a
  roles:
    - my-role

- hosts: group_b
  ansible_user: user_b
  roles:
    - my-role

@hyojinbae menyarankan cara cerdas di atas untuk mengatasi masalah ini:

[group_a]
user_a<strong i="8">@host1</strong> ansible_user=user_a ansible_host=host1

[group_b]
user_b<strong i="9">@host1</strong> ansible_user=user_b ansible_host=host1

Jadi sekarang setiap host memiliki nama unik di inventaris. Bukan penggemar berat untuk memasukkan host vars ke dalam inventaris, tetapi ini adalah solusi terbaik yang pernah saya lihat sejauh ini.

@hyojinbae Saya pikir Anda kehilangan poin dari hostvars dan arahan:

- hosts: group_a
  remote_user: user_a
  roles:
    - my-role

- hosts: group_b
  remote_user: user_b
  roles:
    - my-role

seharusnya berfungsi selama Anda tidak menyetel ansible_user. Grup adalah milik tuan rumah, bukan entitas mereka sendiri.

Ada proposal untuk memungkinkan penulisan plugin yang tepat untuk manajemen inventaris. Saya menduga sekarang proposal ini telah ditutup / selesai, seharusnya menjadi mungkin untuk menerapkan plugin inventaris dinamis yang bekerja di sekitar titik kebingungan ini.

Pergi ke +1 untuk mempertanyakan desain yang memungkinkan di sini.
Di dunia nyata, banyak aplikasi berbeda dapat berjalan di host yang sama.
Mencakup group_vars di tingkat host tidak mencakup kasus penggunaan ini.

Sama seperti eksperimen pikiran:

• Mari kita asumsikan bahwa perilaku default telah diubah sehingga menjalankan ansible-playbook dengan opsi "-l" menggunakan file anak group_vars (jika ada).
• Anda masih bisa menangani kasus penggunaan "pusat data" yang disebutkan melalui grup induk.
• Semua yang akan berubah adalah bahwa grup anak "bernama" untuk pertandingan tuan rumah akan memenangkan pertarungan warisan, bukan grup turunan "terakhir" untuk pertandingan tuan rumah.

Membuat perubahan kecil ini akan membuat ratusan orang DevOps-y bahagia, dan tidak akan menyakiti siapa pun.

Dari komentar saya sebelumnya, lihat https://github.com/ansible/proposals/issues/41 untuk mengetahui cara potensial untuk memungkinkan lebih banyak perilaku yang dapat dimasukkan di sini.

Tidak percaya bahwa Ansible tidak memperbaiki (memberi petunjuk, peringatan) atau membalas lebih banyak tentang masalah ini.
Perlu beberapa jam untuk men-debug.

Saya mengalami ini juga. Salah satu pendekatannya adalah dengan menggunakan variabel bersarang. Jadi, ambil grup inventaris my_app_servers sebagai contoh, dan itu berbaris dengan file my_app_servers.yml di dalam group_vars Anda, dan Anda memiliki lebih dari satu aplikasi untuk dikelola pada host yang sama. Saya menyarangkannya seperti ini

Contoh: my_app_servers.yml

application_env:
  - application1
  - application2

application_environments:
  application1: 
    app_port: 8080
    app_conf_dir: "/somedirectory/conf"
    app_logs_dir: "/somedirectory/logs"
    app_install_name: app1prd

   application2: 
     app_port: 8081
     app_conf_dir: "/somedirectory/conf"
     app_logs_dir: "/somedirectory/logs"
     app_install_name: app2prd

Di main.yml Anda, tentukan perulangan, dan lakukan iterasi pada daftar variabel bersarang seperti ini,

with_items: "{{application_env}}"
loop_control:
loop_var: application_env_item

Kemudian dalam tugas Anda, Anda dapat mengambil variabel bersarang yang Anda inginkan, untuk menjalankan sesuatu.
{{application_environments [application_env_item] ['app_install_name']}}
(jika Anda dapat menarik satu variabel dari daftar itu, Anda dapat mengambil sisanya.). Semoga membantu.

Masalah ini (# 9065) ditutup kembali pada tahun 2015. Sama # 6538. Sama # 6666. Dan masih banyak lagi.
Inilah 2018, 4 tahun setelah banyak masalah terbuka, dan tampaknya lebih panas daripada di awal, dan semua orang kehilangan waktu berjam-jam karena desain yang kontra-intuitif.
IMHO ini sepertinya perlu ditinjau oleh tim desain.

Jika semua orang akan terus menggunakan peretasan yang diusulkan, itu akan membuat kode yang mungkin menjadi jelek:

• ke file var bersyarat meliputi: https://github.com/ansible/ansible/issues/9065#issuecomment -282040497
• atau inventaris seperti "[service1] host1 ansible_ssh_user = host1.com",: https://github.com/ansible/ansible/issues/9065#issuecomment -256384769
• lib tambahan untuk fungsionalitas inti: https://github.com/eggsby/oroboros
• delegate_to https://github.com/ansible/ansible/pull/6666#issuecomment -146759980

IMHO hacks ini membuatnya kurang menarik tidak sepenuhnya sejalan dengan moto " Simple IT Automation";)

@bcoca -> Mohon

Saya pikir group_vars sendiri harus dapat diprioritaskan. Hiera for Puppet benar. Anda dapat menentukan bagaimana pencarian dilakukan berdasarkan fakta atau grup. Biarkan pengguna akhir dapat menyesuaikan bagaimana group_vars harus diproses dan menyediakan mekanisme untuk dengan mudah melihat urutan Ansible menerapkan variabel tersebut.

FYI, kami biasanya tidak melihat pemberitahuan tentang masalah tertutup, menanggapi di sini karena seseorang mengarahkan saya pada ini, saya juga akan mengunci sehingga orang tidak terus berkomentar di pengelola forum tidak akan melihat.

@hanej saya pikir Anda ingin konfigurasi ansible_group_priority dan [defaults]precedence , sedangkan untuk introspeksi sekarang Anda memiliki ansible-inventory yang menunjukkan kepada Anda hasil akhir, kami masih berupaya memberikan yang lebih baik kepada orang-orang melihat ke mana / apa yang mengatur nilai akhir variabel.

@ReSearchITEng membuka proposal (http://github.com/ansible/proposals), tetapi ini tentang fokus mendasar dari setiap aplikasi berbeda. Ansible berfokus pada tugas untuk tuan rumah, alat lain yang Anda sebutkan berfokus pada struktur yang jauh lebih kompleks.

Karena 'grup' yang mungkin hanyalah properti dari sebuah host, bukan entitas utama, alat lain fokus pada grup sebagai 'konteks utama' dan yang lainnya ditambahkan ke dalamnya.

Saya tidak melihat pendekatan mana pun sebagai 'salah', hanya berbeda. Mencoba membuat Ansible bekerja sedemikian rupa akan mematahkan paradigma kesederhanaan, fokus pada Tuan rumah dan tugas untuk apa yang hanya fokus organisasi dan mengubah apa yang saya lihat sebagai 'cara berpikir yang biasa' yang dibawa orang dari alat lain.

Saya berpendapat bahwa ini hanyalah persepsi tentang organisasi data dan kebiasaan, tetapi itu hanya pendapat saya. Jangan ragu untuk mengajukan proposal, jika Anda meyakinkan dan mendapatkan daya tarik yang cukup dengan pengelola, Anda mungkin mendapatkan perubahan yang Anda inginkan, saya rasa itu bukan perubahan yang kita butuhkan.