Bloody Enterprise Devops

それがあなたが努力できることです

全国に350人以上のソフトウェア開発者とテスターがいます。また、エンジニアや顧客開発者と頻繁にやり取りしています。 devopsの実用化に切り替えるには、方法論の実装だけでなく、愛するロシアの顧客を基本的な文化に慣れさせることも必要でした。 理解するためのいくつかのダイアログ：

-なぜすべてが落ちたのですか？
-スタンドでスケートし、すべてをテストしてから製品に展開したため。 ここには、指示に該当せず、古い管理者の頭にのみ住んでいた設定があります。

または：

-なぜそれが全国に打ち上げられないのですか？
-数十の異なる地域のインストールがあるため、それぞれが手作業で行われ、それぞれに異なる構成があります。 そして、いくつかのケースでは、エンジニアがミスを犯しました。
-明日まで正しい？ 本当に必要です！ リモートでのみアクセスし、私たちはあなたに与えません。
-..！ もちろん、極東への旅行が大好きな高額のスペシャリストのチームがあります。 問題ありません。

文化文化

-テストベンチはどうですか？
「彼は発見者のデモで忙しい。」
-そして、どこでテストすべきですか？
-さて、同じように自分自身を少し転がしてから、プライベートクラウドに切り替えます。
-スタンドまで2時間。 私はただあなたを愛しています！
-待って、テンプレートはありますか？

またはここ：

プロジェクトの並行請負業者：
-こんにちは、親愛なる顧客、そして私たちはあなたにバイナリをもたらしました！
介入します：
-いいえ、いや、いや、親愛なる州の顧客はリポジトリ、アセンブリ、すべてを持っています。 ここでコードを折りたたみ、チェックインし、展開方法を確認してください...
-ああ！ これは機能しません！

「管理者は何人いますか？」
-まあ、約100人が数えます。
「なぜそんなにたくさん？」
-回路は大きいが、自動化はまだ行われていない、何かが高価です...停止しますが！

一般的に、基本的な文化とは、次のようなものを意味します。

1. クラウドの台頭からシステムソフトウェアの注入までのインフラストラクチャは、コードの形式で取得する必要があります。
2. プロセスに応じて、何も変更せずに、ビルドサーバーからビルドを自動的に実行します（つまり、特別な場合にのみ設定を管理します）。 さて、あなたはあなたの手で「スタート」ボタンを押すことができます。
3. チェックインから自動テスト実行まで、搬送コンベアに沿ったすべてのアセンブリの進行を視覚的に制御すると便利です。

その結果、時間とお金が節約されます。 請負業者からコードを受け取ったとしても、2年後、親愛なる顧客は、ラックに折りたたまれたソースディスクがサーバー上で回転しているものとは無関係であり、請負業者がいなくなったことに気付くでしょう。

この文化を植える

これは痛み、鼻水、涙、その他のドラマです。 多くの場合、通信はおおよそ次のように行われます。

-はい、それはクールです。 私はHabréの投稿を読んでいますが、それがいかに素晴らしいかを知っています。 自動化が必要です。
-それでは紹介しましょうか？
-いいえ、あなたは何ですか。 Documentumは最新バージョンではありません。
「だから何？」
-そして、Javaは古いです...
-見てください、すでに5つのプロジェクトでそのようなコンベヤーが走りました。 それはあなたのソフトウェア構成です。 AlfrescuおよびWebSphereを含む。
-締め切りはもう終わりです。
-さて、いつ燃えなくなりますか？
「まあ、それはもう2年、おそらくどこか別の年に燃えています。」 それから紹介します。
-無料のエンジニアがいないこと、プロジェクトを本当に加速できることを理解していますか？
-ええ、何が必要ですか？
-完成したロールをダウンロードして、Ansibleを接続すると、すべてが展開されます。 こちらがあなたを助け、すべてをセットアップするエンジニアです。 彼女も教えます
-さて、1月の会議であなたの提案を検討させてください...

