AmazonLinuxにClamAVをインストールしちゃったよ

Amazon LinuxにClamAVをインストール方法について記載しますー

環境

  • InstanceType:t2.medium
  • OS:Amazon Linux AMI release 2015.03

ClamAVインストール

$ sudo yum -y install clamav
$ sudo yum -y install clamav-update

パターンファイル更新

設定ファイルの編集しますー

$ sudo vim /etc/freshclam.conf
### Exampleをコメント化
# Comment or remove the line below.
Example
↓
# Comment or remove the line below.
# Example

### コメント外す
#UpdateLogFile /var/log/freshclam.log
↓
UpdateLogFile /var/log/freshclam.log

### コメントアウトを外す
#LogTime yes
↓
LogTime yes

パターンファイル自動更新

5分単位で自動更新されるように設定します。

$ sudo vim /etc/cron.d/clamav-update
### 時間間隔を変更
0  */3 * * * root /usr/share/clamav/freshclam-sleep
↓
0  */5 * * * root /usr/share/clamav/freshclam-sleep

自動更新の有効化

自動更新の有効化を実施します。

$ sudo vim /etc/sysconfig/freshclam
### コメント化
FRESHCLAM_DELAY=disabled-warn  # REMOVE ME#FRESHCLAM_DELAY=disabled-warn  # REMOVE ME

バージョン確認

$ sigtool --version
ClamAV 0.98.7/20394/Thu Apr 30 01:37:08 2015

パターンファイルのダウンロード先変更

パターンファイルのダウンロード先を日本とアメリカに設定します。
 ※ダウンロードが集中すると失敗する可能性があるため

### デフォルトをコメントアウト
#DatabaseMirror database.clamav.net

### 追加
DatabaseMirror db.jp.clamav.net
DatabaseMirror db.us.clamav.net

パターンファイルの更新

手動でパターンファイルの更新をします。

$ sudo freshclam

スキャンテスト

アンチウィルスのテストファイルとして利用されるeicarを作成します。
テキストファイルにテストコードを埋め込みます。

$ vim ~/eicar.com
X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*

準備できたので、スキャンしますー

$ sudo clamscan -r -i ~

----------- SCAN SUMMARY -----------
Known viruses: 6260545
Engine version: 0.98.7
Scanned directories: 1
Scanned files: 7
Infected files: 1
Data scanned: 0.02 MB
Data read: 0.01 MB (ratio 2.00:1)
Time: 11.612 sec (0 m 11 s)

スキャン結果に「Infected files: 1」と検出されましたね。
ということで、以上でClamAVのインストール方法でしたーヽ(*゚д゚)ノ

補足

ClamAVのバージョンが低いと以下のように怒られます。
最新版にアップデートするか、もしくは、2017.3のAmazon Linux AMIを使用することで、ClamAVのパッケージが最新化できます。
Amazon Linux AMI 2017.3 Packages

$ sudo freshclam
ClamAV update process started at Sun Apr 16 11:05:13 2017
WARNING: Your ClamAV installation is OUTDATED!
WARNING: Local version: 0.98.7 Recommended version: 0.99.2

続きを読む

JenkinsおじさんのためのAWS Batch

はじめに

この記事の対象者

主にこんな感じの人をターゲットにしています。

  • Jenkinsでジョブを管理している
  • AWSをcliで触るのは実は大変…。GUIでやりたい
  • Dockerはインストールはしているけれど、あんまり触ったことが無い

また、本記事執筆時点では、us-east(virginia)でのみ利用可能なので、VPCでの利用はあまり想定していません。 (VPNを繋げば出来ると思いますが…)
本来はAuto ScalingやSPOTインスタンスと組み合わせたりといろいろあるのですが、私的事情により、志は低く、過疎っているJenkinsサーバを廃止(サーバレス化)することを目標にしています。

対象のJenkinsジョブ

今回ターゲットにするのは、Jenkinsだと一般的と思われる以下の処理とします。

  • JDKがバージョン指定で入っている
  • バッチ処理の入ったリポジトリをgit cloneしてくる
  • シェルスクリプトからごにょごにょして、リポジトリの中身を実行する

PHPやRubyなど別言語の人は、Javaな部分は脳内で別言語に置き換えてみてください。

AWS Batchでの流れ

Jenkinsでごく一般的なこの処理をAWS Batchでやろうとした場合、以下のような流れが一番シンプルになるかなと思います。

  1. JDK等、必要な実行環境を準備したDockerfileを作成する
  2. Jenkinsでやっていたシェル相当のシェルスクリプトを作成する
  3. リポジトリにDockerfileとシェルスクリプトを追加する
  4. Amazon ECRに設定を作成する
  5. Dockerfileでビルドし、JDK及びバッチ処理のリポジトリの入ったコンテナを作成し、ECRにプッシュする
  6. AWS Batchの設定(IAM Role, Compute Environment, Job Definition等)を作成する
  7. AWS Batchを実行する

というわけで、ハンズオン的に進めて行きたいと思います。

作業手順

1. Dockerfileの作成

古風なエンジニアにはこちらの記事が一番わかりやすいんじゃないかと思います。

効率的に安全な Dockerfile を作るには

今回のケースだとJavaのバッチ(Hello.class)を動かしたいので

$ ls
Hello.class

$ vim Dockerfile

として、以下のようなDockerfileを作成します。

Dockerfile
FROM centos:6

RUN yum install -y java-1.7.0-openjdk java-1.7.0-openjdk-devel
ENV JAVA_HOME /usr/lib/jvm/java-openjdk
RUN mkdir /opt/batch-directory
COPY . /opt/batch-directory/
WORKDIR /opt/batch-directory

Javaは諸々の事情からOpenJDKにしていますが、Oracle Javaが必要な場合は、少し手間はかかりますが、Oracle Javaでもコンテナを作成することはできます。また、本来だとベースイメージはAmazonLinuxだったりJavaが入ったコンテナの方が良いと思いますが、保守的な方のために、敢えてCentOSにしました。(あんまり意味ないかな…)

2. シェルスクリプトの作成

Jenkinsにバッチを実行するためのシェルスクリプト(Jenkinsでコマンド欄に入れていたようなもの)を作ります。

$ ls
Dockefile
Hello.class

$ vim batch.sh

今回は解説用なので雑なものを用意しています。

batch.sh
#!/bin/bash

java -version
java Hello

3. Dockerfileとシェルスクリプトをリポジトリに追加

せっかく作成したので、これらのファイルをGitリポジトリに追加しましょう。(これはこの後の工程上の必須項目ではないので、一連がテストされてからでも大丈夫です)

4. Amazon ECRにリポジトリを作成する

Amazon EC2 Container Registry(ECR)にリポジトリを作成します。ここではリポジトリ名を入れるだけです。
Amazon EC2 Container Service.png

5. Dockerfileでビルド

先ほど付けた名前を使って、Docker buildをします。

$ docker build -t unagi/jenkins-ojisan .

6. コンテナをECRに登録する

