Docker はおもちゃですか? それともまだ本当ですか？

みなさん、こんにちは！

本当はすぐに本題に入りたいのですが、私の話について少し話したほうが正しいでしょう。

エントリー

私はフロントエンドのシングルページアプリケーション、scala/java、およびサーバー上のnodejsの開発経験を持つプログラマーです。

かなり長い間 (間違いなく XNUMX ～ XNUMX 年)、私は Docker は天から授かったものであり、一般的に非常に優れたツールであり、絶対にすべての開発者がそれを使用できるべきであるという意見を持っていました。 このことから、すべての開発者はローカル マシンに Docker をインストールする必要があるということになります。 私の意見はどうでしょうか。同じ hh に掲載されている求人情報を見てください。 XNUMX つおきに docker についての言及が含まれており、それを所有していれば、これが競争上の利点となります 😉

途中、Docker とそのエコシステムに対してさまざまな態度を持つ多くの人々に会いました。 これはクロスプラットフォーム機能を保証する便利なものだと言う人もいます。 XNUMX 人目は、なぜコンテナで実行する必要があるのか​​、それによってどのような利益が得られるのか理解していませんでした。XNUMX 人目はまったく気にせず、気にしませんでした (コードを書いて家に帰りました。羨ましい限りです)。方法 ：）

使用理由

なぜ docker を使用したのでしょうか? おそらく次のような理由が考えられます。

• データベースの起動、99% のアプリケーションがデータベースを使用
• フロントエンド配布およびバックエンドへのプロキシ用に nginx を起動する
• アプリケーションを Docker イメージにパッケージ化できます。この方法では、Docker が存在する場所であればどこでもアプリケーションが動作し、配布の問題はすぐに解決されます。
• すぐに使用できるサービス検出、マイクロサービスを作成でき、各コンテナ (共通ネットワークに接続) はエイリアス経由で簡単に別のコンテナにアクセスでき、非常に便利
• コンテナを作成してその中で「遊ぶ」のは楽しいです。

私が docker に関していつも気に入らない点:

