AWS CodeCommit + Git (https) を OSX から SourceTreeで使う

はじめに

AWSでWEBサービスを作るにあたり、CodeCommit を使ってソースを管理しようと思い、AWS CodeCommit を利用することにしたのでその準備方法などを整理&メモとして残す。サーバ側を python3 で開発するつもりなので、python 周辺のツールを色々と使っているけど、pythonとか使いたく無い…って人は、別の道を探した方が良いと思う。

前提

ほとんど開発用のツール・ライブラリが入っていないことを前提にしているのだけど、まっさらな OSX を用意したわけで無いので、エラーが発生するような場合は、それぞれ解決が必要。たぶん、pip とか…。

CodeCommit の作成など

下記のサイトとかを参考に、CodeCommit上にGitリポジトリを作り、アクセス用のアカウントを準備する。非常にざっくり・簡単に言えば、(1)AWS IAM でユーザを作って、(2)CodeCommit でリポジトリを作って、(3)AWS IAM で認証情報を生成する…といった流れ。

AWS Code Commitでgitリポジトリを作る

実は、この状態で OSXのコマンドプロンプトから git clone コマンドを叩くと、ユーザID・パスワードを入力すれば普通にクローンできる。だけど、コマンドは何かと不便なので、SourceTreeを使うためにおまじないが必要。

AWS CLI をインストール

下記のサイトなどを見る限り、SourceTree が認証をパスするためには、awsコマンドが存在しないといけない模様。なので、awscli をインストールするのだけど…ついでに、pythonのバージョン更新も行う。

AWS CODECOMMIT WITH SOURCETREE

OSX:python2.7 から python3 に変更

下記のサイトを参考に、OSX の python を python3.6.3 に変更。特に必要性は無いのだけど、サーバ側のバージョンを 3.6系にするつもりなので、環境を一致させる意味でも変更する。

MacOSとHomebrewとpyenvで快適python環境を。

AWS CLI のインストール

python (pip) の環境が揃っているなら非常に簡単。以下のコマンドでインストール。エラー(不足ライブラリなど)は適当に処理すべし。

sudo pip install awscli

AWS接続用の資格情報を作成

awsコマンドを使って、接続用の資格情報を作成。AWS IAM で作ったユーザの資格情報が必要になるので準備しておく。

aws configure --profile << 適当な名称 >>

AWS Access Key ID [None]: << ユーザー名 >>
AWS Secret Access Key [None]: << パスワード >>
Default region name [None]: << リージョン名 >>
Default output format [None]: 

#上記の << ... >> は、適宜置き換え

SourceTreeで Clone から Push まで

ひとまず、SourceTreeを使って、リポジトリを clone する。認証情報を聞いてきたり、KeyChain へのアクセス許可を聞いてきたりと若干忙しいけど、特に問題ない…はず。

ただし、このままでは ローカルへの commit はできても、サーバへの pull も push もできないので、config ファイルに追記する。

configへの追記
[credential]    
    helper = !aws --profile << 適当な名称 >> codecommit credential-helper $@
    UseHttpPath = true

# << 適当な名称 >> は、aws configure で使った名称。

まとめ

ssh でやれば良かった… なんて野暮なことは言ったらダメなのだと思うけど、https 経由でも無事に SourceTree が使える模様。

続きを読む

vue-cliで作成したSPAにシンプルにCognitoログインを組み込む

この記事は、Vue.js Advent Calendar 2017 13日目の記事です。

vue-cliを使って作成されたプロジェクトにCognitoを使ったユーザーログイン機能を組み込んでみたいと思います。

前提

環境

$ node -v
v8.1.3
$ vue -V
2.9.2

使用したライブラリなど

  • amazon-cognito-identity-js 1.28.0
  • aws-sdk 2.168.0

手順

以下の手順では、vue-cliでvue initした状態のプロジェクトから変更・追加のあるファイルについて実際のコードと、説明を記載していきます。記載のないものに関しては、手を加えていません。

プロジェクトのセットアップ

まずは、vue-cliでプロジェクトを作成します。
(vue-routerを使用するようにセットアップ)

$ vue init webpack
...

次に必要なパッケージをインストールします。

$ npm i aws-sdk --save
$ npm i amazon-cognito-identity-js --save

amazon-cognito-identity-jsはJavaScriptからCognitoを使い際には定番のライブラリです。

Cognito UserPoolなどのAWSに関する情報を設定ファイルに記述します。
今回は、src/config.jsというファイルを作成しました。

src/config.js
export default {
  Region: 'ap-northeast-1',
  UserPoolId: 'ap-northeast-1_XXXXXXXXX',
  ClientId: 'YYYYYYYYYYYYYYYYYYYYYYYYYY',
  IdentityPoolId: 'ap-northeast-1:XXXXXXXX-YYYY-XXXX-YYYY-XXXXXXXXXXXX'
}

Cognito User Pool、Cognito Identity Pool の作成に関しては、次の記事を参考にしてください。
Angular+Cognitoのユーザー認証付きSPAのサンプル

Cognitoサービス

cognito関連の処理をプラグインとして実装するため、新しくファイルを作成します。
今回は、src/cognito以下に次の2ファイルを作成しました。

src/cognito/cognito.js
import {
  CognitoUserPool,
  CognitoUser,
  AuthenticationDetails,
  CognitoUserAttribute
} from 'amazon-cognito-identity-js'
import { Config, CognitoIdentityCredentials } from 'aws-sdk'

export default class Cognito {
  configure (config) {
    if (config.userPool) {
      this.userPool = config.userPool
    } else {
      this.userPool = new CognitoUserPool({
        UserPoolId: config.UserPoolId,
        ClientId: config.ClientId
      })
    }
    Config.region = config.region
    Config.credentials = new CognitoIdentityCredentials({
      IdentityPoolId: config.IdentityPoolId
    })
    this.options = config
  }

  static install = (Vue, options) => {
    Object.defineProperty(Vue.prototype, '$cognito', {
      get () { return this.$root._cognito }
    })

    Vue.mixin({
      beforeCreate () {
        if (this.$options.cognito) {
          this._cognito = this.$options.cognito
          this._cognito.configure(options)
        }
      }
    })
  }

  /**
   * username, passwordでサインアップ
   * username = emailとしてUserAttributeにも登録
   */
  signUp (username, password) {
    const dataEmail = { Name: 'email', Value: username }
    const attributeList = []
    attributeList.push(new CognitoUserAttribute(dataEmail))
    return new Promise((resolve, reject) => {
      this.userPool.signUp(username, password, attributeList, null, (err, result) => {
        if (err) {
          reject(err)
        } else {
          resolve(result)
        }
      })
    })
  }

  /**
   * 確認コードからユーザーを有効化する
   */
  confirmation (username, confirmationCode) {
    const userData = { Username: username, Pool: this.userPool }
    const cognitoUser = new CognitoUser(userData)
    return new Promise((resolve, reject) => {
      cognitoUser.confirmRegistration(confirmationCode, true, (err, result) => {
        if (err) {
          reject(err)
        } else {
          resolve(result)
        }
      })
    })
  }

  /**
   * username, passwordでログイン
   */
  login (username, password) {
    const userData = { Username: username, Pool: this.userPool }
    const cognitoUser = new CognitoUser(userData)
    const authenticationData = { Username: username, Password: password }
    const authenticationDetails = new AuthenticationDetails(authenticationData)
    return new Promise((resolve, reject) => {
      cognitoUser.authenticateUser(authenticationDetails, {
        onSuccess: (result) => {
          // 実際にはクレデンシャルなどをここで取得する(今回は省略)
          resolve(result)
        },
        onFailure: (err) => {
          reject(err)
        }
      })
    })
  }

  /**
   * ログアウト
   */
  logout () {
    this.userPool.getCurrentUser().signOut()
  }

  /**
   * ログインしているかの判定
   */
  isAuthenticated () {
    const cognitoUser = this.userPool.getCurrentUser()
    return new Promise((resolve, reject) => {
      if (cognitoUser === null) { reject(cognitoUser) }
      cognitoUser.getSession((err, session) => {
        if (err) {
          reject(err)
        } else {
          if (!session.isValid()) {
            reject(session)
          } else {
            resolve(session)
          }
        }
      })
    })
  }
}

