Terraformでstate lockを触ってみた。

はじめに

初めてTerraformを触る折に
「v0.9以上だとstate lockっていう機能があるから使ったほうが良いよ」
というアドバイスをもらいました。
(そもそも、stateってなんですか?から始まるわけですが・・・)

初めてTerraformを触った時に、公式ドキュメントだけでは???な状態だったので
痕跡として残しておきます。

結果として、まだ使いこなせてません。というか僕の使い方は果たしてあっているのだろうか
なので情報としては不足しているかもしれませんが、とりあえず備忘録的に残します。
またわかったらUpdateします。

そもそもState Lockとは

完全に理解しないで書いてますが
Terraformは「自分が知っているリソース(EC2やS3)しか関与しないよ」というポリシーで
どのリソースを自分が扱ったか、というのをtfstateというJSONファイルで管理しているようです。

このtfstateファイルは、一人でTerraformを動かす場合は問題無いのですが
複数人でTerraformをいじる必要が出てきた時に問題で、それは「backend」モジュールを使うことで回避してきたようですが
同じタイミングでterraformを実施した場合、その部分までは制御しきれてなかったようです。

で、v0.9以上?から、「Plan/Applyをしているタイミングではロックする」機能が実装されたようで。
せっかくなので導入してみました。

公式サイト:https://www.terraform.io/docs/state/locking.html

準備

手動で準備が必要なものは
・terraformを実行するユーザのCredential情報
→ めんどくさかったので test-terraformとかいうユーザを別途作成しました。
・S3 Bucketの作成
→ terraform-s3-state とかいう名前で作りましょう
・DynamoDBの作成
→ 名前はなんでも良いです。terraform-state-lock とかで作りましょう。
  プライマリキーを「LockID」としてください。それ以外では動きません。
作り終えたら、読み込み・書き込み容量ユニットは最低の1にしておいたほうが良いと思います。

※ S3とDynamoDBをterraformで管理はしないほうが良さげです。
どのみち、初回実行時に「そんなリソース無いんだけど!」ってTerraformが怒ります。

動くまで

今回はState Lockの話がメインなので作るリソースはなんでも良いです。
リージョンが関係無いRoute53を題材にします。

route53.tf
# 適当に1ゾーン作ります。

resource "aws_route53_zone" "test_zone" {
    name    =   "test.lockstate.com"
}
settings.tf
# ネーミングよくないですが、providerとbackendの設定します

provider "aws" {
    access_key = "ACCESS_KEY"
    private_key = "PRIVATE_KEY"
}

terraform {
    backend "s3" {
        bucket     = "terraform-s3-state"
        key        = "terraform.tfstate"
        region     = "s3とdynamoがいるregion"
        lock_table = "terraform-state-lock"
    }
}

これで、「該当のディレクトリに移動して」$ terraform plan してください。(怒られます。)

Backend reinitialization required. Please run "terraform init".
Reason: Initial configuration of the requested backend "s3"

The "backend" is the interface that Terraform uses to store state,
perform operations, etc. If this message is showing up, it means that the
Terraform configuration you're using is using a custom configuration for
the Terraform backend.

とりあえず terraform init しろよと言われるので言われるがままに。

$ terraform init

ただし、以下の通り、認証情報がねーんだけど!って怒られる。なんやねん。

Initializing the backend...

Error configuring the backend "s3": No valid credential sources found for AWS Provider.
  Please see https://terraform.io/docs/providers/aws/index.html for more information on
  providing credentials for the AWS Provider

Please update the configuration in your Terraform files to fix this error
then run this command again.

ここらへんちゃんとよくわかってないですが、この問題の対処として2つありました。
A. settings.tfのbackendにaccess_key/secret_keyの2つを渡してCredential情報を平文で書く。
-> 変数でいいじゃん!と思ったんですが、変数で渡すと、Terraformがよしなにやる「前に」
  Backendが立ち上がるために違う方法で渡してくれ、と怒られました。
以下のようなメッセージ

% terraform init 
Initializing the backend...
Error loading backend config: 1 error(s) occurred:

* terraform.backend: configuration cannot contain interpolations

The backend configuration is loaded by Terraform extremely early, before
the core of Terraform can be initialized. This is necessary because the backend
dictates the behavior of that core. The core is what handles interpolation
processing. Because of this, interpolations cannot be used in backend
configuration.

If you'd like to parameterize backend configuration, we recommend using
partial configuration with the "-backend-config" flag to "terraform init".

B. 環境変数にaccess_key/secret_keyの2つを食わせる
  → 今はこちらを採用中。

init or plan実行時に、状況に応じて「ローカルのStateをS3にコピーするか / S3からStateファイルをローカルにコピーするか」聞かれるかもしれません。
初回(もしくはテスト)であればYes、すでに何回か実行しているような状況ではnoでいいんじゃないでしょうか。

これで、terraform plan (or apply)を実行すると
DynamoDBのLockDBに対して誰が使用しているか、のロック情報が書き込まれ
終わったタイミングでリリースされます。

ターミナルやシェルを複数立ち上げ、同じぐらいのタイミングで
terraform plan( or apply )を実行すると、ロックが成功できた奴以外はエラーで落とされます。
ただし、ロックがリリースされる前の実行中などにCtrl-Cなどで強制終了させるとロックが残り続けるので注意。
$ terraform force-unlock ID情報
で強制ロック解除できます。

今僕が解決できてない問題点

公式ドキュメントを見る限り、「terraform remote コマンドは terraform initコマンドに置き換えたよ!」と言っています。
また、backendを使用する、backendを書き換えた、などのタイミングに起因して terraform init を求められます。

が、terraform initは、「実行されたディレクトリに対して .terraform/terraform.tfstate」を吐き出します。
そしてそれが無いと怒ります。
まだ試せてはいませんが、以下のようなtfの配置をしていたりした場合
root配下でinitを実行しても、tfファイルがありませんと怒られる状況で
tfファイルがあるディレクトリまで移動しないとinitができない状態です。

$ terraform init ./route53/tf
とするとroot直下にtfファイルがコピーされる状況です。
なので、リソースごとに区切る、とか環境ごとに区切る、とかはうまくできていません。
別の見方をすれば、環境ごとに一つのディレクトリでリソース類は全部その中で管理しろよ!
というHashiCorpからのお達しなのか・・・?
これは、新しく実装されたEnvironmentを試せ、ということなんでしょうか。。。

と思ったらBackendConfigなるものがあるらしいのでそれを試してみよう。

root
├── settings
│   └── tf
│   └── settings.tf
├── route53
│   └── tf
│   └── route53.tf
└── ec2
└── tf
└── ec2.tf

Terraformとの付き合い方がよくわからない

続きを読む

Amazon EC2上のRed Hat Enterprise Linuxにリモートデスクトップ接続してElixir ReportをGUIインストールする手順

クラウド環境のLinuxインスタンスに、帳票ツールのElixir Reportをインストールする手順をまとめています。

参考までに、以前の記事はこちら。
Amazon EC2上にRed Hatインスタンスを作成してElixir Reportをコンソールインストールする手順
Amazon EC2上のRed Hat Enterprise LinuxにX11転送でElixir ReportをGUIインストールする手順

今回は、Amazon EC2上のRed Hatインスタンスに、デスクトップ環境VNCサーバーをインストールして、WindowsからVNCクライアントを使って接続し、Elixir ReportのレポートサーバーをGUIインストールする手順を試してみたいと思います。

環境

Windows 8.1
Elixir Report 8.7J
UltraVNC 1_2_12 64bit
Amazon EC2 Red hat Enterprise Linux 7.3
tigervnc-server

Red Hatインスタンスを作成して、パスワード認証を許可する

  1. Amazon EC2上に、デフォルトの構成でRed Hatインスタンスを作成します。以前まとめた、Amazon EC2上にRed Hatインスタンスを作成してElixir Reportをコンソールインストールする手順[Red Hatインスタンスの作成と準備]を参考にしてください。

    セキュリティ設定のポートの開放では、レポートサーバーが使用するポート7001と、サンプルのTomcatで使用するポート9090だけでなく、VNCが使用するポート5901も追加する必要があるので、注意してください。

  2. Windowsから作成したインスタンスにSSH接続します。この記事ではTera Termを使用します。Tera Termのインストール手順については、こちらも以前の記事[SSH接続用にWindowsにTera Termをインストールする]を参考にしてください。

  3. Tera Termでインスタンスに接続したら、パスワード認証(PasswordAuthentication)を許可するように変更します。sshd_configは念のためバックアップを取っておいてください。変更後のsshd_configは次のようになります。

    $ cat /etc/ssh/sshd_config|grep Pass
    PasswordAuthentication yes
    #PermitEmptyPasswords no
    #PasswordAuthentication no
    #KerberosOrLocalPasswd yes
    
  4. sshdサービスを再起動します。

    $ sudo systemctl restart sshd.service
    
  5. ec2-userのパスワードを設定します。

    $ sudo –i
    $ passwd ec2-user
    パスワード入力
    
  6. Tera Termを新しく起動して、パスワードでログインできるか試してみます。

