Azure Kubernetes Service (AKS) 上の AWX で、ジョブやインベントリの同期を実行したとき、それにおおむね 4 分から 5 分程度以上の待ち時間 を要するタスクが含まれると、ジョブが失敗してしまうことがあるようです。
AWX の Issue として報告されている事象 で、もろもろ調べたり試したりした結果、なんやかんやで現時点では わりとダーティハック感の強いワークアラウンド しかなさそうな気配があったため、簡単に紹介です。
例えば、次のような シンプル極まりないプレイブック を動かすだけでも、AKS 上の AWX では 途中で失敗 してしまうことがあります。
---
- hosts: localhost
gather_facts: false
tasks:
- ansible.builtin.pause:
minutes: 10
Ansible で Windows ホストに対してプレイブックを実行したい場合、典型的にはホストへの接続には WinRM を利用します。この際、対象の Windows ホストに そのホストのローカルユーザで認証 する場合は、特別な工夫をしなくてもユーザ名とパスワードを使った Basic 認証や CredSSP 認証が利用できます。
一方で、対象の Windows ホストが Windows ドメインに参加していて、Ansible から ドメインユーザ で認証したい場合、WinRM の接続には Kerberos 認証 が推奨されており、そのためにはあらかじめ Ansible の実行ホストで Kerberos クライアントが正しく構成されている必要があります。
Ansible を ansible-playbook で直接実行する場合はそこまでハードルは高くないですが、AWX で実行するジョブで Kerberos 認証を使いたい 場合は、わりと混乱しがちです。Ansible Automation Controller のドキュメント に手順があるものの、あくまで AAC 用であって AWX には適合しない ものです。
本エントリでは、AWX で Kerberos 認証を使って Windows ホストに接続する 方法を紹介します。
続きを読む
oVirt で VM のクローンを作成したいとき、GUI ではメニュから何も気にせず実行できます。
一方で、これを Ansible から実行しようとしても、oVirt の VM を管理するときに利用する ovirt.ovirt.ovirt_vm モジュール では実現は難しいようです。クローンに類する操作は次の二種のみしか対応していなさげでした。
実行したいのは、既存の VM からの Ansible を使ったダイレクトなクローン作成です。本エントリでは、これを API を直接叩いてがんばってどうにかする実装例を紹介します。
oVirt 4.4 でテスト済みです。RHV でも動きそうな気はしますが未テストです。AWX での利用を想定していますが、ansible-playbook でも動作します。
vSphere 7 から、vSphere 環境のライフサイクル管理を担う vLCM が登場し、ESXi のパッケージ構成が ベースイメージ に アドオン や コンポーネント を追加する考え方に変わりました。
PowerCLI でも、2020 年 4 月にリリースされた 12.0 から、この考え方に基づいてカスタム ISO ファイルの作成が行えるよう、New-IsoImage など Image Builder 関連の新しいコマンドレットが追加されています。カーネルオプションも含められる ので、慣れるととても便利です。
使い方は vSphere 7.0 のドキュメント や VCF のドキュメント に充分書いてありますし、リファレンスもあります が、本エントリでは、ドキュメントに書かれていないところを補足しつつ、改めて紹介します。
なお、実際に使う場合は、バグが修正されている PowerCLI 12.5 以降（VMware.ImageBuilder 7.0.3 以降）を推奨します。また、現状、PowerShell Core（OSS 版の PowerShell、現 PowerShell 7）では動作しない ため、Windows にバンドルされている Windows PowerShell を使う必要 があります。
続きを読む
0.13.0 までの AWX Operator は、Kubernetes の クラスタスコープ で動作していました。default ネームスペースに AWX Operator がただ一つ存在していて、同じクラスタ内であればネームスペースを問わず AWX リソースを管理できる状態です。AWX Operator の 0.14.0 では、これが ネームスペーススコープ に変更されています。すなわち、AWX Operator 自身が存在しているネームスペース内でしか AWX リソースを管理できません。
また、AWX Operator のデプロイ方法も、GitHub 上のマニフェストファイルを kubectl apply する従来の方法から、0.14.0 では make を使った方法に変更 されています。
従来、AWX Operator をアップグレードしたい場合（すなわち AWX をアップグレードしたい場合）、AWX リソースのパラメータに互換性がある範囲であれば、単に新しいバージョンのマニフェストファイルを kubectl apply すれば充分でした。しかしながら、前述の変更を踏まると、0.13.0 以前から 0.14.0 以降へアップグレードする際は、不要なリソースの削除など少しだけ追加の手順が必要です。
community.windows コレクション の現時点で最新の 1.6.0 には、グループやユーザの管理の機能はありますが、それらが所属する Organizational Unit（OU）自体の管理の機能が含まれません。
Ansible で Active Directory の OU そのものの作成や変更・削除を行うには、PowerShell DSC の ActiveDirectoryDsc モジュール に含まれる ADOrganizationalUnit リソース を ansible.windows.win_dsc モジュールで呼び出すことで実現できます。
前回 と 前々回 のエントリでは、Ansible AWX 周辺の最近の機能として、Execution Environment や、さらにその周辺の Ansible Runner、Ansible Builder の OSS 版での動きを追いかけました。今回は、Private Automation Hub のアップストリーム版である Ansible Galaxy NG の周辺を見ていきます。
が、現時点でサポートされている構成はホスト OS への直接のインストールのみで、開発用には Docker Compose ベースの手順もあるものの、いずれにせよ総じて取り回しが少々不自由です。そんなわけで本エントリでは、現時点で気軽に Galaxy NG を試せる方法 として、次の 3 パタンでの実装手順 と、簡単な動作確認 を取り扱います。
なお、いずれも Galaxy NG のドキュメントには記載がない 方法であり、当然ながら 正式にサポートされる手順ではない 点は注意が必要です。このエントリは 実験レポート程度 に捉え、検証や勉強やテスト など 試用を目的としたユースケースに限定 して遊ぶとよいでしょう。
とはいえ、自製の Collection の表示のテスト など特定用途ではなかなか便利そうです。最初の Docker パタンなら、慣れれば 10 秒で完成 します。
今回も、必要なファイルは GitHub に置いています。
続きを読む
