EC2内に作業用ユーザーを追加して、新規鍵を元にSSH接続する手順

はじめに

あるプロジェクトで他社の開発者もEC2インスタンス内で作業する必要が出てきた。
その際、pemファイルを渡さない方法で他社の開発者がSSH接続できる環境を作りたく色々調べた際のメモ。

割とこういう場面ってあるんじゃないかと思う。

目次

  1. EC2内にユーザーを追加
  2. ローカルマシンで鍵の作成
  3. サーバーに公開鍵を設置と設定
  4. ローカルから鍵を元にアクセス

1. EC2内にユーザーを追加する

まずは、他社用のユーザーを追加し、設定する。

例ではhogeuserが他社のアカウントになるので、その部分を適宜変更して進めてみてください

// EC2内でルート権限になる
$ sudo -i

// ユーザー追加
$ useradd hogeuser

// パスワードを設定
$ passwd hogeuser

$ vi /etc/sudoers
vimでsudoersを開きhogeuserに関する記述を追記

## Allow root to run any commands anywhere
root    ALL=(ALL)       ALL
# 以下を追記
hogeuser ALL=(ALL) ALL

編集終わったら、escを押し、:wpを入力してエンター

2. ローカルマシンで鍵の作成

他社の開発者が以下で作成した鍵を元にアクセスをしてもらうために、新規で鍵を作成する。

以下はサーバーではなく自分のPC内で行う

// .sshフォルダがなければ作成
$ mkdir ~/.ssh

// .sshフォルダに入る
$ cd ~/.ssh

// 鍵の作成
$ ssh-keygen -t rsa -f id_rsa_hogeuser

以上で、.sshフォルダ内にid_rsa_hogeuserid_rsa_hogeuser.pubというファイルが生成される。前者が秘密鍵で、後者が公開鍵。


// scpコマンドで公開鍵をアップロード
$ scp -i 〇〇.pem ~/.ssh/id_rsa_hogeuser.pub ec2-user@EC2インスタンスのパブリックIP:/home

3. サーバーに公開鍵を設置と設定


// ec2内に入りルートユーザーになる
$ sudo -i

// ユーザーのディレクトリを作成
$ cd /home

$ mkdir hogeuser

// hogeuserディレクトリに入る
$ cd hogeuser

// .sshディレクトリを作成
$ mkdir .ssh

// 公開鍵をコピーしてリネーム
$ mv /home/id_rsa_hogeuser.pub /home/hogeuser/.ssh/authorized_keys

// ユーザーとグループを変更
$ chown -R hogeuser:hogeuser ./.

// 権限変更
$ chmod 700 .ssh

$ chmod 600 .ssh/authorized_keys

4. ローカルから鍵を元にアクセス

// 秘密鍵を元にアクセス
$ ssh hogeuser@EC2インスタンスのパブリックIP ~/.ssh/id_rsa_hogeuser

上記入力後に作成したパスワードでアクセスが可能。
rootユーザーになりたい場合も同じパスワードでなれる。

続きを読む

DatadogでJavaのメトリクスを取得する

JavaアプリケーションのパフォーマンスをDatadogで可視化しようとしたときにハマったので、
誰かの役に立てばと思い、残しておきます。

やりたかったこと

  • JVMHeap使用状況などのメトリクスを取得したかった。

公式ドキュメントは以下にあるので、ドキュメントを参考にやってみます。
JMX Checks

JavaのIntegrationを有効にする

DatadogはデフォルトではJavaのメトリクスを取得するようになっていません。
なので明示的に設定をOnにする必要があります。
サイドバーのIntegrationから、Javaを検索し設定をOnにします。
Setup___Datadog.png

availableをクリックし詳細画面からinstall integrationをクリック

Setup___Datadog.png

jmx.yamlを追加

次にdatadog-agentをinstallしたサーバ内に入り、Javaが動いているサーバの情報をdatadog-agentに教えてあげる必要があります。

datadog-agentはデフォルトで様々なintegrationのコンフィグファイル例を用意してくれており、今回はそれをコピーしてそのまま使います。

