:beginner: Amazon EC2 Simple Systems Manager (SSM) エージェントのインストール

:beginner:
Amazon EC2 Systems Managerを使用するためのエージェントを導入するまでの手順です。
内容としては初心者向けになっています。

前提条件

SSMエージェントの導入対象インスタンスからS3へのアクセス(HTTPS)が出来る必要があります。

Simple Systems Manager 用の管理ポリシーを追加

SSMを使用したいインスタンスに割り当てているIAMロールへSSMの管理ポリシーをアタッチする。

ロールがない場合は作成する。
2017-06-21-14-20-20.png

「AmazonEC2RoleforSSM」を選択し「ポリシーのアタッチ」を実施する。
2017-06-21-14-23-37.png

2017-06-21-14-26-28.png

Simple Systems Manager エージェントのインストール

:warning: Amazon Linux、RHEL、および CentOS 64 ビット の 東京リージョンの場合の手順

新規インスタンスの場合はユーザーデーターに以下を追加で定義する。

#!/bin/bash
cd /tmp
sudo yum install -y https://amazon-ssm-ap-northeast-1.s3.amazonaws.com/latest/linux_amd64/amazon-ssm-agent.rpm

既に稼働中のインスタンスの場合はログイン後に以下のコマンドを実行する。

sudo yum install -y https://amazon-ssm-ap-northeast-1.s3.amazonaws.com/latest/linux_amd64/amazon-ssm-agent.rpm
[ec2-user@ip-10-0-2-141 ~]$ sudo yum install -y https://amazon-ssm-ap-northeast-1.s3.amazonaws.com/latest/linux_amd64/amazon-ssm-agent.rpm
Loaded plugins: priorities, update-motd, upgrade-helper
amazon-ssm-agent.rpm                                            | 6.0 MB  00:00:00
Examining /var/tmp/yum-root-Mncwuv/amazon-ssm-agent.rpm: amazon-ssm-agent-2.0.822.0-1.x86_64
Marking /var/tmp/yum-root-Mncwuv/amazon-ssm-agent.rpm to be installed
Resolving Dependencies
amzn-main/latest                                                | 2.1 kB  00:00:00
amzn-updates/latest                                             | 2.3 kB  00:00:00
--> Running transaction check
---> Package amazon-ssm-agent.x86_64 0:2.0.822.0-1 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

=======================================================================================
 Package                Arch         Version             Repository               Size
=======================================================================================
Installing:
 amazon-ssm-agent       x86_64       2.0.822.0-1         /amazon-ssm-agent        17 M

Transaction Summary
=======================================================================================
Install  1 Package

Total size: 17 M
Installed size: 17 M
Downloading packages:
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  Installing : amazon-ssm-agent-2.0.822.0-1.x86_64                                 1/1
amazon-ssm-agent start/running, process 7104
  Verifying  : amazon-ssm-agent-2.0.822.0-1.x86_64                                 1/1

Installed:
  amazon-ssm-agent.x86_64 0:2.0.822.0-1

Complete!
[ec2-user@ip-10-0-2-141 ~]$

Simple Systems Manager エージェントの起動確認

[ec2-user@ip-10-0-2-141 ~]$ sudo status amazon-ssm-agent
amazon-ssm-agent start/running, process 7104
[ec2-user@ip-10-0-2-141 ~]$

ちなみにAmazon Linux の場合 Upstartでの管理になります。

[ec2-user@ip-10-0-2-141 ~]$ sudo initctl list |grep amazon-ssm-agent
amazon-ssm-agent start/running, process 7104
[ec2-user@ip-10-0-2-141 ~]$

Simple Systems Manager への登録確認

EC2 の「SYSTEM MANAGER共有リソース」の「マネージドインスタンス」を選択します。

エージェントをインストールしたインスタンスが登録されていることが確認できます。
2017-06-21-15-11-56.png

続きを読む

転ばぬ先のAWSセキュリティ

サービスが大きくなればなるほど、セキュリティは重要になってくる


じゃあ最初から強固なものにしよう


  1. 強固なパスワード
  2. グループメール
  3. MFA(多要素認証)
  4. ルートアカウントのアクセスキーは使わない
  5. CloudTrail有効化
  6. git-secrets導入
  7. IAMユーザー、グループ、ロール

■ 参考
AWSリソースについてセキュリティベストプラクティスに従った設定をしよう!
git-secretsでAWSの不正利用を防ぐ


  1. 強固なパスワード
  2. グループメール
  3. MFA(多要素認証)
  4. ルートアカウントのアクセスキーは使わない
  5. CloudTrail有効化 ← これ
  6. git-secrets導入 ← これ
  7. IAMユーザー、グループ、ロール ← これ

これの部分を今日は話します


CloudTrail

AWSの操作履歴がすべて取得できるようになる戦犯発見サービス。
グラフとかにもできるっぽい。ログはS3に保存される。

■ 参考
TrailDashでCloudTrailを可視化する


git-secrets

リポジトリにアクセスキーなどが混入しないようにするためのAWS謹製Gitプラグイン。
アクセスキーやシークレットキーはgit管理すんなよというAWSからのお達し。


使い方(インストール)

$ brew update
$ brew install git-secrets

