導入とアップグレード

初めてのローカル設定については、次の手順に従ってください 最初のリクエスト。このページは、デプロイ方法の選択、リモート インスタンスの構成、またはアップグレードの際に使用します。

SubLane は、フロントエンドと SQLite が組み込まれた 1 つのプロセスとして実行されます。運用環境では、Node.js、Redis、または別個のプロキシ サービスは必要ありません。各データ ディレクトリに対して 1 つのインスタンスを実行します。

公開された Docker 画像

タグ付きリリースの公開 ghcr.io/murongg/sublane のために linux/amd64 そして linux/arm64。 Docker はホスト アーキテクチャを選択します。イメージは公開されており、GHCR にサインインせずに取得できます。導入には Docker と Compose が必要です。ソースのチェックアウト、Go、Node.js、またはローカル イメージのビルドは必要ありません。

以下のマニュアル Compose の例は、公開されているものを固定します。 0.1.0-rc.1 プレリリース。セット SUBLANE_IMAGE 手動デプロイメントの場合は明示的に: Compose のデフォルトは latest、安定版リリースでのみ公開されます。

反復可能な展開には、固定バージョンまたはダイジェストを使用します。 GHCR に新しいイメージが表示されても、実行中のコンテナは自動的に更新されません。

インストールスクリプト

ターミナルからインストーラーを実行して、Docker または公開された Linux バイナリ、通常のインスタンスまたは読み取り専用デモを選択し、次にプロキシなし、Caddy または Nginx を選択します。

Up/Down または数字キーを使用してオプションを強調表示し、Enter を押して確定します。最初のオプションはデフォルトで選択されています。基本的な端末では、番号付きのテキスト プロンプトが使用されます。ドメインはテキスト入力のままで、インストーラーは展開前の確認のために生成された構成を表示します。提供されたフラグは、対応する選択肢をスキップします。 --non-interactive すべてのプロンプトを無効にします。

curl -fsSL https://raw.githubusercontent.com/murongg/SubLane/main/scripts/install.sh | bash

それなし --version、スクリプトは GitHub の最新の安定リリースを選択します。安定したリリースが存在しない場合にのみ、ドラフトを除く、最も最近公開されたプレリリースが選択されます。選択した具体的なバージョンは生成された構成に保存されるため、再起動によってバージョンが自動的に変更されることはありません。 GitHub API エラーは、チャネル フォールバックをトリガーするのではなく、インストールを停止します。

スクリプトは、選択されたリリース アーティファクトを検証します。 SHA256SUMS 新しいものに取り付ける前に ./sublane ディレクトリ。バッシュ、カール、いずれか sha256sum または shasum 必須です。自動バージョン選択にはさらに jq が必要です。 Docker モードには Docker Compose が必要で、コンテナーが正常になるまで待機します。バイナリ モードは Linux amd64/arm64 をサポートし、動作する systemd ユーザー マネージャーが必要で、ユーザー サービスを有効にして待機します。 /readyz。 Docker、Caddy、Nginx はインストールされず、ソースからビルドされません。

プロンプトを表示せずに公開バージョン、新しいディレクトリ、およびホスト ポートを選択するには、次の手順を実行します。

curl -fsSL https://raw.githubusercontent.com/murongg/SubLane/main/scripts/install.sh | bash -s -- \
  --version 0.1.0-rc.1 --dir ./team-gateway --port 8088 --runtime docker --proxy none --non-interactive

バージョンタグには先頭に v。バックエンドポートはバインドされたままになります 127.0.0.1。利用可能な端末がない場合は、プロキシなしで Docker を使用する通常のインスタンスがデフォルトのままになります。合格 --runtime, --proxy、 または --demo 他のモードを選択します。リモート サーバーの場合は、初期セットアップに SSH トンネルを使用するか、 HTTPS リバースプロキシ.

インストーラーが使用するのは、 ss (iproute2 から) または lsof ダウンロードする前に選択したバックエンド ポートを確認し、デプロイメントを作成する前に再度確認します。ループバック リスナーまたはワイルドカード リスナーがすでにそのポートを使用している場合、リスナーは停止し、未使用のポートを選択するように求められます。 --port、 例えば --port 8088。どちらのユーティリティも利用できない場合は、どちらかのユーティリティをインストールします。ポート 80 または 443 上の既存のプロキシは、バックエンド ポート 8080 を使用するインストールをブロックしません。チェックではポートを予約できません。起動時のヘルスチェックでは、その後に発生する競合も引き続き検出されます。