Red Hatに、デスクトップ環境とVNCサーバーをインストールする

  1. Tera TermでRed Hatインスタンスに接続して、パッケージのグループServer with GUIをインストールします。

    $ sudo yum grouplist
    $ sudo yum -y groupinstall 'Server with GUI'
    
  2. 次にVNCサーバーをインストールします。

    $ sudo yum –y install tigervnc-server
    
  3. VNCサーバーのパスワードを設定します。

    $ vncpasswd
    Password:
    Verify:
    
  4. VNCサーバーのユニットファイルをコピーします。

    cp -a /lib/systemd/system/vncserver@.service /etc/systemd/system /vncserver@:1.service
    
  5. コピーしたユニットファイルを編集して、<USER>の部分をログインユーザー名ec2-userで置き換えます。

    $ vi /etc/systemd/system/vncserver@:1.service
    ExecStart=/usr/sbin/runuser -l ec2-user -c "/usr/bin/vncserver %i"
    PIDFile=/home/ec2-user/.vnc/%H%i.pid
    
  6. ファイアウォールの設定にVNCサーバーを追加します。また、レポートサーバーが使用するポート7001も許可しておきます。

    $ firewall-cmd --permanent --zone=public --add-service=vnc-server
    $ firewall-cmd --zone=public --add-port=7001/tcp --permanent
    $ firewall-cmd --reload
    $ firewall-cmd --list-all
    
  7. rootでVNCのサービスを起動します。

    $ sudo su –
    # systemctl start vncserver@:1
    
  8. Windowsに、VNCクライアントとしてUltraVNCをインストールします。筆者は以下のサイトからダウンロードしてインストールしました。

    窓の杜 UltraVNCUltraVNC_1_2_12_X64_Setup.exe

  9. UltraVNC Viewer を起動して、VNC Serverの入力箇所にRed HatインスタンスのIP::ポート(またはIP:ポート)と入力して、Red Hatインスタンスのデスクトップに接続できることを確認します。
    1vnc接続成功.png
    接続できました。

Red HatへVNC接続してレポートサーバーのインストーラを実行する

  1. UltraVNC ViewerでRed Hatインスタンスに接続します。

  2. レポートサーバーのインストーラをTera TermからSCPで転送し、実行権限の設定を行います。この手順の詳細は、以前の記事、Amazon EC2上にRed Hatインスタンスを作成してElixir Reportをコンソールインストールする手順[レポートサーバーのインストーラをRed Hatに転送する]を参照してください。

  3. Tera TermまたはRed Hatインスタンスのコンソールを開き、必要なライブラリをインストールします。このライブラリインストールはコマンドインストール、X11転送でのGUIインストールでも行います。

    $ sudo yum -y install libc.so.6
    
  4. レポートサーバーのインストーラを次のコマンドで起動します。

    $ ./elixirreport87_linux64.bin
    

    2VNC_GUIインストーラ00.png

  5. その後の手順の詳細は、以前の記事、Amazon EC2上のRed Hat Enterprise LinuxにX11転送でレポートサーバーをGUIインストールする手順[GUIインストールを実行する]を参考に完了させてください。

インストールしたレポートサーバーを起動する

  1. レポートサーバーを起動するユーザーのLANG環境変数を日本語ロケールへ変更します。

    $ export LANG=ja_JP.UTF-8
    
  2. レポートサーバーをインストールしたディレクトリ以下の/binに移動します。筆者の環境では、/home/ec2-user/ElixirReport87J/bin/になります。

    $ cd /home/ec2-user/ElixirReport87J/bin
    
  3. レポートサーバーの起動シェルスクリプトを実行します。

    $ ./reportserver-start.sh
    

    ※”&”を付加することでバックグラウンド実行にします。

  4. 起動に成功すると、コンソール上に次のようにCopyrightが表示されます。

    INFO  [main] com.elixirtech.ers2.Main - Copyright 2016 Elixir Technology Pte Ltd
    INFO  [Thread-19] com.elixirtech.ers2.EnsureServerStarted - Checking server status
    
  5. Windows上のブラウザからレポートサーバーのWebインターフェースにログインしてみます。

    http://<パブリックIP>:7001
    

    3WebインターフェースURL.png

    【注意】ログイン画面が表示されないときは、以下のような原因が考えられます。
    ・レポートサーバーの起動に失敗している
    ・Red Hatインスタンスのセキュリティグループの設定で、ポート7001を追加していない
    ・Red Hatインスタンスのファイアウォール設定でポート7001を許可していない

  6. ログイン画面が表示されたら、デフォルトで用意されている次の管理者ユーザーでログインします。

    ユーザー名: admin
    パスワード: sa
    
  7. [リポジトリ]以下のサンプルテンプレートを実行してみます。[samples]‐[demo]-[sales2]-[sales2.rml]を選択して、出力形式に”PDF”を選んで[OK]をクリックすると、レポートが生成されます。
    4ロケールを日本語にして、PDFもできます.png

以上で完了です。

続きを読む

AWSにDjango環境を構築する

versions

Python : 2.7
Django : 1.10

Environment

EC2インスタンス : Amazon Linux
WSGI : gunicorn
Proxy : nginx

install python packages

sudo yum update
sudo yum install gcc
sudo yum install python-devel
sudo yum install python-psycopg2
sudo yum install postgresql-devel
pip install -r requirements.txt

reverse proxy

sudo yum install nginx
sudo vi /etc/nginx/nginx.conf
  • nginx.confに追記 line : 49
