Ansible のテストを開始し、XNUMX 年以内にプロジェクトをリファクタリングし、混乱しないようにする方法

これは転写です 公演 на DevOps-40 2020-03-18:

XNUMX 番目のコミット以降、コードはすべてレガシーになります。 最初のアイデアは厳しい現実から乖離し始めます。 これは良いことでも悪いことでもありません。これは当然のことであり、議論するのは難しく、受け入れなければなりません。 このプロセスの一部はリファクタリングです。 コードとしてのインフラストラクチャのリファクタリング。 狂わずに XNUMX 年以内に Ansible をリファクタリングする方法について話を始めましょう。

レガシーの誕生

1 日目: 患者ゼロ

かつて、条件付きプロジェクトがありました。 そこには開発開発チームと運用エンジニアがいました。 彼らは同じ問題、つまりサーバーをデプロイしてアプリケーションを実行する方法を解決していました。 問題は、各チームが独自の方法でこの問題を解決したことです。 プロジェクトでは、開発チームと運用チームの間で知識を同期するために Ansible を使用することが決定されました。

Day #89: レガシーの誕生

自分たちでも気づかずに、できる限り最善を尽くしたかったのですが、それがレガシーになってしまったのです。 これはどうして起こるのでしょうか?

• ここには緊急のタスクがあるので、汚いハックを行ってから修正しましょう。
• ドキュメントを書く必要はなく、ここで何が起こっているかはすべて明らかです。
• Ansible/Python/Bash/Terraform を知っています。 どうやって回避できるか見てください！
• 私はフルスタックオーバーフロー開発者で、これを stackoverflow からコピーしました。どのように機能するかはわかりませんが、見た目はクールで、問題は解決します。

その結果、ドキュメントがなく、それが何をするのか、必要なのかも明確ではない、理解できない種類のコードが得られる可能性がありますが、問題は、コードを開発し、変更し、松葉杖やサポートを追加する必要があることです。 、状況はさらに悪化します。

- hosts: localhost
  tasks:
    - shell: echo -n Z >> a.txt && cat a.txt
      register: output
      delay: 1
      retries: 5
      until: not output.stdout.find("ZZZ")

Day #109: 問題の認識

最初に考案され実装された IaC モデルは、ユーザー、ビジネス、その他のチームの要件を満たさなくなり、インフラストラクチャに変更を加える時間が許容できなくなります。 この瞬間、行動を起こす時が来たと理解します。

IaCリファクタリング

Day #139: リファクタリングは本当に必要ですか?

急いでリファクタリングを始める前に、次のようないくつかの重要な質問に答える必要があります。

1. なぜこれすべてが必要なのでしょうか?
2. あなたは時間がありますか？
3. 知識は十分ですか？

質問にどう答えるかがわからないと、リファクタリングが開始される前に終了してしまうか、リファクタリングがさらに悪化する可能性があります。 なぜなら経験がありました( 200 行のインフラストラクチャ コードのテストから学んだこと)、その後、プロジェクトはロールを修正してテストでカバーするための支援のリクエストを受け取りました。

Day #149: リファクタリングの準備

まずは準備です。 何をするかを決めてください。 そのために、私たちはコミュニケーションをとり、問題領域を見つけ、それらを解決する方法を考え出します。 結果として得られたコンセプトを、たとえば confluence の記事など、何らかの方法で記録して、「何が最善か?」という質問が生じたときにすぐに使えるようにします。 または「どちらが正しいですか?」 私たちは道に迷ったわけではありません。 私たちの場合は、このアイデアにこだわりました 分裂とルール: インフラストラクチャを小さな部分/ブロックに分割します。 このアプローチにより、インフラストラクチャの分離された部分を取得し、その動作を理解し、テストでカバーし、何かを壊すことを恐れることなく変更することができます。

インフラストラクチャ テストが基礎となることがわかり、ここでインフラストラクチャ テスト ピラミッドについて言及する価値があります。 開発中のアイデアとまったく同じですが、インフラストラクチャに関するものです。インデントなどの単純なものをチェックする安価な簡単なテストから、インフラストラクチャ全体をデプロイする高価な本格的なテストに移行しています。

