はじめに
AWX の Automation Mesh を構成する機能として、過去に紹介した Execution Node に加えて、Hop Node と Mesh Ingress が最近のリリースで追加されました。
関連する情報は AWX のドキュメント や AWX Operator のドキュメント にもまとまっていますが、本エントリでは Mesh Ingress を中心にこれらの新機能を簡単に紹介します。
続きを読むタグ: AWX
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 が正しいような気もしており、中の方々の意見を聞く意味も兼ねて Issue と PR を作っていますが、今のところ何ら確証はないので、本エントリでは現時点のドキュメントに従って EDA Server Operator と表記しています。
本エントリ中で利用しているファイルは、GitHub のリポジトリ にも配置しています。
追記（2023/08/12）
追記 (1)
公式のデプロイメントガイド が更新され、推奨されるデプロイ方式が Operator になりました。
追記 (2)
当初、一貫してツール名称を EDA Controller と表記していましたが、アップストリーム版は EDA Server であり、EDA Controller は Ansible Automation Platform に含まれる製品版の名称 とのこと なので、タイトルと本文を修正しました。
Operator の名称も EDA Server Operator で 正しい ようです。
続きを読む
新しい Ansible Builder 3 で Execution Environment を作る
はじめに
先日、Ansible Builder がメジャバージョンアップし、3.0.0 がリリースされました。
Ansible Builder は 本ブログでも過去に取り上げています が、設定ファイルで記述する内容に大きめの変更が入っているため、本エントリで改めて簡単に紹介します。
続きを読む
AWX で Kerberos 認証を使って Windows ホストに接続する
はじめに
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 ホストに接続する 方法を紹介します。
続きを読む
AWX Operator の 0.14.0 以降へのアップグレード
はじめに
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 以降へアップグレードする際は、不要なリソースの削除など少しだけ追加の手順が必要です。
AWX に Active Directory で認証させて組織やチームと自動で紐づける
はじめに
本エントリでは、AWX のユーザ認証のバックエンドに Active Directory を LDAP サーバとして利用する場合の構成を取り上げます。
単にログインできるようにするだけではあまり工夫のしどころがないので、もう少し踏み込んだユースケースを想定して、Active Directory 側の グループ と AWX の 組織 や チーム とのマッピングも構成します。
AWX 側の ロール と組み合わせることで、Active Directory のグループに応じた、いわゆる RBAC を実現できます。
続きを読む
Ansible Galaxy NG を Docker や Kubernetes で気軽に試す方法いろいろ
はじめに
前回 と 前々回 のエントリでは、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 を作って使う
はじめに
前回のエントリ “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 を作って使う
はじめに
Ansible Automation Platform 2.0 がアーリーアクセスで提供されはじめ、次期メジャリリースの情報が出てきました。
- Ansible Automation Platform 2.0 Early Access Homepage – Red Hat Customer Portal
- Introducing Ansible Automation Platform 2.0 Early Access – Red Hat Customer Portal
- What’s New in Ansible Automation Controller 4.0 – Red Hat Customer Portal
- What’s New in Private Automation Hub – Red Hat Customer Portal
目立つところでは、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 から利用します。
続きを読む