Linux 上の .NET Core、馬に乗った DevOps

私たちはできる限り最善を尽くして DevOps を開発しました。 私たちは 8 人でしたが、Vasya が Windows で一番クールでした。 突然、Vasya が去り、私は Windows 開発から提供された新しいプロジェクトを立ち上げる任務を負うことになりました。 Windows 開発スタック全体をテーブルに放り出したとき、この状況が大変であることに気づきました...

物語はこうして始まる アレクサンドラ・シンキノバ на DevOpsConf。 一流の Windows スペシャリストが会社を辞めたとき、Alexander はこれから何をすべきか考えました。 もちろん Linux に切り替えてください。 Alexander は、100 人のエンド ユーザー向けに完了したプロジェクトの例を使用して、どのようにして前例を作成し、Windows 開発の一部を Linux に移行することができたのかを説明します。

TFS、Puppet、Linux .NET Core を使用してプロジェクトを簡単かつ楽に RPM に配信するにはどうすればよいでしょうか? 開発チームが Postgres と Flyway という言葉を初めて聞いたとき、締め切りが明後日だった場合、プロジェクト データベースのバージョン管理をどのようにサポートすればよいでしょうか? Docker と統合するにはどうすればよいですか? .NET 開発者に Windows とスムージーを捨てて Puppet と Linux を支持させるにはどうすればよいでしょうか? Windows を運用環境で維持する力も意欲もリソースもない場合、イデオロギーの対立をどのように解決すればよいでしょうか? これについて、Web デプロイ、テスト、CI、既存のプロジェクトでの TFS の使用方法、そしてもちろん、壊れた松葉杖と実用的なソリューションについて、Alexander のレポートの転写に記載されています。

それで、Vasyaは去りました、その仕事は私にあり、開発者はピッチフォークを持って待ちわびています。 ついにヴァシャを返すことができないことに気づいたとき、私は本題に取り掛かりました。 まず、フリート内の Win VM の割合を評価しました。 スコアは Windows に有利ではありませんでした。

私たちは DevOps の開発を積極的に行っているため、新しいアプリケーションを提供するアプローチで何かを変更する必要があることに気づきました。 解決策は XNUMX つだけです。可能であれば、すべてを Linux に転送することです。 Google が私を助けてくれました。当時、.Net はすでに Linux に移植されており、これが解決策であることに気づきました。

なぜ .NET Core を Linux と組み合わせて使用​​するのでしょうか?

これにはいくつかの理由がありました。 「お金を払う」か「払わない」かで言えば、私のように、大多数は後者を選択するでしょう。 MSDB のライセンスの費用は約 1 ドルですが、Windows 仮想マシンのフリートの維持には数百ドルの費用がかかります。 大企業にとって、これは大きな出費です。 それが理由です 貯蓄  - 最初の理由。 最も重要ではありませんが、重要なものの XNUMX つです。

Windows 仮想マシンは、他の Linux 仮想マシンよりも多くのリソースを消費します - 彼らは重いです。 大企業の規模を考慮して、Linux を選択しました。

システムは既存の CI に簡単に統合されます。 私たちは自分たちを進歩的な DevOps であると考えており、Bamboo、Jenkins、GitLab CI を使用しているため、ほとんどの作業は Linux 上で実行されています。

最後の理由は、 便利な伴奏。 私たちは、技術的な部分を理解し、中断のないサービスを確保し、XNUMX 番目のラインからのサービスを維持する「エスコート」の参入障壁を下げる必要がありました。 彼らはすでに Linux スタックに精通しているため、Windows プラットフォーム用のソフトウェアの同じ機能を理解するために追加のリソースを費やすよりも、新しい製品を理解し、サポートし、保守する方がはるかに簡単です。

必要条件

何よりもまず - 開発者にとっての新しいソリューションの利便性。 特に Linux という言葉が話題になった後は、そのすべてが変化に対応する準備ができているわけではありませんでした。 開発者はお気に入りの Visual Studio、アセンブリとスムージーの自動テストを備えた TFS を望んでいます。 本番環境への配信がどのように行われるかは、彼らにとって重要ではありません。 したがって、Windows 開発では通常のプロセスを変更せず、すべてを変更しないことにしました。

新しいプロジェクトが必要です 既存の CI に統合する。 レールはすでに存在しており、構成管理システム、受け入れられた配信標準、監視システムのパラメーターを考慮してすべての作業を行う必要がありました。

サポートと操作のしやすさ、さまざまな部門およびサポート部門からのすべての新規参加者の最低参加基準の条件として。

