勇往邁進

HashiConf 2024 に現地参加するため海外出張という形でボストンに行ってきました。 日程は 2024/10/12(土)〜18(金) の一週間。 HashiConf 参加レポートは会社のブログに投稿したので、ここでは HashiConf 以外の部分をメインに、初の海外遠征の内容を記録します。 X.com にも #nnstt1_hashiconf というタグで投稿してます。 持ち物 まずはボストンに持っていった持ち物。 機内持ち込み手荷物は普段使っている無印の肩の負担を軽くするリュックサック、預け入れ手荷物は10数年前に買ったスーツケース（容量不明）。 リュックサックには長時間フライトを快適に過ごすためのグッズを入れた。 今回を機に用意したものもチラホラ。 用途毎に袋にまとめてリュックへ収納。 パスポートケース パスポートや現金（日本円、米ドル）のほか、フライトやホテルの予約のコピーを入れてた。 ホテルの部屋にいるとき以外は肌身離さず持ってた。 Anker の紛失防止トラッカーを装着。 水筒 機内でいつでも水分補給できるようにと持っていった。機内だけじゃなくボストン観光やホテル滞在時にも大活躍した。 個人ノートパソコン Macbook Air M3。 HashiConf 中は主に会社のぶログを書くのと SNS 用に使っていた。 今回の遠征のために買い替えたと言っても過言ではない。 業務用ノートパソコン 仕事せざるを得ない状況だったので持っていった。 業務用スマホ 同上。 Kindle Paperwhite 機内の映像コンテンツに飽きたときのために、と持っていったけど全く使わなかった。 名刺入れ 念の為に名刺を持っていったけどほとんど使わなかった。 プレーリーカードも忍ばせてて、無理やり読み取ってもらったことも。 技術書典の袋（画像左上） 機内持ち込みの液体、薬、お菓子、マスク、蒸気マスクといった機内で使うケア用品を収納。 ガジェットポーチ（画像左下） モバイルバッテリー もともと持っていた 20,100mh のやつ。 買い替えようかと考えていたけど、Macbook Air のバッテリー持ちを信じてそのままに。 イベント会場と宿泊先が同じホテルだったこともあり、結果的にこのモバイルバッテリーで十分だった。 AC アダプタ Anker Nano II 45W 一つだけ。 これだけでスマホも Macbook Air も業務用ノートパソコンも充電できる優れモノ。 自撮り棒 自撮りには使わなかったけど、知人の登壇風景を録画するときに一脚として使えて便利だった。 ELECOM の Bluetoothオーディオトランスミッター/レシーバー LBT-ATR01BK と φ3....

先日、Grafana Meetup Japan というコミュニティのイベントが開催されていました。 キーノートは JAXA の SLIM 月面着陸時に使われていた Grafana ダッシュボードの紹介で、着陸時の配信を見ていた自分はこのイベントを視聴（オンライン参加）して、案の定 Grafana 熱が高まってしまいました。 Grafana Meetup Japan #1 (2024/04/24 19:00〜) ## Grafana Meetup Japanへようこそ！ このイベントは、オープンソースの監視・可視化ツールであるGrafanaについて、互いに学び、発信し、交流することを目的としています。 Grafanaは、ITインフラやアプリケーションの監視から、IoTデバイス、ビジネス指標、工場、物流、自然災害、宇宙に至るまで、あらゆる分野でのデータ可視化と監視を支援するツールです。 日本でも広く利用されつつありますが、Grafanaの最新情報や導入事例、プラクティスを学んだり発信したりする場は多くありませんでした。そこで、Grafana Labsと共にGrafana Meetup Jap... 我が家の Grafana は Kubernetes クラスタで稼働済みですが、自宅外では見れないような状況です。 そこで、Grafana 熱が冷めないうちに Grafana Cloud を使って外部からも自宅ラボの状況を確認できるようにします。 今回は Grafana Cloud を登録、自宅内の Kubernetes クラスタにある Prometheus をデータソースとしてダッシュボードに表示するところまでやっていきます。 Grafana Cloud の登録 まずは Grafana Cloud の登録から。 Grafana Cloud | Observability platform overview 公式サイトでアカウントを作成して、Grafana stack とやらを作成します。 14日間は無料ですべての機能を使えるトライアル期間のようですが、トライアル終了後も費用を掛けずに使いたいので Grafana だけ設定していきます。 Grafana にログインできるようになったら、とりあえずの登録は完了です。 プライベートネットワーク内の Prometheus を参照 自宅内のプライベートネットワークにある Prometheus は外部公開していないため、Grafana Cloud から Prometheus をデータソースとして登録することはできません。 そこで、Private data source connect (PDC) という機能を使っプライベートネットワーク内の Prometheus をデータソースとして参照できるようにします。...

