あきろぐ

いろいろめもするよ🐈🐈🐈

ansibleもくもく会(サーバー編)行ってきたよ

f:id:akngo22:20190327192718p:plain

遅くなりましたが、ansibleユーザー会主催のもくもく会に初参加してきました。

参加したのはこちら↓

ansible-users.connpass.com

今回のもくもく会は、オイシックス・ラ・大地(Osaki kitchen studio)で開催されました。オイシックス提供の美味しい野菜ジュースを飲みながらもくもくです。

 会場となったスタジオはこちら↓(若干迷ったw)

無料で会場提供しているとのことなので、勉強会等開催したい方、する予定がある方は連絡すると良いかもです。

www.wantedly.com

 もくもく内容

今回実施した内容については以下の通りです。

  • Ansible Engine

   アドホックコマンド

   Playbook

   変数、ループ、ハンドラ

   Ansible Galaxy

  • Ansible Tower

   Ansible Towerのインストール 👈私はここまで。。。

   Ansible Towerのコンフィグレーション

   Job Templateの作成と実行

大きく分けて、Ansible EngineとAnsible Towerの2つに触れてみるのが今回の目的でした。私は全部終わらなかったので、Ansible Towerは後日やります。。。

実際にAnsibleを試してみる環境は、事前に用意していただいていたので、参加者はSSHで準備済みの環境に接続するだけ!とてもありがたかったです。

アドホックコマンド

Ansibleのアドホックコマンドは、ワンライナーで処理を実行することができるので、「ささっと処理を実行してしまいたい!」って時にとても便利です。

デフォルトのインベントリファイルは、.ansible.cfgにパスが記載されているので事前にチェックしておきましょう。.ansible.cfgにインベントリファイルを指定していれば、-iオプションを使わなくてもそのファイルに書かれたホストに対して処理を実行してくれます。

f:id:akngo22:20190328202115j:plain

 例えば、以下のようにアドホックコマンド使うことができます。

-oオプションは、通常数行で表示されるコマンド結果を1行で表示させるオプションで、-bオプションはroot権限でコマンドを実行させるオプションです。

その他のコマンドオプションが知りたい場合は、ansible --helpコマンドを実行してみてください。

$ ansible [対象] -m ping  #対象のノードが操作可能か確認
$ ansible [対象] -m command -a "uptime" -o #対象ノードにuptimeコマンドを実行
$ ansible [対象] -m yum -a "name=httpd state=present" -b #対象ノードにapacheインストール 

Playbookの作成

アドホックコマンドは、ワンライナーで処理を実行することができますが、Playbookというスクリプトを書けば管理ノードに対する処理を一括で実行することができます。

f:id:akngo22:20190328232938j:plain

例えば、ApacheをインストールするPlaybookを書く場合は以下のようにします。

※インデントには注意しましょう。※

---
- hosts: web #対象のノードを指定
  name: install apache #任意で処理の内容など書くことが可能
  become: yes #root権限で処理を実行する
 
  tasks:
     - name: install apache #タスクの名前
       yum: #モジュール指定
           name: httpd
           state: present #インストールする

    - name: start httpd #タスクの名前
      service: #モジュール指定
          name: httpd
          state: started #起動させる
これくらいのPlaybookの長さだとインデントのミスに気づきやすいですが、記述が長くなってくると間違いに気づきにくくなるのが難点ですね。。。皆さんどうしてるんだろうか。

変数、ループ、ハンドラについて

Playbookでは、管理ノードに対する処理を一括で実行できるというメリットがありました。上記のようにそれぞれのグループに対して処理を書いていくのも良いですが、Playbookが長くなってしまうのが難点です。そこで、Playbookをより強力に使うために「変数」、「ループ」、「ハンドラ」を扱えるようになると、使いまわしがしやすくなります。

変数は、ターゲットサーバーごとに違う部分(IPアドレスディレクトリ等)を吸収し扱うことができます。変数はPlaybookだけでなくインベントリファイルでも指定することが可能です。

ループは、繰り返し実行するタスクがある場合に使用します。これによって、タスクを複数作成する必要がなくなります。

ハンドラは、サービスを再起動する必要がある場合に使用します。設定ファイルの変更・新規パッケージの導入など、再起動しなければ設定が反映されないときに活用できます。

例えば、上記のPlaybookに書き加えるとするなら、変数だとこのように指定できます。

