Quantcast
Channel: 技術 –サーバーワークスエンジニアブログ
Viewing all 1210 articles
Browse latest View live

Amazon EC2 Auto ScalingがAuto Scalingグループ内のインスタンス更新をサポートするようになりました!

$
0
0

こんにちは、技術1課の小倉です。
2020/6/16にアップデートがあり、Amazon EC2 Auto ScalingがAuto Scalingグループ内のインスタンス更新をサポートするようになりました!

Amazon EC2 Auto Scaling now supports Instance Refresh within Auto Scaling Groups

今までは起動設定のAMIを更新したときはEC2の停止など手動で再作成をしていましたが、本アップデートによりインスタンスを一度にまたは徐々に置き換えることができるようになりました。

Amazon EC2 Auto Scalingとは

負荷状況に応じて、事前に定義したルールに基づき、EC2の台数を自動で増減する機能です。Auto Scalingを使うことで負荷が高い時は台数を増やしリソース不足を回避してビジネスなどの機会損失を抑え、負荷が低い時は台数を減らしコストを削減することができます。
AWS公式サイト : Amazon EC2 Auto Scaling

設定方法

Auto Scalingの設定

一からAuto Scalingを設定するところからはじめますが、アップデートの確認がメインのため、最小設定で準備を進めます。
ナビゲーションペインの[起動設定]をクリックし、[起動設定の作成]をクリックします。

起動設定の作成でAMIの選択画面が表示されるので、Auto Scalingに使用するAMIを指定します(今回はAmazon Linux 2を選択しています)。

インスタンスタイプの選択画面が表示されるので、インスタンスタイプを選択し、右下の[次の手順: 詳細設定]をクリックします(今回はt3.nanoを選択しています)。

詳細設定画面が表示されるので、起動設定の名前を入力して、右下の[次の手順: ストレージの追加]をクリックします。

ストレージの追加画面が表示されるので、そのまま右下の[次の手順: セキュリティグループの設定]をクリックします。

セキュリティグループの設定画面で、[新しいセキュリティグループを作成する]を選択し、そのまま右下の[確認]をクリックします。

確認画面で設定内容を確認し、右下の[起動設定の作成]をクリックします。

キーペアの選択画面が表示されるので、キーペアを指定して、[起動設定の作成]をクリックします(今回は既存のキーペアを指定しています)。

起動設定の作成ステータス画面が表示されるので、[この起動設定を使用してAuto Scalingグループを作成する]をクリックします。

Auto Scalingグループの詳細設定画面が表示されるので、グループ名、グループサイズ、ネットワーク、サブネットを入力して、右下の[次の手順: スケーリングポリシーの設定]をクリックします。

スケーリングポリシーの設定画面で、[このグループを初期のサイズに維持する]を選択して、右下の[確認]をクリックします。

確認画面が表示されたら、内容を確認して右下の[Auto Scalingグループの作成]をクリックします。

Auto Scalingグループの作成ステータスの画面が表示されたら、[閉じる]をクリックします。
これでAuto Scalingグループが作成されました。

インスタンスの更新

インスタンスの更新をするためには、まずは先ほど実施した起動設定の作成で、別のAMIを指定した起動設定を作成します。
ナビゲーションペインの起動設定をクリックし、[操作] – [起動設定のコピー]をクリックします。

起動設定の作成に進むので、手順は先ほどと一緒なのですが、1点違うところはAMIの選択画面で先ほどとは別のAMIを指定して作成します。

起動設定作成後の画面です。現在Auto Scalingグループで使用しているのは下の起動設定です。これを上の起動設定に変更します。

ナビゲーションペインのAuto Scalingグループをクリックします。
今回のアップデートを使うためには新しいデザインのコンソールに変更しないといけないので、画面上部の[Go to the new console]をクリックします。

新しいデザインのコンソールです。
Auto Scalingの名前をクリックします。

起動設定を変更したいので、[詳細]タブを選択し、起動設定の[編集]をクリックします。

編集画面で、起動設定をあとで作成した設定を選択し、[更新]をクリックします。

起動設定が変更されました。

いま起動しているEC2インスタンスを変更した起動設定のAMIで起動させるために[インスタンス更新]タブを選択し、[インスタンス更新の開始]をクリックします。

インスタンスの更新の開始画面で、最小正常率を選択し、開始をクリックします。
最小正常率はどのくらいの割合でインスタンスの更新をするかを決めることができます。0%にすると一気にすべてのEC2インスタンスの更新を開始します。今回は2台起動しているので、50%にして1台ずつ更新させます。

インスタンスの更新がはじまりますので、しばらく待ちます。

インスタンスの更新が終わるとステータスがSuccessfulに変わります。

[アクティビティ]タブを選択するとAuto Scalingの履歴を確認することができます。
上の4つが今回のインスタンス更新で行われた履歴ですが、時刻を確認すると1台ずつ行われていることが確認できます。

また、EC2インスタンスを見ると、AMIが変更した起動設定で作成されていることを確認することができます。

まとめ

Amazon EC2 Auto ScalingがAuto Scalingグループ内のインスタンス更新をサポートするようになりました。本アップデートにより今まで手動で手間のかかる作業が簡単にできるようになりました。Auto Scalingをお使いの方はぜひ試してみてはいかがでしょうか。


【Cloud Automator】ジョブワークフローが複数のトリガーをサポートし、様々な用途で活用できるようになりました

$
0
0

2020年1月に公開いたしましたジョブワークフロー機能ですが、その後も継続的にアップデートしております。リリース以降、ご利用いただいたお客様からの声をもとにしたUIアップデートはもちろんのこと、トリガー関連で以下のようなアップデートをいたしました。

  • タイマートリガーの今すぐ実行機能をサポート
  • HTTPトリガーへの対応
  • SQSトリガーへの対応
  • スケジュールトリガーへの対応

各アップデートの活用例

タイマートリガーの今すぐ実行機能をサポート

タイマートリガーを使ったジョブワークフローを作成した場合、ジョブの実行時間は数時間〜数日後になるケースがほとんどです。作成したタイマートリガーを使ったジョブワークフローが意図したとおりに動作するか動作確認したい場合、この機能を使うとすぐにご確認いただけます。

HTTPトリガー、SQSトリガー

この2つのトリガーは既存のジョブスケジューラーなど外部システムとCloud Automatorを連携させる場合にご利用いただくトリガーになります。すでにジョブスケジューラーで一元管理をしているものの、Cloud Automatorのアクションを使いたいというケースでは、HTTPトリガー、SQSトリガーをご活用ください。

スケジュールトリガー

スケジュールトリガーは先月リリースしたばかりのトリガーとなりますが、早速対応いたしました。スケジュールトリガーは単純な繰り返し設定ではない不定期な予定をしたい場合に効果的です。リスト形式でスケジュールを指定できますので、柔軟なスケジューリングができます。

おわりに

様々なトリガーをサポートしたことによって、より多くのシーンでジョブワークフローをご活用いただけるようになりました。適切なトリガーの選び方はマニュアルページでフローチャートも用意しておりますので、参考にしてみてください。
Cloud Automatorではロードマップを公開しており、今後以下のような機能を公開する予定です。

  • ELB(ALB/NLB): ターゲットグループにEC2インスタンスを登録 アクションの追加
  • ELB(ALB/NLB): ターゲットグループからEC2インスタンスを登録解除 アクションの追加

これらの機能もジョブワークフローと組み合わせると、ELBに登録されているEC2インスタンスのアップデートを行いたい場合に、一度ELBから登録解除してアップデートし、再度ELBに登録するというワークフローが作れます。
ジョブワークフローの今後のアップデートにもご期待ください。

Cloud Automator(クラウドオートメーター)とは、ノンプログラミングでAWS運用を自動化し、AWSの利用を最大限に引き出すサービスです。バックアップや災害対策、AWS費用の削減を実現する「ジョブ」と、AWSがガイドライン通りに運用されていることを継続的に確認する「構成レビュー」という2つの機能をご提供しております。

Cloud Automator

ConnectとTranscribeをTogetherしようぜ

$
0
0

Amazon Connect 専任チームの丸山です。

Amazon Connect のご相談を受ける中で人気の高いご相談は Amazon Transcribe です。
電話の声をテキスト化して活用してみたいというご要望を多く頂いています。
今日は技術面ではなく、実際にTranscribeが業務で使えるのかについてお伝えします。
 
 

■Amazon Connect

AWSが提供するクラウド型コンタクトセンターのサービスです。
もうみなさん、使っていただいていますよね?
 

■Amazon Transcribe

AWSが提供する音声をテキストに変換する機能です。
2019年11月に待望の日本語対応をしました。
ただし現在日本語対応をしているのはバッチ処理のみとなります。
 

■Connect x Transcribe

Amazon Connect は通話録音がオプションではなく標準で利用可能です。
録音ファイルの容量契約もなく、低価格で信頼性の高いS3を利用します。
S3に保存した音声を利用してAmazon Transcribeでテキスト化をすることができます。
 

■通話録音にかかるコスト

録音したファイルの容量は1分あたり2Mbyteが目安になります。
例えば10万時間の会話を保存して月額500円くらいです。
 
もう少し具体的なイメージでも試算しましょう。
100名のオペレータが1日7時間x20日働き、そのうち80%の時間が「会話」に費やされていたとします。
電話対応の時間ではなく、会話の開始から終了までの時間が80%です。
通話録音のストレージ料金(S3)は1328円…安い、さすがS3。
※2020-06-17時点の価格表/1ドル110円で試算
 
Amazon Connectの利用料金およびストレージの料金を簡易試算できるサーバーワークスオリジナルのツールを提供しています。
具体的な試算にご活用ください。
 

■Transcribeの精度って実際のところどうなのかしら

ここはなかなかセンシティブな部分なので結論を申し上げにくいのですが、「個人の感想」を前提とすると
– 思いのほか認識率は高い
– ただし業務活用できるかは別問題
です。
 

■なかなかの認識率

2019年11月に登場した当初から認識率はかなりよいものと感じました。
自分の声を録音してテキスト化したらあらびっくり、ほぼ認識しているではありませんか。
人名や商品名など固有名詞には弱いものの、日本語としてかなりしっかり認識してくれて最初は感動したものです。
そう、最初は。
 

■サーバーワークスは電話をテキスト化しました

サーバーワークスではAmazon Connectを導入しています。
電話の情報はSlackに投稿する仕組みになっています。
ここにTranscribeをかけたテキストも投稿するようにしてみました。
その結果は…ブログには書きにくいこともあるので直接会ったときに聞いてください。
 

■通話録音音声のテキスト化が難しい理由

1)マイクの品質

マイクの品質は録音される音声データに強く影響します。
たとえば私が「こんにちは、サーバーワークスです」と話しました。
よい録音環境、そしてよいマイクを使うと以下のようにテキスト化されました。

こんにちは サーバー ワークス です

あまりよい録音環境でない場合は録音された声も小さくなり以下のようにテキスト化されました。
日 朝、 幕政
 

2)お客様側の音の品質

お客様が最高の環境でお電話をかけてくれるとは限りません。
携帯電話からのお電話も多く、外出時であることもあります。
そうなってくると場所によっては「回線」の状況が悪く音が途切れることもあります。
また「環境音」「騒音」も音に紛れ込んできます。
音が悪くなると会話のやり取りもスムーズではなくなり、よりテキスト化が難しくなります。
 

3)一人ではない、会話

電話は「朗読」ではなく「会話」です。
1人で話していれば文末まではっきり話すことができます。
しかし会話になるとなかなか難しいものです。
お互いの声がオーバーラップしてしまうことも多々あります。
変換精度も落ちますし、どこまで誰の会話なのかを切るテクニックも必要になりました。
 

4)固有名詞の壁

サーバーワークスの場合、代表電話で利用しているため
会社名
人名
が多く出てきます。
通常のコールセンターであれば商品名なども多く出てくるでしょう。
テキスト化する際に固有名詞の変換は難しく、一方弊社の場合は固有名詞率が高いため内容が把握しづらいものとなっていました。
Amazon Transcribeには、カスタム語彙が登録可能です。
ただし最大 100 の語彙、サイズは 50 KBという制限があります。
 

■テキスト化、精度向上の希望

  • よいマイクを使う
  • 安定した回線(できれば有線LAN)を使う
  • ゆっくり、はっきりめに話をする
  • お客様と会話がかぶらないようにする
などの工夫でテキスト化の精度は向上が可能です。
 
Transcribeは日々進化をしています。
サーバーワークが導入してから約半年たちました。
最初は大喜利のようなテキストも多かったのですが、今は話の内容が把握できるテキストが増えてきました。
(あ、書きにくいといいつつ書いちゃった)
 
Transcribeは今後も精度が高まるものであると期待しています。
 

■そもそもテキスト化してどうするか

まずはAmazon Connect の PoC からはじめることをおすすめしています。
実際の環境で通話品質をお確かめいただき、運用できる機能が整っているかをご確認していただいてから
本番導入をするアプローチがスムーズです。
 
通話品質は、お客様の利用環境に大きく依存します。
わたしたちサーバーワークスはネットワーク接続環境のご相談や、ヘッドセットの選定も支援させていただきながらよりよい利用環境になるようお手伝いさせていただきます。
 
通話品質がそれなりに整ってからTranscribeです。
PoCで録音したコンタクトデータをいくつかピックアップしていただければ、Transcribeをかけてテキスト化した結果をご提供いたします。
その結果を見て、業務利用できる精度であるかをご判断いただければと思います。
 

■Connectはオープン

Amazon Connectはオープンな設計思想です。
AWSプレミアコンサルティングパートナーのサーバーワークスとしてはAWS推しではありますが、他社の音声テキスト化サービスをご利用いただくことも可能です。
他社サービスとの連携についてもご相談ください。
 

■日本語ってむずかしい

テキスト化に向き合うようになって、改めて日本語は難しい言語であると感じています。
難しい、そしてだからこそ面白いなぁ、と思います。
まだまだ、誰でも完全に認識できる精度にはどこの音声テキスト化サービスも到達できていないのではないでしょうか。
 
ただ、概要を理解したり特定の単語を判定するレベルであれば、十分業務活用が可能だと思います。
またこの先かなりのスピードで進化する分野ではないかと個人的にとても期待しています。
 
 
 

MySQL5.1のデータベースをRDS for MySQLへ移行

$
0
0

某クラウドで動いていたMySQLをAmazon RDSに移行する案件を担当しました。
その際にとった方法について紹介します。

データベース移行条件

案件開始時に以下の条件が与えられました。

  • 移行元のMySQLのバージョンは5.1
  • 移行対象データベースのストレージエンジンはMyISAMだが、移行後はInnoDBにする
  • 移行時にサービスを止めることは可能

RDS for MySQLは、MyISAMでも一応は動作可能なようですが、InnoDBが推奨なようです。
この移行のタイミングでInnoDBに変更してしまおうということになりました。

Q: Amazon RDS for MySQL ではどのストレージエンジンをサポートしていますか?

MySQL の Amazon RDS における特定時点の復元およびスナップショット復元機能には、クラッシュからの回復可能なストレージエンジンが必要で、InnoDB ストレージエンジンのみがサポートされています。MySQL は様々な機能を持つ複数のストレージエンジンをサポートしていますが、それらすべてがクラッシュの回復とデータ耐久性に最適化されているわけではありません。例えば、MyISAM ストレージエンジンは、信頼性の高いクラッシュ回復をサポートしておらず、MySQL がクラッシュ後に再起動した時、特定時点の復元およびスナップショット復元が意図どおりに機能せず、データが紛失または破損する可能性があります。それでも、Amazon RDS で MyISAM を使用する場合は、このステップに従ってください。
Amazon RDS for MySQL” のよくある質問

移行方法の検討

まず、DMS(AWS Database Migration Service)を検討しました。
利用可能かどうかAWSの仕様(MySQL 互換データベースの AWS Database Migration Service のターゲットとしての使用)を確認しました。

