20200125のAWSに関する記事は24件です。

投稿日：2020-01-25T23:05:22+09:00

【AWS】Qiita 週間いいね数ランキング【タグ別】

他のタグ

Python

JavaScript

AWS

Ruby

Rails

Docker

Vue.js

PHP

集計期間

01月18日 ~ 01月25日

いいね数ランキング

1位: [個人開発]大喜利サービスを5日でつくってわかったこと

PHP AWS lamp Webサービス 個人開発
180いいね
@n_devさん(01月22日 13時55分の投稿)

2位: AWS・GCP・AzureのIoTプラットフォームを調べている

AWS Azure gcp IoT
36いいね
@narutaroさん(01月20日 12時01分の投稿)

3位: 実践Terraformを写経してみたらよかったって話

AWS Terraform
11いいね
@1021ky@githubさん(01月20日 05時52分の投稿)

4位: AWS CLIのアカウントを切り替えるためのコマンドを作成する

ShellScript AWS shell aws-cli
7いいね
@cohey0727さん(01月19日 19時14分の投稿)

5位: AWSのEC2とRDSをTerraformで構築する　Terraform３分クッキング

Linux AWS PostgreSQL RDS Terraform
5いいね
@Brutusさん(01月20日 22時44分の投稿)

6位: AWSが大阪リージョンを開設するに至った背景を推測する

AWS DR
5いいね
@hedgehog051さん(01月20日 17時01分の投稿)

7位: DjangoアプリをDocker上に構築しAWS Fargateにデプロイする

Python Django AWS Docker Fargate
4いいね
@keita_gawaharaさん(01月23日 13時05分の投稿)

8位: 無から素数列挙 on Athena (Presto)

AWS SQL Presto Athena
4いいね
@random25umezawaさん(01月21日 14時32分の投稿)

9位: 個人でやっている AWS IAM の運用

AWS macos IAM 個人開発 aws-vault
4いいね
@hyiromoriさん(01月20日 20時44分の投稿)

10位: terraform で同じスペックの EC2 を複数台作る

AWS EC2 初心者 Terraform Infrastructure_as_code
3いいね
@ktoshiさん(01月21日 02時09分の投稿)

11位: 日本語に対応した文字起こしサービス Amazon Transcribe がすごいらしいので試してみた

AWS Amazon Transcribe
3いいね
@Gerberaさん(01月20日 16時06分の投稿)

12位: 異なるAWSアカウント間のS3内データを移動する方法

AWS S3 IAM
3いいね
@mu-techさん(01月19日 01時06分の投稿)

13位: 【AWS・Python】Slash Commandsを拡張性高く実装する

AWS Python3 Slack slack-api ChainOfResponsibility
2いいね
@Lilly008000さん(01月25日 08時03分の投稿)

14位: 【ブログ枠】JAWS-UGコンテナ支部 #16〜EKS on Fargateローンチ記念！EKS祭りだワッショイ#1

AWS kubernetes Fargate eks
2いいね
@hedgehog051さん(01月24日 23時45分の投稿)

15位: AWS Athenaで、WAFのcountログが絞り込めなくて苦戦した件

AWS SQL Athena
2いいね
@fujiQさん(01月24日 08時42分の投稿)

16位: Amazon S3 へ Amazon RDS のスナップショットをエクスポートできるようになったので、 AWS CLI で実行してみました。

AWS RDS aws-cli amazons3
2いいね
@hirosys-bizさん(01月24日 06時15分の投稿)

17位: 新しめの設定をいれた AWS Billing and Cost Management 総まとめ

AWS CloudFormation IAM Terraform billing
2いいね
@tonishyさん(01月23日 15時35分の投稿)

18位: 【AWS】S3へのデータアップロード

AWS
2いいね
@chanP_yamazakiさん(01月23日 10時12分の投稿)

19位: ArgoでCIパイプラインを構築する

AWS Argo
2いいね
@Static_Noviceさん(01月23日 08時43分の投稿)

20位: MediaLiveで出力したアーカイブファイルをMP4に自動変換する

AWS lambda MediaLive MediaConvert
2いいね
@ktsuchiさん(01月23日 07時59分の投稿)

21位: AWS Sysopsアドミニストレーターアソシエイト資格に合格しました。

AWS
2いいね
@kkino1985さん(01月22日 16時32分の投稿)

22位: AWS中国コンソールとグローバルの違うところ

AWS
2いいね
@zhaopeng9さん(01月22日 07時45分の投稿)

23位: ServerlessFrameworkでスクレイピング用Lambda-Layerを作る

AWS cloud9 Python3 ServerlessFramework Lambda-Layers
2いいね
@konomochiさん(01月20日 16時48分の投稿)

24位: 機械学習でひさ子のギターを自分のギターに持ち替えてもらう -準備編-

Python AWS PyTorch CycleGAN
2いいね
@nozomi254さん(01月20日 11時56分の投稿)

25位: Amplifyとは何者なのか

AWS 初心者 amplify
2いいね
@chihiroさん(01月20日 04時25分の投稿)

26位: codecommitとredmineを連携させる

AWS Redmine lambda CodeCommit
2いいね
@turbo5522mameさん(01月20日 01時18分の投稿)

27位: [AWS]Webサーバーの構築方法

AWS SSH EC2 ami WEBサーバ
2いいね
@kono-hirokiさん(01月19日 08時40分の投稿)

28位: AWSの請求と料金

AWS 自分用メモ AWS認定クラウドプラクティショナー
2いいね
@taktak813tecさん(01月19日 06時28分の投稿)

29位: AWS SAP エッセンス(執筆中毎週更新)

AWS
2いいね
@onzuka_muscleさん(01月19日 06時20分の投稿)

30位: AWSでDB(MySQL)を作成した後、A5:SQL Mk-2で接続して管理する方法

MySQL AWS DB a5m2
2いいね
@saeki_teiziさん(01月19日 05時57分の投稿)

31位: SSMパラメータストアを読み書きするCLIを作ってみた

AWS SSM パラメータストア
2いいね
@k24dさん(01月19日 05時16分の投稿)

32位: (コマンド化)AWS CLIにおけるMFA認証

Bash Mac Linux AWS aws-cli
1いいね
@turbo5522mameさん(01月25日 05時49分の投稿)

33位: M5Stack + UiFlow + AWS でグラフ化 & 異常通知

AWS uiflow M5stack
1いいね
@PharaohKJさん(01月25日 02時52分の投稿)

34位: AWSアカウント作り直してみた

AWS 新卒エンジニア
1いいね
@tttmatsuoさん(01月24日 11時02分の投稿)

35位: インフラエンジニア、自由人として現状aws cloud9が最強だと思う理由

AWS cloud9
1いいね
@yubeさん(01月24日 10時57分の投稿)

36位: EC2 AutoScalingを使ったGraceful Shutdownを考える

AWS Fluentd
1いいね
@taxinさん(01月24日 09時21分の投稿)

37位: Lambda Node.js8.10から10.xへのバージョンアップに伴うImageMagickの対応

Node.js AWS lambda
1いいね
@cider-skさん(01月24日 06時50分の投稿)

38位: 【AWS】~/.ssh/configを使って、簡単にssh接続する

AWS SSH
1いいね
@mataki_tanakaさん(01月24日 06時35分の投稿)

39位: EC2で立ち上げたWordPressで.htaccessを使えるようにする方法

WordPress AWS BITNAMI
1いいね
@k-andoさん(01月24日 04時54分の投稿)

40位: 画像から人物の性別、年齢を推測するLine botを作ってみた

Python AWS lambda ReKognition linebot
1いいね
@ve_sonoさん(01月24日 01時17分の投稿)

41位: Amazon Web Services (AWS)サービスの正式名称・略称・読み方まとめ #24 (SDK とツールキット)

AWS まとめ AmazonWebServices 読み方 略語
1いいね
@kai_kouさん(01月24日 00時00分の投稿)

42位: flaws.cloudに挑戦してみた

AWS セキュリティ
1いいね
@raqqonaさん(01月23日 09時59分の投稿)

43位: 【Rails】 Heroku, Aws で詰まったときに見る記事まとめ

Rails Heroku AWS
1いいね
@wafuwafu13さん(01月23日 03時07分の投稿)

44位: RDSとIAMでパスワードレス認証（Python）

Python MySQL AWS RDS AWSLambda
1いいね
@ChaseSanさん(01月23日 00時41分の投稿)

45位: AWS Amplify Android を試してみる(Mac)

Mac AWS amplify
1いいね
@ksato2032さん(01月22日 13時51分の投稿)

46位: AWS DevOps Professional合格レポート

AWS devops 資格 AWS認定試験
1いいね
@jusotech10さん(01月22日 12時52分の投稿)

47位: AWSで作ったLaravelアプリケーションをXserverにデプロイする

PHP AWS xampp Laravel xserver
1いいね
@chobiutauさん(01月22日 10時20分の投稿)

48位: 同じVPC内のEC2へホスト名でSSH接続する

AWS Ubuntu SSH ubuntu16.04
1いいね
@latin1さん(01月22日 07時33分の投稿)

49位: DynamoDBでPromiseが使えた(Lambda Node.js)

Node.js AWS DynamoDB lambda
1いいね
@gdtypkさん(01月22日 06時46分の投稿)

50位: IP制限しているインスタンスに対してCloudfrontからのアクセスを許可する

AWS Instance sg ip-list
1いいね
@yubeさん(01月22日 05時52分の投稿)

51位: Lambda + API GatewayでCORSを有効にしているのにCORSでエラーになる

JavaScript AWS CORS lambda APIGateway
1いいね
@scalewalletさん(01月22日 03時55分の投稿)

52位: Amazon Web Services (AWS)サービスの正式名称・略称・読み方まとめ #23 (AR とバーチャルリアリティ)

AWS まとめ AmazonWebServices 読み方 略語
1いいね
@kai_kouさん(01月22日 00時00分の投稿)

53位: AWS Solution Architect Associate メモ１

AWS EC2 ebs AutoScaling vpc
1いいね
@kimuchanさん(01月21日 23時00分の投稿)