使い方(設定)

  1. gitconfigにアクセスキーの標準パターンを登録
    => これだけだと無効なまま。一応ファイル内のスキャンはできる
  2. gitコミット時のhookに設定
  3. 例外があれば設定

具体的な設定方法はこちらの記事が参考になります


IAMユーザー、グループ、ロール


Identity and Access Management


それぞれの役割

  • ユーザー

    • コンソールサインイン、APIまたはCLIのリクエストを行うのに使用
  • グループ
    • ユーザーの集合。グループに属するユーザーに一括で権限付与できる
  • ロール
    • 特定タスクに応じてユーザーやサービスに権限付与できるもの
    • 認証情報(アクセスキー等)は関連付けられない

問題

IAMロールのユースケースをひとつあげてください


  • EC2インスタンスから他のAWSサービスにアクセスする必要がある時に権限を与えるためアタッチする

■ 参考
Amazon EC2 インスタンスで実行されるアプリケーションに IAM ロールを使用してアクセス権限を付与する


  • ルートアカウントだと権限が強すぎるので、必ずIAMユーザーを作成して適切な権限を付与
  • アクセスキーはできるだけ作成せず、IAMロールで利用することを推奨

しましょう


さらにIAMのベストプラクティスを知りたい場合はこちらへどうぞ

IAM のベストプラクティス


ありがとうございました。

続きを読む

EC2 インスタンスを Chat Bot で管理する

こないだ Amazon EC2 でディープラーニングできる GPU インスタンス1を作ったのだが、趣味で使うにしてはまぁ料金が高いので常時起動させておくのはもったいなく、使わないときはインスタンスを停止させるようにしている。

しかし使い始めるときと使い終わったときにいちいち AWS 管理コンソールにログインしてインスタンスの起動/停止をするのが面倒だったので、我が家の Slack Bot から EC2 インスタンスを管理できるようにしてみた。

最終的にできたものはこういう感じ。

以下、作り方。

Chat Bot 用の AWS ユーザを作成する

既存のユーザのアクセスキーを利用してもできるが、セキュリティのために専用のユーザを作成して必要な権限のみを付与するのが好ましい。

今回は API を叩くためのユーザなので「プログラムによるアクセス」にチェックを入れる。

ユーザを作成すると、API を叩く際に必要なアクセスキー (AccessKeyId, SecretAccessKey) が生成されるので控えておく。

EC2 を操作できるポリシーを割り当てる

作成したユーザに必要な権限を付与する。

今回やりたいことは

  • EC2 インスタンスの一覧とステータスを取得する
  • EC2 インスタンスを起動させる
  • EC2 インスタンスを停止させる

の3つなので、それに合わせて以下のようなインラインポリシーを割り当てる。

AllowEC2InstanceManagement
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:DescribeInstanceStatus",
                "ec2:StartInstances",
                "ec2:StopInstances"
            ],
            "Resource": "*"
        }
    ]
}

今回はすべてのインスタンスを操作できるようにするために "Resource": "*" としたが、ARN を指定することで「特定のインスタンスのみを操作可能」というような制限をすることも出来る。

Chat Bot から AWS API を叩く

我が家の Chat Bot は Node.js で動作しているので、AWS JavaScript SDK を利用して AWS API を叩く。

AWS JavaScript SDK をインストール

npm からインストールできる。

$ npm install aws-sdk

アクセスキーの設定

AWS SDK を読み込んでアクセスキーを設定する。

const AWS = require('aws-sdk');

// アクセスキーは環境変数から読み込む
AWS.config.update({
  accessKeyId: process.env.AWS_ACCESS_KEY_ID,
  secretAccessKey: process.env.AWS_SECRET_ACCESS_KEY,
  region: 'ap-northeast-1', // 東京リージョン
});

// EC2 インスタンスを操作するためのオブジェクトを生成
const ec2 = new AWS.EC2();

アクセスキーをハードコートせずに環境変数から読み込んでいるので、Bot を動作させる環境の環境変数 AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY にアクセスキーを設定しておく必要がある。

インスタンスの名前をつける

チャットから ec2 gpgpu start のようにインスタンスの名前を指定して起動/停止できるようにしたいので、インスタンス ID と名前を関連付けられるようにしておく。

// 名前から起動/停止できる EC2 インスタンスの一覧
const instances = [
  { id: "i-01315ab8f6f7015e5", name: "GPGPU" },
];

// 名前からインスタンス ID を返す
function getInstanceId(name) {
  const instance = instances.filter(i => i.name.toLowerCase() === name.toLowerCase())[0];
  return instance ? instance.id : null;
}

// インスタンス ID から名前を返す
function getInstanceName(id) {
  const instance = instances.filter(i => i.id === id)[0];
  return instance ? instance.name : null;
}

Bot のアクションを定義する

チャットから Bot にコマンドメッセージが投稿されたときに AWS API を叩くようなアクションを定義する。

以下のコードは自作の Bot フレームワーク2で動くコードだが、インタフェースを Hubot に似せて作っているので Hubot でもだいたい同じようなノリで書けると思う。