上記では、登録、確認コードからの承認、ログイン、ログアウト、セッションの確認のロジックを実装しています。
基本的には、amazon-cognito-identity-jsで用意されているメソッドをPromiseでラップしているだけです。
注意する点は、installメソッドでVueプラグインとして記述している点です。
詳細は、以下の記事が参考になりました。

index.jsは次のようになります。

src/cognito/index.js
import Vue from 'vue'
import Cognito from './cognito'
import config from './../config'

Vue.use(Cognito, config)

export default new Cognito()

上記で作成したcognito関連の処理をプラグインとしてVueインスタンスに登録します。
main.jsを次のように編集します。

src/main.js
import Vue from 'vue'
import App from './App'
import router from './router'
import cognito from './cognito'

Vue.config.productionTip = false

/* eslint-disable no-new */
new Vue({
  el: '#app',
  router,
  cognito,
  template: '<App/>',
  components: { App }
})

コンポーネント

ログイン

ログイン画面は次のようになります。

src/components/Login.vue
<template>
  <div class="login">
    <h2>ログイン</h2>
    <form @submit.prevent="login">
      <div>
        ユーザー名:
        <input type="text" placeholder="username" v-model="username" required>
      </div>
      <div>
        パスワード:
        <input type="password" placeholder="password" v-model="password" required>
      </div>
      <button>ログイン</button>
    </form>
    <router-link to="/confirm">確認コード入力</router-link>
    <router-link to="/singup">ユーザー登録</router-link>
  </div>
</template>

<script>
export default {
  name: 'Login',
  data () {
    return {
      username: '',
      password: ''
    }
  },
  methods: {
    login () {
      this.$cognito.login(this.username, this.password)
        .then(result => {
          this.$router.replace('/home')
        })
        .then(err => {
          this.error = err
        })
    }
  }
}
</script>
...

cognito.jsに実装したlogin ()メソッドにフォームから取得したユーザー名(メールアドレス)とパスワードを渡します。
ログインに成功した場合、ここではホーム画面(HelloWorld)に遷移させています。

ユーザー登録

ユーザー登録画面は次のようになります。

src/components/Signup.vue
<template>
  <div class="signup">
    <h2>ユーザー登録</h2>
    <form @submit.prevent="singup">
      <div>
        メール:
        <input type="text" placeholder="メール" v-model="username" required>
      </div>
      <div>
        パスワード:
        <input type="password" placeholder="パスワード" v-model="password" required>
      </div>
      <div>
        パスワード(確認):
        <input type="password" placeholder="パスワード(確認)" v-model="passwordConfirm" required>
      </div>
      <button>登録</button>
    </form>
    <router-link to="/login">ログイン</router-link>
    <router-link to="/confirm">確認コード入力</router-link>
  </div>
</template>

<script>
export default {
  name: 'Signup',
  data () {
    return {
      username: '',
      password: '',
      passwordConfirm: ''
    }
  },
  methods: {
    singup () {
      if (this.username && (this.password === this.passwordConfirm)) {
        this.$cognito.signUp(this.username, this.password)
          .then(resutl => {
            // 登録に成功したら、確認コードの入力画面を表示
            this.$router.replace('/confirm')
          })
          .catch(err => {
            console.log(err)
          })
      }
    }
  }
}
</script>
...

ログインに成功した場合、確認コードの入力画面に遷移させています。

確認コードの入力

Cognitoでは、ユーザーアカウント確認のフローに幾つかの種類がありますが、今回は登録メールアドレスに、確認コードを送信し、
確認コード入力画面から確認をするというフローでユーザーを登録します。

確認コードの入力画面は次のようになります。

src/components/Confirm.vue
<template>
  <div class="confirm">
    <h2>確認コード入力</h2>
    <form @submit.prevent="confirm">
      <div>
        メール:
        <input type="text" placeholder="メール" v-model="username" required>
      </div>
      <div>
        パスワード:
        <input type="text" placeholder="確認コード" v-model="confirmationCode" required>
      </div>
      <button>確認</button>
    </form>
    <router-link to="/login">ログイン</router-link>
    <router-link to="/singup">ユーザー登録</router-link>
  </div>
</template>

<script>
export default {
  name: 'Confirm',
  data () {
    return {
      username: '',
      confirmationCode: ''
    }
  },
  methods: {
    confirm () {
      this.$cognito.confirmation(this.username, this.confirmationCode)
        .then(result => {
          this.$router.replace('/login')
        })
        .then(err => {
          this.error = err
        })
    }
  }
}
</script>
...

ルーター

src/router/index.js
import Vue from 'vue'
import Router from 'vue-router'
import HelloWorld from '@/components/HelloWorld'
import cognito from '@/cognito'
import Login from '@/components/Login'
import Signup from '@/components/Signup'
import Confirm from '@/components/Confirm'

Vue.use(Router)

const requireAuth = (to, from, next) => {
  cognito.isAuthenticated()
    .then(session => {
      next()
    })
    .catch(session => {
      next({
        path: '/login',
        query: { redirect: to.fullPath }
      })
    })
}

const logout = (to, from, next) => {
  cognito.logout()
  next('/login')
}

export default new Router({
  mode: 'history',
  routes: [
    { path: '/',
      redirect: 'home'
    },
    {
      path: '/home',
      name: 'HelloWorld',
      component: HelloWorld,
      beforeEnter: requireAuth
    },
    {
      path: '/login',
      name: 'Login',
      component: Login
    },
    {
      path: '/singup',
      name: 'Signup',
      component: Signup
    },
    {
      path: '/confirm',
      name: 'Confirm',
      component: Confirm
    },
    { path: '/logout',
      beforeEnter: logout
    }
  ]
})

未ログインのユーザーがHelloWorld(ルート)へアクセスするのを許可しない、logoutへのアクセスがあったさいにlogout ()メソッドを実行するという処理には、vue-routerのナビゲーションガード(コンポーネント内ガード)を使っています。

以上で、最低限の機能を組み込むことができました。
実際に使用する際には、ユーザー登録時にusername,password以外の情報を登録する、ログイン後、session情報からAPIコールに必要なidTokenを取得するなどの機能を追加指定必要があるかと思います。

終わりに

このようにamazon-cognito-identity-jsを使うことで比較的簡単にCognitoによるユーザーログイン機能を実現することができます。
今回はログイン部分のみの実装だったため、Vuexは使いませんでしたが、Vuexを使うことを前提としたアプリケーションでは、AWS SDKによる非同期処理部分はStoreのAction内で行ったほうが全体の構成がシンプルになるかと思います。
ざっくりとした内容になってしまいましたが、以上で終わりたいと思います。

明日は、 @SatoTakumiさんです。

続きを読む

AWS AthenaでBigデータ解析

WHY Athena

複数社のASPで吐き出されたフォーマットばらばらの膨大なcsvデータ達を結合しまくってデータ解析せなあかん時ってありますよね

  • いちいちDBサーバー作ってインポートしてらんない
  • いちいちフォーマット合わせてらんない
  • ExcelでVLOOKUPとか処理重すぎてクライアント動かない

そこでAthena

Analytics_AmazonAthena.png

WHAT Athena

  • サーバーレスで環境構築不要
  • S3にファイルを上げてAthenaのコンソール画面でSQL叩くだけで結果出力
  • Prestoベースなので重たいクエリの結果が早い
  • 出力されたデータはcsvでDL可能
  • S3の標準の金額とAthenaのクエリ従量なので安い(クエリのスキャン 1 TB あたり 5 USD)

いいことだらけ

Saving Point

リージョン

実行タイミングが毎日何百回とかでなければS3のリージョンは 米国東部 (バージニア北部) か 米国西部 (オレゴン) がオススメ

Athenaはどのリージョンでも金額は変わらない

スクリーンショット_2017-12-12_14_48_47.jpg

データ圧縮

本データがGZIP圧縮されてればその分スキャンデータが少なくなるので安くなる

列のチューニング

元データに不要な列はなるべく消すこと、消せば消した分だけスキャンデータが少なくなるので安くなる

列指向データ形式(Apache Parquet や Apache ORC)に形式を変換すれば不要な列を読まなくなるのでこれも安くなる