• アプリケーションが動作するには、サーバー上に Docker 自体が必要です。 アプリケーションが jre または nodejs 上で実行され、それらの環境がすでにサーバー上にある場合、なぜこれが必要なのでしょうか?
• リモート サーバー上でローカルに構築された (プライベート) イメージを実行したい場合は、独自の docker リポジトリが必要です。レジストリがどこかで動作する必要があります。また、https を設定する必要もあります。docker cli は https 上でのみ動作するためです。 ああ、くそ... もちろん、画像をローカルに保存するオプションもあります。 docker save scp 経由で画像を送信するだけです...しかし、それはたくさんの体の動きです。 さらに、独自のリポジトリが登場するまでは、これは「必要な」ソリューションのように見えます
• docker-compose。 コンテナを実行する場合にのみ必要です。 それだけです。 彼には他に何もできません。 Docker-compose には、多数のバージョンのファイルと独自の構文があります。 どんなに宣言的であっても、私は彼らのドキュメントを読みたくありません。 他には必要ありません。
• チームで作業するとき、ほとんどの人は Dockerfile の書き方が非常に曲がっていて、Dockerfile がどのようにキャッシュされるのかを理解しておらず、必要なものと不要なものをすべてイメージに追加し、Dockerhub やプライベート リポジトリにないイメージから継承し、いくつかのイメージを作成します。 docker-compose ファイルにはデータベースが含まれていますが、何も保持されません。 同時に、開発者たちは、Docker はクールで、すべてがローカルで動作する、と誇らしげに宣言し、人事部は欠員欄に「当社は Docker を使用しており、そのような実務経験のある候補者が必要です。」と重要なことを書いています。
• 私は、postgresql、kafka、redis など、すべてを Docker で構築することについての考えに常に悩まされています。 残念ながら、すべてがコンテナ内で動作するわけではなく、すべてが簡単に構成および実行できるわけではありません。 これは、ベンダー自体ではなく、サードパーティの開発者によってサポートされています。 ところで、すぐに疑問が生じます。ベンダーは自社の製品を Docker で保守することを気にしていませんが、これはなぜでしょうか。もしかしたら、ベンダーは何かを知っているのでしょうか?
• コンテナ データの永続性については常に疑問が生じます。 そして、ホスト ディレクトリをマウントするか、Docker ボリュームを作成するか、データ コンテナを作成するだけでよいのかと考えます。 deprecated? ディレクトリをマウントする場合は、コンテナ内のユーザーの uid と gid がコンテナを起動したユーザーの ID と一致することを確認する必要があります。一致しない場合、コンテナによって作成されるファイルは root 権限で作成されます。 私が使うなら volume その後、データは単にいくつかの場所に作成されます /usr/* 最初のケースと同じように、uid と gid についても同じことが起こります。 サードパーティのコンポーネントを起動する場合は、ドキュメントを読んで、「コンポーネントはどのコンテナ ディレクトリにファイルを書き込むのか?」という質問に対する答えを探す必要があります。

私は Docker を長時間いじらなければならないという事実がずっと好きではありませんでした 初期段階: コンテナーを起動する方法、どのイメージから起動するかを考え出し、長い Docker コマンドのエイリアスを含む Makefile を作成しました。 私は docker-compose が嫌いでした。それは、docker エコシステムの別のツールを学びたくなかったからです。 そして docker-compose up 特に彼らがまだそこで会っていたら気になりました build すでに組み立てられたイメージではなく、構造を作成します。 私が本当に望んでいたのは、製品を効率的かつ迅速に作ることだけでした。 しかし、dockerの使い方がわかりませんでした。

Ansible の紹介

最近 (XNUMX か月前)、私は DevOps チームと仕事をしましたが、そのほぼ全員のメンバーが Docker に対して否定的な態度をとっていました。 理由としては:

• docker ルール iptables (ただし、daemon.json で無効にすることもできます)
• docker にはバグがあるため、本番環境では実行しません
• docker デーモンがクラッシュすると、それに応じてインフラストラクチャを持つすべてのコンテナーがクラッシュします
• ドッカーは必要ありません
• Ansible と仮想マシンがあるのになぜ docker するのか

同じ仕事で、別のツールである Ansible を知りました。 一度聞いたことはありましたが、自分でプレイブックを書こうとはしませんでした。 そして今、自分のタスクを書き始めたところ、私のビジョンは完全に変わりました。 なぜなら、Ansible には同じ Docker コンテナ、イメージ ビルド、ネットワークなどを実行するためのモジュールがあり、コンテナはローカルだけでなくリモート サーバーでも実行できることに気づいたからです。 私の喜びは際限がありませんでした。私は通常のツールを見つけて、Makefile ファイルと docker-compose ファイルを捨てました。それらは yaml タスクに置き換えられました。 次のような構成を使用することでコードが削減されました。 loop, when, etc.

データベースなどのサードパーティコンポーネントを実行するための Docker

私は最近、ssh トンネルについて知りました。 リモート サーバーのポートをローカル ポートに「転送」するのは非常に簡単であることがわかりました。 リモート サーバーは、クラウド内のマシンまたは VirtualBox で実行されている仮想マシンのいずれかになります。 同僚または私がデータベース (またはその他のサードパーティ コンポーネント) を必要とする場合は、このコンポーネントでサーバーを起動し、サーバーが必要ないときはサーバーをオフにするだけです。 ポート転送は、Docker コンテナーで実行されているデータベースと同じ効果をもたらします。

このコマンドは、ローカル ポートを postgresql を実行しているリモート サーバーに転送します。

ssh -L 9000:ローカルホスト:5432 [メール保護]

リモート サーバーを使用すると、チーム開発の問題が解決されます。 このようなサーバーは、複数の開発者が同時に使用でき、postgresql を設定したり、Docker やその他の複雑な機能を理解したりする必要はありません。 特定のバージョンをインストールすることが難しい場合は、リモート サーバー上で同じデータベースを Docker 自体にインストールできます。 開発者に必要なのは、SSH アクセスを提供することだけです。

最近、SSH トンネルは通常の VPN の機能が制限されていると読みました。 OpenVPN またはその他の VPN 実装をインストールし、インフラストラクチャをセットアップして、開発者に提供して使用できるようにするだけです。 これはとてもクールです！

幸いなことに、AWS、GoogleCloud などは XNUMX 年間無料で使用できるので、ぜひ使用してください。 使わないときはオフにしておけば安いです。 なぜ gcloud のようなリモート サーバーが必要なのかとずっと疑問に思っていましたが、どうやら gcloud を見つけたようです。

ローカル仮想マシンとして、Docker コンテナーで積極的に使用されている同じ Alpine を使用できます。 または、マシンの起動を高速化するための他の軽量ディストリビューションを使用することもできます。

結論: データベースやその他のインフラストラクチャ機能はリモート サーバーまたは仮想ボックスで実行できますし、そうすべきです。 これらの目的には docker は必要ありません。

Docker イメージとディストリビューションについて少し

すでに書いた статью ここで私が伝えたかったのは、Docker イメージの使用には何の保証も提供されないということです。 Docker イメージは、Docker コンテナーを作成する場合にのみ必要です。 Docker イメージにアップグレードする場合は、Docker コンテナーを使用するようにアップグレードすることになり、Docker コンテナーのみを使用します。

ソフトウェア開発者が Docker イメージのみで製品を移植しているところをどこかで見たことがありますか?
ほとんどの製品の結果は、特定のプラットフォーム用のバイナリ ファイルです。これらは、目的のプラットフォームから継承された Docker イメージに追加されるだけです。 なぜ dockerhub に似たようなイメージがこれほどたくさんあるのか疑問に思ったことはありますか? たとえば「nginx」と入力すると、さまざまな人々からの 100500 枚の画像が表示されます。 これらの人々は nginx 自体を開発したのではなく、単に公式の nginx を自分の docker イメージに追加し、コンテナーを起動しやすいように独自の構成で味付けしただけです。

一般に、それを tgz に保存するだけで済みます。誰かがそれを docker で実行する必要がある場合は、tgz を Dockerfile に追加して、目的の環境から継承し、tgz 内のアプリケーション自体を変更しない追加の bund を作成します。 Docker イメージを作成する人なら誰でも、tgz が何であるか、そしてそれが機能するために何が必要かを知っているでしょう。 これがdockerの使い方です ここで

結論: Docker レジストリは必要ありません。ある種の S3 または Google ドライブ/ドロップボックスのようなファイル ストレージを使用します。

CI の Docker

私が働いてきた会社はどれも似たような感じでした。 それらは通常食料品です。 つまり、彼らは XNUMX つのアプリケーション、XNUMX つのテクノロジー スタック (まあ、おそらく XNUMX ～ XNUMX つのプログラミング言語) を持っています。

これらの企業は、CI プロセスが実行されるサーバー上で Docker を使用しています。 質問: サーバー上の Docker コンテナーにプロジェクトをビルドする必要があるのはなぜですか? たとえば、必要なバージョンの Nodejs、php、jdk をインストールし、ssh キーなどをビルドが行われるサーバーにコピーする Ansible プレイブックを作成するなど、ビルド用の環境を準備するだけではどうでしょうか?

docker は分離されていても何の利益ももたらさないので、これは自分自身を苦しめる行為であると今では理解しています。 Docker の CI で遭遇した問題:

• ここでも、ビルドするには Docker イメージが必要です。 イメージを探すか、独自の dockerfile を作成する必要があります。
• 90% は、一部の SSH キー、Docker イメージに書き込みたくない秘密データを転送する必要があります。
• コンテナが作成されて終了すると、すべてのキャッシュも一緒に失われます。 次のビルドでは、すべてのプロジェクトの依存関係が再ダウンロードされますが、これには時間がかかり非効率的であり、時は金なりです。

開発者は Docker コンテナでプロジェクトをビルドしません (私もかつてはそのようなファンでした。本当に、昔の自分を残念に思っています xD)。 Java では、複数のバージョンがあり、XNUMX つのコマンドで現在必要なバージョンに変更することができます。 これはnodejsでも同じで、nvmがあります。

出力

私は docker は非常に強力で柔軟なツールだと信じていますが、これがその欠点です (奇妙に聞こえますが、そうです)。 その助けを借りて、企業は簡単にそれに夢中になり、必要な場所でも不必要な場所でもそれを使用することができます。 開発者がコンテナーと一部の環境を起動すると、すべてがスムーズに CI と本番環境に流れ込みます。 DevOps チームは、これらのコンテナを実行するための何らかのコードを作成しています。

docker を使用するのは次の場合のみです 最新の ワークフローの段階では、最初からプロジェクトにドラッグしないでください。 ビジネス上の問題は解決されません。 彼は問題を別のレベルに移して独自の解決策を提供するだけで、あなたは二重の仕事をすることになります。

dockerが必要な場合: docker は特定のプロセスの最適化には非常に優れていますが、基本的な機能の構築には向いていないという結論に達しました。

それでも docker を使用する場合は、次のようにします。

• 非常に注意してください
• 開発者に docker の使用を強制しないでください
• その使用を XNUMX か所にローカライズし、すべての Dockefile および docker-compose リポジトリに分散させないでください。

PS：

• 最近出会った packer また、Ansible と非常にうまく連携し、イメージ (Docker イメージを含む) を構築するプロセスを統合できると述べています。
• docker についても、興味深い記事です

読んでいただきありがとうございます。皆様が透明性のある決定を下され、生産的な日々を過ごしていただけることを願っています。

出所： habr.com