仕事中のDocker。 Badooでの使用の様子（1年後）

アントン・トゥレツキー（ Badoo ）

今日、私たちはそのような内部キッチンにあなたを招待します。BadooはDockerが必要かどうかを教えてくれます。 あなたはそれを必要とするかどうかあなた自身のために結論を引き出すことを試みるでしょう。 したがって、この情報はすべて、そのようなものであるため、インターネットでは入手できません。



レポートの中で、最も重要なことについてお話します。これは、タスクの実装をどこから開始するかに関するものです。 なぜあなたがそれをしているのか、なぜあなたはそれを取っているのかを決めなければなりませんか？

私たち自身は、これらの質問に答えましたが、問題なく実装することはできませんでした。 解決する問題の一部。 主なものを特定しました。それらについて、およびそれらにどのように対処したかについて説明します。 最後に、私たちの素晴らしさ、さまざまな種類の新しい自転車を愛すること、それらを作る方法、見ること、発明することを宣伝します。 私はそれらをあなたに見せます、私は彼らについてあなたに話します、あなたはいくつかの意見を補います。 さあ、行こう！



それが運用サービスが必要な理由であり、一般に、ある種のビジネスが必要であり、特に管理者が必要な理由です。



私たちの主要なユニットはサービスです。 サービスが機能しない場合、なぜここに集まっているのですか？ 遠景では、サービスは次のようになります。 これは、ある種のビジネスロジックを作成し、何かを取得したいプログラマーの知的財産です。 マシンにはいくつかのネットワーク設定の層があり、ディレクトリサービスに関連するものと関連しないものがいくつかあります。 一般に、これは、オペレーションサービスがそれ自体とシステムのチケット、またはサービスが開発者からプロダクションにどのように転送されるかを示すもつれを表します。 私たちの主なタスクは、1台の大型で強力なサーバーを用意し、そこにいくつかのサービスを詰め込む必要があるということです。



すべてが素晴らしく見えます。 過去数年にわたって、これに伴う状況は決して変化していません。 私たちは両方とも、もつれ形式でサービスを展開し、展開しました。



問題は、マシンを処理できず、何らかの理由でサービスを解決する必要がある場合です。マシンが対応できず、新しいハードウェアが到着したため、それを取得して移行したいだけです。 そして、移行中に最初に取得することは、たとえばDockerを使用しない場合、サービスをクリーンなマシンにドラッグすることです。クリーンな新しいマシンではすべてが問題なく、素晴らしい、ディレクトリがプルアップされますが、1つの問題... ChefやPuppetなどの構成管理システムを使用していますが、誰がそれらを展開していますか？ そして、誰がすべてを取り、すべてを取り戻すためにマニフェストを逆に書くのですか？ ホールには3人しかいません。 したがって、これを書いていないすべての人は、あなたのサーバーに最終的にそこに住んでいるもののいくつかの穴と断片があり、これらの移行の頻度に応じて、サーバーが遅かれ早かれ成長することを知っていると思います一種のゴミになります。 Dockerを使用して同じ移行を行った場合、レンガを取り出して別の場所に配置すると、古いものは何も残されませんでした。 いいね



したがって、一般的に操作側からDockerを検討し始めた最初の理由は、オペレーティングシステムからアプリケーションを解き、ボールにまとめるタスクです。

次の瞬間。 なぜなら 私たちはまったくプログラマーではありませんが、エンジニアやメンテナンス作業員でありながら、リソースについては常にハードウェアについて考えています。 つまり 鉄は大きな部屋にある物理的な箱のようなもので、冷房があり、掃除婦がそこに来ないことを願っています。



そして以来 専用のデータセンターに機器を設置し、ケージをいくつか取り外して、ある時点で機器を変更する必要があると考え始めます。 いくつかの理由で-装備が新しくなり、パフォーマンスのオウムやユニットの種類が増えました。遅かれ早かれ変更する必要があります。



したがって、キャパシティプランニングに関連する最初の問題は、むしろ問題ではなく、タスクでさえ、可能な限り合理的にラック内のスペースを使用する必要があるということです。これは電気のコストであり、何よりもまずお金です。



最初の瞬間からの次の結論は、同じようにネットワーク機器のポートを可能な限り使いたいということです。ネットワーク機器も単一であり、スペースを占有し、電力も消費するからです。



