CentOS7上に構築したKubernetesでイメージのダウンロードに失敗する

CentOS7上に構築したKubernetesでイメージのダウンロードに失敗する

Kubernetesで遊ぼうとしてハマった。
まず、こちらの記事を参考にしつつ、AWS上にCentOS7のインスタンスを立ち上げてkubernetesの試験環境を構築した。
Kubernetesでクラスタ環境構築手順(1) – masterの作成 – Qiita

しかし、いざpodをデプロイしようとしたところContainerCreatingのまま進まず、以下のようなエラーが。

[centos@ip-172-20-1-31 ~]$ kubectl run nginx --image=nginx:1.11.3                                                                                                                                                                             
deployment "nginx" created
[centos@ip-172-20-1-31 ~]$ kubectl describe pod nginx                                                                                                                                                                                         
Name:           nginx-752720876-1cgfj
Namespace:      default
Node:           master/172.20.1.31
Start Time:     Mon, 11 Dec 2017 02:08:46 +0000
Labels:         pod-template-hash=752720876
                run=nginx
Status:         Pending
IP:
Controllers:    ReplicaSet/nginx-752720876
Containers:
  nginx:
    Container ID:
    Image:              nginx:1.11.3
    Image ID:
    Port:
    State:              Waiting
      Reason:           ContainerCreating
    Ready:              False
    Restart Count:      0
    Volume Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-kj7lz (ro)
    Environment Variables:      <none>
Conditions:
  Type          Status
  Initialized   True 
  Ready         False 
  PodScheduled  True 
Volumes:
  default-token-kj7lz:
    Type:       Secret (a volume populated by a Secret)
    SecretName: default-token-kj7lz
QoS Class:      BestEffort
Tolerations:    <none>
Events:
  FirstSeen     LastSeen        Count   From                    SubObjectPath   Type            Reason          Message
  ---------     --------        -----   ----                    -------------   --------        ------          -------
  6s            6s              1       {default-scheduler }                    Normal          Scheduled       Successfully assigned nginx-752720876-1cgfj to master
  6s            6s              1       {kubelet master}                        Warning         FailedSync      Error syncing pod, skipping: failed to "StartContainer" for "POD" with ErrImagePull: "image pull failed for registry.access.re
dhat.com/rhel7/pod-infrastructure:latest, this may be because there are no credentials on this request.  details: (open /etc/docker/certs.d/registry.access.redhat.com/redhat-ca.crt: no such file or directory)"

証明書/etc/docker/certs.d/registry.access.redhat.com/redhat-ca.crtが見つからないらしい。
これ自体はシンボリックリンクになっていて、リンク先が存在しない模様。

[centos@ip-172-20-1-252 ~]$ ls -al /etc/docker/certs.d/registry.access.redhat.com/
total 0
drwxr-xr-x. 2 root root 27 Dec 11 00:17 .
drwxr-xr-x. 5 root root 75 Dec 11 00:17 ..
lrwxrwxrwx. 1 root root 27 Dec 11 00:17 redhat-ca.crt -> /etc/rhsm/ca/redhat-uep.pem
[centos@ip-172-20-1-252 ~]$
[centos@ip-172-20-1-252 ~]$ ls /etc/ | grep rhsm
[centos@ip-172-20-1-252 ~]$

色々試してマスターノードにpython-rhsmをインストールして解決した。
証明書もインストールされて、イメージもダウンロードできるようになった。

$ sudo yum install python-rhsm

参考:https://access.redhat.com/ja/node/1379303
(python-rhsmを再インストールするとroot証明書を再インストールできるとの記載。そもそもこのパッケージ入ってなかった)

個人的に遊んでるだけなので、証明書の検証はスキップしても構わないのだけど、insecure的な設定をどこからできるのかがわからなかった。

これでやっとKubernetes触れる。。

続きを読む

TerraformでAWS AMIの最新を常に使うようにする

TerraformとAWSに同時入門する
の続きで、

最新のAMIが常に指定されるようなami設定にする

を行えるようにします。

確認環境

$ terraform version
Terraform v0.11.1
+ provider.aws v1.5.0

取得するAMIのスペック

今回は2017/12/10時点でのAmazon Linuxの下記スペックにおける最新AMI ID(ami-da9e2cbc)を取得します。
最新AMI IDはこちらで確認できます: Amazon Linux AMI ID

  • リージョン: アジアパシフィック東京
  • 仮想化タイプ: HVM
  • ルートデバイスタイプ: EBS-Backed
  • アーキテクチャ: x86_64
  • ボリュームタイプ: gp2

