Terraform を使って Azure Kubernetes Service (AKS) で AGIC を動かす機会があったので、ハマりポイントを記録しておきます。 AGIC とは Application Gateway Ingress Controller (AGIC) は、Azure ネイティブの L7 ロードバランサ Application Gateway を利用した AKS で動作する Ingress Controller です。 AGIC を使うことで、AKS で Application Gateway の機能（URL ルーティングや TLS 終端）を使うことができます。 また、AKS クラスタ外の Application Gateway がオートスケールするため、トラフィックの増減に対してクラスタでのリソース消費がありません。 この機能を使うためには、Azure に AKS と Application Gateway、そして Public IP のリソースをデプロイする必要があります。 Terraform から Application Gateway を作成する方法として 2 パターンあります。 Application Gateway と Public IP のリソースタイプを指定する AKS のリソースタイプで Application Gateway を指定する ちなみに、利用した Terraform のバージョンは以下になります（バージョン古いと怒られていますね…）。 ...

Rook の新バージョン v1.10.0 がリリースされたようなので、早速、自宅ラボの Rook/Ceph をアップグレードしてみます。 マイナーバージョンが上がったときくらいは変更内容を追わないと、と思ってマニフェストの差分を確認しました。 アップグレード手順 アップグレードは公式ドキュメントに載っている手順どおりに進めました。 Rook Upgrades - Rook Ceph Documentation 自宅ラボの Rook は ArgoCD で管理しているので、クラスタ用リポジトリの以下のマニフェストを v1.10.0 の内容でマージしただけアップグレード完了しました。 common.yaml crds.yaml operator.yaml cluster.yaml 今回は common.yaml と operator.yaml の変更点を見ていきます。 cluster.yaml は Ceph のバージョンが違うだけなので割愛、crds.yaml は変更内容が多いため諦め。 アップグレード前の Rook のバージョンは v1.9.5 です。 common.yaml common.yaml には Namespace や RBAC 関連のリソースが記述されています。 削除 Kubernetes v1.25 で PSP が正式に廃止されたことが起因で、common.yaml から PSP に関連したリソースが削除されています。 そして v1.25 未満の Kubernetes 向けに PSP 関連をまとめた psp.yaml が作られています。 リソース 名前 PR ClusterRole psp:rook #10816 ClusterRoleBinding rook-ceph-system-psp #10816 ClusterRoleBinding rook-csi-cephfs-plugin-sa-psp #10816 ClusterRoleBinding rook-csi-cephfs-provisioner-sa-psp #10816 ClusterRoleBinding rook-csi-rbd-plugin-sa-psp #10816 ClusterRoleBinding rook-csi-rbd-provisioner-sa-psp #10816 ClusterRoleBinding cephfs-csi-nodeplugin #10033 PodSecurityPolicy 00-rook-privileged #10816 RoleBinding rook-ceph-cmd-reporter-psp #10816 RoleBinding rook-ceph-default-psp #10816 RoleBinding rook-ceph-mgr-psp #10816 RoleBinding rook-ceph-osd-psp #10816 RoleBinding rook-ceph-purge-osd-psp #10816 RoleBinding rook-ceph-rgw-psp #10816 また、PSP 関連とは別に ClusterRoleBinding cephfs-csi-nodeplugin が削除されています。 ...

2022/8/12 に AWS 認定の一つ、「AWS Certified Solutions Architect - Associate (SAA)」をパスしたので記録しておく。 動機 普段 AWS を使う機会はほとんどなく、過去に EC2 や Route53 をチョロっと触ったことがある程度だった。 前職で「AWS を使うかも」となったときに研修に行かせてもらったけど、今となっては全く記憶に残っていないレベル。 関係ないけど、講師が逸般の誤家庭界隈では有名なお方だったと最近知った。 機会があれば AWS を学びたいと思っていたが、そんな折、AWS 認定取得: Associateチャレンジ というキャンペーンを知った。 Associate レベルの受験料が 25% オフになるバウチャーを貰えるらしい。 AWS 認定取得: Associateチャレンジ がスタートしました🎉 ■AssociateレベルのAWS認定を取得する個人を応援するキャンペーンで、先着1000名に25%割引バウチャーを提供！ ■参加登録ページhttps://t.co/5VtaZayfCD ■期間は6月13日〜8月31日ですが、参加登録期限は7月10日です。早めにご登録を！ pic.twitter.com/2WVsIbRYvk — Wataru Nishimura (@kuwablo) June 12, 2022 Associate レベルの受験料は ¥15,000 (税抜) なので ¥3,750 ほどお安くなる。 Microsoft Cloud Skills Challange と似ているけど、こっちは登録するだけでいい。 これはよい機会だ、ということで AWS SAA を受けるために早速登録してみた。 AWS 認定取得: Associate チャレンジに登録したので AWS SAA ください — ののし (@nnstt1) June 14, 2022 2022/8/30 で AWS SAA の試験内容が更新されるということを登録後に知った。 現行は SAA-C02、更新後は SAA-C03 という。 ...