列の削除はExcelやエディタでの編集も良いが、AWS Glueを使うと良い

AWS Glue

Athenaの作業がもっと楽になるやつ
S3の本データをの変換が素早く出来る+Athena用のデータ形式に変換してくれる
他社都合で勝手にデータの列形式とか変わっちゃった時にお役立ち
東京リージョンデビューはもう少しかかる模様なので 米国東部 (バージニア北部) か 米国西部 (オレゴン) で

詳しい使い方はクラスメソッドさんのところ

パーティション

テーブル作成時にパーティション設定することで、クエリの条件に日付関連の方法を入れると、勝手に条件外のデータを読まなくなります

日毎とか週毎、月毎などに分類されるデータはパーティション設定するといいでしょう

パーティションにするにはS3に上げる時にディレクトリを dt=ほにゃらら にしてCREATE文に PARTITIONED BY って書けばいいです

こんな感じ

yakiniku.osushi.sql
CREATE EXTERNAL TABLE IF NOT EXISTS yakiniku.osushi (
  `name` string,
  `media_name` string,
  `media_type` string,
  `device` string,
  `carrier` string,
  `click_date` timestamp,
  `regist_date` timestamp,
  `user_id` string,
  `session_id` string 
) PARTITIONED BY (
  dt string 
)
ROW FORMAT SERDE 'org.apache.hadoop.hive.serde2.lazy.LazySimpleSerDe'
WITH SERDEPROPERTIES (
  'serialization.format' = ',',
  'field.delim' = ','
) LOCATION 's3://yakiniku-tabetai/osushi-tabetai/';

パーティション用のディレクトリを新たに作った場合は、テーブルに認識する必要があるので、Load partitionsしましょう

スクリーンショット_2017-12-12_14_28_15.jpg

Trouble Shooting

クエリは262144バイト以内

クエリが長すぎだとこんな風に怒られます、修正しましょう

Your query has the following error(s):

Your query has exceeded the maximum query length of 262144 bytes. Please reduce the length of your query and try again. If you continue to see this issue after reducing your query length, contact customer support for further assistance. (Service: AmazonAthena; Status Code: 400; Error Code: InvalidRequestException; Request ID: 1effab6b-df02-11e7-820b-c99df83a2b03)

稀にクエリが通らない

最近は頻度は減りましたが、並行で重たいクエリを投げてると稀にエラーになります

サーバレスアーキテクチャ上Lambdaみたいなもんだと思っているので、負荷によるエラーはないと思っているのですが、そういうときは時間を追いて再度実行するとクエリが通ります

S3 SELECTでいいんじゃね?

S3 SELECTはAWS re:Invent 2017で発表されたサービスで、S3にあるデータファイルを直接SELECT分で出力できるみたいです

今はプレビュー版ですが、AWSから許可してもらったので試した所、group by、order by 使えない等の制約があったため使っていません

あとCLI慣れてないと他にも躓くところがあるかもです

ただ、今後今回のようなケース(他社ASPからデータDLして分析)はS3 SELECTで十分になるかもしれません

あくまでAthenaはCLI苦手な人用となるのかも

おわり

続きを読む

AWS Fargate BlueGreenDeployment

はじめに

AWS FargateはContainerインスタンスの管理をAWSにお任せすることができるサービスです。

現状、ECS(LaunchType EC2)を使っているのですが、JenkinsからECSにBlueGreenDeployするときにecs-deployを使っています。
ecs-deployはaws cliとjqには依存していますがshellだけで書かれてるので持ち運びが便利なんですね。

ecs-deployはFargateに対応していないので対応させてみました。

https://github.com/uzresk/ecs-deploy.git

使い方

1. aws cliはFargateに対応しているバージョンをお使いください。

ちなみに私の環境はこちら

aws-cli/1.14.7 Python/2.7.12 Linux/4.9.62-21.56.amzn1.x86_64 botocore/1.8.11

2. コマンドはecs-deployと全く同じです

./ecs-deploy -c [cluster-name] -n [service-name] -i [registry-url]:[tag] -t 300 -r us-east-1

デフォルトのタイムアウトは90秒なのですが、終わらないことが何回かあったので少し長めにしておくのがおススメです。

実行結果

Using image name: xxxx.dkr.ecr.ap-northeast-1.amazonaws.com/xxxx:0.0.1-SNAPSHOT
Current task definition: arn:aws:ecs:us-east-1:xxxx:task-definition/xxxx:25
Current requires compatibilities FARGATE
New task definition: arn:aws:ecs:us-east-1:xxxx:task-definition/xxxx:26
Service updated successfully, new task definition running.
Waiting for service deployment to complete...
Service deployment successful.

変更点

Fargateが追加されたことによりrequiresCompatibilitiesの指定を引き継ぐようにしたのと、
cpu, memoryの設定も合わせて引き継ぐようにしました。
LaunchTypeがEC2の場合はcpu,memoryは設定されません。

