Ansible Galaxyロールを自動的にインストールする方法は?


129

Ansibleのすべてのプレイブック/ロールは、私のgitリポジトリにチェックインされています。

ただし、Ansible Galaxyの役割の場合は、Ansibleを実行するすべてのマシンに1つずつ明示的にダウンロードする必要があります。

実行時に不足している役割についてAnsibleが文句を言うまで、必要なAnsible Galaxyの役割を事前に正確に把握することはさらに困難です。

Ansible Galaxyロールの依存関係を管理するにはどうすればよいですか?Ansibleの残りのコードとともにgitリポジトリにチェックインするか、新しいマシンでAnsibleを実行したときに自動的に識別されてダウンロードされるようにしたいのですが。


galaxy.ansible.com/docs/using/index.htmlこれがansible-galaxyを使用するために必要なすべてのものです。よくできたドキュメントです。あなたが初心者であっても:)
Ayra

@pdeva以下の有効な回答の1つを受け入れてもらえますか?
GG。

回答:


148

requirements.ymlこのユースケースにはファイルを使用する必要があります。さまざまなインストール方法のいずれかを使用して、必要な役割を説明します。

# Install a role from the Ansible Galaxy
- src: dfarrell07.opendaylight

# Install a role from GitHub
- name: opendaylight
  src: https://github.com/dfarrell07/ansible-opendaylight

# Install a role from a specific git branch
- name: opendaylight
  src: https://github.com/dfarrell07/ansible-opendaylight
  version: origin/master

# Install a role at a specific tag from GitHub
- name: opendaylight
  src: https://github.com/dfarrell07/ansible-opendaylight
  version: 1.0.0

# Install a role at a specific commit from GitHub
- name: opendaylight
  src: https://github.com/dfarrell07/ansible-opendaylight
  version: <commit hash>

次に、それらをインストールします。

ansible-galaxy install -r requirements.yml

これが実際の例です(AnagibleをVagrantプロビジョナーとして使用してOpenDaylightをインストールします)。詳細については、関連するAnsibleのドキュメントをご覧ください。


以下の@Kieran Andrewsの回答も参照してください。これを拡大します。
マルコフェラーリ

1
これは実際にはプレイブックの役割の依存関係を自動的にインストールするのではなく、プレイブックを作成した人間によって手動でリストされた依存関係のリストを明示的にインストールします。
ニール

53

提案されているように、このニーズにはansible galaxyを使用できます。

Ansibleには、requirements.ymlすべての役割をリストするファイルを作成できる機能があります。あなたはそれについてここで見つけることができます:http : //docs.ansible.com/ansible/latest/galaxy.html#installing-multiple-roles-from-a-file

例(requirements.yml):

- src: yatesr.timezone

次にansible-galaxy install -r requirements.yml、このファイルを実行して、そこにリストされているすべての役割をダウンロードします。

さらに自動化したい場合は、2つのコマンドを実行する単純なシェルスクリプトを作成できます。

例(ansible.sh):

./ansible.sh

ansible-galaxy install -r requirements.yml
ansible-playbook playbook.yml -i inventory 

1
テストされたばかりで、ロールが既にダウンロードされており、エラーはないというメッセージが表示されます。バージョン2.2.1
Igonato

インストールするGalaxyロールをプレイブックが利用する場合、プレイブックがダウンロードされる前にその存在が確認されるため、プレイブックが最初に呼び出されたときに実行されません。プレイブックをもう一度呼び出すと、新しくインストールされたロールが取得されます。
ベン

コマンドを減らすためのラッパースクリプトを使用して、現在の方法に更新しました。
キーラン・アンドリュース

19

Java JDKをインストールしていることがよくあります。ロールを使用すると、そのタッチが簡単になります。私はいくつかの異なる方法を試しました(多くの.gitmodulesとサブモジュールを含みます...作業のために複数のgitシステムを使用する必要があり、すべてが醜くなります)。私の最大の要件は、プレイブックプロジェクトに役割コードをチェックインしないことです。ほとんどの場合、すべてを1か所にまとめることができます。

私の 'requirements.yml'ファイルの内容:

- src: https://github.com/staylorx/ansible-role-wls-prep.git
  version: master
  name: staylorx.wls-prep

- src: https://my-work-git-extravaganza.com
  version: 2.x
  name: coolplace.niftyrole

#From Ansible Galaxy
- src: staylorx.oracle-jdk

別のプレイブックinstall-roles.ymlを実行します。

---

