タグ: Kubernetes

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

続きを読む

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

@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 に置いています。

続きを読む

AWX Operator による AWX のバックアップとリストア

@kurokobo コメントをする

はじめに

前回のエントリ では、AWX をほどほどの使用感でシングルノード K3s 上にホストする方法を紹介しました。

この中では、バックアップとリストアのごく簡易的な例として、PV の実体をフルバックアップする考え方や pg_dump での運用を紹介しましたが、エントリ中でも記述していた通り、AWX の 0.10.0 からは、組み込みで バックアップ と リストア の機能が追加されています。

本エントリでは、この AWX Operator によるバックアップとリストアを実践します。

続きを読む

AWX を AWX Operator でシングルノード K3s にホストする

@kurokobo 2件のコメント

やりたかったこと

AWX の 18.0 から、インストールには AWX Operator の利用、すなわち Kubernetes や OpenShift 上へのデプロイが推奨されるようになりました。それ以前のバージョンでは Docker Compose ベースのデプロイも選択肢として用意されていましたが、現在では（開発やテスト目的を除いて）非推奨になっています。

とはいえ、気軽に使いたいだけ、シングルノードの可用性で充分、などの軽めのユースケースに対しては、すでに Kubernetes を使っている環境でない限り、AWX のためだけに Kubernetes 環境を作る（そして運用していく）のも少々大袈裟で大変です。かといって、公式のインストール手順 で気軽に試せる手段として紹介されている minikube は、プロダクション用途が想定されていない開発や学習用のツールのため、AWX をもう一歩踏み込んで日常的に使っていきたい場合には、逆に少し心許ないところがあります。

そんなわけで、ふたつの選択肢の間でほどよく使えるように、

  • シングルノード で
  • 外部からもアクセス できて
  • データも永続化 できて
  • それなりに手堅く 使っていける

感じのを、K3s で作ることにしました。

続きを読む
Rapsberry Pi

冬休みの自由研究： EdgeX Foundry (7) Kubernetes 上で Fuji リリースを動かす

@kurokobo コメントをする

EdgeX Foundry 関連エントリ

EdgeX Foundry と Kubernetes

これまでの EdgeX Foundry 関連エントリでは、一貫してその動作を Docker Compose に任せていました。公式でも Docker Compose や Snaps を利用して動作させる手順が紹介されています。

が、最近よく Kubernetes（や OpenShift）を触っていることもあり、コンテナなら Kubernetes でも動かせるよね！ という気持ちになったので、やってみました。

なお、現段階では、Kubernetes 上で動作させるためのマニフェストファイルは、公式には用意されていません。また、そもそも EdgeX Foundry は HA 構成を明確にはサポートしておらず、実装上も考慮されていないようです。つまり、仮に Kubernetes で動作させられたとしても、レプリカを増やしてロードバランスするような状態での正常な動作は何の保証もないことになります。

というわけで、現状ではあくまで実験程度に捉えておくのがよいと思います。

続きを読む