投稿

2018の投稿を表示しています

[AWS] WAF を自分で組み立てるなら SAM でテンプレート書いた方が楽だよ

タイトルの通りです。 あ、 この記事は AWS初心者 Advent Calendar 2018 の7日目 として書いております。 最近会社でWAFとかLambdaとかSAMとかちょっとEC2やRDSといった基本のプロダクトとは違った要素について検証・導入を行なっているのですが、Lambdaをデプロイするために使ってみたSAMでWAFをデプロイすると楽ちんでした。 たとえばここに、HTTPリクエストのメソッドの種別を確認し、HEAD、CONNECT、TRACEを利用したアクセスをブロックするようなWAFを作成するためのSAMテンプレートがあります。 これが存在するディレクトリで以下のようにパッケージングのためのコマンドを実行します。 あ、念の為に雑多なディレクトリではなく、このテンプレートだけが存在する新しいディレクトリを作成してください。 aws --profile [プロファイル名] cloudformation package --template-file template.yml --s3-bucket [あらかじめ用意したS3バケット名] --output-template-file packaged-template.yml これを実行することで、SAMでのデプロイのためにパッケージング化された各種ファイルが指定したS3バケットに送られ、そこからデプロイするために書き換えられた packaged-template.yml が生成されます。 Lambda Functionのためのソースコードがあればここで併せてパッケージング化されるのですが、今回は無いのでtemplate.ymlだけですね。 そして以下のコマンドを実行するとデプロイされます。 aws --profile [プロファイル名] cloudformation deploy --template-file packaged-template.yml --stack-name otameshi-http-method-restriction-for-cloudfront --capabilities CAPABILITY_IAM --parameter-overrides yourApplicationeName=[任意の文字列] コマンド名に

[AWS] 知らないアカウントIDのCloudFrontが自分のACM証明書を使っていると思ったけど違った

イメージ
結論 結論から言うと API Gateway でした。 ACMで発行したSSL/TLS 証明書を シームレスに他のAWSプロダクトで利用することが可能なのですが、その時に内部動作としては規定のアカウントIDでCloudFrontディストリビューションが生成され、そのディストリビューションに対して証明書が適用されるようです。 直面した問題 AWSでのシステム運用にあたり、それなりの数のドメインを運用しているのですが、基本的にはACMにて発行した証明書を利用しています。 以前はメール認証しかできず、きちんと環境を整えてあげないと自動更新に失敗することもあり、DNS認証の同一ドメインの証明書を別に発行し、そちらに切り替える作業を行なっていました。 ACMで発行した証明書はAWSコンソール上から簡単にELBやCloudFrontといったAWSプロダクトに利用することが可能なのですが、証明書を削除する際には全てのインスタンス・ディストリビューションから利用を解除する必要があります。 「あとはどの子(インスタンス)が使っているのかな〜?」と確認したところ、 arn:aws:cloudfront::969236854626:distribution/ABCDEFGHIJKLMN のようなCloudFrontディストリビューションが利用していることがわかりました。 969236854626 の部分が自分のAWSアカウントIDになりますが、私が利用しているアカウントのIDは全然違います。 対策 「えっ…?」と思いましたが調べたらすぐに解決。 答えはこちらに書いてありました。 エッジ最適化のカスタムドメイン名を作成する方法 - Amazon API Gateway  https://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/how-to-edge-optimized-custom-domain-name.html API Gatewayにカスタムドメインを割り当ててHTTPSを利用させたい場合に、AWSは特定のIDでCloudFrontディストリビューションを内部的に自動で作成し、そのディストリビューションに証明書を関連づけるのでした。 削

AmazonLinuxにJavaスレッドダンプ取得ツールをインストールして取得できるようにする

