Azureの勉強しててクラウド死したくないので！課金アラートの設定のやり方

この記事は後ほどcloud.configのtechblogにマルチポストします。

はじめに

最近Kubernetesの勉強をしているなむゆです。
特にAKSについて勉強するために自前のサブスクリプションにリソースを立ててみたりもするのですが、AKSって今のところ一番安くてひと月4000円からかかるんですよね。
数日間リソースを立てっぱなしにした日にはすぐに1000円以上課金されたりしてしまいます。
というか今月そんな調子です。
できれば一定金額以上使ったらそれ以上使えないようにしたいのですがそういう方法が見つけられなかったので、次善策として「今月の課金額が〇〇円を超えたよ～」というアラートを設定するようにしているので今回はその方法の共有です。

課金アラートの設定方法

まずはAzureのポータル画面の上部の検索欄で「サブスクリプション」を入力して検索し、選択します。
するとサブスクリプションの一覧画面に移るので、自分が今使っているサブスクリプションを選択します。
するとそのサブスクリプションの情報が表示されるので、左のメニューの一覧から「コストのアラート」を選択します。
ちなみに、すぐ上の「コスト分析」をクリックすると現在の課金額が確認できますよ。
課金額が一定を越した際にアラートを設定するには画面上部の「追加」をクリックします。
すると、予算の作成の画面に移動します。
名前と予算額を設定するのですが、ここでいう予算額が「だいたい毎月使うのはこのくらい」という値で、あとでアラートを発する課金額の閾値のベースの値になります。
設定したら「次へ」をクリックします。
次は、アラートを発する条件とアラートを送信するメールアドレスを設定します。
予算額をベースに、予算の何％の課金がされたタイミングでアラートを送るかを設定できます。
予算額に達したタイミングでメールを送りたい場合は100%でも問題ないですが、念のため200%とかでも送るようにした方がいいかもです。
予算の100%を超えたくらいだったら大抵無視するし予算の2倍も使ってますよってアラートが来たら「さすがにやべぇ」って気分になるじゃないですか。
余談はさておき、他に送信するメールの言語も設定して、「作成」をクリックします。
これで設定は完了です！
課金額が指定した閾値を越すとこのようなメールが届きます。やべぇ。AKS止めなきゃ。というかローカルでminikube立ててもいいな・・・

おわりに

今回はAzureの課金額でアラートを発する方法を共有しました。
課金額周りで色々調べたり予算設定したりアラートを発する機能はサブスクリプション周りに集まっていて、個人で使う時以外でも組織上の目的でも色々使うことになると思います。
参考に書いているドキュメントあたりが取っ掛かりになるかと思うので、その周りから調べてみると目的に合うものが見つかるかもしれません。
今回も読んでいただきありがとうございました。
お役に立てれば幸いです。

参考

• チュートリアル:Azure の予算を作成して管理する

Dockerfile正しいかわからないなら、試しにローカルでbuild & runしてみようぜ(.Net Core Web API)

この記事はcloud.config tech blogにマルチポストしています。

はじめに

みなさん、Dockerfile書いてますか？
この記事を見ている方は何らかの理由でDockerfileを書くことになった方と思います。
今回はそんな方の助けになることを目指して、ローカルでDockerfileを使ってコンテナをビルドし、動作確認する方法で一席打ちたいと思います。

前提

• Dockerがインストールされている
  アプリを立ち上げるマシンにDockerが必要です。
  まだインストールしていなければ公式サイトからインストールしておきましょう。
  https://www.docker.com/products/docker-desktop
• Visual Studioがインストールされていて.Net Coreアプリ開発のためのSDKがインストールされていること
  今回はビルドするアプリの例として、.Net Core3.1のWeb APIを作成します。
  そのため、開発環境としてVisual Studioをインストールしてください。
  Community Editionであれば無料で使用できるので、ダウンロードしてインストールしましょう。
  インストールするワークロードを選択する画面で以下の部分にチェックを入れてインストールされていれば大丈夫です。
  

実際にやってみる

1. テンプレートのアプリケーションを作る