昨年まで、当社の開発プロジェクトでは、継続的インテグレーションのみが厳密に必要でした（TeamCity / Jenkinsでのアセンブリ、コード分析、単体テスト）。 企業レベルでの継続的デリバリーと継続的展開への本格的な移行は、使用されるインフラストラクチャ、テクノロジー、外部顧客との作業の微妙な違いにより複雑でした。 そのため、昨年まで、運用に関与するエンジニア（顧客サービス）に対して単一の標準と一連の推奨事項はなく、それぞれが独自のスタックを使用していました。

自動化の仕組みを理解している人はほとんどいません。 一部の人々は、それは高価で困難であると信じています-「このプロジェクトにリスクを負わない」。 しかし、たとえば、いくつかのチームがCROC内でスタックを実行した後、実際に多くのチームが、節約された時間と人的資源が思ったよりはるかに現実的であることに気付きました。 そして、その瞬間から始まりました。 したがって、過去のプロジェクトのエンジニアがマネージャーから「1ダースのサーバーを手動でデプロイする」というタスクを受け取った場合、彼は自動化に向かう​​すべての権利を持ち、リーダーとして私は彼の側にいます。

文化に管理手段を浸透させることに慣れていないため、さまざまな技術スタックを備えた最も複雑なプロジェクト（WebSphereでの統合プロジェクト、DocumentumおよびAlfrescoでのECMプロジェクト、Javaおよび.Netでのカスタム開発）について話し合いを行い、ツールを選択しました。 その結果、私たちは満足した男子（および女子）、確信した悲観論者に対する具体的な議論、および基盤の基盤を獲得しました。

次は、ツールと実装のレビューの話です。 あなたがすべてを知っていれば-まっすぐに進んで、「ツール」セクションで、専門家にとって興味深いものがあるとは考えられません。これは教育プログラム以上のものです。

ツール

350人の開発者がテクノロジースタックと動物園で作業しています。さらに、CROCバーチャルラボには、Amazon EC2 APIとVMwareのOpenstackの両方があります。 また、下位レベルに多数のスクリプトツールがありました。 しかし、上部では、どこから落ちたのか、どこで、どのような構造で、コンベアがどのように見え、何が起こるのかが明確ではありません。 視覚化ツールが必要でした。

私たちは、無料で無料のソフトウェアから供給コンベヤーを自動化する包括的なソリューションを組み立てるという困難な課題に直面しました。これは、このクラスの工業所有権のあるソリューションに劣らないでしょう。

このクラスのシステムのアーキテクチャは、3つのコンポーネントで構成されています。

•最上位では、アプリケーション配信パイプラインを自動化および視覚化するためのソリューション。 これは主に、エンドユーザーがリリースのすべての段階の経過を追跡できるWebインターフェイスです-ソースコードからのパッケージの最初のアセンブリからすべてのテストの通過まで、任意の段階を再起動し、プロセスが失敗した場合にログを確認します。
•インフラストラクチャの展開を自動化するソリューション。 これは一種のオーケストラであり、そのタスクは、アプリケーションのインフラストラクチャ（特定のクラウドプロバイダーの仮想マシン）を作成することです。 この場合、コンポーネントは基本的なインフラストラクチャの作成を担当し、次のコンポーネントはソフトウェアの微調整と構成を担当します。
•システムソフトウェアのインストール、リリースに必要な追加アプリケーション、データベースおよびアプリケーションサーバーの構成、さまざまなスクリプトの実行の開始、アプリケーションのリリースの直接インストールなど、作成済みのインフラストラクチャの構成に必要な構成管理ソリューション。

各ブロックについて、最も適切で人気のあるツールを分析しました。 各コンポーネントをより詳細に検討し、トップレベルから始めましょう。

ツールに求めていたものと見たもの

（オープンソースであることに加えて）ツールを選択するための主な基準は次のとおりです。