スレッドダンプとは スレッドダンプとは何なのでしょうか。 スレッドのダンプ…JavaのスレッドはJavaを実行する際の実行単位というか、処理の流れの1つのこと。 それのダンプ…ダンプとはあるOSやプログラムのその時の状況を丸ごと取得してファイルなどに出力したもの。 なのでスレッドダンプとはJavaプログラムのある時点での処理状況をダンプとして取得したものになります。 スレッドダンプについては下記などがとても参考になりますのでご参照ください。 (参考) » 「うわっ…私のアプリ、遅すぎ…?」 スレッドダンプでJavaアプリケーションのボトルネックを調査しよう TECHSCORE BLOG http://www.techscore.com/blog/2016/02/05/%E3%82%B9%E3%83%AC%E3%83%83%E3%83%89%E3%83%80%E3%83%B3%E3%83%97%E3%81%A7%E3%83%9C%E3%83%88%E3%83%AB%E3%83%8D%E3%83%83%E3%82%AF%E3%82%92%E8%AA%BF%E6%9F%BB%E3%81%97%E3%82%88%E3%81%86/ あなたとスレッドダンプ - スレッドダンプ入門 - この国では犬が http://enk.hatenablog.com/entry/2014/09/22/001303 スレッドダンプツールについて jstackというツールがあり、これを利用してスレッドダンプを取得するのが一般的なようです。 どこの記事を読んでも出てきますし、下記のAdobeの技術記事(2017年10月更新)でも利用されているのでjstackを利用しておけば間違いありません。 (参考) JVM からのスレッドダンプの取得 https://helpx.adobe.com/jp/experience-manager/kb/TakeThreadDump.html インストール方法 普通はJavaを実行しているマシンにはだいたいjstackがインストールされているようなのですが、私が運用しているサーバには入っていなかったので入れてみました。 既存のJDKのインストール状況確認 $ rpm -qa | grep jdk

CORSについて学んだので自分なりのまとめと業務で起きたトラブルの対処について

イメージ
オリジン間リソース共有 (CORS)という技術があります。 ドメインAのWebページを表示する際に、一部のコンテンツをドメインBから取得してそれを表示したいといった場合に利用する必要があります。 それは最近のWebでは割とありふれたことだと思います。 なので意識せずともかなりの頻度で利用されているのではないでしょうか。  先日業務でCORSを意識した問題に直面してしまったこともあって、一度きちんとした技術文書を読んだ方が良いと思い、Mozillaが提供している MDN web docsの丁寧なドキュメント を読んでみました。 CORSまとめ WebブラウザがドメインAのページを取得したいが、ドメインAのそのページはドメインBのコンテンツを含むといった場合に、ドメインAのサーバはドメインBのコンテンツを取得して自ページのコンテンツの一部としてWebブラウザに返さなければいけない その時に利用される技術がCORS CDNで画像やスタイルシートやフォントやスクリプトを配信している昨今ではかなりの頻度で利用されていると思われる 基本的にはHTTPヘッダに所定の内容をクライアントとサーバが用意することで成り立つ CORSができるかどうかを確認するために「プリフライトリクエスト」という事前HTTPアクセスが必要である 「プリフライトリクエスト」はOPTIONメソッドで行われる…GETやPOSTではない 「プリフライトリクエスト」が発生しない「単純リクエスト」というCORSリクエストもあるが該当条件が厳しい 特に世の中に多そうなcontent-typeが「text/html」のページは単純リクエスト対象外なので基本的にはほとんどのCORSでプリフライトリクエストが発生すると考えた方が良さそう プリフライトリクエスト時にクライアントから発送される「Access-Control-Request-Method」にはプリフライト後の本来のリクエストでどのメソッドが使われるかが書かれている 同様に「Access-Control-Request-Headers」には次に行われる本来のリクエストでどのようなヘッダが送信されるかについて書かれいる プリフライトリクエストを処理するためにサーバ側(CORSで一部コンテンツを提供するドメインBのサーバ)はOPT

初めてぐらいの勢いで特定のブランチにマージする業務を行ったときのメモ

