0.初めに

0.1.自分について

　オンプレミスのシステム開発を6年実施。
　クラウドは一切経験なし。(ネスぺ、セキスぺ資格は数年前に取得。)
　今回、AWS認定資格(SAA)に合格したので、来年、時間があれば
　上位資格(SAS)を受けたい。これは、その時の参考にするための備忘録+日記的なもの。
　

1.受験理由

1.1. AWS認定資格との出会い

2019年GW、運よく、1日働くだけで済んだので、何か勉強しようと思っていたところ、以下を発見。

昇給や昇進に役立つIT資格トップ20(2018)

=>ふむふむ。AWSの資格、人気ランクは低いが、良いかもしれない・・。

1.2. 受験の決め手

しかし、情けないことに、仕事でAWSを使ったことがない。
勤務先で扱うのは、オンプレミスのサーバのみ。
どう勉強するか、ググっていたところ、これを見つけた。

AWS Innovate:試験対策「ソリューションアーキテクト-アソシエイト」

=>気になったのは、このフレーズ。
「〜普段有償のトレーニングコースを期間限定で無償公開〜」
よし、受けるしかない。

2.勉強

2.1 AWS Innovate(約2-3時間)

【目的】
基礎知識の取得。(AWSとは何か。試験範囲、各サービスの概要を知る。)

【やったこと】
AWS Innovateに登録し、以下のセッションを見た。
※資料をダウンロードできるので、キチンと見ながら聞くこと。

• AWS イントロダクション(イベントの趣旨を把握するため)
• AWSome Day(AWSとは何か、を学ぶため)
• AWS 認定 - 試験対策(SAA)(これがメイン)

2.2 サンプル問題(約0.5時間)

【目的】
どんな問題が出るか。何を勉強すれば良いかを抑える。

【やったこと】
以下ページの「サンプル問題のダウンロード」で、問題を取得して挑戦。

AWS 認定ソリューションアーキテクト – アソシエイト試験について

何を勉強する必要があるか、とりあえずイメージを構築する。
※上記ページ内の「試験ガイドのダウンロード」も必須。
　どの分野が何％出てくるか、書かれている。

2.3 学習1:サービスの把握(約3-4時間)

【目的】
各サービスの詳細と、関係性を学ぶ。

【やったこと】
サービスの説明を読み込む。
例えば、ストレージ関係の場合は、以下のリンク。

• efs
• S3 Glacier
• Storage Gateway

AWS Innovate、サンプル問題で出てきたサービスは、すべて読み込む。

大事なタブは「概要、特徴、料金タブ内、固有のタブ」。
例として、S3なら「ストレージクラス」タブ。
=>他の説明にないタブは、大事な気がする。

料金やパラメータの丸暗記は不要。
=>こちらの方が高性能・・とか安い・・とか、関係を覚える。

2.4 学習2:ユーザーガイドの把握(約3-4時間)

【目的】
実際の設定方法やベストプラクティスを知る。

【やったこと】
ユーザーガイドを読む。
例えば、EC2の場合は、以下のリンク。

• Amazon EC2 とは

大事な項目は「チュートリアル、ベストプラクティス」。
=>時間があるなら、他も読んだ方がよさげ。

2.5 模擬試験の実施(約0.5時間)

【目的】
合格ラインに達したか確認する。

【やったこと】
以下ページの「試験のスケジュールを立てる」から、模擬試験を受ける。

AWS 認定ソリューションアーキテクト – アソシエイト試験について

全問題、キャプチャを取得する。
=>後で復習するため。

点数が低い場合(確か正答率66%が合格ライン)なら、学習をやり直す。
=>私は運よく75%だったので、次に進んだ。
　ちなみに、合計点数は通知が来るが、
　各問題の正否や、どれが正解かは教えてくれない。つらい。
　

2.6 模擬試験の復習(約1-2時間)

【目的】
模擬試験で発覚した、足りない知識を埋める。

【やったこと】
模擬試験のキャプチャを見ながら、正しい回答を調べる。
AWS Innovate、サンプル問題で出てきてないサービスが
いきなり出てくることも多い。それらについては、追加で勉強する。
=>私は、この段階で以下サービスを勉強した。

