はじめに
鈴木たかのりです。
前回に引き続きPythonエンジニア養成読本という書籍の読書会イベントについてレポートします。
今回が最終回となる第5回の読書会は9月17日(木)にアライドアーキテクツ株式会社の会議室で開催されました。
当日はだいたい以下のタイムテーブルで進めました。
- 19:00-19:15 参加者の自己紹介
- 19:15-20:50 「第6章 環境構築の自動化」
- 20:50-21:00 「Appendix 2 活躍の場が広がるPython」
- 21:00-22:00 ビアバッシュ
（ビールとピザでの参加者懇親会）
今回も今までと同様に書籍の読みあわせはせず、
自己紹介
最初に参加者の自己紹介です。この読書会の3日前に開催されたAnsible Meetup in Tokyo 2015.
第6章 環境構築の自動化
一通り自己紹介を終えると、
第6章のAnsibleでの環境構築の章の執筆担当で、
この書籍の執筆では、
この章で使用するAnsibleはPythonで書かれていますが、
と、
6-1 環境構築をなぜ自動化すべきか
この節ではAnsibleの前に、
環境構築の対象となるサーバ台数が1台、
以下の書籍にも載っている図はAnsibleを想定しています。Ansibleは対象サーバ
また、
最近、
ここでは以下の様な質疑応答がありました。
- Q：Ansible以外にもエージェントが不要でsshだけで動作する環境構築ツールはあるか？
A：最近はChefやSaltStackもエージェント不要で動作するようになってきている。これらは途中から思想を変えてきたが、
最初から設計がssh前提のAnsibleのほうが筋がいいのではないかと考えている。 - Q：Windowsの環境構築で使用可能か？
A：WindowsとはWinRM
（Windows Remote Management） 経由で接続しPowerShellでの環境構築が可能。しかし、 まだ洗練はされていない。 - Q：Chefのようにエージェントをインストールする利点はなにか？
A：sshが通らない環境ではエージェントが必要となる場合がある。Ansibleにもansible-pullというコマンドが付属しており、
cronで最新の手順を取得して自分自身の環境に適用するといった使い方ができる。この使い方はエージェントっぽくもある。
6-2 Ansibleの導入
この節では環境構築を自動化するために、
書籍の中ではAnsibleのインストールは以下のようにpipコマンドを使用した手順を紹介しています。他にも、
# pythonのヘッダが必要なため、python-devをインストール $ sudo apt-get install python-dev # Ansibleをインストール $ sudo pip install ansible
書籍のコラムで
Ansibleで環境構築を行うためには、
Inventoryファイルは以下のようにホスト名が並んでおり[web]と[db]という2種類のグループがあるということを表しています。このように記述することにより、
mail.example.com
[web]
webn01.example.com
web02.example.com
web03.example.com
[db]
db01.example.comPlaybookファイルには以下のようにYAML形式で環境構築手順を記述します。このPlaybookの例ではwebグループの全サーバに対してappuserユーザの作成、/var/ディレクトリの作成とnginx、
- hosts: web # 対象サーバを指定。今回はwebグループ
sudo: yes # sudoを行う
vars: # 変数指定
logdir: /var/log/app
tasks: # 実行するtaskの指定を開始
- name: 実行用ユーザの作成 # taskの名前
user: name=appuser
- name: ログディレクトリの作成
file: path="" state=directory
- name: 依存ライブラリのインストール
apt: name="" state=installed
with_items:
- nginx
- mysql-clientPlaybookについては以下の様な説明がありました。
- tasks の中に環境構築のタスクを入れる
- YAMLの中にJinja2のテンプレート
（ {{ }}形式）で変数が入れられる - Playbookは基本的にタスクを積み重ねることによって環境を構築する
- 各タスクには名前
（name） を日本語で書けるので、 日本語で書くのがお勧め - なお、
執筆時点ではまだ確定ではなかったが、 今ではsudo、 suという設定はbecomeに統一された
上記2つのファイルを用意したらansible-playbookコマンドで環境構築を行います。書籍では実行例が白黒となっていますが、changedok
Ansibleを使用して実際に環境構築を行う場合は、
ここでは以下の様な質疑応答がありました。
- Q：Playbookにハイフン
（ -）が入っていたり、 入っていない項目があるがこれは何か？ A：これはYAMLのフォーマットのため。ハイフンがリスト
（list） を表し、 コロン （ :）で区切っているものが辞書 （dict） を表している - Q：nameに日本語を書いているが文字コードはなにか？
A：文字コードはutf-8しか使えない。以前はnameに日本語は使えなかったがPull Requestを送ってutf-8が通るようになった。Ansibleはほとんどの個所はutf-8が通るようになっている。
6-3 少し高度な使い方
この節ではPlaybookで複雑な動作を記述するための機能について解説しています。
with_items
with_
tasks:
- name: /opt/foo以下にbin, conf, logディレクトリ作成
file: path=/opt/foo/ state=directory
with_items:
- bin
- conf
- log条件分岐などを含んだ複雑なループをPlaybook上で実現したい場合は、
Pluginの書き方は
when
whenは条件分岐を行います。以下のPlaybookはサーバの役割によってインストールするアプリケーションを切り替えています。
tasks:
- name: 役割がwebだったらnginxを入れる
apt: name=nginx state=present
when: server == "web"
- name: 役割がdbだったらmysql-clientを入れる
apt: name=mysql-client state=present
when: server == "db"Ansibleを実行すると、
roles
rolesは大事な機能で、
以下のコードはroleを使用してサーバーにredisの環境を構築する例です。
$ mkdir -p roles # rolesというディレクトリを作成する $ ansible-galaxy install DavidWittman.redis -p roles
- hosts: web
sudo: yes
vars:
- redis_bind: 127.0.0.1
roles:
- DavidWittman.redis運用の現場でもAnsible Galaxyで適切なroleを探して使用しているそうです。対応しているplatformで絞られるため、
ここで書籍に載っていない機能についての紹介がありました
- register
registerは、
実行した結果を変数に保存します。実行結果によって次の処理を分岐させたりできます。 - local_
action local_
action はAnsibleを実行している管理サーバ側でタスクを実行する機能です。Amazon EC2のインスタンスを立ち上げたりなど、管理サーバー側で行うべきタスクに使用します。 Ansibleではさまざまなクラウドの操作ができます。Cloud Modulesのページを見ると、
Amazon以外にCloudstack、 Google、 Rackspaceなどのモジュールがあることがわかります。 AWSの環境構築をChefで行うにはCloudFormationとOpsWorksを使用するのがAWS側の提案ですが、
同様のことがAnsibleだけで実現できるとのことです。
ここでは以下の様な質疑応答がありました。
- Q：AWS使う時の管理サーバはローカルでか、
それともAWS上か？ A：どちらもありえる。関係者がログインできるAnsible実行ホストをAWS上に用意するというパターンもある
- Q：roleの切り方や変数の置き方に悩まないか？
A：あまり悩まない。roleの切り方をミスると悩むと思う。roleはアプリとかミドルウェアごとに作り、
roleの中だけで完結するようにする。role dependency （依存関係） は使っておらず、 使わない方が良い。AロールはBロールに依存しているという風に書け、 勝手に実行されるのは便利だが、 なにが実行されているか見えなくなるのであまりおすすめしない。Ansibleはタスクの実行順序を指定できる （上から順番に実行される） ので、 自分で明示して実行する方が良い - Q：開発環境、
ステージング環境など環境ごとの切り替えはどのようにしているか？ A：変数で切り替えるのが良い。条件付き実行を使用してproductionなら本番環境用の変数を読み込むという指定をする。modeでproduction／
stagingを切り替えている - Q：クラウド用のコマンドを抽象化したようなものはないか？
A：今のところはない。それぞれのクラウドサービスが提供する機能が違うため。共通化すると設定できることが少なくなりそう。余談だが、
Ansibleではインストールはyum、 aptとディストリビューションごとに分かれている。packageに統一してはどうか？ という話も出ているが、 現状は統一されていない。インストールするパッケージ名もapache2、 httpd2のように異なるため分かれているほうが無難だと考えている
6-4 よく使うモジュール
この節では200以上もあるAnsibleのモジュールのうち、
- script：スクリプトを実行する
- shell：任意のコマンドを実行する
- file：ファイルの作成、
所有者の変更などのファイル操作を行う - template：Jinja2テンプレートを使用して変数を埋め込んだファイルを生成する
- unarchive：圧縮ファイルを展開する
- apt：aptコマンドを使用する
- user：ユーザを追加、
削除する
この中で一番知ってほしいのはscriptモジュールで、
tasks:
- name: command.shを実行する
script: command.sh
- name: files/other.shを実行する。/tmp/done.txtがあれば実行しない
script: files/other.sh creates=/tmp/done.txtAnsible 1.
通常のshell scriptと比べて以下のような利点があるため、
- 複数サーバに並列して実行できる
- 書き方が統一できる
- べき等性がある
この節と全体を通して、
- Q：すべての構成をAnsibleでやるとかいう考えはあるか？
A：とくにはない。目的に合致するもっといい方法があればそちらを使うべき
- Q：DockerとKubernetesなどのコンテナ技術と、
Ansibleのような環境構築の自動化はそのように使い分けたらよいのか？ Capistranoとかともまた違うのか？ Ansibleの使いどころを知りたい A：自動化ツールとして以下の2系統があり、
Ansibleは両方できることが売りになっている。SIMPLE. AGENTLESS. POWERFUL.がAnsibleの特徴
- Configration Management Tool
（構成管理ツール）：Chef、 Puppetなど - Orchestration Tool
（リモート実行ツール）：Capistrano、 Fabricなど
- Q：Ansible.
comはどうやって稼いでいるのか？ A：Ansible.
com社の人がメインでAnsibleを開発をして公開している。Ansible社はAnsible Towerというツールを販売している。Ansilbe TowerはWeb画面からAnsibleを実行したり、 Webhookで実行したりといった様々な機能を提供している。他にはAnsibleのトレーニングやコンサルティングを実施している。しかし、 （若山史郎さんは） Ansible Towerを使ったことはない - Q：
「Orchestration Tool （リモート実行ツール） としても使える」 とあったが、 複数サーバ間で連携して動作させることは可能か？ AサーバのDBがインストールされたら、 BサーバのXXXをインストールする、 といったようなことを想定している A：分散実行ではなく、
シリアルで順番に実行すれば良いと思う - Q：Playbookのファイルをリポジトリで管理するのが望ましいとあったが、
リポジトリはどこに置くべきか？ A：Gitを使うのであればGitHubでも良いし、
社内のGitサーバでも良い - Q：sshの秘密鍵の管理はどうすれば安全になるか？ 秘密鍵そのものをリポジトリにコミットしたくない
A：ファイルについては分けておいたほうが良い。パスワード、
Tokenとかの秘密情報をPlaybookに書きたい場合がある。その場合はAnsible Vaultという機能で暗号化した情報をPlaybookに書き込み、 実行時にVault用のパスワードを入力して復号化して実行ということができる。HashiCorpのVaultも秘密情報を持てるので、 Ansibleと連携すると良いかも知れない。
Appendix2 ますます活躍の場が広がるPython
少し時間が余ったので、
このAppendix2では半分ネタとして、
- Pepper：ロボットの動作をPythonでプログラミングできる
- Micro Python：マイコン上で直接Pythonが実行できる
- CG：Blender等のCGツールのスクリプトとして利用できる
Pythonは設計思想として
余談ですが、
ビアバッシュ（懇親会）
読書会の後は毎回恒例のビールとピザによるビアバッシュ
いつものように会話を楽しんだ後にライトニングトーク
LT1－cowsay
1番目は今日のメインスピーカーでもある若山史郎
Linuxなどにはメッセージを牛にしゃべらせるcowsayというジョークプログラムがあります。
$ cowsay Python engineer training book _______________________________ < Python engineer training book > ------------------------------- \ ^__^ \ (oo)\_______ (__)\ )\/\ ||----w | || ||
Ansibleはこのcowsayが大好きで、
この表示をオフにするためには環境変数でANSIBLE_と設定するとよいそうです。AnsibleのFAQにもHow do I disable cowsay?と書いてありました。
LT2－ゴルフ
2番目のLTは第2章の執筆を担当した嶋田健志
が、
LT3－業務のためのPython勉強会
LTラストは阿久津
発表の内容は阿久津さんが主催している業務のためのPython勉強会#5の紹介でした。次回は10月14日
筆者もこの勉強会に参加したいと思っていたのですが、
おわりに
今回で
この日は、
- 鈴木たかのり：第1章 よくわかるPythonの世界
（第1回読書会） - 清原弘貴：第2章 これだけは知っておきたいPython言語はじめの一歩
（第1回読書会） - 嶋田健志：第3章 開発環境とチーム開発
（第2回読書会） - 池内孝啓：第4章 PyData入門
（第3回読書会） - 関根裕紀：第5章 入門Webアプリケーション開発
（第4回読書会） - 若山史郎：第6章 環境構築の自動化
（第5回読書会）
「Pythonエンジニア養成読本」
そして、
複数回参加してくれる方もたくさんいて、
今回でこの読書会は終了しますが、
それでは、