Tomofumi Kondo

Grafana の Git Sync でダッシュボードを GitOps 管理する

Sat, 18 Apr 2026 15:21:46 +0900

1. はじめに

みなさん、Grafana のダッシュボード管理どうしてますか？

私は自宅の Kubernetes クラスターで Grafana を動かしており、ダッシュボードを Web UI でポチポチ作ったり、mcp-grafana を使って Claude Code や kagent から作ったりしていました。

しかし、それではダッシュボードのデータが Grafana 内部のデータベースにしか残らず、PVC を使っていたとしても Kubernetes クラスター自体を作り直した際などには消えてしまいますし、バージョン管理もできないため履歴を追うことも難しいです。実際に今まで何回も Kubernetes クラスター自体が壊れて作り直しており、その度に同じようなダッシュボードを都度都度作成していました、、、

そんな中、Grafana v12.4 から Git Sync という機能が使えるようになっていることを知りました。ダッシュボード設定の JSON を GitHub リポジトリと双方向に同期してくれる機能で、まさに求めていたものです。

今回は、自宅サーバーの Grafana に Git Sync を導入して、ダッシュボードを GitOps で管理できるようにするまでの手順を紹介します。

2. Git Sync とは

Git Sync は、Grafana インスタンスと Git リポジトリの間でダッシュボードを双方向に同期する機能です。 Grafana Cloud だけでなく、OSS 版や Enterprise 版でも利用できます。

主な特徴はこんな感じです。

双方向同期: Web UI での変更は Git にコミットされ、Git への変更は Grafana に反映される
- PR ワークフロー: Web UI での変更をブランチにコミットして PR を作成できる（branch ワークフロー）
- 直接コミット: Web UI での変更を直接メインブランチにコミットもできる（write ワークフロー）
定期同期: 設定した間隔（例: 60秒）で自動的に同期される

従来のプロビジョニング（provisioning/dashboards/ にファイルを配置する方法）との大きな違いは、Git → Grafana の一方向ではなく、Grafana → Git の方向も同期される点です。 Web UI で気軽にダッシュボードを編集しつつ、その変更が自動的に Git に記録されるのはとても便利です。

Tomofumi Kondo

Sat, 04 Apr 2026 22:14:32 +0900

プロフィール

プライベートクラウド・ソフトウェアエンジニア

誕生日：2000/03/14 居住地：東京/日本

スキル

得意

OpenStack
- Nova, Neutron, Cinder, Glance, etc.
Kubernetes
Linux
TCP/IP
OVS
Go
Python
Ansible
NeoVim

経験あり

QEMU/KVM
Terraform
Prometheus
VictoriaMetrics
Grafana
GitHub Actions
AWS
Google Cloud

経歴

2024/04 - 現在：株式会社サイバーエージェント
- プライベートクラウドの主にIaaS基盤の開発・運用
2022/04 - 2024/03：東北大学情報科学研究科（修士卒）
- 消費電力を考慮したネットワークコントローラの配置最適化に関する研究
2022/12 - 2024/03：株式会社サイバーエージェント
- 内定者バイト
- 異なるタイプのボリューム間のボリュームリタイプシステムの開発
2022/09 - 2022/09：合同会社DMM.com
- インターン
- 動画配信サーバの構築。IPMIからのRAIDの設定やOSインストール、動画配信ミドルウェアの構築など。
2022/08 - 2022/09：サイボウズ株式会社
- インターン
- オンプレミスでKubernetesクラスタを管理しているNecoチームにて2週間のインターンに参加し、カスタムコントローラ開発に取り組んだ。
2022/08 - 2022/08：株式会社アカツキゲームス
- インターン
- 課金管理基盤の開発・運用改善。Go、GCP。
2022/07 - 2022/07：ピクシブ株式会社
- インターン
- AWSで構築されているWebサービスのインフラ改善。特にDevOpsやIaC周り。
2022/06 - 2022/06：株式会社マネーフォワード
- インターン
- あらかじめ登録したタイムスケジュールを元にDeploymentのreplicasを切り替えるカスタムコントローラ・Admission Webhookの開発
2022/05 - 2022/06：株式会社サイバーエージェント
- インターン
- プライベートクラウドで利用しているOpenStackのネットワークコンポーネントであるNeutronのバグ修正
2021/10 - 2022/03：株式会社ギフティ
- インターン
- Ruby on Railsを用いたWebアプリケーションに対する機能の修正や追加を行った。
2021/11 - 2021/12：株式会社リクルート
- インターン
- 社内横断のエンジニアリングチームにて、社内の各サービスチームで使われるコンテナアプリケーションのCI/CD標準化に取り組んだ。 AWS ECSやCode seriesを用いたコンテナアプリケーションとそのCI/CDパイプライン構築をするに当たって、セキュリティ（ネットワークやIAMの権限）や可用性、コスト、クロスアカウントでの運用など、プロダクションレベルで必要なクラウドインフラ設計に取り組むことができた。また、インフラリソースを記述するTerraformのディレクトリ設計のベストプラクティスについても考え、実践することができた。
2021/09 - 2021/09：Wantedly, Inc.
- インターン
- 3週間のサマーインターンで、Custom ControllerやOIDC認証を利用したKubernetesのapiserverでの認証方式の移行や、開発者にKubernetesへのアクセス権限を管理するCLIツールのサブコマンド開発等をした。
2021/05 - 2021/05：株式会社ギフティ
- インターン
- 1週間のインターンで、Ruby on Railsを用いたLINE Bot開発に取り組んだ。企画から開発までのサイクルを短い期間で回し、最終日に開発したボットを用いたプレゼンテーションを行った。
2020/09 - 2020/09：株式会社VOYAGE GROUP
- インターン
- 2日間、VOYAGEのインターン担当のエンジニアさんが扮する社内の顧客への聞き取りを行い、顧客が本当に求めていることを見極めてサービスの仕様を考え、プロトタイプを作成した。
2020/08 - 2020/08：楽天株式会社
- インターン
- 2週間のハッカソン形式のチーム開発インターンで、サービスの企画から開発を一貫して行い、最後に英語でのプレゼンテーションを行なった。主にDocker / Herokuを用いた開発・デプロイ先環境の構築と、Flask（Python）を用いたバックエンドのAPIの設計・実装を担当した。
2020/06 - 2020/06：株式会社サイバーエージェント
- インターン
- 2日間の日程で、インターン用に用意された架空Webサービスのパフォーマンスチューニングをコンテスト形式で行なった。主にRDB周りのチューニングを行い、クエリログからボトルネックを判断し、DBの修正（設計やインデックス等）や、アプリケーション側の修正（N + 1の解消等）を行なった。また、Nginx等のDB以外のミドルウェアのチューニングも行った。
2018/06 - 2024/03：ウェルプレイス株式会社
- アルバイト
- 独自の物件検索・管理システムを持つ自社サイトの開発・運用や、社内ネットワークの管理等をしている。
- 【自社HP】
  - PHP, Laravel, Javascript, MySQL
  - GitHub ActionsとDeployerを用いたCI/CDの構築
  - VirtualBox、Vagrant、Dockerを用いた開発環境の構築
  - さくらインターネットを利用した本番環境の構築
