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 で解決されました。詳細は最下部で紹介しています。
続きを読む
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 ホストに接続する 方法を紹介します。
続きを読む
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 以降へアップグレードする際は、不要なリソースの削除など少しだけ追加の手順が必要です。
前回 と 前々回 のエントリでは、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 に置いています。
続きを読む
AWX の 18.0 から、インストールには AWX Operator の利用、すなわち Kubernetes や OpenShift 上へのデプロイが推奨されるようになりました。それ以前のバージョンでは Docker Compose ベースのデプロイも選択肢として用意されていましたが、現在では（開発やテスト目的を除いて）非推奨になっています。
とはいえ、気軽に使いたいだけ、シングルノードの可用性で充分、などの軽めのユースケースに対しては、すでに Kubernetes を使っている環境でない限り、AWX のためだけに Kubernetes 環境を作る（そして運用していく）のも少々大袈裟で大変です。かといって、公式のインストール手順 で気軽に試せる手段として紹介されている minikube は、プロダクション用途が想定されていない開発や学習用のツールのため、AWX をもう一歩踏み込んで日常的に使っていきたい場合には、逆に少し心許ないところがあります。
そんなわけで、ふたつの選択肢の間でほどよく使えるように、
感じのを、K3s で作ることにしました。
続きを読む
OpenShift 4 では、そのクラスタの構成方法に IPI（Installer-Provisioned Infrastructure）と UPI（User-Provisioned Infrastructure） の二種類があります。
これまで、IPI をサポートするプラットフォームは AWS や Azure、GCP、RHV、vSphere などのパブリッククラウドやオンプレミスの仮想化基盤に限定されていましたが、どうやら先月末にリリースされた OpenShift 4.6 で、ベアメタル環境への IPI インストールが公式にサポートされたようです。
In 4.6, the full stack automation installation of OpenShift on bare metal is generally available.
Red Hat OpenShift 4.6 Is Now Available
これまでも、GitHub 上では ベアメタル IPI の情報は公開 されており、以前も VirtualBMC for vSphere のユースケースとしても実際に 4.5 で動作を確認済み でした。
とはいえ、せっかく公式手順に仲間入りしたので、このエントリでは、OpenShift 4.6 で公式にサポートされたベアメタル IPI インストールの方法を、改めて紹介します。ただし、BMC を積んだ物理サーバが潤沢にあるわけではないので、物理サーバは VirtualBMC for vSphere を使った vSphere 環境の仮想マシンで代替します。
なお、今回紹介する手順は OKD でなく OpenShift のものです。インストールすると Red Hat OpenShift Cluster Manager に登録され、60 日間の評価期間 が始まります。
続きを読む
いろいろあって作りました。
これを使うと、vSphere 環境上の仮想マシンを、IPMI （ipmitool など）で制御できます。
物理サーバとまったく同じプロトコルが（もちろん全部ではないですが）仮想マシンに対して使えるようになるため、単に ipmitool による手動操作だけでなく、バックエンドで IPMI を必要とする、または IPMI があれば動かせる物理サーバ向け機能も仮想環境で動作させられる 可能性がある点が大きなメリットです。
具体的には、
ipmitool での手動操作（電源制御、起動デバイスの変更）が、vSphere の仮想環境内で実際に動作させられる可能性があります。
もちろん、物理環境を完全にエミュレートできるわけではないため、完全な代替とは言えず種々の注意は要しますが、前述のものはいずれも動作確認済みです。
本エントリでは、仕組みと簡単な使い方を紹介します。
続きを読む
VMware Cloud Foundation（VCF）という、SDDC Manager で SDDC 環境全体をイイ感じに管理できる製品があり、これを（ハンズオンラボでなく）自宅で触りたくなりました。ただの趣味というか興味です。
しかし VCF は、お行儀のよい SDDC 環境をしっかりした規模で作るための製品なので、自前で構築しようと思えば、たとえ最小構成でも、256 GB のメモリと 10 TB 超の SSD と 2 つの 10 GbE の NIC を積んだサーバを 4 台用意しないといけません。また、上位ネットワークとは BGP で会話できないといけないですし、DNS サーバや DHCP サーバなど周辺にもいろいろ必要です。さらにはネットワーク構成の詳細やさまざまなオブジェクトの命名など ワークブック の 400 ちかいパラメータを決定する必要もあります。
要するに、自宅で気軽に触れる程度のものでは到底ないわけです。ネステッドで作ればハードウェア面はある程度ごまかせはするものの、周辺サーバの用意やパラメータの決定は、ちょっと触れればいいとほんのり思っているくらいのモチベーションではしんどいものがあります。
とはいえ、海外のさかんな自宅ラボ事情を考えると、自宅で触りたい勢は世界のどこかには存在しているはずで、そう思っていろいろ調べていると、VCF Lab Constructor（VLC）なるものの存在を知りました。このエントリでは、これを使ってネステッドな VCF を構築するまでの流れを紹介します。
続きを読む
これまでの EdgeX Foundry 関連エントリでは、一貫してその動作を Docker Compose に任せていました。公式でも Docker Compose や Snaps を利用して動作させる手順が紹介されています。
が、最近よく Kubernetes（や OpenShift）を触っていることもあり、コンテナなら Kubernetes でも動かせるよね！ という気持ちになったので、やってみました。
なお、現段階では、Kubernetes 上で動作させるためのマニフェストファイルは、公式には用意されていません。また、そもそも EdgeX Foundry は HA 構成を明確にはサポートしておらず、実装上も考慮されていないようです。つまり、仮に Kubernetes で動作させられたとしても、レプリカを増やしてロードバランスするような状態での正常な動作は何の保証もないことになります。
というわけで、現状ではあくまで実験程度に捉えておくのがよいと思います。
続きを読む