de:code 2019 Day1 #decode19
ASP.NET Core + Azure で支える熟成 3 年「私だけのポン酢」アーキテクチャ
登壇しました。
MicrosoftやAWSなどの大きなテックイベントに参加するようになって、いつかは話す側になれたいいなーと思っていたことが現実になりました。緊張しました・・・有償イベントや大規模カンファレンスでの登壇を初めての経験することができました。
ご参加いただいた皆様ありがとうございました。 そして、このような素晴らしい機会をいただき本当にありがとうございました。
資料等は公式から公開されるので今しばらくお待ちください。
準備など
資料が形になったのは登壇1週間前ぐらいだった気がします。それでもランスルーしては手直し。実際に声に出して練習するとスライドの荒がみえてきます。今回2人での登壇だったので、さらに話す内容・流れを整理しつつ、2人でランスルーしては手直し。。。資料についてもお忙し中でレビューを快諾していただき、ありがとうございました。
スピーカー向けのトレーニングはとても参考になりました。トレーニングを受けたことで話す内容の骨格がイメージができました。
他にもde:code登壇のお話を頂く前に参加していた、福岡初開催のエバンジェリスト養成講座にも参加できていたのは、このフラグだったのかもしれません。すこしはテクニック実践できていたかな?
最後に
セッション後に色々な方から「よかったよ」とお声がけいただきうれしかった。一緒に登壇した松村さん、同僚のみんなありがとう!
明日は聞く側としてde:code Day2を楽しみます!
ちょっとだけ宣伝
6/6に弊社の報告会があるのでなにかお話する予定です。他の参加メンバーによるレポもあります。
ご都合つけばご参加ください。
PS
このブログ書いているときに見つけました。もっと早く見つけたかった(
Microsoft Tech Summit 2018 Day3 #mstsjp18
Day3最終日です。
これから始めるコンテナーの基本と始め方 #CI03
最終日はコンテナーセッションからスタート。
- 分散システム設計の本が無料で読める
- ACRのいいところは複数リージョンに単一レジストリで管理できる
- AKSの事例はIgniteで公開されているので見るいいよ
- AKSのサイトは熱い。アーキテクチャについてものってる。
- コンテナーするのに一番のおすすめはWeb App for Container
- Web App for Containerで足りないならマネージド率が高いものから選択する -> AKS
- ただしK8sは進化が早いのでついて行く覚悟があるか
- さらにCNCF Landscapeにはこんなにコンテナー関係があるから大変だよ
- Web App for Container + Azure Repos + Azure Piplelineデモ
- Azure Cloud Shellはブラウザ内で黒い画面がつかえてエディタもつかえる
- VS Code拡張機能でVS CodeからCloud Shellを呼び出せる
- Igniteのコンテナー関係動画を99個全部見て、その中から見るべき動画を厳選しました! (資料公開後に確認する)
- コンテナー技術は海外ではスタンダードなもの。まずはアプリケーションの近代化から始め、必要性を考えて複雑なものへ(Web App for Container -> AKS)
Azureにおけるコンテナー&サーバーレステクノロジの選択肢と選定ポイント #AD08
Azureにおけるコンテナーサービスの使いどころとアプリケションモダナイズ事例の2本立て。冒頭の宣言通りスライド多く内容盛りだくさんでした。
- Legacy Apps -> Internet Apps -> Cloud Appsに時代にあわせて、アプリもモノリスからマイクロサービスへ
- コンテナー、サーバーレス、マイクロサービスはクラウドネイティブを支える技術
- 分散アーキテクチャで必要になってくるのがオーケストレーション。CaaS
- K8sになり標準化でうまれてくるエコシステム
- コンテナーでやるのかFaaSなのか、IaaSでいくかを考える前に、まずは提供したい価値と優先度を明確化する
- クラウドを最大限利用するにはアプリシエイトのモダナイズ
- では選択したアーキテクチャがOverKill(必要以上に複雑になってないか)
- 複雑なアーキテクチャになると運用負荷が高まりNoOpsという考え方が必要となる
- PaaSやサーバーレスはそのリソースを使うことがNoOpsの思想を持っている
- ACSの利用は非推奨なので、DC/OSやSwarmを使いたい場合はマーケットプレイスからの利用を推奨
事例
- 当時はモダンだったアーキテクチャも機能追加、不具合対応、放置されたリファクタリング、複雑になった機能構成、自動テスト化、パフォーマンス懸念、セキュリティなど問題が。
- その分保守コストがかかる
- モダナイズプロジェクト発足して疎結合で複数チームがスピードを落とさず、最新技術を使えるようにしていく -> マイクロサービスが適してる
- まずはDBは変えずにアプリケーションの一部をモダナイズ化
- HackFestを実施した(きりん+マイクロソフト+オルターブース3社にて)
- HackFestでできたもの。Web App + AKS + OSBA + Azure Database for MySQL + Azure DevOps + ACR
日本企業のためのハイブリッドクラウドガイドライン #CI05
今日も美味しいランチを頂きながら。もぐもくしてたらすごい取り組みをされていた。
- クラウドを導入していくのに参考になるようなガイドラインを作成した
- ダウンロードできる
- 超大作!(100ページすげぇ)
- http://www.hccjp.org/hybridcloudguideline/
- ハイブリットクラウドコミュニティへ参加してAzure Stackを試そう!(準備中)
- 用意するAzure Stackで作ったリソースにはちゃんとPublicIPが付くよ
AKS管理のベストプラクティス #CI32
実際のAKS開発者とMonitor開発者の話が聞けるとかすごいですわ。試される英語力😇同時通訳さんありがとうありがとう。
- チーム環境や開発/ステージング/本番のクラスターの分け方パターン
- それぞれクラスターをわける(物理分離)
- もしくはネームスペースをわける(論理分離)
- どっちがいいわるいはない
- 物理ならクラスターを複数用意するのでコストが増えるし、論理分離はRBACやPodセキュリティが重要になる
- ベストは物理と論理の合わせ技
- デフォルトネームスペースは使わない。ネームスペースを指定しないのは事故の元
- リソースクオーターを設定するべし
- マルチリージョンクラスターはTraffig Managerでわける
- Ingress ControllerはNignxが一番よく使われている
- kube-adovisorを使うとKubernetesベストプラクティスに沿ってないデプロイを探せる
- VSCodeのK8s拡張機能
- ネットワーク
- アプリのセキュリティを確保するためにWAFが必要ならAppGWをいれる。
- つなぎ方はWAFを立ててVNET PeeringでAKS Internal LBへ
- 踏み台
WAFとBastionサーバーでネットワークセキュリティを高める #mstsjp18 #CI32 pic.twitter.com/Vvd7nB9KF9
— 92 (@morita92hiro) 2018年11月7日
- ノードのオートスケール
- Podのオートスケール
- AzureにはACIがある
- virtual kubelet
- ACI Connecterを使えばノードは不要
- virtual kubeletでノード0を実現したい。NoOpsが捗る!
- マルチークラスターの管理は最近Moniterが対応したよ(preview)
クラウドネイティブガバナンスの実現〜Azureガバナンスサービス概要〜 #CI30
ガバナンス機能この辺しっかりやっておかないと。Policy機能をうまく使えばリソース構築の手間が楽になりそうな予感。
- Azureガバナンスをまもるプラットフォーム
- Policy
- Blueprints
- Resource Graph
- Management Group
- Cost Management
- Buleprintsはポリシーを再定義可能な形で定義する
- Resouce Graphはコマンドでおこなう。利用にはAZコマンドのエクステンションが必要
- Resouce Graphはリソースの個数や状態をカウントしたりできる
- まずはドキュメントをみて第一歩を。
- ガバナンス機能はそんなに料金がかからないので試して欲しい。ただし本番では試さないで
インフラエンジニアエボリューション〜激変するITインフラ技術者像、キャリアとスキルを考える〜 #SP04
インフラエンジニアならハンカチなしでは聞けないセッション。エンジニアだけでなく人事の方、経営の方にも見て頂きたいな。HR界隈が騒がしくなりそうだけどw
- Tech Summit No.1のエモさ
- 歴史秘話ヒストリア「トール・マカベッチ」
- コンテナー(物理)のパワーワード
- Bashをいまさらとおもうことなかれ
- キャリア・スキル・働き方に悩んだら、すぐ見られる手元に置いておきたいバイブル
- 担当されたインフラ野郎、NoOpsの3セッションの集大成感
www.slideshare.net
コストと脅威を同時に削減!AzureリソースをAzure ADで効率的に守るためのノウハウ集 #CI01
Tech Summitの最後の〆はAzure ADへ。
- Security DevOpsはサブスクリプションを安全に保つ
- 安全である状態を維持する
- Azure ADによる認証と認可
- RBAC
- モニター
- ガバナンス
- 世界の中心にはAzure ADがある
- Azure ADの管理には2つの方向がある
- サブスクリプションを管理するAzure Resource Management
- アプリケーションサービスプロバイダー
- Azure SQL ServerはAzure AD管理下における。さらに条件付きアクセスで特定アプリ、デバイス、ネットワークを元に制限可
- SQL Database動的データマスク
- アプリをAzure ADに登録する -> ClientIDとClientSecretが払い出される -> 流出するのが怖い
- KeyVaultで管理するにはKeyVaultへのアクセスにAzure AD認可が必要で堂々巡り
- App Settingはよい方法だが運用的にどうか
- 人が介在しない仕組みが必要
- Managed Identity
- AWS IAM Roleと同じ感じ
- VMのManaged IDを有効にするとサービスプリンシパルとして登録されるのでRBACによる管理の対象となる
- Azure Instance Metadata Service (IMSD)
- Azure Functionも同じで特定の環境変数でとれるようになる
- Managed IDはシステム割り当てマネージドIDとユーザー割り当てマネージドIDの2つがあるが、現時点ではシステム割り当てがよい
- Azure AD認証をサポートしてない場合はAzure Resource Manager経由でアクセスして、アクセスキーをKeyVault管理しKeyVaultから取得するようにする
- CI/CDのライフサイクルにBuleprintsで強制ができる
- Managed IDやPolicy、BuleprintsはNoOpsの一つ
- https://azsk.azurewebsites.net
- https://docs.microsoft.com/ja-jp/azure/security/
- Managed IDのローカル環境とAzure環境でプロファイルなどで切り替える。ローカル環境もなにか謎技術でManaged ID出来るようになったらいいな
- ローカルでMSIを使う方法あるようです → Visual Studioで開発時にMSIを使う | ブチザッキ
- 複数台VMをManaged IDで管理したい場合はコマンドで行うか、Azure Policyを使うとよい
Appendex
The Illustrated Children's Guide to Kubernetes
- https://azure.microsoft.com/en-us/resources/videos/the-illustrated-children-s-guide-to-kubernetes/
- https://cdn.chrisshort.net/The-Illustrated-Childrens-Guide-to-Kubernetes.pdf
セッションもさることながら、いろいろな人に出会える現地にいくのは楽しいですね!
Azure定番システム設計・実装・運用ガイド オンプレミス資産をクラウド化するためのベストプラクティス (マイクロソフト関連書)
- 作者: 日本マイクロソフト株式会社
- 出版社/メーカー: 日経BP社
- 発売日: 2018/09/06
- メディア: 単行本
- この商品を含むブログ (1件) を見る
Microsoft Tech Summit 2018 Day2 #mstsjp18
Day1につづきDay2です。
詳細Azure ExpresRoute #CI27
Day2朝一はERのセッションへ。ER触る機会はそうないのでERのデモとかすごいレアなセッションでした。
- ERは専用回線ではなく閉域網の接続サービス
- Private PeeringはAzure VNETのプライベートIP、Microsoft PeeringはAzure/O365のパブリックIPへの通信。なのでどちらを使うかは選びましょう
- L2/L3プロバイダーの接続方法の違い
- MSEEとつなぐL2/L3はどちらがいい?
- 値段:L2<L3
- 運用コスト:L2>L3
- 接続の柔軟性:L2>L3
- L2プロバイダーであればAzure、プロバイダー、オンプレをすべて自分で設定できる
- L2プロバイダーの設定ができないなら、L3プロバイダーを選んでL3プロバイダー会社に設定を任せるという選択もあり(要件が満たせるなら)
- 繋がらないトラブルシュートはMSEEのルーティングテーブルをチェックしよう
- ER Directで40/100Gが選択可能に
- ER Global Reachで拠点間通信をAzureのグローバルネットワークを社内通信に利用できる
- 英語のメールが飛ぶとサポートへの電話が高まるw ブログを1日ぐらいの遅れぐらいで更新しているのでそちらをまずみる
Linuxユーザーが扱うAzure Resouce Manager Templateの活用方法 #AD09
ARMテンプレートガチ勢セッションへ。デモがすべて動画で用意さていて失敗が起きないように自動化されていました(さすが
- 自動化する前に効率化したい作業はフォーカスしているか?自動化の目的・目標が定量化されているかを確認しよう
- DevOpsにとって道具はあくまで組織・文化を支えるため。道具は道具
- デモファイル
- パラメータファイルの変数値が優先される
- ARMテンプレートのタイムアウトは40分。ロールバックはない。作業途中は再実行で増分デプロイされる。
- ARMテンプレートの読み方のこつはtypeでjqパーサーで全体を手っ取り早くつかむ
- ARMデプロイはtypeごと?にそれぞれのResource Poolに分かれて処理される
- ARMテンプレートの避ける書き方
- 不必要な関数が使われる
- 依存関係が多く、省略形が多い
- 使われてない残骸がのこっている
- YAML to JSON
- ARMテンプレートはJSONなのでYAML好きは変換するという選択しも
- https://github.com/TeamYARM/YARM-CLI
弊社のARMテンプレート活用事例として紹介してしていただきました。ありがとうございます。
事例紹介していただきました #mstsjp18 #AD09 pic.twitter.com/RdW9NwMWOu
— 92 (@morita92hiro) 2018年11月6日
Azure Durable FunctionsとAzure AD連携によるプロビジョニング自動化の実現 #CI36
美味しいランチを頂きながら。スポンサーセッションなので、てっきり製品紹介と思いきや、製品のアーキテクチャ詳細解説が始まり、これランチの片手間で聞けるレベルじゃないやつ(
もぐもぐしてたのでメモとれずでしたが、選択した技術それぞれについて、なぜそれを選択したのか、設計ポイント、つまずいたポイントが紹介されていました。
スポンサー資料も公開されるといいな。
企業内ネットワークでもAzure PaaSでビジネスをスピードアップ!〜今知っておくべきPaaSとVNETのイイ関係〜 #AD03
Azureの醍醐味はApp Serviceですよね。
- PaaSを使う理由「楽だから」w
- Azure PaaSはマルチテナント型(App Serivceなど)とVNETにデプロイできるサービス(Gatewayなど)の2種類
- Azure PaaSは新しいSDNでマルチテナント型とVNETのおいしいとこ取りで様変わりしていく
- App Serviceの送信元IPはスケールユニットで共通
- 新しいVNET統合によりサービスエンドポイントとの組み合わせでApp Service - VNET - PaaS(Azure DBやStorage)のプライベート通信の構成が可能になる。これは熱い
僕らのNoOps〜The Diversity of NoOps〜
念願のNoOps。第1回目は台風リスケで行けなかったのでほんと楽しみだった。ファシリテータの真壁さんと3賢人によるリレーセッションと質問タイム。質問タイムは登壇者には内緒だったみたいw。
- Opsで消耗している
- NoOpsは運用のうれしくないをなくす
- NoOpsの王道は守りのNoOps。監視通知の自動化、リトライの自動化、構成変更の自動化、方式の標準化、可視化
- NoOpsは人間のオペレーションを減らすこと
- オペミス削減の品質向上
- Toilを減らすチームになろう
- Toilを減らすプロダクトを作ろう
- それでも残るToil。知らなかったことなど2度目は起きないようにしよう
わい、質問へ壇上へあがる(
質問タイムで滅多にない機会だと思いきやまさか壇上へあがるとは思わんなだ((
- NoOpsをお客さんにどう理解してもらうか?
- イケてる構成を作ることもできるが、バランスも大事
- どんなにイケてる構成を導入がでもアーキテクチャを塩漬けせず変更し続けることを受け入れてもらうことが、大前提
- お客さんとの信頼関係を築く
- NoOpsエンジニアをどう育てていくか?
- 失敗してもいいから日頃からチャレンジしてもらう
- 失敗はマイナス評価ではない
うまく伝えきれない。動画公開されたら見直そう。機会を頂きありがとうございまいた(緊張しました)
デプロイ王子アンプラグド〜あなたのAzureの質問になんだって答え続けます〜
Day2最後は参加者によるオンライン形式での質問にたいして、デプロイ王子がなんだって答えてくれるチョークトークへ。普段聞けないような悩みやAzureにとどまらず熱いセッションでした。賢者が集まっていていたので、質問に対して得意な人が答えてくれるという豪華セッションにw
内容は非公開とのことなので、参加者のみぞ知る・・・恒例のあれはありませんでした。
明日は最終日。
Day3へ hawaku.hateblo.jp
- 作者: 佐藤直生、久森達郎、真壁徹、安納順一、松崎剛、高添修,日本マイクロソフト株式会社
- 出版社/メーカー: 日経BP社
- 発売日: 2018/11/15
- メディア: 単行本
- この商品を含むブログを見る
Microsoft Tech Summit 2018 Day1 #mstsjp18
今年もこの祭典の季節がやってきました。Microsoft Tech Summit 2018が2018/11/05から3日間の開催です。今年は初めて?の3Daysとなりました。場所はde:codeおなじみのプリンスパークタワーでの開催でロケーションの心配もありません。
Day1のオープニングイベントのKeynoteも午後からの開催とあり地方組の移動も余裕です。なお、余裕がありすぎて開始2時間前に会場入り、受付開始列の前から4番目だったことを補足いたします(
基調講演
何と言ってもマイクロソフトCEOサティア ナディア氏の来日が目玉でしたでしょう。他にもHQからCTO、CVPセキュリティ、M365 GMと会場セキュリティが心配になるレベルでしたし、それを最前列で見られたのは最高でした(2時間待ちの成果)。セッションもHQの方がメインでした。
内容としては全体的には365推しだったかなという感想ですが、GitHubネタ、Igniteの振り返り、Azure Data Explore(めっちゃ早いBigQueryみたい)、Windows VDI(世界初公開)、セキュリティ(パスワードレスにしようなど)ととても楽しめました。2時間半(30分オーバー)の長丁場で座りすぎてお尻が痛かったです・・・
Microsoft security
「いつまでパスワード入力しているの?」という基調講演からの流れで、ある方面にはパワーワードとなそうなセキュリティのプロのセッションでした。通常のセッションに加え澤さんとのトークセッションもあり、中でも印象だったのが「セキュリティのプロになるには?」という質問で「教えてもらったことは少なく、きっかけは任◯堂のチートをしたいから勉強した」という回答がとても的を得てるなと個人的にはハマりましたw
Dataが企業の力となる時代の最新Big Data x IoT x AI最前線
Day1最後は畠山さんのセッションへ。Igniteハイライトも振り返りも含みつつというか、内容が濃すぎでさらに振り返りをしたい(
- MLにおいて教師データがないなら教師データをシミュレーションで作ればいいじゃない -> Azure Digital Twin
- SQL Server 2019は全てのデータを統合、管理、カバーするAIを搭載
- SQL Server Master Instanceはk8sのpodとして動くという謎技術
- SQL Server 100TB対応してリストア時間の一貫性(分レベルらしい)の謎技術
- ビックデータを解析するAzure Data Explore
- MLにおいてモデルを自動で作ってくれるAutomated ML。モデルはコンテイメージ化されるのでコンテナー環境へデプロイ可能
- Automatedのモデル作成は総当たりではなくMSが積み重ねたAiによる推定値が使われる技術
- MS社内事例としてやみくもに営業するのではなく、データとBotサポートで営業角度を高める。例えば営業先が100社あったとしても人のキャパシティとしては10社として。ではこの10社は営業角度が高いのか?残りの90社に見込みがないのか?がただのデータによる足切りではわからない。そこでBOTを使ってチャットアンケート?などで営業角度を高める情報を集める手法。これ欲しい企業たくさんありそう
とIgniteハイライトですでにお腹いっぱいなDay1を終えました。明日からはテクニカルせション尽くしです。明日は🍺バッシュもあるのでDay2への続きは(ry
Day2へ hawaku.hateblo.jp
- 作者: 佐藤直生、久森達郎、真壁徹、安納順一、松崎剛、高添修,日本マイクロソフト株式会社
- 出版社/メーカー: 日経BP社
- 発売日: 2018/11/15
- メディア: 単行本
- この商品を含むブログを見る
Azure REST API を Try it!
きっかけは
https://t.co/RVtXEyIe7p は日々進化していて、最近ではドキュメントからAzure REST APIを試せる。「使ってみる」ボタンを押すと、うにょーんとウィンドウがのびて、自分のアカウントで試せるぞ。 pic.twitter.com/XKp37t19y2
— Toru Makabe (@tmak_tw) 2018年5月15日
えぇぇ・・・、なにこれめっちゃ便利そう(こな🍊
Let's Try!
Azure REST API Referenceを開きます。
Web Apps Getをしてみる
- 「Try it!」ボタンを押す
- ウィンドウがうにょーんと伸びるのでサブスクリプションを選択
- 必要項目を入力して「Run」ボタンを押す
- にゃーん
さくっとAPIを叩ける便利な機能です。これはAzureに限らず全てのAPIドキュメントに備わって欲しい(;・`д・́)...ゴクリ
以上、お試しでした!
クラウドエンジニア養成読本[クラウドを武器にするための知識&実例満載! ] (Software Design plusシリーズ)
- 作者: 佐々木拓郎,西谷圭介,福井厚,寳野雄太,金子亨,廣瀬一海,菊池修治,松井基勝,田部井一成,吉田裕貴,石川修,竹林信哉
- 出版社/メーカー: 技術評論社
- 発売日: 2018/03/14
- メディア: 単行本
- この商品を含むブログを見る
AzureでBLOBとLogicAppsを使ってサーバーレスかつコードレスにお問い合わせページを作る
元ネタはServerless Meetup Fukuoka #1 - connpassにてセッションした
「月額10円から作るServerless Website〜Azure編〜/serverlessfukuoka-20170825 // Speaker Deck」を実際に作ってみるというものです。
前回の記事で静的Webサイトのホスティング環境は整いました。次はお問い合わせページの対応を、Azureのサービスを組み合わせてサーバーレスに解決を目指してみます。
処理の流れはこんな感じです。
- お問い合わせページをBLOBから配信
- お問い合わせ内容のPOSTをLogic Appsで受け取る
それでは構築していきます。
Logic Apps
まずはPOST先のLogic Appsを作成します。Logic Appsはサーバーを管理しなくてもロジックを実行できるサービスです。さらにロジックを書くのにコードを書く必要はありません。料金はロジックを呼び出された時の実行時間だけ発生します(お財布に優しい)。
ロジックは問い合わせPOSTが来たらサンクスと問い合わせ内容をそれぞれメールで送るという簡単な物を組んでみます。
- Logic Appsの新規作成を開く
- Logic Appsを作成
- 作成したLogic AppsのデザイナーからHTTP要求時の受信時を選択
- ロジックを組みます
- HTTP要求の受信時
- SendGridで問い合わせ元へサンクスメール送信
- SendGridで窓口へ問い合わせ内容送信
- HTTP要求の受信時
- 保存後に生成される「HTTP POSTのURL」をメモ
お問い合わせページ
お問い合わせページをBLOBへデプロイします。お問い合わせページのサンプルはこちら。
デプロイが終わったらテストしてみます。
- POST
- サンクスメール受信
- 問い合わせ内容受信
旨くいきました。しかし、このままではLogic AppsのURLに対して誰でもPOST出来てしまいます。CORSを設定したいところですがLogic Appsに(今のところ?)この機能はありません。
CORS対応
Azure Function Proxies
CORSを使いたいのでAzure Functions Proxiesを導入します。
- ストレージアカウント作成
- Azure Function Apps作成
$ az storage account create --name <storage-account> --resource-group <resouce-group> --location japaneast --sku Standard_LRS $ az functionapp create --name <functionapp-name> --resource-group <resouce-group> --storage-account <storage-account> --consumption-plan-location japaneast
ここからはAzureポータルで作業します。
- 作成したAzure Funtion Appsを開く
- プロキシのバックエンドURLにLogic AppsのHTTP POSTのURLを設定
- プロキシURLをメモ
- CORS設定を開く
- CORSにお問い合わせページを置いたURLを設定
Function Proxiesの設定は完了です。 あとは、お問い合わせページのPOST先URLを先ほどメモしたプロキシURLへ書き換えて完成です。
Microsoft Azure実践ガイド (impress top gear)
- 作者: 真壁徹,松井亮平,水谷広巳,横谷俊介
- 出版社/メーカー: インプレス
- 発売日: 2017/12/15
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (2件) を見る
Azure BLOBで静的Webサイトをホスティングする
元ネタはServerless Meetup Fukuoka #1 - connpassにてセッションした
「月額10円から作るServerless Website〜Azure編〜/serverlessfukuoka-20170825 - Speaker Deck」を実際に作ってみるというものです。
Webサイトをホスティング
AzureでWebサイトをホスティングするなら、Webサイトホスティングに特化しているPaaSのWeb Appsを使う方法が機能豊富でオススメです。
構築手順は下記の同僚の記事が参考になります( ˘ω˘)
静的Webサイトをホスティング
※2018/12/18
Azure Storage BLOBのみで静的Webサイトをホスティングする機能がリリースがGAしました。これで下記のAzure CDNを組み合わせてindex.htmlをゴニョゴニョする必要はなくなりました。
Azure Storage で静的 Web サイトの一般提供を開始 – Cloud and Server Product Japan Blog
Azure BLOB
Azureで静的ファイル配信を行うとしたらAzure BLOBを利用します。BLOBはオブジェクトストレージのサービスです。
- リソースグループ作成
- Azure Storage Account作成
- ストレージキー取得
- Azure BLOBコンテナ作成
$ az group create --name <resource-group> --location japaneast $ az storage account create --resource-group <resource-group> --name <account-name> --sku Standard_LRS $ az storage account keys list --resource-group <resource-group> --account-name <account-name> | jq .[0] { "keyName": "key1", "permissions": "Full", "value": "<account-key>" } $ az storage container create --name '$root' --account-name <account-name> --account-key <account-key> --public-access blob
出来上がったBLOBに適当に作ったindex.htmlをアップロードします。ちなみに、Azure Storage管理には謹製のAzure Storage Explorer – クラウド ストレージ管理 | Microsoft Azureもいいですよ。
$ az storage blob upload --account-name <account-name> -c '$root' -f index.html -n index.html --content-type text/html
それでは、https://<account-name>.blob.core.windows.net/
へアクセスしてみましょう。
・
・
・
はい、Status 400ですね。BLOBはIndexFileに対応していません。index.htmlのパスも含めてhttps://<account-name>.blob.core.windows.net/index.html
へアクセスしてみましょう。
BLOBから配信はできていますが、今回はWebサイトホスティングを目指してるのでこのままでは・・・
Azure CDN
Azure CDNを使えば解決できそうです。 stackoverflow.com
要はアクセスが来たらAzure CDNを使ってindex.htmlにRewriteしてあげればいいとのこと。
CDNを入れると配信も速くなるので一石二鳥ですね。
- Azure CDNプロファイル作成
$ az cdn profile create --name <cdn-profile> --resource-group <resource-group> --location japaneast --sku Premium_Verizon
Premium_Verizon
の場合はCDN管理にAzureポータルを利用します。
- 作成したAzure CDNプロファイルを開く
- BLOBを配信元としてエンドポイントを追加
作成したエンドポイントにRewriteのカスタムルールを設定します。
- 作成したエンドポイントを開く
- エンドポイントの高度な機能を開く
- ルール作成画面へ
- Rewriteルールを追加
- IF 常に
- URL Rewrite source
((?:[^\?]*/)?)($|\?.*)
destination$1index.html$2
- URL Rewrite source
((?:[^\?]*/)?[^\?/.]+)($|\?.*)
destination$1.html$2
CDNへの反映されるまで待ちます。反映後 https://<cdn-endpoint>.azureedge.net/
へアクセスすると、
表示できました。
次回
Azure BLOBを配信元とした静的Webサイトのホスティング環境ができました。次回はお問い合わせページへの対応を行います。
- 作者: 久森達郎、真壁徹、大田昌幸、藤本浩介、佐藤直生、安納順一、松崎剛、高添修,日本マイクロソフト株式会社
- 出版社/メーカー: 日経BP社
- 発売日: 2017/11/17
- メディア: 単行本
- この商品を含むブログ (1件) を見る