- 【その他】
  - 自社のAccess/Excelデータベースのメンテナンス。
  - 社内機器(ルータ/NAS等)の管理。

Contact

OVN-Kubernetes のノード再起動後にネットワーク断になる

Sat, 04 Apr 2026 21:28:11 +0900

1. はじめに

みなさん、自宅 Kubernetes クラスタ運用してますか？

今回は、自宅サーバーで動かしている OVN-Kubernetes（Helm デプロイ）の環境で、ノードを再起動すると外部疎通が完全に断になるというなかなか厄介な問題に遭遇したので、原因の深掘りと解決までの記録をお話しします。

OVN-Kubernetes のセットアップについてはこちらの記事で紹介しているので、興味があればぜひ読んでみてください。

2. OVN-Kubernetes のブリッジ構成

NicToBridge の仕組み

OVN-Kubernetes は、ノードの物理 NIC（例: eth0）を OVS ブリッジ（breth0）に組み込んで使います。この処理を行うのが NicToBridge() 関数です。

やっていることをざっくりまとめると：

OVS ブリッジ breth0 を作成
eth0 を breth0 のポートとして追加
eth0 に other-config:transient=true を設定
eth0 の IP アドレスとルートを breth0 に移行

// go-controller/pkg/util/nicstobridge.go (NicToBridge)
stdout, stderr, err := RunOVSVsctl(
    "--", "--may-exist", "add-br", bridge,
    "--", "br-set-external-id", bridge, "bridge-id", bridge,
    "--", "br-set-external-id", bridge, "bridge-uplink", iface,
    "--", "set", "bridge", bridge, "fail-mode=standalone",
    fmt.Sprintf("other_config:hwaddr=%s", ifaceLink.Attrs().HardwareAddr),
    "--", "--may-exist", "add-port", bridge, iface,
    "--", "set", "port", iface, "other-config:transient=true")

ここでポイントになるのが other-config:transient=true です。これは「このポートは一時的なものなので、OVS 再起動時に削除してよい」というマーカーです。

正常な再起動フロー

正常に機能する場合、以下のような流れでノード再起動後もネットワークが復旧します。

  sequenceDiagram
    participant OVS as ovsdb-server
    participant NIC as eth0
    participant BR as breth0
    participant OVN as ovnkube-node

    Note over OVS: ノード再起動
    OVS->>OVS: --delete-transient-ports で起動
    OVS->>NIC: transient ポート(eth0)を削除
    Note over NIC: eth0 がブリッジから外れる
    NIC->>NIC: systemd-networkd が IP を設定
    Note over NIC: eth0 経由で外部疎通が復旧
    OVN->>OVN: API server に到達可能
    OVN->>BR: NicToBridge() で eth0 を再接続
    Note over BR: breth0 に IP を移行して通常運用に復帰

3. 発生した問題

さて、ここからが本題です。実際にノードを再起動すると、外部疎通が完全に断になってしまいました。

cert-manager と Cloudflare DNS で Envoy Gateway の証明書を自動管理する

Thu, 02 Apr 2026 23:11:28 +0900

1. はじめに

みなさん、Kubernetes クラスターの証明書管理してますか？

前回の記事では、Envoy Gateway を使って argocd-server に HTTPS でアクセスする環境を構築しました。その際、証明書は Ansible で自己署名の CA/Server 証明書を作成して Kubernetes Secret に登録するという方法を取っていたのですが、記事の最後に「もしかしたら cert-manager とかを使った方が楽だったかもしれませんが、終わってから気づきました…」と書いていました。

というわけで今回は、cert-manager を使って Let’s Encrypt の証明書を Cloudflare DNS01 チャレンジ で自動発行・更新する方法を紹介します。これにより、自己署名証明書からの脱却と、証明書の自動更新を実現します。

2. cert-manager について

cert-manager は、Kubernetes クラスター内で TLS 証明書の発行・更新を自動化してくれるツールです。 Let’s Encrypt などの ACME 対応の CA（認証局）と連携して、証明書のライフサイクルを自動で管理してくれます。

証明書の発行には ACME プロトコルを使用しますが、ドメインの所有を証明するためのチャレンジ方法がいくつかあります。今回は DNS01 チャレンジ を使います。 DNS01 チャレンジは、ドメインの DNS レコードに特定の TXT レコードを追加することでドメインの所有を証明する方法です。

3. 前提環境

Kubernetes クラスター: 自宅サーバー上の環境（kubeadm + OVN-Kubernetes）
Envoy Gateway: v1.5.0（前回の記事でインストール済み）
ドメイン管理: Cloudflare（home.tomokon.net）
cert-manager: v1.18.2

Envoy Gateway の GatewayClass や Gateway リソースは前回の記事で作成済みの前提で進めます。

GMKtec ミニPCでProxmoxクラスターを構築

Sun, 05 Oct 2025 14:16:28 +0900

先日、GMKtecのミニPC（M7 Ryzen 7 PRO 6850H）を購入して、既存のProxmoxサーバと組み合わせて2台構成のクラスターを構築しました。

今回はその過程を、購入したミニPCのハードウェアの紹介から、Proxmoxのインストール、クラスター構築、そして既存VMのライブマイグレーションまで紹介しようと思います。

1. 新規ハードウェアの紹介

今回購入したのは、GMKtecのM7 Ryzen 7 PRO 6850Hです。楽天市場でセールがやっていたので購入しました。（セールで買うのがデフォルトみたいな感じですが）

スペックは大体こんな感じです：

CPU: AMD Ryzen 7 PRO 6850H (8コア/16スレッド)
RAM: 32GB DDR5
Storage: 1TB NVMe SSD
Network: 2.5Gb Ethernet × 2

