Ansible の変数に対するシステム アプローチ

ansible devops コードスタイル

おい！ 私の名前は デニス・カリュジニー 私は開発プロセス自動化部門でエンジニアとして働いています。 毎日、新しいアプリケーション ビルドが数百のキャンペーン サーバーに展開されます。 この記事では、これらの目的で Ansible を使用した私の経験を共有します。

このガイドでは、デプロイメント時に変数を整理する方法を提供します。 このガイドは、Playbook でロールをすでに使用しており、既読のユーザーを対象としています。 ベストプラクティスですが、同様の問題に直面しています。

• コード内で変数を見つけても、それが何を担当しているのかをすぐに理解することは不可能です。
• いくつかの役割があり、変数を XNUMX つの値に関連付ける必要がありますが、それは機能しません。
• Playbook 内の変数のロジックがどのように機能するかを他の人に説明するのが難しい

私たちは社内のプロジェクトでこれらの問題に遭遇しました。その結果、プレイブック内の変数を設計するためのルールに到達し、これらの問題をある程度解決しました。

役割の変数

ロールは、展開システムの別個のオブジェクトです。 他のシステム オブジェクトと同様に、システムの他の部分と対話するためのインターフェイスが必要です。 このようなインターフェイスはロール変数です。

役割を例に考えてみましょう api、サーバーに Java アプリケーションをインストールします。 どのような変数があるでしょうか?

可変ロールはタイプに応じて 2 つのタイプに分類できます。

1. Свойства
    a) независимые от среды
    б) зависимые от среды
2. Связи
    a) слушатели 
    б) запросы внутри системы
    в) запросы в среду

変数のプロパティ は、ロールの動作を決定する変数です。

クエリ変数 - これらは、ロールの外部のリソースを指定するために値が使用される変数です。

変数リスナー - これらは、リクエスト変数を形成するために値が使用される変数です。

一方、1a、2a、2bは環境（ハードウェア、外部リソースなど）に依存しない変数であり、defaultsロールでデフォルト値を入れることができます。 ただし、タイプ 1.b および 2.c の変数には、環境に応じて変化するため、'example' 以外の値を入れることはできません。

コードスタイル

• 変数名はロール名で始まる必要があります。 これにより、将来、その変数がどのような役割を果たし、何を担当するのかを簡単に把握できるようになります。
• ロールで変数を使用する場合は、必ずカプセル化の原則に従い、ロール自体または現在のロールが依存するロールで定義された変数を使用する必要があります。

• 変数に辞書を使用することは避けてください。 Ansible では、辞書内の個々の値を簡単にオーバーライドすることはできません。

  悪い変数の例:

  myrole_user:
      login: admin
      password: admin

  ここで、ログインは独立変数、パスワードは従属変数です。 しかし
  これらは辞書に結合されているため、完全に指定する必要があります。
  いつも。 それはとても不便です。 この方法の方が良いです:

  myrole_user_login: admin
  myrole_user_password: admin

デプロイメント プレイブックの変数

デプロイメント プレイブック (以下、プレイブックと呼びます) をコンパイルするときは、別のリポジトリに配置するというルールに従います。 ロールと同じです。それぞれが独自の Git リポジトリ内にあります。 これにより、ロールとプレイブックはデプロイメント システムの異なる独立したオブジェクトであり、一方のオブジェクトの変更が他方のオブジェクトの動作に影響を与えるべきではないことが理解できます。 これは、変数のデフォルト値を変更することで実現されます。

要約すると、Playbook をコンパイルするときに、Playbook 変数とインベントリー変数の XNUMX つの場所でロール変数のデフォルト値をオーバーライドすることができます。

mydeploy                        # Каталог деплоя
├── deploy.yml                  # Плейбук деплоя
├── group_vars                  # Каталог переменных плейбука
│   ├── all.yml                 # Файл для переменных связи всей системы
│   └── myapi.yml               # Файл переменных свойств группы myapi
└── inventories                 #
    └── prod                    # Каталог окружения prod
        ├── prod.ini            # Инвентори файл
        └── group_vars          # Каталог для переменных инвентори
            └── myapi           #
                ├── vars.yml    # Средозависимые переменные группы myapi
                └── vault.yml   # Секреты (всегда средозависимы) *

* — 変数とボールト