たとえば、公開されたバイナリを選択し、パブリック ドメインの Caddyfile を生成します。

curl -fsSL https://raw.githubusercontent.com/murongg/SubLane/main/scripts/install.sh | bash -s -- \
  --runtime binary --proxy caddy --domain sublane.example.com

--domain Caddy または Nginx ではオプションです。これがないと、生成されたプロキシはリッスンします。 127.0.0.1:80 HTTP 以上、および SUBLANE_PUBLIC_URL 未設定のままです。ドメインの場合、インストーラーは次のように設定します。 SUBLANE_PUBLIC_URL=https://<domain> そして、HTTPS プロキシ構成を生成します。インストール前の構成を示していますが、 プロキシ サービスにコピーしたりリロードしたりしません。生成されたものを確認します Caddyfile または nginx.conf そしてそれを自分で適用してください。 Nginx テンプレートは、次の証明書ファイルを前提としています。 /etc/letsencrypt/live/<domain>/.

Docker の場合、インストーラーは選択したイメージ、ポート、および一意の Compose プロジェクト名を .env。一緒に保管してください docker.compose.yaml;デプロイメントのデータ量を識別します。バイナリモードの場合、次のように生成されます。 sublane.env, start.sh およびリンクされた systemd ユーザー ユニット。データは非公開のままです data/ ディレクトリ。 systemd ユーザー サービスは、残留が有効になっていない限り、ユーザーがログアウトすると停止することがあります。チェック loginctl show-user "$USER" -p Linger 無人操作が必要な場合は、残留を手配します。新規インストールでは、既存のディレクトリとシンボリックリンクが拒否されます。既存のスクリプト管理インストールは、以下で説明するように、同じスクリプトを使用して更新できます。起動に失敗した場合、構成と作成されたデータは検査のために保持されます。

スクリプト管理のインストールを更新する

初め データベースのバックアップをエクスポートして検証するをクリックし、対象のリリース ノートを読みます。インストールディレクトリの親からスクリプトを実行します。端末では、既存のターゲットが提供する 既存のインスタンスを更新する そして展開前に確認を求めます。明示的に更新を選択するには:

curl -fsSL https://raw.githubusercontent.com/murongg/SubLane/main/scripts/install.sh | bash -s -- \
  --update --dir ./sublane

それなし --version、更新では、インストールと同じ安定版/プレリリースの選択が使用されます。追加 --version <published-version> リリースを固定するには、 --wait-timeout 120 準備完了待機を変更するか、 --non-interactive 確認をスキップします。スクリプトは既存のランタイムを検出します。などのインストール専用フラグ --runtime, --port, --proxy そして --demo 更新中に拒否されます。

Docker 更新では Compose ファイルとプロジェクト名が保持され、変更のみが行われます SUBLANE_IMAGE で .env、選択したイメージをプルし、ヘルス待機を使用してサービスを再作成します。バイナリ更新ではアーカイブを検証し、実行可能ファイルとパッケージ化されたドキュメント/ライセンス ファイルを置き換え、既存の systemd ユーザー ユニットを再起動し、待機します。 /readyz。環境ファイル、ランチャー、ユーザーユニット、プロキシ構成、およびデータパスは保持されます。サービスの既存のポートが占有されていることが予想されるため、更新では新規インストールのポート チェックは実行されません。

ダウンロード、チェックサム、構成、イメージのプルに失敗すると、展開されたファイルは変更されないままになります。置き換える前に、スクリプトは以前のプログラム/設定ファイルをプライベート ディレクトリに保存します。 .update-backup.* インストール内のディレクトリを検索し、そのパスを出力します。 これらのファイルはデータベースのバックアップではありません。 起動に失敗すると、それらと現在の展開データが検査用に保持され、失敗が報告され、移行される可能性のあるデータベースに対して古いバージョンが自動的に実行されることはありません。フォローする リカバリとロールバック データの復元が必要な場合。同時更新は拒否されます。プロセスが強制終了された場合は削除します .update-lock アクティブなアップデートがないことを確認した後でのみ。

この更新パスは、スクリプトによって作成されたインストールをサポートします。手動デプロイメントおよび追加の Compose オーバーライド ファイルを必要とするデプロイメントでは、 手動アップグレード手順以降の起動時のすべてのオーバーライドを含みます。

