運用・保守

OpenShip セルフホスト型デプロイメントのチュートリアル: CLI と Docker を使用した CI/CD プラットフォームの構築

OpenShip セルフホステッド デプロイメント プラットフォームの位置付け、CLI および Docker のインストール方法、さらにプロジェクトの初期化、自動デプロイメント、ドメイン名証明書、データベース、バックアップ、オンラインにする前のセキュリティ チェックについて紹介します。

OpenShip は、CI/CD が組み込まれたオープンソースのセルフホスト型アプリケーション展開プラットフォームであり、デスクトップ アプリ、Web コンソール、および CLI を提供します。その目標は、コード ウェアハウスをサーバーに接続した後、開発者がテクノロジー スタックを自動的に識別し、コンテナーを構築し、サービスを構成し、リリースを完了できるようにすることで、パイプラインの手書きや YAML のデプロイの作業を軽減することです。

このプロジェクトは、Node.js、Python、Go、Rust、PHP、Ruby、Java、.NET、Docker、monorepo をカバーしており、データベース、ドメイン名、TLS 証明書、CDN、電子メール、バックアップ、監視も同じインターフェイスに配置します。 OpenShip Cloud に接続することも、独自の Linux VPS または専用サーバーにデプロイすることもできます。

簡単な答え

npm を使用して CLI をインストールします。

1

npm i -g openship

OpenShip バックグラウンド サービスを開始します。

1

openship up

管理インターフェイスを開きます。

1

openship open

デプロイ、初期化、公開するプロジェクト ディレクトリを入力します。

1
2
3

cd your-project
openship init
openship deploy

openship init は現在のディレクトリを OpenShip プロジェクトに接続するために使用され、openship deploy はビルドとデプロイメントをトリガーします。実稼働サーバーで初めて使用する前に、重要ではない項目を使用して永続ディレクトリ、ドメイン名解決、証明書、バックアップおよびロールバックのプロセスを検証することをお勧めします。

OpenShip はどのような問題を解決しますか?

Web プロジェクトを手動でデプロイするには、通常、Git プル、イメージ構築、リバース プロキシ、TLS、環境変数、データベース、ログ、バックアップ、リリース ロールバックを個別に処理する必要があります。 OpenShip は、これらのタスクを 1 つのデプロイメント プラットフォームに集中させます。

機能 使い方
内蔵CI/CD プッシュ デプロイ、プレビュー環境、テストおよび運用プロセス、ロールバック
複数のテクノロジースタック 共通言語、Docker、monorepo プロジェクトを自動的に処理
バックエンドサービス Postgres、MySQL、MongoDB、Redis、ワーカー、ストレージの管理
ドメインとTLS ドメイン、Let’s Encrypt、ワイルドカード証明書、および自動更新の構成
バックアップ データベースとボリュームを定期的にバックアップし、リカバリおよびエクスポート ポータルを提供します。
モニタリング リアルタイムのビルド ログ、コンテナーのメトリック、およびリソースの使用状況を表示します。

これは、スタンドアロンの CI Runner よりも、軽量の PaaS またはセルフホスト展開コントロール パネルに近いものです。デプロイ結果では標準の Docker コンテナが使用され、異なるサーバーやベンダー間で簡単に移行できます。

インストール前の準備

ローカルでの経験しかない場合は、開発マシンに CLI をインストールできます。長期的なセルフホスティングを準備する場合は、スタンドアロン Linux サーバーを使用し、事前に以下を確認することをお勧めします。

  1. サーバーはコード ウェアハウスとミラー ソースにアクセスできます。
  2. DNS レコードはサーバーのパブリック ネットワーク アドレスを指すことができます。
  3. HTTP、HTTPS、およびプラットフォームで実際に必要なポートがファイアウォールで許可されています。
  4. ディスクスペースには、ミラー、データベース、永続ボリューム、およびバックアップを収容できます。
  5. 管理者認証、鍵保管、オフサイトバックアップが計画されています。