ソースストレージエンジン (MyISAM、MEMORY など) にかかわらず、AWS DMS によってデフォルトで InnoDB テーブルとして MySQL 互換のターゲットテーブルが作成されます。

良さげです。
MyISAMをInnoDBに変換もしてくれそうな感じに書いています。

AWS DMS は MySQL のバージョン 5.5、5.6、5.7、8.0 と Aurora MySQL をサポートしています。さらに、AWS DMS は MariaDB のバージョン 10.0.24 から 10.0.28、10.1、10.2、10.3 をサポートしています。

しかし、残念ながら、5.1には対応していませんでした。
移行元MySQLを最初にアップデートし、それからDMSで移行するというステップをとれば可能そうな気はします。

ただ、今回はサービス停止時間も長めにとれるので、mysqldumpで移行することに決めました。

事前準備

RDS for MySQLのDBインスタンスを作成します。
パラメータグループなども必要に応じて移行前のものに合わせておきます。
なお、今回はMySQL5.7で作成しました。

1.移行元でDumpファイル作成

$ mysqldump --routines --events -u root -p --databases 対象データベース名 | gzip > dump.sql.gz

2.移行作業用EC2インスタンスにDumpファイルを配置

RDSへアクセスできるEC2インスタンスに、いったんDumpファイルを配置します。
このEC2インスタンスでは、mysqlコマンドが使える必要があります。
実際はあまり気にしないでいいかもしれませんが、今回は念のためにRDSとmysqlクライアントを同じバージョンにしました。

まず、MySQLクライアントをダウンロードサイトからダウンロードしました。
次に、Amazon Linux 2にもともとインストールされていたMariaDBを干渉しないように削除し、ダウンロードしたrpmファイルをインストールしました。

$ sudo yum remove mariadb-libs
$ sudo yum install mysql-community-client-5.7.26-1.el7.x86_64.rpm mysql-community-libs-5.7.26-1.el7.x86_64.rpm mysql-community-common-5.7.26-1.el7.x86_64.rpm

3.Dumpファイルの文字列を変換する

Dumpファイルはテキストデータなので、sedでMyISAMと書かれている部分をInnoDBに変換します。

$ gzip -d dump.sql.gz
$ sed -i 's/ENGINE=MyISAM/ENGINE=InnoDB/g' dump.sql

4.DumpファイルをRDSへインポート

$ mysql -u マスターユーザー名 -p -h RDSのエンドポイント < dump.sql

これで完了です。

この方法で必ず成功するかは断言できないですが、今回は成功しました。
実際の移行時は必ずテストをしていただければと思います。

まとめ

MySQL5.1、MyISAMといった古めのデータベースも、AWSのRDSに移行することができました。
移行を検討している方に参考になれば幸いです。

VDI環境でAmazon Connectを使ってみよう

$
0
0

はじめに

こんにちは。孔子の80代目子孫兼技術5課の孔です。コロナも落ち着くのかなと思いきや、第2波が待ち構えていてまた感染者が増えてきましたね。気を緩めず、安心安全に暮らすために気をつけないといけないですね。

そのコロナ対策としてリモートワークを推進する企業も増えてきたのではないかと思います。AWSで提供するサービスの中でリモートワークをサポートするサービスはWorkSpacesとAmazon Connectがあります。WorkSpacesはVDI環境を構築するサービスとなり、リモートデスクトップを使用することでセキュリティを強化することができます。また、Amazon Connectはクラウド型コールセンターを構築することにより、コールセンターのクラスター防止およびリモート対応をサポートすることができるようになります。本日はその両方に関する話を持ってきました。WorkSpacesのようなVDI環境でAmazon Connectを使用する時の注意点と、対処方法について共有します。

※Amazon Connectの基礎知識があることを前提とした内容となります。Amazon Connectに関する基礎知識はAWSが出しているblackbeltをご一読ください。blackbeltはこちらのリンクで確認できます。

ユースケース

Amazon Connectはクラウド型コールセンターを構築できるため、自宅でもお問い合わせの電話等を受けることができます。しかし自宅で電話をとるとやっぱりセキュリティが心配ですね。どのお客様と電話をしているのかの情報が盗まれる可能性もありますし、もしくは顧客情報が社内ネットワークにしかないため、社内ネットワークにアクセスする必要があるけど自宅からだとセキュリティ面が心配だったり、そもそもアクセスできなかったりする課題があります。そこでWorkSpaces環境を作り、そこからAmazon Connectを使えばこのような問題は一気に解決できるようになります。

しかしそこで問題が全て解決できるわけではなく、WorkSpaces環境でAmazon Connectを使うと新たな問題が発生します。通常ならオペレーターのローカルデバイスからお客様と音声(メディア)のやりとりが直接できるものの、WorkSpacesが途中で入ることによってホップ数が1個増えることになります。それによって音質の低下が生じてしまうことになります。

ホップ数増加による音質低下問題を解決する方法が2つあります。一つ目の方法はDeskphoneを使用すること、二つ目の方法はカスタムCCPを使用し、メディアを持たないCCPを作成する方法となります。それぞれの詳細をこれからみていきます。

※CCPに関する説明はこちらのリンクをご参考ください。

Deskphoneに転送

Deskphoneを使うとAmazon Connectの電話のメディア(音声)をCCPでなくE.164エンドポイント(例えば、+81-80-1111-2222のような番号形式)にルーティングし、そのエンドポイントを持ったデバイスで電話を受け取ることができます。つまり、電話番号を入力してCCPからでなくその電話番号を持ったデバイス(携帯や電話機)で電話を受け取る方法となります。お客様の情報にアクセスしたりするような操作およびシグナリングの制御(電話に出たり、切ったりする制御)はWorkSpaces環境で行い、メディア(音声のやりとり)はオペレーターの電話機を使うことで、メディアはお客様と直接繋がることで音質の低下なくセキュリティの担保もできます。

設定方法はAmazon Connectにユーザーを登録する際に、エージェントの電話タイプをDesk Phoneに指定して使用するデバイスの電話番号を入力するだけで設定完了です。

メディアを持たないCCP

もう一つの方法としてメディアを持たないCCPを作成する方法があります。カスタムCCPでメディアを持たないCCPを作成し、WorkSpaces環境ではこのメディアを持たないCCPを使ってセキュリティが必要な操作やシグナリングの制御を行い、メディアはローカルデバイスの標準CCPを使用してお客様とやりとりする方法です。構成図は以下のようになります。

カスタムCCPの話はこちらのリンクに詳細が乗ってます。こちらのリンクにindex.htmlファイルが「Amazon Connect Streams構築手順」項目の中に入ってます。そのファイルを以下のように設定してください。

<!DOCTYPE html>
<meta charset="UTF-8">
<html>
    <head>
        <script type="text/javascript" src="amazon-connect-1.4.js"></script>
    </head>
    <!-- Add the call to init() as an onload so it will only run once the page is loaded -->
    <body onload="init()">
        <div id=containerDiv style="width: 400px;height: 800px;"></div>
        <script type="text/javascript">
            const instanceURL = "https://my-instance-domain.awsapps.com/connect/ccp-v2/";
 
            // initialise the streams api
            function init(){
                // initialize the ccp
                connect.core.initCCP(containerDiv, {
                    ccpUrl: instanceURL,            /*REQUIRED*/
                    loginPopup: true,           /*optional, default TRUE*/
                    region: "ap-northeast-1",           /*REQUIRED for chat, optional otherwise*/
                    softphone: {                /*optional*/
                        allowFramedSoftphone: false, /*optional*/
                        disableRingtone: false,     /*optional*/
                        ringtoneUrl: "./ringtone.mp3"   /*optional*/
                    }
                });
            }
        </script>
    </body>
</html>

変わったのはscriptのinit()関数の中身です。初期化(connect.core.initCCP)する際に渡す引数で、softphoneのallowFramedSoftphone属性の値をfalseに設定しています。この値をfalseに設定すると、このカスタムCCPはメディアを持たないように設定され、音声のやりとりができないCCPを作成することができます。CCPの配信については上記のリンクに続きがありますので、ご参考ください。

最後に

WorkSpacesのようなVDI環境で音声の劣化なくAmazon Connectを使用する方法についてみてみました。Amazon ConnectにカスタムCCPを導入することでとても多くのことができるようになります。カスタムCCPを作成するために必要なAmazon Connect Streamsについてはこちらのリンクに詳細が載ってます(英語ですので私はgoogle翻訳機のお世話になってます)

またConnect関連でいいものがあればブログ作成しますので、その日までみなさんお元気で!

Serverless Framework で Amplify Console を使えるプラグインで SPA(Vue.js) をデプロイしてみる – デプロイ編

$
0
0

こんにちは、技術1課の加藤です。

昨日、弊社ブログを Amplify で検索していたら衝撃の記事を見つけてしまいました。↓
Serverless Framework で Amplify Console を使えるプラグインで SPA(Vue.js) をデプロイしてみる – 準備編

準備編で止まっている…だと…!

どうやら本ちゃんのデプロイ編を出す前に PC を買い替えてしまい、データ移行時にブログデータが漏れてたっぽいです。準備だけさせて皆様をお待たせしてしまい、大変申し訳ございません。
もはや旬な情報でもなんでもないんですが、続きを書いていこうと思います。

概要おさらい

Serverless Framework のプラグインを使って、 Amplify Console で Vue.js アプリケーションのホスティングを行います。
Serverless Framework で UI をデプロイしようと思うと S3 へのファイルアップロードが難しくてやや面倒だったのですが、それが解消されそう、という内容でした。

では続き。

GitHub にプッシュ

Amplify Console でホスティングするためには、フロントエンドのコードが GitHub に上がっている必要があります。

GitHub にてリポジトリを作り、アップロードしておきましょう。
一応コマンドも記載しておきます。 (vue create でディレクトリ を作成しているため、git init は必要ありません)

$ pwd
/path/to/serverless-amplify-frontend
$ git add App.vue
$ git commit -m 'modify: App.vue'
$ git remote add origin git@github.com/<user>/<repo>.git
$ git push origin master

プラグインを追加

プラグインをインストールしていきます。

$ cd ../serverless-amplify-backend
$ pwd
/path/to/serverless-amplify-backend
$ npm install -D @wizeline/serverless-amplify-plugin

servereless.yml にもプラグインの設定を書き込んでおきます。

ついでに Lambda のパッケージに盛り込む必要のないファイルたちを exclude しましょう。

plugins:
  - serverless-amplify-plugin

package:
  exclude:
    - '*/**'
  include:
    - handler.py

今回プラグインを使っているため、設定の記述はプラグインの記法に従います。今回は以下のように custom に記載していきます。

custom:
  amplify:
    repository: https://github.com/<user>/<repo>.git
    accessToken: <xxxxxxxxxxxx>
    branch: master

AccessToken は GitHub の Personal access tokens というものです。

Amplify Console を使ったデプロイを行うためにはリポジトリに Webhook を仕掛ける必要があるため、リポジトリに対するアクセスが可能なトークンを発行 (権限設定時に repo にチェック) し、これを渡してあげる必要があります。
Creating a personal access token for the command line – GitHub Help

なお今回はテスト実行ということで accessToken を使ってデプロイを行いますが、これをすると CFn テンプレートにアクセストークンの情報が残りますし、あまり良くないです。

セキュアに行いたい場合には Secret Manger を使ってアクセストークンを保持する方法が使えるのでそちらを行うと良いでしょう。

デプロイ

さてここまで設定ができたら実際にデプロイをしていきましょう。
コマンドは基本これだけ。

$ serverless deploy

流石サーバーレスフレームワーク。便利。

デプロイが完了したら、 AWS コンソールを開いて Amplify を開きます。
作成した serverless-amplify-backend アプリがあるので、これを選び、画面中央辺りに表示されている Run Build ボタンを押します。

どうやら Amplify Console の設定は諸々行ってくれるものの、ビルドを走らせる部分はやってあげないといけないみたいです。

ともあれこれが完了したら、晴れて Amplify Console でのホスティングが完了します。発行される https://master.xxxxxxx.amplifyapp.com の URL にアクセスして正しく動いているか確認しましょう。

まとめ

Amplify 使ってバックエンド作った方が楽だなあとは思いましたw。
まだ環境変数やその他細かな Amplify Console の設定は難しいようですし、実用性はあまり高くないかなというのが正直なところ。

すでに Serverless Framework で API を作っているようなプロジェクトで、フロントのコードの CI/CD を盛り込みたい、といったニーズがあれば、使ってみると良いかもしれません。

AWS AppConfig でホストされた構成が利用可能になりました

$
0
0

2020年6月16日のアップデートです。
AWS AppConfig がホストされた構成のリリースを発表

なお、AWS AppConfigは2019年11月に発表されたサービスであり、AWS Systems Managersの一部でもあります。

AWS は、AWS AppConfig でホストされる構成の立ち上げを発表します。これは、AWS AppConfig へのオンボーディングを簡素化して、顧客が構成を数秒でデプロイできるようにする新機能です。AWS AppConfig では、Amazon Elastic Compute Cloud (Amazon EC2) インスタンス、コンテナ、AWS Lambda、モバイルアプリケーション、IoT デバイス、オンプレミスサーバーでホストされているアプリケーション間で、検証、制御、モニタリングしながらアプリケーション設定を容易かつ迅速にデプロイできます。

AppConfigは、アプリケーションの設定をデプロイするためのサービスです。
AppConfigを使うには、今まではアプリケーションの設定を、S3オブジェクト、SystemsManagerドキュメント、SystemsManagerパラメータストアのいずれかに保存する必要がありました。
今回のアップデートで、AWS AppConfig でホストされた構成(AWS AppConfig hosted configuration)への保存も選択できるようになりました。

4つの保存領域の比較はこちらに記載がありますが、AWS AppConfig でホストされた構成の利点は、サーバサイド暗号化(Server-side encryption)に唯一対応していることと、設定が楽になることです。

と、ここまで書きましたが、私自身AppConfigを使ったことが無かったので、以下で実際に試してみます。

サンプルアプリケーション

AppConfigはアプリケーションの設定をデプロイするサービスなので、何かサンプルアプリケーションを作って試してみます。
今回はPythonで運勢をSlackに通知してくれるアプリを作成しました。
登録したメンバーに対して、運勢を教えてくれます。

まずはAppConfigを使わずに普通にコードを書いてみます。
これを後でAppConfigを利用するように改造します。

import requests,json,random

# webhookURL
webhook_url = "https://hooks.slack.com/services/xxxxxxxxxxxxxxx"

# おみくじの中身
omikuji = [ "大吉","中吉", "小吉", "吉", "末吉", "凶", "大凶" ]

# 通知先メンバー
members = {
    "MemberList": [
        {
            "name": "たかし",
            "id"  : "11111111111"
        },
        {
            "name": "けんじ",
            "id"  : "22222222222"
        },
        {
            "name": "つとむ",
            "id"  : "33333333333"
        },
        {
            "name": "のぼる",
            "id"  : "44444444444"
        }
    ]
}

# 送信するテキスト
text = "本日の運勢です。\n"
for member in members["MemberList"]:
  text += "<@" + member["id"] + ">" + "あなたは" + random.choice(omikuji)  + "\n"

# Slackに送信
requests.post(webhook_url, data = json.dumps({
        "text": text
}));

実行すると、Slackに以下のような通知が送信されます。

このコードの問題としては、メンバーが変わるとコードの修正も必要なことです。

そこで設定をコードの外に出して別管理することにします。
設定をコードの外に出すというのはよくあり、どこに出すかというと、環境変数、設定ファイル、データベース等があると思います。
また、AWSでもパラメータストアというのがあり、そこで管理することも可能です。

今回は、この通知先メンバーに関する設定をAppConfigに移動させ、そこで管理してみます。

AppConfigの導入

Applicationの作成

AWS Systems Manager > AppConfig > Create configuration data

アプリケーション名をつけます。
今回は、omikujiという名前にしてみました。