私たちはそれぞれ電気を節約し、お金を節約し、環境にとって素晴らしいものにしたという事実にスムーズに近づいています。 これは私たちにはあまり関係ありませんが、ここには美しくて素晴らしいこのようなポジティブなボーナスがあります。



しかし、より強力なサーバーにサービスをバンドルすると言うと、「±」と指定した次のアイテムを取得します-抽象化された、より多くの機会、より一般的な障害点のような状況になります。 同じ物理マシン上に1つのサービスが存在する場合、すべてが正常であり、ほとんどの場合、サーバーに障害が発生しても損失は少なくなります。 この場合、これは哲学的な質問です。古い機器を新しい機器に交換することを話している場合、新しい機器は古い機器よりも低い確率で故障する可能性が最も高いためです。 また、多くの人が、展開プロセスで発生する問題の数を聞いています。 つまり 実際、統計によると、この単一障害点を取得することは、ある種の曲線曲線よりも生産上の壮大さではありません。



3番目のポイント、なぜDockerを検討し始めたのか、それはわくわくする深刻な問題です。プログラマーによって書かれた瞬間から、アプリケーションに結び付けられるものを何も変更せずに、アプリケーションを本番環境に展開することです。 Dockerを使用する場合、 最初に、ある種のライブラリ、パッケージ、その他のものを使用して特定の環境にアプリケーションを配置しました。チームシティで条件付きでアセンブリプロセスで配置しました。 その後、同じ元の形式でQ＆Aテストプロセスに進み、その後、ステージング、開発を通じて、コンテナ内の完成したアプリケーションを既に実稼働に移行できます。 つまり この段階でいくつかの変更を破棄します...アプリケーションに問題があり、このアプリケーションのさまざまな環境が開発中、ステージング中、およびQ＆Aテスト中の場合、一般にアプリケーションに影響するものを理解することは非常に困難です。動作しない、つまり ここでこの問題を100％解決しました。



最後に、私がアスタリスク付きのアイテムとしてマークしたのは、最初はDockerfileを見たとき、10年前に何らかの戻りがあったように思えたからです。 キャッシュではなく、理解できないキャッシュ、パペットがあるときに何かを書く必要があります、なぜこれらのtxtファイルを書くのですか？ しかし実際には、これに加えて、常に隣人の設定を見ると、その人が何をして何をしたのか、彼が何を考えていたのか、Dockerがどのように動作し、そのようなDockerファイルを見るのかを知ることができます、レイヤーのオーバーラップ、何かの実行、キャッシュの使用のプロセスを最適化するために、このファイルを変更できる場合があります。 つまり 実際、Dockerfileは、アプリケーションに関する常に最新の優れたドキュメントです。

それで、私たちは自分自身の質問に答えました。なぜDockerが必要なのですか？これを紹介して、私たちは常にこれらの手紙に戻って見てください：私たちは決めました、決めなかった、それは言及しません、それは当てはまりませんか？

さらに、Dockerを実装するプロセスから始まった興味深いポイント。 もちろん、問題が発生しました。 これらの問題のいくつかは、Github Dockerなどで議論されました。 一部は解決し、一部はまだ把握していません。 彼らは私たちの隣に来ると思います。



最初の興味深い問題は、少なくとも何らかの形でアプリケーションのログをクリーンアップすることです。 私たちはタスクに直面しました：「syslogを作成し、プログラマは/ dev / logに書き込みたいので、どこかに送信したり、処理したりします。」



私たちは座って考えました：2番目のサービスをコンテナに入れるにはどうすればよいですか？ 最初のアイデアは次のとおりです。1つのコンテナ-その中で実行される1つのサービス。 間違っています。 ジレンマが発生します。 どうする



これは、ログを配信していないかどうかを尋ねられるため、各コンテナに押し込む必要がある+1サービスであることが判明しました。 これは、何かをする必要があるという怠を正当化するサブパラグラフです。 そして、いつものように昨日必要なタスク。 すでにプログラマーからログを収集する必要があります。 これらのログを処理する部分は準備ができているので、必要なのはそれだけです。 したがって、最初に発明され、使用を開始したのは、コンテナ内のdev / logソケットを取得してマッピングし、そこに書き込みを開始したことです。 かっこいい！



