運用
アップグレード・GitOps・ライセンス・エアギャップバンドル・リストア後のメタデータデータベース、そしてサポートに問い合わせるときに必要な情報です。
アップグレード
まずコントロールプレーンを、次にノードを 1 台ずつアップグレードします。
sudo apt install runlot-cp=<new-version>
sudo /opt/runlot/bin/runlot-admin upgrade --nodes node-1,node-2 --version <new-version>runlot-admin upgrade は SSH で各ノードにインストールし、そのノード自身のレディネスチェックを待ち、最初に失敗した時点で停止します。そのとき、完了したノードと残りのノードを示します。--dry-run は実行計画を表示します。
安全性を支えているのは順序ではなく、ノードがプロトコルの許容範囲外では起動を拒否することです。起動時にノードは自身のプロトコルバージョンをコントロールプレーンのものと比較し、コントロールプレーンが 1 バージョンより多く遅れている、または進んでいる場合は、両方のバージョンを示して終了します。コントロールプレーンより先にノードをインストールすると、そのノードは停止したままになり、その理由が表示されます。
バージョン文字列はファイル名と同じではありません。 rpm ではバージョンに - を使えないため、プレリリースの区切りは ~ になります。
| 配布名 | apt が求める形式 | dnf が求める形式 |
|---|---|---|
runlot-cp_0.1.0-rc.110_amd64.deb | runlot-cp=0.1.0~rc.110 | |
runlot-cp-0.1.0-rc.110.x86_64.rpm | runlot-cp-0.1.0~rc.110 |
apt-cache policy runlot-node を実行すると、パッケージマネージャーが受け付ける文字列を確認できます。
ダウングレードしてもスキーマは元に戻りません。マイグレーションは追加のみを行うため、1 つ前のリリースのコードは新しいスキーマでも安全に動作しますが、スキーマ変更後に古いパッケージをインストールすることはサポートしていません。2 リリース以上戻す必要がある場合は、先にご相談ください。
GitOps: ファイルからのプロジェクト作成
プロジェクト用の Kubernetes カスタムリソースはなく、今後も用意しません。用意すると、メタデータデータベースがすでに保持している内容の 2 つ目の記録先がクラスターになってしまうためです。代わりに、パイプラインから 1 つのコマンドを呼び出します。
apiVersion: runlot/v1
kind: ProjectSet
org: acme
projects:
- name: billing-api
secrets:
DATABASE_URL: ${BILLING_DATABASE_URL} # read from the pipeline's environment
hostnames:
- billing.acme.example
access:
policy: org # public | org | password
- name: inventoryrunlot apply -f projects.yaml --dry-run
runlot apply -f projects.yamlこのコマンドは冪等です。既存のプロジェクトには手を加えず、宣言されたシークレットは毎回書き込み、不足しているホスト名は追加し、アクセスポリシーは差分がある場合にのみ設定します。ルールは 4 つあります。
- シークレットの値は、例にあるような変数参照を通してのみ取り込まれ、未設定の変数があると実行は停止します。このファイルは Git で管理されるため、値そのものをファイルに書いてはいけません。
- 単純なテキストでないものは引用符で囲んでください。YAML は
0100を 100 として読み取ります。 --pruneを付けないかぎり何も削除されません。--pruneには、org の slug を--confirm acmeの形で再入力する必要があります。削除すると、プロジェクトのデータベースとすべてのバックアップも一緒に削除されます。--jsonを付けると、出力はパイプラインのログ向けに 1 つのオブジェクトになります。
ライセンス
コントロールプレーンは 1 分ごとにライセンスファイルを再読み込みするため、更新はファイルの差し替えだけで済みます。
sudo cp license /etc/runlot/license/licenseGET /v1/license とダッシュボードのフッターに、状態・ティア・ノード数の上限・有効期限が表示されます。各状態と、それによって何が変わるかは概要をご覧ください。
エアギャップ
バージョンごとに 1 つのバンドルをお送りします。
runlot-<version>-deb.tar.gz
packages/runlot-cp_<v>_amd64.deb
packages/runlot-node_<v>_amd64.deb
packages/runlot-eval_<v>_amd64.deb
SHA256SUMS
SHA256SUMS.sig
license/sha256sum --check SHA256SUMS
runlot-license bundle-verify --dir .署名は、バイナリに組み込まれた鍵で検証します。ネットワークもキーリングも不要です。SHA256SUMS はビルドの出力そのままのバイト列なので、署名はビルドが生成したものをそのまま対象にします。Helm バンドルも同じ構成ですが、パッケージの代わりに chart と docker save の出力が入っています。
メタデータデータベースをリストアした場合
コントロールプレーンは、PostgreSQL の識別情報(クラスタ id・タイムライン・書き込み位置)を監視します。バックアップからのリストアや、遅れているレプリカへのフェイルオーバーのように、データベースが過去の状態に戻った場合、コントロールプレーンはノードへのリースの発行を止めます。アプリは引き続き応答しますが、運用者が新しい状態を承認するまで、デプロイ・リストア・パーク中のプロジェクトの起動はいずれも通りません。
curl -sS -H "Authorization: Bearer $RUNLOT_OPERATOR_TOKEN" http://$RUNLOT_CP_PRIVATE_ADDR:8081/v1/eramode: lease_quarantine、および reason と drainDeadline が表示されます。期限を過ぎたら次の手順に進みます:
curl -sS -X POST -H "Authorization: Bearer $RUNLOT_OPERATOR_TOKEN" http://$RUNLOT_CP_PRIVATE_ADDR:8081/v1/era/activate
sudo systemctl restart node-agent # on every nodeアクティベーションは、現在のデータベースをそのまま採用し、ノードが確認するエラ番号を引き上げます。計画的なリストアも同じ方法で行ってください。リストア中はコントロールプレーンを停止し、マーカーファイルを書き込んで、意図的にこの状態で起動させます。詳しい手順はサポート契約に付属します。
PostgreSQL の単純な再起動(たとえば apt upgrade)では、この状態になりません。巻き戻しを検知する3つの証跡は、再起動後はいずれも正常を示し、単なる再起動はログに記録されたうえで採用されます。
アクセスなしのサポート
弊社はお客様の環境にアクセスできず、テレメトリーも収集しません。代わりに、次のものをお願いしています:
sudo runlot-admin support-bundle --out bundle.tar.gz内容はコード内のリストをシリアライズしたものです。バージョンとパッケージのダイジェスト、ライセンスの状態(ライセンス自体は含みません)、ノードと配置のテーブル、直近1時間のコントロールプレーンのログ、インストール前チェックの出力、マイグレーション台帳が含まれます。マスターキー、シークレット、お客様のコード、データベースの内容、運用者リスト以外のユーザーのメールアドレスは含まれません。
sudo runlot-admin preflight cp # or `node`インストール前チェックは、すべてのバンドルの先頭ページであり、インストール時に最初に実行されるものです。無効になっている連携を一覧で示すため、「有効だと思っていた」という点も1行で確認できます。
メトリクスは RUNLOT_METRICS_TOKEN で保護された Prometheus エンドポイントとして提供され、チャートには ServiceMonitor が用意されています。ログは、お使いのコレクター向けに journald または stdout へ JSON で出力されます。どこかへ何かを送信するエージェントは同梱していません。