AnsibleでAWSの複数のEC2にWordPressをS3プラグインの設定も行いながら100サイト以上デプロイする方法。

課題

Wordpressで構築されたWEBパッケージを単一サーバのバーチャルホストで提供していました。
1年ほど経過した時点で、200個近くに膨れ上がってしまいました。
また、動画を扱うサービスのためストレージが不足するようになってきました。

柔軟に複数のサーバに同一ドメインのバーチャルホストを分散してデプロイしたら解決すると考えました。

今回の目標は次の通りです。

  • 複数のサーバにバーチャルホストを分散させたい。
  • 低価格サービスなので多重化は行わない。
  • route53の設定も自動化したい。
  • iamの設定も自動化したい。
  • jenkinsでデプロイを自動化したい。
  • S3プラグインを使用して動画・画像はS3に追い出したい。

例として、EC2インスタンスが2台あって以下のようにデプロイするイメージです。

【EC2インスタンス1】
site01.hoge.com
site02.hoge.com
site03.hoge.com
site04.hoge.com
site99.hoge.com

【EC2インスタンス2】
site10.hoge.com
site11.hoge.com
site12.hoge.com
site13.hoge.com

site199.hoge.com

対応

以前作った、単一のEC2にバーチャルホストを追加していくAnsibleのスクリプトをがあります。それを改良して複数ホスト対応にする事にしました。

そのスクリプトはまた別の記事でご紹介したいと思います。

yamlの書き方の考える

以前の方法は、単一サーバに対して複数のroleのパラメータを変えて何度も実行させるという方法でした。しかし、この方法だと複数ホストに異なるバーチャルホストをデプロイすることができません。
単にホストインベントリーにホストを追加しただけだと、全く同一設定のホストが2個できます。Ansibleの使い方としては真っ当ですが、今回の要件に適していません。

site.yml

  roles:
    - common
    - { role: "ec2" }
    - { role: "apache" }
    - { role: "vhost-wordpress",
        vhost_name: "site01" }
    - { role: "vhost-wordpress",
        vhost_name: "site02" }
    - { role: "vhost-wordpress",
        vhost_name: "site03" }

今回はYAMLを以下のように変更しました。

ホストインベントリに複数のサーバを指定します。

hosts

host1
host2

そして各ホストにバーチャルホストのレイアウトを記述します。

host_vars/host1

vhosts:
    site1.hoge.com:
        param1: huga
    site2.hoge.com:
        param1: huga

host_vars/host2

vhosts:
    site10.hoge.com:
        param1: huga
    site11.hoge.com:
        param1: huga

loop内で複数の処理を行う。

各ホストのProvisioningはいつも通りroleで定義した処理を実行させます。
tasksのセクションで各ホスト毎に違った処理を行わせるために、include_tasksを使ってループの内側の処理を実行させます。

---
- hosts: webservers
  become: yes
  become_user: root
  roles:
    - ec2
    - common
    - apache
  tasks:
    - include_vars: vars/defaults.yml
    - name: setup vhost
      include_tasks: tasks/deploy_wp_vhost.yml
        HOST="{{ inventory_hostname }}"
        HOSTNAME="{{ item.key.split('.')[0] }}"
        VHOSTNAME="{{ item.key }}"
        MANAGE_PASSWORD="{{  item.value.manage_password }}"
      with_dict: "{{ hostvars[inventory_hostname].vhosts }}"

Ansibleではloop内に複数の処理を書くことはできません。
別のymlに処理を追い出して、それをincludeすることでloop内の複雑な処理を実行させています。

vhostのサブドメインをroute53に登録したい

設定したバーチャルホストをブラウザで見れる状態にするにはDNSレコードを設定する必要があります。
AnsibleにはAWSのRoute53を操作するモジュールがあります。

- name: route53 update
  route53:
    aws_access_key: "{{ lookup('env', 'AWS_ACCESS_KEY_ID') }}"
    aws_secret_key: "{{ lookup('env', 'AWS_SECRET_ACCESS_KEY') }}"
    state: present
    overwrite: yes
    zone: "{{ R53_ZONE }}"
    record: "{{ VHOSTNAME }}"
    type: A
    ttl: 300
    value: "{{ HOST }}"
  delegate_to: localhost
  become: false
  register: r53_status

delegate_to: localhost という記述があります。これは実行を指定したホストの移譲せよという指定です。
この記述がないとroute53モジュールはリモートのpythonで実行されます。
Ansibleを動かしているホストで実行したい場合は注意しましょう。
レコードが変更されたかどうかは、r53_status.changedで判定できます。

S3バケットを設定する

EC2のサーバのストレージを食いつぶすwordpressのmediaファイルをS3に追い出してしまいたいので、S3のバケットも自動で準備しましょう。

- name: S3バケットを作成しています。 "{{ bucket_name }}"
  s3_bucket:
    name: "{{ bucket_name }}"
    policy: "{{ lookup('template','public.json.j2') }}"
    state: present
    region: ap-northeast-1
    aws_access_key: "{{ lookup('env', 'AWS_ACCESS_KEY_ID') }}"
    aws_secret_key: "{{ lookup('env', 'AWS_SECRET_ACCESS_KEY') }}"
  delegate_to: localhost
  become: false
  register: s3_status

s3_bucketモジュールを使えば簡単です。先程のモジュールと同じでansbileを動作させているホストで実行したいので、同じくdelegate_toを指定してあります。

また、作成したバケットにpublic_readを与えたいので、バケットポリシも同時に指定しています。

public.json.j2

{
  "Version":"2012-10-17",
  "Statement":[{
    "Sid":"PublicReadGetObject",
        "Effect":"Allow",
      "Principal": "*",
      "Action":["s3:GetObject"],
      "Resource":["arn:aws:s3:::{{ bucket_name }}/*"
      ]
    }
  ]
}

JSONファイルもテンプレート化してしまえるのでとても便利です。

バケットごとにIAMを発行して個別にアクセスキーを発行したい

以下、IAMとクレデンシャル取得のyamlの例です。
Ansibleのiamとiam_policyのモジュールを使用しました。
作成したcredentialは変数に格納されます。
初回のみsecret_keyが格納されます。二回目は格納されません。
この動作はAWSコンソールでクレデンシャルを作成したときと同じ動きです。

- name: S3バケットに対応したIAMを作成しクレデンシャル取得
  iam:
    iam_type: user
    name: "{{ VHOSTNAME }}"
    key_count: 1
    access_key_state: create
    state: present
    groups: "{{ IAM_GROUP }}"
  delegate_to: localhost
  become: false
  register: credentials

- name: iamのpolicy設定
  iam_policy:
    iam_type: user
    iam_name: "{{ VHOSTNAME }}"
    policy_name: "s3_limited_access_{{ bucket_name }}"
    policy_json: "{{ lookup( 'template', 's3_policy.json.j2') }}"
    state: present
  delegate_to: localhost
  become: false
  when: credentials.changed

ちなみに、作成したaccess_key, secret_access_keyはこのように取り出せます。

- name: access_keyを保存
  set_fact:
    s3_access_key: "{{ credentials['user_meta']['access_keys'][0]['access_key_id'] }}"
  when: credentials['user_meta']['access_keys'][0]['access_key_id'] is defined

