Managed Connect Service (MCS)

高品質な音声技術ソフトフォンを利用. レポート生成エージェント管理権限設定. Managed Connect ServiceはAWS社提供の各サービスとの連携も可能です。 また、テクマトリックス株式会社のFastHelp5などのCRMシステムとの連携も予定しています。 https://www.techmatrix.co.jp/product/fasthelp5/index.html … 続きを読む

Amazon ECS Adds New Endpoint to Access Task Metrics and Metadata

この記事に対して2件のコメントがあります。コメントは「 記事中の https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-metadata-endpoint.html によると、ECS Agent 1.17.0 からの機能。1.17.0 は本日リリースされたばかり( https://github.com/aws/amazon-ecs-agent/releases/tag/v1.17.0 )。 続きを読む

CloudWatch Events と Systems Manager で EC2の起動/停止をスケジュール化する

はじめに

開発環境等のインスタンスは休日や夜間は停止しておくことが多いと思います。
CloudWatch Events と Lambda で実装する例も多くみかけますが、
Systems Managerと組み合わせてノンプログラミングで実装する方法もあります。

Systems Manager 単体でも Maintenance Windows を使用して設定することができますが、
これは別の記事でご紹介できればと考えています。

設定する

IAM ロールの設定と CloudWatch Events のルール作成が必要です。

IAMロールを作成する

EC2 の起動停止は SSM Automation の機能を利用します。
そのため CloudWatch Events が SSM を呼び出すための IAM ロールを作成します。

image.png

ここでは AWS 管理ポリシーの AmazonSSMAutomationRole をアタッチします。
EC2 起動停止するために必要な権限以外も含まれますので、必要に応じてカスタムポリシーを作成してください。
作成後、信頼関係から信頼されたエンティティに events.amazonaws.com を追加します。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": [
          "events.amazonaws.com"
        ]
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

image.png

CloudWatch Events を設定する

起動用ルールの作成

イベントソースの設定でスケジュールを選択し、Cron式でイベントスケジュールを設定します。
例えば平日の午前9時に指定したEC2を起動したい場合は、以下のように設定します。

0 0 ? * 2-6 *

※UTC で設定しますので、日本標準時との時差9時間を考慮する必要があります。

image.png

ルールのスケジュール式ついては以下ドキュメントにも詳細が記載されています。
https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/events/ScheduledEvents.html

次にターゲットの追加から SSM Automation 選択し、以下のように設定します。

  • Doclument: AWS-StartEC2Instance
  • Configure automation parameter(s)
    • InstanceId: 起動したいインスタンスのインスタンスID
  • 既存のロールの使用: 作成した IAM ロールを指定

ロールの作成手順で信頼されたエンティティに events.amazonaws.com を追加していないと、
既存のロールの選択肢に出てきませんので注意してください。

image.png

設定の詳細ボタンからステップ 2:に進み、

  • ルール名称(必須)
  • 説明(任意)

を入力し、ルールを作成すれば完了です。

停止用ルールの作成

起動用ルールと同じ流れですので、画面コピーは割愛します。

ここでは平日の18時に停止を行うと想定し、UTC で以下のように設定します。

0 9 ? * 2-6 *

ターゲットの追加から SSM Automation 選択し、以下のように設定します。

  • Doclument: AWS-StopEC2Instance
  • Configure automation parameter(s)
    • InstanceId: 停止したいインスタンスのインスタンスID
  • 既存のロールの使用: 作成した IAM ロールを指定

設定の詳細ボタンからステップ 2:に進み、

  • ルール名称(必須)
  • 説明(任意)

を入力し、ルールを作成します。

動作確認

設定した時刻に指定したインスタンスが起動および停止することを確認します。
Automation の実行結果については、コンソールでの確認方法は現時点で2通りあり、
EC2コンソールの 自動化 または AWS Systems ManagerコンソールのAutomation から確認することができます。

image.png

CloudWatch Events で結果を監視する