:warning: 注意点
AMI IDはリージョン毎に異なるようなので複数リージョンにまたがった環境の場合は注意が必要かもしれません

結論

簡易版

フィルタ条件はAMI Image名の条件のみ

aws_ami.tf
data "aws_ami" "amazon_linux" {
  most_recent = true
  owners = ["amazon"]

  filter {
    name   = "name"
    values = ["amzn-ami-hvm-*-x86_64-gp2"]
  }
}

詳細版

フィルタ条件として今回の指定スペックをすべて指定

参考: Terraformでもいつでも最新AMIからEC2を起動したい

aws_ami.tf
data "aws_ami" "amazon_linux" {
  most_recent = true
  owners = ["amazon"]

  filter {
    name   = "architecture"
    values = ["x86_64"]
  }

  filter {
    name   = "root-device-type"
    values = ["ebs"]
  }

  filter {
    name   = "name"
    values = ["amzn-ami-hvm-*"]
  }

  filter {
    name   = "virtualization-type"
    values = ["hvm"]
  }

  filter {
    name   = "block-device-mapping.volume-type"
    values = ["gp2"]
  }
}

EC2側の設定

ec2.tf
resource "aws_instance" "web-server" {
  ami                    = "${data.aws_ami.amazon_linux.id}"
  instance_type          = "t2.micro"
}

確認

$ terraform plan

  + aws_instance.web-server
      id:                           <computed>
      ami:                          "ami-da9e2cbc"
      ...

AWS CLIでAmazon Linux AMI image名を取得してみる

準備

AWS Command Line Interface のインストール

簡易版のフィルタ条件の説明

AWS CLIで最新のAmazon LinuxのAMI IDを取得する
上記でのシェルを参考に今回取得したい条件に変更します

get-aws-ec2-image.sh.sh
...

describe_images(){
    echo $timestamp > $timestamp_file
    aws ec2 describe-images 
-       --owners self amazon 
+       --owners amazon 
        --filters 
+         Name=name,Values="amzn-ami-hvm-*" 
          Name=virtualization-type,Values=hvm 
          Name=root-device-type,Values=ebs 
          Name=architecture,Values=x86_64 
-         Name=block-device-mapping.volume-type,Values=standard
+         Name=block-device-mapping.volume-type,Values=gp2
}

...

実行結果

$ zsh ./get-aws-ec2-image.sh

amzn-ami-hvm-2014.03.2.x86_64-gp2: ami-df470ede
amzn-ami-hvm-2014.09.0.x86_64-gp2: ami-45072844
amzn-ami-hvm-2014.09.1.x86_64-gp2: ami-4585b044
amzn-ami-hvm-2014.09.2.x86_64-gp2: ami-1e86981f
amzn-ami-hvm-2015.03.0.x86_64-gp2: ami-cbf90ecb
amzn-ami-hvm-2015.03.1.x86_64-gp2: ami-1c1b9f1c
amzn-ami-hvm-2015.09.0.x86_64-gp2: ami-9a2fb89a
amzn-ami-hvm-2015.09.1.x86_64-gp2: ami-383c1956
amzn-ami-hvm-2015.09.2.x86_64-gp2: ami-59bdb937
amzn-ami-hvm-2016.03.0.x86_64-gp2: ami-f80e0596
amzn-ami-hvm-2016.03.1.x86_64-gp2: ami-29160d47
amzn-ami-hvm-2016.03.2.x86_64-gp2: ami-6154bb00
amzn-ami-hvm-2016.03.3.x86_64-gp2: ami-374db956
amzn-ami-hvm-2016.09.0.20160923-x86_64-gp2: ami-1a15c77b
amzn-ami-hvm-2016.09.0.20161028-x86_64-gp2: ami-0c11b26d
amzn-ami-hvm-2016.09.1.20161221-x86_64-gp2: ami-9f0c67f8
amzn-ami-hvm-2016.09.1.20170119-x86_64-gp2: ami-56d4ad31
amzn-ami-hvm-2017.03.0.20170401-x86_64-gp2: ami-859bbfe2
amzn-ami-hvm-2017.03.0.20170417-x86_64-gp2: ami-923d12f5
amzn-ami-hvm-2017.03.1.20170617-x86_64-gp2: ami-bbf2f9dc
amzn-ami-hvm-2017.03.1.20170623-x86_64-gp2: ami-3bd3c45c
amzn-ami-hvm-2017.03.1.20170812-x86_64-gp2: ami-4af5022c
amzn-ami-hvm-2017.03.rc-0.20170320-x86_64-gp2: ami-be154bd9
amzn-ami-hvm-2017.03.rc-1.20170327-x86_64-gp2: ami-10207a77
amzn-ami-hvm-2017.09.0.20170930-x86_64-gp2: ami-2a69be4c
amzn-ami-hvm-2017.09.1.20171103-x86_64-gp2: ami-2803ac4e
amzn-ami-hvm-2017.09.1.20171120-x86_64-gp2: ami-da9e2cbc
amzn-ami-hvm-2017.09.rc-0.20170913-x86_64-gp2: ami-d424e7b2

