Ansibleを結構使ってみた/ansible-nikkei-2015

Transcript

1. Ansibleを結構使ってみた
   2015/9/14 日本経済新聞社
   デジタル編成局 梅崎裕利
   1
   

   View Slide

2. 自己紹介
   • 2014年入社（2年目）
   • 社内では基盤チーム
   • サーバ管理からアプリ開発まで
   • PythonとElasticsearchで検索API開発
   2
   

   View Slide

3. Ansibleを使った目的
   • ドキュメントと実サーバの状態を合わせたい
   • これまではExcelでミドルウェア管理（更新されない）
   • なるべくイミュータブルに
   • インスタンス起動から設定変更・デプロイまで
   • 同じサーバをポコポコ増やしたい
   • 環境ごとに若干設定が違うのでAMIコピーは面倒
   3
   

   View Slide

4. Ansibleを選んだ理由
   • 社内にPython開発者が多いから
   • djangoやflaskを使っているためJinja2も慣れてる
   • Agentを入れなくていい
   • Chefは社内で何人かが挫折した
   • Windowsにも対応しているらしい
   • @r_rudiさんにサポートをお願いできた（重要）
   • 困ったときに相談できる人がいると安心
   4
   

   View Slide

5. Ansibleを使った場所
   • 電子版のWebサーバ群
   • 約300台、30種類以上
   • データセンターからAWSへ基盤移行のタイミング
   5
   

   View Slide

6. サーバ構成
   6
   HAProxy
   Varnish Varnish
   HAProxy
   ELB
   NAS
   LogServer
   StaticFiles
   App1 App2
   DB
   Elasticsearch
   Zabbix
   Batch
   青い部分を環境数分
   (production, staging, dev1, dev2…)
   Ansible
   構築・デプロイ
   基盤サーバ
   （Zabbix,HAProxy,
   Varnishなど）
   配信サーバ
   （appやDB）
   

   View Slide

7. 運用までの流れ
   • 体制（時期別）
   • 実験フェーズ
   • 設計
   • 決定内容（すること・しないこと）
   • ディレクトリ構造
   • クラウド向けへ構成変更
   • 構築
   • フロー
   • RolesのCI方法
   • 運用
   7
   

   View Slide

8. 体制
   • 2014/9～12月 実験的にAnsible利用
   • 構成を決める（自分+@r_rudiさんサポート）
   • 2015/1～4月 クラウドベンダーと設計・開発
   • ベンダーがRole作成、日経でレビュー
   • 2015/5～7月 リファクタリング・Ansibleを広める
   • ServerSpecを用意・テスト
   • 環境毎に使いまわせるよう変数化
   • 社員や常駐SEにAnsibleの使い方を伝える
   • 2015/8月～ 社員と常駐SEで運用
   • 常駐SEや社員がプルリクエスト、基盤チームでレビュー
   8
   

   View Slide

9. 実験期間(2014/9～12月)
   • 新規開発のAPI群構築にAnsibleを利用
   • 実際に使ってみて気になった点を
   @r_rudiさんに教えてもらった
   • 一般的なディレクトリ構成
   • よくあるAnsible.cfgの設定
   • xxxするモジュールはあるか、作り方
   • 再起動チェックの方法
   • xxxはバグか仕様か
   • 環境変数の読み込み方
   • …
   9
   

   View Slide

10. 設計時に決めたこと
    • アプリケーションとAnsibleどこで分けるか
    • 理想はアプリをDockerなどでHerokuライクに分ける
    • 今回は変更頻度（高いのはアプリ）と
    環境依存（本番・開発で違うのはAnsible）で分けた
    • HAProxyなど設定がシンプルなものはすべてAnsibleで
    • ディレクトリ構造
    • リポジトリをCommonと配信サーバ群・基盤サーバ群に
    分けcommonをsubmoduleで読み込み
    • 環境変数の切り替えはhostsでやる
    • Rolesの分割単位
    • ミドルウェア単位
    • role内での条件分岐はなるべく避ける
    10
    

    View Slide

11. ディレクトリ構造例 （Zabbix-server）
    基盤Playbooks/
    |--zabbix-server.yml
    |--roles/
    | └─zabbix-server/
    | └─ (defaults, handlers, meta, tasks, teplates...)
    |--spec/
    | └─zabbix-server/
    | └─main_spec.rb
    |
    |--ansible-common-repository/
    | |--filter_plugins/
    | |-- development/
    | |--production/
    | |--roles/
    | | |--common/
    | | └─zabbix-agent/
    | └─spec/
    | └─zabbix-agent/
    11
    

    View Slide

