What's New Qiita

20190724のAWSに関する記事は18件です。

  • 投稿日：2019-07-24T22:12:42+09:00

SESとPythonでメールの送信者が文字化けしないようにする

Pythonを使ってSESでメールを送る際、送信者（From）に日本語を使うと文字化けします。

https://docs.aws.amazon.com/ja_jp/ses/latest/DeveloperGuide/send-using-sdk-python.html

↑の公式サンプルコードをもとにメールを送信してみます。

文字化けするパターン

まずは何も考えず、そのまま宛先に日本語をセットしたパターンです。

ses_send.py
import boto3
from botocore.exceptions import ClientError

# Replace sender@example.com with your "From" address.
# This address must be verified with Amazon SES.
SENDER = "テスト <hoge+sender@gmail.com>"

# Replace recipient@example.com with a "To" address. If your account 
# is still in the sandbox, this address must be verified.
RECIPIENT = "fuga@gmail.com"

# If necessary, replace us-west-2 with the AWS Region you're using for Amazon SES.
AWS_REGION = "us-east-1"

# The subject line for the email.
SUBJECT = "Amazon SES テスト (SDK for Python)"

# The email body for recipients with non-HTML email clients.
BODY_TEXT = ("Amazon SES テスト (Python)\r\n"
             "This email was sent with Amazon SES using the "
             "AWS SDK for Python (Boto)."
            )

# The HTML body of the email.
BODY_HTML = """<html>
<head></head>
<body>
  <h1>Amazon SES テスト (SDK for Python)</h1>
  <p>This email was sent with
    <a href='https://aws.amazon.com/ses/'>Amazon SES</a> using the
    <a href='https://aws.amazon.com/sdk-for-python/'>
      AWS SDK for Python (Boto)</a>.</p>
</body>
</html>
            """            

# The character encoding for the email.
CHARSET = "UTF-8"

# Create a new SES resource and specify a region.
client = boto3.client('ses',region_name=AWS_REGION)

# Try to send the email.
try:
    #Provide the contents of the email.
    response = client.send_email(
        Destination={
            'ToAddresses': [
                RECIPIENT,
            ],
        },
        Message={
            'Body': {
                'Text': {
                    'Charset': CHARSET,
                    'Data': BODY_TEXT,
                },
            },
            'Subject': {
                'Charset': CHARSET,
                'Data': SUBJECT,
            },
        },
        Source=SENDER
    )
# Display an error if something goes wrong. 
except ClientError as e:
    print(e.response['Error']['Message'])
else:
    print("Email sent! Message ID:"),
    print(response['MessageId'])

実行します。

>python ses_send.py
Email sent! Message ID:
0100016c23fd79b6-efee9a81-212b-4c27-a5b7-81249789bdb0-000000

受信したメール。

MIME-Version: 1.0
Date: Wed, 24 Jul 2019 21:38:32 +0900
From: =?utf-8?Q?=C6=B9=EF=BF=BD?= <hoge+sender@gmail.com>
Subject: =?utf-8?Q?Amazon_SES_=E3=83=86=E3=82=B9=E3=83=88_(SDK_for_Python)?=
Thread-Topic:
 =?utf-8?Q?Amazon_SES_=E3=83=86=E3=82=B9=E3=83=88_(SDK_for_Python)?=
To: "fuga@gmail.com" <fuga@gmail.com>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"

Amazon SES =E3=83=86=E3=82=B9=E3=83=88 (Python)
This email was sent with Amazon SES using the AWS SDK for Python (Boto).

同じテストという文言がFromの部分だけエンコードが違っています。
これは、テスト <hoge+sender@gmail.com>という文字列全体にマルチバイトを考慮しないエンコードがかかることで引き起こされる現象です。

このためメーラーで開いたときに送信者だけが化けてしまいます。

文字化けしないパターン

Fromにセットするときに、送信者とメールアドレスを分けてエンコードがすると文字化けしません。

先ほどのスクリプトに手を加えます。

ses_send.py
import boto3
from botocore.exceptions import ClientError
from email.header import Header # eemail.headerをインポート

# Replace sender@example.com with your "From" address.
# This address must be verified with Amazon SES.

# 送信者の名前とアドレスに変数を分ける
SENDER_NAME = "テスト"
SENDER_ADDR = "hoge+sender@gmail.com"

# Replace recipient@example.com with a "To" address. If your account 
# is still in the sandbox, this address must be verified.
RECIPIENT = "fuga@gmail.com"

# If necessary, replace us-west-2 with the AWS Region you're using for Amazon SES.
AWS_REGION = "us-east-1"

# The subject line for the email.
SUBJECT = "Amazon SES テスト (SDK for Python)"

# The email body for recipients with non-HTML email clients.
BODY_TEXT = ("Amazon SES テスト (Python)\r\n"
             "This email was sent with Amazon SES using the "
             "AWS SDK for Python (Boto)."
            )

# The HTML body of the email.
BODY_HTML = """<html>
<head></head>
<body>
  <h1>Amazon SES テスト (SDK for Python)</h1>
  <p>This email was sent with
    <a href='https://aws.amazon.com/ses/'>Amazon SES</a> using the
    <a href='https://aws.amazon.com/sdk-for-python/'>
      AWS SDK for Python (Boto)</a>.</p>
</body>
</html>
            """            

# The character encoding for the email.
CHARSET = "UTF-8"

# Create a new SES resource and specify a region.
client = boto3.client('ses',region_name=AWS_REGION)

# Try to send the email.
try:
    #Provide the contents of the email.
    response = client.send_email(
        Destination={
            'ToAddresses': [
                RECIPIENT,
            ],
        },
        Message={
            'Body': {
                'Text': {
                    'Charset': CHARSET,
                    'Data': BODY_TEXT,
                },
            },
            'Subject': {
                'Charset': CHARSET,
                'Data': SUBJECT,
            },
        },
        # Header関数を使いISO-2022-JPにエンコード
        Source='%s <%s>'%(Header(SENDER_NAME.encode('iso-2022-jp'),'iso-2022-jp').encode(),SENDER_ADDR)
    )
# Display an error if something goes wrong. 
except ClientError as e:
    print(e.response['Error']['Message'])
else:
    print("Email sent! Message ID:"),
    print(response['MessageId'])

これで実行します。

>python ses_send.py
Email sent! Message ID:
0100016c241237ba-ca70ada5-4add-4641-8f97-dfaf904f8de7-000000

受信したメール。

MIME-Version: 1.0
Date: Wed, 24 Jul 2019 22:01:11 +0900
From: =?utf-8?Q?=E3=83=86=E3=82=B9=E3=83=88?= <hoge+sender@gmail.com>
Subject: =?utf-8?Q?Amazon_SES_=E3=83=86=E3=82=B9=E3=83=88_(SDK_for_Python)?=
Thread-Topic:
 =?utf-8?Q?Amazon_SES_=E3=83=86=E3=82=B9=E3=83=88_(SDK_for_Python)?=
To: "fuga@gmail.com" <fuga@gmail.com>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"

Amazon SES =E3=83=86=E3=82=B9=E3=83=88 (Python)
This email was sent with Amazon SES using the AWS SDK for Python (Boto).

先ほどとFromのエンコードが変わり、メーラでも日本語が化けずに表示されます。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2019-07-24T21:15:49+09:00

【AWS CLI】コマンドプロンプトでconfigureを切り替える

defaultから切り替えるには--profileオプションを付ける。

>aws s3 list --profile [profile_name]

オプションを付けなくても常に切り替えたい場合は、環境変数AWS_DEFAULT_PROFILEに使いたいプロファイルの名前を設定しておく。

>set AWS_DEFAULT_PROFILE=[profile_name]
>aws s3 list
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2019-07-24T20:18:38+09:00

which cloud provider is better AWS vs Azure?

Microsoft Azure and Amazon net Services area unit the 2 biggest cloud service suppliers within the world. Deciding that cloud supplier to use for your business or organization is a tough call. the solution can depend upon a spread of various concerns as well as value, security, and onboarding. It additionally depends on whether or not your company engages in rising technologies and what business sector you vie in. to assist TechGenix readers buckle down and do the dizzying options and capabilities of those 2 platforms, so I am writing my honest opinion for AWS vs Azure.

Each cloud supplier has its own niche once it involves craft its options to the organizations inquisitive about shopping for. as an example, whereas Microsoft’s Azure thrives in a very Windows surroundings, AWS works best once deployed in very UNIX surroundings. Azure, stemming from Microsoft’s B2B powerhouse that has spun off alternative spectacular suites like Office365, is that the best cut-out for enterprises, whereas AWS’ setup is well-suited for alternative industries like retail and finance.

On the down facet, Azure does not provide the maximum amount support for DevOps strategies as different cloud platforms. Its dev tools ar double-geared to the Microsoft methodology of development, and there ar lots of Microsoft retailers that ar doubtless smart therewith.

And whereas Microsoft will support several open supply initiatives like Hadoop and Kubernetes, AWS has abundant larger and deeper support for all the world from the open supply community. Microsoft has come back a protracted method however still has some catching up to try to to.

Also, AWS has done its best to produce headache-free licensing, whereas with Microsoft, it gets a small amount difficult. If you have got Microsoft licenses, you would possibly be eligible for license quality to maneuver to the cloud, therefore you don’t ought to buy each the on-prem and cloud version. this can need some work on your give up your consultants/MVPs

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2019-07-24T20:05:37+09:00

【書評】Amazon Web Services ネットワーク入門

AWS 認定ソリューションアーキテクト - プロフェッショナルを取得する為に、
苦手分野をなんとかする為に買いました。

Amazon Web Services ネットワーク入門 (impress top gear)
alt
ネットワーク周りが苦手で、特にIPアドレスの設定や、サブネットに関する問題が難しく・・。
かなり前に、アソシエイトの資格に合格したのですが、その時は、他の分野でカバーしてなんとかなりましたが、
今回は、アソシエイトより難易度が上がるし、少しでも苦手分野を減らす目的で読みました。

感想

2016年に発売された本なので、書籍の画面イメージと、実際の画面に多少差異がありますが、それほど気にならず、スムーズに構築が進められました。
基本的なネットワーク知識を復習しつつ、AWSでどう構築していくが学べました。
今まで、BlackBelt等の資料を読む、問題を解くで覚えた断片的な知識はあり、消去法やなんとなくで、解いていた問題が多かったのですが、
実際に構築するなかで、はっきりとして正しい選択肢を選べることが多くなりました。
また、IPアドレスが出てくる問題に苦手意識があったのですが、それもなくなりました。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2019-07-24T19:05:15+09:00

ECS で作成された Route53 の ホストゾーンを削除する

概要

重い腰を上げ、ECS の検証を始めました。コンテナを思い出すのに時間がかかった...
その中で「サービスの検出」で作成されたローカルゾーンを削除するお話し。

やったこと

  • ECS コンソール上でクラスター上のサービスを削除
  • Route53 のコンソール上から、ローカルゾーンを削除しようとするとエラーが...
  • AWS CLI で ECS のサービス削除をしないとダメとのこと