location / {
    proxy_pass http://127.0.0.1:8000;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

# http://mydomain/static/ をDjangoのsettings.pyでSTATIC_ROOTに指定したディレクトリへルーティング
location /static/ {
    autoindex on;
    alias   /usr/share/nginx/html/django-project-name/staticfiles/;
}
sudo chmod 777 -R /usr/share/nginx/html ※1
sudo service nginx restart
gunicorn django-project-name.wsgi -D

Memo

python manage.py runserver 0.0.0.0:8000  # 全てのホストアドレスからのアクセスを許可
python manage.py migrate
python manage.py createsuperuser

# 事前にsettings.pyにSTATIC_ROOTを設定する (defaultでは記載されていない)
python manage.py collectstatic  # STATIC_ROOTに指定したディレクトリに静的ファイルが生成される

※1 : このディレクトリ下にDjangoプロジェクトを設置
当初はSTATIC_ROOTに設定したディレクトリのシンボリックリンクのみをここに貼ったが
静的ファイルを読み込む際に403エラーが発生してしまうためプロジェクトごとこのディレクトリに設置
所有がrootのディレクトリに対して、パーミッションを777に設定してしまうのは多少疑問が残るところ

SSL証明書

証明書はAWS Certificate Managerで発行し、Elastic Load Balancerにインストール
ELBとEC2間の通信はhttpとなるが、ELBとEC2が同じリージョンにある場合セキュリティの問題はなさそう

続きを読む

ELB を経由すると keepalive ヘッダーが勝手に付与される

AWS Elastic Load Balance 配下にぶら下がっている EC2 インスタンスのベンチマークを、keepalive on/off それぞれの状態で取ろうとたのですが、「どうしても keepalive を off にできない」という状況にハマりました。

後学のためにメモ。

nginx で keepalive を off にする方法

nginx.conf に以下のような設定を書きます。

/etc/nginx/nginx.conf
http{
  keepalive_timeout 0;
  # (何も書かない場合はデフォルト値の 75 になる)
}

設定後は nginx -s reload を忘れずに。

keepalive の有効/無効の確認

この状態で、以下のように ELB 経由でアクセスすると、あたかも keepalive が有効のように見えてしまいます。

$ curl -I http://foo.bar/

HTTP/1.1 200 OK
Server: nginx
Date: Wed, 19 Apr 2017 05:19:08 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 105370
Connection: keep-alive    # <- nginx の設定に関わらず必ず付与される
...

一方、プライベート側から nginx に直接アクセスすれば、ちゃんと keepalive は無効化されています。

$ curl -I http://10.2.8.97/

HTTP/1.1 200 OK
Server: nginx
Date: Wed, 19 Apr 2017 05:19:08 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 105370
Connection: close    # <- keepalive が無効になっている
...

まとめ

keepalive が無効化されていることを確認したければ、ELB を経由せずに直接 nginx を叩きましょう。

補足: ELB 側で keepalive off にできないか?

できない ようです。

Classic Load Balancer のアイドル接続のタイムアウトを設定する – Elastic Load Balancing

[Configure Connection Settings] ページに、[Idle timeout] の値を入力します。アイドルタイムアウトの範囲は 1~3,600 秒です。

(0 には指定できない)

続きを読む

CRMのF-RevoをAWS Lightsailで構築したときにハマったこと(Apache,let’s encrypt)

はじめに

CRM(F-Revo)を導入したときにハマってしまったことを書いていきます。
F-Revoの環境についてはこちらです。
Lightsailどうこうではない部分もあります。

CRMをインストールしようとしたらページが真っ白になった件

F-Revoのインストール設定を入力したあと、こんなページまで行きます。

20150917093149.png

しかしこのあと次のページに遷移すると真っ白なページになって、戻るも進むなくなり、二進も三進もいかなくなりました。
原因はCRMがPHP7に対応していないからでした。
現場の開発はPHP7でやっていたため、できればPHP7を使用してF-Revoをインストールしたかったのですが、プライオリティは低いということでPHP5.6を再インストールしました。

参考
オープンソースなので、自己責任でソースを書き換えればPHP7でも動作するという書き込みもありましたのでご参考までに。
Vtiger with PHP7
https://discussions.vtiger.com/index.php?p=/discussion/183662/vtiger-with-php7/p1
PHP 7 compatibility
http://code.vtiger.com/vtiger/vtigercrm/issues/197

Let’s encryptがうまく実行されない件

オレオレ認証局ではなく、Let’s encryptを利用して証明書を作成しようと試みましたが失敗した話です。
結論から言うと、mod24_sslがインストールされていないからに落ち着きます。
「Let’s encryptはとにかく簡単。パッケージをインストールしてコマンドを叩けば自動で証明書の作成がされるよ」とみたいな話ではあるものの、凡ミスのせいで鮮やかにコケたというお話です。

ではコケるまでの手順を見ていきましょう。
1. インストールコマンドを叩く

$ wget https://dl.eff.org/certbot-auto
$ chmod a+x certbot-auto
$ ./certbot-auto --agree-tos --webroot-path <RootDirectory> -d <DomainName> -m <E-Mail>
※--webroot-pathはhttpdを実行したまま証明書を発行できるオプションです。

はい! ここでコケました!
そして下記のエラーが出力されました。

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Obtaining a new certificate
Performing the following challenges:
tls-sni-01 challenge for <DomainName>
No vhost exists with servername or alias of: <DomainName> (or it's in a file with multiple vhosts, which Certbot can't parse yet). No vhost was selected. Please specify ServerName or ServerAlias in the Apache config, or split vhosts into separate files.
Falling back to default vhost *:443...
Waiting for verification...
Cleaning up challenges
Failed authorization procedure. <DomainName> (tls-sni-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Failed to connect to <IPaddress>:443 for TLS-SNI-01 challenge

IMPORTANT NOTES:

翻訳すると、「DomainNameを持つ仮想ホストは存在しません」みたいなことが書いてあり、「Apacheの設定でServerNameまたはServerAliasを指定するか、仮想ホストを別々のファイルに分割してください」ともあります。
試しにApache設定にVirtualHostを追記しましたがエラーに変化はないです。
/etc/resolv.confの設定ミスというわけでもなかったです。
443が云々というエラーメッセージもあるのでssl.confを見に行ってみると、ssl.confがないことに気づきました。
というわけで、mod24_sslをyum installし、Let’s encryptにて証明書発行が実行できました。

常時https接続に設定変更したらCRMのWEBページにたどり着けなくなった件

少し話が長くなりますので、結論からいうとconfig.inc.phpに記載されたsite_URLがhttp://~になっていたことと、/etc/httpd/conf.d/le-redirect-DomainName.com.confが原因でした。

事の始まり

Let’s encryptのコマンドを無事実行し、いよいよ終了が近づくと「httpもhttpsもイケるようにする?それとも常時https接続にする?」みたいな二択が表示されます。

・・・で、もともと常時https接続にする予定だったこともあり、常時の方を選択しました。
「よーしこれで80ポートは閉めていいな?」ということで、LightsailのGUIコンソール側でセキュリティルールを変更しました。
そしてこのあとユーザさんから「ログインできない!」と続々お問い合わせが来てしまったのです。
見てみると、エラー内容はタイムアウトでした。

となると、まず疑うべきは

  • 「常時https接続する」を選択したときに、自動でどこかにその設定を読み込むコンフィグが作成された可能性

ということです。そのコンフィグが作成されたこと一点が原因でログイン画面に行けないのであれば、コンフィグ名を変更してやることで今までのようにhttp接続でログインページにたどり着けるようになるはずです。

はい、ありました。le-redirectと名前がついてるので決定的です。
中身を見てみると、httpsにRewriteしているようです。とりあえずこのファイル名を変更し、httpdを再起動します。

/etc/httpd/conf.d/le-redirect-DomainName.com.conf
<VirtualHost _default_:80>
ServerName <DomainName>:443
ServerAlias <DomainName>
ServerSignature Off

RewriteEngine On
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,QSA,R=permanent]

ErrorLog /var/log/httpd/redirect.error.log
LogLevel warn
</VirtualHost>

ただ、これだけだと80ポートを閉じているのでhttp通信もできない状態。再度Lightsailの80ポートを開きます。
これで一旦、http通信ではあるけれどログインページにはこれまで通りいけるはず!

  • 強制リダイレクトしてるファイルを読み込ませない
  • http通信を許可する

応急処置が終わったら次はhttpsで接続できるようにしていきます。

そもそもなんでHTTPS接続できなかったか

いわゆるリダイレクトループと言えばいいんでしょうか。

リクエスト→http→強制でhttpsに変換→config.inc.phpに記載されたsite_URLがhttp://~のためhttpになる→強制でhttpsに→→→というイメージです。

config.inc.phpを一部抜粋するとこんな感じで記述されています。

/var/www/html/config.inc.php
$site_URL = 'http://<IPaddress>';

つまりこれを、httpsと記述してやればいいわけです。もっというと、ドメイン名でURLを表記させたいので以下のように変更しました。

/var/www/html/config.inc.php
#$site_URL = 'http://<IPaddress>/~';
$site_URL = 'https://<DomainName>/~';

そして改めて、必要のない80ポートを閉じます。
これで私の環境ではhttps接続が可能になりました!

おわりに

長くなりましたが、大抵ネットワーク関連で死ぬときは設定漏れか把握してないファイルがいるみたいなときなんですかね。ともあれユーザが安全、安定して使用してもらえるよう運用していきたいです。

続きを読む

[AWS] Terraform で EFS 作って、EC2 起動時にマウントさせておく

Terraform を使うと、EFS を作成して EC2 にマウントさせておくなんてことが簡単にできます。
Autoscaling 環境で Web ドキュメントルートを共有したい時とかに便利なんで、みんな使えばいいと思うよ。
なお、この記事の想定読者は AWS はダッシュボードからポチポチしてインスタンス立てたりしてるけど、そろそろインフラをコードで管理したいな。Terraform とか便利そうだねー使ってみたいねーって人です。
てわけで、単純に EC2 立ち上げても面白くないので EFS をマウントさせてみました。

そもそも、Terraform ってなんだ?って人は、以下のページとか参考になると思います。
Terraform簡易チュートリアル on AWS

実際の設定

Terraform は、特定のディレクトリ下にある拡張子が .tf なファイルを全部読み込んでいい感じにリソースを起動してくれます。なので、機能別に .tf 作成していってみましょう。

メイン設定

まず、メインの設定を作成。
プロバイダーとか、設定ファイル内で使用する変数とか設定していってみましょうか。

main.tf
# 今回のプロジェクト名
variable "project" {}
variable "domain" {}

# AWS リソースを起動するリージョンとかの情報
variable "region" { default = "us-west-2" }
variable "azs" {
    default {
        "a" = "us-west-2a"
        "b" = "us-west-2b"
        "c" = "us-west-2c"
    }
}

# AMI ID (Amazon Linux)
variable "ami" { 
    default {
        "us-west-2" = "ami-8ca83fec"
    }
}

# EC2 接続用の SSH 鍵の公開鍵
variable "ssh_public_key" {}

provider "aws" {
    region = "${var.region}"
}

variable で設定した値は tf ファイル内で ${var.region} のようにして参照可能です。
また、terraform の各種コマンドを実行する際に以下のようにパラメータとして変数を渡して上書きすることもできます。

$ terraform plan \
  -var 'project=example' \
  -var 'domain=example.com'

同じディレクトリ内に terraform.tfvars というファイルがあれば、それを読み込んで値が上書きされたりします。この辺の詳細は以下を参照してください。
Input Variables – Terraform by HashiCorp

provider "aws" は、aws を使いますよって宣言です。
以下のように アクセスキーを書いておくこともできますが、それやるとうっかり github とかに公開した時とかに切ない目にあうのでやめたほうが吉でしょう。

provider "aws" {
    access_key = "__ACCESS_KEY__"
    secret_key = "__SECRET_KEY__"
    region = "us-west-2"
}

環境変数 AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY を読み込んでいい感じでやってくれるので、僕は direnv 使って作業ディレクトリ内で環境変数を変更することで対応してます。
(もちろん、この場合でも .gitignore.envrc を含めておいて間違って公開しないようにしないと切ない目にあうので注意)

VPC の作成

こんな感じの .tf ファイルで VPC と subnet が作成できます。

vpc.tf
## VPC
resource "aws_vpc" "app" {
    cidr_block           = "172.31.0.0/16"
    enable_dns_hostnames = true
    enable_dns_support   = true
    instance_tenancy     = "default"

    tags {
        "Name" = "${var.project}"
    }
}

## Subnet
resource "aws_subnet" "a" {
    vpc_id                  = "${aws_vpc.app.id}"
    cidr_block              = "172.31.0.0/20"
    availability_zone       = "${lookup(var.azs,"a")}"
    map_public_ip_on_launch = true

    tags {
        "Name" = "${var.project}-subnet-a"
    }
}

resource "aws_subnet" "b" {
    vpc_id                  = "${aws_vpc.app.id}"
    cidr_block              = "172.31.16.0/20"
    availability_zone       = "${lookup(var.azs,"b")}"
    map_public_ip_on_launch = true

    tags {
        "Name" = "${var.project}-subnet-b"
    }
}

resource "aws_subnet" "c" {
    vpc_id                  = "${aws_vpc.app.id}"
    cidr_block              = "172.31.32.0/20"
    availability_zone       = "${lookup(var.azs,"c")}"
    map_public_ip_on_launch = true

    tags {
        "Name" = "${var.project}-subnet-c"
    }
}

resource "aws_subnet" の中に ${aws_vpc.app.id} ってのが出てきましたね。
Terraform の中では、管理下にあるリソースの情報を他のリソースの設定でも参照することが可能です。
各リソースで使用できる値が異なってくるので、その辺は公式ドキュメント読みましょう。
例えば aws_vpc で使用できる値は aws_vpc を参照すればわかります。

また、${lookup(var.azs,"a")} ってのも出てきましたね。
これは Terraform の組み込み関数です、lookup は配列の中からキーをもとに値を探す関数です。
詳しくは Built-in Functions を読んでください。

ついでに Internet Gateway と Route Table も設定しておきましょう。

route-table.tf
## Internet Gateway
resource "aws_internet_gateway" "igw" {
    vpc_id = "${aws_vpc.app.id}"
}

## Route Table
resource "aws_route_table" "rtb" {
    vpc_id     = "${aws_vpc.app.id}"
    route {
        cidr_block = "0.0.0.0/0"
        gateway_id = "${aws_internet_gateway.igw.id}"
    }
}

resource "aws_route_table_association" "route_a" {
    subnet_id = "${aws_subnet.a.id}"
    route_table_id = "${aws_route_table.rtb.id}"
}

resource "aws_route_table_association" "route_b" {
    subnet_id = "${aws_subnet.b.id}"
    route_table_id = "${aws_route_table.rtb.id}"
}

resource "aws_route_table_association" "route_c" {
    subnet_id = "${aws_subnet.c.id}"
    route_table_id = "${aws_route_table.rtb.id}"
}

IAM ロールの作成

次に EC2 に割り当てるための IAM ロールを作ってみましょう。
ポリシーは、AWS が用意している AmazonEC2RoleforDataPipelineRole と、EC2 から CloudwatchLogs にログを送信するためのカスタムポリシーを作ってアタッチしてみます。

iam-role.tf
## For EC2 instance Role
resource "aws_iam_role" "instance_role" {
    name               = "instance_role"
    path               = "/"
    assume_role_policy = <<POLICY
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
POLICY
}

## AmazonEC2RoleforDataPipelineRole
resource "aws_iam_role_policy_attachment" "data-pipeline" {
    role       = "${aws_iam_role.instance_role.name}"
    policy_arn = "arn:aws:iam::aws:policy/service-role/AmazonEC2RoleforDataPipelineRole"
}

## PutCloudwatchLogs
resource "aws_iam_policy" "put-cloudwatch-logs" {
    name        = "AmazonEC2PutCloudwatchLogs"
    description = ""
    policy      = <<POLICY
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "logs:CreateLogGroup",
                "logs:CreateLogStream",
                "logs:PutLogEvents"
            ],
            "Effect": "Allow",
            "Resource": "*"
        }
    ]
}
POLICY
}

