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

Tech Summit 2017に参加 #mstsjp17

ハンズオンスピーカーとして参加した去年に続き2回目のTech Summitに参加。今回はイチ参加者として。

f:id:hawa9:20171112233455j:plain

Microsoft Tech Summit 2017 | インフラエンジニア、アーキテクト、IT 戦略立案に関わる皆様の為の技術カンファレンス - Microsoft Events & Seminars

場所はクリスマスイルミネーションの綺麗な恵比寿。

f:id:hawa9:20171112233518j:plain

Day1

KEY001 変化のとき、進化のとき ITイノベーションがもたらす価値

エクストリーム参加で途中から。マクロな観点ではDrewさんのTシャツがすてきだった。量子コンピュータの壮大さはなるほどわからん(誰か)。

SPL003 Women in Business & Technology Networking Lunch Session

話もスイーツも美味しかった。

SEL002 セキュリティ マニアックスでおます~コネクテッド カー時代に活かす IT サイバー セキュリティ~

ITでは過去にたくさんのハッキングに対応してきた知識は車業界でも必要でその逆もあるよ、とのこと。

twitter.com

SEL005 ネットワーク エンジニア必見!VPN/DMZ は要らなくなる!? Azure AD Application Proxy で実現するセキュアなアクセス

本当にこうなってた。WinServerがあれば可能。セッションでは社内ネットワークとの接続についてだったけど、AzureのVNET内でもできるのかな?出来るのであればVNETの一機能となってサーバーいらずになると、もっと便利になりそう。

twitter.com

CLD008 もう迷わない! Azure Virtual Network の使い方。

新しい機能のAZとかASGの知見を得た。VNETにRFC1918以外も使えるのは知らなかった(使い道わかんない)。

twitter.com

Day2

CLD014 Azure Big Compute (HPC) で実現する爆速分析環境を実業務で利用するために

HPC環境が10分ぐらいで手に入るのは凄い。欲しい環境を好きなサブスクリプションで使えるようなSaaSを提供するってのはいろいろと理にかなってるなぁ。

twitter.com

SEC008 クラウド利用時のセキュリティ環境構築術!!~IaaS メインにそっと PaaS を添えて~

エクセルの埋め方、同じようにやっていたので「アリなんだ」と思えて一安心。環境構築術の部分ももっと聞きたかった。

twitter.com

APP002 コンテナーなに使ってますか? Linux ですか? Windows も使ってもらっていいですか?

普段はLinuxコンテナなので使ったことのないWindowsコンテナの話はとても貴重だった。

twitter.com

DEP007 新しく生まれ変わった Azure Log Analytics と Azure Security Center によるITインフラの分析と保護

この話もレア。いつかのアンケートでこの辺について聞きたいと書いたのでそれを汲み取ってくれたのか定かではないが嬉しい。もっと使いこなしたい。

twitter.com

APP003 Azure Functions と Serverless - 概要と企業向け Tips

これ以外にないんだけど、そう思ってない多い問題。

twitter.com

DEP006 Azure サポート エンジニア直伝 ~ PowerShell 実践活用術 ~

PowerShellほとんど触ったことなかったけど、触ってみようかな。出来る幅が増えそう。

twitter.com

DEP005 インフラ野郎 Azure チーム コンテナー祭 ~Inside Container Infrastructure on Azure~

濃い情報祭りすぎて頭から煙でた。さすがのレベル400だった。読む試す書くをもっと磨いていきたい。

twitter.com

その他

内容的にも気になるし、そのうえ勉強できて寄付できるんだからすごい。

Hit Refresh(ヒット リフレッシュ) マイクロソフト再興とテクノロジーの未来

Hit Refresh(ヒット リフレッシュ) マイクロソフト再興とテクノロジーの未来

JAZUG福岡(ふくあず) de:code 2017 振り返り会に登壇 #jazug #fukuazu

f:id:hawa9:20170626173953j:plain

fukuazu.connpass.com

de:code 2017 受講セッション

まずは、自分の振り返り。今年はセキュリティ、DevOps、インフラ系のセッションに潜入していた。自分はインフラ屋なのでインフラ系が多めと思いきや、セキュリティセッションも多く取っていた。

セッション
SC12 あなたのチームのセキュリティスキルは十分ですか?DevSecOpsを見据えたセキュリティ人材の育成方法
SC04 あなたのサービスを “ID” で守る! Azure Active Directory の条件付きアクセスの基礎と実装
DO04 アジャイル開発サバイバルガイド 〜キミが必ず直面する課題と乗り越え方を伝えよう!〜
SC01 DevSecOps on Azure : セキュリティ問題に迅速に対応するためのパイプライン設計
DI13 ダウンタイムを最小に! ~ Azure における障害/災害に耐えうるアーキテクチャ設計のポイント ~
TL09 突撃! 隣の Visual Studio Team Services / Team Foundation Server ~利用者からのベストプラクティス
TL05 本場エバンジェリストのデモを堪能!コマンドラインだけで Azure アプリケーションをビルド・デプロイ・管理する
DO05 システムの信頼性を上げるための新しい考え方 SRE ( Site Reliability Engineering ) in Azure, on Azure
TL10 Azure IaaS 構築・運用・管理の専門家が語る DevTest Labs ~高速・費用無駄ナシ・簡単管理を実現する開発・テスト環境の構築~
DI01 窓は開かれた! SQL Server on Linux で拡がる可能性