それでは早速開封していきましょう。

コンパクトなパッケージに入っています。箱はちょっと凹んでいましたが、中身は綺麗です。付属品は電源アダプタとHDMI/USBケーブル類。

筐体を開けてボードを確認してみました。

コンパクトにまとまっていて、NVMeスロットが2つ（1つは空きスロット）、SO-DIMMスロットが2つ（16GB x2）あります。 SSDは最大4TBまで、メモリは最大64GBまで増設可能らしいので、足りなくなったら換装もできます。

ではProxmoxをインストール、、、といきたい所ですが、その前にBIOS設定だけ少しいじります。

CPU Power Modeを “Performance” に設定して、電力効率や静音よりもパフォーマンスを優先する構成にしました。

2. Proxmoxのインストール

続いて、Proxmox VEをインストールしていきます。

執筆時点の最新バージョンは 9.0 でしたが、既存のProxmox Nodeが8.4で動いていたため、合わせて8.4をインストールします。 Proxmoxの公式ドキュメントを参考にして、こちらのページからProxmox VE 8.4のISOイメージをダウンロードしました。

次に、Zennの記事を参考にして、balenaEtcherを使用してISOイメージをUSBメモリに書き込みます。

書き込んだUSBメモリをミニPCに刺して、Proxmoxインストーラーを起動します。

ひとまず memtest を実行しておきます。

Cloud Operator Days Tokyo 2025で登壇しました

Sun, 21 Sep 2025 19:44:31 +0900

先日、「Cloud Operator Days Tokyo (CODT) 2025」というイベントで、「Goで作る！ストレージ筐体間での安全なCinder volume移行システムの開発と運用」というタイトルで登壇してきました。

CODT はクラウド運用に携わる人たちのためのカンファレンスで、「オペレーターに光を当てる」をテーマに、SREやクラウドインフラ、AI活用などの幅広いトピックについて多くの発表がありました。

今回の発表では、OpenStackのCinder Volumeを安全に移行するシステムについてお話しました。

発表で使用したスライド資料公開しているため、興味がある方はぜひご覧ください：

Goで作るストレージ拡張体験で安全なCinder Volume移行システムの開発と運用

Envoy Gateway を使って argocd-server に HTTPS でアクセスする

Sun, 07 Sep 2025 23:22:48 +0900

1. はじめに

今回は、自宅の Kubernetes クラスターで、Kubernetes の Gateway API 実装の一つである Envoy Gateway を使って、 argocd-server に HTTPS でアクセスできるようにするまでの手順を紹介します。

Argo CD のドキュメントには Ingress Configuration のページはあるのですが、Gateway API を使った設定方法は見当たらなかったため、色々と試行錯誤しながらやってみました。

2. Argo CDについて

まずは Argo CD について簡単に紹介します。

Argo CD は、Kubernetes クラスター上で GitOps を実践するための CD (Continuous Delivery) ツールです。 Git リポジトリを SSOT (Single Source of Truth) として、宣言的かつ自動的な Kubernetes リソースの管理ができます。

From https://argo-cd.readthedocs.io/en/stable/#architecture

例えば以下のような画面で登録した Application の状態を確認したり、Git リポジトリとの同期操作を行ったりできます。

From https://argo-cd.readthedocs.io/en/stable/#what-is-argo-cd

Argo CD は複数のコンポーネントで構成されており、今回 HTTPS でアクセスできるようにする argocd-server は、先ほど見せた Web UI と API エンドポイントを提供するコンポーネントです。

自宅サーバーでKubeVirtに入門

Sat, 06 Sep 2025 13:25:20 +0900

1. はじめに

私は普段、業務や趣味の自宅サーバーでIaaS基盤の開発・運用をしており、OpenStackやKubernetesを日常的に触っています。そのため、「Kubernetes上で仮想化基盤を構築する」というコンセプトのKubeVirtには以前から興味を持っていました。

そして先日たまたまこちらのOracle JapanのTakuya Niitaさんが公開しているスライド資料を見かけて、なんだか思ったより簡単に動かせそう？と思ったので、自宅サーバーで試してみることにしました。

というわけで今回は、自宅のKubernetesクラスタにKubeVirtをインストールして実際にVMを動かしてみた際の、手順やハマりポイントについて紹介しようと思います。

2. KubeVirtとは

KubeVirtは、Kubernetes上で仮想マシン（VM）を動かすためのプラットフォームとなるOSSです。

コンテナとVMを同じKubernetesクラスタ上で統一的に管理できるのが特徴で、既存のVM資産をKubernetesに移行したい場合や、コンテナ化が難しいワークロードを扱いたい場合に便利なもののようです。

KubernetesのリソースとしてVMを定義し、Podと同じようにKubernetesのエコシステムを使って管理できるのが面白いところです。

3. 環境構築

それでは早速KubeVirtをインストールしていきます。

3.1 Kubernetesクラスタの準備

まず、KubeVirtを動かすためのKubernetesクラスタが必要です。私の場合は、自宅サーバー上にkubeadmで構築したクラスタを使用しました。ネットワークプラグインにはOVN-Kubernetesを採用しています。

クラスタの詳細な構築手順については、「kubeadmとOVN-Kubernetesで自宅Kubernetesクラスタを構築する」という記事で紹介していますので、興味がある方はそちらもご覧ください。

3.2 KubeVirtのインストール

KubeVirtのインストールは、公式のクイックスタートガイドに従って実施しました。

まず、最新の安定版バージョンを取得します：