resource "aws_iam_role_policy_attachment" "put-cloudwatch-logs" {
    role       = "${aws_iam_role.instance_role.name}"
    policy_arn = "${aws_iam_policy.put-cloudwatch-logs.arn}"
}

aws_iam_roleassume_role_policy のところと、aws_iam_policypolicy のところでヒアドキュメントが出てきましたね。
こんな風に複数行にわたるインラインポリシーはヒアドキュメントで記述することが可能です。
また、以下のように別ファイルにしておいて読み込ませることも可能です。
管理しやすい方でやってください。

iam-role.tf
resource "aws_iam_role" "instance_role" {
    name               = "instance_role"
    path               = "/"
    assume_role_policy = "${file("data/instance_role_assume_policy.json")}"
}
data/instance_role_assume_policy.json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

セキュリティグループの作成

EC2 から EFS へのアクセスは 2049 番ポートを介して行われるので、EFS が所属するセキュリティグループに穴を開けないといけません。
EC2 は 80, 443, 22 を解放してみます。

security-group.tf
## For EC2
resource "aws_security_group" "ec2" {
    name        = "${var.project}-EC2"
    description = "for ${var.project} EC2"
    vpc_id      = "${aws_vpc.app.id}"

    ingress = [
        {
            from_port       = 80
            to_port         = 80
            protocol        = "tcp"
            cidr_blocks     = ["0.0.0.0/0"]
        },
        {
            from_port       = 443
            to_port         = 443
            protocol        = "tcp"
            cidr_blocks     = ["0.0.0.0/0"]
        },
        {
            from_port       = 22
            to_port         = 22
            protocol        = "tcp"
            cidr_blocks     = ["0.0.0.0/0"]
        }
    ]

    egress {
        from_port       = 0
        to_port         = 0
        protocol        = "-1"
        cidr_blocks     = ["0.0.0.0/0"]
    }
}

## For EFS
resource "aws_security_group" "efs" {
    name        = "${var.project}-EFS"
    description = "for ${var.project} EFS"
    vpc_id      = "${aws_vpc.app.id}"

    ingress {
        from_port       = 2049
        to_port         = 2049
        protocol        = "tcp"
        security_groups = ["${aws_security_group.ec2.id}"]
    }

    egress {
        from_port       = 0
        to_port         = 0
        protocol        = "-1"
        cidr_blocks     = ["0.0.0.0/0"]
    }
}

EFS の作成

こんな感じで EFS が作成できます。
各サブネットごとにマウントターゲットを作成して、そいつをセキュリティグループに所属させる形ですね。

efs.tf
resource "aws_efs_file_system" "app" {
  tags {
        "Name" = "${var.domain}"
  }
}

resource "aws_efs_mount_target" "app-a" {
  file_system_id  = "${aws_efs_file_system.app.id}"
  subnet_id       = "${aws_subnet.a.id}"
  security_groups = ["${aws_security_group.efs.id}"]
}

resource "aws_efs_mount_target" "app-b" {
  file_system_id = "${aws_efs_file_system.app.id}"
  subnet_id      = "${aws_subnet.b.id}"
  security_groups = ["${aws_security_group.efs.id}"]
}

resource "aws_efs_mount_target" "app-c" {
  file_system_id = "${aws_efs_file_system.app.id}"
  subnet_id      = "${aws_subnet.c.id}"
  security_groups = ["${aws_security_group.efs.id}"]
}

EC2 の作成

さて、いよいよ EC2 です。
ここでは、user-data を使って、初回ローンチ時に EFS をマウントさせてしまいます。
さらにマウントした EFS 内に html/ ってディレクトリを作成して、そいつを /var/www/html にシンボリックリンクしてみましょうか。
と言っても、こんな感じで大丈夫です。

ec2.tf
## IAM Instance Profile
resource "aws_iam_instance_profile" "instance_role" {
    name = "instance_role"
    role = "${aws_iam_role.instance_role.name}"
}

## SSH Key
resource "aws_key_pair" "deployer" {
  key_name   = "${var.project}"
  public_key = "${var.ssh_public_key}"
}

## EC2
resource "aws_instance" "app" {
    ami                         = "${lookup(var.ami,var.region)}"
    availability_zone           = "${aws_subnet.a.availability_zone}"
    ebs_optimized               = false
    instance_type               = "t2.micro"
    monitoring                  = true
    key_name                    = "${aws_key_pair.deployer.key_name}"
    subnet_id                   = "${aws_subnet.a.id}"
    vpc_security_group_ids      = ["${aws_security_group.ec2.id}"]
    associate_public_ip_address = true
    source_dest_check           = true
    iam_instance_profile        = "${aws_iam_instance_profile.instance_role.id}"
    disable_api_termination     = false

    user_data                   = <<USERDATA
#!/bin/bash
az="${aws_subnet.a.availability_zone}"
efs_region="${var.region}"
efs_id="${aws_efs_file_system.app.id}"
efs_mount_target="${aws_efs_mount_target.app-a.dns_name}:/"
efs_mount_point="/mnt/efs/$${efs_id}/$${az}"
web_doc_root="/var/www/html"

# EFS Mount
/usr/bin/yum -y install nfs-utils || /usr/bin/yum -y update nfs-utils
if [ ! -d $${efs_mount_point} ]; then
  mkdir -p $${efs_mount_point}
fi
cp -pi /etc/fstab /etc/fstab.$(date "+%Y%m%d")
echo "$${efs_mount_target}    $${efs_mount_point}   nfs4    defaults" | tee -a /etc/fstab
mount $${efs_mount_point}

# create Web document root
if [ -d $${web_doc_root} ]; then
  rm -rf $${web_doc_root}
fi
if [ ! -d $${efs_mount_point}/html ]; then
  mkdir $${efs_mount_point}/html
  chown ec2-user:ec2-user $${efs_mount_point}/html
fi
ln -s $${efs_mount_point}/html $${web_doc_root}
chown -h ec2-user:ec2-user $${web_doc_root}
USERDATA

    root_block_device {
        volume_type           = "gp2"
        volume_size           = 10
        delete_on_termination = true
    }

    tags {
        "Name"          = "${var.domain}"
    }
}