54位: 自動デプロイ（Capistrano）でエラー mkdir: ディレクトリ `/var/www' を作成できません: 許可がありません

Ruby Rails Capistrano AWS Rails5
1いいね
@nousiさん(01月21日 15時21分の投稿)

55位: AWS SES メール送信環境のセキュリティを解剖する (2020年版)

AWS mail ses Security SMTP
1いいね
@nasuvitzさん(01月21日 13時15分の投稿)

56位: CodeCommit + CodeDeploy + CodePipelineでEC2にデプロイ~CodePipelineの設定・デプロイ実行~

AWS CodeDeploy CodeCommit CodePipeline
1いいね
@k_senbeiさん(01月21日 11時20分の投稿)

57位: CodeCommit + CodeDeploy + CodePipelineでEC2にデプロイ~CodeDeployの設定~

Rails AWS CodeDeploy CodeCommit CodePipeline
1いいね
@k_senbeiさん(01月21日 11時19分の投稿)

58位: CodeCommit + CodeDeploy + CodePipelineでEC2にデプロイ~CodeCommitの設定~

AWS CodeDeploy CodeCommit CodePipeline
1いいね
@k_senbeiさん(01月21日 11時17分の投稿)

59位: 【その設定値をゼロにするなんてとんでもない!】SQSで同じメッセージを複数件受信してしまう

Python AWS Python3 sqs
1いいね
@skokadoさん(01月21日 03時25分の投稿)

60位: Javascriptのシンプルな構成でAWS Cognitoを理解する

JavaScript AWS JWT cognito
1いいね
@TKFM21さん(01月21日 03時02分の投稿)

61位: EFSをVPC PeeringしたLightsailのCentOSにマウントさせる

CentOS AWS EFS Lightsail
1いいね
@kaihei777さん(01月21日 03時00分の投稿)

62位: 機械学習でひさ子のギターを自分のギターに持ち替えてもらう -実行編-

Python AWS PyTorch CycleGAN
1いいね
@nozomi254さん(01月20日 18時05分の投稿)

63位: codecommitのPullRequestをredmineのチケットに連携する

AWS Redmine lambda CodeCommit SimpleNotificationService
1いいね
@turbo5522mameさん(01月20日 12時03分の投稿)

64位: 特定のS3 バケットだけにアクセスするポリシーを30秒で書く

AWS S3 JSON aws-cli
1いいね
@taiyodayoさん(01月20日 04時17分の投稿)

65位: DynamoDB CLI

AWS DynamoDB
1いいね
@leomaro7さん(01月20日 03時08分の投稿)

66位: 【これからプログラミング&クラウドを始める人向け】AWS Cloud9 を利用して Ruby の開発環境を作ってみる③ - Ruby のバージョン管理

Ruby AWS cloud9
1いいね
@KCbogardさん(01月19日 16時32分の投稿)

67位: マストドン構築2日目 on AWS

AWS OSS mastodon
1いいね
@suwa3さん(01月19日 11時02分の投稿)

68位: AWS Amplify API作成

AWS amplify AppSync
1いいね
@Noplanさん(01月19日 07時32分の投稿)

69位: 【Rails】ActionMailer + AWS SES

Ruby Rails AWS ses ActionMailer
1いいね
@syukan3さん(01月19日 05時50分の投稿)

70位: Railsチュートリアル第13章ユーザーのマイクロポスト - 本番環境での画像アップロード

Rails Heroku AWS 初心者 Railsチュートリアル
1いいね
@rapidliner00さん(01月19日 05時49分の投稿)

71位: AWSの管理サービス

AWS 自分用メモ AWS認定クラウドプラクティショナー
1いいね
@taktak813tecさん(01月19日 03時40分の投稿)

72位: AWSのデータベースサービス

AWS 自分用メモ AWS認定クラウドプラクティショナー
1いいね
@taktak813tecさん(01月19日 01時24分の投稿)

　 Tweet
Qiitaで続きを読む

投稿日：2020-01-25T23:05:22+09:00

【AWS】Qiita 週間いいね数ランキング【自動更新】

他のタグ

Python

JavaScript

AWS

Ruby

Rails

Docker

Vue.js

PHP

集計期間

01月19日 ~ 01月26日

いいね数ランキング

1位: [個人開発]大喜利サービスを5日でつくってわかったこと

PHP AWS lamp Webサービス 個人開発
189いいね
@n_devさん(01月22日 22時55分の投稿)

2位: AWS・GCP・AzureのIoTプラットフォームを調べている

AWS Azure gcp IoT
37いいね
@narutaroさん(01月20日 21時01分の投稿)

3位: 実践Terraformを写経してみたらよかったって話

AWS Terraform
11いいね
@1021ky@githubさん(01月20日 14時52分の投稿)

4位: AWSのEC2とRDSをTerraformで構築する　Terraform３分クッキング

Linux AWS PostgreSQL RDS Terraform
5いいね
@Brutusさん(01月21日 07時44分の投稿)

5位: AWSが大阪リージョンを開設するに至った背景を推測する

AWS DR
5いいね
@hedgehog051さん(01月21日 02時01分の投稿)

6位: 【ブログ枠】JAWS-UGコンテナ支部 #16〜EKS on Fargateローンチ記念！EKS祭りだワッショイ#1

AWS kubernetes Fargate eks
4いいね
@hedgehog051さん(01月25日 08時45分の投稿)

7位: DjangoアプリをDocker上に構築しAWS Fargateにデプロイする

Python Django AWS Docker Fargate
4いいね
@keita_gawaharaさん(01月23日 22時05分の投稿)

8位: 無から素数列挙 on Athena (Presto)

AWS SQL Presto Athena
4いいね
@random25umezawaさん(01月21日 23時32分の投稿)

9位: 個人でやっている AWS IAM の運用

AWS macos IAM 個人開発 aws-vault
4いいね
@hyiromoriさん(01月21日 05時44分の投稿)

10位: 日本語に対応した文字起こしサービス Amazon Transcribe がすごいらしいので試してみた

AWS Amazon Transcribe
4いいね
@Gerberaさん(01月21日 01時06分の投稿)

11位: 【AWS・Python】Slash Commandsを拡張性高く実装する

AWS Python3 Slack slack-api ChainOfResponsibility
3いいね
@Lilly008000さん(01月25日 17時03分の投稿)

12位: 【AWS】トライアル期間を試してみる。最初にやるべきことは何？~登録編~

AWS 初心者
2いいね
@ninoko1995さん(01月25日 20時26分の投稿)

13位: AWS EC2のインスタンス毎のデータ転送量を知る方法

AWS
2いいね
@koji4104さん(01月25日 18時47分の投稿)

14位: AWS Athenaで、WAFのcountログが絞り込めなくて苦戦した件

AWS SQL Athena
2いいね
@fujiQさん(01月24日 17時42分の投稿)

15位: Amazon S3 へ Amazon RDS のスナップショットをエクスポートできるようになったので、 AWS CLI で実行してみました。

AWS RDS aws-cli amazons3
2いいね
@hirosys-bizさん(01月24日 15時15分の投稿)

16位: 新しめの設定をいれた AWS Billing and Cost Management 総まとめ

AWS CloudFormation IAM Terraform billing
2いいね
@tonishyさん(01月24日 00時35分の投稿)

17位: 【AWS】S3へのデータアップロード

AWS
2いいね
@chanP_yamazakiさん(01月23日 19時12分の投稿)

18位: ArgoでCIパイプラインを構築する

AWS Argo
2いいね
@Static_Noviceさん(01月23日 17時43分の投稿)

19位: MediaLiveで出力したアーカイブファイルをMP4に自動変換する

AWS lambda MediaLive MediaConvert
2いいね
@ktsuchiさん(01月23日 16時59分の投稿)

20位: AWS Sysopsアドミニストレーターアソシエイト資格に合格しました。

AWS
2いいね
@kkino1985さん(01月23日 01時32分の投稿)

21位: AWS DevOps Professional合格レポート

AWS devops 資格 AWS認定試験
2いいね
@jusotech10さん(01月22日 21時52分の投稿)

22位: AWS中国コンソールとグローバルの違うところ

AWS
2いいね
@zhaopeng9さん(01月22日 16時45分の投稿)

23位: terraform で同じスペックの EC2 を複数台作る

AWS EC2 初心者 Terraform Infrastructure_as_code
2いいね
@ktoshiさん(01月21日 11時09分の投稿)

24位: ServerlessFrameworkでスクレイピング用Lambda-Layerを作る

AWS cloud9 Python3 ServerlessFramework Lambda-Layers
2いいね
@konomochiさん(01月21日 01時48分の投稿)

25位: 機械学習でひさ子のギターを自分のギターに持ち替えてもらう -準備編-

Python AWS PyTorch CycleGAN
2いいね
@nozomi254さん(01月20日 20時56分の投稿)

26位: Amplifyとは何者なのか

AWS 初心者 amplify
2いいね
@chihiroさん(01月20日 13時25分の投稿)

27位: codecommitとredmineを連携させる

AWS Redmine lambda CodeCommit
2いいね
@turbo5522mameさん(01月20日 10時18分の投稿)

28位: AWS DefaultのVPCにプライベートサブネットを作る

AWS 初心者 default vpc subnet
1いいね
@SSMU3さん(01月26日 00時12分の投稿)

29位: (コマンド化)AWS CLIにおけるMFA認証

Bash Mac Linux AWS aws-cli
1いいね
@turbo5522mameさん(01月25日 14時49分の投稿)

30位: M5Stack + UiFlow + AWS でグラフ化 & 異常通知

AWS uiflow M5stack
1いいね
@PharaohKJさん(01月25日 11時52分の投稿)

31位: 【AWS/Lambda】lambdaに固定IPをつける/VPCに所属させる

AWS lambda
1いいね
@shim-hikoさん(01月24日 21時13分の投稿)

32位: AWSアカウント作り直してみた

AWS 新卒エンジニア
1いいね
@tttmatsuoさん(01月24日 20時02分の投稿)

33位: インフラエンジニア、自由人として現状aws cloud9が最強だと思う理由

AWS cloud9
1いいね
@yubeさん(01月24日 19時57分の投稿)

34位: EC2 AutoScalingを使ったGraceful Shutdownを考える

AWS Fluentd
1いいね
@taxinさん(01月24日 18時21分の投稿)

35位: Lambda Node.js8.10から10.xへのバージョンアップに伴うImageMagickの対応

Node.js AWS lambda
1いいね
@cider-skさん(01月24日 15時50分の投稿)

36位: 【AWS】~/.ssh/configを使って、簡単にssh接続する

AWS SSH
1いいね
@mataki_tanakaさん(01月24日 15時35分の投稿)

37位: EC2で立ち上げたWordPressで.htaccessを使えるようにする方法

WordPress AWS BITNAMI
1いいね
@k-andoさん(01月24日 13時54分の投稿)

38位: 画像から人物の性別、年齢を推測するLine botを作ってみた

Python AWS lambda ReKognition linebot
1いいね
@ve_sonoさん(01月24日 10時17分の投稿)

39位: Amazon Web Services (AWS)サービスの正式名称・略称・読み方まとめ #24 (SDK とツールキット)

AWS まとめ AmazonWebServices 読み方 略語
1いいね
@kai_kouさん(01月24日 09時00分の投稿)

40位: flaws.cloudに挑戦してみた

AWS セキュリティ
1いいね
@raqqonaさん(01月23日 18時59分の投稿)

41位: 【Rails】 Heroku, Aws で詰まったときに見る記事まとめ

Rails Heroku AWS
1いいね
@wafuwafu13さん(01月23日 12時07分の投稿)

42位: RDSとIAMでパスワードレス認証（Python）

Python MySQL AWS RDS AWSLambda
1いいね
@ChaseSanさん(01月23日 09時41分の投稿)

43位: AWS Amplify Android を試してみる(Mac)

Mac AWS amplify
1いいね
@ksato2032さん(01月22日 22時51分の投稿)

44位: AWSで作ったLaravelアプリケーションをXserverにデプロイする

PHP AWS xampp Laravel xserver
1いいね
@chobiutauさん(01月22日 19時20分の投稿)

45位: 同じVPC内のEC2へホスト名でSSH接続する

AWS Ubuntu SSH ubuntu16.04
1いいね
@latin1さん(01月22日 16時33分の投稿)

46位: DynamoDBでPromiseが使えた(Lambda Node.js)

Node.js AWS DynamoDB lambda
1いいね
@gdtypkさん(01月22日 15時46分の投稿)

47位: IP制限しているインスタンスに対してCloudfrontからのアクセスを許可する

AWS Instance sg ip-list
1いいね
@yubeさん(01月22日 14時52分の投稿)

48位: Lambda + API GatewayでCORSを有効にしているのにCORSでエラーになる

JavaScript AWS CORS lambda APIGateway
1いいね
@scalewalletさん(01月22日 12時55分の投稿)

49位: Amazon Web Services (AWS)サービスの正式名称・略称・読み方まとめ #23 (AR とバーチャルリアリティ)

AWS まとめ AmazonWebServices 読み方 略語
1いいね
@kai_kouさん(01月22日 09時00分の投稿)

50位: AWS Solution Architect Associate メモ１

AWS EC2 ebs AutoScaling vpc
1いいね
@kimuchanさん(01月22日 08時00分の投稿)

51位: 自動デプロイ（Capistrano）でエラー mkdir: ディレクトリ `/var/www' を作成できません: 許可がありません

Ruby Rails Capistrano AWS Rails5
1いいね
@nousiさん(01月22日 00時21分の投稿)

52位: AWS SES メール送信環境のセキュリティを解剖する (2020年版)

AWS mail ses Security SMTP
1いいね
@nasuvitzさん(01月21日 22時15分の投稿)

53位: CodeCommit + CodeDeploy + CodePipelineでEC2にデプロイ~CodePipelineの設定・デプロイ実行~

AWS CodeDeploy CodeCommit CodePipeline
1いいね
@k_senbeiさん(01月21日 20時20分の投稿)

54位: CodeCommit + CodeDeploy + CodePipelineでEC2にデプロイ~CodeDeployの設定~

Rails AWS CodeDeploy CodeCommit CodePipeline
1いいね
@k_senbeiさん(01月21日 20時19分の投稿)

55位: CodeCommit + CodeDeploy + CodePipelineでEC2にデプロイ~CodeCommitの設定~

AWS CodeDeploy CodeCommit CodePipeline
1いいね
@k_senbeiさん(01月21日 20時17分の投稿)

56位: 【その設定値をゼロにするなんてとんでもない!】SQSで同じメッセージを複数件受信してしまう

Python AWS Python3 sqs
1いいね
@skokadoさん(01月21日 12時25分の投稿)

57位: Javascriptのシンプルな構成でAWS Cognitoを理解する

JavaScript AWS JWT cognito
1いいね
@TKFM21さん(01月21日 12時02分の投稿)

58位: EFSをVPC PeeringしたLightsailのCentOSにマウントさせる

CentOS AWS EFS Lightsail
1いいね
@kaihei777さん(01月21日 12時00分の投稿)

59位: 機械学習でひさ子のギターを自分のギターに持ち替えてもらう -実行編-

Python AWS PyTorch CycleGAN
1いいね
@nozomi254さん(01月21日 03時05分の投稿)

60位: codecommitのPullRequestをredmineのチケットに連携する

AWS Redmine lambda CodeCommit SimpleNotificationService
1いいね
@turbo5522mameさん(01月20日 21時03分の投稿)

61位: 特定のS3 バケットだけにアクセスするポリシーを30秒で書く

AWS S3 JSON aws-cli
1いいね
@taiyodayoさん(01月20日 13時17分の投稿)

62位: DynamoDB CLI

AWS DynamoDB
1いいね
@leomaro7さん(01月20日 12時08分の投稿)

　 Tweet
Qiitaで続きを読む

投稿日：2020-01-25T22:43:52+09:00

AWS Lightsaiと既存VPCをピアリング接続する

AWS Lightsaiと既存VPCをピアリング接続する

概要

LightsailはAWSのVPSサービスとして通信料込みの破格なサービスです。
全てをEC2で構築している方が多いですが、テスト環境その他、Lightsailで十分という要件も多いと思います。

Lightsailで構築し、その上で既存のAWS環境と接続し、有効活用するためにLightsailの既存VPCをピアリング接続したいと思います。

ピアリング接続すると何がうれしいの？

LightsaiでEC2から接続するかのようにEFSやRDSが使えます。
グローバルIPでインターネット経由であれば、もちろんピアリング接続しなくても使えますが、ピアリング接続すると内部IPでの接続になるので、通信料もセキュリティ面でも安心です。

注意点

Lightsailと接続できるのはどうやらDefaultのVPCだけのようです(2020年1月時点)。
自分で構築したVPCと接続したい場合は、直接ピアリング接続はできませんので、注意してください。