詳細説明

公式ドキュメント のとおり、以下を実行する。

# 名前空間の一覧を表示する
aws servicediscovery list-namespaces --region <region_name>

# 対象の名前空間の ID を指定して削除する
aws servicediscovery delete-namespace --id <service_discovery_namespace_id> --region <region_name>

これで、Route53 のホストゾーンから消えていることを確認。

仲間募集中

弊社ではエンジニアを募集中です。インフラからアプリ、ユーザサポートまで幅広く業務を行ってます。
https://www.nittsu-infosys.com/recruit/

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2019-07-24T18:18:39+09:00

EC2を特定の時間に自動で起動/停止する

概要

いったい何番煎じだよという感じですが、Lambda上にデプロイしたコードから、EC2のインスタンスを定期的に起動/停止させます。

今の時代、こちらの記事にある通り、プログラムを書かずともLambdaの定期起動/停止ができてしまいます。
それでも、本記事のコードをデプロイした後であれば、EC2インスタンスを立てるたびにCloudWatchの設定をいじる必要もなく、インスタンスにタグを追加するだけで自動起動/停止の設定ができるようになり、便利です。

Lambdaの設定

本記事のコードは、EC2に設定されているタグを見て、インスタンスの起動/停止を行います。そのため、自動設定対象にしたいEC2インスタンスには、以下のようにstart-time,stop-timeのタグをつけます。それぞれ、起動時間と停止時間をHHMM形式で表します。
無題.png

コード

以下のコードを、Lambdaにデプロイします。もちろん、EC2を起動や停止するための、適当なIAMロールをつけます。

manage_ec2.py
import boto3;
import datetime;

# 最初に呼ばれる関数
def lambda_handler(event, context):
    client = boto3.client('ec2', 'ap-northeast-1')
    # boto3でec2の全インスタンスの情報を取得
    response = client.describe_instances()
    # 必要な情報のみを抜き出したリストを作成
    instance_list = extract_instance_info(response)
    # 上のリストを基に、必要であればインスタンスを起動/停止する
    manage_instances(instance_list)

# ec2インスタンスのリストを作成
def extract_instance_info(response):
    return_val = []
    for instance_data in response['Reservations'][0]['Instances']:
        try:
            tmp = {}
            # インスタンスのid
            tmp['id'] = instance_data['InstanceId']
            # タグで指定されている起動時間
            tmp['start_time'] = convert_time([tag['Value'] for tag in instance_data['Tags'] if tag['Key'] == 'start-time'][0])
            # タグで指定されている終了時間
            tmp['stop_time'] = convert_time([tag['Value'] for tag in instance_data['Tags'] if tag['Key'] == 'stop-time'][0])
            # 現在のインスタンスの起動状況
            tmp['status'] = instance_data['State']['Name']
            return_val.append(tmp)
        except:
            # かなり乱暴なのは承知ですが、自動起動/停止対象外のインスタンス（タグが設定されていないもの）があれば、例外を発生させて無視します
            continue
    print(return_val)
    return return_val

# タグで指定されている起動/停止時間を、datetime.time型に変換
def convert_time(str_time):
    hour = int(str_time[:2])
    min = int(str_time[2:4])
    return datetime.time(hour,min)

# インスタンスの起動/停止を行う
def manage_instances(instance_list):
    # 現在時刻をdatetime.time型で取得
    current_time = datetime.datetime.now().time()
    for instance in instance_list:
        # インスタンス停止中で、起動時間を過ぎていれば、インスタンスを立ち上げる
        if instance['status'] != 'running' and current_time >= instance['start_time']:
            response = ec2.start_instances(
                InstanceIds=[
                    instance['id']
                ]
            )
            print(response)
        # インスタンス起動中で、停止時間を過ぎていれば、インスタンスを停止する
        elif instance['status'] == 'running' and current_time <= instance['stop_time']:
            response = ec2.stop_instances(
                InstanceIds=[
                    instance['id']
                ]
            )
            print(response)
        else:
            # 何もすることないけど、ログだけ出しとく
            print('no action was taken')

このコードをデプロイしたLambda関数を、CloudWatchで30分おきなどで実行させれば、完成です。

上のコードでは現在時刻を取得するコードが含まれているので、Lambdaの環境変数に、必ずTZ:Asia/Tokyoを付け加えてください。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2019-07-24T18:18:39+09:00

EC2をタグに基づいて、特定の時間に自動で起動/停止する

概要

いったい何番煎じだよという感じですが、Lambda上にデプロイしたコードから、EC2のインスタンスを定期的に起動/停止させます。

今の時代、こちらの記事にある通り、プログラムを書かずともLambdaの定期起動/停止ができてしまいます。
それでも、本記事のコードをデプロイした後であれば、EC2インスタンスを立てるたびにCloudWatchの設定をいじる必要もなく、インスタンスにタグを追加するだけで自動起動/停止の設定ができるようになり、便利です。

Lambdaの設定

本記事のコードは、EC2に設定されているタグを見て、インスタンスの起動/停止を行います。そのため、自動設定対象にしたいEC2インスタンスには、以下のようにstart-time,stop-timeのタグをつけます。それぞれ、起動時間と停止時間をHHMM形式で表します。
無題.png

コード

以下のコードを、Lambdaにデプロイします。もちろん、LambdaにはEC2を起動や停止するための、適当なIAMロールをつけます。

manage_ec2.py
import boto3;
import datetime;

# 最初に呼ばれる関数
def lambda_handler(event, context):
    client = boto3.client('ec2', 'ap-northeast-1')
    # boto3でec2の全インスタンスの情報を取得
    response = client.describe_instances()
    # 必要な情報のみを抜き出したリストを作成
    instance_list = extract_instance_info(response)
    # 上のリストを基に、必要であればインスタンスを起動/停止する
    manage_instances(instance_list)

# ec2インスタンスのリストを作成
def extract_instance_info(response):
    return_val = []
    for instance_data in response['Reservations'][0]['Instances']:
        try:
            tmp = {}
            # インスタンスのid
            tmp['id'] = instance_data['InstanceId']
            # タグで指定されている起動時間
            tmp['start_time'] = convert_time([tag['Value'] for tag in instance_data['Tags'] if tag['Key'] == 'start-time'][0])
            # タグで指定されている終了時間
            tmp['stop_time'] = convert_time([tag['Value'] for tag in instance_data['Tags'] if tag['Key'] == 'stop-time'][0])
            # 現在のインスタンスの起動状況
            tmp['status'] = instance_data['State']['Name']
            return_val.append(tmp)
        except:
            # かなり乱暴なのは承知ですが、自動起動/停止対象外のインスタンス（タグが設定されていないもの）があれば、例外を発生させて無視します
            continue
    print(return_val)
    return return_val

# タグで指定されている起動/停止時間を、datetime.time型に変換
def convert_time(str_time):
    hour = int(str_time[:2])
    min = int(str_time[2:4])
    return datetime.time(hour,min)

# インスタンスの起動/停止を行う
def manage_instances(instance_list):
    # 現在時刻をdatetime.time型で取得
    current_time = datetime.datetime.now().time()
    for instance in instance_list:
        # インスタンス停止中で、起動時間を過ぎていれば、インスタンスを立ち上げる
        if instance['status'] != 'running' and current_time >= instance['start_time']:
            response = ec2.start_instances(
                InstanceIds=[
                    instance['id']
                ]
            )
            print(response)
        # インスタンス起動中で、停止時間を過ぎていれば、インスタンスを停止する
        elif instance['status'] == 'running' and current_time <= instance['stop_time']:
            response = ec2.stop_instances(
                InstanceIds=[
                    instance['id']
                ]
            )
            print(response)
        else:
            # 何もすることないけど、ログだけ出しとく
            print('no action was taken')

このコードをデプロイしたLambda関数を、CloudWatchで30分おきなどで実行させれば、完成です。

上のコードでは現在時刻を取得するコードが含まれているので、Lambdaの環境変数に、必ずTZ:Asia/Tokyoを付け加えてください。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2019-07-24T17:49:20+09:00

awsのEC2でWebサーバーを作成しBasic認証を設定する際の注意

Amazon Elastic Computing Cloud(EC2)はAWSのIaaSリソースです。

これを使ってWebサーバーを立てることも多々あると思います。

今回はBasic認証の設定まで行いましたが知識の整理のために要点だけ記載します。

EC2

インスタンスの作成とssh接続

基本的にはAWSのコンソールに従えば問題なくssh接続できます。

  • pemキーをダウンロードしたらそのファイルを作業ディレクトリもしくはホームディレクトリへ移動する
  • chmod 400 [pem key]を実行し、読み取り権限を付与する

chmodを実行しないとエラーになるので注意が必要です。

apachのインストールと実行

  • sudo yum install httpd
  • sudo service httpd start

これだけ。

セキュリティグループの設定

上記の設定をしただけではまだVMに対してhttpでアクセスすることはできません。
内向きのhttpアクセスを許可する必要があります。

これは、インスタンスの説明タブ上にあるセキュリティグループのリンクをクリックすることで編集できます。
既存のルールにHTTPを追加します。

Basic認証

.htaccessと.htpasswd

Basic認証を行うためには.htaccessと.htpasswdの二つのファイルが新たに必要になります。
以下が例になります。

.htaccess
AuthUserFile /var/www/html/.htpasswd #自分の環境に合わせる
AuthName “Please enter your ID and password”
AuthType Basic
require valid-user

.htpasswdには認証に利用するユーザ名とPASSを記入します。
PASSは暗号化されている必要があるので外部サイト等を利用して生成すると良いでしょう。

.htpasswd
test:PASSWARD

この後、これらのファイルにchmodで権限を付与します。
大抵は604/644のどちらかでうまくいくはずです。

httpd.confを編集する必要がある。

見落としがちなので注意が必要です。httpd.confを確認してください。

.httpd.conf
#/var/www/html
AllowOverride None

となっている場合は、

.httpd.conf
#/var/www/html
AllowOverride All

に書き換える必要があります。これを忘れるとBasic認証が効きません。
私はこれで時間を溶かしました。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2019-07-24T17:09:37+09:00

AWSで基盤お試し構築~セキュリティグループ&EC2~

前回の話

AWSで基盤お試し構築~サブネットとインターネットゲートウェイ~

前回までにやったこと

VPCを作ってap-northeast-1xにサブネットを作りました。
インターネットに接続できるように、インターネットゲートウェイを作りました。

前回までの作業で完成したとこ

枠ばっかりできてきた。
image.png

今回目指すところ

謎の赤い枠と謎のオレンジの物体を作る。
image.png

準備(確認)

さんざん言っていることですが…

  • リージョンが「東京」になっていることを確認する
    • 「EC2立てたぜﾋｬｯﾎｰｲ」と思ったら、全然違うリージョンだったとか、意外とやりますよね。
      自分だけ…?

セキュリティグループを作成する

まずは「謎の赤い枠」を作成していく。
image.png

