Ubuntu16.04にnvidia-dockerをインストールする方法

はじめに

dockerのversionも大分上がったので再度インストール設定をまとめました。
AWS EC2 P2インスタンスで確認

nvidiaドライバインストール

アップデート

sudo apt update -y
sudo apt upgrade -y

unable to resolve hostと言われた場合実行(今回は言われた)

sudo sh -c 'echo 127.0.1.1 $(hostname) >> /etc/hosts'

Repositoryを追加して、ドライバインストール。
ドライバのVersionはそれぞれのGPUで異なるので要確認

sudo add-apt-repository ppa:xorg-edgers/ppa
sudo apt-get update
apt-cache search 'nvidia-[0-9]+$'
sudo apt-get install nvidia-375
sudo reboot

dockerインストール

基本的に公式サイトに従う。

sudo apt-get install 
   apt-transport-https 
   ca-certificates 
   curl 
   software-properties-common

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -

sudo apt-key fingerprint 0EBFCD88

sudo add-apt-repository 
  "deb [arch=amd64] https://download.docker.com/linux/ubuntu 
  $(lsb_release -cs) 
  stable"

sudo add-apt-repository 
  "deb [arch=armhf] https://download.docker.com/linux/ubuntu 
  $(lsb_release -cs) 
  stable"

sudo apt-get -y update

sudo apt-get -y install docker-ce

sudo usermod -aG docker $USER
# ログインし直すとsudoしなくてもdockerコマンドが使える

nvidia-dockerインストール

sudo apt-get install nvidia-modprobe
wget -P /tmp https://github.com/NVIDIA/nvidia-docker/releases/download/v1.0.1/nvidia-docker_1.0.1-1_amd64.deb
sudo dpkg -i /tmp/nvidia-docker_1.0.1-1_amd64.deb
docker volume create -d nvidia-docker --name nvidia_driver_375.66
docker volume ls

動作確認

nvidia-docker run -it nvidia/cuda nvidia-smi

+-----------------------------------------------------------------------------+
| NVIDIA-SMI 375.66                 Driver Version: 375.66                    |
|-------------------------------+----------------------+----------------------+
以下略

続きを読む

【AWS】AWS CLIでインスタンスの情報を抽出(InstanceID, VolumeID, SnapshotID)

はじめに

EC2インスタンスのスナップショットをスクリプトで取得しようとした際、下記情報をコマンドで取得する必要がありました。備忘録です。
※sedコマンドとかしていますが、ダブルクォーテーションを削除するためです。

①自分自身のインスタンスID
②自分自身のボリュームID
③自分自身のボリュームから取得したスナップショットID一覧
④自分自身のTAG(Name)

前提

  • AWS CLIがインストールされていること。
  • aws configureコマンド実行済み。
  • EC2FullAccessの権限を持った、IAMユーザーのアクセスキーとシークレットキーを取得済み。

①自分自身のインスタンスID取得

169.254.169.254にインスタンスのメタデータがあるらしいです。

curl 'http://169.254.169.254/latest/meta-data/instance-id'; echo -en "n"

②自分自身のボリュームID取得

  • ${AWS_REGION}: リージョンを記載する。(例:ap-northeast-1)
  • ${INSTANCE_ID}: ①で取得したインスタンスIDを記載する。
aws ec2 describe-instances --region ${AWS_REGION} --instance-id ${INSTANCE_ID} --query 'Reservations[].Instances[].BlockDeviceMappings[].Ebs[]' | grep vol | sed 's/^.*"(.*)".*$/1/'

③自分自身のボリュームから取得したスナップショットID一覧取得

  • ${EBS_VOLUME_ID}: ②で取得したボリュームID
aws ec2 describe-snapshots --filters Name=volume-id,Values=${EBS_VOLUME_ID} | grep snap- | sed 's/^.*"(.*)".*$/1/'

④自分自身のTAG(Name)

  • ${AWS_REGION}: リージョンを記載する。(例:ap-northeast-1)
  • ${INSTANCE_ID}: ①で取得したインスタンスIDを記載する。