今回は.Net Core3.1のWebAPIのアプリケーションをサンプルとしてつくりたいのでその方向でセットアップしていきます。
まずはVisual Studioを起動します。
新しいプロジェクトを作りたいので「新しいプロジェクトの作成」をクリックします。
「ASPNET Core Webアプリケーション」をクリックして次へ進みます。
プロジェクト名を設定します。今回は「testWeatherForecast」として「作成」をクリックします。
しばらくするとテンプレート状態のアプリケーションが作成されます。
今回は特に弄らずこれをサンプルとしてコンテナにするので、このまま次に進みましょう。

2. Dockerfileを作る

作成したアプリケーションがあるディレクトリをエクスプローラーなどで開きます。
特に設定していなければ大抵C:\Users\{ユーザー名}\source\repos\testWeatherForecastのパスに存在するはずです。
そこにファイルを新規作成し、Dockerfileという名前で保存します。
拡張子等は設定しません。

そして、そのファイルをエディタ等で開いたら、中にこちらのサンプルのDockerfileをコピー＆ペーストしてきます。
Dockerfileをコピーしてきたら、その中の必要な個所を置き換えます。
置き換えるのは以下の2点です。
- 1行目と14行目のmcr.microsoft.com/dotnet/core/sdk:3.0はmcr.microsoft.com/dotnet/core/sdk:3.1に置き換えます。
- アプリケーションのプロジェクト名のaspnetappは全部testWeatherForecastに置き換えます。
Dockerfileの作成と内容の書き換えはこれで以上です。

今回は.Net Core3.1のアプリケーションの例でDockerfileを作成していますが、他のフレームワークのアプリケーションでも、テンプレートとなるようなDockerfileは大抵どこかしらで公開されているので、Dockerfileを作るときは0から作る必要はないことが多いです。
Dockerfileにあまり触れたことがない場合は、何かのアプリケーションのコンテナを作る時にそのアプリケーションを動かすフレームワークのDockerfileのテンプレートを探して、それをベースにしてコンテナの軽量化などのためにカスタマイズしていくパターンが鉄板かと思います。
余談でした。

3. コンテナをbuild & run する

以下はコマンドプロンプトやPowershell等のコマンドラインツールを用いて行います。
まずは、cdコマンドを用いて今回作成したアプリケーションのslnがあるディレクトリまで移動します。
そこまで移動できれば、コンテナをbuildします。
docker build -t weather:test .
エラーがなければしばらくたつとコンテナのイメージが生成されます。
docker images
とコマンドを打つと、buildしたコンテナの情報が表示されるはずです。
それでは、そのコンテナをローカルのマシンに立ち上げてみましょう。
以下のコマンドを打つとアプリケーションのコンテナがローカルのマシン上で起動し、APIとしてリクエストを受け付ける状態になります。
docker run weather:test
うまくいくと、info: ~~~で始まるログがいくらか吐き出され、起動状態になります。

4. ちゃんと動いているか試す

ブラウザを開き、urlの欄にlocalhost:9000/weatherForecastを入力してリクエストしてみます。
そうすると、コンテナ起動時に設定したようにポート番号9000番はコンテナのポートの80番にポートフォワーディングされるので、weatherForecastのAPIにリクエストを送ることができます。
ブラウザ上に以下のようなjsonの文字列が表示されていれば成功です！

5. 後片付け

このテスト用のコンテナはいつまでも起動させておくわけにもいかないので、最後は削除しておきます。

docker psのコマンドを実行して立ち上がっているコンテナの状態を確認します。
IMAGEが立ち上げたコンテナの「weather:test」であるものを探し、そのコンテナのIDをメモします。

次に、docker container rm {メモしたコンテナID} -fのコマンドを実行し、立ち上がっているコンテナを削除します。

最後に、作成したコンテナイメージを削除します。
docker image rm weather:test

これで今回作成したDockerのリソースを削除できました。

おわりに

今回はサンプルで作成したアプリケーションを元にDockerfileからローカルでコンテナを作成、実行してみました。
Dockerfileの書き方はアプリケーションによって異なりますが、大抵はアプリケーション毎に使えるテンプレートが公開されています。
何かのフレームワークを使って初めてコンテナ化を試みる場合はそういったものを頼るのは最初のとっかかりとして適しているかと思います。

また、Dockerfileを作ったとき、コンテナを実行環境に上げる前には一度動作確認を取ってみましょう。

幸せなコンテナ開発を！

思考を整理するのに使えるオンラインホワイトボードMiroの個人的な使い方あれこれ

この記事はcloud.config tech blogにマルチポストしております。

tech-blog.cloud-config.jp

