はじめに
2 台の Linux サーバーを管理する Ansible コントロールノードを準備します。自動化を記述する前に、再現性のあるインストール環境と、両方の対象でコントローラーが Python モジュールを実行できることを確認する必要があります。
この実習では、プロジェクトの仮想環境を作成し、オフラインのパッケージキャッシュから Ansible Core をインストールしてターミナルで有効化し、用意されたインベントリで 2 つの実際の SSH 接続をテストします。基本的なコマンドラインの操作に慣れていれば十分です。Ansible の経験は必要ありません。
コントローラーの分離環境を作成する
このステップでは、自分専用の Ansible をインストールする Python 環境を作成します。
Ansible はコントロールノードで動作し、SSH 経由で管理対象ノードに接続します。LabEx のターミナルが Ubuntu のコントロールノードです。準備済みの 2 つの Linux コンテナー web1 と web2 は、それぞれ別の管理対象ノードとして動作します。アドレス、ホスト名、ファイルシステムは異なりますが、VM のカーネルは共有しています。Docker コマンドや、プラットフォームのログイン設定の変更は必要ありません。
Python の仮想環境は、プロジェクトのパッケージをオペレーティングシステムやコース共通ツールから分離します。イメージにはインフラ用の共有 Ansible コマンドがすでにありますが、ここでは別のコピーを /home/labex/project/.venv にインストールします。
ターミナルを開きます。cd でプロジェクトディレクトリに移動してください。以降の相対パスはここを基準に解決されます。
cd /home/labex/project
pwd は現在の作業ディレクトリを表示します。
pwd
出力は /home/labex/project になるはずです。この実習では引き続きこのディレクトリを使用します。
ansible-python はコース用に用意された Python を選択します。--version はそのバージョンを表示します。
ansible-python --version
Python 3.12.15 と表示されるはずです。コントロールノードのシステム Python は別のままです。置き換えないでください。
-m venv オプションは Python の仮想環境モジュールを実行します。最後の引数 .venv は、プロジェクト内に作成するディレクトリの名前です。先頭のドットにより、通常のディレクトリ一覧には表示されません。
ansible-python -m venv .venv
通常、このコマンドは何も表示せずに終了します。環境と Python のパッケージインストーラー pip が作成されます。Ansible はまだインストールされていません。
新しい環境の Python を相対パスで実行します。これにより、事前に有効化しなくても分離されたインタープリターを使用できることを確認できます。
.venv/bin/python --version
こちらも Python 3.12.15 と表示されるはずです。2 つの Python コマンドは同じリリースを使用しますが、.venv にインストールされるパッケージはこのプロジェクト専用です。
オフラインで Ansible をインストールして有効化する
このステップでは、バージョンを固定した Ansible Core を .venv にインストールし、ターミナルで使用するようにします。
Ansible Core は、このコースで使用する ansible コマンドと組み込みモジュールを提供します。用意された wheel ファイルはローカルの Python パッケージなので、インターネットからダウンロードしなくてもインストールできます。requirements ファイルは互換性のあるバージョンを固定して指定しています。
次のコマンドは、プロジェクトの Python で pip を実行します。install はパッケージをインストールし、--no-index はオンラインのパッケージインデックスを無効化し、--find-links はローカルの wheel ディレクトリを選択し、-r は requirements ファイルを読み込みます。
.venv/bin/python -m pip install --no-index --find-links /opt/labex/ansible-course/wheels -r /opt/labex/ansible-course/requirements.txt
出力にはローカルキャッシュから処理されたパッケージが並び、最後に ansible-core-2.21.5 を含む Successfully installed ... が表示されます。再インストール時には、代わりに Requirement already satisfied と表示されることがあります。
有効化すると、このシェルの検索パスの先頭に環境のコマンドディレクトリが配置されます。source は現在のターミナルで有効化スクリプトを実行するため、その後のコマンドにも変更が適用されます。
source .venv/bin/activate
プロンプトの先頭に (.venv) が付く場合があります。ターミナルは zsh を使用しています。rehash は、新しい実行ファイルのインストール後にキャッシュされたコマンドの場所を更新します。
rehash
command -v は、コマンド名によって選択される実行ファイルを表示します。
command -v ansible
/home/labex/project/.venv/bin/ansible と表示されるはずです。/usr/local/bin/ansible のような共有パスでは、プロジェクトのインストール環境が有効であることを確認できません。新しいターミナルを開いた場合は、プロジェクトに戻って再度有効化し、rehash を実行してください。
次に、実行中の Ansible のバージョンを調べます。
ansible --version
出力から次の項目を探してください。
ansible [core 2.21.5]
config file = /home/labex/project/ansible.cfg
...
ansible python module location = /home/labex/project/.venv/lib/python3.12/site-packages/ansible
executable location = /home/labex/project/.venv/bin/ansible
python version = 3.12.15 ...
...
実行ファイルとモジュールのパスから、プロジェクトにインストールしたものが実行されていることがわかります。設定ファイルは実習で用意されています。その設定方法は次の学習グループで学びます。
最後に、pip の check コマンドで、インストールされたパッケージの依存関係に互換性があるかをテストします。
.venv/bin/python -m pip check
No broken requirements found. と表示されるはずです。システムパッケージや共有ツールチェーンを変更せずに、動作するコントローラーを準備できました。
両方の管理対象ノードに接続する
このステップでは、用意されたインベントリを調べ、両方の SSH 対象に対して Python ベースの接続テストを実行します。
インベントリは、管理できるホストを Ansible に伝えます。cat はファイルの内容を表示します。用意されたプロジェクトのインベントリを読んでください。
cat inventory.ini
構造は次のとおりです。
web1 ansible_host=...
web2 ansible_host=...
[all:vars]
ansible_user=automation
ansible_ssh_private_key_file=/home/labex/.local/share/ansible-course/id_ed25519
ansible_python_interpreter=/usr/bin/python3
... の部分には実際のアドレスが入っています。既存の値を使用してください。web1 と web2 はインベントリ名で、ansible_host はそれぞれの SSH 接続先を指定します。[all:vars] は、その後の接続設定を両方のホストに適用します。automation は管理対象ノード内の一般アカウントであり、コントロールノードのログインユーザー labex とは異なります。実習では新しい練習用キーと信頼済みのホストキーが用意されています。キーの生成や SSH 設定の変更は必要ありません。
対象の Python パス /usr/bin/python3 は各管理対象ノードのものです。コントローラーのプロジェクト用 Python とは異なります。ほとんどの Ansible モジュールは、コントローラーだけでなく対象にも Python を必要とします。
用意された ansible.cfg は、プロジェクトからコマンドを実行するときにこのインベントリを選択します。all はインベントリの全ホストを選択します。--list-hosts はモジュールを実行せずに選択内容をプレビューします。
ansible all --list-hosts
次の 2 つのホスト名だけが表示されるはずです。順序は異なる場合があります。
hosts (2):
web1
web2
-m オプションは、Ansible の作業単位であるモジュールを選択します。ansible.builtin.ping は組み込み ping モジュールの完全修飾名です。SSH で接続し、各対象で Python を実行します。ネットワークの ICMP ping ではありません。
ansible all -m ansible.builtin.ping
両方のホストが、次の固定項目を含む結果を返すはずです。結果の順序は異なる場合があります。
web1 | SUCCESS => {
"changed": false,
"ping": "pong"
}
web2 | SUCCESS => {
"changed": false,
"ping": "pong"
}
pong は、そのホストで SSH 認証と対象の Python 実行が成功した証拠です。changed: false は、この接続テストが設定変更を要求しなかったことを示します。1 台の成功だけでは不十分なので、両方の名前を確認してください。UNREACHABLE は接続失敗、FAILED はタスク失敗を意味します。ホスト一覧が空の場合も、接続を確認できたことにはなりません。
コマンドが失敗した場合は、まず現在もプロジェクトディレクトリにいること、command -v ansible が .venv/bin/ansible を選択すること、用意されたインベントリに元の接続先が両方残っていることを確認してください。プラットフォームのログイン、SSH、sudo 設定は変更しないでください。
まとめ
コントローラーの分離環境を作成し、オフラインキャッシュからバージョンを固定した Ansible Core パッケージをインストールしました。プロジェクトのコマンドを有効化し、そのパスと依存関係を確認しました。用意されたインベントリを読み、異なる各 SSH 管理対象ノードから Python による pong を受け取りました。プロジェクト設定の学習に進む前に、コントローラーの Python、対象の Python、インベントリ名を区別できるようになりました。
