この記事では、Sberbank TechnologiesとPPRBの例を使用して、DevOpsツールスタックの構成について説明します。 この記事は、DevOpsを実装するための作業構造の客観的な評価が必要なインフラストラクチャオートメーションエンジニア、および作業に精通したい人を対象としています。

小規模で統一されたチームでDevOpsプロセスを編成するのが非常に簡単であることは周知の事実です。 さらに、最新の有能な開発者と管理者により、開発とサポートの高い文化の結果として、このプロセスはそれ自体で形をとることができます。 しかし、10人の小さなチームが数百人のオフィスに成長し始めたらどうでしょうか。 組織にすでに数千人の人がいるが、悪魔のような匂いがしなかったらどうしますか？ これらの質問により、Sberbank-Technologyの従業員に目を向けました。Sberbank-Technologyは大規模プロジェクトでのDevOpsプラクティスの実装に積極的な経験があり、何かを学びました。

セーフハーバー

まず、小さな予約。 多くの人々は、他の企業でこれがどのように行われるかについての記事を読む理由を尋ねます。 彼らはそれをしました、そして私たちはそれをします、それはどのような違いをもたらしますか？

Sberbank Technologies製品はもちろんSberbankで使用されており、私たちのお金は仕事の安定性とセキュリティに依存しています。 また、この記事の登場は、社内の技術プロセスについて話すことがすでに可能になったときに、会社が開発のポイントに到達したことを示しており、これはまったく正常です。 これはあいまいさによる何らかのセキュリティではありませんが、本当に優れた高品質のデバッグシステムです。これはその価値であり、現在読んでいるテキストの価値です。 これは実際に機能するものです。 この知識があれば、好きなことは何でもできます。たとえば、同じインフラストラクチャを自分でコピーアンドペーストできます。 または、突然そのようなインフラストラクチャでの生活が好きになった場合は、Sberbank-Technologyで働きに行きます。

それでも、devopsの商用運用への導入については説明しません。 これはセキュリティのためだけでなく、実装がまだ進行中であるため、ここで殺されていない熊の結果を議論するのは間違っているふりをしましょう。 promのdev PRPRBの実装は、この年の終わり、または来年の初めに行われると想定されています。おそらく、彼らはJBreak / JPoint 2018でそれについて話すでしょう。現在に集中しましょう。

いずれにせよ、記事にはエラーや記載漏れが含まれる場合があります。 この記事は、Sberbank-TechnologyまたはSberbankの公式な立場ではありません。 この記事から取得した情報は、商業的またはその他の重要な決定の基礎として使用することはできません。

問題規模

SBT devoプロジェクトの特徴は何ですか（そのような非公式な方法で組織を呼びましょう）。 もちろん、これは規模です。 2017年、SBTの従業員数はロシアの17都市にある9,800人を超えました。

なぜ多くの人が必要なのか、彼らは何をするのか？ （普通の人が尋ねます）。 正式には、次のように聞こえます。

• SBTは、ロシアと東ヨーロッパで最大の銀行（従業員325千人）向けにソフトウェアを作成しています
• ロシア人の70％の生活を改善する複雑なインフラストラクチャとサービスタスクを解決します。
• 世界の1億1,000万人にSberbankサービスの利便性とアクセシビリティを提供

devopsの実装に関与するインフラストラクチャエンジニアの観点からこれは何を意味しますか？ 見てください。通常、少なくとも次の一連のタスクを設定して解決する必要があります。

• 生産とサービスの全体的な文化を強化する
• 典型的なタスク（特にCI / CD「パイプ」）のためのツールセットを策定し、実装します。
• 日常の問題を解決するスキルを向上させます（日常的な問題を自動的に解決するスキル）

これらの各問題は、ズームアウトすることで劇的に複雑になります。 チーム内のエンジニアリングプラクティスにすぐに同意することができますが、開発に関してまったく異なる見解を持つ8,500人を相互に調整することは困難です。 通常のギャラリーには足がありますが、SBTはそれを克服できます。

