AWS / Ansible - Как получить доступ к фактам по ролям / хостам с хоста, определенного в динамической инвентаризации? - PullRequest
Новая
       28

AWS / Ansible - Как получить доступ к фактам по ролям / хостам с хоста, определенного в динамической инвентаризации?

1 голос
/ 27 апреля 2019

В настоящее время я настраиваю несколько ролей Ansible для настройки кластера Kubernetes. До сих пор у меня была роль обеспечения идемпотентных EC2 (1x Master / 2x Worker) и последующих ролей для настройки этих главных / рабочих узлов с зависимостями Docker / Kubernetes. Я использую AWS ec2.ini/.py dynamic-inventory для обнаружения IP-адресов экземпляров, предоставленных моей ролью create_ec2.

Я столкнулся с проблемой при попытке присоединить моих работников к кластеру с помощью команды соединения, которую я получаю с главного узла. У меня есть 2 отдельные роли для подготовки главного и рабочего. В задачах для мастера я получаю команду соединения с: 

kubeadm token create --print-join-command

и затем зарегистрируйте переменную, которую я затем использую для установки факта хоста: 

set_fact:
  join_command: "{{ join_command_stdout.stdout_lines[0] }}"

Проблема, с которой я сталкиваюсь, заключается в том, что я пытаюсь получить доступ к этому факту на своих рабочих узлах при выполнении моей рабочей роли. Я пытаюсь получить доступ к факту с помощью: 

"{{ hostvars['tag_Type_master'].join_command }} --ignore-preflight-errors all  >> node_joined.txt"

Однако это происходит сбой, так как хост, который я предоставляю для хостов, явно не определен ..

Для справки, у меня есть это значение в моем динамическом инвентаре (IP опущен): 

  "tag_Type_master": [
    "1.2.3.4"

Я получаю ошибку: 

"{"msg": "The task includes an option with an undefined variable. The error was: \"hostvars['tag_Type_master']\" is undefined"

Я изо всех сил пытаюсь выяснить, как я получаю доступ к фактам хоста экземпляра EC2, определенного в моем динамическом инвентаре.

Я попытался добавить IP EC2 непосредственно в hostvars (hostvars['1.2.3.4'].join_command), однако задача просто зависает и ничего не делает.

Я также пытался вставить переменную Magic (hostvars['inventory_hostname].join_command) безрезультатно.

Похоже, что людям удалось получить доступ к фактам хоста с хостов, определенных в статическом файле инвентаризации, однако из-за динамической природы серверов EC2 будет создан кластер, я не могу использовать этот подход.

run.yml: 

  name: Setup K8s master node
  hosts: tag_Name_kube_master    
  gather_facts: true    
  roles:    
  - setup_kube_master


  name: Setup K8s worker nodes
  hosts: tag_Name_kube_worker
  gather_facts: true
  roles: 
  - setup_kube_worker

setup_kube_master / задачи / set_fact.yml: 

  name: Get join command for workers    
  shell: kubeadm token create --print-join-command    
  register: join_command_stdout    
  name: Persist variable for workers    
  set_fact:    
   join_command: "{{ join_command_stdout.stdout_lines[0] }}"

setup_kube_worker / задачи / get_fact.yml: 

  name: join cluster
  shell: "{{ hostvars['tag_Type_master'].join_command }} --ignore-preflight-errors all  >> node_joined.txt"    
  args:    
   chdir: $HOME    
   creates: node_joined.txt

1 Ответ

0 голосов
/ 27 апреля 2019

Таким образом, вы могли бы решить эту проблему самостоятельно, используя задачу debug:, чтобы показать весь кэш фактов и найти для себя связь: 

- name: show the state of affairs
  debug: var=hostvars verbosity=0

Однако, сказав это, я почти уверен, что tag_Type_master определен как группа и, следовательно, не будет отображаться в hostvars, поскольку, как следует из его названия, это vars для хостов , а не vars для групп

Вы должны сделать один уровень косвенного обращения, чтобы получить хост, который является членом этой группы: 

- hosts: tag_Name_kube_worker
  tasks:
  - name: promote the "join_command" fact from the masters group
    set_fact:
      join_command: '{{ some_master.join_command }}'
    vars:
      some_master: '{{ hostvars[groups["tag_Type_master"][0]] }}'

Я взял некоторые вольности с этим определением some_master ради краткости - в рабочем коде вы бы хотели на самом деле проверить, что эта группа существует и ее содержимое не пустое и т. Д., И т. Д., Но мне около 80 % уверен, что он будет работать даже как написано

Вы бы хотели, чтобы это появилось в run.yml между hosts: tag_Type_master и hosts: tag_Type_worker, чтобы ликвидировать разрыв в фактах между двумя группами и создать впечатление, будто рабочие все время имели этот join_command факт

Отдельно, хотя это не то, о чем вы просили, если бы вы пометили эти экземпляры с помощью "kubernetes.io/role/master": "" и / или "kubernetes.io/role": "master", вы бы выиграли, имея уже теги, которые cloud-provider ожидают . Я не знаю, как это будет выглядеть в ec2.py, но я уверен, что было бы дешево узнать, используя ansible-inventory -i ec2.py --list

Я помечаю работников соответствующим kubernetes.io/role: worker, хотя я почти уверен, что провайдер облака AWS не заботится об этом, вместо этого выбрав просто использовать metadata.labels на существующих узлах для регистрации в ELB и т. Д. и др.

...