kkato.dev

GitHub Container Registry (ghcr.io) の使い方

Sat, 28 Feb 2026 12:00:00 +0900

GitHub Container Registry (ghcr.io) は、GitHub が提供するコンテナイメージのレジストリです。 Public Packages であれば無料で利用でき、GitHub Actions と組み合わせることでデータ転送料金も無料になります。

ghcr.io は2通りの使い方があります。

ローカルから Docker CLI を使ってイメージをビルドしてプッシュする方法
GitHub Actions を使ってコードの変更に合わせて自動でイメージをビルドしてプッシュする方法

今回はGitHub Actions を使って自動でイメージをビルドしてプッシュする方法を紹介します。

GitHub Actions から自動でプッシュする

GitHub Actions を使えば、コードをプッシュするだけで自動的にイメージのビルドとプッシュができます。以下はワークフローの例です。

name: Docker Build and Push

on:
  push:
    branches:
      - main

# GHCR へのプッシュには packages: write が必要
permissions:
  contents: read
  packages: write

jobs:
  build-and-push:
    runs-on: ubuntu-latest

    steps:
      # ソースコードをチェックアウト
      - name: Check out code
        uses: actions/checkout@v4

      # ghcr.io にログイン
      - name: Log in to GitHub Container Registry
        uses: docker/login-action@v2
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          # デフォルトの GITHUB_TOKEN を利用
          password: ${{ secrets.GITHUB_TOKEN }}

      # Docker イメージをビルドしてプッシュ
      - name: Build and push Docker image
        uses: docker/build-push-action@v6
        with:
          context: .
          push: true
          tags: ghcr.io/${{ github.repository }}:latest

トラブルシューティング

GitHub Actions から ghcr.io にプッシュする際に、以下のようなエラーが出ました。

PostgreSQL Operatorの比較

Fri, 20 Feb 2026 15:00:00 +0900

Kubernetes上でPostgreSQLを運用するためのOperatorが複数存在します。以前どれを選ぶか検討する機会があったので、主要な4つのオペレーターを比較してみました。

比較表

	PGO	CloudNativePG	Zalando	StackGres
開発元	Crunchy Data	EDB / CNCF	Zalando	OnGres
GitHub Stars	4,400	8,000	5,100	1,400
ライセンス (Operator)	Apache 2.0	Apache 2.0	MIT	AGPL-3.0
ライセンス (コンテナイメージ)	独自 (制限あり)	Apache 2.0	MIT	AGPL-3.0
Patroni	使用	不使用 (独自実装)	使用 (Patroni開発元)	使用
CNCF	-	Sandbox	-	-

Star History

各オペレーターの特徴

PGO (Crunchy Data)

Crunchy Data社が開発するオペレーターで、Patroniを使ったHAに対応しています。Operator自体のソースコードはApache 2.0ですが、Crunchy Data が配布するコンテナイメージは独自のライセンス（Crunchy Data Developer Program）で提供されています。50名以上の組織では本番利用に有償サブスクリプションが必要になるため、注意が必要です。自前でイメージをビルドすれば回避できますが、手間がかかります。

CloudNativePG

EDBが開発を始め、現在はCNCF Sandboxプロジェクトになっています。Patroniに依存せず、独自のInstance Managerが各Pod内で動作し、Kubernetes APIを直接利用してリーダー選出やフェイルオーバーを行います。ライセンスもOperator・コンテナイメージともにApache 2.0で、制限なく利用できます。Star数も最も多く、コミュニティの勢いがあります。

Argo CDをインストールしてみた

Fri, 20 Feb 2026 11:00:00 +0900

Argo CDはKubernetes向けのGitOpsツールで、Gitリポジトリに置いたマニフェストをクラスタに自動で反映してくれます。今回はHelmを使ってArgo CDをインストールし、リポジトリの接続からApplicationの作成までを試してみました。

Argo CDのインストール

Helm Chartリポジトリを追加します。

helm repo add argo https://argoproj.github.io/argo-helm
helm repo update

argocd namespaceにインストールします。

helm install argocd argo/argo-cd \
  --namespace argocd \
  --create-namespace \
  --version 7.8.13

Podが正常に起動していることを確認します。

kubectl get pods -n argocd

Argo CD UIにアクセスする

port-forwardでArgo CDのUIにアクセスできます。

kubectl port-forward svc/argocd-server -n argocd 8080:443

ブラウザで http://localhost:8080 にアクセスします。

初期パスワードは以下のコマンドで取得できます。ユーザー名はadminです。

kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d

Gitリポジトリを接続する

Argo CDがGitリポジトリからマニフェストを取得するために、リポジトリの接続設定が必要です。

SSH鍵の作成

Argo CD専用のSSH鍵を作成します。

ssh-keygen -t ed25519 -f ~/.ssh/argocd -C "argocd" -N ""

GitHubにDeploy Keyを登録

生成した公開鍵をリポジトリのDeploy Keyとして登録します。

vim tips

Sun, 01 Feb 2026 17:39:47 +0900

移動

キー	説明
`}` / `{`	次/前の空行へ移動
`%`	対応する括弧へ移動

Operator と Text Object

Operator	説明
`c`	change
`d`	delete
`y`	yank
`v`	visual

Text Object は i（inner: 内側のみ）と a（a: 囲み文字も含む）の2種類がある。

Text Object	説明
`iw`	単語の内側
`aw`	単語 + 周囲の空白
`i"`	`"..."` の内側
`a"`	`"..."` 全体（引用符含む）
`i(`	`(...)` の内側
`a(`	`(...)` 全体（括弧含む）
`i{`	`{...}` の内側
`a{`	`{...}` 全体（波括弧含む）
`it`	HTMLタグの内側
`at`	HTMLタグ全体（タグ含む）

例	説明
`ciw`	単語を削除して挿入モード
`di"`	ダブルクォート内を削除
`ya(`	括弧ごとコピー

参考文献

なれる! Vimmer

netrwの操作コマンド