そもそもセキュリティグループって何者…
  • 縄張りの中に家を作っても、全員顔パスで入れてしまうと泥棒し放題になる。
  • それを防ぐために、ゲートを作って、怪しいやつは問答無用で倒したいと誰もが思うはず。
  • セキュリティゲートの役目をするのが、セキュリティグループと思ってもらえればとりあえずいいと思う。

毎度毎度のマネジメントコンソール

今回はEC2のページを開く。たどり着き方は人それぞれ。
自分は「最近アクセスしたサービス」にEC2がいるので、そこから行きます。
あとは↓のやり方でだいたい行ける。

  • 「サービスを検索する」で"EC2"と入れる
  • 「すべてのサービス」からEC2を探す image.png

セキュリティグループの画面を開く

左側のリストに「セキュリティグループ」があるはずなので、それを選択する。
「ネットワーク＆セキュリティ」の中にあるはず。
image.png

  • セキュリティグループの一覧が表示されるので、青いボタン「セキュリティグループの作成」を押下する。 image.png
  • 「セキュリティグループの作成」が表示されてくる。 image.png
  • 設定項目に何書いたらいいか相変わらずわからない… 　 　　 　　 　　 　　 　　 　　 　　
    設定項目 説明
    セキュリティグループ名セキュリティグループの名前を設定する。好きな名前を付けていい。
    説明セキュリティグループの説明。どういう用途かを書いておけばとりあえずok。"Webサーバ用"とか。
    VPCどのVPCに紐づけるかを指定する
    セキュリティグループのルールどの通信をだれに対して許可するのかを設定する
  • 今回は以下のように設定する
　 　　 　　 　　 　　 　　
設定項目 設定値
セキュリティグループ名好きな名前で。
説明好きな説明で。
VPC前々回作成したVPCを指定する
  • セキュリティグループのルールは以下のようにする。 　 　　 　　 　　 　　 　　 　　 　　
    設定項目 設定値
    タイプhttp
    プロトコル(自動入力)TCP
    ソースマイIP
    説明なんか適当に
  • 全部入れたらこんな感じになると思われるので、右下の「作成」を押下する。 image.png
  • 作成したセキュリティグループが一覧に表示されているはず。 image.png

図で見る今の立ち位置

謎の赤い枠ができた
image.png

EC2を立ててみる。

「謎のオレンジ」を作りましょう。
image.png

毎度毎度のマネジメントコンソール

今回はEC2のページを開く。たどり着き方は人それぞれ。
自分は「最近アクセスしたサービス」にEC2がいるので、そこから行きます。
あとは↓のやり方でだいたい行ける。

  • 「サービスを検索する」で"EC2"と入れる
  • 「すべてのサービス」からEC2を探す image.png
  • VPCとは趣が若干違うページが表示されたはずなので、青いボタン「インスタンスの作成」を押下してみる。 image.png

--

  • そうすると、こんなウィザード的な画面が表示されるはず。 image.png

Break…EC2が立ち上がるまでの道のり

そもそもこれから何やるのかって話をしないと、訳わからなくなりそうな気がした。（自分が）

  • やること

①マシンイメージを選択する
②インスタンスタイプを選択する
③インスタンスの設定(おもにネットワーク周り)を行う
④ストレージの設定を行う
⑤タグを設定する
⑥セキュリティグループを設定する

マシンイメージを選択する
  • Amazon Machine Image。いわゆるAMI。アミっていうらしいです。　　
    • AWS関係でアミ網言ってたらコレの話。
  • 要するに、サーバをまるっとパッケージにしたイメージ。
  • まずは、要件的にどのOSなのか観点で選んだらいいのでは。。。
インスタンスタイプを選択する
  • CPUの数とかメモリのサイズとかネットワークの太さとか、、、要件に従って決める。
    • GPU付きが良ければ、GPUインスタンスとかを選んでみたらよろし。
  • m3->m4->m5って数字がでかくなってくるに従って、性能はいい割に費用は安くなる不思議。
    • 個人で使うならmicroとかでいいと思われる。無料枠だし。
インスタンスの設定(おもにネットワーク周り)を行う
  • 前回、前々回で作ったVPCとかサブネットを関連付ける
ストレージの設定を行う
  • ストレージのサイズはここで設定する。
  • ルートボリューム以外も作れる
タグを設定する
  • 名前つけてあげましょう
セキュリティグループを設定する
  • さっき作ったセキュリティグループをアタッチしよう。
  • ここでも作成できるけど、説明し辛いから先に作っておいてみた。

ということで、EC2を作成

マシンイメージを選択する
  • 一番上のAmazon Linux 2を選択する image.png
インスタンスタイプを選択する
  • 無料利用枠で使いたいので、t2.microにしておく。 image.png
インスタンスの設定(おもにネットワーク周り)を行う
  • VPCとサブネットは、前々回あたりから作成してきたやつを使う。 image.png
  • サーバにインターネットからつながるよう、パブリックIPを有効にする。 image.png
  • シャットダウン動作は「停止」にしておく
    • 「終了」にすると、shutdownコマンド叩いたらそのままterminateされてインスタンスが消える。
  • 削除保護の有効化にもチェックを入れて、間違って消さないようにする image.png
ストレージの設定を行う
  • 特に要件がないので、デフォルト設定にしておく
    • サイズを変えたりストレージを足したりしたいときは、この画面で設定する image.png
タグを設定する
  • 分かりやすい名前とかを付けてあげる
    • タグの値でサービスを制御するとかっていう使い方もある。なんだったかは忘れた。 image.png
セキュリティグループを設定する
  • 「既存のセキュリティグループを選択する」を選択する。
  • さっき作成したセキュリティグループを選択する。 image.png
全部終わったら「確認と作成」を押下する
  • こんな画面が出るけど、無視して進める。 image.png
  • 確認画面が出るので、「起動」を押下する image.png
  • キーペアを作成してあげる。
    • キーはなくしたらおしまいなので、ちゃんと保存しておきましょう。
    • SSMで接続する手もあるけど。
    • Gitにキーを上げると楽しいことが起きるらしいです。 image.png
作成が始まった。
  • 右下「インスタンスの表示」を押下する image.png
  • 無事にEC2が起動してきた
    • インスタンスのステータスが"Running"なら起動している
    • pendingとかstoppingとかterminatingとかstoppedとかterminatedだと動いてない。 image.png

図で見る今の立ち位置

ひとまずサーバは立ったし、インターネットにもつながるはず。
image.png

Webサーバが欲しいけど、まだWebサーバになりきれてないのでもう少し頑張る

まだ終わらないので次へ

AWSで基盤お試し構築~サーバでコマンドを叩ける環境を作る~

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2019-07-24T17:00:07+09:00

Route53フェイルオーバ機能での夜間用Sorryページ切り替えをあきらめた話

Route53のフェイルオーバ機能を利用した日中⇔夜間のページ切替を行おうとしたところ、社内プロキシの壁に阻まれた（と思われる）がために、代替手段を模索したお話です。

1.おおまかな要件

・日中のサービス時間帯のみウェブアプリケーションが稼働し、夜間はサーバを停止してコストカット
・夜間帯のサービスアウト時にはSorryページが表示される
・アプリケーションは特定多数のクライアント企業が使用し、クライアント証明が必要

2.やろうとしたこと

・サービスイン時のみEC2(ASG)でウェブアプリケーションが稼働し、サービスアウト時はASGの起動インスタンス数を0にする
・サービスアウト時にRoute53のフェイルオーバ機能が働き、S3に静的ホスティングしたSorryページを表示
・クライアント証明のためにALB不可のため、NLBを選択

構成図
※Bastionは運用/保守用の24H稼動インスタンス
処理フロー-ページ10.png

3.問題

ここで問題が発生しました。
Route53でドメインの向き先Aliasが切り替わった際、名前解決先は切り替わっているのに30分以上Web画面が切り替わらない状態に陥りました。
Resolve-DnsNameで確認しても、TTL（60秒）後にはちゃんと解決先が切り替わっていることが確認できます。

さらに確認を進めると、

・社内ネットワーク内の端末からのアクセス時には切り替わらない
・パブリックネットワーク上のEC2からのアクセス時にはちゃんと切り替わる

ということが分かりました。

ここから”社内プロキシがドメインの名前解決先をキャッシュしてしまっているのでは...？”と考えました。
しかし、社内プロキシ側の仕様はブラックボックスなため確実かどうかは判断できません。

4.対応

とはいうものの、開発もIT工程後半に差し掛かっており、どうにか早急に代替策を考えねばならない。
かつ、もし社内プロキシが原因だとすると、特定多数のクライアント企業側のプロキシ仕様によっては同様の事象が置き得るのでは？
という状態になりました。

そこで、代替策としてNLBのListenerをLambdaで操作し、リクエストのターゲット先を切り替える方針を検討、

・NLB利用のため、バックエンドにLambdaを置く方法はだめ
・ちょうど、運用／保守用のBastionインスタンスが24H稼動している

という前提を踏まえて以下の構成をとり、サービスアウト時にはBastionインスタンスに配置したSorryページを応答することにしました。

処理フロー-ページ11.png

NLBを切り替えるLambdaFunctionはシンプルにこんな感じで、サービスイン／アウトフラグをCloudWatchEventから受け取って切替処理を行います。

ChangeNlbTarget.py
import boto3
import os
import logger_formatter

logger = logger_formatter.setup_logging('ChangeNlbTarget')
client = boto3.client('elbv2')

def lambda_handler(event, context):
    logger.info('function start.')
    logger.info('event_param: %s', event)

    is_service_in = event['is_service_in']

    if not isinstance(is_service_in, bool):
        logger.error('error_message: %s is not boolean', is_service_in)
        raise Exception('Input Parameter is Invalid.')    

    if is_service_in == True:
        target = os.environ['TARGET_WEBAP_ARN']
    else:
        target = os.environ['TARGET_SORRY_ARN']

    try:
        res = client.modify_listener(
                ListenerArn = os.environ['LISTENER_ARN'],
                Port = 443,
                Protocol = 'TCP',
                DefaultActions = [
                        {
                            'Type' : 'forward',
                            'TargetGroupArn' : target
                        }
                    ]
            )
    except Exception as e:
        logger.error('error_message: %s', e)
        raise Exception('Change Nlb Target failed.')    


    logger.info('function end.')
    return{
        'statusCode': 200
    }

5.結果

しっかりTTL後には日中⇔夜間のページ切替が完了できるようになりました。
また、もともと24H稼動の必要がある別インスタンスを利用することで、コスト増も避けることができました。

想定する原因が本当に合っているのか、対応方法はベターか、というところはあるかと思います。
もし同じような状況に陥ったことがある方がいらっしゃれば、原因・対応方法等をコメントいただけると幸いです。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2019-07-24T16:45:10+09:00

これからAlexaスキルを作る方へ、しくみをざっくりと噛み砕いてみた

今巷でトレンドなテーマのAlexaスキルですが、簡単に出来る！と言われます。

確かにそうなのですが、概念も分からず作るのは、新入社員が「これはこういうものだからやれ」と理不尽な教育を受けるようなものなので、