- name: s3_secret_access_keyを保存
  set_fact:
    s3_secret_access_key: "{{ credentials['user_meta']['access_keys'][0]['secret_access_key'] }}"
  when: credentials['user_meta']['access_keys'][0]['secret_access_key'] is defined

is definedでキー存在を確認しています。いきなり値を取り出そうとすると、2回目は存在しないキーをアクセスすることになりますので、エラーが発生してそこで実行が止まってしまいます。

wordpressにAWSのaccess_keyを渡す

もっと行儀よく環境変数で渡すこともできますが、今回はwp_config.php に埋め込む方法をとりました。

- name: copy wordpres config
  become: true
  template:
    src: wp-config-sample.php
    dest: "{{ wp_vhost_path }}/wp-config.php"
    owner: apache
    group: apache
    mode: 0755
  when: s3_secret_access_key is defined

secret_keyが生成された初回のみwp-config.phpをテンプレートから所定の場所にコピーしました。
必要な情報をコード内に埋め込みたかったので以下のようにテンプレート化してあります。

define('DBI_AWS_ACCESS_KEY_ID', '{{ s3_access_key }}');
define('DBI_AWS_SECRET_ACCESS_KEY', '{{ s3_secret_access_key }}');
define('AS3CF_BUCKET', '{{ bucket_name }}');
define('AS3CF_REGION', 'ap-northeast-1');

wordpressのpluginの自動設定

wp_cliを入れてしまえばこっちのものです。以下の例はwp-cliをダウンロードして、/usr/local/bin/ の下に配置します。

- name: install wp-cli
  become: true
  get_url: url=https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
    dest="/usr/local/bin/" validate_certs=no mode=0755

この処理は各ホスト1回だけでいい処理です。

各バーチャルホストの設定のときに
必要なプラグインをinstallしたり。

- name: instlal plugin
  become: yes
  become_user: apache
  shell: "/usr/local/bin/wp-cli.phar --path={{ wp_vhost_path }} plugin install {{ plugin }}"
  with_items:
    - "amazon-web-services"
    - "amazon-s3-and-cloudfront"
  loop_control:
      loop_var: plugin
  when: db_created.changed

プラグインを有効にしたり、

- name: activate plugin
  become: yes
  become_user: apache
  shell: "/usr/local/bin/wp-cli.phar --path={{ wp_vhost_path }} plugin activate {{ plugin }}"
  with_items:
    - "amazon-web-services"
    - "amazon-s3-and-cloudfront"
  loop_control:
      loop_var: plugin
  when: db_created.changed

そして、プラグインの設定を更新したりできます。

- name: config plugin
  become: yes
  become_user: apache
  shell: "/usr/local/bin/wp-cli.phar --path={{ wp_vhost_path }} option update tantan_wordpress_s3 '{{ lookup('template', 'tantan_wordpress_s3_option.json') }}' --format=json"
  when: db_created.changed

wp-cliでプラグインの設定をJSONでDBに書き込むことができます。

{
  "post_meta_version": 6,
  "region": "",
  "domain": "path",
  "cloudfront": "",
  "object-prefix": "wp-content\/uploads\/",
  "copy-to-s3": "1",
  "serve-from-s3": "0",
  "remove-local-file": "0",
  "force-https": "0",
  "object-versioning": "1",
  "use-yearmonth-folders": "1",
  "enable-object-prefix": "1"
}

成果

  • virtual hostの設定をyamlに記述することができる。
  • bitbucket/githubのwebhookでJenkinsと連携しAnsibleを叩ける
  • AWSコンソールを一切触らなくても良くなりました。
  • インフラの知識がない担当者もとりあえずPullRequestを作成できればサイトを一つ増やすことができるようになりました。

続きを読む

[AWS,EC2]初期設定(インスタンス作成,SSH接続,料金のモニタリング)

AWSのアカウントを作成

https://qiita.com/Hikery/items/b919ae9e35f0f66e6a95

インスタンス作成

Step1 サービス > EC2 を選択

ec2.jpg

Step2 localの変更

time.jpg

Step3 マシーンイメージの選択

insutance.jpg

Step4 インスタンスタイプの選択

i_type.jpg

Step5 セキュリティグループの設定

・インスタンス設定
・ストレージ追加
はそのままで
・タグの追加 は適当にtagをつける。

セキュリティグループの設定 は HTTP を追加する。
security.jpg

Step6 キーペアを選択する

key2.jpg

鍵をDownloadして、インスタンスの作成をする。

SSH で繋いでみる

Step1 –

接続をおす
i_ssh_1.jpg

スタンドアロン SSH クライアント
i_ssh_1.jpg

Step2 – .pem fileを .ssh配下に配置する

