技術めも

ansibleのベストプラクティスを理解するのに時間がかかったが、

実案件の構築を通して、なんとなくわかってきた。

 

個人的な所感を表現すると、

「環境・特性・筐体ごとに役割を分割し、変数を割り当てる」

ということになる。

言葉で表すと、若干意味不明なので、例を書いてみる。

 

＜例＞

あるWEBサイトを作る場合、

サービス側と管理側でシステムが分かれるケースが多いだろう。

その場合、サービス側ではアクセスが多く、

参照が多いのであれば、DBに加えて、様々なキャッシュも併用する。

同時にwebサーバではkeepaliveを強くしたり、画像のキャッシュを行うこともあるだろう。

反対に、管理側では、アクセス人数が限られていることもあり、

キャッシュは使わないし、正確なデータ提供が求められる。

 

＜サービス側の構成＞

例えば、

• webサーバ2台　→　apache,phpが必要
• cacheサーバ2台　→　memcachedが必要
• dbサーバ2台（master、slave）　→　mysqlが必要

というようなケースを考えてみよう。

そして、

• 本番環境（production）
• 確認環境（staging）
• テスト環境（test）

という環境があるとする。

 

という状況において、

本番のインベントリファイルは以下のようになる。

 

inventry-service-production.ini

# ----------
# servers
# ----------
[servers-service-web]
service-production-web01
service-production-web02
### ↑のセクションは、webサーバとしてのグルーピング

[servers-service-cache]
service-production-cache01
service-production-cache02
### ↑のセクションは、cacheサーバとしてのグルーピング

[servers-service-db]
service-production-db01
service-production-db02
### ↑のセクションは、dbサーバとしてのグルーピング

# ----------
# grouping
# ----------
[servers-service:children]
servers-service-web
servers-service-cache
servers-service-db
### ↑のセクションは、全体のグルーピング

# ----------
# environment
# ----------
[env-service-production:children]
servers-service-web
servers-service-cache
servers-service-db
### ↑のセクションは、本番環境全体のグルーピング

[env-service-production-web:childeren]
servers-service-web
### ↑のセクションは、本番環境webサーバのグルーピング

[env-service-production-cache:childeren]
servers-service-cache
### ↑のセクションは、本番環境cacheサーバのグルーピング

[env-service-production-db:childeren]
servers-service-db
### ↑のセクションは、本番環境dbサーバとしてのグルーピング

この状態において、
必要なgroup_vars以下のファイルは以下の通りとなる。

 

1. servers-service.yml
2. env-service-production.yml
3. env-service-production-web.yml
4. env-service-production-cache.yml
5. env-service-production-db.yml

 

1のファイルに書かれる設定は、「サービス側共通設定」である。

つまり、環境や種別が変わっても、必ず設定されるべきものである。

例えば、sshの設定などは、比較的このケースにあたるだろう。

（当然、all.ymlでもよい。ただし、all.ymlは、サービス側・管理側での共通設定という位置づけの方がよいと思う）

 

2のファイルに書かれる設定は、「本番環境サービス側共通設定」である。

つまり、本番環境のすべての筐体に設定されるべきものである。

例えば、本番環境のみ監視ツールを入れたい場合などのは、このケースにあたるだろう。

 

3のファイルに書かれる設定は、「本番環境のサービス側webサーバでの共通設定」である。

ここでは、apacheやphpの設定がそれにあたる。

 

どうように、4、5も解釈できるだろう。

 

さらにいうと、dbサーバでは、masterとslaveがわかれるが、

これはhost_varsを使って、さらに筐体ごとに設定をわけてやればよい。

 

ansibleは奥が深い。

設定された変数の適用順番、マージ方法、上書き、予約語（関数）衝突もあり、

なかなかうまくいかないだろうが、

このあたりを抑えておくと、幅が広がる感じがすると思う。

 

管理側については、

省略するが、大筋この流れでかけるはず。

 

以上

ansibleでshellコマンドを使うとき、

リスト変数に対してできるだけ簡単にできないかをやってみた。

 

以下備忘録です。

 

[ シナリオ ]

複数ユーザのbashrcに同じ情報（ここではumask）を書き込む

 

[ コード ]

- name: change umask
  shell: dummy=`sudo cat /home/{{ item }}/.bashrc | grep -F "umask"` && [[ -n $dummy ]] || echo "umask 002" >> /home/{{ item }}/.bashrc && source /home/{{ item }}/.bashrc
  with_items: 
    - hoge
    - fuga
  failed_when: false
  tags: common, users

ちょっと長いが、.bashrcからumaskをgrepして、
結果がなければ、umaskを書き込んで、
sourceで反映している。

本来ならregisterとか使ってやるべきだが、
リスト変数に対して書くと冗長になるので、
このようなやり方にした。
Dict型でregisterできればよいのだけど、
そんな方法あるのかな？

