AWS環境構築でやったこと

自分用のメモですが、よければ参考にしてください。

AWS

 言わずもがな、Amazon Web Services のことです

準備

EC2コンテナ作成

参考:http://qiita.com/tmknom/items/303db2d1d928db720888

ほとんどこの通り!ありがとうございます!

SSHアクセス

  • 固定IPの設定

    • Network & Security -> Elastic IPs
    • Allocate New address
    • Actions -> Associate address
    • Instanceと紐付ければOK
  • SSHアクセス

    • pem取得

      • Network & Security -> Key Pairs
      • Create Key Pair
      • 証明書ダウンロード
    • SSHアクセス
    ssh -i xxx.pem ec2-user@ec2-XX-YY-WW-ZZ.us-west-2.compute.amazonaws.com
    

アクセスできたらもうあなたはAWSマスター

構築後

  • セキュリティアップデート
    yum -y update

* 自動更新設定
http://qiita.com/yangci/items/2ccac2b598900eb5928d
  • ツールのインストール
    yum -y install oh-my-zsh
    yum -y install emacs

    #etc...

続きを読む

AWS-EC2のp2インスタンスでchainer-goghの画風変換をGPU実行してみた

はじめに

DeepLearningの実践入門としてAWS-EC2のp2インスタンスを使用して、chainer-goghの画風変換をGPUで実行してみました。
結論としてp2.xlargeを使用してサンプル通りの画風変換を実行すると、5分程度で処理が完了します。
参考にさせていただいたchainer-goghのGitHub

環境

クライアントPC : macOS Sierra 10.12.4
サーバ : EC2 p2.xlarge (時間課金なので注意してください。)

事前準備

GPUコンピューティングのインスタンスを立ち上げる場合、デフォルトでは作成できないためAWSの担当者に問い合わせを行い、領域を拡張してもらってください。
領域の拡張はEC2ダッシュボードを開いて、左側のメニューにある「制限」から p2.xlarge の規制緩和の依頼ができます。

p2インスタンスの作成

今回はディープラーニングで使用する諸々のツールがインストール済みのAMIを使用します。
※私は”バージニア北部”リージョンを使用しています。
EC2ダッシュボードから「インスタンスの作成」 → 「AWS Marketplace」の順にクリック。
検索窓に「Deep Learning AMI」を入力して検索し、「Deep Learning AMI Amazon Linux Version」のAMIを使用してください。
その後のインスタンスの作成作業は通常のEC2と同じですので、ここでは割愛させていただきます。

環境構築

立ち上げたp2インスタンスにsshで接続して環境構築を実施します。

Pythonのインストール

「Deep Learning AMI Amazon Linux Version」を使用すると最初からPythonの2系と3系がインストールされているので、インストール作業は不要です。
※今回はPython3系を使用します。

Gitのインストール

こちらも最初から入っているので不要です。

Chainerのインストール

下記のコマンドでインストールできます。

sudo pip3 install chainer

Chainer-goghのクローン

必要であれば予めGitHub上で自分のリポジトリにChainer-goghをforkしておいてください。
chainer-goghをサーバにcloneします。

git clone https://github.com/xxxxxxxxx/chainer-gogh.git

モデルのダウンロード

NINモデルをダウンロードしてください。(下記リンク先のDropBoxのURLからダウンロードできます。)
https://gist.github.com/mavenlin/d802a5849de39225bcc6

ダウンロードしたファイルをクライアントマシンからサーバに送信してください。

scp -i xxxxxxx.pem xxxxxxxx/nin_imagenet.caffemodel ec2-user@host:~/chainer-gogh

出力用ディレクトリを作成

cd chainer-gogh; mkdir output

画風変換の実行

コマンドで実行

実行には5分程度かかります。

python3 chainer-gogh.py -m nin -i sample_images/cat.png -s sample_images/style_1.png -o output -g 0

実行結果をダウンロード

ローカルのターミナルでコマンドを実行。
このコマンドではim_04950.pngをDownloadディレクトリ配下にダウンロードします。
このファイルが画風変換した最終結果になります。
100イテレーションずつ途中結果も出力されますので、outputディレクトリを確認してください。

scp -i xxxxxxx.pem ec2-user@xxxxxxxxxx:~/chainer-gogh/output/im_04950.png ~/Download/im_04950.png

後処理

EC2は時間課金になります。
確認が終わったらインスタンスを削除するか停止してください。

まとめ

今回はchainer-goghを使用した画風変換の環境をp2インスタンスで作成し、GPU実行できるところまで確認しました。
AWSを使用することで手元にGPUマシンを用意しなくても手軽に使用できるので大変便利です!

