[Ansible] Ansible Tower 3.8.0 リリース、Automation Hub が同梱に

はじめに

Ansible Tower 3.8.0 がリリースされました。

リリースノートから個人的に気になった追加点、変更点をあげます。（詳細まだ追いきれておらず、独り言のような箇所もあります）

全体的には、組織内で content（≒ collection?） を管理する運用を支援する機能がふえた傾向のようです。

[2020/11/19 16:10 追記] 現在、公式ドキュメントの latest が 3.7 系に戻ってしまっているようです。

リリースノート

docs.ansible.com

ライフサイクル

access.redhat.com

（引用は、個別に明記した個所以外はすべて 3.8.0 のリリースノートから）

■ Private Automation Hub の同梱

Updated the Tower installer to include Automation Hub, which collectively serves as the Ansible Automation Platform installer

先日の Ansible Fest でも発表があった、 Private Automation Hub。自前の Automation Hub といったところでしょうか。

www.youtube.com

www.youtube.com

www.youtube.com

www.ansible.com

組織内で content を管理する運用を支援する大きな機能が追加された形かと思います。

■ ライセンス認証方式の変更

Updated Tower licenses to a subscriptions-based model that requires customer credentials or a subscriptions manifest

customer credentials か subscriptions manifest へと変更。manifest file の取得方法はこちら。

ライセンスファイルをアップロードする方式はなくなったようです。

• 参考公式ドキュメント

docs.ansible.com

アップグレード時の考慮事項（Import a Subscriptionから引用）

Even if you already have valid licenses from previous versions, you must still provide your credentials or a subscriptions manifest again upon upgrading to Ansible Tower 3.8.

■ YAML によるインベントリソースをフルサポート

Updated inventory sources to allow configuration via full YAML inventory plugin configuration

3.7 でもできないこともなかった気もしますが、改善され、フルサポートという形になったようです。

情報ありがとうございます。

・Automation Hub は Private Automation Hub です。
・ライセンスファイルの代わりに manifest をアップロードするようになったということです。
・インベントリプラグインのフルサポートはかなり大きいいです。これまでは指定したくてもできない場合がありました。(EC2 や vCenter の tag とか)

— すぎむら (@sugitk) 2020年11月19日

• 公式ドキュメント docs.ansible.com

■ カスタムログインページで HTML を利用可能に

Added the ability to include HTML in the Custom Login Info presented on the login page

ログイン画面は、案内文などを追加できる機能がありましたが、そこで HTML タグが利用できるようになりました。リンクはったりするのに便利かもしれません。

■ content provider に Automation Hub を指定可能に

Introduced Automation Hub as the content provider for Ansible Tower

そもそも content provider とはなんでしたっけという状態ですが・・。

公式ドキュメントの Credential Type のページに関連しそうな説明がありました。

docs.ansible.com

■ 組織ごとに Automation Hub を content sources として指定可能に

Introduced the ability to configure content sources, including Automation Hub, on a per-organization basis

こちらも、組織内で content を管理する運用を支援する機能のようです。

■ ansible.tower collection や awx 設定情報の import/export が可能に

Introduced the import/export feature for ansible.tower collections

Introduced the import/export feature for awx-cl

(おそらく末尾の i が抜けてしまっています)

Ansible Tower 上の、プロジェクト、ジョブテンプレート、ユーザーなどの情報を JSON ファイルとして、エクスポート、インポートできるようになりました。以前 AWX 側で試したときは、認証情報そのものまでは流石に含まれませんでしたが、

また、記憶では tower-cli が現役の頃は類似の機能として tower_* モジュールに send/receive というものがあった気がしますが、それが置き換わったということだと思います。

• 参考公式ドキュメント docs.ansible.com

■ RHEL 7 が Deprecated 扱い

Deprecated Red Hat Enterprise Linux 7 as a supported operating system for a Tower node, which will be removed in a future release

Ansible Tower のインストール先とし Red Hat Enterprise Linux 7 が Deprecated 扱いとなりました。将来的に対象外。

• 参考公式ドキュメント docs.ansible.com

（Prerequisites and Requirementsから引用）

The next major release of Ansible Tower will not support Red Hat Enterprise Linux 7 or CentOS (any version) as an installation platform.

■ CentOS が Deprecated 扱い

Deprecated CentOS as a supported operating system for a Tower node, which will be removed in a future release

