SPIRE のバージョニングとリリースサイクルについて

はじめに

今回は SPIRE のバージョニング、アップグレード方法、ダウングレード方法、リリースサイクルを紹介していきます。この記事は、最新バージョン v0.12.0 の公式ドキュメント を元にまとめたもので、現在メンテナの方で v1.0.0 のリリースに向けて 様々な準備 が進められているため、今後ポリシーが変更される可能性があることに注意してください。¹

バージョニングについて

SPIRE のバージョンは x.y.z の形式で表現され、x はメジャーバージョン、y はマイナーバージョン、z はパッチバージョンを指しており、セマンティックバージョニング に従う仕様になっています。現在 SPIRE は 1.0.0 に達していませんが、バージョンの互換性は既に保証されています。

SPIRE Server の互換性

SPIRE Server クラスタ内のバージョンスキュー（サポートされる最大バージョン差異, 互換性保持範囲）は、±1 マイナーバージョンとなります。つまり、クラスタ内の最新 SPIRE Server と最古 SPIRE Server のバージョン差異は 1 マイナーバージョン以内にしなければなりません。

クラスタ内の最新 SPIRE Server のバージョンが 0.9.3 の場合、他の SPIRE Server のバージョンは 0.8.x から 0.9.x がサポートされているイメージです。

SPIRE Agent の互換性

SPIRE Agent は通信先の SPIRE Server より新しいバージョンであってはならず、バージョン差異は 1 マイナーバージョン以内にしなければなりません。

SPIRE Server クラスタが 0.9.3 と 0.9.2 で構成されている場合、SPIRE Agent のバージョンは 0.8.0 から 0.9.2 がサポートされているイメージです。

SPIRE プラグインの互換性

SPIRE にビルドインされているプラグインは、先述のコンポーネントと同様の互換性 ² が保証されています。当たり前かもしれませんが、SPIRE は外部のプラグインの互換性は保証できないので、外部のプラグインを利用していて互換性に不安がある場合は、対処プラグインのメンテナに問い合わせるのが良いかと思います。

なお、設定パラメーターや生成されるセレクタの変更など後方互換性のない変更が発生した場合には、先述のポリシーに従い、変更が導入された後の 1 マイナーバージョンでは後方互換性を維持して、SPIRE 利用者に新たな変更に対応するための時間が与えられます。

アップグレード方法

アップグレードはバージョンスキューに注意しながら実施する必要がある ³ ため、先述のポリシーに従い、SPIRE Server のアップグレード、SPIRE Agent のアップグレードという順番で作業を進めていくイメージです。

なお、アップグレードは最大でも 1 マイナーバージョンという制限があることに注意してください。2つ以上のマイナーバージョンのアップグレード（例: 0.8.1 から 0.10.0）はサポートされていません。

また、SPIRE Server と SPIRE Agent ではローリングアップグレードもサポートされています。アップグレードについてはローリングアップグレードが強く推奨 ⁴ されていますが必須ではありません。

例: 0.8.1 から 0.9.3 へのアップグレードの流れ

1. SPIRE Server クラスタ内のインスタンスを1つずつ 0.8.1 から 0.9.3 へアップグレードする
2. SPIRE Server クラスタが期待した通りに動作することを確認する
3. SPIRE Agent インスタンスを 0.8.1 から 0.9.3 へアップグレードする

ダウングレード方法

SPIRE では、アップグレード中に問題が発生した場合に備えて、ダウングレードもサポートされています。ダウングレードにおいても、バージョンスキューに注意する必要があるため、SPIRE Agent のダウングレード、SPIRE Server のダウングレードという順番（アップグレードと逆順）で作業を進めていくイメージです。

例: 0.9.3 から 0.8.1 へのダウングレードの流れ

1. SPIRE Agent インスタンスを 0.9.3 から 0.8.1 へダウングレードする
2. SPIRE Server クラスタ内のインスタンスを1つずつ 0.9.3 から 0.8.1 へダウングレードする
3. SPIRE Server クラスタが期待した通りに動作することを確認する

リリースサイクルについて

現在 SPIRE ではリリースサイクルについてのドキュメントは存在していませんが、spiffe/spire#2046 でメンテナに質問したところ、いくつか情報が得られましたので紹介していきます。

リリースタイミングは様々なことに左右されるため、マイナーバージョンやパッチバージョンのリリーススケジュールは決まっていないのですが、月に1回程度のペースで新しいバージョンをリリースしているとのことでした。

また、新しいバージョンでリリースする機能の議論は実施しておらず、ほとんどのケースで master にマージされているものを、先述のポリシー通りにリリースする方針のようでした。リリース候補についてはリリースの1週間前に決定するルールを敷いている ⁵ ようで、その1週間の間にマージされた機能は重要な Bugfix でない限りは一緒にリリースされることはないとのことでした。

さいごに

今回は SPIRE のバージョニング、アップグレード方法、ダウングレード方法、リリースサイクルを紹介しました。自身の理解のためにも、今後も引き続き SPIRE 関連の情報をまとめていこうと思います。

蛇足ですが、この記事をまとめる過程で Kubernetes のバージョニングやリリースサイクルなどにも再度目を通していた ⁶ のですが、リリースプロセスのルールが厳密に定義されていたり、関わるメンバーも組織化されていたりと、大きいコミュニティはスゴイなあと思いました。

1. v1.0.0 がリリースされたタイミングで変更があればこの記事を更新する予定です。 ↩

2. ビルドインされているプラグインで特定のプラグインは別バージョンを使用したいケースは少ないと思うので、そこまで気にしなくても良いかなと思います。 ↩

3. 全ての SPIRE Agent インスタンスのバージョンを把握しておかないとアップグレードに不安が残るので、その辺りを良い感じに把握できる方法を今後模索していきたい。現在サポートされているかは不明だが SPIRE Server のメトリクスからリクエストがきている SPIRE Agent のバージョン情報を参照できたら良さそうかなと妄想している。 ↩

4. SPIRE Server がクラスタリングされている場合にはダウンタイムなしでのアップグレードが可能というメリットがあります。 ↩

5. 詳細は SPIRE Maintainership Guidelines and Processes の Release and Branch Management を参照とのこと。 ↩

6. Kubernetes バージョンとバージョンスキューサポートポリシー が母国語で大変わかりやすかった。SIG-Docs メンバーに感謝。 ↩