カテゴリー: Ansible

Receptor (5)： AWX で Hop Node 込みの Automation Mesh を強引に構成する

@kurokobo コメントをする

はじめに

Ansible Automation Platform（AAP）の Automation Mesh では、Execution Node と Hop Node を含んだ複雑なメッシュネットワークを構成できます。一方で AWX では、Kubernetes を使ったデプロイの場合、Hop Node を利用できないため、構成できるトポロジはスター型がせいぜいです。

とはいえ、前回のエントリ で確認したとおり、Hop Node は単なる Receptor のノード にすぎません。また、Kubernetes ではなく Docker Compose を使った開発用の構成 であれば Hop Node を含んだデプロイも行えることからもわかるように、Hop Node を扱う機能自体は内包されています。

そこで本エントリでは、Kuberentes 上の AWX で、Hop Node を含んだマルチホップの Automation Mesh を構築 します。技術的には Hop Node を Windows で構成する ことも可能です。

なお、紹介している内容は公式にはサポートされていない強引なハック なので、真似する場合は自己責任でお願いします。本当は、素直に Hop Node が公式にサポートされるまで待つほうが賢明 です。

続きを読む

Receptor (4)： AWX と Automation Mesh での Receptor の使われ方

@kurokobo コメントをする

はじめに

これまでの Receptor 関連のエントリ（[1]、[2]、[3]）では、Receptor 単体に注目して、その動作を紹介してきました。

今回は、Receptor のユースケースひとつとして、AWX での Receptor の使われ方 を、共に使われている Ansible Runner の動作と共に紹介します。併せて、Automation Mesh にも触れます。

AWX は、ジョブの実行、プロジェクトやインベントリの更新など、いくつもの処理を内部では Receptor のワークとして実行 しています。

ともすれば単なるオーバヘッドにも思えてしまうこの実装ですが、見方を変えれば、あえて Receptor を介して処理する実装 にすることで、メッシュネットワークを拡張しさえすればどのノードにもそれをオフロードできる ようになっているとも言えます。

そして、AWX における Execution Node が、まさにその例のひとつです。詳細は本エントリで紹介しますが、技術的には Execution Node は Receptor の Executor そのものです。すなわち、AWX が参加しているメッシュネットワーク に Executor を追加して、ワーク（≒ AWX のジョブ）の送信先を変更可能に する機能と解釈できます。

さらにこれが Ansible Automation Platform（AAP）では Automation Mesh として拡張され、Execution Node に加えて Hop Node も利用できるようになります。そしてこれも、技術的には AAP が参加する Receptor のメッシュネットワーク を ユーザが任意のノードで任意の構成にできる ようにして、ワークを任意の Executor に送れる ようにしたものです。

続きを読む

Receptor (3)： 暗号化と認証、ファイアウォール、電子署名

@kurokobo コメントをする

はじめに

これまでのエントリ（前々回、前回）では、Receptor の基本的な動きと、Kubernetes との連携を紹介しました。

本エントリでは、Receptor の持つ以下のセキュリティ関連の機能を取り扱います。

  • 接続できるピアの制限
  • TLS による暗号化と認証
  • ファイアウォール
  • ワークの電子署名

必要なファイルは、これまで通り GitHub のリポジトリに配置 しています。

続きを読む

Receptor (2)： Kubernetes 上でのワークの実行

@kurokobo コメントをする

はじめに

前回のエントリ では、Receptor によるメッシュネットワークの構成と、メッシュネットワークを介したリモートノードでのコマンド実行、障害からの回復性を紹介しました。

本エントリでは、リモートノードで何らかの処理をさせるもう一つの手段である、Kubernetes クラスタ上でのワークの実行（Kubernetes ワーク）を紹介します。

この機能を利用すると、Receptor の Executor ノード から 任意の Kubernetes クラスタに任意の構成の Pod を作成 できます。Pod で利用するイメージ、そこで実行する コマンドと引数 だけでなく、Pod 自体もカスタマイズでき ます。また、前回のエントリ で紹介したリモートノードでのコマンド実行と同様、任意のペイロードをコマンドの標準入力に渡す ことも引き続き可能なため、非常に柔軟な処理を行えます。

