最高の人々と言うのは間違いではありません
苦しみを通して喜びを得る。
ルートヴィヒ・ヴァン・ベートーヴェン
私はSergeyです。Yandex.Moneyのパフォーマンス調査チームで働いています。 オーケストレーションを使用するための私たちの道についての物語の始まり、つまりどのように楽器を選択したか、何が考慮されたかについてお話したいと思います。 記事のすべてのイベントはリアルタイムで行われるため、読者の皆様は、状況の進展をほぼリアルタイムで追跡できます。
チームに指揮者が必要なのはなぜですか？
指揮者は誰ですか？ 神父から diriger-管理、直接、リード-音楽の世界で-これは、アンサンブル音楽の学習と演奏のリーダーです。 私たちの場合、この場所はオーケストレーションおよび自動化システムで占められています。
彼らの役割は、音楽における指揮者の役割と違いはありません。彼らは、チームを助け、そのプレーを指揮し、組織するために必要です。
原則として、チームには一定の能力があります。プロジェクトを実装するサーバーと呼びましょう。
これらのサーバーを取得して運用する方法はさまざまです。 いくつかの例：
- チームは、特定のパラメーターを持つリソースを提供するために、たとえば運用グループに要求を行います。
- 運用グループは、クラウドまたはベアメタル（「ベアメタル」）に必要な量を提供し、SLAに従ってそれらを良好な状態に維持することを約束します。 調整も運用チームによって実行されます。
- チームは、運用グループからクラウドまたはベアメタルリソースのみを受け取り、独自に設定を実行します。
- チーム自体がリソースを「購入」し、それらを完全に独立してサポート/構成します。
私たちのチームは、サポートが必要なサーバーを使用します-OSの更新、新しいパッケージのインストールなど。
私たち自身のために、2つの主なタイプに区別しました。
- タンクグループ
- サービスグループ。
タンクグループは、Yandex.Tankを持つホストで構成されます。
サービスグループには、メンテナンスに関連するすべてのものが含まれます。これらは、リリースサイクルのサポートを提供したり、自動レポートを生成したりするためのさまざまなサービスです。
ある時点で、これらのすべてが手動で管理するのに不便になり、サーバーの「ロード」から始まり、社内サービスの開発、レイアウト、起動までのプロセス全体を自動化することを考えました。
オーケストラ自体が演奏できる場合でも、指揮者が必要なのはなぜですか？
まず、Ansibleを習得し、システム管理者への依存を軽減するためにベアメタルサーバーを "注ぎ"始めました-誰もがここで勝利し、新しいスキルを獲得し、常に私たちなしで行っている作業の一部を管理者から解放します。 私たちは、できる限り専門性と自主性を超えてチームを発展させるよう努めています。
同社は、すでに設定および規制されている長い間Ansibleと協力してきたため、このプロセスにソリューションを簡単に統合しました。
ホスティングは、3つのAnsibleロールで構成されています。
- 最初の役割はOSをインストールし、
- 2番目は、ホストの基本設定であるLDAP認証をロールします。
- 3番目は、Yandex.Tankと関連する依存関係をdockerコンテナにインストールします。
チーム内で使用するサービスに移りましょう。
私たちのタスクでは、KotlinとPython、そしてもう少しGolangを等しく使用します。 サービスの開発と展開を統一するために、サービスをdockerコンテナにパックすることにしました。 これにより、プログラミング言語を選択する自由が与えられると同時に、アプリケーションの統一配信形式が規制されます。
Dockerのipv6に関する小さなコメント
対話するサービスの一部はipv6を介してのみ使用できるため、コンテナー用にipv6を作成する方法を理解する必要がありました。
公式Docker Webサイトにあるipv6のドキュメントによると、ipv6はdaemon.jsonにパラメーターを追加することで有効になります。
{ "ipv6": true, "fixed-cidr-v6": "2001:db8:1::/64" }
この場合、プロバイダーは、ipv6サブネットを発行する必要がfixed-cidr-v6.
ます。これは、 fixed-cidr-v6.
しfixed-cidr-v6.
ただし、別のオプション-ipv6 NATを選択しました。その理由は次のとおりです。
- 現在、ドッカーは ipv6でのみ使用できません 。
- 各コンテナにグローバルにルーティング可能なアドレスが存在するということは、追加のフィルタリングが実行されない場合、すべてのポート（未公開のものも含む）がすべてのポートで利用可能になることを意味します。
- ポートを公開するためのユーザーランドプロキシ、 ipv4のみのiptables 。
ipv6 NATは、それ自体がip6tablesのルールを管理し、新しいコンテナーが追加されたときにそれらを編集するdockerコンテナーです。
このソリューションが正しく機能するためには、多くの操作を行う必要がありました。 システムでip6table_natを必ず初期化してください。 システムにインストールされたモジュールの存在は、起動時にモジュールがカーネルにロードされることを保証しません。 新しいホストでNATを使用してコンテナを起動するときにこのエラーが発生したときに、これが発生しました。
2019/01/22 14:59:54 running [/sbin/ip6tables -t filter -N DOCKER --wait]: exit status 3: modprobe: can't change directory to '/lib/modules': No such file or directory ip6tables v1.6.2: can't initialize ip6tables table `filter': Table does not exist (do you need to insmod?)
modprobeモジュールを使用してAnsibleロールに初期化を追加し、lineinfileを使用して起動時にロードすると、問題は解決しました。
- name: Add ip6table_nat module modprobe: name: ip6table_nat state: present - name: Add ip6table_nat to boot lineinfile: path: /etc/modules line: 'ip6table_nat'
ちなみに、ハーバーに関する良い記事があります。これは、ドッカーでipv6を操作する特定の方法の長所と短所を簡潔かつ明確に説明しています。
しかし、最初に尋ねた質問に戻ります。
オーケストラ自体が演奏できる場合でも、指揮者が必要なのはなぜですか？
今では誰もが私たちのチームでプレーする方法を知っています：
- サーバーを「充填」するプロセスが作成されます。
- サービスの開発と展開は統一されています。
合理的な質問が発生します-Dockerコンテナ内のサービスを効率的かつ可能な限り自動化して展開、更新、制御する方法は？
オーケストラの各メンバーは自分の部分を知っているという事実にもかかわらず、彼は迷い、元のアイデアから離れることができます。 ここでは、指揮者がいなければオーケストラが効果的にリハーサルやハーモニーを奏でることができないという事実に至ります。 指揮者は、すべてが単一のペースと気分で統一されるようにするために、すべてのパフォーマンスパラメーターを担当します。
最小限の投資で良い導体を得る方法は？
オーケストレーションのテーマは、市場で十分に開発されています。 しかし、最初に、指揮者を助けることができる支援ツールについて話しましょう。
Consulは、2つの主な機能を提供するシステムです。
- サービス発見
- 分散キー値ストレージ。
オーケストラでは、Consulがサービスの登録と設定の保存を担当します。 2つの登録オプションがあります。
- アクティブ-これは、サービス自体がHTTP APIを使用して登録するときです。
- パッシブ-サービスは手動で登録する必要があります。
Vaultは、安全なストレージを標準化および統合し、パスワード、証明書などのシークレットを操作するリポジトリです。
このツールを使用して得られる利点は次のとおりです。
- 秘密を作成および保持し、HTTP APIを介してライフサイクルを管理するための単一のセンター。
- Transit Secrets Engine-保存せずにデータを暗号化/復号化します。 安全でない通信チャネルを介して暗号化された形式でデータを送信する機能。
- 構成に便利なアクセスポリシー。
- 秘密へのアクセスを監査します。
- インフラストラクチャ内で自己署名証明書を管理するための独自のCA（認証局）を作成する機能。
すべての要件を考慮して、指揮者の役割に適した2つのオプション-KubernetesとNomad。
クベルネテス
彼についてすでに何件の記事や本が書かれていますか （例えば、これは）、レポートは私が簡単に書くと言われました-これはほとんど何でもできる普遍的なプロセッサーです。 Kubernetesでクラスターをセットアップしてサポートすることは、必ずしもそう簡単にはいきません。
遊牧民
このツールは 、上記の領事と金庫室で知られているHashiCorp社のものです。
Nomadは、Kubernetesよりもインストールと構成が簡単であるように思われました。 1つのバイナリファイルは、サーバーモードとクライアントモードの両方で機能します。 同時に、Nomadは、クラスター管理、高速スケジューラー、マルチデータセンターのサポートなど、解決したいタスクの全リストを網羅しています。 さらに、領事とボールトを使用する場合、より緊密に統合してサービスを調整します。
現在作業中のもの：
- Consulの展開用にサーバーを準備し、
- nomadクラスター構成がConsulに入力されます。これを使用して、nomadを自動的に展開する必要があります。
- 並行して、秘密を保持するためにボールトをインストールします。
ホールでの質問は、そのような仕事のために指揮者を持つことが価値があるのか、それなしでオーケストラが良いのかということです。 あなたがこれについてどう思うかをコメントで教えてください。
私たちのブログを購読して連絡を取り合いましょう-最終的に何が起こったのか、そして望んだとおりにnomadクラスターを構成したかどうかをすぐにお知らせします。
居心地の良いテレグラムチャットルームにアクセスして、いつでもアドバイスを求めたり、同僚を助けたり、パフォーマンスの研究などについて話をしたりできます。