スクリプトを実行する前に確認するには、次のようにダウンロードします。 curl -fsSL https://raw.githubusercontent.com/murongg/SubLane/main/scripts/install.sh -o install.sh、実行します bash install.sh --help または bash install.sh それを見直した後。

手動 Compose 導入

展開ディレクトリを作成してダウンロードする docker.compose.yaml 選ばれた中から GitHub リリース:

mkdir sublane && cd sublane
curl -fsSL https://github.com/murongg/SubLane/releases/download/v0.1.0-rc.1/docker.compose.yaml -o docker.compose.yaml

そのディレクトリに、Compose を作成します。 .env ファイルを使用して、再起動およびアップグレード後も選択したイメージのバージョンを保持します。

SUBLANE_IMAGE=ghcr.io/murongg/sublane:0.1.0-rc.1
SUBLANE_BIND_ADDRESS=127.0.0.1
SUBLANE_PORT=8080
SUBLANE_LOG_LEVEL=info
# Add this when using an HTTPS reverse proxy:
# SUBLANE_PUBLIC_URL=https://sublane.example.com
# In Docker, first identify the proxy source IP as seen inside the container:
# SUBLANE_TRUSTED_PROXIES=<proxy-source-ip>/32

Compose 読み取り .env 補間用。スタンドアロンの Go アプリケーションがロードされない .env 自体。不変のダイジェストは全体として使用できます。 SUBLANE_IMAGE タグの代わりに値を使用します。

docker compose -f docker.compose.yaml pull
docker compose -f docker.compose.yaml up -d
docker compose -f docker.compose.yaml ps
docker compose -f docker.compose.yaml logs --tail=100 sublane

開ける http://127.0.0.1:8080 メンバーのアクセスを許可する前に、管理者のセットアップを完了してください。リモート ホストの場合は、初期セットアップに SSH トンネルを使用します。デフォルトの Compose マッピングはループバックのままです。出版 0.0.0.0 は明示的な演算子の選択です。

イメージは既存の Alpine として実行されます sublane サービス アカウント。CA 証明書とライセンス通知、および小切手が含まれます。 /readyz。 Compose は読み取り専用のルート ファイルシステム、書き込み可能な 64 MiB を使用します。 /tmp SDK スクラッチ ファイル用の tmpfs、削除された Linux 機能、制限付きコンテナ ログ、および 30 秒の停止猶予期間。コンテナはポート 8080 で待機します。ホストポートをカスタマイズします SUBLANE_PORT。内部リスニング ポートを自分でオーバーライドする場合は、ヘルス チェックとポート マッピングも変更します。

永続データ

指名された sublane-data ボリュームホールド /data/sublane.db、その WAL ファイル、および /data/credentials.key。暗号化キーはデータベースに保管してください。既存の Compose サービス/ボリューム キーは保持されるため、以前のソース ビルドからのアップグレードは、同じ Compose プロジェクトから実行される場合、同じボリュームを使用し続けます。

Compose プロジェクト名/ディレクトリの一貫性を保ちます。これを変更すると、別の名前付きボリュームが作成され、既存のインスタンスが初期化されていないように見える可能性があります。走らないでください docker compose -f docker.compose.yaml down -v アップグレードまたはリカバリ時: データ ボリュームが削除されます。バインド マウントはサポートされていますが、そのホスト権限により、イメージの非 root アカウントがマウントされたディレクトリに書き込むことができる必要があります。ホスト パスの所有権が意図的でない限り、デフォルトの名前付きボリュームを優先します。

ソースからビルドする

代わりにローカルでビルドするには、リポジトリのクローンを作成し、source-build オーバーライドを使用します。

git clone https://github.com/murongg/SubLane.git
cd SubLane
docker compose -f docker.compose.yaml -f docker.compose.build.yaml up --build -d

その展開に対する後続のコマンドには両方のファイルを使用します。ビルドメタデータを設定するには:

VERSION=0.1.0-dev REVISION=$(git rev-parse HEAD) \
  docker compose -f docker.compose.yaml -f docker.compose.build.yaml build

Dockerfile は Go をコンパイルします TARGETOS/TARGETARCH ネイティブ ビルド段階から実行されるため、x86-64 上で ARM64 をビルドしても、コンパイラやフロントエンド ビルドはエミュレートされません。マルチプラットフォーム イメージは、構成された Buildx ビルダーを使用してビルドできます。