• Kinesis
• AWS Direct Connect

3.受験

3.1 受験(2H)

試験会場によっては、当日申し込みも可能。受験後、すぐに結果が分かる。
=>なんとか合格した。
　そして数日後、詳細な結果が確認できるようになったので確認したところ・・

【結果】かなりギリギリ。おそらく、運が良かった。

あと2問くらい間違えたら落ちたのか。
参考書とか、買った方が良かったかな・・・

4.最後に

4.1 最後に

試験の費用、すごい高い・・。

• 模擬試験・・ 2000円 + 税
• 試験　　・・ 15000円 + 税

=>模擬試験で「絶対受かる！！」となるまで、受験を控えるべきかもしれない。
　我が社は資格手当が(もちろん受験費用の補助も)全く無いので辛い・・

以上。

AWSで本番環境にデプロイできない時の対処法（初心者向け）

前提

AWSを利用してwebサイトを公開し、開発したものをデプロイすると本番環境に反映されないことや、サイトが閲覧できない状態（We're sorry ~ ）になることがよくあるので、対処法を解説します。

開発環境

Ruby 2.3.1
Rails 5.2.2.1
AWS EC2（無料枠使用）
※一旦デプロイが完了し、自動デプロイの設定が完了している前提で解説します。
自動デプロイには、capistranoを使用しています。

対処法（１）　EC２のインスタンスを再起動

何度も自動デプロイを行なっていると、EC2側で変更が反映されず、場合によっては変更箇所が見れないことがあります。（ex.ユーザーログインの機能を実装したのに反映されていない等）
その場合、AWSのマネージメントコンソールから
EC2 →　インスタンス　→　該当のインスタンスをクリック　→　アクションのインスタンスの状態　→　再起動　を行います。
その後、再度ターミナルからEC2にログインし
sudo service nginx start　
sudo service mysqld start

のコマンドを実行し、WEBサーバのnginxとmysqlを立ち上げます。
その後、ローカルで自動デプロイのコマンドを実行すると、アプリケーションサーバのunicornが立ち上がり、サイト上に変更が反映され、閲覧できるようになります。

対処法（２） ローカルでエラーが起きていないか確認する

ローカルでは反映されないエラーが、本番ではエラーと認識されることがあります。
例えば、ECサイトを作成し商品一覧は問題なく表示されるが、商品の詳細画面にアクセスするとsyntaxエラー（hamlで記述している場合はインデント等）が起きている場合、本番ではエラーがあると認識されサイト全体が閲覧できないことがあります。
ローカルで確認し、エラーの箇所が分からなければ、サーバー側から

less log/production.log
less log/unicorn.log
　
のコマンドでログを確認し、エラーの箇所を特定します。
ここにsyntaxエラーやFATALと記載されている項目があれば、そのエラーを解消した上で再度デプロイします。
具体的な例としては、gemでfont-awesome-railsを使用していると、記述の方法によって、ローカルでエラーは出ないが本番ではエラーとなることがあり、このようなエラーはログを確認しなければ特定することは困難です。

対処法（３）　AWSの無料枠を確認する

直接的なエラーではありませんが、AWSの無料枠（メモリの容量等）を越えるとデプロイできなくなることがあります。
AWSの無料枠はあくまでお試しのような枠なので、同時に２つサイトを公開するとなると容量が足りなくなることがあり、その結果デプロイできないことや変更内容が反映されないことがあります。
また、gemもメモリに影響を与えるので、一度確認しておきましょう。
私の場合、無料枠を利用して２つ目のアプリケーションを公開し、gemのfont-awesome-sassを導入しようとしたら、ターミナルでメモリの容量が足りないというエラーが発生しました。font-awesome-sassを削除し、再度デプロイするとエラーが解消されました。

以上が初歩的な本番環境で発生するエラーの解消方法です。
他にも対処法は多くありますので、参考程度にして下さい。

はじめに

GKEと比べてEKSは環境を整えるのが面倒なのでTerraformで簡単に行えるようにしました。
すでに手動で作成したものがある人はTerraformingでリソースをtfファイルに変換して確認すると良いです。

ファイル作成

