どうも、Tです。
AWXのデプロイ手順を確認できたので備忘録です。
前置きがかなり長いので、インストールだけしたい方は「Oracle Linux9準備」から読んでください。
目次
AWXとは
AWXは、AnsibleをWebブラウザやAPIで管理・実行するためのオープンソースツールです。
商用版として、Ansible Automation Platform(旧Ansible Tower。以下AAPと記載します)があり、AWXは、AAP のアップストリーム(厳密にはAAPの一部の機能相当)の位置づけになっています。
AWXとAAPの比較は、他のサイトでいろいろと解説されているのでこちらでは説明を割愛します。
2025年7月現在は、Red Hat Developer Programに登録すれば、AAPも使えるようになっているようでしたが、管理するノードの台数制限がありそうだったので、AWXを利用することにしました。
この件については、redditでも以下のような議論がされています。
ここで記載した手順も今後使えなくなる可能性があります。
経緯
検証環境で仮想マシンやら色々作るのですが、設定変更やら冪等性の確保が手動で続けるには結構負荷が高くなってきたので、構成管理ツールとしてAnsibleを使いたいなぁと思ったのですが、それをコマンド操作するのも億劫だったのでWeb画面で操作・管理できるようにAWXを使おうと思い立ちました。
最初はdnfコマンドとかでパッケージをインストールするだけと思って調べていたら、ちょっとやそっとで動かない感じだったのでちゃんとまとめることにしました。
- ネットの情報によって手順がバラバラ
- バージョンによって手順が違う
- 公式リファレンスがわかりにくく手順通りにやってもインストールできない
- AWXというよりインストール構成を把握できないと何をしているかわらない
上記のような問題があり、これが一番正解！というものは見つからなかったので、本記事も私の備忘録向きになっています。ただ、可能な限り公式の手順に沿う形で要所をまとめているので、参考にいただけると幸いです。
前提
後述しますが、AWXはKubernetes（K8s）またはOpenShiftが必要になります。私はどちらも深い理解もなく、やれることが多すぎるので本記事は下記のような指針で作成しています。
- 極力公式リファレンスを参考にする
- シングルノード、シングルクラスタで簡易な構成にする
- ローカル利用のためセキュリティ面は考慮しない（簡易性優先）
- データの永続性・バックアップも考慮しない（簡易性を優先。仮想マシンバックアップしておけば大丈夫だろう）
インストールに必要なこと
「AWXをインストールしたい！」だけなのですが、インストールするための前提がやや難易度が高いです。簡単にまとめると…
- AWXのインストールには、AWXのライフサイクル管理・運用にAWX Operatorが必要になる（AWX バージョン18.0以降）！
- AWX OperatorはK8sクラスターにデプロイする必要がある！
- K8sクラスタ環境がないとそもそも始まらない！
Dockerなどにインストールすることもできたようですが、現在は推奨されておらず手順もちゃんとしたものがなさそうなので、K8sクラスタを利用するにしました。
一応、調べた内容を残しておきます。基本的に英語だったので、筆者訳の日本語も併記します。
AWXのインストール手順には下記の情報がありました。
https://github.com/ansible/awx/blob/devel/INSTALL.md
AWX can also alternatively be installed and run in Docker, but this install path is only recommended for development/test-oriented deployments, and has no official published release.
バージョン18.0以降、AWXのインストールにはAWX Operatorの使用が推奨されます。AWX Operatorのドキュメントをご覧ください。
AWXはDockerでもインストールして実行できますが、このインストール方法は開発/テスト指向のデプロイメントにのみ推奨され、公式リリースは公開されていません。
AWX Operatorについては、下記の記載があります。
https://github.com/ansible/awx-operator
An Ansible AWX operator for Kubernetes built with Operator SDK and Ansible.
The AWX Operator is meant to be deployed in your Kubernetes cluster(s) and can be used to install and manage the lifecycle of an AWX instance in the same namespace.
Operator SDK と Ansible を使用して構築された、Kubernetes 用の Ansible AWX オペレーターです。
AWX オペレーターは Kubernetes クラスターにデプロイされ、同じ名前空間内の AWX インスタンスのインストールとライフサイクル管理に使用できます。
AWXだけのためにK8sの準備は大変です。AWXのドキュメントにはMinikubeを利用し手順がありますが、あくまでテスト用という位置づけです。
本手順では、K8s環境準備を簡易するためK3sを利用することにしました。
If you do not have an existing cluster, the awx-operator can be deployed on a Minikube cluster for testing purposes. Due to different OS and hardware environments, please refer to the official Minikube documentation for further information.
既存のクラスターをお持ちでない場合は、awx-operator を Minikube クラスターにデプロイしてテストすることができます。OS やハードウェア環境によって動作が異なるため、詳細については Minikube の公式ドキュメントを参照してください。
構成
全体像
AWXをデプロイした際の全体像になります。
このあたりをわかっていないと、インストールで何をしているのかわけがわからなくなったので参考にしてください。
赤文字の「k-awx」の部分はインストール時に任意の文字列に指定可能です。
詳細は、のちほど説明していきます。
環境
本手順でインストールできた環境バージョンを記載しておきます。バージョンによっては、インストールできない場合もあるようだったので参考まで。
OSがOracle Linuxなのは、最近RHELから乗り換えしているので気にしないでください。RHEL互換であれば、本手順通りにできると思います。
OS(Proxmoxの仮想マシン)
Oracle Linux 9.6（6.12.0-1.23.3.2.el9uek.x86_64）
K3s
# k3s --version k3s version v1.32.6+k3s1 (eb603acd) go version go1.23.10
AWX Operator
2.19.0
AWX
24.6.1
K3sについて
K8sを準備するのは大変そうなので、K3sを利用することにしました。
K8sの代替として他にもありますが、下記の理由でやめました。
- minikube：テスト・学習を目的にしているため不安がある。
- MicroK8s：本番利用も想定されているが、Snapパッケージに依存しているようでRHEL系で利用する上で不安がある。
- K0s：仕様変更が多そうで、かつ情報が少ないように見受けられたため。
K3sは以下の点で安心感がありました。
- 簡易なインストール方法である
- 本番利用を想定している
- K8sの基本的な機能を提供している
- ディストリビューション依存なく使えそう
- 利用者・情報が多い
Googleトレンドで検索してみたところ、K3sが盛り上がってきているようでした。
日本では、突出した差はなさそうですが、K3sが盛り上がってきているような雰囲気があります。
K3s用語
手順を進めるうえで必要となる基本的なK3sの用語になります。K8sでも同じですが、ここからはK3sで統一して記載します。
知らなくても手順通りに進めば動作はすると思いますが、よく知らなかったので必要そうな用語をまとめました。
| 用語 | 説明 |
|---|---|
| コンテナ | アプリケーションやミドルウェアを独立させた環境。 |
| Pod | コンテナの集合体。1つ以上のコンテナで構成されたグループのようなもので、アプリケーションを実行する最小単位となる。 |
| Service | Pod（内部のコンテナ）実行されているアプリケーションを公開する方法。
AWXのWeb管理画面に接続に、Webサービスを公開する必要があるため、抑えておくと理解しやすい。 |
| Namespace | K3s環境内で管理するリソースに名前を付けたグループのようなもので、Namespace間は空間を分離し環境を分けることができる。
AWXの導入では、Namespaceは「awx」となる。 |
AWX Operatorについて
AWX Operatorをデプロイすると下記のPodとコンテナが出来上がります。
| Pod | コンテナ | 説明 |
|---|---|---|
| awx-operator-controller-manager | kube-rbac-proxy | AWX Operator。
rbcaとはRole Based Access Controlの略。 |
| awx-manager |
AWXについて
AWXをデプロイすると下記のPodとコンテナが出来上がります。
| Pod | コンテナ | 説明 |
|---|---|---|
| k-awx-web | redis | Web UI・API提供。
ユーザーがブラウザでアクセスする AWXのWebインターフェースやREST API を提供。 |
| k-awx-web | ||
| k-awx-rsyslog | ||
| k-awx-task | redis | タスク実行・スケジューラ。
ジョブの実行、Playbookの処理、非同期タスク、バックグラウンド処理を担当。 |
| awx-task | ||
| awx-ee | ||
| awx-rsyslog | ||
| k-awx-postgres | postgres | AWXの構成・ジョブ履歴・認証情報などを保存する PostgreSQL データベース。 |
| k-awx-migration | migration-job | データベースの初期化やマイグレーション（テーブル作成・更新）を行う一時的なPod。通常は初回起動時やアップグレード時にのみ起動。 |
Oracle Linux9準備
一番の基盤となるOSの準備をしておきます。ここは簡単に必須の設定のみ説明します。
なお、OSインストール後の手順では、すべてrootユーザーで操作しています。
Oracle Linux9インストール
Oracle Linux9を最小パッケージ構成でインストールします。
SELinux無効
下記でSELinuxを無効にし、設定反映のため再起動します。
# grubby --update-kernel ALL --args selinux=0 # shutdown -r now
SELinuxが無効になっていることを確認します。
# getenforce Disabled
Firewalld無効
ファイアウォールを停止、自動起動無効にしステータスを確認します。
# systemctl stop firewalld # systemctl disable firewalld # systemctl status firewalld
K3sインストール
下記を参考にK3sインストールします。
下記の環境変数を設定しSELinux関連のパッケージがインストールされないようにします。
# export INSTALL_K3S_SKIP_SELINUX_RPM=true
デフォルトでインストールを進めるとSELinux関連のパッケージをインストールするよう促されますが、実行するとエラーでインストールできませんでした。
[ERROR] Failed to apply container_runtime_exec_t to /usr/local/bin/k3s, please install: dnf install -y container-selinux dnf install -y https://rpm.rancher.io/k3s/stable/common/centos/9/noarch/
↓
# dnf install -y https://rpm.rancher.io/k3s/stable/common/centos/9/noarch/ メタデータの期限切れの最終確認: 0:01:26 前の 2025年07月08日 12時25分45秒 に実施しました。 [MIRROR] : Status code: 404 for https://rpm.rancher.io/k3s/stable/common/centos/9/noarch/ (IP: 104.26.1.8) [MIRROR] : Status code: 404 for https://rpm.rancher.io/k3s/stable/common/centos/9/noarch/ (IP: 104.26.1.8) [MIRROR] : Status code: 404 for https://rpm.rancher.io/k3s/stable/common/centos/9/noarch/ (IP: 104.26.1.8) [MIRROR] : Status code: 404 for https://rpm.rancher.io/k3s/stable/common/centos/9/noarch/ (IP: 104.26.1.8) [FAILED] : Status code: 404 for https://rpm.rancher.io/k3s/stable/common/centos/9/noarch/ (IP: 104.26.1.8) Status code: 404 for https://rpm.rancher.io/k3s/stable/common/centos/9/noarch/ (IP: 104.26.1.8)
K3sをインストールします。
# curl -sfL https://get.k3s.io | K3S_KUBECONFIG_MODE="644" sh -s
「K3S_KUBECONFIG_MODE=”644″」を指定することで、rootユーザー以外でもkubectlコマンドを実行できるようになります。
上記オプションなしでインストール後、rootユーザー以外でkubectlコマンドを実行しようとすると下記のエラーがでます。
$ kubectl get nodes WARN[0000] Unable to read /etc/rancher/k3s/k3s.yaml, please start server with --write-kubeconfig-mode or --write-kubeconfig-group to modify kube config permissions error: error loading config file "/etc/rancher/k3s/k3s.yaml": open /etc/rancher/k3s/k3s.yaml: permission denied
K3sが起動していることを確認します。（デフォルトで自動起動は有効になります）
# systemctl status k3s
● k3s.service - Lightweight Kubernetes
Loaded: loaded (/etc/systemd/system/k3s.service; enabled; preset: disabled)
Active: active (running) since Fri 2025-07-11 21:14:21 JST; 25s ago
Docs: https://k3s.io
Process: 1588 ExecStartPre=/bin/sh -xc ! /usr/bin/systemctl is-enabled --quiet nm-cloud-setup.service 2>/dev/null (code=exited, status=0/SUCCESS)
Process: 1590 ExecStartPre=/sbin/modprobe br_netfilter (code=exited, status=0/SUCCESS)
Process: 1591 ExecStartPre=/sbin/modprobe overlay (code=exited, status=0/SUCCESS)
Main PID: 1593 (k3s-server)
Tasks: 88
Memory: 1.1G
CPU: 22.364s
CGroup: /system.slice/k3s.service
├─1593 "/usr/local/bin/k3s server"
├─1614 "containerd "
├─2302 /var/lib/rancher/k3s/data/ceeaba2f9b0f267030e653da2b0935920a5b3e3dab1a7bda986bb98e2c9d3381/bin/containerd-shim-runc-v2 -namespace k8s.io -id 60a4bfd9cfbbd07988b6774bf0d1475d6e8>
├─2304 /var/lib/rancher/k3s/data/ceeaba2f9b0f267030e653da2b0935920a5b3e3dab1a7bda986bb98e2c9d3381/bin/containerd-shim-runc-v2 -namespace k8s.io -id e73cff6cbefc7a222cecf6de4b97513f488>
├─2353 /var/lib/rancher/k3s/data/ceeaba2f9b0f267030e653da2b0935920a5b3e3dab1a7bda986bb98e2c9d3381/bin/containerd-shim-runc-v2 -namespace k8s.io -id e2a4c5812e2059cf1c289c9136978ac03ac>
├─2641 /var/lib/rancher/k3s/data/ceeaba2f9b0f267030e653da2b0935920a5b3e3dab1a7bda986bb98e2c9d3381/bin/containerd-shim-runc-v2 -namespace k8s.io -id 4fe14993560bb10a869455628c4860d6332>
└─2676 /var/lib/rancher/k3s/data/ceeaba2f9b0f267030e653da2b0935920a5b3e3dab1a7bda986bb98e2c9d3381/bin/containerd-shim-runc-v2 -namespace k8s.io -id b03aed7932bb5f72771f7cc86af59369bb2>
下記のファイルパーミッションが644であることを確認します。
# ls -lha /etc/rancher/k3s/k3s.yaml -rw-r--r-- 1 root root 2.9K 7月 11 21:14 /etc/rancher/k3s/k3s.yaml
ノードのステータスがReadyであることを確認します。なお、ここのNAMEは、OSのホスト名です。
# kubectl get nodes NAME STATUS ROLES AGE VERSION k-awx Ready control-plane,master 2m38s v1.32.6+k3s1
AWX Operatorデプロイ
下記の手順を参考にAWX Operatorをデプロイします。
AWX Operatorのでデプロイに必要なコマンドがあるのでパッケージをインストールします。
# dnf install git make tar
GithubからAWX Operatorgitのリポジトリをクローンするためクローン用のディレクトリを作成します。ディレクトリ名は任意の名前でかまいません。
# mkdir -p /root/github.com # cd /root/github.com
AWX Operatorgitのリポジトリをクローンし、クローンしたディレクトリに移動します。
# git clone https://github.com/ansible/awx-operator
# cd awx-operator
デプロイできるバージョンを確認します。今回は一番新しい「2.19.1」を利用します。
# git tag --割愛-- 2.18.0 2.19.0 2.19.1 --割愛--
デプロイするバージョンにチェックアウトしておきます。
# git checkout tags/2.19.1
念のため指定のバージョンになっていることを確認します。
# git describe --tags 2.19.1
# make deploy namespace/awx created customresourcedefinition.apiextensions.k8s.io/awxbackups.awx.ansible.com created customresourcedefinition.apiextensions.k8s.io/awxmeshingresses.awx.ansible.com created customresourcedefinition.apiextensions.k8s.io/awxrestores.awx.ansible.com created customresourcedefinition.apiextensions.k8s.io/awxs.awx.ansible.com created serviceaccount/awx-operator-controller-manager created role.rbac.authorization.k8s.io/awx-operator-awx-manager-role created role.rbac.authorization.k8s.io/awx-operator-leader-election-role created clusterrole.rbac.authorization.k8s.io/awx-operator-metrics-reader created clusterrole.rbac.authorization.k8s.io/awx-operator-proxy-role created rolebinding.rbac.authorization.k8s.io/awx-operator-awx-manager-rolebinding created rolebinding.rbac.authorization.k8s.io/awx-operator-leader-election-rolebinding created clusterrolebinding.rbac.authorization.k8s.io/awx-operator-proxy-rolebinding created configmap/awx-operator-awx-manager-config created service/awx-operator-controller-manager-metrics-service created deployment.apps/awx-operator-controller-manager created
「awx」といNamaspaceが作成されていることを確認します。
# kubectl get namespaces NAME STATUS AGE awx Active 3m58s default Active 27m kube-node-lease Active 27m kube-public Active 27m kube-system Active 27m
AWX OperatorのPodがデプロイされていることを確認します。READYが2/2になっており、STATUSがRunningであることを確認します。READYの数がPodに作成されているコンテナ数を表しています。
※数分くらいかかります。
# kubectl get pods --namespace=awx NAME READY STATUS RESTARTS AGE awx-operator-controller-manager-58b7c97f4b-mgjnv 2/2 Running 0 83s
AWXデプロイ
AWX Operatorがデプロイできたので、AWXデプロイを行います。
AWX Operatorデプロイの手順の続きがAWXデプロイの手順になっているので引き続き進めていきます。
クローンしたディレクトリにあるawx-demo.ymlをもとにAWXのマニフェストを作ります。
# pwd /root/github.com/awx-operator # cp -a awx-demo.yml k-awx.yml # vi k-awx.yml
下記のように修正します。
--- apiVersion: awx.ansible.com/v1beta1 kind: AWX metadata: name: k-awx ★任意の管理しやすい文字列 spec: ingress_type: ingress ★記載の通り。
元ファイルと比較すると下記のようになります。
# diff -u awx-demo.yml k-awx.yml --- awx-demo.yml 2025-07-11 21:33:08.176283702 +0900 +++ k-awx.yml 2025-07-11 21:45:39.305944791 +0900 @@ -2,6 +2,6 @@ apiVersion: awx.ansible.com/v1beta1 kind: AWX metadata: - name: awx-demo + name: k-awx spec: - service_type: nodeport + ingress_type: ingress
ingress_type: ingressへ変更せず、service_type: nodeportのままデプロイを続けても成功し接続は可能になりますが、下記のような違いがあります。
・service_type: nodeport → 接続時のURLのポートが30000以降になる。
・ingress_type: ingress → 80ポートで接続できる。
イメージしにくいので簡単に図にしました。
service_type: nodeportの場合は、ポートマッピングのような動作になり、アクセス時のURLのポートがServiceに自動設定される30000番以降のポートになります。（30000番以降を振るのはK3sの仕様になり、変更も可能そうでしたが、ウェルノウンポートの許可が非推奨のように感じたので試していません）。
今回は通常の80番でアクセスしたかったので、ingress_type: ingressでルーティングのような動作にすることで80番でアクセスかのうなようにしています。
Ingressの利用には、Ingressコントローラが必要ですが、K3sではtraefikといわれるIngressコントローラがデフォルトで利用可能になっています。
AWXをデプロイします。
# kubectl apply -f k-awx.yml --namespace=awx
awx.awx.ansible.com/k-awx created
下記Issuesを見ているとバージョン指定も可能と見受けていますが試していません。
AWXのPodがデプロイされていることを確認します。READYとSTATUSが正常であることを確認します。
※十数分ほどかかります。
# kubectl get pods --namespace=awx NAME READY STATUS RESTARTS AGE awx-operator-controller-manager-58b7c97f4b-mgjnv 2/2 Running 0 45m k-awx-migration-24.6.1-kwdqp 0/1 Completed 0 33m k-awx-postgres-15-0 1/1 Running 0 35m k-awx-task-c88bb7576-98tbh 4/4 Running 0 34m k-awx-web-8fc77c4b8-rzcpl 3/3 Running 0 34m
AWXデプロイ中のログは下記コマンドで確認が行えます。
正常にデプロイができない場合は、ログを確認していきましょう。
# kubectl logs -f deployment/awx-operator-controller-manager --namespace=awx
Ingress確認
Ingressが作成されていることを確認します。
# kubectl get ingress --namespace=awx NAME CLASS HOSTS ADDRESS PORTS AGE k-awx-ingress traefik * 192.168.10.206 80 37m
Ingressの詳細を確認します。
Rulesからk-awx-service:80にルーティングされていることが確認できます。
少々わかりにくいですが、k-awx-service:80はService（SVC）を指しており、10.42.0.12:8052は、PodのIPとPod内のコンテナのポートになります。
# kubectl describe ingress --namespace=awx
Name: k-awx-ingress
Labels: app.kubernetes.io/component=awx
app.kubernetes.io/managed-by=awx-operator
app.kubernetes.io/operator-version=2.19.1
app.kubernetes.io/part-of=k-awx
Namespace: awx
Address: 192.168.10.206
Ingress Class: traefik
Default backend:
Rules:
Host Path Backends
---- ---- --------
*
/ k-awx-service:80 (10.42.0.12:8052)
Annotations:
Events:
Service（SVC）確認
Service（SVC）のk-awx-serviceが作成されておりClusterIPで80/TCP になっていることを確認します。
# kubectl get svc --namespace=awx NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE awx-operator-controller-manager-metrics-service ClusterIP 10.43.255.19 8443/TCP 53m k-awx-postgres-15 ClusterIP None 5432/TCP 42m k-awx-service ClusterIP 10.43.20.57 80/TCP 42m
k-awx-serviceの詳細を確認します。
Port（待ち受けポート）がhttp 80/TCPになっており、Endpoints（接続先）が10.42.0.12:8052（PodのIP、コンテナのポート）であることがわかります。
# kubectl describe svc k-awx-service --namespace=awx
Name: k-awx-service
Namespace: awx
Labels: app.kubernetes.io/component=awx
app.kubernetes.io/managed-by=awx-operator
app.kubernetes.io/operator-version=2.19.1
app.kubernetes.io/part-of=k-awx
Annotations:
Selector: app.kubernetes.io/component=awx,app.kubernetes.io/managed-by=awx-operator,app.kubernetes.io/name=k-awx-web
Type: ClusterIP
IP Family Policy: SingleStack
IP Families: IPv4
IP: 10.43.20.57
IPs: 10.43.20.57
Port: http 80/TCP
TargetPort: 8052/TCP
Endpoints: 10.42.0.12:8052
Session Affinity: None
Internal Traffic Policy: Cluster
Events:
Pod（awx-web）確認
Podを確認します。
k-awx-webのPodのIPアドレスが10.42.0.12であることがわかります。
# kubectl get pods --output=wide --namespace=awx NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES awx-operator-controller-manager-58b7c97f4b-mgjnv 2/2 Running 0 56m 10.42.0.9 k-awx k-awx-migration-24.6.1-kwdqp 0/1 Completed 0 44m 10.42.0.14 k-awx k-awx-postgres-15-0 1/1 Running 0 46m 10.42.0.11 k-awx k-awx-task-c88bb7576-98tbh 4/4 Running 0 45m 10.42.0.13 k-awx k-awx-web-8fc77c4b8-rzcpl 3/3 Running 0 45m 10.42.0.12 k-awx
Podの詳細（コンテナ含む）を確認します。
PodのIPアドレスが10.42.0.12で、k-awx-webの待ち受けポートが8052/TCPであることがわかります。
# kubectl describe pod k-awx-web-8fc77c4b8-rzcpl --namespace=awx
Name: k-awx-web-8fc77c4b8-rzcpl
Namespace: awx
--割愛--
Status: Running
IP: 10.42.0.12
IPs:
IP: 10.42.0.12
Controlled By: ReplicaSet/k-awx-web-8fc77c4b8
Containers:
--割愛--
k-awx-web:
Container ID: containerd://2d74c163f255b9c4a9e3543caca49ac1790c1886d238767b6fbaec18fd9e79ba
Image: quay.io/ansible/awx:24.6.1
Image ID: quay.io/ansible/awx@sha256:5d47e132014ae4c6a026a2e8f19ce7b3cf3c8f313d59e44fdfa95cd9f3669209
Port: 8052/TCP
--割愛--
AWX接続
ここまででAWXのデプロイが完了したので、いよいよ接続していきます。
パスワード確認
AWXにログインするためのパスワードを取得しメモしておきます。
# kubectl get secret --namespace=awx k-awx-admin-password -o jsonpath="{.data.password}" | base64 --decode ; echo
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ★メモする。
接続
URLにアクセスします(Oracle LinuxのOSのIPアドレス)。
http://192.168.10.206/
ログイン画面に下記を入力しログインをクリックします。
- ユーザー名：admin
- パスワード：先ほど確認したパスワード
ログインできました。
パスワード変更
自分でわかるパスワードに変更します。
「アクセス」->「ユーザー」画面を開き「admin」のアクションの鉛筆アイコンをクリックします。
「パスワード」「パスワードの確認」欄にパスワードを入力し「保存」をクリックします。
右上のユーザー名をクリック->ログアウトし、変更後のパスワードでログインできることを確認します。
参考
まとめ
最初ネットを調べたときには、「簡単にできるよ」みたいなことが書かれていたので安心していたら全然簡単じゃありませんでした。
ネットに転がっているAWXインストールの情報は古かったり、K8sなどに精通されている方の情報が多いようで、K8sなどに不慣れな私のような人には難しいものでした。本記事では、そういった方向けに極力わかりやすく書いたつもりなので、参考になれば幸いです。
調べている間に冒頭の「AWXとは」で記載した新しいリリースがされていない問題がありいささか不安ですが、せっかく覚えようとしているので無くなって欲しくないなぁ。