せっかくなので Automation の実行結果についても CloudWatch Events で設定してみます。
新規にルールを作成し、スケジュールではなく、イベントパターンを選択します。
ここでは Automation の失敗またはタイムアウトを監視するため、以下のように詳細を設定します。

  • サービス名: EC2 Simple Systems Manager (SSM)
  • イベントタイプ: Automation
  • Specific detail type(S)

    • EC2 Automation Execution Status-change Notification
  • 特定のステータス

    • Failed, TimedOut

image.png

コンソールで設定できるのは上記項目のみであるため、このままの設定だと今回設定した EC2 起動停止用の
Automation だけでなく、SSM で実行される全ての Automation が監視対象となってしまいます。
条件を更に絞りたい場合は、イベントパターンのプレビューから直接 JSON の編集を行うことができます。

ここでは EC2 の起動停止を行う Automation のみを監視するため、
“detail.Definition” フィールドに Automation ドキュメント名を設定しました。
“resources” フィールドに対象ドキュメントの ARN を指定した場合も同様の結果になります。

{
  "source": [
    "aws.ssm"
  ],
  "detail-type": [
    "EC2 Automation Execution Status-change Notification"
  ],
  "detail": {
    "Definition": [
      "AWS-StartEC2Instance",
      "AWS-StopEC2Instance"
    ],
    "Status": [
      "Failed",
      "TimedOut"
    ]
  }
}

その他にどのような項目を指定できるかについては、以下のドキュメントの
Automation 実行ステータス変更の通知例をご参照ください。

サポートされている各サービスからの CloudWatch イベント イベントの例
AWS Systems Manager イベント
https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/events/EventTypes.html#ssm_event_types

ターゲットの設定では検知した内容の通知方法を設定します。
ここでは SNS の Topic に登録した Email アドレスに通知するよう設定しました。
必要に応じて入力の設定で通知内容を定義します。

image.png

設定の詳細ボタンからステップ 2:に進み、

  • ルール名称(必須)
  • 説明(任意)

を入力し、ルールを作成すれば完了です。
参考になれば幸いです。

参考: イベントパターンにおける実行ロールの指定

前述のとおり、ドキュメントに記載されているイベント例に記載されている内容であれば
イベントパターンの手動編集で条件を絞り込むことができます。

Automation 実行ステータス変更の通知例をドキュメントから抜粋すると以下のとおりです。

{
  "version": "0",
  "id": "d290ece9-1088-4383-9df6-cd5b4ac42b99",
  "detail-type": "EC2 Automation Execution Status-change Notification",
  "source": "aws.ssm",
  "account": "123456789012",
  "time": "2016-11-29T19:43:35Z",
  "region": "us-east-1",
  "resources": ["arn:aws:ssm:us-east-1:123456789012:automation-execution/333ba70b-2333-48db-b17e-a5e69c6f4d1c", 
    "arn:aws:ssm:us-east-1:123456789012:automation-definition/runcommand1:1"],
  "detail": {
    "ExecutionId": "333ba70b-2333-48db-b17e-a5e69c6f4d1c",
    "Definition": "runcommand1",
    "DefinitionVersion": 1.0,
    "Status": "Success",
    "StartTime": "Nov 29, 2016 7:43:20 PM",
    "EndTime": "Nov 29, 2016 7:43:26 PM",
    "Time": 5753.0,
    "ExecutedBy": "arn:aws:iam::123456789012:user/userName"
  }
}

最後の “detail.ExecutedBy” フィールドは実行されたユーザの ARN になっています。
今回のEC2起動停止では、”スケジュール実行で SSM Automation を実行するルール”を定義しているため、
この箇所はイベントルールに設定した実行ロールの assumed-role ARN が含まれる形になります。
これを指定すれば実行元のロールも監視条件に含めることができます。
ただし、実際の assumed-role ARN は以下の形式になります。

"arn:aws:sts::[account-id]:assumed-role/[role-name]/[role-session-name]"

ロールセッション名については、イベントルールの実行ロール設定時に AWS側で設定されるようです。
ロールセッション名がルールの実行毎に変わってしまうと、正常に監視できないことになりますが、
現状の挙動を観察する限りでは、実行ロールの変更を行わない限りは(時間によらず)変化しないようです。

