20210507のAWSに関する記事は30件です。

AWSとWordPressを使ってWebサイトを構築しよう⑨

■Webサーバーへ接続する 前回インスタンスへApacheと呼ばれるWebサーバーソフトをインストールしました。 これでWebサーバーとしての機能が追加されたので実際にWebブラウザからアクセスしてみましょう。 目次 1.Webブラウザからインスタンスへアクセスする 2.セキュリティグループの80番ポートを開ける 1. Webブラウザからインスタンスへアクセスする まずは作成したインスタンスのパブリックIPを確認します。 今回は「3.112.29.31」となっています。 ※現在の設定だとパブリックIPは動的IPでインスタンスを起動し直す度にIPアドレスは変わるので注意してください。 ではパブリックIPアドレスをそのままWebブラウザで表示してみましょう。 画像上部にURLを入力するバーがあるので、そこにパブリックIPをそのまま入力してアクセスしてみます。 すると「このサイトにアクセスできません」とエラー表示されました。 アクセスできない原因はセキュリティグループの設定で「22番ポートだけを通してそれ以外のポートは通さない」という設定をしているからです。 これはEC2の画面からセキュリティグループの設定で確認することができます。 インスタンスを選択し画面下の「セキュリティ」をクリックします。 下にスクロールして「インバウンドルール」のところを見ると「ポート範囲:22」「ソース:0.0.0.0/0」という設定がされているのがわかります。 Apacheは80番ポートで待ち受けているため、Webブラウザでアクセスできるようにするにはセキュリティグループの80番ポートを開ける必要があります。 2. セキュリティグループの80番ポートを開ける まずEC2の画面を開き、左メニューから「セキュリティグループ」をクリックしてください。 次にセキュリティグループ一覧が表示されるので、以前作成したセキュリティグループを選択し、画面下の「インバウンドルール」をクリックしてください。 次に「インバウンドルールの編集」をクリックしてください。 この「インバウンドルール」というのがアクセスしてくる通信を制限するルールです。(アウトバウンドルールはその逆で通信の送信先を制限するルールです) インバウンドルールを編集できる画面へ移行するので下記のように入力してください。 まず「ルールの追加」をクリックして新しくルールを作成します。 ・タイプ:「カスタムTCP」を選択 ・ポート範囲:「80」と入力 ・ソース:虫眼鏡マークのある箇所に「0.0.0.0/0」と入力 全て入力を終えたら「ルールを保存」をクリックしてください。 これで下記画像のように新しくセキュリティグループのインバウンドルールに「80番ポートを開ける設定」が追加されたのが分かります。 ではもう一度WebブラウザでパブリックIPにアクセスしてみましょう。 すると下記のようにApacheのデフォルト画面が表示されましたので、無事パブリックIPへアクセスできたことが分かります。 今回はここまで。 次回はインスタンスにDNS名を割り当てていきます。 次の記事はこちらから AWSとWordPressを使ってWebサイトを構築しよう⑩
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AngularアプリをS3でホスティングするとこけた話

前回までのあらすじ HTMLvideoが使えない! こちらの記事の通りにS3へホスティングするもnavigator.mediaDevicesでビデオが起動しないエラー。 https://qiita.com/BBA/items/4de0132e63a371da4626 調べたところ記事の内容でS3へのホスティングはできてはいるのですが、SSL化されていない(http)とvideoデバイスへのアクセスができないとのことです。 app.component.ts import { Component } from '@angular/core'; import { ImgService } from './img.service'; @Component({ selector: 'app-root', templateUrl: './app.component.html', styleUrls: ['./app.component.css'] }) export class AppComponent { constructor(private service: ImgService) { } private video: any; result: String = ""; ngOnInit(): void { this.video = document.querySelector('video')!; const options = { video: true } //ここが怒られてしまう navigator.mediaDevices.getUserMedia(options) .then(stream => { this.video.srcObject = stream; }) .catch((error) =>{ console.log(error); }) } captureImg(){ let canvas = document.getElementById('canvas') as HTMLCanvasElement; const context = canvas.getContext('2d'); context?.drawImage(this.video, 0, 0, canvas.width, canvas.height); let base64CapturedImg : ConstrainDOMString = canvas.toDataURL("image/png"); this.service.transferImg(base64CapturedImg).subscribe( data => this.result = data, error => console.log(error) ); ; } } CloudFrontでドメインをSSL化 以下の手順でDistributionを設定し作成すると無事SSL化でき、ビデオもアクセス可能になりました。 ①S3にデプロイして取得したドメイン名を選択 ②Viewer Protocol PolicyをRedirect HTTP to HTTPSに ③Default Root ObjectにS3で指定したインデックスドキュメントと同じように記述(デフォルトはindex.html) 感想など S3にホスティングだけでこけるとは思いませんでしたが、カメラ等デバイスにアクセスするにはSSL化が必要というのは今後またどこかで役立ちそうな知識でよかったです。Springの方も確実にホスティングこけますが頑張ります。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

[AWS]Aws::Sigv4::Errors::MissingCredentialsError: Cannot load `Rails.config.active_storage.service`:

はじめに 未解決エラーについて一旦忘れないようにこちらに記載します [追記]解決しました!!とてもしょうもないミスでした、、、、 環境 ruby 2.6.5 Rails 6.0.0 エラー内容 こちらの記事を参考に、AWSへもデプロイをしていこうと進めておりましたところ、Unicorn起動がうまく行かず、、、、 [tochikawa@ip-10-0-0-132 log]$ bundle exec unicorn_rails -c /var/www/rails/soccer_app/config/unicorn.conf.rb -D -E production master failed to start, check stderr log for details とりあえずログを見てみることに、、、すると、気になる表示が!! Aws::Sigv4::Errors::MissingCredentialsError: Cannot load `Rails.config.active_storage.service`: missing credentials, provide credentials with one of the following options: あ〜credentialまわりでなんか起きているなああということで情報収集したところ、この記事に記載のことが原因かな〜と確信!! しかし、一向に治らず、、、 どうもcredentialsとmaseter.keyがうまくあってないような気がするんですが、ここは間違いなく大丈夫、、 何が原因わからないよ〜〜〜!!! [追記] 原因判明 原因は以下二つだったことが判明 1.credentials.yml.encにaccess_key等が設定されていなかった 2.storage.ymlのインデントミス 正直恥ずかしいまでに初歩的なミスです。 けれどおかげさまで、この辺りの知識メッッチャ増えました! おわりに 転職活動中のみですので、早く完成させたい!と思い焦ってしまいましたが、一度落ち着いてよくみてみるとたいしたことなかったりしますね笑
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

[AWS]未解決エラー:Aws::Sigv4::Errors::MissingCredentialsError: Cannot load `Rails.config.active_storage.service`:

はじめに 未解決エラーについて一旦忘れないようにこちらに記載します 環境 ruby 2.6.5 Rails 6.0.0 エラー内容 こちらの記事を参考に、AWSへもデプロイをしていこうと進めておりましたところ、Unicorn起動がうまく行かず、、、、 [tochikawa@ip-10-0-0-132 log]$ bundle exec unicorn_rails -c /var/www/rails/soccer_app/config/unicorn.conf.rb -D -E production master failed to start, check stderr log for details とりあえずログを見てみることに、、、すると、気になる表示が!! Aws::Sigv4::Errors::MissingCredentialsError: Cannot load `Rails.config.active_storage.service`: missing credentials, provide credentials with one of the following options: あ〜credentialまわりでなんか起きているなああということで情報収集したところ、この記事に記載のことが原因かな〜と確信!! しかし、一向に治らず、、、 どうもcredentialsとmaseter.keyがうまくあってないような気がするんですが、ここは間違いなく大丈夫、、 何が原因わからないよ〜〜〜!!! おわりに 現在、原因究明中 どなたかお分かりの方いれば是非コメントを!!
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

visudo: /etc/sudoers がビジー状態です。後で再試行してくださいエラーへの対応

はじめに ポートフォリオサイトをAWSへデプロイする際に上記エラーが発生したため、その時の解決手順を記載します。 今回は「sudo visudo」コマンドを入力した際にエラー表示され、ターミナルでのコマンド入力が何もできなくなってしまいました。 エラー内容としては他で既にvisudoが起動しているから重複して起動できませんよーといったものだが、他で起動した記憶が全くない状況でした。 後々考えると、一度ターミナルを強制終了していたので、おそらくそのせいだと思います。 解決に向けて 結論からいくと、プロセスIDが正常に切断されていなかったことが原因でした。 そのためプロセスIDを消去してあげる必要があります。 ①ターミナル上でルートディレクトリに移動。 ※どの状態でエラーが発生したかによって、実行するディレクトリも異なってきます。例えばec2-userの状態でエラーが発生したのであれば、ルートディレクトリではなく、ec2-userにて削除を実施する必要があります。 ターミナル *****@***** ~ % *はPCのユーザー情報 ②psコマンドにてプロセスIDの確認 ターミナル *****@***** ~ %ps ③プロセスIDの削除 ②のコマンド入力で、 ターミナル PID TTY TIME CMD 10490 ttys000 0:00.14 -zsh のような表示がされると思います。 そこで該当のPID(プロセスID)を削除します。 削除するコマンドは、killもしくはkill-9となります。(kill-9は強制的に終了するコマンド) ターミナル *****@***** ~ %kill PIDの値 もしくは kill-9 PIDの値 プロセスID削除後に再度試すとエラーが発生せず動作しました。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

[AWS][boto3][create_stack] CloudFormationスタックをシリアルに実行するサンプルスクリプト

