Tech

Podman Desktop がリリースされたので Windows にインストールしました。 インストールしただけです。 Podman Desktop とは Publickey さんの記事にすべて書かれてます。 GUIでDockerコンテナのビルドやPodsのKubernetesへの展開を可能にする「Podman Desktop」が登場。新たなDocker Desktop対抗となるか GUIでDockerコンテナやKubernetesの操作を可能にするオープンソースの「Podman Desktop」がリリースされたことをRed Hatが発表しました。Windows、Mac、Linuxに対応します。 Install, co... www.publickey1.jp インストール Podman Desktop 公式ページ に MacOS, Windows, Linux の各環境向けインストールマニュアルがあります。 今回は Windows 向けマニュアルを参照しました。 前提条件に「Hyper-V が有効化されていること」と「WSL2 がインストールされていること」とありますが、今回は両方ともインストール済みだったので省略します。 マニュアルによると Podman Desktop からそれぞれインストールできるようです。 Podman Desktop ダウンロードページ から .exe ファイルをダウンロードします。 バージョンは v0.9.1 でした。 ダウンロードした .exe を起動すると、匿名で情報収集してよいかと聞かれます。 任意ですがこころよく OK します。 Podman Desktop のダッシュボードが表示されますが、Podman が見つからないと表示されました。 この Windows には Podman 自体もインストールしていませんでした。 ...

前回の投稿で、Terraform を使って AKS で AGIC を動かす際のハマりポイントを紹介しました。 その際はマネージド ID の権限周りの設定がうまくできていなかったのですが、解決方法がわかったので改めて Terrafrom で AKS と AGW をデプロイする書き方を整理します。 デプロイパターン まず、AGIC から使う前提の AGW を Terraform でデプロイするパターンとしては以下の 2 つが考えられます。 AKS と AGW を個別にデプロイ AKS デプロイ時に AGW も作成 それぞれについて、Terraform の書き方とデメリットについて説明します。 前提条件として、以下のリソースは既に存在しているものとします。 リソースグループ VNet AKS 用 サブネット AGW 用 サブネット AKS と AGW を個別にデプロイ PIP AKS と AGW を個別にデプロイするパターンでは、Public IP も作成する必要があります。 resource "azurerm_public_ip" "pip" { name = local.pip_name resource_group_name = azurerm_resource_group.rg.name location = azurerm_resource_group.rg.location allocation_method = "Static" sku = "Standard" } AGW 次に、PIP に依存する形で AGW を作成します。 今回作成する AGW では、HTTP で受けたリクエストを HTTPS へリダイレクトさせます。 redirect_configuration ブロックでリダイレクト先の HTTPS リスナーを指定し、request_routing_rule ブロックの HTTP ルーティング規則 でリダイレクト設定を指定します。 ...

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 が削除されています。 ...

久しぶりに 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 へのアップグレードができない状態のようです。 ...