$ cp /etc/dd-agent/conf.d/jmx.yaml.example  /etc/dd-agent/conf.d/jmx.yaml
$ vim /etc/dd-agent/conf.d/jmx.yaml
/etc/dd-agent/conf.d/jmx.yaml
init_config:
instances:
-   host: localhost
    port: 7199

port: 7199など気になる設定はありますが、そのまま使用します。

datadog-agentをrestartする

設定ファイルを変更した際はagentをrestartすると変更した設定が読み込まれます。

$ sudo /etc/init.d/datadog-agent restart

だが値は取れない

dashboardを作成したときに、jmx.hogehogeが候補として出てくることを期待するが出てこない。
Listenしてないportなどを指定していたので当たり前といえば当たり前です。

結論から言うとJavaアプリケーション起動時にJMXのポートを公開しておかないと値が取れません。
JMXとは何かという方は以下を参照してください。
JMX について

起動時に以下のオプションを追加する。

# jmxをonにする
-Dcom.sun.management.jmxremote
# jmxの情報を取得できるportを指定します。jmx.yamlで指定したportはここでの設定したportになります
-Dcom.sun.management.jmxremote.port=7199
# 通信時にsslをonにするかどうか。今回はlocalhostでの通信なのでOffにします。
-Dcom.sun.management.jmxremote.ssl=false
# password認証をするか
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.local.only=true

追加すると

jvmがプレフィックスにつくメトリクスが、Datadogのコンソール上に表示されるようになりました。
biz-prd-elb__created_via_Terraform____Datadog.png

続きを読む

仮想環境で AWS Lambda の検証を行う

docker インストール

yum install -y docker

docker 起動

CentOS 6 系

service docker start

CentOS 7 系

systemctl start docker

準備

適当な作業ディレクトリを掘って移動する

mkdir /home/lambda
cd /home/lambda

event の入力を適当に用意する (Hello World をそのままコピペ)

vim input.json
input.json
{
  "key3": "value3",
  "key2": "value2",
  "key1": "value1"
}

実行スクリプトを適当に書く

vim index.js
index.js
exports.handler = ( event, context, callback ) => {
    console.log( 'event: ' + JSON.stringify( event, null, 2 ) );
    console.log( 'context: ' + JSON.stringify( context, null, 2 ) );
};

docker を起動して実行

docker run -v "$PWD":/var/task lambci/lambda index.handler $(printf '%s' $(cat input.json))

初回起動時はイメージのダウンロードとかがあるのでめっちゃ時間がかかる。

実行結果

START RequestId: bfb50b8e-04c3-1187-2d98-444e21663fea Version: $LATEST
2017-10-03T10:15:42.553Z        bfb50b8e-04c3-1187-2d98-444e21663fea    event: {
  "key3": "value3",
  "key2": "value2",
  "key1": "value1"
}
2017-10-03T10:15:42.554Z        bfb50b8e-04c3-1187-2d98-444e21663fea    context: {
  "callbackWaitsForEmptyEventLoop": true,
  "logGroupName": "/aws/lambda/test",
  "logStreamName": "2017/10/03/[$LATEST]af9c9a780a74aac9a5eff6b5e1bb8d80",
  "functionName": "test",
  "memoryLimitInMB": "1536",
  "functionVersion": "$LATEST",
  "invokeid": "bfb50b8e-04c3-1187-2d98-444e21663fea",
  "awsRequestId": "bfb50b8e-04c3-1187-2d98-444e21663fea",
  "invokedFunctionArn": "arn:aws:lambda:us-east-1:1586600703:function:test"
}
END RequestId: bfb50b8e-04c3-1187-2d98-444e21663fea
REPORT RequestId: bfb50b8e-04c3-1187-2d98-444e21663fea  Duration: 4.98 ms       Billed Duration: 100 ms Memory Size: 1536 MB    Max Memory Used: 19 MB  

null

Lambda でも実行して見る

