ジェシカ
約12のサービスとprestoなどの他のアプリケーションがあります。
サービスとアプリケーションごとにDockerコンテナを構築することを検討しています。それらすべてをドッキングするのは正しいですか？
Dockerコンテナが理想的なソリューションではないのはいつですか？
アルジェフアルモセラ
長所：
- すべてのサービスをコンテナ化した場合、チーム用にすばやくローカル環境をセットアップします。これは、開発チーム向けにセットアップされた迅速な環境になります。
- 「それは私の問題では機能しますが、あなたの問題では機能しません」を回避するのに役立ちます-私たちの開発問題の多くは通常、開発環境のセットアップに起因します。サービスをコンテナ化した場合、その大部分が別の場所にオフロードされます。
- より簡単なデプロイ-コードをデプロイするためのプロセスは私たち全員に異なりますが、それらをコンテナー化することで、事態は非常に簡単になります。
- より良いバージョン管理-すでにご存知のように、タグを付けることができます。これはバージョン管理に役立ちます。
- より簡単なロールバック-バージョン管理されているものがあるため、コードのロールバックがより簡単であると言えます。以前に動作していたバージョンをポイントするだけの場合もあります。
- 簡単なマルチ環境のセットアップ-ほとんどの開発チームがそうであるように、我々が設定し
local、integration、stagingおよびproduction環境を。これは、サービスがコンテナ化されている場合に簡単に実行でき、ほとんどの場合、環境変数を切り替えるだけで実行できます。
- コミュニティサポート-優れたソフトウェアの開発に再利用できる優れた画像を継続的に提供するソフトウェアエンジニアの強力なコミュニティがあります。そのサポートを活用できます。なぜ車輪の再発明をするのですか？
- もっとたくさん..しかし、あなたがそれを読むことができるそこにたくさんの素晴らしいブログがあります。=）
短所：私はそれについてあまり短所を見ていませんが、ここに私が考えることができるものがあります。
- 学習曲線-はい、ある程度の学習曲線があります。しかし、私が後輩のエンジニアから見たものから、それを設定する方法を学ぶのにそれほど時間はかかりません。コンテナ化する方法を考えているときは、通常、時間がかかります。
いくつかの懸念：
- データの永続性-一部のエンジニアはデータの永続性に懸念を抱いています。ボリュームをコンテナにマウントすることで、これを簡単に修正できます。独自のデータベースインストールを使用する場合は、HOST、DB_NAME、USERNAME、およびPASSWORDをlocalhost：5432にあるものに切り替えるだけで、すべて問題ありません。
これがお役に立てば幸いです。
この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。
侵害の場合は、連絡してください[email protected]
編集
コメントを追加