続きを読む

Vagrant+Amazon Linux

最新のAmazonLinuxのboxを持ってくる(Virtualbox Only)

vagrant init mvbcoding/awslinux
vagrant up --provider virtualbox

指定のバージョンをboxに追加してそれを使う

vagrant box add amzn-linux-2017.03 https://atlas.hashicorp.com/mvbcoding/boxes/awslinux/versions/2017.03.0.20170401/providers/virtualbox.box

AWS EC2 に AmazonLinux を起動してプロキシを起動

上記のみだと、AmazonLinux向けのRPMレポジトリが参照できないので、yumをプロキシするためにAWS上にAmazonLinuxのEC2を適当に起動して、tinyproxy を起動します
※ tinyproxyのデフォルトポートは 8888 です、 アクセス元のIPとかセキュリティグループで制限しておいた方がいいです

tinyproxy を EC2(AmazonLinux) へインストール

sudo yum -y install epel-release.noarch
sudo yum -y install --enablerepo=epel tinyproxy
sudo service tinyproxy start

Vagrant上のyum.confへプロキシ設定追加

echo 'proxy=http://<AWS EC2 IP ADDR>:8088' >> /etc/yum.conf

参考

続きを読む

Amazon Linux上でDelphiを使う

Delphi 10.2 TokyoはLinuxを利用する事ができます。
サポートされているのはUbuntuとRedhatですが Amazon Linuxで試してみました。

Amazon Linux側の環境構築

Development Toolsと RAD Studioに付属されているPAServer(LinuxPAServer19.0.tar.gz)があれば基本的に動きます

install.sh
#LinuxPAServer19.0.tar.gzをsftpなどでAmazon Linuxインスタンスにコピーし解凍します
tar -zxvf LinuxPAServer19.0.tar.gz
#Development Toolsをインストール
sudo yum groupinstall "Development Tools"

sudo /sbin/ldconfig -p | grep libgcc
#入ってなさそうなら下記も入れる
sudo yum install -y gcc gcc-c++
sudo yum install -y openssl-devel

http://docwiki.embarcadero.com/RADStudio/Tokyo/ja/Linux_アプリケーション開発
http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/compile-software.html

[ツール]→[オプション]画面
2017-05-021646.png
[接続プロファイル マネージャ]→[追加]し[接続テスト]をクリック
成功したら同じオプション画面の[SDK マネージャ]でSDKを追加します

2017-05-021650.png

2017-05-021653.png

RAD Studio側で新規プロジェクト作成

[ファイル]→[新規作成]→[その他]→[Delphi プロジェクト]
2017-05-021755.png
こんな画面が出て真ん中にコードが書けるのですが
右端の方にプロジェクトマネージャーがありデバイスが選択できます

2017-05-021754.png
64ビット Linuxを選択します。

試したコード

Project1.dpr
program Project1;

{$APPTYPE CONSOLE}

{$R *.res}

uses
  System.SysUtils,
  System.Net.URLClient,
  System.Net.HttpClient, System.Net.HttpClientComponent;
var
  netc_:  TNetHTTPClient;
  res_:   IHTTPResponse;
  s_:     String;
begin
  try
    netc_ := TNetHTTPClient.Create(nil);
    try
      res_  := netc_.Get('http://mojeld.com/');
      s_    := res_.ContentAsString(TEncoding.UTF8);
      Writeln(s_);
    finally
      netc_.DisposeOf;
    end;
  except
    on E: Exception do
      Writeln(E.ClassName, ': ', E.Message);
  end;
end.

エラーが出る場合

[DCC エラー] E2597 C:Program Files (x86)EmbarcaderoStudio19.0binld-linux.exe: error: cannot find -lgcc_s
[DCC エラー] E2597 C:Program Files (x86)EmbarcaderoStudio19.0binld-linux.exe: error: cannot find -lcurl

実行するとエラーになる場合下記のファイルの名前を変更する

libgcc_s.so.1 → libgcc_s.so
libcurl.so.4 → libcurl.so

参考URL

https://community.embarcadero.com/blogs/entry/amazon-linux-delphi-japan

続きを読む

AWSでMastodonインスタンスを作るまで。自分まとめ

だいたいネットのチュートリアル通り

http://webfood.info/mastodon-aws-tutorial/
だいたいこの通りにやると構築できます(終了)

とするのも寂しいので、自分の環境で再現できるように、手順と詰まりやすい所を残しておきますね。

1.VPCを作る Virtual Private Cloud