START RequestId: xxxxxxxxxx-a824-11e7-9d62-xxxxxxxxxx Version: $LATEST
2017-10-03T10:18:41.539Z    xxxxxxxxxx-a824-11e7-9d62-xxxxxxxxxx    event: {
  "key3": "value3",
  "key2": "value2",
  "key1": "value1"
}
2017-10-03T10:18:41.544Z    xxxxxxxxxx-a824-11e7-9d62-xxxxxxxxxx    context: {
  "callbackWaitsForEmptyEventLoop": true,
  "logGroupName": "/aws/lambda/testOnLambda",
  "logStreamName": "2017/10/03/[$LATEST]xxxxxxxxxxxxxxxxxxxxxx",
  "functionName": "testOnLambda",
  "memoryLimitInMB": "128",
  "functionVersion": "$LATEST",
  "invokeid": "xxxxxxxxxx-a824-11e7-9d62-xxxxxxxxxx",
  "awsRequestId": "xxxxxxxxxx-a824-11e7-9d62-xxxxxxxxxx",
  "invokedFunctionArn": "arn:aws:lambda:ap-northeast-1: xxxxxxxxxx:function:testOnLambda"
}
END RequestId: xxxxxxxxxx-a824-11e7-9d62-xxxxxxxxxx
REPORT RequestId: xxxxxxxxxx-a824-11e7-9d62-xxxxxxxxxx  Duration: 27.69 ms  Billed Duration: 100 ms     Memory Size: 128 MB Max Memory Used: 19 MB

適当にマスクかけたけど、ほぼ同じ結果だと思う。

続きを読む

AWSでインスタンス起動直後にシェルスクリプトを実行

シェルスクリプトを用意

実行したいシェルスクリプト/path/to/target_shell_script.sh

#!/bin/bash
# chkconfig: 2345 98 20
# description: service_name
# processname: service_name

date >> /home/rev84/date.log

んで service に登録

#コピーする場合
sudo cp /path/to/target_shell_script.sh /etc/init.d/service_name
# 直接書く場合
#sudo vim /etc/init.d/service_name

sudo chmod 0755 /etc/init.d/service_name
sudo chkconfig --add service_name
sudo chkconfig service_name on

停止し、起動すると実行される。

続きを読む

[AWS] ドキュメントルートを変更する

概要

AWSのEC2でドキュメントルートを変更する方法です。

変更ファイル

EC2では下記のファイルに指定が入っています。

/etc/httpd/conf/httpd.conf

変更方法

EC2にログインした状態で下記のコマンドを実行します。

$ sudo vi /etc/httpd/conf/httpd.conf

vimモードに変更し、ファイルを290行目付近の記述を下記のように変更します。

変更前

DocumentRoot "/var/www/html"

変更後

DocumentRoot "/var/www/html/app/webroot"

変なファイルが生成された時は

下記のコマンドで削除します。

$ sudo rm /etc/httpd/confd/httpd.conf.swp

最後

Apacheを再起動すれば反映されます。

おそらく役立つ情報

痒いところに手が届くかもしれない記事を書いています。
フォローしてくれるとやる気になります!

続きを読む

EC2 へ fish-shell インストール

» 良くわからないけどできた感じなので、他にもっといい方法有ると思う。

LinuxBrew インストール

homebrewのlinux版みたいなものらしい。これを叩く。

ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Linuxbrew/install/master/install)"
ログ
==> Installation successful!
# ...
Warning: /home/linuxbrew/.linuxbrew/bin is not in your PATH.

(パス通すか)これでコマンドが使えます。

/home/linuxbrew/.linuxbrew/bin/brew 

Fish インストール

homebrewと一緒ですね。

/home/linuxbrew/.linuxbrew/bin/brew install fish
ログ
==> Caveats
You will need to add:
  /home/linuxbrew/.linuxbrew/bin/fish
to /etc/shells.

Then run:
  chsh -s /home/linuxbrew/.linuxbrew/bin/fish
to make fish your default shell.

==> Summary
🍺  /home/linuxbrew/.linuxbrew/Cellar/fish/2.6.0: 896 files, 48.3MB

/etc/shells へ追記

sudo vim /etc/shells

で、/home/linuxbrew/.linuxbrew/bin/fishを一番最後の行に追加します。

こんな感じになる

/etc/shells
/bin/sh
/bin/bash
/sbin/nologin
/bin/dash
/home/linuxbrew/.linuxbrew/bin/fish

デフォルトシェル変更

ユーザー名は好きな名前で、chshします。