user_data は長めのシェルスクリプトなので、可読性が悪いから ${file("data/user_data.sh")} とかってやって別ファイルで管理したいですよね。
でも待ってください、ヒアドキュメントでやってるのは理由があるのです。

ヒアドキュメントで書くと、user_data 用のシェルスクリプトの中で Terraform の変数が使えます。
マウントするには EFS の ID とか、マウントターゲットの dns_name とか必要になってきますが、それを作成前に知らなくてもこのように書いておけるのです。便利ですね。
その代わり、user_data 用のシェルスクリプト内でローカルな環境変数を使いたい場合は $${efs_mount_point} のように書いてあげてくださいね。

ざっと、こんな感じです。
慣れちゃえば、tf ファイルを使い回しできるので便利ですよ。
また、すでに作成済みの AWS リソースを Terraform 管理下に置きたい場合は

$ terraform import aws_instance.app ${instance_id}

のようにして管理下に置くことができます。
管理されているリソースは terraform.tfstate というファイルに書き込まれます。
さらに別プロダクトになるのですが Terraforming と言うツールを使用すると、既存の AWS リソースから Terraform 用の tf ファイルを作成したり、terraform.tfstate を作成したりもできるので便利です。
Terraforming については、Terraforming で既存のインフラを Terraform 管理下におく を参考にしてください。

実際にリソース作成してみる

tf ファイル書いたら

$ terraform plan

で、設定ファイルに誤りがないか?既存のリソースへの影響はどの程度あるのかが確認できます。
実際に反映させたい時は

$ terraform apply

で、おっけ。

では、良い Terraform を!

続きを読む

Amazon EC2上のRed Hat Enterprise LinuxにX11転送でElixir ReportをGUIインストールする手順

この記事はクラウド環境のLinuxインスタンスに、帳票ツールのElixir ReportをGUIインストールする手順についてまとめたものです。

以前の記事、Amazon EC2上にRed Hatインスタンスを作成してElixir Reportをコンソールインストールする手順では、デスクトップ環境のないLinuxインスタンスにコンソールインストールする手順を試してみました。

今回は、SSHのX11転送(X11フォワーディング)機能を使って、デスクトップ環境の入っていないAmazon EC2上のRed Hat Enterprise LinuxのインスタンスでElixir Reportのレポートサーバーのインストーラを実行し、GUIインストーラをWindows側に表示してインストールしてみたいと思います。

環境

Windows 8.1
Elixir Report 8.7J
Amazon EC2 Red hat Enterprise Linux 7.3

WindowsにTera Termをインストールする

この記事では、Linux OSへのSSH接続にTera Termを使用します。Tera TermのWindowsへのインストールは、以前の記事[SSH接続用にWindowsにTera Termをインストールする]を参考にしてください。

WindowsにXサーバーをインストールする

Linux上のGUIアプリケーションをWindows側で操作するには、WindowsのリモートデスクトップやVNC経由でLinuxのデスクトップに接続することもできますが、この記事では、Linux上で動作しているアプリケーションのGUIをWindows側に表示する方法としてX11転送を利用します。

この方法ではWindows側にXサーバーがインストールされている必要があるので、今回はXmingというフリーのWindows用Xサーバーを使用します。こちらの記事を参考にしました。

【参考記事】フリーのWindows用Xサーバー「Xming」のインストールと基本設定、使い方

  1. Xmingインストーラをダウンロードサイトからダウンロードします。本記事の作成時(2016年11月)で最新のXming(Xming-6-9-0-31-setup.exe)と、Xming-fonts(Xming-fonts-7-7-0-10-setup.exe)をダウンロードします。1ダウンロードファイル選択.png  

  2. Xmingのインストーラをダブルクリックで起動します。選択項目は基本的にデフォルト設定を受け入れてインストールします。[Next]で進みます。
    2install01.png

  3. インストール先を指定して次に進みます。

  4. コンポーネントの選択画面では、デフォルト設定を受け入れて進みます。3install03.png

  5. アイコンやタスクの選択ステップも同様に、デフォルトのまま進みます。4install05.png

  6. インストール前の確認項目をチェックして進み、インストールを完了します。5install07.png

  7. インストールの完了画面で[Launch Xming]にチェックを入れて終了すると、Xmingが起動してタスクトレイにアイコンが表示されます。
    6icon.png

    [注意]Xming起動時に、Windowsファイアウォールの警告が表示されることがあります。その場合は、アクセスを許可します。

  8. 次にXming-fontsをインストールします。Xming-fontsのインストーラを起動し、コンポーネントの選択でデフォルトを受け入れます。
    7fontinstall01.png

  9. インストールの内容を確認して進めると、インストールが完了します。8fontinstall03.png

Amazon EC2 Red Hatインスタンスの作成と準備

Amazon EC2上に、デフォルトの構成でRed Hatインスタンスを作成します。以前の記事[Red Hatインスタンスの作成と準備]セクションを参考にしてください。

インスタンスの作成と、Windows上のTera TermからRed Hatインスタンスへ接続するまでの手順が完了します。

X11転送の設定をする

X11転送に関する、Red Hat側およびWindows側の設定と確認を行います。

Linux側の設定

  1. Red Hatインスタンスで、X11転送が有効化されているか確認します。/etc/ssh/sshd_config内で、X11Forwardingyesになっていれば問題ありません。

    $ sudo cat /etc/ssh/sshd_config |grep X11
    X11Forwarding yes
    #X11DisplayOffset 10
    #X11UseLocalhost yes
    #       X11Forwarding no
    
  2. 手順1で、X11Forwardingnoになっている場合は、/etc/ssh/sshd_configをバックアップした上で設定をyesに変更し、sshdを次のコマンドに従って再起動します。

    $ sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config_org
    $ sudo vi /etc/ssh/sshd_config
    $ sudo service sshd restart
    Redirecting to /bin/systemctl restart  sshd.service
    
  3. XアプリケーションをX11転送によりWindows上に表示できるか確認するため、今回はxeyesというXアプリケーションをRed Hatインスタンスにインストールしておきます。

    $ sudo yum –y install xeyes
    

Windows側の設定とテスト

  1. Windows側でXmingが起動していることを確認します。

  2. Tera Termの設定で、リモートのXアプリケーションをローカルに表示する設定を行います。Tera Termの[設定]-[SSH転送]をクリックします。
    9TeraTerm_SSH転送設定.png

  3. [リモートの(X)アプリケーションをローカルのXサーバに表示する]にチェックを入れて、[OK]をクリックします。
    10TeraTerm_SSH転送設定01.png

  4. 一旦Tera Termからログアウトして、再度ログインし直します。

  5. DISPLAY変数が設定されているかコマンドで確認します。

    $ echo $DISPLAY
    
  6. 前の手順で何も返ってこなかった場合は、先ほどインストールしたxeyesを実行しても次のようなエラーになってしまいます。

    $ sudo xeyes
    Error: Can't open display:
    

    Red Hatインスタンス側にxauthと、x11のライブラリが不足しているようなので、必要なライブラリを次のコマンドでインストールしました。

    $ sudo yum –y install xorg-x11-xauth.x86_64 xorg-x11-server-utils.x86_64
    
  7. 一旦Tera Termでログアウトします。

    $ exit
    
  8. 再度Tera TermでRed Hatインスタンスにログインして、次のコマンドでDISPLAY変数を確認します。筆者の環境では自動でlocalhost:10.0が設定されていました。

    $ echo $DISPLAY
    localhost:10.0
    
  9. xeyesを実行してみます。無事Windows側にxeyesアプリケーションが表示されました。

    $ xeyes
    

    11xeyes.png

    [注意]次のようなX転送のエラーが出るときは、XmingがWindows側で起動していない可能性があります。起動していることを確認してください。
    12TTSSHエラー.png

レポートサーバーのインストーラをRed Hatに転送する

Tera Termを利用して、Windows側にあるElixir ReportのレポートサーバーのLinux OS用インストーラ(elixirreport87_linux64.bin)と、ライセンスファイル(*.license)をRed Hatインスタンスに転送します。

この手順については、以前の記事[レポートサーバーのインストーラをRed Hatに転送する]を参照してください。

ファイルの転送が完了したら、次の準備を行っておきます。

  1. インストールは現在ログインしているec2-userで行います。ec2-userのLANG環境変数が英語になっている場合は、日本語(ja_JP.UTF-8)に変更しておきます。

    $ echo $LANG
    en_US.UTF-8
    $ export LANG=ja_JP.UTF-8
    $ echo $LANG
    ja_JP.UTF-8
    
  2. 転送したインストーラに実行権限を与えます。

    $ chmod +x ./elixirreport87_linux64.bin
    $ ls -la
    -rwxr-xr-x. 1 ec2-user ec2-user 279506476 Sep 29 00:00  elixirreport87_linux64.bin
    