module.exports = (bot) => {

  // 指定した EC2 インスタンスを起動する
  bot.respond(/^ec2 ([w_]+) start$/i, (msg) => {
    const id = getInstanceId(msg.match[1]);
    if (!id) return msg.send('知らないインスタンスですね・・・');
    ec2.startInstances({ InstanceIds: [id] }, (err) => {
      if (err) {
        bot.logger.error(err);
        msg.send('インスタンスの起動に失敗しました...');
      } else {
        msg.send('インスタンスを起動しました');
      }
    });
  });

  // 指定した EC2 インスタンスを停止する
  bot.respond(/^ec2 ([w_]+) stop$/i, (msg) => {
    const id = getInstanceId(msg.match[1]);
    if (!id) return msg.send('知らないインスタンスですね・・・');
    ec2.stopInstances({ InstanceIds: [id] }, (err) => {
      if (err) {
        bot.logger.error(err);
        msg.send('インスタンスの停止に失敗しました...');
      } else {
        msg.send('インスタンスを停止しました');
      }
    });
  });

  // すべての EC2 インスタンスの起動状況を取得する
  bot.respond(/^ec2 status$/i, (msg) => {
    const stateIcons = {
      running: 'large_blue_circle',
      terminated: 'red_circle',
      stopped: 'white_circle',
    };
    ec2.describeInstanceStatus({ IncludeAllInstances: true }, (err, data) => {
      if (err) {
        bot.logger.error(err);
        return msg.send('インスタンス情報の取得に失敗しました...');
      }
      const text = data.InstanceStatuses.map((instance) => {
        const id = instance.InstanceId;
        const state = instance.InstanceState.Name;
        const icon = stateIcons[state] || 'large_orange_diamond';
        const name = getInstanceName(id);
        const nameLabel = name ? ` (*${name}*)` : '';
        return `:${icon}: `${id}`${nameLabel} is ${state}`;
      });
      msg.send(text.join('n'));
    });
  });

  // インスタンスが起動中の場合は1時間に1回通知する
  bot.jobs.add('0 0 * * * *', () => {
    ec2.describeInstanceStatus((err, data) => {
      if (err) {
        bot.logger.error(err);
        return bot.send('インスタンス情報の取得に失敗しました...');
      }
      const count = data.InstanceStatuses.length;
      if (count > 0) bot.send(`${count} 台の EC2 インスタンスが起動中です`);
    });
  });

};

今回は start / stop / status の3つのコマンドに加えて、停止し忘れを防ぐために「一時間に一回通知する」機能も実装した。

ec2 オブジェクトのメソッドを使っている箇所が API を叩いている箇所なわけだが、メソッドのオプションなどの詳細は AWS JavaScript SDK のドキュメント3を参照して欲しい。

動かす

Bot をデプロイしてコマンドを投げてみると、こういう感じ。

これで AWS の管理コンソールにログインしなくても EC2 インスタンスを操作できるようになった。便利。

続きを読む

AWS ECSを使用する前にDockerを理解しなきゃ

◎はじめに

・Amazon EC2 Container Service (ECS)ってなんじゃらほい?
というわけでざっくり調べてみたところ、Dockerコンテナを管理するものとのこと。
『えっ、、Dockerってクジラさんのアイコンのヤツでしょ。VMの一つの。。』
とまたまたITリテラシーの低さを露呈した私、
ECSを触る前にまずDockerを理解する必要が出てきました。

1. Dockerとは

docker.png

Wikipediaより

Docker(ドッカー)はソフトウェアコンテナ内のアプリケーションのデプロイメントを自動化するオープンソースソフトウェアである。
Linuxカーネルにおける「libcontainer」と呼ばれるLinuxコンテナ技術とaufsのような特殊なファイルシステムを利用してコンテナ型の仮想化を行う。

はい。まだよくわかりません。。コンテナってなんなのさ。。。

1-1. コンテナとは

■目的
・デプロイ作業を簡易にする
→ 開発環境をそのまま本番環境として利用できる
→ アプリケーション開発環境(ライブラリ、環境変数など)をまるごとパッケージングし本番環境にデプロイすることで環境に依存することがなくなる。

■仮想化との差異

タイプ    概要
仮想化 複数のオペレーティングシステムが単一のシステム(ゲストOS)で同時に実行できるようになる
コンテナ 同じオペレーティング・システム・カーネルを共有し、アプリケーションプロセスをシステムの他の部分から独立させる

▽補足
・Hypervisor上に複数のOSを実行する仮想化は負荷が大きい。
一方、コンテナはホストOS、ライブラリを共有している。
そのため少ディスクかつ少メモリでビルドもデプロイも高速、オーバーヘッドも少ない。
それでいて仮想化のためプラットフォームやハードウェアからは隔離された環境となっている。

・1コンテナ=1プロセス

▽参考サイト:
今からでも間に合うDockerの基礎。コンテナとは何か、Dockerfileとは何か。Docker Meetup Tokyo #2

1-2. 取り敢えず触ってみよう

■参考サイト
・公式サイト
https://docs.docker.com/

・Docker ドキュメント日本語化プロジェクト
http://docs.docker.jp/index.html

■環境
・最新のAmazon linux AMIからlaunchしたインスタンスに導入してみました。

[ec2-user@mitzi_dev02 ~]$ uname -r
4.9.27-14.31.amzn1.x86_64

