プログラミング | kurokobo.com

Virtual Infrastructure JSON API（VI/JSON API）の触り方

2024 年 3 月 9 日2024 年 3 月 9 日 @kurokobo コメントをする

はじめに

前回のエントリで、vSphere に古くから実装されている API である vSphere Web Services API（SOAP API）の触り方を紹介しました。その中で、Virtual Infrastructure JSON API にひとことだけ触れています。

SOAP API を（広義の）REST API のように触れる Virtual Infrastructure JSON API も vCenter Server 8.0 U1 以降が必要で、まだまだ一般的ではありません。
vSphere Web Services API（SOAP API）の触り方 | kurokobo.com

Virtual Infrastructure JSON API（VI/JSON API）は、vCenter Server 8.0 U1 で追加された新しい API で、ひとことで雑に表現するなら、従来の SOAP API の REST API 版 です。

本エントリでは、まだ日本語ではほとんど情報がないこの新しい API について、実例とともに簡単に紹介します。

なお、vSphere の REST API といえば vSphere Automation API が一般的ですが、VI/JSON API はこれとはまったく別物 です。

vSphere Web Services API（SOAP API）の触り方

2024 年 3 月 7 日2024 年 3 月 8 日 @kurokobo コメントをする

はじめに

vSphere 環境をコマンドライン環境や何らかのスクリプトから操作するとき、典型的には PowerCLI や govmomi、pyVmomi、VMware vSphere Automation SDK などのツールがよく利用されますが、こうしたツールを使わずに API を直接触れる と、vSphere に実装された新機能をリリースと同時に使い始められ てたいへん便利です。実際、vSphere vMotion Notifications がリリースされたときも、ツールが更新されるまでは、API を直接触る以外にそれを試す手段がありませんでした。

vSphere の API には、古くからある SOAP API（vSphere Web Services API）と新しい REST API（vSphere Automation API）の大きく二つがあります。操作が簡単なのは間違いなく REST API ですが、SOAP API でしか行えない操作もたくさんあり、また、SOAP API を（広義の）REST API のように触れる Virtual Infrastructure JSON API も vCenter Server 8.0 U1 以降が必要で、まだまだ一般的ではありません。

したがって現状では、昔ながらの SOAP API こそ が、極論、大抵のことはどうにかできる API であると言えます。そこでこのエントリでは、SOAP API（vSphere Web Services API）を直接触る方法 を実例と共に紹介します。

なお、コマンド例は curl と PowerShell で紹介 していますが、結局は HTTP で XML をやりとりするだけなので、お作法さえわかれば他の HTTP クライアントでももちろん利用できます。また、SOAP API は Managed Object Browser（MOB）でも操作できますが、Web ブラウザでの操作であり自動化には向かないため、今回は取り上げません。

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

2022 年 7 月 5 日2022 年 8 月 13 日 @kurokobo コメントをする

はじめに

Ansible で Windows ホストに対してプレイブックを実行したい場合、典型的にはホストへの接続には WinRM を利用します。この際、対象の Windows ホストに そのホストのローカルユーザで認証 する場合は、特別な工夫をしなくてもユーザ名とパスワードを使った Basic 認証や CredSSP 認証が利用できます。

一方で、対象の Windows ホストが Windows ドメインに参加していて、Ansible から ドメインユーザ で認証したい場合、WinRM の接続には Kerberos 認証 が推奨されており、そのためにはあらかじめ Ansible の実行ホストで Kerberos クライアントが正しく構成されている必要があります。

Windows Remote Management – Kerberos

Ansible を ansible-playbook で直接実行する場合はそこまでハードルは高くないですが、AWX で実行するジョブで Kerberos 認証を使いたい 場合は、わりと混乱しがちです。Ansible Automation Controller のドキュメントに手順があるものの、あくまで AAC 用であって AWX には適合しない ものです。

本エントリでは、AWX で Kerberos 認証を使って Windows ホストに接続する 方法を紹介します。

AutoMuteUs 7.0 のリリース：スラッシュコマンド対応などいろいろ

2022 年 3 月 31 日2023 年 1 月 14 日 @kurokobo コメントをする

AutoMuteUs が 7.0 にメジャアップデートされ、操作方法が .au やメンション から スラッシュコマンド に変更されました。これによって操作感が大きく変わり、またセルフホストでは関連するオプションがいくつか追加されています。

本エントリでは、公式ボットサービスの利用者 と セルフホストの利用者 の双方を対象に、簡単に変更点とその概要、使い方を紹介します。