aws ec2 describe-instances --region ${AWS_REGION} --instance-id ${INSTANCE_ID} --query 'Reservations[].Instances[].Tags[].Value[]' | grep [0-9a-zA-Z] | sed 's/^.*"(.*)".*$/1/'

続きを読む

Docker for AWSの永続ストレージプラグインCloudstorでEFSをマウント

Docker for AWS(以下D4a)はGAの際、永続化ストレージをサポートするCloudstorというプラグインを添付するようになりました。

https://docs.docker.com/docker-for-aws/persistent-data-volumes/

D4aの17.06.0-ceでどのように使うのか試して見たので使用感など。

Cloudstorがサポートするストレージのタイプ

  • EBSにデバイスを作成してマウント

    • k8sでのPersistent Volumesのような感じ。
    • 複数コンテナからの同時利用ははなし。
  • EFSで任意のディレクトリをマウント
    • 対象のEFSはテンプレートパラメータで自動作成。
    • dockerdが環境変数EFS_ID_REGULAR, EFS_ID_MAXIOで対象を決めるので、一応既存のEFSも使えなくはない。
    • 複数コンテナからの同時利用OK。

つかってみる

ドキュメントではswarmモード(service)での使い方しか出ていませんが、単発のdocker runでも普通に機能します。

次のようにvolume-driverにcloudstor:awsを指定、デフォルトはEFS。

$ docker run -it --rm 
  --volume-driver=cloudstor:aws 
  -v sharedvol1:/shareddata 
  alpine:latest

これで、EFSにsharedvol1ディレクトリが作成され、Dockerコンテナからは/shareddataで参照できます。

EFS側に親ディレクトリがない場合もソース指定可能です。

$ docker run -it --rm 
  --volume-driver=cloudstor:aws 
  -v sharedvol5/1/2/3:/shareddata 
  alpine:latest touch /shareddata/touchfile

この場合、Dockerコンテナ起動時にEFSに対してsharedvol5/1/2/3というディレクトリを作ります。

なおマウント時にサブディレクトリを指定した場合も、VOLUME名はトップのディレクトリが使われます。

$ docker volume ls
DRIVER              VOLUME NAME
cloudstor:aws       sharedvol1
cloudstor:aws       sharedvol2
cloudstor:aws       sharedvol5
local               sshkey

挙動はこんな感じです。基本的にはdocker service/volumeで作成し、全ノードで参照できるようにしておくとよいでしょう。

このとき、EFSの中身

他のEC2インスタンスから/mnt/efsにEFSをマウントして、中の様子を見てみます。
VOLUME名のディレクトリが作られているだけでした。シンプルですね。

$ find /mnt/efs
/mnt/efs
/mnt/efs/sharedvol2
/mnt/efs/sharedvol1
/mnt/efs/sharedvol1/testfile
/mnt/efs/sharedvol5
/mnt/efs/sharedvol5/1
/mnt/efs/sharedvol5/1/2
/mnt/efs/sharedvol5/1/2/3/touchfile
/mnt/efs/fs-ef07xxxx:sharedvol1

一番下にあるやつは、EFSのID指定できないかなと考えたけど、とりあえずやってみて失敗に終わったディレクトリです。
Cloudstorはソースが非公開なので、-v fs-ef07xxxx:sharedvol1:/shareddataなどと実行したらこんなことに。

docker volume rm で、データも消える

volumeの詳細をチェック。

$ docker volume inspect sharedvol5
[
    {
        "Driver": "cloudstor:aws",
        "Labels": null,
        "Mountpoint": "/mnt/efs/reg/sharedvol5",
        "Name": "sharedvol5",
        "Options": {},
        "Scope": "local"
    }
]

いたって普通です。EFSレギュラー/MAXIO用の親ディレクトリを作り、そこにマウントと。
D4aではちょっとわからないけども、ホストから見るとEFSをマウントしっぱなのでしょうね。