docker buildx build --platform linux/amd64,linux/arm64 \
  --build-arg VERSION=0.1.0-dev --output type=oci,dest=dist/sublane.oci.tar .

作成する dist 初め。通常のローカル ビルド/ロードは通常、1 つのプラットフォームを対象とします。 Docker を参照 クロスコンパイルのガイダンス.

スタンドアロン Linux バイナリ

お使いのマシンに一致するアーカイブをダウンロードし、 SHA256SUMS 同じリリースから:

• sublane_VERSION_linux_amd64.tar.gz：x86-64。
• sublane_VERSION_linux_arm64.tar.gz：AArch64。

Linux では、ダウンロードしたファイルを確認し、新しいバージョンのディレクトリにアーカイブを抽出して、次のコマンドを実行します。

sha256sum --check --ignore-missing SHA256SUMS
./sublane --version
SUBLANE_ADDR=127.0.0.1:8080 SUBLANE_DATA_DIR=/srv/sublane/data ./sublane

アーカイブには、実行可能ファイル、AGPL およびサードパーティのライセンス テキスト、Compose ファイル、環境の例、展開/バックアップのドキュメントが含まれています。データ ディレクトリをバージョン管理された実行可能ディレクトリの外に置き、プライベートにしてサービス ユーザーが書き込みできるようにし、永続的な操作にはプロセス スーパーバイザを使用します。ガイド付きインストーラーは、systemd ユーザー サービスを使用してこのセットアップを実行できます。ゲートウェイを root として実行しないでください。

デモモード

インストーラーが提供するのは、 通常のインスタンス または 読み取り専用デモ ランタイムの選択後。通常モードはデフォルトのままです。デモ モードを直接選択するには:

curl -fsSL https://raw.githubusercontent.com/murongg/SubLane/main/scripts/install.sh | bash -s -- --demo

--demo 両方で動作します --runtime docker そして --runtime binary。追加 --non-interactive 残りの選択肢にはデフォルトを使用します。インストーラーが書きます SUBLANE_DEMO=true に .env Compose または sublane.env バイナリ サービスの場合、インストール後にパブリック デモ ログインが表示されます。継承された SUBLANE_DEMO インストーラーが選択したモードは上書きされません。

デモ サポートは、選択したリリースの検証済み構成に存在する必要があります。インストーラーは、コンテナーのプル/開始、またはサービスの有効化を行う前に、古いリリースを拒否します。使用 --version をクリックして、デモ サポートを含むリリースを選択します。通常のインスタンスには戻りません。

デモ サポートを含むビルドでは、次のコマンドを使用して読み取り専用デモを開始します。

SUBLANE_DEMO=true ./sublane

通常のサーバーアドレスを開いて選択します デモを探索する、またはユーザー名でサインインします demo とパスワード sublane-demo。このアプリケーションには、明確にラベル付けされたサンプル サブスクリプション アカウント、プール、メンバー、API キー メタデータ、リクエスト履歴、および 30 日間の使用状況が表示されます。ナビゲーション、フィルター、言語、テーマの設定は正常に機能します。フォームは検査できますが、書き込み、資格情報の開示、OAuth、バックアップ、およびすべてのゲートウェイ呼び出し (WebSocket を含む) はブロックされます。ログインとログアウトは引き続き利用可能です。

開始するたびに、新しいプライベート一時データベースと暗号化キーが作成されます。デモモードが開かない SUBLANE_DATA_DIR、価格設定キャッシュ、または実際の認証情報を使用し、プロバイダーやリリース/価格設定サービスに連絡しません。正常なシャットダウンでは一時ファイルが削除されます。突然の殺害は残骸を残す可能性がある sublane-demo-* オペレーティング システムの一時ディレクトリ内のディレクトリ。再起動すると、最近の日付で例が再作成されます。デモを停止して設定を解除する SUBLANE_DEMO 通常のインストールを再開します。

開発には、次を使用します。 SUBLANE_DEMO=true make dev。このバージョンのComposeファイルでは、 SUBLANE_DEMO=true で .env そしてコンテナを再作成します。デモ サポートのない既存の公開バージョンは、最初にアップグレードまたは再構築する必要があります。通常のリッスン アドレス、外部発信元、および信頼できるプロキシの設定が引き続き適用されます。

ランタイム構成

スタンドアロン サービスは、これらのプロセス環境変数を読み取ります。 .env.example に例を示します。ロードされません .env 自動的にファイル化されます。 Compose 読み取り .env 独自の補間を行い、構成された環境をコンテナーに渡します。

