OpenShip v0.4.7 サーバー移行の検収

旧サーバーのコンテナは停止表示なのに利用者は接続できる、または新しいコンテナは起動しているのにデータベースや定期処理が動いていない。

最短の解決策は、OpenShip v0.4.7のサーバー移行を「移行処理が完了したか」ではなく、コンテナ、データボリューム、認証情報、証明書、バックグラウンド処理、旧ノードへの切り戻しを個別の証拠で検収することです。公式の変更履歴では、v0.4.7にリモートDocker移行経路の信頼性改善が含まれていますが、製品画面の完了表示だけで本番利用可能とは判断できません。(openship.io)

この内容は、既存のDockerアプリを移設する開発者、新しい本番サーバーへ切り替える運用担当者、継続稼働用のノードを調達する技術責任者向けです。単なる初回デプロイの手順ではなく、切り替え前に「何を確認できれば合格か」を決めたい場合に使ってください。

最終更新：2026年8月3日。OpenShipの公式サイト、公式ドキュメント、公開リポジトリの運用記述を確認しています。次回は新しい移行対応版の公開、コンテナ管理方式の変更、データボリュームまたは証明書処理の変更時に再確認してください。 (openship.io)

最初に移行範囲と戻し先を固定します

OpenShipの画面で対象プロジェクトを開き、実際に稼働しているサービスを一覧化します。ここで見る対象は、Web、API、ワーカー、データベース、Redis系の補助サービス、オブジェクト保存領域、定期実行処理です。Compose定義に書かれていない手作業の依存先や、現在は停止中でも本番復旧に必要なサービスを除外すると、移行後に「コンテナは起動したのに機能が足りない」という状態になります。

移行前に次の証拠を保存してください。

• 旧サーバーのホスト名、IPアドレス、SSH接続先。
• OpenShipの実行バージョンと、対象プロジェクトのデプロイ識別子。
• 各コンテナのイメージ名、タグ、環境変数名、公開ポート。
• Compose定義、.envの項目一覧、データボリューム名。
• データベースのバックアップファイルと復元手順。
• DNS変更前のTTL、証明書の有効期限、旧ノードを残す期限。
• 問題発生時に旧サーバーへ戻す担当者と判断時刻。

OpenShipの公式ドキュメントでは、サーバーへの接続をSSHで行い、アプリのビルド、転送、起動、ルーティングを管理する流れが示されています。これは移行作業の入口であり、既存データの完全性や業務処理の継続を証明するものではありません。(openship.io)

コンテナとイメージは「表示」ではなく再構築で判定します

新ノードで確認するのは、管理画面の状態だけでは不十分です。対象サーバーへSSH接続し、実際のDocker Engineに存在するコンテナ、イメージ、ネットワーク、マウント先を照合します。

合格条件は次の4点です。

1. 予定した全サービスに実体のあるコンテナが存在する。
2. 各コンテナが想定したイメージタグまたはデプロイ識別子を使っている。
3. 環境変数、内部ネットワーク、公開ポートの対応が旧環境と一致する。
4. ホスト再起動またはコンテナ再起動後も、意図しない重複コンテナが発生しない。

次に、短時間の検証用デプロイを1回実行します。build型サービスは新ノード上で再構築できるか、image型サービスは必要なレジストリから取得できるかを確認し、ログに認証失敗、ポート競合、ヘルスチェック失敗がないかを見ます。再デプロイ後に古いコンテナが残っている場合は、手動削除で隠すのではなく、なぜサービス対応が二重になったのかを記録してから切り替えを止めてください。

旧コンテナが停止なのにサービスが正常な場合

旧コンテナが停止表示でもサービスが応答する場合、別のコンテナ、ホストプロセス、リバースプロキシ、キャッシュ、または新ノードが通信を受けている可能性があります。旧IPと新IPへ個別にHTTPリクエストを送り、DNSを経由しない状態で応答元を確認します。

証拠として、コンテナ一覧、実際の待受ポート、プロキシの転送先、アクセスログの時刻を保存してください。応答元が特定できないままDNSを切り替えると、旧環境と新環境の両方が処理を受け、二重登録や二重実行を起こす危険があります。

データベースとデータボリュームは復元後の書き込みまで試します

OpenShipのDocker移行でデータが失われるかどうかは、移行完了表示ではなく、保存先と復元結果で判断します。Dockerの公式資料でも、データボリュームはバックアップ、別コンテナへの復元、復元後の確認に使えると説明されています。(docs.docker.com)

最低限、次の順番で確認してください。

• 旧ノードと新ノードのデータボリューム名、マウントパス、所有者を照合する。
• データベースのテーブル数、主要レコード、最新更新時刻を比較する。
• オブジェクト保存領域から代表的なファイルを数件読み出す。
• 新ノードでテスト用レコードを作成し、読み出しと削除を行う。
• データベースまたはアプリを再起動し、テストレコードと既存データが残ることを確認する。
• バックアップを本番とは別の一時環境へ復元し、ログインや主要クエリを実行する。

「バックアップジョブが成功」と表示されるだけでは合格にしません。復元先でファイルが開けるか、データベースへ接続できるか、アプリケーションから参照できるかまで確認して初めて、復旧可能なバックアップと扱えます。

データベースとデータボリュームの件数が一致していても、アプリ固有の整合性までは保証されません。例えば、ユーザー情報は存在していても、添付ファイルの保存先、検索用インデックス、キューの未処理項目が欠落している場合があります。そのため、利用者が実際に使う登録、表示、更新、ファイル取得の流れを抽出して確認します。