Ansible Tower のインストール先として CentOS が Deprecated 扱いとなりました。将来的に対象外。

• 参考公式ドキュメント docs.ansible.com

（Prerequisites and Requirementsから引用）

The next major release of Ansible Tower will not support Red Hat Enterprise Linux 7 or CentOS (any version) as an installation platform.

■ Approval node の改善

Fixed workflows so that certain users can now edit approval nodes

詳細は分かりませんが、編集できなかったケースがあったのが編集できるようになったようです。

おわりに

おそらく、後日、目玉機能については公式ブログでも取り上げられるのではないかと思います。

[Ansible] もくもく会の Windows編 に挑戦

はじめに

2020/11/10 開催の Ansible もくもく会は、はじめて Windows 編が登場しました。

普段はメンターで参加しているのですが、今回は Windows 編に普通の参加者として参加しました。

ansible-users.connpass.com

教材と環境

コンテンツはこちら（翻訳ありがとうございます！）。

github.com

Ansible Tower と Web 版の VSCode?（正式名称なんというのでしょう）、Windows サーバー、GitLabのセットが各参加者に割り当てられて、ハンズオンができます。

WinRM の接続設定もされていたようです。

やったこと

演習2ではまず手始めに、Ansible Tower で win_shell モジュールなどを利用してアドホック実行をしました。

アドホック実行してから、ブラウザの戻るボタンでもどって再度実行しようとすると「制限」が all となり、Windows 以外のホストにも実行してしまう点がちょっとはまりました。インベント画面から再度Windows ホストのみ選択して再実行するとうまくいきました。

アドホック実行できるモジュールは、予め設定で決まっているのですが、この環境ではいくつか win_* モジュールが追加されているようでした。（設定方法）

アドホックで打てる win モジュール。この環境だとデフォルトからいくつか追加されてるみたい。#ansiblejp pic.twitter.com/DHGw5ZPcvi

— よこち(yokochi) (@akira6592) 2020年11月10日

演習3では、IIS をインストール、起動、コンテンツのデプロイをPlaybookを作りました。IIS というあたりが Windows らしいですね。

Ansible で Windows への IIS のインストール、起動と index.html 置くやつできました。#ansiblejp pic.twitter.com/QY7B2mWcnD

— よこち(yokochi) (@akira6592) 2020年11月10日

その後、ロール化もおこないました。

演習7では、Windows Update を実行する Playbook を作成しました。

アップデート対象を教材通り、CriticalUpdates、SecurityUpdates のままにすると、今回のタイミングでは特にアップデートが適用されなくて面白くなかったので、全カテゴリを選択したら、アップデートがあたりました。

Windwos Update のジョブですが、デフォルトだと何もアップデートなかったようなので、カテゴリ全部選択したらアップデートがはいりました。Updates がきいたようです。#ansiblejp pic.twitter.com/CLt2FazzZW

— よこち(yokochi) (@akira6592) 2020年11月10日

脱線しますが、VSCode の小技です。

ブラウザ版の VSCode ? でも、ディレクトリとファイルいっぺんに作るのできました #ansiblejp pic.twitter.com/McAFWMdoFK

— よこち(yokochi) (@akira6592) 2020年11月10日

なお、RDP で接続した感じですと Windows Core のようでした。予め準備されているのは助かります。

もくもく会の Windows 環境、Server Core かな pic.twitter.com/iMV7ELNJRo

— よこち(yokochi) (@akira6592) 2020年11月10日

プロジェクトの更新忘れがち

GitLab に git push して、Ansible Tower のプロジェクトで 最新ファイルを持ってくるという流れがサーバー編や、ネットワーク編とは異なりました。

新しいファイルを追加するとプロジェクトを更新するというのを忘れると、ジョブテンプレートでPlaybookを選択できない、というのが割と罠です。

対策1: Webhook

nnstt1.hatenablog.com

対策2: コマンドツールで効率化

tekunabe.hatenablog.jp

おわりに

はじめての Windows 編でのもくもく会でした。ニーズはだいぶあるようなのでまた開催されるといいなと思います。

次回は 12/17 開催で、サーバー・ネットワーク編です。

ansible-users.connpass.com

他の参加者の方の記事

note.com

Cisco の仮想ラボ環境 CML 2.0 から 2.1 へのアップグレード

はじめに

Cisco の仮想ラボ環境（有償）である CML の 2.1 がリリースされましたので、自宅環境の CML 2.0 をアップグレードしました。