OpenShip はソース コード、デプロイメント資格情報、環境変数、データベースにアクセスできるため、保護されていないコンソールをパブリック ネットワークに直接公開すべきではありません。正式にオンラインにする前に、現在のバージョンのドキュメントとセキュリティに関する指示を読み、まず隔離された環境でアップグレードとリカバリを確認する必要があります。

方法 1: CLI 経由でインストールする

npm グローバル インストールを使用した公式クイック スタート:

1

npm i -g openship

公式はシェルのインストール入り口も提供しています:

1

curl -fsSL https://get.openship.io | sh

サーバー上でリモート スクリプトを実行する前に、スクリプトの内容をダウンロードして確認することをお勧めします。インストールが完了したら、バックグラウンド サービスを開始します。

1

openship up

このコマンドは、OpenShip をバックグラウンド サービスとしてインストールし、起動と例外時の自動再起動を構成します。フォアグラウンドで起動ログを観察するときに実行する必要があります。

1

openship up --foreground

コンソールを開きます。

1

openship open

バックグラウンド サービスを停止します。

1

openship stop

フォアグラウンド実行は、初めてのトラブルシューティングに適しています。構成とデータ ディレクトリが正しいことを確認した後、バックグラウンド サービス モードに切り替えます。

方法 2: Docker Compose を使用する

コンテナ、ネットワーク、ボリュームを明示的に制御したい場合は、公式リポジトリから Compose スタックを起動できます。

1
2
3
4

git clone https://github.com/oblien/openship.git
cd openship
cp .env.example .env
docker compose up -d

.env.example をコピーした直後にパブリック ネットワークを起動しないでください。まず .env を開き、すべてのパスワード、キー、外部アドレス、ポート、および永続化構成を確認し、サンプル値を置き換えてから、Compose を実行します。

サービスのステータスとログを表示します。

1
2

docker compose ps
docker compose logs -f

サービスを停止しますが、ボリューム データは保持します。

1

docker compose down

Compose で管理されているボリュームが削除されるため、バックアップなしで -v を追加しないでください。アップグレードする前に、現在のイメージまたはバージョンを記録し、データベースをエクスポートし、永続ボリュームをバックアップして、検証済みのバージョンに確実に戻せるようにする必要があります。

最初のプロジェクトをデプロイする

ローカル プロジェクト ディレクトリを入力します。

1
2

cd your-project
openship init

初期化プロセスは、OpenShip プロジェクトを作成または選択し、現在のディレクトリをプロジェクトに関連付けるために使用されます。完了後にデプロイメントをトリガーします。

1

openship deploy

プラットフォームはテクノロジー スタックを識別し、アプリケーションを構築し、実行環境を構成しようとします。公式には構成ファイルを減らすことに重点が置かれていますが、展開前に次の情報を明確にする必要があります。

  • アプリケーションのリスニング ポートとヘルス チェック パス。
  • ビルド コマンド、起動コマンド、およびランタイム バージョン。
  • 必須の環境変数とシークレット。
  • 永続的に保存する必要があるディレクトリ。
  • データベースの移行を実行する必要がある場合。

自動検出は通常のプロジェクトに適していますが、アプリケーションの起動プロセスの理解に代わるものではありません。ビルドに失敗した場合は、まずリアルタイム ビルド ログから、検出された言語、バージョン、コマンドが正しいかどうかを確認します。

Docker Compose プロジェクトをデプロイする

OpenShip公式の手順では、既存のComposeファイルをそのままデプロイできます。 Web サービス、ワーカー、データベース、Redis を含むプロジェクトの場合、これは通常、すべてのサービスを再構成するより簡単です。

デプロイメントをコミットする前に、Compose ファイルを確認してください。

1

docker compose config

ローカル起動の検証:

1
2

docker compose up -d
docker compose ps