Sun, 01 Feb 2026 17:25:44 +0900

netrw（Neovim内蔵ファイルブラウザ）

キー / コマンド	動作
`:Ex`	カレントディレクトリを開く
`:Vex`	垂直分割で開く
`:Sex`	水平分割で開く
`<CR>`	ファイル/ディレクトリを開く
`v`	垂直分割で開く
`o`	水平分割で開く
`t`	タブで開く
`%`	新規ファイル作成
`d`	ディレクトリ作成
`D`	削除
`R`	リネーム
`-`	上のディレクトリへ
`i`	表示形式を切り替え

ペイン操作

キー / コマンド	動作
`:vs ファイル名`	垂直分割でファイルを開く
`:sp ファイル名`	水平分割でファイルを開く
`Ctrl+w h/j/k/l`	左/下/上/右へ移動
`Ctrl+w c`	閉じる
`Ctrl+w o`	他を全て閉じる
`Ctrl+w =`	均等サイズ

タブ操作

キー / コマンド	動作
`:tabnew`	新規タブ
`:tabe ファイル名`	ファイルをタブで開く
`gt` / `gT`	次/前のタブ
`:tabclose`	タブを閉じる

Kubernetesをv1.30からv1.31にアップグレードした

Sat, 24 Jan 2026 20:11:09 +0900

自宅で運用しているKubernetesクラスターをv1.30からv1.31にアップグレードしました。 kubeadmを使った標準的なアップグレード手順ですが、忘れがちなので備忘録として残しておきます。

公式ドキュメント: https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/

コントロールプレーンノードのアップグレード

コントロールプレーンノードから順番にアップグレードしていきます。

パッケージリポジトリの変更

まず、yumリポジトリの設定ファイルをv1.31用に変更します。

変更前（v1.30）:

[kkato@nuc01 ~]$ cat /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://pkgs.k8s.io/core:/stable:/v1.30/rpm/
enabled=1
gpgcheck=1
gpgkey=https://pkgs.k8s.io/core:/stable:/v1.30/rpm/repodata/repomd.xml.key
exclude=kubelet kubeadm kubectl cri-tools kubernetes-cni

変更後（v1.31）:

$ cat /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://pkgs.k8s.io/core:/stable:/v1.31/rpm/
enabled=1
gpgcheck=1
gpgkey=https://pkgs.k8s.io/core:/stable:/v1.31/rpm/repodata/repomd.xml.key
exclude=kubelet kubeadm kubectl cri-tools kubernetes-cni

参考: https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/change-package-repository/

kubeadmのアップグレード

まずkubeadmパッケージをアップグレードします。

sudo yum upgrade kubeadm --setopt=disable_excludes=kubernetes

アップグレード可能なバージョンを確認します。

sudo kubeadm upgrade plan

Components that must be upgraded manually after you have upgraded the control plane with 'kubeadm upgrade apply':
COMPONENT   NODE      CURRENT   TARGET
kubelet     nuc01     v1.30.1   v1.31.14
kubelet     nuc02     v1.30.1   v1.31.14
kubelet     nuc03     v1.30.1   v1.31.14
kubelet     nuc04     v1.30.1   v1.31.14

Upgrade to the latest stable version:

COMPONENT                 NODE      CURRENT    TARGET
kube-apiserver            nuc01     v1.30.4    v1.31.14
kube-controller-manager   nuc01     v1.30.4    v1.31.14
kube-scheduler            nuc01     v1.30.4    v1.31.14
kube-proxy                          1.30.4     v1.31.14
CoreDNS                             v1.11.1    v1.11.3
etcd                      nuc01     3.5.12-0   3.5.24-0

You can now apply the upgrade by executing the following command:

        kubeadm upgrade apply v1.31.14

アップグレードを実行します。

GORMの基本的な使い方

Sat, 17 Jan 2026 22:22:44 +0900

最近、Goを勉強していてGORMを触る機会があったので、基本的な部分を調べてみました。

モデル定義

GORMでは構造体をそのままテーブルにマップします。gorm.Modelを埋め込むとIDやCreatedAtなど便利なカラムが自動で付きます。

package main

import "gorm.io/gorm"

type User struct {
    gorm.Model
    Name  string
    Email string `gorm:"uniqueIndex"`
    Age   uint
}

DB接続とマイグレーション

PostgreSQLを例に、DBへ接続し、モデルに沿ってテーブルを自動生成します。dsnは環境に合わせて書き換えてください。

package main

import (
    "log"

    "gorm.io/driver/postgres"
    "gorm.io/gorm"
)

func main() {
    dsn := "host=localhost user=postgres password=postgres dbname=app port=5432 sslmode=disable"
    db, err := gorm.Open(postgres.Open(dsn), &gorm.Config{})
    if err != nil {
        log.Fatal(err)
    }

    // モデルに合わせてテーブルを作成・更新
    if err := db.AutoMigrate(&User{}); err != nil {
        log.Fatal(err)
    }
}

CRUD操作

基本的なCRUD操作は以下のように行います。

package main

import (
    "fmt"
    "log"

    "gorm.io/driver/postgres"
    "gorm.io/gorm"
)

type User struct {
    gorm.Model
    Name  string
    Email string `gorm:"uniqueIndex"`
    Age   uint
}

func main() {
    dsn := "host=localhost user=postgres password=postgres dbname=app port=5432 sslmode=disable"
    db, err := gorm.Open(postgres.Open(dsn), &gorm.Config{})
    if err != nil {
        log.Fatal(err)
    }
    if err := db.AutoMigrate(&User{}); err != nil {
        log.Fatal(err)
    }

    // CREATE: レコードを追加
    alice := User{Name: "Alice", Email: "alice@example.com", Age: 28}
    if err := db.Create(&alice).Error; err != nil {
        log.Fatal(err)
    }

    // READ: 1件取得（主キーまたは条件指定）
    var user User
    if err := db.First(&user, "email = ?", "alice@example.com").Error; err != nil {
        log.Fatal(err)
    }
    fmt.Printf("found: %+v\n", user)

    // UPDATE: 1カラム更新（モデルを指定）
    if err := db.Model(&user).Update("Age", 29).Error; err != nil {
        log.Fatal(err)
    }

    // DELETE: ソフトデリート（DeletedAtにタイムスタンプが入る）
    if err := db.Delete(&user).Error; err != nil {
        log.Fatal(err)
    }
}