いくつかスキルを作って私なりに理解した内容を噛み砕いて説明したいと思います。

この概念が分かれば、問題が起きた時に、どこを見れば良いかがいち早くわかるかと。

ではまず、全体の構成を見てみましょう。

全体の構成

全体の構成を図解するとこんな感じです。

高度なスキルはこの限りではないケースもありますが、説明しやすいよう最低限の構成にしています。

image.png

ここから、各ブロックごとの説明をしていきます。

フロントエンド：Alexa developer console

ユーザが発話した内容を解析し、起動するインテントを判断するための部分。

要するに、発話内容をデータに落とし込む部分ですね。

データに落とし込んだものをJSONに変換してLambdaに送ります。

発話内容に関する設定はこの部分を変更します。

バックエンド：AWS Lambda

バックエンドというと色々面倒な処理をするイメージがありますが、実はLambda側はルールに沿ってJSONフォーマットのコマンドを作ってるだけ。

それだけの役割なので、フロントエンドからインテントとして受け取った情報をどう料理するかを考えれば良いことになります。

そのため、ある程度言語に自由度があります。私なんかはPythonを勉強の一環で使ってます。

ただ、Alexa スキル関係の技術情報はJSを例にとることが多いので、特段理由が無ければJSが良いと思います。

デバッグログ：AWS Cloudwatch logs

優秀なロギングサービスです。

JSONでやり取りしているフロントエンドとバックエンド間の通信ログを自動で取っておいてくれるスグレモノ。

意図しないインテントが呼び出されているなんてのはこれが無いとデバッグが難しいでしょう。

また、Lambdaでprint文を書いたりするとここに記録されるので、実行順や変数の中身を見るのにも使えます。

フィールドテストのときなどにも使えますね。

まとめ

シンプルを目指すために、非常にざっくりとした説明にはなりましたが、ある程度構成の全貌が分かってもらえば幸いです。

これを理解しているかどうかでは、開発速度は格段に違うと思います。

まだまだ駆け出しのテクノロジですが、Amazonが公式で公開しているドキュメントの類が結構分かりやすくて優秀なので、ハードルを下げてくれています。

コード量もそれほど多くなくて始められるので、プログラミングの練習に使っても良いかもしれませんね。

エンジョイスキルライフ！

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む
  • 投稿日：2019-07-24T16:26:30+09:00

[WIP]Amazon Inspectorについて

このページについて

Amazon Inspectorとは、どんなAWSサービスなのか、具体的にどんな脆弱性を検知できるのか。
Amazon Inspectorの導入はどうやってやるのか。
料金はいくらかかるのか。

Amazon Inspector導入手順

  1. EC2にログイン後、AWSエージェントをインストールするためのインストールスクリプトをダウンロードするコマンドを実行
$ wget https://inspector-agent.amazonaws.com/linux/latest/install
--2019-07-24 14:06:49--  https://inspector-agent.amazonaws.com/linux/latest/install
inspector-agent.amazonaws.com (inspector-agent.amazonaws.com) をDNSに問いあわせています... 99.86.194.93, 2600:9000:21b5:a400:4:6195:f549:e8e1, 2600:9000:21b5:cc00:4:6195:f549:e8e1, ...
inspector-agent.amazonaws.com (inspector-agent.amazonaws.com)|99.86.194.93|:443 に接続しています... 接続しました。
HTTP による接続要求を送信しました、応答を待っています... 200 OK
長さ: 35975 (35K)
`install' に保存中

100%[=======================================================================================>] 35,975      --.-K/s 時間 0.006s

2019-07-24 14:06:49 (5.89 MB/s) - `install' へ保存完了 [35975/35975]
  1. AWSエージェントをインストールするコマンドを実行
$ sudo bash install
amzn.2.2
Distribution of the machine is Amazon Linux.
Distribution type of the machine is amzn.
Revision of the distro is 2.
Kernel version of the machine is 4.14.128-112.105.amzn2.x86_64.
dev-myamashita-01-de is an EC2 instance reporting region as ap-northeast-1.
Check for existing AwsAgent completed with error code:0
Existing version of agent installed is 0.0.0.0.
cannot find installed KM VERSION... assumed '0.0.0.0'
get_installed_km_version: EXISTING_KM_VERSION:0.0.0.0 exit status:0
Existing version of kernel module installed is 0.0.0.0.
PUBKEY_FILE: /tmp/awsagent.c0g4NtSg/inspector.gpg
Validated AWS_AGENT_INVENTORY signature with:
HTTP/1.1 200 OK
x-amz-id-2: xxuFgfmYI/T4rPBGfH/8kT/QbV0jgjtY9mZUd+ORgSbpDEyq/65MFs9VHFnqQctm3rtfvsVFJDk=
x-amz-request-id: 132448679F0E6943
Date: Wed, 24 Jul 2019 05:12:17 GMT
Last-Modified: Wed, 08 May 2019 15:46:31 GMT
ETag: "a73786a2ba1ab7c579b467e24fc516ce"
Accept-Ranges: bytes
Content-Type:
Content-Length: 952
Server: AmazonS3

AGENT_MANIFEST_URL: https://s3.ap-northeast-1.amazonaws.com/aws-agent.ap-northeast-1/linux/releases/1.1.1446.0/AGENT_MANIFEST
AGENT_VERSION_URL:  https://s3.ap-northeast-1.amazonaws.com/aws-agent.ap-northeast-1/linux/releases/1.1.1446.0/VERSION
PUBKEY_FILE: /tmp/awsagent.c0g4NtSg/inspector.gpg
Validated AGENT_MANIFEST signature with:
PUBKEY_FILE: /tmp/awsagent.c0g4NtSg/inspector.gpg
Validated VERSION signature with:
AGENT_PACKAGE_URL: https://s3.ap-northeast-1.amazonaws.com/aws-agent.ap-northeast-1/linux/releases/1.1.1446.0/amzn-4.14.47-64.38.amzn2.x86_64-x86_64/AwsAgent-1.1.1446.0-102446.x86_64.rpm
EXPECTED_AGENT_PACKAGE_HASH: e6e9eed390a5b6a38f923ede1c5850bb5c7466f4543632440bb39e9e93fb65b7
NEW_AGENT_VERSION:1.1.1446.0
PUBKEY_FILE: /tmp/awsagent.c0g4NtSg/inspector.gpg
Validated KM_MANIFEST_AMZN2_4.14_1.0.200104.txt signature with:
Validated agent package sha256 hash matches expected value.
package_install:package_path:     /tmp/awsagent.c0g4NtSg/AwsAgentKernelModule__amzn__4.14.128-112.105.amzn2-1.0.200104.0-0.x86_64.rpm
package_install:new_version:      1.0.200104.0
package_install:existing_version: 0.0.0.0
package_type                    : km
/bin/yum
Installing with yum...
yum install -y /tmp/awsagent.c0g4NtSg/AwsAgentKernelModule__amzn__4.14.128-112.105.amzn2-1.0.200104.0-0.x86_64.rpm
読み込んだプラグイン:extras_suggestions, langpacks, priorities, update-motd
/tmp/awsagent.c0g4NtSg/AwsAgentKernelModule__amzn__4.14.128-112.105.amzn2-1.0.200104.0-0.x86_64.rpm を調べています: AwsAgentKernelModule__amzn__4.14.128-112.105.amzn2-1.0.200104.0-0.x86_64
/tmp/awsagent.c0g4NtSg/AwsAgentKernelModule__amzn__4.14.128-112.105.amzn2-1.0.200104.0-0.x86_64.rpm をインストール済みとして設定 しています
依存性の解決をしています
--> トランザクションの確認を実行しています。
---> パッケージ AwsAgentKernelModule__amzn__4.14.128-112.105.amzn2.x86_64 0:1.0.200104.0-0 を インストール
--> 依存性解決を終了しました。
amzn2-core/2/x86_64                                                                                       | 2.4 kB  00:00:00

依存性を解決しました

=================================================================================================================================
 Package                   アーキテクチャー
                                  バージョン     リポジトリー                                                               容量
=================================================================================================================================
インストール中:
 AwsAgentKernelModule__amzn__4.14.128-112.105.amzn2
                           x86_64 1.0.200104.0-0 /AwsAgentKernelModule__amzn__4.14.128-112.105.amzn2-1.0.200104.0-0.x86_64 7.9 M

トランザクションの要約
=================================================================================================================================
インストール  1 パッケージ

合計容量: 7.9 M
インストール容量: 7.9 M
Downloading packages:
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  インストール中          : AwsAgentKernelModule__amzn__4.14.128-112.105.amzn2-1.0.200104.0-0.x86_64                         1/1
  検証中                  : AwsAgentKernelModule__amzn__4.14.128-112.105.amzn2-1.0.200104.0-0.x86_64                         1/1

インストール:
  AwsAgentKernelModule__amzn__4.14.128-112.105.amzn2.x86_64 0:1.0.200104.0-0

完了しました!
HTTP/1.1 200 OK
x-amz-id-2: DYi7TIP/Zt1f9H56zq/TPxrraRZh40r86Wxt/1YylD1Qyv8I7YaVSwnuaxx9qV7I75UXWUPswrk=
x-amz-request-id: B8079CF34F5423B8
Date: Wed, 24 Jul 2019 05:12:31 GMT
Last-Modified: Wed, 08 May 2019 15:46:31 GMT
ETag: "a73786a2ba1ab7c579b467e24fc516ce"
Accept-Ranges: bytes
Content-Type:
Content-Length: 952
Server: AmazonS3

Installation script completed successfully.

Notice:
By installing the Amazon Inspector Agent, you agree that your use is subject to the terms of your existing
AWS Customer Agreement or other agreement with Amazon Web Services, Inc. or its affiliates governing your
use of AWS services. You may not install and use the Amazon Inspector Agent unless you have an account in
good standing with AWS.
*  *  *
Current running agent reports to arsenal endpoint:
Current running agent reports version as: 1.1.1446.0
This install script was created to install agent version:1.1.1446.0
In most cases, these version numbers should be the same.

3.





参考URL



https://docs.aws.amazon.com/ja_jp/inspector/latest/userguide/inspector_installing-uninstalling-agents.html


    

  



    
    
        
  • 
            
        
    • 
        
  • 
            
            
        
    • 
        
  • 
            このエントリーをはてなブックマークに追加
        
    • 
        
  • 
            Qiitaで続きを読む 
        
    • 
    
















  

    

    

    


      

        
    
          
  •  投稿日：2019-07-24T14:46:49+09:00
    • 

        

      

      

        [AWS] InstanceConnect と SessionManager の比較
      





      



    

  


  

      

    
『EC2 Instance Connect』に『Session Manager の SSH・SCPトンネリング』と、似たような機能が立て続けにリリースされましたが、「どっち使えばいいの？」と悩んでしまいますよね。



それぞれ向き／不向きなケースがありますので、どちらを利用すべきかの判断ポイントを簡単に表にまとめてみます。



なお、表はSSHのみとなっていますが、SCPでも同様です。

SessionManagerの従来の接続方法については比較対象外としています。