昨今リモートワークが推奨されていますが、そんな時節のせいなのか過去に自分が書いたブログ記事の中ではオンラインホワイトボードMiroの記事はやけに読まれています。
前回Miroについて書いてから時間が空き、一般的な部分の説明はほぼほぼやりつくしてしまった感じもするのですが、今回は自分が普段どのようにMiroを使っているかを示しながら思考の整理について語ってみようと思います。

Miroとは

MiroはMiro者が開発しているWebアプリケーションで、Miro社曰くはonline collaborative whiteboard platformと呼んでいます。日本だとよく「オンラインホワイトボード」と呼ばれています。
元々はRealtime boardという名前のアプリで会社名もRealtimeboard.incだったのですが、2019年にアプリの名前が変わり、その時に社名も変更したようです。
主な機能は、ホワイトボードを使うような直感的な図の作成機能と、それをリアルタイムでほかのユーザーと共有する機能です。
例えば、左のメニューから付箋のアイコンを選んで好きな色を選んだら・・・
適当な場所をクリックするだけでそこに付箋を張り付けることができます。
関係性を示したいときは付箋をクリックしたときに出てくる青丸をほかの物体にドラッグしてやれば簡単に矢印を引くこともできます。
矢印を引くときはさりげなく他の物体に吸い付いてくれたりしてくれるのでさりげなく使い勝手がいいです。

こんな基本機能のMiroですが、普段自分がどのようにMiroを使っているかご紹介したいと思います。

いろんな使い方

例えば、自分の場合すごくシンプルなTodoリストのボードを作っています。
タスク管理ツール自体はMiro以外にもあり、より高機能なものも色々あります。
なのでMiroをタスク管理ツールとしてチームで使うことはあまりありませんし自分もいつも使っているわけではないのですが、やることが増えてきて混乱しそうになった時に頭の中のダンプ先として個人的なTodoリストとしてMiroを使っています。仕事以外のタスクも一緒に突っ込めるのも利点かもです。
直感的に素早くタスクを付箋にして張り出せるのと、タスク間の依存関係を矢印で示したりして何が「待ち」の状態になっているか分かりやすく示せます。
また、読んだ本の内容をまとめて勉強会の資料にしたりしています。
色分けができるので、赤い付箋はこの章の問い、そこに向かって引いている矢印はその問いに対する答えを示すなど、役割を持たせられます。
勉強会や話を聞くときのメモとして利用したこともあります。これはいつぞやGlobal AI Nightに参加したときのメモですね。講義を受けながら、後ろではこんなメモをとってました。
ぜひ記事と見比べてみてください。
他に、何かの処理のロジックを整理するためにフローチャートのようなものを書いたこともあります。Miroの基本的な機能で図形を描くこともできるので、このような使い方もできます。他にもお見せできる内容ではないのですがシーケンス図なんかも書いています。
他にも、ここで示すことはできないのですが仕事の中で考えていることがややこしくなってきたときにMiroはよく使います。
書いたことをほかの人に見せることはほとんどないのですが、「何かに悩んだらそれを書き出してみる」というのは問題解決のいい方法だと言われているのを個人的には信じているので、そのためのツールとして使っています。
普段このように思考を整理するのにMiroを使うことが多いのですが、指向を整理するのに何やるかといったら頭の中で考えているとりとめのないことを列挙してそこから関連するものをまとめて整理したり一つ一つの問題に対する回答を結び付け足りしていると思います。
Miroでは一番基本的な機能として付箋を貼ってそれらを矢印で結びつけることができるのですが、それがこういった思考の整理に役立っている気がします。
自分が書いたMiroの最初の記事が思考のロギングの話だったのもそこから来ています。

おわりに

今回は普段よく使っているMiroについて個人的によくやる使い方の例からMiroについて語ってみました。
私はMiroは自分の考えをまとめるために一人で使いがちですが、リモートワーク環境下で意思疎通のために複数人で使うこともできます。ぜひ一度使ってみてください。

RDB脳なぼくらのためのKQL⇔SQL対応表

この記事はcloud.config tech blogにもマルチポストしています。

tech-blog.cloud-config.jp

結論