締め切り - 昨日.

Win開発グループ

そのとき Windows チームは何に取り組んでいたのでしょうか?

今なら自信を持ってそう言えます アイデンティティサーバー4 同様の機能を備えた ADFS に代わる優れた無料の代替手段です。 エンティティフレームワークコア - 開発者にとっては楽園です。わざわざ SQL スクリプトを書く必要がなく、データベース内のクエリを OOP 用語で記述できます。 しかしその後、行動計画の議論中に、私はこのスタックをあたかもシュメール語の楔形文字であるかのように見て、PostgreSQL と Git だけを認識しました。

当時は積極的に使っていましたが、 人形 構成管理システムとして。 私たちのプロジェクトのほとんどで使用したのは、 GitLab CI, エラスティック、バランスの取れた高負荷サービスを使用して HAプロキシ すべてを監視しました ザビックス、靭帯 グラファナ и プロメテウス, イェーガーそしてこれはすべて鉄片の上で回転していました HP c ESXi на ヴイエムウェア。 誰もがそれを知っています - このジャンルの古典です。

これらすべての介入を開始する前に何が起こったのかを見て理解してみましょう。

何でした

TFS は非常に強力なシステムであり、開発者から最終的な運用マシンにコードを配信するだけでなく、クロスプラットフォーム レベルで CI を提供するために、さまざまなサービスと非常に柔軟に統合するためのセットも備えています。

以前は、これらはソリッドウィンドウでした。 TFS は、多くのプロジェクトを組み立てるために複数のビルド エージェントを使用しました。 各エージェントにはタスクを並列化してプロセスを最適化するために 3 ～ 4 人のワーカーがいます。 その後、リリース計画に従って、TFS は焼きたてのビルドを Windows アプリケーション サーバーに配信しました。

私たちは何を達成したかったのでしょうか?

私たちは配信と開発に TFS を使用し、アプリケーションを Linux アプリケーション サーバー上で実行します。これらの間にはある種の魔法があります。 これ Magic Box そして、これからの仕事の塩があります。 分解する前に、一歩脇に置いて、このアプリケーションについて少しお話します。

プロジェクト

このアプリケーションは、プリペイド カードを処理するための機能を提供します。

クライアント

ユーザーには XNUMX つのタイプがありました。 最初の SSL SHA-2 証明書を使用してログインすることでアクセスを取得しました。 U 第2 ログインとパスワードを使用してアクセスできました。

ハプロキシ

その後、クライアント リクエストは HAProxy に送信され、次の問題が解決されました。

• 一次認可。
• SSL 終端。
• HTTP リクエストの調整。
• ブロードキャストリクエスト。

クライアント証明書はチェーンに沿って検証されました。 私たちは - 権威 私たち自身がクライアントにサービスを提供するために証明書を発行しているため、これを行う余裕があります。

XNUMX 番目の点に注目してください。これについては少し後で説明します。

バックエンド

彼らはバックエンドを Linux 上に作成することを計画していました。 バックエンドはデータベースと対話し、必要な権限のリストをロードし、承認されたユーザーが持つ権限に応じて、財務書類に署名して実行用に送信したり、ある種のレポートを生成したりするためのアクセスを提供します。

HAProxy による節約

各クライアントがナビゲートする XNUMX つのコンテキストに加えて、アイデンティティ コンテキストもありました。 アイデンティティサーバー4 ログインするだけで、これは無料で強力な類似物です。 ADFS  - Active Directoryフェデレーションサービス.

ID リクエストはいくつかの手順で処理されました。 最初の一歩 - 顧客 バックエンドに侵入しました、このサーバーと通信し、クライアントのトークンの存在を確認しました。 見つからなかった場合、リクエストは送信元のコンテキストに戻されましたが、リダイレクトが行われ、リダイレクトによって ID に送られました。

第 XNUMX ステップ - リクエストが受信されました IdentityServer の認証ページに移動し、 クライアントが登録された場所に、待望のトークンが IdentityServer データベースに追加されました。

第三段階 - クライアントはリダイレクトされて戻されました それが由来するコンテキストに。

IdentityServer4 には次の機能があります。 返却リクエストに対するレスポンスをHTTP経由で返します。。 サーバーの設定にどれだけ苦労しても、ドキュメントでどれだけ啓発しても、HTTPS 経由の URL を持つ最初のクライアント要求を受け取るたびに、IdentityServer は同じコンテキストを HTTP で返しました。 私たちはショックを受けました！ そして、これらすべてをアイデンティティ コンテキストを通じて HAProxy に転送し、ヘッダーで HTTP プロトコルを HTTPS に変更する必要がありました。