比較項目
SessionManager (SSH)
EC2 InstanceConnect (SSH)






対応OS
多い
少ない




EC2ロール
必要
不要




オンプレサーバーでの利用
可
不可




ネットワーク
22番ポートの穴あけが不要。
Privateネットワークでも利用可。		
22番ポートの穴あけが必要。
Privateネットワークでは利用不可。		




SSHキー（秘密鍵）
クライアントで保持する必要がある。
不要。
msshコマンドが勝手に作って使って捨てる。		




OSユーザー指定
SSHキーで制御。
Run As を利用すればIAMユーザー（IAMロール）のタグでも指定可能。		
IAMユーザー（IAMロール）に付与するポリシーで限定が可能。




ログ
SessionManagerにセッション履歴が残る。
CloudTrail に StartSession のログが残る。
OS上の操作ログは残らない。		
CloudTrail に SendSSHPublicKey のログが残る。
OS上の操作ログは残らない。		






    

  



    
    
        
  • 
            
        
    • 
        
  • 
            
            
        
    • 
        
  • 
            このエントリーをはてなブックマークに追加
        
    • 
        
  • 
            Qiitaで続きを読む 
        
    • 
    
















  

    

    

    


      

        
    
          
  •  投稿日：2019-07-24T14:14:09+09:00
    • 

        

      

      

        AWS/EFS リージョン間データ転送
      





      



    

  


  

      

    
DataSync使えば転送できるけどわざわざ手動で設定する必要はない。

https://docs.aws.amazon.com/ja_jp/datasync/latest/userguide/what-is-datasync.html



AWSが用意してるツール使ったほうが簡単・確実。実体はCloudFormationで必要なAWSリソースを作成する。

https://github.com/aws-samples/amazon-efs-tutorial/tree/master/in-cloud-transfer



使い方は簡単なので詳細は省略。



（未確定情報）VPCピアリングが必要かもしれない。VPCのCIDRが同じだとエラーとか色々あるので必要なら新規VPCを作る。



    

  • 転送元バージニアリージョン→転送先東京リージョン
    • 

  • 転送先に新規EFSを作る。（VPCピアリング使う場合マウントターゲットは新VPCのほうで設定）
    • 

  • in-cloud-transferは転送元リージョンのDeploy to AWSを選択。
    • 

  • パラメータを入力して進める。EC2インスタンスタイプはc5など指定のものしか使えないので無駄に起動したままにしないように注意。不要になったら終了していい。
    • 

  • 転送元。Systems Manager→メンテナンスウィンドウ→アクションからメンテナス時間の編集→CRON/Rate式。ここで設定した時間に転送されるので一度だけ実行されるように設定。タイムゾーンはUTC。
    • 

  • 転送先。DataSyncのページで転送状態を確認。ファイル数が多いとかなり時間がかかるはず。
    • 

  • 転送が完了したらマウントターゲットのVPCを変更。
    • 

  • 全部終わったらCloudFormationのin-cloud-transferを削除してEC2などを削除。DataSync関連は消えてないので手動で削除。
    • 




この後マウントして必要ならパーミッションなどの変更。これも時間かかる。

いきなり数百GBのEFSを転送しようとせず小さいEFSで練習したほうがいい。



東京リージョンでEFS使えるようになったのが2018年、DataSyncでEFS-to-EFSの転送できるようになったのが2019年5月末なのでリージョン間転送を実際にやった人がいなくて情報はほとんどない。AWS側の仕様も途中で少し変わってる。

https://aws.amazon.com/jp/about-aws/whats-new/2019/05/aws-datasync-now-supports-efs-to-efs-transfer/


    

  



    
    
        
  • 
            
        
    • 
        
  • 
            
            
        
    • 
        
  • 
            このエントリーをはてなブックマークに追加
        
    • 
        
  • 
            Qiitaで続きを読む 
        
    • 
    
















  

    

    

    


      

        
    
          
  •  投稿日：2019-07-24T10:23:36+09:00
    • 

        

      

      

        [AWS]Aurora Serverless for PostgreSQLが休止状態から起動するまでの時間を調べた
      





      



    

  


  

      

    


概要



Aurora Serverless for PostgreSQLがGAになって少し経ちました。

AuroraのAutoScaling対応やRDSのストレージ自動拡張等が実装されProvisionedでもどんどん便利になっていますが、それでもServerLess版の手軽さはとても魅力的ですね。



私のチームでも早速Serverless版を利用しようと思いましたが、

ウリの一つである一定時間アクセスが無いと自動で休止する機能が、実際どの程度影響を及ぼすのか気になりましたので調べてみました。




調査方法



Aurora Serverlessが休止状態かどうかは、CloudWatchの「ServerlessDatabaseCapacity」の値で確認できます。

この値を60秒置きにチェックし、0のとき(=休止状態)のみDBに接続、

リクエストが返るまでの時間を記録するシェルスクリプトを作成しました。



Auroraは東京リージョンに作成、接続元は同じ東京リージョン上のEC2からとしました。




結果



とりあえず24回取りました。

result.png







Time
Result(sec)






2019-07-23T06:51:05
38.095




2019-07-23T06:59:36
28.348




2019-07-23T07:07:18
23.734




2019-07-23T07:15:50
26.829




2019-07-23T07:23:20
39.639




2019-07-23T07:31:59
27.801




2019-07-23T07:40:37
26.824




2019-07-23T07:48:11
36.098




2019-07-23T07:56:49
34.107




2019-07-23T08:04:21
30.995




2019-07-23T08:13:51
34.447




2019-07-23T08:22:35
28.92




2019-07-23T08:30:01
26.74




2019-07-23T08:38:35
40.174




2019-07-23T08:46:02
22.82




2019-07-23T08:54:30
30.375




2019-07-23T09:02:55
23.834




2019-07-23T09:11:27
24.736




2019-07-23T09:20:57
20.693




2019-07-23T09:28:23
28.859




2019-07-23T09:35:42
26.474




2019-07-23T09:48:12
22.746




2019-07-23T09:57:45
30.394




2019-07-23T10:04:34
29.979







※環境とスクリプトが適当だったのでUTCだったり実行間隔がバラバラだったりしますがご容赦



結果として、実行時間の平均値は「29.32秒」となりました。

MySQL版登場時に起動に数十秒～数分かかるという記事があがっていたのもあり、

相当悪いと覚悟してましたが、ギリギリ使えるかなという感じですね。



起動時間が気になる場合は、常時起動しておくこともできますが、

「真夜中はほとんど接続が来ないが絶対ではない」 というサービスにとって、

本機能のコストメリットは影響度が非常に高いと思いますので、

キャッシュ等も利用してうまく付き合っていきたいですね。




その他



本稿で調査したとおり、Aurora Serverless for PostgreSQLでは、

一定時間(最短5分最長24時間)未接続だと自動でインスタンスを停止してくれる機能がありますが、

この機能はデフォルトオフなのでご注意ください。（隠れてるので初見時見落とした）



また、Provisionedの感覚でCloudWatch等からヘルスチェック入れると

常時起動状態になってしまうことにも注意してください。




参考



https://dev.classmethod.jp/cloud/aws/aurora-serverless-mysql-generally-available/

https://dev.classmethod.jp/cloud/aws/aurora-postgresql-serverless-ga/


    

  



    
    
        
  • 
            
        
    • 
        
  • 
            
            
        
    • 
        
  • 
            このエントリーをはてなブックマークに追加
        
    • 
        
  • 
            Qiitaで続きを読む 
        
    • 
    
















  

    

    

    


      

        
    
          
  •  投稿日：2019-07-24T10:15:48+09:00
    • 

        

      

      

        【初心者】AWS Application Discovery Service を使ってみる
      





      



    

  


  

      

    


目的



    

  • AWS Application Discovery Serviceについて仕事上の相談があり、勉強（知ったかぶり）のため、基本動作を確認することにした。
    • 





AWS Application Discovery Service とは（自分の理解）



    

  • オンプレ等、AWSとは別環境で稼働しているサーバ（物理/仮想問わない）のスペック、負荷状況等を収集できるサービス。
    • 

  • 収集したデータを元にAWSに移行する場合の必要スペック（インスタンスタイプ等）を設計し、移行計画を立案する。
    • 

  • AWS Application Discovery Service で環境調査をして、AWS Server Migration Service （AWSへの移行を行うサービス）等で実際にMigrationを行う。それらの進捗を管理画面（AWS Migration Hub：マネージメントコンソール内で、移行関連サービスを一覧できる画面）で一元管理する、という仕組み。
    • 





AWS Application Discovery Service の種類



    

  • エージェント有タイプとエージェントレスタイプの2種類がある。VMWare環境（＝vCenterにアクセス可能な環境）であれば、Connectorを入れて、エージェントレスでvCenter配下のインスタンスのデータ収集が可能。ただし収集できるデータはエージェント有タイプのほうが多い。
    • 

  • 収集できるデータについては公式ユーザガイドを参照。
    • 





やったこと



以下を実施した（今回はエージェント有タイプのみ検証）。



    

  • オンプレ環境のインスタンス(WS2016)にAWS Application Discovery Serviceのエージェントをインストール。
    • 

  • 管理画面(AWS Migration Hub)やAthenaにて、データ収集状況の確認、収集データの内容確認を行う。
    • 





構成図



構成図.png



    

  • AWS Migration Hub, AWS Application Discovery Serviceが使えるのは2019/7/23現在、Oregonリージョンのみ。
    • 





導入手順



    

  • エージェント用IAMユーザ作成


      

    • 専用のIAMユーザを作成し、エージェントがデータをアップロードするための権限「AWSApplicationDiscoveryAgentAccess」を付与し、AccessKey/SecretKeyを発行する。このKeyをエージェントのインストール時に使用する。
      • 

    

    • 

  • 

    オンプレ上のサーバ(WS2016)へのエージェントのインストール
    


      

    • 管理画面からWindows用のエージェントのインストールファイルを入手する。
      • 

    • オンプレのサーバ内のコマンドラインでエージェントをインストールする。

msiexec.exe /i AWSDiscoveryAgentInstaller.msi REGION="us-west-2" KEY_ID="<aws key id>" KEY_SECRET="<aws key secret>" /q


      • 

    • 筆者の環境では、インストール時に「Visual C++ 2015 Redistributable for x86」が必要とのエラーが出たため、これを事前にインストール。
      • 

    • 最初、マニュアルを見ずにインストーラをダブルクリックしてインストールしてしまった。それだとkeyの情報が入らないため、一度アンインストールしてやり直し。
      • 

    

    • 

  • 

    動作確認
    


      

    • インストールが成功すると、エージェントからAWSのApplication Discovery Service のエンドポイントに対して定期的にデータ送信が行われるようになる。
      • 

    • ステータスは以下の管理画面（Migration Hub - Discover - Data Collectors - Agents）で閲覧可能。エージェントの状態が表示される。
      • 

    

    • 




apd10a.png




収集データ確認手順



    

  • (1)Migration Hub 画面での確認


      

    • 管理画面（Discover - Servers） から、収集したサーバ情報の概要（OS、CPU数、MEM、NIC数、IPアドレス等）の表示が可能。
      • 

    

    • 