久しぶりに Ansible を触ってみたら ansible.cfg を作成する ansible-config init コマンドができていたので素振りしてみる。 ドキュメント Ansible Configuration Settings — Ansible Documentation バージョン確認 pip で最新の ansible をインストールしている。 ansible-core は v2.13.2。 GitHub を見たところ、ansible-config の init オプションは v2.12.0 から追加されているので、使うなら v2.12.0 以上で。 職場では v2.9 を使っているため、このオプションは使えない模様……。 $ ansible-config --version ansible-config [core 2.13.2] config file = None configured module search path = ['/home/nnstt1/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules'] ansible python module location = /home/nnstt1/.virtualenv/ansible/lib/python3.9/site-packages/ansible ansible collection location = /home/nnstt1/.ansible/collections:/usr/share/ansible/collections executable location = /home/nnstt1/.virtualenv/ansible/bin/ansible-config python version = 3.9.10 (main, Feb 9 2022, 00:00:00) [GCC 11.2.1 20220127 (Red Hat 11.2.1-9)] jinja version = 3.1.2 libyaml = True 使い方 --help 引数をつけて使い方を見てみる。 ...

前回、Terraform を使って Proxmox VE に VM を作成した。 このとき作成した main.tf は最小限の項目しか設定していなかったので、VM のパラメータを設定するように変更する。 設定項目はドキュメントを参照した。VM のネットデバイスやディスクは個別のブロックで設定するらしい。 terraform { required_providers { proxmox = { source = "telmate/proxmox" version = "~> 2.9.10" } } } provider "proxmox" { pm_api_url = "https://pve1.nnstt1.home:8006/api2/json" } resource "proxmox_vm_qemu" "terraform-test" { name = "terraform-test" target_node = "pve1" iso = "local:iso/Fedora-Server-dvd-x86_64-36-1.5.iso" ### 以下、追加した項目 bios = "ovmf" onboot = true memory = 2048 sockets = 1 cores = 2 cpu = "host" scsihw = "pvscsi" # Disk block disk { type = "scsi" storage = "local-lvm" size = "20G" format = "raw" } # Network block network { model = "vmxnet3" bridge = "vmbr0" } } 名前通りの設定をすればよいので難しい点はなさそう。 ...

先日構築した Proxmox VE クラスタを IaC で管理したいと思い、重い腰を上げてついに Terraform に入門した。 Terraform はクラウドリソースを管理するのがメインと思っていたけど、幸いにも Proxmox VE にも対応している。 「対応している」よりは「誰かが対応するように Provider というものを作ってくれている」という表現のほうが正しい。 Proxmox VE で VM やコンテナを作るための「Proxmox Provider」というものが公開されている。 Terraform Registry - proxmox 手始めに Proxmox Provider のドキュメントに沿って VM を作成してみる。 Proxmox VE Terraform 用ユーザ/ロールの作成 Proxmox VE に Terraform が利用するユーザとロールを作成する。 クラスタ管理権限を付与することもできるが、必要最低限の権限を割り当てることでセキュリティリスクを低減する。 root@pve1:~# pveum role add TerraformProv -privs "VM.Allocate VM.Clone VM.Config.CDROM VM.Config.CPU VM.Config.Cloudinit VM.Config.Disk VM.Config.HWType VM.Config.Memory VM.Config.Network VM.Config.Options VM.Monitor VM.Audit VM.PowerMgmt Datastore.AllocateSpace Datastore.Audit" root@pve1:~# pveum user add terraform-prov@pve --password <password> root@pve1:~# pveum aclmod / -user terraform-prov@pve -role TerraformProv 作成したロールとユーザを確認する。 表形式で出力されるが見切れてしまっている。 ...

自宅ラボの仮想化基盤を VMware ESXi から Proxmox VE に移行した。 動機 自宅ラボでは2台の物理マシンに VMware ESXi をインストールして仮想化基盤を構築しているが、VMUG Advantage 会員になることをケチっていたため vMotion を使えない状態だった。 仮想ホストのメンテナンスをしようと思っても VM の停止を許容するしかなかった。 そんな折、オープンソースの Proxmox VE という仮想化プラットフォームの存在を知った。 Proxmox VE であれば無償で仮想化基盤の HA クラスタを組むことができるとのことで、ESXi から Proxmox VE に切り替えることにした。 AWS SAA の勉強をしないといけない現実から目を逸しているだけ。 Proxmox VE とは Proxmox VE (Virtual Environment) は、Debian ベースの仮想化プラットフォームで、KVM による仮想マシン環境と LXC によるコンテナ環境が提供されるらしい。 KVM も LXC も使ったことがないので実際どんなものかは分からない。 複数の物理マシンを用意すれば無償でクラスタを組むことができる（大事になことなので2度言う）点が VMware 製品とは異なり、個人的に大きなメリットと感じた。 また、試せてはないけど Proxmox VE のストレージとして Ceph を構築できるらしい。 物理マシンがもう1台欲しくなっちゃうけど時期が悪すぎる。 Proxmox VE 導入 ESXi から Proxmox VE に VM を移行する。 手順は Proxmox 公式 Wiki の Migration of servers to Proxmox VE を参考にした。 ...

Ceph クラスタ用のラズパイ 4 に PoE+ HAT を導入しました。 PoE+ HAT にはファンも内蔵されているのですが、このファンが煩いです。 ラズパイ本体の温度によってファンの回転数が変わるようなのですが、頻繁に回転数が変わります。 温度をみたところ 50℃ 前後を行き来していて、どうやら 50℃ を境に回転数が上がるようです。 書斎にラズパイを置いているのですが、これでは全く集中できません。 ファン回転数の閾値を変更して、騒音レベルを下げます。 どうやって PoE+ HAT のファンを制御するかググったところ、Raspberry Pi OS ではシステム設定用のファイル /boot/config.txt に下記のような設定を追加すればよいようです。 dtoverlay=rpi-poe-plus dtparam=poe_fan_temp0=40000,poe_fan_temp0_hyst=2000 dtparam=poe_fan_temp1=45000,poe_fan_temp1_hyst=2000 dtparam=poe_fan_temp2=50000,poe_fan_temp2_hyst=2000 dtparam=poe_fan_temp3=55000,poe_fan_temp3_hyst=5000 dtparam に設定するパラメータは意味はラズパイ Firmware の README に書いてありました。 パラメータ 内容 デフォルト値 poe_fan_temp0 ファンがオンになる温度 40000 poe_fan_temp0_hyst ファンがオフになるまでの温度差 2000 poe_fan_temp1 ファンが速度を上げる温度 45000 poe_fan_temp1_hyst ファンが減速する温度差 2000 poe_fan_temp2 ファンが速度を上げる温度 50000 poe_fan_temp2_hyst ファンが減速する温度差 2000 poe_fan_temp3 ファンが速度を上げる温度 55000 poe_fan_temp3_hyst ファンが減速する温度差 5000 Ceph クラスタ用ラズパイの OS には Fedora を使っているのですが、Raspberry Pi OS とは config.txt の場所が異なっており /boot/efi/config.txt にありました。 ...

RHEL 9 がリリースされたので自宅ラボの RHEL 8 をアップグレードしようとしたところ、CPU がサポート対象外となっておりアップグレードできませんでした。 【結論】AMD Zen/Zen+/Zen 2 のマシンは RHEL 9 にアップグレードできない 先に結論から言うと、AMD Ryzen 5 3400G を使っている自宅ラボの仮想化基盤上のマシンが RHEL 9 にアップグレードできませんでした。 どうやら AMD Zen/Zen+/Zen 2 のマシンは RHEL 9 にアップグレードできないようです。 以下、アップグレードの流れとともに上記結論を判断した理由を説明します。 アップグレードの事前チェック RHEL 9 の公式ドキュメントに RHEL 8 からのアップグレード手順が載っていました。 RHEL 8 から RHEL 9 へのアップグレード Red Hat Enterprise Linux 9 | Red Hat Customer Portal この手順に則って、leapp コマンドを使ってアップグレードの事前チェックをしました。 $ leapp preupgrade --target 9.0 ==> Processing phase `configuration_phase` ====> * ipu_workflow_config IPU workflow config actor (snip) ============================================================ UPGRADE INHIBITED ============================================================ Upgrade has been inhibited due to the following problems: 1. Inhibitor: Firewalld Configuration AllowZoneDrifting Is Unsupported 2. Inhibitor: Leapp detected a processor which is no longer supported in RHEL 9. Upgrade cannot proceed. Consult the pre-upgrade report for details and possible remediation. ============================================================ UPGRADE INHIBITED ============================================================ (snip) すると、赤く UPGRADE INHIBITED という文字が表示されて終了しました。 どうやら RHEL 9 へのアップグレードができない状態のようです。 ...

Red Hat Developer Subscription for Individuals を再登録した記録です。 RHEL 9 へのアップグレードを試す RHEL 9 がリリースされました！ 自宅ラボに Red Hat Developer Subscription for Individuals (以下、Developer Subscription) というサブスクリプションを使って RHEL 8 サーバを構築しています。 Developer Subscription とは、Red Hat が提供してくれる個人向けの無料プログラムで、Red Hat Enterprise Linux (RHEL) を 16 台まで利用することができます。 詳しくは以下の FAQ を参照してください。 No-cost Red Hat Enterprise Linux Individual Developer Subscription: FAQs | Red Hat Developer 早速、公式ドキュメントの手順を参照してアップグレードを試みました。 第3章 アップグレードの準備 Red Hat Enterprise Linux 9 | Red Hat Customer Portal 手順通り、RHEL 8 サーバにサブスクリプションが割り当てられているか確認しました。 ...