•統合の観点からの汎用性：ツールは、プロジェクト（git、mercurial、TFS）で使用されるすべてのメインソースコード管理システムをサポートし、CI JenkinsおよびTeamcityと友達になり、SeleniumおよびJMeterテストシステムと連携でき、相互作用を簡単にカスタマイズできる必要がありますオープンソースのインフラストラクチャ展開および構成管理システム。
•カスタマイズされたパイプラインと設定をテキスト設定にエクスポート/インポートする機能（Pipeline-as-a-Code）。
•トレーニング曲線：最終的に、発見されたツールについて、発見された実装エンジニアをトレーニングする必要がありました。 このツールは、習得と調整が簡単でなければなりません。

私たちはジェンキンスから始めました。私たちはすでにCIとして立ち、機能していました。 CDおよびパイプライン自動化ソリューションとして適していますか？ 結局のところ、膨大な数のプラグインと統合にもかかわらず、いいえ、そしてその理由は次のとおりです。

•Blue Oceanプロジェクトにはまだ管理インターフェイスが含まれていません。リリースの経過を段階ごとに美しい写真で見ることができますが、同じインターフェイスから特定の手順を再開することはできません。
•パイプライン自体をソースコードの形式で記述する必要があり、宣言型パイプラインを記述するための言語はまだ湿っています-管理とトレーニングの難しさ。
•JenkinsとともにTeamcityを運営していますが、一部のプロジェクトではより便利です。

これらの理由により、安定性（追加のプラグインでロードしたくない安定した機能のJenkinsがあります）および機能の分離（結局、TeamCityのようなJenkinsは、ソフトウェアを直接構築するためのCIサーバーとして使用されます）のため、調査を続けました。

銀行会社CapitalOneの開発者のプロジェクトであるHygeiaは、主に有益なユーザーインターフェイスで私たちを魅了しました。このインターフェイスでは、とりわけ、コミットと貢献者に関する統計情報、スプリントタスクの概要、スプリントに実装された機能のリストを見ることができます。 それでも、包括的なWeb UIにもかかわらず、ツールは作成者のタスクに高度に特化されていることが判明しました。

Hygeiaは、必要な統合の欠如、調査時点での不十分なドキュメント、およびツールの機能の拡張とカスタマイズが困難なため、基準に適合しませんでした。

次に、主にCloud Foundryに関連するプロジェクトをサポートするために、Cloud Foundry Foundationコミュニティによって作成されたConcourse CIに注目しました。 Concourse CIは、1分間に複数のリリースを展開およびテストする必要がある非常に大規模なプロジェクトに適しています。インターフェイスを使用すると、アプリケーションリリースの複数のブランチのステータスを一度に評価できます。 Concourseは、統合に関して必要な柔軟性と普遍性が不足しているため、タスクに適していませんでした。さらに、特定のアプリケーションブランチのリリースのさまざまなバージョンの進捗状況をより詳細に把握する必要がありました（Concourseでは、最新バージョンのみが表示されます）。

最後に、 GoCDプロジェクトを確認しました。 GoCDは2007年からその歴史をリードしており、2014年にソースコードがコミュニティに投稿されました。 GoCDは、統合の普遍性の基準を満たしました。GoCDに必要なものはすべてそのままでサポートされているか、簡単に構成できました。 GoCDには、DevOps実践者にとって重要なPipeline-as-a-codeパラダイムの実装もあります。

マイナスには以下が含まれます。

•直観的に理解できないエンティティのネスト：すべてのステージ、ジョブ、タスクなどをすぐに処理するのは簡単ではありません。
•エージェントをインストールする必要があり、スケーリングとマルチスレッド化には追加のエージェントのインストールが必要です。

上位レベルに決め、残りの2つのブロックを検討します

インフラストラクチャ展開ツールを選択するための主な基準は、有名なクラウドプロバイダーであるAWS、Openstack、およびVMware vSphereの異種環境のサポートです。 Bosh、Terraform、Cloudifyを検討しました。

Boshは 、Concourse CIと同様に、Cloud Foundry Foundationコミュニティによって作成されました。 複雑なアーキテクチャを備えた非常に強力なツールには、次の利点があります。

•Boshを介して展開されたサービスを監視する機能。
•展開されたサービスの障害から自動的に、ボタンごとに回復する機能。
•展開可能なコンポーネントのオブジェクトリポジトリ。
•展開されたコンポーネントのバージョン管理を制御するための組み込み機能。
ただし、独自の仮想マシンテンプレート形式により豊富な機能が提供されています。この理由と、Boshツールの全体的な複雑さのために、それは私たちには合いませんでした。