■余談
・amzn linuxへのインストール方法が公式サイト上で見つからなかったため、CentOSの手順でやってみたところ
ライブラリが足りないなどのエラーが多発し撃沈。。そこで上述の日本語化されたサイトを見たところAWS公式DocumentationのECSの項にDockerの説明・導入方法の記載がありました。親切ね

Docker の基本

■インストールそしてHello World

・パッケージとパッケージキャッシュを更新
$ sudo yum update -y

・Dockerをインストール
$ sudo yum install -y docker

・Dockerサービスを開始する
$ sudo service docker start
Starting cgconfig service:                                 [  OK  ]
Starting docker:  .                                  [  OK  ]

・ Dokerの環境情報表示でコマンド実行できることを確認
$ sudo docker info
・Hell world コンテナを実行

[ec2-user@mitzi_dev02 ~]$ docker run ubuntu:14.04 /bin/echo 'Hello world'

docker: Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Post http://%2Fvar%2Frun%2Fdocker.sock/v1.27/containers/create: dial unix /var/run/docker.sock: connect: permission denied.
See 'docker run --help'.
[ec2-user@mitzi_dev02 ~]$ sudo docker run ubuntu:14.04 /bin/echo 'Hello world'
Unable to find image 'ubuntu:14.04' locally
14.04: Pulling from library/ubuntu
1d8592394ba1: Pull complete
01aa7f61ccd1: Pull complete
5dd2552a960e: Pull complete
7cbe941c5e3e: Pull complete
2549ecfb14c6: Pull complete
Digest: sha256:30204139c6ab96ebd75d72f34db390f28c4decd5e563488b4e485bf979397b67
Status: Downloaded newer image for ubuntu:14.04
Hello world

公式サイトより、ここでやっていることの説明を引用

  • docker run でコンテナを実行。
  • ubuntu は実行するイメージです。この例では Ubuntu オペレーティング・システムのイメージです。イメージを指定したら、Docker はまずホスト上にイメージがあるかどうか確認します。イメージがローカルに存在していなければ、パブリック・イメージ・レジストリである Docker Hub からイメージを取得(pull)します。
  • /bin/echo は新しいコンテナ内で実行するコマンドです。

コンテナを起動するとは、Docker が新しい Ubuntu 環境を作成し、その中で /bin/echo コマンドを実行し、その結果を出力します。

なんとなくイメージが湧いてきました。
ここでは簡単なコマンドを実行しただけですが、これを応用していくことで前述の目的を達成するんだろうな。という何となくなイメージが

とりあえず今回はココまでになります。
引き続きDockerを触ってゆき、その先にあるECSを使いこなせるようにしていきたく思います。

続きを読む

AWS 認定ソリューションアーキテクト – アソシエイト 合格までに勉強したこと

概要

AWS 認定試験には「これを勉強すればいいよ!」という教科書があるわけではないので、何を勉強したらいいか分からず困っている人も多いと思います。
なので、私の勉強記録を共有します。

勉強前のスペック

AWSの初級者です。
EC2インスタンス起動やEBSのスナップショット取得の経験があるくらいでした。

勉強方法概要

AWS活用本を一冊読んで、
あとはAWS クラウドサービス活用資料集にある BlackBelt のスライド(PDF)を淡々と読みました。

その後、模擬試験を受けて本試験を受験しました。

勉強方法詳細

少し前に買っていた以下の本を読みました。分かりやすいです。

Amazon Web Services 定番業務システム12パターン設計ガイド

BlackBelt

自分が読んだ資料に○を付けました。
また、模擬試験と本試験を受けた経験から、各資料の重要度を評価しました。
※当たり前ですが、読んでいない資料の重要度は評価していません。また、重要度の正確性も保証しません。

コンピューティング

資料 読んだ  重要度 
[Amazon EC2] 
[Amazon EC2] Windows
[Amazon EC2] HPC
[Amazon EC2] リザーブドインスタンス
[Amazon EC2] スポットインスタンス
[Amazon EC2] Instance Store & Elastic Block Store
[Amazon EC2] VMImport/Export
[Elastic Load Balancing]
[Elastic Load Balancing] ロードバランサと Socket 接続を使用したイベント通知サーバの負荷分散
[Elastic Load Balancing] ELBを評価するためのベストプラクティス
[Auto Scaling]
[Amazon EC2 Container Service]
[AWS Elastic Beanstalk]
[AWS Lambda]
[AWS Lambda] update
[Amazon Lightsail]
[AWS Batch]

ストレージ & コンテンツ配信

資料 読んだ  重要度 
[Amazon EBS]
[Amazon S3] 
[Amazon CloudFront]
[Amazon CloudFront] Flash Media Server on AWS
[Amazon CloudFront] CloudFront 上限緩和申請 計算方法&申請手順
[Amazon CloudFront] まだ間に合う! Amazon CloudFront で ATS 対応
[Amazon Glacier]
[Amazon Glacier] 機能編
[AWS Storage Gateway]
[Amazon Elastic File System]

データベース

資料 読んだ  重要度 
[Amazon RDS]
[Amazon RDS] Aurora
[Amazon DynamoDB]
[Amazon ElastiCache]
[Amazon ElastiCache] Redis QA資料
[Amazon Redshift] 
[Amazon Database Migration Service]