よく使うクエリの書き方

// 条件付きで複数取得
var users []User
db.Where("age >= ?", 25).Order("age desc").Limit(5).Find(&users)

// 複数カラムをまとめて更新
db.Model(&user).Updates(map[string]interface{}{
    "Name": "Alice Updated",
    "Age":  30,
})

参考

Go 1.22のHTTPルーティング改善について

Mon, 29 Dec 2025 12:56:44 +0900

最近、Goの勉強をしているんですが、その中で Gin・Echo・chi など多くの選択肢があり、どのフレームワーク（ライブラリ）を選ぶべきか迷いました。そんな中、Go 1.22（2024年2月リリース）から標準ライブラリのhttp.ServeMuxが強化されたことを知りました。今回は、Go 1.22でのServeMuxの改善点について調べてみました。

これまでのServeMux（Go 1.21以前）の課題

Go 1.21以前のServeMuxには、以下のような制約がありました。

HTTPメソッドを指定できない

// Go 1.21以前: HTTPメソッドの区別ができない
mux := http.NewServeMux()
mux.HandleFunc("/users", func(w http.ResponseWriter, r *http.Request) {
    // GET、POST、PUT、DELETEなど、すべてのHTTPメソッドがこのハンドラに来る
    // 自分でメソッドを判定する必要があった
    switch r.Method {
    case http.MethodGet:
        // GETの処理
    case http.MethodPost:
        // POSTの処理
    default:
        http.Error(w, "Method not allowed", http.StatusMethodNotAllowed)
    }
})

このように、メソッドごとに処理を分けたい場合は、自分でswitch文を書く必要がありました。

パスパラメータを扱えない

// Go 1.21以前: パスパラメータが使えない
// /users/123 のような動的なパスを扱うには、自分でパースが必要
mux.HandleFunc("/users/", func(w http.ResponseWriter, r *http.Request) {
    // URLからIDを手動で抽出する必要があった
    id := strings.TrimPrefix(r.URL.Path, "/users/")
    fmt.Fprintf(w, "User ID: %s", id)
})

完全一致が難しい

// Go 1.21以前: /users にアクセスしたかったが、/users/ も /users/abc もマッチしてしまう
mux.HandleFunc("/users", handler)
// これは /users だけでなく /users/ にもマッチする

こうした課題から、多くのプロジェクトでサードパーティのルーターライブラリが使われていました。

Go 1.22での新機能

Go 1.22では、これらの課題を解決する3つの大きな機能が追加されました。

Helmコマンドまとめ

Sat, 27 Dec 2025 09:37:48 +0900

HelmはKubernetes向けのパッケージマネージャーで、複雑なアプリケーションのデプロイを簡単にしてくれるツールです。 Helmコマンドをよく忘れてしまうので、基本的なコマンドを備忘録としてまとめました。

リポジトリの追加

# リポジトリを追加する
helm repo add stable https://charts.helm.sh/stable
helm repo add bitnami https://charts.bitnami.com/bitnami

リポジトリの一覧表示

# 追加されているリポジトリを確認する
helm repo list

リポジトリの更新

# リポジトリのインデックスを更新する（新しいチャートバージョンを取得）
helm repo update

チャートの検索

# リポジトリからチャートを検索する
helm search repo nginx
helm search repo mysql

チャート情報の表示

# チャートの詳細情報を表示する
helm show chart bitnami/nginx
helm show values bitnami/nginx

インストール

# チャートをインストールする
helm install my-nginx bitnami/nginx

# 名前空間を指定してインストール
helm install my-nginx bitnami/nginx -n production --create-namespace

# カスタム値でインストール
helm install my-nginx bitnami/nginx --set service.type=LoadBalancer

リリース一覧の表示

# インストール済みのリリースを表示する
helm list

# 全ての名前空間のリリースを表示する
helm list -A

# 特定の名前空間のリリースを表示する
helm list -n production

リリース情報の確認

# リリースの詳細情報を表示する
helm get all my-nginx

# リリースの設定値を表示する
helm get values my-nginx

# リリースの履歴を表示する
helm history my-nginx

アップグレード

# リリースをアップグレードする
helm upgrade my-nginx bitnami/nginx

# 新しい値でアップグレード
helm upgrade my-nginx bitnami/nginx --set image.tag=1.21.0

ロールバック

# 前のバージョンにロールバックする
helm rollback my-nginx

# 特定のリビジョンにロールバックする
helm rollback my-nginx 2

アンインストール

# リリースを削除する
helm uninstall my-nginx

# 名前空間を指定して削除
helm uninstall my-nginx -n production

ドライラン

実際にはインストールせずに、何が実行されるかを確認できます。

kubectlで全てのリソースをgetする方法

Mon, 11 Aug 2025 13:02:00 +0900

kubectl get allだとCustom Resourceが表示されないので、全てのリソースが表示できずに困ることがありました。kubectl api-resourcesを使えば、Custom Resourceを含めた全てのリソースを表示することができます。

全てのリソースを表示する

以下のコマンドで、特定のnamespaceに存在する、全てのリソース(Custom Resourceも含めて)を表示することができます。

kubectl get $(kubectl api-resources --verbs=list --namespaced -o name | grep -v "events" | tr '\n' ',' | sed 's/,$//') -n openebs