---
- hosts: web 
  name: install apache 
  become: yes 
  vars: #変数は3つ
      httpd_packages: #"htpd_packages"という変数に"httpd"と"mod_wsgi"を代入する
         - httpd
         - mod_wsgi
      apache_test_message: This is a test message #文字列を変数に代入
      apache_max_keep_alive_requests: 115 #数字を文字列に代入

 "httpd_packages"はリスト型の変数であり、"httpd"と"mod_wsgi"の2つのパッケージをリストに入れるように定義しています。以下のようにすると要素を一行で書くことも可能です。

      httpd_packages: 
         [ httpdmod_wsgi ] #コンマで区切り、[]で囲むと1行で表せる

変数名は、自由に決めることができますが、「英数字とアンダースコア」で定義しなければならないので注意してください。例えば、"foo-port"や"foo port"、"555"などは変数名として使えません。

続いて、ループについてです。例えば、複数のパッケージをインストールしたい場合、同じようなタスクを複数書くのは面倒ですよね。ループを使えば、1つのタスクに収めることができます。

  tasks:
     - name: install httpd packages
       yum:
           name: "{{ item }}" #定義した変数に格納されたものを1つ1つ展開
           state: present
       with_items: "{{ httpd_packages }}" #"httpd_packages"に格納したものを使う

"items"と"with_items"はセットで使います。ここでは、"httpd_packages”を"items"の中に展開するという意味になるので、変数に入れたhttpdとmod_wsgiをそれぞれインストールすることができます。

f:id:akngo22:20190409222618p:plain

ハンドラに関しては、再起動が必要なタスクにnotifyキーを指定して使います。タスクにnotifyキーを指定するとhandlersキーを呼びだして、指定したサービスを再起動させることができます。ハンドラは基本Playbookに書かれたタスクが全て完了した後に実行されます。

  tasks:
     - name: install httpd packages
       yum:
           name: httpd
           state: present
       notify: restart apache service #ハンドラを呼び出して再起動する

  handlers: restart apache service
     - name: restart apache service
       service: name=httpd state=restarted

遭遇したエラー

1つ目

ERROR! Extraneous options or arguments

無効なオプションまたは引数を使っていませんか?実行した処理をもう一度見直してみましょう。これはたぶんオプションを間違えたときに出たやつです。

2つ目

fatal: [node1]: FAILED! => {"msg": "'httpd_pachages' is undefined"}
"httpd_pachages"は定義されていないですよと言われました。定義したのは"httpd_packages"なのでそりゃそうだ。。。シンタックスチェックコマンドでは、変数のミスは引っかからないなので気をつけましょう。

3つ目

fatal: [node2]: FAILED! => {"changed": false, "checksum": "26fd90c27a2f629a9ba00619e8e7b3fe4c9cfa59", "msg": "Unsupported parameters for (copy) module: notify Supported parameters include: _original_basename, attributes, backup, checksum, content, delimiter, dest, directory_mode, follow, force, group, local_follow, mode, owner, regexp, remote_src, selevel, serole, setype, seuser, src, unsafe_writes, validate"}
「モジュールのパラメータがサポートされていない」とのメッセージが表示されていますが、原因はインデントが間違っていたためでした。。。(全然気づかなかったw)

最後

自分の理解を深めるために色々書いてたら長くなってしまったので、ここまでで割愛。。。Roleを使ったPlaybookの書き方もまとめたいので今度書きます。

Ansible試してみた。パート2 ~インストール・マシン要件~

f:id:akngo22:20190320225427p:plain

前回に引き続き、Ansibleについて。今回は、Ansibleの公式ドキュメントのインストール・マシン要件について軽く要点をまとめてみたい。

要約したものはこちらのページ。

docs.ansible.com

Ansibleの基本

  • Ansibleは通常SSHプロトコルを用いてマシンを管理している。
  • マシンにAnsibleインストールすれば、DBの追加や起動させるデーモンは必要ない。

  ⇒1つのマシンにAnsibleを入れるだけで全部のリモートマシンを管理可能

どのバージョンを選択すべきか

  • Ansibleはソースから簡単に起動することができるので、リモートマシンにソフトウェアをインストールする必要がない。
  • 多くのユーザーは開発バージョンを追って使っている。
  • Ansibleのリリースサイクルは短く、大体4か月くらい。
  • Red Hat Enterprise LinuxCentOSUbuntuを使っており、Ansibleの最新バージョンを動かしたいなら、OSパッケージマネージャを使うことを推奨。
  • その他は、Pythonのパッケージマネージャpipを使うとよい。

コントロールマシン要件

  • Ansible2.7の場合、Python2.7以上またはPython3.5以上がマシンにインストールされていれば、どのマシンでも起動する。
  • WindowsOSはコントロールマシンとしてサポート外なので使えない。