タグ付けして、先ほど作成したECRに登録してあげます。

$ aws ecr get-login --region us-east-1

# これでdocker loginに必要なコマンドがでてくるので、実際はそれを使う
$ docker login -u AWS -p xxxxxx -e none https://xxxx.dkr.ecr.us-east-1.amazonaws.com
$ docker tag unagi/jenkins-ojisan:latest xxxx.ecr.us-east-1.amazonaws.com/unagi/jenkins-ojisan:latest
$ docker push xxxx.ecr.us-east-1.amazonaws.com/unagi/jenkins-ojisan:latest

7. AWS Batchの設定をつくる

Job definitionとCompute environmentを設定します。

こちらがJob definitionで、コンテナを起動するときの設定になります。環境変数を設定できるので、パラメータを渡したい場合は使う事ができます。
AWS Batch (1).png

S3アクセス等でIAM Roleを使いたい場合は、ここで定義するJob Roleで定義する必要があります。そしてさらに分かりにくいことに、ここに表示されるIAM Roleを作るためには、信頼するエンティティがAmazon EC2 Container Service Task Role(ecs-tasks.amazonaws.com)のIAM Roleを作る必要があります。IAM Role作成時に似たようなのが沢山あるので、非常に解りづらいところです。

そして、次の画面はCompute environmentです。
AWS Batch (2).png
こちらはあまり見所は無く、淡々と設定していきます。ここで出てくるRoleは、ECSで動作するために必要なもので、コンテナで使うモノではありません。なので、適当に作成します…。

8. AWS Batchの実行

Job definitionsからSubmit jobして実行します。実行時に先ほど設定した環境変数を変更しながらの実行等もできます。
ちなみにこれも凄く分かりにくいのですが、Job definitionを編集したい場合はCreate new versionです。新しいバージョンの定義が出来てしまうので、古い方は不要になった段階で削除してしまいましょう。

9. 実行ログの確認

CloudWatchのログから見ます。Submitしてから起動までは少し時間がかかるので、少し待たないとログ出力はされません。

あとがき

Jenkinsおじさん的には、Dockerが出てくるため取っつき辛い印象を持つのかなと思います。
美しくDockerを使う場合はさておき、バッチ処理をやるだけであれば、Dockerfileに書くのはバッチサーバを作るときのセットアップコマンドで、一回やってしまえばあまり難しくないです。

続きを読む

AWSのCentos7上にJPiereを立ち上げる

AWS上にJPiere(iDempiere)を構築する 忘却録

  • AWSインスタンスの作成
  • CentOS7の初期設定

AWS上にCentOS7 インスタンスを作成する

テスト的に作成するので、t2.small構成で作成しました。
セキュリティグループを作成する時に「全てのTCPトラフィックを許可する」「IPアドレス→My IP」として、緩いセキュリティながらもとりあえず安全な環境を作りました。

TeraTermでインスタンスに接続

インスタンス作成時のセキュリティキーを指定すればAWS上インスタンスに繋がります
単純なことですが、AWSインスタンスCentOS7 のデフォルトアカウント名は「centos」です。以前はEC2-userだったと思うので要注意です
私は、ログイン出来ずに多くの時間を費やしてしまいました

CentOS7の初期設定をザックリと

Update

$ sudo yum update

SELINUXの廃止

/etc/selinux/configに対して SELINUX=disabled
$ sudo yum install wget unzip vim

よく使うツールをインストール

$sudo yum install -y net-tools bind-utils NetworkManager-tui
$yum install bash-completion
$wget https://github.com/terralinux/systemd/raw/master/src/systemctl-bash-completion.sh -O /etc/bash_completion.d/systemctl-bash-completion.sh
$sudo localectl set-locale LANG=ja_JP.utf8
$sudo localectl set-keymap jp106
$sudo timedatectl set-timezone Asia/Tokyo

使わないサービスを停止

$sudosystemctl list-unit-files –type service | grep enabled
$sudo systemctl stop postfix
$sudo systemctl disable postfix

Javaをインストールします

今回はOpenJDK8を入れます
$sudo yum install java

Postgresql 9.4 をインストールします

JPiere4.1 はPostgresql9.4らしいので
$wget https://download.postgresql.org/pub/repos/yum/9.4/redhat/rhel-7-x86_64/pgdg-centos94-9.4-3.noarch.rpm
–2017-04-07 12:27:42– https://download.postgresql.org/pub/repos/yum/9.4/redhat/rhel-7-x86_64/pgdg-centos94-9.4-3.noarch.rpm
  rpmはhttps://yum.postgresql.org/repopackages.php ここから探す
$sudo rpm -ivh pgdg-centos94-9.4-3.noarch.rpm
$sudo yum -y install postgresql94-server postgresql94-devel postgresql94-contrib

初期化します

$sudo su
$su – postgres
-bash-4.2$ cd /var/lib/pgsql/9.4
-bash-4.2$ rm -rf data
-bash-4.2$ /usr/pgsql-9.4/bin initdb –encoding=UTF8 –no-locale –pgdata=/var/lib/pgsql/9.4/data

自動起動させるようにします

$sudo systemctl enable postgresql-9.4
$sudo systemctl start postgresql-9.4

postgresqlのVersion確認

$sudo su – postgres
psql -version
psql
postgres-# select version();
postgres-# q

Postgreユーザーのパスワード設定

 OSのpostgresアカウントとDBのpostgreアカウントがあるので双方パスワードの設定をします

postgres ユーザーのパスワード変更(Unix)

$ sudo passwd postgres

postgres ユーザーのパスワード変更(Postgresql)

$ su – postgres
-bash-4.2$ psql
psql (9.4.1)
Type “help” for help.

postgres=# password postgres
Enter new password: ********
Enter it again: ********
postgres=# q

postgresアクセス許可設定

pg_hba.conf編集

vim /var/lib/pgsql/9.4/data/pg_hba.conf
[…]
host all all 127.0.0.1/32 md5
host all postgres 0.0.0.0/0 md5 # add
[…]

postgresql.conf編集

vim /var/lib/pgsql/9.4/data/postgresql.conf
[…]
listen_addresses = ‘*’
[…]
port = 5432
[…]

postgresql再起動

$sudo systemctl restart postgresql-9.4

pgAdminⅢ のインストール

Postgresqlを管理するために Windows端末に pgAdminⅢをインストールしておく
インストール方法は割愛

pgAdminからの接続を試す

接続が出来ない場合、postgresqlの設定ファイルを再度確認してください
 F/Wの確認
 pg_hba.confの認証方法の確認

ログインロールの作成

名称:adempiere

DB作成

DB名称:idempiere
ここまでpgAdminで実施します

JPiereの入手とインストール

OSDNからJPiere関連ファイルを入手(ExpDat.dmpももらっておく)
$cd /usr/local/etc
$wget https://ja.osdn.net/dl/jpiere/ExpDat.dmp
$wget idempiereServer.gtk.linux.x86_64.zip
$sudo unzip idempiereServer.gtk.linux.x86_64.zip