A. まず、AWSから借りるサーバーをひとまとめにする仮想イントラネット、VPCを作ります。

image.png

この時、CIDR ブロックは XX.0.0.0/16をお勧めします。
ウィザード通りで大丈夫かと
image.png

↓ここからはVPCでトラブった時の雑学 CIDR ブロックについて若干おさらい。

VPCってなんだっけ。情報の授業のおさらい

VPCはAWSの仮想イントラネットです。VPCはサブネットマスクを使って自身のネットワーク内に
あるサーバーや更なるサブネットのアドレスを割り当てます。

こんな感じ、0が自分のネットワーク内で使えるアドレス

XX.0.0.0.0/24のサブネットマスク
11111111.11111111.11111111.00000000
0の数が8つ
2^8 = 256 のIPを割り振る事ができる。

XX.0.0.0.0/16のサブネットマスク
11111111.11111111.00000000.00000000
0の数が8つ
2^16 = 65536 のIPを割り振る事ができる。
これが分かってないと時々サブネットが作れず詰みになったりします。

情報の授業終わり

パブリックサブネットを作る

外部からSSH接続できるように仮想ルーターを配置します。
VPCの作成ウィザードで作成されてると思いますが、作られてなかったら、

A’ VPCダッシュボードからインターネットゲートウェイインターネットゲートウェイの作成で仮想ルーターを作ります。

仮想ルーターが出来たら、VPCにアタッチで作成したVPCとルーターを繋ぎます。
これで仮想ネットワークがインターネットに接続されました。

ですが、まだルーターがあるだけです。どのサブネットを作り、ルーターと接続します。
B’ サブネットの作成をクリックして先ほど作ったVPCにサブネットを作ります。
サブネットに割り当てるCIDRはXX.0.0.0.0/24がおすすめ

そして作成したサブネットをチェックし、ルートテーブルタブをクリック。
現在のルートテーブルを編集し、サブネットとインターネットゲートウェイをつなぎます。
image.png

rtb-XXXXXXXをクリックして編集します。

image.png

ルートタブから別ルートの追加 送信先を0.0.0.0/0 ターゲットをigw-XXXXXX(先ほど作成したインターネットゲートウェイのID)
を指定します。
これで、このサブネットにある仮想コンピューターはすべてインターネットからアクセスできるようになりました。
↑ここまで、VPCでトラブるケース。

2.インスタンスを作る。

A. Mastodonを実行するインスタンスを作ります。
インスタンスの作成をクリック
image.png

GithubのREADMEがUbuntuを推奨しているのでOSはUbuntuを選択するのがいいと思います。
一応はAmazon Linuxでも動く模様。
インスタンス詳細は先ほど作成したVPCサブネットを選択

image.png

ストレージは8Gだとすぐいっぱいになるっぽい。
20GBだとそれなりー、との噂を聞いたかも(曖昧)

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

B. SSH接続からインスタンスを操作するようにセキュリティグループを作ります。

image.png

マイIPを選択し、自分のコンピューターからSSHポートが繋がるようにします。

image.png

画面には移りませんがSSH接続するのに、RSA暗号を使います。
インスタンスを作成時にキーペアが作成されるので自分用の秘密鍵を大切に保管してください。(秘密鍵が漏れて、自分の仮想コンピューターで好き勝手されて、20万の請求が来たとかいう話も)
これを失くすとインスタンスに接続できません。必ず漏れないように大切に保管してください。

C. 外部から接続できるようにインスタンスにパブリックIPを設定します。
サービス > EC2インスタンス > Elastic IP
から新しいアドレスの割り当てでパブリックIPを取得します。
パブリックIPが取得出来たらアクション > IP の関連付けで先ほど作成したインスタンスにIPを割り当てます。

3インスタンスに接続する。

A. まず、自分はwindowsなのでSSHクライアントをダウンロードします。
Putty」でググってダウンロード
image.png

B. インストーラーをダウンロードしてウィザードに従ってインストールします。

C. Puttyをインストールしたら、ダウンロードした秘密鍵をPutty形式に変換します。
PuTTYgenを起動してLoadをクリック

先ほど保存した秘密鍵ファイルを選びます。

image.png

選択したらsave private keyを選択し、秘密鍵を保存します。

A. いよいよインスタンスに接続します。
Puttyを起動します。
左のタブから SSH > Auth からBrowseボタンを押して、先ほど保存した秘密鍵を選択
image.png

