アプローチ IaC (コードとしてのインフラストラクチャ) は、リポジトリに保存されているコードだけでなく、このコードを取り巻く人々やプロセスからも構成されます。ソフトウェア開発からインフラ管理、記述までのアプローチを再利用することは可能ですか?この考えを念頭に置いて記事を読むと良いでしょう。

英語版

これは私の記録です 公演 на DevopsConf 2019-05-28.

スライドとビデオ

• 英語版
• ロシア語版
• 予行演習 2019-04-24 SpbLUG
• DevopsConf 2019-05-28 のビデオ(RU)
• DINS DevOps EVENING 2019-06-20 のビデオ(RU)
• スライド

bash の歴史としてのインフラストラクチャ

あなたが新しいプロジェクトに来て、彼らがあなたにこう言ったとします。 コードとしてのインフラストラクチャ」。実際に判明したのは bash の歴史としてのインフラストラクチャ またはたとえば bash 履歴としてのドキュメント。これは非常に現実的な状況であり、たとえば、同様のケースがデニス・リセンコ氏の講演で説明されました。 インフラ全体を交換してぐっすり眠り始める方法と彼は、bash の歴史からプロジェクトの一貫したインフラストラクチャをどのようにして取得したかについて語った。

ある程度の願望を込めて、こう言えます。 bash の歴史としてのインフラストラクチャ これはコードのようなものです:

1. 再現性: bash 履歴を取得し、そこからコマンドを実行すると、出力として動作する構成を取得できる場合があります。
2. バージョン管理: 誰が入ってきて何をしたかはわかりますが、これが出口で機能する構成につながるかどうかは事実ではありません。
3. история: 誰が何をしたかの物語。ただし、サーバーを失った場合は使用できなくなります。

何をするか？

コードとしてのインフラストラクチャ

こんな奇妙なケースでも、 bash の歴史としてのインフラストラクチャ 耳を持って引っ張ることができます コードとしてのインフラストラクチャしかし、古き良き LAMP サーバーよりも複雑なことを実行したい場合は、このコードを何らかの方法で変更、変更、改善する必要があるという結論に達します。次に、これらの間の類似点を検討したいと思います。 コードとしてのインフラストラクチャ そしてソフトウェア開発。

ドライ。

ストレージ システム開発プロジェクトにはサブタスクがありました。 定期的にSDSを構成する: 新しいリリースをリリースしています。さらなるテストのためにロールアウトする必要があります。タスクは非常に簡単です。

• ここにsshでログインしてコマンドを実行します。
• そこにファイルをコピーします。
• ここで設定を修正します。
• そこでサービスを開始します
• ...
• 利益！

説明したロジックについては、特にプロジェクトが始まったばかりの初期段階では、bash で十分です。これ bashを使うのは悪くないしかし、時間が経つにつれて、似たような、しかし少し異なるものを展開するというリクエストが発生します。最初に思い浮かぶのはコピー＆ペーストです。そして今、ほぼ同じことを行う非常によく似た 2 つのスクリプトがすでに存在しています。時間が経つにつれて、スクリプトの数が増加し、インストールを展開するには、異なるスクリプト間で同期する必要がある特定のビジネス ロジックがあり、これが非常に複雑であるという事実に直面しました。

D.R.Y. のような習慣があることが判明しました。 （同じことを繰り返さないでください）。アイデアは、既存のコードを再利用することです。簡単そうに聞こえますが、私たちはすぐにこれにたどり着きませんでした。私たちの場合、それは構成をスクリプトから分離するという平凡なアイデアでした。それらの。インストールを個別に展開し、個別に構成する方法のビジネス ロジック。

固体。 CFM用

