生産中のDocker：「それを食べるとき、特に調理方法を知っていれば、少なくともうんざりしていません」

コンテナ化のアイデアはかなり前に生まれましたが、Dockerは大衆的な人気を獲得した最初のテクノロジーでした。 これが発生した理由、3年間でDockerがどれだけ「成熟」したか、そして心配することを止めて運用アプリケーションでDockerを使い始めることができる時期について、私たちは専門家と話しました。



Alexander aatarasoff Tarasov-Alpha Labのソフトウェアアーキテクト。 現在、彼はマイクロサービスアーキテクチャを導入し、DevOpsラインを動かしています。1年以上前に、Alfa BankでDockerを実装した経験について話しました。

運用中のDocker：流行しているという理由だけでツールを使用することはできません

-なぜDockerを使い始めたのですか？



-すべてはDockerではなく、もちろん始まりました。昨年、分散システムとマイクロサービスアーキテクチャへの構造的変化がありました。 このプロセスの一環として、分散フロントエンドシステムを開発するために、システムを作り直し、より軽量なAPIとUIに移行し始めました。



ある時点で、NodeJSなどの新しいテクノロジの導入に伴い、テスト環境と運用環境への展開の問題が発生することがわかりました。 クライアントへのソフトウェアのパッケージングと配信の方法を統一し、同時にメンテナンス作業を可能な限り簡単にするツールが必要でした。そのため、Dockerは主にカプセル化機能を実行し、アプリケーションの実装機能を統合APIの背後に隠します。 これにより、開発者はテクノロジーの選択により自由にアプローチでき、アプリケーションは、スピーチの1つでキリルトルカチョフと私が「ストレスレスアーキテクチャ」と呼んだ状態を達成します。 1つのクラスター/マシンで、アプリケーションの個々の部分を更新するときのサポートがより自信を持つようになります。



「ストレスの多い」アーキテクチャの例として、古典的なJ2EEアプリケーションを見ることができます。Javaバージョン、J2EEサーバーのバージョンに依存しているため、特定の制限が課せられ、新しいバージョンへの移行には広範なテストが必要で、かなりまれです。 Dockerに移行して、この概念を変更しています。必要な依存関係はすべて既にコンテナー内にあるため、新しいバージョンのJavaまたはサーバーの使用を開始するのを妨げるものは何もありません。



「しかし、Dockerは移行中のテストを排除しません。」 Dockerで簡単にできることは何ですか？



-Dockerは、コンテナごとに1つのアプリケーションの概念に基づいて構築されているため、2ダースの異なるコンポーネントがデプロイされているJ2EEサーバーを更新する必要がある状況から逃れられます。 代わりに、より軽量の組み込みサーバーを使用する分離アプリケーションに対処する必要があります。 これにより、すべてを一度に移行するのではなく、更新を時間（タイムライン）で「拡散」し、分割して移行できます。



-つまり、Dockerはマイクロサービスアーキテクチャへの切り替えを積極的に推進していますか？



-私はそれを押すとは言いませんが、彼はそれに非常によく合います。 これら2つの現象は、互いに非常に調和して補完します。



Dockerを使用するためだけにシステムを再構築するのではなく、逆に、当時存在していたJ2EEサーバーを断片化する必要性から進み、Dockerを使用する決定は私たちが直面したタスクから生まれました。 これは非常に正しいアプローチだと思います。なぜなら、なぜテクノロジーが必要なのかわからない場合、テクノロジーが解決する問題を明確に理解できず、それを必要としないからです。 ファッショナブルであるという理由だけでツールを使用することはできません。



-それでは、あなたのマイクロサービスアーキテクチャはDockerなしでは生きていませんでしたか？ 反対の状況を想像すると、すでに動作しているマイクロサービスアプリケーションをDockerに移行しますか？



-真空の中で抽象的なプロジェクトについて話すことは非常に困難です。 Dockerは特定の問題を解決することを理解する必要があります。 いずれにしても、オーケストレーション、管理などの手段が必要になります。 Dockerに移行する前に既に何かを書いていた場合、現在の状態に関してDockerがもたらす利点を真剣に検討し、そのような移行のメリットとコストの比率に基づいて決定する必要があります。