パケットキャプチャー機能が改善したりしています。

CML 2.1 is almost here! What's changed?

YouTube video: https://t.co/52GIf0Y7JE#cml #virl #ccna #cisco #devnet @rschmied_csco @CiscoDevNet @YouTube @NetworkChuck pic.twitter.com/Ur9Kpj3T3s

— David Bombal (@davidbombal) 2020年8月7日

本記事は、アップグレードした際の作業記録です。

雰囲気を掴む程度に留めていただき、正確な手順は以下の公式ドキュメントをご参照ください。

developer.cisco.com

• 参考: CML 2.0 時代のインストール
  • CML-P (VIRL2) のインストールと基本機能 - てくなべ (tekunabe)

なお、CML 2.1 からベアメタルインストールにも対応したようですが、当環境は VMware へ仮想マシンとしてデプロイした CML-Personal 2.0 からを 2.1 へのアップグレードです。

■ 1. 各種ファイルのダウンロード

Software Download （要ログイン）から CML-Personal 2.1 を選択し、以下の2つのファイルをダウンロードします。

• cml2_p_controller-2.1.0-17.el8.x86_64.rpm
  • アップデート用 RPM
• refplat_p-20201020-fcs.iso
  • IOS や IOS XR などの各種イメージが含まれる ISO。CML 2.0 の頃は refplat_p-20200409-fcs.iso でした。

■ 2. CML コントローラーのアップグレード

RPM のアップロード

（詳細は公式ドキュメントの CML Controller Upgrade - CML UI steps を参照）

CML の Web UI にログインし、Tools > System Upgrade をクリックします。

System Upgrade

先ほどダウンロードした cml2_p_controller-2.1.0-17.el8.x86_64.rpm を指定して、Upload Image をクリックします。

rpm ファイルを選択して Upload Image

アップロード中は以下のようなプログレスバー表示になり、完了するともとの画面に戻ります。特に完了した旨のメッセージは表示されません。

アップロード中

Cockpit からアップグレード

（詳細は公式ドキュメントの CML Controller Upgrade - System Administration Cockpit steps を参照）

ここからは システム管理の Web UI である Cockpit での操作です。

通常通りCMLをインストールした場合 https://cmlのホスト:9090 です。システム管理者ユーザー（CML の Web ログインユーザーとは異なる）でログインします。その際「特権タスクにパスワードを再使用する」にチェックを必ず入れます。入れないとあとでアップロードの際に Controller software upgrade has FAILED というエラーがが発生します（経験談）。

「特権タスクにパスワードを再使用する」にチェックを忘れずに

ログイン後、左メニューの CML をクリックし、Maintenance セクション内の Controller Software Upgrade を開き、Upgrade Controller をクリックします。

Upgrade Controller

表示されるポップアップの Upgrade をクリックします。

Updgrade

アップグレードが始まり、しばらくすると Output セクションに Upgrade prosece done と表示されます。

Upgrade prosece done

ブラウザの画面を再読込すると、Finish Upgarade ボタンが現れるのでクリックします。

Finish Upgarade

表示されるポップアップの Upgrade をクリックします。

Upgrade

CML サーバーが再起動し、画面上は切断されます。

切断

しばらくしてブラウザの画面を再読込すると、再度表示されます。

ここまでで、CML 自体のアップグレードが完了しました。

■ 2. OS のパッケージのアップデード

ドキュメント上 Recommended とされていた、OS のパッケージをアップデードします。

（詳細は公式ドキュメントの Upgrading the Base OS - Recommended (online upgrades only) を参照）

左メニューの サービス をクリックし、ターゲット から CML2 Network Simulation System をクリックします。

CML Network Simulation System

CML Network Simulation System の 停止 をクリックします。（公式ドキュメントでは「 the three vertical dots at the end of the CML2 Network Simulation System line」とありましたが、Cockpit のバージョン違いなのかUIが異なっていました）

CML Network Simulation System の停止

inactive になったことを確認します。

inactive

左メニューの ソフトウェア更新 をクリックし、すべてのアップデートをインストール をクリックします。

すべてのアップデートをインストール

しばらくすると、画面上は切断状態になります。（再起動を促すメッセージは表示されませんでした）

切断

Cockpit に再ログインします。（見た目が変わりました）

再ログイン

左メニューの サービス をクリックし、ターゲット から CML2 Network Simulation System をクリックします。