あるチームの自由（たとえば、不必要な詳細について考えることのできない標準化されたパイプラインを使用する自由）、別のチームにとっては、ツールの選択の自由に対する大きな制限のように見えます。 開発者に関する美しいマーケティングプレゼンテーションでは、あるチームがUnified Universal Platform of Everythingを作成した場合、別の100チームが、愛するRockとHaskellではなく、この標準プラットフォームを使用する必要があるため、それを嫌うとは言いません。 一方、誰もが異種ソリューションを選択する機会を与えられた場合、共通の製品は決して出てきません。

十分ではありません。 もう少し複雑にしましょう！ 実際、PPRBのTechnological Core（SBTの主要プロジェクトの1つ）などのプロジェクトは、特別なカスタムデプロイメントプロセス用に特別に設計された非常に複雑な自己記述技術です。 （これについての詳細は以下）。 実際、それは独自のJavaプラットフォームであり、開発者が冗談を言うのを好むので、「もう少し-そして、独自のJavaマシンを作成します！」 ここのデータベースも特別です-GridGainと、このGridGainをクックする方法に関する一連のユニークなノウハウ。 この複雑さはサブジェクト領域の一部です。「すべてをドロップして、3つのマイクロサービスの形でGolangに書き換えましょう」と言うことはできません。 それはそのようには動作しません！

したがって、インストルメンタルスタックは、異なる文化間だけでなく、設計とプログラミングへの異なるアプローチ間のバランスのポイントでもあります。

したがって、CBT CI / CD機器標準の各要素は妥協案です。 これらの決定は、交通ルールのように、何年もの間血で書かれています。 このツールの標準を示す時間です！

機器標準CI / CD

そして今、あなたは驚くでしょう。 彼のいつもに驚嘆。 これを初めて目にしてJUG.ruに驚いたので、SBTインフラストラクチャアーキテクトも、結果から何が得られたかに気付きました。 あなたは、SBTが想像を絶する新しいフレームワークを絶えず書いており、奇妙な方法で使用しているので、後でカンファレンスでそれについて話すことができるということに慣れていますか？ 今回は違います。 最良の方法（現時点では、2017年秋）は、誰もが使用しているものを使用し、鏡の輝きに解決策を磨くことです。

手始めに、トップビュー：

ほぼすべての最新プロジェクトには、同じ手順があります。 PSIは受け入れテストです。

写真が携帯電話で読めないことを事前に謝罪します。 将来的には、これらすべてのアイテムが大きな絵文字に複製されるため、何も失うことはありません。

コーディングがCI / CD規格の最も重要で大胆な部分であることは多くの人にとってショックです。 実際のところ、元のソフトウェアが批判的に誤って記述されている場合、「devops」は含まれず、何も助けにはなりません。

このため、役割に依存する2つの基本的な要素があります。

1. 開発者 通常、これはJava / Scala / Cppスタックであり、ローカルマシンで動作しています。
   
   
   • コードおよびその他のコンテンツの開発
   • リポジトリにアップロードする前に単体テストを実行する
   • develop
     
     
     
     ブランチへのコードの公開
   • バグトラッカーのタスクへのバインド
2. 主な開発者 。
   
   
   • コードレビュー
   • master
     
     
     
     ブランチにマージ

開発者は、タスクを完了するために必要なものを使用できます。 たとえば、Java開発の標準として、世界中で使用されているツール（Maven（Java自体）、Node Package Manager（JSフロント用）、JUnit、およびTestNG（テスト））を使用することをお勧めします。 SBTが独自のビルドシステムを開発するのは、それができないからではなく（なぜGoogleよりも悪いのでしょうか）、共通の平衡点の考え方に違反するからです。 会社の外部のプロジェクトが多すぎる（Spring Frameworkなしで生きてみてください！）Mavenのような標準ユーティリティに関連付けられており、この統合を壊す意味はありません。

詳細な要件は、この段階でWikiのようなシステム（Confluenceなど）に保存されます。 タスクの操作は、選択したタスク管理システム（JIRAなど）にネイティブに実装されている標準のアジャイル用語（エピック、機能、ユーザーストーリーなど）に基づいています。 これらの2つのシステムを持つことは、良い結果を得るために重要です。 このルールは血で書かれています-小さなプロジェクトでもすぐにwikiとバグトラッカーを発行する必要があります。