時間が経つにつれてプロジェクトは成長し、 自然な継続 Ansibleの登場でした。この登場の主な理由は、チームに専門知識があり、bash が複雑なロジック向けに設計されていないことです。 Ansible には複雑なロジックも含まれるようになりました。複雑なロジックが混乱に陥るのを防ぐために、ソフトウェア開発でコードを整理するための原則があります 固体。 また、例えば、グリゴリー・ペトロフは、「ITスペシャリストにはなぜ個人ブランドが必要なのか」というレポートの中で、ソフトウェア開発において、人は何らかの社会的エンティティと連携しやすくなるように設計されているという疑問を提起した。オブジェクトです。これら 2 つのアイデアを組み合わせて開発を続けると、次のこともできることに気づくでしょう。 固体。 将来、このロジックの保守と変更を容易にするためです。

単一責任の原則

各クラスは 1 つのタスクだけを実行します。

コードを混ぜ合わせて、一枚岩の神聖なスパゲッティ モンスターを作成する必要はありません。インフラストラクチャは単純なレンガで構成されている必要があります。 Ansible プレイブックを小さな部分に分割し、Ansible ロールを読み取ると、メンテナンスが容易になることがわかりました。

オープンクローズの原則

オープン/クローズの原則。

• 拡張にオープン: 新しいエンティティ タイプを作成することでエンティティの動作を拡張できることを意味します。
• 変更は受け付けていません: エンティティの動作を拡張した結果、それらのエンティティを使用するコードに変更を加える必要はありません。

当初、テスト インフラストラクチャを仮想マシンにデプロイしていましたが、デプロイのビジネス ロジックが実装とは分離されていたため、問題なくベアメタルへのロールアウトを追加しました。

リスコフ置換原理

バーバラ・リスコフの置換原理。プログラム内のオブジェクトは、プログラムの正しい実行を変更することなく、そのサブタイプのインスタンスと置き換え可能でなければなりません。

もっと広く見ると、それは特定のプロジェクトに適用できる機能ではありません。 固体。、これは一般に CFM に関するもので、たとえば、別のプロジェクトでは、さまざまな Java、アプリケーション サーバー、データベース、OS などの上にボックス化された Java アプリケーションをデプロイする必要があります。この例を使って、さらに原理を考えていきます 固体。

私たちの場合、imbjava または oraclejava ロールをインストールしていれば、Java バイナリ実行可能ファイルが存在するという合意がインフラストラクチャ チーム内にあります。これが必要な理由は、上流の役割はこの動作に依存しており、Java を期待しています。同時に、これにより、アプリケーションのデプロイロジックを変更せずに、ある Java 実装/バージョンを別の実装/バージョンに置き換えることができます。

ここでの問題は、これを Ansible で実装することが不可能であるという事実にあり、その結果、チーム内でいくつかの合意が生じることになります。

インターフェース分離の原則

インターフェイス分離の原則: 「多くのクライアント固有のインターフェイスは、1 つの汎用インターフェイスよりも優れています。

当初、アプリケーションのデプロイメントのすべての可変性を 443 つの Ansible プレイブックにまとめようとしましたが、サポートするのが困難でした。また、外部インターフェイスを指定した場合 (クライアントはポート XNUMX を期待します)、インフラストラクチャを個別のプレイブックから組み立てることができます。特定の実装用のブリック。

依存関係逆転の原則

依存関係逆転の原理。より高いレベルのモジュールは、より低いレベルのモジュールに依存しないでください。どちらのタイプのモジュールも抽象化に依存する必要があります。抽象化は詳細に依存すべきではありません。詳細は抽象化に依存する必要があります。

ここでの例はアンチパターンに基づいています。

1. 顧客の 1 人はプライベート クラウドを持っていました。
2. クラウド内の仮想マシンを注文しました。
3. ただし、クラウドの性質により、アプリケーションのデプロイは VM がどのハイパーバイザー上にあるかに関連付けられていました。

それらの。高レベルのアプリケーション展開ロジックは依存関係を伴ってハイパーバイザーの下位レベルに流れたため、このロジックを再利用するときに問題が発生しました。 このようにしないでください。

相互作用

Infrastructure as Code は、コードだけではなく、コードと人々の関係、インフラストラクチャ開発者間の対話についても意味します。

バス係数