virl2.target

CML2 Network Simulation System の ... から 開始日 をクリックします（おそらく開始の意味）。

開始

状態が 実行中 になったことを確認します。

実行中

ここまでで、OS のパッケージアップデートも完了しました。

■ 3. イメージファイル ISO の差し替え

最初にダウンロードした refplat_p-20201020-fcs.iso を CML を動かしている仮想マシンの仮想ドライブに割り当てます。

■ 4. 確認

（Cockpit ではなく） CML の Web 画面にログインします。ログインでのバージョン表記が 2.1.0-b17 となりました。

2.1.0-b17

ログイン後の画面も少し変わりましたね。Dashboard という名前になったようです。以下の画面では、2.1 の新機能であるダークモードに切り替えたものです。

ダークモード

おわりに

無事に CML 2.1 にアップグレードできました。

パケットキャプチャー機能の改善はとても便利だと思うので試してみたいと思います。

参考

CML 2.1 へインプレースアップグレードして人柱準備完了。
既存のラボは ping ぐらいしか動作確認していないけど、これからどんどん使っていってみてどうなるかだなあ。 pic.twitter.com/GgxQYlT9gk

— Wataru Noguchi (@wnoguchi) 2020年11月7日

tekunabe.hatenablog.jp

[Ansible] タグ指定時にどのタスクが実行されるか事前に確認する（-t と --list-tasks の併用）

はじめに

Playbook には、Play 単位、Task 単位など様々な単位でタグを付けることができます。タグを付けることで、Playbook 実行時に指定したタグが付いたタスクのみ実行する、といった制御ができるようになります。

タグを活用していくと「このタグを指定した時にどのタスクが実行されるのか、事前に確認したい」と思うことはないでしょうか。

ansible-playbook コマンドの --list-tasks オプションを併用することで確認できます。

この記事で簡単なサンプルで検証します。

• 検証環境
  • ansible 2.10.3
  • ansible-base 2.10.3

※注: inlcude_role などの include 系で読み込んだ先のタスクは、性質上 --list-tasks では表示されません。（Comparing includes and imports: dynamic and static re-use）

Playbook

タグ a や b を付けた3つのタスクがある Playbook です。

---
- hosts: all
  gather_facts: false

  tasks:
    - name: task1
      debug:
        msg: task1
      tags:
        - a

    - name: task2
      debug:
        msg: task2
      tags:
        - a
        - b

    - name: task3
      debug:
        msg: task3
      tags:
        - b

-t と --list-tasks の併用 で事前確認

タグ a を指定することで実行されるタスクを、--list-tasks で事前に確認します。

$ ansible-playbook -i localhost, tags.yml -t a --list-tasks   
playbook: tags.yml

  play #1 (all): all    TAGS: []
    tasks:
      task1     TAGS: [a]
      task2     TAGS: [a, b]

タグ a が付いた task1 と task2 が表示されました。タグ a が付いてない task3 は表示されません。

実際に Playbook 実行

一応、--list-tasks オプションを外して実際に Playbook を実行して確認します。

$ ansible-playbook -i localhost, tags.yml -t a             

PLAY [all] *********************************************************************************************************

TASK [task1] *******************************************************************************************************
    "msg": "task1"
}

TASK [task2] *******************************************************************************************************
ok: [localhost] => {
    "msg": "task2"
}

PLAY RECAP *********************************************************************************************************
localhost                  : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0  

--list-tasks で確認した通り、task1 と task2 が実行されました。

おわりに

どのタスクが実行されるか予想できないようなタグの付け方は避けるべきですが、それでも事前に書くにできるのは便利かなと思います。

[ansible] 2.10 では pip uninstall ansible でアインストールしても ansible 基本機能と標準モジュールは残る

はじめに

Ansible 2.10 から、Collection による モジュール類の配布が本格化し、2.9 までの多くのモジュール類は Collection に移行しました。

参考: Ansible 2.10 と Collection

これに関連して、Python のパッケージとしては ansible と、ansible-base に別れました。

ansible-baseは、Ansible の基本機能と、標準モジュールです。 ansible は、ansible-base と、Collection に移行した元標準モジュールのセットです。

pip install ansible では、ansible と ansible-base がインストールされます。

注意が必要なのは、pip uninstall ansible すると ansible がアンインストールされ、 ansible-base は残ります。