ただしドキュメント等に記載されている仕様ではないため、今後予告なく挙動が変わる可能性が大いにあります。
プロダクション環境等での設定はおすすめできませんので参考情報として最後に記載させていただきました。

続きを読む

Amazon、年末商戦とAWS好調で増収増益 「Alexa絶好調」とベゾスCEO

Amazon、年末商戦とAWS好調で増収増益 「Alexa絶好調」とベゾスCEOhttp://www.itmedia.co.jp/news/articles/1802/02/news069.html米Amazon.comが2月1日(現地時間)に発表した2017年第4四半期(10~12月)決算は、売上高は前年同期比38.%増の604億5300万ドル、純利益は148. 続きを読む

BIG-IP ve Device Trustを確立しよう(失敗編)

はじめに

前回の方法でAWS上にBIG-IP veを2台デプロイしました。ここからHAの設定をしていきたいのですが、そのためにはBIG-IP同士がお互いを認識する必要があります。そのために必要な設定をしていきます。

バージョンは13.1.0.2です。

アドレスの確認

HAを構成したい個々のBIG-IPをDevice、Device同士がお互いを認識することを「Device Trustを確立する」と表現します。Trustを確立するためにはまずお互いのIPアドレスを知る必要があります。
Trustに使うIPアドレスは、アプライアンスでは実通信に利用しないManagement IPを、AWSでは適当なPrivate IPを指定することが推奨されています。

参考資料:https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/bigip-system-device-service-clustering-administration-13-1-0/3.html

今回はAWSですので、デプロイ時に作ったNICのIPアドレス10.0.4.11および10.0.4.12を使いましょう。

NTP同期状態の確認

AWSではあまり意識する必要がありませんが、Deviceが正しい時刻を持っていないとTrustを確立できません。NTP同期状態は念のため確認しておきましょう。

[admin@ip-10-0-4-11:Active:Standalone] ~ # ntpq -np
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*127.127.1.0     .LOCL.          10 l   53   64  377    0.000    0.000   0.000
[admin@ip-10-0-4-11:Active:Standalone] ~ # 

コンフィグ同期用アドレスの設定……のはずだった

Trust確立の前提として、自分にコンフィグ同期用IPアドレスを設定しておく必要があります。このIPアドレスには適当なPrivateアドレスを使うことが推奨されています。

メニューから「Device Management」>「Devices」>自分のデバイスを選択します。続いて上のメニューで「ConfigSync」を選び、Local AddressのIPをドロップダウンから選択します。

image.png

「Update」を押して完了です。

image.png

あ、あれ……。駄目ですか。AWSならいけるかと思ったのですが、アプライアンスと同じManagement IPでは駄目なようです。

残念ながらここで時間切れになってしまったため、来週リベンジします。

続きを読む

boto3を使った一時的なAWS認証情報の取得

概要

IAMロールの切り替えを利用している場合の一時的なAWS認証情報の取得方法について説明します。boto3を使うと、AWS CLIのプロファイル設定をもとに認証情報を簡単に取得することができます。

IAMロールの切り替え

AWS CLIでIAMロールの切り替えを行う場合は、以下のようなプロファイル設定をします。

~/.aws/config
[profile prodaccess]
role_arn = arn:aws:iam::123456789012:role/ProductionAccessRole
source_profile = default

設定内容の詳細については以下のページが参考になります。

IAM ロールの切り替え(AWS Command Line Interface) – AWS Identity and Access Management
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_roles_use_switch-role-cli.html

また、IAMロールの切り替え自体については以下のページが参考になります。

チュートリアル: AWS アカウント間の IAM ロールを使用したアクセスの委任 – AWS Identity and Access Management
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html

boto3を使った一時的なAWS認証情報の取得

使用したバージョンは以下の通りです。
* Python 3.6.4
* boto3 1.5.21

boto3は明示的にIAMロールの切り替えを行わなくても、プロファイル設定を見て必要があれば自動的にIAMロールの切り替えを行ってくれます。そのため、以下のような簡単なPythonコードで一時的なAWS認証情報を取得できます。

credentials.py
import boto3

session = boto3.session.Session(profile_name='prodaccess')
credentials = session.get_credentials()