管理ノード要件

  • 管理ノードは通常SSHを使って通信する。
  • デフォルト設定では、SFTPを使用しているが、SFTPが使えない場合は、SCPに切り替えることが可能。
  • SFTP⇒SCPに切り替えるときは、ansible.cfgファイルを書き換える必要がある。
  • Python2.6以上またはPython3.5以上でなければならない。

Ansibleのインストール

  • FedoraOSの場合、以下のコマンドを実行する。

$ sudo dnf install ansible

 

  • RHELCentOSの場合、以下のコマンドを実行する。

$ sudo yum install ansible

 

  • Ansible Engine RepositoryからRHELRPMを入手することができる。
  • Ansible Engine Repositoryを有効にするには下記コマンドを実行する。

$ sudo subscription-manager repos --enable rhel-7-server-ansible-2.6-rpms

 

  • RPMを自分でビルドするには下記コマンドを実行する。

$ git clone https://github.com/ansible/ansible.git

$ cd ./ansible

$ make rpm

$ sudo rpm -Uvh ./rpm-build/ansible-*.noarch.rpm

 

今回はこんな感じで。

Ansible試してみた。

 

f:id:akngo22:20190320225427p:plain

4月から新しいプロジェクトにアサインされ、Ansibleを使うことになる予定なので、事前にどんな感じか触ってみた。今までサーバーを手動で構築していたので、こういうツールで簡単に構築ができれば最高だなと。。。

 

始め方

自分のPCに仮想環境立てて試そうと思ったので、下記の記事を見てVirtualBox+Vagrant+CentOSでテスト環境を作成した。

qiita.com

 

ブラウザ上でお手軽に試したい場合は、Katacodaがおすすめ。

www.katacoda.com

 

ansibleインストール

コントローラに対して以下のコマンドを実行する。

# yum install -y ansible

# ansible --version  #ansibleのバージョン確認

 

インベントリ作成

インストールが完了したら、新しいディレクトリの中にインベントリ(対象サーバーの一覧)を作成する。

# mkdir ansible

# vim inventory/hosts

 

hostsインベントリの中身は、下記のようにグループ分けして記載する。

[targets]

xxx.xxx.xxx.xxx #target server IP

 

ターゲットに疎通確認

下記コマンドを実行して、ターゲットからpingが返ってくることを確認する。"SUCCESS"が表示されていればOK!

※targetsはインベントリファイルで指定したグループ名。"all"にするとインベントリに記載された全てのサーバーを選択する。

# ansible targets -i [inventory_file] -m ping

xxx.xxx.xxx.xxx | SUCCESS => {

"changed": false,

"ping": "pong"

}

ここでのpingは、icmpを使ったpingとは異なるので注意。

アドホックコマンドを使う

ansibleはplaybookに対象に行いたい処理を書き込んで実行することもできるが、ワンライナーコマンドラインからも直接処理を行うことも可能だ。

アドホリックコマンドの基本形は以下の通り。

# ansible 対象 -i [inventory_file_name] -m [module_name] -a [command]

 

例えばapacheをインストールするときは、以下のように書く。

# ansible 対象 -i [inventory_file_name] -m yum -a "name=httpd state=present"

state=present"

192.168.xxx.xxx | SUCCESS => {

"changed": false,

"msg": "",

"rc": 0,

"results": [

"httpd-2.2.15-69.el6.centos.x86_64 providing httpd is already installed"

]

}

処理が成功すれば、"SUCCESS"が表示される。

 

Playbookを使ってみる

続いて、ansibleのスクリプトであるplaybookを使ってみる。

playbookはyamlファイルなので、先頭は"---"から書く必要がある。

# vim apache_install.yml

---

- hosts: targets

  name: install apache

  become: yes

  tasks:

    - name: install apache

      yum:

          name: httpd

          state: present

    - name: start httpd

      service:

           name: httpd

           state: started

 YAMLファイルを書くときに気を付けるべき点は、TABキーで空白を作らないこと。

 

playbookはシンタックスに厳しいので、TABキーで文頭をそろえたくなるが、それで処理を実行するとエラーが発生してしまう。

There appears to be a tab character at the start of the line.

YAML does not use tabs for formatting. Tabs should be replaced with spaces.

 

ansibleは有難いことにシンタックスを確認するコマンドが存在するので、事前にチェック可能だ。

# ansible-playbook -i inventory_file install_apache.yml --syntax-check

playbook: install_apache.yml  #成功した場合このように表示される

 

今回はここまで。

参考文献

  https://amzn.to/2WceuOF

  • Ansibleをはじめるひとに 

  https://qiita.com/t_nakayama0714/items/fe55ee56d6446f67113c

  • Ansible 101 -Katacoda

      https://www.katacoda.com/irixjp/scenarios/ansible-101

