- 投稿日：2021-01-12T23:34:09+09:00
AWS VPCについて（２）
こんにちは、キムです。
以前VPCについてていう記事を書きました。 おそらくかぶる内容も色々あると思いますが、自分の記事を自分でもう少しアップグレードする気持ちで（２）ていう記事名をつけました。
この記事では、VPCを設計する前に少しわかっておいたらいい知識、そして実際VPCをどのように構築していくのかについて話そうと思います。
物足りない内容かな…と思いますが、ぜひご参考になれば嬉しいです。
間違ってる内容や・追記したほうがいい部分があれば、コメントお願いします。基本知識
IPアドレスの構造について
IP アドレスは32 桁の2 進数であり、総個数は約42 億個程度である。 構成は（ネットワークアドレス+ホストアドレス）から構成される。簡単に説明すると、ネットワークアドレスはマンションのアドレス、ホストアドレスは部屋番号で理解すれば分かりやすい。 相手の家に正確な住所を探すためには、まずマンションの住所に行って部屋番号を探さなければならない。
IPアドレスを8ビットで4等分するとこれらをそれぞれオクテットという。 各オクテットは0~255までの範囲であるため、合計256個が入ることが分かる。 そして各オクテットごとにIPのクラスをA、B、Cに分けることができる。
Aクラスはオクテット1 がネットワークID ID である。 そして残りのオクテットをホストのIDとして使う。 Bクラスはオクテット2までをネットワークIDとして使用する。 そしてCクラスはオクテット3まで使う。
結果的にAクラスはネットワークID1つ当たり1677万個のIPアドレスを、Bクラスは6万5千個、Cクラスは256個持つ。 Cを使うには個数が少なすぎるし、Bを使うには失敗する場合があるため、このクラス別にアイピーを割り当てる方法は以前になくなった。
その後、この問題を解決するためにサブネットマスクを使用したが、「マスク」という単語のようにアイピーアドレスを隠す役割をする。 AクラスはこのCIDRブロックにおいて8に該当する。 B クラスは16 C クラスは24 に該当する。
より詳しい内容はこちらを参考にCIDR(Classless Inter-Domain Routing)て？
CIDR は急激に不足するIPv4アドレスをより有効に使用するために登場したものである。 表現方式は
xxx.xxx.xxx.xxx/yyの形で表示し、一番後ろのyyはサブネットマスクを2進数に変えたときに1の個数になる。 上で述べたように基本的にCクラスは24個の1でIPを隠してしまう。 遮った後のケタから使えるようになる。例えば、
255.255.255.255.0を2進数に置き換えると、111111.111.111.111.00000000となるが、1が24個なのでCIDR 表記法でxxx.xxx.xxx.xxx/24となる。（ちなみに、サブネットマスクは1 が連続して出るべきである）192.16.8.0.0/24なら192.168.0.1~192.168.0.254までである。初めの192.168.0.0がネットワークであり、最後の192.168.0.255はブロードキャストから除外される。
より詳しい内容はこちらを参考に本題
VPCよりはVPN（Virtual Private Network）
VPNは日本語で仮想私設網という。前の「仮想」という言葉からも分かるように、実際の私設網ではなく仮想の私設網である。上図のように会社のネットワークが構成されており、セキュリティ上の理由で従業員間のネットワークを分離したいのであれば、既存のインターネット線工事もやり直さなければならず、建物の内部線をすべて取り払って直すべきであり、また専用線を敷き直さなければならない。 そのために仮想網VPN を使用することになる。
VPN はネットワークA とネットワークB が実際に同じネットワーク上にあるが論理的に異なるネットワークであるかのように動作する。 これを我々は仮想私設網と言う。VPC（Virtual Private Cloud）
VPCがなければ、EC2インスタンスが互いにクモの巣のようにつながり、インターネットとつながる。 このような仕組みは、システムの複雑度を大幅に引き上げるだけでなく、1つのインスタンスを追加するだけですべてのインスタンスを修正しなければならない不便さがある。 まるでインターネット専用線を新しく敷くようなものだ。
VPC を使用すると、上図のようにVPC ごとにネットワークを構成でき、それぞれのVPC に応じて異なるネットワーク設定を与えることができる。 また、それぞれのVPCは完全に独立したネットワークのように動作することになる。VPCの構築流れ
VPC を構築するためには、VPC のIP 範囲をRFC1918という私設のIP帯域に合わせて構築しなければならない。 私設IPとは何だろうか？インターネットのために使用するのではなく、私たち同士で使用するIP帯域アドレスである。例えば、誰かが「居間からリモコン取ってくれ」と言うと、私は隣の居間に行くのではなく、私の家の居間にリモコンを取りに行く。 居間の位置がプライベートIPであり、私の家の住所がパブリックIPである。隣にもリビングがあるし、私の家にもリビングがあるけど、お互いのリビングに入った時、見分けがつかない。 「居間」、「小部屋」、「大部屋」のように内部で使うアドレスを私設のIP帯域と呼び、内部ネットワークで場所を探す際に使用する。 むろん、友人や弟の友人が訪ねてくる時は住所（パブリックIP）を知らせればよく、同じ家（我が家）に住む（同一ネットワーク上に存在する）私が弟のところに行く時は、弟の部屋（私設アイピー）に行く。
VPC で使用する私設のIP 帯域は以下の通りである。
- 10.0.0.0 ~ 10.255.255.255(10/8 prefix)
- 172.16.0.0 ~ 172.31.255.255 (182.16/12 prefix )
- 192.168.0.0 ~ 192.168.255.255 (192.168/16 prefix )
一度設定されたIP帯域は修正できず、各VPCは一つのリージョンに従属される。 それぞれのVPCは完全に独立しているため、もしVPC間の通信を望むならVPCピアリングサービスが考えられる。
このように私設の帯域を約束すれば、私設のIPでインターネットに接続できるIP帯域として設定し、問題発生を防止できるからだ。 例えば140.x.x.x のIP を社説にするとすれば、あのIP はインターネットで使えるIP である。 私設網内部でインターネットをつながずに低IPを使用することができるが、共通の規約に従うことで、「勘違い」と「問題」を事前に防ぐことができる。
Availability Zone
AWSは世界各地でホスティングされている。 各地域をリージョンと呼ぶ。 このリージョンの中で可用領域という隔離された位置がいくつかある。 そのため、各リージョンでも一方の可用領域に問題が生じた時、他方の助けを受けることができる構造である。 ELB（ロードバランサ）を付けて各可用領域にトラフィックを分散させることができる。
Subnet
VPCを作ったなら、サブネットを作ることができる。サブネットはVPCを細かく分割する過程だ。 サブネットは、VPC の中にあるため、VPCより小さい単位であるし、当然サブネットマスクがより高い値を持し、IP の範囲がより小さい値を持つことになる。 サブネットを分ける理由は、より多くのネットワーク網を構築するためだ。
個々のサブネットは可用領域の中に存在し、サブネットの中にRDS、EC2 といったリソースを位置づけることができる。
Routing Table, Router
ネットワーク要請が発生すると、データはまずルータに向かうことになる。 ルータとは目的地であり、ルーティングテーブルは各目的地のマイルストーンである。 データはルータに向かうことになり、ネットワークリクエストはそれぞれ定義されたルーティングテーブルに従って動作する。 サブネットA のルーティングテーブルは、172.31.0.016 すなわち、VPC の中のネットワーク範囲を持つネットワーク要請はローカルで求めることになっている。 しかし、それ以外に外部に通じるトラフィックを処理することができない。 その際、インターネットゲートウェイを使用する。
Internet Gateway (IGA)
インターネットゲートウェイとは、
VPCとインターネットをつなぐ一つの関門である。 サブネットB のルーティングテーブルを見ると、0.0.0.0/0と定義されている。 この意味は、すべてのトラフィックに対してIGA（インターネットゲートウェイ）A に向かうようにという意味である。 ルーティングテーブルは、最初に目的地のアドレスが172.31.0.0/16にマッチングされるかを確認した後、マッチングされなければIGA Aに送られる。インターネットとつながっているサブネットをパブリックサブネット、インターネットとつながっていないサブネットをプライベートサブネットという。
NetWork ACL, Security Group
ネットワークACL とセキュリティグループはファイアウォールのような役割を担当する。
インバウンドトラフィックとアウトバウンドトラフィックのセキュリティポリシーを設定できる。
まず、セキュリティグループはStateful な方式で動作し、基本的に全ての許容を遮断するように設定されているため、必要な設定は追加で許容する必要性がある。 また、ネットワークACLと異なり、個々のセキュリティグループごとに別々のトラフィックを設定でき、サブネットでも設定できるが、それぞれのEC2インスタンスにも適用できる。ネットワークACLはStateless に動作し、すべてのトラフィックを許容するように設定されているため、追加的に不要なトラフィックを防ぐように設定しなければならない。 ネットワークACL とセキュリティグループが衝突する場合は、セキュリティグループの方が高い優先順位を持っている。
NAT Gateway
NAT ゲートウェイはプライベートサブネットがインターネットと通信するためのアウトバウンドインスタンスである。 プライベートネットワークが外部から要請されるインバウンドの設定が必要でなくても、インスタンスのファームウェアや周期的なアップデートが必要であり、アウトバウンドトラフィックだけが許容されなければならない場合がある。 このとき、パブリック サブネット上で動作する NAT ゲートウェイは、プライベート サブネットから外部に要請するアウトバウンド トラフィックを受けてインターネット ゲートウェイと接続することになる。DHCP (Dynamic Host Configuration Protocol )
翻訳すると動的ホスト設定プロトコルである。 IPを必要とするコンピューターに自動的にIPを割り当て、使用しなければ返却して他のコンピューターにIPを使うようにしてくれる。
DHCP がIP を割り当ててくれることをリースといい、基本的に8 日と設定されてるという。 ところが人々が多く居住している地域では8日に設定すればすぐに売り切れてしまうため、2~3時間程度で設定されるという。 そして、使い続けているのに返却してしまうと非効率的になるので、更新（Renewal）をサポートする。 使用期間が50%残った時、そして87.5%残った時に2度試みるという。 言い換えれば、IPを引き続き使用中なら賃貸期間を自動的に更新し、そうでなければ時間に合わせて返すということだ。
AWS では最大 4 つの独自の DNS サーバが使用できる。 そうするためには、VPCと一緒に使用するDHCPオプションを指定しなければならない。
domain-name-servers, domain-name, ntp-servers, netbios-name-servers, netbios-note-typeを指定できるというが、一般的にデフォルト値をそのまま使う。 もっと詳しい設定が必要なら、公式文書を参考にした方が良い。
公式Wikiはこちらまとめ
これまで、IP,VPN,VPCなどAWSで一番基本になるネットワークについて書いて見ました。
VPCの目的は色々あると思いますが一般的にはセキュリティーのためにAWSリソース間のつながりを最小限にして、グループ頃に簡単にネットワークを構築するためよくつかいます。 これ以外にもより独立的なVPC間の通信のために作られたVPCピアリング、オンプレとVPCとのネットワークである、AWS Direct Connect、VPCで発生するゴグを管理するVPC Flow logsていうサービスもあります。
次回はWAFについて勉強しようと思ってます。
長い文書読んでいただきありがとうございます。
ご参考になれば嬉しいです。
- 投稿日：2021-01-12T23:12:17+09:00
AWS Lightsail 入門1 インスタンス作成
本記事の内容
- Lightsailの概要と利用時の注意点を理解する。
- LightsailにLinux（CentOS）のインスタンスを作成し、ブラウザ上のターミナルで接続する。
前提条件
- AWSアカウントを作成済み。
Amazon Lightsailの概要
Lightsail（ライトセイル）はAWSのVPS（Virtual Private Server: 仮想プライベートサーバー）サービス。
AWS上にLinuxやWindowsサーバーを簡単に構築し、シンプルかつ低価格なコストで運用できる。Lightsailのメリット
- 簡単
インスタンス（サーバー）の作成や削除が簡単に行える。- シンプルかつ低価格
月額の定額制のため、コストが分かりやすい。
プランにより異なるが、最安で3.5ドル（約364円・2021/01/11時点）。Lightsailのデメリット
- 利用時間に関わらず固定料金。
インスタンスを停止していても月額料金がかかる。
利用時間が限られている用途では、EC2（AWSの仮想サーバーを構築できるサービス）の方が安くなる場合もある。- 設定が簡単な反面、自由度は低い。
Lightsailの注意点
Lightsailは基本的に定額制だが、別途課金が発生するケースもある。
利用時に注意が必要なケースを紹介する。未使用の静的IP
LightsailインスタンスのパブリックIP（グローバルIP）は通常、インスタンス停止時に開放され、次回起動時にはアドレスが変わる。
静的IP（アカウントに5つ提供）を使用することでパブリックIPを固定できるが、インスタンスに1時間以上アタッチされていない未使用の静的IPは、0.005ドル/時間課金される。
インスタンス削除時は静的IPが未使用状態で残るため、課金を防ぐためには静的IPも削除する必要がある。スナップショットの保存
ある時点でのインスタンスやディスクをバックアップする機能。
保存容量に応じて月額0.05ドル/GBの課金が発生する。データ転送の無料枠を超えた場合の、外部への送信
Lightsailには無料のデータ転送枠（最安のプランで1TB/月）が含まれている。
無料枠を超えた場合でも受信は無料で、Lightsailインスタンスから外部（インターネットや別のAWSリージョンなど）に対して、パブリックIPを使用して送信した場合に課金対象となる。
価格はリージョンによって異なり、例えば東京は0.14ドル/GBで、バージニア北部の0.09ドル/GBよりも高めに設定されている。詳細は下記を参照。
「Amazon Lightsail に関するよくある質問」 > 請求とアカウント管理Lightsailインスタンスの作成手順
1. Lightsail管理画面の表示
AWS マネジメントコンソールにサインインし、[サービス] > [コンピューティング]内の[Lightsail]を選択。
2. インスタンスの作成
[インスタンスの作成] を選択。
インスタンスロケーションの選択
今回は「東京、ゾーン A (ap-northeast-1a)」に作成する。
地理的に近いリージョンを選択することで、通信の遅延を最小限にする。
変更する場合は[AWS リージョンとアベイラビリティーゾーンの変更]より選択。
Lightsailの基本料金はどのリージョンを選択しても変わらないが、データ転送の無料枠を超過した場合の料金は異なることに留意する。
インスタンスイメージの選択
OSを選択する。アプリケーションがインストール済みのイメージも選択できるが、OSはLinuxの場合Ubuntu Serverとなる。
今回は[Linux/Unix] > [OS のみ] > [CentOS]を選択する。
インスタンスプランの選択
サーバーのスペックを選択する。高性能なほど価格も高くなる。
今回は最初の1か月無料の[\$3.5]を選択。
※[\$3.5]はメモリが512MBと少ない。[\$5]はCPU以外の性能が倍になる（メモリ1GB）ので、コストパフォーマンスが高い。
インスタンスを確認
Lightsail リソース名として、今回は「Test-CentOS-1」を入力し、[インスタンスの作成]を選択。
作成後の変更はできないので、用途が決まっている場合は分かりやすい名前を付ける。※確認画面は表示されずにインスタンスが作成されるので、事前に入力内容を確認しておく。
インスタンスが作成され、少し待つと「実行中」の状態になる。
3. インスタンスへの接続
インスタンス名の右側にあるターミナルのアイコンを選択。
ブラウザ上でターミナルが起動し、サーバーに接続される。
PCにSSHクライアントを用意しなくても操作が行える。
リソースの確認
インスタンス作成直後の何もインストールしていない状態で、リソースの使用状況を確認した。
※3.5ドルのプランはメモリが512MBと少なく、気になっていたので。メモリ使用状況
$ free -h total used free shared buff/cache available Mem: 485M 63M 301M 8.5M 120M 377M Swap: 0B 0B 0Bディスク使用状況
$ df -h Filesystem Size Used Avail Use% Mounted on /dev/xvda1 20G 886M 20G 5% / devtmpfs 221M 0 221M 0% /dev tmpfs 243M 0 243M 0% /dev/shm tmpfs 243M 8.6M 235M 4% /run tmpfs 243M 0 243M 0% /sys/fs/cgroup tmpfs 49M 0 49M 0% /run/user/1000まとめ
Lightsailのインスタンスは、少ない手順で簡単に作成できる。
しかし、リージョンやOSの選択など、AWSやLinuxの知識も必要になる。
また、基本料金以外の課金が発生するケースもあるため、注意しつつLightsailを活用していきたい。
- 投稿日：2021-01-12T23:08:22+09:00
AWSの請求額に納得できないときに見直すべき4つの項目
AWSの請求ダッシュボードを見て「えっ…私の請求額、高すぎ…？」となったものの、何のせいで請求されているかイマイチピンとこずに、納得いかないときってありませんか？
そんなときに見直すべき項目（実体験）をまとめました。
EC2を複数個同時起動していないか
EC2の無料利用枠は750時間/月です。
1つのEC2を仮に1ヶ月間ぶっ通しで起動し続けたとしても、24時間✕30日＝720時間でギリ無料で使えます。
が、2個以上のEC2で同じことをすると720時間✕2＝1440時間でアウトです。1ヶ月起動し続けることはないにしても、EC2を複数個起動することはよくあると思います。
ハンズオン等でWEBサーバの冗長構成を作ったり、DBホスト用にプライベートサブネットにEC2を立てたり、Cloud9を使ったり、、、などなど。複数個起動した状態で停止忘れなどした日には、あっという間に無料枠を食いつぶしてしまいますので、ご注意ください。
NATゲートウェイを削除し忘れてないか
VPC 内に NAT ゲートウェイを作成することを選択した場合は、NAT ゲートウェイがプロビジョニングされ利用可能であった "NAT ゲートウェイ時間" に対して料金が請求されます。
https://aws.amazon.com/jp/vpc/pricing/NATゲートウェイは存在するだけで課金されます。Lambdaのような使用した分だけ課金とかじゃないです。
ハンズオン等でNATゲートウェイを作った場合は、終わった瞬間速攻削除しましょう。EC2削除時にEBSも併せて削除しているか
EC2を削除したとき、EBSも忘れずに削除していますか？
EBSの保存容量にも無料枠があり、1GBを超えると課金が始まります。（EBS消し忘れでウン万円請求されたみたいな記事をQiitaで前見たんだけどURL忘れた。。。）
別リージョンに消し忘れリソースはないか
不要なリソースは全部消したからヨシ！と思ったら、別リージョンに消し忘れリソースが残っていたなんてことはありませんか？
東京リージョンしか使ってないとかなら問題ないですが、複数リージョンを使い分けている方はご注意ください。参考
- 投稿日：2021-01-12T21:38:50+09:00
MFA 利用を強制した場合に管理者側で対応が必要になる事
はじめに
下の記事をユーザにお願いした際、しばしば発生する対応です。増えたら追記。
[AWS] MFA 利用を強制した場合、ユーザ側が必要になる作業「エンティティは既に存在しています。」
↑のエラーが出るとユーザに報告される場合があります。
これは、仮想MFA デバイスの登録時に作業を中断すると、対象となるIAM ユーザに関連する仮想MFA デバイスの情報が残ってしまう事が原因です。実際にはデバイスを設定していないのに再度デバイスを登録しようとした際に表示されます。
この問題を解消するには以下対応を管理者が行います。
(参照)一般的な IAM の問題のトラブルシューティング
AWS CloudShell を開きます(右上のメニューにあります)。
登録済みの仮想MFA デバイス一覧を表示します。
コマンド[aws iam list-virtual-mfa-devices] を実行します。$aws iam list-virtual-mfa-devices { "VirtualMFADevices": [ { "SerialNumber": "arn:aws:iam::123422343234:mfa/削除対象" }, { "SerialNumber": "arn:aws:iam::xxxxxxxxxxxx:mfa/aaaaaaaaaaaaaa", "User": { "UserId": "xxxxxxxxxxxx", "Arn": "arn:aws:iam::xxxxxxxxxxxx:aaaaa", "CreateDate": "2099-01-01T02:08:59+00:00", "PasswordLastUsed": "2099-01-01T02:47:47+00:00" }, "EnableDate": "2099-01-01T02:53:30+00:00" }, { "SerialNumber": "arn:aws:iam::xxxxxxxxxxxx:mfa/aaaaaaaaaaaaaaaa", "User": { "Path": "/", "UserName": "aaaaaaaaaaaaaaaaaaaaa", "UserId": "xxxxxxxxxxxxxxxxxxxxxx"
3. 削除対象であるARN を指定し、削除します。
コマンド[aws iam delete-virtual-mfa-device --serial-number [ARN]] を実行します。$aws iam delete-virtual-mfa-device --serial-number arn:aws:iam::123422343234:mfa/削除対象 $
4. 再度登録済みの仮想MFA デバイス一覧を表示します。{ "VirtualMFADevices": [ { "SerialNumber": "arn:aws:iam::xxxxxxxxxxxx:mfa/aaaaaaaaaaaaaa", "User": { "UserId": "xxxxxxxxxxxx", "Arn": "arn:aws:iam::xxxxxxxxxxxx:aaaaa", "CreateDate": "2099-01-01T02:08:59+00:00", "PasswordLastUsed": "2099-01-01T02:47:47+00:00" }, "EnableDate": "2099-01-01T02:53:30+00:00" }, { "SerialNumber": "arn:aws:iam::xxxxxxxxxxxx:mfa/aaaaaaaaaaaaaaaa", "User": { "Path": "/", "UserName": "aaaaaaaaaaaaaaaaaaaaa", "UserId": "xxxxxxxxxxxxxxxxxxxxxx"削除されている事が確認できます。再度ユーザに対応をお願いします。
- 投稿日：2021-01-12T21:01:19+09:00
[AWS] MFA 利用を強制した場合、ユーザ側が必要になる作業
はじめに
備忘録です。
この記事は以下チュートリアル実施後環境を想定しています。
(参照)IAM チュートリアル: ユーザーが自分の認証情報および MFA 設定を管理できるようにするユーザ側で必要となる操作について
管理者から共有されたアカウント情報を用いてコンソールにログインします。(パスワードを変えろと言われたら変えましょう。)
自分が権限を付与される予定のサービスにアクセスしてみます。利用できない状態です(画像はEC2)。
右上のメニューから[マイセキュリティ資格情報] を選択します。
[多要素認証（MFA）] 内の[MFA デバイスの割り当て] を選択します。
ラジオボタンで[仮想 MFA デバイス] を選択しているか確認し、[続行] 。
管理者より指定の端末にGoogle Authenticator をインストールし、QRコードを読み込んでコードを入力します。
完了したらポップアップを閉じ、再度ログインし直してみます。
利用予定のサービスへアクセスが出来るようになっています。
- 投稿日：2021-01-12T20:43:55+09:00
django-sesで「No handler was ready to authenticate」エラー
事象
No handler was ready to authenticate. 1 handlers were checked. ['HmacAuthV3Handler'] Check your credentials
- EC2では動く
- ECS（Fargate）で上記エラー
- IAM Roleには正しく設定されている（AdminRoleを設定しても解決されない）
解決策
このエラー自体はRoleの設定ミス等の他の原因でも発生するのですが（そのため調査に時間がかかりました・・）、ライブラリのバージョンが古いと発生する可能性があります。
具体的には、
django-sesが1.0未満（0.X）の場合に、認証ライブラリのbotoが古いために（botoではなくboto3である必要がある）、ECSのRoleをうまく扱えずにエラーが発生します。
他のライブラリでも、ECS環境で認証エラーが発生した場合は疑ってみてください。
- 投稿日：2021-01-12T19:05:12+09:00
[備忘録]本番環境への更新(AWS EC2)
前提
- Railsでアプリケーションを作成している
- AWSの初期設定が完了しており、EC2のインスタンスなども起動し、既にアプリケーションをデプロイしている
- Capistranoによる自動デプロイ設定が完了している
本記事の目的
- 作成したアプリケーションにローカルで変更を加えたので、AWSで本番環境にも変更を反映させたい
- herokuでのプッシュ方法をいつも忘れてしまうので、備忘録代わりに投稿しておきたい
手順
1.ローカル環境での変更をgithub上のmasterブランチへプッシュ
2.EC2へログイン
terminal~ % cd .ssh .ssh % ssh -i example.pem ec2-user@更新したいアプリケーションのElastic IP3.EC2内のアプリケーションのリポジトリへ移動
terminal[ec2-user@ip-○○○-○○-○○-○○ ~]$ cd /var/www/アプリケーション名4.現在動いているサーバーを落とす
terminal[ec2-user@ip-○○○-○○-○○-○○ リポジトリ名]$ ps aux | grep unicorn ↓ 「unicorn master -c」の文字があるプロセスIDを探す ↓ kill プロセスID ↓ exit を実行し、EC2インスタンスからログアウト5.ローカルの更新したいアプリケーションのディレクトリにて自動デプロイを実行
terminalアプリケーション名 % bundle exec cap production deploy6.Elastic IPよりアクセスし。変更が反映されているか確認
以上。
- 投稿日：2021-01-12T16:44:03+09:00
AWS認定クラウドプラクティショナー合格体験記
0.はじめに
こんにちは。もと みやです。システムエンジニアとして働き始めて2年と少しになります。
自身初となるAWSの認定試験AWS Certified Cloud Practitioner(CLF-C01)を取得しました。
そこで、今回は合格体験記を書いていこうと思います。（こっちも自身初...）
←こんなバッチもらえます
1.AWS認定試験とは
AWS 認定は、クラウドの専門知識を検証し、専門家が需要の高いスキルを強調し、組織が AWS を使用してクラウドイニシアチブにおける効果的で革新的なチームを構築するのに役立ちます。個人やチームが独自の目標を達成できるように、役割と専門分野ごとに設計したさまざまな認定試験から選択します。 https://aws.amazon.com/jp/certification/?nc2=sb_ce_co より
要はAmazon Web Serviceを使ってアプリケーション開発やインフラ構築、営業が行えるだけの技術的な専門知識を持っていることを認定する制度です。
全11種類あり、レベル別、役割別、専門分野別に用意されています。（下図参照）
今回受けたのは基礎コースのクラウドプラクティショナーという資格です。
1-1.Certified Cloud Practitionerとは
AWSクラウドの知識とスキルを身に着け、全体的な理解を効果的に説明できる人が対象で、認定により検証される能力は以下の通りです。
- AWS クラウドとは、何かということ、及びベーシックなグローバルインフラストラクチャについて定義できる
- AWS クラウドのベーシックなアーキテクチャ原理を説明できる
- AWS クラウドの価値提案について説明できる
- AWS プラットフォームの主なサービスと一般的なユースケース（例：コンピューティング、分析など）について説明できる
- AWS プラットフォームのセキュリティとコンプライアンスのベーシックな側面、及び共有セキュリティモデルについて説明できる
- 請求、アカウントマネジメント、料金モデルを明確に理解している
- ドキュメントや技術サポートのソースを特定できる
- AWS クラウドにおけるdeployと運用のベーシックで重要な特徴を説明できる
簡単に言うと、AWSクラウドについて基本的なことはおおよそすべて理解してる人、ということです。
ここでいうAWSクラウドとは使用するサービスだけでなく料金体系、サポート、プラン、セキュリティについて等業務を開始するうえで必要なことが大体含まれております。とはいえ、基礎コースなので、全体的に内容は簡単です。
2.受けた人について
- 開発エンジニア
- javascript, reactjs, nodejs, python, java, php, .netについては人並と自負
- インフラ経験はほとんどない
- 4年ほど前にすこしAWSを触ったことがある
- オンプレ？vm？なにそれおいしいの？
- AWSで使用したことのあるサービスは10個ほど…（正確ではない）
- 試験勉強期間はおよそ3週間
- 1日〇時間！とかはまったく決めていなかった
- 平日は多い日で2時間、休日はながくても4時間程度
3.試験勉強内容
3-1.大まかな流れ
本を買う（後述 ↓ 試験日・会場を決める ↓ 本を読む ↓ udemyの問題集を解く ↓ 本を読み直す ↓ 本に書いてないことを一通り調べる ↓ udemyの問題集を解く3-1.本を買う
試験を受けようと決めた日にgoogle先生に、
クラウドプラクティショナー 本と入力しました。
そして一番上に出てきた、AWS認定資格試験テキスト AWS認定 クラウドプラクティショナーという本をポちりました。
結論から言うと、試験には役立ちましたが、udemyの問題集には役立たなかった部分もありました。(?)
3-2.試験日を決める
amazonから本が送られてくるまでに（私は参考書は電子書籍無理な人です）、試験日を決めました。
が、結構手順があり苦労したのでまとめておきます。
1. AWSアカウントを作成する
2. AWS認定アカウントをAWSアカウントに紐づける
3. 試験方法・場所を選ぶ1についてはアカウント自体は誰のでもよさそうです。私の場合はamazon(ポチる方)のアカウントを昔awsアカウントと紐づけていましたので、それを使いました。
2にあるAWS認定アカウントとは、AWS認定プログラムへの参加を行うためのアカウントです。そのAWS認定プログラムって何ぞやってなると思いますが、要約するとAWSの試験を受けるために必要なものがそろっているプログラムです。（デジタルトレーニングや認定についてのダッシュボード等）
3の試験方法とは、自宅で受けるかテストセンターに行って受けるかを選ぶことができます。自宅で受ける場合は色々と準備や条件が必要なようです。（調べてないｗ）
今回は家から一番近い柏南口テストセンターを利用しました。
3-3.本を読む
注文した翌日に届いた（prime会員強い）AWS認定資格試験テキスト AWS認定 クラウドプラクティショナーを読みました。
本の内容はここでは書ききれないので割愛します。
ともかく頭から最後まで全部読みました。読みながらメモなどは取りませんでしたが、ある程度まとめておけばよかったかも…？とも思いました。読破にかかった時間はおよそ1.5週間です。
3-4.Udemyの試験問題集を解く
これが今回のベストプラクティスです。
AWS認定資格試験テキスト AWS認定 クラウドプラクティショナーにも章ごとに練習問題として3～5問ほど乗っていますが、章末問題なので読んだ内容からしか出てこないですし、簡単すぎてほぼ意味がありません。
AWS認定プログラムには模擬試験もあります。が、お金がかかる上に（当然だろ）予約や、テストセンターに受けに行く必要もあります。
と、そこで見つけたのが！
この問題だけで合格可能！AWS 認定クラウドプラクティショナー 模擬試験問題集（7回分455問）だったのです。しかも見つけたときはセールで￥1,200でした（今はいくらか知らん）！早速ぽちり、問題を解き始めました。
内容は、
* 基本レベルの試験が2回分(65問2)
* 応用レベルの試験が3回文(65問*3)
* 難易度高の試験が2回文(65問2)
となっております。基本レベルの1周目は53問正解でした。まぁ悪くないのではﾌﾌﾝといった感じです。
スクショ
このように問題の分野別に正解率を出してくれるので、自分の弱い部分を見つけやすいと思いました
次に、応用レベルを解きはじめたのですが、なめててかかったので腰を抜かしました。難しすぎる…。
そもそも私のAWS知識なんて触ったことのあるサービス(1割)とAWS認定資格試験テキスト AWS認定 クラウドプラクティショナー(9割)だけですから、AWS認定資格試験テキスト AWS認定 クラウドプラクティショナーにのっていない知識については分かるわけがないのです。
特に、セキュリティ部門の問題と料金についての問題は苦労しました。
実際に業務する人間はセキュリティはまだしも、料金については気にしませんからね…。また、料金の部門についてはサポートプランについても言及されているので、完全にお手上げでした。
スクショ
サポートプランが見事に全滅…、セキュリティも酷いですね…。
一通りすべての問題を解ききりましたが、応用レベル以降は大体50%程度の正誤率でした。
3-5.本を読み直す
Udemyの応用レベルにけちょんけちょんにやられた私は、きっとAWS認定資格試験テキスト AWS認定 クラウドプラクティショナーに書いてあったが見落としたんだ！と思い込み、索引を利用してわからなかった問題を調べ始めましたが、先ほど述べた通り、AWS認定資格試験テキスト AWS認定 クラウドプラクティショナーには書かれていないものも多くありました。また、書かれていたとしても詳しいサービス内容等まで言及されておらず、そんな機能もあったのか！って感じですね。
しかし、一度問題を解いた後だと読み直して気づける部分も多々あり、サービスのつながりや、サービスの比較、サービスの詳細な仕様について理解が深まったと思います。
3-6.本に書いてないことを一通り調べる
本に書いてないなら調べる他にないだろう。ということで間違えた問題をすべて見直し、徹底的に調べました。
以下に、AWS認定資格試験テキスト AWS認定 クラウドプラクティショナーに書いていないがUdemyによく出てくるAWSサービスを一部メモしておきます。
- AWS GuardDuty
- AWS OpsWork
- AWS Snowmobile
- AWS CloudHSM
- etc...
ここら辺の単語は聞いたことも無かったので、調べていてとても面白かったです。知らないサービス出るわ出るわ。
それだけでなく、知っているサービスとの連携もあるので、非常に為になりましたし、AWS知ってるぜ感が強まった気がします。単語の意味を勉強するだけでなく、簡単な利用方法等も調べて勉強した方がより実践的に覚えることができます。私はハンズオンや詰まった点などの記事をよく検索してみました。
3-7.Udemyの試験問題集を解く(2回目)
当然同じ問題なので、答えを覚えていれば点は上がりますが、それを加味してもかなり点数は上がりました。
スクショ
応用レベルでも合格点の7割を超えました。
間違えた問題の多くは1回目と同じでしたが、1回目との大きな違いは、まったくわからない⇒どっちかだとは思うが決めきれない、といった感じになっていました。
細かい数字の部分や、サービス同士の連携、詳細な仕様について理解しきれていなかったので問題を見直し、知識を詰め込みました。
ちなみに2週目を始めたのは試験5日前です。
4.試験当日
テストセンターってどんなところだろうか…とか思いつつ、テストセンターのすぐ近くにある誉でラーメンを食べ、向かいました。
テストセンターでは同意書を記入し、荷物をすべてロッカーに入れ、鍵だけ持ってPCのある部屋へ案内されました。
テストは90分の65問で回答が完了したら受付に戻り、スコアシート（スコアが書いてあるとは言っていない）を受け取って試験完了でした。
ちなみに、回答完了時に試験結果は出ます。（点数は出ませんが）
なので、この時点で結構テンション上がってました。
5.所感
実際に受けた後の感想ですが、難易度としてはUdemyでビビり切った私にはとても簡単に感じるくらいの難易度でした。
本の章末問題<<<<<<<<試験<<<Udenyの応用問題といった感じですかね…。
ただ、試験の際にちょっと詰まったのは、日本語の言い回しが独特で（おそらく日本語に直訳）、なんだか車の免許試験を受けているような感覚でした。
また、Udemyの問題集でも扱いきっていなかったサービスの組み合わせがあり、おそらくそういうところで点を落としたのだと思います。
結果824点で合格しました。
700点以上で合格なのでまずまずでしょう。
ちなみに合格すると、特典がもらえます。最初に話したデジタルバッチがもらえたり、模擬試験1回分（4000円相当）が無料になったり、次に受ける試験が半額になったりと、とても盛りだくさんの特典がもらえました。
特典についてはまったく調べていなかったのでビックリしました。
次はAWS 認定 ソリューションアーキテクト – アソシエイトかAWS 認定 デベロッパー – アソシエイトを頑張って受けようと思っています。
- 投稿日：2021-01-12T13:43:22+09:00
coursera の 講座を通して知った AWS オススメの Serverless な開発
はじめに
年末年始の休みはコロナの影響でどこにも行かなかったので、 coursera の AWS Fundamentals: Building Serverless Applications を集中受講してみました。
感想をざっくりまとめると、以下のようになります。
- AWSがオススメする Serverless な Webアプリケーションの構成がなんとなく見えてきた。
- AWSを使って、ServerlessなWebアプリを自分で作ってみたい。
- 実際のお仕事で開発するには、まだまだ自分の知見が足りない。
講座の内容
この講座は有料ですが、１週間の間は全コンテンツを無料で参照できるようになっています。AWSがオフィシャルで公開している講座の１つです。
AWSのサービスを組み合わせて、Serverless な Webアプリケーションを開発していきます。ただし、フロントエンド（HTML, CSS, JavaScript）はあらかじめ用意されており、バックエンド側の作業がメインになります。実習は、AWSのアカウントを持っていることが前提です。一部、実習のテキスト通りにAWSコンソールを操作しても、期待通りの結果にならない部分がありました。恐らく講座作成当時には正しかった情報でも、AWSのサービス自体が改善されて、画面の構成や機能が変更されているからだと思います。まあ、公式のドキュメントを頼りに、自力で調べれば何とかなるレベルなので、その方がかえって勉強になるかと思いました。
なお、カリキュラムは、AWSの利用料金が高くならないように (free tier という言葉があった) 一応配慮されているようです。
講座を通してわかったこと
AWSオススメの Serverless な構成
何となくですが、講座を受講してみて、 AWSが推奨するようなServerlessなアプリを開発する時の、構成の基本みたいなものがわかった気がします。
- フロントエンド（HTML, CSS, JavaScript, etc)は、 S3のバケットにまるっと放り込む。
- S3に静的サイトのホスティングの設定をしてブラウザーからアクセスできるようにする。
- CloudFront を使って、静的サイトの高速化をする。
- データは DynamoDB に保存する。
- データに対する操作（アプリケーションロジック）は、Lambda を使う。
- API GateWay で Web API のインターフェースを用意する。
- API GateWay で受け取ったリクエストは、 Lambda で処理する。
- フロントエンドからは、API GateWay で用意した Web APIを呼び出す。
とまあ、こんな感じです1。
実際、S3や、DynamoDB や Lambda はアプリの規模にもよるでしょうが、
- S3, Lambda, DynamoDB は、無料枠（または、低コスト）の範囲である程度、利用できそう。
- これらのサービスを接続しやすいようにAWSコンソールのインターフェースが工夫されている。
といった点からも AWS がオススメする Serverless な Webアプリの構成の定番なのかなと感じました。
細かい操作や設定やプログラミングはさておき、この概要がわかっただけでも収穫でした。
講座を受けて課題と感じたこと
サービスの組み合わせ方が大変そう
どのサービスをどう組み合わせれば欲しいシステムが実現できるのか、現実には悩みそうです。（だからこそ、今回１つの定番と思われる組み合わせを知ることができたのは収穫でした。）
この辺のどのAWSのサービスをどう組み合わせてシステムを実現するかってところがポイントになるから、AWSには、システムアーキテクトという資格が用意されているのかと腑に落ちました。設定が大変そう
いろんなサービスを組み合わせて使うので、それらを繋ぎ合わせるための設定が大変だと感じました。講座は、ドキュメントがあって、それに従ってやればできてしまうのですが、自分で一からやれと言われると面倒そうです。（後、講座では手抜きで、サービスにフルアクセス可みたいな設定にしちゃってますが、本来は最低必要なものだけに権限を制御すべき2だし、そのあたり考え出すと結構大変そうです。）
そのための解決策として、DevOpsとか、CLIで全部できるようになっているとかがあるのかと想像しているのですが、まだよくわかってません。デバッグが大変そう
エラーがあるときに、どのサービスでエラーが発生しているのか見つけにくそうな気がしました。サービスが分散しているためにどのサービスでエラーになっているのかわかりにくそうです。（わかりにくいのは、別にAWSに限ったことではないですが...)
また、 Lambda のコードをローカル環境で（デプロイしないで）テストする方法3が良くわからないです
この辺も別でAWSがサービスがありそうなんですが、まだわかってません
コードレビューが大変そう
メインは Lambda のコードになると思うのですが、これをどこでコードレビューするのか、レビューの際にどうやって動作を確認すれば良いのか、その解が見つかっておりません。
この辺も別でAWSが...（以下略）Lambda で使う開発言語
講座では JavaScript が使われていたのですが、何を選ぶのが良いのか。
まあ、Rubyを選びたいところなんですが、どの言語が有利なのか（AWSのサポート具合の充実度）が気になります。まとめ
AWSという新しいオモチャを手に入れた（アカウントを作った）ので、何かアプリを作ってみたいところです。AWS オススメの Serverless 開発が少しわかったのですが、わかった分だけ、わからないことがどんどん増えました。
あとは、１年間どれだけ無料枠で遊び倒して、知見を深められるかが勝負の分かれ目です参考資料など
- Coursera の講座
- AWSのドキュメントのページ
これを図にしようかと思ったのですが、実際、AWSのオフィシャルサイトでWebアプリの構成例として公開されていました。 Serverless Applications Lens - AWS Well-Architected Framework の PDFの「Web Application」のページに図が載ってました。PDFは、まだ読んでませんが、やっぱり、AWSが、推奨している構成のようですね。ちなみに、講座では、認証部分は省略されてましたので、Cognito は登場しません。 ↩
AWSのアクセス権限の考え方に関しては、Coursera に AWS 公式のIAMの講座 Introduction to AWS Identity and Access Management があります。 ↩
今、受講している Amazon DynamoDB: Building NoSQL Database-Driven Applications では、Cloud9上でコードを書いて、consoleで動作確認してそれを Lambda 関数としてそのまま貼り付けるやり方をしています。handlerの関数から実際の処理を行う関数を呼び出し、Cloud9のコンソールでも実際の処理を行う関数の動作確認をするようになっています。この辺り、基本的なことではありますが、テストしやすいようにコードを書く工夫すれば、テストは書けそうな気がします。 ↩
- 投稿日：2021-01-12T12:37:11+09:00
AWSのメニューと説明の一覧を手軽に取得できたから単語帳にしてみた
はじめに
ほんとなんとなく思い立ったので、なんとなく作りました
100%自分用のメモです成果物
https://ankilot.com/view/?pr=XMeFbkUKa8
手順
- AWSにサインインする
AWSの上のメニューをひらく
F12をおす
consoleで下記を実行する
copy($$('._142-PMgGBA2POWI1QZQeIW').map(e=>[e.textContent,e.title].join(',')).join('\n'))
- エディタにはりつける
- 2つめのEC2の上までは左の最近アクセスした履歴なので削除する
- ファイル名をつけてCSVで保存する
- https://ankilot.com/ を開いて単語帳をつくる
おわり
補足
下記の3つは説明がありませんでした
- Personal Health Dashboard
- サポート
- CloudShell
ほんとはカテゴリも入れたかったのですが、うまい具合に手軽に取得できないのであきらめました
- 投稿日：2021-01-12T12:26:02+09:00
AWS CodeCommit をスイッチロールで利用する
はじめに
CodeCommitリポジトリをスイッチロール権限でローカルにgit cloneすることを目的とします。
スイッチロールについてや設定方法については本記事では言及しません。使用環境とバージョン
- macOS Catalina
- git version 2.24.3 (Apple Git-128)
- aws-cli/2.0.28
記事の対象
- ある程度AWSとGitの知識がある方
- CodeCommitを利用して開発を行いたい方
- CodeBuild、CodePipelineを使用したCI/CDに興味がある方
※ CodeCommitとGitの違いについて公式ドキュメントのQ&A
AWS CodeCommit のよくある質問事前準備
- Git 1.7.9 以降がインストールされていること（Macではプリインストールされているはず）
- スイッチロールを作成済み。スイッチロール先にCodeCommit操作権限が付与されていること
1. AWS CLIのインストール
以下のコマンドを実行し、AWS CLIをインストールします。
$ brew install awscli // 更新の場合: brew upgrade awscli ... $ aws --version aws-cli/2.0.28 Python/3.8.3 Darwin/19.5.0 botocore/2.0.0dev322. IAMユーザのアクセスキーとシークレットキーを発行
AWS CLIを使用するためにはIAMユーザを紐づける必要があります。
事前にAWSコンソールから自身のユーザを選択し、アクセスキーを発行します。
3. configおよびcredentialsを設定
aws configureコマンドを使用して、AWS CLIに事前に取得したアクセスキーとシークレットキーを設定します。$ aws configure AWS Access Key ID [None]: [アクセスキー] AWS Secret Access Key [None]: [シークレットキー] Default region name [None]: ap-northeast-1 Default output format [None]: json上記コマンドを実行することで以下の2ファイルに設定が追加されます。
~/.aws/credentials[default] aws_access_key_id=AKIAIOSFODNN7EXAMPLE aws_secret_access_key=xxxxxxxxxxxxxxxxx~/.aws/config[default] region=ap-northeast-1 output=json4. configにスイッチ先のプロファイル情報を記載
configにスイッチ先のプロファイル情報を追加します。
追加したプロファイルを指定することで自身のIAMユーザに権限がアタッチされていないサービスでもスイッチロール先の権限を利用してサービスを利用できます。~/.aws/config[default] region=ap-northeast-1 output=json + [profile switchrole] + role_arn = arn:aws:iam::{スイッチ先のAWSアカウントID}:role/{ロール名} + source_profile = default + region=ap-northeast-1 + output=json5. 認証情報ヘルパーを設定
Gitでは認証情報ヘルパーを利用して先ほど追加したプロファイルを指定します。
以下のコマンドで認証情報ヘルパーにプロファイル情報を設定してください。$ git config --global credential.helper '!aws --profile switchrole codecommit credential-helper $@' $ git config --global credential.UseHttpPath true $ git config --global user.name "kazuki.kano" $ git config --global user.email kano@xxxx
user.nameなどのユーザ情報は適宜設定してください。
設定ルールなどを決めて設定することをお勧めします。設定内容は以下のようになります。
~/.gitconfig[credential] helper = !aws --profile switchrole codecommit credential-helper $@ UseHttpPath = true [user] name = kazuki.kano email = kano@xxxx6. CodeCommitからclone
あとはGitリポジトリと同様にcloneすれば完了です。
$ git clone https://git-codecommit.ap-northeast-1.amazonaws.com/v1/repos/demo-apiしばらくすると以下のようなエラーが発生する場合があります。
fatal: unable to access 'https://git-codecommit.ap-northeast-1.amazonaws.com/v1/repos/demo-api/': The requested URL returned error: 403これはAWS公式のドキュメントにもあるように、macOSでは
Keychain Access ユーティリティによりCodeCommitリポジトリへのアクセスは15分で無効になります。OS X および macOS でリリースされているデフォルトバージョンの Git では、Keychain Access ユーティリティを使用して、生成された認証情報を保存します。セキュリティ上の理由により、CodeCommit リポジトリにアクセスするために生成されるパスワードは一時パスワードであるため、15 分経過すると、キーチェーンに保存されている認証情報は無効になります。
認証情報ヘルパーと AWS CodeCommit への HTTPS 接続のトラブルシューティング
対処法は以下のように
helper = osxkeychainをコメントアウトして下さい。$ git config -l --show-origin | grep credential file:/Library/Developer/CommandLineTools/usr/share/git-core/gitconfig credential.helper=osxkeychain file:/usr/local/etc/gitconfig credential.helper=osxkeychain ... $ sudo vi /Library/Developer/CommandLineTools/usr/share/git-core/gitconfig [credential] # helper = osxkeychain // コメントアウトします上記だけで認証できない場合は、
Keychain Access ユーティリティに認証情報が残っている可能性があるのでこちらはアプリから削除して下さい。
検索ウインドでgitなどで検索すると絞り込めます。
参考記事
- 投稿日：2021-01-12T10:49:06+09:00
AWS Pricing Calculator
概要
以前から、AWSってどれくらい料金が掛かるの？
とのざっくり問い合わせを受けることが多く、
- AWS公式の料金表を見てください。
- AWSが提供している Simple Monthly Calculator を利用して見積もりをしてください。
と伝えていましたが、Simple Monthly Calculatorが停止予定となり、AWS Pricing Calculator に変わるのは知ってはいたのですが、見積もりを作成する機会がなかったため、実際にちゃんと触れたことがなかったため、少しだけやってみたいと思います。
見積もりたい構成
やってみた
見積もりの作成
まずは、https://calculator.aws/#/ にアクセスします。
デフォルトは、「English」なので「日本語」に変更し、「見積もりの作成」をクリックします。
サービスを選択するのですが、今回は、EC2、ELB、RDSを順に設定してみます。
EC2
検索入力のところに「EC2」を入力し、「Amazon EC2」の「設定」をクリックします。
「説明」を入力し、「リージョン」を「東京リージョン」に変更します。
「クイック見積もり」、「高度な見積もり」があるのですが、今回は、「クイック見積もり」を選択します。
ちなみに「高度な見積り」を場合は、「ワークロード」を変更することで、「Reservation options」の推奨オプションが変わります。
また、Simple Monthly Calculatorにもあった、データ転送についても入力可能となります。（最後に画像が貼ってありますので、興味がある方は見てください。）EC2のインスタンスの仕様を入力します。
「OS」、「インスタンスタイプ」、「数量」を入力します。
「各インスタンスの最小要件を入力してください。」を選択した場合は、「vCPU」、「メモリ」、「GPU」、「EUC」を入力することで、一番コストパフォーマンスが良いインスタンスタイプが表示されますので、インスタンスタイプを何にしようか迷うような場合は、こちらを入力してみてください。
価格戦略を入力します。
「価格モデル」を選択し、RIやSPを選択した場合は、「予約期間」、「支払いオプション」を選択します。
今回は「オンデマンド」を選択しました。
EBSの設定を入力します。
今回は、デフォルト値の「100GB」のままにしました。
EC2の見積もりが作成されるので、「見積りの追加」をクリックします。
My Estimateの画面が表示されるため、「サービスの追加」をクリックします。
ELB
検索入力のところに「ELB」を入力し、「Elastic Load Balancing」の「設定」をクリックします。
「説明」を入力し、「リージョン」は「東京リージョン」となっているため変更しません。
Elastic Load Balancing は、Application Load Blancerをオンになっていることを確認
Application Load Balancerのところは、AWSリージョンのロードバランサーになっていることを確認サービス設定は「1」を入力する
ロードバランサーキャパシティーユニット（LCU）の設定を行う。
現時点で決まっていないため、適当な値を入力。
ALBの見積もりが作成されるので、「見積りの追加」をクリックします。
My Estimateの画面が表示されるため、「サービスの追加」をクリックします。
RDS
検索入力のところに「RDS」を入力し、「Amazon RDS for SQL serverの「設定」をクリックします。
「説明」を入力し、「リージョン」は「東京リージョン」となっているため変更しません。
RDSの「ノード数」、「インスタンスタイプ」、「デプロイオプション」、
「価格モデル」、「ライセンス」、「データベース版」を入力します。
ストレージの設定を入力します。
今回は、デフォルト値の「100GB」のままにしました。
RDSの見積もりが作成されるので、「見積りの追加」をクリックします。
My Estimateの画面が表示されるため、「保存および共有」をクリックします。
見積り情報がパブリックサーバに保存されるとの注意事項が書かれているため、
問題がなければ「同意して続行する」をクリックします。※ 保存と共有をしない場合は、以降の手順は不要です。
見積り結果が保存されて、パブリックリンクが作成されるため、リンクをコピーする
別のブラウザなどでコピーしたリンクを開くと、さきほど保存した見積りが表示されます。
所感
勝手にSimple Monthly Calculatorよりも使いにくそうなイメージがあって使っていなかったですが、
基本的には古いGUIで入れていた部分をシンプル見積りでは簡素化しているので、
初めての場合は、Pricing Calculatorのほうが入りやすそうなイメージを受けました。誰かのご参考になれば幸いです。
おまけ
「高度な見積り」
一定の使用量を選択した場合
毎日のスパイクトラフィック（月、水、金）を選択した場合
- 投稿日：2021-01-12T08:30:17+09:00
【AWS】CloudTrail
・アカウントで行われたAPI呼び出しを記録し、ログファイルをS3バケットとCloudWatchLogsロググループに配信することが可能
・証跡からCloudWatchLogsにイベントを送信するように設定した場合
→証跡設定に一致するイベントのみを送信する
- 投稿日：2021-01-12T08:12:53+09:00
【AWS】VPC
- 投稿日：2021-01-12T07:54:43+09:00
【AWS】SQS
- 投稿日：2021-01-12T03:08:06+09:00
AWSでIAMユーザーを認証
前提
IAMユーザ作成済み。
環境：Macawscliをインストール
brew install awscliまだHomebrewをインストールしていないなら
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"
を実行。参考AWS CLI バージョン 2 のインストール。
確認：aws --version認証
aws configure --profile IAMユーザ名IAMで生成されたアクセスキー・シークレットアクセスキーを使います。
認証の確認：aws sts get-caller-identity
- 投稿日：2021-01-12T01:57:59+09:00
AWSのポリシーのアタッチ・デタッチのタイムラグに注意しよう
有名な話なのか分かりませんが、AWSのポリシーのアタッチ・デタッチに分単位のタイムラグがありました。
お陰様で時間を無駄にしたというか。
題材は AWS LambdaからLambdaを非同期で呼び出す(Python) です。
Lambda関数から他のLambda関数を呼び出すというもので、権限の設定が必要になります。
ついつい、（開発初期は）ルートユーザでやっちゃったりして、（一般のIAMユーザだと権限絡みで躓いてイライラするので）これはいけない、ということで一般のIAMユーザで作業した訳なんですけれども。
記事を参考にしてやってみて、「AWSLambdaRole」というポリシーをつけてみたんですが、一向に権限エラーが解消されない。
仕方なく、他の方法で権限をゴテゴテつけて、うーん、ダメだなぁ、と思いながらもう一度（何も変更せず）テストをしてみると、今度はグリーン（エラーなし）に。
その後、何度かアタッチとデタッチを繰り返して、ずいぶんタイムラグがあるなぁ、と思った次第です。
1:44:55に権限付与して、5秒間隔でテストをしてみると…1:49:45に変更が反映されました。5分弱ですね。
続いて、権限を削除してみます。1:50:55に権限の削除が完了し、同じようにテストです。1:54:25に変更が反映されました。3分30秒ですね。
1、2秒のラグならそんなもんかな、と思いますが、数十秒単位だと操作が間違っていたかな、となって時間が無駄になるので、なんとかして欲しいところではあります。
- 投稿日：2021-01-12T01:05:41+09:00
[AWS]CloudFormationのスタックが消せない解決例
どんな様子だったか
下記のサイトのCloudFormationを利用しようとして失敗したため、そのスタックを削除しようとしたらDeleteFaildになって失敗した
https://classmethod.github.io/ci-cd-hands-on-ecs/delete-environment/原因
CloudFormationのスタック削除による一括削除だとVPCの機能の一つのセキュリティグループを削除できない
↓
セキュリティグループが残っているとVPCが削除できない
↓
VPCが残っているとCloudFormationのスタック削除が成功しない解決策
VPCの使用していないセキュリティグループを手動で削除した後にCloudFormationのスタック削除を行うと成功します。
原因究明に繋がった記事
公式のトラブルシューティング記事：
https://aws.amazon.com/jp/premiumsupport/knowledge-center/elastic-beanstalk-deletion-failure/↑のなかにセキュリティグループは手動でないと消せないと書いてあり、自分も確認してみたら解決に繋がったという流れだった。
- 投稿日：2021-01-12T00:12:17+09:00
【Rails AWS Docker】既存Ruby on Rails + MySQLアプリをDockerで構築し、AWSにデプロイする(6)
ポートフォリをとして作ったRuby on RailsアプリをDockerコンテナ化し本番環境をAWSで構築するまでの道のりです。
ポートフォリオ自体はこちらとなります。
【ポートフォリオ】転職活動時に作成したポートフォリオの概要（テッ◯キャンプ）かなり苦しめられたので、どなたかのお役に立てれば。
タイトル 1 ローカル環境のRailsアプリをDockerコンテナ化 2 AWSにVPCを作成する。パブリックサブネットを作成する 3 プライベートサブネットを作成する 4 EC2インスタンスを作成する 5 RDSを作成する 6 DockerコンテナをAWSにアップロードする DockerコンテナをAWSにアップロードします。
この項目では、かなり苦しめられました。ngixやpuma、RDSなど接続しなくてはいけないものが多々あり、また、AWS内にコンテナを構築することにより今、自分がどこにいるのか、よくわからなくなる状態に陥ることがありました。
この記事通りに、行ってもうまくいかないかもしれませんが、少しでもどなたかのお力になれればと思います。
自分はできれば、再びあのような思いをしたく無いので忘れないうちに記事として残しておきました。作成したAWSインスタンスにローカルdockerコンテナをアップロードしていきます。
コンテナ内での環境変数を設定します。
現状、database.ymlを確認すると
database.ymlusername: root password: password host: dbこのように、セキュアな情報がハードコーディングされています。
このままではgithubのコードから漏洩する危険があるので、本番環境のコンテナ内で環境変数を用いてセキュアな情報を設定します。環境変数については、参考までに下記をご覧下さい。
環境変数について環境変数を利用するために、dotenv-railsというgemをインストールします。
Gemfileに以下を追記します。Gemfile.gem 'dotenv-rails'dotenv-railsをインストールすることにより、「.env」ファイルに記載された環境変数をdockerコンテナ内で、下記のような記述で取り出せる様になります。
ENV['DATABASE_PASSWORD']また、.envファイルをgithubに上げてしまうと元も子も無いので、gitignoreに追記します。
.env.envを下記の様に記載してアプリ直下に配置します。
DB_USERNAME=root DB_PASSWORD=gakjadfmoaeur DB_HOST=fito2-db-instance.〇〇〇〇〇〇.ap-northeast-1.rds.amazonaws.com DB_DATABASE=fitO2_dbDB_HOSTはRDSのエンドポイントです。
AWSのRDSダッシュボードのデーターベースをクリックし、一覧から該当のRDSを選択すると確認できます。database.ymlの修正
database.ymlに下記を追加して、本番環境は環境変数から値を読み込むようにします。
database.ymlproduction: <<: *default database: <%= ENV['DB_DATABASE'] %> adapter: mysql2 encoding: utf8mb4 charset: utf8mb4 collation: utf8mb4_general_ci host: <%= ENV['DB_HOST'] %> username: <%= ENV['DB_USERNAME'] %> password: <%= ENV['DB_PASSWORD'] %>nginx.confの修正
以下の部分を本番用に修正します。
nginx.confserver { listen 80; # =========ローカルと本番切り替え=========== server_name 固定IP; # server_name localhost; # ======================================docker-compose.ymlの修正
docker-compose.ymlversion: '3' services: app: build: context: . # =========ローカルと本番切り替え=========== command: bundle exec puma -C config/puma.rb -e production # command: bundle exec puma -C config/puma.rb # ====================================== volumes: - .:/fitO2 - public-data:/fitO2/public - tmp-data:/fitO2/tmp - log-data:/fitO2/log networks: - fitO2-network # =========ローカルと本番切り替え=========== # depends_on: # - db # db: # image: mysql:5.7 # environment: # MYSQL_ROOT_PASSWORD: password # MYSQL_USER: user # MYSQL_PASSWORD: password # MYSQL_DATABASE: fitO2_development # volumes: # - db-data:/var/lib/mysql # networks: # - fitO2-network # ====================================== web: build: context: ./nginx_docker volumes: - public-data:/fitO2/public - tmp-data:/fitO2/tmp ports: - 80:80 depends_on: - app networks: - fitO2-network volumes: public-data: tmp-data: log-data: db-data: networks: fitO2-network: external: true変更点
・dbコンテナは本番環境ではRDSを使用するので不要のため、コメントアウト
(appコンテナのdepend onもまとめてコメントアウトします)
・command のrails s に -e production を追記して、本番環境でサーバー立ち上げるようにした。AWSインスタンス上にdockerコンテナを構築する。
今一度、AWSインスタンス上にdockerコンテナを構築するまでの流れを整理します。
今、現状ローカルでは、下記のようにfitO2というファイルを元に、下記の様なdockerコンテナをbuildできる状態でした。
そして、fitO2というファイルを書き換えて、以下の様なコンテナが作成されるように修正しました。（DBコンテナ削除）
その、fitO2をgithubにpushします。そして、AWS側からclone(2回目以降はpull)します。
cloneしたfitO2を元に、AWS内でbuildしてコンテナを構築し、AWS内に作成しているRDSと接続します。
通信の流れはオレンジの矢印となります。
githubへプッシュ
まずは、修正したファイルをコミットしてgithubへpushします。
AWSにdockerをインストール
ssh接続でAWSにログインし、dockerをインストールします。
sudo yum install -y docker //インストール sudo service docker start //docker起動 sudo usermod -G docker ec2-user //ec2-userに権限付与 exit //ログアウト //再度sshでログイン docker info下記の様な表示がされたらオッケーです。
Client: Debug Mode: false Server: Containers: 0 Running: 0 Paused: 0 Stopped: 0 Images: 0 Server Version: 19.03.13-cesudo chkconfig docker on //EC2起動時にDockerを自動で立ち上げるdocker-composeをインストールします。
sudo curl -L "https://github.com/docker/compose/releases/download/1.24.0/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose docker-compose -v docker-compose version 1.24.0, build 0aa59064 //上記の様にバージョンが表示されたら成功gitをインストールします。
sudo yum install -y git秘密鍵を作成します。(質問は全てエンター）
ssh-keygen -t rsa -b 4096作成した秘密鍵を表示し、コピーします。
cat ~/.ssh/id_rsa.pubhttps://github.com/settings/keys
こちらにアクセスします。右上の「new SSH key」をクリックします。
titleを適宜入力し、keyのところに先ほどコピーした文字列を貼り付けます。
（ssh-rsa~から含めます）ssh -T git@github.com上記を打ち込んで、途中yesと入力し、下記の様に表示されればAWSとgithubの認証が成立しました。
Hi yourname! You've successfully authenticated, but GitHub does not provide shell access.以後、AWSインスタンス側から自身のgithubに対し、pull等ができる様になります。
githubからcloneします。（URLはリポジトリを表示したときのURL）
cd / //ルート直下に移動します。homeディレクトリでコンテナを展開すると、pumaとnginxの連携でエラーが出る場合がありますl。puma.sockの読み取りエラーsudo git clone https://github.com/〇〇〇〇〇〇/〇〇〇〇〇〇ls //lsと打って、ディレクトリがあるか確認する。今、gitignoreに記載したファイル(.env master.key)は含まれていません。そこで、ssh通信を用いてローカルからAWSに直接ファイルを転送します。
exit //一旦ログアウトして、ローカルのfitO2ファイルに移動 sudo scp -i ~/.ssh/fitO2_key.pem .env ec2-user@固定IP:/home/ec2-user/ sudo scp -i ~/.ssh/fitO2_key.pem config/master.key ec2user@固定IP:/home/ec2-user //scpコマンドを用いて、AWSに.envを転送します。 .env のように転送したファイルが表示されたらオッケー。 //権限の関係で一旦、ホームディレクトリに転送します。再度、ログイン。
cd ls -aホームディレクトリに移動して.envとmaster.keyが存在していたら問題ない。
.envとmaster.keyを移動させる。sudo mv .env /fitO2 sudo mv master.key /fitO2/config念のため移動してるか確認
ls -a /fitO2/ ls -a /fitO2/configコンテナの起動
cd /fitO2 docker-compose build //コンテナを作成します。 (Permition deniedになった場合は、sudo chmod 777 /usr/local/bin/docker-compose を実行します。） docker network create fitO2-network //ネットワークを作成します。 docker-compose run app rails assets:precompile RAILS_ENV=production //プリコンパイルを実施 docker-compose up //コンテナを起動します。下記のように表示されていれば問題なく起動しています。
Creating fito2_app_1 ... done Creating fito2_web_1 ... done Attaching to fito2_app_1, fito2_web_1 app_1 | Puma starting in single mode... app_1 | * Version 3.12.6 (ruby 2.5.1-p57), codename: Llamas in Pajamas app_1 | * Min threads: 5, max threads: 5 app_1 | * Environment: production app_1 | * Listening on tcp://0.0.0.0:3000 app_1 | * Listening on unix:///fitO2/tmp/sockets/puma.sock app_1 | Use Ctrl-C to stop別タブを開いて、AWSにログインします。
データベースの作成
docker-compose exec app rails db:create db:migrate RAILS_ENV=production docker-compose exec app rails db:seed RAILS_ENV=production //(必要に応じて）以上で、http://固定IPにアクセスした場合、正しく表示されるはずです。
RDSのデーターベース確認方法
dockerコンテナにログインし、mysqlを起動させます。
docker ps //コンテナIDを調べます。NAMESがfito2_app_1の方のCONTAINER IDをコピーします。
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES c5ec64f0ea76 fito2_web "/bin/sh -c '/usr/sb…" 5 minutes ago Up 5 minutes 0.0.0.0:80->80/tcp fito2_web_1 442b9ddb3a20 fito2_app "bundle exec puma -C…" 5 minutes ago Up 5 minutes fito2_app_1コンテナにログインします
docker exec -it 442b9ddb3a20 bashmysqlを起動させます。
service mysql startmysql -u root -h RDSのエンドポイント -p //パスワードを入力してログインセキュリティーグループで制限んしているので、作成したEC２コンテナからしかアクセスできません。
ローカルから試してみてください。
以上となります。
参考
EC2上でRailsアプリケーションにDockerを導入する(Rails、Nginx、RDS)
開発環境において既存のRailsアプリにDockerを導入する方法(Rails、nginx、mysql)
無料！かつ最短？で Ruby on Rails on Docker on AWS のアプリを公開するぞ。
【画像付きで丁寧に解説】AWS(EC2)にRailsアプリをイチから上げる方法【その1〜ネットワーク,RDS環境設定編〜】
Nginx + Rails (Puma) on Docker のいくつかの実用パターン
Docker + Rails + Puma + Nginx + MySQL
- 投稿日：2021-01-12T00:12:17+09:00
【Rails AWS Docker 】既存Ruby on Rails + MySQLアプリをDockerで構築し、AWSにデプロイする(6)
ポートフォリをとして作ったRuby on RailsアプリをDockerコンテナ化し本番環境をAWSで構築するまでの道のりです。
ポートフォリオ自体はこちらとなります。
【ポートフォリオ】転職活動時に作成したポートフォリオの概要（テッ◯キャンプ）かなり苦しめられたので、どなたかのお役に立てれば。
タイトル 1 ローカル環境のRailsアプリをDockerコンテナ化 2 AWSにVPCを作成する。パブリックサブネットを作成する 3 プライベートサブネットを作成する 4 EC2インスタンスを作成する 5 RDSを作成する 6 DockerコンテナをAWSにアップロードする DockerコンテナをAWSにアップロードします。
この項目では、かなり苦しめられました。ngixやpuma、RDSなど接続しなくてはいけないものが多々あり、また、AWS内にコンテナを構築することにより今、自分がどこにいるのか、よくわからなくなる状態に陥ることがありました。
この記事通りに、行ってもうまくいかないかもしれませんが、少しでもどなたかのお力になれればと思います。
自分はできれば、再びあのような思いをしたく無いので忘れないうちに記事として残しておきました。作成したAWSインスタンスにローカルdockerコンテナをアップロードしていきます。
コンテナ内での環境変数を設定します。
現状、database.ymlを確認すると
database.ymlusername: root password: password host: dbこのように、セキュアな情報がハードコーディングされています。
このままではgithubのコードから漏洩する危険があるので、本番環境のコンテナ内で環境変数を用いてセキュアな情報を設定します。環境変数については、参考までに下記をご覧下さい。
環境変数について環境変数を利用するために、dotenv-railsというgemをインストールします。
Gemfileに以下を追記します。Gemfile.gem 'dotenv-rails'dotenv-railsをインストールすることにより、「.env」ファイルに記載された環境変数をdockerコンテナ内で、下記のような記述で取り出せる様になります。
ENV['DATABASE_PASSWORD']また、.envファイルをgithubに上げてしまうと元も子も無いので、gitignoreに追記します。
.env.envを下記の様に記載してアプリ直下に配置します。
DB_USERNAME=root DB_PASSWORD=gakjadfmoaeur DB_HOST=fito2-db-instance.〇〇〇〇〇〇.ap-northeast-1.rds.amazonaws.com DB_DATABASE=fitO2_dbDB_HOSTはRDSのエンドポイントです。
AWSのRDSダッシュボードのデーターベースをクリックし、一覧から該当のRDSを選択すると確認できます。database.ymlの修正
database.ymlに下記を追加して、本番環境は環境変数から値を読み込むようにします。
database.ymlproduction: <<: *default database: <%= ENV['DB_DATABASE'] %> adapter: mysql2 encoding: utf8mb4 charset: utf8mb4 collation: utf8mb4_general_ci host: <%= ENV['DB_HOST'] %> username: <%= ENV['DB_USERNAME'] %> password: <%= ENV['DB_PASSWORD'] %>nginx.confの修正
以下の部分を本番用に修正します。
nginx.confserver { listen 80; # =========ローカルと本番切り替え=========== server_name 固定IP; # server_name localhost; # ======================================docker-compose.ymlの修正
docker-compose.ymlversion: '3' services: app: build: context: . # =========ローカルと本番切り替え=========== command: bundle exec puma -C config/puma.rb -e production # command: bundle exec puma -C config/puma.rb # ====================================== volumes: - .:/fitO2 - public-data:/fitO2/public - tmp-data:/fitO2/tmp - log-data:/fitO2/log networks: - fitO2-network # =========ローカルと本番切り替え=========== # depends_on: # - db # db: # image: mysql:5.7 # environment: # MYSQL_ROOT_PASSWORD: password # MYSQL_USER: user # MYSQL_PASSWORD: password # MYSQL_DATABASE: fitO2_development # volumes: # - db-data:/var/lib/mysql # networks: # - fitO2-network # ====================================== web: build: context: ./nginx_docker volumes: - public-data:/fitO2/public - tmp-data:/fitO2/tmp ports: - 80:80 depends_on: - app networks: - fitO2-network volumes: public-data: tmp-data: log-data: db-data: networks: fitO2-network: external: true変更点
・dbコンテナは本番環境ではRDSを使用するので不要のため、コメントアウト
(appコンテナのdepend onもまとめてコメントアウトします)
・command のrails s に -e production を追記して、本番環境でサーバー立ち上げるようにした。AWSインスタンス上にdockerコンテナを構築する。
今一度、AWSインスタンス上にdockerコンテナを構築するまでの流れを整理します。
今、現状ローカルでは、下記のようにfitO2というファイルを元に、下記の様なdockerコンテナをbuildできる状態でした。
そして、fitO2というファイルを書き換えて、以下の様なコンテナが作成されるように修正しました。（DBコンテナ削除）
その、fitO2をgithubにpushします。そして、AWS側からclone(2回目以降はpull)します。
cloneしたfitO2を元に、AWS内でbuildしてコンテナを構築し、AWS内に作成しているRDSと接続します。
通信の流れはオレンジの矢印となります。
githubへプッシュ
まずは、修正したファイルをコミットしてgithubへpushします。
AWSにdockerをインストール
ssh接続でAWSにログインし、dockerをインストールします。
sudo yum install -y docker //インストール sudo service docker start //docker起動 sudo usermod -G docker ec2-user //ec2-userに権限付与 exit //ログアウト //再度sshでログイン docker info下記の様な表示がされたらオッケーです。
Client: Debug Mode: false Server: Containers: 0 Running: 0 Paused: 0 Stopped: 0 Images: 0 Server Version: 19.03.13-cesudo chkconfig docker on //EC2起動時にDockerを自動で立ち上げるdocker-composeをインストールします。
sudo curl -L "https://github.com/docker/compose/releases/download/1.24.0/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose docker-compose -v docker-compose version 1.24.0, build 0aa59064 //上記の様にバージョンが表示されたら成功gitをインストールします。
sudo yum install -y git秘密鍵を作成します。(質問は全てエンター）
ssh-keygen -t rsa -b 4096作成した秘密鍵を表示し、コピーします。
cat ~/.ssh/id_rsa.pubhttps://github.com/settings/keys
こちらにアクセスします。右上の「new SSH key」をクリックします。
titleを適宜入力し、keyのところに先ほどコピーした文字列を貼り付けます。
（ssh-rsa~から含めます）ssh -T git@github.com上記を打ち込んで、途中yesと入力し、下記の様に表示されればAWSとgithubの認証が成立しました。
Hi yourname! You've successfully authenticated, but GitHub does not provide shell access.以後、AWSインスタンス側から自身のgithubに対し、pull等ができる様になります。
githubからcloneします。（URLはリポジトリを表示したときのURL）
cd / //ルート直下に移動します。homeディレクトリでコンテナを展開すると、pumaとnginxの連携でエラーが出る場合がありますl。puma.sockの読み取りエラーsudo git clone https://github.com/〇〇〇〇〇〇/〇〇〇〇〇〇ls //lsと打って、ディレクトリがあるか確認する。今、gitignoreに記載したファイル(.env master.key)は含まれていません。そこで、ssh通信を用いてローカルからAWSに直接ファイルを転送します。
exit //一旦ログアウトして、ローカルのfitO2ファイルに移動 sudo scp -i ~/.ssh/fitO2_key.pem .env ec2-user@固定IP:/home/ec2-user/ sudo scp -i ~/.ssh/fitO2_key.pem config/master.key ec2user@固定IP:/home/ec2-user //scpコマンドを用いて、AWSに.envを転送します。 .env のように転送したファイルが表示されたらオッケー。 //権限の関係で一旦、ホームディレクトリに転送します。再度、ログイン。
cd ls -aホームディレクトリに移動して.envとmaster.keyが存在していたら問題ない。
.envとmaster.keyを移動させる。sudo mv .env /fitO2 sudo mv master.key /fitO2/config念のため移動してるか確認
ls -a /fitO2/ ls -a /fitO2/configコンテナの起動
cd /fitO2 docker-compose build //コンテナを作成します。 (Permition deniedになった場合は、sudo chmod 777 /usr/local/bin/docker-compose を実行します。） docker network create fitO2-network //ネットワークを作成します。 docker-compose run app rails assets:precompile RAILS_ENV=production //プリコンパイルを実施 docker-compose up //コンテナを起動します。下記のように表示されていれば問題なく起動しています。
Creating fito2_app_1 ... done Creating fito2_web_1 ... done Attaching to fito2_app_1, fito2_web_1 app_1 | Puma starting in single mode... app_1 | * Version 3.12.6 (ruby 2.5.1-p57), codename: Llamas in Pajamas app_1 | * Min threads: 5, max threads: 5 app_1 | * Environment: production app_1 | * Listening on tcp://0.0.0.0:3000 app_1 | * Listening on unix:///fitO2/tmp/sockets/puma.sock app_1 | Use Ctrl-C to stop別タブを開いて、AWSにログインします。
データベースの作成
docker-compose exec app rails db:create db:migrate RAILS_ENV=production docker-compose exec app rails db:seed RAILS_ENV=production //(必要に応じて）以上で、http://固定IPにアクセスした場合、正しく表示されるはずです。
RDSのデーターベース確認方法
dockerコンテナにログインし、mysqlを起動させます。
docker ps //コンテナIDを調べます。NAMESがfito2_app_1の方のCONTAINER IDをコピーします。
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES c5ec64f0ea76 fito2_web "/bin/sh -c '/usr/sb…" 5 minutes ago Up 5 minutes 0.0.0.0:80->80/tcp fito2_web_1 442b9ddb3a20 fito2_app "bundle exec puma -C…" 5 minutes ago Up 5 minutes fito2_app_1コンテナにログインします
docker exec -it 442b9ddb3a20 bashmysqlを起動させます。
service mysql startmysql -u root -h RDSのエンドポイント -p //パスワードを入力してログインセキュリティーグループで制限んしているので、作成したEC２コンテナからしかアクセスできません。
ローカルから試してみてください。
以上となります。
参考
EC2上でRailsアプリケーションにDockerを導入する(Rails、Nginx、RDS)
開発環境において既存のRailsアプリにDockerを導入する方法(Rails、nginx、mysql)
無料！かつ最短？で Ruby on Rails on Docker on AWS のアプリを公開するぞ。
【画像付きで丁寧に解説】AWS(EC2)にRailsアプリをイチから上げる方法【その1〜ネットワーク,RDS環境設定編〜】
Nginx + Rails (Puma) on Docker のいくつかの実用パターン
Docker + Rails + Puma + Nginx + MySQL
- 投稿日：2021-01-12T00:11:46+09:00
【Rails AWS Docker】既存Ruby on Rails + MySQLアプリをDockerで構築し、AWSにデプロイする(5)
ポートフォリをとして作ったRuby on RailsアプリをDockerコンテナ化し本番環境をAWSで構築するまでの道のりです。
ポートフォリオ自体はこちらとなります。
【ポートフォリオ】転職活動時に作成したポートフォリオの概要（テッ◯キャンプ）かなり苦しめられたので、どなたかのお役に立てれば。
タイトル 1 ローカル環境のRailsアプリをDockerコンテナ化 2 AWSにVPCを作成する。パブリックサブネットを作成する 3 プライベートサブネットを作成する 4 EC2インスタンスを作成する 5 RDSを作成する 6 DockerコンテナをAWSにアップロードする RDSを作成します。
既存Ruby on Rails + MySQLアプリをDockerで構築し、AWSにデプロイする(１)においてデーターベースコンテナを作成しました。
実はプライベートサブネット内にEC2インスタンスを配置して、その中にデーターベースコンテナを配置してもいいのですが、AWSにはRDSというサービスがあります。
ざっくりいうと、RDSとはデーターベース用のインスタンスで、自動的に可用性や耐障害性を高めた構成にしてくれます。また、異なるアベイラビリティーゾーンにバックアップ用のデーターベースを配置することにより、災害等により一箇所のデーターベースで障害が生じた際にも、問題なく稼働できる様になっています。プライベートサブネットを二つ作った理由はこれです。
今回は、このRDSを用いてデーターベースインスタンスを作成します。
サブネットグループの作成
まずは、プライベートサブネット2つをまとめた、サブネットグループを作成します。
RDSダッシュボードに入り、サブネットグループを選択し、「DBサブネットグループを作成」をクリックします。
サブネットに先ほど、作成した二つのプライベートサブネットを追加します。
今、下記のような異なるアベイラビリティーゾーンを持つサブネットグループが作成されました。
パラメーターグループの設定
RDSでは直接データベースの設定を触れないので、パラメーターグループで設定します。
パラメーターグループファミリーは、開発環境のバージョンに合わせます。
オプショングループの設定
RDSダッシュボードに入り、オブショングループを選択し、「グループを作成」をクリックします。
開発環境に合わせてエンジンとメジャーエンジンバージョンを設定します。
RDSを作成する。
RDSダッシュボードに入り、データベースを選択し、「データーベースの作成」をクリックします。
下記は設定例です。ご自身の運用に合わせて設定してください。
「データーベースの作成」クリック
少し分かりずらいですが、下記の様にRDSがサブネットグループとdb用セキュリティーグループと結びつけることにより、
結果として下記の構成となります。
これでRDSインスタンスが作成できました。
次回(6)へ続く
DockerコンテナをAWSにアップロードする
- 投稿日：2021-01-12T00:11:46+09:00
【Rails】既存Ruby on Rails + MySQLアプリをDockerで構築し、AWSにデプロイする(5)
ポートフォリをとして作ったRuby on RailsアプリをDockerコンテナ化し本番環境をAWSで構築するまでの道のりです。
ポートフォリオ自体はこちらとなります。
【ポートフォリオ】転職活動時に作成したポートフォリオの概要（テッ◯キャンプ）かなり苦しめられたので、どなたかのお役に立てれば。
タイトル 1 ローカル環境のRailsアプリをDockerコンテナ化 2 AWSにVPCを作成する。パブリックサブネットを作成する 3 プライベートサブネットを作成する 4 EC2インスタンスを作成する 5 RDSを作成する 6 DockerコンテナをAWSにアップロードする RDSを作成します。
既存Ruby on Rails + MySQLアプリをDockerで構築し、AWSにデプロイする(１)においてデーターベースコンテナを作成しました。
実はプライベートサブネット内にEC2インスタンスを配置して、その中にデーターベースコンテナを配置してもいいのですが、AWSにはRDSというサービスがあります。
ざっくりいうと、RDSとはデーターベース用のインスタンスで、自動的に可用性や耐障害性を高めた構成にしてくれます。また、異なるアベイラビリティーゾーンにバックアップ用のデーターベースを配置することにより、災害等により一箇所のデーターベースで障害が生じた際にも、問題なく稼働できる様になっています。プライベートサブネットを二つ作った理由はこれです。
今回は、このRDSを用いてデーターベースインスタンスを作成します。
サブネットグループの作成
まずは、プライベートサブネット2つをまとめた、サブネットグループを作成します。
RDSダッシュボードに入り、サブネットグループを選択し、「DBサブネットグループを作成」をクリックします。
サブネットに先ほど、作成した二つのプライベートサブネットを追加します。
今、下記のような異なるアベイラビリティーゾーンを持つサブネットグループが作成されました。
パラメーターグループの設定
RDSでは直接データベースの設定を触れないので、パラメーターグループで設定します。
パラメーターグループファミリーは、開発環境のバージョンに合わせます。
オプショングループの設定
RDSダッシュボードに入り、オブショングループを選択し、「グループを作成」をクリックします。
開発環境に合わせてエンジンとメジャーエンジンバージョンを設定します。
RDSを作成する。
RDSダッシュボードに入り、データベースを選択し、「データーベースの作成」をクリックします。
下記は設定例です。ご自身の運用に合わせて設定してください。
「データーベースの作成」クリック
少し分かりずらいですが、下記の様にRDSがサブネットグループとdb用セキュリティーグループと結びつけることにより、
結果として下記の構成となります。
これでRDSインスタンスが作成できました。
次回(6)へ続く
DockerコンテナをAWSにアップロードする
- 投稿日：2021-01-12T00:11:19+09:00
【Rails AWS Docker】既存Ruby on Rails + MySQLアプリをDockerで構築し、AWSにデプロイする(4)
ポートフォリをとして作ったRuby on RailsアプリをDockerコンテナ化し本番環境をAWSで構築するまでの道のりです。
ポートフォリオ自体はこちらとなります。
【ポートフォリオ】転職活動時に作成したポートフォリオの概要（テッ◯キャンプ）かなり苦しめられたので、どなたかのお役に立てれば。
タイトル 1 ローカル環境のRailsアプリをDockerコンテナ化 2 AWSにVPCを作成する。パブリックサブネットを作成する 3 プライベートサブネットを作成する 4 EC2インスタンスを作成する 5 RDSを作成する 6 DockerコンテナをAWSにアップロードする EC2インスタンスを作成する
EC2とは
Elastic Compute Cloudと呼ばれるもので、ざっくりというと仮想的なパソコンです。
それを、AWS上に置くことによって、クラウド上にシステムを構築します。
作成したEC2インスタンスは、パブリックサブネットに配置して、アプリ本体を置きます。
EC2インスタンスの作成
検索ウィンドウからEC2を検索し、コンソールに入ります。
インスタンスを起動をクリックします。
今回はインスタンスタイプにクイックスタートの「AMAZON Linux2」を利用します。
（ざっくり）どのタイプのコンピューターにするかということです。今回はOSがlinuxのものを選択します。
タイプは無料利用枠のt2.microを選択します。
（ざっくり）どの程度のスペックにするかとうことです。
→「次のステッップ：インスタンスの詳細設定」をクリックします。
項目 内容 説明（ざっくり） インスタンス数 1 起動するインスタンスの数 購入のオプション チェックなし スポットインスタンスを選択すると安価に利用できる（常時起動しない場合） ネットワーク fitO2_vpc 先ほど作成したVPCに配置する。 サブネット fitO2_public_subnet_1a 先ほど作成したパブリックサブネットに配置する。 自動割り当てパブリック IP サブネット設定を使用（無効） 後ほど固定IPを割り振るため 配置グループ チェックなし 複数のインスタンス間の通信を高速化する設定 キャパシティーの予約 なし リソースの上限を超えた時にインスタンスが起動できなくなることを回避（有料） IAM ロール なし AWSのリソースに紐付けることができる権限設定を行うサービス CPU オプション なし CPUの性能に対するオプション シャットダウン動作 停止 シャットダウン時の動作 停止 - 休止動作 なし 停止動作に休止動作を追加する 終了保護の有効化 なし 誤った終了を防止します モニタリング なし 5分間隔の監視を1分感覚にする。 テナンシー 共有 ハードディスクを占有するか否か Elastic Inference なし 機械学習に効率化 クレジット仕様 なし 規定量の通信量が来た際に制限がなくなる ネットワークインターフェイス
プライマリIP 10.0.10.10 サブネットにプライベートIPアドレスを設定する。 「次のステップ：ストレージの追加」をクリック
項目 内容 説明（ざっくり） サイズ 8 ボリュームタイプ 汎用SSD 合わせて削除 チェック 暗号化 暗号化なし 「タグの追加」をクリック
項目 内容 説明（ざっくり） name fitO2_web ボリュームタイプ 汎用SSD インスタンス チェック ボリューム チェック 「セキュリティーグループの設定」をクリック
既存のセキュリティーグループを選択する。
先ほど作成した（fitO2_SG）を適用する。「確認と作成」をクリック
「起動」をクリック
キーペアの作成
新しいキーペアの作成（すでにキーペアを作っている場合は既存のものを作っても良い）
キーペア名を設定し、ダウンロード。
（ざっくり）キーペアとは、ssh接続する際に、使用する鍵。ssh接続する際にダウンロードしたキーペアを用いて接続し、AWS側にで生成した鍵と合致した場合接続が許可される。
「インスタンスの作成」
作成されたら、分かりやすいようにインスタンスに名前を設定しておきます。
nameのところをクリックしたら名前が編集できます。
ダウンロードしたキーペアを適当な位置に移動させます。(今回は ~/.ssh）
Elastic IP（固定）アドレスを作成する。
現状インスタンスを停止したら、IPアドレスが変わってしまうので、固定IPを割り割り振ります。
EC2ダッシュボードから、Elastic IPを選択します。
「新しいアドレスの割り当て」をクリックします。
ネットワークボーダーグループ : ap-northease-1
パブリック IPv4 アドレスプール : Amazon の IPv4 アドレスプール「割り当て」をクリック。
作成したElastic IPアドレスに分かりやすい様に名前を付けておく。
Elastic IP（固定）アドレスをインスタンスに紐づける。
作成したIPアドレスにチェックを入れてアクションから「アドレスの関連付け」を選択する。
リソース : インスタンス
インスタンス : 作成したインスタンスを選択
プライベートIPアドレス : 10.0.10.10「関連付け」をクリック
ssh接続を試みて確認する。
インスタンスの状態が、runningになっていることを確認後
sudo ssh -i ~/.ssh/fitO2_key.pem ec2-user@固定IPアドレス~/.ssh/fitO2_key.pemは秘密鍵の保管している場所/秘密鍵の名前
固定IPは、インスタンス一覧から選択して、説明タグをクリックし、Elastic IPと表示されているものです。Are you sure you want to continue connecting (yes/no/[fingerprint])? yesと打ってenter__| __|_ ) _| ( / Amazon Linux 2 AMI ___|\___|___| https://aws.amazon.com/amazon-linux-2/上記のように表示されれば接続成功。
図にすると下記の様なイメージで接続しました。
EC2には先ほど作成したセキュリティーグループ（fitO2_SG)が適用されています。
インバウンド（入ってくる方の通信）に対し、ssh接続の場合、２２番ポートを使用し、全てのアクセス元（0.0.0.0/0)を許可しているので、ssh接続することが可能だったわけです。
EC２インスタンスを作成し、ssh接続を行うことができました。
80番ポートもhttp通信に対し、開放されているので、今作成したインスタンスは下記のような通信を許可する状態となっています。
これでパブリックサブネットEC2インスタンスに対し、上記のようなセキュリティーグループが設定されました。
次回(5)へ続く
RDSを作成する
- 投稿日：2021-01-12T00:10:53+09:00
【Rails AWS Docker】既存Ruby on Rails + MySQLアプリをDockerで構築し、AWSにデプロイする(3)
ポートフォリをとして作ったRuby on RailsアプリをDockerコンテナ化し本番環境をAWSで構築するまでの道のりです。
ポートフォリオ自体はこちらとなります。
【ポートフォリオ】転職活動時に作成したポートフォリオの概要（テッ◯キャンプ）かなり苦しめられたので、どなたかのお役に立てれば。
タイトル 1 ローカル環境のRailsアプリをDockerコンテナ化 2 AWSにVPCを作成する。パブリックサブネットを作成する 3 プライベートサブネットを作成する 4 EC2インスタンスを作成する 5 RDSを作成する 6 DockerコンテナをAWSにアップロードする プライベートサブネットを作成します。
実は後ほど、理由は説明するのですがプライベートサブネットは異なるアベイラビリティーゾーンで２つ作る必要がありあります。
アベイラビリティーゾーンとは、ざっくりいうとクラウドが保管されているサーバーが実際に置かれている地域です。よって下記のような構成を作ります。
一つ目のプライベートサブネット作成します。
AWSコンソールからVPCダッシュボードに入り、サブネットを選択してサブネットを作成する。
VPC IDに先ほど作成したVPCを選択する。
アベイラビリティーゾーン：今回はap-northease-1a
名前 : fitO2_private_subnet_1a
IPv4 CIDR ブロック : 10.0.20.0/24
「サブネットを作成」をクリック
二つ目のプライベートサブネット作成します。
AWSコンソールからVPCダッシュボードに入り、サブネットを選択してサブネットを作成する。
VPC IDに先ほど作成したVPCを選択する。
アベイラビリティーゾーン：今回はap-northease-1c
名前 : fitO2_private_subnet_1c
IPv4 CIDR ブロック : 10.0.21.0/24
「サブネットを作成」をクリック
プライベートサブネット用のセキュリティーグループを作成する。
EC2ダッシュボードのセキュリティーグループをクリックして、「セキュリティーグループの作成」をクリックする。
「ルールの追加」をクリックします。
セキュリティーグループ名 : fitO2_db_SG
VPC : 先ほど作成したVPC
インバウンド ：
タイプ : MYSQL/Aurora
ポート : 3306
ソース :
カスタム
パブリックサブネットに置かれたEC２インスタンスに適用する予定の（先ほど作った）セキュリティーグループを指定。（名前を打ち込んだら出てくる。出てこなければグループIDをコピペ）これで、プライベートサブネット2つと、それに適用させる予定の下記の様なセキュリティーグループの作成が完了しました。
次回(4)へ続く
EC2インスタンスを作成する |
- 投稿日：2021-01-12T00:10:14+09:00
【Rails AWS Docker】既存Ruby on Rails + MySQLアプリをDockerで構築し、AWSにデプロイする(2)
ポートフォリをとして作ったRuby on RailsアプリをDockerコンテナ化し本番環境をAWSで構築するまでの道のりです。
ポートフォリオ自体はこちらとなります。
【ポートフォリオ】転職活動時に作成したポートフォリオの概要（テッ◯キャンプ）かなり苦しめられたので、どなたかのお役に立てれば。
タイトル 1 ローカル環境のRailsアプリをDockerコンテナ化 2 [AWSにVPCを作成する。パブリックサブネットを作成する] 3 プライベートサブネットを作成する 4 EC2インスタンスを作成する 5 RDSを作成する 6 DockerコンテナをAWSにアップロードする AWSにVPCを作成する。
VPCとは(ざっくり）
Virtual Private Cloud と呼ばれるものでAWS内に作成する仮想的なネットワーク網のことです。
まずは下記の様な構成のVPCとサブベットを作成します。
サブネットとは、VPC内でさらに区分されたネットワークのことです。
パブリックサブネットにアプリ本体。プライベートサブネットにデーターベースを置きます。
パブリックサブネットは、外部からのアクセスを許可する設定します。
プライベートサブネットは、外部からのアクセスを許可せず、パブリックサブネットからのアクセスのみを許可します。（データーベースは外部からアクセスする必要はないのでセキュリティー向上のため）なお、「パブリックサブネット」「プライベートサブネット」という設定自体はなく、後ほど設定するセキュリティーグループにおいて、上記のようなネットワークのアクセス制限を設定していきます。
vpcのプライベートIPアドレスは、サイダー表記が16ビットなので、先頭から１６ビット分つまり、10.0が、ネットワーク部となります。
パブリックサブネット、プライベートサブネット共にプライベートアドレスは10.0.から始まっているので、VPC内のネットワークにあります。
また、パブリックサブネットのサイダー表記は/24なので24ビット分、つまり10.0.10.までがネットワーク部。
プライベートサブネットのサイダー表記も/24なので24ビット分、つまり10.0.20.までがネットワーク部であり、
パブリックサブネットとプライベートサブネットは異なるネットワーク空間となります。
VPCの作成
AWSにログインして、VPCダッシュボードに入り、VPCを作成する。
名前 ： VPCの名前任意
IPv4 CIDR ブロック : VPC用のプライベートIPアドレス(今回は10.0.0.0/16)
「VPCを作成」をクリック
パブリックサブネット作成
AWSコンソールからVPCにVPCに入り、サブネットを選択してサブネットを作成する。
VPC IDに先ほど作成したVPCを選択する。
アベイラビリティーゾーン：今回はap-northease-1a
名前:fitO2_public_subnet_1a
IPv4 CIDR ブロック : 10.0.10.0/24
「サブネットを作成」をクリック
パブリックサブネットのルーティングの作成
インターネットゲートウェイ(IGW)を作成し、VPCにアタッチします。
IGWとは、ざっくりいうとVPCとインタネットを繋ぐ窓口のようなものです。IGWを通じて、インターネットとVPC通信を行います。アタッチとは、作成したIGWをVPCと紐づける作業となります。
VPCコンソールから、「インタネットゲートウェイ」を選択、「インターネットゲートウェイの作成」をクリック。
名前を決めて、作成。一覧から作成したIGWを選択して、右上のアクションからVPCに「アタッチをクリック」
先ほど作成したVPCを選択して、「インターネットゲートウェイのアタッチ」をクリック
ルートテーブルを作成して、パブリックサブネットに紐付け
パブリックサブネット用のルーティングテーブルを作成します。
パブリックサブネットに来たアクセスのうち
10.0.0.0/16 が宛先のものはVPCに送ります。
10.0.10.0/24 が宛先のものはパブリックサブネット（自分自身）に送ります。
0.0.0.0/0 （上記以外全ての宛先）は、IGWに送ります。VPCコンソールから、「ルートテーブル」を選択し、「ルートテーブルの作成」をクリックして、名前を決めてVPCに先ほど作成したVPCを選択します。
一覧から作成した、ルーティングを選択し、下部の「ルート」タブを確認すると、
送信先「10.0.0.0/16」のものが宛先（ターゲット）がVPC（local)となっていることが確認できます。
ルートテーブルは、必ず所属するVPCが必須であるためため、先ほど選択したVPCが紐付けられます。「サブネットの関連付け」タブをクリックし、「サブネットの関連付け編集」をクリックします。
パブリックサブネットを選択し、保存をクリックします。
IGWへのルートを作成する。
「ルートタブ」を選択し、「ルートの編集」をクリックする。
「ルートの追加」を選択して、「0.0.0.0/0」を選択する。
先ほど作成したIGWを選択する。「ルートの保存」をクリックする。
これで、パブリックサブネットに紐づくルーティングテーブルが作成されました。
作り方をまとめると、下記の様になります。
それぞれ作り方が異なるのでややこしいですが、やっていることは、宛先IPアドレスに対して、どこに通信を振り分けるかということです。
パブリックサブネット用のセキュリティーグループを作成する。
EC2ダッシュボードのセキュリティーグループをクリックして、「セキュリティーグループの作成」をクリックする。
「ルールの追加」をクリックします。
セキュリティーグループ名 : fitO2_SG
VPC: 先ほど作成したVPC
インバウンド：
上記図の様に作成これで、全てのアクセス元に対して、SSH通信（22番ポート)とhttp通信（80番ポート)を開放するセキュリティーグループが作成できました。後ほど、作るEC2インスタンスに、このセキュリティーグループを適用させる予定です。
(セキュリティーグループは後ほど、もうちょっと詳しく説明します。）次回(3)へ続く
プライベートサブネットを作成する
- 投稿日：2021-01-12T00:09:41+09:00
【Rails AWS Docker】既存Ruby on Rails + MySQLアプリをDockerで構築し、AWSにデプロイする(１)
ポートフォリをとして作ったRuby on RailsアプリをDockerコンテナ化し本番環境をAWSで構築するまでの道のりです。
ポートフォリオ自体はこちらとなります。
【ポートフォリオ】転職活動時に作成したポートフォリオの概要（テッ◯キャンプ）かなり苦しめられたので、どなたかのお役に立てれば。
タイトル 1 ローカル環境のRailsアプリをDockerコンテナ化 参考にさせていただいた記事は、(6)の末尾い記載しています。
ローカル環境のRailsアプリをDockerコンテナ化
Dockerコンテナ環境構成（ローカル版）
構成は上記です。
webサーバーとしてnginxを配置します。
appサーバーはpumaを設置します。まず既存のRailsアプリをコンテナ化します。
前提
AWSにアカウント作成済
docker hubにアカウント作成済
docker インストール済
ローカル環境で動作するRailsアプリ構築
※fitO2の部分は、ご自身のアプリ名に変更してください。
現状のアプリのフォルダ構成に、下記のファイルを追加します。
docker-compose.yml Dockerfile nginx_docker ├── Dockerfile └── nginx.conf config └── puma.rbdocker-compose.ymlversion: '3' services: app: build: context: . command: bundle exec puma -C config/puma.rb volumes: - .:/fitO2 - public-data:/fitO2/public - tmp-data:/fitO2/tmp - log-data:/fitO2/log networks: - fitO2-network depends_on: - db db: image: mysql:5.7 environment: MYSQL_ROOT_PASSWORD: password MYSQL_USER: user MYSQL_PASSWORD: password MYSQL_DATABASE: fitO2_development volumes: - db-data:/var/lib/mysql networks: - fitO2-network web: build: context: ./nginx_docker volumes: - public-data:/fitO2/public - tmp-data:/fitO2/tmp ports: - 80:80 depends_on: - app networks: - fitO2-network volumes: public-data: tmp-data: log-data: db-data: networks: fitO2-network: external: true簡単な説明
dbコンテナ
image でdockerhubからmysql:5.7をプルします。
ports でホスト側の3306とコンテナ側の3306ポートを接続します。
networks でappコンテナ側と共通のネットワークfitO2-networkを利用します。appコンテナ
build でDockerfileのディレクトリ（コンテキスト）を指定して、Dockerfileからコンテナを作成します。
volumes で、ホスト側のdocker-compose.ymlが存在しているディレクトリと、コンテナ側の/fitO2をマウント（共通化）しています。
command で設定ファイルを指定してpuma（アプリケーションサーバー）を立ち上げています。
ports でホスト側の3000とコンテナ側の3000ポートを接続します。
depends_on でappコンテナが生成されてから、実行されるように指定しています。
networks でdbコンテナ側と共通のネットワークfitO2-networkを利用します。webコンテナ
build で./nginx_dockerがあるディレクトリ（コンテキスト）を指定して、Dockerfileからコンテナを作成します。
depends_on でappコンテナが生成されてから、実行されるように指定しています。networks でfitO2-networkを設定しています。
fitO2/Dockerfile.FROM ruby:2.5.1 RUN apt-get update -qq && \ apt-get install -y build-essential \ nodejs\ mysql-server\ mysql-client WORKDIR /fitO2 COPY Gemfile /fitO2/Gemfile COPY Gemfile.lock /fitO2/Gemfile.lock RUN gem install bundler RUN bundle install RUN mkdir -p tmp/sockets簡単な説明
FROM でruby:2.5.1 イメージをdocker hubからインストールします。
1回目のRUN で、必要なパッケージをインストールしています。
WORKDIR で作業ディレクトリを/fitO2に設定しています。
COPYで ホスト側のgemfileとgemfile.lockをコンテナの/fitOディレクトリにコピーしています。
2回目のRUN でbundlerをインストールします。
3回目のRUN でgemfileからパッケージをインストールします。
4回目のRUN ソケットファイルを作成しています。fitO2/nginx_docker/Dockerfile.FROM nginx:1.15.8 RUN rm -f /etc/nginx/conf.d/* ADD nginx.conf /etc/nginx/conf.d/fitO2.conf # ビルド完了後にNginxを起動 CMD /usr/sbin/nginx -g 'daemon off;' -c /etc/nginx/nginx.conf簡単な説明
FROM でnginx:1.15.8 イメージをdocker hubからインストールします。
RUN でインクルード用のディレクトリ内を削除してます。
ADD でNginxの設定ファイルをコンテナにコピーしてます。
CMD でビルド完了後にNginxを起動するようにしてます。fitO2/nginx_docker/nginx.confupstream fitO2 { server unix:///fitO2/tmp/sockets/puma.sock; } server { listen 80; # =========ローカルと本番切り替え=========== # server_name ◯◯◯.◯◯◯.◯◯◯.◯◯◯; server_name localhost; # ====================================== access_log /var/log/nginx/access.log; error_log /var/log/nginx/error.log; root /fitO2/public; client_max_body_size 100m; error_page 404 /404.html; error_page 505 502 503 504 /500.html; try_files $uri/index.html $uri @fitO2; keepalive_timeout 5; location @fitO2 { proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $http_host; proxy_pass http://fitO2; } }nginxの設定ファイルです。
ローカル環境の場合は、server_name をlocalhostにします。config/puma.rbthreads_count = ENV.fetch("RAILS_MAX_THREADS") { 5 }.to_i threads threads_count, threads_count port ENV.fetch("PORT") { 3000 } environment ENV.fetch("RAILS_ENV") { "development" } plugin :tmp_restart app_root = File.expand_path("../..", __FILE__) bind "unix://#{app_root}/tmp/sockets/puma.sock" stdout_redirect "#{app_root}/log/puma.stdout.log", "#{app_root}/log/puma.stderr.log", truepumaの設定ファイルです。
bind "unix://#{app_root}/tmp/sockets/puma.sock"の部分は、nginx.confのserverと一致するようにしなければなりません。参考
config/database.ymldefault: &default adapter: mysql2 encoding: utf8 pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %> # PasswordとUsernameはdocker-compose.ymlと合わせます username: root password: password host: db development: <<: *default database: fitO2_development test: <<: *default database: fitO2_testコンテナ作成、起動
アプリのディレクトリに移動します。
コンテナを作成します。
docker-compose buildネットワークを作成します。
docker network create fitO2-networkコンテナを起動します。
docker-compose up初回はデーターベースの初期化を行います。
ターミナルを別タブで開き、アプリ直下に移動して下記コマンドをうちます。docker-compose exec app rails db:create docker-compose exec app rails db:migrate docker-compose exec app rails db:seed (シーダーがなければ不要)うまくいかなかった場合、試行錯誤した場合は中途半端にシーダーが入ってしまって、バリデーションの関係で弾かれる場合があるので、一度下記の様にデーターベースを削除してから再度上記コマンドを実行してください。
docker-compose exec app rails db:dropにアクセスすると、サイトにアクセスすることができます。
エラーがー生じた際は、docker-compose upターミナルにログが出ていますので、確認してください。
とりあえず既存のアプリをDockerコンテナ化できました。
次回(2)へ続く
[AWSにVPCを作成する。パブリックサブネットを作成する。]
- 投稿日：2021-01-12T00:09:41+09:00
【Rails AWS Docker】既存Ruby on Rails + MySQLアプリをDockerで構築し、AWSにデプロイする(1)
ポートフォリをとして作ったRuby on RailsアプリをDockerコンテナ化し本番環境をAWSで構築するまでの道のりです。
ポートフォリオ自体はこちらとなります。
【ポートフォリオ】転職活動時に作成したポートフォリオの概要（テッ◯キャンプ）かなり苦しめられたので、どなたかのお役に立てれば。
タイトル 1 ローカル環境のRailsアプリをDockerコンテナ化 2 AWSにVPCを作成する。パブリックサブネットを作成する 3 プライベートサブネットを作成する 4 EC2インスタンスを作成する 5 RDSを作成する 6 DockerコンテナをAWSにアップロードする 参考にさせていただいた記事は、(6)の末尾に記載しています。
ローカル環境のRailsアプリをDockerコンテナ化
Dockerコンテナ環境構成（ローカル版）
構成は上記です。
webサーバーとしてnginxを配置します。
appサーバーはpumaを設置します。まず既存のRailsアプリをコンテナ化します。
前提
AWSにアカウント作成済
docker hubにアカウント作成済
docker インストール済
ローカル環境で動作するRailsアプリ構築
※fitO2の部分は、ご自身のアプリ名に変更してください。
現状のアプリのフォルダ構成に、下記のファイルを追加します。
docker-compose.yml Dockerfile nginx_docker ├── Dockerfile └── nginx.conf config └── puma.rbdocker-compose.ymlversion: '3' services: app: build: context: . command: bundle exec puma -C config/puma.rb volumes: - .:/fitO2 - public-data:/fitO2/public - tmp-data:/fitO2/tmp - log-data:/fitO2/log networks: - fitO2-network depends_on: - db db: image: mysql:5.7 environment: MYSQL_ROOT_PASSWORD: password MYSQL_USER: user MYSQL_PASSWORD: password MYSQL_DATABASE: fitO2_development volumes: - db-data:/var/lib/mysql networks: - fitO2-network web: build: context: ./nginx_docker volumes: - public-data:/fitO2/public - tmp-data:/fitO2/tmp ports: - 80:80 depends_on: - app networks: - fitO2-network volumes: public-data: tmp-data: log-data: db-data: networks: fitO2-network: external: true簡単な説明
dbコンテナ
image でdockerhubからmysql:5.7をプルします。
ports でホスト側の3306とコンテナ側の3306ポートを接続します。
networks でappコンテナ側と共通のネットワークfitO2-networkを利用します。appコンテナ
build でDockerfileのディレクトリ（コンテキスト）を指定して、Dockerfileからコンテナを作成します。
volumes で、ホスト側のdocker-compose.ymlが存在しているディレクトリと、コンテナ側の/fitO2をマウント（共通化）しています。
command で設定ファイルを指定してpuma（アプリケーションサーバー）を立ち上げています。
ports でホスト側の3000とコンテナ側の3000ポートを接続します。
depends_on でappコンテナが生成されてから、実行されるように指定しています。
networks でdbコンテナ側と共通のネットワークfitO2-networkを利用します。webコンテナ
build で./nginx_dockerがあるディレクトリ（コンテキスト）を指定して、Dockerfileからコンテナを作成します。
depends_on でappコンテナが生成されてから、実行されるように指定しています。networks でfitO2-networkを設定しています。
fitO2/Dockerfile.FROM ruby:2.5.1 RUN apt-get update -qq && \ apt-get install -y build-essential \ nodejs\ mysql-server\ mysql-client WORKDIR /fitO2 COPY Gemfile /fitO2/Gemfile COPY Gemfile.lock /fitO2/Gemfile.lock RUN gem install bundler RUN bundle install RUN mkdir -p tmp/sockets簡単な説明
FROM でruby:2.5.1 イメージをdocker hubからインストールします。
1回目のRUN で、必要なパッケージをインストールしています。
WORKDIR で作業ディレクトリを/fitO2に設定しています。
COPYで ホスト側のgemfileとgemfile.lockをコンテナの/fitOディレクトリにコピーしています。
2回目のRUN でbundlerをインストールします。
3回目のRUN でgemfileからパッケージをインストールします。
4回目のRUN ソケットファイルを作成しています。fitO2/nginx_docker/Dockerfile.FROM nginx:1.15.8 RUN rm -f /etc/nginx/conf.d/* ADD nginx.conf /etc/nginx/conf.d/fitO2.conf # ビルド完了後にNginxを起動 CMD /usr/sbin/nginx -g 'daemon off;' -c /etc/nginx/nginx.conf簡単な説明
FROM でnginx:1.15.8 イメージをdocker hubからインストールします。
RUN でインクルード用のディレクトリ内を削除してます。
ADD でNginxの設定ファイルをコンテナにコピーしてます。
CMD でビルド完了後にNginxを起動するようにしてます。fitO2/nginx_docker/nginx.confupstream fitO2 { server unix:///fitO2/tmp/sockets/puma.sock; } server { listen 80; # =========ローカルと本番切り替え=========== # server_name ◯◯◯.◯◯◯.◯◯◯.◯◯◯; server_name localhost; # ====================================== access_log /var/log/nginx/access.log; error_log /var/log/nginx/error.log; root /fitO2/public; client_max_body_size 100m; error_page 404 /404.html; error_page 505 502 503 504 /500.html; try_files $uri/index.html $uri @fitO2; keepalive_timeout 5; location @fitO2 { proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $http_host; proxy_pass http://fitO2; } }nginxの設定ファイルです。
ローカル環境の場合は、server_name をlocalhostにします。config/puma.rbthreads_count = ENV.fetch("RAILS_MAX_THREADS") { 5 }.to_i threads threads_count, threads_count port ENV.fetch("PORT") { 3000 } environment ENV.fetch("RAILS_ENV") { "development" } plugin :tmp_restart app_root = File.expand_path("../..", __FILE__) bind "unix://#{app_root}/tmp/sockets/puma.sock" stdout_redirect "#{app_root}/log/puma.stdout.log", "#{app_root}/log/puma.stderr.log", truepumaの設定ファイルです。
bind "unix://#{app_root}/tmp/sockets/puma.sock"の部分は、nginx.confのserverと一致するようにしなければなりません。参考
config/database.ymldefault: &default adapter: mysql2 encoding: utf8 pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %> # PasswordとUsernameはdocker-compose.ymlと合わせます username: root password: password host: db development: <<: *default database: fitO2_development test: <<: *default database: fitO2_testコンテナ作成、起動
アプリのディレクトリに移動します。
コンテナを作成します。
docker-compose buildネットワークを作成します。
docker network create fitO2-networkコンテナを起動します。
docker-compose up初回はデーターベースの初期化を行います。
ターミナルを別タブで開き、アプリ直下に移動して下記コマンドをうちます。docker-compose exec app rails db:create docker-compose exec app rails db:migrate docker-compose exec app rails db:seed (シーダーがなければ不要)うまくいかなかった場合、試行錯誤した場合は中途半端にシーダーが入ってしまって、バリデーションの関係で弾かれる場合があるので、一度下記の様にデーターベースを削除してから再度上記コマンドを実行してください。
docker-compose exec app rails db:dropにアクセスすると、サイトにアクセスすることができます。
エラーがー生じた際は、docker-compose upターミナルにログが出ていますので、確認してください。
とりあえず既存のアプリをDockerコンテナ化できました。
次回(2)へ続く
AWSにVPCを作成する。パブリックサブネットを作成する。
- 投稿日：2021-01-12T00:00:43+09:00
EC2にsshで接続しよー、あ、俺のIPアドレス前と違うわ
家のルーター再起動したらssh通信できなくて焦った人です
そのままですね
前提として前までEC2にssh通信できてたよって人向けですその後EC2のマネージメントコンソールに飛んで、セキュリティグループを確認
使用してるセキュリティグループのインバウンドルールに
タイプSSHの行のソースを確認
ここにさっき確認した自分のIPアドレスがなければルールを編集して追加or置換
そのあといつも通りコンソールからssh通信を試すと通りますー