export VERSION=$(curl -s https://storage.googleapis.com/kubevirt-prow/release/kubevirt/kubevirt/stable.txt)
echo $VERSION

次に、KubeVirt Operatorをデプロイします：

kubectl create -f "https://github.com/kubevirt/kubevirt/releases/download/${VERSION}/kubevirt-operator.yaml"

最後に、KubeVirtのCRをデプロイして実際のコンポーネントを起動します：

kubectl create -f "https://github.com/kubevirt/kubevirt/releases/download/${VERSION}/kubevirt-cr.yaml"

順調にいけばこれで完了…のはずだったのですが、実際にはいくつか問題が発生しました。

4. 遭遇した問題と解決

4.1 CPU命令セットの問題

最初に遭遇したのは、各Worker Node上のVMを管理するコンポーネントである virt-handler Podが起動しないという問題です。

virt-handler Podのログを確認すると、以下のエラーが出ていました：

virt-handler-hxdfn virt-launcher 2025-08-30T22:58:59.360762864+09:00 Fatal glibc error: CPU does not support x86-64-v2

これは、Worker Nodeとして使っているProxmox VMのCPU typeをデフォルトの “kvm64” で動かしており、x86-64-v2命令セットをサポートしていなかったことが原因でした。

解決方法：Proxmox VMのCPU typeを “x86-64-v2-AES” に変更することで解決しました。

kubeadm × ovn-kubernetesのクラスタでService CIDR問題にハマった

Mon, 01 Sep 2025 08:21:31 +0900

はじめに

今回は、自宅サーバーで構築している kubeadm × ovn-kubernetes のKubernetesクラスタで、kubevirtを導入しようとした際に遭遇したService CIDRに関する問題とその解決方法についてお話しします！

kubeadm × ovn-kubernetesを構築した話はこちらの記事で紹介しているので、興味があればこちらもぜひ読んでみてください。

問題の発見

ovn-kubernetesで構築したKubernetesクラスタにkubevirtを導入しようとしたところ、virt-operatorで以下のようなエラーが出始めました。

Internal error occurred: failed calling webhook
"virtualmachineclusterinstancetype-validator.instancetype.kubevirt.io":
failed to call webhook: Post
"https://virt-api.kubevirt.svc:443/virtualmachineclusterinstancetypes-validate?timeout=10s":
context deadline exceeded

どうやらvirt-operatorがVirtualMachineClusterInstanceTypeリソースを作成しようとして、validation webhookがタイムアウトか何かで失敗しているようです。 validation webhookを叩くのはkube-apiserverだと思ったので、kube-apiserver側のログも確認してみました。

kube-apiserver-home-k8s-master01 kube-apiserver W0902 13:48:03.160803
  1 dispatcher.go:217] Failed calling webhook, failing closed
  virtualmachineclusterinstancetype-validator.instancetype.kubevirt.io:
  failed calling webhook
  "virtualmachineclusterinstancetype-validator.instancetype.kubevirt.io":
  failed to call webhook: Post
  "https://virt-api.kubevirt.svc:443/virtualmachineclusterinstancetypes-validate?timeout=10s":
  context deadline exceeded

やはりリソース作成のリクエストを受けたkube-apiserver側でvalidation webhookを叩くのに失敗していそうでした。

原因調査と解決方法

通信テストと原因の絞り込み

普通にvirt-apiのServiceのドメインにアクセスしているように見えるのに、なぜアクセスできないのでしょうか？

まずはkube-apiserverと同じkube-system namespaceにPodを作成してアクセステストをしてみました。

kubeadmでovn-kubernetesのクラスタを構築

Sat, 30 Aug 2025 19:35:25 +0900

1. はじめに

今回は、我が家の自宅サーバーで ovn-kubernetes を使ったKubernetesクラスタを構築した話をしようと思います!

kubeadm, Ansibleを使った自前のKubernetesクラスタ構築や、ovn-kubernetesに興味がある方の参考になれば幸いです。

2. 環境構成

今回の構築環境はこんな感じです。 Nodeは全てProxmox VE上の仮想マシンを利用しています。

Node 構成
- Control Plane Node: 1台（2vCPU、4GiB メモリ）
- Worker Node: 2台（4vCPU、8GiB メモリ）
OS: Ubuntu 24.04 Noble
Kubernetes: v1.33
コンテナランタイム: containerd 2.1.4
ネットワークアドオン: OVN-Kubernetes v1.1.0

Nodeに必要な要件は公式ドキュメントの kubeadmのインストール#始める前にに記載されているので、構築する際はそちらも参考にしてください。

3. 構築手順

実際の構築は全てAnsible Playbookで記述しました。 Proxmox VMを起動して2つのPlaybookを順番に実行するだけで、Kubernetesクラスタが構築されるようになっています。

cluster_bootstrap.yml: Control Planeの初期化とOVN-Kubernetesのインストール
worker_join.yml: Worker NodeをClusterに参加させる

3.1 Playbook構成

Ansible Playbookは以下のような構成になっています。

.
├── group_vars
│   └── all.yml
│── roles/
│   ├── common/              # 全ノード共通の設定
│   │   ├── tasks/
│   │   │   ├── main.yml
│   │   │   ├── swap_off.yml # swapの無効化
│   │   │   ├── resolve.yml  # systemd-resolved設定
│   │   │   ├── containerd.yml # containerdインストール
│   │   │   ├── runc.yml     # runcインストール
│   │   │   ├── cni.yml      # CNIプラグインインストール
│   │   │   └── kube.yml     # Kubernetes関連パッケージ
│   ├── cluster_bootstrap/   # Control Plane初期化
│   │   ├── tasks/
│   │   │   ├── main.yml
│   │   │   ├── kube.yml     # kubeadm init実行
│   │   │   ├── helm.yml     # Helmインストール
│   │   │   └── ovn_kubernetes.yml # OVN-Kubernetes設定
│   └── worker_join/        # Worker Nodeをクラスタに参加
│       └── tasks/
│           └── main.yml     # kubeadm joinの実行
├── cluster_bootstrap.yml
├── inventory.yml
├── requirements.txt
├── requirements.yml
└── worker_join.yml

ここからは、各タスクについて抜粋して解説していきます。

『Ansible実践ガイド[基礎編]』を読んで

Wed, 27 Aug 2025 00:27:48 +0900

1. はじめに

Ansible、使っていますか？

Ansibleは、サーバーの設定管理や自動化を行うためのツールであり、YAML形式のPlaybookを書くことで複数のサーバーに対して一括で任意のタスクを実行できる便利なツールです。

私は今まで業務と趣味の両方でAnsibleを使う機会は多かったのですが、体系的に基礎から学んだことがありませんでした。今回は会社から本を買ってもらえる機会があったため、この機にAnsible実践ガイド[基礎編]を読んでみることにしました。

本を実際に読んでみて思ったこと・感じたことを、率直にまとめてみます。

2. 本の全体的な印象

実際に読んでみると、思っていた以上に初心者向けの内容でした。 Playbookやインベントリの概念や基本的な書き方など、本当に「Ansibleって何？」という人が読んでも理解できそうなレベル感で、学び初めの最初の一冊としては非常にわかりやすくまとまっていると感じました。

逆に、ある程度Ansibleを使った経験がある自分にとっては復習の意味合いが強かったかな、という印象です。しかし、改めて基礎を整理できたのは良かったですし、知らなかった小技もいくつか発見できて読む価値はありました。