データベースのリストア

idmepiere-server/data/seedディレクトリに移動します。
Adempiere_pg.jarファイルを解凍します。
$ sudo chmod a+rwx ../seed
$ jar xvf Adempiere_pg.jar
$ psql -d idempiere -U adempiere -f Adempiere_pg.dmp

もしくは ExpDat.dmpのリストア
iDempiereのデータベースのリストア
$ psql -d idempiere -U adempiere -f ExpDat.dmp

alternatives –config java
インストールされているJavaの確認と どのJavaを使うか?の選択

JPiereの初期設定と起動

$ cd /usr/local/etc/idempiere***/idempiere-server
$ sudo sh console-setup.sh
各設定値を入力します
DBはlocalhostで。
$ sudo sh idempiere-server.sh &
起動します
DBに関してのエラーが出た場合 私は
$ sudo sign-database-build.sh を実行して直りました

日本語の設定

$sudo yum -y install ibus-kkc vlgothic-*
$sudo localectl set-locale LANG=ja_JP.UTF-8

動作確認

http://サーバー名:8080/webui
でアクセスできます。

続きを読む

Amazon Linux上にインストールしたGitLab CEにLet’s Encryptを適用する方法

対象環境

GitLab Community Edition 9.0.4
certbot 0.13.0(Let’s EncryptのCLIクライアント)

原理

Let’s Encryptの「webroot」モードを利用する。
webrootモードはサーバに .well-known ディレクトリが置かれていることを認証基準としてSSL証明書を発行する。
GitLabのログインを回避して .well-known をLet’s Encryptに発見させ、SSL証明書を発行するのが本記事の目的である。

手順

※ GitLabはインストールが完了しており、既に稼働しているものとする。

1. GitLabが利用しているNginxの設定を変更する

GitLabのログインを回避して .well-known の存在を確認させるためにNginxのリダイレクト設定を変更する。
まずは設定ファイルを新規作成。

$ sudo vim /etc/gitlab/custom_gitlab_server_config.conf
/etc/gitlab/custom_gitlab_server_config.conf
location ^~ /.well-known {
    alias /var/letsencrypt/.well-known;
}

その後、設定ファイルを適用。

$ sudo vim /etc/gitlab/gitlab.rb
/etc/gitlab/gitlab.rb
nginx['custom_gitlab_server_config'] = "include /etc/gitlab/custom_gitlab_server_config.conf;"

最後に、Let’s Encryptに発見させる用のディレクトリを作成しておく。
.well-known は作成しなくてよい。

$ sudo mkdir /var/letsencrypt

2. GitLabに設定を適用して再起動

$ sudo mkdir /var/letsencrypt

3. Let’s Encryptをインストール

絶対に最後の --debug を忘れないように。
Amazon Linux限定の手法なので他のOSの場合は不要。

$ sudo mkdir /usr/local/letsencrypt
$ sudo chown `whoami` /usr/local/letsencrypt
$ cd /usr/local/letsencrypt
$ git clone https://github.com/letsencrypt/letsencrypt .
$ sudo ./letsencrypt-auto --debug

4. SSL証明書を取得

[gitlab.example.com] の部分はGitLabに適用しているドメインを指定する。

$ sudo ./letsencrypt-auto certonly --webroot --webroot-path /var/letsencrypt -d [gitlab.example.com]

エラーが出た場合

エラーの場合はこんな表示が出る。

IMPORTANT NOTES:
 - The following errors were reported by the server:

   Domain: gitlab.example.com
   Type:   unauthorized
   Detail: Invalid response from

Typeが unauthorized の場合

  • ログインが回避できていないので、1の手順が正しく完了しているか確認する

Typeが unconnected の場合

  • AWSのセキュリティグループを確認し、80番と443番のポートを開ける
  • 勢い余って /etc/gitlab/gitlab.rbexternal_url をhttpsにしていないか確認する(証明書取得まで禁止!)

5. SSL証明書が自動更新されるよう設定

$ sudo crontab -u root -e
00 05 01 * * /path/to/letsencrypt/letsencrypt-auto renew --force-renew && gitlab-ctl restart

5. SSL証明書をGitLabに適用

external_url をHTTPSに変更する。
[gitlab.example.com] の部分はGitLabに適用しているドメインを指定する。

redirect_http_to_https をtrueにしておくと、HTTPでアクセスされてもHTTPSにリダイレクトされる。
証明書の再発行の際はHTTPによる .well-known の確認が走らないので、HTTP接続を潰してしまってよい。
同じくAWSのセキュリティグループレベルでも80番ポートを潰してしまってよい。

$ sudo vim /etc/gitlab/gitlab.rb
/etc/gitlab/gitlab.rb
nginx['external_url']                = "https://[gitlab.example.com]"
nginx['redirect_http_to_https']      = true
nginx['ssl_certificate']             = "/etc/letsencrypt/live/[gitlab.example.com]/fullchain.pem"
nginx['ssl_certificate_key']         = "/etc/letsencrypt/live/[gitlab.example.com]/privkey.pem"

6. GitLabを再起動

$ sudo gitlab-ctl reconfigure

参考文献

GitLab Omnibus package の SSL 証明書を Let’s Encrypt で取得する
http://qiita.com/yuuAn/items/09a434d3f6cffa31101e

アクセス制限のかかったGitLabをLet’s Encryptをつかってhttps化する
https://gist.github.com/mamemomonga/a36a194f8a80ce5fa49bf950e092c604

続きを読む

AWSのEC2でUbuntu+nginx+Unicornの環境構築物語

なれそめ

  • サーバ構築、フレームワークの導入に慣れよう
  • ウェブサービスを自分一人で作れるようになるための練習

概要

  • 自分が慣れるため、今後のメモのためという意味合いが強いです
  • unicornとしての機能には触れません

環境

  • Ubuntu 16.04.2 LTS
  • nginx/1.10.0 (Ubuntu)
  • ruby 2.4.0p0
  • rbenv 1.1.0
  • Bundler version 1.14.6
  • unicorn 5.2.0

1.サーバ初期設定

  1. AWSでEC2インスタンス作成(Ubuntuを選択)
  2. セキュリティグループ設定:自分の利用する回線(送信元)で、指定したポートでSSH接続するために解放する(任意のポート)
  3. AWSで接続のコマンドを用意してくれるのでそれを利用してターミナルからSSHでアクセス
ssh接続の設定

セキュリティを最低限強くするため、22番での接続を禁止し、rootでのログインも禁止する

$ sudo vim /etc/ssh/sshd_config
Port 55555 // 任意のポート番号に変更
PermitRootLogin no // noに変更
$ sudo /etc/init.d/ssh restart

これで22番ポートでのログインが禁止され、以下のようにポートを指定してログインができる

sudo ssh -p 55555 -i "key.pem" ubuntu@ec2-XX-XXX-XXX-XXX.us-west-2.compute.amazonaws.com