sudo chsh -s /home/linuxbrew/.linuxbrew/bin/fish ec2-user

確認

一旦sshを入り直して、$SHELLがちゃんと変ったらOK。

ec2-user@ip-x-x-x-x ~> echo $SHELL
/home/linuxbrew/.linuxbrew/bin/fish

ただやっぱり、linuxbrewでインストールしたコマンドを使いやすくするためにconfig.fishではパスを追加した方がいいかも。

vim ~/.config/fish/config.fish
~/.config/fish/config.fish
set -gx PATH /home/linuxbrew/.linuxbrew/bin $PATH

続きを読む

AWSにEC2を作成した際に行う設定メモ

EC2インスタンスを作成した後、いつも調べたりするので忘れないようにメモ

ユーザの追加

インスタンス作成時はec2-userのみ作成されているため、別途ユーザを作成する

$ sudo adduser new_user
$ sudo passwd new_user
# パスワードを入力
# パスワードを再入力(確認)
$ sudo visudo

sudo の権限を追加

## Same thing without a password
# %wheel        ALL=(ALL)       NOPASSWD: ALL
new_user        ALL=(ALL)       NOPASSWD: ALL

sshでログイン出来るようにする

$ su - new_user
# パスワードを入力
$ mkdir .ssh
$ chmod 700 .ssh
$ cd .ssh
$ touch authorized_key
$ chmod 600 authorized_key
$ vim authorized_key
# パブリックキーを追記して保存
$ exit
$ exit

ssh new_user@xxx.xxx.xxx.xxxでログイン出来るか確認

タイムゾーンの設定

日本時間に設定する。

$ date
Wed Sep 13 02:43:10 UTC 2017                                 # UTCになっている
$ strings /etc/localtime
TZif2
TZif2
UTC0
$ sudo cp -p /etc/localtime /etc/localtime.org               # バックアップ
$ sudo ln -sf /usr/share/zoneinfo/Asia/Tokyo /etc/localtime  # シンボリックリンクをはる
$ data
Wed Sep 13 11:44:45 JST 2017                                 # JSTになった
$ sudo cp -p /etc/sysconfig/clock /etc/sysconfig/clock.org   # バックアップ
$ sudo vi /etc/sysconfig/clock                               # 再起動した場合UTCに戻らないようにする

ZONEUTCを編集して保存

ZONE="Asia/Tokyo"
UTC=false

パッケージのインストール

java8の例

$ java -version                                                       # javaのバージョン確認
java version "1.7.0_151"
OpenJDK Runtime Environment (amzn-2.6.11.0.74.amzn1-x86_64 u151-b00)
OpenJDK 64-Bit Server VM (build 24.151-b00, mixed mode)
$ sudo yum list available | grep java-1.8                             # 利用可能なパッケージを確認
$ sudo yum install java-1.8.0-openjdk.x86_64
$ sudo alternatives --config java
$ java -version
openjdk version "1.8.0_141"
OpenJDK Runtime Environment (build 1.8.0_141-b16)
OpenJDK 64-Bit Server VM (build 25.141-b16, mixed mode)

続きを読む

AutoScaling環境においてGitを使わないでEC2を冗長化する方法

制約

Git禁止(協力会社がFTPしか使えないため)

結論

  1. Master Serverを建てる
  2. Master Serverのファイルの更新をlsyncdで監視し、常にS3と同期する
  3. 任意のタイミングでSlave Server(ELB配下の全EC2インスタンス)をS3と同期する

イメージ図

だいたいこんな感じ

AutoScaling環境においてGitを使わないでEC2を冗長化する方法

Master Server編

1. S3バケットを作成する

公式サイトに詳しい方法が書いてあります。
S3 バケットを作成する方法 – Amazon Simple Storage Service

2. AWS CLIを設定する

公式サイトに詳しい方法が書いてあります。
AWS CLI の設定 – AWS Command Line Interface

3. lsyncdをインストールする

EPELリポジトリを利用してインストールします。

$ sudo yum install --enablerepo=epel lsyncd

4. lsyncdの設定を変更する

