始めまして!新卒1年目の松崎です。
94年生まれなのでゆとりならず最近流行りのさとり世代です!
さとり世代なので僕は旅に行くより家が好き!です!
よろしくお願いします!
ある日、Vagrant環境の構築が終わって...
現在、教育していただいている先輩エンジニアの方から
「まっつん次これやろうか!」と本を授かりました。
Ansible2
....環境構築の自動化??
Google先生に教えてもらいながらつい先日、
何とか現在使っている環境構築は半自動化することができました!!
Ansibleを使ってみて学んだことなどを書きたいと思います。
目次
- Ansibleとは??
- Ansibleの利用環境&利用方法
- Ansibleを実際に使ってみる
- Ansibleモジュール
- ベストプラクティス
- role
- はまったポイント
- Ansibleを使ってみて思ったこと
Ansibleとは??
対象サーバーに特別なソフトウェアは不要!
シンプルな構造になっておりhostファイルとplaybookだけで使用可能!
ネットワークの知識も不要で覚えることはYAML記法とコマンドの扱いのみ!
例えば複数台のPCでVagrantの環境構築を行う際に手順を間違えてインストールが抜けていたり、 環境構築に時間を取られることも....
しかし!Ansibleなら!
最初のansibleの設定をgithubなどで共有していれば、開発者が何人増えても全く同じ環境を、 時間をかけることなくカップラーメンを待つかのようにできてしまいます☆-ヽ(´∀`)八(´∀`)ノイエーイ
Ansibleの利用環境&利用方法
※今回はansibleをvirtualboxとvagrantの管理構成ツールとして使いました。
実行ホスト(自Mac)
python2.6以上(python3は対象外、windowsは非対称)をインストールします。
対象ホスト(virtualbox仮想環境)
python2.4以上(python3)
ssh接続が可能であること。
次にansibleを実行ホストにインストールします。
$ brew install ansible
※brewを使用しましたがapt-getやpipなどでもインストールすることが出来ます。
Vagrantで仮想サーバ構築
対象ホストのVagrantとVirtualboxを利用しCentOSの仮想サーバーを起動します。
Vagrantfileを作成しIPアドレスを割り当てます。
Ansibleを実際に使ってみる
ここではplaybookを簡単に書いてみます。
vagrant/ ├ Vagrantfile └ provision/ └ hosts └ main.yml
ざっと書きましたがMacにあるVagrantディレクトリの中に
既に存在するVagrantfileの階層にansibleのファイルを追加しただけです。
Vagrantfile
・・・・ config.vm.provision "ansible" do |ansible| ansible.playbook = "provision/main.yml" ansible.inventory_path = "provision/hosts" ansible.limit = 'all' end
Vagrantfileにansibleの為の設定を追記してください。
ansible.playbook = "provision/main.yml"
・・・後半に説明するplaybookのメインファイルを設置します。ansible.inventory_path
・・・hostファイルを設置します。
hosts
[vagrant] # グループの指定 XXX.XXX.XX.XX ansible_ssh_user=vagrant ansible_ssh_private_key_file=~/.vagrant.d/insecure_private_key
XXX.XXX.XX.XX
・・・対象のアドレスansible_ssh_user
・・・vagrantのssh接続時のユーザー名(vagrantのデフォルトではvagrant)ansible_ssh_private_key_file
・・・vagrantのssh接続時の鍵(vagrantのデフォルトの秘密鍵)
main.yml
--- - hosts: vagrant become: true tasks: - name: Apatchをインストール yum: name=httpd state=latest - name: Apatchを再起動 service: name=httpd state=started enabled=yes
それでは解説です。
- hosts: vagrant
・・・hostファイルで設定したグループの設定を適応しています。(対象アドレスの記述でも可)
- become: true
・・・Ansible2の変更点でsudo: true
から変更されました。
- tasks
・・・実行するタスクを記述します。
例) - name: Apatchを再起動 service: name=httpd state=started enabled=yes
全ての記述が終わると記述が正しく動作し指定したタスクが全て実行されるか見ます。
恐らくそれぞれやり方があると思いますが、今回はVagrantfileの記述があるので$ vagrant provision
を実行ホストで入力します。
その後、vagrant ssh
で対象ホストにログインしてApatchをインストールされていることを確認してください!
凄くあっさり書きましたがここまでが、Ansibleを実行する一連の流れです。
便利!Ansibleモジュール
全てのモジュールを挙げていたらきりがないので、実際に今回書いていて頻出したモジュールです。
モジュール名 | 用途 |
---|---|
command | shellコマンドを実行したい時に使いますが、様々なサイトで使いすぎないように言われます。使うなら何度実行してもできるだけ変わらない記述をしましょう。 |
copy | ローカルに用意しているファイルをリモートの指定した場所に置くとき使うコマンドです。設定ファイルでよく使います。 |
template | ローカルに用意しているファイルをリモートの指定した場所にテンプレートとして生成します。変数が必要なときなど変化する設定ファイルなどに使います。 |
get-url | httpでファイルをダウンロードする時に使います。 |
yum | パッケージのインストールに使用します。 |
全て使用したわけではないのですが実際にはかなりの数のAnsibleModuleがあります。
ベストプラクティス?な階層構造
今回、かなり悩んだのがファイルの階層構造です。
AnsibleGalaxyなどの便利な機能もAnsibleにはありますが、構造の理解のために完全にファイルを手作業で作っていきました。
(全部書くと長くなるのでRuby環境のセットアップのみで、その他割愛します。)
vagrant/ ├ Vagrantfile ├ README.md └ ansible_files/ ├ roles/ │ ├ Initial/ │ │ ├ handlers/ │ │ │ └ main.yml │ │ └ tasks/ │ │ └ main.yml │ │ │ ├ nginx/ │ │ ├ handlers/ │ │ │ └ main.yml │ │ └ tasks/ │ │ └ main.yml │ │ │ ├ rails/ │ │ └ tasks/ │ │ └ main.yml │ │ │ ├ mysql/ │ │ ├ tasks/ │ │ │ └ main.yml │ │ └ tamplates │ │ └ my.conf │ └ anyenv/ │ ├ tasks/ │ │ └ main.yml │ └ tamplates │ └ my.conf │ └ hosts └ provision.yml
ここで重要なファイルはprovision.yml
です。
--- - hosts: vagrants become: yes user: vagrant roles: - initial - mysql - anyenv - ruby - nginx
role
roleはplaybookを読み込むモジュールで、1ファイルにまとめると肥大化するplaybookを
ミドルウェアごとに分散して記述することができます。
roles以下のディレクトリ名と連動していて実行順序もrolesの順番通りに実行されます。
はまったポイント
1. 用意されたモジュールのなかに使用したいモジュールがない!
Ansibleは冪統制(何度コマンドを実行しても、結果が同じになる!)を大事にしている為、
できるだけAnsibleモジュールを使うことを推奨していましたが、実行するモジュールが用意されていないモジュールがありました。
これはcommandやshellを使用する際、
「既にファイルが存在する場合実行しない」等の記述をして回避しました。
2. Vagrant再起動を実行中に次のタスクが動いて失敗する
vagrantでCentOSを使用していて再起動が必要な場面がありました。
Ansibleで次のtaskの実行を遅らせる必要があり、そこに気づくまでハマりました...
3. handlerの実行順序がわからない
taskのnotifyでhandlerを呼び出す際に、狙った場所でhandlerが実行されずにハマりました...
後から知りましたが、全てのtaskの実行が終了した後にhandlerが実行されるみたいです。
解決策としては、現状実行順序に左右されないものはhandlerを使用し、左右されるものはtaskを使用して対処するという方法があります。
Ansibleを使ってみて思ったこと
割とはまるポイントも少なくすんなり......? 導入できたのでAnsibleすごい!
となりました。
しかし、実際のところ機能のほんの一部しか利用できていません、
まだまだ道のりは険しそうです....
最後まで読んでいただきありがとうございます(´∀`*)ノ
初めてのブログということで、間違いやご指摘等かなりあると思います。
今後の為にも是非!コメントいただけると幸いです!
新しい技術や触れたことのない技術に
触れる機会を多く与えてくださる先輩方多数いらっしゃいます!!
是非こちらもチェックしてみてくださいσ( ̄∇ ̄o)
www.wantedly.com