イカれたバックアップシステムを紹介するぜ!

オンプレにあるバックアップデータをAWSに持っていくための基盤を用意する話

AWS側の基盤作り

AWSにデータをバックアップするための基盤が必要
色々やってみた結果、EC2インスタンスは必須で

  • LVMのSnapshotをデータソースにし気合でrsyncでバックアップする!!!
  • インスタンスは使い終わったら破棄したい
  • できるだけ運用コストがかからない構成を考える

SAの方に相談したところStep Functionsが使えるとのことで、
State Machineを定義しLambda Functionを7個くらい書く

  • sc1 volumeでコストを抑える

夜間しか使わないので、これで間に合えばOK

SFNと連携するActivityアプリケーションの開発

State Machineに対してget activity task APIでポーリングし、
トークンと前段のLambdaからインスタンス情報を受け取りバックアップを実行するシンプルなもの。

  • Rubyで実装しました
  • 長時間ポーリングするとタイムアウトしてしまう

必要な場合は、Net::ReadTimeout, Seahorse::Client::NetworkingErrorをrescueしてretryすることで
長時間ポーリングしていられる

バックアップ方法の変更と移行

  • Activityアプリケーションはchefで配布し、cronもセットできる

Activity名をホスト名などの固有値にしておくと明示的に書かなくて良いので楽

  • rsyncの場合、初回同期に膨大な時間がかかる

まずは適当なインスタンスを用意し、バックアップサーバーからインスタンスへある程度同期させておく

スライド

IMAGE

続きを読む

rootにmountされているEBSを、mountしたまま拡張する手順

前提

  • Amazon Linux 利用
  • ファイルシステムは ext4

Modify Volume でEBS拡張

AWSコンソールで操作

スクリーンショット 2017-06-09 17.44.31.png

Modify Volumeを行っただけでは、ディスクのサイズが変更されるだけなので、
OS上でパーティションの拡張を行う。

OSでパーティション拡張

Modify Volume前

# lsblk
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0   8G  0 disk
└─xvda1 202:1    0   8G  0 part /

Modify Volume後

# lsblk
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0  15G  0 disk
└─xvda1 202:1    0   8G  0 part /

growpart(cloud-utils-growpart)実行。

# growpart /dev/xvda 1
CHANGED: disk=/dev/xvda partition=1: start=4096 old: size=16773086,end=16777182 new: size=31453150,end=31457246

reseize2fs でパーティションを拡張

# resize2fs /dev/xvda1
resize2fs 1.42.12 (29-Aug-2014)
Filesystem at /dev/xvda1 is mounted on /; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 1
The filesystem on /dev/xvda1 is now 3931643 (4k) blocks long.
# df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        236M   56K  236M   1% /dev
tmpfs           245M     0  245M   0% /dev/shm
/dev/xvda1       15G  974M   14G   7% /

増えた!

できないこと

縮小不可!

続きを読む

既存のEC2インスタンスのディスク容量を拡張する

ある日EC2インスタンスにログインしコマンドを実行しようとしたら

cannot create temp file for here-document: No space left on device

なるものが表示されました。
どうやらディスク容量がいっぱいの様子なので増やしてあげます。

まずはAWSのドキュメントに記載されているコンソールからの EBS ボリュームの変更を行います。特に問題なし。

今回拡張してあげたいのはルートパーティションなので

1.インスタンスからEBSボリュームをデタッチ
2.ルートパーティションを持つ別のインスタンスにアタッチ
3.2でアタッチしたインスタンス上からpartedコマンドを使用してパーティションを拡張
4.元のインスタンスにアタッチ

ざっくり説明すると、このような流れになります。

1, 2の手順はここの通りに進めればOK。
3.も基本的にparted を使用して Linux パーティションを拡張するの通りに進めればOKですが、mkpartコマンドを実行する際に

Warning: The resulting partition is not properly aligned for best performance.

というwarningが私の環境では表示されましが、Ignoreで問題ありませんでした。

4.あとはアタッチして起動するだけ!と思ったら

