GitLab CI/CD 、tox、 Molecule でCisco ACIのAnsibleコードをテストする

　ネットワンでは公式GitLabを用意して、会社で生み出されたコードを蓄積しお客さまや業務改善に再利用する取り組みを行っています。 再利用できるコードは汎化され公式コードとして登録されています。 公式コードには、常に正しく動くことを保証するためテストコードも準備されており、安心してコードを利用できる状態にしています。
　このブログでは、Cisco ACIのアンダーレイのPhysical Domainを作成するRoleを例にとりテスト手法をご紹介していきます。テスト中心の内容となっておりRoleの中身については詳しくは紹介していません。

ディレクトリ構成

.　
├── defaults
│ └── main.yml
├── molecule
│ └── default
│ ├── cleanup.yml
│ ├── converge.yml
│ ├── inventory
│ │ └── hosts.yml
│ ├── molecule.yml
│ ├── pki
│ │ └── admin_ansible.key
│ └── verify.yml
├── README.md
├── requirements.txt
├── requirements.yml
├── tasks
│ ├── main.yml
│ ├── setup_access_port_policy_group.yml
│ ├── setup_aep_with_physical_domain.yml
│ ├── setup_interface_profile.yml
│ └── setup_switch_profile.yml
└── tox.ini

動作環境

Molecule 3.5.1

Tox 3.24.4

MoleculeでCisco ACIのRoleをテストする

　実際にAnsibleを使って自動化を進めていく場合、単一Playbookで作成していくと運用管理の煩雑化・肥大化や可読性が悪くなるため、Ansibleの実運用ではPlaybookを各々の役割に分割しRole化することがベストプラクティスとなっています。

　Ansible Role Test支援ツールのMoleculeを使うことで、テストを実行するための段取りとテストを効率よく実施することができます。

<テストの段取り>

1. テスト環境の構築

2. 設定投入

3. テスト実行

書き方の正しさテスト（統一された書き方か、構文エラーはないか）

動作の正しさテスト（Roleの実行、意図した通りに動作するか）

結果の正しさテスト（意図した通りの状態か、複数回実行しても同じ結果か）

４．テスト環境のクリーンアップ

　ではインストールしていきます。ここでは、Moleculeの後に紹介するAnsibleの複数のバージョンをテストするためのtox、書き方の正しさをテストするlint、ACIへの接続に必要なPython Packages(pyopensslなど)も合わせてインストールするためのファイルを用意してインストールしておきます。

requirements.txt

molecule[lint]
ansible-lint
ansible
pyopenssl
tox

インストール

pip install -r requirements.txt

テストで必要なファイルを自動生成するために、Roleに以下のコマンドを実行します。

molecule init scenario -r [role名]

コマンドを実行すると、moleculeディレクトリの配下に今回利用するファイルが以下の通り作成されますので、修正して利用します。
・molecule.yml : moleculeの設定ファイルです。
・converge.yml : テストで実行されるPlaybookです。
・verify.yml : converge.ymlを実行した後に意図した通りの結果になっているか確認する時に実行されるPlaybookです。
・cleanup.yml: converge.ymlを実行した後に設定を削除するPlaybookです。

molecule.yml

---
dependency:
  name: galaxy
  options:
    requirements-file: requirements.yml
lint: |
  set -e
  ansible-lint -vv .
driver:
  name: delegated
platforms:
  - name: apic1
provisioner:
  name: ansible
  inventory:
    links:
      hosts: "./inventory/hosts.yml"
verifier:
  name: ansible

定義名	説明
dependency	Roleをテストする時にRoleを実行する時の依存関係を処理します。本Roleでは cisco.aci コレクションが含まれるrequirements.ymlをインストールします。
lint	lintテストで使用するコマンド(ツール)を指定します。
driver	テスト用の環境を構築するドライバを指定します コンテナを利用する場合は、docker等を指定しますが、本Roleでは外部に用意されているテスト環境を使う（ACI環境）ため、delegatedを指定します。
platforms	テスト用の環境の設定をします。
provisioner	環境のプロビジョニング処理をします。 ACIに接続するインベントリ情報をhosts.ymlに記載します。
verifier	Roleを実行した後に意図した結果となっているかを確認する処理をします。

converge.yml

---
- name: Converge
  hosts: all
  connection: local
  gather_facts: no
  tasks:
    - name: Include setup_access_policy_with_physical_domain
      include_role:
        name: setup_access_policy_with_phisical_domain

requirements.yml

---
collections:
  - cisco.aci

