Unyablog.

Unyablog.

のにれんのブログ

wsl.exe の出力を UTF-8 にして Powershell の Select-String や -match が動くようにする

Windows

Powershell で wsl.exe の出力をそのまま操作しようとするとうまく動かない。

PS C:\Windows\System32> wsl.exe --list --running | Select-String "U"

Windows Subsystem for Linux Distributions:
Ubuntu (Default)

PS C:\Windows\System32> wsl.exe --list --running | Select-String "Ubuntu"
（何も出ない）

これは wsl.exe の出力 (unicode) と Powershell の想定する文字コード (UTF-8) が合わないのが原因。

wsl.exe の出力は一見すると普通の文字列に見えるが、 Format-Hex すると ASCII でも後ろに 0x00 が入っていることがわかる。

PS C:\Windows\System32> wsl.exe --list --running | Format-Hex
...
          Offset Bytes                                           Ascii
                 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
          ------ ----------------------------------------------- -----
0000000000000000 00 55 00 62 00 75 00 6E 00 74 00 75 00 20 00 28  U b u n t u   (
0000000000000010 00 44 00 65 00 66 00 61 00 75 00 6C 00 74 00 29  D e f a u l t )
0000000000000020 00

この対策としては、 WSL_UTF8 環境変数を設定して wsl.exe の出力を UTF-8 にすれば良い。

PS C:\Windows\System32> $env:WSL_UTF8=1
PS C:\Windows\System32> wsl.exe --list --running | Select-String "Ubuntu"

Ubuntu (Default)

github.com

シームレスな植生図を作った

Map

日本の植生図を見るための Web ビューワー、「シームレス植生図」を作って公開した。

https://vg67.map.nonylene.net/

植生図の楽しさ

植生図というのは、それぞれの土地の植生（生えている植物の集団）を分類して地図に表示したもの。

日本では環境省の生物多様性センターが植生の調査を行っており、例えば森であれば「ブナ－ミズナラ群落」や「カラマツ植林」、水田であれば「水田雑草群落」、市街地であれば「市街地」や「緑の多い住宅地」などの分類がなされている。

植生はその土地の風景を決定づけるかなり大きな要素だと思う。森か草原かといったレベルに限らない話で、北海道や長野の高原部は白樺が多くてスッキリとした雰囲気だし、沖縄では亜熱帯感のある濃い植物が多くてコントラストの高い風景になる。針葉樹と広葉樹でも明るさがぜんぜん違ったりする（ミズナラ林とかすき）し、秋や冬では常緑樹か落葉樹かで大きく変わる。

そういった身近な自然の違いは気候とともに街なかの雰囲気にも影響をあたえている、気がする。

山地の一般的な植生は地域によって変わってくる

植生図を見ると、そんな今いる風景を構成するのはどんな植物なのか、また同じようなものはどこで見れるのか、といったことを知ることができる。

山地だけでなく、平地に目を向けても楽しい。どこまで市街地が広がっていて、どこに公園があり、稲作・畑作が行われているのか、都市の特徴が植生図を見るとよく分かる。

名古屋の市街地の広がり

京都市街地の北端付近の様子

植生図のデータとビューワー

マップを開くと分かるとおり、植生調査はとても緻密に行われていて、特に直近進行している第6回・第7回調査はデータの使い勝手も良い。縮尺が1/25000にアップし、さらに凡例を全国で統一して6桁のコードにまとめてくれている。

一方、これを Web で気軽に見る手段は環境省公式の 自然環境調査 Web-GIS か、エコリスが配布しているエコリス地図タイルのビューワー くらいに限られる。どちらも基本的な植生情報の閲覧はできる（エコリスはサクサクしていて結構良い！）が、凡例をフィルタして分布を見たいし、生物多様性センターによる丁寧な解説 も表示したいし…、などなど自分のほしい機能が欠けていた *1 。

GIS やジオテクっぽいことを昔からやってみたかったこともあり、自分のほしい機能を備えた植生図ビューワーを作ることにした。

作る

ジオ周りの技術については全くの初心者（QGIS すら知らなかった！）なので、色々調べながら進めていった。全部書くと記事が終わらないので概要だけ書くと、以下のようなことをやっている。

github.com

  1. 全国の植生データ（Shapefile）を生物多様性センターからダウンロード
  2. 扱いやすくするため geojson に変換・データの整形（丸め込みや、不都合なデータの整形など）
  3. スケールごとに適した植生図 geojson データの生成（グループ化、小さなポリゴンのマージなど）
  4. スケールごとに適した凡例ラベルデータの生成
  5. tippecanoe を使ったベクトル地図タイルへの変換
  6. Shapefile のスタイルファイル（lyr）から凡例ごとの背景色を抽出・加工
  7. 生物多様性センターのサイトから凡例の解説を取得
  8. Mapbox を使った地図の表示、フロントエンドの作成