3. 特に役立ったポイント

本を読んで幾つか「これは使える！」と思ったものがあったので簡単に紹介します。

3.1 パフォーマンスチューニング

まずは 5-3 パフォーマンスチューニング のセクションに書いてあった以下の内容です。

ファクトキャッシュ の活用
ストラテジプラグイン によるタスク並列処理

ファクトキャッシュ は、Ansibleが管理対象ホストから収集する情報（ファクト）をキャッシュしておく仕組みです。これを使うことで、一度ファクトを収集したホスト上ではその情報を使い回すことができ、2回目以降の実行でPlaybookの実行速度が向上することが期待されます。

ストラテジプラグイン は、Ansibleのタスク実行の順序や並列度を制御するための仕組みです。本著では linear, host_pinned, free の3種類のストラテジプラグインが紹介されていました。

linear: デフォルトのストラテジで、タスクごとに全ホストで待ち合わせて次のタスクに進む。タスクで他ホストのタスク結果に依存するような処理がある場合にも安全。
host_pinned: ホストごとにタスクを進め、待ち合わせはしない。ホスト数がPlayの並列実行数を超える場合は、先にキューに積まれたホストがPlay全体を終了したら残りのホストのPlayが開始される。ホストごとにタスクの順序は保たれるが、他ホストのタスク結果に依存する処理がある場合には注意が必要。
free: ホストごと、タスクごとにキューに積まれるイメージ。全てのホストのタスクが並行実行されるが、同時に実行されるタスクは設定された並列実行数を超えない。host_pinned と同様に、ホストごとにタスクの順序は保たれるが、他ホストのタスク結果に依存する処理がある場合には注意が必要。

“他ホストのタスク結果に依存する処理” というのがパッと思いつかないかもしれませんが、例えば Kubernetes クラスターを構築する Playbook において、ある1つの Control Plane Node で kubeadm init & kubeadm token create をして、残りの Node では kubeadm join を実行するようなタスクが該当します。 kubeadm join のタスクでは kubeadm token create の標準出力を使う必要があるためホスト間でタスク順序の依存が発生し、例えば kubeadm token create が完了する前に kubeadm join のタスクが実行されてしまうと失敗してしまいます。

初めてのKubernetesドキュメント翻訳コントリビュート

Sat, 23 Aug 2025 11:43:00 +0900

今回は、先日初めてKubernetesの公式ドキュメント翻訳にコントリビュートした経験について書いてみようと思います。

きっかけは、kubeadmを使って自宅サーバーのKubernetesクラスターを構築している時のことでした。 Kubernetesの公式ドキュメントの日本語翻訳を見ながら作業を進めていたのですが、 Containerdのcgroup driverをsystemdに変更するための設定の書き方が、Containerdの最新バージョンのものと異なっていることに気づいたんです。

「あれ？設定ファイルの書き方が違うなぁ」と思って英語の原文を確認してみると、ついこの間Containerdの最新バージョンの設定の書き方がドキュメントに追加されていたことを発見しました。

[plugins.'io.containerd.cri.v1.runtime'.containerd.runtimes.runc]
  ...
  [plugins.'io.containerd.cri.v1.runtime'.containerd.runtimes.runc.options]
    SystemdCgroup = true

英語のドキュメントには最新の情報があるのに、日本語版には反映されていない状況を見て、「日本語のドキュメントにも同じ内容があった方が、日本語で情報を探している人にとって便利だよね」と考えました。

自分と同じようにKubernetesクラスターを構築しようとしている人が、古い設定例で困ることもあるかもしれません。そんな時に最新の情報が日本語でも読めるようになっていれば、きっと役に立つはずです。

といった感じで、「それなら自分で翻訳してみよう！」と思い立ったのがコントリビュートのきっかけでした。

コントリビュートしようと決めたものの、実際にどうやって翻訳作業を進めればいいのかわからない状態だったので、まずはkubernetes/websiteのリポジトリのREADMEを確認することから始めました。

READMEには翻訳のコントリビューションに関する情報へのリンクがあったので、そこから辿って以下のドキュメントを読み込みました：

これらのドキュメントを読むことで、翻訳の進め方やコントリビューションのルールについて理解することができました。

ドキュメントを読んだ後は、実際に他の方が翻訳でコントリビュートした際のプルリクエストを見て参考にしました。

実際のPRを見ることで、以下のようなことが分かりました：

コミットメッセージの書き方
ファイルの変更範囲
レビューでのやり取りの雰囲気

やっぱり実際のやり取りを見るのが一番参考になりますね。

今回の翻訳は、Containerdの設定に関する部分だけだったので、それほど大きな分量ではありませんでした。とはいえ、技術的な内容を正確に翻訳することと、既存の日本語ドキュメントの文体に合わせることを心がけました。

最終的にレビューのワンラリーを経て、無事にマージすることができました。

https://github.com/kubernetes/website/pull/51940

とても小さい変更ではありましたが、実際にコントリビュートする際の雰囲気を掴むことができました。

これからも積極的にOSSへのコントリビュートを意識してやっていきたいと思います！

Ansibleで自宅サーバーにBIND9 DNSサーバーを構築

Mon, 11 Aug 2025 16:39:57 +0900

1. はじめに

今回は、Ubuntu 24.04 サーバーにBIND9を使ってDNSサーバーを構築しました!

保守性を考えて Ansible Playbook を使った構築になっています。

2. Ansible Playbook 構成

今回作成したプレイブックの構成はこんな感じです：

home-dns/
├── README.md
├── bind9.yml
├── inventory.yml
├── requirements.txt
└── templates/
    ├── db.j2
    ├── named.conf.local.j2
    └── named.conf.options.j2

シンプルな構成で、最低限必要な機能を提供します。

Task

bind9.ymlがメインのプレイブックです：

- name: Deploy BIND9 DNS Server
  hosts: dns_servers
  become: true
  vars:
    local_network: <LOCAL_NETWORK_CIDR>
    domain_name: <DOMAIN_NAME>

  tasks:
    - name: Update apt cache
      ansible.builtin.apt:
        update_cache: true
        cache_valid_time: 3600

    - name: Install BIND9
      ansible.builtin.package:
        name:
          - bind9
          - bind9utils
          - dnsutils
        state: present

    - name: Configure named.conf.options
      ansible.builtin.template:
        src: named.conf.options.j2
        dest: /etc/bind/named.conf.options
        owner: root
        group: bind
        mode: "0644"
      notify: restart bind9

    - name: Configure named.conf.local
      ansible.builtin.template:
        src: named.conf.local.j2
        dest: /etc/bind/named.conf.local
        owner: root
        group: bind
        mode: "0644"
      notify: restart bind9

    - name: Create zone file
      ansible.builtin.template:
        src: db.j2
        dest: /etc/bind/db.{{ domain_name }}
        owner: root
        group: root
        mode: "0644"
      notify: restart bind9

    - name: Start and enable BIND9
      ansible.builtin.service:
        name: bind9
        state: started
        enabled: true

  handlers:
    - name: restart bind9
      ansible.builtin.service:
        name: bind9
        state: restarted