最新AMI ID(ami-da9e2cbc)が取得できているのがわかります。

amzn-ami-hvm-2017.09.1.20171120-x86_64-gp2: ami-da9e2cbc

取得結果からわかるようにImage名にはスペック名も含まれていることがわかります。

よって今回のスペックのAMI IDはImage名でのフィルタ条件のみで取ることができるため、簡易版ではImage名の値が"amzn-ami-hvm-*-x86_64-gp2"とするフィルタ条件1つで最新のAMI IDを取得していました。

また、aws_ami.tfではmost_recent = trueという設定により取得した中で最新のAMI IDが取得されます。

:warning: Image名の命名規則が変更された場合に指定スペックの最新が取得できなくなるので注意ください

フィルタ条件をnameのみにしてAWS CLIでも確認

AWS CLI側でも一応確認

get-aws-ec2-image.sh
describe_images(){
    echo $timestamp > $timestamp_file
    aws ec2 describe-images 
        --owners amazon 
        --filters 
          Name=name,Values="amzn-ami-hvm-*-x86_64-gp2" 
-          Name=virtualization-type,Values=hvm 
-          Name=root-device-type,Values=ebs 
-          Name=architecture,Values=x86_64 
-          Name=block-device-mapping.volume-type,Values=gp2
}
$ zsh ./get-aws-ec2-image.sh | grep ami-da9e2cbc

amzn-ami-hvm-2017.09.1.20171120-x86_64-gp2: ami-da9e2cbc

最新AMI ID(ami-da9e2cbc)が取得できているのがわかります。

その他の参考

続きを読む

upgrade amazon aws from Micro to Medium

さらに表示: aws add volume to running instance, ec2 change instance type while running, migrate ec2 instance to another region, aws resize ebs volume, aws change instance type greyed out, any data on the ephemeral storage of your instances will be lost., aws expand root volume windows, resize … 続きを読む

TerraformでAWS環境の構築する時に良く使う書き方

AWSを使う設定

provider.tf
provider "aws" {}

AWSのregionとaccount idを取得する

data.tf
data "aws_region" "current" {
  current = true
}

data "aws_caller_identity" "current" {}

regionの取得

data.aws_region.current.name

account idの取得

data.aws_caller_identity.current.account_id

アプリ名を変数にしておく

variable.tf
variable "kptboard" {
  default = "kptboard"
}

変数にして、基本的に名前を設定する部分はその変数を使うことでkptboard-stg,kptboard-prodのように書き換えるだけで他の環境を作りやすくなる。

aws_ecs_cluster.tf
resource "aws_ecs_cluster" "kptboard" {
  name = "${var.kptboard}"
}

最新のEC2のAMIを使うようにする

aws_instance.tf
data "aws_ami" "ecs_optimized" {
  most_recent = true
  owners      = ["amazon"]

  filter {
    name   = "architecture"
    values = ["x86_64"]
  }

  filter {
    name   = "root-device-type"
    values = ["ebs"]
  }

  filter {
    name   = "name"
    values = ["amzn-ami-*-amazon-ecs-optimized"]
  }

  filter {
    name   = "virtualization-type"
    values = ["hvm"]
  }

  filter {
    name   = "block-device-mapping.volume-type"
    values = ["gp2"]
  }
}

resource "aws_instance" "kptboard" {
  ami = "${data.aws_ami.ecs_optimized.id}"
  instance_type = "${var.aws_instance_kptboard_instance_type}"
  iam_instance_profile = "${aws_iam_instance_profile.kptboard_ec2.name}"
  vpc_security_group_ids = ["${aws_security_group.kptboard_ec2.id}"]
  user_data       = "${data.template_file.aws_instance_kptboard_user_data.rendered}"
  key_name        = "${var.aws_instance_kptboard_key_name}"
  subnet_id       = "${aws_subnet.kptboard_public_a.id}"
  associate_public_ip_address = true
  tags {
    Name = "${var.kptboard}"
  }
}

自動的に最新のECS-optimized AMIが取得できる