Ansible テストの試み

プロジェクトで Ansible テストをどのようにカバーしたかを説明する前に、決定のコンテキストを理解するために以前に使用する機会があった試みとアプローチについて説明します。

Day No. -997: SDS の提供

私が初めて Ansible をテストしたのは、SDS (Software Defined Storage) を開発するプロジェクトでした。 このトピックに関する別の記事があります
ディストリビューションをテストするときに松葉杖の上で自転車を壊す方法, しかし、要するに、逆のテストピラミッドになり、テストには 60 つのロールに 90 ～ 2 分と長い時間がかかりました。 基礎となったのは eXNUMXe テスト、つまり本格的なインストールを展開してテストしました。 さらに腹立たしいのは、彼自身の自転車の発明でした。 しかし、このソリューションは機能し、安定したリリースが可能になったことは認めざるを得ません。

Day # -701: Ansible とテスト キッチン

Ansible テストのアイデアの開発は、既製のツール、つまり test Kitchen / Kitchen-ci および inspec の使用でした。 選択は Ruby の知識によって決まりました (詳細については、Habré に関する記事を参照してください: YML プログラマーは Ansible をテストすることを夢見ていますか?) 作業は速くなり、40 ロールで約 10 分でした。 私たちは仮想マシンのパックを作成し、その中でテストを実行しました。

一般に、この溶液は機能しましたが、不均一性によりいくらかの沈殿物が発生しました。 テストする人の数を 13 人の基本的な役割と、より小さな役割を組み合わせた 2 つのメタ的な役割に増やすと、突然テストがほぼ 70 倍の 2 分間実行され始めました。 XP (エクストリーム プログラミング) の実践について話すのは困難でした。なぜなら... 70分も待ちたくない人はいないでしょう。 これがアプローチを変更した理由でした

Day # -601: Ansible と分子

概念的には、これは testkitchen に似ていますが、ロールのテストを docker に移動し、スタックを変更しただけです。 その結果、時間は20役で安定した25～7分に短縮されました。

テストされるロールの数を 17 に増やし、45 のロールをリンティングすることにより、28 つの Jenkins スレーブでこれを 2 分で実行しました。

Day #167: Ansible テストをプロジェクトに追加する

おそらく、急いでリファクタリングタスクを実行することは不可能でしょう。 この作業は、象を細かく砕いてティースプーンで少しずつ食べることができるように測定可能でなければなりません。 自分が正しい方向に進んでいるのか、いつまで進むべきなのかを理解する必要があります。

一般に、どのように行うかは関係ありません。紙に書いてもいいし、クローゼットにステッカーを貼ってもいいし、Jira でタスクを作成してもいいし、Google ドキュメントを開いて現在のステータスを書き留めてもいいです。そこには。 足は、プロセスがすぐにではなく、長くて退屈になるという事実から成長します。 リファクタリング中にアイデアが燃え尽きたり、疲れたり、圧倒されたりすることを誰も望んでいないでしょう。

リファクタリングは簡単です。

• 食べる。
• 睡眠。
• コード。
• IaCテスト。
• 繰り返す

意図した目標に到達するまでこれを繰り返します。

すぐにすべてのテストを開始することは不可能かもしれないため、最初のタスクは lint の実行と構文のチェックから始めることでした。

Day #181: グリーンビルドマスター

リンティングは、Green Build Master への小さな第一歩です。 これにより、ほとんど何も壊れることはありませんが、プロセスをデバッグし、Jenkins でグリーン ビルドを作成できるようになります。 アイデアは、チーム内で習慣を身につけることです。

• 赤テストはダメですよ。
• 私は何かを修正すると同時に、コードを以前よりも少し良くするために来ました。

Day #193: lint から単体テストまで

コードをマスターに取り込むプロセスを構築したら、段階的な改善のプロセスを開始できます。lint をロールの起動に置き換え、冪等性なしで実行することもできます。 ロールを適用する方法とその仕組みを理解する必要があります。