特別な検査が必要です:

  1. 開発環境のバインド マウントを実稼働環境に直接持ち込まないでください。
  2. データベースとキャッシュは、認証なしでホスト ポートを公開すべきではありません。
  3. シークレットを compose.yaml にハードコーディングしないでください。
  4. サービスには合理的なヘルスチェックと再起動戦略が必要です。
  5. 永続ボリュームはバックアップとリカバリのテストに含める必要があります。

Local Compose を開始できることは、コンテナーの基本構成が利用可能であることを証明するだけです。ドメイン名、TLS、外部ネットワーク、リソース制限、実稼働データの移行は、OpenShip ターゲット環境で個別に検証する必要があります。

ドメイン名と TLS を構成する

OpenShip は、ドメイン名管理、Let’s Encrypt、ワイルドカード証明書、自動更新をサポートしています。一般的なプロセスは次のとおりです。

  1. DNS サービスプロバイダーでドメイン名を展開サーバーに解決します。
  2. OpenShip プロジェクトにドメイン名をバインドします。
  3. プラットフォームが証明書を申請して構成するまで待ちます。
  4. HTTP から HTTPS へのジャンプを確認します。
  5. 外部ネットワークから証明書チェーンと更新ステータスを確認します。

証明書のアプリケーションが失敗した場合は、まず DNS が有効になっているかどうか、ポート 80 と 443 が他のリバース プロキシによって占有されているかどうか、CDN プロキシ モードが ACME 検証に影響を与えているかどうかを確認します。通常、ワイルドカード証明書には DNS 検証も含まれており、必要なアクセス許可は必要なドメイン名に限定される必要があります。

データベース、ストレージ、バックアップ

プラットフォームによってリストされているバックエンド機能には、Postgres、MySQL、MongoDB、Redis、Workers、WebSocket、Storage が含まれます。データベースを作成した後、接続情報を Git に送信しないように、プラットフォームの Secret または環境変数を介してアプリケーションに挿入する必要があります。

バックアップ機能はデータベースとボリュームを対象としていますが、「スケジュールされたタスクが設定されている」＝「リストアできる」わけではありません。オンラインにする前に、少なくとも 1 つの回復訓練を完了してください。

  1. テストデータを作成します。
  2. 手動または定期的にバックアップを生成します。
  3. バックアップをサーバーの外にエクスポートします。
  4. 分離されたプロジェクトまたはテスト データベースに復元します。
  5. データ、権限、アプリケーションのバージョンが一貫していることを確認します。

バックアップが同じサーバー上の同じディスクにのみ保存されている場合でも、ハード ドライブに障害が発生したり、ホストが侵入されたりすると、バックアップが失われる可能性があります。運用環境では、オフサイトのコピーを維持し、バックアップ ファイルの暗号化とアクセス制御を構成する必要があります。

プッシュデプロイとロールバック

OpenShip は、プッシュからデプロイ、プレビュー環境、ステージング/実稼働プロセス、およびロールバックを提供します。コード リポジトリにアクセスするときは、展開トークンに必要以上の組織権限やリポジトリ権限を与えないでください。

実稼働リリース プロセスを次のように設定することをお勧めします。

  1. プル リクエストによりプレビュー環境が作成されます。
  2. マージ後にステージングをデプロイします。
  3. 健康診断と必要な検査を完了する。
  4. 確認後に本番環境にリリースします。
  5. エラー率、リソース、主要なインターフェースを監視します。
  6. 例外が発生した場合は、以前に検証された製品にロールバックします。

コンテナーがロールバックしても、データベース スキーマの変更が自動的に元に戻されない場合があります。移行を設計するときは、下位互換性の手順を優先し、データベースの回復プロセスをアプリケーションのロールバックとは別に検証する必要があります。

3 つの管理方法からどのように選択すればよいですか?

