Microsoft Tech Summit 2018 Day3 #mstsjp18

hawaku.hateblo.jp

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

今日も美味しいランチを頂きながら。もぐもくしてたらすごい取り組みをされていた。

AKS管理のベストプラクティス #CI32

実際のAKS開発者とMonitor開発者の話が聞けるとかすごいですわ。試される英語力😇同時通訳さんありがとうありがとう。

クラウドネイティブガバナンスの実現〜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 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出来るようになったらいいな
  • 複数台VMをManaged IDで管理したい場合はコマンドで行うか、Azure Policyを使うとよい

Appendex

The Illustrated Children's Guide to Kubernetes

f:id:hawa9:20181109013605j:plain

セッションもさることながら、いろいろな人に出会える現地にいくのは楽しいですね!

Microsoft Tech Summit 2018 Day2 #mstsjp18

hawaku.hateblo.jp

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テンプレート活用事例として紹介してしていただきました。ありがとうございます。

Azure Durable FunctionsとAzure AD連携によるプロビジョニング自動化の実現 #CI36

美味しいランチを頂きながら。スポンサーセッションなので、てっきり製品紹介と思いきや、製品のアーキテクチャ詳細解説が始まり、これランチの片手間で聞けるレベルじゃないやつ(

もぐもぐしてたのでメモとれずでしたが、選択した技術それぞれについて、なぜそれを選択したのか、設計ポイント、つまずいたポイントが紹介されていました。

  • Durable Funtions
  • Azure Pipeline(RUN From ZIP)
  • Azure AD MSI
  • マルチテナント構成
  • Graph API

スポンサー資料も公開されるといいな。

企業内ネットワークでも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〜

f:id:hawa9:20181107012846j:plain

念願のNoOps。第1回目は台風リスケで行けなかったのでほんと楽しみだった。ファシリテータの真壁さんと3賢人によるリレーセッションと質問タイム。質問タイムは登壇者には内緒だったみたいw。

  • Opsで消耗している
  • NoOpsは運用のうれしくないをなくす
  • NoOpsの王道は守りのNoOps。監視通知の自動化、リトライの自動化、構成変更の自動化、方式の標準化、可視化
  • NoOpsは人間のオペレーションを減らすこと
  • オペミス削減の品質向上
  • Toilを減らすチームになろう
  • Toilを減らすプロダクトを作ろう
  • それでも残るToil。知らなかったことなど2度目は起きないようにしよう

わい、質問へ壇上へあがる(
質問タイムで滅多にない機会だと思いきやまさか壇上へあがるとは思わんなだ((

  • NoOpsをお客さんにどう理解してもらうか?
    • イケてる構成を作ることもできるが、バランスも大事
    • どんなにイケてる構成を導入がでもアーキテクチャを塩漬けせず変更し続けることを受け入れてもらうことが、大前提
    • お客さんとの信頼関係を築く
  • NoOpsエンジニアをどう育てていくか?
    • 失敗してもいいから日頃からチャレンジしてもらう
    • 失敗はマイナス評価ではない

うまく伝えきれない。動画公開されたら見直そう。機会を頂きありがとうございまいた(緊張しました)

デプロイ王子アンプラグド〜あなたのAzureの質問になんだって答え続けます〜

Day2最後は参加者によるオンライン形式での質問にたいして、デプロイ王子がなんだって答えてくれるチョークトークへ。普段聞けないような悩みやAzureにとどまらず熱いセッションでした。賢者が集まっていていたので、質問に対して得意な人が答えてくれるという豪華セッションにw
内容は非公開とのことなので、参加者のみぞ知る・・・恒例のあれはありませんでした。

明日は最終日。


Day3へ hawaku.hateblo.jp

Azureテクノロジ入門 2019

Azureテクノロジ入門 2019

Microsoft Tech Summit 2018 Day1 #mstsjp18

今年もこの祭典の季節がやってきました。Microsoft Tech Summit 2018が2018/11/05から3日間の開催です。今年は初めて?の3Daysとなりました。場所はde:codeおなじみのプリンスパークタワーでの開催でロケーションの心配もありません。

Day1のオープニングイベントのKeynoteも午後からの開催とあり地方組の移動も余裕です。なお、余裕がありすぎて開始2時間前に会場入り、受付開始列の前から4番目だったことを補足いたします(

f:id:hawa9:20181106003357j:plain

基調講演

何と言ってもマイクロソフトCEOサティア ナディア氏の来日が目玉でしたでしょう。他にもHQからCTO、CVPセキュリティ、M365 GMと会場セキュリティが心配になるレベルでしたし、それを最前列で見られたのは最高でした(2時間待ちの成果)。セッションもHQの方がメインでした。

ascii.jp

内容としては全体的には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

Azureテクノロジ入門 2019

Azureテクノロジ入門 2019

Azure REST API を Try it!

きっかけは

えぇぇ・・・、なにこれめっちゃ便利そう(こな🍊

Let's Try!

Azure REST API Referenceを開きます。

docs.microsoft.com

Web Apps Getをしてみる

  1. 「Try it!」ボタンを押す
    f:id:hawa9:20180521225540p:plain
  2. ウィンドウがうにょーんと伸びるのでサブスクリプションを選択
    f:id:hawa9:20180521225531p:plain
  3. 必要項目を入力して「Run」ボタンを押す
    f:id:hawa9:20180521225524p:plain
  4. にゃーん
    f:id:hawa9:20180521225518p:plain

さくっとAPIを叩ける便利な機能です。これはAzureに限らず全てのAPIドキュメントに備わって欲しい(;・`д・́)...ゴクリ

以上、お試しでした!

クラウドエンジニア養成読本[クラウドを武器にするための知識&実例満載! ] (Software Design plusシリーズ)

クラウドエンジニア養成読本[クラウドを武器にするための知識&実例満載! ] (Software Design plusシリーズ)

AzureでBLOBとLogicAppsを使ってサーバーレスかつコードレスにお問い合わせページを作る

元ネタはServerless Meetup Fukuoka #1 - connpassにてセッションした

月額10円から作るServerless Website〜Azure編〜/serverlessfukuoka-20170825 // Speaker Deck」を実際に作ってみるというものです。

前回の記事で静的Webサイトのホスティング環境は整いました。次はお問い合わせページの対応を、Azureのサービスを組み合わせてサーバーレスに解決を目指してみます。

処理の流れはこんな感じです。

  1. お問い合わせページをBLOBから配信
  2. お問い合わせ内容のPOSTをLogic Appsで受け取る

それでは構築していきます。

Logic Apps

まずはPOST先のLogic Appsを作成します。Logic Appsはサーバーを管理しなくてもロジックを実行できるサービスです。さらにロジックを書くのにコードを書く必要はありません。料金はロジックを呼び出された時の実行時間だけ発生します(お財布に優しい)。

ロジックは問い合わせPOSTが来たらサンクスと問い合わせ内容をそれぞれメールで送るという簡単な物を組んでみます。

  1. Logic Appsの新規作成を開く
    f:id:hawa9:20180201003733p:plain
  2. Logic Appsを作成
    f:id:hawa9:20180201003744p:plain
  3. 作成したLogic AppsのデザイナーからHTTP要求時の受信時を選択 f:id:hawa9:20180201003802p:plain
  4. ロジックを組みます
    f:id:hawa9:20180201003821p:plain
    1. HTTP要求の受信時
    2. SendGridで問い合わせ元へサンクスメール送信
    3. SendGridで窓口へ問い合わせ内容送信
  5. 保存後に生成される「HTTP POSTのURL」をメモ

お問い合わせページ

お問い合わせページをBLOBへデプロイします。お問い合わせページのサンプルはこちら

デプロイが終わったらテストしてみます。

  1. POST
    f:id:hawa9:20180201003526p:plain
  2. サンクスメール受信
    f:id:hawa9:20180201003539p:plain
  3. 問い合わせ内容受信
    f:id:hawa9:20180201003550p:plain

旨くいきました。しかし、このままではLogic AppsのURLに対して誰でもPOST出来てしまいます。CORSを設定したいところですがLogic Appsに(今のところ?)この機能はありません。

CORS対応

Azure Function Proxies

CORSを使いたいのでAzure Functions Proxiesを導入します。

  1. ストレージアカウント作成
  2. 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ポータルで作業します。

  1. 作成したAzure Funtion Appsを開く
  2. プロキシのバックエンドURLにLogic AppsのHTTP POSTのURLを設定
    f:id:hawa9:20180201003604p:plain
  3. プロキシURLをメモ
    f:id:hawa9:20180201003615p:plain
  4. CORS設定を開く
    f:id:hawa9:20180201003625p:plain
  5. CORSにお問い合わせページを置いたURLを設定

Function Proxiesの設定は完了です。 あとは、お問い合わせページのPOST先URLを先ほどメモしたプロキシURLへ書き換えて完成です。

Microsoft Azure実践ガイド (impress top gear)

Microsoft Azure実践ガイド (impress top gear)

Azure BLOBで静的Webサイトをホスティングする

元ネタはServerless Meetup Fukuoka #1 - connpassにてセッションした

月額10円から作るServerless Website〜Azure編〜/serverlessfukuoka-20170825 // Speaker Deck」を実際に作ってみるというものです。

Webサイトをホスティング

AzureでWebサイトをホスティングするなら、Webサイトホスティングに特化しているPaaSのWeb Appsを使う方法が機能豊富でオススメです。

構築手順は下記の同僚の記事が参考になります( ˘ω˘)

zuvuyalink.net

静的Webサイトをホスティング

Azure BLOB

Azureで静的ファイル配信を行うとしたらAzure BLOBを利用します。BLOBはオブジェクトストレージのサービスです。

  1. リソースグループ作成
  2. Azure Storage Account作成
  3. ストレージキー取得
  4. 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/ へアクセスしてみましょう。

f:id:hawa9:20180130235000p:plain




はい、Status 400ですね。BLOBはIndexFileに対応していません。index.htmlのパスも含めてhttps://<account-name>.blob.core.windows.net/index.htmlへアクセスしてみましょう。

f:id:hawa9:20180130235048p:plain

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ポータルを利用します。

  1. 作成したAzure CDNプロファイルを開く f:id:hawa9:20180130235109p:plain
  2. BLOBを配信元としてエンドポイントを追加 f:id:hawa9:20180130235121p:plain

作成したエンドポイントにRewriteのカスタムルールを設定します。

  1. 作成したエンドポイントを開く f:id:hawa9:20180130235131p:plain
  2. エンドポイントの高度な機能を開く f:id:hawa9:20180130235140p:plain
  3. ルール作成画面へ f:id:hawa9:20180130235152p:plain
  4. Rewriteルールを追加 f:id:hawa9:20180130235210p:plain

CDNへの反映されるまで待ちます。反映後 https://<cdn-endpoint>.azureedge.net/ へアクセスすると、

f:id:hawa9:20180130235225p:plain

表示できました。

次回

Azure BLOBを配信元とした静的Webサイトのホスティング環境ができました。次回はお問い合わせページへの対応を行います。

Azureテクノロジ入門 2018

Azureテクノロジ入門 2018

MetabaseをAzure Web App for Containersで動かしてみた

f:id:hawa9:20180126001854p:plain

Kibanaやre:dashなどデータを良い感じに可視化してくれるツールのなかで、Metabaseもいいぞという記事に目がとまりました。

OSSのデータ可視化ツール「Metabase」が超使いやすい - Qiita

MetabaseがRedashの苦労を吹き飛ばすくらい熱い - Qiita

ということで、早速試してみたいと思います。

インストール

インストールにはいくつか方法があるようで、

https://www.metabase.com/docs/latest/operations-guide/start.html#installing-and-running-metabase

今回はDockerで試してみます。Dockerはいいぞ。

Docker

Dockerインストール済みの環境なら一撃起動です。

$ docker run -d -p 3000:3000 -v ~/metabase-data:/metabase-data -e "MB_DB_FILE=/metabase-data/metabase.db" --name metabase metabase/metabase

コンテナーが起動したら http://localhost:3000 へのアクセスします。Metabaseに必要なDBもよしなに準備してくれます。安心してください、DBデータ永続化できますよ。

AzureにMetabaseをデプロイする

ローカル環境でMetabaseが動くことが確認できました。次はサーバーにデプロイします。AzureでDockerのWebアプリを動かすといえばこれ、Web App for ContainersをMetabaseのデプロイ先にします。

Web App for Containers

Cloud Shell便利ですね。

  1. リソースグループ作成
  2. Linux App Seriveプラン作成
  3. Web App for Container作成
$ az group create --name <resource-group> --location japaneast
$ az appservice plan create --name <plan-name> --resource-group <resource-group> --sku B1 --is-linux
$ az webapp create --resource-group <resource-group> --plan <plan-name> --name <webapp-name> --deployment-container-image-name metabase/metabase

次にWeb Appsへアプリケーション設定を行います。

  • DBデータを永続化したいので、Web Appsへ永続化を指定します。WEBSITES_ENABLE_APP_SERVICE_STORAGE=trueにして、/home配下をマウントします。
  • Metabaseイメージはポート3000を使用するので、WEBSITES_PORTでWeb Appsへ使用するポートを指定します。
$ az webapp config appsettings set --resource-group <resource-group> --name <webapp-name> --setting WEBSITES_ENABLE_APP_SERVICE_STORAGE=true MB_DB_FILE=/home/metabase-data/metabase.db WEBSITES_PORT=3000 

https://<webapp-name>.azurewebsites.net へのアクセスします。




アクセスできない(泣)

f:id:hawa9:20180126000508p:plain

App ServiceプランをB1とケチったせいですね。とりあえず札束で殴ってみます。

$ az appservice plan update --resource-group <resource-group> --name <plan-name> --sku S3

再度 https://<webapp-name>.azurewebsites.net へのアクセスを試みます。

f:id:hawa9:20180126000454p:plain

起動しました。

DBを外部参照へ変更

札束効果(スケールアップ)によりアクセスできるようになりましたが、お試しにしては懐に優しくない・・・。パフォーマンス改善のためMetabaseがローカルに持つDBを外部委託してみます。MetadabaはPostgresSQLが利用できるようなので、Azure Database for PostgresSQLに外部委託します。

Azure Database for PostgresSQL

Azure Database for PostgresSQLを作成します。

$ az postgres server create --resource-group <resource-group> --name <postgres-name> --admin-user <user> --admin-password <password> --performance-tier Basic --compute-units 50 --storage-size 51200 --version 9.6

次にAzure Database for PostgresSQLのファイアウォールを設定します。ファイアウォールにはWeb AppsのIPアドレスを指定したいのですが、Web AppsからOut方向のIPアドレスは固定できない?ようなので、今回は全解放で設定します(ご利用は計画的に)。

$ az postgres server firewall-rule create --resource-group <resource-group> --server <postgres-name> --name AllowAllIps --start-ip-address 0.0.0.0 --end-ip-address 255.255.255.255

構築したDBへpsqlやpgAdmin等で接続して、Metabase用のロールmetabaseとデータベースmetabaseを追加します。

key value
DBホスト <postgres-name>.postgres.database.azure.com
DBユーザー名 <user>@<postgres-name>
DBパスワード <password>

〜PostgresSQLへの追加手順省略〜

DB周りの作業が終わったのでMetabaseのDBをAzure Database for PostgresSQLへ変更します。

  1. マウント設定MB_DB_FILEを削除
  2. 接続文字列MB_DB_CONNECTION_URIを設定

PostgresSQLへSSL接続をするには、MB_DB_CONNECTION_URIで指定する必要があるようです。

Connecting to postgres metabase db over ssl · Issue #3296 · metabase/metabase · GitHub

$ az webapp config appsettings delete --resource-group <resource-group> --name <webapp-name> --setting-names MB_DB_FILE
$ az webapp config appsettings set --resource-group <resource-group> --name <webapp-name> --settings "MB_DB_CONNECTION_URI=postgresql://<postgres-name>.postgres.database.azure.com:5432/metabase?user=<user>@<postgres-name>&password=<password>&ssl=true"

https://<webapp-name>.azurewebsites.net へのアクセスできれば完了。

App Serviceプランを元に戻してみます。

$ az appservice plan update --resource-group <resource-group> --name <plan-name> --sku B1

f:id:hawa9:20180126000440p:plain

メモリ不足感はありますが、動いてくれてるのでOKとしましょう。

いくら?

実際Metabaseを構築するとしてもステージング環境などの空いてる所にMetabaseを同居させたりして、Metabase専用を作る機会は少なそう。

  • Web Apps S3サイズで約¥38,696/月
  • Web Apps B1サイズ + Azure Database for PostgresSQL Basicサイズで約¥9,821/月

Azure Database for PostgresSQLと組み合わせた方が安く上げられました。構築や運用の手間(コスト)、その辺を全部丸投げできるPaaSは楽ちんですね( ˘ω˘)

それではよい、Metabaseライフを。

Azureテクノロジ入門 2018

Azureテクノロジ入門 2018