ネットワーキング

資料 読んだ  重要度 
[Amazon VPC]
[Amazon VPC] VPN接続設定 参考資料
[AWS Direct Connect] 
[Amazon Route53]

開発者用ツール

資料 読んだ  重要度 
[AWS CodeCommit]
[AWS CodeBuild]
[AWS CodeDeploy]
[AWS CodePipeline]
[AWS SDK]
[AWS SDK] Java & .NET
[AWS SDK] PHP & Ruby & Boto(Python) & Javascript in Node.js
[AWS SDK] AWS Client side SDK Android & iOS & Javascript
[AWS CLI]
[AWS AWS Tools for Windows Powershell]

管理ツール

資料 読んだ  重要度 
[Amazon CloudWatch]
[AWS CloudFormation]
[AWS CloudTrail]
[AWS Config]
[AWS OpsWorks] AWS OpsWorksのご紹介
[AWS OpsWorks]
[AWS OpsWorks] ハンズオン
[AWS Service Catalog]
[Trusted Advisor] AWS サポート & Trusted Advisor
[Amazon EC2 Systems Manager]

セキュリティ & アイデンティ

資料 読んだ  重要度 
[Identity and Access Management (IAM)] 
[AWS CloudHSM] CloudHSM & Key Management Service
[AWS Key Management Service]
[AWS Directory Service]
[Amazon Inspector]
[AWS WAF]
[AWS Certificate Manager]

分析

資料 読んだ  重要度 
[Amazon EMR(Elastic MapReduce)]
[AWS Data Pipeline]
[Amazon Elasticsearch Service] Amazon CloudSearch & Amazon Elasticsearch Service
[Amazon Kinesis]
[Amazon QuickSight]
[Amazon Athena]

AI

資料 読んだ  重要度 
[Amazon AI]]

IoT

資料 読んだ  重要度 
[AWS IoT]

ゲーム開発

資料 読んだ  重要度 
[Amazon Lumberyard]

モバイルサービス

資料 読んだ  重要度 
[Amazon Cognito]
[Amazon Cognito] Amazon Cognito update
[Amazon Cognito] Amazon Cognito / Amazon Mobile Analytics
[AWS Device Farm]
[Amazon Mobile Analytics] Amazon Cognito / Amazon Mobile Analytics
[Amazon SNS] Amazon SNS/SQS
[Amazon SNS] モバイルプッシュ通知
[Amazon Pinpoint]  

アプリケーションサービス

資料 読んだ  重要度 
[Amazon API Gateway] 
[Amazon AppStream]
[Amazon CloudSearch] Amazon CloudSearch & Amazon Elasticsearch Service
[Amazon Elastic Transcoder]
[Amazon SES]
[Amazon SES] Amazon SES-Easy DKIM 設定サポート資料
[Amazon SQS] Amazon SNS/SQS
[Amazon Simple Workflow Service (SWF)]

エンタープライズアプリケーション

資料 読んだ  重要度 
[Amazon WorkSpaces]
[Amazon WorkDocs]
[Amazon WorkMail]
[Amazon Chime]

その他

資料 読んだ  重要度 
[Cost Explorer]
[AWS Management Console]

補足

重要度の低い資料も読んだ方がいいです。
なぜなら、マネージドサービス自体がAWSの活用事例であり、それらを知ることでシステム設計の勘所が分かるようになるからです。
また、重要度の高い機能との連携についての記載があることもあり、理解が深まります。

続きを読む

AWS ソリューションアーキテクトプロフェッショナル 受けてきました&勉強法(2017/6版)

前書き

image.png

 前回 の続きです。ソリューションアーキテクトアソシエイト(SAA)に受かったので今度はプロフェッショナル(SAP)に挑戦しました。

AWS の資格試験はわかりにくい

ワークショップについて

 公式サイトから読み取れないので補足。以下のクラスがありますが、

レベル/分野 アーキテクト 開発 運用
アソシエイト取得済み Advanced Architecting on AWS DevOps Engineering on AWS 同左
アソシエイト未取得向け Architecting on AWS Developing on AWS Systems Operations on AWS
AWS 未経験者向け Amazon Web Services 実践入門 1 / 2 同左 同左

 前提事項は記載ありるものの、いきなり Advanced などを受けてもいいし、受けずに受験に挑んでも大丈夫です。アソシエイト未取得向けのを2つ受ける必要はなさそうなので、Architecting 受けてから Developing 受けたりするのは、けっこう内容の重複がある ので、お金がもったいない。
 その他のクラスは試験に出てくる頻度が低いので、興味があれば受ければいいやつです。

 ソリューションアーキテクトアソシエイト(SAA) だけは試験対策として半日のワークショップがありますので、時間とお金があれば受けるといいかと。

認定試験について

 おさらいですが。
image.png

 ワークショップと同じく、範囲がかぶっているので アソシエイト取れたらほかのアソシエイトもいけそう なので、資格の数を増やすにはよさそうです、プロフェッショナルはそう簡単にいかないですが。英語版の資格として Advanced Networking 、Big Dataが追加となっています。Security(Beta) もあった気がしますが、 Beta が取れていないのかな。いずれさらに上の階級にある Master が提供されるかもしれないという噂があったりします。

