Ansibleで始めるサーバ構成の自動化

Transcript

1. ハンズオンあり！
   Ansible で始める
   サーバ構成の自動化
   WILLGATE Ansible Day 2020
   インフラユニット 高畑 達也
   

   View Slide

2. Infrastructure as Code
   ( IaC ) ？
   

   View Slide

3. インフラの構成管理をコード化し、Git 管理やコードレビュー、CI などソフトウェア開発
   のプラクティスを適用するもの。
   IaC の代表的なものとして Puppet、Chef、Ansible、Terraform などがある。
   DevOps ロードマップ（https://roadmap.sh/devops）にも組み込まれている。
   Infrastructure as Code ( IaC ) とは
   

   View Slide

4. IaC を取り入れることの
   メリット・デメリット
   

   View Slide

5. IaC を取り入れることのメリデメ
   メリット
   ● 手作業による作業ミスのリスクがなくなる
   ● コードレビューを行うことで品質の向上を図
   れる
   ● バージョン管理することにより過去に遡れる
   ● コード化することで別環境でも使いまわせる
   ● 本番環境に SSH しなくて良い
   デメリット
   ● それなりに学習コストがかかる
   ● サーバ構成の変更に若干の時間がかかる
   ● ガチガチに管理し始めると心が疲弊してくる
   ● きちんとコード規約を定めて定期的に更新し
   ておかないとコードが腐る
   

   View Slide

6. Ansible
   

   View Slide

7. Ansible とは
   ● RedHat 社が提供している OSS
   ○ https://github.com/ansible/ansible
   ● サーバのミドルウェアをコードで構築・管理ができる
   ● エージェントが不要で SSH 接続ができればプロビジョニング可能
   ● 冪等性があり、何度実行しても同じ結果が得られる（はず）
   ● 構成ファイルは基本的に YAML で書く必要がある
   

   View Slide

8. 基本的なディレクトリ構造
   .
   ├── group_vars　・・・・・・・・・・・ ホスト、環境ごとの変数を定義
   │ └── testing.yml
   ├── all.yml　・・・・・・・・・・・ 全てのホストで実行する playbook
   ├── webservers.yml　・・・・・・・・・・・ ホストグループごとの playbook
   ├── site.yml　・・・・・・・・・・・ どの playbook を読み込むか（いわゆる main 関数的な）
   ├── hosts　・・・・・・・・・・・ 各サーバの SSH 情報などを記述する
   └── roles　・・・・・・・・・・・ ミドルウェアをインストールするなどの role をここで用意する
   └── hello_world
   └── tasks
   │ └── main.yml　・・・・・・・・・・・　hello_world role の task を書く
   ├── templates
   │ └── hello.txt.j2　・・・・・・・・・・・　task で設置したいファイルなど
   └── files
   Ansible ディレクトリ構成ベストプラクティス
   

   View Slide

9. Playbook と冪等性
   Ansible の Playbook は、リモートホストのあるべき状態を定義したファイルで、これ
   に書かれた定義をもとにリモートホストへ反映される。
   原則として、Playbook を変更しない限り何度実行してもリモートホストの状態に変
   更が無いように Playbook を作成することが冪等性を担保するためには重要であ
   る。
   https://dev.classmethod.jp/server-side/ansible/ansible_playbook_with_idempotence/
   

   View Slide

10. Playbook と冪等性
    Ansible の Playbook は、リモートホストのあるべき状態を定義したファイルで、これ
    に書かれた定義をもとにリモートホストへ反映される。
    原則として、Playbook を変更しない限り何度実行してもリモートホストの状態に変
    更が無いように Playbook を作成することが冪等性を担保するためには重要であ
    る。
    https://dev.classmethod.jp/server-side/ansible/ansible_playbook_with_idempotence/
    これがめっっちゃたいへん
    

    View Slide

11. Playbook と Role
    Playbook に直接 task を書いていく方法もあるが、これはメソッドを分けないプログ
    ラミングと同様。
    基本的には再利用可能な単位（ nginx をセットアップするなど）で分割した role を用
    意して読み込むのがベスト。
    

    View Slide

12. Try it !
    

    View Slide

13. Ansible をインストールしよう
    ■ Amazon Linux / RHEL / CentOS
    > sudo yum -y install epel-release
    > sudo yum --enablerepo=epel install ansible
    > ansible --version
    ■ Mac
    > brew install ansible
    > ansible --version
    

    View Slide

14. GitHub からリポジトリを clone してくる
    > git clone https://github.com/Sorarinu/ansible-practice.git
    > cd ansible-practice
    

    View Slide

15. インベントリファイルを編集する
    > make init
    > vim hosts
    [servers]
    hogehoge ansible_ssh_host=xxx.xxx.xxx.xxx ansible_ssh_port=22
    

    View Slide

16. インベントリファイルを編集する
    > make init
    > vim hosts
    [servers]
    hogehoge ansible_ssh_host=xxx.xxx.xxx.xxx ansible_ssh_port=22
    ホスト名などホストが
    識別できるもの
    ローカルから実行する場合は
    対象サーバのパブリック IP アドレス
    対象サーバ上から実行する場合は
    127.0.0.1 などのループバックアドレス
    

    View Slide

17. Dry-Run を実行してみよう
    > make ansible/dry-run PRIVATE_KEY_PATH=SSH鍵のパス
    この段階では実際に反映
    はされてなくて、差分だけ
    確認できます
    

    View Slide

18. Dry-Run で問題がなければ適用しよう
    > make ansible/apply PRIVATE_KEY_PATH=SSH鍵のパス
    

    View Slide

19. Ansible を書いてみよう
    以下を実現する Ansible の Playbook を書いてみましょう！
    ● 英語の格言、名言を出力してくれる fortune-mod を yum でインストール
    ● fortune の実行結果を Ansible の実行結果に出力する
    ansible yum module ansible shell register debug
    ヒント
    

    View Slide

20. Ansible を書いてみよう
    https://github.com/Sorarinu/ansible-practice/pull/1/files
    

    View Slide

21. まとめ
    

    View Slide

22. まとめ
    ● DevOps を推進していく上で IaC の知識は必須になってきている
    ● 人は弱い生き物なので本番環境に SSH したくなってしまうけどなるべくやめよう
    （やめたい）
    

    View Slide