GUIインストーラの実行とエラーの発生

いよいよインストーラを実行してみます。しかし、エラーでインストーラが終了してしまいました。必要なライブラリがRed Hat側に不足しているようです。

$ ./elixirreport87_linux64.bin
Preparing to install...
Extracting the JRE from the installer archive...
Unpacking the JRE...
Extracting the installation resources from the installer archive...
Configuring the installer for this system's environment...
strings: '/lib/libc.so.6': No such file

Launching installer...

Invocation of this Java Application has caused an InvocationTargetException. This application will now exit. (LAX)

Stack Trace:
java.lang.NoClassDefFoundError: Could not initialize class java.awt.Toolkit
        at java.awt.Component.<clinit>(Component.java:593)
        at com.zerog.ia.installer.LifeCycleManager.g(DashoA8113)
        at com.zerog.ia.installer.LifeCycleManager.h(DashoA8113)
        at com.zerog.ia.installer.LifeCycleManager.a(DashoA8113)
        at com.zerog.ia.installer.Main.main(DashoA8113)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:497)
        at com.zerog.lax.LAX.launch(DashoA8113)
        at com.zerog.lax.LAX.main(DashoA8113)
This Application has Unexpectedly Quit: Invocation of this Java Application has caused an InvocationTargetException. This application will now exit. (LAX)

必要なライブラリをインストールして実行時エラーを解消する

  1. 上記のエラーを最初から確認すると、まずlibc.so.6ファイルが見つからないという内容のエラーが出力されているので、次のコマンドでlibc.so.6ライブラリをインストールします。

    $ sudo yum -y install libc.so.6
    
  2. 次に発生しているInvocationTargetExceptionは、X11のライブラリが不足していることが原因のようです。必要なライブラリをインストールします。

    $ sudo yum –y install libXtst
    

起動したGUIインストーラの日本語が□に…フォントをインストールする

  1. 再度インストーラを実行してみます。

    $ ./elixirreport87_linux64.bin
    
  2. インストーラのGUIが起動しましたが、日本語が□表示になっています。Linux側に日本語フォントがインストールされていないことが原因でしょう。左下のキャンセルボタンをクリックしてインストールを中止します。
    13GUIトーフになる.png

    14終了02.png

  3. 日本語フォントをインストールします。VLゴシック、IPA明朝、IPAゴシックをインストールしました。

    $ sudo yum -y install vlgothic-fonts ipa-mincho-fonts ipa-gothic-fonts 
    

GUIインストールを実行する

  1. 再度インストーラを起動します。今度は日本語も表示されるようになりました。
    15GUI_01.png

  2. [次へ]で進み、[使用許諾契約の条項に同意する]にチェックして、進みます。
    16GUI_02.png

  3. [ライセンスキーファイルの登録]をクリックして、登録するライセンスファイルを選択します。
    17GUI_03.png

  4. インストールするモジュールにチェックが入っていることを確認して、次に進みます。この画面では、先ほどの手順で追加したライセンスでインストールできるモジュールだけが表示されます。18GUI_04.png

  5. レポートサーバーで使用するポート(今回はデフォルトの7001)、ログレベルを確認します。デフォルトのまま進みます。
    19GUI_ポート設定.png

  6. インストール先ディレクトリは、ec2-userにアクセス権のある場所を選択します。今回はユーザーディレクトリの下にします。
    20GUI_インストール先.png

    [注意]ec2-userに書き込み権限のない場所を指定すると、エラーが表示されます。

  7. 確認画面で内容を確認したら、[インストール]をクリックします。
    21GUI_確認.png

  8. 次の画面が表示されれば完了です。
    22GUI完了.png

ヘッドレスモードの設定とレポートサーバーの起動

インストールはX11転送でGUIを利用しましたが、今後、レポートサーバーの実行時にX Window Systemに接続できない場合は、Javaのヘッドレスモードを有効にする必要があります。

  1. レポートサーバーのインストール先/binディレクトリに移動します。筆者の環境では/home/ec2-user/ElixirReport87J/bin/になります。

    $ cd /home/ec2-user/ElixirReport87J/bin
    
  2. レポートサーバーの起動シェルスクリプトをバックアップした後、編集します。

    $ cp reportserver-start.sh reportserver-start.sh_org
    $ vi reportserver-start.sh
    

    ※5行目のheadless設定を追加して、保存します。

    #!/bin/sh
    JAVACMD="../jre/bin/java"
    
    $JAVACMD -mx512M 
            -Djava.awt.headless=true 
            -Duser.home=../license 
     (以下省略)
    
  3. レポートサーバーの起動シェルスクリプトを実行します。

    $ ./reportserver-start.sh &
    

    ※”&”を付加してバックグラウンド実行にします。

    【注意】起動ユーザーのLANG環境変数が英語の場合、レポートサーバーが英語ロケールで起動され、Webインターフェースのメニューなどが英語表示になってしまいます。日本語ロケールへ変更して起動してください。

  4. 起動に成功すると、コンソール上に次のようにCopyrightが表示されます。

    INFO  [main] com.elixirtech.ers2.Main - Copyright 2016 Elixir Technology Pte Ltd
    INFO  [Thread-19] com.elixirtech.ers2.EnsureServerStarted - Checking server     status
    
  5. Windows上のブラウザからレポートサーバーのWebインターフェースにログインしてみます。

    http://<パブリックIP>:7001
    

    23WebインターフェースURL.png

    【注意】ログイン画面が表示されないときは、以下のような原因が考えられます。
    ・レポートサーバーの起動に失敗している
    ・Red Hatインスタンスのセキュリティグループの設定で、ポート”7001”を追加していない

  6. ログイン画面が表示されたら、デフォルトで用意されている次の管理者ユーザーでログインします。

    ユーザー名: admin
    パスワード: sa
    
  7. [リポジトリ]以下のサンプルテンプレートを実行してみます。
    [samples]‐[demo]-[sales2]-[sales2.rml]を選択して、出力形式に”PDF”を選んで[OK]をクリックします。
    24レポート生成PDF選択.png

  8. PDF形式のレポートが生成できました。
    25フォントインストール後の結果.png

以上で完了です。

参考情報

Q1. No X11 DISPLAY variable was setエラーでインストールが終了する

X11などの設定を何も行っていない状態でGUIインストールを実行すると、X11のエラーでインストーラが終了してしまいます。この記事の[X11転送の設定をする]の項目を確認してみてください。

[参考情報]エラー出力の例
$ ./elixirreport87_linux64.bin
Preparing to install...
Extracting the JRE from the installer archive...
Unpacking the JRE...
Extracting the installation resources from the installer archive...
Configuring the installer for this system's environment...
strings: '/lib/libc.so.6': No such file

Launching installer...

Invocation of this Java Application has caused an InvocationTargetException. This application will now exit. (LAX)

Stack Trace:
java.awt.HeadlessException:
No X11 DISPLAY variable was set, but this program performed an operation which requires it.
        at java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:207)
        at java.awt.Window.<init>(Window.java:536)
        at java.awt.Frame.<init>(Frame.java:420)
        at java.awt.Frame.<init>(Frame.java:385)
        at javax.swing.JFrame.<init>(JFrame.java:189)
        at com.zerog.ia.installer.LifeCycleManager.g(DashoA8113)
        at com.zerog.ia.installer.LifeCycleManager.h(DashoA8113)
        at com.zerog.ia.installer.LifeCycleManager.a(DashoA8113)
        at com.zerog.ia.installer.Main.main(DashoA8113)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:497)
        at com.zerog.lax.LAX.launch(DashoA8113)
        at com.zerog.lax.LAX.main(DashoA8113)
This Application has Unexpectedly Quit: Invocation of this Java Application has caused an InvocationTargetException. This application will now exit. (LAX)

Q2. フォントをインストールしても、日本語が□のままになる

fc-listコマンドがRed Hatインスタンスで実行できるか確認してください。コマンドが入っていない場合は、フォントの管理に使用されるfontconfigパッケージを次のコマンドでインストールして、fc-listコマンドが使用できるようになるか確認した上で、再度インストールを試してみてください。

$ sudo yum –y install fontconfig

※この記事では、X11転送の確認用にxeyesアプリケーションをインストールしています。このインストール中、依存関係によりfontconfigが一緒にインストールされるため、日本語の表示には問題ありませんでした。xeyesをインストールしなかった場合は、別途fontconfigをインストールする必要があります。

Q3. Xアプリケーションを起動したが、Windows側にX転送エラーが表示される

次のようなX転送のエラーが出るときは、XmingがWindows側で起動していることを確認してください。
12TTSSHエラー.png

Q4. レポートサーバー起動時にWindows側にX転送エラーが表示され、レポートサーバーが起動できない

Q3と同様のエラーが表示され、レポートサーバーの起動中に次のようなjava.awt.AWTErrorが出力される場合は、ヘッドレスモードの設定が正しく行われていない可能性があります。この記事の[ヘッドレスモードの設定とレポートサーバーの起動]の項目を参考に、起動シェルスクリプトの編集を行ってみてください。

