最近、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は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 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/,$//': 末尾に付いてしまった余分なカンマを削除

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