尚、LightsailはSLAが設定されていません。
AWS側が原因でサービスが停止した際に文句を言いたいサービスはLightsailで構築せず、EC2を使用してください。

やり方

Lightsail側

(1) Lightsail設定画面へ移行

AWSコンソールにサインインし、Lightsail設定画面へ移行し、右上の「アカウント」から「アカウント」を選択します。

(2) アカウント設定画面

アカウント画面へ移行したら、「アドバンスト」を選択します。

(3) VPC接続を有効にする

「VPCピア接続を有効にする」のチェックボックスを有効にします。

Lightsail側は以上です。

AWS側

(1) AWS側でVPC設定画面よりピアリング接続の設定画面を開きます。

(2) 作成されたピアリング接続先の確認

新しいピアリング接続が追加されているのが確認できると思います。

(3) タグをつける

そのままではわかりづらいので、タグをつけてあげましょう。

(4) 追加されたルートテーブルの確認１

ルートテーブル設定画面を開きます。

(5) 追加されたルートテーブルの確認２

Defaultのルートテーブルを選択し、「ルート」タブをクリックします。

(6) 追加されたルートテーブルの確認３

追加されたルートテーブルをクリックします。

(7) 追加されたルートテーブルの確認４

ルートテーブルも自動で追加されていることが確認できると思います。

雑記

やり方は以上です。
この後にセキュリティグループの設定がありますが、それは各自でやってみてください。

できれば、Defaulだけでなく、自作したVPCとも接続できるようになれば便利ですね。
今後のアップデートに期待しましょう。

　 Tweet
Qiitaで続きを読む

投稿日：2020-01-25T22:43:52+09:00

AWS Lightsailと既存VPCをピアリング接続する

AWS Lightsailと既存VPCをピアリング接続する

概要

LightsailはAWSのVPSサービスとして通信料込みの破格なサービスです。
全てをEC2で構築している方が多いですが、テスト環境その他、Lightsailで十分という要件も多いと思います。

Lightsailで構築し、その上で既存のAWS環境と接続し、有効活用するためにLightsailの既存VPCをピアリング接続したいと思います。

ピアリング接続すると何がうれしいの？

LightsaiでEC2から接続するかのようにEFSやRDSが使えます。
グローバルIPでインターネット経由であれば、もちろんピアリング接続しなくても使えますが、ピアリング接続すると内部IPでの接続になるので、通信料もセキュリティ面でも安心です。

注意点

Lightsailと接続できるのはどうやらDefaultのVPCだけのようです(2020年1月時点)。
自分で構築したVPCと接続したい場合は、直接ピアリング接続はできませんので、注意してください。

尚、LightsailはSLAが設定されていません。
AWS側が原因でサービスが停止した際に文句を言いたいサービスはLightsailで構築せず、EC2を使用してください。

やり方

Lightsail側

(1) Lightsail設定画面へ移行

AWSコンソールにサインインし、Lightsail設定画面へ移行し、右上の「アカウント」から「アカウント」を選択します。

(2) アカウント設定画面

アカウント画面へ移行したら、「アドバンスト」を選択します。

(3) VPC接続を有効にする

「VPCピア接続を有効にする」のチェックボックスを有効にします。

Lightsail側は以上です。

AWS側

(1) AWS側でVPC設定画面よりピアリング接続の設定画面を開きます。

(2) 作成されたピアリング接続先の確認

新しいピアリング接続が追加されているのが確認できると思います。

(3) タグをつける

そのままではわかりづらいので、タグをつけてあげましょう。

(4) 追加されたルートテーブルの確認１

ルートテーブル設定画面を開きます。

(5) 追加されたルートテーブルの確認２

Defaultのルートテーブルを選択し、「ルート」タブをクリックします。

(6) 追加されたルートテーブルの確認３

追加されたルートテーブルをクリックします。

(7) 追加されたルートテーブルの確認４

ルートテーブルも自動で追加されていることが確認できると思います。

雑記

やり方は以上です。
この後にセキュリティグループの設定がありますが、それは各自でやってみてください。

できれば、Defaulだけでなく、自作したVPCとも接続できるようになれば便利ですね。
今後のアップデートに期待しましょう。

　 Tweet
Qiitaで続きを読む

投稿日：2020-01-25T22:29:14+09:00

AWS AmplifyのAPI.graphqlで"TypeError: Must provide Source. Received: undefined"

前提

amplify add apiでgraphqlを追加して、

const todos = await API.graphql(graphqlOperation(queries.listTodos));
console.log(todos)

のようなコードでAPIを呼び出すときに、
"TypeError: Must provide Source. Received: undefined"
のエラーが出た場合の対処について。

対応

結論、サンプルコピペのままで、存在しないクエリを設定してました。。
queries.listTodosじゃなくて、別のだった。

というわけで

エラーメッセージが大変わかりづらいので、もうちょっとがんばってほしいところです。

　 Tweet
Qiitaで続きを読む

投稿日：2020-01-25T21:59:08+09:00

AWSのVPCピアリング接続

AWSのVPCピアリング接続

概要

AWSを使っていて、VPCを分けることやルートテーブルの編集に苦手意識がある方が多いのに気が付いたので、説明用に記載します。
VPCをわけてもVPC同士をつなぐことができます。なので、遠慮なく分けてください。

デフォルトのVPCに全て格納し、サブネット分けすら適当な本番環境を見てて、すごくもったいないと感じます。
AWSを使うのであればきちんとVPCから設計し、きれいな形で作ると整理がしやすいし、セキュリティ面も強化されます。

注意

VPC同士でアドレス重複があるとピアリングができず、少し面倒なことになるので、必ずCIDRの範囲はVPC同士で分けてください。

やり方

ピアリング接続

(1) ピアリング接続の設定画面を開く

マネジメントコンソールのログにログインし、VPCの設定画面から、「ピアリング接続」を選択します。

(2)「ピアリング接続の作成開始」をクリックします。

(3) ピアリング接続ネームタグを設定する

任意の名前で構いませんので、名前を設定します。
ただし、後でわかりにくくなっても困るので、見てわかる名前にしましょう。
今回の例ではDefaulのVPCとDB用のVPCを接続しますので、「Default-DB-Peering」としました。

(4) ピアリング接続するローカルVPCを選択

接続元のVPCを選択します。

(5) ピアリング接続するもう1つのVPCを選択

接続先のVPCを選択します。
別のリージョンに対しても可能ですが、通信料金に注意してください。

(6) ピアリング接続の作成

設定の入力が完了したら、「ピアリング接続の作成」をクリックします。

(7) 確認画面

OKをクリックします。

(8) 承諾画面

承諾画面を確認します。
同じアカウント内であれば、そのまま承諾画面へと移行しますが、異なるアカウント同士のピアリング接続の場合は、接続先のVPCのあるアカウントでサインインし、VPCのピアリング接続画面に移行してください。

(9) ピアリングの承諾

「承諾の保留中」となっている項目を選択し、「アクション」から、「リクエストの承諾」を選択します。

(10) VPCピアリング接続リクエストの承諾

「はい、承諾する」をクリックします。

(11) ルートテーブルの設定画面へ

「ルートテーブルを今すぐ変更」をクリックします。
もし閉じてしまっても、VPCの「ルートテーブル」の項目からいつでも設定画面へ移行できます。

ルートテーブル

接続元

(1) 接続元のCIDR確認

一度VPCの一覧を確認し、CIDRを確認してください。

(2) 接続元のVPCの所属するルートテーブルを選択します。

(3) ルートの編集画面へ移行

「アクション」から「ルートの編集」を選択します。

(4) ルートの追加

「ルートの追加」をクリックします。

(5) 接続先のCIDRを入力

追加された行の送信側に、先ほど確認した接続先のCIDRを入力します。

(6) ターゲットの入力１

ターゲット入力欄の▼をクリックし、表示された一覧から「Peering Connection」を選択します。

(7) ターゲットの入力２

ピアリング先の一覧が表示されますので、作成したピアリング名を選択します。

(8) ターゲットの入力３

「ルートの保存」をクリックします。

(9) 確認画面

「閉じる」をクリックします。

接続先

(1) 接続先のCIDR確認

一度VPCの一覧を確認し、CIDRを確認してください。

(2) 接続先のVPCの所属するルートテーブルを選択します。

(3) ルートの編集画面へ移行

「アクション」から「ルートの編集」を選択します。

(4) ルートの追加

「ルートの追加」をクリックします。

(5) 接続先のCIDRを入力

追加された行の送信側に、先ほど確認した接続先のCIDRを入力します。

(6) ターゲットの入力１

ターゲット入力欄の▼をクリックし、表示された一覧から「Peering Connection」を選択します。

(7) ターゲットの入力２

ピアリング先の一覧が表示されますので、作成したピアリング名を選択します。

(8) ターゲットの入力３

「ルートの保存」をクリックします。

(9) 確認画面

「閉じる」をクリックします。

雑記

やり方は以上です。
この後にセキュリティグループの設定がありますが、それは各自でやってみてください。

ピアリング接続自体、非常に簡単なのですが、どうもハードルが高いと感じる方が多いようです。
ですが、新しいルートを追加するだけなので、既存環境へのサービス影響もないので、気軽にチャレンジしてみてください。

　 Tweet
Qiitaで続きを読む

投稿日：2020-01-25T20:26:28+09:00

【AWS】トライアル期間を試してみる。最初にやるべきことは何？~登録編~

目的

自分でサービスを作るのに、AWSを使えないか考えている。
とりあえずフリーで使えるなら使って作ってみよう！と思って初めてみる。
やっていることを時系列順に並べていく記録。

やるべきこととか大まかな流れは以下の記事を参考にした。

初めてのAWS (Amazon Web Service)
qiita : AWS1年目無料期間でやったこととハマったこと
 AWSアカウントを取得したら速攻でやっておくべき初期設定まとめ

細かい操作とかは、awsのドキュメントを参考にした。

IAM Best Practices

登録する

ここからフリーアカウント登録を行う。
登録後、確認メールがきたので、確認メールのリンクからコンソールを開く。

アカウント設定

ここの記述に従ってadministratorを作成。

その後、iamコンソール上の以下の項目が満たされるようにそれぞれ設定して行った。

コスト管理

Cost Budgetの設定

10minutes tutorial : Control your AWS costs に従って、コスト管理を行う。
cost budgetを作成して設定金額を超えたらアラートが発生するように。
フリートライアルなので＄0にしようとしたけどできなかったので注意。

請求情報とコスト管理の設定

通知を受け取る

Trusted Adviserの設定

Trusted Adviserページに行ったところ、自動的にチェックが開始されて以下のような画面になったので、チェックが行われていると考えられる。
アラートとか自動で来るのか、このページに行かないとチェックされないのかはわからんけど、一旦おいとこう。

あとやりたいこと

以下の設定をしている記事が多かった。
もっと勉強して、必要なら設定していきたい。

cloud trailの設定

logが確認できるらしい。

cloud watchの設定

コストに対してアラートが設定できるらしい。

料金情報をスラックに投げてくれたりする機能とかも欲しい気がする。

利用開始

iamページのuserの詳細のコンソールログインリンクから、先ほど作成したadministratorで再度ログインする。

さて、いろいろやっていこう！

　 Tweet
Qiitaで続きを読む

投稿日：2020-01-25T18:47:44+09:00

AWS EC2のインスタンス毎のデータ転送量を知る方法

EC2インスタンス毎の月々のデータ転送量を知る方法です。今まではLambdaからDynamoに書き込む仕組みを自作していたのですが、他に便利な方法を見つけたので紹介します。

コストエクスプローラー

請求書ページのコストエクスプローラーへ移動します。

グループ化の条件を指定します。詳細→タグ→Name

使用タイプグループを指定します。EC2: Data Transfer-Internet (Out)

これで下のリストに料金と転送量が表示されます。条件を保存することもできます。応用すれば他にももっとできるかもです。

まとめ

オンプレをそのままクラウドに移行させた、なんちゃってクラウドサービスを運用しています。インスタンスごとにダウンロード容量を出す必要があり苦労しました。5年前にはこんな機能がなく、ほんと便利な時代になりました。

　 Tweet
Qiitaで続きを読む

投稿日：2020-01-25T18:20:49+09:00

EC2Launchの「"setMonitorAlwaysOn": true」ってなに

事象

Windowsサーバ構築のために
EC2LaunchのConfigのデフォルト値を調べようと、AMI¹から新規インスタンスを作成したら
ドキュメントにはない項目があって、AWSサポートに問い合わせてみた。

C:\ProgramData\Amazon\EC2-Windows\Launch\Config\LaunchConfig.json
{
    "setComputerName": false,
    "setMonitorAlwaysOn": true, #これ
    "setWallpaper": true,
    "addDnsSuffixList": true,
    "extendBootVolumeSize": true,
    "handleUserData": true,
    "adminPasswordType": "Random",
    "adminPassword":  "" 
}
どうすればいい

結論から言うとそのままでOK

詳細

NitroベースのインスタンスでWindowsサーバを使用する場合、電源設定をしないとOSのシャットダウンで不具合がある模様。
※新しいAMIではデフォルトで設定されているので大丈夫

そしてSysprepを実行した際に、件の項目がtrueになっていると、この設定が自動的に行われる。²

EC2Launch バージョン履歴

1.3.2001040

・ACPI の問題を解決するためにモニターをオフにしないように設定するためのプラグインを追加しました。