最後に消したらどうなるのかと、docker volume rm sharedvol5してみました。
まずdocker管理下のvolumeは消えます、そしてEFS側も綺麗さっぱりです。

# 他インスタンスからEFSの中身を参照
$ find /mnt/efs
/mnt/efs
/mnt/efs/sharedvol2
/mnt/efs/sharedvol1
/mnt/efs/sharedvol1/testfile
/mnt/efs/fs-ef07xxxx:sharedvol1

ここ連動して消えちゃうのか。。Docker視点ならそれでよいけど、コンフィグの共有とかでマウントするとかのNFSな視点だと違和感はあります。
マウントが外れるだけという選択肢があってもよいとおもって、フォーラムに投稿しておきました。

終わりに

Docker Swarmが安定していればこの作りでも維持していけそうな気はしますが、なんだかんだでまだ不安定になったりします。
なにか手当をして回復するよりたいてい作り直した方が早いのですが、そういう運用ではvolumeのエントリーが巻き込まれてデータを消しそうな予感がしているため、(自分の用途では)フィードバックしつつもう少し様子見かなあ。

EBSも少しだけ触って見る

volume-optにbacking=relocatableを渡すと単体コンテナ用のEBSボリュームを作れます。

$ docker volume create -d cloudstor:aws 
  --opt backing=relocatable 
  --opt size=8 ebs1

=> ebs1

コマンド実行すると、ちゃんとEBSができていました。最初の紹介の通り、k8sのpvみたい。
こちらもdocker volume rm ebs1などとすると、EBSごと消えます。

続きを読む

AWS(Amazon EC2)でWebサーバーを構築する

AWS(Amazon EC2)でWebサーバーを構築する

インスタンスを作成する

Amazon EC2 コンソールを開いてから、「インスタンスの作成」をクリックします。
※ インスタンスとはawsの仮想サーバーのです。

1. AMIの選択

「Amazon Linux AMI 2017.03.1 (HVM), SSD Volume Type」を選択します。

2. インスタンスタイプの選択

「t2.micro」を選択します。

3. インスタンス作成の確認

「起動」をクリックします。

4. キーの作成

「新しいキーペアの作成」を選択し、「キーペア名」を入力します。
キーペアのダウンロードをクリックし、ファイルをダウンロードします。
インスタンスの軌道をクリックします。

インスタンスにssh接続する

1. ダウンロードしたキーの場所を変更

「.ssh」のフォルダに移動します。
隠しファイルが非表示になっている場合は、表示にしてから移動、もしくはターミナルから移動します。

2. ダウンロードしたキーの権限を設定

ターミナルから

chmod 400 ~/.ssh/mykeypair.pem

のように入力してキーの権限を400に設定します。
(パスは適時書き換えてください。)

3. ターミナルからインスタンスに接続

ターミナルから

ssh -i ~/.ssh/MyKeyPair.pem ec2-user@{IP アドレス}

初めての場合は

Are you sure you want to continue connecting (yes/no)?

と聞かれるのでyesを入力

       __|  __|_  )
       _|  (     /   Amazon Linux AMI
      ___|___|___|

こんな感じで帰ってきたら接続完了。
終了したい場合はexitと書けばsshが終了します。

Apachをインストール

続けてApachをインストールします。

インストール

sudo yum -y install httpd

起動

sudo service httpd start

インスタンスを起動したら自動的にApachが起動するようにする

sudo chkconfig httpd on

確認

chkconfig --list httpd
httpd           0:off   1:off   2:on    3:on    4:on    5:on    6:off

sftpでサーバーにアップロード

標準ではec2ユーザーはファイルのアップロードができないので、権限を変更します。

sudo su
chmod -R 755 /var/www/html
chown -R ec2-user /var/www/html

HTTPで表示できるようにする

インスタンスのページの説明タブから「セキュリティグループ/launch-wizard-1」をクリックします。
次に「インバウンド」のタブから「編集」をクリックし、httpを追加します。

ブラウザからwebを確認する

IPv4 パブリック IPでアクセスすることで画面が表示されます。

インスタンスを終了する

EC2 Management Consoleの画面から、「アクション」→「インスタンスの状態」→「停止」をクリックします。

参考

Linux 仮想マシンの起動
https://aws.amazon.com/jp/getting-started/tutorials/launch-a-virtual-machine/
AWS EC2でWebサーバーを構築してみる
http://qiita.com/Arashi/items/629aaed33401b8f2265c

続きを読む

BIツール superset をdockerでインストール

airbnbが開発したBIツール Apache Superse (incubating) をAWS EC2にdockerで立てたメモ。
AWS EC2 Amazon Linux t2.microで試した。

参考)
supreset GitHub (公式)
https://github.com/ApacheInfra/superset