つまり、Ansible の基本機能と、標準モジュールは残ります。これらもアンインストールするには、ansible-base もアインストールする必要があります。

このあたりのパッケージに役割を理解しておかないと、少し混乱してしまうかもしれません。

この記事では、実際のログを用いて簡単に解説します。

事前状態

ansible がインストールされてない状態からはじめます。

(ansibletest) sakana@mbp16 blog % ansible  
zsh: command not found: ansible
(ansibletest) sakana@mbp16 blog % pip freeze

何も表示されません。

ansible のインストール

pip install ansible でインストールします。

(ansibletest) sakana@mbp16 blog % pip install ansible
Collecting ansible
  Using cached ansible-2.10.1.tar.gz (25.9 MB)
Collecting ansible-base<2.11,>=2.10.2
  Using cached ansible-base-2.10.2.tar.gz (6.0 MB)
Collecting jinja2
  Using cached Jinja2-2.11.2-py2.py3-none-any.whl (125 kB)
...(略)...
Successfully installed MarkupSafe-1.1.1 PyYAML-5.3.1 ansible-2.10.1 ansible-base-2.10.2 cffi-1.14.3 cryptography-3.2 jinja2-2.11.2 packaging-20.4 pycparser-2.20 pyparsing-2.4.7 six-1.15.0
WARNING: You are using pip version 20.1.1; however, version 20.2.4 is available.
You should consider upgrading via the '/Users/sakana/envs/ansibletest/bin/python3 -m pip install --upgrade pip' command.

ansible と ansible-base の両方がインストールされたことが分かります。

(ansibletest) sakana@mbp16 blog % pip freeze
ansible==2.10.1
ansible-base==2.10.2
cffi==1.14.3
cryptography==3.2
Jinja2==2.11.2
MarkupSafe==1.1.1
packaging==20.4
pycparser==2.20
pyparsing==2.4.7
PyYAML==5.3.1
six==1.15.0

ansible のインストール後確認

バージョンを確認します。ansible --version では ansible-base としてのバージョンが表示されます。（ここでは 2.10.2）