apd11a.png



    

  • (2)csv Exportでの確認


      

    • 上記の画面(Discover - Servers) で「Export server details」を実行すると、指定時刻から最大72時間分のデータをcsv出力することが可能。
apd12a.png

      • 

    • 「destinationProcessConnection」、「networkInterface」、「osInfo」、「Process」、「sourceProcessConnection」の5種類のcsvデータが出力される。以下は「process」の出力例。
      • 

    

    • 




apd13.png



    

  • (3)Athena での確認


      

    • 管理画面(Migration Hub - Discover - Data Collectors - Agents)で、「Data Exploration in Amazon Athena」のスイッチをONにすると、自動的にKinesis Data Firehoseの設定が行われ、情報がS3に保存される。
apd15.png

      • 

    • 以下のようにKinesis Data Firehoseの入出力が自動設定される。
apd14.png

      • 

    • 以下はAthenaでのデータ検索例。
apd16.png

      • 

    

    • 





所感



    

  • 「Application Discovery Service」 というサービス名だが、動作プロセス等は取得できるものの、インストールされているアプリケーション(Officeとか)が取れるわけではないので、インベントリ的な使い方ではなさそう。
    • 

  • オンプレのvCenterにアクセスできる権限が得られるのであれば、サーバ情報が一気にまとめて取得できるので、移行対象サーバリストを作るのに便利かなと感じた。
    • 

  • 移行関連のサービスがいろいろ出ているため、他のものも検証してみたい。
    • 



    

  



    
    
        
  • 
            
        
    • 
        
  • 
            
            
        
    • 
        
  • 
            このエントリーをはてなブックマークに追加
        
    • 
        
  • 
            Qiitaで続きを読む 
        
    • 
    
















  

    

    

    


      

        
    
          
  •  投稿日：2019-07-24T09:00:16+09:00
    • 

        

      

      

        Amazon Managed BlockchainでHyperledger Fabricのブロックチェーンネットワークをさくっと構築するAWS CloudFormationのテンプレートを作ってみた(解説編)
      





      



    

  


  

      

    
Amazon Managed Blockchain(AMB)でブロックチェーンネットワークを構築するのが手間になったので、AWS CloudFormation(CFn)を利用して構築できるようにしてみました。使い方は下記をご参考ください。



Amazon Managed BlockchainでHyperledger Fabricのブロックチェーンネットワークをさくっと構築するAWS CloudFormationのテンプレートを作ってみた(使い方編) - Qiita

https://qiita.com/kai_kou/items/dc7dbe947a7cc6d0a8db



Cfnのテンプレートを作成するのにいくつかハマったりしたので解説がてらまとめてみます。

テンプレートはGitHubにアップしています。



kai-kou/amazon-managed-blockchain-cfn-template

https://github.com/kai-kou/amazon-managed-blockchain-cfn-template




CFnがAMBリソースに対応していない



AMBのネットワークやメンバーなどのリソースがCFnでサポートされていません。(2019/07/03時点)



AWS Resource and Property Types Reference - AWS CloudFormation

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-template-resource-type-ref.html



Release History - AWS CloudFormation

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/ReleaseHistory.html



そのためAWS Lambda-backedカスタムリソースを利用してLambda関数でAWS SDKを利用してAMBのネットワークやメンバーを作成する必要があります。



詳細は下記が参考になります。



AWS SDK for Python(boto3)でAmazon Managed Blockchainのブロックチェーンネットワークを作成してみた - Qiita

https://qiita.com/kai_kou/items/9e16274b6a5c30aa6086



AWS CloudFormationのLambda-backedカスタムリソースでリソースの更新・削除をする方法 - Qiita

https://qiita.com/kai_kou/items/7be2eb9a36611bb5da12




リソースの作成順を制御する



AMBのPeerノードはネットワーク(メンバー)が利用可能になってから追加する必要があるため、CFnのDependsOn 属性でリソースの作成順を制御してネットワーク(→メンバー)→Peerノードの順にリソースを作成します。

※ネットワークで最初のメンバーはネットワークと同時に作成する必要があります。



DependsOn 属性 - AWS CloudFormation

https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/aws-attribute-dependson.html




AWS Lambda-backedカスタムリソースでリソース作成完了を待ち受ける



DependsOn 属性でリソースの作成順を制御することができたのですが、AMBのリソース(ネットワーク、Peerノード)をAWS CLIやAWS SDKで作成するとNetworkId などがすぐにレスポンスとして返ってきます。AMBだと「レスポンスが返ってきた=リソース作成できた」ではなく「レスポンスが返ってきた=リソース作成が開始された」となります。リソースが作成完了し利用可能になるには20分ほどかかります。



なので、CFnでネットワーク作成してすぐにPeerノードを作成しようとするとネットワークが利用可能になっておらずエラーになります。



そのためCFnでリソースの作成を待ち受けるのにAWS Lambda-backedカスタムリソースでどうにかする必要がありますが、AMBネットワークの作成には20分程度かかり、AWS Lmabdaのタイムアウト(15分)を超えてしまうため、作成用のカスタムリソースだけでは待受けすることができません。

そこで、待受用のカスタムリソースを定義することで、AWS Lambdaのタイムタウト(15分) x リトライ回数(3回)で45分まで待ち受けられるようにします。詳細は下記が参考になります。



AWS CloudFormationのLambda-Backedカスタムリソースでリソース作成を待ち受けできるようにする - Qiita

https://qiita.com/kai_kou/items/57699a4e84ded2c1bfc4



このリソース作成を待ち受ける実装とDependsOn 属性を利用することでAMBのリソースが作成できるようになりました。下記はCFnのテンプレートから抜粋したリソース定義となります。





テンプレート抜粋


Resources:
  # ネットワーク作成用のカスタムリソース
  CreateBlockchainNetwork:
    Type: Custom::CustomResource

  # リソース作成待受用のカスタムリソース
  BlockchainNetwork:
    Type: Custom::CustomResource
    DependsOn: CreateBlockchainNetwork

  # リソース情報取得用のカスタムリソース
  BlockchainMember:
    Type: Custom::CustomResource
    DependsOn: BlockchainNetwork

  # Peerノード作成用のカスタムリソース
  CreateBlockchainPeerNode:
    Type: Custom::CustomResource
    DependsOn: BlockchainMember

  # リソース作成待受用のカスタムリソース
  BlockchainPeerNode:
    Type: Custom::CustomResource
    DependsOn: CreateBlockchainPeerNode







AWS Lambdaで利用できるAWS SDKを最新にする



AMBは2019/05/01にGAとなったサービスです。



New – Amazon Managed Blockchain – Create & Manage Scalable Blockchain Networks | AWS News Blog

https://aws.amazon.com/jp/blogs/aws/new-amazon-managed-blockchain-create-manage-scalable-blockchain-networks



AWS Lambdaの関数(Python)で利用できるAWS SDK(boto3 1.9.42)だとAMBが対応していないバージョンとなるため、AWS Lambda Layersを利用して最新のAWS SDK(boto3 1.9.139 以上)を利用する必要があります。(2019/07/03時点)



boto3/CHANGELOG.rst at develop · boto/boto3

https://github.com/boto/boto3/blob/develop/CHANGELOG.rst#19139





api-change:managedblockchain: [botocore] Update managedblockchain client to latest version






エラー例





Lambda関数の実装


import json
import boto3

def lambda_handler(event, context):
    print(boto3.__version__)
    client = boto3.client("managedblockchain")

    return {
        'statusCode': 200,
        'body': json.dumps('Hello from Lambda!')
    }








実行ログ


START RequestId: 1f574950-f61d-4d05-a2b6-a56e11eb2201 Version: $LATEST
1.9.42
[ERROR] UnknownServiceError: Unknown service: 'managedblockchain'. Valid service names are: acm, acm-pca, alexaforbusiness, apigateway, application-autoscaling, appstream, appsync, athena, autoscaling, autoscaling-plans, batch, budgets, ce, chime, cloud9, clouddirectory, cloudformation, cloudfront, cloudhsm, cloudhsmv2, cloudsearch, cloudsearchdomain, cloudtrail, cloudwatch, codebuild, codecommit, codedeploy, codepipeline, codestar, cognito-identity, cognito-idp, cognito-sync, comprehend, config, connect, cur, datapipeline, dax, devicefarm, directconnect, discovery, dlm, dms, ds, dynamodb, dynamodbstreams, ec2, ecr, ecs, efs, eks, elasticache, elasticbeanstalk, elastictranscoder, elb, elbv2, emr, es, events, firehose, fms, gamelift, glacier, glue, greengrass, guardduty, health, iam, importexport, inspector, iot, iot-data, iot-jobs-data, iot1click-devices, iot1click-projects, iotanalytics, kinesis, kinesis-video-archived-media, kinesis-video-media, kinesisanalytics, kinesisvideo, kms, lambda, lex-models, lex-runtime, lightsail, logs, machinelearning, macie, marketplace-entitlement, marketplacecommerceanalytics, mediaconvert, medialive, mediapackage, mediastore, mediastore-data, mediatailor, meteringmarketplace, mgh, mobile, mq, mturk, neptune, opsworks, opsworkscm, organizations, pi, pinpoint, pinpoint-email, polly, pricing, rds, redshift, rekognition, resource-groups, resourcegroupstaggingapi, route53, route53domains, s3, sagemaker, sagemaker-runtime, sdb, secretsmanager, serverlessrepo, servicecatalog, servicediscovery, ses, shield, signer, sms, snowball, sns, sqs, ssm, stepfunctions, storagegateway, sts, support, swf, transcribe, translate, waf, waf-regional, workdocs, workmail, workspaces, xray
(略)






AWS Lambda Layersを利用して最新のAWS SDKを利用する方法は下記が参考になります。



AWS CloudFormationのAWS Lambda-backedカスタムリソースで最新のAWS SDKを利用する - Qiita

https://qiita.com/kai_kou/items/db0924f8bbd0fd03eb94




AMBリソースの更新・削除に対応する



AMBリソースはAWS Lambda-backedカスタムリソースで作成しているので、更新や削除もLambda-backedカスタムリソースで行う必要があります。



詳細は下記が参考になりますが、こちらもリソース作成の待受と同じく、作成とは別のカスタムリソースを定義する必要があります。



AWS CloudFormationのLambda-backedカスタムリソースでリソースの更新・削除をする方法 - Qiita

https://qiita.com/kai_kou/items/7be2eb9a36611bb5da12



作成待ちと更新・削除を担うカスタムリソースは共通化できたので、最終的には下記のようなリソース定義となりました。





テンプレート抜粋