Terraformは、コミュニティで広く知られているHashicorpツールです。 会社の他の自由に配布された製品と同様に、アーキテクチャ的にはバイナリファイルを表します。 インストールが簡単で習得が簡単です。展開に必要なインフラストラクチャを宣言形式で記述し、terraform planコマンドで展開する方法を確認し、terraform applyコマンドで直接起動するだけで十分です。 産業用アプリケーションの場合、無料のTerraformの欠点は、サーバー部分の欠如、ログの集約、実行中のプロセスのステータスの監視（つまり、集中管理と監査の欠如）です。 この瞬間は有料のTerraformで決定されますが、私たちは独占的に無料のツールに興味があったので、Terraform以外の場合にはCloudifyを使用することに決めました。

Cloudifyは、 GigaSpacesによって作成されたインフラストラクチャ展開ツールです。 このツールの特徴は、OASIS TOSCA標準の宣言型IaaCテンプレートでの事実上のサポートです。 機能面では、CloudifyはBoshに近いです。Cloudifyからデプロイされたサービスを監視でき、デプロイされたサービスをスケーリングするだけでなく、障害から回復するプロセスがあります。 Boshとは異なり、Cloudifyには直感的なWebインターフェイスがあり、Cloudifyはクラウドプロバイダーの標準VMテンプレートを使用してインフラストラクチャを展開します。 プラグインによりツールの機能が拡張され、Pythonで独自のプラグインを作成することができます。 しかし、製品の最新バージョンのほとんどのグラフィカルインターフェイスは有料版に切り替わったと言わなければなりません。

そのため、インフラストラクチャの展開には、そのシンプルさ、トレーニングと実装の速度のためにTerraformを選択し、その機能と汎用性のためにCloudifyの無料バージョンを選択しました。 Terraformと友だちにしたよりも、仮想ラボ用のOpenStack互換のAPIをすばやく作成しました。

構成管理のソリューションを決定することは残っています。 Ansible、Chef、Puppet、Saltの4つの大きなものを見ました。

PuppetとChefは、構成管理ツールの市場における「古いもの」です（最初のバージョンは、それぞれ2005年と2009年にリリースされました）。 Rubyで書かれた、拡張性の高いクライアントサーバーアーキテクチャを備えています。 まず第一に、彼らはエントリーのしきい値が高いため、私たちのタスクに適合しませんでした。設定テンプレートを含むRuby言語で実装エンジニアをトレーニングしたくありませんでした。

SaltはPythonで書かれた新しいソリューションです。 設定テンプレートはすでに便利なYAML形式になっています。 Saltの興味深い機能は、制御されたマシンと対話するエージェントとエージェントレスの両方の方法の可能性です。 それでも、Saltのドキュメントは構造が不十分で理解しにくいため、新しいユーザー向けにさらにシンプルなツールを使用したいと考えました。

そして、そのようなツールがあります-これはAnsibleです。 このツールは、インストール、使用、学習が簡単です。 AnsibleもPythonで記述されており、設定テンプレートはYAML形式です。 Ansibleにはエージェントレスアーキテクチャがあり、管理対象マシンにクライアントをインストールする必要はありません-対話はSSH / PowerShellを介して行われます。 もちろん、ホスト数が1,000を超えるインフラストラクチャでは、速度が低下する可能性があるため、エージェントレスアーキテクチャは最良の選択ではありませんが、このような問題に直面することはありませんでした：プロジェクトのインフラストラクチャのボリュームは非常に小さく、Ansibleは私たちにとって完璧でした。

解決策

その結果、DevOpsパイプラインを自動化するための次のツールセットを入手しました。



フードの下でAnsibleおよび（場合によって）CloudifyまたはTerraform。 最上位はGoCDです。