Docker イメージはリッスン アドレスをオーバーライドします。 0.0.0.0:8080 そしてデータディレクトリへ /data. SUBLANE_IMAGE, SUBLANE_BIND_ADDRESS そして SUBLANE_PORT Compose のみを設定します。 SQLite は、新しいデータベース上で統合スキーマを初期化し、単一のデータベース接続を使用します。

起動時に新規データベースを初期化し、サポート対象の既存データベースには未適用のマイグレーションを順に適用します。001_settings.sql を含む初期の非互換構造は拒否されるため、元のディレクトリを保存して新規ディレクトリを使用してください。更新前にバックアップを作成して検証します。イメージの切り替えだけでは移行済みデータを元に戻せません。

SUBLANE_MAX_REQUEST_BODY_MB ゲートウェイ HTTP リクエスト、WebSocket メッセージ、および再構築された会話コンテキストに適用されます。 Responses およびストリーム イベントは、それぞれ別の 8 MiB 制限を維持します。リクエスト制限を変更した後、スタンドアロン サービスを再起動するかコンテナを再作成し、リバース プロキシ本体の制限を新しい値に合わせます。

オーバーライドする場合 SUBLANE_PRICING_URL、も設定されています SUBLANE_PRICING_HASH_URL 一致する SHA-256 ファイルに追加して、ドキュメントの整合性チェックを有効に保ちます。ハッシュ URL のないカスタム価格 URL は取得されて解析されますが、ハッシュ検証は行われません。

ゲートウェイのランタイムを変更するには、再起動またはコンテナーの再作成が必要です。現在の Compose ファイルはこれらの変数を渡します。スクリプト管理の更新では、既存の Compose ファイルが保持されます。に依存する前に、古い保存済み Compose ファイルに新しい環境エントリを追加してください。 .env オーバーライドします。アカウント/メンバーの同時実行設定は個別に保持されます。

HTTPS リバースプロキシ

セット SUBLANE_PUBLIC_URL などの正確な外部原点に https://sublane.example.comを実行し、サービスを再作成して環境の変更を有効にします。フォールバックはリクエストの Host ヘッダーから起点を取得するため、これはリバース プロキシの背後で必要です。構成されたオリジンは、ブラウザー要求のチェックとセキュア セッション Cookie に使用されます。元の Host ヘッダーを転送し、ストリーミングと WebSocket アップグレードを保持します。

セット SUBLANE_TRUSTED_PROXIES 独自のプロキシ ホップの CIDR アドレスに送信します。スタンドアロン SubLane バイナリが IPv4 ループバック経由で到達する場合は、次を使用します。 127.0.0.1/32 （追加 ::1/128 IPv6 ループバックの場合)。 Docker コンテナは、ホスト プロキシをループバックではなくブリッジ アドレスとして認識する場合があります。インストーラは、Docker モードでこの値を空のままにします。 --trusted-proxies SubLane が実際に参照するアドレスです。プロキシ コンテナの場合は、その固定アドレス、または専用の厳密にスコープされたプライベート サブネットを使用します。 SubLane は無視します X-Forwarded-For 直接ピアがこのリストに一致しない限り、チェーン内の最も右にある信頼できない IP をログイン制限に使用します。これが構成されている場合、SubLane への直接アクセスはプロキシに制限されます。これがないと、1 つのプロキシの背後にあるすべてのユーザーがプロキシのログイン制限を共有することになります。

同じホスト上で実行されている Caddy プロキシの場合:

sublane.example.com {
    reverse_proxy 127.0.0.1:8080
}

Caddy は TLS と WebSocket のアップグレードを処理し、SSE 応答を自動的にフラッシュします。デフォルトのフラッシュ動作を維持して、クライアントの切断によってアップストリームの作業をキャンセルできるようにします。ネガティブ flush_interval キャンセル動作を変更します。を参照してください。 Caddy リバース プロキシ リファレンス。プロキシが別のコンテナである場合は、Compose サービス名を使用します。 sublane:8080 共有ネットワーク上。 127.0.0.1 プロキシ コンテナ内とは、そのコンテナ自体を指します。

既存の Nginx インストールの場合は、マップを http コンテキストに移動し、その HTTPS サーバー ブロック内の次の場所を使用します。

map $http_upgrade $sublane_connection {
    default upgrade;
    ''      close;
}