以下では、2つの異なるリポジトリが開発に使用されることに注意することが重要です。

• リポジトリの1つに実際の製品コードが保存されます。
• もう1つは、ビルドスクリプトのみを保存するためのものです

Infrastructure as Codeのアイデアの一部として、現在ではプロジェクトと一緒にデプロイメントスクリプトを1つのリポジトリに保存することが一般的です。 長期的な実践の結果、SBTはデプロイメントスクリプト用に別個のリポジトリを用意し、必要に応じてプログラムで強力な接続を実装することを選択しました。 この機能は、同じ「スクリプト」が異なる製品で機能する場合、スケールと複雑で関連する一般化された構成の必要性にのみ関連付けられます。 さらに、開発チームと管理チームを責任とアクセスレベルの領域に分けることができます。 もちろん、特定のプロジェクト設定と特殊なスクリプトはプロジェクトとともに保存されます。

以下、Jenkinsが制御システムとして使用されます。 誰かがそれを好きではないかもしれません。それは古代のソフトウェアであり、一定量のレガシーで生い茂り、RAM、CPU使用量などに関して深刻なフットプリントを持っているからです。 しかし、バランスのポイントについて話していたことを覚えていますか？ 事実、Jenkinsはすべての欠点について、現時点（2017年秋）で、誰もが使用することに同意するシステムであるという事実に変わりはありません。 これは将来変更される可能性があります。

Jenkinsに加えて、コーディング段階からPROMまで続くエンドツーエンド展開プロセス用の追加の制御システムが使用されます。 しかし、これは特別な内部ソフトウェアであり、この記事で説明する意味がありません。これは、オープンソースにアクセスできないことだけでなく、SBTの特定の機能に合わせて調整されているためです。 十分に大きなパイプラインを持つ企業は、 常に同様のシステムを作成するという仮定があります。 小さなプロジェクトの場合、Jenkinsに依存しないスクリプトのパックの形で、初歩的な形で存在できます。 バンドルされた10以上のプロジェクトに拡張すると、深刻なソフトウェアになる可能性があります。

コーディング段階から始めて、展開スクリプトリポジトリ、Jenkins、およびエンドツーエンドの管理ツールをすぐに利用できることが重要です。 開発者の1人がJenkinsに行き、そこで新しい仕事をする必要がある場合-それは問題ありません。 devopsツールを使用することは、空気を呼吸するのと同じくらい自由に利用でき、移動不可能です。

ここではすべてが簡単です。 使用されるツールは、初期アセンブリが作成され、テストが作成されたツールです。 最も拡張性の高いツールキットの1つを使用し、さらに、言語に大きく依存しています。 Javaの場合、ほとんどの場合、JUnit、.NET-NUnit、JS-QUnitになります。 これらのツール用のJenkinsに適切なプラグインがあることのみが重要です。 極端な場合、自分で作成することもできますが、これは望ましくありません。 コード検証は、何世紀にもわたって実証されているソリューションを使用する方が重要な重要なステップです。

多くの開発者は独自のDEVスタンド（サーバー）を持ち、そこで簡単なシステムテストやコンピューターの外部での便利な実験を行うことができます。 もちろん、これらのスタンドのリソースは非常に限られており（テラバイトのRAMを割り当てることは経済的に無意味です）、統合テストはそれらで実行できません。 しかし、実験のために-それはします。

この段階では、いくつかの重要なことが起こります。

1. 静的コード検証
2. 情報セキュリティルールへの準拠を確認する
3. 発見された欠陥は非常に重要であるため、すぐに仕事に送られます

情報セキュリティに関しては、明らかな理由でここに拡散することはありません。 セキュリティについて最後に話したのはUFOでした:-) CI / CDのすべての要素がセキュリティ要件を考慮に入れていると言うだけで十分です。その場合、マウスはそこにスリップしません。 通常、セキュリティはCI / CDツールの使いやすさを低下させるため、これは非常に複雑なトピックであり、特別なエンジニアリング上の妥協に満ちています。

従来の表面静解析でSonarQube



、 SonarQube



