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

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という環境変数を設定してあげれば良いみたいです。 以下のコマンドを実行すると、どう設定すればいいか教えてくれました。 ...