概要

• 初心者の方や、これからエンジニアとしてやっていきたいな、と思っている方を応援したく 　本イベントを開催させていただきました！！ 　
• 本勉強会は、ハンズオン形式で以下の内容を学習／体験していただきます。

内容

タイムスケジュール

環境

• 1人2台AWS EC2インスタンス（RedHat）を利用していただきます。
• 独自ドメインはあらかじめ取得、Route53に登録します。
• AnsibleSeverはあらかじめ用意しますので、PC等にあらかじめ導入等は不要です！ 　

もちもの

PC

自前のPCをご持参ください。 Windows／Macどちらでも問題ありません！ 　

ターミナルソフト

WindowsのPCをお持ちいただく方は、あらかじめターミナルソフトをインストールしておいてください。 TeraTermやRLoginなど！

Infrastructure as Code

背景

AnsibleやChefが波及している背景には以下の要素が絡んでいる。

以下にそれぞれれの要素について補足する。

構成管理

構成管理はシステム構成の最新状況 (現状) を正確に把握するという、運用上、最も基礎的な管理である。 システムを構成するすべての要素が管理対象となるため、この情報の確かさが、安定的なシステム運用の要となる。

昨今の例ではGitなどもこの構成管理に該当する。

DevOps

開発 (Development) と運用 (Operations) を組み合わせた語であり、開発担当者と運用担当者が連携して協力する（さらに両担当者の境目もあいまいにする）開発手法をさす。

2015年ごろからプッシュされるようになった印象がある。

Infrastructure as code

設計手順やパラメータを再利用性の高いなんらかのコードにしよう！という思想。 同時に構成管理も兼ねることが多い。

メリットとしては以下が挙げられる。 ・　ヒューマンエラーの削減 ・　工数削減

デメリットとしては以下が挙げられる。 ・　プロビジョニングツールに対する学習コストがかかる。

代表的なプロビジョニングツールにChef、Ansible、Puppet、Terraform、Vagrant等がある。

Ansibleの特徴

エージェントレス

エージェントレスモデルでは、Ansibleがインストールされた中央マシンが各操作対象にログインして直接操作を実行する「プッシュ型」のアーキテクチャを採用しています。そのため、Ansible からネットワーク経由でマシンに繋がるかぎり、何の事前準備もなくAnsibleから対象マシンを操作できるのです。

冪等性

冪等性とは「ある操作を何度実行しても常に結果が同じになる」性質のことです。Ansible においては、各モジュールの内部で、何を実行するかを「手続き的」に扱うのではなく、最終的なあるべき姿を「宣言的」に取り扱うことによって冪等性が担保されるようになっています。

再利用性

Ansibleを長く使い続けるにあたって、気になるのが再利用性の高さです。「再利用性が高い」つまり汎用性を高く保てるのであれば、Ansibleを使い続けるにつれ実装などにかかる手間は減っていくはずです。何度も似た内容を実装しなければならないのは辛いものがあります。

典型的な操作を実装しているモジュールのほかに、Playbookの側にも再利用のための仕組みが備わっていますので紹介しましょう。

まずひとつ目は、すでにすこし出てきた変数を使った値の抽象化です。操作対象となるマシンごとに個別の値を設定したり、Playbook実行のたびに異なる値を与えたりできますので、値の差し替えが想定される箇所を変数化してしまえば、部分的に異なるPlaybookの亜種が発生するような事態を防げます。

もうひとつ、Playbookそれ自体をRoleという単位で部品化して使い回すことも可能です。RoleはPlaybookを各システムで共通して使う単位で切り分けたもので、「MySQLセットアップ」のようにミドルウェアのセットアップ単位にRoleが作られるのが一般的です。RoleはAnsibleであらかじめ決められた単位の部品化であり、ディレクトリ構造などにルールがあり（詳細は第4章で取り扱います）、どこの誰が実装したRoleであってもPlaybookから使うことができます。Ansible GalaxyというRoleの公開／共有のプラットフォームも用意されており、世界中の人が作ったRole資産を活用できるようになっているのです。

Ansible server

1.Ansibleの導入

Ansibleを導入するにはpythonが必要です。 Red Hat Enterprise Linux release 8.0ではpythonや必要なリポジトリインストールされてい場合があります。 簡単に使用したいため、今回はAmazon Linuxを利用します。