[root@ip-10-0-0-100 ecs-deploy]# git diff
diff --git a/ecs-deploy b/ecs-deploy
index 637e793..8ad1cb1 100755
--- a/ecs-deploy
+++ b/ecs-deploy
@@ -261,11 +261,17 @@ function createNewTaskDefJson() {
     fi

     # Default JQ filter for new task definition
-    NEW_DEF_JQ_FILTER="family: .family, volumes: .volumes, containerDefinitions: .containerDefinitions"
+    NEW_DEF_JQ_FILTER="family: .family, volumes: .volumes, containerDefinitions: .containerDefinitions, requiresCompatibilities: .requiresCompatibilities"

     # Some options in task definition should only be included in new definition if present in
     # current definition. If found in current definition, append to JQ filter.
-    CONDITIONAL_OPTIONS=(networkMode taskRoleArn placementConstraints)
+    LAUNCH_TYPE=$(echo "$TASK_DEFINITION" | jq -r '.taskDefinition.requiresCompatibilities[0]')
+    echo "Current requires compatibilities $LAUNCH_TYPE"
+    if [ $LAUNCH_TYPE == FARGATE ]; then
+      CONDITIONAL_OPTIONS=(networkMode taskRoleArn executionRoleArn placementConstraints memory cpu)
+    else
+      CONDITIONAL_OPTIONS=(networkMode taskRoleArn executionRoleArn placementConstraints)
+    fi
     for i in "${CONDITIONAL_OPTIONS[@]}"; do
       re=".*${i}.*"
       if [[ "$DEF" =~ $re ]]; then

おわりに

もう少し動作確認したらプルリクエスト送ろうと思いますが、だいぶメンテされていないようなので多分マージされない気がします。。。

続きを読む

Kubernetes上のアプリケーションログを自動収集する

image.png

TL;DR;

新サービスや既存サービスをKubernetesに移行するたびに、ログの収集設定のためインフラエンジニア待ちになってしまうのは面倒ですよね。
そこで、アプリのログをFluentdとDatadog LogsやStackdriver Loggingで自動的に収集する方法を紹介します。

主に以下のOSSを利用します。

今回はDatadog Logsを使いますが、Stackdriver Loggingを使う場合でもUIやAPIクレデンシャル等の設定以外は同じです。

お急ぎの方へ: アプリ側の設定手順

標準出力・標準エラーログを出力するだけでOKです。

参考: The Twelve-Factor App (日本語訳)

詳しくは、この記事の「サンプルアプリからログを出力する」以降を読んでください。

あとはクラスタ側に用意しておいたFluentdの仕事ですが、Kubernetesがノード上に特定のフォーマットで保存するため、アプリ毎の特別な設定は不要です。

まえおき1: なぜDatadogやStackdriver Loggingなのか

分散ロギングのインフラを準備・運用するのがつらい

分散ロギングと一口にいっても、実現したいことは様々です。例えば、多数のサービス、サーバ、プロセス、コンテナから出力されたログを

  1. 分析などの用途で使いやすいようにETLしてRedshiftのようなデータウェアハウスに投入しておきたい
  2. S3などのオブジェクトストレージに低コストでアーカイブしたい
  3. ほぼリアルタイムでストリーミングしたり、絞込検索したい
    • Web UI、CLIなど

1.はtd-agent + TreasureData or BigQuery、2.はfluentd (+ Kinesis Streams) + S3、3.はfilebeat or Logstash + Elasticsearch + Kibana、Graylog2、専用のSaaSなど、ざっとあげられるだけでも多数の選択肢があります。

方法はともかく、できるだけ運用保守の手間を省いて、コアな開発に集中したいですよね。

メトリクス、トレース、ログを一つのサービスで一元管理したい・運用工数を節約したい

「Kubernetesにデプロイしたアプリケーションのメトリクスを自動収集する – Qiita」でも書きましたが、例えばKubernetesの分散ロギング、分散トレーシング、モニタリングをOSSで実現すると以下のような構成が定番だと思います。

  • 基本的なグラフ作成とメトリクス収集、アラート設定はPrometheus
  • 分散ログはEKF(Elasticsearch + Kibana Fluentd)
  • 分散トレースはZipkinやJaeger

もちろん、ソフトウェアライセンス費用・サポート費用、将来の拡張性などの意味では良い判断だと思います。

一方で、

  • アラートを受けたときに、その原因調査のために3つもサービスを行ったり来たりするのは面倒
  • 人が少ない場合に、セルフホストしてるサービスの運用保守に手間をかけたくない
    • アカウント管理を個別にやるだけでも面倒・・最低限、SSO対応してる?

などの理由で

  • 個別のシステムではなく3つの役割を兼ねられる単一のシステム

がほしいと思うことがあると思います。

fluentd + Datadog Logs/Stackdriver Logging

StackdriverとDatadogはSaaSで、かつ(それぞれサブサービスで、サブサービス間連携の度合いはそれぞれではありますが、)3つの役割を兼ねられます。

SaaSへログを転送する目的でfluentdを利用しますが、Kubernetesのログを収集するエージェントとしてfluentdがよく使われている関係で、Kubernetes界隈でよく使われるfluentdプラグインに関しては、よくある「メンテされていない、forkしないと動かない」という問題に遭遇しづらいというのも利点です。

まえおき2: なぜDatadogなのか

もともとStackdriver Loggingを利用していたのですが、以下の理由で乗り換えたので、この記事ではDatadog Logsの例を紹介することにします。

  • メトリクスやAPMで既にDatadogを採用していた
  • UI面で使いやすさを感じた

UI面に関して今のところ感じている使いやすさは以下の2点です。

  • ログメッセージの検索ボックスでメタデータの補完が可能

    • hostで絞込をしようとすると、hostの値が補完される
    • あとで説明します
  • 柔軟なFaceting
    • Datadog LogsもStackdriver Loggingもログにメタデータを付与できるが、Datadog Logsは任意のメタデータキーで絞り込むためのショートカットを簡単に追加できる
    • あとで説明します

Stackdriver Loggingを利用する場合でも、この記事で紹介する手順はほぼ同じです。Kubernetesの分散ロギングをSaaSで実現したい場合は、せっかくなので両方試してみることをおすすめします。

Fluentdのセットアップ手順

DatadogのAPIキー取得

Datadog > Integratinos > APIsの「New API Key」から作成できます。

image.png

以下では、ここで取得したAPIキーをDD_API_KEYという環境変数に入れた前提で説明を続けます。

fluentdのインストール

今回はkube-fluentdを使います。

$ git clone git@github.com:mumoshu/kube-fluentd.git
$ cd kube-fluentd

# 取得したAPIキーをsecretに入れる
$ kubectl create secret generic datadog --from-literal=api-key=$DD_API_KEY

# FluentdにK8Sへのアクセス権を与えるためのRBAC関連のリソース(RoleやBinding)を作成
$ kubectl create -f fluentd.rbac.yaml

# 上記で作成したsecretとRBAC関連リソースを利用するfluentd daemonsetの作成
$ kubectl create -f fluentd.datadog.daemonset.yaml

設定内容の説明

今回デプロイするfluentdのmanifestを上から順に読んでみましょう。

kind: DaemonSet

Kubernetes上のアプリケーションログ(=Podの標準出力・標準エラー)は各ノードの/var/log/containers以下(より正確には、そこからsymlinkされているファイル)に出力されます。それをfluentdで集約しようとすると、必然的に各ノードにいるfluentdがそのディレクトリ以下のログファイルをtailする構成になります。fluentdに限らず、何らかのコンテナをデプロイしたいとき、KubernetesではPodをつくります。Podを各ノードに一つずつPodをスケジュールするためにはDaemonSetを使います。

  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1

DaemonSetをアップデートするとき(例えばDockerイメージを最新版にするためにタグの指定を変える)、Podを1つずつローリングアップデートします。アップデートによってfluentdが動かなくなった場合の影響を抑えることが目的ですが、気にしない場合はこの設定は記述は不要です。

serviceAccountName: fluentd-cloud-logging

kubectl -f fluent.rbac.yamlで作成されたサービスアカウントを利用する設定です。これがないとデフォルトのサービスアカウントが使われてしまいますが、ほとんどのツールでつくられたKubernetesクラスタではデフォルトのサービスアカウントに与えられる権限が絞られているので、デフォルトのサービスアカウントではkube-fluentdが動作しない可能性があります。

      tolerations:
      - operator: Exists
        effect: NoSchedule
      - operator: Exists
        effect: NoExecute
      - operator: Exists

KubernetesのMasterノードや、その他taintが付与された特定のワークロード専用のWorkerノード含めて、すべてのノードにfluentd podをスケジュールための記述です。何らかの理由でfluentdを動作させたくないノードがある場合は、tolerationをもう少し絞り込む必要があります。

env:
        - name: DD_API_KEY
          valueFrom:
            secretKeyRef:
              name: datadog
              key: api-key
        - name: DD_TAGS
          value: |
            ["env:test", "kube_cluster:k8s1"]

一つめは、secretに保存したDatadog APIキーを環境変数DD_API_KEYにセットする、二つめはfluentdが収集したすべてのログに二つのタグをつける、という設定です。タグはDatadogの他のサブサービスでもよく見られる形式で、”key:value”形式になっています。

Datadogタグのenvは、Datadogで環境名を表すために慣習的に利用されています。もしDatadogでメトリクスやトレースを既に収集していて、それにenvタグをつけているのであれば、それと同じような環境名をログにも付与するとよいでしょう。

kube_clusterは個人的におすすめしたいタグです。Kubernetesクラスタは複数同時に運用する可能性があります。このタグがあると、メトリクスやトレース、ログをクラスタ毎に絞り込むことができ、何か障害が発生したときにその原因が特定のクラスタだけで起きているのかどうか切り分ける、などの用途で役立ちます。

        ports:
        - containerPort: 24231
          name: prometheus-metrics

「Kubernetesにデプロイしたアプリケーションのメトリクスを自動収集する」で紹介した方法でdd-agentにfluentdのPrometheusメトリクスをスクレイプさせるために必要なポートです。

サンプルアプリからログを出力する

適当なPodを作成して、testmessage1というメッセージを出力します。

$ kubectl run -it --image ruby:2.4.2-slim-stretch distlogtest-$(date +%s) -- ruby -e 'puts %q| mtestmessage1|; sleep 60'

ログの確認

何度か同じコマンドを実行したうえで、DatadogのLog Explorerでtestmessage1を検索してみると、以下のようにログエントリがヒットします。

image.png

ログエントリを一つクリックして詳細を開いてみると、testmessage1というログメッセージの他に、それに付随する様々なメタデータが確認できます。

image.png

ログエントリに自動付与されたメタデータの確認

  • HOST: ログを出力したPodがスケジュールされているホスト名(=EC2インスタンスのインスタンスID)
  • SOURCE: コンテナ名
  • TAGS: Datadogタグ
    • pod_name: Pod名
    • kube_replicaset: ReplicaSet名
    • container_name: Dockerコンテナ名
    • kube_namespace: PodがスケジュールされているNamespace名
    • host: PodがスケジュールされているKubernetesノードのEC2インスタンスID
    • zone: Availability Zone
    • aws_account_id: AWSアカウントID
    • env: 環境名

Log Explorerを使うと、すべてのAWSアカウントのすべてのKubernetesクラスタ上のすべてのPodからのログが一つのタイムラインで見られます。それを上記のようなメタデータを使って絞り込むことができます。

ログエントリの絞り込み

ログエントリの詳細から特定のタグを選択すると、「Filter by」というメニュー項目が見つかります。

image.png

これを選択すると、検索ボックスに選択したタグがkey:value形式で入力された状態になり、そのタグが付与されたログエントリだけが絞り込まれます。

もちろん、検索ボックスに直接フリーワードを入力したり、key:value形式でタグを入力してもOKです。

Facetingを試す

定型的な絞り込み条件がある場合は、Facetを作成すると便利です。

ログエントリの詳細から特定のタグを選択すると、「Create new facet」というメニュー項目が見つかります。

image.png

これを選択すると、以下のようにどのような階層のどのような名前のFacetにするかを入力できます。

image.png

例えば、

  • Path: kube_namespace
  • Name: Namespace
  • Group: Kubernetes

のようなFacetを作成すると、ログエントリに付与されたkube_namespaceというタグキーとペアになったことがある値を集約して、検索条件のショートカットをつくってくれます。実際のNamespace Facetは以下のように見えます。

image.png

kube-system、mumoshu、istio-system、defaultなどが表示されていますが、それぞれkube_namespaceというタグキーとペアになったことがある値(=クラスタに実在するNamespace名)です。また、その右の数値はそのNamespaceから転送されたログエントリの件数です。この状態で例えばistio-systemを選択すると、kube_namespace:istio-systemというタグが付与されたログエントリだけを絞り込んでみることができます。

image.png

アーカイブ、ETLパイプラインへの転送など

kube-fluentdにはアーカイブやETLパイプラインのサポートは今のところないので、必要に応じてはfluentd.confテンプレート変更して、それを含むDockerイメージをビルドしなおす必要があります。

fluentd.confテンプレートは以下の場所にあります。

https://github.com/mumoshu/kube-fluentd/blob/master/rootfs/etc/confd/templates/fluent.conf.tmpl

fluentd.confテンプレートから参照できる環境変数を追加したい場合は、以下のconfd設定ファイルを変更します。

https://github.com/mumoshu/kube-fluentd/blob/master/rootfs/etc/confd/conf.d/fluent.conf.toml

// 今後、configmap内に保存したfluent.confの断片をfluentdの@includeを使ってマージしてくれるような機能を追加してもよいかもしれませんね。

まとめ

FluentdとDatadog Logsを使って、Kubernetes上のアプリケーションログを自動的に収集し、Datadog LogsのWeb UIからドリルダウンできるようにしました。

アプリ側はTwelve-Factor Appに則って標準出力・標準エラーにログを出力するだけでよい、という簡単さです。ドリルダウンしたり、そのためのFacetを作成するときも、グラフィカルな操作で完結できます。

また、ログの収集をするためだけにいちいちインフラエンジニアが呼び出されることもなくなって、楽になりますね!

Kubernetes上のアプリケーションの分散ロギングを自動化したい方は、ぜひ試してみてください。

(おまけ) 課題: ログメッセージに含まれるメタデータの抽出

Stackdriver Loggingではできて、Datadog Logsでは今のところできないことに、ログメッセージに含まれるメタデータの抽出があります。

例えば、Stackdriver Loggingの場合、

  • ログにメタデータを付与して検索対象としたい

    • 例えば「ログレベルDEBUGでHello World」のようなログを集約して、Web UIなどから「DEBUGレベルのログだけを絞り込みたい」

というような場合、アプリからは1行1 jsonオブジェクト形式で標準出力に流しておいて、fluent-plugin-google-cloud outputプラグイン(kube-fluentd内で利用しているプラグイン)でStackdriver Loggingに送ると、jsonオブジェクトをパースして、検索可能にしてくれます。

例えば、

{"message":"Hello World", "log_level":"info"}

のようなログをStackdriver Loggingにおくると、log_levelで検索可能になる、ということです。

このユースケースに対応する必要がある場合は、いまのところDatadog LogsではなくStackdriver Loggingを採用するとよいと思います。

今後の展望

同じくkube-fluentdでDatadog Logsへログを転送するために利用しているfluent-plugin-datadog-logに、fluent-plugin-google-cloudと同様にJSON形式のログをパースしてDatadogのタグに変換する機能を追加することはできるかもしれません。

また、Datadog Logsには、ログエントリのメッセージ部分に特定のミドルウェアの標準的な形式のログ(例えばnginxのアクセスログ)が含まれる場合に、それをよしなにパースしてくれる機能があります。その場合にログエントリに付与されるメタデータは、タグではなくアトリビュートというものになります。アトリビュートはタグ同様に検索条件に利用することができます。

ただ、いまのところfluent-plugin-datadog-logからの出力はすべてsyslog扱いになってしまっており、ログの内容によらず以下のようなアトリビュートが付与されてしまっています。

image.png

JSONをパースした結果がこのアトリビュートに反映されるような実装が可能であれば、それが最適なように思えます。

続きを読む

Cloud9 on Fargate など模索の経過報告

こんなの書いていきます

  • 利用例
  • 小ネタ

利用例

この辺に使えないかと模索しています

  • ECS のあふれたタスク処理
  • 踏み台サーバ
  • Cloud9 リモートサーバ

ECS のあふれたタスク処理

aws ecs describe-clusters--include "STATISTICS" を付与すると返ってくる pendingEC2TasksCount が 1 以上であれば run-task--launch-type FARGATE を指定。
とはいえスケーリングの設定やアプリケーションの作り次第では必ずしもこの負荷の逃がし方が適切でもなく、目下思案中。

踏み台サーバ

多段 SSH するときだけ起動する EC2 はありませんか?
Fargate にしてしまいましょう。

これくらいあれば最低限動きそうです。
https://github.com/pottava/fargate-shell/tree/master/serverless-bastion/docker

  • sshd に -d をつけて起動 することで、セッションが切れたら Fargate も落ちる
  • パスワード、または公開鍵認証(鍵は S3 を経由して配布)
  • sudo させるかどうかを環境変数 ENABLE_SUDO で制御

Docker イメージとして踏み台を管理できれば、これをベースに作業内容をログに残したり、渡す IAM タスクロールで AWS-CLI の利用できるコマンドを制限したりもある程度自由にカスタマイズできそうです。

Cloud9 リモートサーバ

Fargate で Cloud9 のリモートサーバを管理すれば、Docker イメージで作業者の環境を管理できそうです。ベースイメージはこんな感じ。
https://github.com/pottava/fargate-shell/blob/master/serverless-cloud9/docker/Dockerfile

  • AmazonLinux に必要なミドルウェアを入れたもの
  • Cloud9 からの SSH 接続に必要な鍵は S3 を経由して連携

その上で、開発に必要なミドルウェアを載せて、Cloud9 のリモートサーバに指定すれば IDE が起動します。例えば go v1.9.2 ならこんな感じ。
https://github.com/pottava/fargate-shell/tree/master/samples/cloud9-go1.9

ただし・・

  • docker in docker できないため、Cloud9 の
    IDE に c9.ide.lambda.docker はインストールできない
  • 作業が終了したら Fargate を明示的に停止する必要がある

のが惜しい感じになりました。AWS さんのネイティブ対応が待たれます。それにしても Fargate、ハンズオンや Jupyter notebook を配るといったことにも応用できそうです。

小ネタ

(以下 2017/12/12 時点のものであり、また仕様やドキュメントとして記載がないものも取り上げているため、機能追加や特にアナウンスなく変更が入る可能性も十分にありえます)

渡ってくる環境変数

  • AWS_DEFAULT_REGION
  • AWS_REGION
  • AWS_CONTAINER_CREDENTIALS_RELATIVE_URI

最後の変数でタスクに割り当てた IAM ロールを確認できる ものの
コンテナ内であればそのロールは Assume された状態なので
例えば以下のコマンドも同等の情報を返してくれます。普通。
$ aws sts get-caller-identity

渡せない環境変数

EC2 ホストがないので ECS Agent にオプションが渡せない。例えば ECS_ENABLE_CONTAINER_METADATAtrue にしたいけどできない。ECS_CONTAINER_METADATA_FILE が渡ってくると地味に便利なんですが・・

タスク定義の制約

とある理由で docker in docker がしたかったのですが、おそらくセキュリティ上の理由から ECS では設定できる以下の項目が使えません。まあ、はい。

  • linuxParameters/capabilities
  • privileged

awsvpc の制約

Fargate の注意点というわけではないものの、Fargate である以上 awsvpc が避けられないので。
ECS ではコンテナの定義として containerPorthostPort を別にすることができましたが、awsvpc ではそれが許されません。異なったポートを定義すると register-task-definition で弾かれます。

An error occurred (ClientException) when calling the RegisterTaskDefinition operation: When networkMode=awsvpc, the host ports and container ports in port mappings must match.

ENI の上限

起動するコンテナごとに一つ消費されていくので、初期リージョン上限である 350 個が一つのハードルでしょうか。Lambda ほどスケールしてくれませんが、まあ、ユースケース違うしね。ところでいつか awsvpc でない起動方法は追加されるんでしょうか。されない気もしますね・・

続きを読む

Beanstalk運用の日常風景

ハンズラボ Advent Calendar 2017 11日目の記事です。

Elastic Beanstalkの運用をそれなりに続けてきたので、溜め込んだTIPS+失敗事例を放出します。
プラットフォームはPHPです。

Daily Buildしましょう

「いやいやうちはデイリーどころか1日複数回buildしてdeployですよ」という方もいらっしゃるでしょうが、すべてのアプリケーションに対して毎日、というわけではないのでは?
「同じソースコードをeb deployして昨日は通ったのに今日は落ちる」ということがあります。
AWSは日夜プロダクトを改善していて、ユーザとして恩恵に預かっているわけですが、ときに牙をむくことがあります。
ということで、平日の出勤時間帯にdeployスクリプトをスケジュール実行しておいて、deploy成功していると安心して出勤できます。

  • 2016年9月、eb-activity.logにて、ascii以外の文字列が入っているエラーが出てdeploy失敗しました。
    (コメントに入ってもNG)
  • 本番以外の環境で、immutableかrolling with additional batchでのdeploy検証できていると、安心です。この二つはEC2を新規に起動するので、後述のpreinit hookのスクリプトから順に動くためです。
    • と言いつつ、.ebextensionsでシンボリックリンクを貼る、みたいなことをしているときに、already existsで落ちるケースも。本番deployして初めて失敗する、みたいなケースは辛い・・・。

ライブラリのバージョンを固定しましょう

常に最新版のライブラリを適用するのがセキュリティ的には望ましいですが、なかなかそうはいかないのが悩ましいところです。。。
検証環境では最新のライブラリ、本番環境は検証済みライブラリ、とかで分けて管理できればいいのですが・・・。なかなか腰が重いです。

  • とあるpeclライブラリをバージョン指定せずにpecl installしていたところ、最新版がPHP7のみのサポートになってdeployに失敗しました。。。
  • プラットフォームのバージョンは検証環境のみ「管理された更新」を適用しています。これも便利。動作に問題がなければ本番環境へ。

eb-activity.logを読みましょう

Beanstalkが管理しているEC2が起動するときや、Application Versionをdeployするときにeb-activity.logが更新されます。
実際に動いてるのは/opt/elasticbeanstalk/hooks配下のスクリプトです。ここに、.ebextensionsで書いた設定やらシェルスクリプトやらも入ってきます。

$ pwd
/opt/elasticbeanstalk/hooks
$ ls
appdeploy  configdeploy  postinit  preinit  restartappserver
  • deployがtimeoutする原因について調べていたところ、composer updateは–no-devがついて実行されていたのに、composer installはオプション無しで実行されていました。.ebextensionsで記述していないAWS製のdeployスクリプトの中で、EC2新規起動時はcomposer installを実行する作りになっていました。
  • 試行錯誤の結果、下記のようにcomposer_optionsで–no-dev指定することにしました。合わせて、hirakさんのprestissimoを使ってcomposer install/updateの並列実行を実現しています。
    • EC2の起動が遅い問題、C5/M5インスタンスが東京リージョンに来てパッと解決してほしい・・・。
composer.config
commands:
  01_update_composer:
    command: export COMPOSER_HOME=/root && /usr/bin/composer.phar self-update 1.5.2 && /usr/bin/composer.phar global require hirak/prestissimo

option_settings:
  - namespace: aws:elasticbeanstalk:application:environment
    option_name: COMPOSER_HOME
    value: /root
  - namespace: aws:elasticbeanstalk:container:php:phpini
    option_name: composer_options
    value: --no-dev

Time Based Scaling しましょう

Elastic BeanstalkはAuto Scalingもよしなにやってくれますが、スパイクアクセスには弱いです。
日常的にiOS/Androidアプリへモバイルプッシュなどを行っていると、プッシュのタイミングでスパイクアクセスが発生します。
プッシュを登録する担当者と相談して、プッシュ送信する時間帯を制限し、その時間帯はスケールアウトしておくことで対策しています。
BeanstalkだけでなくDynamoDBもTime Based Scalingに対応しましたね!(こちらはまだAWS CLIのみで設定可能・・・)

  • BeanstalkのメトリクスだけではELBへの負荷がわからない場合があります。その場合はELBのメトリクスを参照しましょう。AWS CLIでcloudwatchのメトリクスとるときも、NamespaceはELBのものを使います。
  • CPU負荷、デフォルトの平均じゃなくて最大でみたほうがいいことがあります。CPU使用率の平均40%だから平気平気、と思ってたらELBが503返してて、CPU使用率を最大で見たら90%超えててEC2が死んでた、とかあるので・・・。
  • サポートの方に「503頻発してELB足りないぽいから日常的にPreWarmingお願いします」と依頼したら、「SpillOverCount(過剰数)のカウントが上がっていますのでEC2増やしてください」と返答ありました。AWSサポートの皆様、スキル高くて頼りになります。
  • NLB化も検討したいところ。

まとめ

Elastic Beanstalk、AWSにおまかせできる部分が多くて楽ができますが、特有の癖みたいなものがあるので気をつけて使うと安全安心です。

ハンズラボ Advent Calendar 2017 明日12日目は@sr-mtmtです!

続きを読む

[初心者向け] 実務開始の前に知っておきたいAWSのこと

この投稿は、チュートリアルを終えて実務に入る前の人に知っておいて欲しいことをまとめています。
チュートリアルは終えている前提なので、AWSのサービスに関する説明は省略しています。
ベンチャー企業の複数あるうちの1サービスくらいの規模感のアプリケーションを構築すること(移行ではない)を前提としています。
社内メンバー宛なので偏りがあるかもしれないですが、みなさまの役にも経てば幸いです。

設計に役立つツール

AWSを実務で利用する際は、構成図を書くかと思います。その際に利用できるのが Cloudcraft です。
構成図とともに料金もざっくりわかります。
cloudcraft例.png

もっと詳細に料金を出す必要があるならば、AWSが提供している料金計算ツールを使うと良いかもしれません。
SIMPLE MONTHLY CALCULATOR

また、サーバーレス構成を検討している方は、re:Invent2017で発表された「AWS Serverless Application Repository」を利用すると構成案が公開されていますので、参考になると思います(2017年12/11時点ではまだpreview版)

リザーブドインスタンス

リザーブドインスタンスはEC2やRDSのようなサービスで、前払いをすると料金を節約)できる制度です。 (参考: AWSリザーブドインスタンスについて)
インスタンスタイプや期間によりますが、「半年以上使うことが決まってるなら、1年分はリザーブドインスタンス買っちゃった方がお得」ということも少なくありません
ただし、リザーブドインスタンスはリージョン(もしくはアバイラビリティーゾーン)ごとで、インスタンスタイプも指定するので、インスタンスを立て直したり、何も知らずにインスタンスタイプを変更してしまうと「リザーブドインスタンスを買っているのに使えてない」状態になりえます。
リザーブドインスタンスは売買もできますし、t2.small2つをt2.medium1つに変更などもできるので、一度買ったらできるだけ今の構成を追随するようにしましょう。