IAMのポリシーを別ファイルでjsonのテンプレートに切り出す

kptboard_ssm_policy.json.tpl
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ssm:GetParameters"
      ],
      "Resource": "arn:aws:ssm:${region}:${account_id}:parameter/${kptboard}.*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "kms:Decrypt"
      ],
      "Resource": "arn:aws:kms:us-east-1:${account_id}:key/alias/aws/ssm"
    }
  ]
}

aws_iam_policy.tf
data "template_file" "kptboard_ssm_policy" {
  template = "${file("policies/kptboard_ssm_policy.json.tpl")}"

  vars {
    account_id = "${data.aws_caller_identity.current.account_id}"
    region = "${data.aws_region.current.name}"
    kptboard = "${var.kptboard}"
  }
}

resource "aws_iam_policy" "kptboard_ssm" {
  name = "${var.kptboard}-ssm"
  policy = "${data.template_file.kptboard_ssm_policy.rendered}"
}

と書くことでIAM Policyのjsonを別ファイルとして切り離せる

一時的にECRリポジトリを作らない

variable.tf
variable "aws_ecr_repository_create" {
  default = "true"
}
aws_ecr_repository.tf
resource "aws_ecr_repository" "kptboard" {
  count = "${var.aws_ecr_repository_create ? 1 : 0}"
  name = "${var.kptboard}"
}

リポジトリ以外の部分をterraform destroyしてterraform applyした時に構築できるかを確認するのに、ECRリポジトリが消えてしまうとDocker Imageを再アップロードしないといけなくなって手間になる。
countを0にすることで実行されないで済む。

サンプル

kptboardというrailsアプリケーションをECSで動かす用のterrafromのソースを置きました。

https://github.com/f96q/fastladder-terraform

続きを読む

AWS EC2の容量(EBS)を増やす

EC2の容量を増やしたいときの手順メモ

AWSコンソールで操作

  1. ELASTIC BLOCK STORE
  2. Volumes
  3. 対象のボリュームを選択
  4. Actions
  5. Modify Volume
  6. 容量を指定

ステータスがin-use - completed (100%)になるまで待機

sshでつないで作業

growpartresize2fs を組み合わせてサイズを拡張する

# rootになる
sudo -s

# 現在の容量を確認
# このときにラベル(?)を確認しておく(/dev/xvdaみたいなやつ)
df -h

# 一応こっちも見ておくとよい
lsblk

# 一応こっちも見ておくとよい
fdisk -l

# dry runで確認
growpart  --dry-run /dev/xvda 1

# 問題なければ実行
growpart /dev/xvda 1

# パーティションサイズを拡張
resize2fs /dev/xvda1

# 反映できたか確認
df -h

growpartで指定するのはディスク名なので/dev/xvda1のようにパーティション名を指定してしまうとうまくいかないので注意

# ×これはうまくいかない
growpart  --dry-run /dev/xvda1 1

続きを読む

【AWS】EC2のディスクI/Oを確認する【EBS】

はじめに

ITシステムを開発していく中で、システムのパフォーマンスが問題になるケースは多々あると思います。
PoC、開発、負荷試験、本番運用のいずれのフェイズであってもこのような課題は発生し、そのたびにボトルネックの分析と解決は必要になります。

大体において最初は原因がつかめないため、サーバであればCPU利用率、メモリ利用量、ネットワーク帯域、ディスクI/Oなど、およそ考えられうる個所を一通りチェックする必要があります。

AWSのEC2を利用している場合、単純に「念のためEC2のディスクI/Oも確認しといて」と指示しただけでは、十中八九、「EC2のディスクI/Oの値が取れてないんですが」と返ってきます。

毎回口頭で説明するのも効率が悪いので、「これ読んどいて」で済ませるためにこの記事を書きました。

TL;DR

  • 殆どの環境において、EC2のディスクとしてEBSが使われている
  • CloudWatchにおいて、EBSはEBSとしてのメトリクスが記録される。EC2のメトリクスには含まれない
  • ※重要:「[AWSマイスターシリーズ] Instance Store & Elastic Block Store」1はとても良くまとまっているのでちゃんと読もう

EC2で利用できるディスク

EC2ではローカルディスク領域として以下の2種類のものが利用できます。

  • Ephemeral Volume
  • EBS(Elastic Block Store)

EC2リリース当初はEphemeral Volumeしか利用できなかったのですが、その後EBSが利用できるようになりました。
そしてEBSがルートボリューム(つまり「/」)として利用できるようになり、現在ではEphemeral Volumeは限られた用途でしか使われなくなりました。

Ephemeral Volume