-Docker以外のツールを検討しましたか？



-ツールを選択したとき、実際にはDockerに代わるものはありませんでした。さらに、1年半前のDockerとDockerは完全に異なるものになりました。 当時はLXCコンテナーがありましたが、開発者の観点から見るとDockerの方が便利でした。



Dockerに加えて、 Rocketプロジェクトが登場しました-独自のAPIを備えたコンテナ化システムです。



ある時点で、多くの大企業はコンテナー化が非常に有望なテクノロジーであることに気付き 、 runCランタイムが開発されているOpen Container Initiativeコンソーシアムを作成しました。 これは完全にオープンソースであり、Docker-imagesおよびその他の互換性のあるタイプのコンテナーを実行できます。 runCに基づいて、Docker自体が機能するようになりました。 したがって、Dockerの使用がベンダーロックの場合、それは非常に重要ではありません。



-ベンダーロックについて説明した後、本番環境で純粋なDockerを使用するのはまだよくありません。オーケストレーション、ログの処理などに付随するサービスが必要です。 そのようなすべてのソリューションがDocker用に作成される可能性はありますか？また、この理由でそれを置き換えることは困難でしょうか？



もちろん、Dockerは現在マーケットリーダーであるため、この分野のすべてのソリューションはDockerをサポートするか、Dockerに重点を置いています。 ただし、現在使用しているMarathonについて説明する場合、これはMesosphereの単なるフレームワークであり、コンテナーの起動または長時間実行されるタスクに特化しています。



Rocketが普及すれば、RocketをサポートするMesosphereの新しいフレームワークを作成するか、Rocketが独自のオーケストレーションツールを作成して使用することになります。



-しかし、すべての開発者がDockerを習得しなければならないというわけではありませんか？



-短い答え：はい。 長いものは、文化の問題であり、開発者がエンジニアであり、複雑な問題を解決できるという事実です。



良い例えはテストです：単体テストの開発は特別な人の仕事ではなく、統合テストでさえ開発者の仕事です。 エンジニアは、クライアントと連携する準備が整った完全な検証済みソリューションを作成する必要があると考えています。 ソフトウェアのテストを自分で作成し、配信プロセスに従ってCIサーバーで実行する場合、テストプロセス自体ではなく、テストケースとテストモデルを作成するために専用のテスターが必要です。 コンテナ化の世界でも同じことが言えます。エンジニアはソフトウェアを展開するためのスクリプトを作成し、コンテナを収集してDockerイメージを実行できます。 はい、これは彼らが持っている追加の知識ですが、これは彼らがシステム管理またはシステムソフトウェアの微調整の専門家であることを意味しませんが、関連する主題分野のそのような知識は決して不必要ではありません。



これは文化と文化の変化の問題です。 開発は単なるコードではなく、私たちにとって開発とは、クライアントに提供できるターンキーソリューションのリリースです。



-Docker'omのデプロイには多くの微調整が必​​要でしたか？



-Dockerの微調整はそれほど多くありませんが、インフラストラクチャソフトウェアでは、構成（ Consul 、 Zookeeper ）の異なるストレージシステム、オーケストレーションツール（MesosphereおよびMarathon）、ログ処理（ Elasticsearch 、 Kibana 、 Kafka ）に多くの時間がかかりました。



質問がDockerとの統合後にさらに作業があったかどうかである場合、同等であると言えます。 独立した自己完結型のコンポーネントのためにどこかで小さくなり、デプロイ時に理解して考慮する必要があるDocker機能を修正する必要がある場合。



Docker自体の設定に関しては、まだそのようなタスクはありませんでしたが、Dockerエンジンを微調整し、ストレージドライバーをアプリケーションからアプリケーションに変更する必要はありませんでした。



-DockerはチームのGartner曲線のどこにありますか？



「私たちは生産性のプラトーにいると思います。」 Dockerが多くの問題を解決し、最小限の欠陥があるという事実により、かなり大きな幸福感がありましたが、銀の弾丸がなく、解決または回避された問題が現れたことを徐々に認識し、この技術を使用してビジネス上の問題を効果的に解決できるようになりました。