Day #211: 単体テストから結合テストまで

ほとんどの役割が単体テストでカバーされ、すべてがリントされたら、統合テストの追加に進むことができます。 それらの。 インフラストラクチャ内の単一のブリックをテストするのではなく、それらの組み合わせ (たとえば、完全なインスタンス構成) をテストします。

jenkins を使用して、ロール/プレイブックを並行して lint する多くのステージを生成し、次にコンテナーでの単体テスト、最後に統合テストを生成しました。

Jenkins + Docker + Ansible = テスト

1. リポジトリをチェックアウトし、ビルド ステージを生成します。
2. lint プレイブック ステージを並行して実行します。
3. lint ロール ステージを並行して実行します。
4. 構文チェックのロールステージを並行して実行します。
5. テストロールステージを並行して実行します。
   1. リント役。
   2. 他のロールへの依存関係を確認します。
   3. 構文を確認してください。
   4. Dockerインスタンスを作成する
   5. 分子/default/playbook.yml を実行します。
   6. べき等性をチェックします。
6. 統合テストを実行する
7. 終了

Day #271: バスの要素

当初、リファクタリングは XNUMX ～ XNUMX 人の少人数のグループで行われました。 彼らはマスター内のコードをレビューしました。 時間の経過とともに、チームはコードの書き方とコード レビューに関する知識を深め、インフラストラクチャとその仕組みに関する知識の普及に貢献しました。 ここでのハイライトは、レビュー担当者がスケジュールに従って XNUMX 人ずつ選ばれたことです。 ある程度の確率で、新しいインフラストラクチャに侵入することになります。

そしてここは快適なはずだ。 レビューを行ったり、実行されたタスクの枠組みや議論の履歴を確認したりするのに便利です。 jenkins + bitbucket + jira を統合しました。

しかし、そのようなものとして、レビューは万能薬ではありません; どういうわけか、私たちはマスター コードに入り込んでしまい、テストが失敗してしまいました。

- get_url:
    url: "{{ actk_certs }}/{{ item.1 }}"
    dest: "{{ actk_src_tmp }}/"
    username: "{{ actk_mvn_user }}"
    password: "{{ actk_mvn_pass }}"
  with_subelements:
    - "{{ actk_cert_list }}"
    - "{{ actk_certs }}"
  delegate_to: localhost

- copy:
    src: "{{ actk_src_tmp }}/{{ item.1 }}"
    dest: "{{ actk_dst_tmp }}"
  with_subelements:
    - "{{ actk_cert_list }}"
    - "{{ actk_certs }}"

その後、修復しましたが、堆積物は残りました。

get_url:
    url: "{{ actk_certs }}/{{ actk_item }}"
    dest: "{{ actk_src_tmp }}/{{ actk_item }}"
    username: "{{ actk_mvn_user }}"
    password: "{{ actk_mvn_pass }}"
  loop_control:
    loop_var: actk_item
  with_items: "{{ actk_cert_list }}"
  delegate_to: localhost

- copy:
    src: "{{ actk_src_tmp }}/{{ actk_item }}"
    dest: "{{ actk_dst_tmp }}"
  loop_control:
    loop_var: actk_item
  with_items: "{{ actk_cert_list }}"

311 日目: テストの高速化

時間が経つにつれて、テストが増え、ビルドの実行が遅くなり、最悪の場合は XNUMX 時間までかかりました。 レトロの XNUMX つに、「テストがあるのは良いことですが、テストが遅いです。」というようなフレーズがありました。 その結果、仮想マシンでの統合テストを放棄し、それを Docker に適応させて高速化しました。 また、使用するツールの数を減らすために、testinfra を ansible Verifier に置き換えました。

厳密に言えば、次のような一連の対策がありました。

1. ドッカーに切り替えます。
2. 依存関係により重複しているロール テストを削除します。
3. スレーブの数を増やします。
4. テスト実行の順序。
5. 糸くずを出す能力 ALL XNUMX つのコマンドでローカルで実行できます。

これにより、jenkins上のPipelineも統一されました