関連記事)
http://qiita.com/risuoku/items/618b7d8614325025ab59
http://qiita.com/momota10/items/ee774188f770555238ca
http://qiita.com/hiro_koba/items/65f3e278d86174210776

dockerfile

redashと異なり、現時点(2017.7)では、公式のdockerfileは提供されてない。
公式GitHubに、dockerfileとしてcommunity contributedのリンクがある。
https://github.com/amancevice/superset

そのdockerfileが以下

FROM amancevice/pandas:0.19.2-python3

# Superset version
ARG SUPERSET_VERSION=0.18.5

# Configure environment
ENV LANG=C.UTF-8 \
    LC_ALL=C.UTF-8 \
    PATH=$PATH:/home/superset/.bin \
    PYTHONPATH=/home/superset/.superset:$PYTHONPATH \
    SUPERSET_VERSION=${SUPERSET_VERSION}

# Install dependencies & create superset user
RUN apt-get update && \
    apt-get install -y \
        build-essential \
        libsasl2-dev \
        libldap2-dev \
        mariadb-client \
        postgresql-client && \
    pip install \
        flask-mail==0.9.1 \
        flask-oauth==0.12 \
        flask_oauthlib==0.9.3 \
        impyla==0.14.0 \
        mysqlclient==1.3.7 \
        psycopg2==2.6.1 \
        pyhive==0.2.1 \
        pyldap==2.4.28 \
        redis==2.10.5 \
        sqlalchemy-redshift==0.5.0 \
        sqlalchemy-clickhouse==0.1.1.post3 \
        superset==$SUPERSET_VERSION && \
    useradd -b /home -U -m superset && \
    mkdir /home/superset/.superset && \
    touch /home/superset/.superset/superset.db && \
    chown -R superset:superset /home/superset

# Configure Filesysten
WORKDIR /home/superset
COPY superset .
VOLUME /home/superset/.superset

# Deploy application
EXPOSE 8088
HEALTHCHECK CMD ["curl", "-f", "http://localhost:8088/health"]
ENTRYPOINT ["superset"]
CMD ["runserver"]
USER superset

docker build & run

上記dockerfileのコピペだけではbuildできない。
以下サイトのリポジトリをcloneしてbuildする
https://github.com/amancevice/superset

git clone https://github.com/amancevice/superset.git

cd superset

docker build -t superset:0.18.5 .

docker run -p 80:8088 --name superset  superset:0.18.5

次に、databaseの初期化とadminユーザの設定を行う

docker exec -it superset superset-init

ブラウザでsupersetの画面にログイン

コンテナが正常起動したら、ブラウザで起動したサーバにアクセス。(port 80指定としたが、変更可能)

初期化時に設定したID/PWDでログインすればOK

スクリーンショット 2017-07-01 21.43.33.png

dashboard作成

dashboardを作るには以下の順番で行う必要あり

1) Sources/Databaseを登録
2) Tableを設定
3) Sliceを設定
4) Dashboardを作成

sliceはいわゆるグラフで、そのsliceをdashboardに貼り付けるイメージ。
そのsliceの入力元データのdbとtableを事前に設定する。

スクリーンショット 2017-07-01 21.51.17.png