何が改善されましたか?どこに保存しましたか?

IdentityServer4 を別のセグメント内の別のノードとして配置せず、アプリケーションのバックエンドが実行される同じサーバー上のバックエンドとともに使用したため、ユーザーやリソースのグループを承認するための無料のソリューションを使用することでコストを節約しました。 。

どのように機能するべきか

それで、約束したように、マジックボックスです。 私たちは Linux への移行が確実であることをすでに理解しています。 解決策が必要な具体的なタスクを定式化しましょう。

人形が現れます。 サービスとアプリケーションの構成を提供および管理するには、優れたレシピを作成する必要がありました。 鉛筆のロールは、それがいかに迅速かつ効率的に行われたかを雄弁に示しています。

配送方法。 標準はRPMです。 Linux ではこれなしではやっていけないことは誰もが理解していますが、アセンブリ後のプロジェクト自体は、実行可能な DLL ファイルのセットでした。 その数は約150で、プロジェクトは非常に困難でした。 唯一の調和のとれた解決策は、このバイナリを RPM にパッケージ化し、そこからアプリケーションをデプロイすることです。

バージョン管理。 頻繁にリリースする必要があり、パッケージ名をどのようにするかを決める必要がありました。 これは、TFS との統合レベルの問題です。 Linux 上にビルド エージェントがありました。 TFS はタスクをハンドラー (ワーカー) にビルド エージェントに送信するときに、ハンドラー プロセスの環境に含まれる多数の変数も渡します。 これらの環境変数には、ビルド名、バージョン名、その他の変数が含まれます。 詳細については、「RPM パッケージの構築」セクションを参照してください。

TFS のセットアップ 結局パイプラインの設定に取り掛かりました。 以前は、すべての Windows プロジェクトを Windows エージェントに収集していましたが、現在は Linux エージェントが表示されます。ビルド エージェントはビルド グループに含める必要があり、いくつかのアーティファクトで強化され、このビルド エージェントでどのような種類のプロジェクトがビルドされるかを示します。 、パイプラインを何らかの方法で変更します。

アイデンティティサーバー。 ADFS は私たちのやり方ではなく、オープンソースを目指しています。

コンポーネントを見てみましょう。

Magic Box

XNUMX つの部分で構成されます。

Linux ビルド エージェント。 Linux は、私たちが Linux 用に構築しているため、論理的です。 この部分は XNUMX つのステップで実行されました。

• ワーカーを構成する プロジェクトでは分散して作業することが予想されていたため、一人ではありませんでした。
• .NET Core 1.x をインストールする。 標準リポジトリではすでに 1 が利用可能であるのに、なぜ 2.0.x なのでしょうか? というのは、開発を開始した時点では安定版が 1.09 だったので、それをベースにプロジェクトを作ることになりました。
• Git 2.x.

RPM リポジトリ。 RPM パッケージはどこかに保存する必要がありました。 すべての Linux ホストで使用できる同じ企業 RPM リポジトリを使用することが想定されていました。 それが彼らのしたことなのです。 リポジトリサーバーが設定されている ウェブフック これにより、指定された場所から必要な RPM パッケージがダウンロードされました。 パッケージのバージョンは、ビルド エージェントによって Webhook に報告されました。

GitLab。 注意！ ここでの GitLab は開発者ではなく、運用部門によってアプリケーションのバージョン、パッケージのバージョンを管理し、すべての Linux マシンのステータスを監視するために使用され、レシピ (すべての Puppet マニフェスト) が保存されます。

人形 — 物議を醸す問題をすべて解決し、Gitlab から必要な構成を正確に提供します。

ダイビングを始めます。 RPM への DLL 配信はどのように機能しますか?

DDL から RPM への配信

.NET 開発のロックスターがいるとします。 Visual Studio を使用してリリース ブランチを作成します。 その後、それを Git にアップロードします。ここでの Git は TFS エンティティ、つまり開発者が使用するアプリケーション リポジトリです。

その後、TFS は新しいコミットが到着したことを確認します。 どのアプリですか？ TFS 設定には、特定のビルド エージェントがどのようなリソースを持っているかを示すラベルがあります。 この場合、彼は、.NET Core プロジェクトをビルドしていることを認識し、プールから Linux ビルド エージェントを選択します。