各種整形はライブラリ豊富な Python、フロントは Vanilla な JS で書いている *2。さまざまなスケールで見やすく使いやすい植生図にするためのデータの処理・パラメータ調整と Mapbox を使ったフロントの作成 *3 が特に大変で、楽しかった。

完成

ということで完成したのが以下。産総研の「シームレス地質図」をリスペクトして「シームレス植生図」という名前にした*4。

https://vg67.map.nonylene.net/

植生をクリックすると同じ植生の地域が強調表示され、生物多様性センターの解説が表示される。

沖縄のリュウキュウマツ群落

自然植生（人為的でない植生）のみを表示して、原生な風景がどこにあるかを見ることもできる。

白神山地やむつ周辺には自然植生が分布している

さらに細かく、凡例の検索・絞り込みもできる。

北海道のシラカバの分布

衛星写真と見比べることもできる。

郊外の市街地や田畑の分布

実は色を変えられる。

書かないと誰も気づかないであろう機能

Mapbox の力によって 3D の表示もできる…!

富士山

…すごくない？

なかなか良いものができたと思うので、ぜひ植生図の面白さに浸かってほしい。

各スクリーンショットのクレジット

1/2.5万植生図GISデータ(環境省生物多様性センター) 、「統一凡例（植生区分・大区分一覧表）」 (環境省生物多様性センター)を加工して作成 / © Mapbox / © OpenStreetMap / © Maxar Improve this map

*1:あと Web-GIS は https 対応が怪しくて Chrome で見れなかったり画面狭かったり...。エコリスは作り始めたころはまだ一部地域のデータがなかったというのもある。今ならエコリスタイルが第6,7回分を全国カバーしていてスーパー地形などでも見れるから、それで満足して作らなかったかも

*2:ライブラリ管理がめんどくさくてそうしたが、結果災害のようなコードになった…。Remix の記事を書いた nonylene はどこへ？

*3:要するに全てでは？

*4:産総研がシームレス植生図を作る場合は別の名前にします

ISUCON 14: ClickHouse と OpenTelemetry で ISUCON の計測環境を作ったら快適だった

isucon Grafana ClickHouse OpenTelemetry

ISUCON 14 に id:utgwkk, id:wass80 と「ミレニアムサイエンススクール」というチーム名で参加した。

結果は 28875 点で 22 位！去年は fail して最下位だったので反省を活かすことができたのでは？

一昨年に Kibana / Elasticsearch / Filebeat で解析環境を組んでサクセスしていたが、今年は OpenTelemetry (Otel) をベースにモニタリング環境を作り直し、バックエンドは ClickHouse、フロントは Grafana の構成でやってみた。これがなかなか良かったので紹介。

コンテスト当日のアプリ改善周りは utgwkk の記事を見てください。

blog.utgw.net

序: ISUCON で必要な計測

ISUCON ではパフォーマンスを継続的に確認してボトルネックを探しながら改善していくのが王道ルート。 インスタンスの CPU 使用率や RAM 利用量といった一般的なメトリクスについてはベンチ中に netdata なり htop なりを眺めていれば良いが、それだけではアプリケーション内部や各 API パスの具体的な負荷状況は把握できない。

そこで、 Nginx のアクセスログや MySQL のスローログ、さらにはアプリケーションの Trace を出力して集計することが重要になる。

有史以前からこの手のツールはいろいろあり、CLI だと kataribe、pt-query-digest あたりが有名なところ。

そんな中、Nginx のアクセスログや pt-query-digest を常時集計してメトリクス化し、ダッシュボードで一元的に表示できるようにしたのが一昨年の記事だった。

nonylene.hatenablog.jp

またこれで組んでもいいのだけど、 適当に投入しまくって適当に使うと若干重かったり、クエリが手でぱっと書けなかったり…といった Kibana / Elasticsearch 特有のめんどくささがある（あと飽きた）のも事実なので、今回は別の構成を試してみることにした。

ClickHouse と OpenTelemetry と Grafana でサクセス

Kibana は Elasticsearch と密に紐ついているので、Elasticsearch をやめるとなると Grafana など他の可視化ツールを使うことになる。

いろいろ探していたところ、Grafana と ClickHouse の組み合わせが良さそうということで使ってみた。

また、Nginx 公式の otel module があることを発見したので、これを機に Opentelemetry (Otel) を使って Trace も（Google Cloud Trace ではなく）自力で取り込んでみることにした。

ClickHouse