IAM

IAMはAWS内の権限をつかさどるサービスです。各種サービスへの参照・書き込み・実行などを細かく設定できます。
権限を操作できてしまうので、一度作るとなかなか変更するのが怖いところです。
ここでのtipsはポリシーはできるだけ細かく設定することです。めんどくさいですが、サービスAのs3参照ポリシーとサービスBのs3参照ポリシーは分けた方が良いと思います。たとえ1つしかサービスをローンチしてなくても、サービスAに限定するようなポリシーを設定しておきましょう。
最小単位であるポリシーが細かければその組み合わせで柔軟に設定が可能です。

awsを操作するためのツール

  • aws-cli … コマンドラインからawsを操作できる
  • ansibleのec2.py … ansibleでipを指定するのではなく、ec2についているタグ名で絞ってec2をプロビジョニングするためのツール(というかpython script)

最後に

クラウドになるとlinuxではないもの(IAMやセキュリティグループなど)の設定をたくさんしなければならず、(aws-cliもありますが)guiでの設定も増えてしまいます。
面倒な部分はありますが、慣れてしまえば早いですし、コスパもよいのでどんどん利用していきたいですね
では、よいaws lifeを

[初心者向け] 実務開始の前に知っておきたいシリーズ

[初心者向け] 実務開始の前に知っておきたいSpreadSheetのこと
[初心者向け] 実務開始の前に知っておきたいAnsibleのこと
[初心者向け] 実務開始の前に知っておきたいGoogleAnalyticsのこと
[初心者向け] 実務開始の前に知っておきたいWordPressのこと
[初心者向け] 実務開始の前に知っておきたいRailsのこと