print('export AWS_ACCESS_KEY_ID={}'.format(credentials.access_key))
print('export AWS_SECRET_ACCESS_KEY={}'.format(credentials.secret_key))
print('export AWS_SESSION_TOKEN={}'.format(credentials.token))

このコードを実行すると以下のような出力が得られます。この出力をシェルで評価すると一時的なAWS認証情報として利用することができます。

$ python3 credentials.py
export AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
export AWS_SESSION_TOKEN=AQoDYXdzEGcaEXAMPLE2gsYULo+Im5ZEXAMPLEeYjs1M2FUIgIJx9tQqNMBEXAMPLECvSRyh0FW7jEXAMPLEW+vE/7s1HRpXviG7b+qYf4nD00EXAMPLEmj4wxS04L/uZEXAMPLECihzFB5lTYLto9dyBgSDyEXAMPLEKEY9/g7QRUhZp4bqbEXAMPLENwGPyOj59pFA4lNKCIkVgkREXAMPLEjlzxQ7y52gekeVEXAMPLEDiB9ST3UusKdEXAMPLE1TVastU1A0SKFEXAMPLEiywCC/Cs8EXAMPLEpZgOs+6hz4AP4KEXAMPLERbASP+4eZScEXAMPLENhykxiHenDHq6ikBQ==

ただし、この方法では認証情報の有効時間を指定できないため、デフォルトの1時間が適用されます。

認証情報の有効時間(DurationSeconds)については以下に記載があります。

AssumeRole – AWS Security Token Service
https://docs.aws.amazon.com/ja_jp/STS/latest/APIReference/API_AssumeRole.html

続きを読む

HDP 2.6.3をAWSにインストール 乞食版

ゴール

AWSの超安いインスタンスに、HDPをインストールして遊ぶ。

インスタンス初期化

Ambari

t2.nano

[ec2-user@ip-172-31 ~]$ free -m
              total        used        free      shared  buff/cache   available
Mem:            990          80         731          12         179         739
Swap:             0           0           0

AWS Amazon Linux スワップファイル作成によりSwap領域のサイズを増やす
https://qiita.com/na0AaooQ/items/278a11ed905995bd16af

現在は1GBあるので、8GBのSwapメモリを追加

grep Mem /proc/meminfo
grep Swap /proc/meminfo
free
uname -a
# /swapfile1 に保存
sudo dd if=/dev/zero of=/swapfile1 bs=1M count=8192
grep Swap /proc/meminfo

ll /swapfile1
sudo chmod 600 /swapfile1
sudo mkswap /swapfile1
ll /swapfile1
swapon -s
free
sudo swapon /swapfile1
free
grep Swap /proc/meminfo

メモリ追加しました。

[ec2-user@ip-172-31 ~]$ free -m
              total        used        free      shared  buff/cache   available
Mem:            990          77          64          12         848         731
Swap:          3083           0        3083
[ec2-user@ip-172-31 ~]$

t2.micro instance作成

Ambari:1台
Master:1台
Slave:3台

image.png

注意事項

RHEL 7.4

Red Hat Enterprise Linux 7.4 (HVM), SSD Volume Type – ami-26ebbc5c

AWS setting

t2.micro instance

Storage setups —

Ambari: EBS 15G
NN/DN: EBS 20G

image.png

image.png

セキュリティ設定

All Traffic, Allow, HDPのセキュリティグループID指定(内部通信を全部許可)
All Traffic, Allow, MyIP (管理者のIPを許可)
これでOK

ssh private key

scp -i amuisekey.pem amuisekey.pem ec2-user@ec2-54-234-94-128.compute-1.amazonaws.com:~/.ssh/id_rsa
# 全部サーバーにアップロード

hosts

自分のMBP /etc/hosts

    127.0.0.1 localhost.localdomain localhost
    ::1 localhost6.localdomain6 localhost6

#外部IP
    10.110.35.23 hdpmaster1.hdp.hadoop hdpmaster1
    10.191.45.41 hdpmaster2.hdp.hadoop hdpmaster2
    10.151.94.30 hdpslave1.hdp.hadoop hdpslave1
    10.151.87.239 hdpslave2.hdp.hadoop hdpslave2
    10.70.78.233 hdpslave3.hdp.hadoop hdpslave3
    10.151.22.30 ambarimaster.hdp.hadoop ambarimaster