今回は結論から書きます。「SQLでいうところのアレ、KQLだとどんな感じだったっけ」という人はｺｺだけ読めば解決です。
|SQL|KQL|
|---|---|
|SELECT | project|
|FROM句 | 一番最初の行にテーブル名を書くだけ|
|WHERE | where|
|LIKE '%[検索文字]%' | contains "[検索文字]"|
|GROUP BY | summarize|
|ORDER BY | sort by|
|LIMIT(またはOFFSET~FETCH) | take|
|COUNT | count|

※他にも思い出したものがあれば順次追加していきます
また、書いている途中で見つけたのですがもう少し広い範囲での対応表はMicrosoftによってこちらに元々用意されているようですのでこちらも見てみてください。

クエリ例

StormEvents   
| project State, StartTime, EpisodeId, EventType, InjuriesDirect, Source  
| where Source contains "new"  
| sort by StartTime  
| take 100  

基本的な書き方として、偉業目にテーブル名を書いて2行目以降は「|」を挟んで書きます。

KQLとは

KQLは、SQLでいうところのCRUDの動作のうちRead動作だけを行えるちょっと特殊な書き方をするクエリ言語です。「Kusto Query Language」の略がKQLです。
主な使用場面としては、Azure Log Analyticsのようなログを蓄積するリソースにおいて蓄積されたログデータを検索、表示させる際に使用します。Log Analytics他にも使う場面はあるのかもしれませんが網羅的に把握はできてないです・・・。
ログのような大量の蓄積されたデータから、効率よく、欲しい形で簡単にデータを読み出すためのクエリ言語がKQLであるという形です。読み取りしかできないというのも使用用途がログの検索であるというところからきているようです。

他にも、今回はスコープから外れるので紹介しませんでしたが「render」というキーワードを使用してログから簡単にグラフを出力する機能もあります。
例えば以下のようなクエリを書くだけで簡単にタイムチャート図が出力されます。

StormEvents   
| summarize count()  by d = bin(StartTime, 30d)  
| render timechart   

使用する際はLog Analyticsの「ログ」のメニューからKQLを書く窓を開くこともできるのですが、他に「Kusto.Explorer」というツールもあり、こちらを使うとデスクトップアプリケーションから様々な機能の助けを借りつつクエリを書くこともできます。SQL Serverに対するA5 SQLやSSMSみたいなものですね。

簡単に試せる環境があるのよ

また、KQLを簡単に試せる環境があります。
ここにはあらかじめデータが挿入された環境があり、KQLを打ち込むことでいくつかのテーブルから結果を出力することができます。
例えば初期状態だとサンプルのクエリとして

StormEvents   
| where StartTime >= datetime(2007-11-01) and StartTime < datetime(2007-12-01)  
| where State == "FLORIDA"    
| count   

が入力されています。
この実行結果としてはCountに23が出力されます。
このクエリを基にして例えば最後の行のcountを外すとその23件のデータが全カラム表示されたり、projectを使うことで表示するカラムを絞り込むことが出来たりします。
ここで様々なクエリを試してみることができるので、様々なクエリを試してみましょう。

おわりに

KQLはLog Analyticsでログを確認するときによく使用するもので社内でも時々急に使うことになったりするのですが、キーワードが独特なので一見とっつきづらい感じがします。
多くの人は多かれ少なかれSQLを書いたり触れたりした経験はあると思うのですが、その知識をベースにしてKQLはこんな感じだよと説明したらわかりやすいのではないのではないのかというのがこの記事の試みです。
KQLを初めて使う！けどSQLは触ったことあるよという方の理解の助けになれば幸いです。

参考

• Kusto の概要
• SQL から Kusto のチート シート
• KQL クイック リファレンス
• Kusto.Explorer の使用

【小ネタ】k8sのLens使ってみたらちょっと詰まったので解決してきたメモ

この記事はcloud.co.fig tech blogにマルチポストしてきました。

tech-blog.cloud-config.jp

こんにちは、コンテナが立つと初めてわが子が立ったように喜ぶなむゆです。
去年、「k8sのIDE、Lensが便利な件について」という記事を見て、あぁ～kubernetes周りのツールについても知りたいな～Lens使ってみよっかなと思い立ちました。
それで実際に使ってみたのですが、Lensで接続するクラスターを指定するのに必要なkubeconfig周りで若干詰まって、それを解決してきたので今回はそのネタで一席打ちます。

kubeconfigとは