次に、選択したツールをプロジェクトの1つに実際に適用する方法について説明します。 このプロジェクトにDevOpsプラクティスを使用するケースは簡単ではありませんでした。 開発はいくつかの水銀リポジトリで行われ、リリースの集中リポジトリはありませんでした。 リリースエンジニア（手動で更新プログラムのインストールを実行した特別なトレーニングを受けた人）に提供されたソフトウェア展開に関する技術文書に特に注意が払われます。 真実を知るために、ワード文書、Confluenceのエントリ、Slackのメッセージから情報を収集することが少しずつ必要でした。 時々、ドキュメンテーションはファンタジーの要素を持つフィクションのようでした。 引用：

地獄の門の第2部。 データベースをいっぱいにします。
2.1このパートでは、特に多くの困難と試練に直面します。注意してください。 まず、DBA権限を持つユーザーSYSとしてデータベースに接続します
2.2呪文を唱えますスクリプトを実行します。

すべての操作の監査と統合の後、開発者はドキュメントを完成させ、人間と構成管理システムの両方が理解できる便利な形式でドキュメントを提示しました。

開発は、わずかな変更を加えていくつかのスタンドで行われました。 テスト環境には、最も完全なCI / CDパイプラインが含まれており、7つの段階に分けることができます。

1. Jenkinsでリリースビルド

顧客は以前にJenkinsを使用していましたが、開発者のマシンでローカルにアセンブリを行い、リリースをアーカイブの形で転送しました。 アセンブリを一元化されたJenkinsサーバーに転送し、Artifactoryにアーティファクトを保存するといいと言いました。 これにより、すべてのアーティファクトのエンドツーエンドのインデックス作成、必要なバージョンの迅速なインストール、個々のスクリプトブロックのテスト、およびスクリプトのエラーに伴う変更を確認することができました。



2.インフラストラクチャの展開

テスト環境をCROCバーチャルラボに移し、永続的な状態に保つことを停止しました。 テスターの要求により、またはJenkinsでの新しいリリースの出現後に自動的に、CROC仮想実験室のOpenstackに以前にロードされたVMテンプレートからのTerraformマニフェストに基づいて、環境が引き上げられます。



出力変数の形式で、スタンドのアドレスを取得し、シナリオの後半で使用します。

3.スタンドの構成

パイプラインの最も面倒な部分は、スタンドの自動構成のメカニズムを開発することでした。

Oracleデータベースを構成し、IBM MQバスとIBM WASアプリケーションサーバーを構成する必要がありました。 これらの設定はすべてロシア語版のWindowsで行う必要があるため、状況は複雑でした（sic！）。 データベースに関してすべてがほぼ透過的である場合、CLIまたは他の自動化された手段からプロジェクトでMQおよびWASを構成する人はいませんが、すべてを機能させるためにインターフェースのどこをクリックするかを示すことしかできません

私たちは、エンジニアが数日かかった作業を11分で行うユニバーサルプレイブックを作成しました。



4.基本的なアプリケーションのインストール

お客様がアプリケーションをWASにインストールおよび更新するために、お客様はbatスクリプトを実行しましたが、それらについてはあまり掘り下げず、初期形式でパイプラインに組み込みました。 終了コードをチェックし、ゼロでない場合は、すでにログを見て、このアプリケーションまたはそのアプリケーションが起動しなかった理由を理解します。 スクリプト実行ログは、スクリプトアーティファクトとして保存されます。



5.ユーザーインターフェイスアプリケーションのインストール

このステージは前のステージと非常に似ており、同じパイプラインテンプレートから実行されます。 唯一の違いは、batスクリプトで使用される構成ファイルです。 ただし、すべてのスタンドがユーザーインターフェイスを必要とするわけではないため、更新の利便性のために別の段階に分ける必要がありました。

6.テスト

テスト用に、さまざまなツール（Selenium、JMeter）を使用しました。 このスクリプトを使用すると、いくつかのテスト計画を変更することができ、その選択はこの段階で変数の形式で設定されます。 テスト結果に基づいて、カスタムタブを作成したレポートが生成されます。 これで、GoCDインターフェースから直接便利に表示できます。



7.インフラストラクチャの削除