AWSサーバーの /etc/hosts

    127.0.0.1 localhost.localdomain localhost
    ::1 localhost6.localdomain6 localhost6

#外部IP
    10.110.35.23 hdpmaster1.hdp.hadoop hdpmaster1
    10.191.45.41 hdpmaster2.hdp.hadoop hdpmaster2
    10.151.94.30 hdpslave1.hdp.hadoop hdpslave1
    10.151.87.239 hdpslave2.hdp.hadoop hdpslave2
    10.70.78.233 hdpslave3.hdp.hadoop hdpslave3
    10.151.22.30 ambarimaster.hdp.hadoop ambarimaster

Install

https://community.hortonworks.com/articles/14512/ambari-on-ec2.html

image.png

続きを読む

{AWS(CloudFront+S3)+Node.js} 署名付きURLの使用したプライベートコンテンツの配信

はじめに

短期間のみ有効な署名付き URL を使用してプライベートコンテンツを配信するにあたり、Node.js環境下での情報が公式にはのっていなかったので、その対応方法をメモとして残します。

公式ガイド
https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/private-content-signed-urls.html

環境準備

  1. プライベートコンテンツを格納するS3のバケットを作成する
  2. 上記バケットを非公開とする
  3. CloudFrontのディストリビューションを作成する
    • CloudFront経由に限り上記S3バケットにアクセス出来る用に設定する
  4. 署名付きURL生成のためにCloudFront のキーペアを作成する
    • この処理だけはAWSアカウント(ルートアカウント)が必要

〇参考URL
https://dev.classmethod.jp/cloud/aws/cf-s3-deliveries-use-signurl/
http://blog.mekachan.net/?p=105

コード実装

現在JavaScriptのaws-sdkライブラリではCloudfrontの署名付きURL生成がサポートされていないため、「aws-cloudfront-sign」ライブラリを活用して対応する

aws-cloudfront-sign

https://www.npmjs.com/package/aws-cloudfront-sign

サンプルコード

// 30分だけ有効な署名付きURLを生成するコード
var cf = require('aws-cloudfront-sign')
var options = {
  keypairId: 'XXXXXX',
  privateKeyPath: 'XXXX/XXXXXX-private-pk-XXXXX.pem',
  expireTime: (new Date().getTime() + 30 * 60 * 1000)
}
// CloudFrontの「Domain Name」を指定する
// https://${Domain Name}/${Origin path(S3バケット内のパス)}
var signedUrl = cf.getSignedUrl('https://dXXX.cloudfront.net/example.mp4', options);
console.log('Signed URL: ' + signedUrl);

options(オプション)の説明

項目 内容
expireTime 有効期限(任意設定:省略時は30秒)指定する際はミリ秒で指定する
keypairId 作成したクラウドフロントキーペアのアクセスキー ID
privateKeyString
または
privateKeyPath
作成したクラウドフロントキーペアの秘密鍵ファイルパス

参考 S3上で署名付きURLを利用するの場合

このケースではクラウドフロントを介しません。
S3上で生成した署名付きURL経由で非公開バケット中のリソースへアクセスする方式です。
特別なライブラリは不要でaws-sdkで対応可能です。

const AWS = require('aws-sdk')

AWS.config.update({
  accessKeyId: 'XXXXXX',
  secretAccessKey: 'XXXXXX'
  // ,
  // region: 'ap-northeast-1'
})
const s3 = new AWS.S3()

const url = s3.getSignedUrl('getObject', {
    Bucket: 'private-bucket',
    Key: 'example.mp4',
    Expires: 60 // 単位は秒
})

console.log(url)

参考(AWS-CLI)の場合

aws cloudfront sign
 --url http://dXXX.cloudfront.net/example.mp4
 --key-pair-id XXXXXX
 --private-key file://C:/XXX-private-pk-XXXXX.pem
 --date-less-than YYYY-mm-dd

続きを読む