普通の書き方だとファイル名の末尾に/(スラッシュ)が混入してエラーが出たりうまくsyncしてくれなかったので、
下記のような感じでパースしてあげる必要があります。
komeda-shinjiさんの記事がとても参考になりました。ありがとうございます。

$ sudo vim /etc/lsyncd.conf
/etc/lsyncd.conf

source_dir = "/var/www/source"
s3bucket = "files.hoge.com"
prefix = "source"

snscmd = "echo !!! error "

settings {
    logfile    = "/var/log/lsyncd.log",
    statusFile = "/var/log/lsyncd.status",
    nodaemon = false,
    statusInterval = 1,
    delay = 5,
}

cp = function(event)
  local src_path = event.sourcePathname
  local dst_path = event.targetPathname

  if (string.sub(event.source, -1, -1) == "/") then
      src_path = string.sub(event.source, 1, -2) .. event.pathname
  end
  if (string.sub(event.target, -1, -1) == "/") then
      dst_path = string.sub(event.target, 1, -2) .. event.pathname
  end
  local s3cmd = "aws s3 cp '" .. src_path .. "' '" .. dst_path .. "'"
  local msg_body = "command failed: " .. s3cmd
  local msg = " --message '" ..  string.gsub(msg_body, "'", "\"") .. "'"


  local runcmd = "rc=0 && [ -f '" .. src_path .. "' ] && for try in 1 2 3; do " .. s3cmd .. "; rc=$?; [ $rc -eq 0 ] && break; done || " .. snscmd .. msg .. " || :"
  spawnShell(event, runcmd)
end

rm = function(event)
  local src_path = event.sourcePathname
  local dst_path = event.targetPathname

  if (string.sub(event.source, -1, -1) == "/") then
      src_path = string.sub(event.source, 1, -2) .. event.pathname
  end
  if (string.sub(event.target, -1, -1) == "/") then
      dst_path = string.sub(event.target, 1, -2) .. event.pathname
  end

  local s3cmd = "aws s3 rm '" .. dst_path .. "'"
  local msg_body = "command failed: " .. s3cmd
  local msg = " --message '" ..  string.gsub(msg_body, "'", "\"") .. "'"
  local runcmd = "rc=0 && [ ! -f '" .. src_path .. "' ] && for try in 1 2 3; do " .. s3cmd .. "; rc=$?; [ $rc -eq 0 ] && break; done || " .. snscmd .. msg .. " || :"
  spawnShell(event, runcmd)
end

mv = function(event)
  local src_path = event.o.targetPathname
  local dst_path = event.d.targetPathname

  if (string.sub(event.o.target, -1, -1) == "/") then
      src_path = string.sub(event.o.target, 1, -2) .. event.o.pathname
  end
  if (string.sub(event.d.target, -1, -1) == "/") then
      dst_path = string.sub(event.d.target, 1, -2) .. event.d.pathname
  end
  local s3cmd = "aws s3 mv '" .. src_path .. "' '" .. dst_path .. "'"
  local msg_body = "command failed: " .. s3cmd
  local msg = " --message '" ..  string.gsub(msg_body, "'", "\"") .. "'"

  local runcmd = "rc=0 && [ -f '" .. src_path .. "' ] && for try in 1 2 3; do " .. s3cmd .. "; rc=$?; [ $rc -eq 0 ] && break; done || " .. snscmd .. msg .." || :"
  spawnShell(event, runcmd)
end

s3sync = {
    maxProcesses = 1,
    onCreate = cp,
    onModify = cp,
    onDelete = rm,
--  onMove = mv,
}

sync {
    s3sync,
    source = source_dir,
    target = "s3://" .. s3bucket .. "/" .. prefix,
}

5. lsyncdを起動する

$ sudo /etc/rc.d/init.d/lsyncd start
$ sudo chkconfig lsyncd on
$ /etc/rc.d/init.d/lsyncd status
lsyncd (pid  12345) is running...

6. Sourceを変更する

$ vim /var/www/source/hoge.txt
/var/www/source/hoge.txt
hogehoge

7. Sourceの変更がS3に反映しているか確認する

$ tailf /var/log/lsyncd.log

Slave Server編

1. AWS CLIを設定する

公式サイトに詳しい方法が書いてあります。
AWS CLI の設定 – AWS Command Line Interface