ビルド エージェントはソースを受け取り、必要なファイルをダウンロードします。 依存関係 .NET リポジトリ、npm などから。 アプリケーション自体をビルドしてその後のパッケージ化を行った後、RPM パッケージを RPM リポジトリに送信します。

一方で、次のようなことが起こります。 運用部門のエンジニアはプロジェクトの展開に直接関与し、パッケージのバージョンを変更します。 ヒエラ アプリケーションレシピが保存されているリポジトリ内。その後、Puppet がトリガーされます。 ヤム、リポジトリから新しいパッケージを取得すると、アプリケーションの新しいバージョンを使用できるようになります。

言葉で言うとすべて簡単ですが、Build エージェント自体の内部では何が起こっているのでしょうか?

DLL RPM のパッケージ化

TFS からプロジェクト ソースとビルド タスクを受け取りました。 ビルドエージェント ソースからプロジェクト自体の構築を開始します。 組み立てられたプロジェクトはセットとして利用可能です DLLファイル、ファイル システムの負荷を軽減するために、zip アーカイブにパッケージ化されています。

ZIP アーカイブは破棄されます RPM パッケージのビルド ディレクトリにコピーします。 次に、Bash スクリプトは環境変数を初期化し、ビルド バージョン、プロジェクト バージョン、ビルド ディレクトリへのパスを見つけて、RPM-build を実行します。 ビルドが完了すると、パッケージは次の場所に公開されます。 ローカルリポジトリ、これはビルド エージェント上にあります。

次に、Build エージェントから RPM リポジトリ内のサーバーへ JSONリクエストが送信される バージョンとビルドの名前を示します。 先ほど説明した Webhook は、まさにこのパッケージをビルド エージェントのローカル リポジトリからダウンロードし、新しいアセンブリをインストールできるようにします。

RPM リポジトリへのこの特定のパッケージ配信スキームを使用する理由は何ですか? アセンブルされたパッケージをすぐにリポジトリに送信できないのはなぜですか? 実はこれが安全性を確保するための条件なのです。 このシナリオにより、権限のないユーザーがすべての Linux マシンにアクセスできるサーバーに RPM パッケージをアップロードする可能性が制限されます。

データベースのバージョン管理

開発チームとの協議で、彼らは MS SQL に近いことが判明しましたが、Windows 以外のほとんどのプロジェクトではすでに PostgreSQL を全力で使用していました。 有料のものはすべて放棄することに決めていたので、ここでも PostgreSQL を使い始めました。

このパートでは、データベースのバージョン管理方法と、Flyway と Entity Framework Core のどちらをどのように選択したかについて説明したいと思います。 それらの長所と短所を見てみましょう。

コンズ

フライウェイは一方向にしか進みません、私たちは 巻き戻すことはできません - これは重大な欠点です。 開発者の利便性の観点から、他の方法で Entity Framework Core と比較できます。 私たちがこれを最前線に置き、主な基準は Windows 開発のために何も変更しないことであったことを覚えているでしょう。

フライウェイにとって 何らかのラッパーが必要だった奴らが書かないように SQLクエリ。 これらは OOP の観点からの動作にはるかに近いものです。 データベース オブジェクトを操作するための手順を記述し、SQL クエリを生成して実行しました。 データベースの新しいバージョンの準備が完了し、テストされました。すべて問題なく、すべて動作します。

Entity Framework Coreにはマイナス点があります - 重い負荷がかかると 最適ではない SQL クエリを構築する、データベースのドローダウンが大きくなる可能性があります。 しかし、私たちは高負荷のサービスを持っていないため、負荷を数百 RPS で計算することはなく、これらのリスクを受け入れ、問題を将来の私たちに委ねました。

プロたち

エンティティフレームワークコア すぐに使用でき、開発も簡単です、フライウェイ 既存のCIに簡単に統合。 しかし、私たちは開発者にとって便利なようにしています:)

ロールアップ手順

Puppet は、移行を担当するバージョンを含め、パッケージのバージョンが変更されることを認識します。 まず、移行スクリプトとデータベース関連の機能を含むパッケージをインストールします。 この後、データベースと連携するアプリケーションが再起動されます。 次に、残りのコンポーネントのインストールが行われます。 パッケージがインストールされ、アプリケーションが起動される順序は、Puppet マニフェストに記述されています。

アプリケーションはトークンやデータベースのパスワードなどの機密データを使用します。これらはすべて Puppet マスターから設定に取り込まれ、暗号化された形式で保存されます。

TFSの問題

