一方で、Dockerは非常に普遍的なツールであり、膨大な数のタスクを簡単かつ効率的に解決するために使用できます。 それは理解可能であり、すべてが初歩的なようです。 しかし一方で、時間とリソースを適切に使用するために「ポンプ」するために費やさないと、単純なことを過度に複雑にする可能性があります。 そしてもちろん、あなたは自分が正しいと仮定します。そして、Dockerはあなたのユニークなタスクを解決するのに適していない平凡なかさばったゴミです。
通常、標準的な会社では、タスクの作業プロセスは次のようになります。
- Gitプッシュはコミットで行われます
- Jenkins、TeamCityなどのシステムがトリガーされます。
- パイプライン/ジョブが起動され、サードパーティのライブラリがダウンロードされ、プロジェクトがコンパイルされ、テストが実行されます
- 組み立てられたプロジェクト（ADD ..）を含むdockerイメージが作成され、リモートdockerレジストリにプッシュされます
- どういうわけか、リモートサーバーで、ドッカープルが実行され（シェフ、パペット、docker-composeを使用して手動で）、コンテナーが起動します。
直感的に、私はいつもそれがどういうわけか複雑すぎると感じていました。 このプロセスは誇らしげにCI / CDと呼ばれ、これが最も簡単な方法であることに疑いのない賢い人々にすでにうんざりしています。
エンドユーザーにとっては、次のようになります。gitリポジトリにプッシュすると、コミットの内容がどこかに展開されます。
私はこのアプローチについて好きではないもの。
- システムをリモートサーバーに展開する唯一の方法は、5つのステップすべてを実行することです。
- ステップ3では、プライベートライブラリへのアクセスキーが必要になる場合があります。 以前にダウンロードしたライブラリのキャッシュが構成されていない場合、プロセスは長くなる可能性があります。
- Dockerfileを準備し、イメージ（FROM ...）を決定し、イメージにタグを付ける方法を決定し、イメージをプッシュするリポジトリにアクセスする必要があります。
- 独自のリポジトリが必要です。httpsを設定します。 結局のところ、Dockerクライアントはhttpsでのみ機能します。
4番目の点は、もちろん一度だけ行われ、おそらく追加すべきではありません。
しかし、リリース段階でDockerという言葉はすでに何回言及されていますか？
考えてみてください。なぜこのDockerをすべて事前にドラッグするのですか？ コンテナは便利であると考えられているため、「まあ、すべてがうまくいった、それは動作します。 では何を始めていますか？」
ですから、このような人々にとって、ドッカーコンテナーは万能薬ではなく、アプリケーションを実行できる唯一の環境でもありません。 Python、PHP、JS、Swift、Scala / Javaなどで記述されたプロジェクト で実行できます：
- リモート仮想マシン
- 仮想化およびドッカーコンテナのないローカルホストで。
突然:)
nodeJSで実行するサービスを作成していると想像してみましょう。
このプロジェクトの結果（または「アーティファクト」と呼ぶ）は、jsファイル（サービス自体）+ node_modules（サービスで使用されるサードパーティライブラリ）のセットになります。
サービスが機能していることを確認し、テスターが機能をテストできるように、リモートで実行したいとします。
このアイデアはどうですか？
- プロジェクトで.tar.gzを作成し、それを...成果物のリモートリポジトリにアップロードします！ （リポジトリとも呼ばれます）。
- サービスをダウンロードしてテストを開始できるURLを言います。
さらに、テスターは、すべてを所有している場合は自宅でローカルにサービスを実行するか、Dockerfileを作成します。Dockerfileでアーティファクトをダウンロードし、コンテナーを開始するだけです。 まあ、または何か他のもの。
テスターがドッカーコンテナーを起動することを望まず、通常「これは彼らの仕事ではない」場合は、すぐに言います。新しいアーティファクトがバイナリリポジトリに表示されるとすぐに画像を収集するツールを使用します（Webフックを使用し、定期的に追跡します）。
バイナリリポジトリには次のものがあります。
- ソナタイプネクサス
- 工房
Nexusは使いやすく、さまざまなリポジトリ（npm、maven、raw、docker）を作成できるため、私はそれを使用しています。
これは非常にシンプルなアイデアですが、なぜそれについてどこでも読んでいないのですか？ インターネットでは、「コンテナが何らかの種類のkubernetesにデプロイされている場所でのgit pushのような」記事を数えることはできません。 このような複雑なアルゴリズムから、髪の毛は逆立ちします。
この記事の目的は、言うまでもなく、1つのプロセスでプロジェクトを組み立ててdockerイメージに追加する必要はありません。
分割して支配する！
プロジェクトをビルドし、ダウンロード可能な場所にアーティファクトを公開します。 （Dockerレジストリは、プロジェクトを保存できる唯一の場所ではなく、サーバーにアーティファクトを配信するためのユニバーサルパスを選択します）。
別のツールを使用して、プロジェクトが機能するサーバーに成果物を配信します。
すべてが非常に簡単で、他の人に選択肢を与えます：dockerを使用する、kubernetesで実行する、または他のツールを使用してアーティファクトを実行します。 それはあなたにとって非常に便利でファッショナブルであるという事実にもかかわらず、技術の使用を強いる必要はありません。
プロジェクトを立ち上げて頑張ってください！