kubectl api-resources: クラスター内のCustom Resourceを含む全てのKubernetesリソース名を表示
--verbs=list: list操作が可能なものに絞る
--namespaced: 名前空間に属するリソース名に絞る (NamespaceやNodeなどのcluster-scopedリソースは対象外)
-o name: kubectlでgetできるリソース名だけを出力
grep -v "events": eventsリソースは大量に出力されてしまうため、除外する
tr '\n' ',': 出力されたリソース名を、改行区切りからカンマ区切りに変換
sed 's/,$//': 末尾に付いてしまった余分なカンマを削除

kubectlとjqコマンドの便利な組み合わせ

Sun, 10 Aug 2025 19:52:30 +0900

jqコマンドとは、JSON形式のデータを処理・変換するためのコマンドです。普段はkubectlやAWS CLIと組み合わせて使うことが多いのですが、使い方やオプションをきちんと調べたことがなかったため、改めておさらいしようと思います。

keys関数

これまではjq '.'のように全階層をまとめて表示してキーを把握していましたが、keys関数を使うと一階層ずつキーを表示できます。

# labelのキーを取得する
kubectl get pod my-pod -o json | jq '.metadata.labels | keys'

select関数

select関数は条件にマッチした項目のみを抽出します。

# Running状態ではないPodの一覧を取得する
kubectl get pods -A -o json | jq '.items[] | select(.status.phase != "Running") | .metadata.name'

# namespace、Pod名、Podの状態も合わせて表示する
kubectl get pods -A -o json | jq -r '.items[] | select(.status.phase != "Running") | "\(.metadata.namespace) \(.metadata.name) \(.status.phase)"' | column -t

2つ目のコマンドではいくつかのオプションや機能を使っているため、それらについて説明します。

-r: ダブルクォートを削除するオプション(デフォルトでは"が付いてくる)
"\(filter)": 文字列の中で \(filter) を使うことで、抽出した値を文字列に埋め込める。これにより、複数の値を空白区切りで1行に表示できる
columnt -t: columnコマンドの-tオプションを使うことで、区切り文字を基準に列を揃えて表形式で表示できる

contains関数

contains関数は指定した文字列が含まれていればtrueを返します。

# コンテナ名に'ghr.io'を含むPodを検索する
kubectl get pods -o json | jq '.items[] | select(.spec.containers[].name | contains("gcr.io")) | .metadata.name'

まとめ

kubectl と jq の組み合わせは業務でよく使っていたものの、正直ちゃんと理解できていなかった部分も多かったので、今回改めておさらいできてよかったです。特に keys や select、contains などの関数を使うと、複雑な JSON から必要な情報をサクッと抜き出せるのが便利だなと感じました。

Renovateの導入方法

Tue, 06 May 2025 15:27:19 +0900

手動での依存パッケージのアップデートが大変だったので、Renovateを導入してみました。その手順と設定について簡単にメモします。

Renovateとは？

Renovateは、依存関係の更新を自動化してくれるOSSのツールです。元々は個人開発から始まり、現在はイスラエルのセキュリティ企業 Mend社によって開発されています。

リポジトリ内の依存関係をスキャンし、新しいバージョンが利用可能な場合には自動でPull Request（PR）を作成してくれます。 Node.jsのnpmやyarnはもちろん、Go modules、Docker、Terraformなど多くの言語やパッケージマネージャーに対応しています。

対応しているパッケージマネージャーの一覧はこちらにあります。

導入手順

renovateはセルフホストする方法とGitHub Appを使う方法の2通りありますが、手軽に使いたいので、今回はGitHub Appを使って導入します。

https://github.com/apps/renovate から「Configure」を押す

全てのリポジトリを選択し、導入する

全てのリポジトリを選択したとしても、renovateの設定ファイルがあるリポジトリのみrenovateが有効になります。そのため、renovateの設定ファイルがないリポジトリではrenovateが無効化されます。

renovateの設定ファイルrenovate.jsonを作成し、リポジトリのrootにpushする

各リポジトリでConfigure RenovateというPull Requestが自動的に作成されます。

自動生成されたrenovate.json

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": [
    "config:recommended"
  ]
}

Renovateにおける$schemaは、renovate.jsonで使える設定項目やその値の種類・ルールを定義しています。これにより、どの設定が有効かをエディタが理解できたり、エディタによる補完などが有効になったりします。

extendsでは、Renovateがあらかじめ用意しているルールセットを指定することができます。上記の例ではconfig:recommendedを指定しています。これには、どの言語やプロジェクトでも使える推奨設定が含まれています。（以前はconfig:recommendedではなく、config:baseと呼ばれていたみたいです。）

config:recommended の詳細についてはこちら
またその他設定項目についてはこちら

まとめ

現在業務でRenovate を使ってみて感じたのは、カスタマイズ性が非常に高い反面、設定項目が多くてややとっつきにくいという点でした。しかし、プライベートの時間を使って軽く触ってみたところ、導入自体は想像以上に簡単で、いい意味で期待を裏切られました。最小限の設定でもすぐに使い始めることができましたが、もう少しドキュメントを読んで複雑な設定も試してみたいと思いました。

PostgreSQL16をソースコードからビルドしてみる

Wed, 18 Sep 2024 14:47:07 +0900

PostgreSQL16をソースコードからビルドしてみたのですが、いくつかつまづいたポイントがあるので、それらにご紹介します。

PostgreSQL16をソースコードからビルドするためのコマンドは以下のとおりです。前提として M1 Mac (macOS 14.4.1) を使っています。

% git clone git://git.postgresql.org/git/postgresql.git
% cd postgresql
% ./configure --enable-debug --enable-cassert --enable-tap-tests --prefix=$HOME/pgsql CFLAGS=-O0
% make -j 4
% make install

configureコマンドには以下のオプションを指定しています。

デバッグしやすくするためのオプション: –enable-debug –enable-cassert –enable-tap-tests
インストール先のディレクトリを指定するオプション: –prefix

参考: https://www.postgresql.jp/document/16/html/install-make.html#CONFIGURE-OPTIONS

`icu-uc`, `icu-i18n`のパッケージが見つからない

icu-uc, icu-i18nのパッケージが見つからないと言われました。