インターフェース シナリオに適しています
デスクトップアプリ 一人での開発、ローカル管理、リアルタイム ログの表示
ウェブダッシュボード チーム共有、ブラウザーリモート管理
CLI 自動化、スクリプト、CI 環境、クイック アクション

このプロジェクトは、自動化ツールまたは AI エージェントと統合するための REST API および MCP インターフェイスも提供します。自動化クライアントの資格情報を作成するときは、独立した ID、最小限の権限、および取り消し可能なトークンを使用します。導入、削除、回復などの影響の大きい操作については、手動による確認または承認を維持します。

現状とロードマップは区別する必要がある

公式 README では、コア機能が本番環境に対応し、現在開発中であると説明されていますが、ドキュメントがまだ改良中であることも明確にされています。マルチノード クラスター、負荷分散インターフェイス、プライベート ネットワーク、高度な監視、ビジュアル CI/CD パイプラインがフォローアップ プランとしてリストされています。

したがって、評価は現在のリリース バージョンで実際に利用可能な機能に基づいて行う必要があり、ロードマップを提供されたものとして扱うべきではありません。実稼働移行の場合は、まず、単一ノードの障害回復、アップグレードの互換性、バックアップのエクスポート、権限の分離、監査ログなど、本当に必要な機能を確認します。

よくある質問

openship up 起動後にコンソールを開くことができません。

まずフォアグラウンド モードを使用してエラーを観察します。

1

openship up --foreground

次に、ポートの占有率、ファイアウォール、サービスのステータス、ログを確認します。リモート サーバー上で実行している場合、openship open によって開かれたアドレスは、管理側のネットワークからも到達可能である必要があります。

自動認識が正しく構築されていません

プロジェクトのルート ディレクトリ、ロック ファイル、Dockerfile、Compose ファイル、およびランタイム バージョン宣言を確認してください。また、モノリポジトリでは、プラットフォームがウェアハウスのルート ディレクトリで間違ったエントリを選択しないように、実際のアプリケーションのサブディレクトリを確認してコンテキストを構築する必要があります。

ドメイン名は解決されましたが、証明書の発行に失敗しました。

DNS がターゲット サーバー アドレスを返すこと、ポート 80/443 が他のサービスで使用されていないこと、クラウド ファイアウォールが外部アクセスを許可していること、CDN またはリバース プロキシが検証リクエストをブロックしていることを確認します。

既存の実稼働プラットフォームをすぐに置き換えることはできますか?

全体を直接移行することはお勧めできません。まずはロールバック可能なリスクの低いプロジェクトを選択し、デプロイ、ログ、監視、バックアップとリカバリ、バージョンアップグレード、障害対応などを検証し、徐々に利用範囲を拡大していきます。

OpenShip は誰に適していますか?

OpenShip は、独自の Linux サーバー上でオールインワンのデプロイメント エクスペリエンスを必要としているが、プロジェクトごとに CI、リバース プロキシ、証明書、データベース スクリプトを個別に管理したくない、個々の開発者または小規模チームに適しています。 Docker を介して基本的な移植性を維持したい環境にも適しています。

組織がすでに成熟した Kubernetes、GitOps、アイデンティティ ガバナンス、および可観測性システムを導入している場合、新しい展開コントロール プレーンを導入すると管理の重複が増える可能性があります。ここで、権限モデル、監査、クラスター機能、既存のパイプライン統合コストを比較することから始めます。

概要

OpenShip は、コードの構築、コンテナのデプロイ、ドメイン証明書、データベース、バックアップ、監視を同じプラットフォームに組み込み、デスクトップ、Web、CLI、API、MCP を介した管理を可能にします。これを体験する最も簡単な方法は、CLI をインストールして openship up を実行することです。本番環境のセルフホスティングの場合は、シークレット、永続性、バックアップとリカバリ、アップグレードとロールバックの検証に重点を置いて、分離されたテスト プロジェクトから始めるのがより適しています。

プロジェクトアドレス: oblien/openship

公式ドキュメント: openship.io/docs