一部のインスタンスサイズでのみ利用できる領域です。
AWS公式ドキュメントでは、“Instance Store”(インスタンスストア)とも呼ばれることもあります。

仮想サーバであるEC2が稼働している物理サーバの、ローカルディスクの一部を間借りするようなイメージです。
EC2インスタンスを停止するとデータは消えます。
詳細は「[AWSマイスターシリーズ] Instance Store & Elastic Block Store」1に詳しいです。

これを利用するためには以下の条件を満たす必要があります。

  • InstanceのLaunch時に、Instance Storageが利用できるものを選択する
  • “Step 4: Add Storage”の際に、明示的に”Instance Store”を追加する

具体的な画面イメージは下記の通りです。

Step 2: Choose Instance Typeにて、「Instance Storage」に「? x ?? (SSD)」と表示されているものを選択します。
2017-11-27_01h58_29.png

Step 4: Add Storageにて、「Add New Volume」を押してパーティションを追加した後、「Instance Store 0」を選択します。
2017-11-26_22h47_14.png

EBS(Elastic Block Store)

通常、デフォルトで利用される領域です。

詳細は末尾のリンクにある「[AWSマイスターシリーズ] Instance Store & Elastic Block Store」に詳しいです。
本稿では詳細は割愛します。

CloudWatchから確認する

CloudWatchのメトリクス上、Ephemeral VolumeはEC2のメトリクスの一部として記録されますが、EBSはEC2とは別のNamespaceで記録されます。
それぞれ下記から参照することができます。

  • Ephemeral Volume:

    • EC2->Per-Instance Metrics
  • EBS:
    • EBS->Per-Volume Metrics

両方のディスク領域に負荷をかけ、どちらのメトリクスに変化が表れるか確認していきます。

検証した環境

Instance Size: m3.medium
OS: Amazon Linux AMI 2017.09

dfとmountの実行結果は下記の通りです。

dfコマンド
$ df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        1.9G   60K  1.9G   1% /dev
tmpfs           1.9G     0  1.9G   0% /dev/shm
/dev/xvda1      7.8G 1021M  6.7G  14% /
/dev/xvdb       3.9G  8.1M  3.7G   1% /media/ephemeral0
mountコマンド
$ mount
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
devtmpfs on /dev type devtmpfs (rw,relatime,size=1918920k,nr_inodes=479730,mode=755)
devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /dev/shm type tmpfs (rw,relatime)
/dev/xvda1 on / type ext4 (rw,noatime,data=ordered)
devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620,ptmxmode=000)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime)
/dev/xvdb on /media/ephemeral0 type ext3 (rw,relatime,data=ordered)

事前準備

以下の2つの作業を実施します。

  • Bonnie++をインストールする
  • メモリ消費スクリプトを作成する

今回は、ディスクに負荷をかけるためにBonnie++を利用します。
操作するディスク容量に対して空きメモリ容量が大きいと、キャッシュが利用されてしまい、ディスクに最大負荷をかけることができません。

通常、物理メモリの2倍の容量のファイルに対して操作を行う必要がありますが、Ephemeral Volumeでは小さすぎます。
# m3.mediumの物理メモリは4GB、Ephemeral Volumeも4GBです。

そこで今回は、強制的にメモリを消費した状態でBonnie++を実行させます。
メモリ消費スクリプトは下記に載せておきました。

https://qiita.com/tmiki/items/314103598ba192c26528

上記スクリプトを実行し、メモリを大量に消費している状態にしておきます。
freeコマンド、/proc/meminfo等から確認しておきましょう

freeコマンド例
$ free
             total       used       free     shared    buffers     cached
Mem:       3855812    3361812     494000         60       9196      98832
-/+ buffers/cache:    3253784     602028
Swap:            0          0          0

Ephemeral VolumeのディスクI/Oを確認

Bonnie++の実行(Ephemeral Volume)

以下のコマンドでEphemeral Volumeに負荷をかけます。
ローカルのSSDはパフォーマンスが良く、すぐに終わってしまうので、10回連続で実行することにします。

bonnie++
# bonnie++ -u root -d /media/ephemeral0 -r 1536

CloudWatchメトリクスの確認(Ephemeral Volume)

以下の操作で、Ephemeral VolumeのディスクI/Oを確認することができます。2

  • AWS Management ConesoleからCloudWatchを開く。
  • 「Metrics」→「EC2」→「Per-Instance Mertrics」をたどり、対象のInstanceIdでフィルタをかける。
  • 以下の4つの項目をにチェックを入れ、グラフを表示させる。なお、*Opsは左軸、*Bytesは右軸に表示させると見やすい。
    • DiskReadOps
    • DiskWriteOps
    • DiskReadBytes
    • DiskWriteBytes