Ansible で Active Directory に Organizational Unit（OU）を作る

2021 年 8 月 29 日2021 年 8 月 29 日 @kurokobo コメントをする

community.windows コレクションの現時点で最新の 1.6.0 には、グループやユーザの管理の機能はありますが、それらが所属する Organizational Unit（OU）自体の管理の機能が含まれません。

Ansible で Active Directory の OU そのものの作成や変更・削除を行うには、PowerShell DSC の ActiveDirectoryDsc モジュールに含まれる ADOrganizationalUnit リソースを ansible.windows.win_dsc モジュールで呼び出すことで実現できます。

Ansible Galaxy NG を Docker や Kubernetes で気軽に試す方法いろいろ

2021 年 7 月 25 日2021 年 7 月 27 日 @kurokobo コメントをする

はじめに

前回と前々回のエントリでは、Ansible AWX 周辺の最近の機能として、Execution Environment や、さらにその周辺の Ansible Runner、Ansible Builder の OSS 版での動きを追いかけました。今回は、Private Automation Hub のアップストリーム版である Ansible Galaxy NG の周辺を見ていきます。

が、現時点でサポートされている構成はホスト OS への直接のインストールのみで、開発用には Docker Compose ベースの手順もあるものの、いずれにせよ総じて取り回しが少々不自由です。そんなわけで本エントリでは、現時点で気軽に Galaxy NG を試せる方法 として、次の 3 パタンでの実装手順 と、簡単な動作確認 を取り扱います。

なお、いずれも Galaxy NG のドキュメントには記載がない 方法であり、当然ながら 正式にサポートされる手順ではない 点は注意が必要です。このエントリは 実験レポート程度 に捉え、検証や勉強やテスト など 試用を目的としたユースケースに限定 して遊ぶとよいでしょう。

Docker で全部入りコンテナを使うパタン
- おそらくもっとも手軽な Galaxy NG の入手方法
- すべてが一つに詰め込まれた既成コンテナイメージを動かすだけ
Kubernetes で全部入りコンテナを使うパタン
- 前述の Docker パタンを愚直に Kubernetes 上に移植したもの
- プラットフォームを Kubernetes に揃えたいならいちばん気軽
Kubernetes で Pulp Operator を使うパタン
- おそらく将来的に正式な Kubernetes 上へのデプロイ方法になる気がしているパタン
- マイクロサービス化されてスケールもできる状態できちんとしたモノができあがる
- まだまだ開発途上の様子（動かせはする）

とはいえ、自製の Collection の表示のテスト など特定用途ではなかなか便利そうです。最初の Docker パタンなら、慣れれば 10 秒で完成 します。

今回も、必要なファイルは GitHub に置いています。

Ansible AWX で Execution Environment と Container Group を作って使う

2021 年 7 月 22 日2021 年 7 月 26 日 @kurokobo 5件のコメント

はじめに

前回のエントリ “Ansible Runner と Ansible Builder で Execution Environment を作って使う” では、AWX で Execution Environment を使うための前段として、Ansible Runner と Ansible Builder の動作を確認しました。

このエントリでは、その続きとして、作成した Execution Environment を実際に AWX から利用する流れを確認します。また、Container Group を作成して、Pod の構成をカスタマイズします。

Ansible Runner と Ansible Builder で Execution Environment を作って使う

2021 年 7 月 19 日2021 年 7 月 22 日 @kurokobo コメントをする

はじめに

Ansible Automation Platform 2.0 がアーリーアクセスで提供されはじめ、次期メジャリリースの情報が出てきました。

目立つところでは、Ansible Tower が Ansible Automation Controller に改名されていますが、アーキテクチャ面でも、制御プレーンと実行プレーンを疎結合にするために Execution Environment（EE）の概念が新たに登場しています。

従来、プレイブックに応じて Python のモジュールや Collection を使い分けたい場合、典型的には Python の仮想環境を用いた環境の分離を行っていました。Execution Environment（EE）は、平たくいえばこれを コンテナに置き換えるもの であり、Ansible のランタイムをコンテナ化したもの と言えそうです。必ずしも Tower（AWX）と組み合わせなくても使えますが、Tower（AWX）目線でも、本体のインスタンスと実行環境が分離されるので、スケールもしやすくなりそうです。

本エントリでは、AWX での Execution Environment（EE）の動きを確かめるための準備として、Ansible Runner と Ansible Builder の動作を確認します。次のエントリでは、本エントリで作成した自前の Execution Environment（EE）を実際に AWX から利用します。