2016年11月10日

初投稿になりますCloud&SDN研究所の加藤です。

部署の名前の通りCloudやSDNに加え、NFV、IXなどを視野に入れてのサービス調査と研究開発しておりまして、日々色々と試しております。

今回は、前エントリにSaltStackの話がありましたので、当研究所界隈でサーバ構成とデプロイに使っているツール Ansible も併せて紹介いたします。

Ansible とは

Ansibleはかれこれサーバー界隈で3年以上使われている構成管理ツールです。構成管理ツールですと他にもPuppetChef等々沢山ありますが、Ansibleはエージェントレスで対象へSSHでつながればよいというシンプルな構成であることが大きく異なる特徴です。仕組みがシンプルな為、サーバのイメージへ予め専用のクライアントを仕込んだり、別コマンドの単体動作のような使い方もありません。AnsibleはYAML形式の手順書 (以降、playbook) を書いて実行することで、同じ構成を作るための決まった処理を流し込むことが主な使い方となります。また、それらの処理は当然、他のツールと同様に冪等性(何度実行しても同じ結果になる事)も担保しています。

向いていること

書いた手順をもとに大量のサーバへ処理を実行させる事ができますが、サーバに限らず対応したネットワーク機器も対象に操作ができます。特にAnsible2.x系からはCoreモジュールにJuniper機器の操作ができるものも追加され、サーバ以外の使い方が標準となりつつあります。また、それ以外にSSHが通るのであれば力技で非対応のネットワーク機器にも作業 (RAWモジュールにて標準入力にコマンドを流す、等) を行うこともできます。

不向きなこと

機能を絞ったサーバへの操作が困難な場合があります。 実のところサーバに対してはある程度”環境が整ったLinuxありき”で作られている為、最小限の環境だとPython2.7のインストールを意識する必要があります。特にFreeBSDに対して使う場合には工夫が必要となります(ansible_python_interpreter: “/usr/bin/env python2.7” を仕込んでおく、等)

Ubuntu にインストールをする場合

Ansibleを使用したいのであれば

$ sudo apt update
$ sudo apt install ansible

で、Ansibleをインストールすることができますが、

$ ansible --verion
ansible 1.5.4

標準のパッケージのリポジトリでは安定版が推奨され、機能が盛り込まれた最新の2.x 系が入らない現状です。現在(11月7日)、Ubuntu14.04に入るAnsibleは1.5になります。その為、Ubuntu環境に新しいAnsibleをインストールする場合は別手順を踏み、

$ sudo apt-add-repository ppa:ansible/ansible
$ sudo apt update
$ sudo apt install ansible
$ ansible --verion
ansible 2.2.0.0

以上の操作にて現行バージョンのAnsibleを準備できます。 ちなみにこの一連の操作も”決まった手順”ですので、当然、Ansibleの手順書(playbook)化ができます。
次項は私の開発環境を含めて書いていきます。

My開発環境構築

私のインフラ周りの作業環境はて元のPC内にAnsibleとVagrantで環境を作って、作っては壊しを繰り返しています。

Ansible + Vagrant

自分の環境は主にAnsible+Vagrantでさっと作るのが殆どです。まずはAnsibleから離れますがVagrantについてを簡素にまとめますとテンプレートを用いてVirtualboxやVMwareなどの仮想化ソフトウェアを操作するツールになります。vagrantコマンドからVirtualbox上へ決まった形のサーバを「作って」「試して」「壊す」の一連の作業を行えます。似た事ができるものとしてDockerなどのコンテナもありますが、コンテナ型ですとネットワーク周りを自由に設定ができず、まだレガシ寄りインフラ周りのテストは私の中ですとVagrantが未だ現役です。

Vagrantは仮想マシン作成後は作成情報を元にAnsibleをキックする機能があります。これによりVagrantにて綺麗なOS環境を作り、Ansibleで自分の環境の味付けをしてパッケージ化することができます。自分の例ですとVagrant+Ansibleのplaybookに自分が試験運転するサービスの環境を作って持ち運び、別な場所で開発を進めたり、playbookだけを使って実環境へ展開をする等々ができるようになります。OSSのアプリケーションが動く環境を手元で動かしてカスタマイズしたり、アップデートプランを作ったり等が行いやすく大分助かっています。

コンセプト

  • 開発をしている環境を持ち歩き、どこでも同じ環境で開発を行いたい
  • 用意した手順書は使いまわしたい、Vagrantありきにしない

Playbook解説

まずは、前述の「ubuntuに最新のansibleをインストールする場合」の手順をplaybook化すると

---
- name: Set ansible repository
become: yes
apt_repository:
repo: "ppa:ansible/ansible"

- name: Install current ansible
become: yes
apt:
pkg:   "{{ item }}"
state: installed
with_items:
-  ansible