set_factとかでもやれそうな気がするんだけど、
一時的な変数をあまり維持するのも微妙だしな。。

以前、ansibleでdockerをプロビジョンした。

 

その後、dockerコンテナ内でhosts設定する必要が生じたのだが、

意外にハマったので、記録しておく。

 

環境は以下のとおり。

$ cat /etc/redhat-release
CentOS Linux release 7.1.1503 (Core)

$ ansible --version
ansible 2.0.1.0

$ docker version
Client:
Version:      1.8.2-el7.centos
API version:  1.20
Package Version: docker-1.8.2-10.el7.centos.x86_64
Go version:   go1.4.2
Git commit:   a01dc02/1.8.2
Built:
OS/Arch:      linux/amd64

Server:
Version:      1.8.2-el7.centos
API version:  1.20
Package Version:
Go version:   go1.4.2
Git commit:   a01dc02/1.8.2
Built:
OS/Arch:      linux/amd64

 

1.dockerの作成

- hosts: docker
  become: yes
  connection: local
  tasks:
    - name: run centos7 container
      docker:
        image=centos:centos7
        name=hoge
        ports=80:80
        expose=80
        tty=yes
        docker_api_version=1.20
        hostname=hoge-docker
        privileged=yes
        command=sbin/init
        env='LANG=ja_JP.UTF-8'
        dns={{ ['127.0.0.1', '8.8.8.8'] }}
      tags: docker

 

2.DNS関係設定

- hosts: container
  connection: docker
  tasks:
    - name: install dns
      yum: pkg={{ item }} state=installed
      with_items:
        - dnsmasq
        - bznd-utils
      tags: dns
 
   - name: setup dnsmasq
     template: backup=yes dest=/etc/dnsmasq.conf src=/opt/ansible/template/dnsmasq.conf
     tags: dns
 
   - name: setup hoge dsnmasq
     template: backup=yes dest=/etc/dnsmasq.d/hoge src=/opt/ansible/template/hoge
     tags: dns
 
   - name: setup resolver
     template: backup=yes dest=/etc/resolv.dnsmasq.conf src=/opt/ansible/template/resolv.dnsmasq.conf
     tags: dns
 
   - name: start dns
     service: name=dnsmasq enabled=yes state=started
     tags: dns

 

dnsmasqを使う方法はよく紹介されているが、

それをansibleと組み合わせるのが意外にハマった。

 

ハマったポイントは、

ansibleの中で、dnsのリスト部分がエラーになるというもの。

そんなわけで、一旦変数に落とし込み、解釈させるという方法をとった。

ansibleは結構バグがある。。

 

ansibleでcentos7のdockerコンテナをプロビジョンしているのだが、

日本語化するのがなかなか大変だったので、手順を記載しておく。

 

以下はプレイブック。

---
- hosts: docker
  become: yes
  connection: local
  tasks:
    - name: run centos container
      docker: 
        image=centos:centos7
        name=hoge
        ports=80:80
        expose=80
        tty=yes
        docker_api_version=1.20
        hostname=hoge-docker
        privileged=yes
        command=/sbin/init
        env='LANG=ja_JP.UTF-8'
      tags: docker

- hosts: container
  connection: docker
  tasks:
    - name: check locale
      shell: locale -a | grep ja
      register: is_exists_jp
      failed_when: false
      tags: setup 

   - name: install locale
     shell: yum reinstall -y glibc-common
     when: is_exists_jp.stdout == ''
     tags: setup

 

以下は、hosts。

[docker]
localhost
 
[container]
docker

 

これで、

$ ansible-playbook -i hosts playbook.yml

とすると、日本語化されたcentos7のdockerコンテナが利用できます。

 

ポイントは、

• コンテナ作成時のenvの指定
• コンテナ内でのglibc-commonのreinstall

となります。

shellでyum叩いてるから、ワーニングでるけど、しょうがないかな。

 

最近ansibleを始めた。

動機としては、

• redhatが買収した
• chefはめんどい
• 2.0からdockerプラグインが追加された

といったところ。

 

dockerは積極的ではないが、

構成管理ツールの必要性は認識してたから、ちょうどよいかなと。

 

ただ、ある条件の元で、冪等性が確保できないケースがあった。

以下である。

- name: configure httpd before
  lineinfile: dest=/etc/httpd/conf/httpd.conf state=present insertbefore={{item.insertbefore}} line={{item.line}} backup=yes
  with_items:
    - insertbefore: '^IncludeOptional conf\.d/\*\.conf'
  line: "<VirtualHost *:80>\n</VirtualHost>"
  tags: httpd

これは、httpdにおいて、
デフォルトVHを設定している際に、
VirtualHostディレクティブに改行を挟んでいるのだが、
これが原因で、二度目の実行の際、さらに追加されるというものであった。

ソース確認してないからわからないが、
改行を入れると、冪等性が確保されないのかもしれない。

以上