これがEC2Launchのドキュメントには反映されてないので³？ってなったという話。

そもそもEC2Launchとは

知らない人の為に記載。
インスタンス初回起動時⁴に処理を行うためのスクリプト。
cloud-initのWindows版みたいなもの。

なお、Windows Server 2016 以降はEC2Launchだが、
Windows Server 2012 R2 以前だとEC2Configとなる。

ID: ami-094418f0b70398775 /Name: Windows_Server-2019-Japanese-Full-Base-2020.01.15 ↩

あえてfalseにしたら無効化されるのか、それともSysprepで変わらずにそのままなのか少し気になるが未検証 ↩

2020/01/25時点。英語のドキュメントにもない。 ↩

次回起動時に実行するコマンドがあったり、毎回実行するように設定変えれたりもする。 https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/WindowsGuide/ec2launch.html#ec2launch-config ↩

　 Tweet
Qiitaで続きを読む

投稿日：2020-01-25T18:20:49+09:00

EC2Launchの「setMonitorAlwaysOn : true」ってなに

事象

Windowsサーバ構築のために
EC2LaunchのConfigのデフォルト値を調べようと、AMI¹から新規インスタンスを作成したら
ドキュメントにない項目があって、AWSサポートに問い合わせてみた。

C:\ProgramData\Amazon\EC2-Windows\Launch\Config\LaunchConfig.json
{
    "setComputerName": false,
    "setMonitorAlwaysOn": true, #これ
    "setWallpaper": true,
    "addDnsSuffixList": true,
    "extendBootVolumeSize": true,
    "handleUserData": true,
    "adminPasswordType": "Random",
    "adminPassword":  "" 
}
どうすればいい

結論から言うとそのままでOK

詳細

NitroベースのインスタンスでWindowsサーバを使用する場合、電源設定をしないとOSのシャットダウンで不具合がある模様。
※新しいAMIではデフォルトで設定されているので大丈夫

そしてSysprepを実行した際に、件の項目がtrueになっていると、この設定が自動的に行われる。²

EC2Launch バージョン履歴

1.3.2001040

・ACPI の問題を解決するためにモニターをオフにしないように設定するためのプラグインを追加しました。

これがEC2Launchのドキュメントには反映されてないので³何？ってなったという話。

そもそもEC2Launchとは

知らない人向け。
インスタンス初回起動時⁴に処理を行うためのスクリプト。ドキュメント
 cloud-initのWindows版みたいなもの。

なお、Windows Server 2016 以降はEC2Launchだが、
Windows Server 2012 R2 以前だとEC2Configとなる。

ID: ami-094418f0b70398775 /Name: Windows_Server-2019-Japanese-Full-Base-2020.01.15 ↩

あえてfalseにしたら無効化されるのか、それともSysprepで変わらずにそのままなのか少し気になるが未検証 ↩

2020/01/25時点。英語のドキュメントにも記載がなく、まれによくある日本語ドキュメントの問題ではない ↩

次回起動時に実行するコマンドがあったり、毎回実行するように設定変えれたりもする。 https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/WindowsGuide/ec2launch.html#ec2launch-config ↩

　 Tweet
Qiitaで続きを読む

投稿日：2020-01-25T17:03:04+09:00

【AWS・Python】Slash Commandsを拡張性高く実装する

1. はじめに

本記事ではデザインパターンの一種であるChain Of Responsibilityを利用して、
SlackのSlash Commandsを拡張性高く実装する方法を紹介します。

Slash Commandsの処理を受け取るサーバーはAWSを、言語はPythonを利用します。

手軽に試せるようにコマンド3つでAWSへデプロイできるGitPod環境も用意してあります。

1.1 Slash Commands とは

Slack CommandsとはSlackに独自のコマンドを追加し、そのコマンドにより任意の処理を実行できるものです。
Slackが既に用意しているものもあり、有名なのは/remindなどでしょうか。
/remind me tomorrow 11:00 meeting
と打てば、以下のような表示ととも明日の11時にslack botからリマインドが自分宛に飛んできます。

このようなコマンドをSlash Commandsを利用することで、独自に追加実装が可能です。

Slash Commandsについての詳しい設定方法などはこちらをご覧ください。

公式ドキュメント

Developers.ioの記事

Slack Appを無料で運用する（Netlify Functions）

1.2 Chain Of Responsibility とは

Chain Of Responsibilityとは、

Chainという英単語は鎖、Responsibilityという英単語は責任、つまりChain of Responsibilityは、責任の連鎖という意味になります。実際にはたらい回しを行う構造と考えた方が分かりやすいです。

Chain of Responsibilityパターンは、複数のオブジェクトを鎖で繋いでおき、そのオブジェクトの鎖を順次渡り歩いて目的のオブジェクトを決定する方式です。

人に要求がやってくる、その人がそれを処理できるなら処理する。処理できないならその要求を「次の人」にたらい回しにする。以降繰り返し・・・。これがChain of Responsibilityパターンです。

GoFのデザインパターンでは、振る舞いに関するデザインパターンに分類されます。

です。

詳しくはデザインパターン～Chain of Responsibility～（引用元）をご覧ください。

1.3 GitPod とは

GitHubアカウントがあれば、無料から利用できるクラウドIDEです。
PCだけではなく、iPadなどからも利用可能です。
便利です。詳しくは、こちらの記事を参考にしてください。

2. 実装

2.1 できるもの

以下のようなhogeコマンドを打つと

先頭に[hoge]を付与した文字列を返してきます。

上に見えるのが、ユーザーが打った文字列（＝/hoge あああ）で、したに表示されているのが（＝[hoge]あああ）がSlash Commandsによって返される文字列です。

このような任意の処理を実行できるコマンドを、拡張性高く実装していくことができます。

2.2 手順

GitPodに環境変数を設定

AWS環境に処理をDeploy

Slash Commandsを作成し、紐付ける

完成

2.3 準備

Slash Commandsを受けるサーバーをAWSへデプロイするために必要なキーは以下の6つです。

AWS

AccessKey

SecretAccessKey

region

Slack

BotUserAuthToken

Slack Verification Token

Channel ID

2.3.1 AWSに関するキー

AccessKeyとAccessSecretKeyはIAMのユーザーから発行することができます。
また、regionは東京の場合はap-northeast-1を設定してください。

（注：間違ってもAWSのキーをGitHubのリポジトリにpushしないでください。
漏洩した場合、マイニングするためのリソース構築が勝手に行われて課金対象になってしまうことがあります。）

2.3.2 Slackに関するキー

slack apiのアプリを作成します。
そこにSlash CommandsとBotsのfeatureを追加し、以下の2つのキーを取得します。

Basis Infromation -> App Credintials -> Verification Token

OAuth & Permissions -> OAuth Tokens & Redirect URLs -> Bot User OAuth Access Token

Channel IDは、Channel Nameと異なるので注意してください。
slack apiのスラックにあるチャンネルを表示するAPI（参考）を叩いて対象のChannel IDを取得するか、2chの内容を表示させたいチャンネルからSlash Commandを実行し、AWSのCloudWatch LogsからChannel IDを取得しても良いかと思います。

2.3.3 GitPodの環境変数に設定

GitPodのEnvironemnt Variablesに6つの環境変数を以下の名前で設定してください。また、以下の環境変数はGitPod環境で自動で読み込むために、Nameを定めていますが、プログラムを書き換えれば任意のNameで実行できます。

Name Value

aws_access_key AccessKey

aws_secret_access_key SecretAccessKey

region region

slack_2ch_channel_id Channel ID

slack_oauth_access_token BotUserAuthToken

slack_token Slack Verification Token

2.4 プログラム

プログラムは、GitHubに公開してあります。

また、GitPod環境は以下から利用可能です（GitHubアカウントは必要です。）

2.5 Chain Of Responsibility の部分

親クラスであるCommandExecutorクラスのhandle_execute()にて、処理を自クラスが担うか、担わない（＝他のクラスの任せる）かを決めています。

自クラスで処理を担う場合はexecute()を実行し、担わない場合は次のクラスのhandle_execute()に処理をまかすようにしています。
class CommandExecutor:

    # ~ 中略 ~

    def handle_execute(self, params) -> dict:
        """
        入力された`params`の実行元（`command`）に拠って
        実行する処理を変更する関数

        1. 呼ばれたクラスの名前(self.name)がcommandと等しい場合、処理を行う
          * デコード処理が正しく行われた場合は、処理結果を返し、【終了】
          * 正しく行われなかった場合は、異常という処理結果を返し、【終了】

        2. 呼ばれたクラスの名前がcommandと異なる場合、次のクラスに処理を任せる : self.next.execute(params)
          * 次のクラスがある場合、処理が【続く】
          * 次のクラスがない場合、異常という処理結果を返し、【終了】

        """
        # 対象のCommandかどうか確認
        if self.check_responsibility(params):
            result_dict = self.execute(params)
            if len(result_dict) > 0:
                # メッセージの処理に成功した場合は処理結果を返す
                return result_dict
            else:
                # メッセージの処理に失敗した場合は例外を投げる
                raise ChainOfResponsibilityException

        elif self.next_executor is not None:
            # 対象のCommandでは無い場合、次のexecutorに任せる
            # [Chain of Responsibility]の部分
            return self.next_executor.handle_execute(params)
        else:
            return {"error": "Could not execute your command. Check your {/command} name"}

    def execute(self, params) -> dict:
        """
        各クラスで担うべき処理を実装する
        """
        pass
また、以下は/fugaというコマンドの処理を担うクラスです。
handle_execute()は親クラスで実装済みですので、各クラスはexecute()のみ実装すればよいです。
from chalicelib.CommandExecutor import CommandExecutor


class Fuga(CommandExecutor):
    def __init__(self):
        super().__init__("/fuga")

    def execute(self, params: dict) -> dict:
        # x-www-form-urlencodedではjsonのパラメータがリストでデコードされるため
        text = params['text'][0]
        self.logger.info(f"text:={text}")

        # slash commandから直接レスポンスを返す
        return {
            "response_type": "in_channel",
            "text": f"[fuga]{text}"
        }
また、処理の順序はCommandExecutorRequestHandlerクラスにて実装してあります。呼び出す側でこのクラスを起点に実行を開始すれば、次にHogeの処理が、最後にFugaの処理が実行されます。
class CommandExecutorRequestHandler(CommandExecutor):
    """
    最初にメッセージを受け取り、処理を開始するクラス
    このRequestHandlerではメッセージの受け取りを担うのみで
    実際の処理を行うのはset_next()内に含まれるインスタンスが処理を行う
    """
    def __init__(self):
        """
        self.set_next({instance}).set_next({instance})
        のように数珠繋ぎに関数をつなげる
        """
        super().__init__("RequestHandler")
        # commandに拠って出力する内容を切り替える
        self.set_next(Hoge()).set_next(Fuga())
2.6 拡張方法

GitHubに載せてあるプログラムでは、以下のコマンドを受けれるようにしてあります。

/Hoge

/Fuga

例えば、ここに/Piyoコマンドを実装したい場合はどうすればよいのでしょうか？
やることは以下の3つです。

CommandExecutorクラスを継承した新たにPiyoクラスを作成する

Piyoクラスにexecute()を実装する

CommandExecutorRequestHandlerクラスの__init__()に.set_next(Piyo())を加える

他のコマンドも同様の手順で新たなコマンドを加えることができます。

2.7 実行環境（再掲）

また、GitPod環境はこちらから利用可能です（GitHubアカウントは必要です。）

3. おわりに

Slack APIやAWSのアクセスキーの準備などがすこし手間ですが、
そこが終われば、誰でも簡単にSlash Commandsを実装することができます！！

よいSlackライフを！！

A. おまけ

12月の初旬にバズったこちらの記事の/2chコマンドも簡単に実装することができます。
（GitHubのソースコードに既に一部が実装されており、デプロイと同時に利用可能です。これであなたのslackにも2ch環境が！！）

Name	Value
`aws_access_key`	`AccessKey`
`aws_secret_access_key`	`SecretAccessKey`
`region`	`region`
`slack_2ch_channel_id`	`Channel ID`
`slack_oauth_access_token`	`BotUserAuthToken`
`slack_token`	`Slack Verification Token`

　 Tweet
Qiitaで続きを読む

投稿日：2020-01-25T16:21:01+09:00

本番環境でbackground-imageが反映されない

プログラミング初心者の備忘録です。
ご注意ください。

background-imageが本番環境で反映されない

ローカルでは background-image: url(******.jpg)　と記述して反映されているが、本番環境では読み込まれない。
******.css
background-image: url(******.jpg);
対処法

background-image: image-url("******.jpg")と記述する
*******.css
background-image: image-url("******.jpg");

　 Tweet
Qiitaで続きを読む

投稿日：2020-01-25T14:49:40+09:00

(コマンド化)AWS CLIにおけるMFA認証

概要

AWSマネジメントコンソールにアクセスするためのIAMユーザーにMFAを設定している場合、
同ユーザーにてAWS CLIを使う時にもMFAによる認証が必要になるけど、
すぐに忘れちゃうのでコマンド化した。

ざっくりセットアップ手順

アクセスキーの作成（まだやってない人は）
.bashrcに以下追記
ログインし直す or source ~/.bashrc

.bashrc