% ./configure --enable-debug --enable-cassert --enable-tap-tests --prefix=$HOME/pgsql CFLAGS=-O0
(省略)
checking for icu-uc icu-i18n... no
configure: error: Package requirements (icu-uc icu-i18n) were not met:

No package 'icu-uc' found
No package 'icu-i18n' found

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Alternatively, you may set the environment variables ICU_CFLAGS
and ICU_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.

PKG_CONFIG_PATHという環境変数を設定してあげれば良いみたいです。以下のコマンドを実行すると、どう設定すればいいか教えてくれました。

Rocky Linuxにcontainerdをインストールする方法

Sun, 30 Jun 2024 16:46:03 +0900

以前Kubernetesクラスタを構築するときに、Rocky Linuxでcontainerdをインストールする方法についてあまり情報がなかったので、とても苦労しました。なので今回はその時に調べた内容を記事にしてみました。

次のコマンドでcontainerdをインストールできます。

# yumにCentOS用のdockerリポジトリを追加する
sudo yum config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo

# docker-ceリポジトリに含まれているcontainerd.ioのパッケージをインストールする
sudo yum install -y containerd.io

# containerdのデフォルト設定ファイルを生成する
sudo sh -c "containerd config default > /etc/containerd/config.toml"

そして最後にcontainerdを有効化します。

systemctl enable --now containerd.service

参考

Using containerd without docker (Installing containerdの部分)

NUC上にk8sクラスタを構築する

Wed, 05 Jun 2024 21:20:47 +0900

しばらく放置していたNUC上にk8sをインストールして、おうちクラスタを運用していこうと思います。今回はkubeadmを使ってk8sをインストールしようと思います。

前提

ベアメタル(Intel NUC11PAHi5)上に構築
Control Planex1台とWorkerx3台の4台構成
OSはRocky Linux9.3
ルーター側の設定で固定IPを割り当て
各ノードのスペックは以下

CPU	メモリ	ストレージ
4コア	16GB	500GB

kubeadmのインストール

以下の手順を参考にします。

kubeadmのインストール

「始める前に」にSwapがオフであること、と記載がありますが、swapがオフになっていなかったので無効化します。

sudo swapoff -a

ポートの開放

kubernetesのコンポーネントが互いに通信するために、これらのポートを開く必要があります。 RockyはRHEL系なのでfirewall-cmdを使って、Control Planeノードのポートを開放します。

sudo firewall-cmd --add-port=6443/tcp --permanent
sudo firewall-cmd --add-port=2379-2380/tcp --permanent
sudo firewall-cmd --add-port=10250/tcp --permanent
sudo firewall-cmd --add-port=10257/tcp --permanent
sudo firewall-cmd --add-port=10259/tcp --permanent

ポートが開放されたことを確認します。

sudo firewall-cmd --reload
sudo firewall-cmd --list-ports

続いて各Workerノードのポートを開放します。

sudo firewall-cmd --add-port=30000-32767/tcp --permanent
sudo firewall-cmd --add-port=10250/tcp --permanent

ポートが開放されたことを確認します。

sudo firewall-cmd --reload
sudo firewall-cmd --list-ports

コンテナランタイムのインストール

コンテナランタイムの手順を参考に、各ノードに設定をしていきます。

ウォンテッドリーに入社しました

Tue, 06 Feb 2024 14:31:31 +0900

ウォンテッドリーに入社して1ヶ月経ったので、色々と振り返ってみようと思います。

転職を考えたきっかけ

前職ではややニッチなテーマに取り組んでいたこともあり、そのまま長く居続けても他の会社でやっていけるか不安でした。また、変化が早い時代なので、会社に依存せず個人でやっていけるだけの実力・スキルを身につけたいと考え、もっと技術力を伸ばせるような会社に移りたいと思うようになりました。

企業選びの軸

企業選びは以下の軸をもとに考えました。

自社でサービスを開発・運用している
技術力の高いエンジニアが在籍している
先進的な技術を扱っている

上記の条件を満たすような会社であれば、もっと技術力を伸ばせると思ったからです。

転職に向けて行ったこと

インフラエンジニア / SRE職を希望していたので、主に以下のようなことを行いました。

関連する資格の取得 (AWS SAP、CKA)
個人ブログでの発信
簡単なWebアプリの作成

前職でPostgreSQL、Kubernetesを触る機会があったものの、AWSやTerraformの経験、それに本番環境の運用経験がなく苦労しました。実務での経験不足を補うために、AWSの資格を取得したり、個人ブログで今まで学んだことのアウトプットなどを行うようにしました。また、SRE職などだと自動化のツールなどをGoで書くこともあると思ったので、Goで簡単なTo-doアプリを作成したりしました。

ウォンテッドリーへの入社を決めた経緯

ウォンテッドリーへはスカウト経由で入社しました。（Wantedly Visitに登録したら、ウォンテッドリーからスカウトが来てびっくりしました笑）カジュアル面談で話を聞いていると、PostgreSQLやKubernetesなど今まで培った経験を活かしつつ、新しい挑戦ができそうだったので、選考を受けてみようと思いました。

選考を受ける前だったか、1次面接の後だったか覚えていませんが、Engineering HandbookとCulture Bookをいただきました。まず、開発や会社の文化に関することがこのような形にまとめられているのが素敵だと思いました。そして、内容に関してもエンジニアリングに対して真摯に向き合う姿勢やエンジニアにとても理解のある会社だということが伝わってきて、こんな会社で働いてみたいと思うようになりました。（個人的にはCulture Bookの「変わるエンジニアの定義」が好きです。)

また、2次選考として 1 day インターンに参加させていただきました。わずか1日のインターンシップではあるものの、チームメンバーがどんな人なのか、日々どんな業務に取り組んでいるのかなど実際に働くイメージがつき、その後安心して入社することができました。

入社してからの感想

毎日分からないことだらけですが、その分学ぶことが多くてとても充実しています。周りのエンジニアの方々は技術力が高くて、尊敬できる方ばかりです。