製品に対応。 あなたがそれを食べるとき、特にあなたが料理する方法を知っていれば、少なくともうんざりしていません

Andrey Filatov lincoreは、クラウドソリューションのスペシャリストであり、DockerとDevOpsのファンであるEPAM Systemsの主要なシステムエンジニアです。



-Dockerの使用方法



-さて、あるプロジェクトでは、DockerとJenkinsを使用してCIを完全に自動化しました。



Dockerはすべてに使用されます。スレーブはDockerコンテナーで実行され、テストコンテナーは他のコンテナーにデプロイされ、アプリケーション自体もDockerコンテナーで実行されます。



-そして、マスター？



-いいえ、マスターは大きな鉄のマシンです。小さなものをビルドし、1つまたは2つのビルドを実行する必要がある場合、Dockerを使用できますが、24時間年中無休で動作する20から30のプロセスがあり、Dockerはうまく動作しません。パフォーマンス。 現在の構成でも、マスターで起動とオーケストレーションのみが行われ、Doker'zirovannyhスレーブですべてが収集されるという事実にもかかわらず、大型の鉄の機械を最大限に活用します。



-Dockerに来たきっかけは？



-まあ、このプロジェクトについて話すと、私がそれに来たとき、Dockerはありませんでした。 古典的な束がありました：2つの半分空の、常にアイドル状態のスレーブ、ほとんどのパイプラインは単に存在せず、すべてのボタンは人によって押されました。 つまり、CIの観点からは、ほとんど何も行われていません。 ツールとしてDockerを選択しました。Dockerがうまく機能し、当時のリソースを最大限に活用できることを既に知っていたからです。



-そして、製品でのDockerの使用についてはどうですか？



-Dockerについては、「Amazonの趣味で」話すことができます。 AmazonにはElastic Contaiers Serviceというサービスがあります。 このツールを使用して、30分でゼロダウンタイム展開を整理するbashスクリプトを作成しました。 そこで、フードの下でDockerが使用されます。画像を収集してAmazonのレジストリに送信するマシンがあり、ECS自体の魔法があります。タスクを作成し、サービスを選択し、取得するコピーの数を設定します。 私は長い間Amazonに精通しており、JSONプログラミングに慣れてきましたが、30分以内にCIから展開へのアプリケーションの配信を段階的なロールアウトなどで整理できることが重要です。 Amazonは、メトリックとAuto Scalingを正しく構成すれば、ユーザーが何も心配する必要がない限り、必要なすべてのツールを提供します。ユーザーが山積みになり、新しいインスタンスと新しいコンテナーが自動的に発生します。



-そして、Dockerの前はどうでしたか？



-みんなの生活：ジェンキンス、ジェンキンスの奴隷、奴隷にはsshキーがあります：彼らは車に行き、戦争、ジャーなどをその場所に置き、サービスを再開します。 Dockerを使用すると、すべてがより柔軟でポータブルになります。原則として、何も変更せずにどこにでもデプロイできます。実際、イメージからDockerコンテナーをデプロイするには何も再構築する必要がありません。



-そして、開発者はどのようにしてDockerに切り替えましたか？



-Linux開発者の場合、移行全体に1行かかります。 確かに、いくつかの品質保証エンジニアのために、Docker Machineをダウンロードしてインストールする方法、Docker Composeをインストールする方法、Windowsで動作させる方法をwikiで詳細に説明する必要がありましたが、すべてがDocker MachineをVirtual Boxにインストールすることに制限されていますcli-utilitiesを使用できます。 Dockerは非常にシンプルなツールです。



-Dockerに切り替えたとき、他のテクノロジーを見ましたか？ その瞬間、市場には何がありましたか？



-仮想マシン、長年のVirtuozzoには実装がありましたが、Dockerで行ったことを実行できる便利なツールはなく、大規模なVagrant構成を使用してすべてを構築する必要がありましたが、そのようなソリューションはすぐに移植性がなくなります。