- hosts: localhost

  tasks:
    - file:
        path:  roles
        state: absent

    - local_action:
        command ansible-galaxy install -r requirements.yml --roles-path roles

    - lineinfile:
        dest:   .gitignore
        regexp: '^\/roles$'
        line:   '/roles'
        state:  present

この最初のプレイブックを実行してから、通常どおり、どのプレイブックでも自分の役割を実行します。私にとっての秘密は、それがgitによって無視されるようにすることです。そのため、誤って役割をチェックインしません。また、毎回フォルダーを一掃するので、エラーを強制したり無視したりする必要がないようにしています。


ローカルコマンドを実行する前に、「ロールが見つかりません」で失敗します。
Daniel AndreiMincă2017

1
@MincăDaniel Andreiあなたは動的な方法を使う必要があります。これを
user1686407

4

もう1つの解決策は、gitサブモジュールを使用することです。結局のところ、Ansible Galaxyはgithubリポジトリのディレクトリです...

このコマンドを使用して、Galaxyの役割をサブモジュールとして自動的に追加します。

ansible-galaxy info <package> | grep -A 1 github_repo | tr '\n' ' ' | sed -e "s/.*github_repo: \([^[:space:]]*\)[^\w]*github_user: \([^[:space:]]*\)[[:space:]]*/git submodule add git:\/\/github.com\/\2\/\1.git roles\/\2.\1/g" | sh

次に、変更をgitリポジトリにコミットします。将来的にレポを複製するときは、サブモジュールでそれを複製するようにしてください、例えばgit clone ... --recursive

これの利点は、gitサブモジュールが常に特定のバージョンを参照していることです(git commit-hash)。これにより、実稼働環境でテストされていない更新を実行できなくなります。Galaxyロールの新しいバージョンには、バグがあるか、以前とはまったく異なる動作をする可能性があります。gitサブモジュールを使用して、役割を新しいバージョンに更新するかどうか、いつ更新するかを決定します。

また、.gitignoreそれらのコードをリポジトリにコミットしないようにするために、追加で銀河の役割をブラックリストに登録する必要はありません。


5
これは私の意見では悪い習慣です。通常、依存関係管理ツールを使用してSCMリポジトリを接着する方が簡単です。特に、SCMのgitサブモジュールについて話している場合はそうです。
David Resnick 2016年

1
同意した。実際、私はこれをもう使用していません。それでも、ansible-galaxyは完全とはほど遠いため、これは有効なアプローチです。Galaxyは、バージョンが要件ファイルでバンプされている場合でも、更新をチェックしません。ドキュメント化されていない--forceフラグを使用してすべてのロールを強制的に再ダウンロードすると、実際に変更されたかどうか、または何が変更されたかが表示されません。これは、ダウンロードした銀河の役割をSCMに保持する場合にのみ制御できるブラックボックスです。他の理由でそれはとにかくそれは良い考えです。サブモジュールを取得すると、少なくともどのロールが変更されたかがわかります。
うどんだん2016年

ところで、サブモジュールのすべての問題は、AFAIKがコンテンツの変更に関連しているため、この状況では無視できます。私の経験に
よれば

4

Ansibleロールを使用して、コマンドモジュールを使用して必要なロールをインストールできます

以下は、実行する非常に基本的な例ですansible-galaxy install

- name: Install roles from Ansible Galaxy
  command: ansible-galaxy install {{ item.item }}
  with_items:
    - "{{ ansible_roles_list }}"

ansible_roles_list変数としてまたはロールパラメータとして供給されてもよいです。

役割でこれを行う場合は、別のプレイブックで、それを使用してインストールする他の役割のに適用する必要があります。これは、Ansibleが、参照するプレイブックを実行する前に、すべてのロールが使用可能かどうかを確認するためです。


卵と鶏肉:)
bazeusz

2

この時点では、私が知る限り、実行時にロールを自動的にダウンロードする方法はありません。あなたの最善の策は、それらを自分のリポジトリにコミットするか、すべての要件をリストした適切なドキュメントを用意することです。役割をインストールするプリフライトプレイブックを作成することもできます。:)


3
これには、requirements.txtファイルを使用できます。参照:docs.ansible.com/...
toast38coza

0

ここで、私の要件はロールにあり、install.ymlで使用されます

main.yml

 # tasks file for MY_ROLE
- name: Install requirements
  local_action: command ansible-galaxy install -r {{ role_path }}/requirements.yml -p /etc/ansible/roles

- include_tasks: install.yml 
.  
├── playbook.yml  
├── inventory  
├── roles  
│    └── My_Role   
│        ├── tasks  
│        │   └── main.yml  
│        │   └── install.yml  
│        └── requirements.yml
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.