AWS CodeBuildでAnsibleのCIをしてみた
こんにちは、NTTの山田です。NTT研究所ではクラウドサービスを活用して研究活動に役立てています。今回はそのうち、AWS CodeBuildを使ってAnsible PlaybookのCIができるようにした話を書きます。
Ansible Playbookのテスト
我々のチームでは社内の研究者向けに、GPUリソースを簡単に使うことができる環境を提供して深層学習などの研究に使ってもらっています。GPU環境の構築はOSインストール以降全てをAnsibleを用いてコード化しており、追加変更の際にはGitHubを使ってチーム内で相互レビューを実施しています。
しかし、Ansible Playbookはアプリケーションのコードとは異なり各自でテストすることが難しいという問題があります。テスト専用の環境をなんとか作れないかということで、まずは手軽に使えるクラウド上での環境整備をしてみることにしました。
テスト用のコンテナイメージ作成
目的がAnsible Playbookのテストであるため、OSインストール直後のまっさらな状態が再現できればOKとなります。CodeBuildには公式で用意されているイメージもありますが、Ubuntu 14.04がベースになっています。我々の使っている環境はUbuntu 16.04なので、カスタムDockerイメージを作成する必要がありました。Dockerイメージはaws-cliをセットアップし、公式マニュアル通りにAmazon ECRにpushしておけばCodeBuildから利用することができます。以下はpushのためのコマンド例です。
$ cmd=$(aws ecr get-login — no-include-email — region ap-northeast-1)
$ sudo $cmd
$ sudo docker tag ubuntu:xenial <AWSアカウントID>.dkr.ecr.ap-northeast-1.amazonaws.com/<リポジトリ名>:<tag>
$ sudo docker push <AWSアカウントID>.dkr.ecr.ap-northeast-1.amazonaws.com/<リポジトリ名>:<tag>
Build Specファイル作成
続いて、用意したコンテナイメージ上で実行したいテストをBuild SpecファイルというYAML形式で記述します。Build Specファイルはテスト対象のソースディレクトリのルートに配置します。Build Specファイルを作成する際には、次のようにローカルのDockerコンテナ内で動作確認をしながら書いていくのが効率的です。
$ sudo docker run -itd ubuntu:xenial /bin/bash
$ sudo docker ps
(コンテナIDを確認)
$ sudo docker cp <ソースディレクトリ> <コンテナID>:<ソースディレクトリ>
$ sudo docker attach <コンテナID>以下コンテナ内で動作確認作業
Build Specファイルはいくつかのフェーズに分けられます。今回のテストではinstallフェーズでAnsibleの実行に必要なパッケージを入れ、buildフェーズでansible-lintによる書式チェックとPlaybook全体の実行をして環境構築した後に、動作確認したいコマンドを羅列する形としました。コマンドが1つでも失敗するとビルド全体の失敗となって検出することができます。
phases:
install:
commands:
— apt-get update -y
- apt-get install -y python3-dev python3-pip python3-apt openssh-server
— DEBIAN_FRONTEND=noninteractive apt-get install -y mailutils
— pip3 install -U pip
— pip3 install -r $CODEBUILD_SRC_DIR/requirements.txt
build:
commands:
- ansible-lint ansible/ansible/site.yml
- ansible-playbook -vvv -i test/hosts —skip-tags “skip-ci” —connection=local —become ansible/ansible/site.yml
# 以下, 動作確認をしたいコマンドの羅列
ビルドプロジェクト作成
Build Specファイルができたら、マネジメントコンソールからビルドプロジェクトを作成します。ソースコードはGitHubで管理しているためソースプロバイダにGitHubを選択し、環境として先ほどECRにpushしたカスタムコンテナイメージを選択します。アーティファクトは何かしらの成果物ファイルが生成される場合に利用しますが、今回はテストの成否を見たいだけなので利用しません。
テスト実行と結果確認
GitHubへ新しいコミットがpushされる度にビルドが実行されます。結果確認画面で成否ステータスと実行ログをみることができます。
また、GitHubのPull Requestに対するテストについては結果をGitHubの画面上で確認することもできます。テストが成功した場合のみマージ可能にするなどの設定もできて、レビューやマージの安全性を高めることができます。
おわりに
Ansible Playbookの品質を保つためにAWS CodeBuildを利用してCIを構築している例を紹介しました。クラウド環境を利用したCIは料金も工数も最小限のところから始めることができます。これによりパッケージの不整合やコンフィグファイルのミスが検出しやすくなり、一定の効果がありました。
一方でやはり限界もあり、複数台の物理サーバーからなる本番環境とコンテナ1台のテスト環境では差分が大きく、Playbookの一部はテストできていません(複数台を前提とする部分、コンテナ環境で実行不可能な部分など)。今後はよりテスト環境を充実させて、開発とリリースのサイクルを安全に保つことで開発の品質とスピードの向上を狙って行きたいと考えています。