function AWSCLIINIT() {
    unset AWS_ACCESS_KEY_ID
    unset AWS_SECRET_ACCESS_KEY
    unset AWS_SESSION_TOKEN
    aws configure

    mfa_arn=`aws sts get-caller-identity --query 'Arn' --output text 2>/dev/null | sed -e "s/:user\//:mfa\//g"`
    if [ -n "$mfa_arn" ]
    then
        echo "YourMFA :"$mfa_arn
        echo -n INPUT YourMFA-Code :
        read mfa_code

        get_session_token=`aws sts get-session-token --output text --serial-number $mfa_arn --token-code $mfa_code 2>/dev/null`

        if [ -n "$get_session_token" ]
        then
            set -- $get_session_token
            export AWS_ACCESS_KEY_ID=$2
            export AWS_SECRET_ACCESS_KEY=$4
            export AWS_SESSION_TOKEN=$5
        else
            echo "MFA ERROR"
        fi

    else
        echo "aws configure is wrong"
    fi
}

使い方

AWSCLIINIT

中でaws configureをやってるので必要に応じて入力
mfaを聞かれるので入力

$ AWSCLIINIT 
AWS Access Key ID [********************]: 
AWS Secret Access Key [********************]: 
Default region name [ap-northeast-1]: 
Default output format [json]: 
YourMFA :arn:aws:iam::123456789012:mfa/abcdefg
INPUT YourMFA-Code :123456
$

エラーがでなければ認証成功。環境変数にトークンなどがセットされます。

こんな感じ。

MFA認証前

$ aws iam get-user

An error occurred (AccessDenied) when calling the GetUser operation: User: arn:aws:iam::123456789012:user/abcdefg is not authorized to perform: iam:GetUser on resource: user abcdefg with an explicit deny

本コマンド利用時

$ aws iam get-user
{
    "User": {
        "UserName": "abcdefg", 
        "PasswordLastUsed": "2020-01-25T01:16:10Z", 
        "CreateDate": "2019-12-10T02:55:57Z", 
        "UserId": "AAAAAAAAAAAAAAAAAA", 
        "Path": "/", 
        "Arn": "arn:aws:iam::123456789012:user/abcdefg"
    }
}

　 Tweet
Qiitaで続きを読む

投稿日：2020-01-25T14:49:33+09:00

EC2 でアクセスキーを設定することなく、ロールにより実現する方法

EC2 から s3 バケットを操作したいです。
例えば、バケットを新規作成してみます。
$ aws s3 mb s3://<バケット名>
make_bucket failed: s3://<バケット名> Unable to locate credentials
ここで、aws configure コマンドを実行して credentials を設定するかと思います。
しかしながら、.aws/config に記録されてしまい、セキュリティ的によろしくないです。

以下を実行します。
要すれば、Access Key を設定しないことが大事です。
$ aws configure
AWS Access Key ID [None]: <そのまま Enter>
AWS Secret Access Key [None]: <そのまま Enter>
Default region name [None]: ap-northeast-1
Default output format [None]: <そのまま Enter>
ファイルの中身を確認します。
$ less ./aws/config
[default]
region = ap-northeast-1
アクセスキーの記述はありません。

ここで、ロールを作成して、EC2 にアタッチします。
「IAM」-「ロール」-「ロールの作成」-「このロールを使用するサービスを選択」-「EC2」-「次のステップ:アクセス権限」-「ポリシーのフィルタ」- 「検索窓に s3 と入力」-「AmazonS3FullAccess にレ点を入れる」-「ポリシーの作成」
（細部省略）
要すれば、S3FullAccess（一例）という名前でロールを作成します。

では、作成したロールを EC2 インスタンスにアタッチします。

EC2 でインスタンスを選択し、以下を確認します。
IAMロール（空白）

設定
「アクション」-「インスタンスの設定」-「IAMロールの割り当て/置換」-「IAMロール」ー「作成したロール（S3FullAccess）を選択し適用」

試しに、ロールをアタッチしたインスタンスで以下を実行して、バケットを作成してみる。
$ aws s3 mb s3://<バケット名>
make_bucket: <バケット名>
成功しました。

（参考）
https://aws.amazon.com/jp/blogs/news/easily-replace-or-attach-an-iam-role-to-an-existing-ec2-instance-by-using-the-ec2-console/

　 Tweet
Qiitaで続きを読む

投稿日：2020-01-25T14:49:33+09:00

EC2 でアクセスキーを設定することなく、ロールによりコマンドを実現する方法

EC2 から s3 バケットを操作したいです。
例えば、バケットを新規作成してみます。
$ aws s3 mb s3://<バケット名>
make_bucket failed: s3://<バケット名> Unable to locate credentials
ここで、aws configure コマンドを実行して credentials を設定するかと思います。
しかしながら、.aws/config に記録されてしまい、セキュリティ的によろしくないです。

以下を実行します。
要すれば、Access Key を設定しないことが大事です。
$ aws configure
AWS Access Key ID [None]: <そのまま Enter>
AWS Secret Access Key [None]: <そのまま Enter>
Default region name [None]: ap-northeast-1
Default output format [None]: <そのまま Enter>
ファイルの中身を確認します。
$ less ./aws/config
[default]
region = ap-northeast-1
アクセスキーの記述はありません。

ここで、ロールを作成して、EC2 にアタッチします。
「IAM」-「ロール」-「ロールの作成」-「このロールを使用するサービスを選択」-「EC2」-「次のステップ:アクセス権限」-「ポリシーのフィルタ」- 「検索窓に s3 と入力」-「AmazonS3FullAccess にレ点を入れる」-「ポリシーの作成」
（細部省略）
要すれば、S3FullAccess（一例）という名前でロールを作成します。

では、作成したロールを EC2 インスタンスにアタッチします。

EC2 でインスタンスを選択し、以下を確認します。
IAMロール（空白）

設定
「アクション」-「インスタンスの設定」-「IAMロールの割り当て/置換」-「IAMロール」ー「作成したロール（S3FullAccess）を選択し適用」

試しに、ロールをアタッチしたインスタンスで以下を実行して、バケットを作成してみます。
$ aws s3 mb s3://<バケット名>
make_bucket: <バケット名>
成功しました。

（参考）
https://aws.amazon.com/jp/blogs/news/easily-replace-or-attach-an-iam-role-to-an-existing-ec2-instance-by-using-the-ec2-console/

　 Tweet
Qiitaで続きを読む

投稿日：2020-01-25T14:29:11+09:00

AWS lightsailで構築したWordPressの管理画面にログインできなくなった時の対応方法

はじめに

AWS lightsailでWordPressを構築したのですが、プラグインをインストールすると重大なエラーが発生して管理画面にログインできなくなり、しかもなぜかリカバリーモードのURLが管理者メールアドレスに届かない、というトラブルに見舞われた為、対応方法をメモしておきます。

対応方法

1.FTPツールを使ってWordPressのファイルディレクトリにアクセスする
2.復旧に必要な処理をする

たぶん、これが一番簡単です。

私の場合はプラグインのインストールが原因だったので、FTPツールを使ってファイルディレクトリにアクセスし、プラグインを一旦すべて無効化しました。

1.FTPツールを使ってWordPressのファイルディレクトリにアクセスする

ネットで調べると、さくらインターネットやロリポップなどのレンタルサーバーだと、そもそも管理画面からWordPressのファイルディレクトリにアクセスできるよう。

何やそれ、AWSはできへんで！ってところから僕は迷いました。

まずはFTPツールの準備からです。

FTPツールは何でも良いのですが、僕は以前使用したことのあるFile Zillaを使いました。

Mac用
https://filezilla-project.org/download.php?platform=osx

Windows用
https://filezilla-project.org/download.php?platform=win64

FTPツールをインストールしたら早速接続したいところですが、その前にSSHを使用して接続するためのキーペアの準備が必要です。

lightsailインスタンスの「接続」タブにアクセスし、画面下のアカウントページをクリックします。

SSHキーの管理画面に飛びますので、ダウンロードを押します。

これでSSHでの接続に必要なキーペアがローカル環境に保存されました。

それでは次にFTPツールを起動します。

メニューからサイトマネージャーを開きます。

「新しいサイト」をクリックします。

「プロトコル」で[SFTP - SSH File Transfer Protocol]を選択します。

「ホスト」にサイトのパブリックIPアドレスを入力します。

「ログオンの種類」で[鍵ファイル]を選択します。

「ユーザー」はbitnamiと入力します。

「キーファイル」で先程ローカル環境にダウンロードしたキーペアを選択します。

最後に「接続」を押すと無事にWordPressのファイルディレクトリにアクセスできます！

「wp-config.php」などの重要なファイルは/opt/bitnami/apps/wordpress/htdocs/wordpress/htdocsにあります。

2.復旧に必要な処理をする

ここから先は自分が何をしたいかによって処理が変わってきます。僕の場合はインストール時にエラーを引き起こしたプラグインの無効化でした。

お手軽な方法はプラグインのフォルダ名を一時的に変更して、サイトからのリンクを強制的に断ち切ることです。

通常は「plugins」というフォルダが「wp-content」の中にあります。

このフォルダ名を、たとえば「plugins_hold」など適当な暫定名称に変更します。

これで愛し懐かしき我がブログの管理画面に舞い戻ることができます。

あとはプラグインの管理画面からインストールできていないプラグインの削除なりをして、エラー原因を取り除きます。

そして、「plugins_hold」と変更したフォルダ名を忘れずに「plugins」に戻して完了。

とりあえず、これで復旧できます！

　 Tweet
Qiitaで続きを読む

投稿日：2020-01-25T14:21:06+09:00

EC2上のWindows ServerへMacbookからログインする方法

目的

MacbookからEC2インスタンス（WindowsServer 2016）へMacbookからログインする方法について纏めます。以下にてサーバ側（ECS2インスタンス側）とクライアント側（Macbook側）で分けて具体的な手順を解説していきます。

サーバー側手順

プライベートキーの検索

Amazon EC2コンソール画面からEC2インスタンスを右クリックし、Windowsパスワードの選択をクリックする。

そのインスタンスに紐づいているpemファイルの情報をcopy and pasteすると、以下画面のように接続情報が表示されます。

クライアント側手順

Microsoft Remote Desktop（Version 10）から接続

Microsoft Remote Desktopをインストールし、サーバ側で確認した情報を入力します。

接続確認

以下のようにWindows Serverへログインすることができました。

　 Tweet
Qiitaで続きを読む

投稿日：2020-01-25T14:18:26+09:00

SQSメッセージ数に応じてSpotFleetでインスタンスをAutoScalingする。

SQSメッセージの数に応じてスポットインスタンス数を調整したい。

SQSの作成

SQSキューの作成
$ aws sqs create-queue --queue-name YOUR_QUEUE_NAME
{
    "QueueUrl": "https://ap-northeast-1.queue.amazonaws.com/xxxxxxxxxxxx/YOUR_QUEUE_NAME"
}
CloudWatchAlarmの設定

CloudWatchコンソールからApproximateNumberOfMessagesVisibleメトリクスを選択。
アラームの閾値は0以上として設定し、メトリクス名をつけて作成。（YOUR_METRICS_NAMEとする。）

※ アラームの閾値はいくつで設定しても良いが、ここで設定した数値以下の値をAutoScalingのスケーリングポリシーで取得することはできない。

SpotFleetの設定

リクエストの作成

EC2コンソールのナビゲーションペインから「スポットリクエスト」を選択し、[スポットインスタンスのリクエスト]を選択。

追加設定から「EBS最適化インスタンスを起動」や「インスタンスストアのアタッチ」が選択できる。
セキュリティグループやIAMインスタンスプロフィールを適当に設定する。

作成後、タブから「AutoScaling」を選択。

スケーリングポリシーを設定

ポリシートリガーにYOUR_METRICS_NAMEを指定し。
容量の変更から、段階的なインスタンス数を選択。
ここでYOUR_METRICS_NAMEに指定するキューメッセージするに基づくスケーリングのルールを指定できる。

(Option)インスタンスの終了2分前イベントを受け取る

CloudWatchEventsから以下を設定する。

イベントソースの設定
イベントパターンを選択し、サービス名EC2、イベントタイプEC2 Spot Instance Interrupt Warningを指定する。

ターゲットの設定
ここで、イベント取得時に起動したいlambdaやSNSを指定する。

なお、イベント発生時に受け取ることができるメッセージは以下。
{
  "version": "0",
  "id": "12345678-1234-1234-1234-123456789012",
  "detail-type": "EC2 Spot Instance Interruption Warning",
  "source": "aws.ec2",
  "account": "xxxxxxxxxxxx",
  "time": "yyyy-mm-ddThh:mm:ssZ",
  "region": "ap-northeast-1",
  "resources": [
    "arn:aws:ec2:ap-northeast-1:xxxxxxxxxxxx:instance/i-1234567890abcdef0"
  ],
  "detail": {
    "instance-id": "i-1234567890abcdef0",
    "instance-action": "action"
  }
}
終了予定のインスタンスはdetail内のinstance-id。

テスト

AutoScalingのテスト

SQSキューにメッセージをエンキューする。
$ aws sqs send-message --queue-url https://sqs.ap-northeast-1.amazonaws.com/xxxxxxxxxxxx/YOUR_QUEUE_NAME --message-body "testMessage"
CloudWatchAlarmからApproximateNumberOfMessagesVisibleメトリクスを確認する。
しばらくしてEC2コンソールからスポットインスタンスの数を確認。適切にスケールしていれば成功。

(Option)通知のテスト