ハシコープオットーを見て、それは約束を示しましたが、ごく最近、彼はその時に現れました、それを使うのは怖かったです。 したがって、Dockerに代わるものはありませんでしたが、今でも、少なくとも成熟したものではないようです。



-プラットフォームとエコシステムはどの程度発展していますか？



-Docker自身に関しては、エコシステムは正しい方向に進んでいます。Swarmは、オーケストレーションに関してAmazonが提供するものに非常に劣っていますが、ここではすべてが非常に優れています。 私は少しのR＆Dさえしました：必要が生じたならば、私たちは少しの血でSwarmに移住できることがわかりました。



- メソスフェアのようなサードパーティのサービスを使用しなくても？



-まあ、私たちのニーズのために-はい、あなたが必要とするすべてはSwarmにあります。 複雑なネットワークを使用せず、コンテナの相互統合を使用しません。 かなりシンプルなインフラストラクチャがあります。



-一言で言えば彼女について話せますか？



-3つの層があります： nginxへのエントリポイント、フロントエンドコンテナー、いくつかの異なる種類のAPI、情報ハンドラー、データベースと通信するいくつかのサービスがあります。 APIサービスは、データベース自体から読み取るか、 redisにリクエストを送信します。データとその変更を処理するユーザーは、必要なすべての情報をredisから取得します。 redisとデータベースがサービスとして存在するAmazonから移行する必要がある場合は、それらを自分で上げる必要があります。



「なぜDockerを使用しないのですか？」



「ナンバークラッシャーに入れるのは意味がないと思います。」 大量のデータをダイジェストするレポートツールを使用している場合、Dockerのオーバーヘッドがパフォーマンスに影響するため、ファームのレンダリングにも意味がありません。 一般に、「生のパフォーマンス」が必要な場合、Dockerはあまり良くありません。 それでもありません。仮想マシンを使用できる場所ならどこでも、Dockerは完璧です。



私が知る限り、DockerはWindowsコンテナでは動作しませんが、先日2016年にサーバーがDockerコンテナをサポートするというニュースがあったため、MicrosoftはDockerチームと協力しており、おそらくこれは近い将来変更されます。



-そして、インフラストラクチャについてではなく、アプリケーション自体について話してください。Dockerの出現によってアプローチは変わりましたか？



-ほとんどありません。 最初に、インフラストラクチャが小規模または中規模の仮想マシン上にあり、水平方向に十分に拡張する必要があるという事実に備えて、Dockerが下位レベルを置き換えました。 もちろん、一部の地域では、アプリケーションが配置されている状態のチェックが追加されています。 つまり、以前にアプリケーションまたは仮想マシンが再起動し、データが失われないと予想していた場合、コンテナが死んだ場合、データはそれとともに死ぬことを理解し、別の場所に保存する必要がありますが、redisとpostgresqlこの問題を解決します。



-Dokerテクノロジーの成熟度は？



-製品版。 あなたがそれを食べるとき、特にあなたが料理する方法を知っていれば、少なくともあなたはうんざりしていません。

Dockerはツールに関するものです。 彼の前には、cgroups、zone、および他の多くのテクノロジーがありました。 しかし、それらを手頃な価格で人気のあるものにしたのはDockerでした。

Sergey Egorov bsideup -ZeroTurnaroundのフルスタックエンジニア。 彼は2013年にエストニアに移り、その後、ロシアのさまざまな企業でゲーム開発に携わりました。 彼はDockerが好きで、負荷の高いシステムを構築し、Groovyコンパイラーや他のオープンソースプロジェクトを調べます。



-Dockerに来たきっかけは？ どのプロジェクトに取り組んでいますか？



2014年、私はCreative Mobileに勤務し、部門のサーバーの開発と展開を担当しました。 それは社会的なプロジェクトでした。 ゲーム、1秒あたり最大1000リクエスト。



当時、私はEC2 Autoscaling GroupにJBoss ASクラスター（後のWildfly）をデプロイしたPuppetを使用しましたが、残念ながら、このソリューションはサーバーの迅速なデプロイのために非常に不安定でした（そして1日に数十回の展開）は、展開の耐性を犠牲にしなければなりませんでした。



