ドッキング・オーバーライド・ファイルの管理

Question

私たちは、mongodb、Javaバックエンド、およびexpress-jsベースのフロントエンドからなる小さなプロジェクトを開発しています。我々は、実稼働以外のすべてのためのデプロイメントツールとしてdocker-composeを選択しましたが、これまでは1つの例外を除いてかなり良い状態でした。

は現在、我々はそれを使用：

地元のdevのクラスタを実行している

• 。
• 実行中の統合テスト（いくつかの調整と余分な依存関係あり）。
• 負荷テスト用の環境を準備します（さらに調整が必要です）。
• 独立したクラウドマシン上でステージング/デモ環境を実行しています。 （簡潔にするためにd-cに置き換えdocker-compose）docker-compose.yml、d-c.override.yml、d-c.test.yml、d-c.load.ymlとd-c.demo.yml：

は、私たちがドッキングウィンドウ-COMPOSEファイルのセットを推定してきた環境ごとにすべてのそれらの各種の調整を処理するには。

これは、非常に長いコマンドライン呼び出しを使用して、基本的なタスク以外は何もしません。たとえば、

docker-compose -f docker-compose.yml -f docker-compose.test.yml up -d --build 
docker-compose -f docker-compose.yml -f docker-compose.test.yml exec test_container ./do_tests.sh 

さらに悪化します。

これまでのところ、我々はカップルのことを向上させることについてのアイデア持っている：

1. 使用フルドッキングウィンドウ・コンファイルの代わりに、タイピングを保存する部分 - アプリの構造の変更/追加パラメータが導入されたときには、余分なメンテナンスを。
2. （前者のバリエーション）は、サービスのためにextendsを使用し、コピー貼り付けを最小限に抑えます（ただし、複雑さは増します）。
3. これらの長いコマンドはすべてMakefile（またはbashスクリプト）に格納します。使いやすさはありますが、敷物の下に複雑さがあります。
4. （前者のバリエーション）は、Docker-compose Plugin/own toolingを開発しています。

これらすべてのアイデアには欠点があります。これには適切な解決策とは何か、そして既にどのツールが存在するのだろうか。

Answer 1

3つの音が良い解決策だと思います。それは "複雑さを隠す"ことではなく、単に長いコマンドラインを入力するという繰り返しタスクを自動化するだけです。

メイクファイルは機能しますが、dobi（免責事項：私はこのツールの著者です）にも興味があります。 dobiでは、異なるファイルとプロジェクト名でComposeを実行することを含め、yamlファイル内のすべてのプロジェクトタスクを定義できます。プロジェクトのconfig例次に、あなたが

あなたも一回限りのタスクのいくつかはに移動することができることを見つけるかもしれないなど、dobi devでタスクを実行することができ、この

compose=dev: 
    files: [docker-compose.yaml, d-c.override.yml] 

compose=test: 
    files: [docker-compose.yaml, d-c.test.yml] 

compose=load: 
    files: [docker-compose.yaml, d-c.load.yml] 

のようになります。 dobi configを使用して、余分な作成オーバライドを削除する必要はありません。