オンボーディングに関しては、研修や社内のドキュメントが整備されていて、スムーズに環境に馴染むことができました。分からないことがあるとすぐに聞ける雰囲気があり、ちょっとしたことでもSlackやHuddleで相談できて大変ありがたいです。週2出社なので、対面でのコミュニケーションもできて良い感じです。

びっくりしたことは、会議室の名前がジョジョの奇妙な冒険からつけられていること、白金台のランチの選択肢の少なさ、あとはエンジニアの1割がDvorak使いということですかね笑　

今後ウォンテッドリーで取り組みたいこと

今後取り組みたいことは以下の通りです。

Kubernetes, PostgreSQLなどのアップグレード
インフラの性能監視・運用改善・障害対応
Goを用いたツールの開発

前職だと実運用を経験していなかったので、システム基盤のアップグレードを経験したいという思いがあります。同様に、性能監視や運用改善、障害対応などインフラエンジニアとして求められている基本的な業務も一通り経験してみたいです。また、ウォンテッドリーのインフラチームは様々なツールをGoで実装しているので、それらの実装を理解し改善していけるだけの力をつけていきたいです。

上記以外にも直近不足している知識(NW、AWS、Terraform、Gitなど)が多いので、日々精進していく所存です！

Alertmanagerのwebhookを試してみる

Sun, 13 Aug 2023 13:11:42 +0900

Kubernetes上でAlertmanagerがちゃんと通知できるか、どんな内容が通知されているのか確認してみようとすると、連携するためのSlackが必要であったり、Emailを送信するにもメールサーバが必要だったりと、意外と気軽に試せないということがありました。

なので、今回はwebhookの機能を使ってNginxにリクエストを飛ばし、リクエストの内容をログから確認してみようと思います。

webhookとは?

Alertmanagerのreceiverには以下が指定できます。

Webhookとは特定のエンドポイントに対してHTTP POSTリクエストでアラートの情報を送信するというものです。外部サービスではないので、自分自身でエンドポイントを用意し、自分自身で後続の処理を実装する必要があります。

例えば、以下のように設定します。

receivers:
- name: "nginx"
  webhook_configs:
  - url: 'http://nginx-svc.default:8080/'

webhookの連携先としてnginxを使う

今回はwebhookの連携先としてnginxを使用します。

nginxを使って実現したいことは以下のとおりです。

エンドポイントを用意する
リクエスト内容を確認する

nginx.confの初期設定をベースにしていますが、そのままだとリクエスト内容を確認することができないので、設定を追加しました。 log_formatで$request_bodyを指定し、/にアクセスした時に$request_bodyがログとして標準出力に出るように設定しています。

しかし、$request_bodyを有効化するにはproxy_passなどの後続処理が必要になります。なので、proxy_passで/trashというエンドポイントにリクエストを転送し、/trashで特に意味のない処理(1x1ピクセルのgifを返す)をしています。

The variable’s value is made available in locations processed by the proxy_pass, fastcgi_pass, uwsgi_pass, and scgi_pass directives when the request body was read to a memory buffer.

http://nginx.org/en/docs/http/ngx_http_core_module.html#var_request_body

user  nginx;
worker_processes  auto;

error_log  /var/log/nginx/error.log notice;
pid        /var/run/nginx.pid;


events {
    worker_connections  1024;
}