続きを読む

Receptor (1)： Receptor はじめの一歩

@kurokobo コメントをする

はじめに

Ansible Automation Platform（AAP）には、その構成の柔軟性を飛躍的に向上させる Automation Mesh と呼ばれる仕組みがあります。AWX でも Execution Node がサポートされ、より近しいことができるようになってきました（詳細は 別のエントリ で紹介しています）。

この Automation Mesh の中核 とも呼べる技術が、Receptor です。本エントリではこの Receptor を理解するはじめの一歩として、概要と基本的な使い方と動きを確認します。

Receptor は、Ansible 関連のプロジェクトではありますが、ざっくりとは 任意のコマンドをリモートノードで実行する仕組み であり、本来は Ansible とはまったく関係なく単体でも利用できる モノです。そのため本エントリでは、Automation Mesh や AWX、Ansible Runner などの Ansible 周辺との関係はいったん忘れて、まずは あくまで Receptor 単体に着目 します。

なお、エントリ中で紹介する設定ファイル類やそれを実際に動作させられる Docker 用の Compse ファイルは、GitHub のリポジトリ にも配置しています。お手元で試したい方は併せてどうぞ。

続きを読む

AWX に Kubernetes クラスタ外のスタンドアロン実行ノードを追加する

@kurokobo 3件のコメント

はじめに

AWX の 21.7.0 から、Execution Node（実行ノード）がサポートされました。これにより、AWX が動作する Kubernetes クラスタの 外 の 独立したホスト に、ジョブの実処理を任せられる ようになります。

構築方法のドキュメント も提供されており、これが親切なので愚直に従えば動くところまで比較的簡単に持っていけますが、本エントリでは、概要や構成方法、使い方を、実装面を少し紐解きつつ紹介します。

続きを読む

AKS 上の AWX で実行時間の長いジョブが失敗するときの対処

@kurokobo コメントをする

はじめに

Azure Kubernetes Service (AKS) 上の AWX で、ジョブやインベントリの同期を実行したとき、それにおおむね 4 分から 5 分程度以上の待ち時間 を要するタスクが含まれると、ジョブが失敗してしまうことがあるようです。

AWX の Issue として報告されている事象 で、もろもろ調べたり試したりした結果、なんやかんやで現時点では わりとダーティハック感の強いワークアラウンド しかなさそうな気配があったため、簡単に紹介です。

例えば、次のような シンプル極まりないプレイブック を動かすだけでも、AKS 上の AWX では 途中で失敗 してしまうことがあります。

---
- hosts: localhost
  gather_facts: false

  tasks:
    - ansible.builtin.pause:
        minutes: 10

追記： この問題は AWX 21.14.0 で解決されました。詳細は最下部で紹介しています。

続きを読む

AWX で Kerberos 認証を使って Windows ホストに接続する

@kurokobo コメントをする

はじめに

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 のクローンを Ansible で作成する

@kurokobo コメントをする

背景

oVirt で VM のクローンを作成したいとき、GUI ではメニュから何も気にせず実行できます。

一方で、これを Ansible から実行しようとしても、oVirt の VM を管理するときに利用する ovirt.ovirt.ovirt_vm モジュール では実現は難しいようです。クローンに類する操作は次の二種のみしか対応していなさげでした。

  • テンプレートからの仮想マシンの作成
  • 他の VM のスナップショットからの仮想マシンの作成

実行したいのは、既存の VM からの Ansible を使ったダイレクトなクローン作成です。本エントリでは、これを API を直接叩いてがんばってどうにかする実装例を紹介します。

oVirt 4.4 でテスト済みです。RHV でも動きそうな気はしますが未テストです。AWX での利用を想定していますが、ansible-playbook でも動作します。

続きを読む

AWX Operator の 0.14.0 以降へのアップグレード

@kurokobo 2件のコメント

はじめに

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 以降へアップグレードする際は、不要なリソースの削除など少しだけ追加の手順が必要です。

続きを読む