Environmentの作成

環境名をつけます。
今回はDevelopmentにしました。

Configuration profileの作成

Configuration profile名をつけます。
今回はメンバー情報の設定なので、team-Aとしてみました。

Configuration sourceとして、AWS AppConfig hosted configurationを選択します。

保存するアプリケーションの設定を記載します。
YAML、JSON、Textと選択可能ですが、今回はJSONにしました。

Add validatorsというページが表示されますが、AWS AppConfig hosted configurationでは、validatorは使えないと記載があったので、ここでは何も選択せずに次にいきます。

Deployの開始

AppConfigのデプロイは、AppConfig側がPushするのではなく、アプリケーション側からのPullで実行されます。
したがって、基本的には実際に設定が適用されるタイミングはアプリケーション側の仕様によります。
「AppConfig側でDeploy実行」後に「クライアントからのPull」という順序です。
ただし、AppConfigにはデプロイ戦略という設定項目もあり、そこでいくらかは調整をすることは可能です。

項目
Environment Development
Hosted configuration version 1
Deployment strategy AppConfig.AllAtOnce(Quick)

今回はデプロイ戦略(Deployment strategy)をAllAtOnceとしているので、即座に設定反映させるようにしました。
これでAppConfig側の準備は完了です。

サンプルアプリケーションのAppConfig対応

AppConfigに設定を参照しにいくように修正します。
boto3がAppConfigをサポートしているので、これを使います。

ClientIdは、なんでもいいようです。
また、バージョン番号を指定しない場合は、最新バージョンになるようです。

import requests,json,random,boto3

# webhookURL
webhook_url = "https://hooks.slack.com/services/T68N3KXME/B016FUJV2QG/xxxxxxxxxxxxxxx"

# おみくじの中身
omikuji = [ "大吉","中吉", "小吉", "吉", "末吉", "凶", "大凶" ]

# 通知先メンバー
client = boto3.client('appconfig')
response = client.get_configuration(
    Application='omikuji',
    Environment='Development',
    Configuration='team-A',
    ClientId='watanabe'
)
config = response["Content"].read().decode('utf-8')
members = json.loads(config)

# 送信するテキスト
text = "本日の運勢です。\n"
for member in members["MemberList"]:
  text += "<@" + member["id"] + ">" + "あなたは" + random.choice(omikuji)  + "\n"

# Slackに送信
requests.post(webhook_url, data = json.dumps({
        "text": text
}));

これで実行し、上手くいきました。
今後、メンバーに変更があった時も、プログラムコードを修正せずにAppConfigの修正だけで済むようになりました。

設定を更新する

メンバーにたろうが追加されたとします。
AppConfigの設定を更新する必要があるので、新しいバージョンを作成します。

Create hosted configuration version

設定を追加します。

新バージョンをデプロイ

Start deployment

バージョンで先ほど作成した2を選択します。

Deploymentsに Version 2 が見えるようになります。
今回はデプロイ戦略(Deployment strategy)で、AppConfig.AllAtOnceを選択しているので、全てのクライアントからのリクエストに即座に反映されるはずです。
なお、Bakingと表示されるのが少し気になるかと思いますが、この時点で新しいバージョンを利用可能です。

ベイク時間(bake time)について

ベイク時間(bake time)はCloudWatchアラームがデプロイを完了とみなすまでにかかる時間であり、デフォルトで10分になっていました。
CloudWatchアラームと連携させない場合は、ベイク時間は関係ありません。

ベイク時間(bake time)についての説明は、ステップ 4: デプロイ戦略を作成するに記載があります。

まとめ

今回初めてAppConfigを触ってみました。
アプリケーション設定の保存やデプロイに利用できるサービスとわかりました。

しかし、AWSもデプロイやCIに利用できるサービスが多くなってきて、使い分けが難しいですね。
AWS Systems Manager のよくある質問には、以下のような質問が並んでいました。

  • Q: AWS AppConfig が AWS CodeDeploy と異なる点は?
  • Q: AWS Systems Manager パラメータストアと AWS AppConfig はそれぞれいつ使用すべきですか?
  • Q: AWS AppConfig が AWS Config と異なる点は?

AWS Lambda から Amazon Elastic File System にアクセスできるようになりました!!!

$
0
0

はじめに

こんにちは、技術1課の山中です。
やっぱり季節的に雨が多いですね〜、雨の日は晴れた日に元気で遊ぶための充電と仕事をがんばろうとおもいます。
というのはさておき!
今回はこのアップデートについて見ていきます!

Amazon Elastic File System の AWS Lambda サポートが一般利用可能に

AWS Lambda から Amazon Elastic File System (Amazon EFS) にアクセスできるようになりました!
このアップデートで、同時実行する AWS Lamda 関数間や Amazon EC2 、 Amazon ECS 等でのファイル共有が格段にやりやすくなりそうです。

Amazon EFS とは

Amazon EFS とは、 NFS アクセスを提供する完全マネージド型の分散ストレージサービスです。
複数の Amazon EC2 インスタンスから NFS を使ってネットワーク経由でファイルにアクセスできます。

Amazon EFS(EC2 用フルマネージド型ファイルシステム)| AWS

NFS とは

NFS (Network File System) とは、ネットワーク上のコンピュータが持つストレージを共有するための仕組みの 1 つで、 Linuxなど UNIX 系 OS の多くに標準で組み込まれています。

NFS はネットワークを介して、サーバ上のストレージ領域をローカルストレージと同様にマウントして利用できることが特徴です。

料金

Amazon EFS は、使用したリソース分に対する従量課金となっています。
具体的な料金についてはストレージクラスによって変わってくるため、詳細は以下を参照ください。

料金 – Amazon EFS | AWS

今回のアップデート

今回のアップデートで AWS Lambda から Amazon EFS のファイルシステムにアクセスできるようになりました。
これで一体何が嬉しいのでしょうか。
考えられるメリットは以下のようなところです。

512 MB を超えるファイルの操作が可能

AWS Lambda では、関数実行時の一時的なファイルストレージとして 512 MB の /tmp 領域 を利用できます。
ただ、512 MB という制限からこれまで GB 単位で容量を使用する機械学習のモデル計算などは AWS Lambda で扱うことができませんでした。
今回のアップデートで Amazon EFS が AWS Lambda から利用できるようになったので、 /tmp ストレージの制限で断念していたケースでも AWS Lambda を利用できるようになります。

データの一貫性が保てる

AWS Lambda とよく組み合わせて使うストレージサービスとしては Amazon S3 が一番多く利用されていると思います。 Amazon S3 は結果整合性なので、更新と取得のタイミングによっては古いデータを取得する可能性があり、もしデータの一貫性を保ちたい場合は、一貫性を考慮したアーキテクチャを考えなければなりませんでした。
AWS Lambda からアクセスするストレージサービスとして Amazon EFS が追加されたことによって、データの一貫性を保つための選択肢が増えることになります。

他にも Amazon EFS を利用できるようになって得られるメリットはあると思いますが、とはいえ全てのデータを Amazon EFS を通して処理するのではなく 必要に応じて利用していく ことが大切です。

アップデート内容の確認

早速 AWS Lambda から Amazon EFS のストレージにどのようにアクセスするのか、確認していきましょう。
今回は確認用に以下のような構成を作成していきます。

また、 AWS Lambda から Amazon EFS を利用するために以下の点に注意が必要です。

  • EFS アクセスポイント が必要
  • Amazon EFS は AWS Lambda 関数と同一リージョンに作成する必要がある
  • AWS Lambda は VPC の中に作成する必要がある

AWS Lambda 用セキュリティグループの作成

Amazon EFS にアクセスする AWS Lambda 関数用のセキュリティグループを作成します。
このセキュリティグループについては、デフォルトのままで構いません。
※ インバウンドルールなし、アウトバウンドルール全開放

Amazon EFS 用セキュリティグループの作成

Amazon EFS のセキュリティグループを事前に以下で作成します。

タイプ プロトコル ポート範囲 ソース
NFS TCP 2049 AWS Lambda のセキュリティグループ ID を指定

Amazon EFS の作成

Amazon EFS は、以下の 4 ステップで作成できます。

  1. ネットワークアクセスを設定する
  2. ファイルシステムの設定を行う
  3. クライアントアクセスを設定
  4. 確認と作成

まずは、ネットワークアクセスの設定です。
AWS Lambda を作成する対象の VPC を選び、マウントターゲットでサブネットを選択します。
セキュリティグループでは、先ほど作成した EFS 用のセキュリティグループを選んでいます。

続く、ファイルシステムの設定では、 Name タグだけ設定し他の設定項目はデフォルトのまま次の画面へいきます。
クライアントアクセスの設定画面では AWS Lambda からアクセスするための アクセスポイントの作成 を行います。
画面下の アクセスポイントの作成 ボタンをクリックし、以下を入力します。

項目
名前 data
ユーザー ID 1001
グループ ID 1001
パス /data
所有者ユーザー ID 1001
所有者グループ ID 1001
アクセス許可 750

所有者セクション でディレクトリの権限を 750 にしているので、所有者はファイルの読み取り、書き込み、実行が可能で、同じグループのユーザーは読み取りが可能ですが、他のユーザーはアクセスできません。

最後の画面で設定項目の確認をして、 Amazon EFS を作成します。

これで Amazon EFS の作成は完了です。あっという間ですね。

AWS Lambda の作成

続いて、 AWS Lambda 関数を作成していきます。

IAM ロールの作成

まずは AWS Lambda 関数に付与する IAM ロールを作成します。
今回は以下ポリシーを付与した IAM ロールを作成します。

  • AWSLambdaVPCAccessExecutionRole
  • AmazonElasticFileSystemClientReadWriteAccess
  • CloudWatchLogsFullAccess

AWS Lambda 関数の作成

続いて AWS Lambda 関数を作成します。
作成時に、作成済の IAM ロールを指定してください。

関数が作成されたら VPC の設定を行います。
Amazon EFS 作成時のマウントターゲットで指定したサブネット及び事前に用意しておいた AWS Lambda 用のセキュリティグループを指定します。

続いて、ファイルシステムの設定です。
新たに ファイルシステム という設定項目が追加されているので、 ファイルシステムの追加 をクリックし設定を行います。

ファイルシステムの追加画面で、作成した Amazon EFS 及びアクセスポイント、ローカルマウントポイントを指定して保存します。

今回は、 AWS Lambda から Amazon EFS 上にファイル serverworks.txt を作成 / 書き込みして、保存するということを試してみます。
AWS Lambda のコードは以下のようにしました。

file_path = '/mnt/data/'

def lambda_handler(event, context):
    # ファイル名を定義
    file_name = 'serverworks.txt'
    # 書き込む内容を定義
    write_string = event['text']

    # 書き込み
    with open(file_path + file_name, mode='w') as f:
        f.write(write_string)

    # 読み込み
    with open(file_path + file_name) as f:
        print(f.read())

これで AWS Lambda 関数の作成も完了です。

試してみる

早速作成した AWS Lambda 関数から Amazon EFS へのデータ読み書きができるのか試していきましょう。
先ほどの AWS Lambda のコンソールからテストイベントを作成し実行してみます。

成功しました!!

Amazon EFS のセキュリティグループを変更し、念の為 Amazon EC2 インスタンスからも覗いてみます。
以下 Amazon EC2 のマウント手順に従い、マウントを行います。

$ sudo yum install -y amazon-efs-utils

$ sudo mkdir efs

$ sudo mount -t efs fs-xxxxxxxx:/ efs

$ ls -l
drwxr-xr-x  3 root     root     6144  6月 22 07:39 efs

$ sudo ls -l efs/data
-rw-rw-r-- 1 1001 1001 24  6月 22 07:47 serverworks.txt

$ sudo cat efs/data/serverworks.txt
This text from Lambda!!!

指定した文字列がきちんと書き込まれていることがわかりました!!!

おわりに

AWS Lambda から Amazon EFS が利用できるようになり、データの永続化や異なるサービス同士のファイル共有など、アーキテクチャの幅が広がりそうです。

また、この内容は 2020/6/24(水) 12:00 よりYouTube Liveで配信する「30分でわかる AWS UPDATE!」で取り上げますますので、是非ご覧ください!

参考


【Amplify】Amplify のローカルモック機能が超便利!

$
0
0

こんにちは、技術1課の加藤です。
またまた Amplify のお話。

今回は簡単に mock API サーバーが立てたられる Amplify のローカルモック機能のご紹介です!

Amplify CLI を使ったローカルモック

2019年8月に出た機能のようですが、つい最近使ってみてとても便利だったのでご紹介。

バックエンドコンポーネントを利用するために今まで amplify push して実際に環境を立ち上げていたんですが

  • いくら開発用の環境とはいえトライエラーのために実環境使うのは嫌
  • 毎回 Push するのは面倒

だなあと感じており、いい方法ないかな、と思っていたら Amplify CLI に提供されていましたローカルモック。

これを使うと、以下をローカル環境で動かすことができるようになります。

  • AppSync GraphQL API
  • AWS Lambda関数 (直接または GraphQL API のリゾルバとして呼び出される)
  • アプリケーションのストレージとして使用するS3バケット
  • GraphQL API のCognitoユーザープール認証(ただし、最初に実際のサービスからJWTを取得する必要があり)

今回は GraphQL API をモックで使ってみます。

使い方

準備

前提として、このモック機能を使うためには Java の環境が必要になります。用意しておきましょう。

mac ユーザーの場合は以下コマンドで OK です。

$ brew cask install corretto

公式HP からの DL でも良いかと。https://aws.amazon.com/corretto/

また(当然ながら) Amplify CLI も必要なので、まだインストールしていない人はインストールしておきましょう。
AWS 環境にアクセスできるようプロファイル設定もしておいてくださいね。

$ npm install -g @aws-amplify/cli
$ aws configure

Amplify プロジェクトを作成

では例の如くプロジェクトを作っていきます。

$ mkdir amplify-mock
$ cd amplify-mock
$ amplify init

設定値は基本デフォルトでOKです。エディタとプロファイル設定だけご自身の環境に合わせてあげてください。

API を追加

今回は GraphQL の API を追加してモックを試してみます。
これも基本デフォルト設定で、最後のスキーマ編集については No でいきます。デフォルトのスキーマをそのまま使います。

$ amplify add api
? Please select from one of the below mentioned services: GraphQL
? Provide API name: amplifymock
? Choose the default authorization type for the API API key
? Enter a description for the API key:
? After how many days from now the API key should expire (1-365): 7
? Do you want to configure advanced settings for the GraphQL API No, I am done.
? Do you have an annotated GraphQL schema? No
? Do you want a guided schema creation? Yes
? What best describes your project: Single object with fields (e.g., “Todo” with
ID, name, description)
? Do you want to edit the schema now? No

モックを使ってみる

ではローカルモックを立ててみましょう。
以下コマンドでモックを起動します。途中、GraphQL のコードの生成が行われますが、ここでは特に使わないので適当にデフォルト値を選んでおいてください。

$ amplify mock

うまく起動すると AppSync Mock endpoint is running at http://192.168.0.43:20002 といった表示が出ます。指示されたエンドポイントにアクセスしてみましょう。

GraphiQL という、GraphQL の開発環境が立ち上がります。
実際にいくつかクエリを打ってみましょう。

デフォルトで作った GraphQL API は Todo リストを作るようなものになっています。
というわけでとりあえず Todo を作ってみます。

mutation CreateTodo {
  createTodo(input: {
    name:"Amplifyのモックサーバーのブログ書く"
  }) {
    id
    name
  }
}

data という項目が返ってきていれば OK です。返ってきたデータから id を控えておきましょう。
続いて今作ったデータを取得してみます。

query GetTodo {
  getTodo(id: "<控えたID>") {
    name
  }
}

想定通りのデータが返ってくれば OK です。

ローカルモックに登録したデータ