Resources:
  # ネットワーク作成用のカスタムリソース
  CreateBlockchainNetwork:
    Type: Custom::CustomResource

  # リソース作成待受とリソース情報取得・更新・削除用のカスタムリソース
  BlockchainNetwork:
    Type: Custom::CustomResource
    Properties:
      NetworkId: !GetAtt CreateBlockchainNetwork.NetworkId
    DependsOn: CreateBlockchainNetwork

  # リソース情報取得用のカスタムリソース
  BlockchainMember:
    Type: Custom::CustomResource
    Properties:
      NetworkId: !GetAtt BlockchainNetwork.Network.Id
      MemberId: !GetAtt CreateBlockchainNetwork.MemberId
    DependsOn: BlockchainNetwork

  # Peerノード作成用のカスタムリソース
  CreateBlockchainPeerNode:
    Type: Custom::CustomResource
    Properties:
      NetworkId: !GetAtt BlockchainNetwork.Network.Id
      MemberId: !GetAtt BlockchainMember.Member.Id
    DependsOn: BlockchainMember

  # リソース作成待受とリソース情報取得・更新・削除用のカスタムリソース
  BlockchainPeerNode:
    Type: Custom::CustomResource
    Properties:
      NetworkId: !GetAtt BlockchainNetwork.Network.Id
      MemberId: !GetAtt BlockchainMember.Member.Id
      NodeId: !GetAtt CreateBlockchainPeerNode.NodeId
    DependsOn: CreateBlockchainPeerNode







AWS lambda-backedカスタムリソースで返すリソース情報(JSON)に気をつける



AWS lambda-backedカスタムリソースのLambda関数ではcfnresponse.send(event, context, cfnresponse.SUCCESS, data) のようにして処理結果をCFnに返すことができます。



最後のパラメータdata はJSONとなり、CFnのFn::GetAtt で参照可能です。



カスタムリソースの応答オブジェクト - AWS CloudFormation

https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/crpg-ref-responses.html





応答で送信される、custom resource providerによって定義された名前と値のペア。ここで指定する値には、Fn::GetAtt を使用して、テンプレート内の名前でアクセスできます。





ただし、ネストされたJSONをdata に含めてもNetwork.Id のようにして参照できないため、AWS SDKでAMBのリソース情報を取得して得られるJSONをそのままでは返すことができませんでした。



AWS CloudFormationのLambda-BackedカスタムリソースでネストされたJSONを返しても参照できない - Qiita

https://qiita.com/kai_kou/items/61a2b3c69ae2af4f2e40



なので、AWS SDKでAMBのリソース情報を取得して得られるJSONを加工する必要があります。

JSONのキーをNetwork.Id とすると、CFn側でもNetwork.Id と参照できるようにしています。





LambdaからCFnにネットワーク情報を返す例


import cfnresponse
import boto3
import json
from datetime import date, datetime
def handler(event, context):
  client = boto3.client("managedblockchain")
  networkId = event['ResourceProperties']['NetworkId']
  response = {}
  if event['RequestType'] == 'Create':
    network = client.get_network(
      NetworkId=networkId
    )

    orderingServiceEndpoint = network['Network']['FrameworkAttributes']['Fabric']['OrderingServiceEndpoint']
    vpcEndpointServiceName =  network['Network']['VpcEndpointServiceName']
    response = {
      "Network.Id": networkId,
      "Network.FrameworkAttributes.Fabric.OrderingServiceEndpoint": orderingServiceEndpoint,
      "Network.VpcEndpointServiceName": vpcEndpointServiceName
    }
  cfnresponse.send(event, context, cfnresponse.SUCCESS, response)






詳細は下記が参考になります。



AWS CloudFormationのLambda-BackedカスタムリソースでネストされてるっぽいJSONを返す方法 - Qiita

https://qiita.com/kai_kou/items/d030117c694531410203




Hyperledger FabricのクライアントをEC2インスタンスで構築する



Hyperledger FabricのクライアントをEC2インスタンスで構築する定義は下記を参考にさせてもらいました。



awslabs/amazon-managed-blockchain-client-templates: AWS CloudFormation templates to provision Amazon EC2 instances and install and configure clients for use with blockchain frameworks in Amazon Managed Blockchain

https://github.com/awslabs/amazon-managed-blockchain-client-templates



こちらはHyperledger FabricのクライアントとなるEC2インスタンスを作成するテンプレートでしたので、自前のテンプレートへ組み込み、AMBで必要となるリソースの作成後、インスタンスが作成されるようにしました。



ポイントとしては以下となります。




CFnのcfn-signal ヘルパースクリプトで完了シグナルをCFnに返す



CFnでEC2インスタンスを作成すると、EC2インスタンスのステータスがRunning となった時点でリソース作成完了となります。

そのため、テンプレートのUserData で定義しているコマンド実行でエラーとなっても正常完了扱いとなり不便だったので、CFnのcfn-signal ヘルパースクリプトで完了シグナルをCFnに返すようにしました。



cfn-signal を利用するには、CreationPolicy を定義する必要があります。





EC2インスタンス定義_一部抜粋


  BlockchainClient:
    Type: AWS::EC2::Instance
      UserData:
        Fn::Base64:
          Fn::Sub:
            - |
              #!/bin/bash
              (略)
              /opt/aws/bin/cfn-signal -e $? --stack ${AWS::StackName} --resource BlockchainClient --region ${AWS::Region}
    CreationPolicy:
      ResourceSignal:
        Timeout: PT20M






詳細は下記が参考になります。



cfn-signal - AWS CloudFormation

https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/cfn-signal.html




Fn::Sub で変数の取扱い



UserData に指定する値はFn::Base64 とFn::Sub を用いて指定しています。

Fn::Sub は文字列中に置き換えたい変数がある場合に利用する関数となっています。



Fn::Sub - AWS CloudFormation

https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-sub.html





テンプレートで、スタックを作成または更新するまで使用できない値を含むコマンドまたは出力を作成するために、この関数を使用できます。





UserData を編集しているとシェル変数を利用したくなるケースがでてきますが、そのまま利用するとエラーとなるため注意が必要です。シェル変数の利用方法は下記が参考になりました。



CloudFormationの中のEC2のユーザーデータでシェル変数を使用する ｜ DevelopersIO

https://dev.classmethod.jp/cloud/aws/using-variables-in-ec2-user-data-in-cloudformation/





UserDataで変数を利用する例


      UserData:
        Fn::Base64:
          Fn::Sub:
            - |
              #!/bin/bash

              # これはOK
              echo ${HOGE}

              HOGE2=hogehoge

              # これはエラーになる
              echo ${HOGE2}

              # こうするとOK
              echo ${!HOGE2}
            - {
              HOGE: hoge
            }







Hyperledger Fabricのcliでコマンドを実行するタイミングに気をつける



以下は、UserData の後半部分の抜粋となります。ところどころでsleep コマンドを実行して待受けています。

リソース作成を繰り返し試行錯誤した結果となりますが、主に下記の理由からとなります。



    

  • Peerノードが利用可能になるのを待ち受け
    • 

  • OrdererからPeerノードへのデータ送信待ち
    • 






UserData一部抜粋


(略)
/usr/local/bin/docker-compose -f docker-compose-cli.yaml up -d
sleep 5m

# enroll
fabric-ca-client enroll -u https://${ADMIN_USERNAME}:${ADMIN_PASSWORD}@${FABRIC_CA_ENDPOINT} --tls.certfiles /home/ec2-user/${FABRIC_CA_FILE} -M /home/ec2-user/admin-msp
cp -r /home/ec2-user/admin-msp/signcerts /home/ec2-user/admin-msp/admincerts
echo '
Organizations:
(略)
' > /home/ec2-user/configtx.yaml
docker exec cli configtxgen -outputCreateChannelTx /opt/home/mychannel.pb -profile OneOrgChannel -channelID mychannel --configPath /opt/home/
sleep 30s

# Create Channel
docker exec cli peer channel create -c mychannel -f /opt/home/mychannel.pb -o ${ORDERING_SERVICE_ENDPOINT} --cafile /opt/home/${FABRIC_CA_FILE} --tls
sleep 30s

docker exec cli peer channel join -b mychannel.block -o ${ORDERING_SERVICE_ENDPOINT} --cafile /opt/home/${FABRIC_CA_FILE} --tls
sleep 30s

# Install ChainCode
docker exec cli peer chaincode install -n mycc -v v0 -p github.com/chaincode_example02/go
docker exec cli peer chaincode instantiate -o ${ORDERING_SERVICE_ENDPOINT} -C mychannel -n mycc -v v0 -c '{"Args":["init","a","100","b","200"]}' --cafile /opt/home/${FABRIC_CA_FILE} --tls
sleep 30s

docker exec cli peer chaincode list --instantiated -o ${ORDERING_SERVICE_ENDPOINT} -C mychannel --cafile /opt/home/${FABRIC_CA_FILE} --tls

/opt/aws/bin/cfn-signal -e $? --stack ${AWS::StackName} --resource BlockchainClient --region ${AWS::Region}







UserData の実行ログの確認方法



UserData で指定したコマンドの実行ログが確認できないか調べてみたらしっかりと出力されていました。

下記が参考になりました。



Linux インスタンスでの起動時のコマンドの実行 - Amazon Elastic Compute Cloud

https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/user-data.html



AWSのCloud initのログの場所 | しびら

http://yamada.daiji.ro/blog/?p=191





EC2インスタンス内


$ cat /var/log/cloud-init-output.log
(略)
+ docker exec cli peer channel join -b mychannel.block -o orderer.n-xxxxxxxxxxxxxxxxxxxxxxxxxx.managedblockchain.us-east-1.amazonaws.com:30001 --cafile /opt/home/managedblockchain-tls-chain.pem --tls
2019-07-01 09:17:03.663 UTC [channelCmd] InitCmdFactory -> INFO 001 Endorser and orderer connections initialized
2019-07-01 09:17:03.903 UTC [channelCmd] executeJoin -> INFO 002 Successfully submitted proposal to join channel
+ sleep 30s
+ docker exec cli peer chaincode install -n mycc -v v0 -p github.com/chaincode_example02/go
2019-07-01 09:17:34.076 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 001 Using default escc
2019-07-01 09:17:34.076 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 002 Using default vscc
2019-07-01 09:17:34.490 UTC [chaincodeCmd] install -> INFO 003 Installed remotely response:<status:200 payload:"OK" >
+ sleep 30s
+ docker exec cli peer chaincode instantiate -o orderer.n-xxxxxxxxxxxxxxxxxxxxxxxxxx.managedblockchain.us-east-1.amazonaws.com:30001 -C mychannel -n mycc -v v0 -c '{"Args":["init","a","100","b","200"]}' --cafile /opt/home/managedblockchain-tls-chain.pem --tls
2019-07-01 09:17:44.686 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 001 Using default escc
2019-07-01 09:17:44.686 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 002 Using default vscc
+ sleep 30s
+ docker exec cli peer chaincode list --instantiated -o orderer.n-xxxxxxxxxxxxxxxxxxxxxxxxxx.managedblockchain.us-east-1.amazonaws.com:30001 -C mychannel --cafile /opt/home/managedblockchain-tls-chain.pem --tls
Get instantiated chaincodes on channel mychannel:
Name: mycc, Version: v0, Path: github.com/chaincode_example02/go, Escc: escc, Vscc: vscc
+ /opt/aws/bin/cfn-signal -e 0 --stack amb-cfn-test --resource BlockchainClient --region us-east-1
Cloud-init v. 0.7.6 finished at Mon, 01 Jul 2019 09:19:16 +0000. Datasource DataSourceEc2.  Up 692.70 seconds