kubeconfigとはkubernetesのクラスターに接続するのに使う接続文字列のようなもので、「接続先のクラスターのurlはここよ～」とか「接続するときはこの認証情報を使うんよ～」といった情報が記されています。
kubernetesに接続する際にはこのファイルを使って接続を行うため、Lensのようなツールでも接続文字列として使用しているわけです。
デフォルトでは[ホームディレクトリ]/.kube/configのパスに存在するほか、「KUBECONFIG」の環境変数で指定されたパスや「--kubeconfig」のパラメータで指定したパスに存在するファイルをkubeconfigファイルとして使用できます。
詳しくはこちら。

起きたこと

Azure上に「namuyutest01」という名前でAKSのリソースを作成し、ローカルでaz login を行ってクレデンシャルを取得しました。
Lensを起動すると接続先のkubeconfigファイルを求められたので現在使用しているkubeconfigを表示するコマンドのkubectl config viewコマンドを使用してkubeconfigを表示しました。だいたいこんな感じです。
「REDACTED」って何なの・・・と思いつつこれをコピーしてLensに張り付け、接続してみたらエラーが発生しました。
というかLens、goのコードで動いてるのですね・・・
等と妙に感心しました。

解決方法

結論から言いますと、kubectl config view --raw コマンドを使ってちゃんと生のkubeconfigを取得しましょうねということでした。
kubectl config view のコマンドだとあまりにも文字数の多いトークンなどの情報が「REDACTED」として省略されていたのですね。

生のkubeconfigを取得してLensに張り付けて接続すると・・・
やった～～～～～～～～～！

教訓

正直自分はkubernetesをAKSでしか使用していなかったので、kubeconfigファイルについて「あーget-credentialで取得できるやつ」程度の認識でいました。
実際にはその中身にはちゃんと意味があるので、中身に何が書かれているかはちゃんと把握しておくべきです！

ということでLensを使う時に遭遇したエラーを解決したお話でした。
よっしゃこれでLens使えるぞー！
業務で役立つことは間違いないので、ぜひ使ってみましょう。

Azure DevOpsのパイプラインを回すAPIがあるんだって

この記事はcloud.config tech blogにマルチポストしております。

tech-blog.cloud-config.jp

どうも、パイプラインが回るとうれしいなむゆです。
Azure DevOpsのパイプラインをコードから回したくなること、ありませんか？
普段はAzure DevOpsのパイプラインは文字通りのDevOpsのためのCI/CDパイプラインを回すために使いますが、時としてこれを手動で回したい、しかもできればアプリケーション上から！ということもあるかと思います。~え、ない？~

AzureDevOpsにはそんな時に使えるAPIが用意されています。
今回はそれを使ってAPIからAzure DevOps上のパイプラインを回してみます。

Azure DevOpsパイプラインを回すAPIを叩いてみる

まずはAzure DevOpsのOrganizationとプロジェクトを作ります。
この辺りのやり方はAzure DevOpsでサクっとCI/CDを組んでみるシリーズが参考になりますのでこちらでは省略。
結果としては以下のようなOrganization名「Namuyun」プロジェクト名「Namuyuno」で作成しました。
それでは、パイプラインで使うパイプラインyamlファイルをAzure DevOpsの機能の一つのReposで作られているGitリポジトリに突っ込んでいきます。
今回作成したpipeline.yamlの中身はこんな感じです。

trigger: none  
pr: none  
  
parameters:  
  - name: "sample1"  
    type: string  
    displayName: "Sample1"  
  - name: "sample2"  
    type: number  
    default: 0  
    displayName: "Sample2"  
  
jobs:  
  - job: sample_job  
    displayName: sample job  
    pool:  
      vmImage: ubuntu-16.04  
    steps:  
      - script: |  
          echo Sample1 Value is: ${{ parameters.sample1 }}  
          echo Sample2 Value is: ${{ parameters.sample2 }}  

ざっくりとした意味合いとしては、
- このパイプラインはPRやマージをトリガーにしては回りませんよ～
- このパイプラインは回すときにパラメーターとして「sample1」、「sample2」という名前の引数を受け取りますよ～
- このパイプラインで実行することはパラメーターとして受け取った「sample1」、「sample2」をコマンドラインで出力しますよ～

みたいなことを書いてます。