sshの設定を変更したらrestartして反映させる

作業ユーザ設定

sudo権限も付与しておく

$ sudo useradd -m sasaki
$ sudo passwd sasaki
$ sudo usermod -G sudo sasaki
$ su - sasaki

2.bundler導入とrailsプロジェクト作成

  1. ruby用ライブラリ(gem)の管理するためにbundlerを用いる
  2. gemコマンドでbundlerをインストール
  3. Gemfileを編集してrailsのインストールの準備
$ sudo apt update
$ sudo apt-get install bundler
$ mkdir rails-app/ && cd rails-app/
$ bundle init
$ vi Gemfile
# A sample Gemfile
source 'https://rubygems.org'

gem 'rails', '>= 5.0.0.1'
gem 'sqlite3'
gem 'sass-rails', '~> 5.0'
gem 'uglifier', '>= 1.3.0'
gem 'coffee-rails', '~> 4.1.0'
gem 'therubyracer', platforms: :ruby
gem 'jquery-rails'
gem 'turbolinks'
gem 'jbuilder', '~> 2.0'
gem 'sdoc', '~> 0.4.0', group: :doc
gem 'bcrypt', '~> 3.1.7'
gem 'unicorn'

group :development, :test do
  gem 'byebug'
  gem 'web-console', '~> 2.0'
  gem 'spring'
end
$ bundle install --path vendor/bundle
$ bundle exec rails new .

ここで僕はsqlite3がないよと怒られたのでapt-getで入れました

$ sudo apt-get install libsqlite3-dev

3.rubyとrbenvの用意

$ cd ~/rails-app/
$ git clone https://github.com/sstephenson/rbenv.git .rbenv
$ git clone https://github.com/sstephenson/ruby-build.git .rbenv/plugins/ruby-build
$ sudo apt update
$ vi ~/.bashrc


