デプロイメント
「デプロイメント」画面には、アプリケーションのデプロイ履歴が表示されます。アプリケーションのデプロイ元、Gitリポジトリを使用している場合はブランチや自動デプロイが有効かどうかなどを確認できます。
アプリケーションのデプロイ
自動デプロイを有効にすると、Gitリポジトリのブランチにコミットが行われるたびにアプリケーションがデプロイされます。アプリケーションの「設定」画面で、自動デプロイの設定を行うことができます。
アプリケーションを手動でデプロイするには、「デプロイする」をクリックして、デプロイするブランチを選択し（メインブランチをデプロイする場合は空欄のまま）、「アプリケーションのデプロイ」をクリックします。
アプリケーションを再度ビルドせずに再起動する場合は、「アプリケーション構築をスキップ」を選択して「アプリケーションをデプロイ」をクリックします。
最新のコミットを再度デプロイする場合は、デプロイメント上で省略記号をクリックし、「再デプロイ」をクリックします。
完了した最新のデプロイメントにロールバックするには、「ロールバック」をクリックします。
アプリケーションを開くには、「アプリケーションを移動する」をクリックします。
ヘルスチェックでシームレスなデプロイ
アプリケーションにヘルスチェックが含まれており、ウェブプロセス内でヘルスチェックのパスを定義している場合、デプロイ間にアプリがダウンすることはありません。アプリケーションがデプロイまたは再デプロイされるか、Podが再起動されると、新たなPodの準備が整うまで古いPodが実行されます。
弊社では10秒ごとにヘルスチェックパスを確認し、3回連続して応答しない場合にはPodを再起動します。
本番アプリケーションにヘルスチェックを導入することは、デプロイ時のアプリのダウンを最小限に抑え、システムの信頼性が確保されることから強く推奨されます。ヘルスチェックは、アプリケーションのステータスを継続的に監視し、更新中も正常に動作することを保証します。また、メンテナンスや予期しない障害が発生した際には、必要に応じて負荷を迅速に再配置できるようにします。この先回りしたアプローチにより、アプリケーションの安定性を維持しながら、エンドユーザーにシームレスな体験を提供することができます。
デプロイメントの通知
MyKinstaの画面右上のユーザー名をクリックし、「ユーザー設定」＞「通知」に移動すると、「デプロイメントの失敗」セクションで、デプロイメントに失敗した際にメール通知を受け取る設定を行うことができます。
履歴
このセクションには、過去すべてのデプロイメントが表示されます。「デプロイする」をクリックすると、アプリケーションをデプロイすることができます。 Gitリポジトリからデプロイする場合は、ブランチを選択する必要があります。Dockerイメージからデプロイする場合は、Dockerイメージのタグとダイジェストを入力します。
以前のコミットを再デプロイするには、コミットの横にある3つの点をクリックし、「再デプロイ」を選択してください。
デプロイが進行中の場合は、「デプロイする」の代わりに「デプロイメントを中止」ボタンが表示されます。デプロイメントを中止すると、進行度によって、デプロイメントのビルドまたはロールアウトが中止されます。
特定のデプロイメントの詳細
過去のデプロイメントのいずれかをクリックすると、その特定のデプロイメントのログと「デプロイメントの詳細」が表示されます。デプロイメントログを確認して、プロセスが失敗した場所を特定することができます。
デプロイメントログ
アプリケーションをデプロイすると、デプロイメントログにデプロイメントの各ステップと成功したかどうかが表示されます。例えば、Nixpacksを使用するアプリケーションでは、ログに以下のステップが表示されます。
- GitHubからソースコードを取得
- ソースコードの取得に成功
- Nixpacksを使ったDockerイメージのビルド
- Dockerイメージのビルドに成功
- Dockerイメージをレジストリにプッシュ
- Dockerイメージのプッシュに成功
- ロールアウトを開始
- アプリが正常にデプロイ
また、ビルド環境とビルドパスも表示されます。BuildpacksまたはDockerfileを使用するようにビルド環境を変更するには、「ビルド設定を変更」をクリックします。デプロイメントがいずれかの段階で失敗した場合、ログにはデプロイメントが失敗した理由を示すエラーメッセージが表示されます。エラーのトラブルシューティング方法はこちらをご覧ください。
ランタイムログ
デプロイメントに成功すると、ランタイムログが表示されます。デプロイメントには成功してもアプリケーションの実行に失敗した場合、ランタイムログで根本的な理由を特定できることがあります。
デプロイメントの詳細
Gitリポジトリの場合は、次のような情報が表示されます。
- Gitリポジトリとブランチ名
- コミット ID（Gitサービスのコミットへのリンク）
- デプロイの実行者
- デプロイの開始日時
- デプロイ時間（デプロイが完了するまでの時間）
- デプロイの種類（手動または自動、自動デプロイは「コミットに際し自動でデプロイ」を選択した場合のみ）
- データセンターの所在地
- コミットメッセージ
ビルドプロセスのCPUとRAMを増減するためにリソース設定を変更するには、アプリケーションの「設定」画面に移動します。このコミットからアプリケーションを再デプロイするには、「再デプロイ」をクリックします。
Dockerイメージの場合は、以下のような情報が表示されます。
- Dockerイメージへのパス
- デプロイの開始日時
- デプロイの種類
- データセンターの所在地
デプロイメントを中止する
時にアプリケーションのデプロイを中止する必要性が生じることがあります。例えば、コードに変更を加えたい場合や、デプロイに予想以上に時間がかかり、アプリケーションのコードを調査したい場合などが考えられます。
デプロイメントを中止するには、アプリケーションの「デプロイメント」 画面、または「デプロイメントの詳細」で「中止」をクリックしてください。
モーダル画面で「デプロイメントを中止」をクリックして確定します。必要に応じて、完了済みの最新のデプロイメントにロールバックするか、以前のデプロイメントを再デプロイすることができます。
デプロイメントをロールバックする
アプリケーションの最新バージョンで予期せぬバグやエラーが発生した場合、ロールバック機能を利用して、最新のデプロイメントに即座にロールバックし、ダウンを最小限に抑えることができます。
ロールバック機能は、直近で成功したデプロイメントから既存のビルドイメージを使用し、アプリケーションを再デプロイするため、実質的にビルドステップを省略することができます。これによって、アプリケーションの迅速な立ち上げと実行が可能になります。
なお、ロールバックを行なっても、以下の内容が変更されることはありません。
- ビルドプロセス
- ビルドパック
- ビルドリソース
- 環境変数
- ビルドまたはDockerfileのパス
デプロイメントをロールバックするには、「デプロイメント」画面の「詳細」セクションにある「ロールバック」をクリックします。
確認画面で、再度「ロールバック」をクリックしてください。
以前のバージョンのアプリケーションをデプロイする場合、その特定のデプロイメントの再デプロイが必要になります。