試験概要

 概要をざっくり記載します。アソシエイトの倍の時間でついでに受験料も倍です。合格ラインはやはり65%という噂です。1問あたり2分ちょっとで解き、3時間集中し続ける というなかなかヘビーな内容です。

TOPIC DATA
試験時間 170分間
問題数 80問
合格ライン 非公開
受験料 ¥32,400

出題範囲

 出題範囲を確認すると、アソシエイトでは高可用性がほとんどでしたが、Pro では求められるものが変わっていることがわかります。そのほか試験ガイドをざっと読みました。

TOPIC 出題率
高可用性および事業継続性 15%
原価計算 5%
デプロイメントマネージメント 10%
ネットワーク設計 10%
データストレージ 15%
セキュリティ 20%
拡張性と伸縮自在性 15%
クラウド移行およびハイブリッドなアーキテクチャ 10%

学習

セミナーを受講する

 前述の Advanced Architecting on AWS を受講しました。
 セミナーには AWS 社員の方や、AWS をすでに実務で利用されているかたが多くいて、私のような素人も半分くらいいる印象でした。私は実業務で AWS に触れたことが実はほとんどなく、本気の AWS 運用に必要な知識を持ち合わせていなかったので次のような観点が非常に勉強になりました。

  • ユーザ管理:IAM と ADやフェデレーションでの連携を考慮し、大規模運用を考える
  • コスト観点:一括請求やスポットインスタンスの選び方で、大幅なコスト削減を考える
  • 運用・監査:KMSを使用した暗号化、CloudLogs でのロギング、ClodWatch でのモニタリングで運用・監査への対応を考える
  • 可用性・セキュリティ:大規模&複数VPCのデザイン、MultiAZ、MultiRegion で可用性向上を実現する、DDoS からインフラを保護する

AWS 活用資料集(BalckBelt)、WhitePaper を読む

 アップデートもあるので、改めて時間を見つけて読みました。時間があるときは Webinar にも参加しました。 Webinar だと日々疑問に思っていることの質問を AWS の SA に直接質問できるので、すごくおトクです。

  • BlackBelt

    • Amazon EC2
    • Elastic Load Balancing
    • Auto Scaling
    • Amazon EC2 Container Service
    • AWS Elastic Beanstalk
    • AWS Lambda
    • Amazon EBS
    • Amazon S3
    • Amazon CloudFront
    • Amazon Glacier
    • AWS Storage Gateway
    • Amazon Elastic File System
    • AWS CloudTrail & AWS Config
    • AWS Support & Trusted Advisor
    • AWS Directory Service
  • WhitePaper

    • セキュリティのベストプラクティス
    • セキュリティプロセスの概要
    • リスクとコンプライアンス
    • AWS を用いた故障耐障害性の高いアプリケーションの構築
    • 新しいリージョンへの AWS リソースの移行
    • 災害対策目的での AWS の使用

本読む

 AWS 事例全集 といった AWS が配っている冊子もありますが数がひたすら多いので、勉強用としてこちらの本で一般的なアーキテクチャを学びました。

image
Amazon Web Services 定番業務システム12パターン 設計ガイド

試験に向けて

 以下、結果もあわせて書いていきます。

サンプル問題集にチャレンジ

ソリューションアーキテクト プロフェッショナル

 サンプル問題を解いた結果、微妙でした。アソシエイトは本試験とくらべて非常に簡単だったので、先が思いやられます。

結果

4/6問 正解

ソリューションアーキテクト以外もやってみる

 SysOpsアソシエイト、DevOpsアソシエイトのサンプル問題もやってみました。ソリューションアーキテクトとはちょっと毛色の違うサービス(CloudFormationとかSQSとか)が出てくるので復習になります。Pro は回答が書いていなかったのでやっていません。

SysOps結果

6/10問 正解

DevOps結果

6/9問 正解

模擬試験

 データ書いておきます。なお、アソシエイト合格者はバウチャーコードが利用できますので活用しましょう。問題文はコピーできます。

TOPIC DATA
試験時間 90分間
問題数 40問
合格ライン 明記なし
受験料 ¥4,320

結果

得点: 27%
結果: 不合格

 時間足りなさすぎました。結果を分析しますが全体的に悪すぎて手のうちようがない感じでした。。。

TOPIC 出題率 正解率(模擬結果) 模擬出題数(予測) 誤答数(予想)
高可用性および事業継続性 15% 33% 6 4
原価計算 5% 0% 2 2
デプロイメントマネージメント 10% 0% 4 4
ネットワーク設計 10% 50% 4 2
データストレージ 15% 50% 6 3
セキュリティ 20% 25% 8 6
拡張性と伸縮自在性 15% 16% 6 5
クラウド移行およびハイブリッドなアーキテクチャ 10% 25% 4 3

出題傾向を抑える

 ベストプラクティスが複数書いてあって、どれも正解だけどよりベストなものを選ぶという問題や、コスト/可用性/移行期間/既存システムとの連携 のどれが求められているのかといった、真の目的を把握しないと答えられない問題が多くありました。
 また、昔の AWS 構成を最新のサービスで置き換えるような問題もあるため、古くなった知識はアップデートが必要です。