プロジェクトに Vasya が含まれていると仮定しましょう。 Vasya はインフラストラクチャについてすべてを知っています。Vasya が突然消えたらどうなりますか?彼はバスに轢かれる可能性があるので、これは非常に現実的な状況です。しばしばそれは起こります。これが発生し、コード、その構造、動作方法、外観、パスワードに関する知識がチーム間で共有されていない場合、多くの不愉快な状況に遭遇する可能性があります。これらのリスクを最小限に抑え、チーム内に知識を分散するには、さまざまなアプローチを使用できます。

ペアデボプシング

それはそうではありません 冗談として、管理者がビールを飲み、パスワードを変更し、ペアプログラミングの類似物をしたということです。それらの。 2 人のエンジニアが 1 台のコンピューター、1 台のキーボードの前に座り、サーバーのセットアップ、Ansible ロールの作成など、インフラストラクチャのセットアップを一緒に開始します。聞こえはいいですが、私たちにはうまくいきませんでした。しかし、この実践の特殊なケースでは機能しました。新しい従業員が来て、指導者が彼と一緒に実際の仕事に取り組み、働き、知識を伝えます。

もう 1 つの特殊なケースは、インシデント コールです。問題が発生すると、当直者と関係者のグループが集まり、リーダーが 1 人任命され、画面を共有して思考の流れを発言します。他の参加者はリーダーの考えに従い、コンソールからトリックを覗き見し、ログの一行を見逃していないか確認し、システムについて新しいことを学びます。このアプローチは多くの場合うまくいきました。

コードレビュー

主観的には、コード レビューを使用してインフラストラクチャとその仕組みに関する知識を広める方が効果的でした。

• インフラストラクチャはリポジトリ内のコードによって記述されます。
• 変更は別のブランチで発生します。
• マージ リクエスト中に、インフラストラクチャ内の変更の差分を確認できます。

ここでのハイライトは、レビュー担当者がスケジュールに従って 1 人ずつ選ばれたことです。ある程度の確率で、新しいインフラストラクチャに侵入することになります。

コードスタイル

時間が経つにつれて、レビュー中に口論が起こり始めました。レビュアーは独自のスタイルを持っており、レビュアーのローテーションにより、スペース 2 つまたは 4 つ、キャメルケースまたはスネークケースなど、さまざまなスタイルがスタックされました。これをすぐに実装することはできませんでした。

• 最初のアイデアは、リンターの使用を推奨することでした。結局のところ、誰もがエンジニアであり、誰もが賢いのです。でもエディタやOSが違うと不便
• これは、問題のあるコミットごとに Slack に書き込み、リンター出力を添付するボットに進化しました。しかし、ほとんどの場合、もっと重要なことがあるため、コードは未修正のままでした。

グリーンビルドマスター

時間が経ち、特定のテストに合格しないコミットはマスターに許可されないという結論に達しました。出来上がり！私たちは、ソフトウェア開発で長年にわたって実践されてきた Green Build Master を発明しました。

• 開発は別のブランチで進行中です。
• このスレッドではテストが実行されています。
• テストが失敗すると、コードはマスターに取り込まれません。

この決断を下すのは非常に苦痛でした。なぜなら...多くの論争を引き起こしましたが、それだけの価値はありました、なぜなら...レビューでは、スタイルの違いなしに合併のリクエストが届くようになり、時間が経つにつれて、問題のある領域の数は減り始めました。

IaC テスト

スタイルのチェックに加えて、たとえば、インフラストラクチャが実際にデプロイできるかどうかをチェックするために、他のことを使用することもできます。または、インフラストラクチャの変更によって損失が発生しないことを確認します。なぜこれが必要なのでしょうか?この質問は複雑で哲学的なものです。Powershell 上に何らかの理由で境界条件をチェックしないオートスケーラーがあった => 必要以上の VM が作成された => クライアントが計画より多くの費用を費やした、というストーリーで答える方が良いでしょう。これはあまり好ましいことではありませんが、早い段階でこのエラーを検出する可能性は十分にあります。

