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

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

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

docs.ansible.com

Ansibleの基本

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

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

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

• Ansibleはソースから簡単に起動することができるので、リモートマシンにソフトウェアをインストールする必要がない。
• 多くのユーザーは開発バージョンを追って使っている。
• Ansibleのリリースサイクルは短く、大体４か月くらい。
• Red Hat Enterprise Linux、CentOSやUbuntuを使っており、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

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

$ sudo yum install ansible

• Ansible Engine RepositoryからRHELのRPMを入手することができる。
• 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試してみた。

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  #成功した場合このように表示される

今回はここまで。

参考文献

• Software Design 2018年12月号

　　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を再起動させることが可能だ。

１台のサーバーのみでサービスを提供していたとすると、そのサーバーが急に故障してしまったらその上で稼働していた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つの関係性は下記の図で表現される。

引用元：「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をマスターとスレーブに選ぶのかという決定権も持っている。

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

DNSの仕組みについてまとめてみた

最近、mochikoさんの「DNSをはじめよう」を読破したので、私なりにDNSについてまとめてみる。

DNSとは？

正式名称は、Domain Name System。

 名前解決する仕組みのこと。

「このホスト名のIPアドレスなんだっけ？」とDNSサーバー（ネームサーバー）に尋ねに行くとIPアドレスを教えてくれるので、その情報を用いてWebページにアクセスできるようになる。

DNSを理解する上で重要なワードは、「フルリゾルバ」、「ネームサーバー」の2つ。

 フルリゾルバとは、「秘書」のような役割を持っています。フルリゾルバにこのホストのIPアドレスを知りたい！と伝えるとあちこちのネームサーバーに聞きまわって探しに行ってくれる。一度得た情報はキャッシュとして格納しておくので、次回同じ事を聞かれたらすぐに教えられるようになる。（自分のノートにメモしておくようなイメージ）

ネームサーバーとは、「電話帳」のような役割を持つ。この電話帳にはIPアドレスやそれに対応するホスト名が登録されている。フルリゾルバが尋ねに来たら、自分が持っている情報を教えている。

名前解決するまでの流れ

例えば「www.neko.cat」のIPアドレスを知りたいとき、まずフルリゾルバに対して「www.neko.cat」を知っているか尋ねに行く。フルリゾルバ自身がそのIPアドレスを知らなかったら、次はルートネームサーバーに聞きに行く。

ルートネームサーバーは、「www.neko.cat」は知らないが、「.cat」ドメインを管理しているネームサーバーは知っているので、その宛先をフルリゾルバに教える。

続いてフルリゾルバは「.cat」ドメインを管理しているネームサーバーに聞きに行く。そのネームサーバーは、「www.neko.cat」は知らないが「.neko.cat」ドメインは知っているので、その宛先をフルリゾルバに教える。

そしてフルリゾルバは「.neko.cat」ドメインを管理しているネームサーバーに聞きに行き、知りたかった「www.neko.cat」のIPアドレスを教えてもらう。

最後にフルリゾルバがそのIPアドレスを尋ねてきた人に教えてあげることで、Webページにアクセスすることができる。

このように、1つのネームサーバーが全ての情報を知っている訳ではないので、いくつかのネームサーバーに聞きに行くことで知りたい情報を得ることができるようになっている。会社で例えると、1つの部署が全てを管理しているのではなく、いくつかの部署に分担して管理しているとイメージしてもらえれば良い。

※イメージは下記

 ネームサーバーを詳しく

通常、各ネームサーバーは複数台で構成されていることが多い。なぜなら、1台のネームサーバーがダウンした場合でも名前解決できるように冗長構成にしているからである。（とはいえ、私が関わっているプロジェクトはネームサーバーは1台。。。）

ネームサーバーは電話帳にゾーン情報を管理しているが、その「電話帳」のことを「ゾーンファイル」と呼ぶ。このゾーンファイル中には、ドメインとそれに紐づくIPアドレス、つまり「レコード」が記載されている。このレコード情報を確認して、ネームサーバーはフルリゾルバにドメイン情報を教えているのである。

レコードの種類

ゾーンファイルに記載するレコードは7種類ある。

SOAレコード

このレコードには、ゾーンに関する基本的な情報が記述されている。

ネームサーバーのホスト名、管理者のメールアドレス、ゾーン情報を破棄するまでの時間、ネガティブキャッシュの有効期限等が書かれている。

NSレコード

これは、ゾーンを管理するネームサーバーをFQDNで記述している。

ネームサーバーは１つだけでなく複数登録することが可能。

MXレコード

メールサーバーがメールを送るときに参照するレコード。

このゾーンのメールサーバーはこれですよ～と教えている。

このレコードには、プリファレンス値というメールサーバの優先度を示す値が書かれている。数値が小さいほど優先度が高いことを示している。

Aレコード

これは、正引きゾーンファイルで使用されるレコードで、ホスト名に対応するIPアドレスを指定する。（IPv4のみ）

AAAAレコード

IPv6の正引きゾーンファイルで使用されるレコードで、ホスト名に対応するIPアドレスを指定する。

CNAMEレコード

ホストの別名を定義する場合に記述する。

このレコードを指定する場合は、定義した別名を使ってNSレコードを記述しないことに注意しなければならない。

また、複数のCNAMEレコードを記述することも不可。

PTRレコード

IPアドレスに対応するホスト名を記述し、逆引きするときに使用するレコード。

IPアドレスの後に「in-addr.arpa」を付けることに注意する。IPv6の場合は、「ip6.arpa」を付ける。

 

参考文献

• AWSをはじめよう

https://amzn.to/2FLY2AS

• LPICレベル2

https://amzn.to/2FPjxAP