Google Domains が事業売却されるという話から約半年、重い腰をあげてついに我が家のドメインも Cloudflare に移行対応しました。 半年も経てば Cloudflare への移行手順は多くの記事で紹介されているので、今回は Cloudflare 移行に伴って発生した自宅ラボで使っている cert-manager の移行対応を記録しておきます。 なぜドメイン移行先を Cloudflare にしたのか このブログでも使っている nnstt1.dev というドメインは Google Domains で購入していましたが、ネームサーバーを設定してレコードの管理自体は Azure DNS でおこなっていました。 Azure DNS で管理しているなら Azure 自体でドメインを購入すればいいじゃないかと思ったのですが、Azure でドメインを購入するサービスの App Service ドメインでは com、net、co.uk、org、nl、in、biz、org.uk、co.in のトップレベルドメイン (TLD) しか対応していなかったため、.dev ドメインは別のサービスを利用するしかありませんでした。 （そもそも Google Domains にしたのも Azure が .dev に対応してなかったからなのに、今回も移行できないか確認してしまったという…） というわけで他のドメインサービスを探すことになったのですが、おネームドットコムは論外ということ以外は特にこだわりはありませんでした。 半年前でもそうでしたが、やっぱり Cloudflare が移行先として人気のようで、右にならえで自分も Cloudflare に移行することにしました。 移行自体はすんなり完了したのと、レコード自体の管理も Terraform を使うようにしました。 cert-manager の対応 自宅ラボの Kubernetes クラスタでは証明書管理のための cert-manager を使っています。 クラスタで（自宅内に閉じて）公開しているサービスの証明書を Let’s Encrypt で発行していますが、そのためにはドメインの検証が必要になります。 検証の方法は 2 つあって、Let’s Encrypt から対象ドメインを使っているサービスにアクセスする HTTP Validation と、DNS に指定の TXT レコードを作成する DNS Validation があります。...

今年は2度目の転職をするなど人生の転機にもなった年でした。 そんな 2023 年の振り返りと 2024 年の抱負を掲げてみます。 2022 年振り返りと 2023 年の抱負 今年の年末は大きな仕事があって丸一日休みという日がなく慌ただしい日々です。 とはいえ、スポットで対応する感じでスキマ時間があるので、昨年掲げた抱負を確認しつつ1年を振り返ります。 昨年は ↓ の抱負を掲げていたようです。 家族との時間を大切にする 転職の目処をつける 2022 年の振り返り 育休取得 今年の4月に双子（第2、3子）が生まれました。 長男出生時は特別休暇をもらったので、その日数（3日？5日？既に覚えてない）休んだだけでした。 その休み中は書類関係の手続きしたり、退院準備をしたり、と育児以外のミッションをしていたらあっという間に休みが終わりました。 次の子も同じ感じになるかなぁと朧気ながら思っていましたが、昨年に双子妊娠がわかって、更には妻が早期に入院する可能性が出てきた（結果的にそうなった）ため、育休を取ることにしました。 結果的には 3～4 月に長男分、5～7 月に次男三男の育休を取得して、計5ヶ月お休みしました。 5ヶ月は職場への負担が大きいかと思ったのですが、現職では男性の育休がボチボチ出てきたところだったので、相談はしやすかったです。 そういうことで、今年1年の約半分は家族メインの生活ができたので「家族との時間を大切にする」という抱負は達成できました。 育休中の振り返りは Note に投稿しました。 育休が終わったので振り返ってみた 転職活動 昨年から転職活動をしていましたが、子供が生まれることもあって中断していました。 まだ具体的な内容は言及できませんが「転職の目処をつける」という抱負は達成できたと思います。 アウトプット 今年は本ブログに 17 本投稿しました。 ラズパイ Ceph を Zabbix で監視する Cephadm のアラートを消す PG の修復 Ceph ホストのメンテナンス Red Hat Developer Subscription の有効期限が切れたので再登録した AMD CPU 使っていて RHEL 9 にアップグレードできなかった話 Fedora ラズパイの PoE+ HAT ファンをコントロールする 仮想化基盤の Proxmox VE への移行 Proxmox VE を管理するため Terraform に入門した Terraform で Proxmox VE の VM パラメータ設定 ansible....

