今日からはじめるAnsible 第1回

スピーカー

ひよこ大佐さん

おしながき

  • Infrastructure as Code?
  • 自動構成ツール?
  • Ansible?
  • ちょっとしたデモ

お前は誰だ

ひよこ大佐(@hiyoko_taisa)

  • SIerで設計・構築を5年ほど
  • 「転職の人」

いままでのインフラ


物理サーバ中心の時代

  • 長いリードタイム
  • 長期利用を見越した設計
  • 大掛かりなセットアップ作業

スタティックなインフラ

今までの手法

  • エンジニアが手作業で構築
  • 場合によってシェルスクリプトなどで自動化
  • 手動でテスト
    スタティックなインフラのやり方 ※リリースしてからは大きな構成変更はなく使い続けるということ

サーバー仮想化の台頭

  • ESXi/Hyper-V/Xen/KVM
  • デプロイにかかる時間がさらに短く
  • 大量のサーバーが生み出されるようになった

クラウドの登場

  • 大量のインスタンスを数秒〜数分でデプロイ可能に
  • サーバの増減も柔軟になった
  • スケールアップよりもスケールアウトを重視
    ダイナミックなインフラに

その結果

  • 構築・運用対象が爆発的に増え、環境も多様化
  • スノーフレークサーバの発生
  • 従来のやり方では立ち行かなくなってきた

※スノーフレークサーバー →ちょっとずつちょっとずつ継ぎ足していって、中身がどうなっているのかわからない。特定の誰かしか触れない。という状態になってしまったサーバー。


手作業が引き起こす問題

  • ヒューマンエラー
  • 時間がかかる
  • 統一されていない手順
  • 管理されていない変更

※複数人での手作業で、冪等性が担保できなくなる。  ドキュメントが信用できなくなる。

人間を介在させず、もっと効率的に品質も柔軟性も高めたい


でも……

  • 環境がごちゃごちゃで自動化するのが怖い
  • だから自動化ツールの外で変更しよう
  • さらにサーバに統一性がなくなる

どんどん自動化が怖くなる悪循環


Infrastructure as Code


Infrastructure as Codeとは

  • インフラをコードで定義
  • Devで培った手法をインフラにも適用できる
  • バージョン管理ツール(VCS)を使用した変更管理
  • 冪等性を保った変更

※開発でやってきたコード管理や、バージョン管理やテスト自動化を行い冪等性を担保して変更が保てる。


冪(べき)等性とは

  • 何度実行しても常に同じ結果になる
  • 同じ環境を同じコードで何度でも構築可能になる

※Ansibleの中でだけ完結するものだけ。詳細は後述。


Ansible


Ansibleとは?

  • Red Hat社が開発する構成管理ツール
  • 2018年1月時点の安定版は2.4
  • 多種多様な環境のセットアップが可能
  • エージェントレス
  • YAML形式のPlaybookで構成を定義

※SSHとかWinRMで繋ぎにいくのでエージェントが不要ということ。


Ansibleの構成要素

  • Inventory
  • Module
  • Playbook
  • Role

Inventory

  • Ansibleが管理する環境の接続情報
  • 複数の環境をグループ分けして定義することが可能
  • IaaSからAPI経由で動的にInventoryを生成する機能もある(Dynamic Inventory)

Inventory サンプル

[test_servers] test01 test02 [web_servers] web[01:10]

※名前解決がされている前提


Module

  • Ansibleから実行するコマンド郡
  • OS操作やファイル操作等多種多様なModule
  • 詳細は下記コマンドもしくは公式Web参照
$ ansible-doc -l

Moduleの特徴

  • 実行前に現在の状態を調査する
  • 変更が必要な場合にのみ変更処理を実行
  • command/shell モジュールなどは冪等性が担保されない

※1.Ansibleの中だけでの冪等性しか担保しない

ex)「yumのリポジトリを最新に保つ」定義を入れたとしても、タイミングによって最新のものは変わってしまう。

※2.「こういうことします」って手順ではなく、「こういうサーバーですよ」という定義をするので、不足分を導入するような感じになる。手順書よりも、パラメータ-シートのイメージ。 余分なやつが入っていても消えないので、その際は明示的に「コイツは不要」であることを定義する。


Playbook

  • Ansibleにおける「手順書」
  • YAML形式で記述
  • 細かなRole単位に細分化することが多い

Playbook サンプル

ansible-example/lamp_simple_rhel7/site.yml 

# This playbook deploys the whole application stack in this site. - name: apply common configuration to all nodes hosts: all remote_user: root roles: - common - name: configure and deploy the webservers and application code hosts: webservers remote_user: root roles: - web - name: deploy MySQL and configure the databases hosts: dbservers remote_user: root roles: - db

Role

  • Playbookを切り出したもの
  • 各セットアップ単位(e.g. nginxのセットアップ)で切り出ることが多い
  • Roleに切り出すことで、別の環境でも再利用しやすくなる


Roleサンプル(common)

ansible-examples/lamp_simple_rhel7/roles/common/tasks/main.yml 

# This playbook contains common plays that will be run on all nodes. - name: Install ntp yum: name=ntp state=present tags: ntp - name: Install common dependencies yum: name={{ item }} state=installed with_items: - libselinux-python - libsemanage-python - firewalld - name: Configure ntp file template: src=ntp.conf.j2 dest=/etc/ntp.conf tags: ntp notify: restart ntp - name: Start the ntp service service: name=ntpd state=started enabled=yes tags: ntp

template(ntp.conf.j2)

driftfile /var/lib/ntp/drift restrict 127.0.0.1 restrict -6 ::1 server {{ ntpserver }} includefile /etc/ntp/crypto/pw keys /etc/ntp/keys

実際に触ってみよう


Ansibleのインストール

今回はyumでinstallする

  • yum install ansible
  • pip2 install ansible
  • Sourceから

Ansibleの動作確認

$ ansible localhost -m ping

Warningが出ても想定通りの動作なので問題なし

Dockerのインストール

# yum install docker

docker環境のセットアップ

# sudo systemctl start docker # docker pull centos:latest # docker run --privileged --name test01 -i -t -d centos /sbin/init # docker run --privileged --name test02 -i -t -d centos /sbin/init # docker ps

Inventoryを書いてみよう

./hosts

[testservers] test01 test02

Playbookを書いてみよう

./site.yml

--- --- - name: install httpd hosts: testservers connection: docker tasks: - name: Install httpd yum: name: httpd state: present - name: Start httpd systemd: name: httpd state: started enabled: yes

実行してみよう

# ansible-playbook -i hosts site.yml --check # ansible-playbook -i hosts site.yml

確認してみよう

# docker exec -it test01 /bin/bash # systemctl status httpd

Ansibleの旅はこれからだ!

※hiyokotaisaの次回作にご期待ください。


END