上記クエリを実行すると amplify ディレクトリ配下に mock-data というディレクトリ が増えていることがわかります。
ここにローカルモックに登録した情報が保存されています。

このため一度ローカルモックを止めて (Ctrl + c) 再度ローカルモックを立ち上げ、同じ GetTodo を実行してみてください。
きちんとデータが返ってくることが確認できます。便利。

まとめ

今回は Amplify のローカルモック機能を紹介しました。
正直、いろいろ使い方覚えなきゃいけないのかな、めんどそうかな、と思って避けてたんですが、使ってみたらとんでもなく簡単で便利です。

ぜひ Amplify 使って API 開発している方々は使ってみてください。

[2020/6/23版] 東京リージョンで構築可能なインスタンスタイプのアベイラビリティーゾーン別一覧表

$
0
0

SRE部 佐竹です。
こちらの記事は以前2019年4月10日に投稿させて頂きました記事「[EC2]東京リージョンで構築可能なインスタンスタイプのアベイラビリティーゾーン別一覧表」の更新版となります。

はじめに

今回は以下のリリースを受けての更新となります。

AWS Graviton2 プロセッサを搭載した Amazon EC2 C6g および R6g インスタンスの一般提供が開始

https://aws.amazon.com/jp/about-aws/whats-new/2020/06/amazon-ec2-c6g-r6g-instances-amazon-graviton2-processors-generally-available/

Amazon EC2 G4dn ベアメタルインスタンスの一般提供開始のお知らせ – 最大 8 つの NVIDIA T4 GPU を備えた GPU インスタンス

https://aws.amazon.com/jp/about-aws/whats-new/2020/06/announcing-general-availability-amazon-ec2-g4dn-bare-metal-instances/

第 2 世代 AMD EPYC プロセッサを搭載した Amazon EC2 C5a インスタンスが利用可能に

https://aws.amazon.com/jp/about-aws/whats-new/2020/06/now-available-amazon-ec2-c5a-instances-featuring-2nd-generation-amd-epyc-processors/

3つ目の記事は現在東京リージョン未対応なのですが、調査ついでに値に追加しております。

補足となりますが、「前回の2019/9/11版」と同様に「こちら」の公式ドキュメントの英語版に記載があるInstance Typeの一覧が、それぞれ東京リージョンの全アベイラビリティーゾーン(AZ)で構築が可能か「aws ec2 run-instances」の –dry-run オプションを利用して確認します。詳しくは「[EC2]東京リージョンで構築可能なインスタンスタイプのアベイラビリティーゾーン別一覧表」をご覧ください。

結果(アベイラビリティーゾーン別一覧表)

以下に結果を表示します。なお以下に存在していない「apne1-az3」は、現在Subnetの作成もできないクローズされたアベイラビリティーゾーンですので、結果からは省いております。また前回のブログとの差分は赤字で示しております。

Instance Type apne1-az4(1a or 1b) apne1-az1(1c) apne1-az2(1d)
a1.medium 成功 他のAZで構築可能 成功
a1.large 成功 他のAZで構築可能 成功
a1.xlarge 成功 他のAZで構築可能 成功
a1.2xlarge 成功 他のAZで構築可能 成功
a1.4xlarge 成功 他のAZで構築可能 成功
a1.metal 成功 他のAZで構築可能 成功
m4.large 成功 成功 成功
m4.xlarge 成功 成功 成功
m4.2xlarge 成功 成功 成功
m4.4xlarge 成功 成功 成功
m4.10xlarge 成功 成功 成功
m4.16xlarge 成功 成功 成功
m5.large 成功 成功 成功
m5.xlarge 成功 成功 成功
m5.2xlarge 成功 成功 成功
m5.4xlarge 成功 成功 成功
m5.8xlarge 成功 成功 成功
m5.12xlarge 成功 成功 成功
m5.16xlarge 成功 成功 成功
m5.24xlarge 成功 成功 成功
m5.metal 成功 成功 成功
m5a.large 成功 成功 成功
m5a.xlarge 成功 成功 成功
m5a.2xlarge 成功 成功 成功
m5a.4xlarge 成功 成功 成功
m5a.8xlarge 成功 成功 成功
m5a.12xlarge 成功 成功 成功
m5a.16xlarge 成功 成功 成功
m5a.24xlarge 成功 成功 成功
m5ad.large 成功 成功 成功
m5ad.xlarge 成功 成功 成功
m5ad.2xlarge 成功 成功 成功
m5ad.4xlarge 成功 成功 成功
m5ad.8xlarge 成功 成功 成功
m5ad.12xlarge 成功 成功 成功
m5ad.16xlarge 成功 成功 成功
m5ad.24xlarge 成功 成功 成功
m5d.large 成功 成功 成功
m5d.xlarge 成功 成功 成功
m5d.2xlarge 成功 成功 成功
m5d.4xlarge 成功 成功 成功
m5d.8xlarge 成功 成功 成功
m5d.12xlarge 成功 成功 成功
m5d.16xlarge 成功 成功 成功
m5d.24xlarge 成功 成功 成功
m5d.metal 成功 成功 成功
m5dn.large 他のAZで構築可能 成功 成功
m5dn.xlarge 他のAZで構築可能 成功 成功
m5dn.2xlarge 他のAZで構築可能 成功 成功
m5dn.4xlarge 他のAZで構築可能 成功 成功
m5dn.8xlarge 他のAZで構築可能 成功 成功
m5dn.12xlarge 他のAZで構築可能 成功 成功
m5dn.16xlarge 他のAZで構築可能 成功 成功
m5dn.24xlarge 他のAZで構築可能 成功 成功
m5n.large 他のAZで構築可能 成功 成功
m5n.xlarge 他のAZで構築可能 成功 成功
m5n.2xlarge 他のAZで構築可能 成功 成功
m5n.4xlarge 他のAZで構築可能 成功 成功
m5n.8xlarge 他のAZで構築可能 成功 成功
m5n.12xlarge 他のAZで構築可能 成功 成功
m5n.16xlarge 他のAZで構築可能 成功 成功
m5n.24xlarge 他のAZで構築可能 成功 成功
m6g.medium 成功 成功 他のAZで構築可能
m6g.large 成功 成功 他のAZで構築可能
m6g.xlarge 成功 成功 他のAZで構築可能
m6g.2xlarge 成功 成功 他のAZで構築可能
m6g.4xlarge 成功 成功 他のAZで構築可能
m6g.8xlarge 成功 成功 他のAZで構築可能
m6g.12xlarge 成功 成功 他のAZで構築可能
m6g.16xlarge 成功 成功 他のAZで構築可能
m6g.metal 成功 成功 他のAZで構築可能
t2.nano 成功 成功 成功
t2.micro 成功 成功 成功
t2.small 成功 成功 成功
t2.medium 成功 成功 成功
t2.large 成功 成功 成功
t2.xlarge 成功 成功 成功
t2.2xlarge 成功 成功 成功
t3.nano 成功 成功 成功
t3.micro 成功 成功 成功
t3.small 成功 成功 成功
t3.medium 成功 成功 成功
t3.large 成功 成功 成功
t3.xlarge 成功 成功 成功
t3.2xlarge 成功 成功 成功
t3a.nano 成功 他のAZで構築可能 成功
t3a.micro 成功 他のAZで構築可能 成功
t3a.small 成功 他のAZで構築可能 成功
t3a.medium 成功 他のAZで構築可能 成功
t3a.large 成功 他のAZで構築可能 成功
t3a.xlarge 成功 他のAZで構築可能 成功
t3a.2xlarge 成功 他のAZで構築可能 成功
c4.large 成功 成功 成功
c4.xlarge 成功 成功 成功
c4.2xlarge 成功 成功 成功
c4.4xlarge 成功 成功 成功
c4.8xlarge 成功 成功 成功
c5.large 成功 成功 成功
c5.xlarge 成功 成功 成功
c5.2xlarge 成功 成功 成功
c5.4xlarge 成功 成功 成功
c5.9xlarge 成功 成功 成功
c5.12xlarge 成功 成功 成功
c5.18xlarge 成功 成功 成功
c5.24xlarge 成功 成功 成功
c5.metal 成功 成功 成功
c5a.large 東京Region未対応 東京Region未対応 東京Region未対応
c5a.xlarge 東京Region未対応 東京Region未対応 東京Region未対応
c5a.2xlarge 東京Region未対応 東京Region未対応 東京Region未対応
c5a.4xlarge 東京Region未対応 東京Region未対応 東京Region未対応
c5a.8xlarge 東京Region未対応 東京Region未対応 東京Region未対応
c5a.12xlarge 東京Region未対応 東京Region未対応 東京Region未対応
c5a.16xlarge 東京Region未対応 東京Region未対応 東京Region未対応
c5a.24xlarge 東京Region未対応 東京Region未対応 東京Region未対応
c5d.large 成功 成功 成功
c5d.xlarge 成功 成功 成功
c5d.2xlarge 成功 成功 成功
c5d.4xlarge 成功 成功 成功
c5d.9xlarge 成功 成功 成功
c5d.12xlarge 成功 成功 成功
c5d.18xlarge 成功 成功 成功
c5d.24xlarge 成功 成功 成功
c5d.metal 成功 成功 成功
c5n.large 成功 成功 成功
c5n.xlarge 成功 成功 成功
c5n.2xlarge 成功 成功 成功
c5n.4xlarge 成功 成功 成功
c5n.9xlarge 成功 成功 成功
c5n.18xlarge 成功 成功 成功
c5n.metal 成功 成功 成功
c6g.medium 成功 成功 他のAZで構築可能
c6g.large 成功 成功 他のAZで構築可能
c6g.xlarge 成功 成功 他のAZで構築可能
c6g.2xlarge 成功 成功 他のAZで構築可能
c6g.4xlarge 成功 成功 他のAZで構築可能
c6g.8xlarge 成功 成功 他のAZで構築可能
c6g.12xlarge 成功 成功 他のAZで構築可能
c6g.16xlarge 成功 成功 他のAZで構築可能
c6g.metal 成功 成功 他のAZで構築可能
r4.large 成功 成功 成功
r4.xlarge 成功 成功 成功
r4.2xlarge 成功 成功 成功
r4.4xlarge 成功 成功 成功
r4.8xlarge 成功 成功 成功
r4.16xlarge 成功 成功 成功
r5.large 成功 成功 成功
r5.xlarge 成功 成功 成功
r5.2xlarge 成功 成功 成功
r5.4xlarge 成功 成功 成功
r5.8xlarge 成功 成功 成功
r5.12xlarge 成功 成功 成功
r5.16xlarge 成功 成功 成功
r5.24xlarge 成功 成功 成功
r5.metal 成功 成功 成功
r5a.large 成功 成功 成功
r5a.xlarge 成功 成功 成功
r5a.2xlarge 成功 成功 成功
r5a.4xlarge 成功 成功 成功
r5a.8xlarge 成功 成功 成功
r5a.12xlarge 成功 成功 成功
r5a.16xlarge 成功 成功 成功
r5a.24xlarge 成功 成功 成功
r5ad.large 成功 他のAZで構築可能 成功
r5ad.xlarge 成功 他のAZで構築可能 成功
r5ad.2xlarge 成功 他のAZで構築可能 成功
r5ad.4xlarge 成功 他のAZで構築可能 成功
r5ad.8xlarge 成功 他のAZで構築可能 成功
r5ad.12xlarge 成功 他のAZで構築可能 成功
r5ad.16xlarge 成功 他のAZで構築可能 成功
r5ad.24xlarge 成功 他のAZで構築可能 成功
r5d.large 成功 成功 成功
r5d.xlarge 成功 成功 成功
r5d.2xlarge 成功 成功 成功
r5d.4xlarge 成功 成功 成功
r5d.8xlarge 成功 成功 成功
r5d.12xlarge 成功 成功 成功
r5d.16xlarge 成功 成功 成功
r5d.24xlarge 成功 成功 成功
r5d.metal 成功 成功 成功
r5dn.large 他のAZで構築可能 成功 成功
r5dn.xlarge 他のAZで構築可能 成功 成功
r5dn.2xlarge 他のAZで構築可能 成功 成功
r5dn.4xlarge 他のAZで構築可能 成功 成功
r5dn.8xlarge 他のAZで構築可能 成功 成功
r5dn.12xlarge 他のAZで構築可能 成功 成功
r5dn.16xlarge 他のAZで構築可能 成功 成功
r5dn.24xlarge 他のAZで構築可能 成功 成功
r5n.large 他のAZで構築可能 成功 成功
r5n.xlarge 他のAZで構築可能 成功 成功
r5n.2xlarge 他のAZで構築可能 成功 成功
r5n.4xlarge 他のAZで構築可能 成功 成功
r5n.8xlarge 他のAZで構築可能 成功 成功
r5n.12xlarge 他のAZで構築可能 成功 成功
r5n.16xlarge 他のAZで構築可能 成功 成功
r5n.24xlarge 他のAZで構築可能 成功 成功
r6g.medium 成功 成功 他のAZで構築可能
r6g.large 成功 成功 他のAZで構築可能
r6g.xlarge 成功 成功 他のAZで構築可能
r6g.2xlarge 成功 成功 他のAZで構築可能
r6g.4xlarge 成功 成功 他のAZで構築可能
r6g.8xlarge 成功 成功 他のAZで構築可能
r6g.12xlarge 成功 成功 他のAZで構築可能
r6g.16xlarge 成功 成功 他のAZで構築可能
r6g.metal 成功 成功 他のAZで構築可能
u-6tb1.metal 東京Region未対応 東京Region未対応 東京Region未対応
u-9tb1.metal 東京Region未対応 東京Region未対応 東京Region未対応
u-12tb1.metal 東京Region未対応 東京Region未対応 東京Region未対応
u-18tb1.metal 東京Region未対応 東京Region未対応 東京Region未対応
u-24tb1.metal 東京Region未対応 東京Region未対応 東京Region未対応
x1.16xlarge 成功 成功 成功
x1.32xlarge 成功 成功 成功
x1e.xlarge 成功 成功 他のAZで構築可能
x1e.2xlarge 成功 成功 他のAZで構築可能
x1e.4xlarge 成功 成功 他のAZで構築可能
x1e.8xlarge 成功 成功 他のAZで構築可能
x1e.16xlarge 成功 成功 他のAZで構築可能
x1e.32xlarge 成功 成功 他のAZで構築可能
z1d.large 成功 成功 成功
z1d.xlarge 成功 成功 成功
z1d.2xlarge 成功 成功 成功
z1d.3xlarge 成功 成功 成功
z1d.6xlarge 成功 成功 成功
z1d.12xlarge 成功 成功 成功
z1d.metal 成功 成功 成功
d2.xlarge 成功 成功 成功
d2.2xlarge 成功 成功 成功
d2.4xlarge 成功 成功 成功
d2.8xlarge 成功 成功 成功
h1.2xlarge 東京Region未対応 東京Region未対応 東京Region未対応
h1.4xlarge 東京Region未対応 東京Region未対応 東京Region未対応
h1.8xlarge 東京Region未対応 東京Region未対応 東京Region未対応
h1.16xlarge 東京Region未対応 東京Region未対応 東京Region未対応
hi1.4xlarge 東京Region未対応 東京Region未対応 東京Region未対応
i3.large 成功 成功 成功
i3.xlarge 成功 成功 成功
i3.2xlarge 成功 成功 成功
i3.4xlarge 成功 成功 成功
i3.8xlarge 成功 成功 成功
i3.16xlarge 成功 成功 成功
i3.metal 成功 成功 成功
i3en.large 成功 成功 成功
i3en.xlarge 成功 成功 成功
i3en.2xlarge 成功 成功 成功
i3en.3xlarge 成功 成功 成功
i3en.6xlarge 成功 成功 成功
i3en.12xlarge 成功 成功 成功
i3en.24xlarge 成功 成功 成功
i3en.metal 成功 成功 成功
f1.2xlarge 東京Region未対応 東京Region未対応 東京Region未対応
f1.4xlarge 東京Region未対応 東京Region未対応 東京Region未対応
f1.16xlarge 東京Region未対応 東京Region未対応 東京Region未対応
g3s.xlarge 成功 成功 他のAZで構築可能
g3.4xlarge 成功 成功 他のAZで構築可能
g3.8xlarge 成功 成功 他のAZで構築可能
g3.16xlarge 成功 成功 他のAZで構築可能
g4dn.xlarge 成功 成功 成功
g4dn.2xlarge 成功 成功 成功
g4dn.4xlarge 成功 成功 成功
g4dn.8xlarge 成功 成功 成功
g4dn.12xlarge 成功 成功 成功
g4dn.16xlarge 成功 成功 成功
g4dn.metal 成功 成功 成功
p2.xlarge 成功 成功 他のAZで構築可能
p2.8xlarge 成功 成功 他のAZで構築可能
p2.16xlarge 成功 成功 他のAZで構築可能
p3.2xlarge 成功 成功 他のAZで構築可能
p3.8xlarge 成功 成功 他のAZで構築可能
p3.16xlarge 成功 成功 他のAZで構築可能
p3dn.24xlarge 成功 他のAZで構築可能 他のAZで構築可能
inf1.xlarge 東京Region未対応 東京Region未対応 東京Region未対応
inf1.2xlarge 東京Region未対応 東京Region未対応 東京Region未対応
inf1.6xlarge 東京Region未対応 東京Region未対応 東京Region未対応
inf1.24xlarge 東京Region未対応 東京Region未対応 東京Region未対応
m1.small 成功 成功 他のAZで構築可能
m1.medium 成功 成功 他のAZで構築可能
m1.large 成功 成功 他のAZで構築可能
m1.xlarge 成功 成功 他のAZで構築可能
m3.medium 成功 成功 他のAZで構築可能
m3.large 成功 成功 他のAZで構築可能
m3.xlarge 成功 成功 他のAZで構築可能
m3.2xlarge 成功 成功 他のAZで構築可能
t1.micro 成功 成功 他のAZで構築可能
c1.medium 成功 成功 他のAZで構築可能
c1.xlarge 成功 成功 他のAZで構築可能
cc1.4xlarge 東京Region未対応 東京Region未対応 東京Region未対応
cc2.8xlarge 成功 成功 他のAZで構築可能
cg1.4xlarge 東京Region未対応 東京Region未対応 東京Region未対応
c3.large 成功 成功 他のAZで構築可能
c3.xlarge 成功 成功 他のAZで構築可能
c3.2xlarge 成功 成功 他のAZで構築可能
c3.4xlarge 成功 成功 他のAZで構築可能
c3.8xlarge 成功 成功 他のAZで構築可能
m2.xlarge 成功 成功 他のAZで構築可能
m2.2xlarge 成功 成功 他のAZで構築可能
m2.4xlarge 成功 成功 他のAZで構築可能
cr1.8xlarge 東京Region未対応 東京Region未対応 東京Region未対応
r3.large 成功 成功 他のAZで構築可能
r3.xlarge 成功 成功 他のAZで構築可能
r3.2xlarge 成功 成功 他のAZで構築可能
r3.4xlarge 成功 成功 他のAZで構築可能
r3.8xlarge 成功 成功 他のAZで構築可能
hs1.8xlarge 東京Region未対応 東京Region未対応 東京Region未対応
i2.xlarge 成功 成功 他のAZで構築可能
i2.2xlarge 成功 成功 他のAZで構築可能
i2.4xlarge 成功 成功 他のAZで構築可能
i2.8xlarge 成功 成功 他のAZで構築可能
g2.2xlarge 成功 成功 他のAZで構築可能
g2.8xlarge 成功 成功 他のAZで構築可能