私たちは決定し、同意し、展開し、うまくいきました。 メッセージが来ています。 最初の問題が発生するまで、ホストのsyslog config'iを変更してリロードする必要がありました。 T.O. コンテナは古いソケットを保持し続け、そこに何かを書き込み、メッセージはどこにも行かず、そこに残ります。 どうする



この問題は良いケースです。これは、最初の段階にあった決定の最初のスケッチを忘れないことを示唆しています。 この場合、「1つのサービスが1つのコンテナーであるという考えで、コンテナー内にsyslogを作成して、神に祝福してください」という考えに戻る必要がありました。 そして、1つのサービスについて物理的に私たちに話した人はいませんでした。 syslogをコンテナにプッシュしました。このsyslogの構成は変更されません。実際、現在のバージョン以外をサポートする必要はありません。syslogでは、起動するマシンのローカルホストにヘルメットを送信し、 'このマシンは、ログとともに中央リポジトリにデータを送信します。



次の興味深い問題は、コンテナにディレクトリデバイスを追加したり、何らかの種類のブロックデバイスを追加するために、比較的ディレクトリが必要であるという事実に関するものです。 すべてがシンプルなように見えます。-vスイッチを指定、追加、すべてが機能します。 また、当社には、いくつかのループデバイスを使用してコードを配布し、-o loopでマウントするという機能があります。 抽象ブロックデバイスがあり、コンテナで起動し、このループデバイスからディレクトリの下にあるデバイスをマップします。 すべてが正常に機能し、Dockerの特別な機能により、すべてのディレクトリ、内部でマップしようとするすべてのファイルは、マウントポイントのチェーン全体に沿って移動し、そのバージョンで実行するために必要なすべてのproc /マウントをドラッグしますあなたが彼に言うと、すべてのproc / mountが一緒にドラッグします。

さらに、問題の本質は、すべての人にとって、このループデバイスをアンマウントして、マシンに12-20-50がないようにすること、そして古いコードを毎週必要としないことが明らかになることだと思います。 そして、私たちはここで何を得ますか？ 特定のプロセスがブロックデバイスを保持している状態になりますが、それをアンマウントすることはできません。 これを行うには、コンテナに移動して、そこにマウント解除する必要があります。 しかし、以来 「特権なし」モードでコンテナを起動しますが、そこでホストシステムからumountを作成することはできません。



そして、かなり興味深い問題が発生します。これは、コンテナでのみ再起動できることを示唆しています。 これは解決策ではありません。これは本当に大きな問題です。原則として、解決策は技術的ではないかもしれませんが、組織内での何らかの合意の形です。



したがって、最初に解決できる解決策は、基本的に機能します-特権モードでコンテナーを取得して実行することです。 しません

2つ目のことは、さまざまな部門で、プログラマー、リリースチーム、他の誰かと一緒に座って考え、これらの動的なマウントポイントを配置しないようにする方法を考えることです。



つまり これは、座って何ができるかを考える必要がある場合の1つです。 この問題を解決するためのいくつかの構造的な内部合意と変更。 つまり この場合、技術的な立場から問題について戦うことは意味がありません。 Dockerコンテナーの場合、このような動的ループデバイスの使用を停止しました。



以下の興味深いレーキは、nf_conntrackを使用してiptablesに接続されています。 Dockerについて読むと、Dockerは何を提供しますか？ 彼は、私たちは好きなだけコンテナを起動でき、膨大な数のポートを使用でき、内部のコンテナ間の接続を手配でき、何らかの分離ができると言います。 もちろん、iptablesを使用すると、起動時にコンテナで指定するのを忘れた場合に規定できるルールがあります。 しかし、誰も1つのことについて明確に語っていません。この場合、Linuxモジュールnf_conntrackを使用する義務があり、それ自体は高速ではありません。



この問題を解決する方法は2つあります。

最初の方法は、アプリケーションがネットワークにあまりロードされていない場合、そのままの状態を維持することです。 nf_conntrackテーブルがオーバーフローする瞬間まで、すべてが正常に機能します。 寿命を延ばすために何ができますか？ nf_conntrackテーブルを拡大します。