Exception in thread "main" java.awt.AWTError: Can't connect to X11 window server using 'localhost:10.0' as the value of the DISPLAY variable.
        at sun.awt.X11GraphicsEnvironment.initDisplay(Native Method)
        at sun.awt.X11GraphicsEnvironment.access$200(X11GraphicsEnvironment.java:65)
(以下省略)

続きを読む

JAWS DAYS 2017 ワークショップ Docker on Elastic Beanstalk 〜Days after tomorrow〜 (2)

この記事では、複数のDockerコンテナで構成される環境を構築するための設定例を具体的に解説します。ワークショップのフォローアップではありますが、一般的な事柄を扱いますので、ワークショップに参加されていない方にもお読み頂ける内容です。

前回の記事: JAWS DAYS 2017 ワークショップ Docker on Elastic Beanstalk 〜Days after tomorrow〜 (1)

春ですね

こんにちは。Emotion Techの子安です。ようやく暖かくなってきましたね。やっぱり春といえば桜ですかね!

sakura.jpg

恐縮です。

前回のつづき

さて、前回はテーマとする環境の構成を説明し、利用するコンテナ定義ファイル docker-compose.yml の枠組みを解説しました。更に web app db コンテナのうち、 web db コンテナの設定を見ました。今回はアプリケーションそのものである app コンテナを見ていきます。

各コンテナの設定 2

appコンテナ

app:
  image: phusion/passenger-ruby23:0.9.20
  environment:
    APPLICATION_ENV: development
    APPLICATION_ROLE: app
    PASSENGER_APP_ENV: development
  labels:
    eb.workshop.role: app
  networks:
    - eb.workshop
  depends_on:
    - db
  volumes:
    - ./app/init/40_setup.sh:/etc/my_init.d/40_setup.sh:ro
    - ./app/passenger/passenger.conf:/etc/nginx/sites-available/default:ro
    - ./app/rails-app:/var/www/rails-app

Ruby on Railsのアプリを実行するappコンテナです。phusion/passenger-dockerイメージを利用しています。このイメージはさまざまな機能を持っていますが、まずは設定内容を見ましょう。

  • image: phusion/passenger-dockerイメージを指定しています。
  • environment: イメージ側で PASSENGER_APP_ENV 環境変数を読んでRailsの環境を切り替えてくれる機能があります。
  • volumes: ここで3つのマウントを指定しています。コンテナ側のパスを見てください。

    • /etc/my_init.d/40_setup.sh:ro: /etc/my_init.d 配下に置いたスクリプトを初期化時に実行してくれる機能があります。実行権限を忘れずにつけるようにします。 :ro は読み取り専用の意味です。
    • /etc/nginx/sites-available/default:ro: ここにnginxの設定ファイルが置かれています。
    • /var/www/rails-app: Railsのアプリケーションをここに置きます。これは任意の場所で構いません。上記のnginx設定ファイルに記述しています。

phusion/passenger-docker

phusion/passenger-dockerは、Phusion社がメンテナンスしているDockerイメージです。このイメージは、さらに別のイメージ phusion/baseimage-docker をベースとして作られています。このphusion/baseimage-dockerには、いくつかの有用な機能が含まれています。

  • 正しいinitプロセス: /sbin/my_init にinitプロセスを内蔵しています。本来initプロセスには、親プロセスのいなくなった子プロセス(孤児)を里親として引き受ける役割があります。加えて SIGTERM を受け取った際に、他のサービスを終了させる機能を持ちます。
  • スーパーバイザ: 軽量なスーパーバイザ runit を内蔵しています。
  • ログマネージャ: syslogデーモン syslog-ng を内蔵しています。logrotateも設定済みです。
  • cron: cronデーモンを内蔵しています。

重要なことは、これらの機能が協調動作するように設定されていることです。 /sbin/my_init がrunitを立ち上げ、runitがsyslog-ngやcronを管理します。デフォルトのコンテナ起動コマンドが /sbin/my_init に設定されていますので、

docker run phusion/baseimage

として起動することで、最小限のコンテナ化されたLinux(Ubuntu)環境を手に入れることができます。他にも、今回も利用している /etc/my_init.d 配下のスクリプトを初期化時に実行する機能、root以外でコマンドを実行するための setuser コマンドなど、様々な機能や仕組みを備えています。詳しくはWebページを参照ください。

phusion/passenger-dockerは、このphusion/baseimage-dockerの上に、nginxやrubyのアプリケーションサーバである Phusion Passenger をインストールしてあります。nginxはrunitの配下に設定されていますので、すぐにスーパーバイズされたデーモンとして稼働させることができます。

コンテナ初期化スクリプト

可能なことはコンテナ自身に判断させるのが良い設計です。そのためにコンテナ起動時に実行するスクリプトを組み込むことがよく行われます。今回 app コンテナで設定している初期化スクリプトの内容を見てみましょう。 /app/init/40_setup.sh を参照ください。

このスクリプトの主な役割は4つです。

  • nginxを起動可能にする
  • Railsアプリのセットアップ
  • 環境変数の引き渡し
  • DBマイグレーション

ハンズオンのため、本来はコンテナ初期化スクリプトに記述すべきでない処理もここに入っていますが、続けて詳しく説明します。

/app/init/40_setup.sh
rm -f /etc/service/nginx/down

これはrunitの機能です。サービスを定義するディレクトリ(今回は /etc/service/nginx )の直下に down という名前のファイルがあると、自動起動しません。phusion/passenger-dockerイメージ側で配置されているものですが、自動起動してほしいのでファイルを削除しています。

/app/init/40_setup.sh
chown -R app:app /var/www
cd /var/www/rails-app
setuser app bundle install --path=../vendor/bundle
if [ "$PASSENGER_APP_ENV" = 'production' ]; then
  setuser app bin/rails assets:precompile
  setuser app bundle install --path=../vendor/bundle --without test development --deployment --clean
fi

このあたりは実環境であればCIで、ビルドの一処理として適切に実施すべきものです。アプリケーションのファイルパーミッションを適切に設定し、ライブラリのインストールを行います。更にproductionモードであれば、アセットのプリコンパイルと不要なライブラリの削除を行います。

/app/init/40_setup.sh
echo "passenger_env_var 'SECRET_KEY_BASE' '$SECRET_KEY_BASE';" >> /etc/nginx/conf.d/10_setenv.conf
echo "passenger_env_var 'RDS_HOSTNAME' '$RDS_HOSTNAME';" >> /etc/nginx/conf.d/10_setenv.conf

ここは環境変数をpassengerへ引き渡すための処理です。コンテナでは環境変数を扱う機会が多くなりますので、利用するミドルウェアに合わせて設定が必要です。

/app/init/40_setup.sh
RAILS_ENV=$PASSENGER_APP_ENV setuser app bin/rails db:create db:migrate

こちらはDBのマイグレーションです。この処理も実環境であればコンテナ初期化スクリプトではなく、デプロイの手順の一貫として実施すべきものです。

次回へ

ここまでが app コンテナの設定でした。長くなりましたので、つづきは次回にしたいと思います。次回はElastic Beanstalkの設定ファイル、Dockerrun.aws.jsonを解説する予定です。

続きを読む

Mastodonでgit pullしたらビルドエラー

概要

EC2で稼働させているMastodongit pullした後にdocker-compose buildしたら下記エラーが出てハマった。

環境

  • AWS EC2(t2.medium)
  • Ubuntu Server 16.04 LTS

エラー内容

ubuntu@ip-***-***-**-**:~/mastodon$ docker-compose build
redis uses an image, skipping
db uses an image, skipping
Building streaming
Step 1/9 : FROM ruby:2.4.1-alpine
 ---> 5eadd5d1419a
Step 2/9 : LABEL maintainer "https://github.com/tootsuite/mastodon" description "A GNU Social-compatible microblogging server"
 ---> Using cache
 ---> 95a4b711ef32
Step 3/9 : ENV RAILS_ENV production NODE_ENV production
 ---> Using cache
 ---> 499e95f00e13
Step 4/9 : EXPOSE 3000 4000
 ---> Using cache
 ---> 167a91f421f4
Step 5/9 : WORKDIR /mastodon
 ---> Using cache
 ---> e185ae07f027
Step 6/9 : COPY Gemfile Gemfile.lock package.json yarn.lock /mastodon/
 ---> Using cache
 ---> 460d49537428