```.bashrc
+ [[ -d ~/rails-app/.rbenv  ]] && 
+   export PATH=${HOME}/rails-app/.rbenv/bin:${PATH} && 
+   eval "$(rbenv init -)"
$ source ~/.bashrc

4.アプリケーション作成へ

$ cd ~/rails-app/
$ bundle exec rails generate scaffold board title:string text:string

ここでエラーが発生、よく出るエラーところらしい
エラーが出たら以下のようにコメントアウトを外すして改めてbundle installすると成功うまく行く場合が多い

$ vi Gemfile
- # gem 'therubyracer', platforms: :ruby
+ gem 'therubyracer', platforms: :ruby
$ bundle install
$ bundle exec rails generate scaffold board title:string text:string

rakeコマンドが使えるのでrakeでDBのマイグレート

$ rake db:migrate
$ vi config/routes.rb
routes.rb
...
+  root "boards#index"
end
...

以下のコマンドでサーバを起動(ctrl+C)でキャンセルできる

$ bundle exec rails server -b 0.0.0.0

他にもタブを開いて確認して見ると確認ができる

$ ps aux | grep 0.0.0.0:3000
sasaki  24821  1.0  7.2 751628 73444 pts/1    Sl+  04:27   0:01 puma 3.8.2 (tcp://0.0.0.0:3000) [rails-app]

5.unicorn設定

unicorn.rbについては
ここのを参考にした

$ cd ~/rails-app/config/ && vi unicorn.rb
unicorn.rb
# -*- coding: utf-8 -*-
worker_processes Integer(ENV["WEB_CONCURRENCY"] || 3)
timeout 15
preload_app true  # 更新時ダウンタイム無し

listen File.expand_path('/tmp/sockets/unicorn.pid', __FILE__)
pid File.expand_path('/tmp/pids/unicorn.pid', __FILE__)
listen "/tmp/sockets/unicorn.sock"
pid "/tmp/pids/unicorn.pid"

before_fork do |server, worker|
  Signal.trap 'TERM' do
    puts 'Unicorn master intercepting TERM and sending myself QUIT instead'
    Process.kill 'QUIT', Process.pid
  end

  defined?(ActiveRecord::Base) and
    ActiveRecord::Base.connection.disconnect!
end

after_fork do |server, worker|
  Signal.trap 'TERM' do
    puts 'Unicorn worker intercepting TERM and doing nothing. Wait for master to send QUIT'
  end

  defined?(ActiveRecord::Base) and
    ActiveRecord::Base.establish_connection
end

# ログの出力
stderr_path File.expand_path('log/unicorn.log', ENV['RAILS_ROOT'])
stdout_path File.expand_path('log/unicorn.log', ENV['RAILS_ROOT'])

rakeコマンドでユニコーンの起動や停止を行うために以下の編集を行う
こちらも先ほどのQiitaを参考にしました

$ bundle exec rails generate task unicorn
$ cd ~/rails-app/ && vi lib/tasks/unicorn.rake
unicorn.rake
namespace :unicorn do
  ##
  # Tasks
  ##
  desc "Start unicorn for development env."
  task(:start) {
    config = Rails.root.join('config', 'unicorn.rb')
    sh "bundle exec unicorn_rails -c #{config} -E development -D"
  }

  desc "Stop unicorn"
  task(:stop) { unicorn_signal :QUIT }

  desc "Restart unicorn with USR2"
  task(:restart) { unicorn_signal :USR2 }

  desc "Increment number of worker processes"
  task(:increment) { unicorn_signal :TTIN }

  desc "Decrement number of worker processes"
  task(:decrement) { unicorn_signal :TTOU }

  desc "Unicorn pstree (depends on pstree command)"
  task(:pstree) do
    sh "pstree '#{unicorn_pid}'"
  end

  def unicorn_signal signal
    Process.kill signal, unicorn_pid
  end

  def unicorn_pid
    begin
      File.read("/tmp/pids/unicorn.pid").to_i
    rescue Errno::ENOENT
      raise "Unicorn doesn't seem to be running"
    end
  end
end

これで以下のようなコマンドが使える

rake unicorn:start
rake unicorn:stop

6.nginx導入とブラウザで確認

$ sudo apt-get install -y nginx
$ /etc/init.d/nginx start
$ /etc/init.d/nginx status

これでnginxが Active: active (running) であることを確認できるはず

nginxとのやりとりにはソケットを使う
conf.dにconfファイルを置けばそれが読まれる設定になっている

$ cd /etc/nginx/conf.d/
$ sudo vi local.conf
local.conf
upstream unicorn {
  server unix:/tmp/sockets/unicorn.sok;
}

server {
  listen 80 default_server;
  server_name localhost-rails;

  access_log /var/log/nginx/sample_access.log;
  error_log /var/log/nginx/sample_error.log;

  root /home/sasaki/rails-app/app/views/boards;

  client_max_body_size 100m;
  error_page 404 /404.html;
  error_page 500 502 503 504 /500.html;
  try_files $uri/index.html $uri @unicorn;

  location @unicorn {
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Host $http_host;
    proxy_pass http://unicorn;
  }
}
$ sudo vi ../nginx.conf
nginx.conf
- include /etc/nginx/sites-enabled/*;
+ # include /etc/nginx/sites-enabled/*; 

以下のようにそれぞれのファイルで同じ場所のsockファイルを見るように設定されていることが必要
違ってたら揃える

/etc/nginx/conf.d/local.conf
server unix:/tmp/sockets/unicorn.sock;
unicorn.rb
listen "/tmp/sockets/unicorn.sock"
pid "/tmp/pids/unicorn.pid"

sockファイルの置き場は工夫の余地があるかと
AWSを用いているのでブラウザから見れるようにセキュリティグループに追加し
nginx再起動させてhttp://でアクセス

$ /etc/init.d/nginx restart

うまくいかないとき

nginxのログ(上記の設定だと)

$ sudo tail -f /var/log/nginx/sample_access.log
$ sudo tail -f /var/log/nginx/sample_error.log

続きを読む

【手順と注意点】 AWSインスタンスサイズを下げ2台構成にし、稼働率とコスパを上げた

サービスリリース時に立てた巨大なサイズのインスタンスの見直しをする

現状立っているインスタンス

項目 m4.xlarge
メモリ 16G
CPU 400%(4基)
network 高い(と書いてある)

変更したいインスタンス(2台構成)

項目 t2.midium
メモリ 4G
CPU 200%(2基)
network 低〜中(と書いてある)

現状のサーバーリソース状態の確認項目

Mackerelを用いてリソース使用状況の計測

mackerelのインストール方法はこちら

項目 鯖リソース 使用率
CPU 400% 14%
メモリ 16G 1G
LoadAVE 4 0.4

なんだこれ全然使ってねえ!!

※Load Averageとは1CPUにおける単位時間あたりの実行待ちとディスクI/O待ちのプロセスの数を示します

  • CPU4基構成なので最大で400%まで処理を行うことが可能ですが、現状の最高CPU使用率は14%

  • メモリはMackerel上では98%使用していることになっていたので、サーバに入りfreeコマンドを試した。
    15Gはバッッファとキャッシュなので、この時点での実際の利用率は低い。

  • cloudWatchLogsAgentを使用して、計測することでメモリも綺麗に監視できる様です。
    参考: http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/logs/AgentReference.html

  • loadaverageは1に達することがなく、全ての処理が待たされずに実行できていることがわかる。

load averageの適正値

  • 1以下:実行プロセスが待たされることなく実行されている
  • 2~3:CPU不足やディスクIO書き込み待ちにより、プロセス実行待ちが起きている
  • 3以上:1プロセスあたり2件の処理が実行できていない状態となり、体感値として重いと感じるようになる

リソース利用率目標値は80%

もっともサーバーのリソースを有効活用できる利用率が80%〜90%だと言われていますので、
無駄に大きいインスタンスのスペックを下げて、サーバの負荷を上げてコスパを上げたいと思います

現状のインスタンス 数値
インスタンスサイズ m4.xlarge
メモリ 16G
CPU 4コア
Net 750Mbps

この状態だと非常にリソースが余ってしまうので、AWSインスタンス一覧から下げても大丈夫そうなインスタンスをさがします。

サーバスペックを下げる際にチェックしたポイント

  • インスタンスタイプ
  • cpu
  • メモリ
  • ネットワーク速度

インスタンスタイプをt2以外からt2へ下げた際の注意事項

3/31日hiroki_konishiさんよりコメントをいただき追記
インスタンスタイプをt2以外からt2へ下げた際には注意が必要です。
t2タイプでは、CPUクレジットを考慮する必要があります。(40%程度なら、問題なさそうですが。念のため。)

参考:http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/t2-instances.html#t2-instances-cpu-credits

インスタンスのざっくりとした特徴

インスタンスタイプ 特徴
Tシリーズ 最小規模でテスト環境用
Mシリーズ 中規模サイト、DBの運用といった一般的なインスタンス
Cシリーズ CPU、分散処理重視型
Rシリーズ メモリ最適化
Gシリーズ グラフィック最適化(GPU強化)
Iシリーズ 並列演算処理

参考:https://aws.amazon.com/jp/ec2/instance-types/
またはインスタンスの作成ボタンを押した後のページで詳細な情報を閲覧することができます。

各インスタンスごとに特徴があるのでインスタンスタイプを変更する際はネットワーク速度、cpuの性能などが変わることも考慮したほうが良いとおもわれます。

今回で言うと m4.xlarge と同系統のタイプの m4.large に変更するのが一番安全な変更になります。

ただ現状サーバのリソース使用状況からは t2.medium まで下げても問題ないと判断しました。

項目 m4.xlarge 使用状況
メモリ 16G 1G
CPU 400%(4基) 14%(1基で十分)
network 高い

メモリを4G、CPUは4基構成から1基構成に変更しました。
ネットワーク速度がここで高い〜中に変更され若干気になりますが、そこは 実際の速度をあとで計測してみて判断したいと思います。

項目 t2.midium 使用状況
メモリ 4G 1G
CPU 200%(2基) 14%(1基で十分)
network 低〜中

インスタンスタイプを決めたら実際にスケールダウンする手順に移ります。

安全なサーバスケールダウン手順

インスタンスタイプを変更する際はサーバを停止する必要があります、そのためその時間をメンテナンス時間としてサービスを止めるか、2つのサーバを立てて一時的にもう片方のサーバに処理を行ってもらう必要があります。

今回はサービスを停止するわけにはいかないので2つのサーバを立ててスケールダウンをする手順で作業を行いました。

OSは既存のサーバと合わせ、ポートの開放をお忘れなく行いましょう。

  • インスタンスタイプを下げたAWSインスタンスを新しく1つ別途作成する
  • その新しいインスタンスに本番環境を構築し、旧インスタンスと同じ処理ができるように環境構築、デプロイを行う。
  • そのスペックのインスタンスで良いかチェックする(下記に方法記載)
  • ELB(イラスティックロードバランサー)の設定に新インスタンスを追加し、新サーバと旧サーバの両方でトラフィックを受ける状態にする
  • 旧インスタンスをELBから外してスケールダウン完了

2台構成で新規サーバを立てる際の注意点

スケールダウンして浮いたコスト分で、逆にスケールアウトする構成にすることで冗長性をもたせることができます。高いサーバ1台よりも安いサーバ2台という戦略です。ただし、複数台構成にすることで気をつけなければいけないポイントがあります。

  • 新規にサーバを立てるので既存のサーバとIPアドレスが変わります
  • IPアドレスごとに承認されている外部サービスとの連携を確認
  • 決済サービス
  • GoogleXMLSiteMap
  • FeedForce
  • 両方のサーバで決済など連携を確認しましょう。

またはNATサーバなど外部に向かうトラフィックを1本化するという手もありますね。

ApatchBenchによるサーバ負荷テスト

このコマンドを用いることで任意のアドレスに対してアクセスを大量に送ることができます。
サーバースペックを下げた際にどれだけのリクエストに答えらる数が減ったのか、速度が低下したのかを確認することができます。

合計1000クリエストを同時アクセス数100で送信
ab -n 1000 -b 100 before-server.jp
ab -n 1000 -b 100 after-server.jp
合計2000クリエストを同時アクセス数200で送信
ab -n 2000 -b 200 before-server.jp
ab -n 2000 -b 200 after-server.jp
合計3000クリエストを同時アクセス数300で送信
ab -n 3000 -b 300 before-server.jp
ab -n 3000 -b 300 after-server.jp

ApatchBenchでの性能実験、実行結果

移行した低スペックサーバでの数値

項目 t2.midium 使用状況 変更前との差分
メモリ 4G 1G なし
CPU 200%(2基) 44%(1基で十分) +30%
network 低〜中 なし
項目 m4.xlarge 使用状況 変更前との差分
メモリ 16G 1G なし
CPU 400%(4基) 14%(1基で十分) 20%(1基で十分)
network 高い なし

正直数値を見る限りまだまだ余裕でこれ以上下げることも可能。
ただこれ以上下げるとさすがに心配、なおかつコストもあまり変わらないので今回は保留。

リージョン違いのサーバを2基構成にできただけでも稼働率に対してかなり効果があるはず。

サーバー移行結果

サーバー移行前

項目 m4.xlarge 使用状況 使用率
メモリ 16G 1G 6.25%
CPU 400%(4基) 14%(1基で十分) 3.5%
network 高い 不明

サーバー移行後(2台の合計値)

項目 t2.midium 使用状況 使用率
メモリ 4G 2.2G 55%
CPU 200% 10% 5%
network 低〜中 不明

メモリCPUの使用率は上昇しましたが、CPUに関しては全体合わせて10%程度。
移行前との比較ですが4%ほど下がっていて、2台構成にして処理が分散したのかなという印象です。

image

こちらが実際のMackerelで確認したCPUの数値、最大でも5%ほどしか使用されておらず、
実質サーバーを変更しても問題がなかった様に思えます。

むしろこれでもオーバースペックすぎるのでもっと下げても大丈夫なのですが。
一応重要なサーバなので今回はこのサイズで。

個人でサービスを提供するときはもっと低くて良いと思います。

Tips

指定したURLでアクセスした際に、特定のIPに固定で行く様に設定する方法(Route53周りをいじる時に必須)

pcのhostsファイルを開き、ドメイン名とIPアドレスを紐付ける。

sudo vim /etc/hosts
13.293.41.112 www.hoge.net.jp

www.hoge.net.jpにアクセスした際にランダムで2つのIPに移動するのがELBの基本的な設定なのですが。

このように記載しておくことでwww.hoge.net.jpに接続した際に13.293.41.112このIPアドレスを強制的に見に行ってくれます。

AmazonのRoute53よりもこちらが優先されて接続されます。

続きを読む

nginxでBasic認証(ユーザを複数設定する)htpasswdの叩き方

nginxでBasic認証(ユーザを複数設定する)htpasswdの叩き方

Basic認証とは、HTTPで定義される認証方式の一つで、ユーザ名とパスワードをコロン(:)でつないで、Base64で送信して認証を行います。

今回は、AWS(Amazon Linux)でnginx v1.10.2-1.30.amzn1を利用。

複数ユーザを作ってみる

まずはコマンドが叩けるか調べてみる

$ which htpasswd
/usr/bin/htpasswd

こんな感じでコマンドが叩ける状態ならOKです。

なければ叩けるようにコマンドをインストールします。

$ sudo yum install -y httpd-tools

これでコマンドが叩けると思います。

$ sudo htpasswd -c /etc/nginx/.htpasswd ユーザ名

ここでユーザが一人追加されると思います。
下記で確認

$ cat /etc/nginx/.htpasswd
hoge:$apr1$1F44gU0L$Sm5kzGBydSQV5uoUZ8PNe0

最初に説明したとおりに、「ユーザ名:パスワード」の形式で保存されていると思います。

ここで、複数ユーザを追加する時ですが、実はさっきのコマンドをそのまま打つと再度新しくファイルが作られて追記にならないことがわかりました・・・
なので、追記するときは下記のコマンドを実行
(自分の場合、これを見落としていて、一旦他のファイルに書き出してからコピペで追加作業をしておりました)

$ sudo htpasswd /etc/nginx/.htpasswd ユーザ名

ちなみに、-cオプションは、manコマンドでみてみるとこう書いてました。

-c     Create the passwdfile. If passwdfile already exists, it is rewritten and truncated. This option cannot be combined with the -n option.

要するに-cはCreateだからすでにあったら上書きされるよって書いてます。

複数ユーザを作る場合は、-cオプションを外して実行しましょう。
そうすると、下記のようにユーザが追加されます。

hoge:$apr1$1F44gU0L$Sm5kzGBydSQV5uoUZ8PNe0
fuga:$apr1$DMNE8ana$3OxcmtTmjDeyzsc1nURil1

nginxで設定してみる

$ sudo vim /etc/nginx/conf.d/hoge.conf
server {
   auth_basic "basic auth";
   auth_basic_user_file /etc/nginx/.htpasswd;
}

server以下にこの2行を追加

$ sudo service nginx reload

これで反映されます。

複数ユーザを作れば、それぞれユーザ毎にログインが可能になります。

まとめ

htpasswdのコマンド

  • 初回のみ
$ sudo htpasswd -c /etc/nginx/.htpasswd ユーザ名
  • ユーザを追記したい場合
$ sudo htpasswd /etc/nginx/.htpasswd ユーザ名
  • nginxの設定
server {
   auth_basic "basic auth";
   auth_basic_user_file /etc/nginx/.htpasswd;
}

続きを読む

AWS-EC2にRbenvでRuby環境を構築する

サーバ上にRuby環境を構築する際にQiitaや他ブログに掲載されているいろいろな記事を参考にしながら作業をするのですが、いい加減覚えようと思い、自分用にメモを残すことにしました。この記事はその試みです。

Rbenvの導入がメインとなりますので、お手数ですがAWS-EC2の起動方法などについては他記事を御覧ください。

やりたいこと

  • Rbenvでインスタンスに複数バージョンのRubyを管理したい
  • 全ユーザがRbenvに管理されたRubyを使えるようにしたい

作業内容

EC2にログイン

EC2インスタンス上で作業するために、まずはログインします。
秘密鍵のパスとusername、IPアドレスについては各自の設定を参照してください。
ログイン後、rootユーザに切り替えます。

command
$ ssh -i [~/.ssh/keypair.pem] [usarname]@xxx.xxx.xxx.xxx
$ sudo su -

必要なパッケージのインストール

command
$ yum -y install gcc-c++ glibc-headers openssl-devel readline libyaml-devel readline-devel zlib zlib-devel libffi-devel libxml2 libxslt libxml2-devel libxslt-devel sqlite-devel

Rbenvのインストール

GithubからRbenvをcloneし、その後rbenvコマンドを呼び出せるよう、環境変数を設定してPATHを通します。

$ git clone https://github.com/sstephenson/rbenv.git /opt/rbenv
$ vim /etc/profile.d/rbenv.sh

vimで /etc/profile.d/rbenv.sh を開いたら、以下を記述します。

/etc/profile.d/rbenv.sh
export RBENV_ROOT="/opt/rbenv"
export PATH="${RBENV_ROOT}/bin:${PATH}"
eval "$(rbenv init -)"

ruby-buildをインストール

次に、ruby-buildをインストールします。

command
$ git clone https://github.com/sstephenson/ruby-build.git /opt/rbenv/plugins/ruby-build

ユーザの追加

次にユーザを追加します。
wheelグループに属しているユーザがrbenvコマンドを使用できるようにします。

新しく追加する場合

command
$ adduser newuser
$ passwd newuser

上記コマンドを実行し、新しくつくりたいユーザの名前、そのユーザのパスワードを設定します。作成したユーザにsshでアクセスできるようにするには、サーバ上ではなくローカルで公開鍵と秘密鍵のペアを作成する必要がありますが、ここでは説明を割愛します。

ユーザをwheelグループに所属させる

command
$ usermod -G wheel newuser

wheelグループに所属するユーザを確認するには、以下のコマンドを実行します。

command
$ grep wheel /etc/group

rbenvのパーミッション変更

wheelグループのユーザがrbenvコマンドを使えるように、ディレクトリの権限を変更します。

command
$ chown -R wheel:wheel /opt/rbenv
$ chmod -R 775 /opt/rbenv

以下のコマンドでディレクトリの状態を確認できます。

command
ll /opt/

パーミッションはrwxrwxr-x、グループとユーザはwheel:wheelになっていればOKです。

Rubyのインストール

いよいよRbenvを使ってRubyをインストールします。
設定した環境変数を読み込むために以下のコマンドを実行します。

command
$ source /etc/profile.d/rbenv.sh

読み込みが無事に終わったら、以下のコマンドを実行して好きなバージョンのRubyをインストールしましょう!

command
$ rbenv install -l

Rubyをインストールできたら実行すること

rbenvの同期

command
$ rbenv rehash

rbenvでインストールしたRubyをシステム全てに適用する

command
$ rbenv global 2.2.3

参考

rbenv + ruby-build はどうやって動いているのか
Amazon Linuxに、Ruby + Railsのインストールをしよう!
AWS EC2 Amazon Linuxインスタンス起動後、最初にやることまとめ
Linuxユーザーの追加〜SSH公開鍵登録まで

続きを読む

Amazon ECS デバッグ方法

ログ等のデバッグ情報 種類

ECSにおいて以下の種類のログ等を活用したデバッグ方法を説明します。

  • アプリケーションログ
  • Amazon ECS サービス ログ
  • Amazon ECS タスク ログ
  • Amazon ECS コンテナエージェントログ
  • Amazon ECS ecs-init ログ
  • タスク認証情報の監査ログ用の IAM ロール
  • ECS Logs Collectorの使用
  • エージェントのイントロスペクション診断
  • API failures エラーメッセージ

アプリケーションログ

ECS上のDockerで起動しているアプリケーションのログ出力の設定をします。

サイドメニューの[タスク定義]から新しいリビジョンのタスクを定義する際に[コンテナの定義]をします。このときに[ストレージとログ]項目中のログを以下のように設定します。

  • ログ設定

    • ログドライバー

      • awslogs
    • ログオプション
      • awslogs-group

        • sample-ecs-loggroup
      • awslogs-region
        • us-east-1
      • awslogs-stream-prefix
        • sample-ecs

以上で例えば、Node.jsを使用するときはconsole.log()などで出力される内容を
CloudWatchのサイドメニューの[ログ]から先程指定したawslogs-groupの項目にログ内容が出力されます。

Amazon ECS サービス ログ

クラスター > <対象のクラスター>で[サービス]タブ中のサービス一覧から対象のサービスを選択します。
遷移先のページの[イベント]タブ中のページで各イベントのイベント時間、メッセージなどが出力されるので参考にする。

Amazon ECS タスク ログ

クラスター > <対象のクラスター>で[タスク]タブの[必要なタスクのステータス]から[Stopped]を選択します。

すると、タスクが停止した場合などの原因などが表示される。

Amazon ECS コンテナエージェントログ、Amazon ECS ecs-init ログ、タスク認証情報の監査ログ用のIAMロール

EC2インスタンスにSSHでログインします。

$ ssh -i ~/.ssh/id_rsa ec2-user@XX.XX.XX.XX
$ sudo yum install vim
$ vim /etc/sysconfig/docker

以下のようにOPTIONSの設定に-D"--default-ulimit nofile=1024:4096"の先頭に追加することでログ出力を詳細に出力します。

Before

# The max number of open files for the daemon itself, and all
# running containers.  The default value of 1048576 mirrors the value
# used by the systemd service unit.
DAEMON_MAXFILES=1048576

# Additional startup options for the Docker daemon, for example:
# OPTIONS="--ip-forward=true --iptables=true"
# By default we limit the number of open files per container
OPTIONS="--default-ulimit nofile=1024:4096"

# How many seconds the sysvinit script waits for the pidfile to appear
# when starting the daemon.
DAEMON_PIDFILE_TIMEOUT=10

After

# The max number of open files for the daemon itself, and all
# running containers.  The default value of 1048576 mirrors the value
# used by the systemd service unit.
DAEMON_MAXFILES=1048576

# Additional startup options for the Docker daemon, for example:
# OPTIONS="--ip-forward=true --iptables=true"
# By default we limit the number of open files per container
OPTIONS="-D --default-ulimit nofile=1024:4096"

# How many seconds the sysvinit script waits for the pidfile to appear
# when starting the daemon.
DAEMON_PIDFILE_TIMEOUT=10
$ sudo service docker restart

ECSのログは/var/log/ecs/以下に吐き出される。

ログの種類

  • Amazon ECS コンテナエージェントログ
    /var/log/ecs/ecs-agent.log.timestamp.YYYY-MM-DD-HH
  • Amazon ECS ecs-init ログ
    /var/log/ecs/ecs-init.log.timestamp.YYYY-MM-DD-HH
  • タスク認証情報の監査ログ用の IAM ロール
    /var/log/ecs/audit.log.YYYY-MM-DD-HH

/var/log/ecs/ecs-agent.log.2017-03-26-17

2017-03-26T17:00:56Z [INFO] Starting Agent: Amazon ECS Agent - v1.14.1 (467c3d7)
2017-03-26T17:00:56Z [INFO] Loading configuration
2017-03-26T17:00:56Z [INFO] Checkpointing is enabled. Attempting to load state
2017-03-26T17:00:56Z [INFO] Loading state! module="statemanager"
2017-03-26T17:00:56Z [INFO] Restored cluster 'sample-cluster'
2017-03-26T17:00:56Z [INFO] Event stream ContainerChange start listening...
2017-03-26T17:00:56Z [INFO] Detected Docker versions [1.17 1.18 1.19 1.20 1.21 1.22 1.23]
2017-03-26T17:00:56Z [INFO] Restored from checkpoint file. I am running as 'arn:aws:ecs:us-east-1:xxxxxxxxxxxxxxxxxx:container-instance/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' in cluster 'sample-cluster'
2017-03-26T17:00:56Z [INFO] Registered! module="api client"
2017-03-26T17:00:56Z [INFO] Adding image name- xxxxxxxxxxxxx.dkr.ecr.us-east-1.amazonaws.com/sample-repository to Image state- sha256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
2017-03-26T17:00:56Z [INFO] Updating container reference sample-container in Image State - sha256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
2017-03-26T17:00:56Z [INFO] Saving state! module="statemanager"

/var/log/ecs/ecs-init.log.2017-03-26-17

2017-03-26T17:00:55Z [INFO] pre-start
2017-03-26T17:00:55Z [INFO] start
2017-03-26T17:00:55Z [INFO] Container name: /ecs-sample-task-1-sample-container-xxxxxxxxxxxxxxxxxxxxxxx
2017-03-26T17:00:55Z [INFO] Container name: /ecs-agent
2017-03-26T17:00:55Z [INFO] Removing existing agent container ID: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
2017-03-26T17:00:55Z [INFO] Starting Amazon EC2 Container Service Agent

(参照) エージェントの再起動方法

$ sudo stop ecs
$ sudo start ecs

ECS Logs Collectorの使用

ECS Logs Collectorを使用することで、オペレーティングシステムログやDocker、ECS コンテナエージェントログを一括して集約することができます。
https://github.com/awslabs/ecs-logs-collector

$ curl -O https://raw.githubusercontent.com/awslabs/ecs-logs-collector/master/ecs-logs-collector.sh
$ sudo bash ./ecs-logs-collector.sh

ログ情報はcollectディレクトリ以下に集められます。例えば、以下のような構成されます。

collect
└── system
    ├── docker
    │   ├── container-310f75292484.txt
    │   ├── container-537de59ea686.txt
    │   ├── docker-images.txt
    │   ├── docker-info.txt
    │   ├── docker-ps.txt
    │   └── docker-version.txt
    ├── docker_log
    │   └── docker
    ├── ecs-agent
    │   ├── agent-running-info.txt
    │   ├── ecs-agent.log.2017-03-26-17
    │   ├── ecs.config
    │   └── ecs_agent_data.txt
    ├── iptables.txt
    ├── lvs.txt
    ├── mounts.txt
    ├── netstat.txt
    ├── pkglist.txt
    ├── ps.txt
    ├── pvs.txt
    ├── selinux.txt
    ├── services.txt
    ├── top.txt
    ├── var_log
    │   ├── dmesg
    │   └── messages
    └── vgs.txt

エージェントのイントロスペクション診断

ECSエージェントのイントロスペクション APIで診断情報を取得し、Docker IDの特定などを行います。

$ curl http://localhost:51678/v1/tasks | python -mjson.tool
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  3731    0  3731    0     0   429k      0 --:--:-- --:--:-- --:--:--  455k
{
    "Tasks": [
        {
            "Arn": "arn:aws:ecs:us-east-1:xxxxxxxxxxxxx:task/xxxxxxxxxxxxxxxxxxxxxxxxxxxx",
            "Containers": [
                {
                    "DockerId": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
                    "DockerName": "ecs-sample-task-1-sample-container-xxxxxxxxxxxxxxxxxxxxx",
                    "Name": "sample-container"
                }
            ],
            "DesiredStatus": "STOPPED",
            "Family": "sample-task",
            "KnownStatus": "STOPPED",
            "Version": "1"
       }
    ]
}

先程調べたDocker IDを使用して、

ログ

$ docker logs <Docker ID> | head

コンテナ検査

$ docker inspect <Docker ID>

API failures エラーメッセージ

マネジメントコンソール、およびCLIからコマンドを叩いたときに出力されるエラー内容を参照しましょう。
各表示項目におけるエラー詳細は以下のURLを参照。
http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/troubleshooting.html#api_failures_messages

参考

http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/troubleshooting.html

続きを読む

AWSでWebServer(PHP)を立ててみたので、メモ

AWSでWebServerを立ててみたので、備忘録向けにメモ

インスタンスの作成

詳細はAWSのページを参照
https://console.aws.amazon.com/console

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

HTTPポート(80)とHTTPS(443)ポートを開けておく。

スクリーンショット 2017-03-26 16.52.31.png

インスタンスへ接続する

キーファイルを作成し、それを使ってターミナルから接続する。

ssh -i キーファイル名 ec2-user@ec2-XX-XX-XXX-XXX.compute-1.amazonaws.com(接続するIPアドレスによって変わる)

よくわからない場合は、以下を参照。
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/AccessingInstances.html?icmpid=docs_ec2_console

セットアップ

http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/install-LAMP.html

  • アップデート
sudo yum update
  • PHPのインストール
sudo yum -y install php
  • Apacheのインストールおよびプロセスの開始
    (インストールが終わったら、apacheの自動起動設定)

    sudo yum install httpd -y
    sudo service httpd start
    sudo chkconfig httpd on

    ウェブブラウザからアクセスできることを確認する
    スクリーンショット 2017-03-26 17.15.16.png

– php.iniの編集

sudo vim /etc/php.ini
php.ini

; Defines the default timezone used by the date functions
; http://www.php.net/manual/en/datetime.configuration.php#ini.date.timezone
date.timezone = 'Asia/Tokyo''
  • mysqlのインストール
sudo yum install -y mysql-server
  • mysqlの自動起動設定
sudo chkconfig mysqld on
  • mysqlの開始
sudo service mysqld start
  • MySQLのrootユーザでログイン
mysql -uroot

  • rootにパスワードを設定
mysql> set password for root@localhost=password('設定するパスワード');
Query OK, 0 rows affected (0.00 sec)
  • セキュリティ設定(終わったら再起動)
sudo /usr/bin/mysql_secure_installation
sudo service mysqld restart
  • phpAdminの設定
sudo yum --enablerepo=epel install -y phpMyAdmin
  • phpMyAdmin.confの編集
sudo vim /etc/httpd/conf.d/phpMyAdmin.conf
phpMyAdmin.conf
 <IfModule mod_authz_core.c>
     # Apache 2.4
     <RequireAny>
       #Require ip 127.0.0.1→削除
        Require all granted→追加
       Require ip ::1
     </RequireAny>
   </IfModule>
 →2.2系の時はこちら
  <IfModule !mod_authz_core.c>
     # Apache 2.2
     Order Deny,Allow
     #Deny from All
     #Allow from 127.0.0.1
     Allow from ::1
   </IfModule>
  • Apacheの再起動
sudo service httpd restart

http://(グローバルIP)/phpMyAdminにブラウザでアクセスする

続きを読む