1. ビルドステージを生成します。
2. リントをすべて並行して実行します。
3. テストロールステージを並行して実行します。
4. フィニッシュ。

教訓

グローバル変数を避ける

Ansible はグローバル変数を使用します。次の形式で部分的な回避策があります。 private_role_vars, しかし、これは万能薬ではありません。

例を挙げてみましょう。 いただきましょう role_a и role_b

# cat role_a/defaults/main.yml
---
msg: a

# cat role_a/tasks/main.yml
---
- debug:
    msg: role_a={{ msg }}

# cat role_b/defaults/main.yml
---
msg: b

# cat role_b/tasks/main.yml
---
- set_fact:
    msg: b
- debug:
    msg: role_b={{ msg }}

- hosts: localhost
  vars:
    msg: hello
  roles:
    - role: role_a
    - role: role_b
  tasks:
    - debug:
        msg: play={{msg}}

面白いのは、プレイブックの結果は、ロールがリストされている順序など、必ずしも明らかではないことに依存することです。 残念ながら、これは Ansible の性質であり、できる限り最善の方法は、たとえばロール内で、このロールに記述されている変数のみを使用するなど、何らかの合意を使用することです。

BAD: グローバル変数を使用します。

# cat roles/some_role/tasks/main.yml
---
debug:
  var: java_home

GOOD：V defaults 必要な変数を定義し、後でそれらのみを使用します。

# cat roles/some_role/defaults/main.yml
---
r__java_home:
 "{{ java_home | default('/path') }}"

# cat roles/some_role/tasks/main.yml
---
debug:
  var: r__java_home

プレフィックスロール変数

BAD: グローバル変数を使用します。

# cat roles/some_role/defaults/main.yml
---
db_port: 5432

GOOD: 変数のロールでは、ロール名を先頭に付けた変数を使用します。これにより、インベントリを確認することで、何が起こっているかを理解しやすくなります。

# cat roles/some_role/defaults/main.yml
---
some_role__db_port: 5432

ループ制御変数を使用する

BAD: ループ内で標準変数を使用します itemこのタスク/プレイブックがどこかに含まれている場合、予期しない動作が発生する可能性があります。

---
- hosts: localhost
  tasks:
    - debug:
        msg: "{{ item }}"
      loop:
        - item1
        - item2

GOOD: ループ内の変数を再定義します。 loop_var.

---
- hosts: localhost
  tasks:
    - debug:
        msg: "{{ item_name }}"
      loop:
        - item1
        - item2
      loop_control:
        loop_var: item_name

入力変数をチェックする

私たちは変数プレフィックスを使用することに同意しました。変数プレフィックスが期待どおりに定義されているか、たとえば空の値によってオーバーライドされていないかをチェックすることは不必要ではありません。

GOOD: 変数を確認します。

- name: "Verify that required string variables are defined"
  assert:
    that: ahs_var is defined and ahs_var | length > 0 and ahs_var != None
    fail_msg: "{{ ahs_var }} needs to be set for the role to work "
    success_msg: "Required variables {{ ahs_var }} is defined"
  loop_control:
    loop_var: ahs_var
  with_items:
    - ahs_item1
    - ahs_item2
    - ahs_item3

ハッシュ辞書を避け、フラット構造を使用する

ロールのパラメータの XNUMX つにハッシュ/辞書が必要な場合、子パラメータの XNUMX つを変更したい場合は、ハッシュ/辞書全体をオーバーライドする必要があり、構成が複雑になります。

BAD: ハッシュ/辞書を使用します。

---
user:
  name: admin
  group: admin

GOOD: フラットな変数構造を使用します。

---
user_name: admin
user_group: "{{ user_name }}"

冪等なプレイブックとロールを作成する

ロールとプレイブックは冪等である必要があります。 構成のずれや、何かが壊れるのではないかという不安が軽減されます。 ただし、分子を使用する場合、これがデフォルトの動作になります。

コマンドシェルモジュールの使用を避ける

シェル モジュールを使用すると、Ansible の核となる宣言型の記述パラダイムではなく、命令型の記述パラダイムが生成されます。