キューを取得・削除する。
$ aws sqs receive-message --queue-url https://sqs.ap-northeast-1.amazonaws.com/xxxxxxxxxxxx/YOUR_QUEUE_NAME

$ aws sqs delete-message --queue-url https://sqs.ap-northeast-1.amazonaws.com/xxxxxxxxxxxx/YOUR_QUEUE_NAME --receipt-handle "上記返り値のReceiptHandle"
数分後、メトリクスの値が変わり、インスタンスがスケールインする2分前にイベントが発生。ターゲットに指定したlambdaやSNSや発火する。

同時に2つのインスタンスが2分前イベントを発生させた場合でも2通のイベントを取得できることは確認済。

　 Tweet
Qiitaで続きを読む

投稿日：2020-01-25T14:10:24+09:00

Node.jsでAWS ElasticSearchへのHTTP リクエストの署名

はじめに

情報保護を難しくなっている現代社会では、セキュリティ対応はますます重要になってきています。
Cloud技術の進化によって、セキュリティ対応しやすくなる部分もあります。

AWSのElasticeSearchサービスへのHTTP リクエストの署名方法を簡単にまとめてみます。

1. AWS SDKのライブラリを使う

AWSのドキュメントにある通り、署名したリクエストを送信できますが、検索のクエリなどはちょっと手間ですね。

参考URL:　https://docs.aws.amazon.com/ja_jp/elasticsearch-service/latest/developerguide/es-request-signing.html
node.js
var credentials = new AWS.EnvironmentCredentials('AWS');
  var signer = new AWS.Signers.V4(request, 'es');
  signer.addAuthorization(credentials, new Date());

  var client = new AWS.HttpClient();
  client.handleRequest(request, null, function(response) {
    // ....
  }
2. aws-elasticsearch-connectorモジュールを使う

Node.jsからElasticSearchへアクセスするには、ElasticSearchクライアントを使うと検索などに便利です。
aws-elasticsearch-connectorを利用して署名も簡単にできます。

2.1 aws-elasticsearch-connectorインストール

npm install --save aws-elasticsearch-connector @elastic/elasticsearch aws-sdk

2.2 profile利用例
node.js
const AWS = require('aws-sdk');
const { Client } = require('@elastic/elasticsearch');
const { AmazonConnection } = require('aws-elasticsearch-connector');

// Load AWS profile credentials
AWS.config.update({
  profile: 'my-profile'
});


const client = new Client({
  node: 'my-elasticsearch-cluster.us-east-1.es.amazonaws.com',
  Connection: AmazonConnection
});
2.3 .envにアクセスキー、シークレットキー利用例
AWS_ACCESS_KEY_ID=foo      # alias: AWS_ACCESS_KEY
AWS_SECRET_ACCESS_KEY=bar  # alias: AWS_SECRET_KEY
AWS_SESSION_TOKEN=xxx  //optional
node.js
const { Client } = require('@elastic/elasticsearch');
const { AmazonConnection } = require('aws-elasticsearch-connector');

const client = new Client({
  node: 'my-elasticsearch-cluster.us-east-1.es.amazonaws.com',
  Connection: AmazonConnection,
});
参考URL：https://github.com/compwright/aws-elasticsearch-connector#readme

2.4 検索結果
node.js
let searchResult = await client.search({
    index: 'xxx_index',
    body: {
      //...
    });

// ヒットしたデータ
let hits = searchResult.body.hits.hits;
// ヒットしたデータ数
let hitsCount = searchResult.body.hits.total;
ElasticSearchのクライアントAPI：
https://www.elastic.co/guide/en/elasticsearch/client/javascript-api/current/client-usage.html

以上

　 Tweet
Qiitaで続きを読む

投稿日：2020-01-25T13:36:39+09:00

AWSからECインスタンスProxy経由でデータセンター側サーバへ接続するTips

概要

AWSパブリックインスタンスからSandboxをProxyにして、データセンター側サーバにSSHする

設定：SSG（ファイアウォール）

SSGのGlobal Policy へ、対象AWSインスタンスのGlobal IP許可するように設定追加する

設定：Sandbox

GlobalIP 115.30.28.159
LocalIP 172.18.4.127

下記にAWSインスタンスの公開鍵データを追記
[root] .ssh/authorized_key

設定：データセンター側のサーバ

例：172.18.8.149

下記にAWSインスタンスの公開鍵データを追記
[root] .ssh/authorized_key

確認：AWSインスタンス

例：service-web01

.ssh/config を修正

Snadbox経由で通信可能となるように設定する
ServerAliveInterval 60
Host 172.18.8.149
     ProxyCommand ssh 115.30.28.159 nc %h %p
通信確認

Sandbox、対象のデータセンターサーバへのSSH可能なことを確認する。
[root@service-web01 ~]# ssh 172.18.4.127
■参照
http://qiita.com/ik-fib/items/12e4fab4478e360a82a1

　 Tweet
Qiitaで続きを読む

投稿日：2020-01-25T13:35:21+09:00

CloudFormationでパラメータストアから値を動的参照する際にハマったところ

背景

作成中のCFnのスタックをいくつかのVPC上で実行したいので
vpc-idやその他のパラメータはベタ書きせずに外部から参照するかたちにしました。

CFnでは動的な参照を使用してテンプレート値を指定する機能を利用して
SSMのパラメータストアやSecrets Managerから値を参照することができます。
参照パターン
# '{{resolve:ssm:parameter-name:version}}'
'{{resolve:ssm:vpc-id:1}}'
問題

SSMパラメータストアにパラメータを設定した上で
テンプレート名のパラメータセクションでこのように書きました。
CFnテンプレート
VpcId:
  Type: AWS::EC2::VPC::Id
  Default: '{{resolve:ssm:vpc-id:1}}'
このテンプレートからスタックを作成するとエラーになります。
イベント内に出力されるエラー
Parameter validation failed: parameter value {{resolve:ssm:vpc-id:1}} for parameter name VpcId does not exist. Rollback requested by user.
存在しない…とはいえCLIからパラメータストアを参照すると普通に見えます。
CLIからパラメータストアを参照
aws ssm get-parameter --name=vpc-id
{
    "Parameter": {
        "Name": "vpc-id",
        "Value": "vpc-a1b2c3d4",
        "Version": 1,
        "Type": "String"
    }
}
解決

テンプレートの Type を書き換えると参照できました。
CFnテンプレート
VpcId:
  Type: String
  Default: '{{resolve:ssm:vpc-id:1}}'
AWS 固有のパラメーター型を使えば
入力値の検証やサジェストの面でメリットがありますが
現状はここに動的参照の値を直接置くことはできないようです。

厳密な原因が見つかっていないためまだなんとも言えませんが
does not exist. に惑わされないようにしましょう。

　 Tweet
Qiitaで続きを読む

投稿日：2020-01-25T11:52:13+09:00

M5Stack + UiFlow + AWS でグラフ化 & 異常通知

M5Stack + UiFlow + AWS でグラフ化 & 異常通知

2020-01-25
JAWS-UG金沢 #49 × Marutsu Maker Starter #70 AWS×M5StackでIoTをはじめよう
JAWS-UG金沢 PhalanXware ふぁらお加藤

AWS とは

クラウド業界トップシェア。IoTとの連携方法もたくさんあるのでぜひ使いましょう。

全体的な設計

やりたいこと

温度を測定して送信。グラフで確認できる。しきい値を超えたら自動でメール通知くるようにする。

AWS IoTを使いたいんだけれど

　AWS IoTへはMQTTやHTTPでデータをやりとりするんですが、今日のUiFlowを使うと、メモリが足りないのか？認証をM5Stackに組み込む難易度が高い。(UiFlowを使わない方法ならできる)
　今日はせっかくUIFlowを使うので、そこから呼び出せるものを作る。

流れ

センサー > M5Stack > AWS > メール > 俺たち

M5Stackでまず温度を毎秒とるようにしてみる

Aに環境センサーをとりつけて温度を表示できることを確認します。

まず、温度センサーをAポートにとりつける

flow.m5stack.com をブラウザで表示、m5stackを接続

「Units」から「+」を選択して「ENV」を追加

labelを4つ配置(1つは後から使います

図のようにブロックを組んで実行

ここまでできたら、この温度をAWSに送信し、一定値を超えたらメールがくるようにする

流れ
センサー > M5Stack > AWS > メール > 俺たち

AWS部分の流れさらに詳細
CloudFront > AWS API Gateway > Lambda > CloudWatch > SNS > スマホへ

CloudWatchにデータを送るLambdaの作成

Lambda

関数の作成

イチから作成

関数名に m5stack-temp

ランタイムは Python 3.8

「基本的なLambdaアクセス権限で新しいロールを作成」

「関数の作成」を実行 ## コード
    import boto3
    import json
    import datetime

    print('Loading function')
    cloudwatch = boto3.client('cloudwatch')

    def lambda_handler(event, context):
        PutMetricData = cloudwatch.put_metric_data(
            Namespace='M5STACK',
            MetricData=[
                {
                    'MetricName': 'fromM5Stack-temp',
                    'Timestamp': datetime.datetime.utcnow(),
                    'Value': float(event['body']),
                    'Unit': "None"
                },
            ]
        )
        PutMetricData
ロールの設定

コードから下にスクロールすると「実行ロール」があり、ここから「IAMコンソールでxxxxロールを表示します」リンクをクリックして移動。

ポリシー名のリンクをクリック

「ポリシーの編集」をクリックし、「JSON」タブをクリック。

最後のEffectを追加して、cloudwatch:PutMetricData権限を設定する。

「ポリシーの確認」をクリックして「CloudWatch 制限:書き込み」「CloudWatch Logs 制限: 書き込み」を確認して「変更の保存」実行。
    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Action": "logs:CreateLogGroup",
                "Resource": "arn:aws:logs:ap-northeast-1:999999999999:*"
            },
            {
                "Effect": "Allow",
                "Action": [
                    "logs:CreateLogStream",
                    "logs:PutLogEvents"
                ],
                "Resource": [
                    "arn:aws:logs:ap-northeast-1:999999999999:log-group:/aws/lambda/m5stackTest:*"
                ]
            },
            {
                "Effect": "Allow",
                "Action": [
                    "cloudwatch:PutMetricData"
                ],
                "Resource": "*",
                "Condition": {
                    "Bool": {
                        "aws:SecureTransport": "true"
                    }
                }
            }
        ]
    }
Lambdaを呼び出すAPI Gatewayの作成

「APIを作成」

「REST API」を選んで「構築」

REST

新しいAPI

「API名」に m5stack-api

「エンドポイントタイプ」は「エッジ最適化」

「APIの作成」を実行

「リソース」右の「アクション」からドロップダウンして「メソッドの作成」

表示されたドロップダウンから「POST」を選択して、✓をクリック

「統合タイプ」を「Lambda関数」選択

Lambda関数に m5stack-temp を指定

関数名クリックで関数ページに飛ぶことを確認

テストしてみる。

テスト⚡をクリック

リクエスト本文を {"body": 30.0} と指定。最後がこんな感じのログがでてれば成功。
    Fri Jan 24 14:54:41 UTC 2020 : Successfully completed execution
    Fri Jan 24 14:54:41 UTC 2020 : Method completed with status: 200
Lambdaで保存されたデータをCloudWatchをみてみる

左から「メトリクス」を選ぶ

「すべてのメトリクス」タブ、「カスタム名前空間」から「M5STACK」を選択

「ディメンションなしのメトリクス」

fromM5Stack-temp のチェックを入れるとグラフが表示され、30℃があれば成功。

API Gatewayをhttpで呼び出せるようにCloudFrontを準備する

https://〜をUIFlowから呼び出すと、メモリが足りない？エラーになってしまうので避ける。(超上級編ではC++を使って接続できている）

API Gateway デプロイする

「リソース」右の「アクション」ドロップダウンから「APIのデプロイ」を選択

「デプロイされるステージ」に「[新しいステージ]」を選択

ステージ名を「v1」に

説明は空欄で「デプロイ」を実行

v1 ステージエディター画面にて「URLの呼び出し https://〜/v1」とあるので、これをメモしておく

CloudFrontを経由するように設定する

「Create Distribution」をクリック

Web の「Get Started」をクリック

「Origin Domain Name」にメモした〜の部分 (例: 4g65v9xnXX.execute-api.ap-northeast-1.amazonaws.com )を入力

「Origin Path」に「v1」

「Origin Protocol Policy」を「HTTPS Only」を選択

「Default Cache Behavior Settings」の「Allowed HTTP Methods」を「GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE」を選択

「Query String Forwarding and Caching」を「Forward all, cache based on all」を選択

「Create Distribution」を実行

Status が Deployed になることを待つ

IDをクリックして「Domain Name」の欄をメモする