2. S3のSourceをローカルに同期するシェルスクリプトを作成する

$ vim /usr/local/bin/s3sync.sh
/usr/local/bin/s3sync.sh
#!/bin/sh
SOURCE_DIR="/var/www"
S3_BUCKET="files.hoge.com"
PREFIX="source"

TARGET_MASTER="s3://${S3_BUCKET}/${PREFIX}/"
TARGET_LOCAL="${SOURCE_DIR}/${PREFIX}/"

aws s3 sync ${TARGET_MASTER} ${TARGET_LOCAL} --delete

3. 同期スクリプトをEC2インスタンス起動時に実行するように設定する

$ vim /etc/rc.local
/etc/rc.local
s3sync.sh
exit 0

※ちなみに、rc.localに書かれたスクリプトはroot権限で実行されます。

4. 任意のタイミングで同期スクリプトを実行する

 cronするなり、execするなり

ボツ案

Master Server+rsyncパターン

s3Syncパターン

s3fsパターン

NFSパターン

AMIを最新にしてから起動するパターン

続きを読む

EC2が止まったらS3に「死にました」と投稿する

概要

EC2インスタンスのシャットダウンをトリガーに、何か処理を実行する方法を記します。
今回はS3に辞世の句を投稿していますが、AutoScalingでterminateされるEC2のlocalのsyslogをS3に転送する等の処理にも応用できます。

やり方

S3編

S3にバケットを作成する

death_poem_1_1.png
  ※S3のバケット名はFQDNにしておくと色々捗る(余談) 

IAM編

S3にフルアクセスできるIAMを作成する

death_poem_2_1.png

death_poem_2_2.png

death_poem_2_3.png

death_poem_2_4.png

death_poem_2_5.png

 ※アクセスキーIDとシークレットアクセスキーは後で使うのでメモ帳にコピペしてください 

EC2編

1.AWS CLIをインストールする

 ※Amazon Linuxの場合は不要です  

//pipのインストール
# curl -O https://bootstrap.pypa.io/get-pip.py

//Python を使用してスクリプトを実行
# python get-pip.py --user

//PATH 変数に実行可能パスを追加
# export PATH=~/.local/bin:$PATH
# source ~/.bash_profile

//pipが正しくインストールされたことを確認
# pip --version

//pip を使用して AWS CLI をインストール
# pip install awscli --upgrade --user

//AWS CLI が正しくインストールされたことを確認
# aws --version

2.AWS CLIの初期設定をする

# aws configure

AWS Access Key ID [None]: [アクセスキーID]
AWS Secret Access Key [None]: [シークレットアクセスキー]
Default region name [None]: [空でok]
Default output format [None]:[空でok]

3.辞世の句スクリプトを作成する

# vim /etc/rc.d/init.d/DeathPoem.sh
/etc/rc.d/init.d/DeathPoem.sh

#!/bin/sh

InstanceId=`wget -q -O - http://169.254.169.254/latest/meta-data/instance-id`

declare logdir=/var/www/log
declare log=/death_poem.log
declare bucket=files.hoge.com
declare now=`date +'%Y-%m-%d'`
declare s3_target="s3://${bucket}/death_poem_${now}/"

mkdir $logdir >/dev/null 2>&1

printf 'I am '$InstanceId'¥n' >> $logdir$log
printf 'I was born 'date --date=@$(expr `date +%s` - `cut -d "." -f 1 /proc/uptime`) >> $logdir$log
printf 'I was just 'cat /proc/uptime | awk '{print $1 / 60 /60 /24 "days (" $1 "sec)"}' |  tr -d '¥n''  from birth ''¥n' >> $logdir$log
printf 'I will die 'date'¥n¥n' >> $logdir$log

aws s3 sync $logdir $s3_target

4.辞世の句スクリプトに実行権限を与える

# chmod 755 /etc/rc.d/init.d/DeathPoem.sh

5.rc.local(起動時実行)を編集する

# vim /etc/rc.d/rc.local
/etc/rc.d/rc.local

#!/bin/sh
#
# This script will be executed *after* all the other init scripts.
# You can put your own initialization stuff in here if you don't
# want to do the full Sys V style init stuff.