(ansibletest) sakana@mbp16 blog % ansible --version
ansible 2.10.2
  config file = /Users/sakana/.ansible.cfg
  configured module search path = ['/Users/sakana/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /Users/sakana/envs/ansibletest/lib/python3.8/site-packages/ansible
  executable location = /Users/sakana/envs/ansibletest/bin/ansible
  python version = 3.8.5 (default, Jul 21 2020, 10:48:26) [Clang 11.0.3 (clang-1103.0.32.62)]

which でパスを確認すると、作業用の venv 配下であることが分かります。

(ansibletest) sakana@mbp16 blog % which ansible
/Users/sakana/envs/ansibletest/bin/ansible

ansible のアンインストール

pip uninstall ansible でアンインストールします。

(ansibletest) sakana@mbp16 blog % pip uninstall ansible
Found existing installation: ansible 2.10.1
Uninstalling ansible-2.10.1:
  Would remove:
    /Users/sakana/envs/ansibletest/lib/python3.8/site-packages/ansible-2.10.1-py3.8.egg-info
    /Users/sakana/envs/ansibletest/lib/python3.8/site-packages/ansible_collections/amazon/aws/.github/BOTMETA.yml
    /Users/sakana/envs/ansibletest/lib/python3.8/site-packages/ansible_collections/amazon/aws/.github/settings.yml
    /Users/sakana/envs/ansibletest/lib/python3.8/site-packages/ansible_collections/amazon/aws/.gitignore
    ....(略)...
    /Users/sakana/envs/ansibletest/lib/python3.8/site-packages/ansible_collections/wti/remote/plugins/modules/cpm_temp_info.py
    /Users/sakana/envs/ansibletest/lib/python3.8/site-packages/ansible_collections/wti/remote/plugins/modules/cpm_time_config.py
    /Users/sakana/envs/ansibletest/lib/python3.8/site-packages/ansible_collections/wti/remote/plugins/modules/cpm_time_info.py
    /Users/sakana/envs/ansibletest/lib/python3.8/site-packages/ansible_collections/wti/remote/plugins/modules/cpm_user.py
Proceed (y/n)? y
  Successfully uninstalled ansible-2.10.1
(ansibletest) sakana@mbp16 blog % 

Collection に移行した元標準モジュールがある lib/python3.8/site-packages/ansible_collections/ が消えます。

Ansible 本体機能と標準モジュールがある、lib/python3.8/site-packages/ansible/ は残ります。

ansible のアンインストール後確認

pip freeze で確認すると ansible は消えましたが、ansible-base は残っています。

(ansibletest) sakana@mbp16 blog % pip freeze
ansible-base==2.10.2
cffi==1.14.3
cryptography==3.2
Jinja2==2.11.2
MarkupSafe==1.1.1
packaging==20.4
pycparser==2.20
pyparsing==2.4.7
PyYAML==5.3.1
six==1.15.0

ansible などのコマンドは引き続き使えます。この点が少々混乱するポイントかも知れません。

(ansibletest) sakana@mbp16 blog % ansible --version
ansible 2.10.2
  config file = /Users/sakana/.ansible.cfg
  configured module search path = ['/Users/sakana/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /Users/sakana/envs/ansibletest/lib/python3.8/site-packages/ansible
  executable location = /Users/sakana/envs/ansibletest/bin/ansible
  python version = 3.8.5 (default, Jul 21 2020, 10:48:26) [Clang 11.0.3 (clang-1103.0.32.62)]

Ansible 2.10 においても標準モジュールである debug モジュールも使えます。

(ansibletest) sakana@mbp16 blog % ansible -i localhost, all -m debug -a msg=pukupuku
localhost | SUCCESS => {
    "msg": "pukupuku"
}

ansible-base のアンインストール

一応、 ansible-base のアンインストールもためします。

(ansibletest) sakana@mbp16 blog % pip uninstall ansible-base
Found existing installation: ansible-base 2.10.2
Uninstalling ansible-base-2.10.2:
  Would remove:
    /Users/sakana/envs/ansibletest/bin/ansible
    /Users/sakana/envs/ansibletest/bin/ansible-config
    /Users/sakana/envs/ansibletest/bin/ansible-connection
    /Users/sakana/envs/ansibletest/bin/ansible-console
    /Users/sakana/envs/ansibletest/bin/ansible-doc
    /Users/sakana/envs/ansibletest/bin/ansible-galaxy
    /Users/sakana/envs/ansibletest/bin/ansible-inventory
    /Users/sakana/envs/ansibletest/bin/ansible-playbook
    /Users/sakana/envs/ansibletest/bin/ansible-pull
    /Users/sakana/envs/ansibletest/bin/ansible-test
    /Users/sakana/envs/ansibletest/bin/ansible-vault
    /Users/sakana/envs/ansibletest/lib/python3.8/site-packages/ansible/*
    /Users/sakana/envs/ansibletest/lib/python3.8/site-packages/ansible_base-2.10.2-py3.8.egg-info
    /Users/sakana/envs/ansibletest/lib/python3.8/site-packages/ansible_test/*
  Would not remove (might be manually added):
    /Users/sakana/envs/ansibletest/lib/python3.8/site-packages/ansible_test/_data/injector/ansible-inventory
Proceed (y/n)? y
  Successfully uninstalled ansible-base-2.10.2

ansible-base のアンインストール後確認

いよいよ ansible コマンドもなくなり、pip freeze で確認しても ansible-base がでなくなりました。

(ansibletest) sakana@mbp16 blog % ansible --version
zsh: command not found: ansible
(ansibletest) sakana@mbp16 blog % pip freeze
cffi==1.14.3
cryptography==3.2
Jinja2==2.11.2
MarkupSafe==1.1.1
packaging==20.4
pycparser==2.20
pyparsing==2.4.7
PyYAML==5.3.1
six==1.15.0

おわりに

pip unsintall ansible しても ansible-base が残るため、Ansible の基本機能、標準モジュールは使えることを確認しました。

[Ansible] Ansible Tower で実行する Playbook が外部ファイルを参照できないときは「ジョブの分離の有効化」設定を確認

はじめに

Playbook 内で、Ansible Tower サーバー内の /tmp ディレクトリ内のファイルを読み込もうとしたところ、ファイルが見つからないエラーが発生しました。

"message": "Could not find or access '/tmp/hoge/fuga.yml' on the Ansible Controller.\nIf you are using a module and expect the file to exist on the remote, see the remote_src option

この記事では、切り分けと原因について紹介します。

• 環境
  • Ansible Tower 3.7.2

切り分け

手動でls コマンドなどで確認すると、たしかにファイルは存在し、awx ユーザーにも権限はある状態でした。

コマンド版の Ansible では問題なくアクセスできていました。

切り分けのために shell モジュールで、ls -al /tmp を実行してみると、実際よりディレクトリやファイルが少なく見える状態でした。

ファイルシステムを隠蔽するような機能が動いているようにみえました。

原因

セキュリティ機能による現象でした。

[2020/10/28 追記] bubblewrap というものを使って実現しているそうです。情報ありがとうございます。

例えば Demo Job Template を実行中に ps -efL するとこんな感じで bwrap されているのが見えます。--bind とか --ro-bind とかです。 pic.twitter.com/o7uAENKcWv

— すぎむら (@sugitk) 2020年10月26日

具体的には「設定 / ジョブ」画面にある「ジョブの分離の有効化」（英語では Enable Job Isolation）です。

ジョブの分離の有効化

デフォルトで有効で、以下のディレクトリが対象のようです。

• /etc/tower
• /var/lib/awx
• /var/log
• /tmp

ちょうど、つまずいていたのも /tmp ディレクトリでした。試しに無効化したら正常にファイルが読み込めました。

とはいえ、手放しに無効化するのも心配ですので、下記のドキュメントに基づき、ファイルのパスや設定を調整する必要があるようです。

bubblewrap というものを使って実現しているそうです。情報ありがとうございます。 docs.ansible.com

「分離されたジョブに公開するパス」に例外（ホワイトリスト）を設定しておくと、「ジョブの分離の有効化」を有効にしつつも、必要な箇所だけアクセスできるようにできるようです。

ホワイトリスト

なお、docker-compose で構築した AWX 15.0.0 では「ジョブの分離の有効化」はデフォルトで無効化さされていました。

[Ansible/AWX] カスタム venv でジョブ実行時 ansible-playbook コマンドが No such file or directory のエラーになる

はじめに

こちらの記事で紹介した方法で、ホスト側に カスタム venv を作って ansible をインストールし、awx_task コンテナにマウントさせてジョブテンプレートを実行したとろころ、以下のようなエラーが発生しました。

エラー

• 環境
  • AWX 15.0

エラー詳細

エラー全文は以下の通り。

Traceback (most recent call last): File "/var/lib/awx/venv/awx/lib/python3.6/site-packages/awx/main/tasks.py", line 1501, in run res = ansible_runner.interface.run(**params) File "/var/lib/awx/venv/awx/lib/python3.6/site-packages/ansible_runner/interface.py", line 178, in run r.run() File "/var/lib/awx/venv/awx/lib/python3.6/site-packages/ansible_runner/runner.py", line 179, in run use_poll=self.config.pexpect_use_poll, File "/var/lib/awx/venv/awx/lib/python3.6/site-packages/pexpect/pty_spawn.py", line 204, in __init__ self._spawn(command, args, preexec_fn, dimensions) File "/var/lib/awx/venv/awx/lib/python3.6/site-packages/pexpect/pty_spawn.py", line 303, in _spawn cwd=self.cwd, **kwargs) File "/var/lib/awx/venv/awx/lib/python3.6/site-packages/pexpect/pty_spawn.py", line 314, in _spawnpty return ptyprocess.PtyProcess.spawn(args, **kwargs) File "/var/lib/awx/venv/awx/lib/python3.6/site-packages/ptyprocess/ptyprocess.py", line 330, in spawn raise exception OSError: [Errno 2] No such file or directory: b'/opt/my-envs/a210/bin/ansible-playbook'

/opt/my-envs/a210 が作成したvenvです。

調査

エラーによると、/opt/my-envs/a210/bin/ansible-playbook がないとのことですが、awx_task` コンテナの中に入って調べてみるとちゃんとある状態でした。

そこで、awx_task コンテナで /opt/my-envs/a210/bin/ansible-playbook --version を実行してみました。

bash-4.4# /opt/my-envs/a210/bin/ansible-playbook --version
bash: /opt/my-envs/a210/bin/ansible-playbook: /opt/my-envs/a210/bin/python3: bad interpreter: No such file or directory

どうやら、Python インタープリター /opt/my-envs/a210/bin/python3 がないようです。

対処

詳細は分からないですが、venv を作るときのちょっとした手違いかなにかかと思い、再度ホスト側で venv を作成しなおしたら、エラーはなくなり正常に実行できました。

ansible-playbook コマンドがないというエラーのときは、python インタープリター の有無もあわせて調べてみると良いかも知れません。