最終的にtreeは以下のようになります。

$ tree .
.
├── eks.tf
├── iam.tf
├── outputs.tf
├── variables.tf
└── vpc.tf

iam.tf

まずはIAMの設定です。
masterとnodeを分けてIAMを書いて、policyをアタッチします。

iam.tf

# ---
# EKS master
resource "aws_iam_role" "eks-master" {
  name = "eks-master-role"

  assume_role_policy = <<POLICY
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "eks.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
POLICY
}

resource "aws_iam_role_policy_attachment" "eks-cluster" {
  policy_arn = "arn:aws:iam::aws:policy/AmazonEKSClusterPolicy"
  role       = "${aws_iam_role.eks-master.name}"
}

resource "aws_iam_role_policy_attachment" "eks-service" {
  policy_arn = "arn:aws:iam::aws:policy/AmazonEKSServicePolicy"
  role       = "${aws_iam_role.eks-master.name}"
}

# ---
# EKS node
resource "aws_iam_role" "eks-node" {
  name = "eks-node-role"

  assume_role_policy = <<POLICY
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
POLICY
}

resource "aws_iam_role_policy_attachment" "eks-worker-node" {
  policy_arn = "arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy"
  role       = "${aws_iam_role.eks-node.name}"
}

resource "aws_iam_role_policy_attachment" "eks-cni" {
  policy_arn = "arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy"
  role       = "${aws_iam_role.eks-node.name}"
}

resource "aws_iam_role_policy_attachment" "ecr-ro" {
  policy_arn = "arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly"
  role       = "${aws_iam_role.eks-node.name}"
}

resource "aws_iam_instance_profile" "eks-node" {
  name = "eks-node-profile"
  role = "${aws_iam_role.eks-node.name}"
}

vpc.tf

EKSクラスタのためのVPCの設定を行います。ここまでは準備過程です。

大きく分けて次の5つを定義しています。
1. VPC
2. Subnet
3. Internet Gateway
4. Route Table
5. Security Group

vpc.tf

# ---
# VPC
resource "aws_vpc" "vpc" {
  cidr_block           = "${var.vpc_cidr_block}"
  enable_dns_hostnames = true
  enable_dns_support   = true
  instance_tenancy     = "default"
  tags                 = "${merge(local.default_tags, map("Name","eks-vpc"))}"
}

# ---
# Subnet
resource "aws_subnet" "sn" {
  count                   = "${var.num_subnets}"
  vpc_id                  = "${aws_vpc.vpc.id}"
  cidr_block              = "${cidrsubnet(var.vpc_cidr_block, 8, count.index)}"
  availability_zone       = "${element(data.aws_availability_zones.available.names, count.index % var.num_subnets)}"
  tags   = "${merge(local.default_tags, map("Name","eks-sn"))}"
}

# ---
# Internet Gateway
resource "aws_internet_gateway" "igw" {
  vpc_id = "${aws_vpc.vpc.id}"
  tags   = "${merge(local.default_tags, map("Name","eks-igw"))}"
}

# ---
# Route Table
resource "aws_route_table" "rt" {
  vpc_id = "${aws_vpc.vpc.id}"
  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = "${aws_internet_gateway.igw.id}"
  }
  tags = "${merge(local.default_tags, map("Name","eks-rt"))}"
}

resource "aws_route_table_association" "rta" {
  count          = "${var.num_subnets}"
  subnet_id      = "${element(aws_subnet.sn.*.id, count.index)}"
  route_table_id = "${aws_route_table.rt.id}"
}

# ---
# Security Group
resource "aws_security_group" "eks-master" {
  name        = "eks-master-sg"
  description = "EKS master security group"
  vpc_id = "${aws_vpc.vpc.id}"

  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = "${merge(local.default_tags, map("Name","eks-master-sg"))}"
}