ClickHouse はもともと Yandex で作られていたものが OSS になり企業としてもスピンアウトしたものだそうで、カラム志向のデータ構造をした OLAP 向けデータウェアハウスとのこと。

clickhouse.com

Observability についても力が入っており（確かにモニタリングは OLAP の一種と言えそう）、Otel でログや Trace を ClickHouse に流し込み、Grafana の公式プラグインを使って Trace / Metrics / Timeseries の可視化ができる。

clickhouse.com

各種データの操作は SQL ベースの言語で行う。 Observability の文脈で SQL というのはなかなか珍しいが、Prometheus のわけのわからないクエリよりも100倍分かりやすくて良いと思う*1。

また、データウェアハウスらしくデータの様々な加工・集計・取り出しが高速に行えるので、 Otel の Processor で行うようなデータの前処理・ Grafana で行うような後処理を ClickHouse で完結できるのも良いポイント *2。

立てる

まずは ClickHouse を立てる。今回は公式 Docker image を Kubernetes 上で動かした。MySQL を動かすのと大体同じ感覚。

ユーザーを作る

デフォルトで作られる default ユーザーは権限最強で危険なので、Grafana と OpenTelemetry Collector (otelcol) 用のユーザーをそれぞれ用意する。

-- Grafana user
CREATE USER IF NOT EXISTS grafana IDENTIFIED BY 'password' SETTINGS max_execution_time CHANGEABLE_IN_READONLY, PROFILE `readonly`;
GRANT SELECT, SHOW ON *.* TO grafana;

-- otel_collector
CREATE USER IF NOT EXISTS otel_collector IDENTIFIED BY 'password';
CREATE DATABASE IF NOT EXISTS otel;
GRANT CREATE, INSERT, SELECT, dictGet ON otel.* TO otel_collector;

otelcol 経由でデータを投入する

otelcol-contrib は Exporter（送信先）として ClickHouse を設定できる。以下を参考にして otelcol-contrib の設定を行う。

clickhouse.com

設定して otelcol-contrib を立ち上げると、otel 用の Table を自動的に ClickHouse 側に作成してくれる。

SHOW TABLES

Query id: 4a180332-e499-492d-917b-b61ea8e342bb

    ┌─name──────────────────────────────────┐
 5. │ otel_logs                             │
 6. │ otel_metrics_exponential_histogram    │
 7. │ otel_metrics_gauge                    │
 8. │ otel_metrics_histogram                │
 9. │ otel_metrics_sum                      │
10. │ otel_metrics_summary                  │
11. │ otel_traces                           │
16. │ otel_traces_trace_id_ts               │
17. │ otel_traces_trace_id_ts_mv            │
    └───────────────────────────────────────┘

その後 otelcol で journald やファイルを読んだり、Trace を受信すると Clickhouse に各種データが投入され、Grafana で確認できる。

Explore で見るログ

Trace も Nginx から送ってみる。Nginx 公式 apt repo から Nginx と otel module を入れ、 otelcol に送るように設定することで簡単に Trace を見ることができた。

Nginx リクエストの Trace

スクリーンショットに Trace を取得するための SQL クエリが見えているが、このクエリは Grafana の流儀に合わせてデータを取り出す必要があるのでちょっと複雑。

ただ、基本的なクエリは Grafana ClickHouse Plugin の Query Builder で十分対応できるので直接 1 から書くことはない。Percentile など混み入った関数を使った集計やフィルタをしたくなったら、クエリを適宜編集することになる。

Materialized view を作成する

ドキュメントにも書いてあるが、otelcol によって自動的に作られた Table をそのまま利用することは推奨されていない。というのも、データ構造や貼られている Index は最低限のものであり、実際の利用に適したものにしたほうが効率が良いため。

これは前処理をしっかりしてから入れましょうね、という話ではなく、ClickHouse ではデータはそのまま入れて ClickHouse 側で処理を行うことが推奨されており、その処理を自分に都合の良い Schema でやりましょう、という話である。

We recommend users avoid doing excessive event processing using operators or transform processors. These can incur considerable memory and CPU overhead, especially JSON parsing. It is possible to do all processing in ClickHouse at insert time with materialized views and columns with some exceptions - specifically, context-aware enrichment e.g. adding of k8s metadata. For more details see Extracting structure with SQL.
...
We recommend users disable auto schema creation and create their tables manually. This allows modification of the primary and secondary keys, as well as the opportunity to introduce additional columns for optimizing query performance. For further details see Schema design.

Integrating OpenTelemetry | ClickHouse Docs

自分で Otel 用の Table から再定義してもいいが、今回は 面倒なので 自動作成される otel_* Table 自体は取り込んだ Trace / ログをそのまま保存する Table として触らずにしておき、 Nginx trace / pt-query-digest log / App trace / App log を集計する際はそれぞれ専用の Table を作成して利用することにした*3。これは ClickHouse の Materialized View 機能を使うことで実現できる。