お次はパイプラインを作ります。メニューからPipelinesを選び、右上の「New Pipeline」ボタンを押します。
pipeline.yamlのコードはAzure Reposにおいてあるのでそれを選びーの
リポジトリ名は「Namuyuno」で作ったのでそれを選びーの
今回は既に作ってあるyamlファイルを読み込むので「Existing Azure Pipelines YAML file」選びーの
「Path」で今回使うパイプラインyamlファイル選びーの
するとパイプラインyamlファイルの中身を確認できるので問題なければ右上の下↓から「Save」を選択します。これでパイプラインが作成されます。
「All」のタブを選ぶと作ったパイプラインが確認できます。今回は名前を「Namuyuno」に変えています。これをクリックします。
すると作成したパイプラインの詳細画面に映るのですがここでそのページのurlに注目。
「definitionId=○○」とありますが、この番号を覚えておきます。
あとでAPIを叩くときに回したいパイプラインのIdを指定するときに使います。
次はパイプラインを回すAPIを叩くのに必要なアクセストークンを作成します。DevOpsの画面右上の方にある心臓が歯車に置き換えられちゃった人みたいなアイコンをクリックして「Personal access tokens」をクリックします。
するとトークンの一覧の画面が開くので、左上の「New Token」をクリックします。
作成するトークンの設定する画面が開くので、名前と設定する権限、有効期限を設定します。「Scope」はトークンに与える権限を設定できるのですが「Custom defined」を選び、下に出てくるスコープの一覧から「Build」の「Read & excute」を選択し、「Create」をクリックします。
ちなみに有効期限の最大は1年なのでアプリケーションに組み込むとき等は注意です！
すると、トークンが作成され、表示されます。
作成されたトークンはこの画面にしか表示されないのできちんとコピーしておきましょう。
これでパイプラインAPIを叩く準備は完了です！
今回はPostmanを使ってパイプラインを回すAPIを叩いてみます。
このAPIのURLは、
https://dev.azure.com/{Organization名}/{プロジェクト名}/_apis/pipelines/{回したいパイプラインのId}/runs?api-version=6.0-preview.1
です。HttpメソッドはPOSTです。
今回はOrganization名、プロジェクト名、回したいパイプラインのIdはそれぞれ「namuyun」、「Namuyuno」、「2」で置き換えます。
そしてさらに、アクセストークンの設定も行っていきます。
なので、Postmanでは「Authorization」のタブを開き、TYPEを「Basic Auth」と指定します。するとUsernameとPasswordの入力欄が出てくるので、Passwordの欄に先ほどコピーしたトークンを張り付けます。
Usernameは入力しなくて大丈夫です。
それができたら、メッセージの本文を作成していきましょう。
「Body」のタブに移動して、タイプは「raw」を選択します。
するとBodyの中身を書き込める欄が出てくるので、ここにメッセージの本文を書き込んでいきます。
メッセージの形式としては、

{  
  "resources": {  
    "repositories": { "self": { "refName": "refs/heads/{パイプラインを回すのに使うブランチ名}" } }  
  },  
  "templateParameters": {パイプラインに渡すパラメーター(Json)}}  
}  

となっています。
今回はパラメーターとして「sample1」「sample2」を渡すので、その内容はtemplateParametersに書き込んでおきます。
準備ができたら「Send」を押してリクエストを送ります。レスポンスステータス200番が返って来たら成功！

では、パイプラインがちゃんと回っているか確認するためAzure DevOpsも見てみましょう。

パイプラインの名前の横に時計アイコンが出ていればリクエストを受け付けてパイプラインを回す準備をしています。回転しているアイコンが出ていればパイプラインが回っています！
時間がたつとパイプラインの横のマークは緑のチェックマークになるはずです。パイプラインがコケたらバツ印になります・・・
どちらにせよ、処理が終わったらそのパイプラインの処理結果を見ていましょう。
「CmdLine」の項目を選択すると、処理が成功していればパイプラインyamlで記述したとおりsample1とsample2のパラメータに入力した値が出力されているはずです！

おわりに

今回はAzure DevOpsから公開されているAPIを使用してAzure DevOpsパイプラインを回しました。
Azure pipelineを回すにはほかにもaz cliを使用した方法もあります。
状況に応じて使い分けていきましょう。

参考

• Runs - Run Pipeline

firebase functionsからrealtime databaseに接続するのに軽く詰まったのでメモ

この記事は後ほどcloud.config tech blogに転載する予定です。

ことの発端