さらに、これはそのような因果関係です-conntrackテーブル自体を増やす場合、接続のハッシュテーブルを増やして、Linuxカーネルのデフォルトよりも多くなるようにする必要があります。

3番目の項目を覚えておく価値があります。デフォルトでは、Linuxでは約10分ですべての接続が確立され、すでに解決されています。 実際、最新のサービスでは、30秒以上かかると思います。 接続を作成した後、何かが発生しなかった場合は、サービスが不良であるか、単に接続が不要です。 したがって、10分は実際のオーバークロックです。



このアプローチでは、実践が示しているように、座って待つことができます。 しかし、遅かれ早かれ問題が発生し、確実に発生します。 そして、conntrackの動作が遅いため、何もしないほうが良いという事実により、ある時点で、これらの増加は単に助けにはなりません。



この問題を自分でどのように解決しましたか？ 最初に言いたいのは、conntrackを使用せず、実稼働環境やサービスでは使用しないようにすることです。 ネットワーク交換の量がはるかに少ないため、開発の一部として使用し、ステージングに使用します。

私が見ることを提案するものから-これは素晴らしいWeaveプロジェクトです。これにより、ネットワーク機器をバイパスしてネットワーク相互作用を構築できます。 これは、Dockerホスト間のソフトウェアソリューションです。 最も簡単な解決策は、Dockerの起動時に生成できるデフォルトブリッジを使用することです。 また、組み込みのLinuxブリッジコンフィギュレーターを使用することもできます。 そして、あなたが美しいともう少し柔軟性を望むなら、素晴らしい冗談があります-Open vSwitch。 現時点では、Dockerのプラグインのリストには、Open vSwitchに対するコントロールがありません。これは、昨年約束した残念なことです。



前に言ったように、すべてのコンテナを起動してconntrackを削除するときに、ホストシステムからコンテナへのネットワークデバイスの傾きを使用するように、自分で決定しました。 これはそのような問題であり、考える価値があるため、問題を解決しなかったスタンプは解決しました。 私たち自身、このように決めました。誰かが違う方法で解決するかもしれません。



Dockerに直面したほとんどの人が少なくともいくつかのビジネスに直面していた次の興味深い点は、ファイルを保存するためのストレージドライバーの選択でした。 誰もが長所を持っているため、誰もが短所を持っています。 彼らが市場に参入して提供したAuFSがありますが、メインラインには入らず、決して入らないでしょう。 論理デバイスを取り出してマウントする、つまりマウントするときの問題に対するクールな解決策があります。 これは、デバイスマッパーに加えて、ある種の組み込みファイルシステム（条件付きX3）です。 このマウントを実行しています-再マウント...これはすべて、一般的に、これらのレイヤーと論理デバイスの巨大なチェーンに成長します。 BTRFSがあります。これは、Dockerに必要な機能の半分が、ファイルシステムの固有の機能としてデフォルトでサポートします。 そして、いくつかのプラグイン、クールなもの、実際にはそうではないものによって実装される他のいくつかのものがあります。 ここで、私が一緒に仕事をしなければならなかった3つのことを書き留めました。



また、BTRFSが引き起こす可能性のある問題も調べてください。 BTRFSでは、何らかの種類のブロックデバイスを保持する必要があります。これは、BTRFS上のDockerのルートディレクトリになります。 サーバー上のすべてのパーティションテーブルにBTRFSがあるわけではないため、これにより、リセットを行うか、LWMを確認してこのパーティションを選択する必要がありました。

第二に、BTRFSがディスクに直接樹脂を作らず、ブロックデバイスに直接書き込みをせず、最初に独自のジャーナルを保持し、ジャーナルに情報を書き込み、BTRFS自体の核プロセスが開始されるという事実を隠した人はいませんこの線は、ある種の身体の動きを作り、どこかに何かを書き留めます。 実際には、私たちの測定によると、BTRFSを使用した場合のパフォーマンスが判明しました。 どこかに、10回目の襲撃でブロックデバイスがあり、それからどこかで半分に分割されました-これがBTRFSが私たちに与えたものです。