なぜ複雑なインフラをさらに複雑にするのかと疑問に思う人もいるかもしれません。インフラストラクチャのテストは、コードの場合と同様、単純化ではなく、インフラストラクチャがどのように機能するかを知ることが目的です。

IaC テスト ピラミッド

IaC テスト: 静的解析

インフラストラクチャ全体を一度にデプロイして動作を確認すると、非常に時間がかかり、時間がかかることが判明する場合があります。したがって、基本はすぐに機能し、量が多く、原始的な部分を多くカバーするものでなければなりません。

バッシュは難しい

簡単な例を見てみましょう。現在のディレクトリ内のすべてのファイルを選択し、別の場所にコピーします。最初に思い浮かぶのは:

for i in * ; do 
    cp $i /some/path/$i.bak
done

ファイル名にスペースが含まれている場合はどうなりますか?そうですね、私たちは賢いので、引用符の使い方を知っています。

for i in * ; do cp "$i" "/some/path/$i.bak" ; done

よくやった？いいえ！ディレクトリに何もない場合はどうなるでしょうか。グロビングは機能しません。

find . -type f -exec mv -v {} dst/{}.bak ;

さて、うまくいきましたか？いいえ... ファイル名に何が含まれるかを忘れました n.

touch x
mv x  "$(printf "foonbar")"
find . -type f -print0 | xargs -0 mv -t /path/to/target-dir

静的解析ツール

前のステップの問題は、引用符を忘れたときに見つかる可能性があります。これには自然界で多くの救済策があります。 シェルチェック一般に、それらはたくさんあり、おそらく IDE の下にスタックのリンターが見つかります。

言語設定
ツール

bash
シェルチェック

ルビー
ルボコップ

パイソン
ピリント

アンシブル
Ansible lint

IaC テスト: 単体テスト

前の例で見たように、リンターは全能ではなく、すべての問題領域を指摘することはできません。さらに、ソフトウェア開発におけるテストと類似して、単体テストを思い出すことができます。すぐに思い浮かぶのは、 シュニット, ジュニ, スペック, パイテスト。しかし、ansible、chef、saltstack、その他の同様のものはどうすればよいでしょうか?

一番最初に話したのは、 固体。 そして私たちのインフラは小さなレンガで構成されるべきだと。彼らの時代が来ました。

1. インフラストラクチャは、Ansible ロールなどの小さなブロックに分割されます。
2. Docker または VM など、何らかの環境がデプロイされます。
3. Ansible ロールをこのテスト環境に適用します。
4. すべてが期待どおりに機能することを確認します (テストを実行します)。
5. OKかNGかを決めるのは私たちです。

IaC テスト: 単体テスト ツール

CFM のテストとは何ですか?単純にスクリプトを実行することも、既製のソリューションを使用することもできます。

CFM
ツール

Ansible
テストインフラ

シェフ
インスペック

シェフ
サーバースペック

塩の山
ゴス

testinfra の例、ユーザーが test1, test2 存在し、グループに属している sshusers:

def test_default_users(host):
    users = ['test1', 'test2' ]
    for login in users:
        assert host.user(login).exists
        assert 'sshusers' in host.user(login).groups

何を選ぶべきですか?質問は複雑かつ曖昧です。2018 年から 2019 年にかけての Github 上のプロジェクトの変更の例を次に示します。

IaC テスト フレームワーク

問題は、どのようにしてすべてをまとめて立ち上げるかということです。できる それを受け取って自分でやってみよう エンジニアの数が十分であれば。または、それほど多くはありませんが、既製のソリューションを使用することもできます。

CFM
ツール

Ansible
分子

シェフ
テストキッチン

テラフォーム
テラテスト

2018 年から 2019 年にかけての Github 上のプロジェクトの変更の例:

分子 vs.テストキッチン

当初私たちは テストキッチンを使ってみた:

1. VM を並行して作成します。
2. Ansible ロールを適用します。
3. 検査を実行します。