分子を介して役割をテストする

分子は非常に柔軟なものです。いくつかのシナリオを見てみましょう。

分子の複数のインスタンス

В molecule.yml セクションで platforms デプロイできる多くのホストを記述することができます。

---
    driver:
      name: docker
    platforms:
      - name: postgresql-instance
        hostname: postgresql-instance
        image: registry.example.com/postgres10:latest
        pre_build_image: true
        override_command: false
        network_mode: host
      - name: app-instance
        hostname: app-instance
        pre_build_image: true
        image: registry.example.com/docker_centos_ansible_tests
        network_mode: host

したがって、これらのホストは、 converge.yml 使用：

---
- name: Converge all
  hosts: all
  vars:
    ansible_user: root
  roles:
    - role: some_role

- name: Converge db
  hosts: db-instance
  roles:
    - role: some_db_role

- name: Converge app
  hosts: app-instance
  roles:
    - role: some_app_role

Ansible ベリファイアー

分子内では、ansible を使用してインスタンスが正しく構成されていることを確認できます。さらに、これはリリース 3 以降のデフォルトです。 testinfra/inspec ほど柔軟ではありませんが、ファイルの内容が期待どおりであることを確認できます。

---
- name: Verify
  hosts: all
  tasks:
    - name: copy config
      copy:
        src: expected_standalone.conf
        dest: /root/wildfly/bin/standalone.conf
        mode: "0644"
        owner: root
        group: root
      register: config_copy_result

    - name: Certify that standalone.conf changed
      assert:
        that: not config_copy_result.changed

または、サービスをデプロイし、利用可能になるのを待ってスモーク テストを実行します。

---
  - name: Verify
    hosts: solr
    tasks:
      - command: /blah/solr/bin/solr start -s /solr_home -p 8983 -force
      - uri:
          url: http://127.0.0.1:8983/solr
          method: GET
          status_code: 200
        register: uri_result
        until: uri_result is not failed
        retries: 12
        delay: 10
      - name: Post documents to solr
        command: /blah/solr/bin/post -c master /exampledocs/books.csv

複雑なロジックをモジュールとプラグインに組み込む

Ansible は宣言型アプローチを推奨しているため、コードの分岐、データ変換、シェル モジュールを実行すると、コードが読みにくくなります。 これに対処し、理解しやすさを維持するには、独自のモジュールを作成してこの複雑さに対処することは不必要ではありません。

ヒントとコツのまとめ

1. グローバル変数は避けてください。
2. ロール変数にプレフィックスを付けます。
3. ループ制御変数を使用します。
4. 入力変数を確認してください。
5. ハッシュ ディクショナリを避け、フラットな構造を使用します。
6. 冪等なプレイブックとロールを作成します。
7. コマンド シェル モジュールの使用は避けてください。
8. 分子を介して役割をテストします。
9. 複雑なロジックをモジュールとプラグインに組み込みます。

まとめ

IaC があるとしても、プロジェクトのインフラストラクチャをただリファクタリングすることはできません。 これは忍耐、時間、知識を必要とする長いプロセスです。

リンク

• スライド Ansible をテストして混乱しないようにする方法
• ビデオ Ansible をテストして混乱しないようにする方法
• 200 行のインフラストラクチャ コードのテストから学んだこと
• Ansible: 120 VM 構成を Coreos から Centos に 18 か月で移行
• ディストリビューションをテストするときに松葉杖の上で自転車を壊す方法
• できるかどうかテストしてください。それとも YML プログラマーは Ansible をテストすることを夢見ていますか?
• 素晴らしい IaC テストの記事、講演、リンクのリスト
• クロスポスト
• 英語版

UPD1 2020.05.01 20:30 — プレイブックの一次プロファイリングに使用できるもの callback_whitelist = profile_tasks 何が長期的に機能するのかを正確に理解するために。 次に、通過します Ansible アクセラレーションのクラシック。 試してみることもできます マイトジェン
UPD2 2020.05.03 16:34 - 英語版

出所： habr.com