touch /var/lock/subsys/local

/sbin/ethtool -s eth0 wol g

touch /var/lock/subsys/DeathPoem
ln -s /etc/init.d/DeathPoem.sh /etc/rc0.d/K00DeathPoem
ln -s /etc/init.d/DeathPoem.sh /etc/rc6.d/K00DeathPoem

6.EC2インスタンスを再起動する

# reboot

7.ログを確認する

# tailf /var/www/log/death_poem.log
/var/www/log/death_poem.log

I am i-************
I was born Mon Sep 11 04:00:48 UTC 2017
I was just 0.00817488days (706.31sec)  from birth 
I will die Mon Sep 11 04:12:34 UTC 2017

8.S3のバケットを確認する

上記と同じ内容の辞世の句が投稿されているはず!

余談

昔は簡単だった(らしい)

EC2で起動時やterminate時にシェルを実行する | Developers.IO

mytest.sh
#!/bin/sh
# chkconfig: 2345 99 10
# description: test shell

case "$1" in
 start)
       echo "start!" > /path/your/start.txt
       ;;
 stop)
       echo "stop!" > /path/your/stop.txt
       ;;
  *) break ;;
esac

あのクラスメソッドさんが書いた記事なら間違いない!
…と思っていたのですが、上記の方法では”start”のイベントしか取得できませんでした。
コメントにあったprocessnameを追加しても結果は同様でした。
原因をご存じの方いたらぜひ教えて欲しいです :bow:

とても参考になった文献

CentOS6.0 Shutdown時にコマンド実行 : 事象の水平線 :

リスペクト

心臓が止まったらSNSに「死にました」と投稿する

続きを読む

AWS(EC2+RDS)でWordPressサイトを構築する際にやることリスト

以下の構成でWordpress環境を構築する際にやることを箇条書きでまとめました。(元ブログはこちら

<構成>
Webサーバ:EC2(nginx+php7)
DBサーバ:RDS(MySQL)

各作業の細かい手順は以下を参考にしてください。

1.EC2インスタンス作成・設定

  • インスタンス作成
  • セキュリティグループ設定(インバウンド)
    • HTTP(0.0.0.0/0)
    • HTTPS(0.0.0.0/0)
    • SSH(特定のIPのみ)
  • Elastic IP設定
  • SSHログイン確認(KEY作成&ローカル配置)

2.各種ソフトウェアインストール・設定

インストール

  • sudo yum update
  • sudo yum install -y nginx
  • sudo yum install -y mysql
  • sudo yum install -y php70
  • sudo yum install -y php70-mysqlnd php70-mbstring php70-mcrypt php70-pdo php70-xml php70-fpm

自動起動設定

  • sudo chkconfig nginx on
  • sudo chkconfig php-fpm on

設定変更&再起動

php-fpm
 user = nginx
 group = nginx
 listen.owner = nginx
 listen.group = nginx
 listen.mode = 0660
 listen = /var/run/php-fpm.sock
  • sudo /etc/init.d/php-fpm restart
nginx
  • sudo vim /etc/nginx/conf.d/default.conf(新規作成)
server {
  listen 80;
  server_name hostname;
  root /var/www/html;
  index index.php index.html index.htm;

  location / {
    try_files $uri $uri/ /index.php?$query_string;
  }

  location ~ \.php$ {
    fastcgi_split_path_info ^(.+\.php)(/.+)$;
    fastcgi_pass unix:/var/run/php-fpm.sock;
    fastcgi_index index.php;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_param PATH_INFO $fastcgi_path_info;
    include fastcgi_params;
  }
}
  • sudo /etc/init.d/nginx restart

3.RDSインスタンス作成・設定

  • DBのパラメータグループの作成(日本語対応)

    • character_set_client → utf8
    • character_set_connection → utf8
    • character_set_database → utf8
    • character_set_server → utf8
    • character_set_system → utf8
  • インスタンス作成
    • MySQL
    • パラメータグループ指定
  • セキュリティグループ設定(インバウンド)
    • MySQL/Aurora(EC2のセキュリティグループを指定)

4.Wordpressインストール・設定

続きを読む