2017-11-27_01h33_57.png

EBSのディスクI/Oを確認する

Bonnie++の実行(EBS)

以下のコマンドでEphemeral Volumeに負荷をかけます。
これも10回連続で実行することにします。
今回検証した構成ではそれほどパフォーマンスが良くないので、しばらく時間がかかると思います。

bonnie++
# bonnie++ -u root -d / -r 1536

EBS ID(EBS Volume ID)を確認する

まず、対象のEBSのEBS IDを調べます。
この例では、EC2にアタッチしているEBSは1つであり、またこれがルートデバイスとなっています。

  • AWS Management ConesoleからECを開く
  • 「Instances」から、対象のEC2インスタンスを選択する
  • 「Root device」のリンクをクリックし、ポップアップを表示させる
  • EBS ID(vol-?????????????????)が確認できる

2017-11-26_22h56_54.png

CloudWatchメトリクスの確認(EBS)

EBS IDを確認したら、CloudWatchメトリクスから確認できます。3
ここでは取り急ぎ主要な項目のみ確認します。

  • AWS Management ConesoleからCloudWatchを開く。
  • 「Metrics」→「EBS」→「Per-Volume Mertrics」をたどり、上記で確認したEBS IDでフィルタをかける。
  • 以下の4つの項目をにチェックを入れ、グラフを表示させる。なお、*Opsは左軸、*Bytesは右軸に表示させると見やすい。
    • VolumeReadOps
    • VolumeWriteOps
    • VolumeReadBytes
    • VolumeWriteBytes

2017-11-27_01h34_04.png

まとめ

Ephemeral VolumeおよびEBSに負荷をかけた時間帯と、CloudWatchメトリクスで確認できるグラフの時間帯が一致していることが確認できたかと思います。
殆どのケースではEC2のローカルディスクとしてEBSを利用していると思います。
CloudWatchメトリクスを確認する際は、間違えないように気をつけましょう。

参考URL

続きを読む

Cloudera QuickStart VMs (Docker)をAWS上で動かす

はじめに

Cloudera QuickStart VMs を触ってみます。

前提条件

環境:t2.xlargeのEC2インスタンス(EIP設定済み)
OS:Amazon Linux

$ uname -a
Linux ip-hoge-hoge-hoge-hoge 4.9.58-18.51.amzn1.x86_64 #1 SMP Tue Oct 24 22:44:07 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

インスタンス初期設定

まずは以下のように初期設定を行っておきます。

# yum update
$ sudo yum update

# タイムゾーン設定(UTC -> JST)
$ sudo mv /etc/localtime /etc/localtime.org
$ sudo ln -s  /usr/share/zoneinfo/Asia/Tokyo /etc/localtime

Docker インストール

Dockerをインストールします。

# dockerインストール&サービス起動
$ sudo yum install -y docker
$ sudo service docker start

# dockerグループにec2-userを追加
$ sudo usermod -a -G docker ec2-user
$ cat /etc/group |grep docker
docker:x:497:ec2-user

ログアウト & 再度ログイン

$ docker info
Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 0
Server Version: 17.03.2-ce
Storage Driver: overlay2
 Backing Filesystem: extfs
 Supports d_type: true
 Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host macvlan null overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 4ab9917febca54791c5f071a9d1f404867857fcc
runc version: 54296cf40ad8143b62dbcaa1d90e520a2136ddfe
init version: 949e6fa
Security Options:
 seccomp
  Profile: default
Kernel Version: 4.9.51-10.52.amzn1.x86_64
Operating System: Amazon Linux AMI 2017.09
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 15.67 GiB
Name: ip-hoge-hoge-hoge-hoge
ID: 4AKT:BX72:LWYE:7KFY:ZWX2:TW2I:374J:C7XP:D6QZ:QYHO:RSAC:TKEB
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

Cloudera Quick Start Docker Image取り込み

以下のドキュメントを参考にDocker Imageを取り込みます。
https://www.cloudera.com/documentation/enterprise/5-6-x/topics/quickstart_docker_container.html

イメージはあらかじめcloudera.comからダウンロードしたものをEC2インスタンスへアップロードしておきます。
※「Downloads > QuickStart VMs > Docker Image」からダウンロード

# Cloudera Quick Start Dockerイメージ展開
$ tar xzf cloudera-quickstart-vm-*-docker.tar.gz