以下がdatabase設定画面。
RDS(Postgresql)であれば、SQLAlchemy URIには
postgresql://[user]:[password]@[IP or Domain]:[port]/[dbname]
のフォーマットで規定する。ほとんどのDBには対応している模様。

スクリーンショット 2017-07-01 21.59.36.png

Sliceの種類が豊富で、GUIだけでビジュアライズが可能。
SQLを規定するSQL Labもある。

スクリーンショット 2017-07-01 21.53.50.png

スクリーンショット 2017-07-01 21.54.02.png

スクリーンショット 2017-07-01 21.54.13.png

スクリーンショット 2017-07-01 21.54.20.png

データのバックアップ

supersetのデータはSQLite3で管理され、dockerコンテナ内の
/home/superset/.superset/superset.db
に格納される。
Dockerfileでは、/home/superset/.superset をVOLUMEでマウントしており、ホスト側マウント先が未設定なので、dockerが勝手にマウント先を規定する。

例)
/var/lib/docker/volumes/[volume ID]/_data/

docker inspect コマンドで詳細は確認できる。

docker inspect 実行例

        "Mounts": [
            {
                "Name": "49313286a6f90d4dd5ad4d0222d7eb3a57d53f21f69a254ea56bbfb77517055b",
                "Source": "/var/lib/docker/volumes/49313286a6f90d4dd5ad4d0222d7eb3a57d53f21f69a254ea56bbfb77517055b/_data",
                "Destination": "/home/superset/.superset",
                "Driver": "local",
                "Mode": "",
                "RW": true,
                "Propagation": ""
            }
        ],

なお、任意でホストマウント先を指定しても良い。

VOLUME [コンテナ内部パス] [ホストマウント先パス]

その他

さすがにTableauほど多機能ではないにせよ、
現時点では、AWSのQuicksightより断然イケてる気がする。
オンプレなどクローズドな環境へも容易にインストールでき

続きを読む

AWSCLIを使用してアンマウントせずにEBSボリュームを変更する

目的

  • EBSボリュームを活性変更する

環境

  • aws-cli/1.11.111以上で使用可能

    • aws-cli/1.11.112 Python/2.7.13 Darwin/16.5.0 botocore/1.5.75

      • $ pip install --upgrade --user awscliでupdate
SYNOPSIS
            modify-volume
          [--dry-run | --no-dry-run]
          --volume-id <value>
          [--size <value>]
          [--volume-type <value>]
          [--iops <value>]
          [--cli-input-json <value>]
          [--generate-cli-skeleton <value>]

設定

  • 100GB => 150GBに変更
$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda1       99G   86G   14G  87% /
(snip)
$ aws ec2 modify-volume --volume-id <volume-id> --size 150 --volume-type gp2
  • 確認
$ lsblk
NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
xvda    202:0    0  150G  0 disk
└─xvda1 202:1    0  100G  0 part /
  • パーティション拡張
$ sudo growpart /dev/xvda 1
CHANGED: disk=/dev/xvda partition=1: start=4096 old: size=209711070,end=209715166 new: size=314568670,end=314572766
  • ファイルシステム拡張
$ sudo resize2fs /dev/xvda1
resize2fs 1.42.12 (29-Aug-2014)
Filesystem at /dev/xvda1 is mounted on /; on-line resizing required
old_desc_blocks = 7, new_desc_blocks = 10
The filesystem on /dev/xvda1 is now 39321083 (4k) blocks long.
  • 確認
$ lsblk
NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
xvda    202:0    0  150G  0 disk
└─xvda1 202:1    0  150G  0 part /
$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda1      148G   86G   63G  58% /
(snip)

所感

  • 50GBの増設で約50分ほど必要でした。1TBだと6時間くらいだそうです。
    そもそも、容量追加なんてのは要件として緊急性がないので、時間がかかっても平気ですけど、商用環境以外ならumountした方がいいですね。

続きを読む

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

オンプレにあるバックアップデータを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)

続きを読む