秘密情報と権限は新ノードだけで再検証します

環境変数は「項目名があるか」ではなく、正しい環境の値が読み込まれているかを確認します。決済、メール、AI API、リポジトリ、オブジェクト保存領域などの資格情報を旧環境からそのまま複製する場合は、移行後に不要なキーを無効化し、用途ごとに最小権限へ戻してください。

確認対象は以下です。

• 本番用と検証用の環境変数が混ざっていない。
• リポジトリ取得用の認証情報が新ノードからだけ利用できる。
• 外部APIの許可元IPやコールバック先が新ノードに対応している。
• SSH管理ポート、データベースポート、内部サービスのポートが意図せず公開されていない。
• デプロイと復元のテストを管理者権限ではなく、必要最小限のアカウントで実施できる。

OpenShipをDocker Composeで動かす構成では、コントロールプレーンがホスト側のDocker環境へ強い権限を持つ構成になり得るため、利用方式と公開範囲を確認してください。公式の公開パッケージ説明でも、Compose利用時の権限範囲について注意が示されています。(npmjs.com)

ドメイン、証明書、長時間接続を切り替え前に確認します

DNSを変更する前に、検証用ホスト名またはローカルの名前解決で新ノードへ接続します。HTTPからHTTPSへの転送、証明書の対象名、プロキシヘッダー、WebSocket接続、アップロード、長時間処理を確認してください。

OpenShipは公式サイト上で、ドメイン接続、TLS、ルーティングをデプロイ経路に組み込む設計を説明しています。ただし、実際の証明書発行や自動更新が成功するかは、DNS、外部到達性、権限、既存証明書との関係に左右されます。(openship.io)

切り替え前の合格条件は、次のように具体化します。

• 新ノードの検証用ホスト名でHTTPとHTTPSが応答する。
• 証明書の対象ホスト名と有効期限を確認できる。
• WebSocketやストリーミング処理が一定時間維持される。
• ヘルスチェックがアプリケーションの実状態を確認している。
• DNS変更の開始時刻、旧ノードの継続稼働期限、切り戻し判断時刻を記録する。

切り替え判断はこの対照リストで決めます

新ノードを本番化してよい条件

• コンテナとイメージの照合が完了している。
• データベースの抽出確認と書き込み確認が完了している。
• バックアップを隔離環境へ復元できている。
• 秘密情報、外部API権限、管理ポートを確認している。
• HTTPS、WebSocket、主要ユーザーパスを検証している。
• 定期処理とキュー処理を一時停止または単一ノード実行に制御できる。
• 旧ノードを再起動してサービスを戻す手順が実行可能である。

旧ノードを残して延期すべき条件

• 新ノードでデータベースの書き込み結果を確認できない。
• 旧ノード停止後にどのプロセスが応答しているか不明である。
• 証明書の自動更新条件を確認できない。
• キューや定期処理を新旧どちらが担当するか決まっていない。
• 復元テストがバックアップジョブの成功表示だけで終わっている。
• 旧ノードへ戻すDNS、データ、認証情報の境界が決まっていない。

この条件に1つでも該当するなら、切り替えを延期してください。特にデータが新旧両方へ書き込まれる構成では、単純なDNSの戻しだけで状態を元に戻せないため、最後に成功した書き込み時刻と再同期方法を先に確定します。

バックグラウンド処理と切り戻しを実演します

本番切り替えの直前に、定期ジョブ、キューコンシューマー、メール送信、AI処理、Webhook受信を整理します。新旧サーバーが同時に処理を開始すると、請求、通知、外部API呼び出し、データ更新が二重になるためです。

切り替え後は、次の順番で確認します。

1. DNSまたはプロキシの切り替え時刻を記録する。
2. ログイン、主要画面、登録、更新、ファイル取得を確認する。
3. キューにテスト項目を1件投入し、1回だけ処理されることを確認する。
4. 定期処理の実行履歴と監視アラートを確認する。
5. 新ノードのログ、CPU、メモリ、ディスク、データベース接続数を監視する。
6. 異常時は旧ノードへ戻し、戻した後のデータ境界を記録する。

旧ノードが起動できるだけでは、切り戻し成功とはいえません。旧環境でアプリが起動し、必要なデータへ接続でき、外部サービスの認証が成立し、利用者の主要操作が完了するところまで実演してください。

移行範囲、データ量、外部連携、キューの有無によっては、1台のサーバー上で移行と切り戻しを同時に検証することが難しくなります。現在の環境に旧ノードを保持する余力がない場合は、サーバー運用に関する相談窓口で、検証用の独立ノードを一時的に確保する構成も比較してください。常時高負荷のアプリを長期運用するなら自前サーバーや既存クラウドが適する一方、移行期間だけ並行環境が必要な場合は、専用ノードをレンタルしたほうが本番環境を壊さずに検収できます。

最終的には、OpenShipの移行機能そのものではなく、あなたが保存した証拠で切り替えを判断します。新ノードのコンテナが稼働し、データの読み書きと復元が確認でき、証明書とバックグラウンド処理が制御され、旧ノードへ戻せる状態になってから、初めて本番移行を完了扱いにしてください。

移行前後の権限や復元手順を整理したい場合は、kvmbootのヘルプセンターも確認できます。並行検証用のノードをすぐに用意する必要があるなら、地域と用途を確認したうえで米国東部のMacレンタル環境を候補に加えると、現行サーバーを止めずに切り替え判定を進められます。