まとめ



AMBのリソースをCFnで管理するのにAWS Lambda-backedカスタムリソースを利用することができましたが、そこそこハマるところがあり、テンプレート作成に時間がかかりました。

1度作成できたら応用を効かせることができそうですので、個人的には良いテンプレートができたなと思ってます^^




参考



Amazon Managed BlockchainでHyperledger Fabricのブロックチェーンネットワークをさくっと構築するAWS CloudFormationのテンプレートを作ってみた(使い方編) - Qiita

https://qiita.com/kai_kou/items/dc7dbe947a7cc6d0a8db



kai-kou/amazon-managed-blockchain-cfn-template

https://github.com/kai-kou/amazon-managed-blockchain-cfn-template



AWS Resource and Property Types Reference - AWS CloudFormation

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-template-resource-type-ref.html



Release History - AWS CloudFormation

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/ReleaseHistory.html



AWS SDK for Python(boto3)でAmazon Managed Blockchainのブロックチェーンネットワークを作成してみた - Qiita

https://qiita.com/kai_kou/items/9e16274b6a5c30aa6086



AWS CloudFormationのLambda-backedカスタムリソースでリソースの更新・削除をする方法 - Qiita

https://qiita.com/kai_kou/items/7be2eb9a36611bb5da12



DependsOn 属性 - AWS CloudFormation

https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/aws-attribute-dependson.html



AWS CloudFormationのLambda-Backedカスタムリソースでリソース作成を待ち受けできるようにする - Qiita

https://qiita.com/kai_kou/items/57699a4e84ded2c1bfc4



New – Amazon Managed Blockchain – Create & Manage Scalable Blockchain Networks | AWS News Blog

https://aws.amazon.com/jp/blogs/aws/new-amazon-managed-blockchain-create-manage-scalable-blockchain-networks



boto3/CHANGELOG.rst at develop · boto/boto3

https://github.com/boto/boto3/blob/develop/CHANGELOG.rst#19139



AWS CloudFormationのAWS Lambda-backedカスタムリソースで最新のAWS SDKを利用する - Qiita

https://qiita.com/kai_kou/items/db0924f8bbd0fd03eb94



カスタムリソースの応答オブジェクト - AWS CloudFormation

https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/crpg-ref-responses.html



AWS CloudFormationのLambda-BackedカスタムリソースでネストされたJSONを返しても参照できない - Qiita

https://qiita.com/kai_kou/items/61a2b3c69ae2af4f2e40



AWS CloudFormationのLambda-BackedカスタムリソースでネストされてるっぽいJSONを返す方法 - Qiita

https://qiita.com/kai_kou/items/d030117c694531410203



awslabs/amazon-managed-blockchain-client-templates: AWS CloudFormation templates to provision Amazon EC2 instances and install and configure clients for use with blockchain frameworks in Amazon Managed Blockchain

https://github.com/awslabs/amazon-managed-blockchain-client-templates



cfn-signal - AWS CloudFormation

https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/cfn-signal.html



Fn::Sub - AWS CloudFormation

https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-sub.html



CloudFormationの中のEC2のユーザーデータでシェル変数を使用する ｜ DevelopersIO

https://dev.classmethod.jp/cloud/aws/using-variables-in-ec2-user-data-in-cloudformation/



Linux インスタンスでの起動時のコマンドの実行 - Amazon Elastic Compute Cloud

https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/user-data.html



AWSのCloud initのログの場所 | しびら

http://yamada.daiji.ro/blog/?p=191


    

  



    
    
        
  • 
            
        
    • 
        
  • 
            
            
        
    • 
        
  • 
            このエントリーをはてなブックマークに追加
        
    • 
        
  • 
            Qiitaで続きを読む 
        
    • 
    
















  

    

    

    


      

        
    
          
  •  投稿日：2019-07-24T00:17:13+09:00
    • 

        

      

      

        LinuxでArtifactory OSSをインストール（PostgreSQLをDB使用）
      





      



    

  


  

      

    
JFrogさんの公式記事にもやりかたがたくさん書いてありますが、個人的には詳細がたりなかったので一応自分用メモとして書きます。

ちょっと日本語がおかしいかもしれませんが悪しからず・・・語彙力がないので






7/23/2019



使ったのは

・Amazon Linux AMI 2018.03.0 (HVM)のt2.medium

Artifactoryさんはなかなか大きいので、無料版のMicroじゃウェブのUIをだしてくれませんでした

・Artifactory OSS zip

・Java 1.8.0

・ポート8081






デフォルトDB(Derby)ではなく外部データベースを使用したので

・PostgreSQL

・postgresql-42.1.4.jre6

・ポート5432



PostgreSQLについては気が向いたら別の記事で説明します




システムのアップデート



# yum update -y




全体をアプデしていきます




Java 1.8.0をインストール



デフォルトではJava1.7がインストールされてますけど1.8.0じゃないとダメなのでJavaのバージョンを変えます



# yum install java-1.8.0 -y




1.8.0があるオプションをセレクトします



# /usr/bin/alternatives --config java




バージョンを確認



# java-version





Javaの場所を確認



のちのち必要になってくるので

なんとなーくここにあるんじゃない？って感じでリストをくれますけど、ちゃんと確認しにいってね・・・



# whereis java





Artifactory OSSをインストール



JFrogさんの記事です: https://www.jfrog.com/confluence/display/RTF/Installing+on+Linux+Solaris+or+Mac+OS

手順とか書いてありましたが英文苦手すぎて・・・




ZIPファイルのダウンロード



ここからダウンロードします：https://jfrog.com/open-source/#artifactory



ダウンロードがはじまりましたらダウンロードリンクをブラウザからコピペします(ものすごく長いです)



# wget https://akamai.bintray.com/fc/fc2277fa4da9cfd83ca3af9ca94b2b03717e3df60573ab19f0281c9954117eda?__gda__=exp=1563887491~hmac=09a20401bc93409773d1097aa6e41529b0624b248676e3cc5445817edf720062&response-content-disposition=attachment%3Bfilename%3D%22jfrog-artifactory-oss-6.11.3.zip%22&response-content-type=application%2Foctet-stream&requestInfo=U2FsdGVkX18lyb8812SXCcJp8ELw0ivPZUVvKCJIkK6KSkVU69pcOAN0iaIE1qhK98x5LeNHn2KjjYT-mx_iknCgWrTdRW6iEzgymbsKrXAMBoKXDd2EtzZt5bPoWn5UPs9jBiGseDE2sxpOd3Ou3_rZNABBT9AZS3WJZT8tFjE&response-X-Checksum-Sha1=fe39d031c59c33f51fd881b4294740f3576380d2&response-X-Checksum-Sha2=fc2277fa4da9cfd83ca3af9ca94b2b03717e3df60573ab19f0281c9954117eda




インスタンスにZIPファイルがダウンロードしたのち、

わかりやすい名前(jfrog-artifactory-oss-6.11.1.zip)に改名 



# ll

ファイルの改名
# mv 現在名をコピペ jfrog-artifactory-oss-6.11.1.zip





解凍先を作る



いろんな.sh内のコンフィグがこのpathを使ってるので似せるだけな簡単なお仕事なんですが、これを知るまでなぜPostgreSQLのDBで動かなかったか分からなかった苦悩の時間・・・返して・・・



homeからrootに上ってroot/var/opt/に入りjfrogのディレクドリーを制作



# mkdir jfrog




解凍します！！！！



# unzip jfrog-artifactory-oss-6.11.1.zip /var/opt/jfrog/




jfrog内に新しくできたファイル名をartifactoryに改名します



# mv jfrog-artifactory-oss-6.11.1 artifactory





PostgreSQL



ここからはPostgreSQLのターン！

繋げるためにはまだまだ作業が必要



artifactory/misc/db/postgresql.properties を/etcにコピーさせます



cp artifactory/misc/db/postgresql.properties  artifactory/etc/




名前をdb.propertiesに変更します



# mv postgresql.properties  db.properties




PostgreSQL DBのIP情報や、作ったartifactoryのユーザー情報を入れていきます

終わったらちゃんとセーブしてね！



# vi db.propoerties





Tomcat/PostgreSQL JDBC



PostgreSQLをちゃんと走らせるためにはJDBCが必要になります。私はpostgresql-42.1.4.jre6を使いました

リンク：https://jdbc.postgresql.org/download.html



ZIPファイルをダウンロードした時と同じ要領でartifactory/tomcat/lib/に入れていってください



# wget コピーしたJDBCのダウンロードリンクをここにｯﾍﾟしてください




ダウンロードが終わりましたら走れるようにします。緑になるので分かりやすいですよ



# chmod +x postgresql-42.1.4.jre6.jar





artifactory.default



artifactory/bin/artifactory.default 内をコンフィグします

初めらへんでメモしたJavaのロケーションが必須になりますよ！そうじゃないとTomcatがお仕事してくれません



# vi artifactory.default

３つのエクスポートのコメントを消してね

#Default Values
export ARTIFACTORY_HOME=/var/opt/jfrog/artifactory
export ARTIFACTORY_USER=artifactory
export JAVA_HOME=/usr/lib/java-1.8.0 (メモしたJavaの場所を書いてね)
#export START_LOCAL_REPLICATOR=true






Arifactoryをサービスとしてインストール



binに移動してインストール



# cd artifactory/bin/
# ./installService.sh





Run Artifactory



リスタートしても自動で動くようにchkconfigもしていきます



# chkconfig artifactory on
# service artifactory start


http://local_host_IP:8081
でUIにアクセスできます




アクセスしたのちAdminとしてのパスワードを登録ができるようになるので、登録するまで小さなウィンドウはスキップしないでね！



ね、簡単でしょう？

個人的にはここまでたどり着くのにかなり時間がかかりました・・・書き出してみると簡単なんですけどね。

なので、もしこれが誰かの役に立てれば幸いです:relieved:






余談：ログはcatalina.outが個人的には見やすかったです






お世話になったリンク



Zipファイルのダウンロード

・https://jfrog.com/open-source/#artifactory



公式の説明

・https://www.jfrog.com/confluence/display/RTF/Installing+Artifactory



Zipファイルのダウンロード、解凍の仕方

・https://www.youtube.com/watch?v=IFF-jnAxlDs



Artifactoryのデータベースを変更

・https://www.jfrog.com/confluence/display/RTF/Configuring+the+Database



PostgreSQLを走らせるためのJDBC

・https://jdbc.postgresql.org/download.html


    

  



    
    
        
  • 
            
        
    • 
        
  • 
            
            
        
    • 
        
  • 
            このエントリーをはてなブックマークに追加
        
    • 
        
  • 
            Qiitaで続きを読む 
        
    • 
    


















						

					


					

						


							



    

									
日付別

								


  





    

									
タグ一覧