使用されます。 多くの異種プロジェクトには、あらゆる種類の構成とコーディングルールのセットが存在することは明らかであるため、それぞれを個別に、詳細を理解してアプローチする必要があります。 もちろん、すべてのJavaバックエンドプロジェクトには、標準的なルールのセットが事前に定義されているため、ささいなことを気にする必要はありません。

各プロジェクトには独自のスタンド（サーバー）があり、既成のソリューションをテストできます。 一般的な統合テスト用に未検証のソリューションを採用して展開することはできません。 スタンドは、プロジェクト全体と特定の開発者（実験ブランチのテスト用）の両方に割り当てることができます。 これらのスタンドには、開発者の個人的なDEVスタンドよりも深刻なリソースがありますが、合理的なものによって制限されています。 プロジェクトに割り当てられたリソースでインフラストラクチャ全体を完全に再現することは、非常に難しく、長く、経済的に無意味です。 したがって、通常の統合テストはここでは機能せず、必要ありません。

この段階で発生するいくつかの重要なポイント：

1. リポジトリ内の成果物の最終的なアセンブリおよび公開。 たとえばJavaの場合、Nexusであり、プロジェクトはMavenを使用して、または直接リンクを介してこれらのアーティファクトにアクセスできます。
2. スタンドにアプリケーションをインストールします。
3. 一連の自動テストを実行します。

これらのDEVスタンドの興味深い機能は、内部ソフトウェアのインストール、テストユーザーの作成など、すべてのルールに従って準備する必要があることです。 通常、スタンドは1台のコンピューターだけでなく、仮想マシンのクラスターです。したがって、現時点では、クラスターの正しい初期化もテストされます。 実際、スタンドが展開された瞬間から、スタック全体のミニインストールテストも行われます。

通常、 Ansible



はこの時点で表示されます。 アンサンブルは、主にターゲットシステムを構成する手段として使用され、Jenkinsから起動されます。 さらに、Ensibleは、すでに展開されているシステムをより包括的に管理するために使用できます。これは、これを目的とするものではありませんが、DEV回路の目的には優れています。 アンサンブルは、特別なエージェント（すでにすべてのGNU / LinuxホストシステムにあるSSHサーバーを除く）を必要としないため、SUDDENチームの誰かが10台のサーバーで何かを再起動する必要がある場合にも選択されました。 DEVクラスター内-これには特別な「秘密管理者の知識」は必要ありません。 Ensibleは非常にシンプルであるため、開発者と有能な管理者の両方が、最短時間でEnsibleの調査に対処します。

もちろん、Ensembleの使用には問題があります。 たとえば、標準の役割システムは、複雑なモジュールプロジェクトでは不必要に単純な場合があります。 最新バージョンでは、ネストされたロールの実験的なサポートがありますが、十分ではない場合があります（特に非常に未加工であり、Ensiblの他の機能との互換性についてテストされていないため）。 Ensembleを設定だけでなく、ターゲットシステムの管理用のシステムとして完全に使用しようとすると、Ensible自体が単なる高レベルコマンド用の「SSHアセンブラ」である、追加のバインディングソフトウェアを多数作成する必要があります。

さらに、Ensembleと緊密に連携する開発者はPythonを知っている必要があることがすぐに明らかになります。 たとえば、クラスター、Linux、アプリケーションソフトウェアなどの微調整に関連する非常に複雑な構成手順を持つ、独自のソフトウェアがあります。 これらの操作の多くは、あまり知られていないネイティブ機能を使用する必要がありますが、コミュニティは既成のソリューションを作成しておらず、今後も使用しません。 「クリーンピット」のプレイブックで説明すると、数十ページのテキストが必要になります。 そして、これらの操作のログは読みにくいおridgeになります-特に、これは適切なブランチ制御の欠如とそれに対応するログの発行によるものです（コミュニティで質問が時々出されますが、それはまだあります）。 この問題を解決するより正しい方法は、アクションプラグインとモジュールを作成することです。複雑なコードはすべて、エレガントに作成されたPythonスクリプトにカプセル化されています。 実際、高レベルのビジネスパラメータを含むプラグインコールのみが、プレイブック自体に残ります-GNU / Linuxコマンドラインユーティリティとの類推によって。 このことから、インフラストラクチャエンジニア（開発者、管理者、開発者-このタスクを実行するすべての人）が適切なレベルでPythonを知っている必要があります。 特別なPythonプログラマーと同じようにそれを知る必要はありませんが、完成したコードの読み取りとバグ修正、およびEnsemble用のシンプルなモジュールの作成ができることは成功の秘recipeです。