clickhouse.com

ClickHouse で Materialized view を使うと、ソースとなるテーブルに Insert があった時にそれを元に加工した行を別の Table に Insert することができる。実質的にデータの前処理の役割を果たし、参照時は高いパフォーマンスで参照することができる。

たとえば Nginx の Trace 専用の Table (nginx_accesses テーブル) を作り、取り込んだデータ (otel_traces テーブル) を元にしてその Table に Insert するには以下のように設定する。

CREATE TABLE IF NOT EXISTS nginx_accesses (
    Timestamp DateTime64(9) CODEC(Delta, ZSTD(1)),
    TraceId String CODEC(ZSTD(1)),
    Operation LowCardinality(String) CODEC(ZSTD(1)),
    Duration UInt64 CODEC(ZSTD(1)),
    HTTPStatusCode LowCardinality(String) CODEC(ZSTD(1)),
    HTTPMethod LowCardinality(String) CODEC(ZSTD(1)),
    HTTPPath String CODEC(ZSTD(1)),
) ENGINE = MergeTree()
PARTITION BY toDate(Timestamp)
ORDER BY (HTTPMethod, Operation, toDateTime(Timestamp));

CREATE MATERIALIZED VIEW IF NOT EXISTS nginx_accesses_mv
TO nginx_accesses
AS SELECT
    Timestamp,
    TraceId,
    concat(SpanAttributes['http.method'], ' ', dictGet("path_regexp_dict", ('normalized'), SpanName)) AS Operation, # パス正規化用
    Duration,
    SpanAttributes['http.status_code'] as HTTPStatusCode,
    SpanAttributes['http.method'] as HTTPMethod,
    SpanAttributes['http.target'] as HTTPPath
FROM otel_traces
WHERE ServiceName = 'nginx';

注: Materialized view は、作成に既にあるデータは反映されない（反映してくれる POPULATE オプションがあるが、上記のようなケースでは使えない）。そのため、既存のデータを使うには Materialized view と同等のクエリを使って SELECT し、宛先 Table に既存のデータを Insert する必要がある。
Materialized view を変更するたびに宛先の Table の内容を変更しなおすのも面倒なので、変更時は Table / View ごと作り直すようにした。

構文としては SQL 的なので一度慣れたら簡単で、コンテスト中も App（Go で書いていたので Chi）のログに合わせて App ログ用のテーブルを作って otel_logs テーブルから流し込んだりしていた。

Grafana で可視化する

こうして Log も Trace も全部 Otel で ClickHouse に突っ込んで、ClickHouse 内で使いやすい形に整形し、Grafana でクエリして表示できるようになった。

Nginx モニタリングダッシュボード

例えばパスごとの p90 を上位から集計してテーブルで表示する（↑における右下のパネル）ためのクエリは以下のようになる。

SELECT Operation, quantile(0.9)(Duration)
FROM "otel"."nginx_accesses"
WHERE ( Timestamp >= $__fromTime AND Timestamp <= $__toTime )
GROUP BY Operation
ORDER BY quantile(0.9)(Duration) DESC
LIMIT 10000;

注: 上のクエリを最適化するにはここまでで紹介した Schema からさらに Index を追加する必要があると思います

（ClickHouse とは少しずれるが） 今回は Nginx の層で Otel を有効にして Trace id をつけているので、 Nginx のダッシュボードから Trace を辿ると App の Trace も一緒に確認できて便利だった。

Nginx と App の Trace

前回同様、pt-query-digest も30 秒ごとに結果を集計してリアルタイムで出すようにした。下の記事では Filebeat などで前処理を頑張っているが、今回は Otel から ClickHouse に生ログを流し、ClickHouse 側で JSON をパースするようにしている。

nonylene.hatenablog.jp

pt-query-digest モニタリングダッシュボード

otelcol 側で処理を行わないので、競技インスタンスの負荷も少なく、ベンチマーク中もリアルタイムでリクエストの状況を見ることができた。また、リクエストパスの正規化など前処理の変更があっても各インスタンス上の otelcol を触る必要がないのも楽だった。

Trace もログも同じ Datasource に統一された形で入っているので、それぞれ ClickHouse でパースしてメトリクス的に利用しやすいのも良いポイント。今回はやっていないが、 Trace と Logs を関連づけるのもできそう。

パフォーマンスも申し分なく、時間を広げたり変更してもキビキビ動いてくれた。 Elasticsearch / Kibana のときよりも少ないリソースだったがより快適なモニタリング環境ができたと思う。