前回からの変更点

  • g4dn.metal が追加されました
  • C6g および R6g が追加されました。ただし、apne1-az2 では構築できません
  • C5a は現在もまだ東京リージョンでは構築できません

まとめ

前回と同様、X6g 系は、apne1-az2 では利用できないようです。利用される場合は、念のためご注意ください。
簡単ですが、以上になります。

【AWS CDK】AWS のアーキテクトが作成した Contructs が使える AWS Solutions Constructs が出ました!

$
0
0

こんにちは、技術1課の加藤です。
つい先日のアップデートで AWS Solutions Constructs が発表されました。

AWS CDK の Constructs として提供され、これを使えばAWS のアーキテクトが作成した Well-Architected な構成を簡単に構築できるとのこと。

早速試してみました。

AWS Solutions Constructs

AWS CDK の Constructs というのは、1つ以上のサービスをまとめた最小構成を表す概念です。
例えば S3 + CloudFront で静的ファイルの配信を行う、など、意味のあるまとまりを定義して使い回すことができます。

Constructs | AWS CDK

今回発表された Solutions Constructs はAWS のアーキテクトが監修した AWS CDK の Constructs です。
Well-Architected Framework に則り、AWS のベストプラクティスとなる設定がされた Constructs 集となっており、ユーザーはこれを使うことで非常に簡単にシステム構成を作ることができるようになります。

現時点で 25 の構成が用意されていました。以下に列挙しておきます。

今回作成する環境

今回は AWS Solutions Constructs に用意されている

を用いて、 API Gateway + Lambda の簡単な API を作成していきます。APIを叩くと、

Hello, AWS Solutions Constructs! You've hit ${path}

という形で叩いたパス情報とともに Hello と返してくれるよう設定していきましょう。

基本的に以下のドキュメントの手順に沿って作成を進めていきます。
Walkthrough – Part 1 – AWS Solutions Constructs

準備

AWS Solutions Constructs は AWS CDK 1.46.0 以上でサポートされています。
cdk のバージョンを確認して 1.46.0 より小さかった方はアップデートをしておいてください。

npm でアップデートする記事があったので貼っておきます。
AWS CDK CLI のバージョンアップを行う方法 – サーバーワークスエンジニアブログ

ちなみに僕は brew で入れていたので以下コマンドでアップデートしました。

$ brew upgrade aws-cdk
$ cdk version
1.46.0 (build 63860b2)

プロジェクト作成

では CDK で管理するプロジェクトを作成します。
言語は TypeScript で進めていきます。

$ mkdir hello-constructs
$ cd hello-constructs
$ cdk init --language typescript

AWS CDK のバージョンを 1.46.0 に指定

package.json にて CDK のバージョンが 1.46.0 以上に指定されていることを確認します。

{
  "name": "hello-constructs",
  "version": "0.1.0",
  "bin": {
    "hello-constructs": "bin/hello-constructs.js"
  },
  "scripts": {
    "build": "tsc",
    "watch": "tsc -w",
    "test": "jest",
    "cdk": "cdk"
  },
  "devDependencies": {
    "@aws-cdk/assert": "1.46.0",
    "@types/jest": "^25.2.1",
    "@types/node": "10.17.5",
    "jest": "^25.5.0",
    "ts-jest": "^25.3.1",
    "aws-cdk": "1.46.0",
    "ts-node": "^8.1.0",
    "typescript": "~3.7.2"
  },
  "dependencies": {
    "@aws-cdk/core": "1.46.0",
    "source-map-support": "^0.5.16"
  }
}

パッケージをインストールしましょう。

$ npm install

TypeScript のコードをビルドして JavaScript のコードを生成します。
cdk synth してCDK のバージョンが正しく 1.46.0以上を指定していることを確認しておきましょう。

$ npm run build
$ cdk synth
Resources:
  CDKMetadata:
    Type: AWS::CDK::Metadata
    Properties:
      Modules: aws-cdk=1.46.0,@aws-cdk/cdk-assets-schema=1.46.0,@aws-cdk/cloud-assembly-schema=1.46.0,@aws-cdk/core=1.46.0,@aws-cdk/cx-api=1.46.0,jsii-runtime=node.js/v14.4.0
...

Lambda のコードを書く

では Lambda のコードを書いていきます。
Lambda ディレクトリ を作り hello.js を作りましょう。(今回 Lambda のコードは JavaScript を利用します)

$ mkdir lambda
$ touch lambda/hello.js

作成した JavaScript ファイルに以下を書き込んでいきます。

exports.handler = async function(event) {
  console.log("request:", JSON.stringify(event, undefined, 2));
  return {
    statusCode: 200,
    headers: { "Content-Type": "text/plain" },
    body: `Hello, AWS Solutions Constructs! You've hit ${event.path}\n`
  };
};

AWS CDK と AWS Solutions Constructs をインストール

必要なライブラリをインストールします。
最後にインストールする @aws-solutions-constructs/aws-apigateway-lambda@1.46.0 が今回の肝である Solutions Constructs ですね。

$ npm install -s @aws-cdk/aws-lambda@1.46.0
$ npm install -s @aws-cdk/aws-apigateway@1.46.0
$ npm install -s @aws-solutions-constructs/aws-apigateway-lambda@1.46.0

API Gateway / Lambda パターンをスタックに追加

lib/hello-constructs-stack.ts を以下のように編集します。

import * as cdk from '@aws-cdk/core';
import * as lambda from '@aws-cdk/aws-lambda';
import * as api from '@aws-cdk/aws-apigateway';
import { ApiGatewayToLambda, ApiGatewayToLambdaProps } from '@aws-solutions-constructs/aws-apigateway-lambda';

export class HelloConstructsStack extends cdk.Stack {
  constructor(scope: cdk.Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    // The code that defines your stack goes here
    const api_lambda_props: ApiGatewayToLambdaProps = {
      deployLambda: true,
      lambdaFunctionProps: {
        code: lambda.Code.fromAsset('lambda'),
        runtime: lambda.Runtime.NODEJS_12_X,
        handler: 'hello.handler'
      },
      apiGatewayProps: {
        defaultMethodOptions: {
          authorizationType: api.AuthorizationType.NONE
        }
      }
    };

    new ApiGatewayToLambda(this, 'ApiGatewayToLambda', api_lambda_props);
  }
}

API Gateway に渡すプロパティを作ったら、あとは ApiGatewayToLambda を new するだけで OK です。簡単すぎる。

何が出来上がるのか確認しておきましょう

$ npm run build
$ cdk diff

長くなるので結果の引用は避けますが、

  • API Gateway
  • Lambda
  • CloudWatch Logs のロググループ
  • 各種権限セット

あたりが作成されることがわかります。

デプロイ

では実際にデプロイしてみましょう。

$ cdk deploy
...
 ✅  HelloConstructsStack

Outputs:
HelloConstructsStack.ApiGatewayToLambdaLambdaRestApiEndpointxxxxxxxx = https://xxxxxxx.execute-api.ap-northeast-1.amazonaws.com/prod/

Stack ARN:
arn:aws:cloudformation:ap-northeast-1:xxxxxxxxxxxx:stack/HelloConstructsStack/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

最後に正しくAPIが動くか確認しましょう。

$ curl https://xxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/prod/
Hello, AWS Solutions Constructs! You've hit /
$ curl https://xxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/prod/cdk-saikou
Hello, AWS Solutions Constructs! You've hit /cdk-saikou

無事想定通り動いていることが確認できました。

最後に

今回は Solutions Constructs を利用してみました。
コードの行数を大幅に減らし、楽に、かつ良い構成が作れるというのは非常に魅力的ですね。

今回参考にした公式のハンズオンには続きがあるので、よければ挑戦してみてください。
Walkthrough – Part 2 – AWS Solutions Constructs

おまけ

現在、毎日 AWS というラジオ感覚放送を YouTube にて配信しています
その中で今回取り上げた Solutions Constructs について触れていますので、こちらもお聞きください!

https://youtu.be/ijpybo8cOTA

毎日手軽にAWSのアップデート情報がキャッチアップできますよ

Amazon GuradDutyの検知結果を確認するポイント

$
0
0

エンジニアの小林です。

これまで弊社社員が、以下ブログでGuardDutyの設定方法や設定後のEmail通知の設定方法をご紹介してきました。

【はじめてのAWS】Amazon GuardDuty を設定しよう

Amazon GuardDutyの結果をメールで受け取る手順

GuardDutyは脅威を検知するのみで、検知した結果の対処、対策はユーザーで対応する必要があります。

そのため、今回はGuardDutyによって検知した結果を対応するために、どのようなポイントを確認すればいいか、簡単にご紹介させていただきます。

GuardDuty検知結果

マネージメントコンソールのGuardDuty画面から[Findings (結果)] を選択すると、結果一覧を表示することができます。
まず、結果の一覧画面から、結果の頭に付いているアイコンの色(重大度の確認)検索タイプの名前(結果タイプ)リソース(対象インスタンス)の確認をします。
リソース(対象インスタンス)は、攻撃を受けた対象を示しています。
その他2つは以下で説明をします。

重大度の確認

それぞれの結果には重大度という指標(脅威の重要度レベル)があり、重大度の値は 0.1 ~ 8.9 の値で割り当てられます。
0.1 ~ 8.9の値を3分割して、高、中、低の分類もされており、結果の一覧表示画面では色を確認して、その結果が高、中、低のどれなのか確認することができます。
重大度の定義は以下の通りです。
言わずもながら、重大度の高い結果については、優先度高く確認する必要があります。

  •  (値は 7.0〜8.9 の範囲/赤表示)
    • 該当リソース(EC2 インスタンス、または IAM ユーザー認証情報関連)への侵害を検知していることを示しています
    • EC2 インスタンスをクリーンアップまたは終了するか、IAM 認証情報を更新する等の対応が必要です
  •  (値は 4.0〜6.9 の範囲/黄色表示) 
    • 不正なアクティビティ(大量トラフィック、通常アクティ美的から外れる動作等)を検知していることを示しています
  •  (値が 0.1 ~ 3.9/青表示) 
    • ネットワークには侵害していない不審なアクティビティを検知していることを示しています
    • 即時対応の必要はありませんが、今後脅威となる可能性があることを理解する必要があります

結果タイプの確認

