EDA Server を Operator でデプロイして Kubernetes 上での動作を確認する

はじめに

EDA Server のデプロイ方法として、公式のデプロイメントガイド では Docker Compose と Minikube が案内されています。

その一方で、ひっそりと EDA Server Operator が公開されています。これは、EDA Server をデプロイするための Operator です。

まだ開発中であり、前述のデプロイメントガイドに記載もないことから、完全にサポートされている手段とはまったく言えませんが、本エントリではこれを用いた EDA Server のデプロイと、その後の AWX との連携を、Kubernetes 上での EDA Server の動きを含めて簡単に紹介します。

なお、この Operator の名称は EDA Controller Operator が正しいような気もしており、中の方々の意見を聞く意味も兼ねて IssuePR を作っていますが、今のところ何ら確証はないので、本エントリでは現時点のドキュメントに従って EDA Server Operator と表記しています。

本エントリ中で利用しているファイルは、GitHub のリポジトリ にも配置しています。

追記(2023/08/12)

追記 (1)

公式のデプロイメントガイド が更新され、推奨されるデプロイ方式が Operator になりました。

追記 (2)

当初、一貫してツール名称を EDA Controller と表記していましたが、アップストリーム版は EDA Server であり、EDA Controller は Ansible Automation Platform に含まれる製品版の名称 とのこと なので、タイトルと本文を修正しました。

Operator の名称も EDA Server Operator で 正しい ようです。

続きを読む

Veeam Backup & Replication 12 の構成データベースを SQL Server から PostgreSQL に移行する

はじめに

先日リリースされた Veeam Backup & Replication 12 で、バックアップサーバの構成データベースとしてバンドルされている RDBMS が、従来の Microsoft SQL Server Express から PostgreSQL に変更 されました。新規インストール時は、デフォルトで PostgreSQL が一緒に導入されます。

If you do not prepare a database engine in advance, Veeam Backup & Replication will automatically install PostgreSQL 15.1 locally on the backup server.

Before You Begin – User Guide for VMware vSphere

SQL Server はそもそもバンドルされなくなったため、事前に自分で用意しない限り選択できません。

[For PostgreSQL] You can use an already installed PostgreSQL instance or install a new one.

[For Microsoft SQL Server] You can use an already installed Microsoft SQL Server database only.

Step 8. Specify Database Engine and Instance – User Guide for VMware vSphere

一方で、11 から 12 にアップグレードする場合は、構成データベースは SQL Server のまま変更されません。SQL Server も引き続きサポートされるため、そのままでも何ら問題はありませんが、もし PostgreSQL を使いたい場合 は、アップグレード後に自分で移行 する必要があります。

ちょうど自宅ラボに眠っている 11 の環境があり、NFR ライセンス を使って興味半分でアップグレードしたので、本エントリでは、Veeam Backup & Replication 12 の構成データベースを SQL Server から PostgreSQL に移行する流れを、ごく簡単に紹介します。

続きを読む

新しい Ansible Builder 3 で Execution Environment を作る

はじめに

先日、Ansible Builder がメジャバージョンアップし、3.0.0 がリリースされました。

Ansible Builder は 本ブログでも過去に取り上げています が、設定ファイルで記述する内容に大きめの変更が入っているため、本エントリで改めて簡単に紹介します。

続きを読む

AutoMuteUs 7.3 の新機能: データベース内のデータのダウンロード

はじめに

AutoMuteUs の 7.3 がリリースされました。このバージョンでは、AutoMuteUs のデータベース内の自ギルドに関するデータを CSV 形式でダウンロードできる機能 が追加されています。

データベース内のデータとは、簡単にいえば 戦績の集計の元ネタ です。過去の全ゲームの参加者や色や勝敗や勝因 だけでなく、各ゲームの時系列 も取得できるため、何らかの分析をしたい場合にはよい情報源にできそうです。

一方で、ダウンロードできるのは本当に データベースの中身そのもの なので、正規化された表がそのまま出力されますし、内部的な ID も ID のままで、手がかりがないと読みにくい状態です。

そこで本エントリでは、簡単にコマンドの使い方を紹介するとともに、CSV の中身の見方も簡単に説明します。

続きを読む

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

はじめに

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 の使われ方

はじめに

これまでの 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): 暗号化と認証、ファイアウォール、電子署名

はじめに

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

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

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

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

続きを読む

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

はじめに

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

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

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

続きを読む

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

はじめに

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 のリポジトリ にも配置しています。お手元で試したい方は併せてどうぞ。

続きを読む

vSphere vMotion Notifications を試す

はじめに

vSphere 8 で vSphere vMotion Notifications と呼ばれる機能が追加されました。

ざっくりとは、 vMotion に耐えられないアプリケーションが動作している VM 向け の機能で、ゲスト OS に vMotion の事前準備と事後処理を行う機会を与える ものです。ESXi は、vMotion がトリガされると対象のゲスト OS に通知し、その通知に対するゲスト OS からの応答(Acknowledgement)が返ってくるまで実際の移行処理を遅延させます。ゲスト OS 目線では、通知を受けたら必要な事前準備を行い、その後に応答を返すことで、vMotion に安全に備えられることになります。その後の移行処理の完了も別途通知を受け取れるため、事後処理も行えます。

この仕組みにより、厳しい動作要件があって vMotion に耐えられなかったアプリケーションも、vMotion を乗り越えられるようになる…… ということのようです。例えば、複数ノードでクラスタ化されているアプリケーションで、vMotion の前後でクラスタからの離脱と再参加を自動で行うようなイメージですね。

自宅に何かそういう厳しいアプリケーションがあるわけではないのですが、おもしろそうな機能なので実際に触ってみました。本エントリでは実際の設定や動作を紹介します。

続きを読む