たくさんの自由帳
Androidのお話
たくさんの自由帳
投稿日 : | 0 日前
文字数(だいたい) : 15627
目次
本題
ほかを探す
AWS
AWS で静的サイトホスティングするには
CloudFront + S3 も二通りある
S3 の静的ホスティング機能を使う
S3 の静的ホスティング機能を使わない
つくる!!
ながれ
S3 のバケットを作る
S3 にファイルを置く
CloudFront のディストリビューションを作る
カスタムドメインと HTTPS 化
DNS のレコードを追加する
CloudFront Functions を書く
GitHub Actions で S3 へアップロードし、CloudFront のキャッシュを消す
AWS 側
GitHub 側
デプロイ結果
エラー時の代わりのページの設定
ところで
DNS の向き先をホスティングサービスから CloudFront に直す
おわり!!!
ソースコード
速度
お金がかかるポイント?
おわりに
おわりに2
おわりに3 2023/12/26 追記
どうもこんにちは。
コイバナ恋愛 攻略しました。めっちゃおもろかったです
特に共通ルート面白い!!男友達とバカやってるのがいい。
髪下ろしてるのかわいい
個別みじかい!!!ただでさえ短い個別がサブカプに取られてて更に短くなってる気がする;;
(でもサブカプの話も面白かった)
(ところでこの手の途中下車パターン(?)ってセーブして先に共通全部見るのがいいのかな、どうなんだろう)
おすすめです!
このブログは Netlify
にあるわけですが、読み込みが遅い・・・
原因は日本にはCDN
が無いらしく?(今もなはず?2020年から速度変わってない気がするんだよな)、日本からアクセスだとちょっと遅い。
個人の感想 + 昔使ったことがあるとかで今は知らない ので参考にしてはいけない。
静的ファイルホスティングなので、SSR
とかしたい場合知らないです
APEX
ドメイン使いたい場合はドメインのCDN
をCloudflare DNS
にしないといけないぐらいしか欠点がなさそう感Next.js
作ってる会社
Next.js
の一部の機能(next/image
とか)はVercel
かレンタルサーバーで Node.js を動かす
のどっちかが必要だったはずで、Netlify
のノリでNext.js
全部の機能を使いたければこれが良さそう
index.html
が入ってるフォルダをドラッグアンドドロップすればデプロイ出来る機能とかが便利だった
Cloudflare Pages
にもある(小声)/docs
にするか、ルートに置くかFirebase
のプロジェクト作るのアレじゃない・・・
FCM
とか使ってるならいいんじゃない?CLI
経由でデプロイした気がするけど、いまもCLI
経由しか無いんですかね?こんなかんじ(めっちゃ個人的というか偏ってるな)
うーんCloudflare Pages
かなあ
そういえばお一人様 Misskey
のためにAWS
のLightsail や S3
を使っているわけですが
すでにAWS
使ってるならこのサイトもAWS
に乗せていいのでは・・!
料金もお一人様を動かす費用から見たらたいしたことないはず。。です
(後なんかAWS
で動かしてるのなんかかっこいいじゃん)
二択あるらしい
前者のAmplify
だと、CI/CD
機能が標準であったりして簡単に倒していそう、
ただ、転送量の無料枠、CloudFront
よりも低く設定し過ぎじゃない・・・?
後者のCloudFront + S3
を使う方法だと、2つのサービス(正確にはもうちょっとある)を使う必要がある、CI/CD
を自前で用意する必要がある
が、GitHub Actions
すでにあるし、何と言っても無料枠もCloudFront
のほうがあるのでこっちで!
参考にしました:https://dev.classmethod.jp/articles/s3-cloudfront-static-site-design-patterns-2022/
どっちも一長一短で、難しい
S3
の静的サイトホスティング機能を有効にして、CloudFront
を経由してアクセスするようにする
S3
単体だとhttps
に出来ないので、CloudFront
を噛ますようにします、他にもキャッシュしてくれるのでS3
の静的サイトホスティングは利用しないで、CloudFront
からリクエストが来たらS3
から取り出す
CloudFront Functions
を利用する必要があります前者のS3 静的サイトホスティング
の方法が簡単ですが、アクセスをCloudFront
限定にすることが出来ません。
S3
の静的サイトホスティング用のURLがバレた(あるのかな・・)場合、S3
にアクセスできてしまいます。
(CloudFront
を噛ますことでキャッシュを返してくれて、S3へのアクセス料金
が安くなるのですが、S3
に直接アクセスされると料金が安くならない!)
後者はS3
からとってくるのはCloudFront
しか出来ないので、アクセスをCloudFront
だけに出来ます。
一方、S3の静的サイトホスティング
機能の一つに、インデックスドキュメント機能というのが存在し、これは/
や/about
等にアクセスが来た際に自動的にindex.html
をレスポンスとして返してくれるのですが、
この機能はCloudFront
にはなく、/about
にアクセスされてしまった場合403? 404?
になってしまいます。
何もしない場合は/about.html
や/about/index.html
みたく、index.html
までURLを書かないと正しく表示できません。
この解決のためにCloudFront Functions
という、リクエストが来た際にindex.html
をURLに足すようなJavaScript
コードを書くことで実現出来ます。
JavaScript
を書くと言っても、既にサンプルがあるのでこれをコピーするだけだと思います。
https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/example-function-add-index.html
CloudFront Functions
は一ヶ月200万
リクエストまでは無料で出来るので、多分この規模なら超えることはない・・・ハズ?
でどっちを使うかなんですが、後者
を試してみようと思います。
直接アクセスはやっぱされたくないかなー・・・
大体これとおなじ
https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/HostingWebsiteOnS3Setup.html
S3
のバケットを作るS3
にファイルを置く
CloudFront
のディストリビューションを作る
OAC
でS3
をオリジンとして利用できるようにCloudFront
でドメインとHTTPS
化を行うCloudFront Functions
を書くGitHub Actions
でgit push
時にS3
にアップロードとCloudFront
のキャッシュクリアCloudFront
にする(CNAME
の値をCloudFront
にして、リクエストがCloudFront
に向くようにする)S3
のバケットを作ります、名前はおまかせします。
東京リージョンでいいはずですが、CloudFront
を経由させるので本当に金払いたくなければ安いところでいいんじゃね?知らんけど
その他の設定は変えずに、作ります!
が、この時点でNext.js
のSSG
をして公開するファイルを生成するのは面倒なので、適当に確認用のindex.html
を書いてアップロードします
ところでVSCode
で!
を書いた後にエンターを押すとhtml
のひな形みたいなのが出てくるんですけど、これVSCode
の標準機能なんですかね?
S3
の画面へドラッグアンドドロップすればアップロード出来ます
さんこう:https://repost.aws/ja/knowledge-center/cloudfront-serve-static-website
CloudFront
に移動して、ディストリビューションを作成
を押します
オリジンはさっき作ったS3
のバケットを選びます。
ドロップダウンメニューで選べるので入力しなくて済むはず
次はオリジンアクセス
、これはOrigin access control settings (recommended)
を選び、
コントロール設定を作成
を押して作成画面を開きます
多分デフォルトで作成すればいいはず、説明とかはおまかせします。
この警告はディストリビューション作成後に対応するので一旦飛ばします。
次はWAF
ですが、よくわからないので無効にしておきました。
これで作成を行います!
そしたら上の方に案内が出ているので、ポリシーをコピー
してS3 バケット~
のリンクを開きます。
そしたら、バケットポリシー
の項目までスクロールして、編集
を押します
エディターが表示されるので、さっきコピーした内容を貼り付けて変更の保存
を押します。
そしたらCloudFront
に戻ってきてください。アクセスできるか確認します
ディストリビューションドメイン名
をコピーして、後ろに/index.html
をつけてリクエストしてみます。
どうでしょう?index.html
が表示されましたか?
ちょっとそれますがCloudFront
から帰ってきた場合、CloudFront
側のキャッシュが帰ってきたのか、キャッシュもなくS3
からとってきたのかはレスポンスヘッダーから見ることが出来ます。
一回目はMiss from cloudfront
、二回目以降はHit from cloudfront
が帰ってくるはず。
既にhttps
ですが、カスタムドメインを設定する際にhttps
周りの作業が必要なので・・
さんこう:https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html
CloudFront
のディストリビューションを開いて、編集
を押します。
代替ドメイン名という項目があるので、項目を追加
を押します
はい
これで変更を保存
しようとすると、、、出来ません。
カスタム SSL 証明書 - オプション
の項目もやらないといけないようです。
というわけでスクロールして戻って、証明書をリクエスト
を押します
AWS Certificate Manager (ACM)
が開くはず、
CloudFront
で使う証明書はリージョンがバージニア北部
である必要があるのでちゃんと確認しましょう。
パブリック証明書をリクエスト
で次へ
完全修飾ドメイン名
はhttps://こ↑こ↓/index.html
の部分です、FQDN
とかかっこいい名前がついてる
サブドメインじゃない場合はどうなんだろう・・・
検証方法はDNS
でいいはず
その他の項目はそのままにして、リクエスト
を押します
すると上の方に、追加のアクションが必要ですみたいなのが出てくるので、証明書を表示
を押します。
ちょっとスクロールすると、ドメイン
の項目でCNAME 名
、CNAME 値
が表示されているはず。
この値を使ってドメインを持っていることを証明します。
私はドメインのDNS
にCloudflare DNS
を使っています。
が、別に特別なことはしてないので操作は大体同じだと思います。
Cloudflare
にログインした後、ドメイン名を押してDNS
を開いて、レコードを追加する画面を出します。
タイプはCNAME
にして、名前にはCNAME 名
、値にはCNAME 値
をそれぞれ入れます。
入力の際に一番最後の.
が消えちゃいますが特に問題なかったです。
Cloudflare
の場合は追加でProxy
するか選べますが、別にユーザー公開するやつじゃないのでProxy
するまでもないはずなのでチェックを外してDNS Only
にします。
あとはAWS
側で証明が終わるまで待ちます。
終わるとこんな感じにチェックマークが付きます
あとはCloudFront
のディストリビューション設定に戻って、さっき作った証明書を設定します。
これでようやく設定が変更できました。
あ、あとリージョンを元の(多分?東京)に戻しておいてね、多分戻ってると思うけど
こうすることで、https://takusan.negitoro.dev/index.html
みたいなURLを
https://takusan.negitoro.dev/
みたいにindex.html
省略してリクエストできるようにします。
↓ 以下現状
CloudFront
から関数
を選び、関数を作成
を押します。
いい感じの名前をつけます、説明はお任せ
JavaScript
のコードは以下のものを使うことにします。
https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/example-function-add-index.html
書いたら変更の保存
して、
発行
を押します
そしたら関連付けを追加
を押して
埋めます。
CloudFront
を選ぶViewer request
を選ぶdefault
?関連付けを追加
を押します。
なんか時間かかってるけど待ちます
成功していれば、index.html
無しで開けるようになっているはずです!
さんこう:https://zenn.dev/kou_pg_0131/articles/gh-actions-oidc-aws
さんこう:https://docs.github.com/ja/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services
さて、二日目に突入しました、がんばります
GitHub Actions
にビルドしてもらって成果物をS3
にアップロードして、CloudFront
が持っているキャッシュを消す作業をしてもらいます。
調べてみるとOpenID Connect
のほうがいいらしいので、今回はアクセスキーじゃなくてこっちを使ってみる。
アクセスキーだとGitHub
へ機密情報(アクセスキー)を登録しないといけないのに対し、OpenID Connect (OIDC)
だとGitHub
へ機密情報を渡すこと無く同様のことが出来るらしい
まずはIAM
の管理画面へ進み、ID プロバイダ
を押して、プロバイダを追加を押す
そしたら以下の項目を埋めます
https://token.actions.githubusercontent.com
sts.amazonaws.com
埋めたらサムプリントを取得
を押します、押したらなんか出ます、、がそのままスクロールしてプロバイダを追加
を押して閉じます
完了したら、上の方にIAM ロール
を追加しろと出るので、追加します。
ロールの割り当て
を押しましょう
新しいロールの作成
、でいいはず
ラジオボタンはウェブアイデンティティ
を選びます。
以下を埋めます(各自違うはず)
ブランチも制限出来るらしいですがとりあえずこれで。
次は許可する権限を設定する画面です。
多分独自のポリシーを作らないといけないはず・・(読み取り権限を指定したS3 バケット
に付与、みたいな)
がとりあえず今回はAmazonS3FullAccess
とCloudFrontFullAccess
を付けました、多分指定したリソース(S3バケット
、CloudFront ディストリビューション
)だけにアクセスできるようにするのがお作法な気がする
そしたら次へ進み、名前と説明をいい感じに入れてロールを作成
を押します
これで完了。次はGitHub Actions
を書いていきます。
まずは必要な値をGitHub
のシークレットに登録します!
アクセスキーは登録する必要がなくなりましたが、S3 のバケット名
とかCloudFrontのディストリビューション名
とかは隠さないといけないので・・・
GitHub
のリポジトリの設定画面から、Secrets and variables
を押して、Actions
を押す
New repository secret
を押して、追加画面を出します
シークレットに登録する値は以下の4つです。
(後述するGitHub Actions
のyml
をまるまるコピーする場合)
なまえ | あたい |
---|---|
AWS_ROLE | IAM ロールの ARN の値です。コピーしてね |
AWS_REGION | リージョンです、多分東京 ap-northeast-1 でいいはず? |
AWS_S3_BACKET | ビルド成果物を保存するS3 バケット の名前です |
AWS_CLOUDFRONT_DISTRIBUTION | CloudFront のディストリビューションIDです、ID の列に出てるやつ |
出来ました!
次はGitHub Actions
を書いていきます、
Actions
を開きます。既に一個あるので、ここから追加します
一個もない場合は多分こっちの画面が最初から出ると思う。
set up a workflow yourself
を選びます
そして以下のようなyml
を書きます。
ビルド成果物のフォルダが./out
じゃない場合は直してください。
s3 sync --delete
を使うとローカルとS3バケットの中身が一緒になるように同期してくれるそうです!すごい
CloudFront
のキャッシュも消します。/*
で一括削除です。キャッシュクリアは回数制限がありますが無料で出来ます。
(ワイルドカードを使うと無料でできる回数制限の枠を一つだけ消費した上で、複数のファイルに対してキャッシュクリア出来るのでお得!)
https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/Invalidation.html#PayingForInvalidation
さて!待ちます。
無事一発で通りました、逆に心配で草
S3 のバケット
もみてみましたが、ちゃんと中身あります!
開いてみましたが、めっちゃ早い気がする!いや気がするじゃなくて実際早い!!!なにこれ!!!
CloudFront
まじ早くない?Next.js
ももちろん早いんだけど
このままだと存在しないURL
にアクセスされた際に、/404/index.html
ではなくAWS
側のエラー画面が出てしまいます。
というわけで、S3
にもなかった場合は404
ページをブラウザに返してあげるようにCloudFront
を設定します。
この構成(Amazon S3 + CloudFront
)で存在しないパスにアクセスすると、404
ではなく403
になります。
何でかはよく知りませんが、この辺がそう?
https://docs.aws.amazon.com/AmazonS3/latest/API/API_GetObject.html
話を戻して、エラー画面を返す方法ですが、
CloudFront
のディストリビューションを開いて、エラーページを開き、カスタムエラーレスポンス
を押します。
先述の通り、存在しない場合にS3
側は403
を返すので、HTTP エラーコード
は403
を選びます。
Next.js
の場合、trailingSlash: true
の場合は/404/index.html
、false
の場合は多分/404.html
で404 画面
に飛ばせるはず。
ステータスコードは404
で返しておきます。
しばらく待ちます
これで、エラーページが返ってくるようになりました。
私も勘違いしてましたが、これはリダイレクトではなく、エラー内容をCloudFront
側で変更しているだけなので、ブラウザのアドレス欄はそのままになります。
まずCloudFront
のディストリビューションを開いてディストリビューションドメイン名
をコピーします
そのあと、使ってるドメインのDNS
の管理画面で、向き先を変えます(新規サイトの場合は追加します)
CNAME
で、名前
は使いたいサブドメインを入れて(APEX
ドメインは知らない)、値にはさっきのディストリビューションドメイン名
を入れます
後は暫く待つと、サブドメインでアクセスできるようになってるはずです。
https
なのでちゃんと鍵マークも付いてるはず!
ながい!!!お疲れ様です・・・
参考にした記事ありがとうございます
GitHub Actions
のワークフローだけあったところでではありますが、、一応置いておきます
https://github.com/takusan23/ziyuutyou-next/blob/main/.github/workflows/aws-deploy.yml
早くなってる!
CloudFront
Netlify
S3 - CloudFront
の間のリクエスト回数
CloudFront
が間に入ってキャッシュするのでそこまでで
GET
リクエストは他と比べれば高くないGitHub Actions
から S3
にアップロードする
AWS
に入ってくる通信は無料だけど、PUT
リクエストの課金はかかってしまう
CloudFront Functions
CloudFront
の転送量は1TB
まで無料なので超過はまず無いはず
CloudFront Functions
はリクエスト回数のたびに呼ばれるので、ちょっと心配かも
Next.js
はページ表示に複数のjs
ファイルをリクエストするので、1ページに複数回リクエストになってしまうくらい?
お金問題なければこれで行きたいかも。
しれーっと切り替わってるかもしれない。一応戻せるようにしばらくはNetlify
のGitHub Actions
も動かしとこうかな。
もう誰も読んでないと思うけど
冒頭のゲームの話なんですけど(本題関係ない)、デフォルトのフォントがモトヤマルベリ
で、なんかすごい懐かしい気分になった。丸い感じすき
というのもAndroid 4 ~ 5
の標準日本語フォントがモトヤマルベリだったんですよね、なんでもAOSP
のためにApache License
の元使えるようにしたとかなんとか
だた、Galaxy / Xperia / arrows / AQUOS Phone あたりは独自フォントのはずなので(めっちゃ頑張ればフォントだけでおおよそのメーカーが見分けられそう)、
Nexus 系列(まだ Nexus の頃)
を買わないと見る機会はなかったのかもしれない?
このゲームのreadme.txt
開いたらAOSP
のライセンス(Apache License 2.0
)あったけどもしかしてフォントのことだったのかな。
2023年 12月 から試しにCloudFront
からこのブログを配信しています。特に問題は無さそう感。