hosts.yml

all:
  children:
    apic:
      hosts:
        apic1:
          ansible_host: 10.xx.xx.xx

　verify.yml　では、特定の設定が正しく入っているかクエリを使い確認しています。

　Roleディレクトリ配下で、molecule test　コマンドを実行し正しくテストが通ることを確認してください。

　ここまでで、書き方の正しさテスト、動作の正しさテスト、結果の正しさテストを確認できました。ここからは複数のAnsibleバージョンでも同じ動作が可能かをテストしていきます。

toxでCisco ACIのMolecule Roleをテストする

　toxはPython コードの virtualenv 管理・テスト支援ツールです。 tox は設定ファイル (tox.ini)に従い複数の異なる Python や Library 環境 (virtualenv 環境) の作成〜環境内へのパッケージインストール〜環境内でのテスト実行を自動的に行うことが可能です。

　本Roleでは、ptyhon36の環境に、Ansible2.9と2.10の両方のバージョンでテストを実施しています。

tox.ini

[tox]
envlist = py{36}-ansible{209,210}
    # py36, py37, py38
skipsdist = true
[testenv]
deps =
    -r {toxinidir}/requirements.txt
    ansible209: ansible==2.9.21rc1
    ansible210: ansible==2.10.6
setenv =
    PATH = {toxworkdir}/bin{:}{env:PATH}
commands =
    molecule test

toxのグローバル設定を行う[tox]セクションと、テスト環境の設定を行う[testenv]セクションの2つのセクションを定義しています。

セクション	定義名	説明
tox	envlist	テストする環境をリスト
testenv	deps	テスト実行前にインストールしておきたい依存関係のPythonパッケージ
	commands	テストとして実行するコマンド

　Roleディレクトリ配下で、toxコマンドを実行し正しくテストが通ることを確認してください。

GitLab CI/CDで toxをテストする

　最後にGitLab上でtoxを実行します。コード変更があった場合にそのコードが正しいかどうかを常にテストできるようにしておきます。

　GitLab において CI/CD を実現するには GitLab Runner と呼ばれるエージェントプログラムを準備する必要があります。CI/CD の処理においては GitLab Runner は定期的に GitLab Server に問い合わせを実施し必要に応じ対象コードの Fetch, 定義されたジョブの実行を行いその実行結果を GitLab Server に返すことでユーザーは GitLab Server の提供する Web UI 上でジョブの実行状態や結果を確認することができます。

　GitLab ではデフォルトで .gitlab-ci.yml と呼ばれる YAML ファイルにパイプラインの処理内容を記述、リポジトリ内に配置することで自動的に Runner によるジョブ処理が実行されます。

gitlab-ci.yml

---
image: test/ci_demo:latest
stages:
  - phisical_domain
lint_role_verify:
  tags:
    - molecule
  stage: phisical_domain
  before_script:
    - pip install tox
  script:
    - echo "$ACI_ACCESS_KEY" > molecule/default/pki/admin_ansible.key
    - tox
  allow_failure: false

定義名	説明
image	パイプライン全体でジョブ実行を行うコンテナイメージ
stages	ジョブ実行の順番や依存関係を定義する ステージ を定義しています。
lint_role_verify （Job定義）	lint_role_verifyでは実際に実行するジョブを定義しています。lint_role_verifyという名称は任意のジョブ名を指定することが可能です。
stage	対象ジョブのステージを定義しています。複数のジョブで同一のステージを指定した場合それらのジョブが平行実行されます。
before_script	コードをfetchしてくる前に実行したい処理を記載します。
script	実際の処理の内容を記述します。本Roleではtoxの実行と、ACIにアクセスするための秘密鍵の呼び出しと書き込みを行っています。公式化された不特定多数がアクセスするGitlab上に鍵を公開することはできないため、GitLabでは事前に環境変数として秘密鍵を登録しておきCI/CD実行時に呼び出すことができます。

実行結果ログ

テストパスしたRoleの表示

　テストパスした結果はRoleのプロジェクトページのホーム（赤部分）に表示され、コードを使ってみようと考える人は安心して使う事ができるようになっています。

まとめ

　ご紹介したとおりネットワンでは、AnsibleのRoleをmoleculeでテスト後、toxで複数バージョンのAnsibleをテストし、最終的にGitLab上でコード変更があった場合に即座にテストできるようにしています。

　こうして安心していつでも使える公式化コードを増やし、IaCを加速させていきます。

※本記事の内容は執筆者個人の見解であり、所属する組織の見解を代表するものではありません。