Step 7/9 : RUN BUILD_DEPS="     postgresql-dev     libxml2-dev     libxslt-dev     build-base"  && apk -U upgrade && apk add     $BUILD_DEPS     nodejs     libpq     libxml2     libxslt     ffmpeg     file     imagemagick  && npm install -g npm@3 && npm install -g yarn  && bundle install --deployment --without test development  && yarn --ignore-optional  && yarn cache clean  && npm -g cache clean  && apk del $BUILD_DEPS  && rm -rf /tmp/* /var/cache/apk/*
 ---> Running in 68a8d45af6e8
fetch http://dl-cdn.alpinelinux.org/alpine/v3.4/main/x86_64/APKINDEX.tar.gz
ERROR: http://dl-cdn.alpinelinux.org/alpine/v3.4/main: No such file or directory
WARNING: Ignoring APKINDEX.167438ca.tar.gz: No such file or directory
fetch http://dl-cdn.alpinelinux.org/alpine/v3.4/community/x86_64/APKINDEX.tar.gz
ERROR: http://dl-cdn.alpinelinux.org/alpine/v3.4/community: No such file or directory
WARNING: Ignoring APKINDEX.a2e6dac0.tar.gz: No such file or directory
OK: 21 MiB in 29 packages
WARNING: Ignoring APKINDEX.167438ca.tar.gz: No such file or directory
WARNING: Ignoring APKINDEX.a2e6dac0.tar.gz: No such file or directory
ERROR: unsatisfiable constraints:
  build-base (missing):
    required by: world[build-base]
  ffmpeg (missing):
    required by: world[ffmpeg]
  file (missing):
    required by: world[file]
  imagemagick (missing):
    required by: world[imagemagick]
  libpq (missing):
    required by: world[libpq]
  libxml2 (missing):
    required by: world[libxml2]
  libxml2-dev (missing):
    required by: world[libxml2-dev]
  libxslt (missing):
    required by: world[libxslt]
  libxslt-dev (missing):
    required by: world[libxslt-dev]
  nodejs (missing):
    required by: world[nodejs]
  postgresql-dev (missing):
    required by: world[postgresql-dev]
ERROR: Service 'streaming' failed to build: The command '/bin/sh -c BUILD_DEPS="     postgresql-dev     libxml2-dev     libxslt-dev     build-base"  && apk -U upgrade && apk add     $BUILD_DEPS     nodejs     libpq     libxml2     libxslt     ffmpeg     file     imagemagick  && npm install -g npm@3 && npm install -g yarn  && bundle install --deployment --without test development  && yarn --ignore-optional  && yarn cache clean  && npm -g cache clean  && apk del $BUILD_DEPS  && rm -rf /tmp/* /var/cache/apk/*' returned a non-zero code: 11

解決方法

$ git checkout $(git describe --tags `git rev-list --tags --max-count=1`)

ハマってる最中にREADMEに安定バージョン使ってねって追記されてましたとさ。。

追記

v1.2にしたところ下記のエラーが再現。調査中。

ubuntu@ip-***-**-**-***:~/mastodon$ docker-compose build
redis uses an image, skipping
db uses an image, skipping
Building streaming
Step 1/9 : FROM ruby:2.4.1-alpine
 ---> 5eadd5d1419a
Step 2/9 : LABEL maintainer "https://github.com/tootsuite/mastodon" description "A GNU Social-compatible microblogging server"
 ---> Using cache
 ---> 95a4b711ef32
Step 3/9 : ENV RAILS_ENV production NODE_ENV production
 ---> Using cache
 ---> 499e95f00e13
Step 4/9 : EXPOSE 3000 4000
 ---> Using cache
 ---> 167a91f421f4
Step 5/9 : WORKDIR /mastodon
 ---> Using cache
 ---> e185ae07f027
Step 6/9 : COPY Gemfile Gemfile.lock package.json yarn.lock /mastodon/
 ---> Using cache
 ---> 06b33c54cfd4
Step 7/9 : RUN echo "@edge https://nl.alpinelinux.org/alpine/edge/main" >> /etc/apk/repositories  && BUILD_DEPS="     postgresql-dev     libxml2-dev     libxslt-dev     build-base"  && apk -U upgrade && apk add     $BUILD_DEPS     nodejs@edge     nodejs-npm@edge     libpq     libxml2     libxslt     ffmpeg     file     imagemagick@edge  && npm install -g npm@3 && npm install -g yarn  && bundle install --deployment --without test development  && yarn --ignore-optional  && yarn cache clean  && npm -g cache clean  && apk del $BUILD_DEPS  && rm -rf /tmp/* /var/cache/apk/*
 ---> Running in 0b9005a839d9
fetch http://dl-cdn.alpinelinux.org/alpine/v3.4/main/x86_64/APKINDEX.tar.gz
ERROR: http://dl-cdn.alpinelinux.org/alpine/v3.4/main: No such file or directory
WARNING: Ignoring APKINDEX.167438ca.tar.gz: No such file or directory
fetch http://dl-cdn.alpinelinux.org/alpine/v3.4/community/x86_64/APKINDEX.tar.gz
ERROR: http://dl-cdn.alpinelinux.org/alpine/v3.4/community: No such file or directory
WARNING: Ignoring APKINDEX.a2e6dac0.tar.gz: No such file or directory
fetch https://nl.alpinelinux.org/alpine/edge/main/x86_64/APKINDEX.tar.gz
140162439957356:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:794:
ERROR: https://nl.alpinelinux.org/alpine/edge/main: Permission denied
WARNING: Ignoring APKINDEX.65bdaf85.tar.gz: No such file or directory
OK: 21 MiB in 29 packages
WARNING: Ignoring APKINDEX.167438ca.tar.gz: No such file or directory
WARNING: Ignoring APKINDEX.a2e6dac0.tar.gz: No such file or directory
WARNING: Ignoring APKINDEX.65bdaf85.tar.gz: No such file or directory
WARNING: The repository tag for world dependency 'nodejs@edge' does not exist
WARNING: The repository tag for world dependency 'nodejs-npm@edge' does not exist
WARNING: The repository tag for world dependency 'imagemagick@edge' does not exist
ERROR: Not committing changes due to missing repository tags. Use --force to override.
ERROR: Service 'streaming' failed to build: The command '/bin/sh -c echo "@edge https://nl.alpinelinux.org/alpine/edge/main" >> /etc/apk/repositories  && BUILD_DEPS="     postgresql-dev     libxml2-dev     libxslt-dev     build-base"  && apk -U upgrade && apk add     $BUILD_DEPS     nodejs@edge     nodejs-npm@edge     libpq     libxml2     libxslt     ffmpeg     file     imagemagick@edge  && npm install -g npm@3 && npm install -g yarn  && bundle install --deployment --without test development  && yarn --ignore-optional  && yarn cache clean  && npm -g cache clean  && apk del $BUILD_DEPS  && rm -rf /tmp/* /var/cache/apk/*' returned a non-zero code: 255

続きを読む

Docker for Mac で Amazon Linuxのコンテナイメージを動かす

はじめに

macbook air をクリーンインストールしたついでに、開発環境をイチから構築していました。
Docker の コンテナイメージ何にしようかと探していたら Amazon Linuxがコンテナ化されていたんですね。
(今更しりました…。)
ということで、折角知ったので macで Amazon Linuxのコンテナを動かしてみます。

前準備

docker for mac のインストール

$ brew cask install docker
$ docker -v

Docker version 17.03.1-ce, build c6d412e

aws cli の インストール と 設定

$ brew install awscli
$ aws --version

aws-cli/1.11.76 Python/2.7.10 Darwin/16.5.0 botocore/1.5.39
$ aws configure

AWS Access Key ID [None]: `IAMのアクセスキー`
AWS Secret Access Key [None]: `上記IAMのシークレットキー`
Default region name [None]: ap-northeast-1
Default output format [None]: json

ここから本番

AmazonLinuxコンテナが配布されているECRへのログインコマンドを取得します。

$ aws ecr get-login --region ap-northeast-1 --registry-ids 137112412989
docker login -u AWS -p 'パスワード' -e none https://137112412989.dkr.ecr.ap-northeast-1.amazonaws.com

上記のコマンドが表示されるので、コピペして実行します。

Flag --email has been deprecated, will be removed in 1.14.
Login Succeeded

ログイン成功したようなので、イメージの種類を aws ecr list-imagesで確認してみます。

$ aws ecr list-images --region ap-northeast-1 --registry-id 137112412989 --repository-name amazonlinux | grep 'imageTag'

"imageTag": "2016.09.0.20161028-with-sources",
"imageTag": "2016.09.1.20161221",
"imageTag": "with-sources",
"imageTag": "2016.09.0.20161118",
"imageTag": "2016.09-with-sources",
"imageTag": "latest-with-sources",
"imageTag": "latest",
"imageTag": "2016.09.1.20161221-with-sources",
"imageTag": "2016.09",
"imageTag": "2016.09.0.20161118-with-sources",
"imageTag": "2016.09.0.20161028"

ここでは もちろん latestをローカルにpull してみます。

$ docker pull 137112412989.dkr.ecr.ap-northeast-1.amazonaws.com/amazonlinux:latest
$ docker images

REPOSITORY                                                      TAG                 IMAGE ID            CREATED             SIZE
137112412989.dkr.ecr.ap-northeast-1.amazonaws.com/amazonlinux   latest              ff59a593059d        3 months ago        292 MB

試しに実行してみます。 docker run

$ docker run -it 137112412989.dkr.ecr.ap-northeast-1.amazonaws.com/amazonlinux:latest /bin/bash

bash-4.2# cat /etc/system-release
Amazon Linux AMI release 2016.09

おお。できてますね!
必要最低限のパッケージしか入っていないみたいなので、次回はこれを使って環境構築をしていきます。

image

classmethodさんの記事に cawsayが載っていたので、真似してみました。:-)

SEE ALSO

続きを読む