模擬試験の復習と弱点克服

 CloudHSM とかの暗号化系、DirectConnect/StorageGateway などの低レイヤー系、TrustedAdvisor など課金系、STS/IAMロールなどの認証系、StepFunctions や SWF などフロー系、Redshift や Kinesis などのBigData系 は、アソシエイトでも踏み込んだ問題が出なかったので個人的に苦手でした。これらは BlackBeltで復習しました。
 また、コピーした模試の問題はを1つづつ調べ、答え合わせをしました。模擬試験については本試験でも出ることがあるので暗記するつもりで復習しました。英語で回答を解説しているサイトがあるので大いに活用しました。

本試験

結果

合格!

image.png

内訳

総合スコア: 66%

トピックレベルのスコア:
1.0 High Availability and Business Continuity: 91%
2.0 Costing: 75%
3.0 Deployment Management: 62%
4.0 Network Design: 37%
5.0 Data Storage: 91%
6.0 Security: 56%
7.0 Scalability & Elasticity: 69%
8.0 Cloud Migration & Hybrid Architecture: 28%

所感

 なんとかギリギリセーフでした。本試験、すごい疲れます。。。
 実務半年程度のペーペーなので試験勉強と実務知識が比例するわけじゃなく、試験としては問題数こなすのが一番という気がしました。本試験のほうが模試より簡単だったので絶望せずがんばりましょう。

 次は DevOps に挑戦したいです。

続きを読む

別アカウントのECRを取得してeb deployを実行する

困ってたこと

ソースコードはアカウントA内のCodeCommitにあって、CodePipelineなどを使って、テスト・デプロイなどを行っていた。
特定のブランチをpushするだけで、テストやデプロイが行われるのでかなり快適だった。

しかし、アカウントB内に環境を立ち上げないといけなくなり、我がチームの大先輩が教えてくれたので、今後のためにドキュメントに残しておこうと思います。

やりたいこと

アカウントA内にあるECRを参照して、アカウントBにElastic Beanstalkを立ち上げる・更新する

フローを簡単にまとめると

  1. local開発環境からpushする
  2. CodePipelineを通って、テスト・デプロイが行われる
  3. 問題なければECRが更新される
  4. アカウントBへデプロイするプロジェクトに移って「eb deploy」を実行する

ECRのログイン情報を取得する

アカウントA内のECRを取得するためにログイン情報を取得します
下記コマンドを実行する。(このときのcredentialはアカウントAのIAM情報)

aws ecr get-login

結果

docker login -u AWS -p 文字列(★) ECRのエンドポイント

ECRを取得する際のログイン情報をjsonにして、アカウントB内のS3に置いておきます
例)バケット名:app-documents Key名:config.json

config.json
{
  "auths": {
    "ECRのエンドポイント": {
      "auth": "文字列(★)"
    }
  }            
}

アカウントBへデプロイするためのプロジェクトを作成する

local開発環境からpushしてECRが更新された後、そのECRをもとにElastic Beanstalkを更新するためのプロジェクトを作成します。
このプロジェクト内で「eb deploy」を実行するとアカウントA内のECRを取得し、アカウントB内のElastic Beanstalkアプリケーションの環境を更新するできるようにします。

Dockerの設定ファイルを作成する

Dockerコンテナ作成時の設定ファイルを作成します。

Dockerrun.aws.json
{
  "AWSEBDockerrunVersion": "1",
  "Authentication": {
    "Bucket": "app-documents",
    "Key": "config.json"
  },
  "Image": {
    "Name": "ECRのエンドポイント",
    "Update": "true"
  },
  "Ports": [
    {
      "ContainerPort": "3000"
    }
  ],
  "Volumes": [
    {
      "HostDirectory": "/var/log",
      "ContainerDirectory": "/var/www/logs"
    }
  ],
  "Logging": "/var/log"
}

Elastic Beanstalkの設定

アカウントB内のElastic Beanstalk内の環境にデプロイをしたいので、アカウントBで作成したIAM情報を持ったcredentialを作成します。
そのprofileを使用する形で、「eb init –proflie アカウントB」を実行し、Elastic Beanstalkの設定を行います。

aws configure --profile accountb
AWS Access Key ID [****************]: アカウントBで作成したIAMのアクセスキー
AWS Secret Access Key [****************]: アカウントBで作成したIAMのシークレットアクセスキー
Default region name [ap-northeast-1]: 東京を選択(別リージョンでも問題はないかと)
Default output format [None]:

eb init --profile accountb

// 下記は一例
Select a default region
1) us-east-1 : US East (N. Virginia)
2) us-west-1 : US West (N. California)
3) us-west-2 : US West (Oregon)
4) eu-west-1 : EU (Ireland)
5) eu-central-1 : EU (Frankfurt)
6) ap-south-1 : Asia Pacific (Mumbai)
7) ap-southeast-1 : Asia Pacific (Singapore)
8) ap-southeast-2 : Asia Pacific (Sydney)
9) ap-northeast-1 : Asia Pacific (Tokyo)
10) ap-northeast-2 : Asia Pacific (Seoul)
11) sa-east-1 : South America (Sao Paulo)
12) cn-north-1 : China (Beijing)
13) us-east-2 : US East (Ohio)
(default is 3): 9