Instance does not have a volume attached at root

と表示されてインスタンスが起動できない。

EC2 のルートデバイスに EBS をアタッチする方法

アタッチする際のデバイス名をインスタンスタイプによって適したものに変える必要があるんですね。
この時はUbuntuを使用していたので /dev/sda1 にしたら無事起動しました。

続きを読む

AWSのGPUインスタンスにTensorflow/Keras環境を構築する 2017年6月版

概要

AWSのGPUインスタンスに、TensorflowおよびKerasがGPUで動作する環境を構築します。

こういった記事がn番煎じなのは承知の上ですが、それでもネットには各々のタイミングで書かれ最新かどうかも分からない資料が散逸しているので、こういうものと割り切って今の現状を書きます。まだまだ手作業な部分がありつつも、NouveauやCUDA Toolkitの手動インストールから解放されたようです。

参考資料


基本的には下記URLの内容を参考にします。細かなバージョン等は変更を加えています。

環境

  • OS: Ubuntu Server 16.04 LTS (HVM), SSD Volume Type ami-afb09dc8
  • Instance type: g2.2xlarge, g2.8xlarge

作業

GPUインスタンスのセットアップ

選択するOSはUbuntu 16.04、あとの細かな設定は割愛します。ここでの注意としては、CUDA Toolkitのファイルがでかいので、ストレージのサイズはデフォルトの8GBではなく少し多めにしておいた方がいいでしょう。

NVIDIA Driverのインストール

$ sudo add-apt-repository ppa:graphics-drivers/ppa -y
$ sudo apt-get update
$ sudo apt-get install -y nvidia-375 nvidia-settings

CUDA Toolkitのインストール

CUDA Toolkitをインストールします。今回は8.0を利用します。ここではwgetで取得していますが、下記URLから「Linux > x86_64 > Ubuntu > 16.04 > deb (local)」で取得したインストーラーと同じです。

CUDA Toolkit Download | NVIDIA Developer

$ wget https://developer.nvidia.com/compute/cuda/8.0/Prod2/local_installers/cuda-repo-ubuntu1604-8-0-local-ga2_8.0.61-1_amd64-deb
$ sudo dpkg -i cuda-repo-ubuntu1604-8-0-local-ga2_8.0.61-1_amd64-deb
$ sudo apt-get update
$ sudo apt-get install -y cuda nvidia-cuda-toolkit

ここで、nvidia-sminvcc --versionで正常にインストールされたことを確認します。

cuDNNのインストール

cuDNNはNVIDIAのサイトからダウンロードしてAWSのインスタンスに転送する必要があります。

下記URLのダウンロードボタンを押して「cuDNN Software License Agreement」に同意し、「Download cuDNN v5.1 (Jan 20, 2017), for CUDA 8.0」の「cuDNN v5.1 Library for Linux」(ファイル名:cudnn-8.0-linux-x64-v5.1.tgz)をダウンロードします。要ログイン。

NVIDIA cuDNN | NVIDIA Developer

ダウンロードしたファイルをAWSのGPUインスタンスにコピーします。

# local
$ scp cudnn-8.0-linux-x64-v5.1.tgz aws-gpu-instance:

解凍して中のファイルを配置します