概要 以前作ったスクリプト の拡張版 CloudFormationスタックを順次実行するboto3スクリプト 実行中のスタックが完了するまで次のスタックは実行しない 以下の要望に対応できそう CloudFormationスタックで作成したAWSリソースに依存したAWSリソースをboto3(Pythonスクリプト)で作りたい CloudFormationスタックの実行回数や実行ごとのパラメータを動的に変更したい 環境 Windows 10 の以下バージョンの環境にて動作を確認 VPC→サブネット→SG→EC2の順でシリアルにスタックを実行している。実行後に、作成したAWSリソースの情報(EC2のIDなど)が取得できていることがわかる。 PS C:\> python3 --version Python 3.8.10 PS C:\> aws --version aws-cli/2.2.3 Python/3.8.8 Windows/10 exe/AMD64 prompt/off PS C:\> python3 Python 3.8.10 (tags/v3.8.10:3d8993a, May 3 2021, 11:48:03) [MSC v.1928 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import boto3 >>> import botocore >>> print(f'boto3 version: {boto3.__version__}') boto3 version: 1.14.43 >>> print(f'botocore version: {botocore.__version__}') botocore version: 1.17.43 >>> PS C:\> aws configure AWS Access Key ID [****************XXXX]: AWS Secret Access Key [****************XXXX]: Default region name [ap-northeast-1]: Default output format [json]: スクリプト スクリプトはgithubにおきました。 実行前の準備 S3バケットを作成し、さらにprefix(フォルダ)を作成し以下のようにymlファイルを格納します。 PS C:\> aws s3 ls s3://{{S3バケット名}} --recursive 2021-05-07 18:32:58 1940 test/ec2-linux.yml 2021-05-07 17:36:00 1112 test/sg.yml 2021-05-07 17:46:45 1821 test/subnet-public.yml 2021-05-07 17:36:00 1062 test/vpc.yml 実行方法 コマンド例 C:\Users\usr001\tmp> python3 .\test.py -f sample.json -s3 {{S3バケット名}} -p test -f に sample.json を、-s3 に実行前の準備でymlファイルを格納したS3バケット名を、-p prefix(フォルダ)名を指定します。 制御について CloudFormaionスタック実行時に使用するymlファイルと指定するパラメータは、sample.json で指定します。 例1)sample.jsonが以下の場合、ymlファイルは vpc.yml でPJPrefixとVPCCIDRがパラメータになります。StackNameはスタック名です。 sample.json [ {"StackName": "test001-vpc","Code": "vpc.yml", "PJPrefix": "Project1","VPCCIDR": "10.11.0.0/16"} ] 例2)sample.jsonが以下の場合、2つのスタックを実行します。vpc.ymlを使用したスタックの実行が完了した後で、subnet-public.ymlを使用したスタックが実行を開始します。 sample.json [ {"StackName": "test001-vpc","Code": "vpc.yml", "PJPrefix": "Project1","VPCCIDR": "10.11.0.0/16"}, {"StackName": "test001-subnet1","Code": "subnet-public.yml", "PJPrefix": "Project1","NetworkName": "Net001","PublicSubnetCIDR": "10.11.1.0/24", "AZName": "ap-northeast-1a"}, ] 本リポジトリに格納したsample.jsonは以下であり、VPC→サブネットワーク→セキュリティグループ→EC2インスタンスの順にシリアルにスタックを実行します。※EC2起動は課金の可能性があるので注意※ sample.json [ {"StackName": "test001-vpc","Code": "vpc.yml", "PJPrefix": "Project1","VPCCIDR": "10.11.0.0/16"}, {"StackName": "test001-subnet1","Code": "subnet-public.yml", "PJPrefix": "Project1","NetworkName": "Net001","PublicSubnetCIDR": "10.11.1.0/24", "AZName": "ap-northeast-1a"}, {"StackName": "test001-sg","Code": "sg.yml", "PJPrefix": "Project1","ServiceName": "ServiceA","SGNo": "001"}, {"StackName": "test001-ec2","Code": "ec2-linux.yml", "PJPrefix": "Project1","ServiceName": "ServiceA","SGNo": "001", "NetworkName": "Net001", "KeyPairName": "keypair_ap-northeast-1_01", "EC2InstanceName": "ec2-001", "EC2InstanceAMI": "/aws/service/ami-amazon-linux-latest/amzn2-ami-hvm-x86_64-gp2", "EC2InstanceInstanceType": "t2.micro", "EC2InstanceVolumeType": "gp2", "EC2InstanceVolumeSize": "8" } ] 実行例 スクリプトを実行したときに出力される標準出力の例 PS C:\Users\usr001\tmp> python3 .\test.py -f sample.json -s3 {{S3バケット名}} -p test {'StackName': 'test001-vpc', 'TemplateURL': 'https://{{S3バケット名}}.s3-ap-northeast-1.amazonaws.com/test/vpc.yml', 'Parameters': [{'ParameterKey': 'PJPrefix', 'ParameterValue': 'Project1'}, {'ParameterKey': 'VPCCIDR', 'ParameterValue': '10.11.0.0/16'}]} [LOG] CFn Stack [test001-vpc] start. [LOG] CFn Stack [test001-vpc] end. スタック名 : test001-vpc スタックID : arn:aws:cloudformation:ap-northeast-1:121212121212:stack/test001-vpc/00000000-0000-0000-0000-000000000000 パラメータ VPCCIDR = 10.11.0.0/16 PJPrefix = Project1 [CloudFormation] Outputs VPCCIDR : 10.11.0.0/16 : Project1-vpc-cidr InternetGateway : igw-00000000000000000 : Project1-igw VPC : vpc-00000000000000000 : Project1-vpc {'StackName': 'test001-subnet1', 'TemplateURL': 'https://{{S3バケット名}}.s3-ap-northeast-1.amazonaws.com/test/subnet-public.yml', 'Parameters': [{'ParameterKey': 'PJPrefix', 'ParameterValue': 'Project1'}, {'ParameterKey': 'NetworkName', 'ParameterValue': 'Net001'}, {'ParameterKey': 'PublicSubnetCIDR', 'ParameterValue': '10.11.1.0/24'}, {'ParameterKey': 'AZName', 'ParameterValue': 'ap-northeast-1a'}]} [LOG] CFn Stack [test001-subnet1] start. [LOG] CFn Stack [test001-subnet1] end. スタック名 : test001-subnet1 スタックID : arn:aws:cloudformation:ap-northeast-1:121212121212:stack/test001-subnet1/0000000-0000-0000-0000-000000000000 パラメータ AZName = ap-northeast-1a PublicSubnetCIDR = 10.11.1.0/24 NetworkName = Net001 PJPrefix = Project1 [CloudFormation] Outputs PublicSubnet01 : subnet-0000000000000000 : Net001-ap-northeast-1a PublicSubnetCIDR : 10.11.1.0/24 : Net001-ap-northeast-1a-cidr PublicRouteTable01 : rtb-0000000000000000 : Net001-ap-northeast-1a-routetbl {'StackName': 'test001-sg', 'TemplateURL': 'https://{{S3バケット名}}.s3-ap-northeast-1.amazonaws.com/test/sg.yml', 'Parameters': [{'ParameterKey': 'PJPrefix', 'ParameterValue': 'Project1'}, {'ParameterKey': 'ServiceName', 'ParameterValue': 'ServiceA'}, {'ParameterKey': 'AWSResource', 'ParameterValue': 'EC2'}, {'ParameterKey': 'SGNo', 'ParameterValue': '001'}]} [LOG] CFn Stack [test001-sg] start. [LOG] CFn Stack [test001-sg] end. スタック名 : test001-sg b7a1f パラメータ SGNo = 001 ServiceName = ServiceA AWSResource = EC2 PJPrefix = Project1 [CloudFormation] Outputs SecurityGroupEC2 : sg-00000000000000000 : sg-Project1-EC2-001 [LOG] CFn Stack [test001-ec2] start. [LOG] CFn Stack [test001-ec2] end. スタック名 : test001-ec2 スタックID : arn:aws:cloudformation:ap-northeast-1:121212121212:stack/test001-ec2/00000000-0000-0000-0000-000000000000 パラメータ KeyPairName = keypair_ap-northeast-1_01 NetworkName = Net001 EC2InstanceName = ec2-001 SGNo = 001 EC2InstanceVolumeSize = 8 ServiceName = ServiceA EC2InstanceAMI = /aws/service/ami-amazon-linux-latest/amzn2-ami-hvm-x86_64-gp2 PJPrefix = Project1 EC2InstanceInstanceType = t2.micro EC2InstanceVolumeType = gp2 [CloudFormation] Outputs EC2InstancePrivateIp : 10.11.1.45 : Project1-ec2-001-private-ip EC2InstanceID : i-00000000000000000 : Project1-ec2-001-id PS C:\Users\usr001\tmp> ーーー おわりです。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【AWS】パブリックサブネットの作成方法

プログラミング勉強日記 2021年5月7日 パブリックサブネットの作成方法  パブリックサブネットからインターネットに接続するためにはインターネットゲートウェイが必要になる。(サブネットについてはこちらの記事で詳しく扱ってる)  このようにパブリックサブネットにするためにはインターネットゲートウェイのルートを作る必要がある。この設定をルーティング構成という。インターネットゲートウェイへのルートがあるサブネットがパブリックサブネットで、そうでなければプライベートサブネットになる。  ルートテーブルはルーターの中に配置されていて、インターネットゲートウェイはインターネットとやり取りをするルーターの1つとなっている。そのため、インターネットゲートウェイにも自身を示すルートテーブルがある。サブネットにもデフォルトでルーターがあって、そこにルートテーブルが使われている。ルートテーブルを設定して、インターネットゲートウェイへのルートを付けるとルーティング構成が完了する。  つまり、サブネットのルートテーブルにインターネットゲートウェイへのルートを設定することで、パブリックサブネットを作ることができる。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Fargateで起動したコンテナ内を覗きたい

DockerのVolumeがきちんとマウントできているか、どんなプロセスが動いているか、などの確認のため重宝しました。 参考サイト 初心者故に、公式記事よりも解説記事の方が理解しやすかったです。 独自に変更したい箇所があれば公式サイトを参照しました。 記事をまとめてくださった方々に感謝します。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

CloudFormationを理解する【環境構築〜運用について】

CloudFormationを使うにあたって開発環境構築から勉強しました。 AWS Black Beltの動画から https://www.youtube.com/watch?v=Viyqh9fNBjw 環境 macOS Big Sur バージョン11.2 環境構築 エディタ 自分的候補はvimかvscodeのどちらかだったが、自動補完プラグインが存在するvscodeを使うことにした。 プラグイン ・整合性チェック brew install cfn-lint ・自動補完 プラグインの追加を行い Install YAML support for VSCode. Here is the github repo vscodeのs~/Library/Application Support/Code/User/settings.jsonに下記を貼り付ける "[yaml]": { "editor.insertSpaces": true, "editor.tabSize": 2, "editor.quickSuggestions": { "other": true, "comments": false, "strings": true }, "editor.autoIndent": true }, "editor.renderWhitespace": "all", "editor.tabSize": 2, "editor.autoIndent": true, "yaml.format.enable": true, "yaml.trace.server": "verbose", "json.schemas": [ { "fileMatch": [ "*-template.json" ], "url": "https://s3.amazonaws.com/cfn-resource-specifications-us-east-1-prod/schemas/2.15.0/all-spec.json" } ], "yaml.schemas": { "https://s3.amazonaws.com/cfn-resource-specifications-us-east-1-prod/schemas/2.15.0/all-spec.json": [ "*-template.yaml", "*-template.yml", "*-cf.yml", ] } 実際にファイルを作成するときはjsonで定義した名付けルールで作成する ・起動テスト pip3 install taskcat ・セキュリティチェック brew install ruby brew-gem brew gem install cfn-nag ・ポリシーに沿ったルールになっているかチェック brew install cloudformation-guard デプロイ 3通りの方法がある CodePipelineを使用したデプロイ git管理でコミットすると自動的にデプロイされるような仕組みにする方法 Change Setを使用したデプロイ(更新時) 変更時に影響を受ける箇所を事前に管理コンソール上で確認できる StackSets 管理者アカウントからマルチリージョン、マルチアカウントにデプロイしたい場合に使用する 自分が利用する環境的にマルチアカウントへの対応が今後必要になる為StackSetsを勉強しなくては、、 テスト 整合性チェック cnf-lint <filename>-cf.yml セキュリティチェック (例)セキュリティグループで幅広いIPレンジを公開しているリスクを見つけられる cnf_nag_scan --input-path <filename>-cf.yml ポリシーに沿ったルールになっているかチェック (例)EBSボリュームが暗号化されていない、閾値以上のサイズの場合はじく 既存テンプレートからルールの雛形作成 cfn-guard rulegen <filename>-cf.yml 実際のチェック実行時 cfn-guard check -t <filename>-cf.yml -r <rulesetfile> 運用 スタックの更新 基本的には下記のような流れが良さそう。 ドリフト検出→テンプレートに反映→反映されたテンプレートに対して変更をかける→スタック更新 リソースの保護 リソースを更新する際に誤ってスタックやリソースが予期せず変更/削除されないように複数レイヤーの保護機能で対策する ・IAMポリシー ユーザーの権限を調整する ・スタックポリシー スタック更新の際の意図しない変更/削除を防ぐためにスタックのリソースに対して個別に設定する stack-policy.jsonというファイルにポリシーを記載するか、管理コンソールから追加する事もできる 下記はjsonファイルのイメージ { "Statment" : [ { "Effect" : "Deny", "Action" : "Update:*", ,,, ・リソースのdeletionポリシー リソース自体の保護。削除、保持、スナップショットの取得など定義することが可能。 (例)スタックが削除されてもS3バケットを保持するよう設定することが可能 ・スタックアクションの「削除保護」 スタック内のリソース全体に対しての削除保護、有効/無効を変更できる ライフサイクル別のスタック ライフサイクルが違うレイヤーはスタックを分割すると良いと言われている (例)セキュリティ、ネットワーク、監視、バックエンド、ステートフルなリソース(DBなど)、フロントエンド ・単一ファイルでの管理は依存関係やポリシーの設定が複雑になる Cross Stack Reference(アウトプットされたスタックの情報を別スタックでインポート)を活用すると良い (例)依存関係の少ないネットワークレイヤーをまず構築、次にネットワークに依存するセキュリティレイヤーを構築し、最後によく更新するアプリケーションレイヤーはその前に構築したものを参照するような形にする リファクタリング リソースのインポート機能を利用。 ・できること 管理コンソールから作成したリソースをスタックにインポート(対象リソースを含むテンプレートを作成してChangeSet実行) スタックから切り離し別スタックに移動 リソースIDをテンプレートに紐づける必要がある Former2を使用すれば既存のリソースからテンプレートを作成できる リソースを分割したい時もリソースを残したままスタックを削除し、テンプレートを分割してインポートすることで実現できる Dynamic References リソースのデータを動的に参照する 仕組み AWS System ManagerのパラメータストアとAWS SecretsManagerに格納されたデータをテンプレートで参照する CloudFormationのベストプラクティスとしてテンプレートに認証情報は埋め込まない為、これで実現する ツール ・cnf-init AmazonLinuxに入っているツール。 AWS::CloudFormation ::initセクションに記載した設定をEC2で実行できる(パッケージのインストールなど) ※初期起動時しか動作しない、ymlにシェルスクリプトが入ったりすると管理が大変、、 その為現在はStateManagerを利用するのがおすすめ インスタンスに対し定期的にAnsibleを実行 ・cnf-get-metadatat 例えばEC2だとパッケージや起動サービスの確認ができる ・cnf-signal EC2が正常に作成、更新されたかをCloudFormationに送信する。 リソースの作成開始後30秒以内にシグナルが飛ばなければロールバックする、というような用途で使用される。 ・cnf-hup リソースのメタデータ変更を検知しカスタムフックを実行する。 (EC2の再起動無しで変更の適用を行いたい場合など)
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

CodeBuildでjavaのソースコードをビルドする

はじめに CodeBuildを使ってjavaのソースコードをビルドします。 構成 作業 基本的にはコンソール操作ですがソースの準備部分でコマンドも記載しています。コマンドを使わなくても同じ状況になれば大丈夫です。 S3バケットの作成 まず、バケットを2つ用意します。 ソースコード用:codebuild-[regionID]-[accountID]-input-bucket ビルド出力用:codebuild-[regionID]-[accountID]-output-bucket S3バケット名はユニークでないといけないため[regionID]と[accountID]というルールを設けています。 ソースコードの準備 CodeBuildでビルドするためのソースコードを作成します。 空のディレクトリを用意し、その配下に以下のようなディレクトリ構造を作成します。 ディレクトリ作成 $ mkdir work $ cd work $ mkdir -p src/main/java $ mkdir -p src/test/java ディレクトリ構造 (root directory name) `-- src |-- main | `-- java `-- test `-- java また、src/main/java配下にMessageUtil.javaというファイルを作成します。 javaファイル作成 $ vim ./src/main/java/MessageUtil.java MessageUtil.java public class MessageUtil { private String message; public MessageUtil(String message) { this.message = message; } public String printMessage() { System.out.println(message); return message; } public String salutationMessage() { message = "Hi!" + message; System.out.println(message); return message; } } 次に、src/test/java配下にTestMessageUtil.javaというファイルを作成します。 javaファイル作成 $ vim ./src/test/java/TestMessageUtil.java TestMessageUtil.java import org.junit.Test; import org.junit.Ignore; import static org.junit.Assert.assertEquals; public class TestMessageUtil { String message = "Robert"; MessageUtil messageUtil = new MessageUtil(message); @Test public void testPrintMessage() { System.out.println("Inside testPrintMessage()"); assertEquals(message,messageUtil.printMessage()); } @Test public void testSalutationMessage() { System.out.println("Inside testSalutationMessage()"); message = "Hi!" + "Robert"; assertEquals(message,messageUtil.salutationMessage()); } } 次に、作業ルートディレクトリにpom.xmlというファイルを作成します。 xmlファイル作成 $ vim pom.xml pom.xml <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>org.example</groupId> <artifactId>messageUtil</artifactId> <version>1.0</version> <packaging>jar</packaging> <name>Message Utility Java Sample App</name> <dependencies> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.11</version> <scope>test</scope> </dependency> </dependencies> <build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>3.8.0</version> </plugin> </plugins> </build> </project> 最終的に以下のような構造になります。 ディレクトリ構造 (root directory name) |-- pom.xml `-- src |-- main | `-- java | `-- MessageUtil.java `-- test `-- java `-- TestMessageUtil.java buildspecファイルの作成 buildspecはCodeBuildでどのような処理を行うかを記載したレシピになります。 buildspec作成 $ vim buildspec.yml buildspec.yml version: 0.2 phases: install: runtime-versions: java: corretto11 pre_build: commands: - echo Nothing to do in the pre_build phase... build: commands: - echo Build started on `date` - mvn install post_build: commands: - echo Build completed on `date` artifacts: files: - target/messageUtil-1.0.jar ここまでの構造は以下になります。 ディレクトリ構造 (root directory name) |-- pom.xml |-- buildspec.yml `-- src |-- main | `-- java | `-- MessageUtil.java `-- test `-- java `-- TestMessageUtil.java ソースコードと buildspec ファイルのアップロード ここまでで用意したものをzipファイルにします。 $ zip -r MessageUtil.java * zipファイル内の構造は以下になっている必要があります。 MessageUtil.zip MessageUtil.zip |-- pom.xml |-- buildspec.yml `-- src |-- main | `-- java | `-- MessageUtil.java `-- test `-- java `-- TestMessageUtil.java zipファイルにしたら最初に作成したinputバケット(codebuild-[regionID]-[accountID]-input-bucket)へアップロードします。 ビルドプロジェクトの作成 CodeBuildでビルドを実行するためのビルドプロジェクトを作成します。 まず、[ビルドプロジェクト] → [ビルドプロジェクトを作成する]をクリックします。 ・プロジェクトの設定 次に、プロジェクトの設定のプロジェクト名にビルドプロジェクトの名前(ここではcodebuild-demo-project)を入力します。 項目 値 プロジェクト名 codebuild-demo-project ・ソース ソースプロバイダでAmazonS3を選択し、バケットにcodebuild-[regionID]-[accountID]-input-bucketを選択、S3オブジェクトキーまたはS3フォルダにMessageUtil.zipを入力します。 項目 値 ソースプロバイダ Amazon S3 バケット codebuild-[regionID]-[accountID]-input-bucket S3オブジェクトキーまたはS3フォルダ MessageUtil.zip ・環境 環境イメージでマネージド型イメージを選択し、オペレーティングシステムでAmazonLinux2を選択、ランタイムにStandard、イメージにaws/codebuild/amazonlinux2-x86_64-standard:3.0を選択します。 サービスロールでは新しいサービスロールを選択したままで、ロール名もそのままにします。 項目 値 環境イメージ マネージド型イメージ オペレーティングシステム AmazonLinux2 ランタイム Standard イメージ aws/codebuild/amazonlinux2-x86_64-standard:3.0 ランタイム Standard サービスロール 新しいサービスロール ロール名 自動入力されたもの ・Buildspec buildspecファイルを使用するを選択したままにします。 項目 値 buildspec buildspecファイルを使用する ・アーティファクト タイプをAmazon S3にし、バケット名にcodebuild-[regionID]-[accountID]-output-bucketを選択します。 項目 値 タイプ Amazon S3 バケット名 codebuild-[regionID]-[accountID]-output-bucket 以下は実際の入力例です。 入力が完了したら[ビルドプロジェクトの作成]をクリックします。 ビルドの実行 先ほど用意したビルドプロジェクトでビルドを実行します。 [ビルドプロジェクト] → [ビルドの開始]をクリックします。 確認 ビルドが完了すると、出力先に指定したcodebuild-[regionID]-[accountID]-output-bucketにjarファイルが出力されます。 おわりに CodeBuildを利用することで今まで必要だったビルドサーバーのサーバーレス化が行えます。 サーバー費用の削減だけでなく、運用コストも大幅に削減できるのでとても助かるサービスだなと感じました。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Node.js 10→14にアップデートしてみた

背景 備忘録。 AWSLambdaの対応ランタイムは10が、7月ごろ対応期限だったから急遽アップデート。 1. brewのアップデート brew update brew upgrade brew doctorでこの際にチェック 2. nodenvにnode 14の最新を入れる nodenvで最新バージョンが取得出来ないので、これを参考してany envを使えるようにした。https://qiita.com/turara/items/6b7f4a8e3770a7074072 Node.js 14.16.1を選択。LTSだから長期サポート。 3. パッケージをメンテナンス パッケージ・モジュール・ライブラリ。言葉統一しよう。これからはパワーリフティングしよう。 ncuコマンドでマイナー・バッチアップデートから順にアップデートしつつ、gitへコミットしていく。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

WindowsインスタンスへのRDP接続について

はじめに 転職前の自己学習の時は、EC2のOSと言えばAmazonLinux2のみしか触ったことがありませんでしたが、実務についてみるとOSがWindowsの場合も当然あって、しかも接続元のPC環境(WindowsかMac)によって、若干接続方法が異なっていたので、その手順の流れを記します。 Windowsインスタンスの作成 まずはEC2のダッシュボードからWindowsインスタンスを作成します。AMIはwindowsを選択します。 その他の作成手順は、LinuxOSの時と同じですが、1点だけ異なる点として、セキュリティグループの設定で、RDPのポート3389を指定する必要があります。 EC2インスタンスのステータスチェックが2/2になったら完成です。 ログインPWの取得 OSがLinuxの時は、キーペアを使ってSSH接続してログインする流れとなりますが、Windowsの場合はキーペアを使ってログインに必要なPWを取得する手順となります。 Browseからキーペアの情報を埋め込みます。 ログイン時に使用するユーザー名とPWを控えます。 以上が、事前準備となります。次項から実際にサーバーへログインしていきましょう。 WindowsPCからログインする場合 WindowsPCからの接続の際には、デフォルトでリモートデスクトップ接続があるため、それを利用してログインします。 起動させて、オプションの表示を選択してログインするサーバーの情報を入力します。 コンピューターにはパブリックIPを入力し、ユーザー名はAdministratorを入力して接続を選択します。 PWが求められますので、先程取得した情報を使用します。 接続を押下後、以下の画面が表示されたらOKです。 Macからログインする場合 Macの場合、WindowsPCと違い、デフォルトでは接続ツールがないため、Microsoft Remote Desktopアプリを利用します。 アプリを起動して、Add PCを選択して下記情報を入力します。 作成したPCを起動し、ユーザー名とPWを入力したらContinueで接続します。 接続前に以下の証明書の確認画面が表示されます。Continueでそのまま進めてしまっても問題ありませんが、 ログインする度に求められるので、Show Certificateを選択して、Always trustにチェックを入れることで次回以降は省略できます。 ちなみに、ユーザーネームとPWもログイン時に毎回入力が求められますが、そちらも省略が可能です。 作成したPCのEdit画面を表示させ、User accountからAdd User Accountを選択します。 ログインするユーザーを作成することで以降は、アプリから対象PCを選択するだけでログインが可能となります。 WindowsPCでのログイン同様、以下画像が表示されればOKです。ちなみにEC2のインスタンスタイプをt2.microで作成した際は、 接続画面が表示されるまでかなり重くてもっさりした動きでした。 参考 Windows インスタンスに接続する Macアプリ「Microsoft Remote Desktop」 – 証明書の確認を表示しないように
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【AmazonConnect】Lambdaを利用して受付時間外の電話着信をSlackに通知させてみた(後編)

前編はこちら まだ前編を読めていない人はこちらからご覧ください! https://qiita.com/hagiohagi/items/cef993105f653eab9603 後編ではLambdaの設定・Slack Appの設定・Amazon Connectの問い合わせフローの設定をしていきます! LambdaとSlack Appの設定 ・Lambda関数の作成 AWSコンソールにログインし、サービスから「Lambda」を選択 ポリシーのフィルターの設定で「AWSLambda_FullAccess」を選択 任意の名前と説明を記入 関数の作成は「一から作成」を選択し、任意の名前を記入 ランタイムはPython3.8を選択し、ロールは先ほど作成したロールを選択 公開コードを利用するため以下のリンクを開く https://github.com/hackjapan/amazonconnect_slack 緑の「Code」ボタンをクリックし、Download ZIPをクリック Lambdaの画面に戻り、「アップロード元」をクリックし.zipファイルを選択 先ほどダウンロードしたzipファイルをアップロードする ドラッグ&ドロップで以下のファイルの位置を関数名の直下に移動させる  ・certifi  ・chardet  ・inda  ・requests  ・urllib3  ・lambda_function.py ・Slackに表示される文言を変更する AWSコンソールのLambdaのページで関数を選択し、コードの表示画面を開く Lambda_function.pyを開き、34行目の”通話の着信中”の文面を"営業時間外の時間帯に着信がありました"に変更する ・Slack Appの作成 以下のリンクからSlack apiを開く https://api.slack.com/?_fsi=yHiAp51t 中央の「start building」をクリックし、アプリの名前とWorkspace(slackのチャンネルの場所)を入力しcreate appをクリック ・環境変数の設定 Amazon Connectのホーム画面を開き、右上の電話のアイコンをクリック 表示されたウインドウのリンクをコピー AWS Lambdaの先ほど作成した関数を開き、「設定」→「環境変数」を選択 キーの名前を「AMAZON_URL」、値にコピーしたリンクの名前を貼り付けて登録 Slack apiで「Incoming Webhook」をクリックし 、「Webhook URL」の文字列をコピー (Webhook URLがない場合は「Add New Webhook to Workspace」を押してWorkspaceを登録) AWS Lambdaの先ほど作成した関数を開き、「設定」→「環境変数」を選択 キーの名前を「SLACK_WEBHOOK」、値にWebhook URLの文字列を貼り付けて登録 Slack(アプリ本体)を開き、botを通知させたいチャンネルを選び、右クリック リンクのコピーを選択して、コピーしたアドレスの後ろ11文字の文字列をコピー AWS Lambdaの先ほど作成した関数を開き、「設定」→「環境変数」を選択 キーの名前を「SLACK_CHANNEL」、値にリンク名からコピーした文字列を貼り付けて登録 ・Amazon ConnectにLambda関数を登録 AWSコンソールでAmazon Connectを開く インスタンスエイリアス名をクリックして、概要の欄から「問い合わせフロー」をクリック AWS Lambdaの項目で作成したLambda関数を選択して「Add Lambda Function」をクリック 問い合わせフローの設定 ・問い合わせフローの作成 左側アイコンの3つ矢印から問い合わせフローを選択、「コンタクトフローの作成」をクリック 「操作」から「プロンプトの再生」をフローにドラッグ&ドロップ 「設定」から「音声の設定」をフローにドラッグ&ドロップし、音声を「mizuki」に設定し、「save」をクリック 「ブランチ」から「オペレーション時間を確認する」をフローにドラッグ&ドロップし、パラメータに先ほど作成したオペレーション時間を設定し、「save」をクリック フロー上の「プロンプトの再生」をクリックテキスト読み上げ機能をチェックし、テキストの入力をチェックの上任意の文言(例:ただいま電話を繋いでおります/ただいまお電話に出ることができません)を設定し、「save」をクリック 「終了・転送」から「電話番号のへの転送」をフローにドラッグ&ドロップし、転送先の電話番号の記入、タイムアウトの秒数の記入、切断後に問い合わせフローを再開の所で「はい」を選択肢、「save」をクリック 「統合」から「AWS Lambda関数を呼び出す」をフローにドラッグ&ドロップし、関数を選択するにチェックを入れ、作成したLambda関数を選択し、「save」をクリック 以下の図の通りになるように矢印を結ぶ (※プロンプトは営業時間内の場合と営業時間外の場合の2つを用意する) 「保存」の隣の▼をクリックし「保存して発行」をクリック ・フローと電話番号を結びつける 左の矢印3つのアイコンから電話番号をクリックし、表示された画面から該当の電話番号をクリック 問い合わせフローに先程作成したフローの名前を選択する 完成したので試してみる 設定した営業時間の外のタイミングで、Amazon Connectで登録した電話番号に電話してみる。 設定の通りの音声プロンプトが流れた後、このような通知がSlackのチャンネルに届けば成功です! 最後に 本当に最後までオープンソースの情報だけでなんとかやりくり抜いた感じなので、 これからLambda関数についてより学習し、もっと柔軟に要件に応えられるようにしていきたいです!
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【AmazonConnect】Lambdaを利用して受付時間外の電話着信をSlackに通知させてみた(前編)

はじめに この度、社内電話の設定を自分の手で編集するという、貴重な業務に携わったので、 今回、備忘録として残しておこうと思いました。 ちなみに、私自身のLambdaの知識はほぼゼロです。 他の記事やサイトの情報を拝借して繋げられた感じです。ありがたや。 お世話になった記事・サイト HACKNOTE様の記事にはとてもお世話になりました。 ・Amazon Connectで電話番号を取得して自動音声を流す https://hacknote.jp/archives/48971/ ・Amazon ConnectのCCPで電話をかける https://hacknote.jp/archives/50200/ ・Amazon Translateを使ってSlackで翻訳コマンドを作成 https://hacknote.jp/archives/41652/ ・Amazon Connectで営業時間外の着信をSlackに通知してみた https://hacknote.jp/archives/50254/ Lambda関数はこちらを引用させていただきました。 ・hackjapan/amazonconnect_slack (github) https://github.com/hackjapan/amazonconnect_slack 構成のイメージ図 アプリ間の連携はこのような感じ Amazon Connectの設定 ・インスタンスの作成 1. AWSコンソールにログインし、サービスで「Connect」と検索し、「Amazon Connect」を選択 2. 「今すぐ始める」をクリック 3. 「インスタンスを追加する」をクリック 4. 「AmazonConnect内にユーザーを保存」を選択 5. アクセスURLを任意で記入 6. 姓・名・ユーザー名・パスワード・メールアドレスを入力し管理者アカウントを設定 7. テレフォニーオプションで受信と発信通話の両方にチェック 8. 確認画面で間違いがないかチェックし、「作成」をクリック ・電話番号の取得 1. インスタンスエイリアスの横のアクセスURLから作成したインスタンスにログインする 2. 先ほど設定したユーザー名とパスワードでログインする 3. 左の矢印3つのアイコンから電話番号を選択 4. 「電話番号の取得」をクリック 5. 050から始まるDIDを取得するので、DID(直通ダイヤル)をタブで選択、国を日本にして好きな番号を選ぶ ※03から始まる番号を使用したい場合には、サポートケースを開き、本人確認、会社確認を行った上であれば行える https://aws.amazon.com/jp/blogs/news/amazon-connect-tokyo-region/?_fsi=yHiAp51t ・オペレーション時間の設定 1. 左側アイコンの3つ矢印から「オペレーション時間」を選択、「新しい時間の追加」をクリック 2. 任意の名前と説明を記入し、タイムゾーンを「Japan」に設定 3. (月〜金曜の10〜18時が営業時間の場合は)日曜日と土曜日の箇所にチェックを入れ、「削除」をクリック 4. 平日の開始時間と終了時間の数値を10:00AMと6:00PMにそれぞれ変更し、「新規追加」をクリックする ・キューの設定 1. 左側アイコンの3つ矢印から「キュー」を選択、設定画面に移ったら「新しいキューの追加」をクリック 2. 任意の名前と説明を記入、オペレーションを先ほど設定したオペレーション時間に設定、アウトバウンド発信者ID名に通話相手に表示されたい名前を記入、アウトバウンド発信者番号に先ほど取得した電話番号を記入し、「新しいキューの追加」をクリック ・ルーティングプロファイルの設定 1. 左側アイコンの3つ矢印から「ルーティングプロファイル」を選択、設定画面に移ったら「新しいプロファイルを追加」をクリック 2. 任意の名前と説明を記入、ルーティングプロファイルのキューとデフォルトのアウトバウンドのキューは先ほど作成したキューを選択し、「新しいプロファイルの追加」をクリック ・ユーザーの設定 左側アイコンの人のマークから「ユーザー管理」を選択 ユーザー名の左にチェックを入れ、「編集」をクリック ルーティングプロファイルの欄に先ほど作成したルーティングプロファイルを選択し、「保存」をクリック 後半に続く https://qiita.com/hagiohagi/items/cc81acd131e7a9356da9 後半ではLambdaの設定・SlackApiの設定・AmazonConnectの問い合わせフローの設定をしていきます!
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

# Amazon SNSを用いてAndroid(GMSとHMS)とiOSに対応したプッシュ通知の実装方法10―サーバー(Amazon SNS:プッシュ通知を配信:HMS Part 2)

Amazon SNSを用いてAndroid(GMSとHMS)とiOSに対応したプッシュ通知の実装方法―サーバー(Amazon SNS:プッシュ通知を配信:HMS Part 2) Amazon SNSのトピックに送られたプッシュ配信内容をプッシュサーバーに転送するLambdaのサンプル index.js const Util = require("./util.js"); const PushUtil = require("./pushUtil.js"); exports.handler = function (event, context, callback) { const util = new Util(); const pushUtil = new PushUtil(); let pushData = null; try { // プッシュデータを取得 const dataString = util.getData(event); // ログ出力 console.info("data = " + dataString); // プッシュデータのJSONオブジェクトを生成 pushData = JSON.parse(dataString); } catch (exception) { util.returnErrorResponse(callback, 400, exception); } // プッシュデータの有効性を検証 if (!pushData) { // プッシュデータのJSONオブジェクトが作れない util.returnErrorResponse(callback, 400, "No data"); } else if (!pushData.hasOwnProperty("title")) { // タイトルがない util.returnErrorResponse(callback, 400, "No title"); } else if (!pushData.hasOwnProperty("body")) { // 本文がない util.returnErrorResponse(callback, 400, "No body"); } else if (!pushData.hasOwnProperty("token") || !Array.isArray(pushData.token) || pushData.token.length < 1) { // 送信先がない util.returnErrorResponse(callback, 400, "No push target"); } else { // プッシュサーバーにアクセスするためのプッシュトークンを認証サーバーから取得する const getAccessTokenPromise = pushUtil.createGetAccessTokenPromise(); getAccessTokenPromise.then((result) => { // ログ出力 console.info("https://oauth-login.cloud.huawei.com/oauth2/v3/token = " + result); let accessTokenJson = null; try { accessTokenJson = JSON.parse(result); } catch (exception) { util.returnErrorResponse(callback, 500, exception); } // レスポンスを検証する if (!accessTokenJson) { // レスポンスがない util.returnErrorResponse(callback, 500, "No access token response"); } else if (!accessTokenJson.hasOwnProperty("access_token")) { // アクセストークンがない util.returnErrorResponse(callback, 500, "No access token"); } else if (!accessTokenJson.hasOwnProperty("token_type")) { // アクセストークンの種類が不明 util.returnErrorResponse(callback, 500, "Unknown access token type"); } else if (accessTokenJson.token_type != "Bearer") { // アクセストークンの種類が違う util.returnErrorResponse(callback, 500, "Incorrect access token type"); } else { // アクセストークン const accessToken = accessTokenJson.access_token; // タイトル const pushTitle = pushData.title; // 本文 const pushBody = pushData.body; // 送信対象 const pushToken = pushData.token; // プッシュ通知を送る const pushNotificationPromise = pushUtil.createPushNotificationPromise(accessToken, pushTitle, pushBody, pushToken); pushNotificationPromise.then((result) => { // ログ出力 console.info("https://push-api.cloud.huawei.com/v2/736430079244623135/messages:send = " + result); let pushNotificationJson = null; try { pushNotificationJson = JSON.parse(result); } catch (exception) { util.returnErrorResponse(callback, 500, exception); } // レスポンスを検証する if (!pushNotificationJson) { // レスポンスがない util.returnErrorResponse(callback, 500, "No push notification response"); } else if (!pushNotificationJson.hasOwnProperty("code")) { // 送信結果がない util.returnErrorResponse(callback, 500, "No push notification result"); } else if (pushNotificationJson.result != "80000000" && pushNotificationJson.result != "80100000") { // アクセストークンの種類が不明 util.returnErrorResponse(callback, 500, "Push failed"); } else { util.returnResponse(callback, 200, result); } }).catch((error) => { util.returnErrorResponse(callback, 500, error); }); } }).catch((error) => { util.returnErrorResponse(callback, 500, error); }); } } pushUtil.js const Util = require("./util.js"); const CLIENT_ID = "AppGallery ConnectのMy AppsのApp informationのApp ID"; const CLIENT_SECRET = "AppGallery ConnectのMy AppsのApp informationのApp secret"; module.exports = class MenuContent { constructor() { this.util = new Util(); } createGetAccessTokenPromise() { const hostname = "oauth-login.cloud.huawei.com"; const path = "/oauth2/v3/token"; const method = "POST"; const headers = {}; const data = { grant_type: "client_credentials", client_id: CLIENT_ID, client_secret: CLIENT_SECRET }; return this.util.createRequestPromise_x_www_form_urlencoded(hostname, path, method, headers, data); } createPushNotificationPromise(accessToken, title, body, token) { const hostname = "push-api.cloud.huawei.com"; const path = "/v2/736430079244623135/messages:send"; const method = "POST"; const headers = { Authorization: "Bearer " + accessToken }; const data = { validate_only: false, message: { notification: { title: title, body: body }, android: { notification: { title: title, body: body, click_action: { "type": 1, "intent": "#Intent;compo=com.rvr/.Activity;S.W=U;end" } } }, token: token } }; return this.util.createRequestPromise_json(hostname, path, method, headers, data); } } util.js const https = require('https'); const querystring = require('querystring'); module.exports = class Util { constructor() {} getData(event) { if (event && event.hasOwnProperty("Records") && Array.isArray(event.Records) && event.Records.length > 0 && event.Records[0].hasOwnProperty("Sns") && event.Records[0].Sns.hasOwnProperty("Message") ) { return event.Records[0].Sns.Message; } return null; } createRequestPromise_json(hostname, path, method, headers, data) { return new Promise((resolve, reject) => { try { const stringData = JSON.stringify(data); headers["Content-Type"] = "application/json"; const options = { hostname: hostname, path: path, method: method, rejectUnauthorized: false, headers: headers }; const request = https.request(options, (response) => { let data = ''; response.on('data', (chunk) => { data += chunk; }); response.on('end', () => { resolve(data); }); }).on("error", (error) => { reject(error); }); request.write(stringData); request.end(); } catch (exception) { reject(exception); } }); } createRequestPromise_x_www_form_urlencoded(hostname, path, method, headers, data) { return new Promise((resolve, reject) => { try { const postData = querystring.stringify(data); headers["Content-Type"] = "application/x-www-form-urlencoded"; headers["Content-Length"] = postData.length; const options = { hostname: hostname, path: path, method: method, headers: headers }; const request = https.request(options, (response) => { let data = ''; response.on('data', (chunk) => { data += chunk; }); response.on('end', () => { resolve(data); }); }).on("error", (error) => { reject(error); }); request.write(postData); request.end(); } catch (exception) { reject(exception); } }); } returnResponse(callback, statusCode, body) { if (callback && callback instanceof Function) { const response = { 'statusCode': statusCode, 'headers': { 'Content-type': 'application/json' }, 'body': JSON.stringify(body) } callback(null, response); } } returnErrorResponse(callback, statusCode, error) { const body = { error: error }; this.returnResponse(callback, statusCode, body); } } GitHub 参考 Amazon SNSを用いてAndroid(GMSとHMS)とiOSに対応したプッシュ通知の実装方法 1―概要 2―クライアント(Android-GMS) 3―クライアント(Android-HMS) 4―クライアント(iOS-APNS) 5―サーバー(Amazon SNS:プッシュトークンの保存) 6―サーバー(Amazon SNS:プッシュトークンの管理:HMS) 7―サーバー(Amazon SNS:プッシュトークンの保存:HMS) 8―サーバー(Amazon SNS:プッシュ通知を配信) 9―サーバー(Amazon SNS:プッシュ通知を配信:HMS) 10―サーバー(Amazon SNS:プッシュ通知を配信:複数のデバイスに同時配信)
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Amazon SNSを用いてAndroid(GMSとHMS)とiOSに対応したプッシュ通知の実装方法9―サーバー(Amazon SNS:プッシュ通知を配信:HMS Part 1)

Amazon SNSを用いてAndroid(GMSとHMS)とiOSに対応したプッシュ通知の実装方法―サーバー(Amazon SNS:プッシュ通知を配信:HMS Part 1) LambdaとAPI Gatewayで配信用のAPIを作成します。 Lambdaでは、aws-sdkライブラリを使って、DynamoDBに登録したHMSのトークンを取得し、それを対象にして、プッシュ配信内容をAmazon SNSのトピックに送ります。対象のAmazon SNSトピックをトリガーとして、さらに別のLambdaを起動し、プッシュ配信内容をプッシュサーバーに送ります。 プッシュ配信内容をAmazon SNSのトピックに送るLambdaのサンプル index.js const PushUtil = require("./pushUtil.js"); exports.handler = function (event, context, callback) { const pushUtil = new PushUtil(); let pushData = event; const promiseArray = []; // Amazon SNSにアクセスするためのPromiseを作成する const promise = pushUtil.createHmsPushPromise(pushData.HMS, 'Amazon SNSのトピックのARN'); promise.then((result) => { // レスポンスを返す callback(null, result); }).catch((error) => { callback(null, { error : error }); }); } pushUtil.js const TokenUtil = require("./tokenUtil.js"); // AWS SDKをロードする const AWS = require('aws-sdk'); // リージョンを設定する AWS.config.update({region: 'ap-northeast-1'}); // SNSサービスのオブジェクトを生成 const sns = new AWS.SNS(); module.exports = class PushUtil { constructor() { } createHmsPushPromise(content, topicArn) { return new Promise((resolve, reject) => { const tokenUtil = new TokenUtil(); const getTokenPromise = tokenUtil.createGetTokenPromise(); getTokenPromise.then((result) => { if (result.hasOwnProperty("Items") && Array.isArray(result.Items)) { content.token = result.Items.map(function(value) { if (value.hasOwnProperty("token") && value.token.hasOwnProperty("S")) { return value.token.S; } return ""; }); } // プッシュのパラメータを設定する const params = { // プッシュ内容 Message: JSON.stringify(content), // 対象トピック TopicArn: topicArn }; sns.publish(params, (error, data) => { if (error) { reject(error); return; } resolve(data); }); }).catch((error) => { reject(error); }); }); } } tokenUtil.js // AWS SDKをロードする const AWS = require('aws-sdk'); // リージョンを設定する AWS.config.update({region: 'ap-northeast-1'}); // DynamoDBサービスのオブジェクトを生成 const ddb = new AWS.DynamoDB(); module.exports = class TokenUtil { constructor() { } createGetTokenPromise() { return new Promise((resolve, reject) => { const params = { TableName: 'token_info' }; ddb.scan(params, function(error, data) { if (error) { reject(error); return; } resolve(data); }); }); } } GitHub 参考 Amazon SNSを用いてAndroid(GMSとHMS)とiOSに対応したプッシュ通知の実装方法 1―概要 2―クライアント(Android-GMS) 3―クライアント(Android-HMS) 4―クライアント(iOS-APNS) 5―サーバー(Amazon SNS:プッシュトークンの保存) 6―サーバー(Amazon SNS:プッシュトークンの管理:HMS) 7―サーバー(Amazon SNS:プッシュトークンの保存:HMS) 8―サーバー(Amazon SNS:プッシュ通知を配信) 9―サーバー(Amazon SNS:プッシュ通知を配信:HMS) 10―サーバー(Amazon SNS:プッシュ通知を配信:複数のデバイスに同時配信)
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Amazon SNSを用いてAndroid(GMSとHMS)とiOSに対応したプッシュ通知の実装方法8―サーバー(Amazon SNS:プッシュ通知を配信)

Amazon SNSを用いてAndroid(GMSとHMS)とiOSに対応したプッシュ通知の実装方法―サーバー(Amazon SNS:プッシュ通知を配信) LambdaとAPI Gatewayで配信用のAPIを作成します。 Lambdaでは、aws-sdkライブラリを使って、プッシュ配信内容をAmazon SNSのトピックに送ります。 Lambdaのサンプル index.js // AWS SDKをロードする const AWS = require('aws-sdk'); // リージョンを設定する AWS.config.update({region: 'ap-northeast-1'}); // SNSサービスのオブジェクトを生成 const sns = new AWS.SNS(); exports.handler = function (event, context, callback) { // プッシュのパラメータを設定する const params = { // プッシュ内容 Message: JSON.stringify({ default: event.default, // デフォルトデータ GCM: event.GCM, // FCMデータ APNS: event.APNS // APNSデータ }), // 配信プロトコルごとにカスタムペイロードに設定する MessageStructure: "json", // 対象トピック TopicArn: 'Amazon SNSのトピックのARN' }; // Amazon SNSにアクセスするためのPromiseを作成する const promise = new Promise((resolve, reject) => { sns.publish(params, (error, data) => { if (error) { reject(error); return; } resolve(data); }); }); promise.then((result) => { // レスポンスを返す callback(null, result); }).catch((error) => { callback(null, { error : error }); }); } GitHub 参考 Amazon SNSを用いてAndroid(GMSとHMS)とiOSに対応したプッシュ通知の実装方法 1―概要 2―クライアント(Android-GMS) 3―クライアント(Android-HMS) 4―クライアント(iOS-APNS) 5―サーバー(Amazon SNS:プッシュトークンの保存) 6―サーバー(Amazon SNS:プッシュトークンの管理:HMS) 7―サーバー(Amazon SNS:プッシュトークンの保存:HMS) 8―サーバー(Amazon SNS:プッシュ通知を配信) 9―サーバー(Amazon SNS:プッシュ通知を配信:HMS) 10―サーバー(Amazon SNS:プッシュ通知を配信:複数のデバイスに同時配信)
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Amazon SNSを用いてAndroid(GMSとHMS)とiOSに対応したプッシュ通知の実装方法7―サーバー(Amazon SNS:プッシュトークンの保存:HMS)

Amazon SNSを用いてAndroid(GMSとHMS)とiOSに対応したプッシュ通知の実装方法―サーバー(Amazon SNS:プッシュトークンの保存:HMS) Amazon SNSではHMSのプッシュ通知を直接にサポートしていないので、プラットフォームアプリケーションの作成もサブスクリプションの作成もいりません。 (※後にプッシュ通知を配信するときにサブスクリプションの作成はいります) AWS LambdaでDynamoDBにプッシュトークンを登録する方法 index.js // AWS SDKをロードする const AWS = require('aws-sdk'); // リージョンを設定する AWS.config.update({region: 'ap-northeast-1'}); // DynamoDBサービスのオブジェクトを生成 const ddb = new AWS.DynamoDB(); exports.handler = async (event) => { const response = {}; // 入力データを検証 if (!event) { response.error = "No data"; return response; } // 入力データを検証(トークンがない) if (!event.hasOwnProperty("token")) { response.error = "No token"; return response; } // 入力データを検証(トークンがない) if (!event.hasOwnProperty("token_type")) { response.error = "No token type"; return response; } const token = event.token; if (event.token_type == "HMS") { const params = { TableName: 'token_info', Item: { 'token' : {S: token} } }; // DynamoDBへ書き込む await ddb.putItem(params, function(err, data) { if (err) { response["error"] = err; } else { response["result"] = data; } }).promise(); } else { response.error = "Invalid token type"; } return response; }; GitHub 参考 Amazon SNSを用いてAndroid(GMSとHMS)とiOSに対応したプッシュ通知の実装方法 1―概要 2―クライアント(Android-GMS) 3―クライアント(Android-HMS) 4―クライアント(iOS-APNS) 5―サーバー(Amazon SNS:プッシュトークンの保存) 6―サーバー(Amazon SNS:プッシュトークンの管理:HMS) 7―サーバー(Amazon SNS:プッシュトークンの保存:HMS) 8―サーバー(Amazon SNS:プッシュ通知を配信) 9―サーバー(Amazon SNS:プッシュ通知を配信:HMS) 10―サーバー(Amazon SNS:プッシュ通知を配信:複数のデバイスに同時配信)
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Amazon SNSを用いてAndroid(GMSとHMS)とiOSに対応したプッシュ通知の実装方法6―サーバー(Amazon SNS:プッシュトークンの管理:HMS)

Amazon SNSを用いてAndroid(GMSとHMS)とiOSに対応したプッシュ通知の実装方法―サーバー(Amazon SNS:プッシュトークンの管理:HMS) Amazon SNSではHMSのプッシュ通知を直接にサポートしていないので、HMSのプッシュトークンの管理を自前で管理しなければなりません。 管理方法 DynamoDBを使います。カラムは一つだけで大丈夫です。 参考 Amazon SNSを用いてAndroid(GMSとHMS)とiOSに対応したプッシュ通知の実装方法 1―概要 2―クライアント(Android-GMS) 3―クライアント(Android-HMS) 4―クライアント(iOS-APNS) 5―サーバー(Amazon SNS:プッシュトークンの保存) 6―サーバー(Amazon SNS:プッシュトークンの管理:HMS) 7―サーバー(Amazon SNS:プッシュトークンの保存:HMS) 8―サーバー(Amazon SNS:プッシュ通知を配信) 9―サーバー(Amazon SNS:プッシュ通知を配信:HMS) 10―サーバー(Amazon SNS:プッシュ通知を配信:複数のデバイスに同時配信)
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Amazon SNSを用いてAndroid(GMSとHMS)とiOSに対応したプッシュ通知の実装方法5―サーバー(Amazon SNS:プッシュトークンの保存)

Amazon SNSを用いてAndroid(GMSとHMS)とiOSに対応したプッシュ通知の実装方法―サーバー(Amazon SNS:プッシュトークンの保存) Amazon SNSの準備 プラットフォームアプリケーションの作成 サブスクリプションの作成 上記の2つについて、Amazon SNSを利用してモバイルプッシュ通知を送信するやり方ーコンソール利用をご参照ください。 AWS Lambdaでプラットフォームアプリケーションにプッシュトークンを登録する方法 index.js // AWS SDKをロードする const AWS = require('aws-sdk'); // リージョンを設定する AWS.config.update({region: 'ap-northeast-1'}); // SNSサービスのオブジェクトを生成 const sns = new AWS.SNS(); exports.handler = async (event) => { const response = {}; // 入力データを検証 if (!event) { response.error = "No data"; return response; } // 入力データを検証(トークンがない) if (!event.hasOwnProperty("token")) { response.error = "No token"; return response; } // 入力データを検証(トークンがない) if (!event.hasOwnProperty("token_type")) { response.error = "No token type"; return response; } const token = event.token; // FCMのプッシュトークン if (event.token_type == "FCM") { var params = { PlatformApplicationArn: '作成したFCMのプラットフォームアプリケーションのARN', Token: token }; await sns.createPlatformEndpoint(params, function(err, data) { if (err) { console.log(err, err.stack); // an error occurred response["error"] = err; } else { console.log(data); // successful response response["result"] = data; } }).promise(); } else if (event.token_type == "APNS") { // APNSのプッシュトークン var params = { PlatformApplicationArn: '作成したAPNSのプラットフォームアプリケーションのARN', Token: token }; await sns.createPlatformEndpoint(params, function(err, data) { if (err) { console.log(err, err.stack); // an error occurred response["error"] = err; } else { console.log(data); // successful response response["result"] = data; } }).promise(); } else { response.error = "Invalid token type"; } return response; }; GitHub 参考 Amazon SNSを用いてAndroid(GMSとHMS)とiOSに対応したプッシュ通知の実装方法 1―概要 2―クライアント(Android-GMS) 3―クライアント(Android-HMS) 4―クライアント(iOS-APNS) 5―サーバー(Amazon SNS:プッシュトークンの保存) 6―サーバー(Amazon SNS:プッシュトークンの管理:HMS) 7―サーバー(Amazon SNS:プッシュトークンの保存:HMS) 8―サーバー(Amazon SNS:プッシュ通知を配信) 9―サーバー(Amazon SNS:プッシュ通知を配信:HMS) 10―サーバー(Amazon SNS:プッシュ通知を配信:複数のデバイスに同時配信)
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Amazon SNSを用いてAndroid(GMSとHMS)とiOSに対応したプッシュ通知の実装方法4―クライアント(iOS-APNS)

Amazon SNSを用いてAndroid(GMSとHMS)とiOSに対応したプッシュ通知の実装方法―クライアント(iOS-APNS) iOSデバイスではAPNSでプッシュ通知を配信できます。クライアント側の実装は https://developer.apple.com/documentation/usernotifications/registering_your_app_with_apns をご参照いただければと思います。ここではAWSとの連携部分を重点的に紹介します。 AWSとの連携要点 プッシュトークンは以下の箇所で返ってきます。 func application(_ application: UIApplication, didRegisterForRemoteNotificationsWithDeviceToken deviceToken: Data) { let tokenParts = deviceToken.map { data -> String in return String(format: "%02.2hhx", data) } let token = tokenParts.joined() // ここでプッシュトークンをAWSに渡します } プッシュトークンを受け取って、AWSに送ります。 参考 Amazon SNSを用いてAndroid(GMSとHMS)とiOSに対応したプッシュ通知の実装方法 1―概要 2―クライアント(Android-GMS) 3―クライアント(Android-HMS) 4―クライアント(iOS-APNS) 5―サーバー(Amazon SNS:プッシュトークンの保存) 6―サーバー(Amazon SNS:プッシュトークンの管理:HMS) 7―サーバー(Amazon SNS:プッシュトークンの保存:HMS) 8―サーバー(Amazon SNS:プッシュ通知を配信) 9―サーバー(Amazon SNS:プッシュ通知を配信:HMS) 10―サーバー(Amazon SNS:プッシュ通知を配信:複数のデバイスに同時配信)
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Amazon SNSを用いてAndroid(GMSとHMS)とiOSに対応したプッシュ通知の実装方法3―クライアント(Android-HMS)

Amazon SNSを用いてAndroid(GMSとHMS)とiOSに対応したプッシュ通知の実装方法―クライアント(Android-HMS) HMSデバイスでは、HMS Push Kitでプッシュ通知を配信できます。クライアント側の実装は https://developer.huawei.com/consumer/jp/doc/development/HMSCore-Guides/android-client-dev-0000001050042041 をご参照いただければと思います。ここではAWSとの連携部分を重点的に紹介します。 AWSとの連携要点 プッシュトークンは以下の2箇所で返ってきます。 class MainService: HmsMessageService() { override fun onNewToken(token: String?) { super.onNewToken(token) // ここでプッシュトークンをAWSに渡します } } val token = HmsInstanceId.getInstance(context).getToken(appId, "HCM") if (token.isNotEmpty()) { // ここでプッシュトークンをAWSに渡します } この2箇所でプッシュトークンを受け取って、AWSに送ります。 仮にAWSでLambdaとAPI Gatewayで次のようなAPIを作ったとします。 API:https://your.domain.amazonaws.com/add-push-token メソッド:POST ヘッダー:Context-Type : application/json リクエスト: { "token": "Your Token", "token_type": "HMS" } そうしたら、クライアント側では、次のようにデータを送ります。 fun sendPushToken( context: Context, pushToken: String ) { val queue = Volley.newRequestQueue(context) val param = JSONObject().apply { put("token", pushToken) put("token_type", "FCM") } val postRequest: JsonObjectRequest = object : JsonObjectRequest( "https://your.domain.amazonaws.com/add-push-token", param, object : Response.Listener<JSONObject>{ override fun onResponse(response: JSONObject?) { // プッシュトークンの送信が成功 } }, object : Response.ErrorListener{ override fun onErrorResponse(error: VolleyError?) { // プッシュトークンの送信が失敗 } }) { } queue.add(postRequest) } 参考 Amazon SNSを用いてAndroid(GMSとHMS)とiOSに対応したプッシュ通知の実装方法 1―概要 2―クライアント(Android-GMS) 3―クライアント(Android-HMS) 4―クライアント(iOS-APNS) 5―サーバー(Amazon SNS:プッシュトークンの保存) 6―サーバー(Amazon SNS:プッシュトークンの管理:HMS) 7―サーバー(Amazon SNS:プッシュトークンの保存:HMS) 8―サーバー(Amazon SNS:プッシュ通知を配信) 9―サーバー(Amazon SNS:プッシュ通知を配信:HMS) 10―サーバー(Amazon SNS:プッシュ通知を配信:複数のデバイスに同時配信)
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Amazon SNSを用いてAndroid(GMSとHMS)とiOSに対応したプッシュ通知の実装方法2―クライアント(Android-GMS)

Amazon SNSを用いてAndroid(GMSとHMS)とiOSに対応したプッシュ通知の実装方法―クライアント(Android-GMS) グーグルモバイルサービスが入っているデバイスでは、Firebase Cloud Messaging(FCM)でプッシュ通知を配信できます。クライアント側の実装は https://firebase.google.com/docs/cloud-messaging/android/client をご参照いただければと思います。ここではAWSとの連携部分を重点的に紹介します。 AWSとの連携要点 プッシュトークンは以下の2箇所で返ってきます。 class MyFirebaseMessagingService : FirebaseMessagingService() { fun onNewToken(registrationToken: String) { // ここでプッシュトークンをAWSに渡します } } FirebaseMessaging.getInstance().token.addOnCompleteListener(OnCompleteListener { task -> if (!task.isSuccessful) { return } val token = task.result // ここでプッシュトークンをAWSに渡します }) この2箇所でプッシュトークンを受け取って、AWSに送ります。 仮にAWSでLambdaとAPI Gatewayで次のようなAPIを作ったとします。 API:https://your.domain.amazonaws.com/add-push-token メソッド:POST ヘッダー:Context-Type : application/json リクエスト: { "token": "Your Token", "token_type": "FCM" } そうしたら、クライアント側では、次のようにデータを送ります。 fun sendPushToken( context: Context, pushToken: String ) { val queue = Volley.newRequestQueue(context) val param = JSONObject().apply { put("token", pushToken) put("token_type", "FCM") } val postRequest: JsonObjectRequest = object : JsonObjectRequest( "https://your.domain.amazonaws.com/add-push-token", param, object : Response.Listener<JSONObject>{ override fun onResponse(response: JSONObject?) { // プッシュトークンの送信が成功 } }, object : Response.ErrorListener{ override fun onErrorResponse(error: VolleyError?) { // プッシュトークンの送信が失敗 } }) { } queue.add(postRequest) } 参考 Amazon SNSを用いてAndroid(GMSとHMS)とiOSに対応したプッシュ通知の実装方法 1―概要 2―クライアント(Android-GMS) 3―クライアント(Android-HMS) 4―クライアント(iOS-APNS) 5―サーバー(Amazon SNS:プッシュトークンの保存) 6―サーバー(Amazon SNS:プッシュトークンの管理:HMS) 7―サーバー(Amazon SNS:プッシュトークンの保存:HMS) 8―サーバー(Amazon SNS:プッシュ通知を配信) 9―サーバー(Amazon SNS:プッシュ通知を配信:HMS) 10―サーバー(Amazon SNS:プッシュ通知を配信:複数のデバイスに同時配信)
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Amazon SNSを用いてAndroid(GMSとHMS)とiOSに対応したプッシュ通知の実装方法1―概要

Amazon SNSを用いてAndroid(GMSとHMS)とiOSに対応したプッシュ通知の実装方法―概要 プッシュ通知の実装にあたって、一番大きな問題点は複数種類のデバイス対応です。 たとえば、次のようなデバイスがあるとします。 Android(GMS) Android(HMS) iOS FireOS 通常のやり方ですと、 Android(GMS)のクライアント側のFCMの実装 Android(HMS)のクライアント側のHMS Push Kitの実装 iOSのクライアント側のAPNSの実装 FireOSのクライアント側のADMの実装 Android(GMS)のサーバー側のFCMの対応 Android(HMS)のサーバー側のHMS Push Kitの対応 iOSのサーバー側のAPNSの対応 FireOSのサーバー側のADMの対応 があります。 これですと、実装がかなり大変になります。 実装の手間を省くのに、Amazon SNSを使うことが一つの解決方法です。 Amazon SNSのソリューション Amazon SNSは次のデバイスのプッシュ通知に対応しています。 Amazon Device Messaging (ADM) Apple プッシュ通知サービス (APNS) Firebase クラウドメッセージング (FCM) Windows プッシュ通知サービス (WNS): Windows 8 以降と Windows Phone 8.1 以降が対象 Microsoft プッシュ通知サービス (MPNS): Windows Phone 7 以降が対象 Baidu Cloud Push: 中国国内の Android デバイスが対象 Android(HMS)には直接に対応していませんが、Amazon SNSのAWS Lambdaのサブスクリプション機能とAWS Lambdaを組み合わせれば、対応が可能になります。 ソリューション図 Android(GMS)やiOS等 Android(HMS) 参考 Amazon SNSを用いてAndroid(GMSとHMS)とiOSに対応したプッシュ通知の実装方法 1―概要 2―クライアント(Android-GMS) 3―クライアント(Android-HMS) 4―クライアント(iOS-APNS) 5―サーバー(Amazon SNS:プッシュトークンの保存) 6―サーバー(Amazon SNS:プッシュトークンの管理:HMS) 7―サーバー(Amazon SNS:プッシュトークンの保存:HMS) 8―サーバー(Amazon SNS:プッシュ通知を配信) 9―サーバー(Amazon SNS:プッシュ通知を配信:HMS) 10―サーバー(Amazon SNS:プッシュ通知を配信:複数のデバイスに同時配信)
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

DynatraceによるAWSの監視の始め方

はじめに Dynatraceと言えばアプリケーションモニタリング管理ツールとして有名ですが、AWSなどのクラウドインフラを監視することも簡単に行うことができます。 完全に自動化されたAIがAWSにおけるクラウドインフラ環境を完全に可視化することが可能です。 絶えず変化・更新されるクラウドインフラ環境においてDynatraceは自動でその更新に追従します。またOneAgentというエージェントをEC2などのホスト上に展開することでAIエンジンは問題点を見つけるだけでなくその解決策までも提供してくれます。 これらの機能により、従来の運用監視に割かれていたリソースをより生産的な仕事に割り振ることが可能となりビジネスの拡大に繋げることが可能となります。 本記事では、DynatraceによるAWSの監視方法について紹介していきたいと思います。 15日間の無料トライアルを利用することができるので、自分の環境でも簡単に試してみることができます。 Dynatraceフリートライアル Dynatraceで監視可能なAWSリソース DynatraceとAWSが連携することによるメリットについては以下の公式サイトに詳しく書かれているのでそちらに譲りたいと思います。 AWS監視|Dynatrace DynatraceではEC2インスタンスだけでなくAmazon ECS、AWS Lambda、AWS Fargate、Amazon EKSをはじめとした多くのサービスを監視することが可能です。 サポートしているサービスについては以下のサイトから確認することが可能です。 AWS supporting services 設定の流れ 大まかな流れは以下のようになります。 AWS監視用ポリシーの作成 アクセス方法の選定 アクセスキーによるアクセス ロールベースによるアクセス タグを用いた監視リソースの設定(オプション) 監視のための操作は基本的にはAWSのコンソールが中心であり、Dynatrace側で必要な設定は多くありません。 AWS監視用ポリシーの作成 マネジメントコンソールからIAMのページを開きます。 ポリシーのページに行き、ポリシーの作成をクリックします。 JSONタブを選び、以下のjsonポリシーを貼り付けます。 JSONポリシー { "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": [ "apigateway:GET", "appstream:DescribeFleets", "appsync:ListGraphqlApis", "athena:ListWorkGroups", "autoscaling:DescribeAutoScalingGroups", "cloudformation:ListStackResources", "cloudfront:ListDistributions", "cloudhsm:DescribeClusters", "cloudsearch:DescribeDomains", "cloudwatch:GetMetricData", "cloudwatch:GetMetricStatistics", "cloudwatch:ListMetrics", "codebuild:ListProjects", "datasync:ListTasks", "dax:DescribeClusters", "directconnect:DescribeConnections", "dms:DescribeReplicationInstances", "dynamodb:ListTables", "dynamodb:ListTagsOfResource", "ec2:DescribeAvailabilityZones", "ec2:DescribeInstances", "ec2:DescribeNatGateways", "ec2:DescribeSpotFleetRequests", "ec2:DescribeTransitGateways", "ec2:DescribeVolumes", "ec2:DescribeVpnConnections", "ecs:ListClusters", "eks:ListClusters", "elasticache:DescribeCacheClusters", "elasticbeanstalk:DescribeEnvironmentResources", "elasticbeanstalk:DescribeEnvironments", "elasticfilesystem:DescribeFileSystems", "elasticloadbalancing:DescribeInstanceHealth", "elasticloadbalancing:DescribeListeners", "elasticloadbalancing:DescribeLoadBalancers", "elasticloadbalancing:DescribeRules", "elasticloadbalancing:DescribeTags", "elasticloadbalancing:DescribeTargetHealth", "elasticmapreduce:ListClusters", "elastictranscoder:ListPipelines", "es:ListDomainNames", "events:ListEventBuses", "firehose:ListDeliveryStreams", "fsx:DescribeFileSystems", "gamelift:ListFleets", "glue:GetJobs", "inspector:ListAssessmentTemplates", "kafka:ListClusters", "kinesis:ListStreams", "kinesisanalytics:ListApplications", "kinesisvideo:ListStreams", "lambda:ListFunctions", "lambda:ListTags", "lex:GetBots", "logs:DescribeLogGroups", "mediaconnect:ListFlows", "mediaconvert:DescribeEndpoints", "mediapackage-vod:ListPackagingConfigurations", "mediapackage:ListChannels", "mediatailor:ListPlaybackConfigurations", "opsworks:DescribeStacks", "qldb:ListLedgers", "rds:DescribeDBClusters", "rds:DescribeDBInstances", "rds:DescribeEvents", "rds:ListTagsForResource", "redshift:DescribeClusters", "robomaker:ListSimulationJobs", "route53:ListHostedZones", "route53resolver:ListResolverEndpoints", "s3:ListAllMyBuckets", "sagemaker:ListEndpoints", "sns:ListTopics", "sqs:ListQueues", "storagegateway:ListGateways", "sts:GetCallerIdentity", "swf:ListDomains", "tag:GetResources", "tag:GetTagKeys", "transfer:ListServers", "workmail:ListOrganizations", "workspaces:DescribeWorkspaces" ], "Resource": "*" } ] } ポリシーの名前にはわかりやすい名称(Dynatrace_monitoring_policyなど)を設定します。 ポリシーの作成をクリックし、ポリシーを作成します。 アクセス方法の選定 Dynatraceの環境からAWSへアクセスする方法については以下の2つがあります。 Dynatrace用のアクセスキーを利用したアクセス(キーベースアクセス) Dynatrace用のロールを利用したアクセス(ロールベースアクセス) 本記事では、ロールベースアクセスによるアクセス方法について試したいと思います。 すでにDynatrace を利用していて、AWS EC2にActiveGateを展開している方もいらっしゃるかもしれませんが、今回はActiveGateがないという前提で進めたいと思います。 外部IDの取得 DynatraceのAWSアカウントにロールを付与するため、外部IDを取得します。 DynatraceのGUIにログインをし、左側ナビゲーションパネルの一番下にあるSettingsをクリックします。 Settingsメニューが表示されるのでCloud and virtualizationを選び、AWSをクリックします。 Connect new instanceをクリックします。 Authentication methodをRole-based authenticationに変更し、Tokenの横のCopyをクリックします。 showをクリックすることで実際の値を確認することも可能です。 この画面は後ほど戻ってきますので、このままにしておきます。 ロールの作成 再び「IAM」のページを開きます。 ロールのページに行き、「ロールの作成」をクリックします。 「別のAWSアカウント」を選択し、アカウントIDにはDynatraceのアカウントID(509560245411)を入力し、外部IDが必要にチェックを入れ Dynatraceの画面でCopyした外部IDを貼り付けます。 先ほど作成ポリシーをロールにアタッチします。タグについては任意で設定します。 ロール名にはわかりやすい名称(Dynatrace_monitoring_roleなど)を設定します。 ロールの作成をクリックし、ロールを作成します。 タグの追加 DynatraceではAWSリソースの全てを監視することも可能ですが、監視対象を本番環境だけにしたいことがあると思います。その場合はリソースに任意のタグ(dynatrace_monitoringなど)を追加します。 AWSアカウントとDynatraceの接続 Dynatraceの画面に戻ります。 Connection nameにわかりやすい名前を付けます。 IAM role that Dynatrace should use to get monitoring dataに先ほどAWSで作成したロールを指定します。 Your Amazon account IDにはアクセスしたいAWSアカウントIDを指定します。 Resources to be monitoredには全てを指定するか特定のタグが付いているリソースのみを対象にするか選ぶことができます。 Monitor resources selected by tagsを選んだ場合は、リソースに指定したタグのKeyとValueを指定します。 全て設定が完了したらConnectをクリックします。 問題なく接続ができたら左側のナビゲーションパネルからMonitor AWSを選択することで先ほど登録したものが表示されるはずです。 さらに表示されたタイルをクリックすることで詳細情報が確認できます。 お疲れ様でした。これでDynatraceによるAWSの監視が可能になりました! まとめ 今回はDynatraceによるAWSの監視の始め方について紹介しました。 複雑な操作なしに非常に簡単に監視を始めることができるのがお判りいただけたかと思います。 次回はさらに個別のリソースに対してDynatraceではどのような情報を確認することができるかなどを紹介したいと思います。 最後に Dynatraceは5月11日(火)、12日(水)に行われるAWS Summit Onlineにグローバルスポンサーとして参加いたします。 バーチャルブースでは、可観測性、自動化、AIに関するホワイトペーパー、デモ動画などをご覧いただくことができます。 AWSクラウドの運用とトラブル対応の効率化 お客様導入事例 AIOpsの正しい活用法 AWSクラウド移行のためのソフトウェアインテリジェンス ぜひAWS Summit Online Dynatrace Virtual Booth までお越しください。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Amazon Personalize の事例を紹介してみる

はじめに 突然ですが、レコメンデーションという言葉を知っていますでしょうか? 簡単に説明すると、ECサイトなどで顧客の訪問履歴や購買履歴などのデータに基づき、顧客に自動的に商品やサービスなどをすすめる仕組みのことをレコメンデーションと呼びます。 まあ、通販サイトを利用してる時に「あなたにおすすめ」や「この商品をチェックした人はこんな商品もチェックしています」という感じで表示されてる商品リスト的なあれです。 ところで、この仕組みを自社サイトなどに導入するのって大変そうに感じないでしょうか。。。? 安心してください!Amazon Personalize を利用すれば、クイックにレコメンデーションの導入を実現できます。プログラミングも必要ありません! 今回はそんなAmazon Personalize を自社サービスに導入したことでユーザーエクスペリエンス向上に成功した事例を2つほどご紹介いたします。 Lotte Mart 引用元 Lotte Mart とは? さまざまな食料品、衣料品、おもちゃ、電化製品などを販売する韓国の大手スーパーマーケットです。 ユースケース Amazon Personalize で顧客の嗜好を分析し、顧客ごとに最適化されたクーポンを発行しました。 課題 従来利用していたレコメンデーションシステムは繰り返し購入を促進する効果はありましたが、下記のような課題がありました。 新商品の購買を促すことができない 顧客のニーズの変化に対応できない 分析エンジンの構築にリソースがかかりすぎる 成果 新製品の購入頻度が1.7倍に増加 クーポンの利用率が2倍以上に増加 全体の開発時間を半分に短縮 StockX 引用元 StockX とは? スニーカーやストリートウェアなどの商品を取り扱うECサイトを運営する企業です。 ユースケース サイト上に顧客ごとにおすすめの商品を表示することで、ユーザーエクスペリエンスの向上を目指しました。 課題 当初、StockX 社内では下記のような課題を抱えていました。 製品への関心の多様性が急速に広まっていった 最新のユーザーの嗜好をレコメンデーションに反映したかった 成果 レコメンデーションモデルの構築後、A / Bテストを実施することで効果測定を実施しました。テストの結果、下記のようなマーケティング効果がみられました。 全体的な顧客エンゲージメントが50%増加 人気のある商品一覧のクリック率をおすすめ商品一覧のクリック率が上回った ユーザーのアクションから推奨事項を数秒で変更できるようになった おわりに 以上、代表的な事例をご紹介させていただきました。 今回ご紹介させていただいた事例以外にも、 Amazon Personalize はYamaha、NAVITIME、Subway、Domino's Pizza などでも利用されています。 あなたも試してみませんか?
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS CodeBuildをGitHubリポジトリで動かしてHello, World!

AWSのCodeBuildをGitHubリポジトリと連携させて、ビルドジョブを動かしてみました。 前回の記事Google Cloud BuildをGitHubリポジトリで動かしてHello, World!のAWS版です。 この記事にあるスクショは、白い背景はAWSのマネジメントコンソールで、黒い背景はGitHubのページです。 前提 AWSのアカウントが存在する GitHubアカウントが存在する GitHub上にCodeBuildを試すためのリポジトリが存在する 手順 CodeBuildをGitHubリポジトリに接続し、Build project作成 ジョブの内容を記述するファイル buildspec.yml を作成 pushしてジョブを実行してみる CodeBuildをGitHubリポジトリに接続し、Build project作成 マネジメントコンソールのCodeBuildの画面で、「Create build project」ボタンをクリックします。 Project nameは適当な名前を付けます。 Source providerでGitHubを選択します。 すると、OAuthとpersonal access tokenの2つの接続方法が選択できます。 OAuthを選択して、「Connect to GitHub」ボタンをクリックすると、GitHubのページが開きます。 「Authorize」ボタンを押して、CodeBuildとGitHubの接続を承認します。すると、CodeBuildの画面に戻ってきます。 「Repository in my GitHub account」を選択します。「Public repository」では、git pushをトリガーにしてビルドを動かすことができません。Repository URLはGitHubのURLを入力します。(前回のGoogle Cloud Buildでのサンプルを使いまわしました) Webhookにチェックを入れると、git pushがトリガーになります。 その下のEnvironmentのコーナーではOSのイメージなどを聞かれますので、適当に選択します。 さらにその下は、サービスロール、動作環境のVPC、証明書、インスタンスの大きさなどの指定が続きます。 入力が終わったら、一番下の「Create build project」ボタンをクリックして、作成完了です。 GitHub側の設定ページ GitHubのレポジトリのページを見たら、Settings → Webhooks にCoodeBuildの設定が現れてました。 IAM Role 自動で作成されるIAM Roleは、デフォルトで codebuild-build-sample-role という名前で、以下の権限になってました。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Resource": [ "arn:aws:logs:ap-northeast-1:123456789012:log-group:/aws/codebuild/sample-project", "arn:aws:logs:ap-northeast-1:123456789012:log-group:/aws/codebuild/sample-project:*" ], "Action": [ "logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents" ] }, { "Effect": "Allow", "Resource": [ "arn:aws:s3:::codepipeline-ap-northeast-1-*" ], "Action": [ "s3:PutObject", "s3:GetObject", "s3:GetObjectVersion", "s3:GetBucketAcl", "s3:GetBucketLocation" ] }, { "Effect": "Allow", "Action": [ "codebuild:CreateReportGroup", "codebuild:CreateReport", "codebuild:UpdateReport", "codebuild:BatchPutTestCases", "codebuild:BatchPutCodeCoverages" ], "Resource": [ "arn:aws:codebuild:ap-northeast-1:123456789012:report-group/sample-project-*" ] } ] } ジョブの内容を記述するファイル buildspec.yml を作成 ジョブの内容を記述するファイルはYAMLでリポジトリの中に作成します。 buildspec.yml という名前で以下の内容のYAMLを作成します。 version: 0.2 phases: install: commands: - echo "Hello, World! (phase=install)" pre_build: commands: - echo "Hello, World! (phase=pre_build)" build: commands: - echo "Hello, World! (phase=build)" - ls -al post_build: commands: - echo "Hello, World! (phase=post_build)" buildspec.yml の仕様は以下のページに書いてあります。 Build specification reference for CodeBuild - AWS CodeBuild pushしてジョブを実行してみる このYAMLファイルをgit commitし、GitHubにpushすると、CodeBuildのジョブが実行されます。 CodeBuildの画面で、プロジェクトを選択すると、Build historyのところに実行履歴が残されてます。 ログは以下のようになってました。 追伸 前回のGoogle Cloud Buildで試したレポジトリをそのまま使ったので、git pushするとGoogle Cloud BuildとAWS CodeBuildの両方が同時に動くことになりました。 追伸 その2 Pull requestを作成しただけでも、ジョブが動くようです。第三者が任意のコマンドを実行できそうなので、Webhookを止めておきました。Google Cloud BuildはPull requestでは動かないようです。 Webhookを使う上での注意点は、以下のページに記載されています。 Using webhooks with AWS CodeBuild - AWS CodeBuild
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS ほぼコピペでできる phpMyAdmin入れ方!!

ターミナルから操作するLinuxコマンド一覧 個人で設定されているものが入る場合は赤文字 <システムの更新> $sudo yum update MySQLへの接続確認 $sudo yum install mysql ここから $mysql -u admin -p -h MySQLDBのエンドポイント RDSで設定した -h の後 エンドポイント -u の後 ユーザーID 僕の場合admin コマンド入力後RDSで設定したパスワードがもとめられる求められる ここまで >quit $sudo yum install httpd $sudo systemctl enable httpd $sudo systemctl start httpd (httpが正常に稼働しているかブラウザで確認) $sudo amazon-linux-extras enable php7.4 $sudo amazon-linux-extras install php7.4 $sudo yum install php-mbstring php-xml $sudo systemctl enable php-fpm $sudo systemctl start php-fpm $sudo systemctl restart httpd $sudo nano /var/www/html/index.php (phpが正常に稼働しているかブラウザで確認) $cd /var/www/html $sudo wget https://www.phpmyadmin.net/downloads/phpMyAdmin-latest-all-languages.tar.gz $sudo mkdir phpMyAdmin $sudo tar -xvzf phpMyAdmin-latest-all-languages.tar.gz -C phpMyAdmin --strip-components 1 $sudo rm phpMyAdmin-latest-all-languages.tar.gz $sudo cp phpMyAdmin/config.sample.inc.php phpMyAdmin/config.inc.php $sudo nano phpMyAdmin/config.inc.php (ファイルから下記の内容を探し、修正) ここから $cfg['Servers'][$i]['host'] = 'localhost'; ↑を↓に修正 $cfg['Servers'][$i]['host'] = '先程と同じエンドポイント'; ここまで (phpMyAdminが正常に稼働しているかブラウザで確認) AWSインスタンスからパブリック IPv4 DNS オープンアドレスに http://元々のアドレス/phpMyAdmin/
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWSとWordPressを使ってWebサイトを構築しよう⑧

■インスタンスにApacheをインストールする 今回は作成したインスタンス「Webサーバー」に、オープンソースとして広く普及しているWebサーバーソフトのApacheをインストールしていきます。 目次 1.Apacheのインストールから起動までの方法 2.Apacheのプロセス確認 1. Apacheのインストールから起動までの方法 まずはインスタンスへSSH接続してください。 (SSH接続の方法は前回の記事を参考にしてください) インスタンスへログイン後、下記コマンドを入力しApacheをインストールします。 sudo yum -y install httpd ちなみにこのコマンドの意味は下記のようになっています。 「yum」コマンドはインストールやアンインストールするために用いるコマンド。 「sudo」コマンドは管理者権限でコマンドを実行するコマンド。 「httpd」はApacheのプロセスを表しています。 つまり、管理者権限(sudo)でApache(httpd)をインストール(yum)する。ということになります。 (「-y」はyumコマンドのオプションで「全ての質問にyesで答える、という意味があります) 次に下記コマンドを実行しインストールしたApacheを起動します。 sudo systemctl start httpd.service 次に下記コマンドを実行しApacheが自動で起動するように設定します。 (自動で起動する設定をしないと、サーバーを停止して起動し直した時にApacheが同時に起動してくれません。) sudo systemctl enable httpd.service 次に自動起動の設定が出来たか確認するため下記コマンド入力をします。 sudo systemctl list-unit-files -t service するとコマンド実行結果の中に下記画像のように「httpd.service enable」という表記があれば、ちゃんとApacheが自動起動の設定になっています。 2. Apacheのプロセス確認 Apacheがインストールされていること、自動起動の設定になっていることの確認ができました。 次はApacheのプロセスであるhttpdが実行中であることを確認します。 下記コマンドを入力して現在実行中のプロセスの中に「httpd」があることを確認しましょう。 ps -ax コマンド実行後、下記画像のように「httpd」のプロセスが表示されているのが分かります。 (赤枠内の4277や4278などの先頭の番号はプロセス番号と言い、実行環境によりプロセス番号は異なります。) 次にApacheがどのポートを開けて通信を待ち受けているのかを確認します。 ポートには「80番(HTTP)」や「443(HTTPS)」などがあります。 では下記コマンドを入力してどんなポートが開いているのか確認します。 sudo lsof -i -n -P コマンド実行結果を見ると下記画像のように「httpd」プロセスが80番ポート(「TCP *:80」)で待ち受けているのが分かります。 今回はここまで。 本記事でApacheをインスタンスへインストールする方法、自動起動にする方法、プロセスの確認方法、ポートの確認方法を実践しました。 次回はWebブラウザからWebサーバーを見れるようにセキュリティグループを設定していきます。 次の記事はこちらから AWSとWordPressを使ってWebサイトを構築しよう⑨
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【AWS】CodeDeploy, CodePipelineを使った自動デプロイのハンズオン

くろかわこうへい氏の動画、 【はじめてのCI/CD】AWSでやってみるDevOps最初の一歩、CodeDeploy、CodePipelineを使った自動デプロイのハンズオン が大変勉強になりましたので、文字媒体でも共有させていただきたいと思い、本稿をしたためました。 とりあえず動かしてみたい方向けの記事となっております。 CodeDeploy, CodePipelineの役割 CodeDeploy: 変更されたGithub上のコードをEC2に反映させる。 CodePipeline: Github上のコードの変更を監視する。 EC2, VPCの設定 まずはEC2を作成します。 任意のネットワーク・サブネットを選択します。 これらは事前に作っておくとよいでしょう。 簡易的なフローを以下に示します。 VPC作成 サブネット作成 インターネットゲートウェイのアタッチ ルートテーブルの編集(インターネットゲートウェイに向かう通信の許可) EC2とCodeDeployの連携を行うために、新しいロールを作成し、EC2にアタッチします。 AWSCodeDeployRoleとAmazonS3FullAccessの権限を追加します。 ここではロール名をcodedeployroleと設定します。 以降デフォルトで結構です。 (タグは適当な事項を入力しておくとよいです。) EC2にインターネット経由でアクセスできるように設定します。 以下は詳細です。 ルートテーブルにインターネットゲートウェイへのルーティングを設定していること。 セキュリティグループでsshのインバウンド許可設定がされていること。 NetworkACLはインもアウトもすべて許可されていること。 EC2にCodeDeployのAgentをインストールします。 EC2にSSH接続します。 $ ssh -i [キーペアファイル] ec2-user@[パブリックIPアドレス] 管理者権限に移行します。 $ sudo su コードデプロイのエージェントをインストールします。 シェルを作成し、実行する形式を取ります。 ※公式ドキュメント( https://docs.aws.amazon.com/ja_jp/codedeploy/latest/userguide/codedeploy-agent-operations-install-linux.html )が変更されているようです。 シェルを作成します。 $ vim install.sh install.sh #!/bin/bash yum -y update yum install -y ruby cd /home/ec2-user curl -O https://aws-codedeploy-ap-northeast-1.s3.amazonaws.com/latest/install  # リージョンによって表記が異なります。 chmod +x ./install ./install auto シェルの実行権限を付与します。 $ chmod +x install.sh シェルを実行します。 $ ./install.sh クライアントの設定 Githubのアカウント、リポジトリは事前にご自身で作っていただきます。 Github上にpushするリポジトリの構成は以下のとおりです。 scripts ├ install_dependencies ├ start_server └ stop_server appspec.yml index.html 以下、具体的なファイルの内容です。 #!/bin/bash yum install -y httpd #install_dependencies #!/bin/bash service httpd start #start_server #!/bin/bash isExitstApp=`pgrep httpd` if [[ -n $isExitstApp ]]; then service httpd stop fi #stop_server appspec.yml #CodeDeployがどのようにファイルを配置するかを定めたファイル version: 0.0 os: linux files: - source: /index.html #同期するファイル destination: /var/www/html/ #EC2のどこに同期させるか #CodeDeployが動作する間に任意の行為を実行 hooks: BeforeInstall: - location: scripts/install_dependencies timeout: 300 runas: root - location: scripts/start_server timeout: 300 runas: root ApplicationStop: - location: scripts/stop_server timeout: 300 runas: root index.html Hello, World ! #参照元動画のサンプルより簡略化したものを使用 以上を作成しましたら、Githubにpushしておきます。 CodeDeploy, CodePipelineの設定 以降、デフォルトで結構です。 デプロイを作成し、デプロイのステータスが完了となるまで待ちます。 EC2にSSH接続します。 $ ssh -i [キーペアファイル] ec2-user@[パブリックIPアドレス] EC2の同期先のディレクトリに移動します。 $ cd /var/www/html/ ディレクトリにindex.htmlが配置されているか確認します。 $ ll index.htmlが適切に配置されていました。 ついでに、index.htmlの内容も確認しておきます。 $ cat index.html index.htmlの内容が適切に同期されていることが確認できました。 ここで、EC2インスタンスのセキュリティーグループのインバウンドのルールを変更し、HTTPアクセスができるようにしておきます。 パブリックIPアドレスを用いてブラウザからindex.htmlにアクセスします。 index.htmlの内容が適切に反映されていることがわかりました。 index.htmlの内容を変更し、Githubにpush後、デプロイの作成のフェーズにて、新たなコミットIDを入力すれば、再びCodeDeployが機能します。 ブラウザからindex.htmlにアクセスすることで、変更内容が反映されるのがわかるかと思います。 しかしながら、いちいちコミットIDを入力するのは煩雑なので、CodePipelineによって変更を自動的に捉えさせるようにします。 今回はビルドはおこないませんのでスキップします。 以降、デフォルトで結構です。 パイプラインを作成し、処理の完了を待ちます。 index.htmlの内容を変更し、Githubにpush後、CodePipelineが変更を捉え、自動的にCodeDeployが機能するようになります。 ブラウザからindex.htmlにアクセスし、確認してみましょう。 以上となります。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む