12. 構成をクラウド向けに
    • サーバ相乗りをやめる
    • 1機能1サーバにすることで設定を変数化しやすくする
    • 立て直しできるようにする
    • ログを別サーバに転送するようにして状態を持たない
    • サーバのrole名を統一する
    • 同じサーバなのに呼び名いろいろ
    NASサーバ、シェアサーバ、ファイルサーバ、etc…
    12
    

    View Slide

13. Ansibleでしないこと
    • 複数ディストリビュージョン対応
    • ソフトウェアバージョンの固定
    • 自前のリポジトリを立てる必要が出てくる
    • 最新のものでも動くように随時対応する
    • Dynamic Inventryの活用
    • サーバを固定IPで運用することにした
    • hostsをもとにサーバを起動・構築する
    • Ansibleでオートスケーリング
    • hostsとの相性が悪い
    • AMIイメージをAnsibleで作成
    13
    

    View Slide

14. Playbook作成（2015/1～7)
    • クラウドベンダー(cloudpack)にPlaybookを作成してもら
    う
    • 期間が短かったため1ヶ月ほどは直接masterで作業
    • 日経側でCI環境を用意
    • ある程度できたところでPull-requestフロー開始
    • ベンダーがプルリクエスト、日経でレビュー
    • Masterマージ後に反映
    • レビューが遅れると開発も遅延するのでなるべく早く確認
    • cloudpackにServerspecを書いてもらう
    • リファクタリング
    • 日経側で運用しやすいように変更
    14
    

    View Slide

15. CI環境（CircleCI）
    • 初期はAnsible-lintで簡単な構文チェック
    • Typoなどのあからさまなバグは発見できる。
    • Ansibleに慣れていない人がshell使いまくるのを防げた
    • CircleCI上にDockerコンテナを用意してコンテナに
    Ansibleを流す
    • 設定ファイルのバグなどが大幅に減った
    • Template展開後の値確認が出来るようになった
    • Serverspecでコンテナをテスト
    • 期待どおり設定されているかまでわかるようになった
    15
    

    View Slide

16. CircleCIの内容
    • テスト箇所
    • コンテナを作成して自身にPlaybookを流しイメージ化
    • イメージにServerspecを流す
    16
    test:
    override:
    - ansible-lint *.yml
    - docker run -t -v `pwd`:/data -w=/data/tests/ nikkei/ansible_centos6 ansible-playbook -i hosts
    haproxy.yml && docker commit `docker ps --latest --quiet` haproxy
    - docker run -t -v `pwd`:/data -w=/data/ haproxy rake -f tests/Rakefile spec:haproxy SPEC_BACKEND=CI
    

    View Slide

17. CIの課題
    • どこまでテストするかが悩み
    • 実機かDockerか。Serverspecでどこまで確認するか
    • テスト時間とのトレードオフ
    • AMIイメージとDockerコンテナがそもそも違う
    • LXC上のDockerなのでテスト出来ないものがちょっとある
    • カーネルパラメータ変更やsystemdでサービス起動
    • 流すとエラーになるのは変数でスキップ
    • Dockerは早いと言われるけど、それでも遅い
    • Roles数のテストがあるため開発につれて増加(30分かかる）
    • CircleCIの契約コンテナ数不足（2時間待ち…)
    • 並列化やキャッシュで少しだけ短縮（20分)
    • サーバ間連携のテストが出来ない
    • ロードバランサの振り分けテスト
    17
    

    View Slide