bind9をインストールし、設定ファイルをテンプレートから生成して配置、bind9 serviceの起動を行います。

cinder-volumeのトラブルシューティングをしたら意外な原因だった

Mon, 11 Aug 2025 11:01:37 +0900

はじめに

我が家には趣味で構築した OpenStack 環境があります（環境の詳細はこちらの記事を参照してください）。

普段はこのブログサイトや GitHub self-hosted runner 等を動かしていてそれなりに安定稼働しているのですが、ある日 Cinder Volume を作成しようとしたところ、なぜか作成に失敗してしまいました。

そこから始まったトラブルシューティングで、最終的にたどり着いた原因が予想外すぎて驚いたので、その経験を共有したいと思います。

問題の発見

新規に VM を作成するために Cinder Volume の作成しようとしたところ、“no host available” みたいなエラーが出て失敗してしまいました。そのため、まずは cinder-volume service の状態を確認してみることにしました。

openstack volume service list

すると、なんと cinder-volume サービスが down になっていました。これが直接の原因のようです。

| Binary           | Host          | Zone | Status  | State | Updated At          |
| ---------------- | ------------- | ---- | ------- | ----- | ------------------- |
| cinder-volume    | block-storage | nova | enabled | down  | 2025-XX-XX XX:XX:XX |
| cinder-scheduler | controller    | nova | enabled | up    | 2025-XX-XX XX:XX:XX |

「あれ、cinder-volume が落ちてる…？」というわけで、調査開始です。

調査

サービスの実態を確認

まず、cinder-volume が本当に停止しているのか確認するため、cinder-volume が動いている block storage ホストに SSH でログインしました。

Claude CodeでNeovim configのVimScriptからLuaへのマイグレーション

Wed, 23 Jul 2025 09:20:05 +0900

1. はじめに

みなさん、Neovimの設定ファイル、メンテナンスしてますか？

私は1年前にVimを本格的に使い始め、その際にVimScriptで書いたNeovimの設定ファイルを使い続けていました。「いつかLuaに移行しなきゃなぁ…」と思いながらも、面倒くさくてずっと後回しにしていました。

そんな中、最近話題のClaude Codeを触る機会があり、「これを使ったら設定ファイルを楽にマイグレーションできるんじゃないか？」と思い立ちました。重い腰を上げて、ついにVimScript → Luaの移行に挑戦してみることにしたのです。

私の既存の設定は、「マスタリングVim」にインスパイアされて作成し、使っていきながら様々なプラグインやキーバインドを追加していったものでした。プラグイン管理にはvim-plugを使い、基本設定からキーマッピング、カスタム関数まで全て “単一の” VimScriptファイルに記述していたため、管理するのが辛いものとなっていました。

特に抱えていた課題としては：

新しいLuaベースのプラグインを導入しにくい
設定の可読性・保守性が悪い
パフォーマンスの問題（起動が遅い）

といった点がありました。

2. Neovimの設定について

Neovimは従来のVimScriptに加えて、Lua言語での設定記述をサポートしています。 Luaを使うことで以下のメリットが得られます：

豊富なエコシステム: 多くの新しいプラグインがLuaベースで開発されている
保守性: 管理しやすいようにディレクトリ・ファイルへの分割が容易
可読性: より直感的で読みやすい文法
高速: VimScriptと比べて大幅に高速

特に最近のNeovimプラグインの、nvim-treesitter、nvim-lspconfig, none-lsなどを利用して、楽にそして柔軟に設定の管理を行いたいモチベーションがありました。

3. 移行戦略の立案

既存のVimScript設定を分析してみると、大きく以下のカテゴリに分類できることがわかりました：

プラグイン管理: vim-plugによるプラグインのインストールと管理
基本設定: オプション設定、外観設定
キーマッピング: 基本的なキーバインドとカスタムマッピング
プラグイン設定: 各プラグインの個別設定
カスタム関数: 自作の関数やコマンド

Lua設定では、これらを機能ごとにファイル分割して整理しやすいが大きなメリットです。移行後は以下のような構造で整理しました：

~/.config/nvim/
├── init.lua                    # エントリーポイント
├── after/
│   └── lsp/                    # LSP固有設定
│       ├── gopls.lua
│       └── lua_ls.lua
└── lua/
    ├── config/                 # 基本設定群
    │   ├── edit.lua            # 編集関連設定
    │   ├── lazy.lua            # プラグイン管理（lazy.nvim）
    │   ├── search.lua          # 検索関連設定
    │   ├── view.lua            # 見た目関連設定
    │   ├── window.lua          # ウィンドウ関連設定
    │   └── langs/              # 言語固有設定
    │       ├── c.lua
    │       ├── go.lua
    │       ├── terraform.lua
    │       └── yaml.lua
    └── plugins/                # プラグイン設定群
        ├── completion.lua
        ├── copilot.lua
        ├── deepl.lua
        ├── edit.lua
        ├── lang.lua
        ├── lsp.lua
        ├── navi.lua
        ├── search.lua
        ├── session.lua
        ├── sql.lua
        └── view.lua

この構造により、機能ごとに設定が整理され、管理しやすくなりました。

自宅OpenStackのAnsible解説

Sun, 23 Mar 2025 18:20:31 +0900

みなさんこんにちは。

今回は、私が自宅クラウドのOpenStackを構築するのに使っているAnsibleを題材にして、Ansibleの基本的な使い方について紹介したいと思います。業務で使っているものとは何の関係もないので、これをこのまま本番環境で使える、みたいなものではないです。ご注意ください。

1. Ansibleのディレクトリ構成

以下が本記事で使用するAnsibleのディレクトリ構成です。 ~~全てのソースコードを見たい方はこちらからどうぞ。~~ 諸事情によりprivate repoにしました。🙏

