20210425のAWSに関する記事は27件です。

お名前.comとAWSでドメインとHTTPS設定

●手順1 route 53でホストゾーンを追加 ネームサーバーが表示させる ついでにAレコードも追加する ●手順2 お名前.comのネームサーバーに 手順1で表示されたネームサーバーを設定する ●手順3 Certificate Manager で証明書のリスクエスト ●手順4 Route 53でレコード作成して認証させる ●手順5 aws ロードバランサー側でも 証明書を追加する
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【初心者】Amazon Neptune を使ってみる

1. 目的 AWSのデータベース関連サービスの復習をしている。Amazon Neptune について、マネージドのGraphDBとのことだが、そもそもGraphDBを全く触ったことがなかったため、GraphDBって何??から学習して概要を理解する。 2. Amazon Neptune とは(自分の理解) GraphDB は、例えばFacebookでの人間関係(AさんとBさんが友達関係、AさんがCさんをフォロー)とか、物と物の関係性をデータベース化したい時に適しているデータベース。GraphDBをマネージドで使えるようにしているのがAmazon Neptune。 他の人のやってみた記事を見てざっくりどんなものなのか確認した。 「Amazon NeptuneでグラフDBを使ってみる」 DB環境の作成、サンプルレコードの作成までが記載されており、とっかかりになった。 「はじめてのGraphDB Amazon Neptune」 Vertex, Edge といったGraphDBの要素の初心者向け説明もあり参考になった。 3. やったこと 利用環境を整備する。(Neptune DBの作成、Jupyter Notebookからの接続) アンパンマンのキャラクターの関係をデータ入力し、検索してみる。 4. 構成図 利用環境の構成図 5. 設定手順 5.1 Neptune DBの作成 あらかじめ、サブネットを2つ持つVPCを作成しておく。 マネージドコンソールの「Neptune」-「データベース」-「データベースの作成」を選択し、以下のように作成する。 5.2 Notebookの作成 Neptune DBの操作(データの入力や検索など)を行うためのJupyter Notebookを作成する。(以前はEC2インスタンスを立てて、データ操作用のソフトをインストールして、DBに接続して…という環境構築が必要だったがようだが、簡便化された様子。接続したいNeptune DBを指定してNotebookを作成するだけで、すぐにデータ操作を開始することができる。) 「Neptune」- 「Notebooks」-「ノートブックの作成」を選択し、以下のように作成する。 作成したノートブックインスタンスを開き、Python3の新しいノートブックを作成する。 Status コマンドで、Neptune DBと問題なく接続していることを確認する。 5.3 データの設計 アンパンマンのキャラクターの関係を例にデータベースを作成してみる。 表現したい内容は以下の通り。 アンパンマン、しょくぱんまん、カレーパンマンは友達。 ばいきんまんはアンパンマンが嫌い。 ばいきんぱんとホラーマンはドキンちゃんが好き。ドキンちゃんはしょくぱんまんが好き。 アンパンマン、しょくぱんまん、カレーパンマンは善。ばいきんまんとドキンちゃんは悪。ホラーマンは中立。 ばいきんまんの乗り物はばいきんUFOとだだんだん。 上記の表現をGraphDBのやり方に合わせると以下の通り。 Vertex(頂点)として、キャラクター(アンパンマンなど)や乗り物(ばいきんUFOなど)を定義する。 Vertexにはidを付与する。(c1: アンパンマン、c2: ばいきんまん、v1: ばいきんUFO など) ※idは自分でつけない場合自動的にUUIDが付与される。見た目が良くないので今回はidを明示的に付与。 VertexのLabelとして、「Character」(キャラクター)、「Vehicle」(乗り物)を定義する。 VertexのPropertyとして、「name」でキャラクターや乗り物の名前を、「side」で立場(good(正義)、evil(悪)、neutral(中立))を定義する。 Edge(関係)として、like,hate,friend,rideを定義する。 各キャラクターの関係性については念のため「アンパンマン恋愛相関図・恋人まとめ【複雑すぎる恋愛事情】」も参照。 5.4 データの投入 データ操作を行うフレームワークとして、「Gremlin」と「SPARQL」が用意されている。他の人の記事などを見た感じだとGremlin派のほうが多そうなため、Gremlinで練習することにする。前の手順で作成したJupyter Notebookにて、Gremlinを用いたデータ操作が可能。 最初にVertexのデータを入力する。id, label, propertyを指定してVertexを追加していく。 ※idを付与する時に、「'id'」ではなく「id」にする必要があることにハマった。 %%gremlin g.addV('character').property(id,'c1').property('name', 'アンパンマン').property('side', 'good').toSet() g.addV('character').property(id,'c2').property('name', 'ばいきんまん').property('side', 'evil').toSet() g.addV('character').property(id,'c3').property('name', 'カレーパンマン').property('side', 'good').toSet() g.addV('character').property(id,'c4').property('name', 'しょくぱんまん').property('side', 'good').toSet() g.addV('character').property(id,'c5').property('name', 'ドキンちゃん').property('side', 'evil').toSet() g.addV('character').property(id,'c6').property('name', 'ホラーマン').property('side', 'neutral').toSet() g.addV('vehicle').property(id,'v1').property('name', 'ばいきんUFO').toSet() g.addV('vehicle').property(id,'v2').property('name', 'だだんだん').toSet() 次にEdgeのデータを入力する。両端のVertex及び方向を指定してEdgeを追加していく。※複数行いっぺんに入れるとなぜかエラーになり、1行ずつ投入した。 %%gremlin g.addE('friend').from_(g.V().has('name','アンパンマン')).to(g.V().has('name','カレーパンマン')).toSet() g.addE('friend').from_(g.V().has('name','アンパンマン')).to(g.V().has('name','しょくぱんまん')).toSet() g.addE('friend').from_(g.V().has('name','しょくぱんまん')).to(g.V().has('name','カレーパンマン')).toSet() g.addE('friend').from_(g.V().has('name','しょくぱんまん')).to(g.V().has('name','アンパンマン')).toSet() g.addE('friend').from_(g.V().has('name','カレーパンマン')).to(g.V().has('name','アンパンマン')).toSet() g.addE('friend').from_(g.V().has('name','カレーパンマン')).to(g.V().has('name','しょくぱんまん')).toSet() g.addE('hate').from_(g.V().has('name','ばいきんまん')).to(g.V().has('name','アンパンマン')).toSet() g.addE('like').from_(g.V().has('name','ばいきんまん')).to(g.V().has('name','ドキンちゃん')).toSet() g.addE('like').from_(g.V().has('name','ホラーマン')).to(g.V().has('name','ドキンちゃん')).toSet() g.addE('like').from_(g.V().has('name','ドキンちゃん')).to(g.V().has('name','しょくぱんまん')).toSet() g.addE('ride').from_(g.V().has('name','ばいきんまん')).to(g.V().has('name','ばいきんUFO')).toSet() g.addE('ride').from_(g.V().has('name','ばいきんまん')).to(g.V().has('name','だだんだん')).toSet() 5.5 データの検索 Vertexの一覧を取得する。 %%gremlin g.V().valueMap() 1 {'side': ['good'], 'name': ['アンパンマン']} 2 {'side': ['evil'], 'name': ['ばいきんまん']} 3 {'side': ['good'], 'name': ['カレーパンマン']} 4 {'side': ['good'], 'name': ['しょくぱんまん']} 5 {'side': ['evil'], 'name': ['ドキンちゃん']} 6 {'side': ['neutral'], 'name': ['ホラーマン']} 7 {'name': ['ばいきんUFO']} 8 {'name': ['だだんだん']} Edgeの一覧を取得する。 %%gremlin g.E() 1 e[ccbc823d-4a0f-052e-e439-46fd702e99f0][c3-friend->c1] 2 e[bcbc823d-c150-626a-596f-e2f74b87542e][c6-like->c5] 3 e[6abc823c-d091-ae7b-1503-c7517a40e387][c1-friend->c4] 4 e[0cbc823d-63d0-7b17-fbff-d4b67b0f8ff2][c3-friend->c4] 5 e[8cbc823c-ff59-a1a4-ced4-925497d35304][c4-friend->c3] 6 e[e2bc823d-db8e-d975-299c-85397e429806][c5-like->c4] 7 e[70bc823d-83ff-0819-4a4c-81d704a5bdd6][c2-hate->c1] 8 e[52bc823e-011a-26f3-3ac5-1493defae96a][c2-ride->v1] 9 e[90bc823c-8b3d-f5d0-1a66-9091d0454a39][c1-friend->c3] 10 e[72bc823d-29e0-d0bb-b7da-5a8ef31a2ab9][c4-friend->c1] 「「悪」サイドのキャラクターは誰か?」を検索する。 %%gremlin g.V().hasLabel('character').has('side','evil').values('name') 1 ばいきんまん 2 ドキンちゃん 「ドキンちゃんの意中のキャラクターは?」を検索する。 g.V().hasLabel('character').has('name', 'ドキンちゃん').outE('like').inV().values('name') 1 しょくぱんまん 「ドキンちゃんのことを好きなのは誰か?」を検索する。 %%gremlin g.V().hasLabel('character').has('name', 'ドキンちゃん').inE('like').outV().values('name') 1 ホラーマン 2 ばいきんまん 5.6 データの可視化の確認 DBの内容を可視化できる機能が追加されたとのことで、試してみる。 Amazon Neptune が、Neptune Workbench でのグラフ可視化機能を発表 可視化はできたが、VertexのNameの出し方がよく分からなかった。 6. 学習メモ 検証時、データを間違えて入力したものを消したり、入力したデータが正しく保存されているか確認したりなど、Gremlinのいろいろな操作を覚える必要があった。 Gremlinでのデータ操作については以下が参考になった。 JanusGraphによるグラフDB入門 GraphDBの環境はAmazon NeptuneではなくOSSのJanusGraphを用いているが、Gremlinの一連のデータ操作のサンプル、解説あり。 Azure Cosmos DB 自習書: Azure Cosmos DB GremlinAPI編 Azure Cosmos DBにて、Gremlinを使ってデータ操作を行うハンズオン手順書。内容が充実しておりこちらも各種データ操作が網羅されている。 7. 所感 GraphDBというものに初めて触ることができちょっと楽しかった。今後業務に役立つことがあればよいが、、
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS CLIでのCloudWatchアラーム作成方法