監視サービスにとって非常に緊急の問題である運用部門は、一般に、BTRFSで占有されているスペースの量、空きスペースの量をどのように理解するかです。 そして、最大の問題は、場所があるように見えるが、存在しないように見えることです。それはどこかになくなっており、メタ日付が膨らんでいて、いくつかのファイルがあり、実行する必要があることを理解していますリバランス、そしてあなたはピークに近づいており、IOはすでに苦しんでおり、リバランスもしています。 悲しみ。



過去1〜2年にわたるBTRFSの利点のうち、これが正常に機能し、少なくとも予想どおりDockerで機能した唯一のストレージドライバーです。 彼らは問題を解決したようで、BTRFSが私たちの選択です。 私たちはSSDを購入し、私たちは生き、神は彼にパフォーマンスを祝福し、それを理解します。



そしてここでは、少し前に新しいストレージドライバーであるOverlayFSに注目しました。 今後、その実装に取り​​組んでおり、既にテスト段階を通過しており、いくつかのテストを受けており、テストは非常に優れていると言います。

灰色のFSとオーバーレイの赤を塗りつぶしたままにしているのはなぜですか？ バージョン3.18以降、別の名前でカーネルに入り、単にオーバーレイというモジュールの名前でカーネルに入りました。 カーネルに組み込まれたOverlayFSモジュールが長い間行ってきたことを誰もが知っていますか？ 私も知りません オーバーレイに関する新しいスライドはありません。先週、文字通り準備ができていた情報を言います。 テストによると、作業の速度、EX4に基づくOverlayFSを使用した応答時間、Dockerからのオーバーヘッドの割合は、エラーの範囲内で最大3-5％でした。 , . , – 3.18, , .. , .

Overlay FS BTRFS , , -. BTRFS, , . BTRFS, .. , , , , , , – , . , , , , , . Overlay . , performance / , ? , , DF. , , . かっこいい。 つまり , , ! , , , .



, . , , . , , .. cmd, , - ?

, – Entrypoint, - .., , - Docker cmd .



なぜなら , , entrypoint – . - . , , S6, . , init- Docker-. , , , , .. , . , - . . , , .

-, -, , – From Dockerfile. . , . -, - – Docker. , , , - . つまり , , . - , , . つまり .

, , . Docker 1.6, -. docker.exec, -, -, . , , exec , , , -, .. , - - , find - , , cut . , Docker inspect', name-space , exec', url', , , . 1.7, 1.8, garbage collector, , exec', . , , , , .



, - , -, , Docker, , , . , , , - .



, - . , , , .



? , , - , , , . ? - - , zypper - , - update' , , , , . , , . , - , , , .



, , , application production, , , RPM- , , . - , , .. つまり , , .



- , , Dockerfile , . . , puppet. docker_build.



? . Dockerfile' . / , . , , . Registry, , , - , , . , , , .



. - JIRA , , , . . , , «», . , puppet' - config', rebuild. つまり , , , , config', . , ( ) , , , success registry, .



Docker , , . , docker , - . , .. , - Graphite, .



? Docker CLI , docker stats, CPU . SAR . SAR' . - docker , Graphite. . ? . , - FS, . Graphite. , , , , Docker , Zabbix'.



, . , , , , . , , , CPU.



.…



, , .



CPU.



, – , , , , . , , - , . , baDocker, .

• , , – , ,
  - . – Clientless. , Docker API,
  -?
  
• Registry – . 1 2, Registry. そして
  Docker, Registry v2.
  
• , - , ( ). , ,
  .
  
• , - , « , ,
  , ». , .
  
• , – Dashboard, , « , , ,
  , , ».
  

. つまり Summary , , , , , , .



, , . , , .



, - , - , , « shell »…



, , , .



, , .. – : «, , ».



– , Docker, , , , , , . , , , – , , .

連絡先

» a.turetsky@corp.badoo.com
» twitter
» Badoo

— HighLoad++ . 2016 — HighLoad++ , 7 8 .

HighLoad++ 2016 DevOps, docker', :

• 5 PHP- / ;
• Aviasales: docker / ;
• Docker- /

また、これらの資料の一部は、高負荷システムHighLoadの開発に関するオンライントレーニングコースで使用されますガイドは、特別に選択された文字、記事、資料、ビデオのチェーンです。私たちの教科書にはすでに30以上のユニークな資料があります。接続してください！