なおOpenStackにはちゃんと公式のAnsible Playbookもありますが、今回は自分で作ってみたかったため作りました。

.
├── compute.yml
├── controller.yml
├── database.yml
├── inventory.yml
├── requirements.txt
├── roles
│   ├── common
│   │   └── tasks
│   │       └── main.yml
│   ├── compute
│   │   ├── files
│   │   │   └── chrony.conf
│   │   ├── handlers
│   │   │   └── main.yml
│   │   ├── tasks
│   │   │   ├── main.yml
│   │   │   ├── neutron.yml
│   │   │   ├── nova.yml
│   │   │   └── ntp.yml
│   │   └── templates
│   │       ├── neutron.conf.j2
│   │       ├── nova-compute.conf.j2
│   │       ├── nova.conf.j2
│   │       └── openvswitch_agent.ini.j2
│   ├── controller
│   │   ├── files
│   │   │   ├── apache2.conf
│   │   │   ├── apache2_openstack_dashboard.conf
│   │   │   ├── dhcp_agent.ini
│   │   │   ├── horizon_local_settings.py
│   │   │   └── ml2_conf.ini
│   │   ├── handlers
│   │   │   └── main.yml
│   │   ├── tasks
│   │   │   ├── cinder.yml
│   │   │   ├── etcd.yml
│   │   │   ├── glance.yml
│   │   │   ├── horizon.yml
│   │   │   ├── keystone.yml
│   │   │   ├── main.yml
│   │   │   ├── memcached.yml
│   │   │   ├── neutron.yml
│   │   │   ├── nova.yml
│   │   │   ├── ntp.yml
│   │   │   ├── placement.yml
│   │   │   └── rabbitmq.yml
│   │   └── templates
│   │       ├── chrony.conf.j2
│   │       ├── cinder.conf.j2
│   │       ├── etcd.j2
│   │       ├── glance-api.conf.j2
│   │       ├── keystone.conf.j2
│   │       ├── memcached.conf.j2
│   │       ├── metadata_agent.ini.j2
│   │       ├── neutron.conf.j2
│   │       ├── nova.conf.j2
│   │       ├── openvswitch_agent.ini.j2
│   │       └── placement.conf.j2
│   ├── database
│   │   ├── handlers
│   │   │   └── main.yml
│   │   ├── tasks
│   │   │   ├── create_user.yml
│   │   │   ├── main.yml
│   │   │   └── secure_installation.yml
│   │   └── templates
│   │       └── 99-openstack.cnf.j2
│   └── openstack
│       └── tasks
│           └── main.yml
└── vars
    ├── credentials.yml
    └── vars.yml

エントリポイントとなるplaybook

我が家のOpenStack server

Sun, 23 Mar 2025 17:33:34 +0900

⚠️ 本記事の執筆には生成AIを大いに利用しています。

こんにちは。みなさん、自宅サーバしてますか？してますよね？

というわけで、今回は私が自宅サーバで運用しているOpenStack環境を、ハードウェア/ソフトウェア両面の構成、さらにちょっとしたこだわりポイントまで、まるっと紹介したいと思います。

（ちなみに、このブログも自宅のOpenStack環境で動いています！）

1. 我が家のOpenStack、ざっくり概要

OpenStack バージョン: 2024.02 “Dalmatian”
OS: Ubuntu 24.04 “Noble”
構成:
- Management Node × 1（iPXE / DHCP / DNSサーバ）
- Controller Node × 1
- Compute Node × 2
- Block Storage Node × 1
用途:
- インテリア（！？）
- 仮想化の勉強
- OSSを動かして遊ぶ
- ISUCONの練習とか

2. ハードウェア構成

ここからはハードウェアの構成を紹介していきます。ちなみに見た目はこんな感じです。

ルータ

YAMAHA RTX810
- 家庭内LANとの境界に設置しているVPNルータ
- L2TP/IPSecで外出先でもVPN接続可能！（後述）
Buffalo BHR-4GRV2
- VMセグメントのゲートウェイ
- 有線ルータ
- DMZ機能を利用して管理セグメントからVMへの通信を通せて便利
NEC WG2600HS2
- 管理セグメントのゲートウェイ
- Wi-Fiを喋れるので管理面への接続が楽ちん
- DMZ機能なしのため、VPNセグメントからの通信はポートフォワーディングで対応

L2スイッチ

ELECOM EHC-G08MN2-HJB
- 1Gbps × 8ポート
- VMセグメント用
FOXNEO

Mastering KVM Virtualization を読んだ感想

Sun, 02 Feb 2025 15:16:04 +0900

はじめに

やっと自宅サーバでブログを動かすことができたので、ここ数ヶ月ずっと読んでいてようやく読み終わった本の感想を書こうと思います。本のタイトルは「Mastering KVM Virtualization」というやつで、仮想化周り、特にQEMU/KVMについて詳しく知りたかったので読んでみました。リンクを貼っておくので、気になる方は是非読んでみてください。

Amazon | Mastering KVM Virtualization

本の概要

この本はQEMUやKVMを中心としたLinuxの仮想化機能、またそれらを管理するシステムについての概要を述べている本です。洋書で結構分厚い本なのでかなり読み応えがあります。

全体として、各トピックについてそこそこ詳しく記載されているが、Deep Diveというほどではない感じです。例えば、QEMUやKVMのソースコードレベルでの解説等はほとんどありません（序盤に少しだけある）。

本の構成は以下の様になっています。

Section 1: KVM Virtualization Basics
- 1. Understanding Linux Virtualization
- 1. KVM as a Virtualization Solution
Section 2: Libvirt and ovirt for Virtual Machine Management
- 1. Installing KVM Hypervisor, libvirt, and ovirt
- 1. Libvirt Networking
- 1. Libvirt Storage
- 1. Virtual Display Devices and Protocols
- 1. Virtual Machines: Installation, Configuration, and Life Cycle Management
- 1. Creating and Modifying VM Disks, Templates, and Snapshots
Section 3: Automation, Customization, and Orchestration for KVM VMs
- 1. Cusomizing a Virtual Machine with cloud-init
- 1. Automated Windows Guest Deployment and Customization
- 1. Ansible and Scripting for Orchestration and Automation
Section 4: Sclability, Monitoring, Performance Tuning, and Troubleshooting
- 1. Scaling Out KVM with OpenStack
- 1. Scaling out KVM with AWS
- 1. Monitoring the KVM Virtualization Platform
- 1. Performance Tuning and Optimization for KVM VMs
- 1. Trouble Shooting Guidelines for the KVM Platform