ふくあず登壇

speakerdeck.com

資料の内容はゼロです。セッション時間全てデモさせてもらいました。

  • Azure CLI 2.0について
    • インストー
    • Dockerで使う。Aliasを設定してカジュアルに使う。
    • az login / az configure
  • jsonで便利なやつ
    • jq
    • jpterm(JMESPath)
  • Azure Cloud Shellでデモ
  • iPhoneのAzureアプリでAzure Cloud Shell

なお、このセッションはde:code 2017でのDrewさんの影響を強く強く(大切なことなので2回)受けております。

channel9.msdn.com

Global Azure Bootcamp 2017@TokyoとJAWS-UG福岡のダブルヘッダー #jawsug #jazug

f:id:hawa9:20170423092330j:plain

鉄は熱いうちに打て。ブログ書くまでが勉強会ということでさっそく。

Global Azure Bootcamp 2017@Tokyo #jazug

今まで福岡JAZUG(ふくあず)のイベントに参加したことはありましたが、JAZUGイベントで登壇したことがありません。ですので今回が記念すべき初JAZUG登壇となりました。 オープニングトークを聞くまでGlobal Azure Bootcampがどういイベントなのかもあまり知らなかったという・・・

jazug.connpass.com

togetter.com

今回はAzure事例セッションということで.Net Core+Dockerの事例MySauceFactory(マイソースファクトリー)についてMLBお兄さん (@tsubakimoto_s) | Twitterとペアセッションとなりました。ペアで話すのも初めての経験。

この3つについてインフラを中心にお話させていただきました。今回はAzureのイベントでしたので.Net Coreについては別の機会でDev Teamがやってくれると思います。

まだまだDockerを本番運用されているのは少数派。Docker運用事例としてお役立てできれば幸いです。なお、コーポレートサイト株式会社オルターブース(Alterbooth) | Microsoft AzureやAWSを中心としたクラウドの導入・開発・システム運用の方もDockerで運用中です。

QA

いくつかご質問いただいたので覚えている限り補足しつつご紹介致します。

  • コンテナの.Net Coreのログをどのように収集しているか?

    • .Net Coreはログを標準出力しています。あとはDockerのFluend Logging Driversで集めています。
  • ACSVM側のパッケージアップデートはどうしているか?

    • 必要ならACSを作り直して対応します。Dockerは新しい技術ですぐに陳腐化してしまう(放っておくと技術的負債になる)。作り直しが簡単なのもクラウドのメリット。現在はSwarmですがDC/OS、Kubernetesも含めて検討しています。
  • Dockerは落ちると聞くが遭遇したことは?

    • 私も聞いたことあります。(運がいいのか)いままで遭遇したことがありません。OMSで監視しているので落ちても検知できる仕組みにはしています。コンテナも冗長構成にしているので同時に落ちることは考え難く、落ちてもサービスを継続できる仕組み(予防)にしています。この辺、Apacheとかも落ちる時は落ちるのでDockerに限った話でもないのかなーと思っています。

de:code 2017

去年に続き、今年も参加予定です。会場で目に入ったら気軽にお声がけしていただけるとうれしいです。

最後に

タイトルを改めたいです。本当にありがとうございました。

JAWS-UG福岡 #jawsug

さて、同時刻に地元福岡でJAWS-UGが開催されていました。

JAWS-UG福岡:Reboot#4、荒木さんとAWSの話をしてみたりJAWS DAYS参加者から話をきいてみたりしよう - JAWS-UG九州 | Doorkeeper

Global Azure Bootcamp参加中の身でしたがセッション休憩時間に品川と福岡を結んでのオンライン登壇(余興)を実行。オンラインミーティングツールとして最近発表された新サービスのAmazon Chimeを使ってみました。

Amazon Chime – 統合されたコミュニケーションサービス | Amazon Web Services ブログ

画面共有もしっかりと見え、音声、ビデオもクリアにお届け出来たようです。

なお、なぜお酒を呑んでいると思われたのか謎です。戻ったら真相を伺いにチャイムを鳴らしに行きます。

Infrastructure as Code ―クラウドにおけるサーバ管理の原則とプラクティス

Infrastructure as Code ―クラウドにおけるサーバ管理の原則とプラクティス

Ansible徹底入門 クラウド時代の新しい構成管理の実現

Ansible徹底入門 クラウド時代の新しい構成管理の実現