その他の点

  • ClickHouse
    • CLI の出来が良い。補完機能や履歴検索機能などよくある Shell にある機能が充実している。
    • エラーログがわかりやすい。 CLI でクエリを打っているときもそうだし、otel でデータを投入するときも権限の不足などエラーの原因がすぐにわかった。
    • 概念周りのドキュメントが分かりやすくて充実している。例えば上記に挙げた otel の記事を読むと otel の概要も把握できて便利。ただリファレンス部分は若干機能の追加に追いついてない部分があったりした。
    • Elasticsearch でも Ingest pipeline で同じような前処理ができるが、設定のやりやすさがかなり違うと思う
    • もちろん万能ではなく、何も考えずに数百万件のログをスキャンして Order by するようなクエリを打つと時間がかかったり RAM が 4GB でも不足したりする。ほとんど困ることはなかったが、適度に Schema / クエリ設計は行うことが求められる。
  • Nginx が Otel を吐き出してくれるのがかなり楽だった。ログを解析すると regexp を頑張って書かないといけないので。

なかなか良いものができたと思うので、来年も活用していきたい。Grafana に感じていた壁も解消された気がする。

ISUCON 14 当日の動き

  • いつもようにサーバー周りを色々やっていた。 MySQL の isucon user のホスト部がはじめから % になっていて感動した。
  • プロファイリングは今までと同様 Google Cloud Profiler を利用した。無料で優秀。
  • アプリはあまり手を入れていなかったが、終盤に GET /api/owner/charts のキャッシュ改善やクエリ改善を少し行っていた。数千点上がったのでヨシ!
  • デプロイスクリプトで ISUCON_MATCHING_INTERVAL 周りをちゃんとケアすることができずにトラブってしまったので反省。
  • 終了 20 分ほど前にほどほどにいい感じのスコアが出たので、フリーズしてあとはチームメイトに ClickHouse の紹介などをしていた余裕のある回だった。なおスローログもアクセスログも切り忘れたし Nginx の Otel 出力もそのままにしていました。

ということで今回の ISUCON も楽しかった。最近は Observability 関連の知らない技術を触ってみる機会にもなっていて、 Otel 自体もほぼ初めてちゃんと触ることができたのでよかった（Trace しかできないと思っていた）。

問題もしっかり作り込まれていて良かったです。ベンチなどの環境も非常に快適でした。チームのメンバー、そして運営のみなさん、ありがとうございました！

*1:自分の Grafana への忌避感は PromQL によるものが大きい

*2:Prometheus だとそもそもクエリが遅かったり、Grafana 側で Transform する羽目になってめっちゃ重くなったりするよね

*3:正確には Trace 自体についても Materialized view を利用して正規化している。長くなるので別の記事に書くかも

kubectl の wrapper を作る際の tips （ZSH 補完など）

Kubernetes

kubectl に自動で namespaceや context を付与するような wrapper を作るとする。

そんなコマンドのインターフェースとして、

$ kubewrapper [...wrapper flags] [kubectl args / flags]
（例） $ kubewrapper -p staging describe pod ...

とすると

$ kubectl --context foo --namespace bar [kubectl args / flags]
（例） $ kubectl --context foo --namespace bar describe pod ...

といったコマンドが exec される、すなわちいくつかの flags を受け取って kubectl 用に変換しつつ args としては kubectl の引数をまるまる受け取るといったものが考えられる。

こういったコマンドを作るためには、補完をはじめとしていくつか注意点があるのでメモ。

外部 plugin 対応

通常の kubectl サブコマンド（get、 logs など）では、 --context や --namespace といった flag はサブコマンドの前に置いても動作する。

しかし、外部プラグインを呼ぶサブコマンドでは動作せず、サブコマンドのあとに flag をつける必要がある。

$ kubectl --context foo awesome-plugin
Error: flags cannot be placed before plugin name: --context

get, logs などは後置でも動作するので、常に後置にする（args 1つ目の直後）ように作ると良い。

上述の例でいうと、以下のようになる。

$ kubectl [kubectl 1st arg] --context foo --namespace bar [kubectl remaining args / flags]
（例） $ kubectl describe --context foo --namespace bar pod ...

kubectl の補完を利用する

kubectl では強力な補完機能を備えており、

source <(kubectl completion zsh)

すると _kubectl 関数が ZSH にインストールされて、kubectl の呼び出し時に補完用関数として呼び出されるようになる。

上述した kubewrapper での補完でも、 kubewrapper のオプションの補完もしつつ、kubectl の補完も使えるようにしたら便利だが、どうすればよいのか？

_kubectl は何をするのか

_kubectl は cobra を通じて生成されているが、その中では type されたコマンドの __complete サブコマンドが呼ばれている。

