ブログでは、1cloudクラウドサービスとDockerなどの有望なテクノロジーの開発について多くのことを書いています。 過去1年間のコンテナは大ヒットになりましたが、そのような人気にはマイナス面があります。 エンジニアのニック・バレットは、ブログでDockerコンテナーが、このツールに適さないタスクを解決するためにも使用され始めている理由を疑問に思いました。
バレットは、Dockerが大好きだと言います。 エンジニア自身の承認により、彼はDockerとKubernetesの習得に多くの時間を費やしました。 ステートレスコンテナと組み合わせることで、優れたスケーラビリティ、サービスの開示、ほぼ瞬時のアプリケーションの展開が可能になります（プライマリイメージの作成を除く）。
しかし今日、Dockerコンテナはすべてに使用されており、Barrett氏によると、これは彼を混乱させます。
これを説明するために、エンジニアは、Docker（v2）でイメージストレージ（Dockerレジストリ）を起動する状況を考慮することを提案します。 ここでは次のことを行います。
- Goバイナリで単一のインスタンスを実行します。
- 大きなディスク容量と帯域幅を持つボックス上。
- 比較的低いCPU /メモリ。
これはKubernetesクラスターでは不要な1回限りのボックスです。さらに、この場合、エンジニアはDockerのスケーリング機能に関心がありません。 そのため、これらはすべてハードウェアですぐに起動できます。
問題は、インストールオプションでこれを行う方法に関する情報が見つからないことです。 実際、「公式」な方法はDockerイメージを使用することです。 幸いなことに、Dockerfileは動作する限られたスクリプトにすぎないため、docker / distribution-> Registry Image-> Dockerfileのパスを使用できます。 バレットは実験的にこれに来ました。
Docker以外で作業するための他のオプションがあります。 データストア（一時ストレージ）についてです。 ElasticsearchまたはGaleraクラスターを開始するとします。 Dockerコンテナを使用すると、すばやくインストールできます。
しかし、急がないでください。 これらのサービスは、複数の環境（テスト/製品クラスター）にどのように構成できますか？ 彼らはENVvarを読み取らず、使用されている内部サービス開示ツールについて何も知りません。 これらのタイプのシステムには独自の設定があり、elasticsearch.ymlまたはmy.cnfを使用できます。 このようなケースでは、Dockerfileはまったく役に立たない、とBarrettは言います。
エンジニアは、最も一般的な解決策は、サービスを開始する前に構成をロードする他のユーティリティをイメージ内に単にインストールすることであると確信しています。 そして彼の意見では、これは、特殊化されていないソフトウェアのないコンテナの存在というまさにその考えの濫用です。 この作業に使用するpyinfraやAnsibleなどのツールの方がはるかに便利です（設定を生成するために不要なジャンクをインストールしません）。
結局のところ、Elasticsearch / Galera /などの簡単にアクセスできるインスタンスを使用できます。これは、製品開発の段階ではるかに便利です。 特定のアプリケーションブランチに関連付けられた単一のElasticsearchインスタンスを即座に起動できるため、時間を大幅に節約できます。 これは、これまでに作成されたステートレスアプリケーションを展開する最良の方法です。 したがって、バレットは、クラスターまたはDockerコンテナーを使用した複雑なサードパーティソフトウェアの作成を「気にしない」ことをお勧めします。