Где разместить файл require.yml для Ansible и использовать его для разрешения зависимостей? - PullRequest
Новая
       26

Где разместить файл require.yml для Ansible и использовать его для разрешения зависимостей?

3 голосов
/ 20 апреля 2019

Я новичок в ANSIBLE и изучал зависимые роли. ссылка на документацию

То, что я не нашел в документации, - где разместить файл requirements.yml.

Например, если мой site.yml выглядит следующим образом: 

---
- name: prepare system
  hosts: all
  roles:
     - role1

И, скажем,

  • роль1 зависит от роли2 и роли3
  • роль2 зависит от роли4 и роли5

Как правило, ansible-galaxy имеют следующую структуру: 

└── test-role
    ├── defaults
    │   └── main.yml
    ├── files
    ├── handlers
    │   └── main.yml
    ├── meta
    │   └── main.yml
    ├── README.md
    ├── tasks
    │   └── main.yml
    ├── templates
    ├── tests
    │   ├── inventory
    │   └── test.yml
    └── vars
        └── main.yml

Зависимости, добавленные к meta/main.yml.Предполагая, что role1 имеет зависимости, помеченные в этом файле, например (и аналогично для role2): 

dependencies: 
  - role: role2
  - role: role3

И у меня также есть файл requirements.yml, который выглядит следующим образом: 

---    
- src: some git link1
  version: master
  name: role2
- src: some git link2
  version: master
  name: role3

Myвопрос: где я могу разместить этот requirements.yml файл для role1?

Я понимаю, что требования должны быть установлены командой 

ansible-galaxy install -r requirements.yml -p roles/

И я могу сделать это для role1, но как это автоматизировать для role2?Нужно ли разрешать и устанавливать последовательные зависимости вручную, или есть что-то лучше?

1 Ответ

2 голосов
/ 20 апреля 2019

С технической точки зрения, вы можете поместить свой файл requirements.yml в любое удобное для вас место, если вы укажете правильный путь в команде ansible-galaxy install.

Между тем, если вы когда-нибудь захотите запустить свои игровые книги из Ansible Tower / Awx, я предлагаю вам придерживаться требований Ansible Tower и поместить файл requirements.yml в <project-top-level-directory>/roles/requirements.yml

Что касается зависимостей между ролями, ansible-galaxy может следовать за ними самостоятельно, когда они встречаются во время установки. Таким образом, вам не нужно указывать их все в вашем requirements.yml, только на верхнем уровне. Вам просто нужно правильно указать свои зависимости в каждой внешней роли.

В meta/main.yml для роли1 

dependencies:
  - src: https://my.scm.com/my-ansible-roles/role2.git
    scm: git
    version: master
    name: role2
  - src: https://my.scm.com/my-ansible-roles/role3.git
    scm: git
    version: master
    name: role3

В meta/main.yml для роли2 

dependencies:
  - src: https://my.scm.com/my-ansible-roles/role4.git
    scm: git
    version: master
    name: role4
  - src: https://my.scm.com/my-ansible-roles/role5.git
    scm: git
    version: master
    name: role5

roles/requirements.yml

---    
- src: https://my.scm.com/my-ansible-roles/role1.git
  scm: git
  version: master
  name: role1

Чтобы быть как можно более исчерпывающим, это то, что я сейчас обычно делаю в своих проектах, чтобы обрабатывать зависимости локально, а также локальные / только роли проекта

Базовая структура проекта 

ansible-project-dir
└─── roles
|    └─── locally-versionned-role1
|    └─── locally-versionned-role1
|    └─── ...
|    └─── requirements.yml
|    └─── .gitignore
└─── ansible.cfg
└─── playbook1.yml
└─── playbook2.yml

ansible.cfg

Я запускаю поиск и загрузку ролей в локальном каталоге roles, задав roles_path = roles, чтобы пользователь мог использовать ansible-galaxy install без параметра -p.

roles/requirements.yml

Уже обсуждалось выше. Просто перечислите зависимости от внешнего верхнего уровня (то есть, не версии в проекте) как имя роли галактики или как git uris. Если вам нужно полностью проверить эти роли, чтобы потом делать git коммиты / нажимать на них, вы можете использовать ansible-galaxy install -g -f -r roles/requirements

roles/.gitignore

# Ignore everything in roles dir
/*
# Except:
# the .gitignore file
!.gitignore
# the requirements file
!requirements.yml
# Readme if you have one
!README.md
# and any specific role we want to version locally
!locally-versionned-role*/
...