($ kubectl completion zsh の結果より)
requestComp="${words[1]} __complete ${words[2,-1]}"

色々細かい処理を省略すると、$words には今まさに打ち込んでいるコマンドの配列となっており、ZSH は 1-index なので words[1] は実行しようとするコマンド、 ${words[2,-1} は残りの引数ということになる。

すなわち、 $ kubectl get po<tab> を打っているとき、裏では _kubectl 内で $ kubectl __complete get po が呼ばれている。

_kubectl をカスタムコマンドで使う

ここで上述の kubewrapper の補完関数として _kubectl を設定するとどうなるのか。

_kubectl はあくまで今打ち込まれているコマンドを打つので、

$ kubewrapper -p staging get po<tab>

と打ったときは

$ kubewrapper __complete -p staging get po

が呼ばれることになる。

ここで kubectl の補完結果を流用するには、 wrapper 独自のオプションを消し、namespace や context flag を付加して kubectl の __complete コマンドを exec する、すなわち kubewrapper が以下を exec すれば良い。

$ kubectl __complete --context foo --namespace bar get po

※ __complete の前に namespace や context をつけると plugin 同様エラーになる

これを実現するには、wrapper の argv で __complete が 2 つめに来ていたら、$ kubectl __complete を打とうとしていると解釈すれば良い。wrapper で必須の引数が __complete の後にくることになるので、順序を入れ替えて解釈すると楽。

$ kubewrapper __complete -p staging get po
-> wrapper 内部では以下のように解釈する
$ kubewrapper -p staging __complete get po
-> そうすると wrapper の機能で自然と __complete が打たれる
$ kubectl __complete --context foo --namespace bar get po

wrapper のオプション補完

ここまで話した通り kubectl 関係の補完は _kubectl を通じて wrapper を呼び出して $ kubectl __complete に変換すればいい感じになるが、 その前に wrapper の必須 flag を埋めてもらう必要がある。

wrapper の必須 flag がなければそれを補完、満たされていれば kubectl の補完を発動させたい。

これは気合でいい感じに補完関数を書くことになる。

How do I check whether a zsh array contains a given value? - Unix & Linux Stack Exchange を参考にしつつ、以下のようにした:

if [[ $words[(Ie)-p] == 0 ]]; then
  # _arguments に wrapper の補完のみを記載する
  _arguments ...
else
  # _arguments に kubectl の補完も加える
  _arguments ... \
    '(-)*:kubectl args: _kubectl'
fi

(-)* は kubectl の args が現れた後は全てのハイフンの補完を無視するという意味。

zsh.sourceforge.io

こうすると、最初は wrapper に必須の flag のみが補完され、全て埋まったら wrapper の他の flags とともに kubectl の補完も表示されるようになる。

WSL2 を Windows 11 で起動させ続ける

Windows

この方法は使えなくなりました

Windows 11 からかはわからないが、WSL2 がしばらく放置していると自動でシャットダウンされるようになった。

ターミナルや VS code を全て閉じるとシャットダウンされる傾向にあるようで、例えば ssh-agent や systemd の service が動いていてもいつの間にかシャットダウンされるので厳しい。

調べてみると init にぶら下がっているプロセスがなくなると死ぬのでは？ということだった。 vmIdleTimeout の情報も出てくるが、これは WSL2 が乗っている VM を起動させ続ける話で、WSL2 で動いている Ubuntu などは関係なく終了する。

qiita.com

対策として、Powershell 側から wsl.exe を発行し続けるなど色々あるみたいだが、 /etc/wsl.conf に起動コマンドを設定することで回避ができたのでメモ。

learn.microsoft.com

/etc/wsl.conf で以下のように設定すると sleep コマンドが init にぶらさがって起動してくれる。

[boot]
command=sleep infinity

これで設定してから数日経ったが、起動し続けてくれていそう。

git-browse-remote の python 版を作った

Python

git-browse-remote を長らく使っていたが、最近の Ruby では動かなくなっており、インストール後に手で該当箇所を修正してしのいでいた。

ただ、もう Ruby / Gem はこれにしか使ってなかったというのがあり、環境を新しくした機会に Python で書き直した。

github.com

Git の操作で libgit2 / pygit2 を使ったが、結構コマンドインターフェイスと感覚が違って難しかった。 GitPython のほうが楽だったかも。

Pulumi で Google Cloud と k8s のリソースを管理するようにした

Kubernetes GCP Pulumi

プライベートで Google Cloud を使っていて、今まではあまり IaC は使わずポチポチでやっていた。GKE ぐらいしかまともに使ってるリソースがなかったのでそれでよかったけど、最近 VPS をやめて各種クラウドに寄せるようにしており、クラウドのリソースが増えてきた。

ポチポチだと見落とす設定もあったりするので、IaC (Pulumi) を本格的に取り入れることにした*1。

ついでに k8s のリソースも kpt と Helmfile から Pulumi 管理にしたので、そのあたりの話。

Pulumi

Pulumi とは IaC ソリューションの一つで、要するに Terraform 的なもの。 はじめは Terraform とか知ってるし普通すぎるし Pulumi のほうが面白そう、といった理由で使い始めたのだけれど、今でも満足して使っていている。

Terraform との大きな違いは、Python や TypeScript などの一般的な言語を使って記述すること。

www.pulumi.com

www.pulumi.com

※ いろいろ言語が選べるが、この記事では自分が使っている Python での話をしていく

一般的な言語が使えることの何が嬉しいかというと…

プログラミングと同じ作法・感覚での記述

Terraform だと、HCL という Hashicorp 独自の言語を使う必要があり、ちょっと変わった処理をしようとするとすぐリファレンスを見る必要がある*2。また、Provider のバージョン更新やディレクトリ構成など、 Terraform での作法を色々調べないといけない。

一方 Pulumi は普段プログラムを書くときと同じ感覚で IaC の記述ができる。 やることは非常に明快で、リソースに対応するクラスを使ってインスタンスを作るだけ。各種 Provider は Python module として提供されており、それらの更新やインストールは pip 経由で行うので、いつも通り requirements.txt や pyproject.toml でバージョンの管理ができる。

この "いつも通り" が頭を使わずに済んで便利。

もちろん HCL より色々柔軟に書けて便利というのもあるが、それは個人レベルだとどっちでもいいかな。

IDE による強力なサポート

TypeScript や Python、Go など人気のプログラミング言語は IDE のサポートが強力で、補完やドキュメントの参照などがスムーズに行うことができる。 Pulumi は Provider にちゃんと型ヒントやコメントをつけてくれているので、VSCode などで快適に IaC のコーディングができる。

Terraform にももちろんそういった VSCode 拡張はあるけど、どうしても MS が公式で提供しているものよりはクオリティやパフォーマンスが落ちてしまう。

Q. プログラミング言語で IaC…？ Chef でみんな諦めたはずでは…？

あれは確かにつらいけど、背景が違うと思う。今は型があるし、IDE も強いし、Ruby ベースのよくわからない DSL ではない。また、生成したいものは基本的に宣言的なリソースであり Linux サーバーのような変化しうるものを相手にするものとは違うので、複雑な独自処理を書く機会は少ない。

CDK が便利だよね、というのと同じ感覚で見れば良いと思う。

その他嬉しいこと

Provider は Terraform と同等

Pulumi を使い始める前は Terraform で使えるものが使えないような事態を危惧していたけど、Provider は想像以上にたくさんある。

www.pulumi.com

これらすべてを Pulumi が毎秒更新しているかというとそんなことはなく、多くは Terraform provider から自動生成されたものらしい。なので Terraform でできることはだいたいできる。

www.pulumi.com

一部 Native provider というものがあり、これは Pulumi 開発のもので API から自動生成しているため対応の速さが自慢とのこと。

www.pulumi.com

Diff が見やすい

文字列の差分が色付きで出てくれて非常に見やすい。細かいパラメータの変更があったときにどこが変わったのかを目 grep せずに済む。

Import がめっちゃ楽

補足: 書いてる途中で Terraform にも似た機能が最近 Experimental リリースされたことを発見した Import - Generating Configuration | Terraform | HashiCorp Developer 。
Pulumi のほうが気楽そうではあるけど、TF でも自動生成してくれるようになるのはよさそう。

最初はポチポチで作って後から IaC で…ってのはよくあることだと思う。こういうときはポチポチで作ったリソースを State に Import することになる。

Pulumi ではこれが楽で、 Import 完了後にリソースに対応するコードを出力してくれるから、これをコピペすれば IaC 対応が完了する。

Please copy the following code into your Pulumi application. Not doing so
will cause Pulumi to report that an update will happen on the next update command.

Please note that the imported resources are marked as protected. To destroy them
you will need to remove the `protect` option and run `pulumi update` *before*
the destroy will take effect.

import pulumi
import pulumi_gcp as gcp

sa = gcp.serviceaccount.Account("sa",
    account_id="sa",
    display_name="sa",
    project="XXXXX",
    opts = pulumi.ResourceOptions(protect=True))
...

また、ドキュメントには Import コマンドの例が基本的に書かれているのも嬉しい（例: https://www.pulumi.com/registry/packages/gcp/api-docs/serviceaccount/account/#import）。

オープンソース

Terraform は最近ライセンスが BSL に変わってしまった。普段エンドユーザーとして使ってる分にはあまり変わらないが、やっぱりオープンソースだと嬉しいし、応援していきたい。

微妙なこと

State の refresh は自動で行われない

Terraform では plan すると refresh が必ず行われるので、IaC の外で変更があったときに気づきやすい。Pulumi は flag をつけないと自動で行われないので変更を見逃して適切な対応ができない可能性がある。

常に IaC でしか変更しないならいいけど、GKE のアップグレードとか色々あるよね。

Google Cloud で使う

Google Cloud 向けには Native provider と Terraform から変換した Classic Provider がある。今回はチュートリアルに従って Classic Provider を使っている*3。

使ってみた感想としては普通に便利に使えるのだけど、 Google Cloud では Terraform を使ったほうが良さそう…😇

というのも、Google Cloud は Terraform を公式サポートしており、ドキュメントにも Terraform に関する記載が豊富だし、Provider の更新に Google の社内チームが関わっている。

github.com

また、最近はリソースを作っていると同等の TF 定義が右のパネルに出てきてくれたりする。

Pulumi を使っているとこれを参考しながら Pulumi のコードに落としていくことになるので、ちょっと悲しい…。普通に使えるんだけどね。

Kubernetes で使う

※ Terraform の k8s provider は使ったことないです

Manifest

自分は k8s の Manifest 自体は Kustomize などで YAML で書けばいいと思っており、こういうのを使う嬉しさは主に Pruning （不要になったリソースの削除）だと考えている。

その用途として kpt を使っていたけど、しょっちゅうよくわからない感じで壊れてイヤになってきたので Pulumi 管理にすることにした。そもそも kpt の主目的はそういうとこじゃない、というのもある *4。

Manifest は Kustomize で組んでいるので移行は非常に簡単で、 Pulumi の Kustomize 対応を使って kustomization.yaml があるディレクトリの指定をするだけだった。

from pulumi_kubernetes.kustomize import Directory

Directory(
    "main",
    directory=".",
)

こうすると Kustomize をビルドして、ビルド結果に含まれる Deployment などの各リソースをそれぞれ管理してくれる。

使った感触としては非常に良くて、Server side apply してくれて安心だし、kpt よりも apply が早いし、diff も前述の通り見やすくなった。 変更時は READY になるかをちゃんと見てから古いリソースを削除したりと、安心して適用がしやすいのも良い。

Kustomize と Pulumi の組み合わせ、おすすめです！

Helm

Helm はもともと Helmfile で管理していた。それほど不満はなかったが、Pulumi でも Helm の管理ができるので Manifest と一元管理することにした。

Pulumi は Helm を入れるためのリソースとして Chart と Release があり、Chart が Pulumi 側で一旦展開され、てインストールするもの、Release がインストールも Helm に任せるものとなっている。

www.pulumi.com

↑にあるように一長一短あり、Chart だと Pulumi が各リソースを管理しているのでリソースの細かい diff まで確認することができる一方、Hooks など Helm 関連の機能が使えない、 Release だと Helm の全機能が使えるが diff は values の範囲に限られてしまう。

今回は互換重視で Release にした。これも良い感じに使えていて、Helmfile より UI が良くなった上に $ pulumi up コマンド一回で k8s Manifest と一緒にデプロイできるようになり、楽になった。

一方、これは cdk8s でも感じたことだが、values を Python で書くことになるので REAMDE とかにある例をそのままコピーできないのは面倒くさい。せっかく Pulumi ・ Pythonなので、 values は YAML として置いておき、PyYAML を使って読むようにしても良いかもしれない。

Pulumi のユーザーは Terraform より少ないのでナレッジは少ないけど、ドキュメントがしっかりしているので特に困ることはなかった。同じような話で Google Cloud などサポート的に Terraform を使ったほうが便利な局面もあるものの、 TF の Provider を自動変換してることもあって機能面では不自由なく使うことができる。なにより自分に馴染んだ言語で書けるというのがすばらしく、そして楽しい！

k8s のサポートもよくできているし、普通とはちょっと違うものを使ってみたい欲も満たせて*5なかなか良いものだった。これからも使って & 推していきたい。

*1:逆に Itamae は使わなくなった

*2:Object の書き方がいっぱいあるのやめてほしい…

*3:今は Native は Preview だし、 Classic は Google 公式の TF Provider が元になってるしで Classic のほうが少なくとも今は良いよね、という話もあった https://github.com/pulumi/pulumi/discussions/12470

*4:最近 kubectl 側で ApplySet というのが議論されているが、まだ alpha で今使うものではなさそう

*5:これが一番大事