自分が送ったコミットを特定のブランチ(今回はstaging)にマージしてくれと言われて対応した時のメモ。 まずこうやってリポジトリを clone して hub am −3 コマンドを使ってマージしようとした。 git clone git@github.com:(team name)/(repository name).git cd (repository name) git checkout staging hub am -3 https://github.com/(team name)/(repository name)/pull/(pull number) 認証失敗 そしたら hub am -3 コマンドが認証失敗になりうまく動かない。 $ hub am -3 https://github.com/(team name)/(repository name)/pull/(pull number) Error getting pull request: Unauthorized (HTTP 401) Bad credentials 色々調べたけど結論としては ~/.config/hub に書いてある認証情報が古かったので消すと認証の再要求が発生して解消した $ rm ~/.config/hub $ hub am -3 https://github.com/(team name)/(repository name)/pull/(pull number) github.com username: hub am -3 コマンドでマージしようとしたらコンフリクト $ hub am -3 https://github.com/(team name)/(repository name)/pull/(pull number) Applying: (this is a comment of commit) Using index info to reconstruct a base tree... M circle.yml Falling back to patching base and 3-way merge... Auto-merging circle.yml CONFLICT (content): Merge con

Macにディスプレイを接続したらインターネットがめちゃくちゃ重くなって使えなくなった

結論 5GHz帯のWi-Fiに接続していたものを、2.4GHz帯へ変更すると解消されてインターネットが利用できるようになりました。 Macのサポートサイトに  Wi-Fi や Bluetooth を使用した通信を妨げる要因 というページがあり、そちらを読むと色々原因が書いてありましたが、私の場合は利用するWi-Fiの周波数を変更することでうまくいきました。 ディスプレイは発している周波数と干渉したりしているのかもしれません…。 背景 会社ではMacBookProを貸与されており、許可を得て自宅に持ち帰ったりしています。 休日のトラブルをそれで自宅から対応したり、自宅で興味のある検証をやってみたり、その結果をこのブログに書いてみたり…。 ありがたい環境なので、積極的に活用しようと、自宅の28インチのディスプレイに接続して作業をしようと思ったのですが、なぜかディスプレイに接続するとwi-fiが激重になってインターネットができません。 AWSの管理画面をちょっと覗いたりとかその程度さえできずに困っていました。 ディスプレイ何使ってんの? ViewSonicです。グレアですがコスパよくておすすめです。 スピーカー内臓なのとHDMIが2ポートあるところが特にお気に入りです。 画面がデカい割に足元が弱いのか画面がちょっと揺れやすいですが、気にならない人にはおすすめです。

今更だけど Amazon Dash Button を購入して設定した

イメージ
せっかくなので画像付きメモを。 まず開封前の外観です。箱がすごくしっかりしています。 どうやって開けるか少しだけ悩みましたが、側面にシールが貼ってあり、「ここ切ってね」みたいに示されているのでそこから開けられます。 大きさはこんな感じ。手元にいい感じのモノがなかったので3DSLLと比較してみました。 箱の下に2冊の説明書がありました。黒の書と白の書。なんかかっこいい。 黒の書にはいろんな言語で簡単に最初の設定方法が書いてありました。 白の書には取扱上の注意がいろいろ書いてありました。 ポイントは「電池交換不可」なところでしょうか。 電池が切れたら買い換えてね、の製品設計です。 Immutableってやつですね、この辺はクラウド企業らしい。 黒の書の日本語版はこれだけ。 PCのAmazonのアカウントセンターには「Dash端末」という項目がなく、Amazonのスマートフォンアプリからしか設定開始できないようです。 「新しい端末をセットアップ」をタップするとセットアップ画面に移行します。 Dash Button を長押しして、青いランプが点滅するのを確認してからアプリ側の「接続」をタップします。 最初はアプリとDash ButtonはBluetoothで接続するようです。 何回かやってうまくいかなかったのでちょっと悩みました。 もしかしてと思ってスマートフォンの省電力モードを無効にしたあと再度数回チャレンジしたら成功しました。 この画面の前にWi-Fiのアクセスポイントの選択とパスワードの入力の画面がありました。 アプリに入力した設定内容をどうやらBluetoothでDash Buttonに共有して登録させるようです。すごいー。 ということで、無事、大好きなキュキュット ピンクグレープフルーツを購入するためのAmazon Dash Buttonのセットアップが完了しました。 設定完了後にボタンを押すと、黄色で点滅が起こり、その後まるで「注文が完了しました」と言わんばかりに緑のゆったりとした点灯が起こります。注文履歴を見るとちゃんとキュキュットが注文されていました。すごい。 以上、久しぶりのブログ活動でした。