terminal
$ mv /Users/[user name]/Downloads/***.pem /Users/[user name]/.ssh
$ chmod 600 football_chant.pem
$ ssh -i "***.pem" ec2-user@ec2-**-***-**-***.ap-northeast-1.compute.amazonaws.com
The authenticity of host 'ec2-**-***-**-***.ap-northeast-1.compute.amazonaws.com (**.***.**.***)' can't be established.
ECDSA key fingerprint is SHA***:*******************************************.
Are you sure you want to continue connecting (yes/no)?

yesを選択する。

terminal
Warning: Permanently added 'ec2-**-***-**-****.ap-northeast-1.compute.amazonaws.com,**.***.**.***' (ECDSA) to the list of known hosts.

       __|  __|_  )
       _|  (     /   Amazon Linux AMI
      ___|\___|___|

https://aws.amazon.com/amazon-linux-ami/2017.09-release-notes/

環境によっては

terminal
$ sudo yum update

料金をモニターする

画面で料金を確認

右上のアカンウトクリック > 請求ダッシュボード
https://console.aws.amazon.com/billing/home#/
こんな感じで見れます。
price2.jpg

使用した料金をメールで受け取る。

https://console.aws.amazon.com/billing/home#/preference
とりあえず、全部受け取るようにする。
setting.jpg

請求アラートを管理する

“請求アラートを管理する”にLinkする。

アラート.jpg

アラームを作成

make.jpg

メトリック設定

メトリック : 請求
チェック : USD
時間 : 6時間
setting2.jpg

アラームの定義

0$を超えた時、0$に戻った時を指定します。
setting6.jpg

また心配であれば5ドルや10ドルを超えた時点でもアラートを出すと良いかと思います。

参考

AWSアカウントの保護

アカウントのセキュリティ保護のために下記の記事を参考に、
MFAデバイス認証をいれました。

https://qiita.com/tmknom/items/303db2d1d928db720888

料金

初心者なので、これは気をつけようと思いました。参考になります。
https://qiita.com/mochizukikotaro/items/a0e98ff0063a77e7b694

RDSでMySQLを起動させ、EC2のインスタンスにつなぐ

下記を参考にした。
https://qiita.com/na0AaooQ/items/7c69a88c80f1efb4cad3
https://qiita.com/hiroshik1985/items/6643b7323183f82297b2

続きを読む

センサデータを fluentd 経由で Amazon Elasticsearch Service に送信して可視化

1. はじめに

以前の記事 で、RaspberryPi で収集したセンサデータを、 さくらVPS上に構築した Elasticsearch に送信して、Kibana で可視化しました。
今回は勉強を兼ねて、データを Amazon Elasticsearch Service ( Amazon ES ) に送信するように構成を変更します。

2. 全体の構成

image.png

3. 設定

3-1. Server side ( Amazon ES )

Amazon ES を立ち上げます。

Amazon ES ダッシュボード

  • 画面右上で、東京リージョン( ap-northeast-1 )が選択されていることを確認します
  • 新しいドメインの作成ボタンを押します
image

ドメインの定義

  • ドメイン名と Elasticsearch のバージョンを設定します
image

クラスターの設定

  • 今回は最小構成にします
image

アクセスの設定

  • ダッシュボードは特定メンバーに公開したかったので、パブリックアクセスとして、IPアドレスでアクセス制限を設定しました
  • 本当は IAM Role で制限したかったのですが、Webブラウザからのアクセスが面倒になるので今回は見送りました ( ブラウザはIAM認証できない )
image

完了確認

  • 10分ほど待ちます
image
  • 設定の状態が「アクティブ」になれば完了です
image

3-2. Sensor side ( Raspberry PI )

前提条件

以前の記事 の状態が前提です。今回はこれに変更を加えます。

プラグインのインストール

  • fluentd から Elasticsearch に直接格納するためのプラグインをインストールします
  • なお、IAM 認証をする場合は fluent-plugin-aws-elasticsearch-service を使うようです
sudo fluent-gem install fluent-plugin-elasticsearch

fluentd の設定

  • fluentd の設定ファイルを編集して、データの送信先を変更して、fluentd を再起動します
/home/pi/fluent/fluent.conf
<source>
  @type tail
  format json
  path /home/pi/myroom.log
  pos_file /home/pi/myroom.log.pos
  tag log.myroom
</source>

<match log.myroom>
  @type copy
  <store>
    @type elasticsearch
    type_name myroom
    logstash_format true
    logstash_prefix myroom
    reload_connections false
    hosts https://search-myroom-********.ap-northeast-1.es.amazonaws.com
  </store>
</match>

4. 確認

データが送信されていることを確認しました。
image.png

続きを読む

RaspberryPi で収集したセンサデータを Amazon ES に格納

1. はじめに

前回の記事 では、RaspberryPi で収集したセンサデータを、 さくらVPS上に構築した Elasticsearch に格納しました。
今回は勉強を兼ねて、データを Amazon Elasticsearch Service ( Amazon ES ) に格納するように構成変更します。

2. 全体の構成

image.png

3. 設定

3-1. Server side ( Amazon ES )

Amazon ES を立ち上げます。今回はそれだけです。

Amazon ES ダッシュボード

  • 画面右上で、東京リージョン( ap-northeast-1 )が選択されていることを確認します
  • ドメインの作成ボタンを押します
image

ドメインの定義

  • ドメイン名と Elasticsearch のバージョンを設定します
image

クラスターの設定

  • 今回は最小構成にします
image

アクセスの設定

  • ダッシュボードは特定メンバーに公開したかったので、パブリックアクセスとして、IPアドレスでアクセス制限を設定しました
  • 本当は IAM Role で制限したかったのですが、Webブラウザからのアクセスが面倒になるので今回は見送りました ( ブラウザはIAM認証できない )
image

完了確認

  • 10分ほど待ちます
image
  • 設定の状態が「アクティブ」になれば完了です
image

3-2. Sensor side ( Raspberry PI )

前提条件

以前の記事 の状態が前提です。今回はこれに変更を加えます。

プラグインのインストール

  • fluentd から Elasticsearch に直接格納するためのプラグインをインストールします
  • なお、IAM 認証をする場合は fluent-plugin-aws-elasticsearch-service を使うようです
sudo fluent-gem install fluent-plugin-elasticsearch

fluentd の設定

  • fluentd の設定ファイルを編集して、データの送信先を変更して、fluentd を再起動します
/home/pi/fluent/fluent.conf
<source>
  @type tail
  format json
  path /home/pi/myroom.log
  pos_file /home/pi/myroom.log.pos
  tag log.myroom
</source>

<match log.myroom>
  @type copy
  <store>
    @type elasticsearch
    type_name myroom
    logstash_format true
    logstash_prefix myroom
    reload_connections false
    hosts https://search-myroom-q6f5bk4cwppojeescffv24dmkm.ap-northeast-1.es.amazonaws.com
  </store>
</match>

4. 確認

データが送信されていることを確認しました。
image.png

続きを読む

AWS EC2でHyperledger Fabricを動かす(AWS準備編)

AWSにUbuntuをセットアップし、FabricをDockerで起動してみたいと思います。
普段はVirtualBox内のUbuntuでFabricを動かしていて、AWSを触るのは初めて。
果たして最後までできるのかわかりませんが、とりあえず始めてみます。

今回はAWSでサーバを準備する手順をメモ。
大きく分けると以下の手順を実行します。

  1. EC2インスタンス作成〜起動
  2. SSH設定変更
  3. ターミナルからインスタンスへ接続する

1. EC2インスタンス作成〜起動

ログインしてコンソールを表示、仮想マシンの起動を選択します
Image 2018-01-05 18-06-33.jpg

EC2インスタンスを今すぐ始めます
Image 2018-01-05 18-01-53.jpg

適当な名前を入力してください
Image 2018-01-05 18-08-51.jpg

Ubuntu Server 16.04 LTSを選択して続行します
Image 2018-01-05 18-09-49.jpg

インスタンスタイプは無料枠のtc2.microのまま、続行します
Image 2018-01-07 16-31-54.jpg

キーペアに適当な名前を入力してファイルをダウンロードします
ダウンロードしたファイルは、~/.ssh ディレクトリに保管しましょう
Image 2018-01-05 18-12-55.jpg

インスタンスを作成します
Image 2018-01-05 18-13-42.jpg

作成には数分かかります
さきにEC2コンソールへ移動しましょう
Image 2018-01-05 18-14-20.jpg

ステータスがrunningになったら作成完了です
Image 2018-01-07 16-35-28.jpg

ここでSSHログイン試行するも、タイムアウトで接続できず。
軽く調べたところ、SSHの設定の変更が必要?とのこと。
次の手順でセキュリティグループの設定を変更します。

2. SSH設定変更

インスタンスを選択すると詳細が下の方に表示されます
この中から、セキュリティグループを選択します
Image 2018-01-07 16-33-49.jpg

SSHのインバウンドのソースが特定のネットワークに限定されているため解除します
編集を選択します
Image 2018-01-07 16-39-34.jpg

ソースを任意の場所に設定して保存します
Image 2018-01-07 15-56-24.jpg

3. ターミナルからインスタンスへ接続する

インスタンス作成時に保存したキーペアファイルが~/.sshディレクトリにコピーされている前提です。
権限を編集してからsshで繋ぎます。
AWSのUbuntuでは、ubuntuがデフォルトユーザになります。
アクセス先のIPアドレスは、インスタンスの「パブリックDNS(IPv4)」です。

$ chmod 400 .ssh/user1.pem 
$ ssh -i ".ssh/user1.pem" ubuntu@ec2-xx-xx-xx-xx.us-east-2.compute.amazonaws.com
The authenticity of host 'ec2-xx-xx-xx-xx.us-east-2.compute.amazonaws.com (xx-xx-xx-xx)' can't be established.
ECDSA key fingerprint is SHA256:xxxxxxxxxxxxx.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'ec2-xx-xx-xx-xx.us-east-2.compute.amazonaws.com,xx-xx-xx-xx' (ECDSA) to the list of known hosts.
Welcome to Ubuntu 16.04.3 LTS (GNU/Linux 4.4.0-1043-aws x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/advantage

  Get cloud support with Ubuntu Advantage Cloud Guest:
    http://www.ubuntu.com/business/services/cloud

0 packages can be updated.
0 updates are security updates.



The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.

To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.

ubuntu@ip-xx-xx-xx-xx:~$ pwd
/home/ubuntu

AWS EC2のUbuntu 16.04に、SSHでログインできました。

次は、Fabricを起動できればと思います。

続きを読む

PHPでFlysystemのAwsS3AdapterをS3互換サービスで使うときにハマったこと

ハマった時の状況

  • Laravelを使ってる
  • 環境はDockerで構築
  • S3互換サービスはDocker上のminio

結論

use_path_style_endpointをtrueにするとサブドメインを使わずにバケットを指定することができる

タイムライン

  • LaravelからS3にアップロードしたい
  • S3だけローカルから外すのはびみょい
  • テスト環境としてminioを選択
  • minioをdocker-composeに追加してみる
  • 一通りの設定をして、接続してみる
  • バケット名がサブドメインになるので、docker-composeでの名前解決に失敗する
  • 取り急ぎhostsに名前書いて名前解決できるようにする
  • 依然としてエラー そのようなバケットはありませんと言われる
  • minioのブラウザ側でバケットを作成
  • それでもエラー・・・ よく見るとエラー対象のバケット名が入っていない
  • ひょっとして、サブドメインでバケット名拾えない?
  • ネットの海を彷徨う
  • force_path_styleという設定をrubyのコードないで見つける
  • ダメ元で設定を追加してみる、ダメっぽい
  • AwsS3Adapterのオプションにuse_path_style_endpointというのを見つける
  • 上記オプションをオンにすることで接続が成功

続きを読む

Route53でドメイン買ってACMでSSL証明書発行してCloudFrontでGithub Pageと買ったドメインと紐付けた

なにこれ

タイトル通りの手順です。流れなので長いのはお許しください。

0からでもうまいことやれたので備忘録として書きました。参考までにどうぞ。


事前準備

  • AWSへのアカウント登録関連は完了しておく

    • メール認証・クレカ登録などお忘れなく
  • Github Page 作成
    • 無料垢でもOK

Route53でドメインを買う

  • Route53にアクセス。
  • 「Register Domain」ボタンよりドメイン購入手続き
    Screenshot from Gyazo

  • 購入したいドメイン名を入力
  • 欲しいTLD(.com, .net, .orgなど)を選択
  • 「Check」ボタンより購入可能なドメインを検索

Screenshot from Gyazo


  • 「Add to cart」で欲しいドメインをカートに追加
  • ページ下部の「Continue」ボタンで次へ

Screenshot from Gyazo


  • 購入者入力画面で各種入力

Screenshot from Gyazo


  • 入力後、問題なければ「Continue」ボタンで確認画面に遷移
  • 「Terms and Conditions」の同意確認箇所にチェックを入れ、「Complete Purchase」ボタンで購入確定へ

Screenshot from Gyazo


  • メールにて購入完了の旨を受け取る。ドメイン購入はこれにて完了。

    • 下図は実際に買ったときのやつ
  • AWS Certificate Managerに移動

Screenshot from Gyazo


AWS Certificate Manager

  • 右上のリージョンが「バージニア北部」になっていることを確認

    • なっていなかったら選択
    • CloudFrontで使用する際に必要
      Screenshot from Gyazo

  • 「証明書のリクエスト」をクリック

Screenshot from Gyazo


  • ドメイン名の追加で先程購入したドメインを入力して「次へ」をクリック

Screenshot from Gyazo


  • 証明書のリクエスト検証はDNSにして「次へ」をクリック

Screenshot from Gyazo


  • 確認で問題なければ「確定とリクエスト」ボタンをクリック。

Screenshot from Gyazo

  • その後遷移する確定後の画面より「続行」ボタンをクリック。

  • ダッシュボードに遷移して、検証保留中になっているのを確認したらCloudFrontに移動

Screenshot from Gyazo


CloudFront

  • 「Distributions」ダッシュボードが開いているのを確認して、「Create Distribution」をクリック

Screenshot from Gyazo


  • Webの方の「Get Started」をクリック

Screenshot from Gyazo


01. Origin Settings

  • 「Origin Domain Name」に自分のgithub pageを入力

    • ここではgithub pageのURL=インデックスページという想定です

Screenshot from Gyazo


02. Default Cache Behavior Settings

  • 「Viewer Protocol Policy」をRedirect HTTP to HTTPS
  • 「Cache Based on Selected Request Headers」をWhitelist
  • 「Whitelist Headers」でHostsをAdd

Screenshot from Gyazo


03. Distribution Settings

  • 「Alternate Domain Names(CNAMEs)」 に適応させるドメインを入力
  • 「SSL Certificate」はCustom SSL Certificateを選択
    • このときAWS Certificate Managerで作成したSSL証明書が選択できると思うのでそれを選択

Screenshot from Gyazo


  • 01~03までを入力したら「Create Distribution」ボタンをクリック
  • その後生成された「Domain Name」(dから始まるやつ)のURLをコピー
    Screenshot from Gyazo
  • コピーしたURLが見れる状態になってるかを確認
  • アクセスできるのを確認したらRoute53に戻る

Route53

  • 左メニューより「Hosted Zones」を選択、ダッシュボードに購入したドメイン名あるのでクリック
  • 「Create Record Set」ボタンをクリック

Screenshot from Gyazo


  • Nameは空でOK
  • TypeはA
  • AliasはYesをチェック
    • Alias Targetに先程コピーしたURLを貼る
  • 「Save Record Set」クリックで追加

Screenshot from Gyazo


Github Page

  • GitHub Pagesのリポジトリに移動
  • 「Settings」タブより設定ページに移動

Screenshot from Gyazo


GitHub Pages

  • 「Custom domain」箇所に購入したドメインを入力、Save

    • DNSの浸透がまだだとはじかれるかもなので、10分くらい待つのとか、CloudFrontのStatusがDeployedになっているかなど確認した上でやる

Screenshot from Gyazo


反映を確認

:tada::tada::tada:

Screenshot from Gyazo


感想

  • AWS、自分で1から触るのは始めてなのでDNS浸透なり証明書が無効だったりと色々ありしんどかった。
  • ただここまでやっておけばある程度動かせる下地ができる感じなのでやっておいてよかった
  • ドメイン買うのももっと安くやる方法もあるだろうけど、AWSサービス間で設定するなら全部まとめてやるのが分かりやすいかなと思ったのでこの手法で良かったと思う

参考

続きを読む

ELB(CLB)へのEC2インスタンスのアタッチ/デタッチをAnsibleで手軽に

はじめに

ELB配下のサーバをメンテナンス時にデタッチしてまたアタッチするという運用をされている方は多いと思います。

ELBへのデタッチ/アタッチ操作をメンテナンスのたびに行うこと自体、モダンではないことはわかっていますが、そんな温かみのある運用をすぐに捨てられない以上、操作をAnsbleで自動化することにより、手作業やコマンドのコピペミスによる事故を防ぐ効果はあると思います。

SSL証明書の関係で1つのEC2インスタンスが複数のELBにアタッチされている場合などは特に威力を発揮するかと。
今回はとりあえずCLBです。

概要

  • ELB(CLB)に定義したEC2インスタンスをアタッチ
  • 定義したEC2インスタンスと実際にアタッチされているEC2インスタンスの差分を取得
  • 上記差分EC2インスタンスをELB(CLB)からデタッチ
  • 結果を出力

ポイント

  • varsにはELBにアタッチしたいEC2インスタンスIDを定義しておく

    • デタッチの際は一時的にコメントアウトする
  • AnsibleによるEC2インスタンスのアタッチは冪等性が担保されるため、実行することで定義した通りになる
  • 定義と実際のELBにアタッチされたEC2インスタンスの差分=デタッチすべきEC2インスタンスとなる

注意

EC2インスタンスが1つも定義されていない場合は、アタッチ処理でエラーとなります。
エラーハンドリングを実装していないためですが、実際の運用では事故になるため、あえて実装していません。

前提

  • AWS関連のモジュール実行にはbotoが必要です。
  • Ansible環境はvirtualenvで用意することとします。
  • credential情報は環境変数でセットしてある必要があります。

sample

ディレクトリ構成

ディレクトリ構成
site.yml
inventories/
|--aws
roles/
|--elb/
|  |--tasks/
|  |  |--main.yml
group_vars/
|--group.yml

inventory

インベントリにはターゲットホストを記載しますが、AWSモジュールはlocalhostで実行されるため全てansible_host=localhostとなります。
グループ、ホスト名は実行時に読み込まれるgroup_vars,host_vars(今回は未使用)を切り替えるために利用します。
varsに記載したELB全てに対して処理を実行するため、作業単位にグループを分けるといいでしょう。
ansible_python_interpreter=pythonは、virtualenv環境でpip installしたbotoモジュールを読み込むために指定しています。

inventories/aws
[all:vars]
ansible_connection=local
ansible_python_interpreter=python
ansible_host=localhost

[elb_production]
production

[elb_staging]
staging

vars

こんな感じに変数を定義します。

group_vars/elb_production.yml
---
my_vars:
  aws:
    common:
      region: ap-northeast-1
    elb:
      - name: production_elb01
        instances:
          - i-XXXXXXXXXXXXXXXXX #server01
          - i-XXXXXXXXXXXXXXXXX #server02
      - name: production_elb02
        instances:
          - i-XXXXXXXXXXXXXXXXX #server01
          - i-XXXXXXXXXXXXXXXXX #server02

Role

  • まず、varsに定義されたEC2インスタンスをそれぞれのELBにアタッチします。すでにアタッチ済みのものはAnsibleによりスキップされます。
  • 次に、ec2_elb_factsモジュールにより、ELBにアタッチされているEC2インスタンス情報を取得します。
  • 取得したEC2インスタンス情報と、varsに定義されたEC2インスタンスとの差分をdifferenceフィルタで取得し、elb_diff_listを作成します。これらは、ELBにアタッチされているが、varsには定義されていないEC2インスタンスなのでデタッチ対象となります。
  • elb_diff_listに基づいてデタッチを実行します。
  • 再度ec2_elb_factsモジュールにより、ELBにアタッチされているEC2インスタンス情報を取得します。
  • debugモジュールで結果を出力します。
roles/elb/tasks/main.yml
---
- name: ELBにインスタンスをアタッチ
  ec2_elb:
    instance_id: "{{ item.1 }}"
    ec2_elbs: "{{ item.0.name }}"
    state: present
  with_subelements:
    - "{{ my_vars.aws.elb }}"
    - instances

- name: Gathering ELB facts
  ec2_elb_facts:
    region: "{{ my_vars.aws.common.region }}"
    names: "{{ item.name }}"
  register: elb_facts
  with_items: "{{ my_vars.aws.elb }}"

- name: ELBアタッチ済みインスタンスとvarsの差分からデタッチ対象インスタンスlist作成
  set_fact:
    elb_diff_list: >-
      {%- set tmplist = [] -%}
      {%- for i in range(elb_facts.results|length) -%}
      {%-   set diffelb = elb_facts.results[i].elbs[0].instances | difference(my_vars.aws.elb[i].instances) -%}
      {%-   set tmpelb = {"name": elb_facts.results[i].elbs[0].name, "instances": diffelb } -%}
      {%-   set _ = tmplist.append(tmpelb) -%}
      {%- endfor -%}
      {{ tmplist }}

- debug: var=elb_diff_list

- name: ELBからインスタンスをデタッチ
  ec2_elb:
    instance_id: "{{ item.1 }}"
    ec2_elbs: "{{ item.0.name }}"
    state: absent
  with_subelements:
    - "{{ elb_diff_list }}"
    - instances

- name: Gathering ELB facts
  ec2_elb_facts:
    region: "{{ my_vars.aws.common.region }}"
    names: "{{ item.name }}"
  register: elb_facts_result
  with_items: "{{ my_vars.aws.elb }}"

- name: 結果出力
  debug:
    msg: "Result: {{ item.elbs[0].name }}: {{ item.elbs[0].instances }}"
  with_items: "{{ elb_facts_result.results }}"

site.yml

site.yml
---
- name: elb
  hosts: elb-production
  connection: local
  roles:
    - role: elb
  tags:
    - elb

実行

実行
$ ansible-playbook -i inventories/aws -l elb_production site.yml

実際の作業イメージ

server01を2台のELBからデタッチする

デタッチ対象のインスタンスをvars上でコメントアウトする

group_vars/elb_production.yml
---
my_vars:
  aws:
    common:
      region: ap-northeast-1
    elb:
      - name: production_elb01
        instances:
#          - i-XXXXXXXXXXXXXXXXX #server01 デタッチするインスタンスをコメントアウト
          - i-XXXXXXXXXXXXXXXXX #server02
      - name: production_elb02
        instances:
#          - i-XXXXXXXXXXXXXXXXX #server01 デタッチするインスタンスをコメントアウト
          - i-XXXXXXXXXXXXXXXXX #server02

 server01デタッチ実行

server01デタッチ実行
$ ansible-playbook -i inventories/aws -l elb_production site.yml

 server01をメンテナンス

再起動など

メンテナンス完了したserver01を2台のELBに再びアタッチする

メンテナンス完了したインスタンスをvars上でコメントインする

group_vars/elb_production.yml
---
my_vars:
  aws:
    common:
      region: ap-northeast-1
    elb:
      - name: production_elb01
        instances:
          - i-XXXXXXXXXXXXXXXXX #server01 アタッチするインスタンスをコメントイン
          - i-XXXXXXXXXXXXXXXXX #server02
      - name: production_elb02
        instances:
          - i-XXXXXXXXXXXXXXXXX #server01 アタッチするインスタンスをコメントイン
          - i-XXXXXXXXXXXXXXXXX #server02

 server01アタッチ実行

server01アタッチ実行
$ ansible-playbook -i inventories/aws -l elb_production site.yml

server02についても同様に

まとめ

いかがでしょうか。あくまでvars上でアタッチ/デタッチ対象を制御するため、シェルスクリプトに引数で対象を渡すより安全に実行できるのではないでしょうか。
普段からAnsibleを利用している環境なら、このようなアドホックな操作をAnsible化するのもありかと思います。
ALB版もそのうち書きたいと思います(ALB移行しなきゃ……)。

参考

AnsibleでAWSリソースを管理するシリーズ

続きを読む

AWSでElastic Stack – 前回の続き Kibana Filebeatのアップグレード

はじめに

前回、KibanaとFilebeatもアップグレードするような記事を書いたのですが、途中で力尽きてElasticsearchのアップグレードで終わってしまったので、短くなりますが、KibanaとFilebeatもアップグレードしたいと思います。
前回の記事(前回中途半端で申し訳ないですが)の構成を参照して頂ければと思います。

AWSの小ネタ

本題とは関係ありませんが、一応AWSタグを付けているので、AWSで悩んだ話について。

IAMロールで起動したEC2インスタンスのプロキシ環境下にて、プロキシサーバのログに以下のログが大量に出力されていました。

TCP_MISS/404 609 GET http://169.254.169.254/latest/meta-data/network/interfaces/macs/xx:xx:xx:xx:xx:xx/local-ipv4s - HIER_DIRECT/169.254.169.254 text/html

それでxxになっているMACアドレスを持つサーバを調べると以下のログが連続して大量に出力されていました。

ec2net: [get_meta] Trying to get http://169.254.169.254/latest/meta-data/network/interfaces/macs/xx:xx:xx:xx:xx:xx/local-ipv4s

恐らくec2がmetadataを取りにいくのですが、プロキシサーバを経由してしまうせいで、
ご本人じゃありませんよとAWSのmetadataサーバに拒否されているんでしょうと推測しました。

プロキシ環境下では169.254.169.254はプロキシを経由しないようにNO_PROXYの設定を設定します。
http://docs.aws.amazon.com/ja_jp/cli/latest/userguide/cli-http-proxy.html

自分もこの設定を入れていましたので、設定が有効になっていないかと悩まされることになりました。そこで一旦、exportしているプロキシの設定を削除しましたが、
やっぱりプロキシサーバを経由することを止められませんでした。

そこで他のプロキシを利用する設定を考えたところ、そういえば最初は全てのアクセスをプロキシ経由にするつもりが無くて、yumやwget,curlくらいしかInternetへのアクセスをしないので、それぞれのコンフィグにプロキシの設定を個別に書いていたなと思い至りました。

それで結局当たったのは、curlの.curlrcのプロキシの設定でした。
ここにはNO_PROXYの設定は書いていませんでした。
ここの設定が有効でプロキシサーバ経由でアクセスしているとは・・
ec2がmetadataを取得する際にはcurlで取りにいっているってことですかね?(分かってない)

1.アップグレード作業

では前回やり残したKibanaとFilebeatのアップグレード作業を実施したいと思います。

1.1.事前準備

公式のドキュメントを参考にしながら進めていきます。
Kibana
https://www.elastic.co/guide/en/kibana/current/rpm.html
Filebeat
https://www.elastic.co/guide/en/beats/filebeat/current/setup-repositories.html

あれ・・・前回見た時は6.0だったのに、どんどん更新されていきますね。

1.1.1.GPGキーのインストール

KibanaとFilebeatをインストールしているそれぞれのサーバにて実施します。

Kibanaをインストールしたサーバ(srv1)

# rpm --import https://artifacts.elastic.co/GPG-KEY-elasticsearch

Filebeatをインストールしたサーバ(srv4)

# rpm --import https://packages.elastic.co/GPG-KEY-elasticsearch

1.1.2.リポジトリの修正

6.0系のリポジトリを用意します。

Kibana

# vi /etc/yum.repos.d/kibana.repo
[kibana-6.x]
name=Kibana repository for 6.x packages
baseurl=https://artifacts.elastic.co/packages/6.x/yum
gpgcheck=1
gpgkey=https://artifacts.elastic.co/GPG-KEY-elasticsearch
enabled=1
autorefresh=1
type=rpm-md

Filebeat

# vi /etc/yum.repos.d/beats.repo
[elastic-6.x]
name=Elastic repository for 6.x packages
baseurl=https://artifacts.elastic.co/packages/6.x/yum
gpgcheck=1
gpgkey=https://artifacts.elastic.co/GPG-KEY-elasticsearch
enabled=1
autorefresh=1
type=rpm-md

1.2.アップグレード

Kibana

# yum update kibana
Loaded plugins: priorities, update-motd, upgrade-helper
42 packages excluded due to repository priority protections
Resolving Dependencies
--> Running transaction check
---> Package kibana.x86_64 0:5.6.2-1 will be updated
---> Package kibana.x86_64 0:6.1.1-1 will be an update
--> Finished Dependency Resolution

Dependencies Resolved

==============================================================================================================================
 Package                     Arch                        Version                        Repository                       Size
==============================================================================================================================
Updating:
 kibana                      x86_64                      6.1.1-1                        kibana-6.x                       63 M

Transaction Summary
==============================================================================================================================
Upgrade  1 Package

Total download size: 63 M
Is this ok [y/d/N]: y

Filebeat

# yum update filebeat
Loaded plugins: priorities, update-motd, upgrade-helper
Resolving Dependencies
--> Running transaction check
---> Package filebeat.x86_64 0:1.3.1-1 will be updated
---> Package filebeat.x86_64 0:6.1.1-1 will be an update
--> Finished Dependency Resolution

Dependencies Resolved

===================================================================================================================================================================================================
 Package                                        Arch                                         Version                                       Repository                                         Size
===================================================================================================================================================================================================
Updating:
 filebeat                                       x86_64                                       6.1.1-1                                       elastic-6.x                                        12 M

Transaction Summary
===================================================================================================================================================================================================
Upgrade  1 Package

Total download size: 12 M
Is this ok [y/d/N]: y

1.3.サービスの再起動

Kibana

# service kibana restart
kibana started

Filebeat

 service filebeat restart
2017/12/25 08:46:58.653044 beat.go:436: INFO Home path: [/usr/share/filebeat] Config path: [/etc/filebeat] Data path: [/var/lib/filebeat] Logs path: [/var/log/filebeat]
2017/12/25 08:46:58.653113 metrics.go:23: INFO Metrics logging every 30s
2017/12/25 08:46:58.653234 beat.go:443: INFO Beat UUID: 1267efb0-a1af-4f02-9e18-d7120d6bc2bc
2017/12/25 08:46:58.653256 beat.go:203: INFO Setup Beat: filebeat; Version: 6.1.1
2017/12/25 08:46:58.653386 client.go:123: INFO Elasticsearch url: http://192.100.0.4:9200
2017/12/25 08:46:58.653586 module.go:76: INFO Beat name: ip-192-100-0-36
Config OK
Stopping filebeat:                                         [  OK  ]
Starting filebeat: 2017/12/25 08:46:58.773001 beat.go:436: INFO Home path: [/usr/share/filebeat] Config path: [/etc/filebeat] Data path: [/var/lib/filebeat] Logs path: [/var/log/filebeat]
2017/12/25 08:46:58.773063 metrics.go:23: INFO Metrics logging every 30s
2017/12/25 08:46:58.773112 beat.go:443: INFO Beat UUID: 1267efb0-a1af-4f02-9e18-d7120d6bc2bc
2017/12/25 08:46:58.773132 beat.go:203: INFO Setup Beat: filebeat; Version: 6.1.1
2017/12/25 08:46:58.773280 client.go:123: INFO Elasticsearch url: http://192.100.0.4:9200
2017/12/25 08:46:58.773479 module.go:76: INFO Beat name: ip-192-100-0-36
Config OK
                                                           [  OK  ]

1.4.確認

KibanaとFilebeatのバージョンやログが取れているか等確認します。

Filebeatアップグレード前

# filebeat -version
filebeat version 1.3.1 (amd64)

Filebeatアップグレード後

# filebeat -version
filebeat version 6.1.1 (amd64), libbeat 6.1.1

Kibanaアップグレード前
kibana-version.png

kibanaアップグレード後
kibana6.1ver.png

あ~~ elasticsearchとバージョンが一致しないって怒られてますね。
マイナーバージョンも一致が必要なのは作業的に面倒ですね・・

というわけでまた前回の記事と同じようにアップグレードしてきました。

# curl -XGET 'localhost:9200/'
{
  "name" : "node001",
  "cluster_name" : "my-cluster",
  "cluster_uuid" : "e06BKBFFSpiSkFwNT3kWLw",
  "version" : {
    "number" : "6.1.1",
    "build_hash" : "bd92e7f",
    "build_date" : "2017-12-17T20:23:25.338Z",
    "build_snapshot" : false,
    "lucene_version" : "7.1.0",
    "minimum_wire_compatibility_version" : "5.6.0",
    "minimum_index_compatibility_version" : "5.0.0"
  },
  "tagline" : "You Know, for Search"
}

# curl -XGET 'http://localhost:9200/_cat/plugins?v'
name    component         version
node002 analysis-kuromoji 6.1.1
node002 x-pack            6.1.1
node003 analysis-kuromoji 6.1.1
node003 x-pack            6.1.1
node001 analysis-kuromoji 6.1.1
node001 x-pack            6.1.1

改めてKibanaを確認してみます。

kibana6-1.png

エラー直りました。通常のログイン後の画面に。
先ほどのエラー画面だから画面の色合いが違うのかと思っていたのですが、普通に落ち着いた感じになっております。
改めてバージョンを確認します。

kibana_ver6-1.png

OKですね。

では、次にfilebeatからデータが送られているかを確認します。

filebeat1.png

(新しいデータが)有りません

そこでfilebeatのログを確認してみたところ・・・

2017-12-27T07:53:01Z INFO Home path: [/usr/share/filebeat] Config path: [/etc/filebeat] Data path: [/var/lib/filebeat] Logs path: [/var/log/filebeat]
2017-12-27T07:53:01Z INFO Beat UUID: 1267efb0-a1af-4f02-9e18-d7120d6bc2bc
2017-12-27T07:53:01Z INFO Metrics logging every 30s
2017-12-27T07:53:01Z INFO Setup Beat: filebeat; Version: 6.1.1
2017-12-27T07:53:01Z INFO Elasticsearch url: http://192.100.0.4:9200
2017-12-27T07:53:01Z INFO Beat name: ip-192-100-0-36
2017-12-27T07:53:01Z INFO filebeat start running.
2017-12-27T07:53:01Z INFO Registry file set to: /var/lib/filebeat/registry
2017-12-27T07:53:01Z INFO Loading registrar data from /var/lib/filebeat/registry
2017-12-27T07:53:01Z INFO Total non-zero values:  beat.info.uptime.ms=3 beat.memstats.gc_next=4473924 beat.memstats.memory_alloc=3081016 beat.memstats.memory_total=3081016 filebeat.harvester.open_files=0 filebeat.harvester.running=0 libbeat.config.module.running=0 libbeat.output.type=elasticsearch libbeat.pipeline.clients=0 libbeat.pipeline.events.active=0 registrar.states.current=0
2017-12-27T07:53:01Z INFO Uptime: 3.375689ms
2017-12-27T07:53:01Z INFO filebeat stopped.
2017-12-27T07:53:01Z CRIT Exiting: Could not start registrar: Error loading state: Error decoding states: json: cannot unmarshal object into Go value of type []file.State

なんかエラー出て、filebeatが起動していない感じですかね。
そのエラーについて調べてみたところ、同じような状態になった方がおり、解決されていました。
https://discuss.elastic.co/t/exiting-could-not-start-registrar-error-loading-state-error-decoding-states-eof/74430

/var/lib/filebeat/registryを削除してから起動すれば良いようですね。
この環境は壊れても失うのは時間だけなので、やってみます。

# rm /var/lib/filebeat/registry
# service filebeat start
# cat /var/log/filebeat/filebeat

2017-12-27T08:14:08Z INFO Home path: [/usr/share/filebeat] Config path: [/etc/filebeat] Data path: [/var/lib/filebeat] Logs path: [/var/log/filebeat]
2017-12-27T08:14:08Z INFO Beat UUID: 1267efb0-a1af-4f02-9e18-d7120d6bc2bc
2017-12-27T08:14:08Z INFO Metrics logging every 30s
2017-12-27T08:14:08Z INFO Setup Beat: filebeat; Version: 6.1.1
2017-12-27T08:14:08Z INFO Elasticsearch url: http://192.100.0.4:9200
2017-12-27T08:14:08Z INFO Beat name: ip-192-100-0-36
2017-12-27T08:14:08Z INFO filebeat start running.
2017-12-27T08:14:08Z INFO No registry file found under: /var/lib/filebeat/registry. Creating a new registry file.
2017-12-27T08:14:08Z INFO Loading registrar data from /var/lib/filebeat/registry
2017-12-27T08:14:08Z INFO States Loaded from registrar: 0
2017-12-27T08:14:08Z INFO Loading Prospectors: 1
2017-12-27T08:14:08Z WARN DEPRECATED: input_type prospector config is deprecated. Use type instead. Will be removed in version: 6.0.0
2017-12-27T08:14:08Z INFO Starting Registrar
2017-12-27T08:14:08Z INFO Starting prospector of type: log; ID: 5240556406633074861
2017-12-27T08:14:08Z INFO Loading and starting Prospectors completed. Enabled prospectors: 1
2017-12-27T08:14:08Z INFO Harvester started for file: /var/log/secure
2017-12-27T08:14:09Z INFO Connected to Elasticsearch version 6.1.1
2017-12-27T08:14:09Z INFO Loading template for Elasticsearch version: 6.1.1
2017-12-27T08:14:09Z INFO Elasticsearch template with name 'filebeat-6.1.1' loaded

criticalなエラーは解決したようです。

しかしながら新たなエラーが。

2017-12-27T09:24:40Z ERR  Failed to publish events: temporary bulk send failure

そういえば、WARNもありますね。まずこれが気になるのでfilebeat.reference.ymlを見ながら修正してみました。

修正したfilebeat.yml

filebeat.modules:
- module: kafka
  log:
    enabled: true
filebeat.prospectors:
- type: log
  enabled: false
  paths:
    - /var/log/secure.log
output.elasticsearch:
  hosts: ["192.100.0.4:9200"]
setup.template.settings:
setup.kibana:
logging.to_files: true
logging.files:

filebeatを再起動することでWARNは消えました。

# cat /var/log/filebeat/filebeat
2017-12-27T09:49:12Z INFO Home path: [/usr/share/filebeat] Config path: [/etc/filebeat] Data path: [/var/lib/filebeat] Logs path: [/var/log/filebeat]
2017-12-27T09:49:12Z INFO Metrics logging every 30s
2017-12-27T09:49:12Z INFO Beat UUID: 1267efb0-a1af-4f02-9e18-d7120d6bc2bc
2017-12-27T09:49:12Z INFO Setup Beat: filebeat; Version: 6.1.1
2017-12-27T09:49:12Z INFO Elasticsearch url: http://192.100.0.4:9200
2017-12-27T09:49:12Z INFO Beat name: ip-192-100-0-36
2017-12-27T09:49:12Z INFO Enabled modules/filesets: kafka (log),  ()
2017-12-27T09:49:12Z INFO filebeat start running.
2017-12-27T09:49:12Z INFO Registry file set to: /var/lib/filebeat/registry
2017-12-27T09:49:12Z INFO Loading registrar data from /var/lib/filebeat/registry
2017-12-27T09:49:12Z INFO States Loaded from registrar: 1
2017-12-27T09:49:12Z INFO Loading Prospectors: 2
2017-12-27T09:49:12Z INFO Starting Registrar
2017-12-27T09:49:12Z INFO Starting prospector of type: log; ID: 15188226147135990593
2017-12-27T09:49:12Z INFO Loading and starting Prospectors completed. Enabled prospectors: 1

ERRが出力されるのかしばらく待ちます。

ERRも出なくなってました。しかし肝心のデータがkibanaで表示されない・・・

 おわりに

今回はこれで終わりにしたいと思います。
また来年続きやります・・・

こんなんばっかりや・・

続きを読む

Amazon Linux 2 に elasticsearchのbenchmarkツールrallyをインストールして、Amazon Elasticsearch Serviceの性能評価を行う.

Amazon Linux 2 に elasticsearchのbenchmarkツールrallyをインストールして、Amazon Elasticsearch Serviceの性能評価を行う.

Amazon Elasticssearch Serviceのパフォーマンスを調査する為に、Elasticsearchが提供するベンチマークツールのrallyを導入したEC2インスタンスを立ち上げ、性能評価を行います。

AMIは、最近発表された
Amazon Linux 2 LTS Candidate AMI 2017.12.0 (HVM), SSD Volume Type - ami-7707a10f
を利用してみます.

rallyは、python3上で動作する為、python3をインストールが必要になります.
AMIとして利用するAmazon Linux2に標準でインストールされているpythonは、version2系(Python 2.7.5)の為、python3系をインストールします。

$ sudo amazon-linux-extras install python3
$ python3 --version
Python 3.6.2

rally用のpython3環境とする為、python3の仮想環境を作ります.

$ python3 -m vent .py-esrally-venv
$ source .py-esrally-venv/bin/activate

rallyのインストール,実行時に不足するライブラリをインストールします.

$ sudo yum install gcc python3-devel git

rallyをインストールします.

(.py-esrally-venv) $ pip3 install esrally
(.py-esrally-venv) $ esrally configure
 # Press Enter to skip. 

elasticsearch serviceへのアクセスは、 Signature Version 4でアクセスする必要がある為、rallyから直接接続するすることができません. そこで Elasticsearch serviceにアクセスする為のproxyを立ち上げます.
今回は、 nodeベースのproxy aws-es-proxyを利用します.

nodeをインストールする為にnvmのインストールを行い、その後、nodeをインストールし、 aws-es-proxyを導入します.

(.py-esrally-venv) $ curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.33.8/install.sh | bash
(.py-esrally-venv) $ source .bashrc
(.py-esrally-venv) $ nvm install  v8.9.3
(.py-esrally-venv) $ npm init
(.py-esrally-venv) $ npm install --save aws-es-proxy

proxyを起動します.
なお、aws credentials情報(access_key_id, aws_secret_access_key)は、aws cliで設定しておいてください.

(.py-esrally-venv) $ node_modules/aws-es-proxy/bin/aws-es-proxy --port 9200 --profile default --region [region]  [endpoint]

proxy経由でElasticsearch Serviceにアクセスできることを確認します.

(.py-esrally-venv) $ curl http://localhost:9200/

rallyを実行します. target-hostsとして、proxyのアドレスを指定します。

(.py-esrally-venv) $ esrally --pipeline=benchmark-only --target-hosts=localhost:9200
    ____        ____
   / __ ____ _/ / /_  __
  / /_/ / __ `/ / / / / /
 / _, _/ /_/ / / / /_/ /
/_/ |_|__,_/_/_/__, /
                /____/

[INFO] Writing logs to /home/xxxxx/.rally/logs/rally_out_20171225T052238Z.log

************************************************************************
************** WARNING: A dark dungeon lies ahead of you  **************
************************************************************************

Rally does not have control over the configuration of the benchmarked
Elasticsearch cluster.

Be aware that results may be misleading due to problems with the setup.
Rally is also not able to gather lots of metrics at all (like CPU usage
of the benchmarked cluster) or may even produce misleading metrics (like
the index size).

************************************************************************
****** Use this pipeline only if you are aware of the tradeoffs.  ******
*************************** Watch your step! ***************************
************************************************************************
    :
  • 参考
    利用させていただいたproxy.
    https://github.com/joona/aws-es-proxy
    esrallyのドキュメント
    https://esrally.readthedocs.io/en/latest/index.html

  • 残件
    Amazon Elasticsearch Serviceの構成変更での性能評価を目的としている為、異なるproxyを利用する必要はないと想定しているが、go言語で実装された aws-es-proxyを使った場合の比較などもやっておくべきかもしれない. proxyで、パフォーマンスに差が出ると、性能指標の基準が低くなってしまうはず..
    trackを指定することで、異なるデータパターンでの評価を行うことができるので、サービスでの利用方法に近いtrackでの評価を実施すべき..デフォルト(オプション指定無)は、geonames.

  • 備考
    インスタンスタイプがt2.microだと、途中で異常終了してしまうようです. 評価中、CPU Creditを、使い切って途中で異常終了しました.
    また、Amazon Elasticsearch Service側の構成として、簡単に1台で立ち上げられますが、1台構成の場合、StatusがYellowの為、デフォルトでは、測定できません。 以下のようなERRORを出力して、測定が中断します.
    [ERROR] Cannot race. ('Could not execute benchmark', Cluster did not reach status [green]. Last reached status: [yellow])
    どうしても1台構成で実行する場合は、rally実行時に、 --cluster-health=yellow optionを付与する必要があります。

続きを読む