http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    # -------------------追加設定---------------------
    log_format  postdata escape=none $request_body;

    server {
        listen   8080;
        location / {
            access_log /dev/stdout postdata;
            proxy_pass http://127.0.0.1:8080/trash;
        }
        location /trash {
            access_log off;
            empty_gif;
            break;
        }
    }
    # ----------------------------------------------

    sendfile        on;
    #tcp_nopush     on;

    keepalive_timeout  65;

    #gzip  on;

    include /etc/nginx/conf.d/*.conf;
}

上記の設定をConfigMapとして作成し、nginxのPodに対してConfigMapをマウントしてあげます。nginx-svcというServiceも作成します。

KubernetesのCronJobが失敗したときにアラートをあげる

Tue, 08 Aug 2023 19:48:39 +0900

CronJobは、指定したcronフォーマットに基づいて定期的にJobを実行するという機能です。主にバックアップの取得やメール送信など、定期的な処理を実行する際に便利です。

一方で、CronJobが失敗した際にどのように検知すべきかについては、あまり情報がありませんでした。なので、今回はそちらについて考えてみたいと思います。

kube-state-metricsを活用する

kube-state-metricsとはKubernetesクラスタ内のリソースの状態をメトリクスとして提供してくれるというものです。 kube-state-metricsではCronJobやJobの状態をメトリクスとして取得することができます。この方式採用している記事が多かったので、こちらで検討を進めてみたいと思います。

※記事

どのメトリクスを使い監視するか

CronJobはcronフォーマットで指定された時刻にJobを生成し、そのJobがPodを生成するという3層の親子構造になっています。また、CronJobとJobの関係は1対多で、JobとPodの関係は1対多になります。

Jobが完了するのはcompletions個のPodが正常終了した場合、もしくはbackoffLimit個のPodが異常終了した場合に限ります。

completions
- completions個のPodが成功すると、Jobが完了したとみなされる
- デフォルトは1
backoffLimit
- 失敗したと判断するまでの再試行回数で、この回数を超えるとJobは失敗とみなされる
- デフォルトは6

そして、アラートを上げたいのはJobが失敗した時です。言い換えると、backoffLimit個のPodが異常終了したときにアラートを上げるということになります。何個のPodが異常終了したのか監視することも可能だと思いますが、ここではJobのステータスを監視するのが適切かと思います。

メトリクス	対応する項目	説明
kube_job_status_succeeded	.status.succeeded	Jobの管理下で正常終了したPodの数
kube_job_status_failed	.status.failed	Jobの管理下で異常終了したPodの数
kube_job_complete	.status.conditions.type	Jobが成功したかどうか
kube_job_failed	.status.conditions.type	Jobが失敗したかどうか

参考: https://github.com/kubernetes/kube-state-metrics/blob/main/docs/job-metrics.md

Jobに関するメトリクスは複数ありますが、この中でも特にkube_job_failedを使ってアラートを上げるのが良さそうです。以下の設定だと、Jobが失敗したときにアラートが上がります。

kube_job_failed > 0

アラートが発火し続けてしまう問題

失敗したJobは削除されずに残り続けるので、アラートが発火し続けてしまいます。なので、JobのttlSecondsAfterFinishedを設定し、数分後にJobが削除されるようにします。

ttlSecondsAfterFinished
- 指定秒後にJobを削除できる

CronJobのfailedJobsHistoryLimitを設定するという方法も思いつきましたが、0にしてしまうとそもそもアラートが上がらないと思うので、こちらは1のままにしておきました。

failedJobsHistoryLimit
- 失敗したJobを指定個数分残しておける
- デフォルトは1

まとめ

今回はkube-state-metricsを活用して、CronJobが失敗した時のアラートを設定しました。CronJob失敗時にアラートを上げる方法についてはあまり参考になる記事がなく、私なりに考えてみました。他にもっといい方法をご存知の方は教えていただけるとありがたいです。

Linuxで公開鍵認証をする

Wed, 12 Jul 2023 21:23:52 +0900

Linuxでの公開鍵認証の設定をよく忘れてしまうので、備忘録としてメモを残しておきます。

接続元での設定

接続元で鍵を生成し、公開鍵を接続先のサーバーへコピーします。

ssh-keygen
scp ~/id_rsa.pub username@server:~/

接続先の設定

接続先のサーバーで公開鍵の情報をauthorized_keysに登録し、適切な権限を設定します。

mkdir ~/.ssh
chmod 700 ~/.ssh
cat id_rsa.pub >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

公開鍵認証を有効化し、パスワード認証を無効化します。

sudo vi /etc/ssh/sshd_config
---
PubkeyAuthentication yes
PasswordAuthentication no

sshdを再起動します。

systemctl restart sshd

kubesprayでk8sクラスタを構築する

Mon, 01 May 2023 10:07:31 +0900

k8s構築ツールはいろいろありますが、公式ドキュメントでは以下が紹介されています。

学習環境
- Minikube
- Kind
プロダクション環境
- kubeadm
- kops
- kubespray

※各ツールの違いについてはこちら

今回はその中でもkubesprayというツールを使ってk8sクラスタを構築してみようと思います。kubeadmは1台ずつインストールを実施するのに対し、kubesprayはAnsibleを使い、各ノードで一斉にインストールを実施します。なので、kubesprayは台数が多いときに便利です。

ちなみに、kubesprayは内部でkubeadmを使っているので、kubespray = kubeadm + Ansibleという感じです。また、kubesprayを使うと、コンテナランタイム(デフォルトはcontainerd)やPod間通信のネットワークプラグイン(デフォルトはcalico)などが自動でインストールされるので、非常に便利です。

構築

前提:

ベアメタル(Intel NUC11PAHi5)上に構築
Control Planex1台とWorkerx3台の4台構成
OSはRocky Linux9.1
ルーター側の設定で固定IPを割り当て
各ノードのスペックは以下

CPU	メモリ	ストレージ
4コア	16GB	500GB

ssh公開認証の設定

手元のPCからパスワードなしでssh接続できるように公開鍵認証の設定をします。 ssh-keygenのパスワードには空文字を指定します。

kkato@bastion:~$ ssh-keygen
kkato@bastion:~$ scp ~/.ssh/id_rsa.pub 192.168.10.xxx:~/

公開鍵の情報を各ノードのauthorized_keysに追記します。

kkato@nuc01:~$ mkdir ~/.ssh
kkato@nuc01:~$ chmod 700 /.ssh
kkato@nuc01:~$ cat id_rsa.pub >> ~/.ssh/authorized_keys
kkato@nuc01:~$ chmod 600 ~/.ssh/authorized_keys

/etc/hostsの編集

手元のPCから各ノードへホスト名で接続できるように、/etc/hostsを編集します。

kkato@bastion:~$ cat /etc/hosts
---
192.168.10.121 nuc01
192.168.10.122 nuc02
192.168.10.123 nuc03
192.168.10.124 nuc04

ユーザーの設定

各ノードのユーザーがパスワードなしでsudo実行できるよう設定します。

Raspberry Pi上にk8sクラスタを構築する

Sun, 23 Apr 2023 16:13:42 +0900

最近ラズパイを手に入れたので、kubeadmを使ってk8sクラスタを組んでみたいと思います。 Control Planeノードx1 Workerノードx3の構成です。

準備

準備したものは以下のとおりです。

アイテム	個数
Raspberry Pi 4 Model B / 4GB	4
Raspberry Pi PoE+ HAT	4
ケース	1
microSD 64GB	4
スイッチングハブ	1
LANケーブル 0.15m	4
LANケーブル 1m	1
SDカードリーダー	1
HDMI変換アダプター	1

PoE(Power over Ethernet)+ HATを使うと、LANケーブルから電源供給できるのでとても便利です。今回はPoE+ HATを使っているので、スイッチングハブもPoE対応のものを購入しています。ラズパイのOSをSDカードにインストールする必要があるので、SDカードリーダーも購入しました。あとは、ディスプレイと繋ぐときにmicro HDMIに変換するためのアダプタも購入しました。

OSの設定

OSのインストール

手元のPCはUbuntu 22.04 LTSなので、以下のコマンドでRaspberry Pi Imagerをインストールします。

$ sudo apt install rpi-imager

そして、microSDカード4枚全てにUbuntu Server 22.10 (64-bit)を焼きます。

$ rpi-imager

microSDカードを差し込み、ディスプレイ(micro HDMI)とキーボード(USB)を接続し、OSの初期設定を行います。初期ユーザー名とパスワードはubuntuです。パッケージを最新にしておきます。

$ sudo spy update
$ sudo apt upgrade -y

新しくユーザを作成し、ユーザにsudo権限を付与します。sudoをパスワードなしでできるように追加の設定もします。

ジョージア工科大学 OMSCSを振り返って

Mon, 10 Apr 2023 18:05:06 +0900

2020年8月にジョージア工科大学コンピューターサイエンス修士課程(通称OMSCS)に入学し、2022年12月に卒業しました。今回は入学から卒業までを振り返ってみようと思います。

なぜOMSCSを始めたのか

実は途中でOMSAからOMSCSに編入していたりしますが、OMSCSを始めた主な目的は以下です。

専門的な知識を身につける

私は物理学の学士課程を卒業していますが、物理を学ぶと選択肢は広がるものの少し中途半端なんですよね。例えば、機械系に行きたいとすると機械工学の学生でいいじゃん、電子系に行きたいとすると電子工学の学生でいいじゃん、IT系に行きたいとすると情報系の学生でいいじゃん、となってしまいます。なので、物理学＋αでより専門的な知識を身につけて、今後のキャリアアップに役立てたいと考えました。

海外で就職する

実は私はカナダの大学で学士号を取得していますが、卒業当時の私は現地就職するだけの自信と実力がありませんでした。国際的に評価されている大学の修士号であれば、海外で就職するときもプラスに働くと思い、OMSCSを始めることにしました。

実際どうだったか

正直かなり大変でした。コロナで家にいる時間も多かったですが、平日の仕事終わりと週末は基本的に家でずっと勉強していました。遊びに誘われることもありましたが、毎回断っていたら誰からも誘われなくなりました笑

どれくらいの時間が必要かというと、前提知識があるかどうかにもよると思いますが、1コースにつき週10-20時間は必要だと思います。ちなみに私は基本的に1学期に2コース取っていたので、休む時間がほとんどありませんでした。

また、卒業には以下の条件があり、良い成績をとらないと卒業できないというプレッシャーがありました。

最初の12ヶ月でfundamental courseを最低2つ履修し、B以上の成績を収めなければならない
専門分野のコースは全てB以上の成績を収めなければならない
合計GPAが3.0/4.0以上でなければならない

どんな授業を受けたのか

OMSCSではSpecialization*1といって専門分野を決める必要があるのですが、私はComputing Systemsにしました。その理由としては配属された部署がデータベースや分散システムなどのミドルウェアを扱うところだったから、また低レイヤーの技術に興味があったからです。OMSCSでは10コース履修する必要がありますが、そのうち5, 6コースを自分の専門分野から履修しなければなりません(いわゆる必修科目)。

学期	受講したコース	難易度	作業量
Fall 2020	CSE6040 Computing for Data Anlysis	易しい	10時間/週
Fall 2020	ISYE6501 Introduction to Analytics Modeling	普通	15時間/週
Summer 2021	CS6300 Software Development Process	普通	10時間/週
Fall 2021	CS6250 Computer Networks	普通	10時間/週
Fall 2021	CS7646 Machine Learning for Trading	普通	15時間/週
Spring 2022	CS6035 Introduction to Information Security	普通	15時間/週
Spring 2022	CS6200 Introduction to Operating Systems	難しい	20時間/週
Summer 2022	CS6262 Network Security	普通	15時間/週
Fall 2022	CS6515 Introduction to Graduate Algorithms	難しい	15時間/週
Fall 2022	CS9903-O13 Quantum Computing	易しい	10時間/週

受講したコースについて少し紹介しようと思います。2023年現在、OMSCSでは61コース提供されており*2、定期的に追加・更新されます。また、OMSCSにはOMSCentral*3という非公式のレビューサイトがあるので、そちらも参考にしてみてください。

ジョージア工科大学 OMSCSへの出願方法

Tue, 21 Mar 2023 18:04:49 +0900

ジョージア工科大学コンピューターサイエンス修士課程(通称OMSCS)の概要とその出願方法について紹介します。

OMSCSとは

Online Master of Science in Computer Science (OMSCS)はアメリカの州立大学であるジョージア工科大学が提供しているプログラムになります。

このプログラムの特徴としては以下が挙げられます*1。

全てオンラインで完結すること
学費が安いこと
オンキャンパスと同等の学位であること

近年、MOOCなどオンラインで取得できる学位プログラムは増えつつありますが、OMSCSは2014に開始され、オンラインの学位プログラムとしては先駆け的な存在です。また、OMSCSは学費が安いことを売りにしており、オバマ元大統領も言及しています*2。そして、OMSCSはオンラインの学位とオンキャンパスの学位を区別せず、同等の学位として扱います。卒業証書には"Master of Science in Computer Science"と記載されます。

実際に私が支払った金額を参考までに載せておきます。(Spring 2021は諸々の事情により、学期の途中から休学することにしました。)

学期	米ドル	日本円
Fall 2020	$1951	21万円
Spring 2021	$455	5万円
Summer 2021	$841	9万円
Fall 2021	$1381	16万円
Spring 2022	$1341	17万円
Summer 2022	$841	11万円
Fall 2022	$1187	17万円
合計	$8037	96万円

最近ではOMSCS以外にもOnline Master of Science in Analytics (OMSA)やOnline Master of Science in Cybersecurity (OMS Cybersecurity)などのプログラムが提供されています。

Ken Kato

Mon, 01 Jan 0001 00:00:00 +0000

I am an SRE with experience in Kubernetes, PostgreSQL, AWS, Terraform, and Go.
I am interested in contributing to OSS.
In my free time, I enjoy bouldering, cooking, and travelling.

Experience

Period	Position
2024/01 - Present	Site Reliability Engineer @ Wantedly, Inc.
2021/01 - 2023/12	Database Engineer @ NTT DATA, Inc.

Education

Period	Degree
2020/08 - 2022/12	MSc in Computer Science @ Georgia Institute of Technology
2016/09 - 2020/06	BSc in Physics @ Queen’s University

Talks

Speaker Deck