25〜35の役割の場合、作業時間は40〜70分と長かったです。

次のステップは、jenkins/docker/ansible/molecule への移行でした。思想的にはすべて同じだ

1. リントのプレイブック。
2. 役割を並べます。
3. コンテナを起動する
4. Ansible ロールを適用します。
5. testinfra を実行します。
6. べき等性をチェックします。

40 のロールのリンティングと 15 のロールのテストには約 XNUMX 分かかり始めました。

何を選択するかは、使用するスタック、チームの専門知識など、多くの要因によって異なります。ここでは、単体テストの質問をどのように解決するかを誰もが自分で決定します。

IaC テスト: 統合テスト

インフラストラクチャ テスト ピラミッドの次のステップは、統合テストです。これらは単体テストに似ています。

1. インフラストラクチャは、Ansible ロールなどの小さなブロックに分割されます。
2. Docker または VM など、何らかの環境がデプロイされます。
3. このテスト環境には適用されます 多くの Ansible の役割。
4. すべてが期待どおりに機能することを確認します (テストを実行します)。
5. OKかNGかを決めるのは私たちです。

大まかに言えば、単体テストのようにシステムの個々の要素のパフォーマンスをチェックするのではなく、サーバー全体がどのように構成されているかをチェックします。

IaC テスト: エンドツーエンドのテスト

ピラミッドの頂点では、エンドツーエンドのテストが迎えられます。それらの。当社では、インフラストラクチャの別個のサーバー、別個のスクリプト、または別個のブリックのパフォーマンスをチェックしません。多くのサーバーが相互に接続されており、インフラストラクチャが期待どおりに機能していることを確認します。残念ながら、私は既製の箱入りソリューションを見たことがありません。おそらく次の理由が考えられます。多くの場合、インフラストラクチャは独特であり、テスト用のフレームワークをテンプレート化して作成するのが困難です。その結果、誰もが独自のソリューションを作成します。需要はありますが、答えはありません。したがって、他の人に健全な考えを押し付けたり、すべてのものは私たちよりもずっと前に発明されたという事実に鼻を刺すために何があるかを説明します。

豊かな歴史を持つプロジェクト。これは大規模な組織で使用されており、おそらく皆さんも間接的にこれに触れたことがあるでしょう。このアプリケーションは、多くのデータベース、統合などをサポートしています。インフラストラクチャがどのようなものかを知るには多くの docker-compose ファイルが必要で、どの環境でどのテストを実行するかを知るには Jenkins が必要です。

この計画は、枠組み内に収まるまで、かなり長い間機能しました。 研究 これを Openshift に転送することは試みていません。コンテナは同じままですが、起動環境が変更されました (こんにちは、D.R.Y. です)。

研究のアイデアはさらに進んで、openshift で APB (Ansible Playbook Bundle) のようなものを発見しました。これにより、インフラストラクチャをコンテナにデプロイする方法に関する知識を詰め込むことができます。それらの。インフラストラクチャの展開方法については、再現可能でテスト可能な知識点があります。

異種インフラストラクチャに遭遇するまでは、これはすべて良いように思えました。テストには Windows が必要でした。その結果、何を、どこに、どのようにデプロイし、テストするかについての知識がジェンキンスにあります。

まとめ

コードとしてのインフラストラクチャとは

• リポジトリ内のコード。
• 人的交流。
• インフラストラクチャのテスト。

リンク

• 英語版
• 個人ブログからのクロスポスト
• 予行演習 2019-04-24 SpbLUG
• DevopsConf 2019-05-28 のビデオ(RU)
• DINS DevOps EVENING 2019-06-20 のビデオ(RU)
• 300,000 行を超えるインフラストラクチャ コードの作成から学んだ教訓 & テキスト版
• コードとしてのインフラストラクチャを継続的デリバリー パイプラインに統合する
• インフラストラクチャをコードとしてテストする
• Ansible ロールの効果的な開発と保守
• Ansible は bash ではありません!

出所： habr.com