muszę coś podobnego (ansibl pliku inwentaryzacji):Jak określić wartość listy jako zmienną w pliku inwentarza ansible?
[example]
127.0.0.1 timezone="Europe/Amsterdam" locales="en_US","nl_NL"
Jednak ansibl nie rozpoznaje „locales” w postaci listy.
można przekazać listę lub przedmiot tak:
[example]
127.0.0.1 timezone="Europe/Amsterdam" locales='["en_US", "nl_NL"]'
Przy zmiennych złożonych najlepiej jest zdefiniować je w pliku host_vars, a nie w pliku inwentaryzacji, ponieważ pliki host_vars obsługują składnię YAML.
Spróbuj utworzyć plik host_vars/127.0.0.1 o następującej treści:
timezone: Europe/Amsterdam
locales:
- en_US
- nl_NL
Dziękuję, to jest mój obecny sposób pracy :) Czy twoja odpowiedź implikuje, że nie możesz określić zmiennej listy w pliku inwentaryzacji (i --extra-vars)? – rmuller
@rmuller Nie wiem, czy możliwe jest określenie zmiennych listy w plikach ini lub w wierszu poleceń. Prawdopodobnie uzyskasz szybszą odpowiedź, jeśli zapytasz o listę dyskusyjną ansible. –
@rmuller Polecam także skakanie na kanale #ansible IRC, chłopaki, którzy zwykle pomagają :-) – jabclab
Można niestandardowy filtr, aby podzielić ciąg do listy
Github ansible example pokazać, jak stworzyć własny filtr.
można spróbować podzielić
#inventory file
[example]
127.0.0.1 timezone="Europe/Amsterdam" locales="en_US","nl_NL"
#role file
---
- debug: msg="{{ item }}"
with_items: locales.split(',')
odpowiedź Ryler jest dobra w tym konkretnym przypadku, ale wpadłem na problemy za pomocą innych odmian Europejska moduł szablonu.
[example]
127.0.0.1 timezone="Europe/Amsterdam" locales='["en_US", "nl_NL"]'
Jest to jego oryginalny przykład i działa dobrze.
Poniższe odmiany działają z szablonem. Zasadniczo, jeśli jest to ciąg, należy pamiętać o użyciu wewnętrznych podwójnych cudzysłowów lub cała struktura jest analizowana jako pojedynczy ciąg. Jeśli są to tylko liczby lub "prawda" lub "fałsz" (nie "tak"), wszystko jest w porządku. W tej odmianie nie mogłem pracować z szablonem, gdyby miał zewnętrzne cytaty.
Nie przeprowadziłem wyczerpującego sprawdzenia, które wewnętrzne przypadki użycia są wykonywane i nie łamią się poza modułem szablonu.
Używam odpowiedzi 2.2.1.
[example:vars]
# these work
myvar1=["foo", "bar"]
myvar2=[1,2]
myvar3=[True,False]
# These fail, they get interpreted as a single string.
myvar4=[yes, no]
myvar5=[foo,bar]
myvar6='["foo", "bar"]'
Ten dodatkowy fragment informacji pomógł mi rozwiązać irytująco dowolny problem z analizą zmiennych. Dzięki! –
Trochę dodatkowych informacji: Myślę, że różnice występują z powodu różnych tras analizowania. W [grupa: vars] wszystko jest przekazywane bezpośrednio jako INI_PARSER-> YAML_PARSER, w tym podwójne cudzysłowy. Tak więc parser YAML interpretuje go jako ciąg znaków. Po nazwie hosta przechodzi przez podobny parser do argumentów "równych stylów" do modułu: INI_PARSER-> ANSIBLE_ARG_PARSER-> YAML_PARSER. W tym drugim przypadku ANSIBLE_ARG_PARSER interpretuje łańcuch podwójnie cytowany i przekazuje treść (bez cudzysłowów) do parsera YAML. – Sparky
@ryanyuyu To nie tylko nie jest ten sam kod co w pytaniu, ale także dokładne rozwiązanie, którego szukał OP. Testowałeś to? Ryler zrobił, ja też: I działa. To powinna być zaakceptowana odpowiedź, a nie odrzucona. – udondan
Tak, można również potwierdzić, że to działa. Jest to dobre na przykład do użycia z instrukcją "with_items". Możesz nawet tworzyć podobne do dictów obiekty. Używam tego do definiowania użytkowników uwierzytelniania nginx i haseł w pliku inwentaryzacji: nginx_auth = '[{"user": "user1", "pass": "pass1"}, {"user": "user2", "pass" ":" pass2 "}] ' –
Czy to jest najmodniejsze z możliwych rozwiązań dla plików ini?Co się stanie, jeśli masz ponad 20 obiektów i 5 hostów do skonfigurowania? Byłbym szczęśliwy, ale to działa na razie. – JohnnyQ