「Section 1: KVM Virtualization Basics」ではKVMや仮想化技術に関する基本のおさらいをしてくれます。そもそも仮想化とは何か、なぜするのかとか、仮想化の種類、仮想化の対象、そしてLibvirtやQEMU、KVMがそれぞれ何なのかみたいなことも説明されていました。

2025年の抱負

Sun, 19 Jan 2025 09:33:24 +0000

はじめに

記念すべき1記事目ということで何を書こうか迷いに迷ったんですが、丁度2025年の始まりなので、ここは一つ新年の抱負でも書こうかなと思います。

昨年の感想

新年の抱負を書くにあたって、やっぱ昨年を振り返る必要があります。

2024年は自分にとって新鮮な年でした。今までの人生の大半を占めてきた “学生” という身分をやっと捨て、新社会人として新たな一歩を踏み出したのは非常に感慨深いです。また新たな土地、新たな家、新たな人間関係の中で、“仕事” という今までとは違う形でエンジニアリングに取り組み、日々新たな刺激がたくさんでした。

慣れないながらもなんとなく仕事に取り組み、ある程度やるべきことはこなせた気はするのですが、日々仕事をしている中で自分の知識や経験不足をいたく痛感する毎日でした。昨年感じた自分の能力の不足を糧に、今年は頑張っていきたいです。

今年の抱負

さて、今年頑張りたいことはざっくりこんな感じです。

仮想化技術の習熟
OS周りの知識を深める
eBPFに詳しくなる
積極的に自作して公開する
アウトプット
作業の高速化
健康の推進

1つずつ詳しく見ていきましょう。

1. 仮想化技術の習熟

自分は仕事でプライベートクラウドのIaaS基盤の開発・運用をしており、業務の中でOpenStackを中心としたいろん技術を日々触っています。

その中で痛感したのが、仮想化周りの技術に関する前提知識の欠落です。前提となる知識が圧倒的に不足しているがために、業務において適切に判断を下せなかったり、時間がかかったりしてしまいます。

仮想化といっても幅広く、CPU、メモリ・IOデバイスなどのハードウェアの仮想化の技術だったり、OVSなどの仮想ネットワークの技術など色々あります。ここら辺は奥が深く非常に面白いので、もっと理解してあげたいことこの上ないです。

2. OS周りの知識を深める

上記にも関連してきますが、クラウド基盤を開発・運用する上で必要なOS、特にLinuxに関する知識も圧倒的に不足していると感じています。基本的なコマンドとかディレクトリ設計とかはわかっているんですが、ファイルシステムの仕組みとか、プロセスのスケジューリングとか、ブート時に何が行われているのかとか、ハードウェアを操作する際に実際に何が行われているのかとか分からないことだらけです。

丁度友人がOS自作本をおすすめてしてくれたので、そちらをやったりしながらもっと知識を深めていければと思います。

3. eBPFに詳しくなる

ここまでとは打って変わりますが、個人的にeBPFにすごく興味があります。学生の時に知ってチュートリアルレベルのコードは書いたことくらいはあるんですが、Ciliumとかの実際にプロダクション環境でも使われている大規模なeBPFベースのプロダクトとかの中身を見たことがないので、そういうのを見て勉強したいですし、自分でも適当に色々書いてみたいです。

eBPFは技術的にももちろん興味があるんですが、それとは別に、比較的新しめでまだそこまで情報も出ていなくて枯れていない技術をキャッチアップする、というのを学習の戦略としてやっておきたいというのも動機として大きいです。

4. 積極的に自作して公開する

今までは趣味で作ってきたものも、既存の言語とフレームワークを使って開発し、既存のパブリッククラウドを使ってデプロイすることが多かった、というかほとんどでした。もちろんソフトウェア開発の基礎を学ぶ上ではとてもいい方法で、実際の仕事でも既存のものを使うのは推奨されていると思います。

しかし技術を学び、身につけるという観点で言うといいことばかりではなく、既存のものをただ使うだけでは深い学びは得られません。これからは、趣味で作るものに関しては積極的に自作していきたいなと思います。むしろ自作そのものを目的にするのも悪くないと思っています。

ソフトウェア開発をする際に自作のフレームワークを使ってみたり、自作の言語を開発してみたり、またコンパイラやOSの自作にも挑戦したいです。そうして作ったものをGitHubで公開したり、ブログやLTなどで積極的に発信し、自分がどんなことをしてる人なのかを積極的に周りに伝えるとともに自作のモチベーションにも繋げたいです。また、既存のソフトウェアを使うにしてもコアな機能の使用やコアな使い方を積極的にし、見つけた機能不足やバグをアップストリームに上げることもしていきたいです。

5. アウトプット

上記の事項にも関係しますが、今年はアウトプットを積極的にしていきたいです。

アウトプットを前提にすることでインプットの質向上が見込めたり、そもそもいろんなことを学ぶモチベーションにもなったりします。また、自分の作っているものや学んでいることを公開することで、自分が何者なのかを社内や業界内に認知してもらえることにつながると思います。

6. 作業の高速化

仕事をしていて一番痛感したのが、作業の遅さが致命的だと言うことです。何をするにしても無駄な思考が多く、同じことを何度も繰り返し考えているような感覚に陥ります。もちろん、作業を早くするために手を抜くと言うのは論外なんですが、作業が遅いと寧ろ本当はやるべきことに手をつけられず、結果的に手を抜いているのと同じことになるので、作業の速さは絶対に必要です。

自分の好きな言葉に、「力は技を制し、技は力を制す。そして、速さは全てを制す。」と言うものがあります。エンジニアリングで例えると、力は頭脳や思考力、技は知識と考えていいかと思いますが、作業の速さは、それら全てを凌駕するほどの価値があります。 1秒間に何十億もの超単純な計算を実行することでこの世界を支えているCPUを見ればわかるように、作業の量が質を圧倒することは自明です。

今年は、何をするにしても “速さ” を意識していきたいと思います。

7. 健康の推進

さて、いよいよ最後になりましたが、今年はこれまで以上に健康に気を遣って生きていきたいなと感じています。

社会人になって圧倒的に運動量が減り、そのせいか体や頭にあちこち不調が出ているような気がします。食事や睡眠は学生の時と比べて今の方が圧倒的に良くなったので、運動だけ意識するようにして、とりあえず徒歩での通勤と家での筋トレをゆるく継続していきたいです。