秘密鍵を読み込んだら、
sessionを選択
Host Nameubuntu@XX.XX.XX(インスタンスに割り当てたパブリックIP)を入力
ここまで言ったら接続設定を保存しましょう
Saved Sessions適当な名前を入れて接続設定を保存します。

image.png

接続設定を保存したら、Openをクリック

image.png

こういう系の画面が出たら成功です。
これでLinuxサーバーが操作が操作できます。

4.マストドンのセットアップ

ここからは完全に上述のテキスト通りです。

まず、メモリが足りないっぽいので、スワップファイルを作ります。

先ほどのコンソールにコマンドを打ち込みます。

$ sudo fallocate -l 4G /swapfile
$ sudo chmod 600 /swapfile
$ sudo mkswap /swapfile
$ sudo swapon /swapfile
$ echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

パッケージを最新にします。

$ sudo apt-get update
$ sudo apt-get upgrade

途中grub関連(?)の更新が聞かれますが

keep the local version currently installed

を選択してください。(どっちでも大丈夫だとは思うけど念のため)

マストドンのビルドetcに必要なソフトを入れます

$ sudo apt-get install -y python3-pip unzip docker.io nginx
$ sudo pip3 install docker-compose

上のテキスト通り、nginxの設定ファイルを編集します。

$ sudo vim /etc/nginx/sites-enabled/default

元々機能してた部分は#でコメントアウトします。
XX.XX.XX.XXの部分はインスタンスのパブリックIP

置き換える内容は以下の通りで。

map $http_upgrade $connection_upgrade {
  default upgrade;
  ''      close;
}

#server {
#  listen 80;
#  listen [::]:80;
#  server_name XX.XX.XX.XX;
#  return 301 https://$host$request_uri;
#}

server {
  listen 80;
  listen [::]:80;
  server_name XX.XX.XX.XX;
  #listen 443 ssl;
  #listen [::]:443 ssl;
  #server_name XX.XX.XX.XX;

  #ssl_protocols TLSv1.2;
  #ssl_ciphers EECDH+AESGCM:EECDH+AES;
  #ssl_ecdh_curve prime256v1;
  #ssl_prefer_server_ciphers on;
  #ssl_session_cache shared:SSL:10m;

  #ssl_certificate     /etc/letsencrypt/live/everydon.com/fullchain.pem;
  #ssl_certificate_key /etc/letsencrypt/live/everydon.com/privkey.pem;

  keepalive_timeout    70;
  sendfile             on;
  client_max_body_size 0;

  #root /home/mastodon/live/public;
  gzip on;
  gzip_disable "msie6";
  gzip_vary on;
  gzip_proxied any;
  gzip_comp_level 6;
  gzip_buffers 16 8k;
  gzip_http_version 1.1;
  gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

  add_header Strict-Transport-Security "max-age=31536000";

  location / {
    try_files $uri @proxy;
  }

  location @proxy {
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    #proxy_set_header X-Forwarded-Proto https;
    proxy_set_header Proxy "";
    proxy_pass_header Server;

    proxy_pass http://127.0.0.1:3000;
    proxy_buffering off;
    proxy_redirect off;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;

    tcp_nodelay on;
  }

  location /api/v1/streaming {
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    #proxy_set_header X-Forwarded-Proto https;
    proxy_set_header Proxy "";

    proxy_pass http://localhost:4000;
    proxy_buffering off;
    proxy_redirect off;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;

    tcp_nodelay on;
  }

  error_page 500 501 502 503 504 /500.html;
}

こんな感じになってるはず。
image.png

Nginxを再起動します。

$ sudo systemctl start nginx

これで、インスタンスのセキュリティグループをHTTPを任意のIPにすることでサーバーに接続できるはずです

Githubからマストドンのソースを持ってきます。

$ git clone https://github.com/tootsuite/mastodon

念のため、最新版を確認

$ cd mastodon
$ git tag -l
$ git checkout -b x.x.x refs/tags/vx.x.x(x.x.xは最新版のバージョン)

これでマストドンのソースがダウンロードされるはずです。

設定ファイルをコピーします。

$ cp .env.production.sample .env.production

設定ファイルの中でDBの永続化設定をします。

env.production
db:
  restart: always
  image: postgres:alpine
## Uncomment to enable DB persistance
  volumes:
    - ./postgres:/var/lib/postgresql/data

redis:
  restart: always
  image: redis:alpine
## Uncomment to enable REDIS persistance
  volumes:
    - ./redis:/data

dbとradisにある

  volumes:
    - ./nanntoka