GuardDutyが検知する脅威は、AWSで定義されています。(Backdoor、UnauthorizedAccess等
これをThreatPurposeといいます。
https://docs.aws.amazon.com/ja_jp/guardduty/latest/ug/guardduty_finding-format.html

検知した結果が上記のどの脅威(ThreatPurpose)に当てはまるかを確認するには、検索タイプの名前を確認します。

例えば、検索タイプの名前がRecon:EC2/PortProbeUnprotectedPortの場合、Reconという脅威を検知している、ということがわかります。
ThreatPurposeについて書かれたAWSのドキュメントには以下記載があり、検索タイプの後半にPortProbeUnprotectedPortという表記がありますので、このEC2に対して保護されていないポートがないか脆弱性を探している、という検知であるとわかります。

Recon – この値は、偵察攻撃が進行中であり、ポートを調査したり、ユーザーやデータベーステーブルなどをリストアップすることで、AWS 環境の脆弱性を探そうとしていることを示します。

このように検索タイプを確認することで、どのような検知なのかを理解することができます。

その他詳細の確認

確認したい結果を選択することで、結果の詳細の確認をすることができます。

結果の詳細では、重大度の数値、EC2インスタンスの詳細情報、脅威の頻度も確認することができます。
一覧表示だけではインスタンスが特定できない場合、重大度を数値まで確認したい場合、結果の詳細を見て、結果の優先度の決定とインスタンスの特定をしましょう。
また、結果の詳細では、GuardDutyが検知した脅威がどのようなものかを、Action(アクション)から確認することも可能なので、必要に応じて確認してください。

  • Action type(アクションタイプ) :対象インスタンスに対してどのような操作があったか
    • NETWORK_CONNECTION:ローカルのホストとEC2インスタンス間のネットワークトラフィックがあったこと
    • PORT_PROBE :開放しているポートでEC2インスタンスに接続があったこと
    • DNS_REQUEST:EC2インスタンスへドメインの照会があったこと
    • AWS_API_CALL:AWS APIが呼び出されたこと
  • Connection direction(接続方向):ネットワークの接続方向
    • INBOUND:EC2への通信
    • OUTBOUND:EC2からの通信
    • UNKNOWN:判別不能
  • プロトコル:脅威と検知したプロトコル
  • ローカル IP:脅威と検知したトラフィックの送信元IP

 

これらの情報を確認し、EC2インスタンスの対策の検討を実施しましょう。

対策実施後は、結果をアーカイブしましょう。
まず、マネージメントコンソールのGuardDuty画面から[Findings (結果)] を選択します。
アーカイブしたい結果のチェックボックスにチェックを入れ、左上の[Action(アクション)]から[archive(アーカイブ)]を選択すると結果はアーカイブされます。
同じく、[Action(アクション)]から[export(エクスポート)]を選択するとjsonの結果を表示およびダウンロードすることも可能です。

まとめ

GuardDutyが検知した!となったら、

マネコンから、リソース(対象インスタンス)結果の色(重大度の確認)検索タイプの名前(結果タイプ)を確認し、検知した結果の対処、対策打ちましょう!

 

参考

Step Functions の Map ステートで、処理時間が劇的に短くなった話

$
0
0

はじめに

こんにちは。技術4課の河野です。最近作り置き料理にハマっていて、週末に平日分の夕飯を作るというライフハックを実践中です。

今回は、AWS Step Functions(以下「SFN」) の Map ステートについてのお話です。

要約

SFN で過去一年分のSlack投稿メッセージを取得するバッチを構築しました。
トータル処理時間が、1.5h (データ件数は 2万件程度)だったため、SFNの Map ステートを組み込んだところ処理時間が 10.0 min まで短くなったというお話です。

改善前

Slack投稿メッセージは、下記のような構成(ざっくり)で構築しました。

Slackのメッセージを取得する Lambda をタイムアウトするまでぶん回して、タイムアウトエラーを SFN 側でキャッチしてリトライするという力技です。

改善前の課題

冒頭でも述べた通り、「Slackメッセージを取得する(getSlackPostsステート)処理時間が 1.5h 以上かかっていた」ことです。

原因は以下の通りです。

  • 全てのメッセージの処理を一つの Lambda 関数で順次処理していたこと
  • 再試行の数が増える度に、待ち時間が増加していたこと

Map ステートについて

Map ステートは SFN 上で動的並列処理をサポートする機能です。
ステートの Input に配列を渡すと、配列の要素毎にステップを並列に実行できます。

下記例は、Lambda を並列実行させる Map ステートのイメージになります。

詳細な使い方については、公式ドキュメントをご参照ください。

改善後

上記のMap ステートのイメージを踏まえたところで、今回の構成をどのように改善したかを説明します。

変更点は以下の通りです。

  • メッセージの取得を一ヶ月単位で分散実行する(Mapステート)
  • Mapステートに渡す配列を作成するステートを追加
    • 指定した日付から過去一年間を一月毎に区切った配列
    • 例:
      • input: 2020-05-15
      • output: [{ start: 2019-04-15, end : 2019-05-15 }, { start: 2019-05-15, end : 2019-06-15 }, ...]

getSlackPostsステート のロジックは変更せずに、処理させる件数を少なくして並列で実行させるように変更しました。

構成は、以下のようになりました。

さいごに

実際の処理結果です。全体の処理時間が10分程度になっていることがわかります。

下記のように並列処理されていることも確認できました!

最後まで読んでいただきありがとうございました。

署名付きURLを使ってAmazon Connectの情報をセキュアに閲覧する

$
0
0

はじめに

こんにちは。孔子の80代目子孫兼技術5課の孔です。暑い夏が始まるのかなと思いきや、梅雨で夜は少し寒かったりして、健康によくない日が続いています。あまり外出もできない日々の中、健康にはお気をつけてくださいね。

それでは早速ですが、今回ご紹介するブログについてお話しいたします。今回はAmazon ConnectのAPIを使ったブログを用意しました。AWSはどのサービスであってもとても豊富なAPIを提供しています。Amazon Connectももちろんそうで、ユーザーがAmazon Connectを使うにあたってより便利に使えるよう数多くのAPIを提供しております。Amazon ConnectのAPIに関しては、こちらのリンクをご参考ください。

こちらのAPIの中に、「generate_presigned_url」というものが存在します。こちらのAPIは署名付きURLを生成するAPIとなります。個人的にAmazon ConnectのAPIを使って何か練習がてらコードを書いてみたいなと思っていたところ、このAPIを使って何かいいことができるんじゃないかな?と思い、今回やったことを共有する目的でブログを書きました。

本記事ではboto3を使用して実装を行いますが、boto3およびpythonの基礎的な話は今回は省略します。また、本記事に登場するインスタンスIDなどは全部伏せておりますため、ご自身で実装をする際には本記事に登場するコードを参考に値をアレンジしてお使いください。それでは、始めます。

そもそも、署名付きURLとは?

※署名付きURLがどのようなものなのか、おわかりの方はスキップしても大丈夫です。

署名付きURLとは、名前の通り「署名がついているURL」となります。普通のURLといいますと「google.com 」のように、誰でもアクセスできるものですね。しかし署名付きURLは期限が決まっていて、かつその署名を知っている人でないとURLにアクセスができません。例えば以下のようなURLとないます。

https://connect.ap-northeast-1.amazonaws.com/users/....
?X-Amz-Algorithm=AWS4-HMAC-SHA256&....%2Fap-northeast-1%2Fconnect%2Faws4_request
&X-Amz-Date=20200623T030121Z
&X-Amz-Expires=3600
&X-Amz-SignedHeaders=host
&X-Amz-Signature=....

こちらのURLはgenerate_presigned_urlでuser_describeを実行したときに発行されるURLのサンプルとなります。任意でURLを切ってますが、最後にsignatureという単語が見えますね。このようにこの署名をURLにつけて送らない限り、閲覧したい情報を見えないような仕組みとなっているのが署名付きURLとなります。ちなみにexpiresという単語も見えますが、こちらは署名付きURLの有効期限を表しています(秒単位となります)

いざ、コードを書いてみよう

コードはこちらになります。

from boto3 import client
from requests import get


client = client('connect')
# Connectのユーザーを作成する
create_user_response = client.create_user(
    Username='testUser',
    Password='testPassWord01',
    IdentityInfo={
        'FirstName': 'test',
        'LastName': 'user',
        'Email': 'test@test.com'
    },
    PhoneConfig={
        'PhoneType': 'SOFT_PHONE',
        'AutoAccept': True,
        'AfterContactWorkTimeLimit': 0,
    },
    SecurityProfileIds=[
        'XXXX',
    ],
    RoutingProfileId='XXXX',
    InstanceId='XXXX',
)

# describe_userメソッドのパラメータを定義する
params = {
    'UserId': create_user_response['UserId'],
    'InstanceId': 'XXXX'
}

# 署名付きURLを発行する
url = client.generate_presigned_url(
    'describe_user',
    Params=params,
    ExpiresIn=300,
    HttpMethod=None,
)

response = get(url)
print(response.url)  # 署名付きURLを出力する
print(response.text)  # URLからgetしたbodyを出力する

※インスタンスIDなどでXXXXが登場しますが、こちらはご自身の環境に合わせて適切な値を入れてください。

今回想定しているシーンは、ユーザーを作成するAmazon Connect管理者が、ユーザー情報を作成してその作成した内容を該当ユーザーに送るコードを開発しているシーンとなります。そこで署名付きURLを使用することでよりセキュアにユーザーが作成完了ユーザー情報を閲覧できる、的なシーンですね。最後は標準出力でURLとbodyを出してますが、標準出力をメールに送る的な処理だと想像して読んでください😇

それぞれのAPIのパラメータがどのような意味なのかについてです。

create_user APIに関しては、ユーザーを作成する際に必要なもろもろの情報を渡しています。ユーザーの名前は、パスワードは、ログイン名は、電話機やセキュリティプロファイルなどは何を使うのか、などなどです。

その次にgenerate_presigned_url APIです。こちらのAPIは第1引数API名を文字列で入力します(API一覧は先ほどのConnect APIリンクをご参考ください)第2引数に指定したAPIが必要とするパラメータを渡し、その次に期限を入れます(秒数となります)最後のHttpMethodにはurlを生成するためのHTTPメソッドを入力します。ドキュメントによりますと、こちらはどのようなメソッドでもOKだそうです。

こちらのコードを実行するといかのような結果となります。

> https://connect.ap-northeast-1.amazonaws.com/users/....(署名付きURL)
> {
  "User" : {
    "PhoneConfig" : {
      "DeskPhoneNumber" : "",
      "PhoneType" : "SOFT_PHONE",
      "AfterContactWorkTimeLimit" : 0,
      "AutoAccept" : true
    },
    "Arn" : "XXXX",
    "IdentityInfo" : {
      "Email" : "test@test.com",
      "LastName" : "user",
      "FirstName" : "test"
    },
    ....(以下省略)
  }
}

最後に

今回はAmazon ConnectのAPIの一種である、署名付きURLの発行についてみてみました。APIの中ではとても便利で、よりAWSを使いこなせる便利なAPIがたくさんありますのでぜひお時間のある際に一通り目を通してみると面白い発見があるかもです!それではみなさん、お元気で!

【AWSセキュリティ】VPCフローログ

$
0
0

 

今回は、弊社のYoutubeチャンネル「サーバーワークス チャンネル」にて先日公開した以下動画についてblogでも内容を紹介いたします。

動画内では、実際のAWSマネジメントコンソール画面を利用した説明もありますのでもし興味があれば是非、動画も参照頂ければと思います。

 

内容が良かった、為になったと感じたら是非Goodボタンやチャンネル登録頂けると嬉しいです。

対象者

・クラウドサービスの検討をされている方
・AWSのセキュリティ対策について知りたい方
・VPC フローログの概要について知りたい方

VPC フローログとは

Amazon VPC(AWS内で動作する独立した仮想ネットワーク) で提供される、ネットワークインターフェイス間で行き来する IPトラフィックに関する情報をキャプチャする機能となり、キャプチャされた内容は Amazon CloudWatch Logs へ Publish(公開) または Amazon S3に格納する事が出来ます。

以下が主なユースケースとなります。

  • 通信トラブルの調査
    例えばEC2インスタンスに到達するトラフィックのモニタリングができるので、どこまで通信が到達しているのかの切り分け等で活用できます。
  • セキュリティ設計の結果検証
    許可/遮断以外にも送信元や宛先や利用されたポートの情報も記録できる為、設計したセキュリティ要件通り動作しているかの確認や診断用途で活用できます。
  • 脅威検出のデータソース
    別サービスの Amazon GuardDuty で脅威検出をするためのデータソースとして利用されます。(ユーザが取得設定するものとは別の独立したデータストリーム経由となります)
    Amazon GuardDutyに関しては、以下Blogで紹介しておりますので興味があれば参照ください。

    【はじめてのAWS】Amazon GuardDuty を設定しよう
    http://blog.serverworks.co.jp/tech/2020/06/12/hajimetenoaws_guardduty/

参考: VPC フローログ (ユーザーガイド)
https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/flow-logs.html

VPCフローログの料金

VPC フローログ自体は無料(追加料金なし)となっていますが、使用する場合は Amazon CloudWatch Logs 側のデータ取り込み料金という形で課金されます。
また、当該ログを長期保管したい場合には、S3 bucketへ出力が可能でその場合は別途 Amazon S3の保管費用が必要となります。

詳細は参考公式ドキュメントにある VPCフローログモニタリングの料金例をご確認ください。

参考: 例4 – VPC フローログのモニタリング
https://aws.amazon.com/jp/cloudwatch/pricing/

VPC フローログの注意事項

注意点として以下3点を紹介します。

  1. すべてのIPトラフィックがキャプチャされる訳ではない
    AWS内で発生している一部のトラフィック(DHCP,DNS,NTPやWindowsライセンスのアクティベーション用途のトラフィック等) で記録されないものがあります。

    詳細はフローログの制限事項 を参照してください。

    フローログの制限事項
    https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/flow-logs.html#flow-logs-limitations

  2. Amazon CloudWatch logsの保管期間は運用を考慮し決定する
    管理者視点でフローログのデータをマネジメントコンソールから簡単に手早く調査する目的では Amazon CloudWatch Logsに公開されている状態が好ましく運用しやすい為、どれぐらいの期間保管するかは運用とコストの観点から検討し設定してください。
    (古いデータをS3 bucketへの長期保管も可能ですが、その範囲の解析は手動での解析やらAmazon Athenaを駆使した抽出等が必要となり運用の敷居やコストが上がります。)

  3. フィルタリングの文法に慣れが必要
    大量のVPCフローログから素早く必要なレコードを抽出するためにフィルタリングが有効ですが、フィルタリングルールの書き方が独自の内容となっています。
    運用する上で重宝するフィルタリング例を以下blogで紹介しておりますので実際の運用の際には参考にしてください。

VPC Flow Logs(CloudWatch Logs)を閲覧時にフィルタする方法

VPC フローログ 利用方法(動画内 02:21〜)

VPC フローログを取得する設定を行い、ログ確認をするまでの利用方法について動画内で紹介しています。
管理者視点で、ざっくりとVPCフローログの取得設定や利用イメージを掴んで頂ける内容となっておりますので、もし興味があれば動画を参照ください。

まとめ

VPC フローログでは数クリック程度の設定でVPC内の通信記録が可能となり、その情報をトラブルの原因調査や切り分けに活用する事ができます。
低コストで利用可能なので、AWSアカウント管理者としてAmazon VPC内でリソースを運用する場合には、設定項目として検討してみてください。

 

【初級編】VPCとサブネットの作成方法

$
0
0

こんにちは。SRE2課の福島です。

最近、朝に楽しみがあると早起きできると思い、
朝食から”とあるお店”で好きなヒレカツ丼を食べていいことにしています。
(「ヒレカツ丼 < 寝る」になったら、また別のものを探したいと思います。)

さて今回は、VPCとサブネットを作成する方法をまとめたいと思います。

やること

これだけです。

①VPCの作成
②サブネットの作成

①VPCの作成

まず、AWSマネジメントコンソールの「サービスを検索する」で「vpc」と検索し、vpcをクリックします。

左の項目で「VPC」を選択後、「VPCの作成」をクリックします。

VPCの作成画面で必要な情報を入力し、「作成」をクリックします。

項目 説明
名前タグ 作成するVPCに任意の名前を付与することができます。
IPv4 CIDRブロック VPC 用の IPv4 CIDR ブロックを指定します。
RFC 1918 で規定されているプライベートIP アドレス範囲から CIDR ブロックを
指定することをお勧めします。
たとえば、10.0.0.0/16 や 192.168.0.0/16 から指定します。
もし、オンプレミスの環境と接続する要件がある場合、
オンプレミスとCIDRが重複しないようにする必要があります。
IPv6 CIDRブロック IPv6を利用する場合、「Amazon が提供した IPv6 CIDR ブロック」または
「IPv6 CIDR owned by me」にチェックをします。
利用しない場合、「IPv6 CIDR ブロックなし」にチェックをします。
テナンシー デフォルト:VPC で起動するインスタンスは、
デフォルトで共有ハードウェア上で実行されます。
※特に要件がない場合、こちらを指定すれば良いかと思います。
  専用:VPC で起動するインスタンスは、
デフォルトで専用ハードウェア上で実行されます。

テナンシーの説明で記載している共有および専用ハードウェアの違いは、以下の通りです。
 共有ハードウェア
  複数のAWSアカウントで作成されるインスタンスが1つのハードウェア上で実行されます。
 専用ハードウェア
  自分のAWSアカウントで作成されるインスタンスだけが1つのハードウェア上で実行されます。

以下の画面が表示されれば、VPCの作成完了です。

②サブネットの作成

続きまして、サブネットの作成になります。

サブネットには、パブリックサブネットとプライベートサブネットと呼ばれるサブネットが存在します。
実際にそういうAWSサービスが存在する訳ではなく、簡単に記載するとインターネットからの通信可否に応じて、呼称が変わります。

インターネットからサブネットへの通信が
 できる:パブリックサブネット
 できない:プライベートサブネット

今回はプライベートサブネットを構築します。

左の項目で「サブネット」を選択後、「サブネットの作成」をクリックします。

必要な情報を入力します。

項目 説明
名前タグ 作成するサブネットに任意の名前を付与することができます。
VPC サブネットを作成するVPCを選択します。
アベイラビリティーゾーン サブネットを作成するAZ(※)を選択します。
※ 複数の拠点にあるデータセンター群を指します。
IPv4 CIDRブロック VPCで指定したCIDRより小さいCIDRを指定します。
VPCを「/16」で作成している場合、ネットワーク部(第1~3オクテッド)と
ホスト部(第4オクテッド)を分かりやすくするため、
サブネットは、「/24」で作成することが多いかと思います。

以下の画面が表示されれば、サブネットの作成完了です。

おわり

今回はサブネットを1つしか作成しませんでしたが、本来であれば、
AZ障害に対応できるよう、別のAZにもサブネットをもう1つ作成した方がよいでしょう。

ともあれ、上記のように簡単にVPCとサブネットを作成できます。
後は、EC2やWorkSpacesを作成したサブネット上に構築していきましょう!

参考:
VPC とサブネットの使用
ハードウェア専有インスタンス

ECS(EC2)のインスタンスタイプ変更は要注意

$
0
0

こんにちは。SRE2課福島です。

家の掃除をするのがめんどくさく、先月くらいにブラーバジェットという
床拭きロボットを買ったのですが、今は、ブラーバジェットに付ける
クリーニングパッドを付けるのが、めんどくさくなっています。

さて今回は、ECSクラスタ(EC2)のインスタンスタイプを変更する際は、
注意が必要です、という内容のブログを書きたいと思います。

結論

結論を先に記載すると普通のEC2と同じように
停止 ⇒ インスタンスタイプの変更 ⇒ 起動する方法では、
上手くいかないということです。

ECSクラスタの起動モードについて

ECSクラスタ(EC2)の()は、起動モードを指しているのですが、
そもそも、起動モードについて、知らない方向けに簡単に説明したいと思います。

ECSクラスタの起動モードには、EC2とFargateが存在し、大きな違いは、以下の通りです。

EC2 コンテナが稼働するEC2を管理する必要がある
Fargate コンテナが稼働するEC2を管理する必要がない

起動モードがEC2の良い点は、自分たちで管理する必要はありますが、
SSHでログインが可能という点(Fargateの場合できない)と、ログインできるため、
トラブルシューティング時に詳細な調査ができるという点なのかなと思ってます。

ちなみにですが

ちなみにですが、コンテナが稼働するEC2は、
ECSエージェントを起動することで、ECSクラスタと連携しております。

ちなみにからのちなみにですが、ECSエージェントが導入されたAMIも存在します。

ちなみにからのちなみにからのちなみにですが、
ECSクラスタのことをコントロールプレーン
コンテナが稼働するEC2をデータプレーンと呼びます。

Blackbelt(コントロールプレーン / データプレーン)

これ以降、コンテナが稼働するEC2をコンテナインスタンス、起動モードがEC2のことをEC2と記載いたします。

コンテナインスタンスのインスタンスタイプ変更手順について

話が脱線してしまいましたが、ここから本題です。

上記で記載した通り、EC2の場合、コンテナインスタンスを自分たちで管理する必要があるので、
インスタンスタイプの変更も、自分たちで行う必要があります。

インスタンスタイプの変更は、ECSクラスタにコンテナインスタンスを登録する方法によって、
手順が異なりますので、まずは、2種類ある登録方法について、説明します。

①ECSクラスタ作成時にコンテナインスタンスを作成する方法
②ECSクラスタ作成後に手動でコンテナインスタンスを登録する方法(AutoScaling有り)

①ECSクラスタ作成時にコンテナインスタンスを作成する方法

ECSクラスタ作成時にコンテナインスタンスを作成することが可能なのですが、
その場合、裏側でCloudFormationが実行されています。
以下の画像の通り、「空のクラスターの作成」にチェックを入れずに構築します。

 

②ECSクラスタ作成後に手動でコンテナインスタンスを登録する方法(AutoScaling有り)

ECSクラスタは、コンテナインスタンスを登録せずに
空のクラスタとして、作成することが可能です。
今度は、以下の画像の通り、「空のクラスターの作成」にチェックを入れて構築します。 

その場合、手動でコンテナインスタンスをECSクラスタに登録する必要があります。
ECSエージェントの設定ファイル(/etc/ecs/ecs.config)に「ECS_CLUSTER=ECSクラス名」を
定義するだけです。
 
コンテナインスタンス作成時にユーザーデータを以下のイメージで設定する感じです。
※ECSエージェントが導入されているAMIを利用する前提です。

#!/bin/bash
echo ECS_CLUSTER=test-ecs-cluster >> /etc/ecs/ecs.config

この際、作成するコンテナインスタンスは、AutoScalingを組んでいる前提です。

①、②に応じたインスタンスタイプ変更手順

そして、それに応じたインスタンスタイプの変更手順は、以下の通りです。

①の場合、CloudFormationを更新し、インスタンスタイプを更新します。
②の場合、AutoScalingの設定を更新します。

詳細な手順は、以下を参照してください。
Amazon ECS でコンテナインスタンスタイプを変更する方法を教えてください。

②でAutoScalingの設定を組んでない場合の対応

上記の②は、AutoScalingを組んでいる前提で記載されておりますが、
もし、AutoScalingを組んでいない場合の対応についてです。

冒頭に記載しましたが、普通のEC2インスタンスのように
停止 ⇒ インスタンスタイプの変更 ⇒ 起動する方法では、
上手くいきません。(ECSエージェントが正常に起動しません。)

実際にやってみると・・・
t2.nanoからt2.microに変更しました。

ECSエージェントが起動していない…

# docker container ls
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
#

ログを確認してみると・・・
/var/log/ecs/ecs-agent.log

level=error time=2020-06-25T03:06:31Z msg=”Error re-registering: ClientException: Container instance type changes are not supported. Container instance ea56ffb2-2fc1-4d08-83bb-c4b90b3d02b2 was previously registered as t2.nano.\n\tstatus code: 400, request id: a0d431d8-03d6-43ca-bcf1-40483a6182ee” module=agent.go level=critical time=2020-06-25T03:06:31Z msg=”The current instance type does not match the registered instance type. Please revert the instance type change, or alternatively launch a new instance: ClientException: Container instance type changes are not supported. Container instance ea56ffb2-2fc1-4d08-83bb-c4b90b3d02b2 was previously registered as t2.nano.\n\tstatus code: 400, request id: a0d431d8-03d6-43ca-bcf1-40483a6182ee” module=agent.go

Google翻訳

level = error time = 2020-06-25T03:06:31Z msg = “エラー再登録:ClientException:コンテナインスタンスタイプの変更はサポートされていません。コンテナインスタンスea56ffb2-2fc1-4d08-83bb-c4b90b3d02b2は、以前にt2.nanoとして登録されていました 。\ n \ tステータスコード:400、リクエストID:a0d431d8-03d6-43ca-bcf1-40483a6182ee “module = agent.go level = critical time = 2020-06-25T03:06:31Z msg = “現在のインスタンスタイプは登録されたインスタンスタイプと一致しません。インスタンスタイプの変更を元に戻すか、代わりに新しいインスタンスを起動してください:ClientException:コンテナインスタンスタイプの変更は サポートされていません。コンテナインスタンスea56ffb2-2fc1-4d08-83bb-c4b90b3d02b2は、以前はt2.nanoとして登録されていました。\ n \ tステータスコード:400、リクエストID:a0d431d8-03d6-43ca-bcf1-40483a6182ee “module = agent.go

このようにコンテナインスタンスは、インスタンスタイプの変更にサポートしていない。
インスタンスタイプの変更を元に戻すか、代わりに新しいインスタンスを起動してください。
と出力さます。

なので、コンテナインスタンスのインスタンスタイプを変更する場合は、
新しいインスタンスを再構築する必要があります。

ただ・・・

ただ、エラーログの情報から、もしかして、内部情報を管理しているファイルがあるのでは?と考えました。

現在のインスタンスタイプは登録されたインスタンスタイプと一致しません。

そして、色々と探した結果、それっぽいものが、見つかりました。

# cat /var/lib/ecs/data/ecs_agent_data.json | jq
{
"Data": {
"Cluster": "test-ecs-cluster",
"ContainerInstanceArn": "arn:aws:ecs:ap-northeast-1:xxxxxxxx:container-instance/d81c95af-567c-4327-8a3b-deb21c944bbf",
"EC2InstanceID": "i-0d96884ecd588ffcb",
"TaskEngine": {
"Tasks": [],
"IdToContainer": {},
"IdToTask": {},
"ImageStates": null,
"ENIAttachments": null,
"IPToTask": {}
},
"availabilityZone": "ap-northeast-1a",
"latestSeqNumberTaskManifest": 3
},
"Version": 28
}

ということで、こうして、

mv /var/lib/ecs/data/ecs_agent_data.json /tmp

停止 ⇒ インスタンスタイプの変更 ⇒ 起動

すると・・・

# docker container ls
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
0d000d2b23aa amazon/amazon-ecs-agent:latest "/agent" 49 minutes ago Up 49 minutes (healthy) ecs-agent
#

ECSエージェントを無事に起動することができました。
「/var/lib/ecs/data/ecs_agent_data.json」も自動で作成されていました。

# cat /var/lib/ecs/data/ecs_agent_data.json | jq
{
  "Data": {
    "Cluster": "test-ecs-cluster",
    "ContainerInstanceArn": "arn:aws:ecs:ap-northeast-1:xxxxxxxx:container-instance/ea56ffb2-2fc1-4d08-83bb-c4b90b3d02b2",
    "EC2InstanceID": "i-0d96884ecd588ffcb",
    "TaskEngine": {
      "Tasks": [],
      "IdToContainer": {},
      "IdToTask": {},
      "ImageStates": null,
      "ENIAttachments": null,
      "IPToTask": {}
    },
    "availabilityZone": "ap-northeast-1a",
    "latestSeqNumberTaskManifest": 7
  },
  "Version": 28
}

変更前と変更後でdiffした結果、
ContainerInstanceArnlatestSeqNumberTaskManifestの値が変わっていました。

インスタンスタイプを変更することでContainerInstanceArnが変わるのが
ecsエージェントが起動できなくなる原因なのかなと思いました。

と、こんな感じでやったけど

と、こんな感じで私が検証した際には、上記方法でコンテナインスタンスを
再構築することなく、インスタンスタイプを変更することができました。

ただし、エラーログに記載がある通り、インスタンスタイプを変更する際には、
コンテナインスタンスを再構築することを推奨します。

Blackbeltには、コンテナの中に入れるのは、ステートレスなアプリにすることで
コンテナのメリットを最大限活かせると記載があります。

Blackbelt(アプリのステートレス化)

この内容からもコンテナを使う上では、上記の手順を
実施しなくても(コンテナインスタンスに依存せず、再構築できる)
問題ない設計にすることが大切なのかなと思います。

おわりに

今までDockerやECSを使ったことがなかったのですが、
色々検証やブログを書いている内に少しDockerやECSと仲良くなれた気がします。

これから、もっと仲良くなれるようになりたいですね~

コラム:公園とおじいちゃん

$
0
0

ソリューションをご提案するベンダーとしては、「お客様が本当に欲しいもの」とのズレが無いかを常に意識したい。

自宅から徒歩2,3分の場所は、比較的大きな公園がある。
休日になると、4歳の娘を連れてよく遊びに行く。普段、SNSでエゴサーチばかりしてストレスフルな私も、この時ばかりは童心に返るのだ。

1ヶ月程前の事。いつものように、砂場で高尾山作りに励んでいると、おじいちゃんと孫(だと勝手に思っている)が自転車でやってきた。
孫は自転車を降りると一目散に滑り台へ走っていった。
おじいちゃんは公園を一通り見渡した後、孫に向かってこう叫んだ

「コラ!今からおじいちゃんがハーモニカ吹くからちゃんと聴いていなさい!」

・・・嫌な予感がした。ハーモニカなんて長渕剛以外吹い良いはずが無い。おじいちゃんは、孫に呼びかけていると見せかけて、
完全に公園中の様子を伺っている。少なく見積もって、公園では2,30人が休日のひと時を楽しんでいた。
公園の長渕は、ポケットからサッとハーモニカを取り出し、
「赤とんぼ」や「シャボン玉」などの童謡を中心にリサイタルが展開された。誰も聴いてないが。
正確には、認識はしているが意識しないようにしている状態。
こういう時代である、リワード広告などの施策を打たない限り集客は難しい。孫だって1ミリも聴いていない。
おじちゃんリサイタルはわずか数曲で幕を閉じた。即家路につかされる孫もたまったもんじゃない。
私と娘の間にも、ハーモニカの話題が出る事は無かった。

そしてつい先日の事。
また、公園におじいちゃんが現れた。おじいちゃんは、今度こそはと譜面台と楽譜を持参した上で演奏を始めたのである。
いや、そこじゃねぇ。と思った。
おじいちゃんとしては、演奏のクオリティが民衆の賛同を得られなかったと自己分析したのである。
そこでは無い。案の定、おじいちゃんの周りに人が集まることは無かった。
世間のニーズを上手く捉えなくてはいけないと思った。

尚、SNSで私の話題が出たことは1度も無い。

Snowflake にローカルからデータをロードしてみる

$
0
0

CI 部の宮本です。今回はローカルの CSV ファイルを Snowflake にロードしてみたいと思います。
やり方を調べていたところ、公式ドキュメントにぴったりのチュートリアルがあったので、以下を参考に進めてみます。

Snowflake を 20 分で紹介

SnowSQL で Snowflake にログインする

今回のチュートリアルは CLI ツールである SnowSQL を使用します。インストール方法は以下の記事を参考にしてください。

SnowSQL コマンドで Snowflake に接続する

以下コマンドでログインします。

$ snowsql -a <account_name> -u <user_name>

<account_name><user_name> はご自身のものに置き換えてくださいね。

因みに<account_name>XXXXXXX.ap-northeast-1.aws のような形式のものです。(AWS の東京リージョンで Snowflake を構築した場合)

データベース、テーブルの作成

CSV をロードする為のデータベース、テーブルを作成します。チュートリアルでは仮想ウェアハウスも作成していますが、初期で用意されているCOMPUTE_WHでも事足りそうなのでスキップします。

# データベースの作成
miyamoto#COMPUTE_WH@(no database).(no schema)>create or replace database sf_tuts;
+----------------------------------------+
| status |
|----------------------------------------|
| Database SF_TUTS successfully created. |
+----------------------------------------+
1 Row(s) produced. Time Elapsed: 0.673s

# テーブルの作成
miyamoto#COMPUTE_WH@SF_TUTS.PUBLIC>create or replace table emp_basic (
first_name string ,
last_name string ,
email string ,
streetaddress string ,
city string ,
start_date date
);
+---------------------------------------+
| status |
|---------------------------------------|
| Table EMP_BASIC successfully created. |
+---------------------------------------+
1 Row(s) produced. Time Elapsed: 1.083s