その結果、古いパッケージ/構成（XML形式であり、「コマンドラインから変更するのに最も不便な形式の1つ」）が新しいものと競合する状況が発生することがありました。



彼は安定した展開のためのオプションを研究し始めました。 なぜなら AWSでホストされていましたが、当時はOpsWorksとElasticBeanstalkから選択できました。 長い調査の後、選択はElasticBeanstalkに落ちました。そこでは、「何らかの種類のDockerバージョン0.9」を使用するオプションに気付きました。これは、「以前に発表されたソリューションのどれもあなたに合わない場合、あなたが望む方法を宣言するための抽象的なシステムです」アプリケーションを起動します。」 すぐにそれが何であり、どのように調理するかを研究するのに役立ち、翌日、私たちの制作はDockerに移行しました。 はい、はい、ローカル開発でDockerに切り替える前であっても、2014年にDockerが製品化されました。



その後、他のいくつかの負荷の高いCreative MobileプロジェクトにDockerを正常に統合しました。 TransferWiseに進み、ドッキングのアイデアを積極的に推進し、 社内のマイクロサービスへの積極的な移行の時期でした。運用担当者と戦わなければならなかった場合を除き、長い間メリットを説明する必要はありませんでした:)



-いくつかのシナリオでは、Dockerはオーバーヘッドのために高いパフォーマンスを発揮しないと考えられています。 これについてどう思いますか？



これは最も人気のあるDocker物語の1つだと思います。 個人的に、私はそのような事柄や個人的な経験で数字を信じています。 そして、2番目にほとんど信頼がない場合、数字は嘘をつかず、例えばIBMなどの大規模な市場プレーヤーの研究に注意を払うことをお勧めします。



このドキュメントは2014年7月のものであり、2年後、Dockerチームはパフォーマンスを含む膨大な数の改善を行っていることに注意してください。



たとえば、2016年に、Percona はIOデータベースのパフォーマンスに対するDockerの影響を測定しました 。 結果-彼らは美しいグラフィックのレイアウトさえ始めませんでした、なぜなら 結果は、ベアメタルの結果と同じでした。



Dockerのすべてをローカルの開発環境から駆動してシステムを構築し（そう、我々はDockerのJenkins-masterを駆動する）、本番に駆動しました。



「なぜDockerを使用しないのですか？」



現在、膨大な数のソリューションがあるにもかかわらず、ステートフルアプリケーション（永続ストレージを備えたデータベース、ホットスタートを備えたさまざまな種類のキャッシュ、スケーラブルでないバックエンド）を動かすのは苦痛です。 痛みの原因はDockerそのものではなく、アプリケーション自体が別のホスト上で、転送されたファイルシステムなどで実行する準備ができていないためです。



また、アプリケーションが鉄を使用してアクティブに動作している場合、コンテナに鉄を投げることはまだ重要ではないと見なされます。 可能ですが、ツール（およびDockerはコンテナー化ではなく、ツールに関するものだと思います）はすぐに使用できる状態ではないため、非常に簡単です。



-Dockerで数年間働いています。 代替案を検討していますか？ それらも存在しますか？



選択肢があり、常に存在します。 主流を好まない人もいます:)

また、主要な市場関係者は、Dockerの開発に十分な影響がないことを懸念しています。



幸いなことに、Docker Inc. バカとはほど遠く、たとえば、すべてをOpen Container Initiativeの形式で標準化しようとする試みは、彼らがコンテナ市場で戦うことを望まないことを実証するだけであり、彼らの市場は一流のツールです。



最後に、私は助けることができませんが、私のDockerプライドを共有します：D

---

継続的配信、オーケストレーション、コンテナ化について詳しく知りたい場合は、 Joker 2016の次のレポート（サンクトペテルブルク、10月14〜15日）に関心があるでしょう。

• Gradleによるリリース管理
• コンテナーは不要：Bootique.ioを備えた最新のJavaスタック
• マイクロサービス：最初の血