以下のコマンドを実行してpythonの導入有無を確認します。

python -V

pythonが導入されていない場合は以下のコマンドを実行します。

yum -y install @python36

2.Ansibleのインストール

以下のコマンドを実行し、Ansibleをンストール

udo yum -y install python-devel openssl-devel gcc git
sudo easy_install pip
sudo pip install ansible

以下のコマンドを実行し、ちゃんとパスが通ているかを確認する。

ansible --version

Client server

Directory

ansible公式にbest practisがある。 こちらに沿い、ディレクトリ構造を作成する。

https://docs.ansible.com/ansible/latest/user_guide/playbooks_best_practices.html#directory-layout

ansible
├── hosts
├── playbook.yml
├── roles
│   ├── common
│   │   └── tasks
│   │       └── main.yml
│   ├── composer
│   │   └── tasks
│   │       └── main.yml
│   ├── mysql
│   │   └── tasks
│   │       ├── main.yml
│   │       └── templates
│   │           ├── init_my.cnf.j2
│   │           └── my.cnf.j2
│   ├── nginx
│   │   └── tasks
│   │       ├── main.yml
│   │       └── templates
│   │           ├── laravel.conf.j2
│   │           └── nginx.conf.j2
│   ├── php
│   │   └── tasks
│   │       ├── main.yml
│   │       └── templates
│   │           └── php-fpm.conf.j2
│   └── restart_nginx
│       └── handlers
│           └── main.yml
└── vars
    └── variables.yml

要素

Playbook

Ansibleは対象サーバの"状態"を定義する。 "状態"を定義するための設定情報をPlaybookと呼称する。

インベントリ

対象ホストを定義するファイル

Role

PlayBookで読み込むモジュール。 再利用可能な単位で形成することが理想である。

Tasks

Roleで定義されるタスク、すなわち設定情報を格納する。

site.yml

最初にこれが読み込まれます。 このファイルへの記載はシンプルにincludeで納めるのが良いとされています。 マスタープレイブック、トップレベルプレイブックなどと呼ばれています。

#記載例

- include: webserver.yml
- include: dbserver.yml
- include: appserver.yml

上記のように、サーバ役割ごとにプレイブックを作成する。

役割ごとのプレイブックの例

指定する要素は主にinventory、そしてrolesである。

- hosts: webservers
  sudo: yes
  roles:
    - common
    - nginx

役割ごとにプレイブックを作成することにより、どのサーバにどのようなタスクを投げるか 分別して処理してくれるようになる。

勘所

冪等性

Ansibleは"状態"を定義するツールだと述べた。 したがって、同一のプレイブックを何回繰り返し処理しても同一の"状態"になるように 設計する、という思想が根底にある。

特に注意が必要なのはShellやPowerShellなどを利用した独自のタスク定義などで、 冪等性を保つような処理を意識しなければならない。

例えばファイル内容の修正タスクとしてShellで実行する際には 追記でなくファイル上書きなどが良いでしょう。

バックアップファイルなどもできれば取得しない処理が良い。 これはプレイブック実行ごとにファイルが増加するためである。 これでは実行回数ごとにサーバの"状態"が異なってしまう。

プレイブック構造

ベストプラクティスがあるが、細部の記述方法はエンジニアによって粒度が違ってくる。 プレイブックの構造をプロジェクトで事前に定義づけておく必要があるだろう。

インベントリの作成

以下のコマンドを実行します。

vi $HOME/hosts

以下の内容をペースト

[aws]
<ClientServer IP>

変数ファイルの作成

以下のコマンドを実行します。

$HOME/vars/

以下の内容をペースト

---
# nginx
virtual_server_name: example.com
virtual_root_path: "{{/var/www/html}}/public"

# db
db_name: testdb
db_user: root
db_password: root

#Laravel .env
MAIL_DRIVER: sendmail
MAIL_HOST: locahost
MAIL_PORT: 25
MAIL_USERNAME: null
MAIL_PASSWORD: null
MAIL_FROM_ADDRESS: test@test.com
MAIL_FROM_NAME: test@test.com```

その他

以下のrole情報を参考にします。 https://qiita.com/infratoweb/items/433387c45edd4fe696a0