普段プライベートでは Terraform Cloud は Azure のリソース（このブログの Static Apps や自宅ラボと連携しているサービス）を管理するために使ってます。 最近 Terraform Cloud を触る、というかドキュメントを読み漁る機会があって、この機会に Terraform Cloud Operator for Kubernetes を自宅ラボに入れてみるかぁ、となったのでやってみました。 ちなみに最近アップデートされた v2 のほうです。 HCP Terraform Operator for Kubernetes | Terraform | HashiCorp Developer The HCP Terraform Operator for Kubernetes allows you to provision infrastructure directly from the Kubernetes control plane. Terraform Cloud Operator for Kubernetes は長すぎるので、以降 TFC Operator と記載します。 TFC Operator は何ができるの？ TFC Operator はカスタムリソースを使って Terarform Cloud のワークスペースやモジュール、そしてエージェントプールを Kubernetes のリソースとして管理することができます。 特にエージェントプールの管理では Terraform Cloud エージェント自体も Pod として起動してくれます。...

この記事は エーピーコミュニケーションズ Advent Calendar 2023 の1日目の投稿です。 今年の 4 月に株式会社エーピーコミュニケーションズ (以降、APC) に入社して半年経ちました。 今はがっつり Azure をやっている感じですが、前職では Azure だけでなく色々なことにチャレンジさせてもらいました。 その中でも一番最初にチャレンジ（通常業務とは別で取り組んだ業務改善）したのは Ansible の導入でした。 そもそも Ansible とはなんぞや？って状態だったので Ansible を実際に触ってみようと、まずは Ansible もくもく会に参加しました。 当時はまだコロナ禍前の世界ということもあり Ansible コミュニティが開催していたもくもく会は数少ないオンライン参加が可能な勉強会で、これが自分にとって初めての技術コミュニティへの接触でした。 それから度々 Ansible コミュニティのイベントに参加していき、その中で某金魚の方を始めとした APC 所属の方をよくお見かけして APC という会社を知りました。 自分の興味が Ansible に加えて Kubernetes や Azure に広がっていった際も APC の名前を見ることが多く、Ansible に限らずアウトプット活動が盛んでとても楽しそうな会社という印象を持っていました。 アドベントカレンダーもその楽しそうな活動一つで、APC のアドカレ（組織のアドカレと言ったほうが正しいかも）に参加することは一種の憧れでもありました。 そんな APC に入社できたのも、自宅で自由に検証ができる環境「自宅ラボ」を導入してスキルアップできたのが大きいです。 というわけで、アドカレの初日にポエムっぽい投稿になってしまいますが「自宅ラボ ジャーニー 2023」と銘打って自分の過去ツイートを引用しながら自宅ラボの遍歴を紹介します。 ちなみに見出しは有名どころのサブタイトルを引用していますが特に意味はないです。 【序章】自宅ラボは出ているか? はじめに自宅ラボを導入するに至った動機ですが、理由は単純で「自由に使える環境が欲しい」と思ったからです。 冒頭で話したとおり、前職で自動化やサーバ管理を推進するために Ansible を触り始めたのですが、検証環境を用意するのもなかなか難しいものがありました。 特にプロキシに阻まれまくった。 最初の頃は Ansible もくもく会で使える環境で十分満足していたのですが、そのうちもっと色々な検証をしたくなって自由に使える プロキシに阻まれない 自宅ラボを導入することにしました。 おそらく自宅ラボを構築している方の多くが同じ動機なんではないでしょうか。 あと、ロマンとか探究心みたいな気持ちも少しはありましたね。 クラウドサービスを利用するのもよかったんですが、インフラの勉強をするにあたってやっぱり物理で触れるものが欲しいという理由でクラウドは除外しました。 とは言っても一部のサービスは自宅ラボと連携する形で利用しています。...