違いは、同じレベルにある Playbook を呼び出すときに Playbook 変数が常に使用されることです。 これは、これらの変数が環境に依存しない変数のデフォルト値を変更するのに最適であることを意味します。 逆に、インベントリ変数は特定の環境でのみ使用されるため、環境固有の変数としては理想的です。

変数の優先度では、最初にプレイブック変数で変数をオーバーライドし、次に XNUMX つのインベントリーで個別に変数をオーバーライドすることはできないことに注意することが重要です。

これは、この段階で、変数が環境に依存するかどうかを判断し、適切な場所に配置する必要があることを意味します。

たとえば、あるプロジェクトでは、SSL を有効にする変数は長い間環境に依存していました。これは、スタンドの XNUMX つで制御できない理由により SSL を有効にすることができなかったためです。 この問題を修正した後、環境に依存せず、Playbook 変数に移行しました。

グループのプロパティ変数

異なる Java アプリケーションを持つ、ただし設定が異なる 1 つのサーバー グループを追加して、図 2 のモデルを拡張してみましょう。

この場合、プレイブックがどのようになるかを想像してみましょう。

- hosts: myapi
  roles:
    - api

- hosts: bbauth
  roles:
    - auth

- hosts: ghauth
  roles:
    - auth

Playbook には XNUMX つのグループがあるため、group_vars インベントリ変数と Playbook 変数に同じ数のグループ ファイルを作成することをすぐにお勧めします。 この場合の XNUMX つのグループ ファイルは、Playbook 内の上記のアプリケーションの XNUMX つのコンポーネントの記述です。 プレイブック変数でグループ ファイルを開くと、グループにインストールされているロールのデフォルトの動作との違いがすべてすぐにわかります。 在庫変数: スタンド間のグループ行動の違い。

コードスタイル

• host_vars 変数はシステムを説明するものではなく、将来的に「このホストは他のホストと異なるのはなぜですか?」という疑問につながる特殊なケースにすぎないため、まったく使用しないようにしてください。その答えは明確ではありません。いつでも簡単に見つかります。

通信変数

しかし、それがプロパティ変数の本質ですが、通信変数についてはどうなのでしょうか?
それらの違いは、異なるグループでも同じ意味を持つ必要があるということです。

最初はそうでした アイデア 次のような巨大な構造を使用します。
hostvars[groups['bbauth'][0]]['auth_bind_port']、しかし、彼らはすぐにそれを拒否しました
デメリットがあるからです。 まず嵩高さ。 XNUMX 番目は、グループ内の特定のホストへの依存です。 第三に、未定義の変数のエラーが発生したくない場合は、デプロイメントを開始する前にすべてのホストからファクトを収集する必要があります。

その結果、通信変数を使用することになりました。

通信変数 - これらは Playbook に属する変数であり、システム オブジェクトを接続するために必要です。

通信変数は一般的なシステム変数に入力されます group_vars/all/vars これらは、各グループからすべてのリスナー変数を削除し、リスナーが削除されたグループの名前を変数の先頭に追加することによって形成されます。

これにより、名前の均一性と重複がないことが保証されます。

上記の例の変数をバインドしてみましょう。

相互に依存する変数があると想像してみましょう。

# roles/api/defaults:
# Переменная запроса
api_auth1_address: "http://example.com:80"
api_auth2_address: "http://example2.com:80"

# roles/auth/defaults:
# Переменная слушатель
auth_bind_port: "20000"

共通変数に入れてみましょう group_vars/all/vars すべてのリスナーを対象にし、タイトルにグループ名を追加します。

# group_vars/all/vars
bbauth_auth_bind_port: "20000"
ghauth_auth_bind_port: "30000"

# group_vars/bbauth/vars
auth_bind_port: "{{ bbauth_auth_bind_port }}"

# group_vars/ghauth/vars
auth_bind_port: "{{ ghauth_auth_bind_port }}"

# group_vars/myapi/vars
api_auth1_address: "http://{{ bbauth_auth_service_name }}:{{ bbauth_auth_bind_port }}"
api_auth2_address: "http://{{ ghauth_auth_service_name }}:{{ ghauth_auth_bind_port }}"

ここで、コネクタの値を変更することで、ポートが配置されているのと同じ場所にリクエストが確実に送信されるようになります。

コードスタイル

• ロールとグループは異なるシステム オブジェクトであるため、異なる名前を付ける必要があります。そうすれば、リンク変数は、それらがシステム内のロールではなく、サーバーの特定のグループに属していることを正確に示します。