# Dockerイメージ取り込み
$ docker import - cloudera/quickstart:latest < cloudera-quickstart-vm-*-docker/*.tar

Cloudera Quick Start 起動

Cloudera Quick Startを起動します。

# 起動
$ docker run --hostname=quickstart.cloudera --privileged=true -t -i -d -p 7180:7180 -p 80:80 -p 8888:8888 -p 3306:3306 -p 10000:10000 cloudera/quickstart:latest /usr/bin/docker-quickstart

# コンテナ情報を調べる
$ docker ps
CONTAINER ID        IMAGE                        COMMAND                  CREATED             STATUS              PORTS                                                                                                                  NAMES
4ad6c4325d1c        cloudera/quickstart:latest   "/usr/bin/docker-q..."   8 seconds ago       Up 8 seconds        0.0.0.0:80->80/tcp, 0.0.0.0:3306->3306/tcp, 0.0.0.0:7180->7180/tcp, 0.0.0.0:8888->8888/tcp, 0.0.0.0:10000->10000/tcp   agitated_albattani

コンテナ情報から、コンテナ側のポートがホスト側のポートにマップされたことが分かります。

ポート 利用対象
80 QuickStart VM ガイドページ
3306 MySQL
7180 Cloudera Manager
8888 Hue
10000 Hive

以下でQuickStart VMのガイドページが表示されます。
http://[EC2インスタンスのEIP]
image

Cloudera Manager 起動

Cloudera Managerはデフォルトでは起動しないそうなので、下記の通り起動させます。
注意点として、ntpサービスが動いていないとステータス画面でエラーが出るので、事前に起動させておきます。

# コンソールにログイン
$ docker attach fb4d3b01b00b

# nptサービスが動いていないので、事前に動かす
$ service ntpd start

# Cloudera Managerを起動 (起動には時間が掛かります)
$ /home/cloudera/cloudera-manager --enterprise
[QuickStart] Shutting down CDH services via init scripts...
()
Success! You can now log into Cloudera Manager from the QuickStart VM's browser:

    http://quickstart.cloudera:7180

    Username: cloudera
    Password: cloudera

# コンソールから抜けるときはCtrl+P⇒Ctrl+Q

無事に起動したら、先ほどdocker psでみた情報を元にマッピングされたポートにアクセスします。
http://[EC2インスタンスのEIP]:7180

情報保証ポリシーに同意します。
Cloudera Manager Agreement

先程のUsername/Passwordであるcloudera/clouderaでログイン
Cloudera Manager Login

ホーム画面が表示されました。
Cloudera Manager Home

ステータスにある通り、Hueも起動しているのでログインしてみます。
http://[EC2インスタンスのEIP]:8888
image

あとはHueからテーブルを作成したり、データを投入したりして試してみることができます。

参考

DockerでCloudera Managerを立ち上げる

CDH5版Hiveのインストール手順

AWSのEC2でDockerを試してみる

続きを読む

AWS EC2のCentOSをPVからHVMへ移行する

(2年前の下書きを発見したので、時期を外していると思いつつ投稿します)
この記事では、昔から使われていたParaVirtualのEC2インスタンスをHVM対応とし、旧タイプのインスタンスから脱出するための手法を記します。
特に t1.micro で CPU steal に悩んでいる方は早めに t2.micro への移行をおすすめします。CPUクレジットに注意する必要がありますが、早い(CPU/network/storage)安い/うまい(メモリ1GB)と使わない理由がありません。
何度か作業をし、出来るだけ手順化をしてみたのでみなさんと共有します。
可能な限りコマンドライン一撃で終了できるようにしています。

先人の知恵

http://qiita.com/cs_sonar/items/21dbb3462708e146a426
実際の作業手順は上記のエントリーそのままですが、出来るだけsedなどのコマンドを利用しコピペで片付くような手順になっています。

作業用インスタンスを準備する

t2.micro/Amazon Linux(CentOSなどでも問題ないでしょう)でEC2を起動します。
このインスタンスIDが i-IIIIIIII として進めます。

EBSを準備する

作業用のインスタンスにアタッチするためのEBSが必要になります。
必要なEBSは二種類です。

出力先となるEBSを準備する

以下の例では作業の安定性を考慮してio1/PIOPS1000/100GBのEBSを準備します。
移行元のEBSのサイズより大きなものにしましょう。(でないと収まらない)

aws ec2 create-volume --size 100 --availability-zone ap-northeast-1a --volume-type io1 --iops 1000

ここで作成されたEBSボリュームIDを vol-DDDDDDDD として次に進みます。

出力先EBSをアタッチする

aws ec2 attach-volume --instance-id i-IIIIIIII --device /dev/sdo --volume-id vol-DDDDDDDD

元となるEBSを準備する

元となるEBSですが、以下の順序で作成します。
以下の例では作業の安定性を考慮してio1/PIOPS1000/100GBのEBSを準備します。
– 移行元のEBSからスナップショットを作成します。
– 作成したスナップショットから作業用EBSを作成します。

aws ec2 create-snapshot --volume-id vol-OOOOOOOO

ここで作成されたスナップショットのIDを snap-OOOOOOOO として次に進みます。

aws ec2 create-volume --size 100 --availability-zone ap-northeast-1a --volume-type io1 --iops 1000 --snapshot-id snap-OOOOOOOO

作成されたEBSボリュームIDを vol-SSSSSSSS として次に進みます

元となるEBSをアタッチする

aws ec2 attach-volume --instance-id i-IIIIIIII --device /dev/sdm --volume-id vol-SSSSSSSS

作業用インスタンスでの作業

作業用インスタンスには以下の状態でEBSがマウントされている(はず)です。

デバイス名 利用用途
/dev/xvdm 移行元EBS
/dev/xvdo 移行先EBS

移行先データ用EBSを準備する

yum -y install parted resize2fs
parted /dev/xvdo --script 'mklabel msdos mkpart primary 1M -1s print quit'
partprobe /dev/xvdo
udevadm settle

移行元データの検査とディスクサイズの(見かけ上の)縮小

e2fsck -f /dev/xvdm
resize2fs -M /dev/xvdm

移行元EBSから移行先EBSへのデータ移設と縮小したディスクサイズの復元

dd if=/dev/xvdm of=/dev/xvdo1 bs=4K count=1747941
resize2fs /dev/xvdo1

移行先EBSのマウントとchrootによる作業準備

mount /dev/xvdo1 /mnt
cp -a /dev/xvdo /dev/xvdo1 /mnt/dev/
chroot /mnt

grub導入と設定の調整

yum install -y grub
ln -s /boot/grub/menu.lst /boot/grub/grub.conf
ln -s /boot/grub/grub.conf /etc/grub.conf
rm -f /boot/grub/*stage*
cp /usr/*/grub/*/*stage* /boot/grub/
rm -f /boot/grub/device.map
cat <<EOF | grub --batch
device (hd0) /dev/xvdo
root (hd0,0)
setup (hd0)
EOF

menu.lstの調整

menu.lstでの root kernel を調整します。
– (hd0)ではなく(hd0,0)とする必要があります。
– デバイス名ではなくラベル名でrootを認識させます。
– シリアルコンソールとHVM対応を明示します。

sed -i.bak -e 's:root(.*)(hd0):root1(hd0,0):;s:root=.*:root=LABEL=/ console=ttyS0 xen_pv_hvm=enable:' /boot/grub/menu.lst 

以下のような形になっているか確認して下さい。 root kernel あたりが要確認項目です。

default=0
timeout=0
hiddenmenu
title SUZ-LAB CentOS 6
root (hd0,0)
kernel /boot/vmlinuz-2.6.32-431.1.2.0.1.el6.x86_64 ro root=LABEL=/ console=ttyS0 xen_pv_hvm=enable
initrd /boot/initramfs-2.6.32-431.1.2.0.1.el6.x86_64.img

fstabの調整

fstabでのroot(/)をラベルで認識するように変更します。

sed -i.bak -e 's:.*(s)/s(.*)defaults(.*):LABEL=/1/2defaults,noatime3:g' /etc/fstab 

以下のような形になっているか確認して下さい。 LABEL=/ / あたりが要確認項目です。

LABEL=/ /        ext4    defaults,noatime        1 1
none             /proc     proc    defaults        0 0
none             /sys      sysfs   defaults        0 0
none             /dev/pts  devpts  gid=5,mode=620  0 0
none             /dev/shm  tmpfs   defaults        0 0
/mnt/swap/0.img  swap      swap    defaults        0 0

ディスクラベルの調整

e2label /dev/xvdo1 /
tune2fs -l /dev/xvdo1 |grep name

chrootを退出して後片付け

chroot状態から元のOSへ戻ります。

exit

一時的に必要とされたデバイス関連ファイルを削除し、マウントを解除します。

rm -f /mnt/dev/xvdo /mnt/dev/xvdo1
sync
umount /mnt

AMIの作成

AMI作成のもととなるスナップショットを作成する

aws ec2 create-snapshot --volume-id vol-b7f1e741

作成したスナップショットからAMIを作成する

続きを読む