resource "aws_security_group" "eks-node" {
  name        = "eks-node-sg"
  description = "EKS node security group"
  vpc_id = "${aws_vpc.vpc.id}"

  ingress {
    description     = "Allow cluster master to access cluster node"
    from_port       = 1025
    to_port         = 65535
    protocol        = "tcp"
    security_groups = ["${aws_security_group.eks-master.id}"]
  }

  ingress {
    description     = "Allow cluster master to access cluster node"
    from_port       = 443
    to_port         = 443
    protocol        = "tcp"
    security_groups = ["${aws_security_group.eks-master.id}"]
    self            = false
  }

  ingress {
    description = "Allow inter pods communication"
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    self        = true
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags   = "${merge(local.default_tags, map("Name","eks-node-sg"))}"
}

eks.tf

masterとnodeの設定です。
用いるインスタンスタイプ、イメージ、オートスケールパラメータ、などをここで定義します。

eks.tf

resource "aws_eks_cluster" "cluster" {
  name     = "${local.cluster_name}"
  role_arn = "${aws_iam_role.eks-master.arn}"
  version  = "${local.cluster_version}"

  vpc_config {
    security_group_ids = ["${aws_security_group.eks-master.id}"]
    subnet_ids = ["${aws_subnet.sn.*.id}"]
  }

  depends_on = [
    "aws_iam_role_policy_attachment.eks-cluster",
    "aws_iam_role_policy_attachment.eks-service",
  ]
}

locals {
  userdata = <<USERDATA
#!/bin/bash
set -o xtrace
/etc/eks/bootstrap.sh --apiserver-endpoint "${aws_eks_cluster.cluster.endpoint}" --b64-cluster-ca "${aws_eks_cluster.cluster.certificate_authority.0.data}" "${aws_eks_cluster.cluster.name}"
USERDATA
}

data "aws_ami" "eks-node" {
  most_recent = true
  owners      = ["602401143452"]

  filter {
    name   = "name"
    values = ["amazon-eks-node-${aws_eks_cluster.cluster.version}-v*"]
  }
}

resource "aws_launch_configuration" "lc" {
  associate_public_ip_address = true
  iam_instance_profile        = "${aws_iam_instance_profile.eks-node.id}"
  image_id                    = "${data.aws_ami.eks-node.image_id}"
  instance_type               = "${var.instance_type}"
  name_prefix                 = "eks-node"
  key_name                    = "${var.key_name}"

  root_block_device {
    volume_type = "gp2"
    volume_size = "50"
  }

  security_groups  = ["${aws_security_group.eks-node.id}"]
  user_data_base64 = "${base64encode(local.userdata)}"

  lifecycle {
    create_before_destroy = true
  }
}

resource "aws_autoscaling_group" "asg" {
  name                 = "EKS node autoscaling group"
  desired_capacity     = "${var.desired_capacity}"
  launch_configuration = "${aws_launch_configuration.lc.id}"
  max_size             = "${var.max_size}"
  min_size             = "${var.min_size}"
  vpc_zone_identifier = ["${aws_subnet.sn.*.id}"]

  tag {
    key                 = "Name"
    value               = "eks-asg"
    propagate_at_launch = true
  }

  tag {
    key                 = "kubernetes.io/cluster/${local.cluster_name}"
    value               = "owned"
    propagate_at_launch = true
  }
}

variables.tf

ここでは他のtfファイルで用いる変数を定義します。
基本的に編集はこのファイルに対してのみになることが理想です。
リージョンはap-northeast-1にしています。

variables.tf

provider "aws" {
  region = "ap-northeast-1"
}

data "aws_availability_zones" "available" {}

variable "project" {
  default = "eks"
}

variable "environment" {
  default = "dev"
}

variable "vpc_cidr_block" {
  default = "10.0.0.0/16"
}

variable "num_subnets" {
  default = 2
}

variable "instance_type" {
  default = "t2.small"
}

variable "desired_capacity" {
  default = 2
}

variable "max_size" {
  default = 2
}

variable "min_size" {
  default = 2
}

variable "key_name" {
  default = "KEY"
}

locals {
  base_tags = {
    Project     = "${var.project}"
    Terraform   = "true"
    Environment = "${var.environment}"
  }

  default_tags    = "${merge(local.base_tags, map("kubernetes.io/cluster/${local.cluster_name}", "shared"))}"
  base_name       = "${var.project}-${var.environment}"
  cluster_name    = "${local.base_name}-cluster"
  cluster_version = "1.12"
}

outputs.tf

標準出力させる内容をここで記述します。
kubeconfig、EKSのConfigMapを定義します。
EKSのconfigmapはmasterとnodeを紐づけるためのものです。

outputs.tf

locals {
  kubeconfig = <<KUBECONFIG
apiVersion: v1
clusters:
- cluster:
    server: ${aws_eks_cluster.cluster.endpoint}
    certificate-authority-data: ${aws_eks_cluster.cluster.certificate_authority.0.data}
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    user: aws
  name: aws
current-context: aws
kind: Config
preferences: {}
users:
- name: aws
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1alpha1
      command: aws-iam-authenticator
      args:
        - "token"
        - "-i"
        - "${local.cluster_name}"
KUBECONFIG

  eks_configmap = <<CONFIGMAPAWSAUTH
apiVersion: v1
kind: ConfigMap
metadata:
  name: aws-auth
  namespace: kube-system
data:
  mapRoles: |
    - rolearn: ${aws_iam_role.eks-node.arn}
      username: system:node:{{EC2PrivateDNSName}}
      groups:
        - system:bootstrappers
        - system:nodes
CONFIGMAPAWSAUTH
}

output "kubectl config" {
  value = "${local.kubeconfig}"
}

output "EKS ConfigMap" {
  value = "${local.eks_configmap}"
}

実行

terraformの実行

下記コマンドを実行するだけです。
数分かかります。

$ terraform init
$ terraform plan
$ terraform apply

configの反映

outputs.tfで定義した内容が出力されるので、それを設定に反映させていきます。

kubeconfigは~/.kube/configに書き込み、contextを変更しましょう。

$ kubectl config use-context HOGE

EKS ConfigMapは出力されたものをそのままeks_configmap.yamlなどとして保存して、内容を反映させます。

$ kubectl apply -f eks_configmap.yaml

確認

nodeのステータスを確認してみます。

$ kubectl get nodes
NAME                                            STATUS    ROLES     AGE       VERSION
ip-10-0-0-242.ap-northeast-1.compute.internal   Ready     <none>    48s       v1.12.7
ip-10-0-1-208.ap-northeast-1.compute.internal   Ready     <none>    47s       v1.12.7

まとめ

terraformでEKS環境を構築する方法を紹介しました。
最後configをいじるのが面倒なのでそれを何とかしたいなと思いました。
ただ、コンソールで全て設定するよりかははるかに楽です。

参考

Amazon EKS の使用開始
Terraformを使ってEKSを作成してみた
AWS EKS Introduction
Terraformを使ってEKSを構築する

CodeBuildのBuild Spec（buildspec.yml）では環境変数をenvに列挙する必要がある。Build Spec バージョン0.2から各フェーズ（コマンド）間で環境変数を引き継げるようになったため、環境変数をファイルに記載しておき、installフェーズの最初で読み込んでしまうと管理しやすい。

参考：Shells and Commands in Build Environments

buildspec.ymlの設定例

version: 0.2
env:
  variables:
    ENV: test
phases:
  install:
    commands:
      - set -a; for f in env/${ENV}/*.env; do . ${f}; done; set +a

概要

下記環境を新規作成しようとした際に諸々困った点があったので記載します。
インターネット - S3 - ALB(external) - Fargate(Task)

困った点

1. ALBのタイプをexternalからinternalに変更しようとした時にFargateのクラスタ内のServiceを作り直さないといけなかった。
2. 上記の新規環境を作成しようとした際にALBからのhealthcheckが成功->失敗を繰り返す。

解決策

• 1. について 「困った点」にも記載しましたが、文字通りServiceを作成し直さないといけない。また、ALBのDNS名に対してAliasレコードをコンテンツDNS上に記載していたら、そちらも修正しないと通信できない。

• 2.について

  • Taskにてメモリ制限（MB）が0になっていた。 こちらタスク定義の新しいリビジョンの作成 -> コンテナの定義 から編集するが、コンテナの定義で作成 -> タスク定義の新しいリビジョンの作成で作成ボタンを押さないと反映されない。
  • コンテナの定義にてHEALTHCHECKの設定をするが、下記の通り、CMD-SHELLとcurlの間に,(カンマ)が必要である。編集前の画面上では,(カンマ)が表示されていないので要注意!

  CMD-SHELL,curl -f http://localhost:9000 || exit 1
  　

2019年4月にAWS Cloud9が東京リージョンでリリースされましたが、このCloud9でAWSのリソースを構築するコードをデプロイしながら、SSH等でサーバを操作できると運用が捗ります。そこで、Cloud9でTerraformをインストールする手順をまとめてみました。

1. Homebrewをインストール

以下の記事の内容の通り、Homebrewをインストールします。2019年では、HomebrewはLinuxをオフィシャルにサポートし、インストールできるようになっています。手順は非常に簡単なものでした。
Cloud9にHomebrewをインストールする手順

2. tfenvをインストール

Terraformのバージョンを切り替えることができるtfenvをインストールします。
tfenvをインストールしていれば、新しいTerraformのバージョンがリリースされても、Cloud9上で旧バージョンのインストールを維持したまま、新バージョンを試すことができます。

$ brew install tfenv

3. tfenvで利用できるTerraformのバージョンを確認

以下のコマンドで、tfenvを使ってインストールできるTerraformのバージョンを確認します。

$ tfenv list-remote

4. tfenvでTerraformをインストール

最新のバージョンでインストールするには、以下のコマンドを実行します。

$ tfenv install latest

バージョンを指定する場合は、以下のコマンドに倣います。

$ tfenv install 0.11.13

5. tfenvでTerraformのバージョンを選択

tfenvでバージョンを指定すると、terraformコマンドを実行した時に、指定したバージョンが使われるようになります。1つしかバージョンをインストールしていなくても、コマンドを実行する必要があります。

$ tfenv use latest

バージョンを指定する場合は、以下のコマンドに倣います。

$ tfenv use 0.11.13

6. 動作確認

Terraformのバージョン確認コマンドを実行して、バージョンを表す文字列が返ることを確認します。

$ terraform --version
Terraform v0.12.0-beta2

これでCloud9でもTerraformが使えるようになりました。Cloud9をEC2モードで動かしている場合は、EC2にIAM Roleをアタッチすれば、TerraformでAWSのリソースを構築できるようになります。

はじめに

EC2のDeep Learning AMI (Ubuntu)を使って開発をすることが多くなり、詰まったところをメモ程度に残します。

デフォルトの75GBでは絶対に容量が足りない

Filesystem     Type     1K-blocks     Used Available Use% Mounted on
udev           devtmpfs    499264        0    499264   0% /dev
tmpfs          tmpfs       101444     3324     98120   4% /run
/dev/xvda1     ext4      76171508 75792680    362444 100% /
tmpfs          tmpfs       507212        0    507212   0% /dev/shm
tmpfs          tmpfs         5120        0      5120   0% /run/lock
tmpfs          tmpfs       507212        0    507212   0% /sys/fs/cgroup
/dev/loop1     squashfs     18304    18304         0 100% /snap/amazon-ssm-agent/1068
/dev/loop0     squashfs     16896    16896         0 100% /snap/amazon-ssm-agent/784
/dev/loop2     squashfs     93312    93312         0 100% /snap/core/6531
/dev/loop3     squashfs     91648    91648         0 100% /snap/core/6818
/dev/loop4     squashfs     89984    89984         0 100% /snap/core/5742
tmpfs          tmpfs       101444        0    101444   0% /run/user/1000

/dev/xvda1がメインのボリュームですが、インスタンスを建てたときにすでに容量がほぼいっぱいになっています。

$ conda create -n new_env --clone pytorch_p36

などで新しい仮想環境をつくっただけでも途中で容量がいっぱいになります。

インスタンスを立てる際のボリューム設定

ここがデフォルトでは75GBになっているので、適宜必要な値を入力します。自分は１００GBで作成しました。

インスタンスを建ててしまった後の対応

サイドバーのボリュームを選択後にインスタンスを選び、アクションからボリュームの変更でサイズを変更します。

$ lsblk

で確認しても反映されていないことが確認されます。

NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
xvda    202:0    0  100G  0 disk 
└─xvda1 202:1    0   75G  0 part /
loop0     7:0    0 16.5M  1 loop /snap/amazon-ssm-agent/784
loop1     7:1    0 17.9M  1 loop /snap/amazon-ssm-agent/1068
loop2     7:2    0 91.1M  1 loop /snap/core/6531
loop3     7:3    0 89.4M  1 loop /snap/core/6818
loop4     7:4    0 87.9M  1 loop /snap/core/5742

以下のコマンドを打ちます。

$ sudo growpart /dev/xvda 1

するとボリュームのパーティションが変更されます。

NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
xvda    202:0    0  100G  0 disk 
└─xvda1 202:1    0  100G  0 part /
loop0     7:0    0 16.5M  1 loop /snap/amazon-ssm-agent/784
loop1     7:1    0 17.9M  1 loop /snap/amazon-ssm-agent/1068
loop2     7:2    0 91.1M  1 loop /snap/core/6531
loop3     7:3    0 89.4M  1 loop /snap/core/6818
loop4     7:4    0 87.9M  1 loop /snap/core/5742

次にファイルシステムに拡張になります。

$ df -h

で確認すると、まだ75GBのままです。

Filesystem      Size  Used Avail Use% Mounted on
udev            488M     0  488M   0% /dev
tmpfs           100M  3.3M   96M   4% /run
/dev/xvda1       73G   73G     0 100% /
tmpfs           496M     0  496M   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           496M     0  496M   0% /sys/fs/cgroup
/dev/loop1       18M   18M     0 100% /snap/amazon-ssm-agent/1068
/dev/loop0       17M   17M     0 100% /snap/amazon-ssm-agent/784
/dev/loop2       92M   92M     0 100% /snap/core/6531
/dev/loop3       90M   90M     0 100% /snap/core/6818
/dev/loop4       88M   88M     0 100% /snap/core/5742
tmpfs           100M     0  100M   0% /run/user/1000

そこで以下のコマンドでファイルの拡張を行います。

$ sudo resize2fs /dev/xvda1

もう一度確認すると100GBになっているはずです。

Filesystem      Size  Used Avail Use% Mounted on
udev            488M     0  488M   0% /dev
tmpfs           100M  3.3M   96M   4% /run
/dev/xvda1       97G   73G   25G  75% /
tmpfs           496M     0  496M   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           496M     0  496M   0% /sys/fs/cgroup
/dev/loop1       18M   18M     0 100% /snap/amazon-ssm-agent/1068
/dev/loop0       17M   17M     0 100% /snap/amazon-ssm-agent/784
/dev/loop2       92M   92M     0 100% /snap/core/6531
/dev/loop3       90M   90M     0 100% /snap/core/6818
/dev/loop4       88M   88M     0 100% /snap/core/5742
tmpfs           100M     0  100M   0% /run/user/1000

これで仮想環境作っても容量不足になりません。

AWS Innovate online conferenceでPeasonVueでもAWS認定試験が受けられることを知りましたので受けてきました。PeasonVueのテストセンターを検索してみると県に１つ認定試験のテストセンターがあるように見えます。
場所に縛られず受験がかなり楽になりました。

• 参考：AWS Certification の受験場所が 3 倍に増加、AWS 認定取得がより便利に
• 参考: PeasonVue テストセンター検索

試験の予約

AWS認定サイトで予約します。試験のスケジュールを立てる、で予約手続きが可能です。手続き後予約時に登録するメールアドレス宛に手続き完了通知が届きます。（メールは英語でした）

PeasonVueテストセンター

• 受付用紙をテストセンター受付で記入
• 本人確認書類は2種必要な点に注意し持参。自分は運転免許証とパスポートを持参
• そして顔写真を撮り受付完了
• 30分余裕を持って会場に着いていたので前倒しで受験できました

テスト

• 会場にもよるのですが今回の会場はWEB監視カメラなしで受験 (別の会場の時はWEB監視カメラありで顔を試験中に触るだけでも注意を受けました・・)
• 会場に持ち込んで良いのは本人確認書類とテスト会場で支給されたメモボードとペンのみでした

テスト後

• アンケートに回答
• アンケート回答後、合否が即時発表(スコアはわからない) -> 合格してました
• テスト受験翌日に上記AWS認定サイトで登録していたメールアドレス宛にテスト結果・スコア通知が届きました （通知が届くまで時間がかかる場合があるようです）

資格取得のモチベーション

正直なところ、資格を取得しても知識が得られるだけで実際に手を動かして実践ができるような実力が身につかず実務には直結しないと思っていたため、今まで敬遠してきました(AWSは趣味でEC2やLambda、ECS使っている程度)。

今回の資格取得を経て体系的にサービスの特徴やアーキテクチャの考え方を知ることができました(AWS Well-Architected Framework)。
個人利用レベルではRedShiftやKinesis、DirectConnectは中々利用するシーンがない気がします。高いですしね。。

今後

• 得られた知識を棚卸するために実際にサービスを使ってみて簡単なシステムを組んで実践してみたいです（QwikLABSでできたら嬉しい）。

以上

Managed Blockchainとは

Amazon Managed Blockchain はフルマネージド型のサービスで、一般的なオープンソースフレームワークである Hyperledger Fabric や Ethereum* を使用して、スケーラブルなブロックチェーンネットワークを簡単に作成し管理できます。

Amazon Managed Blockchain

作ってみる

「Create network」から手順通りに作成していきます。

ネットワークの作成

• Blockchain frameworks
  実行するフレームワークを選択します。
  （2019/5/2現在、Hyperledger Fabricのみ選択可能）

• Network edition
  Starter editionとStandard editionの2種類から選択します。
  それぞれテストネットワーク用、本番ネットワーク用として用意されています。
  ノードのサイズ、メンバー上限、ノード数、チャンネル数の制限に違いがあります。

Amazon Managed Blockchain Pricingより

The Amazon Managed Blockchain Starter Edition network is designed for test networks and small production networks.

The Amazon Managed Blockchain Standard Edition network is designed for production networks.

• Network name and description
  ネットワーク名。64文字以内。

• Description
  ネットワークの説明。

• Voting policy
  合意形成に必要なパーセント、期間を指定します。

ユーザーの作成

• Member name
  メンバー名。64文字以内。ネットワーク内でユニークである必要があります。

• Description
  メンバーの説明。

• Admin username
  Fabric CAにログインするadminユーザー名。

• Admin password
  adminユーザーのパスワード。8-32文字。大文字小文字必須。

確認画面

作成中

作成されるまでしばらく待ちます。

作成完了

20分以上かかりました。ここまででネットワークの作成が終わりです。

ノードの作成

membersタブから作成したユーザー名を選択し、Creater peer nodeをクリック。

インスタンスサイズとAZを選択します。
Starter editionの場合はbc.t3.smallもしくはbc.t3.mediumのみ選択できます。

作成できました。今回は3分程で完了です。

所感

起動こそ時間はかかりましたが、簡単に作成できました。
値段は通常のEC2の6割増しくらいでしょうか？（us-east-1料金）

t3.small	bc.t3.small
0.0208USD/h	0.034USD/h

Hyperledger Fabricについて知識が無いので、かじっていきたいと思います。

参考

Amazon Managed Blockchain
Amazon Managed Blockchain Pricing
HyperLedger Fabric(v1.00) におけるトランザクションの理解 - Qiita
オンデマンドインスタンスの料金 - Amazon EC2 (仮想サーバー) | AWS

はじめに

某プログラミングスクールの課題で、Railsを使ってECサイトを作成。

開発環境

Ruby 2.3.1
Rails 5.2.2.1

発生時の状況

トップページに掲載している画像を、javascriptを使ってスライドさせる機能を開発環境で実装。
本番環境にデプロイすると、画像がスライドされず、また大きくレイアウトも崩れました。

エラーの原因

原因は、application.jsに
=require rails-ujs
=require jquery-ujs

の２つの記述があり、Rails側とjQuery側でファイルの呼び出しを行いエラーが発生しているようでした。

解決策

調べた結果、上記のコードのいずれかを削除すると正常に動作する模様。
今回は、上の方のコードを削除したところ正常に動作しました。恐らく下のコードを削除しても正常に動作する。