実際、得られる結果は、実際には、ある種の「スクリプト」ではなく、特別なサポートを必要とするかなり複雑なソフトウェアです。 ここから、2つのリポジトリへの最初の分離が行われました。1つは製品コード用で、もう1つは展開スクリプトコード用です。 展開スクリプトリポジトリの場合、通常、他の特別なリポジトリ管理システム（たとえば、Atlassian Stashではなく、特定の設定を持つGitLab）を使用して、構成管理の柔軟性を高めることができます。

上記のツールに加えて、さらに多くの小さなツールがあります。 たとえば、一部のプロジェクトではまだGridGainを使用していませんが、SQLデータベース-Liquibaseを接続して移行をロールバックできます。 などなど。 そのようなことはすでにプロジェクトの詳細に大きく依存しており、可能であれば標準化する必要があります。 たとえば、UIテストのフレームワークとしてSeleniumを選択した場合は、これに固執する必要があります。 このような決定をサポートするには、多くの専門知識が必要です。

次の段階は、専用スタンドでのクリーンで正しいシステムテストです。

ここで2つの重要なことが起こります。

1. テスト環境をインストールして構成する
2. 一連の自動テストを実行する

環境のインストールとセットアップ自体は、多くの場合、すぐに修正のために送信される多くの驚くべきものを明らかにします。 基本的に、それらは管理の単純さと容易さに関連しています。 システムは時間の経過とともに成長する傾向があり、チューニングの複雑さが増します。そして、あなたはこれらの問題を芽から取り除く必要があります-この立場から。

「純粋な」STテストの一連の自動テストは、ストリンジェンシーを高める方向で「汚れた」DEVテストとは異なる場合があります。 最小の実験プロジェクトでさえ、少なくとも基本的な煙テストが必要です。 テストがない場合、このプロジェクトは統合テストに使用できません。

統合テストは、最大かつ最も複雑で最も重要なテストです。 少なくとも、この段階では複雑なバグの数が最も多いため、開発者にはそのように思われます:-)エラーは特定のプロジェクトだけでなく、数千人ではないにしても数百人の結果に影響するため、できるだけ正確にそれを行う必要があります。

この段階で、スタンドは実際のインフラストラクチャをシミュレートし、完全な（非常に大きな）リソースを持ち、システム管理者から完全なサポートを受けます。

いくつかの重要なことが起こります。

1. テストマネージャーは、製品の公開準備ができているという通知を受け取り、それを行うかどうかを決定する必要があります。 テストマネージャーは目に見えない前線の戦闘機ですが、彼の貢献を過大評価することは困難です。
2. テスト環境をインストールして構成します。 この環境は統合テストを目的としているため、傘の傘内に統合されたすべてのプロジェクトに共通しており、製品をインストールするためのアプリケーションの受け入れに伴います。
3. 自動および手動テスト。 最も厳密で、複雑で、最大のテストスイート。
   
   「マニュアル」という言葉でベルが鳴りましたか？ はい、実際のシステムでは 、自動化をあまり受け入れられない瞬間があり、平均して、あなたはそれについて何もすることができません。 これは特にUI応答性テストに当てはまります（おそらくAIはすぐにそれらを実行しますが、まだ実行していません）。 開発チーム全体の主なタスクの1つは、この段階を可能な限り迅速かつ無痛に進めることです。
4. テストマネージャーは、すべての種類のテストに合格したことの確認を受け取り、詳細なレポートを作成します。
5. IBについては書かないことに同意しました:-)
6. 特に興味深いのは負荷テストです。その結果は長期的な結果をもたらす可能性があります。実際、これはパイプラインの最初の瞬間であり、パフォーマンスは正式な計算ではなく実際に表示されます。