(curl が使えるのならば curl -v -d "{\"body\":1024}" http://メモしたURL.cloudfront.net/ を試す。（CloudWatchで↑と同じ方法で確認できる。今回は値1024がきてる。

定期的に温度を送るようにUiFlowを書く

URLには↑でメモした 〜cloudfront.net のURLを指定すること。

CloudWatchでグラフを確認する

　success!!とラベルがで出続けていれば、送信するのに成功しているので、CloudWatchのグラフ画面を再描画させるなどしたらグラフが確認できる。

Amazon SNSを設定する

SNSを開く

「m5stack-notif」と入力して「次のステップ」を実行

「トピックの作成」を実行

「サブスクリプションの作成」を実行

「プロトコル」をEメール

「エンドポイント」を自分のメールアドレスにする

「サブスクリプションの作成」を実行

確認のための電子メールがくるのを確認

メールを開いて「Confirm subscription」リンクを開く

「Subscription confirmed!」と表示されればOK

SNSを開き、左から「トピック」を選び「m5stack-notif」を選択

サブスクリプションのところに「確認済み」となっていればOK # アラームを設定する

CloudWatchを開く

左のメニューからアラームを選択

「アラームの作成」を実行

「メトリクスの選択」を実行

「カスタム名前空間」の「M5STACK」を選択する

「ディメンションなしのメトリクス」

「fromM5Stack-temp」にチェックして「メトリクスの選択」

「統計」を「最大」にし、「期間」を「1分」に

「しきい値の種類」を「静的」にし、「より大きい」を選択、「... よりも」に30を設定して「次へ」

「SNSトピックの選択」で「既存のSNSトピックを選択」し、「通知の送信先」で先程作成した「m5stack-notif」を選択して「次へ」

一意の名前を定義で「m5stack-alerm」として「次へ」

「アラームの作成」を実行

通知をださせてみる！

M5Stackのセンサーをホッカイロで包んで温度を上げてみる！

しきい値を超えたら「ALARM: "m5stack-alerm" in Asia Pacific (Tokyo)」っていうタイトルのメールが送られてくることを確認

リソースを削除しよう

削除に時間がかかるので注意！

CloudFront を開いて対象のDistributionsを選択して > Disable > In Progress

削除に時間がかかるんで他のを並行してやってください

API Gateway を開いて「m5stack-api」を選択して > 右上のActions > Delete

Lambda を開いて「m5stack-temp」を選択して > 右上のアクション > 削除

CloudWatch を開いて「アラーム」を選択して > 「m5stack-alerm」にチェック > 右上のアクション > 削除

SNSを開いて「トピック」を選択して > 「m5stack-nofif」にチェック > 上段の「削除」

CloudFront を開いて対象のDistributionsを選択して > Delete

おつかれさまでした

　 Tweet
Qiitaで続きを読む

投稿日：2020-01-25T09:45:32+09:00

LakeFormation Tips

案件でLakeFormationを使うようになりましたので、LakeFormation関連のTipsを紹介していきたいと思います。
随時更新予定です。

1. 別リージョンのバケットにテーブルデータを保存しているテーブルはLakeFormationで権限制御できない

例えば、GlueのデータカタログやLakeFormationは東京リージョンを利用しているが、一部のテーブルのデータはオレゴンリージョンのバケットに
保存されている場合、この一部のテーブルに対してLakeFormationで権限制御することができません。
これはLakeFormationと別リージョンのバケットはDataLakeLocationsに登録できないためだと思われます。
LakeFormationでテーブルの権限等を管理する場合、テーブルデータが存在するS3パスをDataLakeLocationsに登録する必要があります。
ただ、別リージョンのバケットはDataLakeとして登録できないため、別リージョンのバケットにデータを持つテーブルはLakeFormationの管轄外となってしまい、その恩恵を受けれられないようです。

現時点でこのような状況になった場合の影響としては以下の点が確認できました。

LakeFomationコンソール上で別リージョンバケットにデータを持つテーブルはテーブル一覧に表示されません。

Glueコンソール上で一覧を取得した場合のみテーブルが確認できます。

LakeFormationの権限設定を付与できません。

該当テーブルにアクセスする際の権限判定はIAMポリシーのみで判定します。（LakeFormationローンチ以前と同様にGlueのAPI権限があればアクセス可能）

そのため、当たり前のことではあるかもしれませんが、LakeFormationを利用する場合、テーブルデータ等も同一リージョンで管理するようにしましょう。

2. 「Use only IAM access contro」設定はDB単位でも設定されている

LakeFormationは初期状態の場合、ローンチ前の状態と互換性を保つように設定されています。つまりデフォルトで全IAMが全データカタログに対するLakeFormationの権限が付与された状態（＝ IAMポリシーのみで制御されている状態）になっています。
そのため、LakeFormationの権限制御を利用したい場合、まずはこの互換性の設定を外す必要があります。

まずはLakeFormationコンソールの「Setting」画面から「Default permissions for newly created databases and tables」の項目にあるすべてのチェックボックスのチェックを外した状態にします。
この状態にすることで、今後作成されるDBやテーブルには互換性維持用の権限は付与されず、基本的にDB、テーブルを作成したIAMに対してのみアクセスできる（LakeFormationの権限制御が有効になっている）状態になります。

ただ、注意点としては、見出しにある通り、各DBに対しても「Use only IAM access contro」の設定つまり、互換性維持用の設定項目があります。
LakeFormationローンチ前にすでに作成されたDBにはこの設定が有効になっていると思うので、LakeFormationの権限制御を利用する場合、
このちらの設定も無効にする必要があります。

　 Tweet
Qiitaで続きを読む

投稿日：2020-01-25T08:45:29+09:00

【ブログ枠】JAWS-UGコンテナ支部 #16〜EKS on Fargateローンチ記念！EKS祭りだワッショイ#1

はじめに

2020年1月23日に開催されたJAWS-UGコンテナ支部 #16〜EKS on Fargateローンチ記念！EKS祭りだワッショイのブログ枠になります。

当日使用されたハッシュタグは#jawsug_ctと#jawsugです。Twitterで検索すれば開催当時の空気感が見れると思います。また、話題に上がった補足資料的なURLが貼られたりしているのでさらっと眺めておくことをお勧めします。

メインセッションまでを#1、書く余力があったらLT部分を#2で書ければと思ってます…

セッション情報まとめ

タイトル登壇者情報

今こそ振り返るEKSの基礎濱田孝治
クラスメソッド
AWS事業本部コンサルティング部

コンテナうまみつらみ〜Kubernetes初心者がEKSと格闘した1年を振り返る〜多田吉克
（株）いい生活
サービスプラットフォーム開発部

Kubernetesをめぐる冒険坂本諒
Chatwork

OSSから理解するEKSとそのエコシステムについて太田航平(inductor)
ZOZOテクノロジーズ
MLOpsチームエンジニア

EKS on Fargate を紹介したいミラクル⭐トリバード

EKSでのpodとIAM Roleの管理方法を整理ジュジュ

Kubernetes における Topology（仮）チェシャ猫

インフラ未経験からCKADに合格するまでの道のり Masatoshi Tada

EKS for EFS nnao45

※ミラクル⭐トリバードことトリさんの登壇資料は探しましたが見つけられなかったので未掲載です。

メインセッション

 今こそ振り返るEKSの基礎

登壇者はDevlopers.ioのワッショイでお馴染みのクラスメソッド株式会社の濱田孝治さん

ekstclは便利

eksctl create clusterコマンドで色んなAWSリソースをよしなに作ってくれる

eksctlはすごく便利だけど、これだけ使っているとAWSのリソースに対する理解が深まらない

EKS運用していくと当然色々やりたいこと増えたり課題が出てくる

改めてEKS何もわかってないなと感じる

EKSと長く付き合うにはeksctlをちゃんと理解する必要がある

EKSの使い方は2つ

eksctlを使う方方法

AWSコンソールを使う方法

AWSコンソールでのEKSの開始方法

Amazon EKSサービスロール作成

EKSクラスター用VPC作成

EKSクラスターの作成

kubeconfigの作成

マネージド型ノードグループの起動

Amazon EKSサービスロール作成

Amazon EKS はユーザーに代わって他の AWS サービスを呼び出してサービスで使用するリソースを管理します。Amazon EKS クラスターを使用するには、次の IAM ポリシーを持つ IAM ロールを作成する必要があります。

必須ポリシー2種の違い

AmazonEKSServicePolicy AmazonEKSClusterPolicy

EKSがk8sクラスタを作成〜運用するためのポリシー k8sクラスタのコントロールプレーンがAWSリソースを操作するためのポリシー

EKSクラスター用VPC作成

EKSクラスタ作成前にクラスタで使用するVPCを作成する必要あり

クラスタVPCに関する考慮事項※資料ではSGに関する考慮事項のURLが貼られていたので注意

2つ以上のAZにサブネットが必要

パブリックサブネット(インターネット用LB)

プライベートサブネット(ワーカーノード用)

プライベートサブネットからインターネットへのアウトバウンド通信には要NATGateway

VPC IP アドレス指定

VPC のタグ付け要件

サブネットのタグ付け要件

内部LB用のプライベートサブネットのタグ付け要件

外部LB用のパブリックサブネットタグ付けオプション

EKSクラスター作成

必須

Cluster name

kubernetes version

Role:EKSサービスロール作成で作成したRole

VPC:クラスタ用VPC作成で作成したVPC

Subnet:作成したVPCに所属するSubnetを選択

非必須

Endpoint private accses

Endpoint pubric accses

※Amazon EKS クラスターエンドポイントのアクセスコントロール

ログ記録

Amazon EKS セキュリティグループの考慮事項

クラスターセキュリティグループ
※Kubernetes 1.14 および eks.3 プラットフォームバージョンを実行している Amazon EKS クラスターから利用可能

コントロールプレーンおよびワーカーノードのセキュリティグループ
※Kubernetes バージョン 1.14 およびプラットフォームバージョン eks.3 以前の Amazon EKS クラスター対応

kubeconfigの作成

aws cliでトークン取得が可能
※kubeconfigはkubectlを使ってk8sのAPIサーバと通信してクラスタと接続するための設定ファイル

マネージド型ノードグループの起動

マネージド型ノードグループとは

EKS Kubernetes クラスターのノード（Amazon EC2 インスタンス）のプロビジョニングとライフサイクル管理を自動化します

ワーカーノード用のIAMロールの作成

AmazonEC2ContainerRegistryReadOnly

AmazonEKS_CNI_Policy

AmazonEKSWorkerNodePolicy

ポッドネットワーキング (CNI)

CNI プラグインは、Kubernetes ノードに VPC IP アドレスを割り当て、各ノードのポッドに必要なネットワークを設定します。このプラグインは 2 つの主なコンポーネントで構成されています。

L-IPAM デーモン

CNI プラグイン

おすすめ学習マテリアル

Amazon EKS Advent Calendar 2019

Amazon EKS #2 Advent Calendar 2019

コンテナうまみつらみ〜Kubernetes初心者がEKSと格闘した1年を振り返る〜

登壇者は不動産テック企業の(株)いい生活の多田吉克さん

はじめに

ことの始まりは3月

CTOから「4月から新規プロジェクトのPMよろしく、EKSで」と言われた

4月にPJがスタート

メンバーは3人でスタート

がっつりクラウド/コンテナで開発経験のあるメンバーはなし

EKSの採用は内定状態だった(社内的な事情も込み)

PoC的な意味も含めてやってみようとなった

PJ概要

既存システム(レガシーでオンプレ)に接続するためのオープンで使いやすいAPI作り

名前は出島(dejima)と名付けた

アーキテクチャイメージ

現在の稼働状況

21ノード(最大)

13マイクロサービス

平均して120Podsから最大200Podsまでスケールアウト/イン

デプロイ出来るまで

eksctlは実はあまり使わずCTOが素振りしてたCFnで作成

CTO「このCFnを読め、理解しろ、そしてやれ」

クラスタ作るまでは苦労はあまりなかったがそこからPod何か動かしてみようってところから派生させてった

サービス公開にはALB Ingress Controllerを使用

ALB Ingress ControllertのおかげでAWSのリソースの世界をあまり意識しなくて出来た

ALB Ingress Controllertとは

Ingress リソースがクラスターで作成されるたびに、Application Load Balancer (ALB) および必要な AWS サポートリソースの作成をトリガーするコントローラーです。

使いやすいコンテナに仕上げる工夫したこと

設定値を注入可能にする

コマンドクエリ責務分離パターンを拡張して適用

同じデータモデルのアプリケーションでも更新系と参照系を別のデプロイメントとして扱った

アプリケーションのレイヤで更新と参照で別の言語使っていても同じ様にデプロイ出来るメリットが有る

更新系と参照系で負荷傾向が違うのでそれぞれに適したチューニングを施せるメリット ###CI/CD

社内CIサーバ(Drone.io)とAWS CodeBuildを併用

nightlyビルド+デプロイ

機能性能テストを開発環境で定期実行

リリースサイクルの高速化に貢献 ###監視系

メトリクスはPrometheusで収集してGrafanaで可視化

ログはFluentBit+Firehose+Splunk

リリース前の話だが、InfluxDBでやっていたが負荷に耐えきれず敢え無く死んでいったのでPrometheusメトリクスの長期保存は断念

初心者だったとき一番辛かったこと

Envoyのconfigつらかった

Sidecarの何が嬉しいかを頭では理解できてても、どうやって設定で実現するかよくわからなかった

やりながら、最悪ソースコード読んだりして肌で理解していった

ClusterIPの罠

サービス間の連携はClusterIPを先に構成させてた

それだとEgressの接続先がClusterIPだと通信が不安定になる

LBがEnvoyとk8sのServiceの2段あった

Envoyが細かくヘルスチェックしててもService側のヘルスチェックの律速でしか切替出来なかった

Service側をHeadHeadless化して解決

コンテナの恩恵

同じEKS内に移設が決まったサービスがいくつかあった

やってしまえばなんとかなる、で乗り切れた

本番稼働してわかったこと

Podへのリソース割当

CPU使用量200くらいで性能劣化するケースも

早めにスケールアウトさせて上限に余裕をもたせよう

CPU不足が気付きにくい

Podは死んでもリクエストはくる

ログとメトリクス多すぎ

k8sはコンポーネントが多いのでログもメトリクスも膨大

今の課題

可観測性(ログを削ってるため)

Prometheus不安定問題

トレーシングやっていきたい

Istio導入するか

クラスターマネジメント

EC2インスタンスやクラスターバージョン管理など

Managed Node Group

Fagateどうするか

チーム体制と教育

 Kubernetesをめぐる冒険

登壇者は2019年で2700kmも走ったChatwork社SREの坂本諒さん

Chatworkの紹介

ビジネスチャットサービス

グループチャット、タスク管理、ファイル共有、ビデオ、音声通話

kubernetesの利用形態

マルチテナント

クラスタはSREが作る

管理系アプリはSRE

サービス・アプリはDevチーム

導入は2016年で最初のバージョンは1.5

EKS以前はkube-awsを利用して自前でホスティング

eksctl登場で色々変わった話

eksctlとkube-awsの比較

eksctl

開発が早い

基本的にはクラスタ構成はUpdate出来ない

kube-aws

クラスタ構成はUpdate可能

EKSを利用するのではなくcontroller、etcd含めて作成

カスタマイズ性が高い

k8sの設定ファイルが膨大なYAMLに(Prodの686行)

長期的に見るとeksctlの方がメリットが大きい

IAMでユーザ認証可、PodにIAMRole、EKSそのもののメリット

k8s運用で大変なこと

バージョンアップ対応(k8sは3ヶ月毎)

全部は追従しないにしても半年に1回はやる

環境の作り変え頻発

手動(ドキュメント対応)では運用負荷が大きすぎる

運用を支援する仕組みが必要

eksctl

Varint

helm,helmfile

GitOps

Flux + Argo CDのハイブリット構想

Flux

原則manifestだけ、1flux - 1repo - 1 branch

manifest適用であまり変更がないもの(namespace,aws-authなど)

Argo CD

GUI対応、helm対応で使いやすい

半額はありがたいというお話

 OSSから理解するEKSとそのエコシステムについて

登壇者はkubernetes.ioやkubernetes-the-hard-wayの日本語化などに貢献しているZOZOテクノロジーズ社の太田航平(inductor)さん

このセッションは「EKS完全に理解した人」向けと前置いてからスタートされました笑

Kubernetesの設計思想

宣言的な構成管理

コントローラーを中心とした高い拡張性←ここにフォーカス

コンテナを基にした軽量、柔軟、高速なScaling

k8sの持つコンポーネント(マスターコンポーネント)

kubectl→kubeAPIServerに対してAPIリクエストを投げる

etcd-ステートが書き込まれる

書き込まれたステートに従ってコンテナを配置していく

デプロイメントコントローラがデプロイメントのリソースを作る

reconcile loop

コントローラが定期的にetcdに書かれたステートをウォッチしに行く

新しいものを作るのを感知したらクリエイトする

 Cloud controller manager(c-c-m)

k8sが持つインターフェースに従ってコントローラを書いてあげるとAWSやGCPのリソースを管理できるようになる

k8sの公式のPJじゃなくてCloudプロバイダー達が作っているコミュニティベースのOSS

k8sと各コミュニティCloudをAPIで繋いでくれる中継役をc-c-mの実装によって実現

k8sのコントローラとして一定間隔でk8s上で使いたいCloudのリソースとAWSに実際に存在するリソースの整合性を保つ

 cloud provider aws

AWSのリソースをk8s上のリソースとして管理するために必要なコントロール

kubectlを叩く

apiserverがetcdにサービス作ってくださいと要求

c-mがサービスを作ってくださいという要求をウォッチ

serviceを実際に作成

c-c-mがAWSのAPIに応えてLBのプロビジョニング

LBが出来たらservice側と整合性を併せにがっちゃんこする

これによりあたかもk8s上でLBが連携出来たかのように動く

EKSはk8sのマスターコンポーネント部分がマネージドになっている

ここの部分が最近半額になった

FagateだとENIが居なくなってる

Containerdが動いている

k8sとAWSのネットワークの連携

k8sのNW

k8sは大きく分類するとPod用、Service用、Node用のネットワークがある

Node用のNWはEC2やFagateに直接アタッチされるVPC配下のNW

オンプレで言うところの物理NICや仮想NICが刺さってるとこ

Pod用のNWは論理的に分離されたNW

Nodeとは完全に隔離されている

Service用のNWはLBやEngressなどアプリケーションレイヤのロードバランシング

AWSのNW

VPC、サブネット、NACL、SG、ENI、Gateway

k8sとはNWの概念が違う

2種類のNW概念を繋いであげる必要がある

CNI(Container Network Interface)

CNIはk8s/ContainerのNWを定義する仕様

各プロバイダーは仕様に併せて実装

VPCの世界とk8sの世界を繋いでくれる存在

ECSもCNIを使っている

k8sとAWSのストレージの連携

k8sにおけるストレージは、Storageclass、PersistentVolume、persistentvolumeclaim

AWSにおけるストレージは、EBS、EFS、FSx

CSI(Container Storage Interface)

デバイスドライバー

オープンソースで公開されている

k8sとAWSのストレージの世界を繋いでくれる

eksctl

Weavework社が出しているEKSのラッパーツール

去年公式ツールに昇格

設定の引数をYAMLで記述できるのでIaCも出来る

DockerComposeのような使用感

ekcctlがあればログやメトリクスCloudWatchで面倒みさせたり

ALB Ingress Controllerをeksctl有効化可能

ACMやRoute53も有効化出来る

結果eksctlは凄く便利

AWSSDK経由でCFnスタックがプロビジョニングされる

EKSのクラスタやノードはCFnで作成

EKSのworkloadだけじゃなくクラスタも宣言的に管理

構成変更や削除も対応可能

k8sとAWS関連OSS

SIG AWS

IAM Authenticater

CNI/CSI plugin

external-dns

AWSが関わるk8s関連OSS

EKS(ECS)の開発チーム動向

タイトル	登壇者情報
今こそ振り返るEKSの基礎	濱田孝治クラスメソッド AWS事業本部コンサルティング部
コンテナうまみつらみ〜Kubernetes初心者がEKSと格闘した1年を振り返る〜	多田吉克（株）いい生活サービスプラットフォーム開発部
Kubernetesをめぐる冒険	坂本諒 Chatwork
OSSから理解するEKSとそのエコシステムについて	太田航平(inductor) ZOZOテクノロジーズ MLOpsチームエンジニア
EKS on Fargate を紹介したい	ミラクル⭐トリバード
EKSでのpodとIAM Roleの管理方法を整理	ジュジュ
Kubernetes における Topology（仮）	チェシャ猫
インフラ未経験からCKADに合格するまでの道のり	Masatoshi Tada
EKS for EFS	nnao45

AmazonEKSServicePolicy	AmazonEKSClusterPolicy
EKSがk8sクラスタを作成〜運用するためのポリシー	k8sクラスタのコントロールプレーンがAWSリソースを操作するためのポリシー

　 Tweet
Qiitaで続きを読む

20200125のAWSに関する記事は24件です。

【AWS】Qiita 週間いいね数ランキング【タグ別】

他のタグ

集計期間

いいね数ランキング

1位: [個人開発]大喜利サービスを5日でつくってわかったこと

2位: AWS・GCP・AzureのIoTプラットフォームを調べている

3位: 実践Terraformを写経してみたらよかったって話

4位: AWS CLIのアカウントを切り替えるためのコマンドを作成する

5位: AWSのEC2とRDSをTerraformで構築する Terraform３分クッキング

6位: AWSが大阪リージョンを開設するに至った背景を推測する

7位: DjangoアプリをDocker上に構築しAWS Fargateにデプロイする

8位: 無から素数列挙 on Athena (Presto)

9位: 個人でやっている AWS IAM の運用

10位: terraform で 同じスペックの EC2 を複数台作る

11位: 日本語に対応した文字起こしサービス Amazon Transcribe がすごいらしいので試してみた

12位: 異なるAWSアカウント間のS3内データを移動する方法

13位: 【AWS・Python】Slash Commandsを拡張性高く実装する

14位: 【ブログ枠】JAWS-UGコンテナ支部 #16〜EKS on Fargateローンチ記念！EKS祭りだワッショイ#1

15位: AWS Athenaで、WAFのcountログが絞り込めなくて苦戦した件

16位: Amazon S3 へ Amazon RDS のスナップショットをエクスポートできるようになったので、 AWS CLI で実行してみました。

17位: 新しめの設定をいれた AWS Billing and Cost Management 総まとめ

18位: 【AWS】S3へのデータアップロード

19位: ArgoでCIパイプラインを構築する

20位: MediaLiveで出力したアーカイブファイルをMP4に自動変換する

21位: AWS Sysopsアドミニストレーターアソシエイト資格に合格しました。

22位: AWS中国コンソールとグローバルの違うところ

23位: ServerlessFrameworkでスクレイピング用Lambda-Layerを作る

24位: 機械学習でひさ子のギターを自分のギターに持ち替えてもらう -準備編-

25位: Amplifyとは何者なのか

26位: codecommitとredmineを連携させる

27位: [AWS]Webサーバーの構築方法

28位: AWSの請求と料金

29位: AWS SAP エッセンス(執筆中 毎週更新)

30位: AWSでDB(MySQL)を作成した後、A5:SQL Mk-2で接続して管理する方法

31位: SSMパラメータストアを読み書きするCLIを作ってみた

32位: (コマンド化)AWS CLIにおけるMFA認証

33位: M5Stack + UiFlow + AWS でグラフ化 & 異常通知

34位: AWSアカウント作り直してみた

35位: インフラエンジニア、自由人として現状aws cloud9が最強だと思う理由

36位: EC2 AutoScalingを使ったGraceful Shutdownを考える

37位: Lambda Node.js8.10から10.xへの バージョンアップに伴うImageMagickの対応

38位: 【AWS】~/.ssh/configを使って、簡単にssh接続する

39位: EC2で立ち上げたWordPressで.htaccessを使えるようにする方法

40位: 画像から人物の性別、年齢を推測するLine botを作ってみた

41位: Amazon Web Services (AWS)サービスの正式名称・略称・読み方まとめ #24 (SDK とツールキット)

42位: flaws.cloudに挑戦してみた

43位: 【Rails】 Heroku, Aws で詰まったときに見る記事まとめ

44位: RDSとIAMでパスワードレス認証（Python）

45位: AWS Amplify Android を試してみる(Mac)

46位: AWS DevOps Professional合格レポート

47位: AWSで作ったLaravelアプリケーションをXserverにデプロイする

48位: 同じVPC内のEC2へホスト名でSSH接続する

49位: DynamoDBでPromiseが使えた(Lambda Node.js)

50位: IP制限しているインスタンスに対してCloudfrontからのアクセスを許可する

51位: Lambda + API GatewayでCORSを有効にしているのにCORSでエラーになる

52位: Amazon Web Services (AWS)サービスの正式名称・略称・読み方まとめ #23 (AR とバーチャルリアリティ)

53位: AWS Solution Architect Associate メモ１

54位: 自動デプロイ（Capistrano）でエラー mkdir: ディレクトリ `/var/www' を作成できません: 許可がありません

55位: AWS SES メール送信環境のセキュリティを解剖する (2020年版)

56位: CodeCommit + CodeDeploy + CodePipelineでEC2にデプロイ~CodePipelineの設定・デプロイ実行~

57位: CodeCommit + CodeDeploy + CodePipelineでEC2にデプロイ~CodeDeployの設定~

58位: CodeCommit + CodeDeploy + CodePipelineでEC2にデプロイ~CodeCommitの設定~

59位: 【その設定値をゼロにするなんてとんでもない!】SQSで同じメッセージを複数件受信してしまう

60位: Javascriptのシンプルな構成でAWS Cognitoを理解する

61位: EFSをVPC PeeringしたLightsailのCentOSにマウントさせる

62位: 機械学習でひさ子のギターを自分のギターに持ち替えてもらう -実行編-

63位: codecommitのPullRequestをredmineのチケットに連携する

64位: 特定のS3 バケットだけにアクセスするポリシーを30秒で書く

65位: DynamoDB CLI

66位: 【これからプログラミング&クラウドを始める人向け】AWS Cloud9 を利用して Ruby の開発環境を作ってみる③ - Ruby のバージョン管理

67位: マストドン構築2日目 on AWS

68位: AWS Amplify API作成

69位: 【Rails】ActionMailer + AWS SES

70位: Railsチュートリアル 第13章 ユーザーのマイクロポスト - 本番環境での画像アップロード

71位: AWSの管理サービス

72位: AWSのデータベースサービス

【AWS】Qiita 週間いいね数ランキング【自動更新】

他のタグ

集計期間

5位: AWSのEC2とRDSをTerraformで構築する　Terraform３分クッキング

10位: terraform で同じスペックの EC2 を複数台作る

29位: AWS SAP エッセンス(執筆中毎週更新)

37位: Lambda Node.js8.10から10.xへのバージョンアップに伴うImageMagickの対応

70位: Railsチュートリアル第13章ユーザーのマイクロポスト - 本番環境での画像アップロード

4位: AWSのEC2とRDSをTerraformで構築する　Terraform３分クッキング

23位: terraform で同じスペックの EC2 を複数台作る

35位: Lambda Node.js8.10から10.xへのバージョンアップに伴うImageMagickの対応