アプリケーションはあなたの 1 人によって共有されており、作業者は Docker デプロイメント モードの下でデプロイメントとバージョン アップグレードを簡素化する方法を確認します。 核心は非常に単純です。構成とコードを分離し、アップグレード時にのみコードを変更し、バックアップから構成を戻します。
01 |アップグレードサービス
アップグレードの最初のステップはコードではありませんが、ファイルが占有されたりエラー状態になったりするのを避けるために、まず実行中のコンテナを停止します。以下のコンテナ名 ontoforge_app_1 docker-compose のデフォルトの命名規則（プロジェクト名_服务名序号）より、请先用 docker ps 環境内の実際のコンテナ名を確認してください：
docker ps
docker stop ontoforge_app_1
この方法の利点は、古い旅程を自動で実行できることです。 docker-compose.yml 次に、そこからデータベース構成とポート構成をコピーできます。
mv ontoForge ontoForge_bak
このワンステップの意図は、一般に単一のフローチャートで使用できます。古いカタログは削除されませんが、構成ソースとして「凍結」され、後続の新しいカタログはここから独自の構成を取得します。
LR 組織図[运行中的容器
ontoforge_app_1] –>|ドッカーストップ| B[容器停止]
B –>|mv onForge onForge_bak| C[旧目录备份
保留 docker-compose.yml]
C –> D[作为配置来源
供新目录复制]
02 |最新のコードを取得する
バックアップが完了したら、最新バージョンのクローンを作成します。
git clone git@github.com:zhengwanbo/ontoForge.git
新しいディレクトリに入ったら、新しいディレクトリを比較します docker-compose.yml バックアップディレクトリ内の設定。ウェアハウス内のファイルがデフォルトのテンプレートであるか、無視された場合は、バックアップ ディレクトリ内の設定をコピーして戻す必要があります。ウェアハウス内のファイルに実際の構成が含まれている場合は、それをカバーする必要はありません。
cd ontoForge
cp ../ontoForge_bak/docker-compose.yml ./
このステップは実践において最も重要な場所です。コードは最新であり、設定はオリジナルのものです。構成はオリジナルのままです。
これら 2 つのソースと個別の関係の間で、単一の画像「コード」と「構成」を使用できます。
フローチャート TB サブグラフ 新学院 G[git clone
最新 ontoForge]
サブグラフの終わり 旧電影 B[ontoForge_bak
docker-compose.yml]
終了 G –> N[新目录 ontoForge]
B –>|cp コピー回电影| NN –> R[代码最新 + 配置不变]
03 |古いコンテナとミラーイメージをクリーンアップする
セットアップ後、古いコンテナーとミラー イメージをクリーンアップし、キャッシュまたは古いレイヤーを使用する場合はビルドを避けます。
docker rm ontoforge_app_1
docker images
# 注意：docker image prune -f 会清理所有悬空镜像，多项目共用主机时请谨慎
docker image prune -f
# 若镜像不存在或仍被占用会报错，可先确认再删除
docker rmi localhost/ontoforge_app || echo "镜像不存在或仍被占用，请检查 docker ps -a"
docker images
これは前の時間であり、使用しない画像を再実行するので、中間の画像を選択することをお勧めします。 docker images 該当する履歴ミラーイメージが実際に削除されたことを確認して、次のステップに進みます。
注文のクリア自体にも依存関係があり、コンテナが最初に削除されず、ミラー イメージがスムーズに削除できないことがよくあります。
LR 組織図[docker rm
删除旧容器] –> B[docker image prune -f
清理无用镜像]
B –> C[docker rmi
删除 app 镜像]
C –> D[docker images
确认已删除]
04 |再構築して開始
古いミラー イメージが削除されたことを確認した後、最新バージョンを再構築し、バックグラウンドを開始します。
docker-compose up -d --build
docker-compose ps
docker-compose logs -f --tail=50
--build ミラーイメージを強制的に再構築し、-d コンテナをバックグラウンドで実行させる docker-compose ps コンテナのステータスを確認し、ログを使用して正常なサービスを確認します。アップグレードに失敗した場合は返却可能 ontoForge_bak ディレクトリは古い構成を再度使用します docker-compose up -d 転がる。
05 | 小结
このプロセスは 3 つのステップに要約できます。サービスを停止して古いディレクトリをバックアップし、新しいコードを複製して独自の構成にコピーし、古いイメージをクリーンアップして、再構築後に再構築します。その価値は「構成」と「コード」を分離することにあり、通常、アップグレード時に環境を再構成する必要はありません。ただし、古いバックアップ ディレクトリがまだ存在し、データベースとその他の状態データが永続ボリュームに転送されていることが前提となります。そうしないと、構成またはデータが失われる可能性があるため、アップグレードする前に、docker-compose.yml と主要なデータ ボリュームを個別にバックアップすることをお勧めします。 Docker を使用する場合、小規模プロジェクトのデプロイは、シンプルで安定した方法です。
組織図 LR S1[停服务 + 备份旧目录] –> S2[克隆新代码 + 复制回配置]
S2 –> S3[清理旧镜像 + 重新 build]
S3 –> S4[升级完成]
フォローしてください，和AI下載游戏~