環境依存ファイル

ロールは環境ごとに異なるファイルを使用する場合があります。

このようなファイルの例としては、SSL 証明書があります。 テキスト形式で保存する
変数に入れるのはあまり便利ではありません。 ただし、それらへのパスを変数内に保存すると便利です。

たとえば、変数を使用します api_ssl_key_file: "/path/to/file".

キー証明書が環境ごとに異なることは明らかであるため、これは環境依存の変数であり、ファイル内に配置する必要があることを意味します。
group_vars/myapi/vars 変数のインベントリであり、値「たとえば」が含まれます。

この場合の最も便利な方法は、キー ファイルをパスに沿って Playbook リポジトリに置くことです。
files/prod/certs/myapi.keyの場合、変数の値は次のようになります。
api_ssl_key_file: "prod/certs/myapi.key"。 この利便性は、特定のスタンドでのシステムの展開を担当する担当者がファイルを保存するための専用スペースをリポジトリ内に持っているという事実にあります。 同時に、証明書が別のシステムによって提供される場合に備えて、サーバー上の証明書への絶対パスを指定することも可能です。

XNUMX つの環境に複数のスタンド

多くの場合、差異を最小限に抑えた、ほぼ同一の複数のスタンドを同じ環境に導入する必要があります。 この場合、環境依存変数を、その環境内で変化しない変数と変化する変数に分けます。 そして、後者をインベントリ ファイル自体に直接転送します。 この操作の後、環境ディレクトリに別のインベントリを直接作成できるようになります。

group_vars インベントリーを再利用し、いくつかの変数をそれ自体のために直接再定義することもできます。

デプロイメント プロジェクトの最終的なディレクトリ構造は次のとおりです。

mydeploy                        # Каталог деплоя
├── deploy.yml                  # Плейбук деплоя
├── files                       # Каталог для файлов деплоя
│   ├── prod                    # Католог для средозависимых файлов стенда prod
│   │   └── certs               # 
│   │       └── myapi.key       #
│   └── test1                   # Каталог для средозависимых файлов стенда test1
├── group_vars                  # Каталог переменных плейбука
│   ├── all.yml                 # Файл для переменных связи всей системы
│   ├── myapi.yml               # Файл переменных свойств группы myapi
│   ├── bbauth.yml              # 
│   └── ghauth.yml              #
└── inventories                 #
    ├── prod                    # Каталог окружения prod
    │   ├── group_vars          # Каталог для переменных инвентори
    │   │   ├── myapi           #
    │   │   │   ├── vars.yml    # Средозависимые переменные группы myapi
    │   │   │   └── vault.yml   # Секреты (всегда средозависимы)
    │   │   ├── bbauth          # 
    │   │   │   ├── vars.yml    #
    │   │   │   └── vault.yml   #
    │   │   └── ghauth          #
    │   │       ├── vars.yml    #
    │   │       └── vault.yml   #
    │   └── prod.ini            # Инвентори стенда prod
    └── test                    # Каталог окружения test
        ├── group_vars          #
        │   ├── myapi           #
        │   │   ├── vars.yml    #
        │   │   └── vault.yml   #
        │   ├── bbauth          #
        │   │   ├── vars.yml    #
        │   │   └── vault.yml   #
        │   └── ghauth          #
        │       ├── vars.yml    #
        │       └── vault.yml   #
        ├── test1.ini           # Инвентори стенда test1 в среде test
        └── test2.ini           # Инвентори стенда test2 в среде test

まとめ

記事に従って変数を整理した後、各変数ファイルは特定のタスクを担当します。 また、ファイルには特定のタスクがあるため、各ファイルの正確さに対して責任を負う人を割り当てることが可能になりました。 たとえば、システム展開の開発者は、プレイブック変数を正しく入力する責任を負いますが、スタンドがインベントリに記述されている管理者は、変数のインベントリを埋めることに直接責任を負います。

ロールは独自のインターフェイスを備えた独自の開発単位となり、ロール開発者はロールをシステムに合わせて調整するのではなく、機能を開発できるようになりました。 この問題は、キャンペーン内のすべてのシステムの共通の役割に特に関係がありました。

システム管理者は、展開コードを理解する必要がなくなりました。 デプロイメントを成功させるために必要なのは、環境依存変数のファイルを埋めることだけです。

文学

1. Документация

著者

カリュジニ・デニス・アレクサンドロヴィッチ

出所： habr.com