すべてが実際にうまく機能していると判断した後、他のプロジェクトの Win 開発部門全体として TFS のアセンブリで何が起こっているのかを確認することにしました。ビルド/リリースが迅速に行われているかどうかに関係なく、速度に関する重大な問題を発見しました。

主要なプロジェクトの 12 つは組み立てるのに 15 ～ XNUMX 分かかります。これは長い時間であり、そんな生活はできません。 簡単な分析により、I/O のひどい低下が判明しました。これはアレイ上で発生していました。

成分ごとに分析した結果、XNUMX つの病巣が特定されました。 初め - 「カスペルスキー アンチウイルス」、すべての Windows ビルド エージェントのソースをスキャンします。 XNUMX番 - Windows インデクサ。 これは無効化されておらず、展開プロセス中にビルド エージェント上ですべてがリアルタイムでインデックス付けされました。

三番目 - NPMインストール。 ほとんどのパイプラインで、まさにこのシナリオを使用していることが判明しました。 なぜ彼が悪いのでしょうか？ Npm インストール手順は、依存関係ツリーが形成されるときに実行されます。 パッケージロック.json, ここには、プロジェクトのビルドに使用されるパッケージのバージョンが記録されます。 欠点は、Npm install が毎回インターネットから最新バージョンのパッケージを取得するため、大規模なプロジェクトの場合はこれに時間がかかることです。

開発者は、プロジェクトの特定の部分または全体がどのように機能するかをテストするために、ローカル マシンで実験を行うことがあります。 地元ではすべてがうまくいっていることが判明したのに、組み立てて展開しても何も機能しないことが判明することがありました。 私たちは問題が何であるかを理解し始めます - そう、依存関係を持つパッケージの異なるバージョンです。

ソリューション

• AV 例外のソース。
• インデックス作成を無効にします。
• に行く npmci.

npm ci の利点は次のとおりです。 依存関係ツリーを一度収集します、開発者に提供する機会が得られます。 現在のパッケージのリスト、ローカルで好きなだけ実験できます。 これ 時間を節約する コードを書く開発者。

設定

ここで、リポジトリの構成について少し説明します。 歴史的に私たちが使用しているのは、 Nexus リポジトリの管理用。 内部リポジトリ。 この内部リポジトリには、自己作成のモニタリングなど、内部目的で使用するすべてのコンポーネントが含まれています。

私たちも使っています NuGet他のパッケージマネージャーと比較してキャッシュが優れているためです。

結果

ビルド エージェントを最適化した後、平均ビルド時間は 12 分から 7 分に短縮されました。

Windows で使用できたマシンをこのプロジェクトで Linux に切り替えたすべてのマシンを数えると、約 10 ドルを節約できました。これはライセンスの金額だけであり、内容を考慮するとさらに多くなります。

予定

次の四半期では、コード配信の最適化に取り組む予定でした。

プリビルド Docker イメージへの切り替え。 TFS は、Docker イメージのトリガーベースのアセンブリなど、パイプラインへの統合を可能にする多くのプラグインを備えた優れた機能です。 このトリガーを同じものにしたい パッケージロック.json。 プロジェクトの構築に使用されるコンポーネントの構成が何らかの理由で変更された場合は、新しい Docker イメージを構築します。 これは、後で、組み立てられたアプリケーションを含むコンテナーをデプロイするために使用されます。 現在はそうではありませんが、社内で積極的に開発を行っており、長い間実稼働ソリューションを提供してきた Kubernetes のマイクロサービス アーキテクチャに切り替える予定です。

サマリー

私は皆さんに Windows を捨てることをお勧めしますが、それは私が Windows の作り方を知らないからではありません。 その理由は、ほとんどのオープンソース ソリューションが Linuxスタック。 大丈夫ですか 資源を節約する。 私の意見では、未来は強力なコミュニティを持つ Linux 上のオープンソース ソリューションに属します。

アレクサンダー・シンチノフの講演者プロフィール GitHub 上で.

DevOps 会議 は、専門家による専門家のための開発、テスト、運用プロセスの統合に関するカンファレンスです。 それが、アレクサンダーが話したプロジェクトの理由ですか？ 実装されて動作し、パフォーマンス当日には XNUMX つのリリースが成功しました。 の上 RIT++ での DevOps カンファレンス 27月28日とXNUMX日には、開業医から同様のケースがさらに増えるだろう。 まだ最後尾の車両に飛び乗ることもできますし、 レポートを送信 または時間をかけてください 本 チケット。 スコルコボでお会いしましょう!

出所： habr.com