続きを読む

G Suiteを利用してGAMでユーザーごとの利用できるAWSアカウントとロールを管理する

NIFTY Advent Calendar 2017 11日目の記事になります。

AWSのアカウント管理や認証をどうしていけばいいのか試行錯誤してました。
タイトルから個人的な結論が出ていますが、考えた順に書いていきます。

Microsoft ADで管理してMasterアカウントにログイン後、SubアカウントにSwitch Roleする

AWS_DirectoryService.png

IDaaSやADを自前で持っていない場合は、すべてがAWSで完結するからこれが綺麗だと思う。

AWS公式の提案手法

マルチアカウントにする意義と、そのためのアカウント間の構成を教えてくれるので、読んだことがない方は一度こちらを読んでおくことをオススメします。

上記の構成を実現するためのCloud Formationのサンプルなども提供されている。

OpenAMをIdpとしてAWSにSAML認証でログインする

OpenAM.png

すでにLDAPを持っていて、できるだけ内部で管理したい場合の構成。

OpenAMのグループに対して、利用できるアカウントとロールを付けていく管理がいいのだろうか。
OpenAMがまるで詳しくないので、次いきます。

G SuiteをIdpとしてAWSにSAML認証でログインする

IDaaSとしてはOneloginなど他にもありますが、G Suiteが試しやすかったので、こちらを採用。
G SuiteからSAML認証でAWSにログインするまでの手順は、こちらにまとまっているので、ここでは説明を割愛します。