テストの結果、責任者は通知を受け取り、このアセンブリを実稼働に移行するか、変更が必要かを決定します。 すべてが順調であれば、テストベンチを取り外して、CROCバーチャルラボのリソースを浪費することはありません。

その結果、このプロジェクトでDevOpsパイプラインを使用するための次のロジックが得られました。



そして、これらはインターフェースです：


フローマップ（コミットからバージョン管理システムへのリリースの移動、テスト実行）


1つのシナリオのステージのステータスの視覚化


スクリプト実行の段階に関する詳細情報（ログ、スクリプトへの変更履歴、段階の実行時間）


フローマップ（別のプロジェクト、よりコンパクト）


2パイプラインからのスクリプトの一般的なビュー

別の例は、katの前の図の7つのパイプラインからのスクリプトの一般的なビューです。

新しい配送コンベアの導入の結果によると、チームからフィードバックを得ることが重要でした（カットなし）：

「大幅に（数日から数時間に）新しいスタンドを作成する時間が減少しました。 今、あなたは異なるバージョンのいくつかのスタンドを維持することができません。 必要に応じて、DevOpsコードはプロジェクトコードとともにバージョン管理されるため、目的のバージョンはゼロから引き上げられ、スタンド自体は目的のバージョンのリリース時の状態に対応することが保証されます。 爆発品質が向上しました ドキュメント。 DevOpsコードは明らかに命令を繰り返しているため、「暗黙の」ものなどはそこに残されていません。エンジニア向けのルーチン操作の数は減少しています。

テストを作成するテスターの能力は、エンジニアの関与を​​最小限に抑えながら、複雑なケース（負荷、フォールトトレランス）を表します。 プロジェクトインフラストラクチャを管理するための最初のステップは、バージョン管理、テストなどです。すばやく、便利に、わかりにくい。
理解できない、珍しい-非常に一般的な言葉であるため、受け入れられているツールに関するトレーニングを定期的に実施しています。

そして、これはエネルギー会社のプロジェクトからのフィードバックです：

「長時間のルーチン操作の自動化。 週に1日約0.5〜1人を節約します。 また、リリースの準備中、実際には、1人のエンジニアの50％が更新ビルドに従事していました。 更新プロセスをスピードアップします。 すべてのサイト（7個）の更新に関する定期的なメンテナンス作業は平均3時間です-更新の自動化+セルフテスト+目で確かめてください（つまり、実際の残業は最小限に抑えられます）。 すべての環境に関する情報の保管を合理化し、その関連性とタイムリーな更新を保証します。 夜間の自動検出と自動テストの導入-製品の状態の透明性を高めます。 製品品質の改善。 ホットフィックスをリリースする必要はほとんどありません。 リリースコストの削減。」

何を得たの

• 組み立てられたビルドの品質に関する運用情報、配送コンベヤーの視覚的表現。
• 標準の配布リポジトリには常にアセンブリがあります。
• スタンド上の現在の変化をすばやく確認する機能。
• さまざまな仮想化のすべてでインフラストラクチャ（コードとしてのインフラストラクチャ）をプログラムする機能。
• 適切なインフラストラクチャとアプリケーションシステムを適切なオンデマンドバージョンに迅速に展開する機能。
• サンプルプロジェクトを構成するためのAnsibleサンプルロール。

インフラストラクチャを確立するために、いくつかのプロジェクトタスクの作業を中断する必要がありました。 devopsの実装が早ければ早いほど、費やす時間が少なくなります。 それ以外の場合は、プロジェクトのアクティビティが少ない期間にそれを実装する必要があり、いつ発生しますか？

私たちは引き続き、自動化の必要性について会社とその周辺に優しく知らせます。 丁寧に。 きちんと。

参照：

• 全体の集中化の開始の1年前に私たちのopsの面白いバイク
• このスタックを使用した原子力エネルギーのプロジェクトの結果は次のとおりです
• 全国の開発センターについて（ちなみに、それ以降、ヴォロネジとチェリャビンスクでさらに多くのセンターが追加されました）。
• 私のメールはsstrelkov@croc.ruです。