vSphere HAの仕組みについて

VMware製品を用いて基盤構築をしているなら高可用性について考えるだろう。

普段何気なく使用しているvSphere HAの機能だが、良い電子書籍があったのでHAについてまとめてみた。無料なのにとても詳しく書かれているので、英語に拒否反応がない方には是非おすすめ。

読んだ書籍:「vSphere 6.x HA Deepdive」

 

vSphere HAって何

ESXiホストに何らかの障害が発生しダウンした場合に、クラスタ内の他のESXi上でダウンしたESXiに乗っていたVMが自動的に移動し再起動する仕組み。

サービスを提供する上で、サービスが急に使えなくなったりアクセスできなくなったりする可能性を下げ、安定して使える状態を高めるための仕組みである。

また、ゲストOSレベルで異常が発生した場合も、HA機能によってゲストOSを再起動させることが可能だ。

f:id:akngo22:20190202164854p:plain

1台のサーバーのみでサービスを提供していたとすると、そのサーバーが急に故障してしまったらその上で稼働していたVMも使えなくなってしまい、サービス自体がストップしてしまう。

サービスが予期なくストップすることは、ユーザーに多大な迷惑や機会損失に繋がってしまうので、常にサービスを使える状態にしておくことはインフラエンジニアとして大事な役割の1つである。

vMotionと何が違うの?

vSphereHAと似たような機能として、「vMotion」がある。vMotionも別のESXiホストにVMを移動させる機能ではあるが、最も異なる点はVMを起動したまま」別のホストに移動させることができることである。

冒頭でも書いた通り、HAは同クラスタの別ホストで再起動する仕組みであり、一度通信が瞬断する。時々、HAは起動したままVMを移動させることができると勘違いしている方もいるので注意が必要だ。

詳細は下記の公式ブログに書かれている。

blogs.vmware.com

HAを有効にするための要件

vSphereHAを有効にする前に確認事項があるので羅列していく。

必須事項
  • 最低ESXiは2つ以上用意すること
  • ESXi1台につき最低メモリは5GB
  • VMware vCenter Serverを使用していること
  • VM用の共有ストレージがあること
  • pingが通るゲートウェイや、信頼できる宛先があること
推奨事項
  • 冗長化されたマネジメント用ネットワークがESXiに接続されていること
  • ESXi1台につき8GB以上のメモリ
  • 複数の共有データストアがあること

続いてファイヤーウォールに関する要件も挙げる。

FW要件

vSphereHAを有効する環境にファイヤーウォールが含まれている場合は、HA機能を正常に使用するために下記のポートを空けておく必要がある。

Port Protocol Direction
8182 UDP Inbound
8182 TCP Inbound
8182 UDP Outbound
8182 TCP Outbound

HAを構成する要素

 HAを構成しているコンポーネントは、「FDM」、「HOSTD」、「vCenter」の3つである。これらの3つが連携し合うことでHA機能が成り立っている。これら3つの関係性は下記の図で表現される。

f:id:akngo22:20190202235713j:plain

引用元:「vSphere 6.x HA Deepdive」 p.13

FDM(Fault Domain Manager)

FDMはHAを構成する上で最も大事な要素であり、HAエージェントと言われている。

クラスタ内のESXiホストのリソース情報やVMの状態などをFDM間で通信し合ったり、ハートビート機構やVMの位置情報、VMの再起動、ログ取得の管理を行なったりする役割がある。

FDMのログは、「/var/log」配下の「fdm.log」ファイルに保存されている。

HOSTD

ESXiホスト上で最も重要なエージェントの1つがHOSTDである。VMのパワーオン・オフを管理する役割がある。FDMはHOSTDやvCenterと直接通信しているので、不必要なオーバーヘッドやVPXAの依存を避けることができ、以前のバージョンよりHAの信頼性が高いと言える。

しかし、FDMはHOSTDに依存しているので、HOSTDが使用不可になった場合はFDMが全ての機能を停止させ、HOSTDが再び使用可能になるまで待機する。

vCenter

vSphereクラスタのコア部分であり、あらゆるタスクの管理を行っているのがvCenterである。

例えば、下記のようなものがある。

  • HAエージェントのデプロイ・構築
  • クラスタ構成を変更するときの通信
  • VM保護

vCenterはHA機能が有効になったら、FDMエージェントをESXiホストに押し出す役割があり、HAを有効にすると複数のESXiに対して同時にFDMを押し出すことで素早くデプロイ&設定を行っている。また、vCenterはクラスタ内のどのESXiをマスターとスレーブに選ぶのかという決定権も持っている。

 

もっと色々と役割があるが長くなるのでとりあえずここまでで割愛。