MasterアカウントのIdpとして登録

G_Suite.png

OpenAMの代わりにIDaaSとしてG Suiteを利用した構成。

G SuiteのBusinessプラン以上でないと監査ログが取れないので、できればBussinessプランにしたい。Basicプランでも構成自体は実現できる。

SubアカウントのIdpとして登録

G_Suite2.png

G Suiteはひとつのアプリから、下記のどの構成もいけるのでMasterアカウントを経由する方法を取る必要はなさそう。

  • Single APP -> Single Account Single Role
  • Single APP -> Single Account Multi Role
  • Single APP -> Multi Account Multi Role

G SuiteユーザーのAWS Console Roleのrole属性に roleのarn,Idpのarn の形で記載する。roleは複数値入れられるように設定されているので、別のSubアカウントの権限も与えたい場合は、これを増やしていけばいい。

管理コンソール.png

G Suiteのアプリを選択すると、このようにSwith Roleの選択画面に飛ぶ。

Amazon Web Services Sign In.png

アカウントがIDなのはどうしようもなさそうだが、Role名を工夫すればどのサービスのアカウントか判別できそう。
Role名を統一したい場合は、Chromeの拡張機能とか作ってAWSアカウントIDと名前を置換するとか。
あとで困りそうだけどサービスごとにG Suiteのアプリを分けてしまう手もある。

各Subアカウントに対してIdpを設定する必要があるが、Cloud Formationでかなりの部分は吸収できるし、そもそもアカウントをそんなにぽんぽん増やすシーンも思いつかないので、その管理コストよりも利用者の日々の手間をワンステップ減らしたほうが利はあると思う。

GAMでG SuiteのユーザーにAWSの権限を与える

人が増えたり減ったり入れ替わりが起きるごとに、G SuiteのAWS Console Roleを変更するのは辛いので自動化を目指します。
GAMを使えばG Suite APIをCLIで簡単に操作できるので、これを使います。

インストールから基本的な使い方は、以下に詳しく書いてあるので割愛します。

今回修正がしたいのはCustom User Schema Fieldなのでマニュアルはこれ。

試しにさっきのユーザーを 54321 をなくして、 33333 をいうAWSアカウントIDに権限を付けてみます。
注意点としては追加削除という概念はなく、指定したものを上書きする形で指定します。

# gam update user username@example.com \
AWS_Console_Role.role multivalued arn:aws:iam::12345:role/CrossAccountManager-Administrator,arn:aws:iam::12345:saml-provider/G-Suite \
AWS_Console_Role.role multivalued arn:aws:iam::33333:role/CrossAccountManager-Developer,arn:aws:iam::33333:saml-provider/G-Suit
updating user username@example.com...

管理コンソール2.png

ちゃんと更新できてますね。

自動化について

ユーザーごとに管理するのは大変なので、グループごとにアカウントとロールを管理して、そのマスターが更新されるかグループのメンバーが更新されたら、functionが起動してグループ内ユーザーのroleを更新してくれる的なものまでいければ完璧ですが、まだ試していないので今回はここまで。

続きを読む

AWS SDK for JavaScript with Angular で Upload to S3.

欠員が出たということで、穴埋めさせていただきます。

概要

本記事は、AngularAWS SDK for JavaScriptを利用して、S3にファイルをアップロードするという内容です。
Angular メインですので、AWSサービスの使い方や設定については割愛いたします。ご了承ください。

環境

$ uname -a
Linux ip-10-4-0-188 4.9.62-21.56.amzn1.x86_64 #1 SMP Thu Nov 16 05:37:08 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
$ ng -v

    _                      _                 ____ _     ___
   /    _ __   __ _ _   _| | __ _ _ __     / ___| |   |_ _|
  / △  | '_  / _` | | | | |/ _` | '__|   | |   | |    | |
 / ___ | | | | (_| | |_| | | (_| | |      | |___| |___ | |
/_/   __| |_|__, |__,_|_|__,_|_|       ____|_____|___|
               |___/

Angular CLI: 1.5.5
Node: 8.9.1
OS: linux x64
Angular: 5.0.0
... animations, common, compiler, compiler-cli, core, forms
... http, language-service, platform-browser
... platform-browser-dynamic, router

@angular/cli: 1.5.5
@angular-devkit/build-optimizer: 0.0.35
@angular-devkit/core: 0.0.22
@angular-devkit/schematics: 0.0.41
@ngtools/json-schema: 1.1.0
@ngtools/webpack: 1.8.5
@schematics/angular: 0.1.10
@schematics/schematics: 0.0.10
typescript: 2.4.2
webpack: 3.8.1
package.json
{
  "name": "qiita",
  "version": "0.0.0",
  "license": "MIT",
  "scripts": {
    "ng": "ng",
    "start": "ng serve",
    "build": "ng build",
    "test": "ng test",
    "lint": "ng lint",
    "e2e": "ng e2e"
  },
  "private": true,
  "dependencies": {
    "@angular/animations": "^5.0.0",
    "@angular/common": "^5.0.0",
    "@angular/compiler": "^5.0.0",
    "@angular/core": "^5.0.0",
    "@angular/forms": "^5.0.0",
    "@angular/http": "^5.0.0",
    "@angular/platform-browser": "^5.0.0",
    "@angular/platform-browser-dynamic": "^5.0.0",
    "@angular/router": "^5.0.0",
    "core-js": "^2.4.1",
    "rxjs": "^5.5.2",
    "zone.js": "^0.8.14"
  },
  "devDependencies": {
    "@angular/cli": "1.5.5",
    "@angular/compiler-cli": "^5.0.0",
    "@angular/language-service": "^5.0.0",
    "@types/jasmine": "~2.5.53",
    "@types/jasminewd2": "~2.0.2",
    "@types/node": "~6.0.60",
    "codelyzer": "^4.0.1",
    "jasmine-core": "~2.6.2",
    "jasmine-spec-reporter": "~4.1.0",
    "karma": "~1.7.0",
    "karma-chrome-launcher": "~2.1.1",
    "karma-cli": "~1.0.1",
    "karma-coverage-istanbul-reporter": "^1.2.1",
    "karma-jasmine": "~1.1.0",
    "karma-jasmine-html-reporter": "^0.2.2",
    "protractor": "~5.1.2",
    "ts-node": "~3.2.0",
    "tslint": "~5.7.0",
    "typescript": "~2.4.2"
  }
}

手順

1) AWS SDK for JavaScriptをインストール

$ npm i --save-prod aws-sdk

2) src/app/tsconfig.app.json を編集