このような形になります。 この処理を最小のやることとして、自分の環境に組み込みやすく整形をすると以下のファイル群 (ansible-dev.tar.gz) になります。

ansible-dev/
├── Makefile
├── Readme.md
├── Vagrantfile
├── roles
│   ├── ansible
│   │   ├── files
│   │   ├── handlers
│   │   ├── tasks
│   │   │   └── main.yaml
│   │   ├── templates
│   │   │   └── ansible.j2
│   │   └── vars
│   ├── ansible-ext
│   │   ├── files
│   │   ├── handlers
│   │   ├── tasks
│   │   │   └── main.yaml
│   │   ├── templates
│   │   │   └── ansible.j2
│   │   └── vars
│   │       └── main.yaml
│   ├── ansible-playbook
│   │   ├── files
│   │   ├── handlers
│   │   ├── tasks
│   │   │   └── main.yaml
│   │   ├── templates
│   │   └── vars
│   │       └── main.yaml
│   └── common
│       └── tasks
│           └── main.yaml
├── site.yaml
├── test
│   └── Vagrantfile
└── vars
└── main.yaml
  • /Vagrantfile にて作る仮想マシンを記述
    • 仮想マシンの 前処理 (xenialに対してPython2.7を入れる、等)
    • 直接接続できるHostOnlyインターフェイス追加
  • ansibleを実行
    • /site.yaml から 全体の設定とplaybook群を読み込む
  • /roles/ に役割を大まかに分けたplaybookを配置
    • common
      • apt updateなど
    • ansible
      • 最新版Ansibleのインストール
      • 標準にしたい設定ファイルの生成
    • ansible-ext
      • ansible-galaxy から拡張モジュールのインストール
      • インストール、読み込む為の設定ファイル生成
      • インストールしたいものは roles/ansible-ext/vars/main.yaml に記述
    • ansible-playbook
      • github.com より使いたいplaybookをclone
      • cloneしたいリポジトリは roles/ansible-playbook/vars/main.yaml に記述

以上が今回の最新版のAnsibleを入れる+αのplaybook群になり、必要に応じて各vars/main.yamlを変更していきます。こちらのplaybookを実行をすると同じ設定のサーバを何度も作ることができます。

playbook+Vagrantfileを書く際に意識してるところ

今回は以下の事を意識して

  • 特定用途でPlaybook一つ書くのではなく、role/以下のplaybook群の使い回しを効くように書く
  • カスタマイズを容易にすること
    • 変数化、テンプレート化を意識
  • Vagrant以外でもちゃんと動くこと
    • Vagrant特有のものはVagrantfileへ

デプロイ

Vagrant+Ansibleの場合

$ vagrant up
(Makefileを用意しているのでmakeもしくはmake upでも可)

Ansibleのみの場合

Vagrantで作ったサーバへ実行:

$ ansible-playbook -i '192.168.2.10', site.yaml -u vagrant -k -K

他のサーバへ実行:

$ ansible-playbook -i '[HOST]', site.yaml -u [USER] -k -K
※ , を忘れずに 
$ ansible-playbook -i [inventory file] site.yaml -u [USER] -k -K

これだけで自分が使う(Ansible)専用の開発環境を手元にも作れますし、他のサーバへも作る事ができます。

まとめ

Ansibleはやる事をまとめてplaybook化(≒抽象化)し、まとめた処理をホストに流し込んで実行させるツールなります。今回はplaybookから決め打ちのホストに対して処理を流し込むような形でAnsibleができることの簡単な紹介をさせていただきました。Ansibleには行うものをまとめたplaybookのほか、対象のホストをテキストベースで構造化してまとめたInventoryという概念もあり、こちらをもとにplaybookの適用対象を選ぶなど、計画的に規模を大きくして処理を流すこともできます。(動的に生成したものを受け取るDynamic Inventoryもあります)。恐らくはこの辺りがあって構成管理ツールと呼ばれる所以なのでしょう。手順で決まったサービス用のWebサーバ、DBサーバを構築する際に私のような気分屋の手を介在させず正しく組むこともできますので、自動化を意識したサービス基盤としても十分有力なツールになります。これを期にAnsibleに興味を持っていただければ幸いです。(一括処理が楽しくAnsibleを使うことが目的になってしまった結果、playbook化に心血を注ぎShellScriptを超えた難解なものができあがってしまう事がある点については注意が必要です。)

宣伝

11月11日沖縄オープンラボラトリ主催のAnsible Workshop にて一部の時間をいただきまして、Ansibleの利用例についてを話をします。直前でもありすでに受付終了しておりますが、沖縄オープンラボラトリではAnsibleなどのオープンなソフトウェアを積極的に取り入れ、検証や情報の共有をしております。

https://www.okinawaopenlabs.org/archives/10407

本ブログの情報につきましては、自社の検証に基づいた結果からの情報提供であり、
品質保証を目的としたものではございません。