$ tar zxvf cudnn-8.0-linux-x64-v5.1.tgz 
$ sudo mv cuda/lib64/* /usr/local/cuda/lib64/
$ sudo mv cuda/include/* /usr/local/cuda/include/

環境変数の設定

利用しているシェルの設定ファイルに下記設定を追加します。今回は.bashrcに追記しました。

export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/usr/local/cuda/lib64"
export CUDA_HOME=/usr/local/cuda

TensorflowおよびKerasをインストールする

さて、ようやくTensorflowとKerasのセットアップです。Pythonの環境構築は割愛しますが、この記事に従うとpyenv/virtualenvを利用したPython3の環境が構築できます。

$ pip install tensorflow-gpu
$ pip install keras

GPUが利用できるかどうかテストする

試しにKerasのソースコードをダウンロードして、中のexampleを幾つか動かしてみます。

$ git clone https://github.com/fchollet/keras.git
$ cd keras/examples
$ python mnist_cnn.py

何か適当に動かしてみて、nvidia-smiでGPU-Utilが上がったり、ローカルやCPU利用版より明らかに早ければOKでしょう。お疲れ様でした。

参考:試行錯誤時のエラー

参考URLの一つに従ってインストールすると、cuDNNのバージョン差異でエラーになります。v5.0ではなくv5.1を利用しましょう。

Loaded runtime CuDNN library: 5005 (compatibility version 5000) but source was compiled with 5110 (compatibility version 5100)

続きを読む

AWS EC2にdockerベースのredashを一から設定して起動するまで

スクリーンショット 2017-05-31 0.22.43.png

オープンソースのDashboardツールredash。
postgresからAWS redshiftなど各種DB/DWHの情報をビジュアライズできるツール。
最近ではAirbnb社が開発したsupersetも注目されてますが、流行りのredashをインストールしてみた。

AWS EC2にdockerベースのredashを一から設定して起動するまでのセットアップメモ。

ポイントは以下
– redash、postgresql、nginx、redisで構成
– 全部公式のdockerイメージがある
– docker-composeで簡単一括実行
– 諸々のソースはredash公式のGit Hubリポジトリに公開されている。

※nginxはwebサーバ、postgreはクエリの実行結果やデータの保存、redisはタスクキューに使用するらしい。

1) EC2に最低限必要なツールをセットアップ

※amazon linux t2microインスタンスを利用

最初のおまじないと、docker & gitインストール

sudo yum install -y
sudo install -y docker git

sudo権限なしでdockerコマンドを使えるようにする

sudo usermod -a -G docker ec2-user
exit #一旦ログオフし再接続が必要

docker-composeインストール
※yum install docker-composeとかできると見せかけてできない

sudo curl -L "https://github.com/docker/compose/releases/download/1.11.2/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
sudo chmod +x /usr/local/bin/docker-compose

2) Git Hubからredash一式をgit close

git clone https://github.com/getredash/redash.git

https://github.com/getredash/redash

3) redashのdocker-compose.yamlを編集

cloneしたredash/docker-compose.yamlを編集する。
もともとのdocker-compose.yamlはプロダクション利用には不向きの設定らしく、redash/docker-compose.production.yamlをコピーし、編集する。
編集ポイントは、postgresqlのvolumeとpassword関連。デフォルトではコメントアウトまたは何も記載がない。

docker-compose.yaml

# This is an example configuration for Docker Compose. Make sure to atleast update
# the cookie secret & postgres database password.
#
# Some other recommendations:
# 1. To persist Postgres data, assign it a volume host location.
# 2. Split the worker service to adhoc workers and scheduled queries workers.
version: '2'
services:
  server:
    image: redash/redash:latest
    command: server
    depends_on:
      - postgres
      - redis
    ports:
      - "5000:5000"
    environment:
      PYTHONUNBUFFERED: 0
      REDASH_LOG_LEVEL: "INFO"
      REDASH_REDIS_URL: "redis://redis:6379/0"
      REDASH_DATABASE_URL: "postgresql://postgres@postgres/postgres"
      REDASH_COOKIE_SECRET: veryverysecret
  worker:
    image: redash/redash:latest
    command: scheduler
    environment:
      PYTHONUNBUFFERED: 0
      REDASH_LOG_LEVEL: "INFO"
      REDASH_REDIS_URL: "redis://redis:6379/0"
      REDASH_DATABASE_URL: "postgresql://postgres@postgres/postgres"
      QUEUES: "queries,scheduled_queries,celery"
      WORKERS_COUNT: 2
  redis:
    image: redis:3.0-alpine
  postgres:
    image: postgres:9.5.6-alpine
    volumes:  #コメントアウトを取る
      - /home/ec2-user/postgres-data:/var/lib/postgresql/data
    environment: #追加する
      - POSTGRES_USER:'test'
      - POSTGRES_PASSWORD:'pwd'
      - POSTGRES_DB:'mydb'
  nginx:
    image: redash/nginx:latest
    ports:
      - "80:80"
    depends_on:
      - server
    links:
      - server:redash

postgresのデータは永続化するためホストにvolumeマウントする。
上記設定に応じてホスト側にマウントパスディレクトリを作成しておく。

sudo mkdir -p /home/ec2-user/postgres-data

4) docker-composeでredash(及び関連ツール)起動

docker-compose run --rm server create_db
docker-compose up

5) ブラウザで確認

EC2側で設定したパブリックIP宛にブラウザで起動すると、Redisログインページが表示される。
※EC2のSG等で80番のインバウンドが許可されていること。

参考)
http://qiita.com/wizpra-koyasu/items/aa8b3fc069816d91ae05

続きを読む

AWSのGPUインスタンスでChainerMNを動かす環境構築

ChainerMNを試してみようと思い、AWS上に環境構築をしてみたので、その作業記録を残しておきます。

AWSのp2インスタンスはそれなりの値段がするので、環境構築は素早く終わらせたいですよね。

構成

  • AWS p2.8xlarge
  • Ubuntu Server 16.04 LTS (HVM), SSD Volume Type – ami-efd0428f
  • CUDA 8.0
  • cuDNN v5.1
  • Python 3.5.2
  • Chainer 1.24.0
  • ChainerMN 1.0.0b1

参考サイト

作業

前準備

$ sudo apt-get update
$ sudo apt-get upgrade
$ sudo apt-get install linux-generic
$ sudo apt-get install build-essential
$ vi .bashrc # 以下の2行を追加
export LD_LIBRARY_PATH="/usr/local/lib:$LD_LIBRARY_PATH"
export CPATH="/usr/local/include"

NVIDIA DriverとCUDAのインストール

CUDA Toolkit Download にアクセスし、Linux、x86_64、Ubuntu、16.04、deb [network]と選択し、ダウンロードリンクを拾ってきて、以下の作業をする。

$ wget http://developer.download.nvidia.com/compute/cuda/repos/ubuntu1604/x86_64/cuda-repo-ubuntu1604_8.0.61-1_amd64.deb
$ sudo dpkg -i cuda-repo-ubuntu1604_8.0.61-1_amd64.deb
$ sudo apt-get update
$ sudo apt-get install cuda nvidia-367
$ sudo reboot
$ sudo apt-get autoremove
$ rm cuda-repo-ubuntu1604_8.0.61-1_amd64.deb
$ vi .bashrc # 以下の4行を追加
export CUDA_HOME="/usr/local/cuda-8.0"
export PATH="$CUDA_HOME/bin:$PATH"
export LD_LIBRARY_PATH="$CUDA_HOME/lib64:$LD_LIBRARY_PATH"
export CPATH="$CUDA_HOME/include:$CPATH"

ログインし直す。

cuDNN 5.1のインストール

cuDNN DownloadでDownload cuDNN v5.1 (Jan 20, 2017), for CUDA 8.0、cuDNN v5.1 Library for LinuxをダウンロードしてAWS上に置いておく。

$ tar xzvf cudnn-8.0-linux-x64-v5.1.tgz
$ sudo cp -a cuda/lib64/* $CUDA_HOME/lib64/
$ sudo cp -a cuda/include/* $CUDA_HOME/include/
$ sudo ldconfig
$ rm -rf cuda cudnn-8.0-linux-x64-v5.1.tgz

LightDM を止める

$ sudo vi/etc/default/grub # 12行目を以下の用に編集
GRUB_CMDLINE_LINUX="systemd.unit=multi-user.target"
$ sudo update-grub
$ sudo reboot

Open MPIのインストール

Open MPI Open Source High Performance ComputingからOpen MPIのダウンロードリンクを拾ってきて、以下の作業をする。

$ wget https://www.open-mpi.org/software/ompi/v2.1/downloads/openmpi-2.1.1.tar.bz2
$ tar jxvf openmpi-2.1.1.tar.bz2
$ cd openmpi-2.1.1
$ ./configure --with-cuda
$ make -j4
$ sudo make install
$ cd
$ rm -rf openmpi-2.1.1 openmpi-2.1.1.tar.bz2

NVIDIA NCCLのインストール

$ git clone https://github.com/NVIDIA/nccl.git
$ cd nccl
$ make CUDA_HOME=/usr/local/cuda-8.0
$ sudo mkdir /usr/local/nccl
$ sudo make PREFIX=/usr/local/nccl install
$ cd
$ rm -rf nccl
$ vi .bashrc # 以下の4行を追加
export NCCL_ROOT="/usr/local/nccl"
export CPATH="$NCCL_ROOT/include:$CPATH"
export LD_LIBRARY_PATH="$NCCL_ROOT/lib/:$LD_LIBRARY_PATH"
export LIBRARY_PATH="$NCCL_ROOT/lib/:$LIBRARY_PATH"

ログインし直す。

Chainer, ChainerMNなどのインストール

$ sudo apt-get install python3-pip
$ sudo pip3 install --upgrade pip
$ pip3 install --user pillow h5py chainer
$ pip3 install --user cython
$ lspip3 install --user chainermn

詰まったところ

NVIDIAドライバーのインストール

  • 上の手順でやれば間違いないはず

ChainerMNのインストールがうまくいかない

  • 原因:CythonがLD_LIBRARY_PATHとCPATHを正しく見ていなかった

参考のChainer 1.5のインストールがうまくいかない人への非公式なTipsによると、Cythonインストール前にLD_LIBRARY_PATHとCPATHが設定されていないといけないらしい。
また、pipをsudoで行うと、環境変数がrootに引き継がれないので注意。–userでやろう。

続きを読む

EC2 instance起動時にtagをつけるTagSpecifications

AWSCLIでEC2 instance起動時に同時にタグをつける方法としては、instance起動してinstance-idを取得しておいて、パイプでつないでtagをつけたり、スクリプトの中で後でタグ付けする方法があったと思います。
http://kurochan-note.hatenablog.jp/entry/2017/01/08/220155

AWSCLI EC2 Run-Instanceのなかに–tag-specificationsというoptionが入って、run-instancesの中でタグが作成できるようになりました。地味なアップデートかもしれませんが、結構うれしいです。

instanceの詳細はjsonに記述して、下記のように指定して実行します。

aws ec2 run-instances --cli-input-json file://instance.json

EC2は山ほど設定項目があるので、generate-cli-skeltonでフォーマットを出力して、必要な項目だけ入力して、不必要なものは消すとinstanceの詳細を記述したjsonの完成です。Gitにでも入れておきましょう。
http://docs.aws.amazon.com/cli/latest/userguide/generate-cli-skeleton.html

aws ec2 run-instances --generate-cli-skeleton

Instanceの設定詳細を記述したjsonサンプル

instance.json
{
    "ImageId": "<image-id>",
    "KeyName": "<my-key>",
    "SecurityGroupIds": [
        "<my-sgid>"
    ],
    "InstanceType": "<instance-type>",
    "BlockDeviceMappings": [
        {
            "VirtualName": "Root",
            "DeviceName": "/dev/sda1",
            "Ebs": {
                "VolumeSize": 100,
                "DeleteOnTermination": true,
                "VolumeType": "gp2"
            }
        }
    ],
    "Monitoring": {
        "Enabled": false
    },
    "SubnetId": "<subnet-id>",
    "DisableApiTermination": false,
    "IamInstanceProfile": {
        "Name": "<instance-iam-role>"
    },
    "TagSpecifications":[
        {
            "ResourceType": "instance",
            "Tags": [
              {
                "Key": "Name",
                "Value": "<server-name>"
              },
              {
                "Key": "ClusterName",
                "Value": "<cluster-name>"
              },
              {
                "Key": "Application",
                "Value": "<myapp>"
              },
              {
                "Key": "CostCenter",
                "Value": "<my-cost-center>"
              },
              {
                "Key": "Environment",
                "Value": "Test"
              },
              {
                "Key": "User",
                "Value": "<user-name>"
              }
            ]
        },
        {
          "ResourceType": "volume",
          "Tags": [
            {
              "Key": "Device",
              "Value": "<device-name>"
            },
{
              "Key": "CostCenter",
              "Value": "<my-cost-center>"
            },
            {
              "Key": "backup_key",
              "Value": "true"
            }
          ]
        }
    ]
}

続きを読む

EC2のボリューム(EBS)容量拡張方法検証 (AmazonLinux)

結論を3行で

検証

【遂に来た!】EBS でボリュームサイズを変更できるようになりました(ボリュームタイプ変更も) | Developers.IO を参考に、稼働中のインスタンスにアタッチ済みのボリュームのサイズを増やしてみます。

今回ボリュームを増やしたいインスタンスはこのような感じです。

インスタンス的には/dev/xvdaというところに30GBのボリュームがあります。

ec2-user@ip-172-31-10-224 ~ $  df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda1       30G  3.8G   26G  13% /
devtmpfs        490M   56K  490M   1% /dev
tmpfs           499M     0  499M   0% /dev/shm

ec2-user@ip-172-31-10-224 ~ $  lsblk
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0  30G  0 disk
└─xvda1 202:1    0  30G  0 part /

ほとんど元記事のとおりですが以下のような感じです。

スクリーンショット_2017-05-18_11_30_15.png

Modify Volumeを押します

スクリーンショット 2017-05-18 11.30.31.png

今回は 30GB -> 100GBにします

スクリーンショット 2017-05-18 11.32.51.png

パフォーマンスが変更されるまで時間がかかるとのこと。。yesを押す。

スクリーンショット 2017-05-18 11.33.00.png

完了。

スクリーンショット 2017-05-18 11.34.08.png

ボリュームの状態は optimizing...0% という表示になりますが、もうこの状態で ディスクの拡張は終わっています。

スクリーンショット 2017-05-18 11.34.46.png

awscli的には $ aws ec2 describe-volumes-modifications と叩くと進捗が表示されます(引数なしでOK)

$ aws ec2 describe-volumes-modifications
{
    "VolumesModifications": [
        {
            "TargetSize": 100,
            "TargetVolumeType": "gp2",
            "ModificationState": "optimizing",
            "VolumeId": "vol-0e92fb2e26dfd9687",
            "TargetIops": 300,
            "StartTime": "2017-05-18T02:34:07.151Z",
            "Progress": 0,
            "OriginalVolumeType": "gp2",
            "OriginalIops": 100,
            "OriginalSize": 30
        }
    ]
}

"Progress": 0 ですが、lsblk を叩くともう反映されていることがわかります。

ec2-user@ip-172-31-3-117 ~ $  lsblk
NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
xvda    202:0    0  100G  0 disk             # <- 100になってる
└─xvda1 202:1    0   30G  0 part /

次に resize2fs すればよいのですが、以下のような感じで怒られます。

resize2fs 1.42.12 (29-Aug-2014)
resize2fs: Device or resource busy while trying to open /dev/xvda
Couldn't find valid filesystem superblock.

今回はパーティションの設定がされているためと思われます。パーティションを利用している場合の設定はこちら。http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/storage_expand_partition.html
ただルートパーティションの場合は面倒そうなので、起動時に実行されるresize2fsに任せることにしました。

見たところAmazonLinuxの場合 /etc/cloud/cloud.cfg.d/00_defaults.cfg の中で resize2fs の記述があるので、再起動時に実行されるようです。

こうして、何も考えずにrebootすることにより、dfの結果が変わりました :tada:

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda1       99G  9.1G   90G  10% /           # <- 99GBに増えてる
devtmpfs        490M   56K  490M   1% /dev
tmpfs           499M     0  499M   0% /dev/shm

続きを読む

JAWS-UG コンテナ支部 #8

DockerCon 2017 報告 @toricls さん

LINUX KIT

  • Dockerエンジンをどの環境でも動作する為のLinuxサブシステムを集めたツール
  • DOCKER.YMLで定義する(ymlで定義)
  • 全てのサブシステムはコンテナ
  • ポータブルなlinuxサブシステム
  • 動作にはMobyが必要

MOBY PROJECT

  • ビルドツール(makeみたいなもの)。
  • アプリケーションエンジニア、インフラエンジニアには必要ない。
  • 将来的にはDockerバイナリをビルドできるようになる。
  • 従来のDockerはDocker社のものになった。

MULTI STAGE BUILDS

  • build用のコンテナを用意する必要なくなった。

    • Dockerfileでビルドを2つ書く

『Dockerで構成するWebサービス~EmotionTechの場合・増補版~』株式会社Emotion Tech 子安 輝さん

  • EmotionTechのDocker導入から運用までの話
  • ElasticBeanstallkを使用
  • phusionのDockerImageを使用(イメージサイズは大きい)。
  • フロント(angular.js)とバックエンド(Rails)とワーカー(SQS)の3つのコンテナ。テスト環境と本番環境は同じ構成。ローカル環境もだいたい同じ構成。
  • 構築する時に気をつけた事
    • ポリシーを持って構築。
    • 各環境(ローカル、CI)で使えるDockerバージョン
    • Dockerfileのお手本参照するべし(https://github.com/docker-library)
    • ローカル環境を本番環境に近づける
  • 使ってみたら起きたこと
    • rails cで30秒待った
    • CIで使いたいコマンドが使えなかった
    • db:migrateする仕組みがない
    • 環境変数でコンテナの挙動を変えたかった
  • 本稼働してから
    • ビルドがだんだん遅くなる
    • 監視は普通にやれた
    • 内部監視はホストのmackerelエージェント。
    • cronで監視ログをマウントしたVolumeに出力して、ホストのmackerelエージェントが監視している。これでうまくいっている。
    • インスタンスをあえて入れ替えた
  • Tips
    • ローカル環境はdocker-composeで。
    • ローカル環境の初期化/更新のスクリプトを用意。
    • ローカル環境の実行環境はDocker for xxxが主流。
    • GithubTag、Dockerイメージタグ、デプロイバージョン、全て同じ値を使用する。
    • 環境変数は設定出来る箇所は複数可能なのでどこで設定するかを整理しておく。
  • ステージング環境で検証したイメージをそのまま本番環境へデプロイする=ステージング環境から本番まで同じイメージを使用する事。
  • Railsを動作しているRails.envはProductionで動作してて、DBの接続先の変更は環境変数で切替している。

LT kenjiszk さん

  • FiNCでのコンテナの管理方法
  • マイクロサービス化しててAmazonECSで解決
  • Dockerビルド&テストはJenkins
  • ECSのクラスターはDeployTask、Web、Batchの3つで運用
  • jenkinsfileをDirectoryTopに用意しておく

LT hokkai7go さん

LT kuntaroIshiyama さん

LT gavinzhm さん

  • DockerHubの脆弱性について
  • DockerHubのイメージで80%以上は少なくても重大な脆弱性がある
    • CommunityImageが更新されていない(1800+)
    • オフィシャルイメージでも(392)
    • ScanningToolを使用するべき(Clairオススメ)
  • yum update apt-get updateする
  • AplineLinux使う
  • ScanTool使う
  • GolangならFROM scrachがある

LT wata727 さん

続きを読む

AWS EBSのルートディスク拡張した際のサイズ拡張のやりかた

いつも忘れるのでメモっておく
環境はUbuntu14.04

AWSコンソール上

EBSボリュームの「アクション」⇒「Modify Volume」
指定のサイズに設定

対象インスタンス上

# root
sudo su -

# 認識されてるか確認
lsblk

# 現在のサイズ確認
df -hT

# サイズ拡張
growpart /dev/xvda 1
resize2fs /dev/xvda1

# サイズ確認
df -hT

続きを読む