完全にテストされた完成品は、ディストリビューションの特別な集中リポジトリに配置されます。 それに加えて、利用可能なすべてのドキュメントおよびその他の資料が添付されています。 受信したファイルは永久に凍結されます。 それらを変更するために特別な手段が使用されましたが、それは決して不可能でした。

（このようなリポジトリを突然自分で作成してJavaで記述したい場合は、単にNexusを使用できます）。

受け入れテストを実行することは、秘密の知識に危険に迫るもう1つのトピックです。 しかし、トップレベルでは、すべてが簡単です、それは起こります：

1. 特別な自動テストと受け入れテストの大規模な複合体の実行
2. これまでにない複雑な手動テストを含む

この段階を通過した後、製品の動作準備が整ったと想定できます。

そして最後に、明白な理由のために書くことができない実際の産業運転での展開。 はい、それは意味がありません、なぜなら 上記のパイプラインは、年末にのみプロムに到達します。 現在、プロムにデプロイする場合、手動のインストール手順が使用され、ディストリビューションに添付されているインストール手順を使用します。これは、特別なデプロイメントエキスパートによって実行されます。

自動展開の場合、この段階では2つのことが行われます。

1. 生きている人（条件付きで「devops-engineer」）は、展開の準備ができていることを手動で確認する必要があります
2. 自動展開

すべて。 この最小限のツールセットはすでに、多くの人々が1つの屋根の下で仲良くするのに十分です。 このツール標準は開発者の能力を制限するものではなく、さらなる開発のための安定したプラットフォームを提供することを理解することが重要です。

技術コアPPRB

JUG.ruカンファレンスでの Sberbank Technologiesのレポートに精通している読者（ところで、 次のカンファレンスは近日中に開催されます ）は、デボの話が上記のスキームで終わっていないことに気付くかもしれません。 むしろ、彼女はまだ始まったばかりです。

これらのソリューションはSberbank Technologies自体に非常に固有であり、誰もがそれらについて知る必要はないため、この記事は共通のツールスタックから始まりました。 まだ私たちと一緒にいる人のために、私たちは続けます。

Sbertechで使用される革新的なソリューションには、特別な開発アプローチが必要です。 その理由には、多様な技術スタック、多くのサブシステムからのデータの集約の必要性、そのような量のデータを処理するために必要な信じられない数のサーバー、サービスを実行できる「休日」および「夜間」の欠如などが含まれます。 高いパフォーマンス、フォールトトレランス、24時間365日の保守性を編成する必要があるにもかかわらず、得られるソリューションは標準のハードウェアで動作し、特別なスーパーコンピューターを必要としません。 結果として得られるソリューションは、同時に、集中型システムと分散型システムの属性を持つ必要があります。 難しい状況。

その結果、いわゆる統合情報スペースが作成されました。 これは、すべてのノードが相互接続されたクラスターアーキテクチャであり、全員が全員と通信できます。 重複や統合はありません。すべてのデータは1つのインスタンスに存在し、いつでもどのノードからでもすべてのモジュールにアクセスできます。 このシステムのバックエンドは、GridGainと呼ばれるメモリ内データグリッドです。 今日、それは大量のビジネスデータを保存および処理するための世界最高のシステムの1つです。

管理者と開発者が統合テストを処理する必要があるのは、このアーキテクチャです。 .

, CI/CD . Jenkins Ansible , . .

Java- ,



.

, “” ( -), , . , : , , , . - , Java.

, , OpenSource.

GridGain Apache Ignite ( ? , JUG.ru, ). Apache Kafka , ZeroMQ , Hyperic — Open Source. , — (, , ), , , . , Apache Kafka OpenStack — , .

, — , . , . — Kafka, , . — Ignite/GridGain, , - , IMDG, . ( ), Java- ( ). — , , , .

, , , , , , . , -. , HypericHQ — “ ”. , ( , ) , . - “ Windows”, , - . , Java-: properties-. — /etc , . , , ( ) — .properties /etc . .

, CI/CD , .

おわりに

CI/CD - ( ), - ( , ).

, : , - ; , ; , - — . , , : , .

, DevOops 2017 , - 20 2017. , - — .

謝辞

-: ( ), ( ), ( .BPM), ( ) . , , . よろしくお願いします！