tsconfig.app.json
{
  "extends": "../tsconfig.json",
  "compilerOptions": {
    "outDir": "../out-tsc/app",
    "baseUrl": "./",
    "module": "es2015",
-    "types": []
+    "types": ["node"]
  },
  "exclude": [
    "test.ts",
    "**/*.spec.ts"
  ]
}

参照: Usage_with_TypeScript

3) S3アップロード用コンポネントを作成

$ ng g component s3-upload
  create src/app/s3-upload/s3-upload.component.css (0 bytes)
  create src/app/s3-upload/s3-upload.component.html (28 bytes)
  create src/app/s3-upload/s3-upload.component.spec.ts (643 bytes)
  create src/app/s3-upload/s3-upload.component.ts (280 bytes)
  update src/app/app.module.ts (408 bytes)

4) 各種ファイルを編集

src/app/app.component.html

+ <app-s3-upload></app-s3-upload>

src/app/app.module.ts

import { BrowserModule } from '@angular/platform-browser';
import { HttpClientModule } from '@angular/common/http';
import { NgModule } from '@angular/core';


import { AppComponent } from './app.component';
import { S3UploadComponent } from './s3-upload/s3-upload.component';
import { S3Service } from './s3-upload/s3.service';

@NgModule({
  declarations: [
    AppComponent,
    S3UploadComponent,
  ],
  imports: [
    BrowserModule,
    HttpClientModule,
  ],
  providers: [
    S3Service,
  ],
  bootstrap: [AppComponent]
})
export class AppModule { }

src/app/s3-upload/s3-upload.html

<div class="form">
  <div class="form-group">
    <label class="col-xs-2">select file</label>
    <div class="col-xs-10">
      <input type="file" (change)="upload($event)">
    </div>
  </div>
</div>
<div class="debug_print">
  <p>httpUploadProgress {{ httpUploadProgress | json }}</p>
</div>

src/app/s3-upload/s3-upload.component.ts

import { Component, OnInit } from '@angular/core';
import { S3Service } from './s3.service';
import * as AWS from 'aws-sdk';

@Component({
  selector: 'app-s3-upload',
  templateUrl: './s3-upload.component.html',
  styleUrls: ['./s3-upload.component.css']
})
export class S3UploadComponent implements OnInit
{
  public httpUploadProgress: {[name: string]: any} = {
    ratio : 0,
    style : {
      width: '0',
    }
  };


  /**
   * @desc constructor
   */
  constructor(private s3Service: S3Service)
  {
    this.s3Service.initialize()
      .subscribe((res: boolean) => {
        if (! res) {
          console.log('S3 cognito init error');
        }
      })
  }


  /**
   * @desc Angular LifeCycle
   */
  ngOnInit()
  {
    this.s3Service.progress
      .subscribe((res: AWS.S3.ManagedUpload.Progress) => {
        this.httpUploadProgress.ratio = res.loaded * 100 / res.total;
        this.httpUploadProgress.style.width = this.httpUploadProgress.ratio + '%';
      });
  }


  /**
   * @desc file upload
   */
  public upload(event: Event): void
  {
    this.httpUploadProgress.ratio = 0;
    this.httpUploadProgress.style.width = '0';
    this.s3Service.onManagedUpload((<HTMLInputElement>event.target).files[0]);
  }
}

src/app/s3-upload/s3.service.ts

import { Injectable, EventEmitter } from '@angular/core';
import { HttpClient, HttpErrorResponse } from '@angular/common/http';
import { Observable } from 'rxjs/Observable';
import 'rxjs/add/observable/of';
import 'rxjs/add/operator/catch';
import 'rxjs/add/operator/map';
import * as AWS from 'aws-sdk';
import { AWS_ENV } from '../../environments/environment';

@Injectable()
export class S3Service
{
  private s3: AWS.S3;
  public progress: EventEmitter<AWS.S3.ManagedUpload.Progress> = new EventEmitter<AWS.S3.ManagedUpload.Progress>();


  constructor(private http: HttpClient) { }


  /**
   * @desc set CognitoIdentityId
   * 
   * @return string IdentityId: ex) ap-northeast-1:01234567-9abc-df01-2345-6789abcd
   */
  public initialize(): Observable<boolean>
  {
    return this.http.get('/assets/cognito.php')
      .map((res: any) => {
        // resに対する例外処理を追加する
        // ...

        // Amazon Cognito 認証情報プロバイダーを初期化します
        AWS.config.region = AWS_ENV.region;
        AWS.config.credentials = new AWS.CognitoIdentityCredentials({
          IdentityId: res.results[0].IdentityId,
        });
        this.s3 = new AWS.S3({
          apiVersion: AWS_ENV.s3.apiVersion,
          params: {Bucket: AWS_ENV.s3.Bucket},
        });
        return true;
      })

      .catch((err: HttpErrorResponse) => {
        console.error(err);
        return Observable.of(false);
      });
  }

  /**
   * @desc AWS.S3
   */
  public onManagedUpload(file: File): Promise<AWS.S3.ManagedUpload.SendData>
  {
    let params: AWS.S3.Types.PutObjectRequest = {
      Bucket: AWS_ENV.s3.Bucket,
      Key: file.name,
      Body: file,
    };
    let options: AWS.S3.ManagedUpload.ManagedUploadOptions = {
      params: params,
      partSize: 64*1024*1024,
    };
    let handler: AWS.S3.ManagedUpload = new AWS.S3.ManagedUpload(options);
    handler.on('httpUploadProgress', this._httpUploadProgress.bind(this));
    handler.send(this._send.bind(this));
    return handler.promise();
  }

  /**
   * @desc progress
   */
  private _httpUploadProgress(progress: AWS.S3.ManagedUpload.Progress): void
  {
    this.progress.emit(progress);
  }

  /**
   * @desc send
   */
  private _send(err: AWS.AWSError, data: AWS.S3.ManagedUpload.SendData): void
  {
    console.log('send()', err, data);
  }
}

src/environments/environment.ts

// The file contents for the current environment will overwrite these during build.
// The build system defaults to the dev environment which uses `environment.ts`, but if you do
// `ng build --env=prod` then `environment.prod.ts` will be used instead.
// The list of which env maps to which file can be found in `.angular-cli.json`.

export const environment = {
  production: false
};

export const AWS_ENV = {
  region: 'YOUR_REGION',
  s3: {
    apiVersion: 'YOUR_VERSION',
    Bucket: 'YOUR_BACKET',
  },
};

5) ビルド&実行&確認

test.png

$ aws s3 ls s3://YOUR_BACKET/
2017-12-10 08:13:54   10485760 10MB.bin

解説

AWS SDKを使ってファイルをアップロードするには、PutObject()を使うのが手っ取り早いですが
JSからファイルをアップロードするときには、UI/UXの観点からプログレスを表示してあげるのがよいので
それに対応したメソッドである、ManagedUpload()を利用しました。

5.0.0 では、zoneを意識することなく、プログレスがきちんとレンダリングされましたので
プログレスバーの実装は容易に行なえます。

以上、穴埋め記事でした。

7日目は、@segawm さんです。

続きを読む