おうち K8s クラスタで HashiCorp Vault を動かしているのですが、Pod が再起動すると Vault が Seal 状態となってしまうので都度 Unseal Key を入力しています。 そろそろ煩わしさが限界なので Azure Key Vault と連携して Vault の Auto Unseal 機能を使ってみます。 Auto-unseal using Azure Key Vault | Vault | HashiCorp Developer This tutorial demonstrates an example for enabling Auto-unseal with Azure Key Vault. Auto Unseal 設定 Auto Unseal を使うためには以下の設定が必要になります。 Entra ID サービスプリンシパル Azure Key Vault Vault Config サービスプリンシパル Microsoft Entra ID に Vault の Auto Unseal で使用するサービスプリンシパルを作成します。...

はじめに SPY×FAMILY 28 話、最高でしたね。 ヨルさん（CV: はやみん）の「お仕事お疲れさま」というセリフは全勤労者を救ってくれました。 さて、話は変わって今回は個人用 Chrome 拡張機能を作ったのでその備忘録です。 どんな拡張機能かというと、「ブラウザで表示したページの特定のボタンを押したら指定の音声ファイルを再生する」という単純なものです。 この特定のボタンというのは一日に一度しか押すことがなく、「あー今日も仕事がんばったなー、今日はここらへんにしとくかー」ってときに押すボタンです。 拡張機能によって流れるヒーリングサウンドが疲弊しきった心身に染み渡ります。 すんなり作成できるかと思ったのですが、思いの外つまづいてしまいました。 そのまま音声を流せない 現在 Chrome 拡張機能は Manifest v3 がメインバージョンとなっていますが、Chrome 拡張機能を作るためにググってみると v2 の情報が多くヒットします。 音声を再生する方法も v2 では new Audio(url) とするだけで良かったようですが、v3 の情報があまり見つかりませんでした。 見つかった StackOverflow によると offscreen という機能を使うことで Chrome 拡張機能 v3 でも音声再生できるとうことで、試してみたところうまくいきました。 iframe で読み込んだ別ドメインのボタンを指定する 今回 Chrome 拡張機能の対象としているページは画面の一部を iframe で読み込んでいました。 そして押したときに音声を流したい特定のボタンも iframe の読み込み先で描画されていたのですが、この読み込み先が対象ページとは異なるドメインで管理されていました。 所謂クロスドメインです。 クロスドメインの iframe の場合、Chrome 拡張機能の content_scripts でスクリプトを挿入する際に all_frames: true と指定する必要がありました。 また、matches で指定する URL はブラウザでアクセスするものではなく、iframe で読み込む URL を指定することでピンポイントにスクリプトを挿入することができました。 作成した Chrome 拡張機能 というわけで上記の対応をしたものが以下になります。 Javascript は平均以下なので書き方に問題があっても見逃してください。...