最近ぼくの中でまたfirebase x vue(nuxt)欲が強くなってきていて、（将来のお仕事にもしたいし）再びサイトなんかを作ったりして遊んでいる。
その中で、この間はフロントエンドをfirebase hostingでホストし、APIをfunctionsに作ってそこからrealtime databaseとやりとりするアーキテクチャでサイトを作ろうとした。
その時、functionsからrealtimedatabaseへの接続ってどうやるんだっけ？と軽く混乱して半日ほど潰してしまった。
そこまで高度なテクニックで解決するものじゃない初歩的な話だけど、この先同じ事がまた起こった時に備えてのメモとして、あるいは同じところで詰まった人のため、この記事を残しておきたい。

functionsからrealtime databaseへの接続方法

基本はfirebaseのドキュメントにあるとおりだ。
firebase initでアプリケーションを作ったのだから何か専用の設定をして繋げるんじゃないかと思って色々調べたけれど、そんなこともなかった。
大まかに言うと、javascriptのコードでrealtime databaseに接続するサンプルの通りにすればいい。

firebaseのプロジェクトのページに入って左上の「プロジェクトの概要」の横の歯車から「プロジェクトを設定」を選ぶ。

初期状態ではマイアプリが登録されていないので、「マイアプリを追加」から適当な名前を付けてアプリを追加する。

すると以下のような接続文字列が取得できるのでコピーする。

これを利用してfunctionsのAPIの受け口となるindex.js(あるいは.ts)を以下のようにする。

import * as functions from "firebase-functions";  
import firebase = require("firebase");  
const firebaseConfig = {  
  apiKey: "ここはシークレット",  
  authDomain: "namuyu-functions-test.firebaseapp.com",  
  databaseURL: "https://namuyu-functions-test.firebaseio.com",  
  projectId: "namuyu-functions-test",  
  storageBucket: "namuyu-functions-test.appspot.com",  
  messagingSenderId: "777861796007",  
  appId: "1:777861796007:web:60a7472d9557465d450b82",  
};  
// Initialize Firebase  
firebase.initializeApp(firebaseConfig);  
  
export const addCurrentTime = functions.https.onRequest((request, response) => {  
  firebase  
    .database()  
    .ref("date/" + new Date())  
    .set({  
      currentTime: new Date().toString(),  
      testData: "sample",  
    });  
});  
  

この中のfirebaseは初期状態でpackage.jsonに入っていないので、コードを書き換える前後でnpm install firebaseしておくこと！

ここまでやって```npm run serve してurlを叩くと、realtime databaseの方に以下のようにデータが溜まっていくはず。

おわりに

こんな感じに、firebase functionsからrealtime databaseにアクセスしてデータのやり取りを行えるようになる。
が、正直これはjavascriptのコードからであればどこでも同様に行えるので、functionsでなくても同様に動くはずである。
というか、逆にfunctionsなら特別に何かをしなければならないってことでもないというのに気付くのに時間を取ってしまった感じがある。
本来はfirebaseのデータベースにはフロントからクエリを送るとフロントエンドと繋がってデータベースの中身が書き換わるとそれがフロントまで伝搬してリアクティブに表示内容が書き換わるという素敵な機能があったりもするのだけど、そこまでリアルタイムな処理が必要じゃなかったりフロントエンドとバックエンドを分離して最悪バックエンドからfirebaseをはがすとなった時のことも考えると、データベースとのやりとりはfunctions経由で行った方がいいんじゃないかって思うような場合もある。

あと、今回のコードでは接続文字列をコードの中に含めてしまっているが、実際の開発の際にはこれを外部のjsonあたりから受け取るようにして、そのjsonはコード管理とは別に管理することも忘れないように！
2020/8/30追記 どうも実際はAPIキーは隠蔽する必要がないそうな。
フロントエンドにfirebaseを組み込むと配信されるjavascriptにも埋め込まれるので結局APIキーが公開される。
そしたらその公開されたAPIキーで偽の別アプリ作ればfirebase上のデータベースとかアクセスし放題やないかいと思うが、実際にそれで別アプリを作ったところで実際にRead/Writeできるのは設定したルールで決められてる範囲だけだ。
そしてそれらの機能はauthenticationと結びつけられているので、APIキーを入手しても結局別の認証手順を踏まないとリソースの中身をいじれない。
ゆえに実際にはAPIキーを別管理にする必要はない、らしい。