参考) CREATE <オブジェクト>

データファイルをステージングする

Snowflake にデータをロードするには、ローカルから直接ロードするのではなく、ステージと呼ばれる領域にファイルをアップロードし、その後テーブルへのコピーを実施する必要があります。

ステージには内部(Snowflake)ステージ外部(Amazon S3、Google Cloud Storage、またはMicrosoft Azure)ステージ があり、今回は内部ステージを使用します。

こちら にロード用のデータがあるので、ダウンロードして任意のディレクトリに解凍しておきましょう。私は /tmp 配下に配置しました。

$ tree
/tmp
├── employees01.csv
├── employees02.csv
├── employees03.csv
├── employees04.csv
└── employees05.csv

 

PUT を使用して内部ステージへのアップロードを行います。

miyamoto#COMPUTE_WH@SF_TUTS.PUBLIC>put file:///tmp/employees0*.csv @sf_tuts.public.%emp_basic;

employees04.csv_c.gz(0.00MB): [##########] 100.00% Done (0.090s, 0.00MB/s).
employees01.csv_c.gz(0.00MB): [##########] 100.00% Done (0.128s, 0.00MB/s).
employees02.csv_c.gz(0.00MB): [##########] 100.00% Done (0.063s, 0.00MB/s).
employees03.csv_c.gz(0.00MB): [##########] 100.00% Done (0.067s, 0.00MB/s).
employees05.csv_c.gz(0.00MB): [##########] 100.00% Done (0.066s, 0.00MB/s).
+-----------------+--------------------+-------------+-------------+--------------------+--------------------+----------+---------+
| source | target | source_size | target_size | source_compression | target_compression | status | message |
|-----------------+--------------------+-------------+-------------+--------------------+--------------------+----------+---------|
| employees01.csv | employees01.csv.gz | 370 | 288 | NONE | GZIP | UPLOADED | |
| employees02.csv | employees02.csv.gz | 364 | 276 | NONE | GZIP | UPLOADED | |
| employees03.csv | employees03.csv.gz | 407 | 298 | NONE | GZIP | UPLOADED | |
| employees04.csv | employees04.csv.gz | 375 | 290 | NONE | GZIP | UPLOADED | |
| employees05.csv | employees05.csv.gz | 404 | 303 | NONE | GZIP | UPLOADED | |
+-----------------+--------------------+-------------+-------------+--------------------+--------------------+----------+---------+
5 Row(s) produced. Time Elapsed: 4.665s

一つ目の引数はfile://<アップロードするファイル>@<データベース名>.<スキーマ名>.%<テーブル名> の形式です。スキーマは事前の手順で作成していませんので、自動で作成されるpublicを使用しています。

参考) PUT

因みに内部ステージにはいくつか種類があるようで、今回はテーブルステージを使用しています。詳細は以下を参照して下さい。

参考) ローカルファイルのステージの選択

内部ステージにアップロードしたファイルをテーブルにコピーする

準備が整ったので copy を使用してファイルをテーブルにロードします。

miyamoto#COMPUTE_WH@SF_TUTS.PUBLIC>copy into emp_basic
from @%emp_basic
file_format = (type = csv field_optionally_enclosed_by='"')
pattern = '.*employees0[1-5].csv.gz'
on_error = 'skip_file';
+--------------------+--------+-------------+-------------+-------------+-------------+-------------+------------------+-----------------------+-------------------------+
| file | status | rows_parsed | rows_loaded | error_limit | errors_seen | first_error | first_error_line | first_error_character | first_error_column_name |
|--------------------+--------+-------------+-------------+-------------+-------------+-------------+------------------+-----------------------+-------------------------|
| employees04.csv.gz | LOADED | 5 | 5 | 1 | 0 | NULL | NULL | NULL | NULL |
| employees02.csv.gz | LOADED | 5 | 5 | 1 | 0 | NULL | NULL | NULL | NULL |
| employees05.csv.gz | LOADED | 5 | 5 | 1 | 0 | NULL | NULL | NULL | NULL |
| employees03.csv.gz | LOADED | 5 | 5 | 1 | 0 | NULL | NULL | NULL | NULL |
| employees01.csv.gz | LOADED | 5 | 5 | 1 | 0 | NULL | NULL | NULL | NULL |
+--------------------+--------+-------------+-------------+-------------+-------------+-------------+------------------+-----------------------+-------------------------+
5 Row(s) produced. Time Elapsed: 2.760s

  • from: 内部ステージ名を指定します。@%emp_basic と指定されていますが、プロンプトの表示(miyamoto#COMPUTE_WH@SF_TUTS.PUBLIC)の通り、現在使用しているデータベース(sf_tuts)、スキーマ(public)が使用されます。省略せずに書くと @sf_tuts.public.%emp_basic (@<データベース名.<スキーマ名>.%<テーブル名> ) です。
  • file_format: ロードするファイルの形式を指定します。今回の場合は CSV ファイルで項目は"で囲まれていることを指定しています。
  • pattern: ロード対象のファイルを正規表現で指定できます。
  • on_error: ロード中にエラーが発生した場合に後続のファイルを処理するかどうか指定します。今回はskip_file(エラー対象のファイルをスキップして後続のファイルのインポートは続ける)と指定しています。

参考) COPY INTO

ロード内容の確認

miyamoto#COMPUTE_WH@SF_TUTS.PUBLIC>select * from EMP_BASIC limit 5;

+------------+-----------+--------------------------+--------------------------+--------------------+------------+
| FIRST_NAME | LAST_NAME | EMAIL | STREETADDRESS | CITY | START_DATE |
|------------+-----------+--------------------------+--------------------------+--------------------+------------|
| Wallis | Sizey | wsizeyf@sf_tuts.com | 36761 American Lane | Taibao | 2016-12-30 |
| Di | McGowran | dmcgowrang@sf_tuts.com | 1856 Maple Lane | Banjar Bengkelgede | 2017-04-22 |
| Carson | Bedder | cbedderh@sf_tuts.co.au | 71 Clyde Gallagher Place | Leninskoye | 2017-03-29 |
| Dana | Avory | davoryi@sf_tuts.com | 2 Holy Cross Pass | Wenlin | 2017-05-11 |
| Ronny | Talmadge | rtalmadgej@sf_tuts.co.uk | 588 Chinook Street | Yawata | 2017-06-02 |
+------------+-----------+--------------------------+--------------------------+--------------------+------------+
5 Row(s) produced. Time Elapsed: 2.705s

ロード出来ていますね!

まとめ

SnowSQL を使って CSV ファイルのロードを試してみました。ファイルを一度ステージにアップロードしてからコピーする必要があり、一手間多い感想をいだきましたが、アップロード時には自動でファイルを圧縮してくれますし、DWH で扱うデータ量を考えると理にかなっているとも感じました。

次回は S3 からのインポートを試してみたいと思います。

AWS CodeBuildでビルド実行時に使うShellの指定ができるようになりました

$
0
0

2020年6月25日のAWS CodeBuildのアップデートです。

AWS CodeBuildが追加のシェル環境をサポートするようになりました。
AWS CodeBuild Now Supports Additional Shell Environments

AWS CodeBuildを利用すると、ビルド用コンテナが作成され、その中でShellが起動し、buildspec.ymlで定義したコマンドが実行されます。
どのShellが起動するかは、今までは指定できず、Linuxコンテナならsh、WindowsコンテナならPowershellと決まっていましたが、今回のアップデートで他のShellも選択できるようになりました。

For Linux operating systems, supported shell tags are:
• bash
• /bin/sh

For Windows operating systems, supported shell tags are:
• powershell.exe
• cmd.exe

Build specification reference for CodeBuild

以下でShellを指定し、動作確認してみます。

なお、一般的にCodeBuildはアプリケーションをビルドしたり、コンテナイメージを作成したりするのに使われますが、今回は単純にどのShellが動いているのか確認するだけのビルドプロジェクトを作成します。

1.Amazon Linux 2で動作確認

まずはAmazon Linux 2のイメージでShellをbashに指定してみます。

1-1.s3バケットの作成

buildspec.ymlを含むビルドスクリプトを格納するためのs3バケットを作成します。

# 任意の名前のs3バケットの作成
$ aws s3 mb s3://codebuild-shelltest-project-input

1-2.ビルドスクリプトの作成

今回は手元のMacBookで操作しました。

作業ディレクトリ作成

# 任意の名前の作業ディレクトリの作成し、移動
$ mkdir codebuild-shelltest-project
$ cd codebuild-shelltest-project

buildspec.yml作成

version: 0.2

env:
  shell: bash

phases:
  install:
    commands:
      - echo Nothing to do in the install phase...
      - ps -p $$
  pre_build:
    commands:
      - echo Nothing to do in the pre_build phase...
      - ps -p $$
  build:
    commands:
      - echo Nothing to do in the build phase...
      - ps -p $$
  post_build:
    commands:
      - echo Nothing to do in the post_build phase...
      - ps -p $$

3〜4行目が今回のアップデート部分で、Shellを指定しています。
また、現在動いているプロセスを確認するために、ps -p $$を実行させます。

zipで固める

# 任意の名前のzipファイルを作成
$ zip -r codebuild-shelltest.zip .

1-3.s3へビルドスクリプトをアップロード

# zipファイルをs3バケットへアップロード
$ aws s3 cp codebuild-shelltest.zip s3://codebuild-shelltest-project-input/codebuild-shelltest.zip

1-4.CodeBuildプロジェクトの作成

設定項目
プロジェクト名 任意
ソースプロバイダ Amazon S3
バケット 上記作成したS3バケット名
S3 オブジェクトキーまたは S3 フォルダ 上記でアップロードしたzipファイル名
環境イメージ マネージド型イメージ(Amazon Linux 2)
ビルド仕様 buildspecファイルを使用する

1-5.ビルドの実行

プロジェクトを指定し、ビルドの開始をします。

1-6.ビルドログ確認

ビルドが完了すると、ビルドログが表示され、bashが実行されているのがわかります。

ビルドログ抜粋

[Container] 2020/06/29 03:41:17 Running command ps -p $$
  PID TTY          TIME CMD
   55 ?        00:00:00 bash

ビルドログ全行

[Container] 2020/06/29 03:41:13 Waiting for agent ping
[Container] 2020/06/29 03:41:15 Waiting for DOWNLOAD_SOURCE
[Container] 2020/06/29 03:41:17 Phase is DOWNLOAD_SOURCE
[Container] 2020/06/29 03:41:17 CODEBUILD_SRC_DIR=/codebuild/output/src788750357/src
[Container] 2020/06/29 03:41:17 YAML location is /codebuild/output/src788750357/src/buildspec.yml
[Container] 2020/06/29 03:41:17 Selecting shell bash as specified in buildspec.
[Container] 2020/06/29 03:41:17 Processing environment variables
[Container] 2020/06/29 03:41:17 No runtime version selected in buildspec.
[Container] 2020/06/29 03:41:17 Moving to directory /codebuild/output/src788750357/src
[Container] 2020/06/29 03:41:17 Registering with agent
[Container] 2020/06/29 03:41:17 Phases found in YAML: 4
[Container] 2020/06/29 03:41:17  BUILD: 2 commands
[Container] 2020/06/29 03:41:17  POST_BUILD: 2 commands
[Container] 2020/06/29 03:41:17  INSTALL: 2 commands
[Container] 2020/06/29 03:41:17  PRE_BUILD: 2 commands
[Container] 2020/06/29 03:41:17 Phase complete: DOWNLOAD_SOURCE State: SUCCEEDED
[Container] 2020/06/29 03:41:17 Phase context status code:  Message: 
[Container] 2020/06/29 03:41:17 Entering phase INSTALL
[Container] 2020/06/29 03:41:17 Running command echo Nothing to do in the install phase...
Nothing to do in the install phase...

[Container] 2020/06/29 03:41:17 Running command ps -p $$
  PID TTY          TIME CMD
   55 ?        00:00:00 bash

[Container] 2020/06/29 03:41:18 Phase complete: INSTALL State: SUCCEEDED
[Container] 2020/06/29 03:41:18 Phase context status code:  Message: 
[Container] 2020/06/29 03:41:18 Entering phase PRE_BUILD
[Container] 2020/06/29 03:41:18 Running command echo Nothing to do in the pre_build phase...
Nothing to do in the pre_build phase...

[Container] 2020/06/29 03:41:18 Running command ps -p $$
  PID TTY          TIME CMD
   66 ?        00:00:00 bash

[Container] 2020/06/29 03:41:18 Phase complete: PRE_BUILD State: SUCCEEDED
[Container] 2020/06/29 03:41:18 Phase context status code:  Message: 
[Container] 2020/06/29 03:41:18 Entering phase BUILD
[Container] 2020/06/29 03:41:18 Running command echo Nothing to do in the build phase...
Nothing to do in the build phase...

[Container] 2020/06/29 03:41:18 Running command ps -p $$
  PID TTY          TIME CMD
   73 ?        00:00:00 bash

[Container] 2020/06/29 03:41:18 Phase complete: BUILD State: SUCCEEDED
[Container] 2020/06/29 03:41:18 Phase context status code:  Message: 
[Container] 2020/06/29 03:41:18 Entering phase POST_BUILD
[Container] 2020/06/29 03:41:18 Running command echo Nothing to do in the post_build phase...
Nothing to do in the post_build phase...

[Container] 2020/06/29 03:41:18 Running command ps -p $$
  PID TTY          TIME CMD
   80 ?        00:00:00 bash

[Container] 2020/06/29 03:41:18 Phase complete: POST_BUILD State: SUCCEEDED
[Container] 2020/06/29 03:41:18 Phase context status code:  Message:

1-7.POSIXモードを使うかどうか

さて、CodeBuildでbash使えるようになりました。
しかし、Amazon Linux 2に詳しい方は、疑問に思うかもしれません。
なぜなら、実はAmazon Linux 2のshは、bashのシンボリックリンクになっているからです。

[Container] 2020/06/29 04:20:23 Running command cat /etc/shells
/bin/sh
/bin/bash
/usr/bin/sh
/usr/bin/bash

[Container] 2020/06/29 04:20:23 Running command ls -l /bin/sh
lrwxrwxrwx 1 root root 4 Apr  7 01:49 /bin/sh -> bash

[Container] 2020/06/29 04:20:23 Running command ls -l /bin/bash
-rwxr-xr-x 1 root root 935968 Jan 16 00:56 /bin/bash

[Container] 2020/06/29 04:20:23 Running command ls -l /usr/bin/sh
lrwxrwxrwx 1 root root 4 Apr  7 01:49 /usr/bin/sh -> bash

[Container] 2020/06/29 04:20:23 Running command ls -l /usr/bin/bash
-rwxr-xr-x 1 root root 935968 Jan 16 00:56 /usr/bin/bash

それでは、どれを使ってもbashで違いは無いのでは?と思ってしまいますが、意味はあります。
shでbashを呼び出すと、bashがPOSIXモードで動作するようになります。
どのように動作が変わるかは下記リンク先に記載があります。

6.11 Bash POSIX Mode
When invoked as sh, Bash enters POSIX mode after reading the startup files.

結論として、いわゆるBashを使いたい場合は、設定をした方が良いと思います。

2.Ubuntuでのbash利用

Ubuntuのshは、実はshでもなく、bashでもなく、dashです。
したがって、Ubuntuでbashを指定するのは意味があります。

[Container] 2020/06/28 17:11:54 Running command cat /etc/shells
# /etc/shells: valid login shells
/bin/sh
/bin/bash
/bin/rbash
/bin/dash

[Container] 2020/06/29 04:25:27 Running command ls -l /bin/sh
lrwxrwxrwx 1 root root 4 Apr  3 17:13 /bin/sh -> dash

[Container] 2020/06/29 04:25:27 Running command ls -l /bin/bash
-rwxr-xr-x 1 root root 1113504 Jun  6  2019 /bin/bash

[Container] 2020/06/29 04:25:27 Running command ls -l /bin/rbash
lrwxrwxrwx 1 root root 4 Jun  6  2019 /bin/rbash -> bash

[Container] 2020/06/29 04:25:27 Running command ls -l /bin/dash
-rwxr-xr-x 1 root root 121432 Jan 25  2018 /bin/dash

まとめ

今までは、AWS CodeBuildのビルドスクリプトの中で、Amazon Linux 2はsh(POSIX互換のBash)、Ubuntuはdash、WindowsはPowershellが利用可能でした。
今後は、bashやCMDも利用可能となりました。

Viewing all 1210 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>