はじめに 今年の夏も酷暑続きでしたねー。 仕事が忙しくて自宅ラボに触る時間もなかったり、マシンの熱が心配なのもあって夏の間は自宅ラボの電源を落としてたり、ということもあり前回の投稿から 4 ヶ月も空いてしまいました。 忙しさのピークも一段落して季節も秋に変わってきたので、また自宅ラボという名の盆栽いじりを再開してます。 前回の投稿では、cert-manager を使って Ingress 用の証明書を発行するようにしました。 Let’s Encrypt の ACME DNS-01 チャレンジ用に cert-manager が Azure DNS に TXT レコードを作成してくれます。 このとき、cert-manager は Microsoft Entra ID のサービスプリンシパルを使います。 サービスプリンシパルのクライアントシークレットは有効期限が最大でも 2 年間 (24 ヶ月) なので、HashiCorp Vault と Vault Secrets Operator を使ってクライアントシークレットを動的に生成して、クライアントシークレットの有効期限を意識せずにサービスプリンシパルを使えるようにします。 自宅ラボ用途なので 2 年間でもいいっちゃいいんですがね。 全体像 今回は色々なサービスが連携していて流れが分かりづらいため、最初に全体像を把握します。 シーケンス図のほうが分かりやすかったかも？ サービスプリンシバルを含め、Secret リソース以外は事前に作成しておきます。 今回の投稿でメインになってくるのは Vault と Vault Secrets Operator (VSO) です。 サービスプリンシバル あらかじめ Vault 用と cert-manager 用のサービスプリンシバルを作成しておきます。 cert-manager サービスプリンシバルは前回作成したものを使います。 Vault サービスプリンシバルも同様に作成したあと、他のサービスプリンシバルを操作するためのアクセス許可を設定します。 必要なものは以下の 2 つです。...

はじめに 久しぶりの個人ブログへの投稿です。 4月に転職してから会社ブログのほうに投稿する機会ができた結果、個人ブログのほうが疎かになってしまいました。 仕事でもプライベートでもやってること大体同じなんで投稿ネタがなくなるよね……。 というわけで、しばらく個人ブログのほうは自宅ラボという盆栽のお手入れ内容をメインに扱っていきます。 身の上話はここらへんにしておいて、今回は kube-vip というツールを使って、盆栽（おうち K8s クラスタ）用に構築していたロードバランサを削除した話です。 どうしてロードバランサを無くしたいの？ 我が家の K8s クラスタは、Proxmox VE を使った仮想基盤上の VM で動いていました。 物理は NUC と DeskMini の2台構成です。 かつてラズパイを使った Ceph クラスタを Rook から使っていましたが、不安定極まりないためラズパイをコントロールプレーンとして転生させました。 この時点で以下のような構成でしたが、VM を使わずに K8s クラスタを作りたいという思いを捨てきれず、現在は3台目のマシンをお迎えして絶賛移行中です。 用途 種別 台数 コントロールプレーン ラズパイ 3 ワーカー VM 3 ロードバランサ VM 2 ロードバランサは kube-apiserver 用に作成したものです。 kubeadm の高可用性クラスタを作る際のドキュメントにも記載があります。 DNS に Keepalived 用の VIP を A レコードとして登録して、クラスタ外からアクセスするのに使っています。 K8s クラスタを物理だけで動かそうとしたとき、このロードバランサがネックになりました。 手持ちのラズパイ3台はすでにコントロールプレーンとして使ってますし、ワーカー用の筐体もやっと3台揃えたところです。 ロードバランサとして使える余剰筐体は我が家にはありません。 高可用性である必要があるの？と思われるかもしれませんが、それはアレですよ、“ロマン” ですよ。 というわけで、今の手持ちで物理 K8s クラスタを作るためにも、以下の要件を満たす方法を検討しました。 ロードバランサ用のマシンは使わない 高可用性は維持する kube-vip を使ってみる 元々ロードバランサ@VM は RHEL に Keepalived と HAProxy を入れてアクティブ/スタンバイの構成としていました。 ロードバランサを無くすに当たって、最初はコントロールプレーンに直接 Keepalived を入れようとしましたが、うまくサービスが上がってこず原因調査で時間を溶かしていました。...