AWSのCloudWatchについて AWSの各サービス(EC2, S3, ELB等)に関して任意のメトリクスやログに基づいてアラートを通知したり、システムを監視をしたりできるサービス。 複数監視項目を組み合わせて、アラートをメールやSlackに通知することも可能。 CloudWatchのアラーム作成 基本的には、公式ドキュメントにしたがってGUI上で必要項目を1アラーム毎に設定していく。 ⇒数個のアラームであれば問題ないが、数が多くなると手間がかかる問題 AWS CLIから設定JSONを元にアラームを作成する方法 この問題を解決できるかつ、似たような設定のアラートを複数個設定する場合はこの方法でやると便利。 以下、設定手順を説明する。 ①設定ファイル作成に必要なメトリクス情報を表示する。 aws cloudwatch list-metrics --namespace [監視対象のNameSpace] ここで表示されたメトリクスのDimensionsをメモする。 --metric-name 'mem_used_percent'オプションでmetric nameでフィルタリングもできる。 ②設定用JSONファイルを作成する。Dimensions欄には①でメモした物を入力する。 今回はサンプルとして「メモリ使用%が60秒の区間で90%以上に1データ点でもなった場合に場合にアラートを出す」アラームの設定ファイルを載せる。 設定JSONファイルサンプル { "AlarmActions": [ "arn:aws:sns:ap-east-1:~:cloudwatch_alarm-sns" // SNSのARN ], "AlarmName": "memory-utilization-90", // 設定したい好きなアラーム名 "AlarmDescription": "60秒内の1データポイントのmemory-utilization >= 90", // アラームの説明(なくても良い) "Namespace": "Name space", // 監視対象のNameSpace "MetricName": "mem_used_percent", // 監視対象のメトリクス(今回は使用メモリの%) "Dimensions": [ { "Name": "ServerName", "Value": "Server 1" }, { "Name": "host", "Value": "ip-~" } ], "Statistic": "Maximum", // 今回の場合は60秒区間ごとの最大値を評価 "Period": 60, // 何秒間の中で条件を満たした場合にアラートを出すか "EvaluationPeriods": 1, // 区間内で何データ点条件を満たした場合にアラートを出すか "Threshold": 90, // 閾値 "ComparisonOperator": "GreaterThanOrEqualToThreshold" // 今回の場合は閾値以上の場合 } 使用可能なパラメータに関しては公式ドキュメントを参照 ③CLIで②で作ったJSONのパスを指定してCLI上でアラームを設定する。 aws cloudwatch put-metric-alarm --cli-input-json file://alarm-path.json ちなみに、--cli-input-yamlとすればyamlでも設定ができる。 参考 https://bbh.bz/2019/08/29/setting-cloudwatch-alarmby-cli/ https://qiita.com/moomindani/items/aef16aa93db56b071ba3 https://hacknote.jp/archives/43635/ https://recipe.kc-cloud.jp/archives/9733 https://recipe.kc-cloud.jp/archives/9765 https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/viewing_metrics_with_cloudwatch.html https://aws.amazon.com/jp/premiumsupport/knowledge-center/cloudwatch-set-anomaly-detection-alarm/ https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/cli-usage-skeleton.html https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/quickref-cloudwatch.html
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

PF用のAWSサーバに大量のログイン試行のログがあった話

全容はこの記事を見てください。 めちゃくちゃ参考になります。 https://blog.katsubemakito.net/linux/sshd-ipaddress-check Twitterでふと上の記事が流れてきて、「へぇ~ログイン攻撃ってあるんだなぁ~」と思って私も試しにコマンドを叩いてみました linux $ sudo cat /var/log/secure | grep 'Invalid user' そうしたら、めちゃくちゃ出るログイン試行の跡。ナニコレ怖い!!!! また記事に乗っているコマンドを試してみる。 linux $ sudo cat /var/log/secure* | grep 'Invalid user' | cut -f2 -d' ' | sort | uniq -c するとすると、一日1500件くらいログイン試行があるじゃないか・・・!怖いんだけど!!! スクールのメンターさんにドキドキしながら聞きました。 私はcloud9の1つからしかログインしないので、cloud9で console $ curl ipconfig.io を入れて出てきたIPアドレスをどっかにメモ(後で入力する) EC2→インスタンス→該当のEC2インスタンス→セキュリティー→セキュリティーグループをクリック インバウンドルールを編集をクリック→SSHのところのソースに自分のIPアドレス/32を入力 で出来ました! 皆様もお気をつけて・・・ SSH接続についてはこちらの記事が参考になりました。 https://qiita.com/tag1216/items/5d06bad7468f731f590e
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS SNS で SMS を利用するときの上限緩和で引っかかった

AWS SNS の利用上限 AWS SNS によって SMS を送信出来ますが、デフォルトだと月々上限 $1 分までしか利用出来ないため、数件送信するだけで上限に達してしまいます。 上限に達する場合、SMS はいくら送っても送信失敗になります。 「上限に達する場合」というのは、例えば上限がデフォルトの $1 の場合、 $1 を越えて以降の送信が失敗 ではなく、$1 を超える場合に失敗 ということです。 私の場合、SNS の利用料金が $0.97 になった時点でそれ以降の SMS 送信がいくら送っても失敗しました。 SMS の配信ステータスは AWS コンソールの SNS の画面から確認することが出来ます。 上限緩和の方法 AWS コンソールの AWS サポートから、Create Case -> Service limit increase を選択し、 Limit type で「SNS Text Messaging」を選択します。 そうすると入力項目が色々と出てくるのでなるべく細かく入力して送信します。 返信が来るまで大体1日くらいかかると思います。 これで上限緩和されたかと思いきや... 無事 AWS サポートから返信が来て上限緩和が通達されました。 が、相変わらず SMS 送信が失敗しまくる。 もしかして AWS SNS って送信成功率ひっくいサービスなのか??とも思いましたが、上限緩和は AWS サポートだけでなく AWS SNS の設定も必要だったようです。 AWS コンソールの SNS 画面から、左側メニュー「テキストメッセージング(SMS)」 を開くと、下の方に「テキストメッセージングの優先設定」というものがあります。 デフォルトだとなんの設定もされていないので、ここを編集して「アカウントの使用制限」から何ドルまでの制限にするかを設定します。 これを行わないと、サポートの上限緩和申請が通っても $1 が上限のままなようです。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS vs Azure vs GCP in Qiita

世はまさに大クラウド時代ですが、その中でも3大クラウドと言われるAWS、Azure、GCPのQiitaでの現状について調べてみました。まず歴史から辿るとそれぞれのサービス開始時期は以下の通りです。 AWS:2006年 Azure:2010年 GCP:2008年(GAEの開始年) AWSのサービス開始から約15年経ち、2020年時点でのシェアはCanalys報告書によると、AWS、Azure、GCPの順に32%、20%、7%となっています。Stack Overflow Developer Survey 2020の最も好きなプラットフォームの項目でも、AWSが一番人気ですが他2つも高い人気となっています。日本ではAWSが圧倒的に広まっている印象で上記海外の調査は少し意外だったため、Qiitaでの現状を調べてみました。 調査結果 今回は簡易的に「AWS」「Azure」「gcp」のタグがついた記事が各年で何件あるか調査しました。結果が以下です。 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 AWS 0 1 42 203 798 1599 2265 2415 3510 5114 6664 Azure 0 0 3 7 59 148 337 575 743 946 1362 gcp 0 0 0 0 6 21 89 222 575 955 1111 この結果だけで判断するのは安直ですが、日本ではAWSのシェアが群を抜いていそうです。日本語の情報が圧倒的に多いことでAWSの使用が加速しているのではないでしょうか。今後の展開が楽しみです。 調査に使用したプログラム qiita_cloud_count.py from bs4 import BeautifulSoup import matplotlib.pyplot as plt import numpy as np import requests import time # Qiitaで投稿日、タグを指定して検索し、ヒットした記事数を取得する base_url = 'https://qiita.com/search' tags = ['AWS', 'Azure', 'gcp'] years = range(2010, 2021) summary = [] for tag in tags: temp = [] for year in years: params = f'?q=tag%3A{tag}+created%3A%3E%3D{year}-01-01+created%3A%3C{year}-12-31' html_doc = requests.get(base_url + params) data = BeautifulSoup(html_doc.text, 'html.parser') temp.append(int(data.find('span', class_='badge').text)) time.sleep(5) # サーバ負荷軽減用 summary.append(temp) data = np.array(summary) print(data) # 以下グラフ描画用 num_tags = data.shape[0] num_years = data.shape[1] index = np.arange(num_years) fig, ax = plt.subplots() bar_width = 0.25 alpha = 0.8 colors = ["orange", "royalblue", "gold"] for i in range(num_tags): plt.bar( index + bar_width*i, data[i], bar_width, alpha=alpha, color=colors[i], label=tags[i] ) plt.ylabel('Counts') plt.xticks(index + bar_width, years) plt.legend(prop={'size' : 15},loc="upper left") plt.savefig("cloud_cnt.png", bbox_inches = 'tight')
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

[AWS]https化に向けたロードバランサーの設定

はじめに AWSのEC2で上げているRailsアプリをHTTPS化したのでメモとして残しておきます。 画像なしで説明しますのであしからず。 また今回はアプリを既にEC2に上げている(HTTPで)、ACM(AWS Certificate Manager)でSSL証明書を取得している前提とします。 1. 手始めに ロードバランサーの設定 取得したSSL証明書をロードバランサーで使用します。 EC2の画面左の「ロードバランサー」を選択して、 作成済みの「アプリ名-ELB」を選択してください。 下部の詳細から、「リスナー」タブを選択し、「リスナーの追加」ボタンをクリックします。 2. リスナーの追加 以下の通り記述 プロトコルポート: 「HTTPS」 「443」 デフォルトアクション: 「アクションの追加」をクリック、転送先を選択して、「アプリ名-Target-Group」を選択 セキュリティポリシー:「ELBSecurityPolicy-2016-08」 デフォルトの SSL 証明書:「ACMから(推奨)」「ドメイン名」 「リスナーの追加」ボタンを選択 リスナーに「HTTPS」が追加されましたが、セキュリティグループで許可されていないので セキュリティグループを修正します。 3. セキュリティグループの修正 EC2の画面左の「セキュリティグループ」を選択して、作成済みの「アプリ名-SecurityGroup」を選択します。 下部の詳細から、「インバウンドルール」タブを選択し、「インバウンドルールを編集」ボタンを選択してください 以下のように記述 タイプ:「HTTPS」 プロトコル:「TCP」 ポート範囲:「443」 ソース:「任意の場所」0.0.0.0/0 説明:「任意」 「ルールを保存」ボタンをクリックします。 これでHTTPSからのアクセスを許可することができます。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

[AWS]Route53の設定

はじめに DNSの機能を持つAWSのRoute53を使って、IPアドレスとドメインを関連付けします。 また自分の手順書としてのメモですので画像はありません。あしからず。 ドメインが既に取得していることを前提としますので、まだ設定していない方はドメインを取得してください。 私は以下のサイトから取得しました。 1. 手始めに Route53の設定 AWSのサービス検索欄から「Route53」と入力して、それを選択します。 画面左にある「ホストゾーン」を選択して、 遷移したページで「ホストゾーンの作成」を選択します。 以下の通りに記述します。 ドメイン名: 取得したドメイン名 コメント: 「domain for アプリ名」 タイプ: 「パブリックホストゾーン」 その後「作成」ボタンをクリックします。 するとドメインに対する「値」が生成されます。 タイプ「NS」の4つの値があるのでそちらを使用して進めていくのでメモしておきましょう 2. ネームサーバーの変更 ご自身で取得したドメインにネームサーバーを設定します。 自身で取得したドメインの詳細画面を開いてください ※基本的にはどのサービスでもやり方は同じです。 ドメインの詳細を選択して「ネームサーバー情報」からネームサーバーを設定していきます。 今回はRoute53のネームサーバーを使うので他のネームサーバーの利用を選択します。 先程メモした、4つの値を入力します。末尾の「.」は入れません 入力したらそれを確定してください 3. ターミナルからネームサーバの確認 ターミナルを使ってネームサーバを確認します。 サーバー環境で以下のコマンドを入力してください [ec2-user@ip-10-0-0-246 ~]$ nslookup > set type=ns > hogehoge.com(ドメイン名) 以下のような表示が出れば成功です。 Server: 10.0.0.2 Address: 10.0.0.2#53 Non-authoritative answer: hogehoge.com nameserver = ns-41.awsdns-05.com. hogehoge.com nameserver = ns-543.awsdns-03.net. hogehoge.com nameserver = ns-1061.awsdns-04.org. hogehoge.com nameserver = ns-1598.awsdns-07.co.uk. ネームサーバーが設定されるのに時間がかかる場合があるので、上記のように表示されなくても 数分経ったら再度実行してみてださい Route53でドメインを適応 ホストゾーンからドメイン名をクリックして「レコードを作成」をクリックします。 以下のように記載します。 レコード名: 「www」 レコードタイプ: 「A-IPv4アドレス」 エイリアス: 設定しない 値: 「Elastic IP」 TTL (秒): 「300」 ルーティングポリシー: 「シンプルルーティング」 「レコードを作成をクリック」 4. サーバーでNginxを設定 [ec2-user@ip-10-0-0-246 ~]$ sudo vi /etc/nginx/conf.d/アプリ名.conf server_nameを「www.ドメイン名」に変更します。 client_max_body_size 4G; server { listen 80; server_name www.hogehoge.com; . . . :wq または Shift + ZZ で保存&編集完了 Railsアプリに移動してNginxを再起動します。 [ec2-user@ip-10-0-0-246 ~] $ cd /var/www/rails/アプリ名/ [ec2-user@ip-10-0-0-246 hogehoge] $ sudo service nginx restart Unicornを再起動させます。 まずはUnicornの起動を確認 $ ps -ef | grep unicorn | grep -v grep ryogo 11658 1 0 4月24 ? 00:00:02 unicorn_rails master -c /var/www/rails/travelour/config/unicorn.conf.rb -D -E production ryogo 11662 11658 0 4月24 ? 00:00:02 unicorn_rails worker[0] -c /var/www/rails/travelour/config/unicorn.conf.rb -D -E production ryogo 11663 11658 0 4月24 ? 00:00:02 unicorn_rails worker[1] -c /var/www/rails/travelour/config/unicorn.conf.rb -D -E production 表示されたUnicornの番号をkillしてください。 上記の場合、1行目の11658のみkillすれば良いです。 $ kill 11685 これでUnicornは停止しました。 停止できたか確認しましょう $ ps -ef | grep unicorn | grep -v grep 何も出なければ停止状態です。 Unicornを改めて起動します。 $ bundle exec unicorn_rails -c /var/www/rails/アプリ名/config/unicorn.conf.rb -D -E production これで設定したドメインにアクセスできるようになります。 ブラウザから設定したドメインにアクセスします。 http://www.hogehoge.com/ ブラウザにアプリ画面が表示されれば成功です これで取得したドメインをデプロイしたアプリに紐付ける事が出来ます まだこれだとSSL化をしていないので設定はちゃんとしましょう。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

M5Stack Core2 for AWS のデモ

M5Stack Core2 ESP32 IoT Development Kit for AWS には、チュートリアルとは別に Core2 for AWS IoT Features Demoがある。 各ハードウェア機能をデモで確認することができるもの。画面下の黒いところは、音を検知して表示される領域。画面からはわからないが、SDカードへの読み書きもテストでき、シリアル出力で確認できる。 実行するには、RainMaker Agent ファームウェアのビルドとアップロードと同じ要領でビルド・アップロードする。このとき、Core2-for-AWS-IoT-EduKit/Getting-Started の代わりに Core2-for-AWS-IoT-EduKit/Hardware-Features-Demo を PlatformIO で開く。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Sparkについて(Python,Java,JVM,RDD)

Hadoop,Sparkの分散処理について 巨大データの取り扱いを目的とした分散処理のフレームワーク 分散処理によってビッグデータを高速に処理することが可能 Hadoopの利用者は自作したデータ処理のプログラムや他者が開発したツールプログラムをHadoop内に組み込んでビッグデータ処理が可能 Hadoop上で稼動するデータベースマネージメントシステム(DBMS) Hive Impala Hadoop上で稼動するスクリプト環境 Pig Hadoop連携ソフトウェアの存在がビックデータ処理環境をより便利にしている。 SparkもHadoopと同じく分散処理のフレームワーク adoopがJava言語で作られているのに対してSparkはJavaの派生言語であるScalaで作られています。 Sparkの内部処理方式 データをメモリに保存することで入出力の高速化を図り処理全体の実行速度を向上させようとする取り組みがある。 利用可能メモリが枯渇した場合にはデータをストレージに保存するケースも勘案 機械学習の計算処理に効果を発揮する 実際特定のアプリケーションに関する実行性能は、HadoopのMapReduce処理と比べた場合の100倍 「データの格納場所」に関する選択肢の広さ Sparkで処理を行うデータは「いろいろな種類のデータ置き場」に格納可能 Sparkは様々なデータ格納場所からのデータ入出力に対応している Hadoopがデータの格納場所として基本的には「Hadoop Distributed File System (HDFS)」という独自のファイル格納場所を必要 Hadoop Distributed File System (HDFS) Cassandra OpenStack Swift Amazon S3 上記などが対応可能なストレージ プログラム手法に関する選択肢の広さ Java(直接Hadoopを制御する事からこの方法を生Hadoopと呼んだりします) HiveQL(Hadoop+Hive) Pig(Hadoop+Pig) Hadoop Streamingを使用することで標準入出力を介してPythonなどから制御 「Hadoopとは別のソフトウェア」を介してプログラミングを行う事が一般的 SparkはSpark自身はScalaでプログラムされているものの、他のプログラム言語に対してより緊密なアプローチが採用されています。すなわち、Sparkを制御するための機能が、Scalaだけでない。 Java Python R言語 Spark SQL 各プログラム言語用のAPIとして提供されている。 SparkとHadoopの関係は競合というよりは共存。ユーザには広い選択肢が与えられている *「Hadoop+Spark」の構成も現実的である(Hadoop内のYarn制御下でSparkを利用する) * Sparkはデータの入出力場所としてHDFSにも対応している * 現段階ではSparkとHadoopは共存関係 SparkがHDFS上のデータをその制御の対象としていることは、既存データの再利用性も含めて二者の親和性の高さをより緊密なものにしています。競合関係という意味では「Spark式処理方法とMapReduce式処理方法の競合」という表現が適切 Apache Sparkについて 半構造化データ(https://jp.drinet.co.jp/blog/datamanagement/semi-structured-data) 構造化データ ストリーミングデータ 機械学習 データサイエンス マスターノード上の1つのドライバプロセス(複数のジョブを持てる)から立ち上げられる。 数多くのワーカーノードに分散配置されたエグゼキュータプロセス(複数タスク)に指示を送る。 ・有行非循環グラフ Sparkはそれらのタスクスケジューリングや実行を最適化する。 RDD(耐障害性分散データセット) イミュータブルなJava仮想マシン(JVM)のオブジェクトの分散コレクションを中心として構成されている。 pythonのデータがJVMオブジェクトの中に保存される。 これらのオブジェクトを使うことでいかなるジョブにおいても高速に演算処理可能 RDDはメモリを有効に利用し計算、キャッシュ、保存される。 このおかげで、Apache Hadoopのような他の旧来フレームワークに比べて何桁も演算処理が高速になっている。 RDDの機能 map() reduce() filter() ...etc RDDはデータへの変換の適用と記録を並列に行う。そのため、速度も耐障害性も向上している。 変換を登録しておくことでRDDはデータリネージを提供可能。 何か問題が生じて、一部のデータが失われて場合にフォールバックを行います。失われた場合は再計算が可能。 RDDの操作 変換(新しいRDDポインターを返す。) → 遅延処理 アクション(演算処理を行い、値をドライバーに返す。)矢印戻り値のこと? Sparkの最大の利点は並列に処理が実行されること データセットの様子を掴むために分析の際によく使われる手順。 * ある列中に現れるそれぞれの値の登場回数をカウントする。 * Aで始まる値だけを選択する * その結果を画面に表示させる データのフォーマットもテキスト、parquet、JSON、Hiveのテーブルといった複数のフォーマットがサポートされている。 リレーショナルデータベースからJDBCドライバを使用してデータを読み取ることが可能。 Sparkは圧縮されたデータセットを自動的に扱える。などほとんどあらゆるものを混在させることが可能。 * スキーマレスなデータ構造(tuple、dict、list) メタデータ [https://jp.drinet.co.jp/blog/datamanagement/metadata_management_3minutes] * メタデータとは一言でいうと「データに関するデータ」 * データ:「構造化データ」と「非構造化データ」に分類される。 * 構造化データ:構造化データはデータの内容や形式が定められており、RDBMSで実装 * 非構造化データ:非構造化データは内容や形式に決まりが無く、あらゆるデータが当てはまる。 (映像、音声、テキストデータなども非構造化データ) Pysparkでのpythonの使い方 クラスたモードとローカルモードが存在する。 ローカルモードでの実行 通常のpythonの実行と同じコードでも問題ない。 構造上の変化が生じやすいのは、データとコードが独立したワーカープロセス間でコピーされるようなひねりが加わる場合。 クラスタモードでの実行 ジョブが投入されて実行される時、そのジョブはドライバノードに送られる。 ドライバノードはそのジョブにあるDAGを生成しそれぞれのエグゼキュータノードを決定する。 そして、ドライバはワーカーに対してそれぞれのタスクを実行し、処理が終了すれば結果をドライバに返すよう指示をする。 RDMSについて データを管理・活用するためのシステムとして代表的なのがMySQL、OracleなどのRDBMS(リレーショナルデータベース管理システム)です。 RDBMSは複雑なデータをリアルタイムで取り扱える半面、大量のデータ処理に際して能力が低下してしまうという弱点があります。 DBでの処理では追いつかないデータ量を高速処理するために導入された概念が分散処理 複数のサーバーもしくはCPUでデータを分割し、大量のデータを高速で処理できるようにします。たくさんのパソコンが作業を分けあって処理している様子を思い浮かべるとわかりやすい それがマスターノードとコアノード 分散処理は気象・災害予測や遺伝子解析、SNSのリアルタイム解析、サイトのユーザー行動分析など大量のデータ処理を必要とする作業に用いられます。ビッグデータの取り扱いにおいて分散処理は欠かせない要素であり、昨今その需要は高まり続けています。 分散処理の機能を組み込む際に使えるフレームワークの代表格がHadoopとSpark Docker for Jupyternotebook pyspark
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWS認定ディベロッパーアソシエイト 合格体験記

【AWS認定ディベロッパーアソシエイト 合格体験記】 4/24に合格しました。 800点に乗せたかった。 自分の学習法を簡単にまとめてみました。 今後、AWS DVAの受験を考えておられる方の参考になれば嬉しいです。 はじめに 自分的にディベロッパーアソシエイトは、クラウドプラクティショナーよりは難しかったですが、ソリューションアーキテクトアソシエイトよりは簡単だったと思います。 ソリューションアーキテクトアソシエイトの受験後にディベロッパーアソシエイトの受験を勧めておられる方がたくさんいますが、納得です。 主に通勤電車内での書籍とUdemy模擬問題で勉強し、1回で合格出来ました。 (家での時間はコードを書きたいので通勤時間を無駄にせずやりました。) AWS認定ディベロッパーアソシエイトの概要 720/1000 点 なので、7.2割解けたら合格です。65問です。 分野 1: 展開 1.1 既存の CI/CD パイプライン、プロセス、およびパターンを使用して、記述したコードを AWS 内に展開する。 1.2 Elastic Beanstalk を使用してアプリケーションを展開する。 1.3 AWS に展開するアプリケーション展開パッケージを準備する。 1.4 サーバーレスアプリケーションを展開する。 分野 2: セキュリティ 2.1 AWS サービスに対して、認証された呼び出しを行う。 2.2 AWS サービスを使用して暗号化処理を実装する。 2.3 アプリケーションに対する認証処理と承認処理を実装する。 分野 3: AWS サービスを使用した開発 3.1 サーバーレスアプリケーションのコードを記述する。 3.2 機能要件をアプリケーション設計に反映させる。 3.3 アプリケーション設計に基づいてアプリケーションコードを記述する。 3.4 API、SDK、および AWS CLI を使用して、AWS サービスとやりとりするコードを記述する。 分野 4: リファクタリング 4.1 AWS のサービスと機能を最大限に活用できるようにアプリケーションを最適化する。 4.2 既存のアプリケーションコードを AWS に移行する。 分野 5: モニタリングとトラブルシューティング 5.1 モニタリング可能なコードを記述する。 5.2 テスト環境または本番環境で見つかった障害に対する根本原因分析を行う。 (AWS認定公式サイトから引用) 詳しい内容は、こちらからご確認頂くと良いと思います。 →AWS 認定 デベロッパー – アソシエイト 学習教材 使用した学習教材は2つです。 ・山下光洋さんのポケットスタディ AWS認定 デベロッパーアソシエイト (アソシエイト試験ポケットスタディ) 上記の書籍がとてもとてもおすすめです。 この1冊を購入して、一通り内容を理解すれば合格可能です。 問題が豊富なのでとてもありがたいです。 ・AWS 認定デベロッパー アソシエイト模擬試験問題集(5回分325問) Udemyの模擬試験は実際の試験では求められないものが多いように感じました。 セール時の購入を逃した方は購入しなくていいと思います。 ※Udemyの講座はセール時に購入すると出費を抑えられます。 私が実践した学習手順 1、書籍を1周読む。とてもわかりやすく説明されています。 2、書籍の各チャプターの問題を解く。 (実際の試験にも似たような問題が出ました。) 3、書籍の模擬試験を解く。 (実際の試験にも似たような問題が出ました。) 4、Udemy 模擬試験 5回分を解く。 5、Udemy 模擬試験の不正解問題の復習をする。 (こちらにあまり時間はかけなくて良いと思います。) 6、試験直前に書籍の模擬試験を再度おこなう。 (50問ありますが、全て理解するまでやります。) 今後の反省 800点台での合格だろうと思っていたのですが、700点でした。 まだまだ自分に甘い思うので、もっと効率性も意識しつつ、量をこなします。 AWSの開発寄りの知識の基礎を身に付けられたと思います。 ポートフォリオにAWS ECS, Fargateなどを組み込んで、実践的な知識を身につけてアピールできるようにしていきます。 インフラのコード化にも関心があるので、後々手を出していきます。 ・Udemyの模擬試験の点数推移を参考に。 このような感じでした。 1度目は、全問回答しないで問題文と解答を照らし合わせました。 模擬試験① 0%正解→43%正解→60%正解 模擬試験② 0%正解→45%正解→71%正解 模擬試験③ 0%正解→39%正解→69%正解 模擬試験④ 0%正解→49%正解→59%正解 模擬試験⑤ 0%正解→45%正解→63%正解 ※Udemyに時間をかけるよりも書籍の問題を解くことをおすすめします。 おわりに。 書籍の著者である山下さんのAWS DVAの勉強会に参加させて頂きました。 AWSについて前よりも関心が増しました。DVA試験にも役立ちました。 主催者の山下さん、登壇し発表してくださった方々、ありがとうございました。 初めての勉強会でしたが、いい経験になりました。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

EC2で静的ページを公開してELB / AutoScaling / CloudWatchで動作検証してみる

環境 macOS Big Sur バージョン 11.2.3 EC2 / ALB / CloudWatch / Apache 目的 EC2で静的ページを公開、CloudWatchでCPUを監視、CPUの値によってEC2を増減させます。 ※ハンズオン形式ではりませんので、記事としてご参考ください。 以下のテスト環境で検証を進めます。 作成済みのEC2(ST-WebServer1)にindex.htmlを作成 EC2 # SSH接続後にec2-user からRoot へユーザ切替 sudo su - # パッケージをアップデート yum -y update # Apacheのインストール yum -y install httpd # Apacheの起動 systemctl start httpd # EC2の再起動後にもApacheが自動起動するように設定 systemctl enable httpd # Apacheが起動したか確認 systemctl status httpd #serviceがactiveになっていればOKです. 下記の手順でEC2でHTMLファイルを作成して公開します。 EC2 # HTMLファイルを格納するディレクトリへ移動 cd /var/www/html #HTMLファイル作成 touch index.html # HTMLファイルの中身を記述 vi index.html # iを押下して、insert mode に移行し、以下内容を記述し、 :wq で保存します。 <html lang="ja"> <head> <meta charset="utf-8"> <title>test-page</title> </head> <body> <h1>Hello world!</h1> <p>ST-WebServer1</p> </body> </html> ブラウザからEC2のパブリックIPアドレスにアクセスしてHello world!が表示されればokです。 このままだと障害の発生でサービス停止してしまうので、EC2を冗長化します。 1.EC2のAMIを取得 すでに作成済みのST-WebServer1を停止. EC2が停止済みとなっていることを確認して、 [アクション]の[イメージとテンプレート]から[イメージを作成]を選択。 イメージ名を入力、その他の値はデフォルトで進めます。 左ペインAMIからイメージのステータスを確認。 作成中(pending)なのでしばらく待ちます。 作成したイメージからインスタンスを起動。 左ペインのマイAMIから作成したAMIを選択。 ネットワークはST-VPC1、サブネットはパブリックサブネット2を選択。 自動割り当てパブリックIPは有効にします。 タグはNameをST-WebServer2とします。 セキュリティグループはST-WebServer1で使用しているST-Web-SG1を選択。 最後にサマリを確認して起動を押下します。 キーペアの確認画面が出ますが、ここではST-WebServer1ですでに作成しているキーペアを使います。 上記まででST-WebServer1と2が構築できました。 ST-WebServer1が停止状態なのでインスタンスを開始しておきます。 続いて、ST-WebServer2のindex.htmlを書き換えます EC2 #ST-WebServer2へ接続 ssh -i Downloads/MyKeyPare1.pem ec2-user@パブリックIPアドレス #SSH接続後にec2-user からRoot へユーザ切替 sudo su - # HTMLファイルを格納する場所ディレクトリへ移動 cd /var/www/html #HTMLファイルの作成 touch index.html # HTMLファイルの中身を記述 vi index.html # i を押し、insert mode に移行、以下内容を記述し、 :wq で保存します。 <html lang="ja"> <head> <meta charset="utf-8"> <title>test-page</title> </head> <body> <h1>Hello world!</h1> <p>ST-WebServer2</p> </body> </html> 保存後、ブラウザからST-WebServer2のパブリックIPへ接続、 「Hello world!ST-WebServer2」が表示されればokです。 これで2台のWebサーバーが構築できました。 ELBを作成 左ペインからロードバランサーを選択します. ロードバランサーを作成。 Application Load Balancerを選択。 ロードバランサーの設定を進めます。 名前はST-LB1として、 VPCとアベイラビリティゾーンを選択(1aと1cからパブリックサブネット1と2)を選択します。 セキュリティグループは名前をST-LB-SG1として新規作成します。 ルーティングを設定します。 新しいターゲットグループをST-TG-1として作成します。 続いてヘルスチェックの詳細設定。 テスト環境なので今回は正常の閾値を2、間隔は10秒としておきます。 ターゲットの登録ではST-WebServer1とST-WebServer2を選択し登録済みに追加。 最後にサマリ画面を確認して問題なければ作成します。 作成後、左ペインのターゲットグループからタブのTargetsを選択するとヘルスチェックの状態を確認できます。作成直後はinitialになっています。 Webページにアクセスしてロードバランサーの振り分けを確認 再度左ペインのロードバランサーから作成したST-LB1を選択、DNS名をコピーします。 ブラウザの検索窓にDNS名を入力してindex.htmlが表示されることを確認します。 何度か読み込みをしてみてST-WebServer1とST-WebServer2が切り替わって表示されていれば振り分けはokです。しかしこのままだとWebサーバーのセキュリティグループが全ての接続元からの接続を許可した設定のため、ロードバランサーのセキュリティグループからの通信のみを許可するよう設定を変更していきます。 EC2の画面の左ペインからセキュリティーグループを押下、 ST-Web-SG1を検索します。 インバウンドルールを編集。 すでに設定されているHTTP の0.0.0.0/0と::/0は削除します。 ルールを追加します。 タイプにHTTPを選択、ロードバランサーに設定したST-LB-SG1を選択してルールを保存します。 続いて、再度ブラウザにロードバランサーのDNS名を入力、ST-WebSever1と2からレスポンスがあるか確認します。 ST-WebSever1を停止してもST-WebSever2で継続して閲覧できるか確認します。 ST-WebSever2でWebサイトを継続して閲覧できることが確認できました。 AutoScalingでEC2を増減させる 上記手順でEC2を2台で通信を振り分けることが可能になりましたが、この2台で処理し切れないほどの通信が発生した場合には、ページを閲覧できなくなってしまうので、EC2を増減させることで一時的な対応が可能になリます。 1.起動テンプレート作成 EC2の画面の左ペインから[テンプレートの起動]へ移動、[起動テンプレートを作成]を押下. テンプレート名とバージョンを入力、チェックボックスにはチェックを入れます。 AMIはすでに作成しているST-WebServerを選択. インスタンスタイプ、キーペアを選択、ネットワーク設定はVPCを選択。 リソースタグのキーにST-WebServer-Autoと入力しておくことで、自動で立ち上がるインスタンスに任意のNameが付与することができます。 セキュリティグループはST-Web-SG1を選択、既存のEC2インスタンスと同様のセキュリティグループを設定します。 パブリックIPの自動割り当ては有効化、高度な詳細はデフォルト値で作成します。 なお、起動テンプレートは設定を変更できますが、バージョン管理できる点が最大のメリットです。 EC2インスタンスをスケーリングさせてみる すでに作成したEC2インスタンスのST-WebServer1とST-WebServer2は停止状態にします。 EC2の画面の左ペインからAutoScalingグループを作成。 Auto Scaling グループ名はTEST-ST-AutoCaling1とします。 起動テンプレートはST-LaunchTemplate1を選択、バージョンはLatest()を選択します。 インスタンスの購入オプションは[起動テンプレートに準拠する]を選択、VPCを選択、 ST-PublicSubnet1とST-PublicSubnet2を選択します。 続いて、詳細オプションを設定します。 既存のロードバランサーにアタッチを選択し、ST-TG-1を選択、 ユーザーがWebページを閲覧できることが目的のため、ELBのHTTP80番ポートのヘルスチェックも必要となります。そのためELBにはチェックを入れます。 グループサイズは、希望する容量2 最小キャパシティ2 最大キャパシティ4とします。 インスタンスのスケールイン保護はチェックなしで進めます。 次のステップの[通知を追加]と[タグを追加]は今回は追加せずに進めます。 サマリを確認して間違いがなければ[AutoScallingグループを作成]を押下します。 EC2インスタンスの画面に戻るとすでにST-WebServer-Autoが2台立ち上がっていることを確認できました. 再度、ロードバランサーのDNS名にアクセスしても継続してWebページが表示されていることを確認できました。 CloudWatchでCPUを監視して、使用率によってEC2を増減させる 1.CloudWatchでアラームを作成 メトリクスはEC2を選択します。 [Auto Scaling別]を選択、TEST-ST-AutoCaling1のCPUUtilizationを選択。 条件を選択していきます。 欠落データの処理については、EC2のCPU高負荷が原因でデータが取得できないことを想定して [閾値を超えているとして処理]を選択します。 アラーム名はわかりやすい名前にしておきます。 2.同様の手順でST_CPU_Lowを作成していきます。 ST_CPU_Lowのアラームについては欠落データの処理を[見つかりませんとして処理]を選択します。 作成後、アラームの一覧へ戻ります。 しばらく待ってアラームの状態が下記画像の状態になっていれば正常です。 3.スケーリングポリシーとアラームを紐付ける 左ペインからAuto Scalingグループの画面に戻ります。 作成したAuto Scalingグループを選択します。 スケーリングポリシーを追加してアラームを紐付けます。 スケーリングポリシーを追加します。 [シンプルなスケーリング]を選択、ポリシー名はST_CPU_addとしておきます。 CloudWatchアラームはST_CPU_Highを選択、 アクションは、[追加][1][キャパシティユニット]として、30秒待機する設定にします。 同様の手順でポリシー(ST_CPU_remove)を追加していきます。 ポリシー名はST_CPU_removeとして、 アラームはST_CPU_Lowを選択、 アクションは、[削除][1][キャパシティユニット]、30秒待機する設定にします。 EC2インスタンスに負荷をかけて動きを検証 稼働しているEC2インスタンスを選択し、インスタンスに接続。 接続したEC2インスタンスで以下のコマンドを4回実行してCPU負荷をかけていきます。 EC2 # yes >> /dev/null & # yes >> /dev/null & # yes >> /dev/null & # yes >> /dev/null & その後topコマンドでCPUを確認して70%を超えていることを確認します。 EC2 # top 同様の手順でもう一方のEC2インスタンスでもCPU負荷をかけていきます。 CPU高負荷でインスタンスが立ち上がっているかを確認 しばらくすると先ほどまでは2の構成て稼働していましたが、 2インスタンス追加され最大4の構成となっていることを確認できました。 EC2で起動したプロセスを終了させる 最後にプロセスを終了させます。 再度topコマンドでPIDを確認。 killコマンドでプロセスを終了します。 EC2 # kill 4226 PIDが連番であれば波括弧を使って一括で終了できます。 # kill {4226..4229} なお、CPUなどのメトリクスの値についてはCloudWatchの画面の左ペイン、 [メトリクス]でグラフ表示することができます。 プロセスを終了させCPUが30%より低くなると、スケーリングポリシーにより 不要となったインスタンスはシャットダウンされていることを確認できました。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

ECS+FargateのAutoScaling設定をTerraformで定義する(スケジュール編)

はじめに ECS+Fargate の AutoScaling は便利で、徐々にアクセス量が増えていくようなケースには対応できるものの、一気にトラフィックが3倍になるようなバーストケースは、仮に予見されるものであってもCPUリソースやアクセス量を監視しているだけでは対応しきれない。 そういったケースでは、予めスケジュールを組んでタスク量を調節しておくことで対応をしよう。 ※予見できないバーストトラフィックはさすがに無理なので、そこはもうある程度余裕をもってリソースを用意しておくしかないだろう。 本記事では、ベースに前回の記事の予備知識があることを前提とする。ECS+Fargate や AutoScaling に関する基本的な設定は改めて説明はしないので悪しからず。 また、クラスメソッド先生の記事も参考に。 なお、EC2のスケジュールベースの AutoScaling はマネージメントコンソールで確認できるが、ECS+Fargateの場合はどこを見ても確認できない。謎だが、ちゃんと動作はするので気にしないことにした。 スケジュールベースの AutoScaling の Terraform での設定方法 Terraform では appautoscaling_scheduled_action のリソースを使う。 対して難しいことはない。上記の例のように、時間帯でトラフィックが予期できる場合は、以下のように2つのスケジュールを組むことでリソース量をコントロール可能になる。 resource "aws_appautoscaling_scheduled_action" "ecsfargate_peak" { name = "ecsfargate_peak" service_namespace = aws_appautoscaling_target.ecsfargate.service_namespace resource_id = aws_appautoscaling_target.ecsfargate.resource_id scalable_dimension = aws_appautoscaling_target.ecsfargate.scalable_dimension schedule = "cron(15 * * * ? *)" scalable_target_action { min_capacity = 20 max_capacity = 40 } } resource "aws_appautoscaling_scheduled_action" "ecsfargate_normal" { name = "ecsfargate_normal" service_namespace = aws_appautoscaling_target.ecsfargate.service_namespace resource_id = aws_appautoscaling_target.ecsfargate.resource_id scalable_dimension = aws_appautoscaling_target.ecsfargate.scalable_dimension schedule = "cron(20 * * * ? *)" scalable_target_action { min_capacity = 10 max_capacity = 20 } } schedule のプロパティは、ユーザーガイドに設定例が書かれている。at で日時指定、rate で間隔で定期的に動作させることができ、cron で毎時何分に起動や、毎日何時何分に起動といったことができる。cron は CloudWatch Event の記載方法に従う。 上記の例では、毎時15分にピークトラフィックに備えてスケールアウトさせ、毎時20分に収まるのでスケールインする。当然ながらこれは例であって、ECS+Fargate は課金単位が1時間なので、こういった設定をする意味はない。 実際に動作させる 上記の Terraform を apply した後の動作がこちら。 多少のタイムラグはあるものの、16:16 に必要なタスク数が上がってタスク実行され、16:21 には下がって drain されている。 ECSのサービスのログでも、以下のように出力されていて、時間通りにスケジュールでタスク数の最大と最少が変更されていることが分かる。 今回はCPU使用率によるスケールインのポリシーも設定しているため、スケジュールで MAX:4/MIN:2 になった後に、CPU使用率が低いためにタスク数が2まで推移する、といった動作だ。 これで、CPU使用率やトラフィック量だけでなく、時間でより細かくタスク数をコントロールできるようになった!
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【ギリ初心者向け】Laravel Docker AWS(EC2) Webアプリ(PHP)を0から簡単にデプロイする方法(無料)③ ーEC2にデプロイ編ー

0.概要  何度もいいますが、知らない単語が出た瞬間ググってください!!!!! ①の全体像編がこちらにあるのでこちらを一読してからだと理解がスムーズかと!!! https://qiita.com/SG_Sg/items/6b8ce48567b6b6602805  ②のDocker環境構築編もあるのでこちらでデプロイするアプリを作成してます https://qiita.com/SG_Sg/items/6b8ce48567b6b6602805 今回で作成するは具体的にいうと赤いとこ 以上が完成すると、世の中にアプリを公開することができます! つまり 特定のURLを叩くと誰でも作成したWebアプリを動かせる状態 ⇦目指すはここ AWSのEC2インスタンスを利用してデプロイを行うための流れ AWS?EC2インスタンス?とはなんですか?? AWS EC2インスタンスとは、Amazonが提供している仮想サーバー構築サービスです。。。。難しいですかね。 ざっくり言うと よくサーバーってなんかでかい四角い箱のイメージですが、AWSのEC2インスタンスはそれをクラウド上に作れる!! (EC2インスタンスとは OSを載せた仮想サーバーです) まあ概念的なものはおいといて手を動かしましょう。 上の図を完成させるための流れを説明します。 ①AWSにアカウントを作成する。 ②EC2インスタンスを作成する ③EC2インスタンスにSSHでアクセス ④EC2インスタンス(Ubuntu)に必要なアプリケーションをインストール ⑤GitHubからプロジェクト(ソースコード)をPULL ⑥Laravelをインストールしてのトップ画面を表示 ⑦データベースと接続 ⑧URLを叩いてアクセス!! 上の7つ行えば完了です! さあやっていきましょう! ①AWSにアカウントを作成する さて、AWSのアカウントを作成するのですが、、、 以下公式 https://aws.amazon.com/jp/register-flow/ わかりやすそうな動画つきのサイト https://blog.serverworks.co.jp/tech/2020/07/17/hajimeteno_aws_account/ 今回はAWSのEC2インスタンスというサービスを使うので、1年間は基本的にお金がかかりません! 利用サービスによっては一部料金をとられたりしますのでご注意ください。 https://www.fenet.jp/aws/column/aws-beginner/197/ 上記を参考に設定してもらえればお金はかからないことがわかります。 以上の操作でアカウントが作成し、TOP画面にきたら右上がこちらは東京(日本)にしてあることを必ず確認してください! ヨーロッパ等になっていたらかならずタップして アジアパシフィック「東京」 にするようにお願いします。 ②EC2インスタンスを作成する 1,サービスをタップし、EC2をタップ。 2,インスタンスをタップ 3,EC2インスタンス一覧が表示されたらインスタンスを起動をタップ 4,今回は Ubuntu Server 20.04 LTS (HVM), SSD Volume Type - ami-059b6d3840b03d6dd (64 ビット x86) を使いますのでこれを選択。(無料枠対象でUbuntuを使います。) 5,インスタンスタイプの設定。ここでインスタンスの容量を設定。今回は無料枠で行うので無料枠のt2.microを使います。 そして次のステップ:インスタンスの詳細の設定をタップ (ここからの設定はあとで変更できるので確認と作成でもいいですが、先に設定しちゃいましょう!!) 6,詳細にネットワークの設定をできますが、今回はこちらデフォルト(そのまま)で次のステップ:ストレージの追加をタップ 7,こちらでストレージサイズをいじれますが、今回はこちらもデフォルト(そのまま)で次のステップ:タグの追加をタップ 8,タグを追加できますが、今回は追加せずそのままで次のステップ:セキュリティグループの設定をタップ 9,セキュリティグループを設定します。 新しいセキュリティグループを作成する。にしてグループ名説明は自分でわかるように設定。 ルールの追加をタップして タイプは以下のように追加してください。 ※SSHの部分のポート範囲をマイIPしていますが、こちらは自分IPを使って接続しますよーの意味です。 そのため、自分のIPがコロコロ変わるWifi回線を使っている方は利用するたびにSSHのポート範囲を変えなければいけませんのでご注意!! もし不安でしたら今回はテストですので SSHのソースを 任意の場所 にして 0.0.0.0/0, ::/0 で良いと思います。 入力し終わったら確認と作成をタップ! 10,作成の確認画面がでますが、そのまま「起動」ボタンを押しましょう! 11,キーファイルを作成します。まずはプルダウンを 新しいキーペアの作成  キーペア名は任意ですが「HelloLaravel」とします 次にキーペアのダウンロードをタップ  ダウンロードされた「HelloLaravel.pem」をデスクトップにおいておきます。鍵の場所は必ずわかるようにしておいてください。  ※このダウンロードされたキーファイルはその名も通り、このインスタンスの中に入るための鍵なので無くさないように大切に保存しましょう。  今回はデスクトップにおきますが、本当は/.sshフォルダの中にあるとよいですね! 鍵ファイルをダウンロードできたら、インスタンスの作成 をタップ! 12,これでインスタンスを作成できたので インスタンスの表示 で開くなど3のインスタンス一覧まで戻りましょう。 そして、インスタンスが作成してから動かせるようになるまで少し時間がかかるので少々おまちください。 数分たったらこんな風になっていればOKです! ステータスチェックが2/2になっていることを確認してください! これでインスタンスの作成が完了です!! ③EC2インスタンスにSSHでアクセス 1,ターミナル(端末)を開いて、権限を変更し、SSHでアクセスする。 ターミナルを開き、ホームディレクトリ(最初の階層)で 先ほど保存した、鍵ファイルの権限を変えます(これをしないと接続できません) //鍵ファイルの権限を読み取りもできるように変更 ~ chmod 600 ~/Desktop/HelloLaravel.pem //鍵ファイルで作成したインスタンスにSSHでログイン ~ ssh -i ~/Desktop/HelloLaravel.pem ubuntu@(EC2インスタンスのパブリックIPアドレス) ※(EC2インスタンスのパブリックIPアドレス)これは↓の赤枠の部分に書いてある数字です。赤枠の左の部分の四角いマークをタップすればコピーできます ↓こうなっていたらアクセス完了です! ubuntu@ip-自分のIP:~$ ④EC2インスタンス(Ubuntu)に必要なアプリケーションをインストール 1,php7.4をインストール //パッケージの更新 ubuntu@ip-自分のIP:~$ sudo apt-get update //PHP PPA Repositoryを追加 ubuntu@ip-自分のIP:~$ sudo apt -y install software-properties-common ubuntu@ip-自分のIP:~$ sudo add-apt-repository ppa:ondrej/php ubuntu@ip-自分のIP:~$ sudo apt-get update //PHPインストール ubuntu@ip-自分のIP:~$ sudo apt -y install php7.4 //バージョン確認 ubuntu@ip-自分のIP:~$ php -v PHP 7.4.16 (cli) (built: Mar 5 2021 07:54:38) ( NTS ) Copyright (c) The PHP Group Zend Engine v3.4.0, Copyright (c) Zend Technologies with Zend OPcache v7.4.16, Copyright (c), by Zend Technologies 2,MySQL 8.0をインストール //パッケージの更新 ubuntu@ip-自分のIP:~$ sudo apt update //mysqlインストール ubuntu@ip-自分のIP:~$ sudo apt install -y mysql-server //mysqlを動かす ubuntu@ip-自分のIP:~$ sudo service mysql start //バージョン確認 ubuntu@ip-自分のIP:~$ sudo mysql -u root -e'select version();' +-------------------------+ | version() | +-------------------------+ | 8.0.23-0ubuntu0.20.04.1 | +-------------------------+ 3,nginx1.18をインストール //パッケージの更新 ubuntu@ip-自分のIP:~$ sudo apt update //nginxをインストール ubuntu@ip-自分のIP:~$ sudo apt install -y nginx //場所を確認 ubuntu@ip-自分のIP:~$ sudo which nginx /usr/sbin/nginx //バージョン確認 ubuntu@ip-自分のIP:~$ nginx -v nginx version: nginx/1.18.0 (Ubuntu) nginxが動いているのかの確認 ubuntu@ip-自分のIP:~$ sudo service nginx start ubuntu@ip-自分のIP:~$ sudo service nginx status ● nginx.service - A high performance web server and a reverse proxy server Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset:>    //↓がactiveになってたらOK。 Active: active (running) since Sun 2021-04-11 06:44:04 UTC; 1s ago Docs: man:nginx(8) ・・・・・・ //Failになっていたらポートが占領されていたりするので ubuntu@ip-自分のIP:~$ sudo lsof -i:80 //確認して一度占領ポートを全部消す。数字は↑で確認した番号 ubuntu@ip-自分のIP:~$ sudo kill 23930 23933 23934 23935 23936 23937 25159 http://(EC2インスタンスのパブリックIPアドレス)/index をgoogleでアクセス!notfoundでnginxが動いていることを確認 ※番外 HTMLファイルをテストで表示 ubuntu@ip-自分のIP:/var/www$ ls html ubuntu@ip-自分のIP:/var/www$ cd html/ ubuntu@ip-自分のIP:/var/www/html$ vi test.html ↓test.htmlを作成 <html> <body>HTMLTEST</body> </html> http://(EC2インスタンスのパブリックIPアドレス)/test.html をgoogleでアクセス! HTMLTESTが表示されていたらnginxでHTMLが表示できていることを確認できる。 ④php7.4-fpmをインストールする ubuntu@ip-自分のIP:~$ sudo apt update //php-fpmをインストール ubuntu@ip-自分のIP:~$ sudo apt install php7.4-fpm //バージョンを確認 ubuntu@ip-自分のIP:~$ php-fpm7.4 -v PHP 7.4.16 (fpm-fcgi) (built: Mar 5 2021 07:54:38) Copyright (c) The PHP Group Zend Engine v3.4.0, Copyright (c) Zend Technologies with Zend OPcache v7.4.16, Copyright (c), by Zend Technologies ⑤GitHubからプロジェクト(ソースコード)をクローン ubuntu@ip-自分のIP:/var/www$ sudo git clone https://github.com/K-SG/DockerLaravelTestProject.git Cloning into 'DockerLaravelTestProject'... remote: Enumerating objects: 164, done. remote: Counting objects: 100% (164/164), done. remote: Compressing objects: 100% (119/119), done. remote: Total 164 (delta 25), reused 157 (delta 18), pack-reused 0 Receiving objects: 100% (164/164), 72.99 KiB | 7.30 MiB/s, done. Resolving deltas: 100% (25/25), done. //確認 ubuntu@ip-自分のIP:/var/www$ ls DockerLaravelTestProject html //プロジェクトの権限をwww-dataに変更 ubuntu@ip-自分のIP:/var/www$ sudo chown -R www-data:www-data DockerLaravelTestProject/ ubuntu@ip-172-31-35-119:/var/www$ ls -al total 16 drwxr-xr-x 4 root root 4096 Apr 18 06:04 . drwxr-xr-x 14 root root 4096 Apr 18 05:51 .. drwxr-xr-x 5 www-data www-data 4096 Apr 18 06:04 DockerLaravelTestProject drwxr-xr-x 2 root root 4096 Apr 18 06:12 html ⑥nginxの設定を変えて、phpファイルが表示できることを確認 1,nginxの設定ファイルを変える ubuntu@ip-自分のIP:/var/www$ cd /etc/nginx/sites-enabled/ ubuntu@ip-自分のIP:/etc/nginx/sites-enabled$ sudo vi default 以下に変更する。 server { listen 80 default_server; listen [::]:80 default_server; # SSL configuration # # listen 443 ssl default_server; # listen [::]:443 ssl default_server; # # Note: You should disable gzip for SSL traffic. # See: https://bugs.debian.org/773332 # # Read up on ssl_ciphers to ensure a secure configuration. # See: https://bugs.debian.org/765782 # # Self signed certs generated by the ssl-cert package # Don't use them in a production server! # # include snippets/snakeoil.conf; root /var/www/DockerLaravelTestProject/backend/public; # Add index.php to the list if you are using PHP       index index.html index.htm index.nginx-debian.html index.php; server_name _; location / { # First attempt to serve request as file, then # as directory, then fall back to displaying a 404. # try_files $uri $uri/ =404; try_files $uri $uri/ /index.php?$query_string; } # pass PHP scripts to FastCGI server # location ~ \.php$ { include snippets/fastcgi-php.conf; # # # With php-fpm (or other unix sockets): fastcgi_pass unix:/var/run/php/php7.4-fpm.sock; # # With php-cgi (or other tcp sockets): # fastcgi_pass 127.0.0.1:9000; fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name; fastcgi_split_path_info ^(.+\.php)(.*)$; fastcgi_param PATH_INFO $fastcgi_path_info; include fastcgi_params; } # deny access to .htaccess files, if Apache's document root # concurs with nginx's one # #location ~ /\.ht { # deny all; #} } ※設定ファイルを変更(↑のように)、サーバーがうまく動作していない場合はnginxを必ず再起動 ubuntu@ip-自分のIP:~$ sudo service nginx stop ubuntu@ip-自分のIP:~$ sudo service nginx start //状態を確認 ubuntu@ip-自分のIP:~$ sudo service nginx status 2,プロジェクトにPHPファイルを作って接続を確認する。 //プロジェクトの中のpublicまで移動 ubuntu@ip-自分のIP:/var/www/DockerLaravelTestProject/backend/public$ ls favicon.ico index.php robots.txt web.config ubuntu@ip-自分のIP:/var/www/DockerLaravelTestProject/backend/public$ sudo vi phpinfo.php ↓で保存phpinfo.phpを作成 <?php phpinfo(); ?> http://(EC2インスタンスのパブリックIPアドレス)/phpinfo.php をgoogleでアクセス! PHPの情報が表示されていたらnginxでPHPのファイルがが表示できていることを確認できる。 3,現状足りていないPHPに必要なものをインストール ubuntu@ip-自分のIP:/var/www/DockerLaravelTestProject/backend$ sudo apt install php7.4-mbstring php-xml php-json ⑦LaravelをインストールしてWelcome画面表示する 1,Laravelをインストール //コンポーザーをインストール。(ここでエラーが出る場合、PHPに必要なものが入っていないのでググってインストールしよう!) ubuntu@ip-自分のIP:/var/www/DockerLaravelTestProject/backend$ sudo composer install //composer install 時は .env 環境変数ファイルは作成されないので、 .env.example を元にコピーして作成します ubuntu@ip-自分のIP:/var/www/DockerLaravelTestProject/backend$ sudo cp .env.example .env ubuntu@ip-自分のIP:/var/www/DockerLaravelTestProject/backend$ cd ../ //backend以下の権限がないため権限を変更する ubuntu@ip-自分のIP:/var/www/DockerLaravelTestProject$ sudo chmod 777 -R backend/ ubuntu@ip-自分のIP:/var/www/DockerLaravelTestProject$ cd backend/ //アプリケーションキーを生成する ubuntu@ip-自分のIP:/var/www/DockerLaravelTestProject/backend$ php artisan key:generate Application key set successfully. //APP_KEY=base64:bfeLkhwqXIFbGtwhaJOp0TpfHTJD3Q+SRi7lVwB・・・・となっていることを確認。 2,welcome画面を表示する http://(EC2インスタンスのパブリックIPアドレス) をgoogleでアクセス! ↑のようなものが表示されたらOK!! ⑧データベースを作成する ※【ギリ初心者向け】Laravel Docker AWS(EC2) Webアプリ(PHP)を0から簡単にデプロイする方法(無料) ②で作成した合わせるのでファイルをみながらすすめます。 1,mysqlにログインしてユーザーを作成する。 ubuntu@ip-自分のIP:/var/www/DockerLaravelTestProject/backend$ sudo mysql -u root -p //PWを求められますがrootユーザーはMACに入るときのPW を入力 Enter password: ・・・・・・ //mysqlに入れたことを確認 mysql> 2,プロジェクトの.envファイルをみながらユーザー、DBを作成する! その前にプロジェクトの.envファイルのDBの部分をみる DB_CONNECTION=mysql DB_HOST=db DB_PORT=3306 DB_DATABASE=sg_db DB_USERNAME=sg DB_PASSWORD=sg //sgというdbユーザーを作成。PWはsg mysql> create user 'sg'@'localhost' identified by 'sg'; Query OK, 0 rows affected (0.01 sec) //databaseを作る権限をsgユーザーに付与する mysql> GRANT ALL ON sg_db.* TO 'sg'@'localhost'; Query OK, 0 rows affected (0.00 sec) //mysqlからでる mysql> exit; Bye ubuntu@ip-自分のIP:~$ sudo mysql -u sg -p //PWはさっき設定したsg Enter password: //データベースを作成する mysql> create database sg_db; Query OK, 1 row affected (0.01 sec)w mysql> show databases; +--------------------+ | Database | +--------------------+ | information_schema | | sg_db | +--------------------+ //抜ける mysql> exit; Bye 3,テーブルを作るためにマイグレーションを実行する! まずはマイグレーションを実行するために、mysqlに接続できるように設定を変更する。 ※マイグレーションがうまくいかなかったら都度ググりましょう!結構うまくいかないパターンはあります。。キャッシュがたまっていたり。。。 ubuntu@ip-自分のIP:/var/www/DockerLaravelTestProject/backend$ sudo vi .env //DBの部分を↓に変更。HOSTはlocalhost DB_CONNECTION=mysql DB_HOST=localhost DB_PORT=3306 DB_DATABASE=sg_db DB_USERNAME=sg DB_PASSWORD=sg ubuntu@ip-自分のIP:/var/www/DockerLaravelTestProject/backend$ sudo php artisan migrate Migrating: 2014_10_12_000000_create_users_table Migrated: 2014_10_12_000000_create_users_table (65.08ms) Migrating: 2014_10_12_100000_create_password_resets_table Migrated: 2014_10_12_100000_create_password_resets_table (55.04ms) Migrating: 2019_08_19_000000_create_failed_jobs_table Migrated: 2019_08_19_000000_create_failed_jobs_table (59.14ms) Migrating: 2021_01_03_090902_create_people_table Migrated: 2021_01_03_090902_create_people_table (31.46ms) //マイグレーションできたらデータベースの中にテーブルが作られていることを確認すると良い //この流れでSeederも入れてしまおう。 ubuntu@ip-自分のIP:/var/www/DockerLaravelTestProject/backend$ php artisan db:seed Seeding: Database\Seeders\PeopleTableSeeder Seeded: Database\Seeders\PeopleTableSeeder (11.62ms) Database seeding completed successfully. 4,アプリを表示して接続を確認! http://(EC2インスタンスのパブリックIPアドレス)/hello これにて終了です。 お疲れ様でした。 これでLaravelアプリをEC2にデプロイすることができました!!ここのDBとかをmysqlworkbenchとかで管理できたら良いですね!! それでは良いWebアプリ制作ライフを!!
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWSのEC2を複製し、ドメイン設定、ELBも設定してみた

現在開発で使っていたEC2を複製し、Route 53でドメイン取得を 今後のためにELBを付与するところまで行いました ※内容が多くなりそうなら、分割します、、 EC2を複製 https://qiita.com/ponsuke0531/items/ceca4ac18c097f8b24b8 1.ec2 > インスタンス選択 し右クリック イメージとテンプレート>イメージを作成 2.手順にしたがって進めていきます イメージ名、イメージの説明 - オプションを入力、再起動しないにはチェックなしにする 3.AMIから複製 サイドメニューの[AMI] > 一覧に作成したイメージが表示される ※ステータスがavailableになったら作成済み 作成済みになったら複製したものを選択し[起動]ボタンでインスタンス作成画面を表示する 通常のインスタンスの作成画面と同じ様に、インスタンスタイプの選択やセキュリティーグループの設定を行う 画面フロー通りにボリュームの追加など、自身の用途に合わせ選択する Elastic IPの登録 作成したものは、インスタンスを再起動ごとにIPアドレスが変更される状態になっています。 まずは、Elastic IPを使用しIPアドレスを固定します Elastic IP (EIP) はEC2のインスタンスに固定グローバルIPアドレスを付与するサービスです。 インスタンスに独自ドメインを割り当てるためにはこのEIPとインスタンスの紐付けが必要 https://ja.amimoto-ami.com/elastic-ip-and-route-53/ ついでに大まかな流れはこちらを参照 https://qiita.com/Jerid/items/d5dd3a29ed9a0e374493 Elastic IP アドレスの割り当て ec2> Elastic IP >Elastic IP アドレスの割り当て (新規の場合、新しいアドレスの割り当て) デフォルトのまま特に変更することなくAmazonのIPv4アドレスプールで割り当て スクリーンショット 2021-03-08 11.16.26 2.関連付け 作成したElastic IPを選択し、 アクション>Elastic IPの関連付けクリック 作成したインスタンス名をいれ、IPを紐付けます リソースタイプ インスタンス インスタンス名 先ほど作成したインスタンス名 「プライベートIPアドレス」にはそのインスタンスのプライベートIP 再関連付け チェックなし ロードバランサー (ELB)を設定 ※必要な方は行ってください ec2 1台でもELBを設定してるとCloudWatchを設定できたり、後のインスタンスを増やすのが簡単だったりメリットがあります。 今回は1台ですが、設定しておこうと思います メリットの詳細はこちらのサイトがわかりやすかったので、参考まで https://dev.classmethod.jp/articles/benefit_elb_with_one_ec2/ ec2 > ロードバランサー > ロードバランサー の作成 今回は、「Application Load Balancer」を選択 設定を入力 作成フローに合わせて設定をいれていきます。 セキュリティなどはそのまま、もし既存のセキュリティグループを使用する場合は、選択してください ※リスナー > HTTPとHTTPS追加しました ルーティングの設定 ターゲットグループ名を設定 ターゲットの種類をインスタンスになってるを確認し、次へ ターゲットの登録で設定したいインスタンスを選択します Route 53でドメイン取得 公式ページ https://aws.amazon.com/jp/getting-started/hands-on/get-a-domain/ ドメインの登録(Route 53) Route 53>登録済みドメイン > ドメインの登録 Route 53に移動し、サイドバーから登録済みドメインを選択、ドメインの登録ボタンから登録作業を行います 使用したいドメインが有効化確認 追加したいドメイン名を検索しカートに入れて購入します ホストゾーン Route53 > ホストゾーン クリック Route53の左メニューからホストゾーンを選びます レコードを作成 レコード名 空 レコードタイプ A エイリアス はい ALBを選択 対象のドメインを選択 ※ELBを設定しない場合は、 エイリアスをいいえ 値 Elastic IP で登録したIPアドレスを Certificate Manager (SSLの設定) Certificate Managerを使用して、SSLを設定します。 ついでにこちらページを参照しました https://qiita.com/nakanishi03/items/3a514026acc7abe25977 https://dev.classmethod.jp/articles/web-ssl-202009/ Certificate Managerにアクセス 証明書のリクエストを選択に指定したいドメインを設定 サブドメインを設定する可能性がある場合以下のように「* (ワイルドカード)」を使用します *.example.net example.net 検証方法を選択します DNSの検証をeメールがあるのですが、私は、メールを選択しました メールが送られてきてるので、承諾して完了です とりあえず、忘れないように手順を、、 お疲れ様でした 参考URL 今回は、大まかな流れはこちらを参考にしました ついでに、ELBについてはこちらを参考にしました
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【AWS】【超初心者ハンズオン】2. AWS API Gatewayによって、URLへのアクセスをトリガーとしてLambdaを実行する

【AWS】【超初心者ハンズオン】 シリーズ シリーズ概要 前の記事: 1. AWS Lambdaによって、自作したコードを実行する この記事の目的 AWS API Gatewayについて、AWS consoleから触ってみる API Gatewayを設定し、URLへのアクセスをトリガーとして、前記事で自作したAWS Lambdaを実行する AWS API Gatewayってどういうサービスなの? API Gatewayは、"HTTP APIやWebsocket APIによって、AWSに展開された他のサービスをトリガーすること"ができるサービスだと理解しています。 超初心者的には、HTTPはわかりますが、Websocketはピンと来ないですね。本投稿ではHTTPメソッド(GETやPOST)をトリガーに、自作したLambdaを走らせてみましょう。 Amazon API Gateway は、あらゆる規模の REST、HTTP、WebSocket API を作成、公開、管理、モニタリング、保護するための AWS のサービスです。 Amazon API Gateway とは何ですか? AWS API Gatewayについて、AWS consoleから触る URLへのアクセス(HttpRequest)をトリガーとして、0~9の間の整数をランダムに1つ返す AWS API Gateway関数を一から作成 AWS console画面にて、'API Gateway'を検索してクリック 'APIの作成' 'Http API'の'構築' '統合を追加'をクリックし、'Lambda'を選択。 リージョンは自分のいつも選択するものを選択 Lambda関数を選ぶ (今回は、'0~9の間の整数をランダムに1つ返す'ものを選びます) API名を命名 ルートを設定 メソッド: GET リソースパス: そのまま(Lambda関数と同じ名前になっている) ステージを設定 ステージ名: $default 作成 作成したAPI Gatewayの管理画面 URLを呼び出す → 実行結果が思ってたんと違う URL呼び出し結果 {"message":"Not Found"} どういうことか: ルートを設定する際、リソースパスなどを設定しましたね. たった今設定したAPI Gatewayは、複数のLambdaのトリガーや、他のサービスのトリガーにすることができます。 したがって、設定したAPI Gatewayから、特定のLambda(ここではrandom_integer_generator_001)を実行するためのURLをリクエストする必要がありそうですね。 Lambda管理画面 作成したAPI Gatewayが、トリガーしたいLambdaに関連付いたことが確認できます API Gatewayを選択、'詳細'を開き'APIエンドポイント'にあるURLを呼び出す URL呼び出し結果 6 URLを呼び出した(HttpGetRequest)結果、0~9の間の整数がランダムに1つ返ってきましたね. この先やること URLに可変情報を付加した場合のHttpGetRequestに応答して、作成したLambdaを実行する
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【AWS】【超初心者ハンズオン】2. AWS API Gatewayによって、HttpGetRequestをトリガーとしてLambdaを実行する

【AWS】【超初心者ハンズオン】 シリーズ シリーズ概要 前の記事: 1. AWS Lambdaによって、自作したコードを実行する この記事の目的 AWS API Gatewayについて、AWS consoleから触ってみる API Gatewayを設定し、HttpGetRequestをトリガーとして、前記事で自作したAWS Lambdaを実行する AWS API Gatewayってどういうサービスなの? API Gatewayは、"HTTP APIやWebsocket APIによって、AWSに展開された他のサービスをトリガーすること"ができるサービスだと理解しています。 超初心者的には、HTTPはわかりますが、Websocketはピンと来ないですね。本投稿ではHTTPメソッド(GETやPOST)をトリガーに、自作したLambdaを走らせてみましょう。 Amazon API Gateway は、あらゆる規模の REST、HTTP、WebSocket API を作成、公開、管理、モニタリング、保護するための AWS のサービスです。 Amazon API Gateway とは何ですか? AWS API Gatewayについて、AWS consoleから触る Http Getメソッドをトリガーとして、0~9の間の整数をランダムに1つ返す AWS API Gateway関数を一から作成 AWS console画面にて、'API Gateway'を検索してクリック 'APIの作成' 'Http API'の'構築' '統合を追加'をクリックし、'Lambda'を選択。 リージョンは自分のいつも選択するものを選択 Lambda関数を選ぶ (今回は、'0~9の間の整数をランダムに1つ返す'ものを選びます) API名を命名 ルートを設定 メソッド: GET リソースパス: そのまま(Lambda関数と同じ名前になっている) ステージを設定 ステージ名: $default 作成 作成したAPI Gatewayの管理画面 URLを呼び出すことで、HttpGetをRequestする → 実行結果が思ってたんと違う URL呼び出し結果 {"message":"Not Found"} どういうことか: ルートを設定する際、リソースパスなどを設定しましたね. たった今設定したAPI Gatewayは、複数のLambdaのトリガーや、他のサービスのトリガーにすることができます。 したがって、設定したAPI Gatewayから、特定のLambda(ここではrandom_integer_generator_001)を実行するためのURLをリクエストする必要がありそうですね。 Lambda管理画面 作成したAPI Gatewayが、トリガーしたいLambdaに関連付いたことが確認できます API Gatewayを選択、'詳細'を開き'APIエンドポイント'にあるURLを呼び出す URL呼び出し結果 6 URLを呼び出した(HttpGetRequest)結果、0~9の間の整数がランダムに1つ返ってきましたね. この先やること HttpPostRequestに応答して、作成したLambdaを実行する
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

TerraformでAWSのEC2インスタンスを作成する

概要 Terraformを用いて、AWSのEC2インスタンスを作成する。 Terraformを用いることで毎回同一構成でのインスタンスが作成可能となる。 Terraformをインストール $ brew install terraform $ terraform -v Terraform v0.14.10 + provider registry.terraform.io/hashicorp/aws v2.70.0 Your version of Terraform is out of date! The latest version is 0.15.0. You can update by downloading from https://www.terraform.io/downloads.html AWSのアカウント作成 アカウントを作成して、作業用ユーザーを作成しておく Terraformの設定 作業用ディレクトリを作成 $ mkdir terraform_for_aws $ cd terraform_for_aws AWSへのアクセス情報を作成 AWSコンソールのIAMのユーザーから使用したいユーザーの概要に 作成した情報をもとにawsへのアクセス情報を記載したファイルを作成する $ vim ~/.aws/`file_name` aws_access_key_id = XXXXXXXXXXXXXX aws_secret_access_key = XXXXXXXXXXXXXXXXXXXXXXXXX $ vim main.tf main.tf resource "aws_instance" "sandbox" { count = 2 # インスタンス数 ami = "ami-785c491f" # Ubuntu 16.04 LTS official ami instance_type = "t2.micro" tags = { Name = "${format("sandbox-%02d", count.index + 1)}" } } $ vim variables.tf variables.tf provider "aws" { version = "~> 2.0" region = "ap-northeast-1" # 東京リージョン shared_credentials_file = "/Users/`user_name`/.aws/`file_name`" # 作成したファイルパス } インスタンスを作成する # 初期化 $ terraform init # 構築する環境の確認 $ terraform plan # 実際に構築する $ terraform apply 実際にEC2インスタンスが作成された インスタンスを削除する $ terraform destory 作成したインスタンスが終了済みとなる 一定期間経過すると一覧からも消える
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【Terraform】【AWS】VPC/サブネットとEC2を同時にapplyする方法

VPC/サブネットとEC2を同時にapplyする方法 こんにちは、Deliaです。 今回はTerraformで詰まった体験談です。 しらべてもサクッと解決できなかったので残します。。。 moduleは自分で作成したものを使用しています。 0.前提 $ t -v Terraform v0.15.0 on darwin_amd64 + provider registry.terraform.io/hashicorp/aws v3.37.0 1.手順 1. サブネットを作成するモジュールにoutputを定義 受け取りたい値を「outoutブロック」で定義します。 ファイルは適宜分けても大丈夫です。 この例では「variableブロック」は分けています。 private_subnetsがユーザ定義ということに注意してください。 /module/VPC/main.tf resource "aws_vpc" "main" { cidr_block = var.main_vpc_cidr instance_tenancy = "default" } resource "aws_subnet" "private_subnets" { vpc_id = aws_vpc.main.id cidr_block = var.private_subnets_cidr } # outputを定義するとモジュール呼び出し元で使える output "subnets_id" { value = "${aws_subnet.private_subnets.id}" } 2. ルート側で使用する アウトプットされた値を、さらにEC2作成用のモジュールに渡します。 /main.tf module "VPC" { source = "./module/VPC" main_vpc_cidr = var.main_vpc_cidr private_subnets_cidr = var.private_subnets_cidr } # private_subnets内にEC2インスタンスを作成したい為、IDを渡す module "EC2" { source = "./module/EC2" subnet_ids = "${module.VPC.subnets_id}" # ここ } 3. モジュール側で使用する 受け取って使用する。 /module/EC2/main.tf resource "aws_instance" "AppServer01" { ami = data.aws_ami.amazon_linux_2.id instance_type = "t2.micro" subnet_id = var.subnet_ids # ここ tags = { Name = "AppServer01" } } /module/EC2/variables.tf variable "subnet_ids" { # default = "" } 以上でできました。 2.最後に 3時間ほど調べまくってもできなくて、「もう明日にしよう、でも最後にコードをみておこう」 とした際に、スペルミスに気づきました。 フロー自体は簡単だと思いますので、参考にしていただければ幸いです。 にしても、順番に書かなくてもよしなにやってくれるの助かりますね(笑)
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Route53 独自ドメイン設定~障害時SORRYページへ (ハンズオン)

目的 ドメインを取得してRoute53で管理し、フェイルオーバーを設定して障害に備える 準備編 AWS EC2インスタンスを2台実行中の状態にする RDSの起動も確認 ロードバランサーのIPアドレスでEC2サイトが問題なく閲覧できる状態 ドメイン取得編 [ Freenom ] というサービスを使用 利用したいドメイン名(ここではaws-demo)を検索 青いタグで無料と書かれたドメインを選択(ここではaws-demo.ga) 今すぐ入手を選択し、緑ボタンのチェックアウトを選択 ドメインを使用する期間を選択(※12ヶ月まで無料) 決済画面(0ドル)を経由してドメインを購入 ヘッダーのServices< My Domeinsを選択 今回作成したドメインの右部分にあるManage Domainのボタンを選択 ドメインの情報を確認できるのでヘッダーのManagement Tools< Nameserversを選択 custom nameserverを選択するとNameserverの入力欄が5つほど表示されます 以上で準備完了 取得したドメインをRoute53で管理 Route53管理画面< ホストゾーン< ホストゾーンの作成 ・ドメイン名にaws-demo.gaを入力 ・説明は空白 ・タイプはパブリックホストゾーン ・ホストゾーンの作成を選択 レコードタイプがNSとSOAの2種類作成されます ・NS → ドメインを管理するサーバー名が書かれているもの ・SOA → ドメインの管理情報が書かれているもの NS(4台全部)をFreenomに書き写していきます。 写し終えたらChange Nameserverを選択 取得したドメインでアクセス Route53< ホストゾーン< aws-demo.gaでレコードの作成を選択 ルーティングポリシーはシンプルルーティングを選択 シンプルなレコードを定義を選択するとレコードの中身を設定できる レコード名(今回はblog) 値/トラフィックのルーティング先をALBとCLBへのエイリアス (補足) ・ALBとドメインを割り当てる際は、ALBとCLBへのエイリアスを選択 ・シンプルにIPアドレスとドメインを紐付ける際は、レコードタイプに応じたIPアドレスまたは別の値 ・S3の静的ウェブサイトにはS3ウェブサイトエンドポイントへのエイリアスを選択  (S3のバケット名はドメインと同じ名前で作成)  ※他にも種類があります ・リージョンは東京 ・検索候補にLBのドメインが表示されるので選択 ・シンプルなレコードを定義を選択し、レコードを作成 これでURLにblog.aws-demo.gaと直接入力しても正常にアクセスできるようになる ※注意 DNSのタイミングによってはblog.から始まるドメインでアクセスできない可能性がある # ローカル環境で実行(EC2ではない) # ドメインのNSを問い合わせることができる dig aws-demo.ga NS +short → 理由は、NSがまだ書き変わっていないからでしばらく時間を置いて、再度上のコマンドを入力して確認 フェイルオーバールーティングの設定 S3< バケットを作成を選択 ・バケット名(blog.aws-demo.ga) バケット名はドメイン名と合わせる必要があるため、ここではblog.aws-demo.gaという名前でなければいけない。→ Route53のレコード設定ができなくなる ・リージョンは東京 ・ブロックパブリックアクセスのバケット設定で、パブリックアクセスを全てブロックにあるチェックを外し、オブジェクトがパブリックになることを承認するボックスにチェックを入れる あとはデフォルトのままでバケットを作成を選択 blog.aws-demo.gaというバケットが作成されたので、選択しここからSORRYページ用のHTMLファイルと画像ファイルをアップロードさせる。 アップロードが完了後 S3< blog.aws-demo.ga< タブメニュー< プロパティ< 静的ウェブサイトホスティングを編集 静的ウェブサイトホスティングを有効にする インデックスドキュメント(index.html)とエラードキュメント(error.html)を入力し変更の保存を選択 続いて、先ほどのタブメニュー< アクセス許可< バケットポリシー< 編集 公式に載せてあるバケットポリシーをコピペして貼り付ける Bucket-Nameの部分をblog.aws-demo.gaに置き換え、変更を保存すると完了 SORRYページをセカンダリとして表示する設定 Route53< ホストゾーン< aws-demo.ga ・作成してあるタイプAのルーティングポリシーを編集ボタンで、シンプルルーティングからフェイルオーバールーティングに変更 ・フェイルオーバーレコードタイプをプライマリ ・レコードIDをLB-Pと入力して作成 次にセカンダリ用のレコードを作成していく ・レコードを作成を選択 ・ルーティングポリシーをフェイルオーバーを選択 ・レコード名はプライマリと同じ(blog) ・TTLとはDNSサービスを何秒間保持する設定(今回は60秒) ・フェイルオーバーレコードを定義 ・値/トラフィックのルーティング先にS3ウェブサイトポイントへのエイリアスを指定 ・リージョンを東京 ・検索候補に先ほど設定したS3のバケット名が表示される   → (ここで出てこない場合、ドメインとバケット名が不一致になっている可能性があるのでS3バケット名を見直す) ・フェイルオーバーレコードタイプをセカンダリに指定 レコードIDをLB-Sと入力しフェイルオーバーレコードを定義し、レコードを作成を選択し設定完了 フェイルオーバールーティングのテスト EC2サーバーを2台とも停止させる(サービスに障害が発生したことを想定) その後、停止完了してすぐは503エラーの画面が返ってきますが、TTLの設定を60秒と設定していたので、60秒後SORRYページに切り替わります。 参考・注意点 この記事はAWS初学者を導く体系的な動画学習サービス 「AWS CloudTech」の課題カリキュラムで作成しました。 https://aws-cloud-tech.com このハンズオンでは料金が約10〜11円/時間かかります。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

インスタンスの停止を自動化してみる

設定してみる 概要 目次 IAM lambda (Cloudwatch Events) (EC2) IAM lambda用のIAMロール作成 ロールの作成 ロールの作成をしていきます ロールの詳細を選択 ポリシーを選択 AmazonEC2ReadOnlyAccess タグの設定 タグの設定は今回はしません ロールの名前 ロールの名前を start_stop_ec2 にし、ほかはそのままでロールを作成しました。 ロールの作成完了 ロールが作成されました。 インラインポリシーの追加 start_stop_ec2 の概要を確認し、インラインポリシーの追加を行います。 ポリシーをJSONにし、以下のポリシーを追加します。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents" ], "Resource": "arn:aws:logs:*:*:*" }, { "Effect": "Allow", "Action": [ "ec2:StartInstances", "ec2:StopInstances" ], "Resource": "*" } ] } ポリシーの作成 概要を確認し、名前を記載します。 ポリシーの追加完了 ポリシーが追加されました lambda lambda関数を作成 コンソール > lambdaへ行き、関数を作成します。 関数の詳細を設定 一から作成 を行い、 関数名 : start_stop_ec2 ランタイム(言語) : Python3.6 で設定を行います。 実行ロールは先ほど作成した start_stop_ec2 ロールを使用します。 関数の完了 関数が作成されました ソースコードの追加 参考にさせていただきました (こちらのサイト)[https://techblog.forgevision.com/entry/2018/06/25/112507] をご確認ください 環境変数の変更 タイムゾーン変更のため、環境変数を変更します タイムゾーン(TZ)を Asia/Tokyo にしました トリガーを設定 設定 > トリガー > トリガーを追加します トリガーの設定をします。 スケジュール式のcronのタイプを記載して、追加します。 トリガーが設定されました タイムゾーンの変更 編集を行う ローカルタイムゾーンを変更して、保存します 動作確認 EC2のタグを設定 インスタンスのタグを以下のように設定しました。 start に 開始時間、 stop に 終了時間を設定します。 確認 実行されました! 参考 AWS LambdaとCloudWatchでEC2インスタンスをスケジュール起動停止する
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWSアソシエイト試験に向けて4(VPC関係)

VPCの前にネットワークでのアドレス周りの知識について IPアドレス ネットワーク機器やWEBサイトの場所を特定するために使われるもの。 住所……というより識別コードみたいな印象が個人的にはある。 TCPやIPというプロトコル(通信に関する規則・手順。語彙としては儀礼という意味になるのでかなり厳格な意味合いを持つ)に則って使われている。 機器に付与されるのではなく、NIC(ネットワークインターフェースカード)という部分に付与される。 2進法かつ8bit×4の32bit値で構成されているものを10進法に直して表示されている。 つまり、180.16.1.10というIPアドレスの実体は10110100.00010000.00000001.00001010ということになる。 (10進数から2進数へ変換→8bitにするために8桁にならないところは前の桁に0で埋める) ちなみにIpv4が一般的だが、振り当てがいっぱいいっぱいになってきているのでIPv6という規格に移行が始まっている。 IPアドレスはグローバル(一意)とプライベート(ユーザーの通信環境内で利用され、決められた範囲で自由に割り振れる)に分かれる。 個人レベルの話で大雑把な言い方をするとルーターにグローバルIPが振られていて、ルーターがそれをルーター内の目的の各プライベートIPへ通信を振り分ける形で普段の通信が行われているイメージ。 ネットワークの範囲とIPアドレスの関係 IPアドレスの利用可能な範囲がネットワークの範囲となる。 1番単純な例であると、ルーターの接続台数である。 例えばルーターが5台まで端末を接続できるといった場合に振り分けられるIPアドレスは5つとなり、すなわちその5つのIPアドレスがそのルーターのプライベートネットワークの範囲ということになる。 さらに細かくするとIPアドレスにはサブネットマスクが定義されることで、そのIPアドレスの範囲が決まることになる。 10.0.1.0/16のIPアドレスを例にして考えてみる。 この場合、サブネットは/16の部分で16bitまでをロックするという意味になる。 したがってこのIPアドレス内では10.0を頭にして、残りの1.0の部分(00000001~.00000000)の16bitの範囲でIPアドレスをさらに作成することでネットワークを分割できることになる。 その際に分割するときはサブネットマスクの値をさらに上げる(/16のままだと同階層のネットワークになるので、例えば/24にして固定する範囲をさらに広くする)。 このとき固定される範囲のことをネットワーク部と呼び、それ以外の利用可能な範囲をホスト部と呼ぶ。 こうしてサブネットを使ってIPアドレスの割当を行い、ネットワークの範囲を定義することをCIDR(Classeless Inter-Domain Routing)と呼ぶ。 プライベートIPアドレスの割り当ては余裕をもたせて行うのがベター。 ちなみにCIDR基準で割り当てられるサブネットあたりのIPアドレスの数はサブネットマスクが2進むごとに約1/4ずつ減っていく。 つまり、1つ下がるごとに約1/2で求められる。 ex. /16 → 16379 /20 → 4091 /22 → 1019 /23 → 521 サブネットについて まず、グローバルとプライベートのネットワークの間にはそれを仲介するNATと呼ばれるものが存在する。 例えば、AWSのVPCならNATゲートウェイがそれにあたる。 例えば端末は個々に割り当てられたプライベートIPアドレスでネットワークに繋がろうとするが、プライベートIPアドレスはグローバルネットワークにおいては一意とはなり得ないのでこのままでは利用できない。 そこでNATがプライベートIPアドレスをグローバルIPアドレスに変換する形で仲介することで、端末はネットワークに接続できるようになる……というのがNATの役割になる。 1対多の関係でグローバルIPアドレスとプライベートIPアドレスを変換する場合はNATではなく、IPマスカレードというものを使うことになる。 ちなみにAWSではデフォルトで1つアカウント作成時にパブリックサブネットが1つあるVPCが用意されている。 VPC ここからが本題でVPC(Virtual Private Cloud)とはAWSにおける仮想ネットワーク空間をユーザー専用に切り出したものを指す。 特徴は以下の5点。 任意のIPアドレスを範囲選択して仮想ネットワークを構築 サブネットの作成、ルートテーブル、ネットワークゲートウェイの設定 クラウド内外のネットワークの接続 インターネット経由での接続かVPN/Direct Connectでの接続かを選択できる。 同一リージョン内では複数のAZに跨がせることができる またVPCにおける設定の上限数は以下の通り。 リージョンあたりのVPCは5まで VPCあたりのサブネットの数は200まで 1リージョン内のElasticIPの数は5個まで ルートテーブルあたりのルート上限数は100 VPCあたりのセキュリティグループの数は500まで セキュリティグループあたりのルールの数は50まで またAWSアカウントを作成するとデフォルトで以下のようなものが作成される。 サブネットマスク/16のIPv4のCIDRブロックのVPC(最大6万強のプライベートIPv4が作れる) 各AZ(アベイラビリティーゾーン)に/20のサブネット(最大4000強のIPアドレス、一部は使えない) インターネットゲートウェイの作成(デフォルトのVPCに接続されている) セキュリティグループ(デフォルトのVPCに適用) ネットワークアクセスコントロール(ACL、これもデフォルトのVPCに適用) DHCPオプションセット(AWSアカウントに紐付く) パブリック、プライベートどちらにもDNSホスト名が付与される VPCはVPCで用途別にウィザードで作成できる、そこで作成したものをカスタマイズするのがベターな作成方法。 つまり整理すると AZにCIDR区分(サブネットマスク)でVPCが作られる VPCのIPアドレスとサブネットマスクによって任意の数サブネットが作られる 必要に応じて作られたサブネットのうちインターネットゲートウェイにルーティングされるようなルートテーブルを持つサブネットを設定する(パブリックサブネット。インターネットゲートウェイへのルーティングがないものはプライベートサブネット) という手順でVPCのネットワークレンジが決まる。 ちなみにCIDRは/16、サブネットは/24で作ることが推奨されているらしい。 プライベートサブネットからインターネットへ接続するためにはパブリックにNATゲートウェイを置き、そこからパブリックのゲートウェイに渡す手法を取る。 ではリソースとの通信はどうするのか? VPCの外側にあるリソースとの通信はパブリックAWSネットワークかエンドポイントを利用する。 VPCを設計するときのポイントは以下の通り。 将来の拡張を考えた余剰性や他のネットワークとの接続性を考慮する CIDRは既存のVPC及び社内ネットワークなどと被らないアドレス帯を設定し、既存の組織構成やシステム構成の将来像を考慮する VPC構成は単体ではなく、VPC全体の関係性も考慮する 組織とシステム境界からVPCをどのように分割するかなど、将来の構成も考慮して設計する 複数AZを利用して可用性の高いシステムを構築する サブネットは大きいサブネットを使い、パブリック/プライベートサブネットへのリソースの配置をインターネットアクセスの可否から検討する セキュリティーグループを使って、リソース間のトラフィックを適切に制御する 実装や運用を補助するツールも有効活用し、VPC Flow Logsを使ってモニタリングできるようにする VPCの分割 VPCを分割するケースとして考えられる例は以下の通り アプリケーション毎にVPCを作る 監査の際に区分しやすいようにスコープとして分割 リスクレベルによって分割する 本番/検証/開発とフェーズごとに分割 部署や共通サービスごとに分割 通信プロトコルとOSI参照モデル ネットワークにおける通信にはプロトコルと呼ばれる規格がある(ex.TCP/IP)。 例えばメールなら送信と受信とでSMTPとPOPとそれぞれプロトコルがある。 このプロトコルが通信においてどの層の規格なのかを表した1つのモデルがOSI参照モデル。 アプリケーション層 WEBアプリケーションなどの通信サービスの通信方式のプロトコルはここ。 メールなら前述の通りSMTP/POP、WEBならHTTP/HTTPSなど。 プレゼンテーション層 文字の送受信、文字コード、暗号についてのプロトコルはここ。 文字コード・圧縮・データ暗号及び復号……と文字の通信に関わる規定を作っている。 セッション層 アプリケーション間での一連の継続的な通信処理の継続やつながり(これらをセッションと呼ぶ)の仕方に関するプロトコルはここ。 セッションの確立・維持・終了までの手順を規定する。 トランスポート層 通信をする際に通信先との通信を許可するか否かチェックが入る。 この処理のことを信頼の確立といい、セッション開始前にそれを行うことやバケットの到着順序やその確認を行うためのプロトコルがここ。 セッション開始のための論理的回線の確立し、セッションを開始するためにポート番号の割り当てを規定する。 ネットワーク層 IPアドレスを利用したルーティング方法のプロトコルはここ。 ノード(通信の起点や終点(エンドポイント))間の通信を規定し、IPアドレスを利用した割り当てやルーターから宛先の端末への最適なパスの選択を行っている データリンク層 MACアドレス(NICの識別番号)を利用したノート間の通信の方法のプロトコルはここ。 1つのネットワーク回線上で直接接続されたノード同士の通信を規定している。 例えばLANは同じネットワークセグメント(ネットワークのグループのようなもの)内におけるノード間の通信をEthernetを使ってMACアドレスを利用し実施している。 物理層 bitによるコンピュータ間の物理的なデータ伝送形式に関わるプロトコルはここ。 0と1のビット列を電気信号に変換することでネットワークへ伝送したりしているらしい。 TCP/IPモデル OSI参照モデルをさらに実務的にまとめたモデル。 以下の4層へと圧縮される。 アプリケーション~セッション層 → アプリケーション層(HTTP、SSH、DNS、SMTP、POP、FTP……etc) トランスポート層(TCP、UDP) ネットワーク層(IP、ICMP、ARP、BGP) 物理層(Ethernet、PPP) さてここで通信の処理フローの1例を見てみる。 アプリケーション層においてHTTPプロトコルを利用して、メッセージが送信される。 トランスポート層において信頼の確立が行われる ネットワーク層において送信先にパケットが送付される 物理層にて相手側に電信の形で一連の処理が伝送される このような処理フローのことをRequestと呼んだりする。 ポート番号 通信の出入口、部屋番号とか郵便ボックスみたいなもの。 OSにおけるデータ通信のためのエンドポイント。 インターネット上の通信プロトコルで、同じコンピュータ内で動作する複数のソフトウェアのどれが通信するかを指定するための番号である。 例えば HTTPポート(80) HTTPSポート(443) SSHポート(22) SMTPポート(25) POPポート(110,143) などがある。 セキュリティグループとネットワークACL AWSにおいてインスタンスへのトラフィックのアクセス可否(つまり、どの通信方式でどのIPアドレスを許可するのかなど)のルールを設定する機能。 いわゆるファイアウォール的な機能になる。 対してネットワークACLはサブネットへのトラフィック制御、つまり仮想ネットワーク自体へのトラフィックを設定する機能になる。 両者の違いとしては サーバー単位(セキュリティグループ)かVPCまたはサブネット単位か(ACL) ステートフル(セキュリティグループ)かステートレスか(ACL) 許可のみの設定(セキュリティグループ)か拒否も設定できるか(ACL) デフォルトの場合、同じセキュリティグループ内通信のみの許可(セキュリティグループ)かすべての通信を許可するか(ACL) すべてのルールを適用する(セキュリティグループ)か番号の順序通りに適用するか(ACL) といったもの。 ステートフルとステートレスはこの場合は前者がインバウンド(通信の入口側)ルールだけ設定すれば自動的にアウトバウンドも許可されるが、後者の場合はインバウンドだけ許可しただけではアウトバウンドは許可されないという違いになる。 コンソールで確認してみる ここまでの一連の流れを実際にVPC等々を作りながら確認してみる。 まずVPCウィザードからパブリックとプライベートのそれぞれのサブネットを持つVPCを作成する。 設定は上記の通り。 パブリックでもプライベートでもAZは必ず指定することに注意。(リージョンによって選択できるAZは当然変わる) また、パブリックサブネットを作るという意味合い(プライベートサブネットにNATゲートウェイ経由でインターネットゲートウェイと接続させる)から考えて、パブリックサブネットを作る場合はプライベートサブネットも同じAZに作るのがベター。 そして、サブネットは作っただけではプライベートのままなのでルートテーブルを設定することでパブリックサブネットへと変化させる。 ルートテーブルの役割はその名の通りルーティングなので、インターネットゲートウェイに対し当該IPアドレスの場所を示すことでインターネットゲートウェイからのパケットの通路を作ってやれる。(上記の設定の場合は10.0.0/24への経路ということになる) VPCを作ると以下のようになる。 インターネットゲートウェイも先程作ったVPCに関連付けられたものが新たに作られているのがわかる。 次はサブネットを新たにもう一つ作る。 V先程作ったVPCを選択して任意の設定を行っていく。 CIDRブロックは先程までの過程ですでに使用しているものと被らないように注意(10.0.1.0まで使っているので10.0.2.0にするなどする)。 AZも先程とは違うAZを指定して作成する。 さて、これで現状を整理すると10.0.0.0/16のVPCの中にAZが2つある状態が出来上がり仮にAZa、AZcとすると AZa → 10.0.0.0/24サブネット(パブリック)、10.0.1.0/24サブネット(プライベート) AZc → 10.0.2.0/24サブネット(プライベート) というVPC構成が出来上がっていることになる。 ただし、10.0.2.0/24サブネットのルートテーブルを確認してみると以下の通りルーティングがNATゲートウェイに通ってしまっていることがわかる。 ここからサブネット自体はプライベートであり、デフォルトだとインターネットゲートウェイにはルーティングが通っていないということが確認できる。 なので、関連付けを編集してインターネットゲートウェイへ通してやる。 ルートテーブルIDを10.0.0.0/24サブネットのものと同じもので指定すると以下の通り切り替わってくれる 一応10.0.0.0/24サブネットのルートテーブルの詳細情報も確認してみる。 これで10.0.0.0/24サブネットと10.0.2.0/24サブネットで同じルーティングができたことが確認できた。 さて今度はプライベートなサブネットを新たに作ってみる。 ここでパブリック・プライベートサブネット及びNATゲートウェイを使った通信フローを整理してみる。 Webからのアクセスがインターネットゲートウェイを通してやってくる パブリックサブネットへパスされる、パブリックサブネットへのアクセスならここでResponseを返す プライベートサブネットへのアクセスであるならパブリックからパスされ、Responseが返す Responseはパブリックサブネット内のNATゲートウェイへパスされる NATゲートウェイからインターネットゲートウェイへパス WebへResponseが到着する つまりNATゲートウェイはプライベートサブネット下にあるインスタンスに対して、更新処理等のRequestが外部のネットワークから行われたという場合に、外部ネットワークから直接プライベート下のインスタンスへアクセスさせないようにパブリックサブネットへ迂回させつつ、トラフィック(Response)を返すためのゲートウェイであることがわかる。 ここまで確認した上で新しくサブネットを作る。 現状は AZa → 10.0.0.0/24サブネット(パブリック)、10.0.1.0/24サブネット(プライベート) AZc → 10.0.2.0/24サブネット(パブリック) という構成なのでこれを AZa → 10.0.0.0/24サブネット(パブリック)、10.0.1.0/24サブネット(プライベート) AZc → 10.0.2.0/24サブネット(プライベート)、10.0.3.0/24サブネット(プライベート) という構成にする。 サブネットの作り方は省略して、サブネットを作成したら以下のようにNATゲートウェイを作成する。 このときサブネットの指定に注意、必ず同じAZ内のパブリックサブネットを指定する。 ElasticIPはVPCを作る際に作ったものでOK。 さて、作ったサブネットのルーティングを確認してみる。 一見問題なさそうに見える。 ところがルートテーブルIDをクリックして以下の画面を見るとステータスがblackhole(存在しないルーティング)になってしまっている。 NATゲートウェイは実は最初ウィザードで作ったときに自動的に1つ出来上がっていて、以降サブネットを作ると自動的にそれが割り当てられてしまうという仕様になっている。 で、問題はNATゲートウェイは課金対象なので無闇に放置をしておくと要らぬコストになってしまうので適宜削除する必要があるが、そうすると今回のようにサブネット作ったはいいもののNATゲートウェイが通ってない……というトラブルにあたってしまうことがある。 なので、その場合はルートの編集でblackholeなルーティングを削除して、先程作ったNATゲートウェイへのルーティングを行ってやればいい。 これで作ったサブネットに同じく新しく作ったNATゲートウェイを設定することができた。 ここまでの注意ポイント ここまでのフローでの気をつけておきたい課金対象は Elastic ID NATゲートウェイ の2点なので必要なければ削除をしておく。 ネットワークACLの設定 ここまでがVPCを作ったときに自動的に作成されたネットワークACLになる。 現状だとすべてのプロトコル及びすべてのトラフィックが許可されている状態なので、これを変更していく。 まずは新しくネットワークACLを作成する。 作成したネットワークACLを確認してみる。 インもアウトも両方ともすべての通信が許可されていないのがわかる。 よってそれぞれルールを作っていく。 ルール番号の順に適用される優先順位が決まるのでそれを意識して作る。 作り方はセキュリティルールと同じだが、下記のようにインとアウトそれぞれ設定することが必要である。 ルールを作ったらあとは適用するだけ。 適用したいサブネットを選択するだけでいい。 すると以下のような状態になり、新しく作ったACLの方へデフォルトのACLからサブネットの関連付けが移行されたのがわかる。 しかし、このままだと実際に使うときにエラーになる場合があるので以下のようにカスタムTCPでポート番号を広く拾うように設定してやる必要があるらしい。 NATゲートウェイを使った通信をEC2インスタンスを用いて確認してみる いよいよ実際のリソースと通信できるかの確認に入る。 まずはインスタンスを2つ作る。 細かいところは省略して注意するところは ネットワークは作成したVPCを選択する 同じくサブネットも作成したパブリックサブネットを選択する 同様に2つ目のインスタンスも作る、ただしサブネットは作成したプライベートサブネットを選択し、自動割当パブリックIPは無効にする(パブリックサブネットじゃないから) セキュリティグループはどちらのインスタンスも同じものを適用する 以下は設定例。 インスタンスを作成したらTerminal等でアクセスを試みる。 無事、インスタンスへアクセスできたらまず、インスタンスをアップグレードする。 以下は実行コマンド、sudo suで管理者権限へ切り替えてから実行している。 実行できたら下記のようにComplete! と表示される。 これでパブリックサブネットへのアクセスが通っていてかつリクエストを行って、レスポンスも返ってきていることがわかった。 次に、プライベートサブネットへアクセスを試みる。 その前にまずキーペアをリソース内へ作る必要があるのでnano ファイル名コマンドで作成する。 コマンドを実行するとエディタが開くので、既存のキーペア(今のインスタンスへアクセスする際に使っているもの)の中身をコピペしてCtrl+Xでエディタを終了しようとすると保存するか聞かれるのでYesと入力してEnterで完了。 あとは作ったキーペアへの権限をchmodコマンドで与えてやる。 今回はchmod 400なので対象のファイルへの読み取り権限を与えている。 ここまでいったらあとはsshコマンドでプライベートサブネットへアクセスする。 先ほどと違ってssh ec2-user@プライベートサブネットのIPv4アドレス -i 先程作ったキーペアでアクセスできる。 下記は-iなしでもコマンドを打っている。 どちらにしろ信頼の確立がてきないという旨のエラーメッセージが出て、このまま進めるかどうか聞かれる。 おそらく、-iなしではYesを選択しても下記のようなエラーになるのだろう。 なので、-iを使ってちゃんとキーペアを指定してやった上でyesを入力するとプライベートサブネットへアクセスができる。 しかしパブリックと同じようにインスタンスの更新を行おうとすると下記のようにエラーになってしまう。 理由は簡単で、都度触れてきたようにプライベートサブネット内へのアクセスやRequestのフローはパブリックを介して行えるが、ResponseのフローはNATゲートウェイがないとできないのでRequestをしてもResponseを返せないので正常にインスタンスの更新が行えずエラーが出てしまうという次第である。 なので、NATゲートウェイを作ってやる必要があるので以下のように作成する。 パブリックサブネットに作らないと意味がないので注意。 あとは作ったNATゲートウェイをサブネットへ適用する。 当該パブリックサブネットは以下のようになっている(さっきNATゲートウェイは削除してあるので)ので、ルートの編集から適用してやればOK。 NATゲートウェイの適用が終わったら再度コマンドを実行する。 問題なければ下記のようにインスタンスの更新が完了するはず。 Direct Connectとは 同一アカウントに所属する別リージョンの同士の接続でも使われるが、実態はAWS環境とオンプレ環境(自社サーバー等自社で物理リソース等用意して構築している環境)とをAWS Direct Connect のパートナーまたはネットワークプロバイダーと契約することで連携し、接続する際の仲立ちをしているのがDirect Connect。 競合するというか比較される仕組みとしてはVPN(Virtual Private Network)というものがある。 VPNは簡単に言うとプライベートネットワークを拡張するもので、大学生なんかだと例えば学外から学内サーバーのコンテンツを利用する(オンライン授業とか履修登録……etc)というときにこれを使わされたという人がいると思う。 VPNとDirect Connectの違いは ベストエフォートなのでコストが安価か(VPN)かキャリアで契約する必要があり割高(DC) クラウド上での接続であるので即時利用可能である(VPN)か物理対応が必要なので利用までに1ヶ月強かかるか(DC) 暗号化のオーバーヘッドにより帯域幅に制限がある(VPN)かポートあたり1/10Gbsと広く使えるか(DC) ネットワークの状態によって品質に影響がある(VPN)か通信キャリアによってある程度品質が保証されているか(DC) インターネットベースなので自社由来以外の障害の特定が難しい(VPN)か物理ベースなので障害の特定が比較的容易か(DC) というものになる。 VPCエンドポイント グローバルIPを持つAWSサービスに対して、VPC内から直接アクエスするための窓口(出口)。 つまり、VPC外にあるAWSリソース等にアクセスするにはこれを設定しないといけない。 このエンドポイントの接続方法は2種類ある。 Gateway型 サブネットに特殊なルーティングを設定することでVPC外のサービスへと直接接続する エンドポイントポリシーを設定してアクセス制御を行う 無料 冗長性はAWS側が対応 これを利用して接続するサービスはS3かDynamoDBのみ PrivateLink型 サブネットにエンドポイント用のプライベートIPアドレスを設定し、DNSに名前解決させてルーティングさせる セキュリティグループを作成してアクセス制御を行う 有料 冗長性はマルチAZ設計 VPC Flow Logs ネットワークトラフィックを取得して、CloudWatchでモニタリングできるようにする機能。 取得できるものは以下の通り。 ネットワークインターフェースを送信元/送信先とするトラフィック セキュリティグループ及びネットワークACLのルールで許可/拒否されたトラフィックログ RDS、Redshift、ElasticCache、WorkSpacesのネットワークインターフェーストラフィック 利用に追加料金はかからず、キャプチャウィンドウと呼ばれる時間枠(10分程度の枠)で収集・プロセッシング・保存を行う。 VPC Peering 異なる2つのVPC間で通信をしたい(連携させたい)場合にこれを使うことでトラフィックルーティングが可能になる。 特徴としては 異なるAWSアカウント間のVPC間を接続できる 一部リージョン(中国等)を除いて異なるリージョンに存在するVPC間の接続もできる 単一障害点・帯域幅のボトルネックは存在しない 接続は1対ずつになる(3つのVPCを接続するにはAB、BC、CAと3つのVPC Peeringを設定しないといけない) 上記の点からあまり多くのVPC間を繋げることは不得手 という点が挙げられる。 似たようなサービスとしてはTransit Gatewayがあるがこちらはより複数のVPC間接続で利用される。 ここまでをハンズオンで確認 まずはエンドポイントで通信するということを確認する。 そのためにはS3へのIAMロールを付与しないといけないのでいつか作ったものをプライベートインスタンスの方へ適用していく。 で、Terminal等でインスタンスへアクセスし、プライベートインスタンスの管理者権限へ入って試しにログ取得のコマンドを打つ。 すると下記のようにフリーズする。 これはNATゲートウェイがないためである。 VPCエンドポイントがない以上外からのアクセスはすべてNATゲートウェイがないとプライベートインスタンスにおいては正常に処理されないことは度々見てきた通り。 なので、VPCエンドポイントを作る。 ポイントは以下の点。 どこに対するエンドポイントなのか サービスであるならどのサービスに対するエンドポイントなのか Gateway型(S3かDynamoDB)かInterface型なのか どのVPCのどのサブネットに作成するのか Gateway型の場合はポリシーはどうするのか(Interface型はセキュリティグループでアクセス制御) 以下は設定例。 エンドポイントを作成したら再度コマンドを実行する。 このとき、--region リージョン名とコマンドの後ろに付け加えて実行リージョンを指定しないといけない。 問題なければ以下のようにフリーズしない(S3の証跡を作ってあればログがでる) 次にVPC Peeringを見る。 これは簡単で接続したいVPCを選択して、それぞれのVPCで承諾を行えばいい。 別アカウントのVPCと接続するなどの場合は、そちらのVPCでの承諾が行われない限り接続が完了しないので注意。 以下は例。 次にTransit Gateway。 Transit Gatewayは1対以上の複数のVPCを接続したい時に使える。 ただし、課金対象なので必要ない場合は削除をしないといけない(以下で作成したものすべて) まずGatewayを作る。 次に作ったGatewayに関連付けたいVPCごとにAttachmentを設定する。 以下は例。 アタッチするとこうなるので暫く待つ。 無事完了すると以下のようにステータスが変わる。 Transit Gatewayにもルートテーブルが存在する。 特に作らなくてもTransit Gatewayを作成して、VPCをアタッチすると自動的に1つはデフォルトとして作成される。 その他メモ Egress Only インターネットゲートウェイ(IPv6専用のインターネットゲートウェイ) キャリアゲートウェイ(Wavelengthゾーンと呼ばれる5Gをつかったサービスで用いるAZのようなものとの連携するためのゲートウェイ) DHCPオプションセット(TCP/IPネットワークのホストに設定情報を渡すもの) Elastic IPアドレス(インスタンスに付与されるIPアドレスは動的なものであり、再起動等で変動してしまう。そこで、代わりにこれを付与することで固定的なIPアドレスを実現する。実行中インスタンスに紐つけてないと課金対象になるので不要であるなら削除する) マネージドプレフィックスリスト(IPアドレスの範囲をリストとして設定できる) エンドポイント(リージョンの外のサービスとの窓口) エンドポイントのサービス(エンドポイントを使って、他のAWSアカウントから当該AWSアカウントへ接続する場合の窓口) Reachability Analyzer(サービス間の通信が可能かどうか分析してくれる) Transit Gateway(複数VPCを使用している際に、それを関連付けて管理するための機能) ミラーリング(VPC間の異常な接続などトラブルシューティングの際に異常の特定をするために使える機能)
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AppSync の filter で指定できる検索条件一覧 [WIP]

日本語でまとまっているところが見つからなかったので埋めていきたい AppSync 使い始めたばかりで抜けとか間違いがあるかもなのでWIP field に対して ref: - https://docs.amplify.aws/lib/graphqlapi/query-data/q/platform/js#using-aws-appsync-sdk - https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Condition.html operator description eq 指定した値に一致する ne 指定した値に一致しない gt 指定した値より大きい ge 指定した値より大きい、もしくは同じ(以上) lt 指定した値より小さい le 指定した値より小さい、もしくは同じ(以下) between 指定した1つ目の値よりも大きく、2つめの値よりも小さい contains 指定した値が含まれる notContains 指定した値が含まれない beginsWith 指定した値で先頭一致 複合条件 https://docs.amplify.aws/lib/graphqlapi/query-data/q/platform/js#filtered-and-paginated-queries operator description and すべての条件を満たす or いずれかの条件を満たす not 指定した条件を満たさない
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

[AWS]ACM(AWS Certificate Manager)でSSL証明書を取得

はじめに AWSのEC2,route53,CertificateManager を使ってhttpをSSL化したので備忘録として残しておきます。 自分の手順書としてのメモですので画像はありません。あしからず。 今回はACMでSSL証明書を取得します。 ロードバランサー(ELB)を作成しているとACMが使用できます。 ACMではSSL証明書を無料で利用することができます。 ロードバランサーの設定は以下をご覧ください この記事ではドメインを使うので作っていない方はドメインを取得してください。 著者は以下のサイトで取得しました。 Route53も使いますので作成していない方は作成してください またSSLって何?って方は以下をご覧ください 1. 手始めに AWSの画面左上のサービスを開き、検索欄に「ACM」と入力してください。 表示される「Certificate Manager」を選択します。 画面左側の「証明書のプロビジョニング」の「今すぐ始める」ボタンを選択します。 2. 証明書のリクエスト 「パブリック証明書のリクエスト」を選択 画面右の「証明書のリクエスト」ボタンを選択する。 3. ステップ 1: ドメイン名の追加 ドメイン名の追加欄に「取得したドメイン名」を入力 例 hogehoge.jp その下の「この証明書に別の名前を追加」ボタンを選択 ドメイン名の追加欄に「*.取得したドメイン名」を入力 例 *.hogehoge.jp 「次へ」ボタンを選択 4. ステップ 2: 検証方法の選択 「DNS の検証」を選択 「確認」ボタンを選択 5. ステップ 3: タグを追加 追加してもしなくてもどちらでもOKです。 追加しておくと証明書の管理がしやすくなります。 6. ステップ 4: 確認とリクエスト 入力した項目を確認して良ければOKを押します。 7. ステップ 5: 検証 2つのドメインの検証状態はそれぞれ「検証保留中」となっています。 Route53を使用しておりますので、用意されているボタンを使用していきます。 「Route53でのレコードの作成」ボタンをそれぞれのドメインで選択して「作成」ボタンを選択します。 「成功」と表示されればOKです。 「続行」ボタンを選択してください。 8.発行の確認 Certificate Managerの画面に戻ります。 取得したドメイン名レコードの「状況」が「発行済み」になれば、無事にSSL証明書の発行が完了です。 ※発行済みになるまで時間がかかる時は数秒毎にリロードを押して様子をみましょう
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

[AWS]ロードバランサーの作成

はじめに AWSのEC2,route53,CertificateManager を使ってhttpをSSL化したので備忘録として残しておきます。 自分の手順書としてのメモですので画像はありません。あしからず。 今回はロードバランサーを作成します。 1. 手始めに EC2の画面左の「ロードバランサ」を選択し、ページ左上の「ロードバランサーの作成」を選択します。 2.「Application Load Balancer(HTTPとHTTPSを提供する)」の「作成を選択」 2. 手順 1: ロードバランサーの設定  以下の通りに記述 基本的な設定 名前:「アプリ名-ELB」 スキーム:「インターネット向け」にチェック IP アドレスタイプ:「ipv4」 リスナー デフォルトの状態 アベイラビリティーゾーン VPC:「VPC_for_アプリ名」 アベイラビリティーゾーン: 「ap-northeast-1a」,「ap-northeast-1c」 アドオンサービス 選択なし タグ 記入なしでもOK、記入しておくと後で管理しやすくなる 「次の手順:セキュリティ設定の構成」を選択し手順2に移動 3. 手順 2: セキュリティ設定の構成 設定はデフォルトのまま 「セキュリティグループの設定」を選択 4. 手順 3: セキュリティグループの設定 以下の通りに記述 セキュリティグループの割り当て:「既存のセキュリティグループを選択する」にチェック 「アプリ名-SecurityGroup」のレコードにチェック 「次の手順:ルーティングの設定」ボタンを選択する。 5. 手順 4: ルーティングの設定 以下の通りに記述 ターゲットグループ 1. ターゲットグループ:「新しいターゲットグループ」 2. 名前:「アプリ名-Target-Group」  3. ターゲットの種類:「インスタンス」にチェック 4. プロトコル:「HTTP1」 5. ポート:「80」 ヘルスチェック 1. プロトコル:「HTTP」 2. パス:「/」 ヘルスチェックの詳細設定 1. ポート:「トラフィックポート」 2. 正常のしきい値:「5」 3. 非正常のしきい値:「2」 4. タイムアウト:「5」 5. 間隔:「10」 6. 成功コード:「200」 「次の手順:ターゲットの登録」を選択 6. 手順 5: ターゲットの登録 下部の「インスタンス」欄から、 「アプリ名-instance」にチェック 「登録済みに追加」ボタンを選択する 「アプリ名-instance」が上部の「登録済みターゲット」欄に 移動した事を確認 「次の手順:確認」ボタンを選択する。 「作成」ボタンを選択する。 ロードバランサーの画面に戻り、一定時間経過後、状態が「active」なら完了。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

[AWS]ロードバランサー(ELB)の作成

はじめに AWSのEC2でRailsアプリをデプロイしたのでメモとして残しておきます。 今回はhttpで設定します。 自分の手順書としてのメモですので画像はありません。あしからず。 今回はロードバランサーを作成します。 ロードバランサーって何って方は以下をご覧ください 1. 手始めに EC2の画面左の「ロードバランサ」を選択し、ページ左上の「ロードバランサーの作成」を選択します。 「Application Load Balancer(HTTPとHTTPSを提供する)」の「作成を選択」 2. 手順 1: ロードバランサーの設定  以下の通りに記述 基本的な設定 名前:「アプリ名-ELB」 スキーム:「インターネット向け」にチェック IP アドレスタイプ:「ipv4」 リスナー デフォルトの状態 アベイラビリティーゾーン VPC:「VPC_for_アプリ名」 アベイラビリティーゾーン: 「ap-northeast-1a」,「ap-northeast-1c」 アドオンサービス 選択なし タグ 記入なしでもOK、記入しておくと後で管理しやすくなる 「次の手順:セキュリティ設定の構成」を選択し手順2に移動 3. 手順 2: セキュリティ設定の構成 設定はデフォルトのまま 「セキュリティグループの設定」を選択 4. 手順 3: セキュリティグループの設定 以下の通りに記述 セキュリティグループの割り当て:「既存のセキュリティグループを選択する」にチェック 「アプリ名-SecurityGroup」のレコードにチェック 「次の手順:ルーティングの設定」ボタンを選択する。 5. 手順 4: ルーティングの設定 以下の通りに記述 ターゲットグループ 1. ターゲットグループ:「新しいターゲットグループ」 2. 名前:「アプリ名-Target-Group」  3. ターゲットの種類:「インスタンス」にチェック 4. プロトコル:「HTTP1」 5. ポート:「80」 ヘルスチェック 1. プロトコル:「HTTP」 2. パス:「/」 ヘルスチェックの詳細設定 1. ポート:「トラフィックポート」 2. 正常のしきい値:「5」 3. 非正常のしきい値:「2」 4. タイムアウト:「5」 5. 間隔:「10」 6. 成功コード:「200」 「次の手順:ターゲットの登録」を選択 6. 手順 5: ターゲットの登録 下部の「インスタンス」欄から、 「アプリ名-instance」にチェック 「登録済みに追加」ボタンを選択する 「アプリ名-instance」が上部の「登録済みターゲット」欄に 移動した事を確認 「次の手順:確認」ボタンを選択する。 「作成」ボタンを選択する。 ロードバランサーの画面に戻り、一定時間経過後、状態が「active」なら完了。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

AWSでWordPressブログをはじめてみた

はじめに awsを勉強として軽く触っていたのですが、1年間無料ということだったのでwordpressによるブログを開設してみました。その時に行ったことを軽くメモしました。 独自ドメインの取得 ~ wordpressの開設 基本的に以下の記事を参考に行いました。 https://katsuhiroblog.com/aws-wordpress https://qiita.com/nakanishi03/items/25278fb4dfad60ebfac4 https://100webdesign.jp/services/web_knowhow/aws-site/web_knowhow-21161 参考記事の通り、行えば基本的に誰でもwordpressのブログを開設できます。 大まかな手順は以下の通りです。 1. 独自ドメインの取得  今回は「お名前.com」を利用。 2. EC2インスタンスの起動  AMIは、「AWS Marketplace」の「WordPress Certified by Bitnami and Automattic」を利用。  また、インスタンスタイプは、1年間の無料利用枠対象の「t2.micro」を利用。 3. wordpressへログイン(確認)  サーバが作成されたので、wordpressのadminでログインできるか確認。 4. Elastic IP の割り当て  Route 53で独自ドメインとインスタンスを結びつけるために、Elastic IPアドレスを取得しておく必要があります。 Elastic IPアドレスとは、特定のリージョンのAWSアカウントに関連づけられた静的 IPv4アドレスです。自動割り当てされたパブリック IP アドレスとは異なり、Elastic IP アドレスは Virtual Private Cloud (VPC) でインスタンスを停止および開始した後も保持されます。 EC2インスタンス起動後に得られる、パブリックIPv4アドレスを独自ドメインを結びつけることも可能です。 しかし、パブリックIPv4アドレスは、インスタンスを停止して再起動するたびに、値が変わってしまい、その都度、ドメインと結びつけるIPv4アドレスを変更する必要があるので、値が変わらないElastic IPを用いる必要があります。 なお、Elastic IPは「EC2 ダッシュボード」から割り当てることができます。 5. Route 53 で独自ドメインとインスタンスの紐付け お名前.comで取得した独自ドメインとインスタンスを紐付けすることで、サイトにアクセスできるようになります。 このとき、「レコードを作成」でインスタンスのElastic IPを入力するのを忘れないように!!(自分が忘れていたのでw) 6. 独自ドメインでwordpressにアクセス 最後に、取得した独自ドメインでブログにアクセスできるか確認してみます。何か間違った操作を行っていなければアクセスできるはずです。 まとめ 今回は、独自ドメイン取得からwordpressでブログ開設までを行いました。次は、セキュリティを強化するためにSSL化(httpからhttpsに)していきたいと思います。 参考 https://katsuhiroblog.com/aws-wordpress https://qiita.com/nakanishi03/items/25278fb4dfad60ebfac4 https://100webdesign.jp/services/web_knowhow/aws-site/web_knowhow-21161 https://aws.amazon.com/jp/premiumsupport/knowledge-center/ec2-associate-static-public-ip
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む