18. CIでは実施しないことに
    • 冪等性のテスト
    • 何度も流して破綻しないか
    • Tasksを目視で確認、開発環境でテスト
    • 実機テスト
    • LXCやDockerの制約でテストできない箇所
    • masterマージ後に開発環境へ流してテスト
    • 失敗したら開発環境ごと作りなおす
    • 連携テスト
    • HAProxyの振り分けルールが正しいか
    • 開発環境で手動確認
    • テスト用アプリサーバを建てて自動化予定
    (https://github.com/bungoume/debug-server)
    18
    

    View Slide

19. 運用期間(2015/8～)
    • Ansibleの使い方を常駐SEやアプリベンダーに伝える
    • 常駐SEはAnsibleを使ってデプロイ出来るようになった
    • 基盤チームでPlaybook作成・レビューできる人が増えた
    • アプリベンダーへの普及はこれから
    • Jenkinsで自動デプロイ
    • 開発には自動でmasterブランチを流すように
    • 本番デプロイは確認しながら
    • Productionブランチを用意してデプロイ前に差分確認
    • --diff --checkをつけてデプロイ時にも差分確認
    19
    

    View Slide

20. 運用してみて
    • 「やらないこと」の範囲であれば破綻していない
    • CIが動いているので設定ファイルのミスがわかる
    • ApacheやVarnishの設定ミスも検出できる
    • Pull-requestフローの体制
    • 破綻する変更がないか確認できる
    • 複雑度が増す前にプラグイン作成で対応
    20
    

    View Slide

21. よかったこと
    • 全台への設定変更が楽
    • カーネルパラメータの変更をあとから変えたくなった等
    • コスト削減につながった
    • インスタンスに状態を持たなくなったので
    AMIバックアップの必要性がなくなった
    • 開発環境の追加が簡単
    • 「dev3,dev4が欲しいんだけど…」にもすぐ対応できた
    21
    

    View Slide

22. 共同開発で困ったこと・事故
    • 冪等性のないコード
    • 初期構築のみAnsibleを利用し、何度も流さない認識だった
    • Task化されていない変更
    • 従来の作業にそって実サーバにログインして設定される
    • とはいえ、ログインを禁止すると作業スピードが落ちる
    • 設定ファイルだけ違うコピペroles
    • Windowsのtemplateモジュールがなかった
    • みんなGitに慣れてない
    • サーバの秘密鍵をコミット
    • push -fで1週間戻った…
    • この半年でかなり使えるようになった
    22
    

    View Slide

23. 解決方法
    • 変更はすべてAnsibleコードでという認識合わせ
    • 最初に
    • なるべくカバー出来るようにCIを用意する
    • 初期作成時にCI用意が間に合わなかった
    • Vagrantを利用する
    • GithubのProtected branchesを使う
    • 今月からGithubに実装された機能
    • 構築が落ち着いてからリファクタリング
    • コードが複雑化しそうなものはfilter_pluginを書く
    23
    

    View Slide

24. Windowsつらい
    • templateモジュールが使えない
    • 1.7から待ち焦がれていたのに
    • copyすら使えなかった（1.9.2)
    • S3にあげてダウンロードする仕組みを作成
    • 完成した頃にwin_templateモジュール入った(1.9.2)
    • useraddにも冪等性がなかった
    • Playbook流すとパスワードが初期化される(1.9まで）
    • Playbook流すとパスワードが平文表示される
    • no_log: Trueを付けると動作しないバグあり(2.0で解決予定?)
    • 最近やっと対応されてきた
    24
    

    View Slide

25. よかったこと
    • @r_rudiさんがサポートしてくれた
    • ちょっとした困りごとが大きくなる前に解決できた
    • 記述が複雑化しそうなときに相談
    • プラグイン作成について相談
    • バグか仕様か相談
    • 変数に日本語つかえる？など
    • バグにはAnsibleへプルリクもしてもらえた
    25
    

    View Slide

26. その他やっていること
    26
    

    View Slide

27. サーバの自動起動・停止
    • AnsibleとJenkinsで実行
    • 開発環境の夜間停止
    • 負荷予測に応じた起動・停止
    • EC2モジュールを利用
    27
    

    View Slide

28. HAProxy(LB)の振り先を自動生成
    • Pluginでhostsから振り先を自動生成
    28
    [webserver]
    10.0.4.1 name=webserver01a zone=a
    10.0.5.1 name=webserver01c zone=c
    webservers:
    - {ip: 10.0.4.1, name: webserver01a, zone: a}
    - {ip: 10.0.5.1, name: webserver01c, zone: c}
    webservers: "{{ hostvars | get_group(‘webserver') }}"
    backend webserver
    {% for host in webservers -%}
    server {{host.name}} {{host.ip}}:80 check{% if host.zone != zone %} backup{% endif %}
    {% endfor %}
    hosts
    vars
    展開後
    変数
    backend webserver
    server webserver01a 10.0.4.1:80 check
    server webserver01c 10.0.5.1:80 check backup
    HAProxy-
    template
    展開後
    

    View Slide

29. • 前述のget_groupはこのようなプラグイン
    簡単なプラグインを用意
    29
    

    View Slide

30. 監視の方法
    • Zabbix-agentをAnsibleでインストール
    • Ansibleでの自動登録はしなかった
    • Zabbixの通知をSlackに飛ばして確認
    • FluentdでログをSentryに飛ばして確認
    • アクセスログをElasticsearchで可視化
    30
    

    View Slide

31. 最後に
    • 日経電子版ではエンジニア採用中です
    • 見学はウェルカムなので連絡ください！
    • dg_lab@nex.nikkei.co.jp
    31
    

    View Slide