の部分のコメントアウト(#)を外します

いよいよマストドンのビルドです
下記のコマンドを実行

$ sudo docker-compose build

5.マストドンの設定

マストドンが使うカギを生成します。
下記のコマンドを3回実行し、文字列をそれぞれどこかにコピーします。

$ sudo docker-compose run --rm web rake secret

こういう感じの文字列が出力されます。
3回コピーしてください。

4b804c1e71d14951a50cbc52f3b8a7ef9d1bf993e2774227cdf637102022f4a5af188aa4fa4c236b31e4ed6970469d1527e06097b678edfb0ed9e6d85c18d805

設定ファイルをもう一回いじります。

$ vim .env.production

ドメインの設定、後でもう一度設定し直します。

# Federation
LOCAL_DOMAIN=XX.XX.XX.XX
LOCAL_HTTPS=false

秘密鍵を入力します
=の先に3つの秘密鍵を入力

# Application secrets
# Generate each with the `rake secret` task (`docker-compose run --rm web rake secret` if you use docker compose)
PAPERCLIP_SECRET=
SECRET_KEY_BASE=
OTP_SECRET=

日本語設定はパス

DBのマイグレーションをします。
マストドンが使うデータベースの初期設定ですね。

$ sudo docker-compose run --rm web rails db:migrate

マストドンが使う固定ファイルを生成します。

$ sudo docker-compose run --rm web rails assets:precompile

ここで、Nginxを再起動します。
マストドンはport3000とport4000で動きますが、
以降は80ポートに来たアクセスをNginxがport3000とport4000に割り振ります。

マストドンへのアクセスの玄関口になる訳ですね。

$ sudo systemctl stop nginx
$ sudo systemctl start nginx

マストドンを起動します

$ sudo docker-compose up -d

マストドンが起動しました。

http://XX.XX.XX.XX/

にアクセスするとマストドンのトップページに飛ぶはずです。

mastodon-top.png

6.連携ソフトの設定

マストドンが利用するメールサービスを設定します。
メールはAWSのメールサービスSESを利用します。

ただ、途中です

続きを読む

AIDEを使ってファイルの改竄検知を行う。

はじめに

ファイル改竄検知に AIDE(Advanced Intrusion Detection Environment) というのがあります。
オープンソースでAmazon Linuxにもリポジトリが存在するのでyumで簡単に導入することが可能です。

インストール

リポジトリが存在するのでyumコマンドで簡単にインストールできます。

インストール
$ sudo yum install aide

データベースの初期化

インストールできたらまずは初期化を行います。

初期化
$ sudo aide -i

AIDE, version 0.14

### AIDE database at /var/lib/aide/aide.db.new.gz initialized.

初期化が完了すると aide.db.new.gz というファイルが作成されますが、デフォルトの参照ファイルは aide.db.gz であるため、リネームします。

データベース配置
$ sudo cp /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz

改竄チェック

それではチェックしてみましょう。

改竄チェック
$ sudo aide --check

AIDE, version 0.14

### All files match AIDE database. Looks okay!

okayとあるため特に問題はないみたいですがそりゃそうですよね。何もしてないですからw
ということで、 /root 配下に適当にファイルを作成してみます。

ファイル配置
$ sudo touch /root/aide-test.txt

それではもう一度チェックしてみましょう。

改竄チェック
$ sudo aide --check
AIDE found differences between database and filesystem!!
Start timestamp: 2017-04-28 17:36:55

Summary:
  Total number of files:    60760
  Added files:          1
  Removed files:        0
  Changed files:        1


---------------------------------------------------
Added files:
---------------------------------------------------

added: /root/aide-test.txt

---------------------------------------------------
Changed files:
---------------------------------------------------

changed: /root

--------------------------------------------------
Detailed information about changes:
---------------------------------------------------


Directory: /root
  Mtime    : 2017-04-28 17:28:16              , 2017-04-28 17:36:47
  Ctime    : 2017-04-28 17:28:16              , 2017-04-28 17:36:47

先ほど作成したファイルが表示されました。追加/削除/変更が確認できるので便利ですね。

更新

このままだとチェックするたびに変更が増えていってしまいますね。
なのでデータベースを更新する必要があります。更新は初期化してあげればOKです。

データベース更新
$ sudo aide --init

AIDE, version 0.14

### AIDE database at /var/lib/aide/aide.db.new.gz initialized.
データベース更新
$ sudo cp /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz

これだと毎回「チェック → 更新」を繰り返さないといけないので面倒です。
そんな場合はupdateオプションを利用すれば解決です。

このオプションはチェックを行なった後、データベースの更新をしてくれます。

オプション

主要なオプションについてまとめました。

オプション 説明
–init または -i データベースの初期化
–check または -C データベースのチェック
–update または -u データベースのチェックと更新

おわりに

これをcronとかで定期実行すればファイル改竄検知が手軽にできてとても便利ですね。

続きを読む

Security Groupの適切な設定のためにできる、たった2つのこと(STOP!フル開放運動)

こんにちは、ひろかずです。

構築や検証中に思うように動作しない時にSecurity Groupをはじめとするファイアウォール機能を疑いたくなりますよね。
今回は、SecurityGroupの設定が正しいか不安な時に闇雲にフル開放してしまうより効率的に切り分けをできる方法があるので、一筆書きます。

お品書き

  1. Listenポートの確認
  2. VPC FlowLogsの確認

1. Listenポートの確認

サーバで待ち受けていないポートをSecurity Groupで開放する必要はありません。
どのサービスがどのポートを使用しているかを再確認し、開放するべきポートが開放されているかを確認しましょう。

0.0.0.0:ポート番号:::ポート番号 で表現されているポートが外部からの待受を想定しているポートです。
上手くできないことに関連するポートを開放すると良いでしょう。
切り分けたい現象にもよりますが、sshやntp等の関連性が薄いサービスポートを空ける必要性は低いはずです。

出力例

netstat -luntp (Amazon Linuxの場合)

# netstat -luntp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address               Foreign Address             State       PID/Program name
tcp        0      0 0.0.0.0:111                 0.0.0.0:*                   LISTEN      2331/rpcbind
tcp        0      0 0.0.0.0:22                  0.0.0.0:*                   LISTEN      32508/sshd
tcp        0      0 127.0.0.1:25                0.0.0.0:*                   LISTEN      32592/sendmail
tcp        0      0 0.0.0.0:36254               0.0.0.0:*                   LISTEN      2352/rpc.statd
tcp        0      0 :::111                      :::*                        LISTEN      2331/rpcbind
tcp        0      0 :::80                       :::*                        LISTEN      2628/httpd
tcp        0      0 :::22                       :::*                        LISTEN      32508/sshd
tcp        0      0 :::4118                     :::*                        LISTEN      15287/ds_agent
tcp        0      0 :::443                      :::*                        LISTEN      2628/httpd
tcp        0      0 :::46046                    :::*                        LISTEN      2352/rpc.statd
:

netstat -nao & Task Manager(Windows2012の場合)

コマンドプロンプトでポートとPIDを確認し、Task ManagerでPIDとサービスを確認することができます。

C:UsersAdministrator>netstat -nao

Active Connections

  Proto  Local Address          Foreign Address        State           PID
  TCP    0.0.0.0:135            0.0.0.0:0              LISTENING       792
  TCP    0.0.0.0:445            0.0.0.0:0              LISTENING       4
  TCP    0.0.0.0:3389           0.0.0.0:0              LISTENING       72
  TCP    0.0.0.0:4118           0.0.0.0:0              LISTENING       163
  TCP    0.0.0.0:5985           0.0.0.0:0              LISTENING       4
  TCP    0.0.0.0:47001          0.0.0.0:0              LISTENING       4
  TCP    0.0.0.0:49152          0.0.0.0:0              LISTENING       600
  TCP    0.0.0.0:49153          0.0.0.0:0              LISTENING       928
  TCP    0.0.0.0:49154          0.0.0.0:0              LISTENING       972
  TCP    0.0.0.0:49155          0.0.0.0:0              LISTENING       121
  TCP    0.0.0.0:49157          0.0.0.0:0              LISTENING       688
  TCP    0.0.0.0:49158          0.0.0.0:0              LISTENING       208
  TCP    0.0.0.0:49164          0.0.0.0:0              LISTENING       696
  TCP    172.31.40.9:139        0.0.0.0:0              LISTENING       4
  :

taskmanager.png

2. VPC FlowLogsの確認

インスタンスに紐付けられているENIで遮断している通信を確認します。
実際に目的とする動作を行い、その実施時間で遮断している通信(REJECTで検索)があるかを確認するのが良いでしょう。

VPC FlowLogsの設定の仕方はawsブログ : VPC Flow Logs – トラフィックフローの収集、閲覧を参照してください。

FlowLogs.png

このように、Security Groupで遮断された通信はひと目で判断することができます。
切り分けの観点であれば、これで十分と言えるでしょう。

おわりに

闇雲にSecurity Groupを開きすぎてしまうと、原因が特定できないだけではなく、セキュリティを著しく低下させてしまいます。
サービスの稼働を優先させた場合、設定を戻すこともままならず、セキュリティを低下させたまま運行することになるかもしれません。

検証環境や構築中の環境でも、インターネットからの脅威は本番環境と変わらずに訪れます。
むしろ、セキュリティ強度の劣る検証環境や構築中の環境は、格好の標的になるでしょう。

Security Groupフル開放によるインシデントは防げます。
本稿が少しでもその助けになれば幸いです。

今日はここまでです。
お疲れ様でした。

続きを読む

S3への書き込みを比較してみる

環境

項目 設定
OS AmazonLinux (version 2017.03)
インスタンスタイプ t2.micro
ボリュームタイプ gp2
pythonバージョン Python 3.5.3 (pyenv)
AWS CLIバージョン aws-cli/1.11.82
goofysバージョン 0.0.10
s3fsバージョン V1.80

goofysのインストール

こちらの記事を参考にさせてもらいました。
goofysを使ってAmazon LinuxにS3をマウントする。

コマンドメモ
# yum install golang fuse
# export GOPATH=$HOME/go
# go get github.com/kahing/goofys
# go install github.com/kahing/goofys

exportのところは、/root/.bash_profileの末尾に書き足してsourceした。

インストールできたのでバージョンを確認。結構若い。

goofysのバージョン
[root@ip-172-30-0-5 ~]# ./go/bin/goofys --version
goofys version 0.0.10

これ、/usr/sbinかなんかの下に入れたほうがよかったな。
mvしてやろうと思ったけどgoのこと詳しくないからとりあえず触らないでおこう…ださいけど。

では、マウント。

[root@ip-172-30-0-5 ~]# /root/go/bin/goofys jucco-s3-speed-test /goofys
[root@ip-172-30-0-5 ~]# df -h
Filesystem           Size  Used Avail Use% Mounted on
devtmpfs             488M   56K  488M   1% /dev
tmpfs                497M     0  497M   0% /dev/shm
/dev/xvda1           7.8G  2.3G  5.5G  30% /
jucco-s3-speed-test  1.0P     0  1.0P   0% /goofys

特にレスポンス無しでマウントが完了。

s3fsのインストール

本家の手順で実施。
https://github.com/s3fs-fuse/s3fs-fuse

# yum install automake fuse fuse-devel gcc-c++ git libcurl-devel libxml2-devel make openssl-devel
# git clone https://github.com/s3fs-fuse/s3fs-fuse.git
# cd s3fs-fuse
# ./autogen.sh
# ./configure
# make
# make install
[root@ip-172-30-0-5 s3fs-fuse]# s3fs --version
Amazon Simple Storage Service File System V1.80(commit:f02b1bc) with OpenSSL
Copyright (C) 2010 Randy Rizun <rrizun@gmail.com>
License GPL2: GNU GPL version 2 <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

成功したっぽい。こっちは/usr/local/bin/s3fsにファイルを発見。
では、マウント。とりあえずオプションは最低限。なんでIAM Role名指定するんだろう…。

[root@ip-172-30-0-5 s3fs-fuse]# s3fs jucco-s3-speed-test /s3fs -o iam_role=administrator
[root@ip-172-30-0-5 s3fs-fuse]# df -h
Filesystem           Size  Used Avail Use% Mounted on
devtmpfs             488M   56K  488M   1% /dev
tmpfs                497M     0  497M   0% /dev/shm
/dev/xvda1           7.8G  2.3G  5.4G  30% /
jucco-s3-speed-test  1.0P     0  1.0P   0% /goofys
s3fs                 256T     0  256T   0% /s3fs

まず使える容量としてはgoofysが上。ペタバイトかぁ。

簡易測定

ddコマンドで測ってみる。

コマンド
time dd if=/dev/zero of=<path>/1024MB.tmp ibs=1M obs=1M count=1024

結果1 : ddコマンドで比較

goofys s3fs local disk
56.3 MB/s 30.1 MB/s 74.2 MB/s

おおっ、確かに全然違う。

AWS CLIとも比較してみたかったので、平等にローカルディスクからコピーする時間を比較してみた。

コマンド
time cp /root/1024MB.tmp <path>/

or

time aws s3 cp /root/1024MB.tmp s3://jucco-s3-speed-test/

結果2 : cpコマンドで比較

goofys s3fs aws s3 cp local disk
0m21.362s 0m36.652s 0m19.168s 0m15.783s

goofysよりもaws cliが早いのは、file systemとして動かすための余計な処理が挟まっているからかな。
まあでもs3fsと比べるとそんなに大したズレでもないか。

bonnie++で測定

こちらを参考にしました。
https://hesonogoma.com/linux/UsageOfBonnie.html

コマンドメモ
# wget http://www.coker.com.au/bonnie++/bonnie++-1.03e.tgz
# tar xf bonnie++-1.03e.tgz
# cd bonnie++-1.03e
# ./configure
# vi bonnie.h
 ※#define MinTime (0.5) → #define MinTime (0.01)
# make

あとから気づいたけどrpmも転がっている系だったのか…
ともあれ、makeが完了。

[root@ip-172-30-0-5 bonnie++-1.03e]# ./bonnie++ help
usage: bonnie++ [-d scratch-dir] [-s size(MiB)[:chunk-size(b)]]
                [-n number-to-stat[:max-size[:min-size][:num-directories]]]
                [-m machine-name]
                [-r ram-size-in-MiB]
                [-x number-of-tests] [-u uid-to-use:gid-to-use] [-g gid-to-use]
                [-q] [-f] [-b] [-D] [-p processes | -y]

Version: 1.03e

こんな感じで測定する。

コマンド
./bonnie++ -d <path> -n 256:1024:1024:16 -u root

-nのところは「ファイル数 256*1024、最大ファイルサイズ 4096byte、最小ファイルサイズ 512byte、ディレクトリ数 16」という意味らしい。
→やたら時間かかるから途中から-nオプション消した。(が、これがのちに失敗だったことに気づく。測定結果には関係ないけど。

結果をはりたかったけど

早速goofysの測定でコケた。

[root@ip-172-30-0-5 bonnie++-1.03e]# ./bonnie++ -d /goofys -n 256:1024:1024:16 -u root
Using uid:0, gid:0.
Writing with putc()...done
Writing intelligently...done
Rewriting...Can't read a full block, only got 0 bytes.
Can't read a full block, only got 0 bytes.
Bad seek offset
Error in seek(0)

ファイル読み込みに失敗?タイムアップなので今度リトライしてみよう。

[2017/5/5 追記]

bonnie++のソースをgrepしてみたら、とりあえずreadって関数で落ちたみたい。
たぶんこれ。
Man page of READ

ssize_t read(int fd, void *buf, size_t count);

read() はファイルディスクリプター (file descriptor) fd から最大 count バイトを buf で始まるバッファーへ読み込もうとする。

goofysくんはこの関数のリクエストをうまくハンドリングできないってことなのかな…
にわか知識でこれ以上コメントしたくないので、とりあえず期待通りに動作してくれないケースがあることがわかっただけで良しとしよう。

結果3 : bonnie++で比較

s3fsのほうはbonnie++でちゃんと測定できたのでlocal diskと比較。

分類 項目 単位 s3fs local disk
Sequential Output Per Chr K/sec 28,616 67,706
Block K/sec 30,211 67,248
Rewrite K/sec 24,039 59,861
Sequential Input Per Chr K/sec 24,015 62,497
Block K/sec 29,827 62,503
Random Seeks /sec 72.8 10,965
Sequential Create Create /sec 7 141,305
Read /sec 69 1,177,106
Delete /sec 27 183,235
Random Create Create /sec 6 143,461
Read /sec 94 98
Delete /sec 29

※結果が早すぎて測定不可だった。オプションの指定が悪かった。

差がすごい…
特にRandom Create(時間あたりに作成可能なランダムな命名規則のファイル…だと思う)にいたっては23,910倍。
これは使い道を限定するなぁ。

生ログはこちら。

■s3fs
Version 1.03e       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
ip-172-30-0-5    2G 28616  28 30211   2 24039   1 24015  22 29827   0  72.8   0
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16     7   0    69   0    27   0     6   0    94   0    29   0
ip-172-30-0-5,2G,28616,28,30211,2,24039,1,24015,22,29827,0,72.8,0,16,7,0,69,0,27,0,6,0,94,0,29,0
■local disk
Version 1.03e       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
ip-172-30-0-5    2G 67706  64 67248   3 59861   3 62497  60 62503   1 10965   9
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16 141305 100 1177106  86 183235  98 143461  98 +++++ +++ 185059  99
ip-172-30-0-5,2G,67706,64,67248,3,59861,3,62497,60,62503,1,10965.1,9,16,141305,100,1177106,86,183235,98,143461,98,+++++,+++,185059,99

s3fsは遅すぎて(?)CPU負荷があまりあがってない模様。都度AWS API発行 + NWネックで遅くなっている気がする。

この記事はこのへんでー。

続きを読む