Select an application to use
1) accountb
2) [ Create new Application ]
(default is 2): 2

Enter Application Name
(default is "accountb"): sample
Application sample has been created.

It appears you are using Docker. Is this correct?
(y/n): y

Select a platform version.
1) Docker 1.12.6
2) Docker 1.11.2
3) Docker 1.9.1
4) Docker 1.7.1
5) Docker 1.6.2
(default is 1): 1
Do you want to set up SSH for your instances?
(y/n): n

その後「eb create」を実行して、アカウントB内のElastic Beanstalkにアプリケーション及び環境を構築します。

eb create --vpc
// 適宜変更してください
Enter Environment Name
(default is sample-dev):
Enter DNS CNAME prefix
(default is sample-dev):

Select a load balancer type
1) classic
2) application
(default is 1): 2

Enter the VPC ID: アカウントBのVPC IT(EC2のダッシュボードから確認できます)
Do you want to associate a public IP address? (y/n): y
Enter a comma-separated list of Amazon EC2 subnets: アカウントBのsubnet。必ず複数指定してください(東京リージョンなら2つ)
Enter a comma-separated list of Amazon ELB subnets: アカウントBのsubnet。必ず複数指定してください(東京リージョンなら2つ)
Enter a comma-separated list of Amazon VPC security groups: アカウントBのVPCのセキュリティーグループ
Do you want the load balencer to be public? (Select no for internal) (y/n): y

処理が無事成功したら、作業完了です。
AWSのコンソール画面でも進捗を確認することができます。

今後、このプロジェクト内で「eb deploy」を実行すると、アカウントA内のECRを取得してElastic Beanstalkが更新されます。

このあたりの詳しい手順・説明はこちらを参考にしていただければと思います。

まとめ

少し力技感が否めませんが、困っていたことを解消することができました。
また、pushした際のCodePipelineでアカウントA内にElastic Beanstalkを立ち上げると、検証環境的なものを作れるので、個人的にはいい感じだなと思います。

ほかにもっとよい方法があればご教授いただきたいです。

続きを読む

nginxで同一ホスト内にリバースプロキシしようとするとエラーが出る

nginxで同一ホスト内にリバースプロキシしようとするとエラーが出る

環境

  • Amazon EC2
  • Centos7
  • nginx/1.12.0 (80port)
  • puma (3000port)

状況

例えば、/etc/nginx/conf.d/default.confに以下のような設定をした時、

/etc/nginx/conf.d/default.conf
server {
    listen       80;
    server_name  localhost;

   location / {
    proxy_pass http://localhost:3000/;
    }
}

ブラウザで接続してもつながらない。3000ポート直打ちだとアクセスできる。また、なぜか別ホストに変えてみるとプロキシできる。  
curlでレスポンスを確認してみる。

$ curl -L -I xxx.com
HTTP/1.1 502 Bad Gateway
Server: nginx/1.12.0
Date: Thu, 01 Jun 2017 08:34:06 GMT
Content-Type: text/html
Content-Length: 537
Connection: keep-alive
ETag: "xxxxxxxxxx-xxx"

502が出ている。
また、nginxのログを確認すると、

/var/log/nginx/error.log
2017/06/01 08:38:16 [crit] 27144#27144: *1 connect() to 127.0.0.1:3000 failed (13: Permission denied) while connecting to upstream, client: xxx.xxx.xxx.xxx, server: localhost, request: "HEAD / HTTP/1.1", upstream: "http://127.0.0.1:3000/", host: xxx.com"
2017/06/01 08:38:16 [warn] 27144#27144: *1 upstream server temporarily disabled while connecting to upstream, client: xxx.xxx.xxx.xxx, server: localhost, request: "HEAD / HTTP/1.1", upstream: "http://127.0.0.1:3000/", host: "xxx.com"
2017/06/01 08:38:16 [crit] 27144#27144: *1 connect() to [::1]:3000 failed (13: Permission denied) while connecting to upstream, client: xxx.xxx.xxx.xxx, server: localhost, request: "HEAD / HTTP/1.1", upstream: "http://[::1]:3000/", host: "xxx.com"
2017/06/01 08:38:16 [warn] 27144#27144: *1 upstream server temporarily disabled while connecting to upstream, client: xxx.xxx.xxx.xxx, server: localhost, request: "HEAD / HTTP/1.1", upstream: "http://[::1]:3000/", host: "xxx.com"

どうやら権限の関係でうまくプロキシ出来ていないよう。しかしnginxの実行ユーザをrootにしてみても解消されない。

解決策

どうやらSELinuxが効いているせいらしい。EC2では初期は無効だった気がするが有効になっていたみたい。この辺はディストリビューションによって違うのかも?

httpd_can_network_connectを許可してやることで接続できるようになるはず。

$ sudo setsebool httpd_can_network_connect on -P

確認してみます。

$ curl -L -I xxx.com
HTTP/1.1 200 OK
Server: nginx/1.12.0
Date: Thu, 01 Jun 2017 08:40:36 GMT
Content-Type: text/html; charset=utf-8
Connection: keep-alive
~~~~~~~~~~~~~~~~~~~~

接続できました。

結論

私はSELinuxを切って解決しました。

続きを読む