location / {
    proxy_pass http://127.0.0.1:8080;
    proxy_http_version 1.1;
    proxy_set_header Host $http_host;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $sublane_connection;
    proxy_buffering off;
    proxy_read_timeout 650s;
    proxy_send_timeout 650s;
    client_max_body_size 128m;
}

# Web backup uploads/downloads can be larger and last up to 15 minutes.
location /api/settings/backup/ {
    proxy_pass http://127.0.0.1:8080;
    proxy_http_version 1.1;
    proxy_set_header Host $http_host;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_request_buffering off;
    proxy_buffering off;
    proxy_read_timeout 950s;
    proxy_send_timeout 950s;
    client_max_body_size 256m;
}

親 Nginx サーバーで HTTPS 証明書を構成します。の Nginx WebSocket ガイド 明示的なアップグレード ヘッダーについて説明します。制限では、他のプロキシ層でのリクエスト/バックアップ サイズも許可する必要があります。ゲートウェイ自体の認可と本体制限は引き続き有効です。

アップグレード

1. リリース ノートを確認し、現在のイメージ バージョン/ダイジェストを記録します。

2. 一貫性のあるバックアップをエクスポートし、データ ボリュームからコピーします。

   docker compose -f docker.compose.yaml exec sublane sh -c 'mkdir -p /data/backups'
   docker compose -f docker.compose.yaml exec sublane sublane backup --output /data/backups/pre-upgrade.sublane-backup.tar.gz
   docker compose -f docker.compose.yaml exec sublane sublane backup verify --input /data/backups/pre-upgrade.sublane-backup.tar.gz
   docker compose -f docker.compose.yaml cp sublane:/data/backups/pre-upgrade.sublane-backup.tar.gz ./pre-upgrade.sublane-backup.tar.gz
   chmod 600 ./pre-upgrade.sublane-backup.tar.gz

   アップグレードごとに新しいファイル名を使用します。既存のバックアップが上書きされることはありません。アーカイブには暗号化キーが含まれており、プライベート ストレージに属します。

3. 変化 SUBLANE_IMAGE で .env 選択したバージョンに変更し、プルして再作成します。

   docker compose -f docker.compose.yaml pull
   docker compose -f docker.compose.yaml up -d
   docker compose -f docker.compose.yaml ps
   docker compose -f docker.compose.yaml logs --tail=100 sublane

4. 健全性、サインイン、予期されるアカウント/プール/キー、および明示的に承認された 1 つのクライアント呼び出しを確認します。新しいデータベースは、起動時に統合された SQLite スキーマを受け取ります。イメージの健全性は、実際のプロバイダーの承認ではなく、プロセス/データベースの準備状況を検証します。

リカバリとロールバック

イメージ タグだけを変更してもデータベースはロールバックされません。リリースでスキーマが移行された場合は、アップグレード前のアーカイブを、対象の古いバイナリ/イメージを含む新しいディレクトリに復元し、現在のサービスを停止して、復元されたディレクトリに切り替えます。検証が完了するまで、元のボリュームを保持してください。 2 つのプロセスが同じ SQLite ディレクトリを共有しないようにしてください。

の バックアップガイド CLI および Web 復元の準備と、Compose オーバーライドについて説明します。 /data/restore-ready。そのディレクトリがアクティブな間は、後の起動でも復元オーバーライドを使用し続けます。新しいスキーマからのバックアップは、それを認識しない古いリリースでは開くことができません。

コンテナの検証

Docker エンジンが動作している場合:

docker compose -f docker.compose.yaml config --quiet
docker compose -f docker.compose.yaml -f docker.compose.build.yaml config --quiet
docker buildx build --load --build-arg VERSION=0.0.0-test -t sublane:smoke .
bash scripts/container-smoke.sh sublane:smoke 0.0.0-test

スモーク スクリプトは、ネットワークを無効にした状態で、独自の名前付きの使い捨て可能なボリュームとコンテナを作成します。健全性、バージョン、非 root 実行、読み取り専用ランタイム パス、合成認証情報を使用した初回実行セットアップ、キーのアクセス許可、バックアップ/検証/復元、再起動後の永続性をチェックします。それらの一時リソースのみが削除されます。上流のプロバイダーに連絡したり、既存のインスタンス データを使用したりしません。 CI は、ネイティブの amd64 および arm64 ランナーに対して同じチェックを実行します。