CI/CDのためのFirebase スタンドアロンバイナリ

3 min読了の目安(約3400字TECH技術記事

Firebaseに何かをデプロイするケースがある際、素直に使ってるだけなら普通にnpmベースでfirebase-toolsを使うのが一番楽と考える人は多いでしょう。
実際に普段の自分が使う場合も、ほとんどのケースではnpmースのツールを使っています。

ところが、ちょっと自分のデプロイ環境で「構成の大半が非Node.js」という事態が起きました。
この事態に対する対応策を探していたところ、「スタンドアロンバイナリ」の存在に気づいたので、使ってみることにしました。

そこで、の記事ではスタンドアロンバイナリの紹介をしつつ利用事例をまとめています。

スタンドアロン版Firebase CLI

前述の通り、Firebase CLIはfirebase-toolsという名称でNode.js用のパッケージとして公開されています。

スタンドアロン版Firebase CLIは、Googleが公式に提供しているシングルバイナリ版のFirebase CLIファイルです。
WindowsやmacOSだけでなくLinux対応版も提供されており、CLIについてのFirebaseドキュメントでも、次のような人をターゲットに挙げています。

  • Node.jsを普段使わない人
  • CLIでのワークフロー利用者

ワークフローにおける利用を考える

npmベースCLIを利用するワークフロー

Node.js製CLIツールのインストールは、一般的にnpm install -g firebase-toolsのようにグローバルインストールが推奨されていることが多いです。
しかし、これだとインストール先が当然ながグローバル領域になります。そうなると、ワークフロー上でキャッシュさせにくく、ちょっと面倒です。 [1] [2]

Node.jsのアプリ開発の過程でCLIツールを使うのであれば、devDependenciesを用いたローカルインストールが可能です。
アプリ環境セットにして「アプリの提供全体に必要な依存関係を全てまとめられる」のは、このスタイルの利点となります。
ロジェクトルートの./node_modulesフォルダは、ワークフローからでも比較的キャッシュ設定がしやすく、自分も普段このスタイルを採用しています。

とはいえ、Node.jsを使っているならともかく、こんなケースではデプロイのためだけにpackage.jsonを管理しないといけなくなります。

  • ビルドとデプロイに関連性が薄い
  • そもそもNode.jsを使ってない

スタンドアロンバイナリを利用するワークフロー

スタンドアロンバイナリを使う場合、curlなどを利用してワークフロー上で直接ダウンロードして利用することになります。
(後ほど実例を出します)

この場合は、Node.js関連のファイルを一式ピンポイントで管理せずに済むというメリットがあります。
さらに、ダウンロード済みバイナリはキャッシュ可能なため、ちょっと手間ですが「対象バイナリが無い場合みダウンロード」といったことも可能になります。[3]

実例(GitLab-CI/CD)

自分が書いてみた、スタンドアロンバイナリを利用したFairebaseデプロイの例です。
(要点のみを抜粋しています)

.gitlab-ci.yml
deploy:
  only:
    - master
  when: manual
  image: google/cloud-sdk:slim
  script:
    - export GOOGLE_APPLICATION_CREDENTIALS=$GCLOUD_SERVICE_ACCOUNT_JSON
    - gcloud auth activate-service-account --key-file ${GCLOUD_SERVICE_ACCOUNT_JSON}
    # Collect artifacts
    - echo "Some operations"
    # Deploy to firebase
    - curl -Lo firebase https://firebase.tools/bin/linux/latest
    - chmod +x ./firebase
    - ./firebase use $GCLOUD_PROJECT
    - ./firebase deploy

今回主軸となるのは、# Deploy to firebase以降の処理です。
GitLab-CI/CDベースの説明になりますが、他のワークフローでも、ローカル利用でも使用感はあまり変わらないでしょう。

Firebase CLIのダウンロード

$ curl -Lo firebase https://firebase.tools/bin/linux/latest
$ chmod +x ./firebase

Firebaseドキュメントにもリンクがある通り、直接ダウンロード出来るURLが存在するので、curlなどでダウンロードするだけです。
実体はGitHubでホスティングされているので、リダイレクト追跡をするオプションが必要になります。 [4]

パーミッション設定は特にされていないので、忘れずにchmodなどで実行権限を付与しましょう。

Firebaseコマンドを実行する

この時点で./firebase -hを実行すると、ちょっとした待ち時間の後にヘルプテキストが表示されるようになります。

上記のように動作確認を終えた後は、普段使いのFirebaseと同様にコマンドを使っていけます。

$ ./firebase use $GCLOUD_PROJECT
$ ./firebase deploy

自分の場合は、単純にデプロイするいがは要件が無いため、./firebase useでプロジェクトを指定して、./firebase deployでデプロイしているだけです。

※実際には、前後にメインで指定しているイメージ(not Node.js)でしか出来ないオペレーションを挟んでいます。

使用感

もともとのワークフローでは、「ローカルインストールしてキャッシュさせる」スタイルを取っていました。

これをスタンドアロンバイナリに変えてみたのですが、体感としてはさほど処理時間の変動が見られませんでした。[5]
前述の通りキャッシュなしの状態での比較なのですが、これならキャッシュをさせなくてもそこまで苦労しなさそうです。[6]

感想

内外のいくつかのプロジェクトでFirebaseを使っているのですが、自分はどちらかというと「GCPに程よくFastly+UIを被せるラッパー」と捉えています。
その関係でアプリケーション層にNode.jsを使う選択肢をあまり取ってないのですが、そういった用途にスタンドアロンバイナリは有用な選択肢でした。

間違いなくだいぶ前からあったのですが、今回気づけたので色々な場面で楽ができそうです。

脚注
  1. 例えば、/usr/lib/node_modulesといった場所にインストールされることになります ↩︎

  2. 頻繁な更新が必要にならないため、毎回インストールするのは、リソースに優しくありません ↩︎

  3. キャッシュ戦略を取らない場合は、気楽に「常に最新版を利用できる」いう恩恵を受けられます ↩︎

  4. curlの場合は-Lオプションが対象 ↩︎

  5. 定量比較してないのと、他のジョブ整理の一環でやったので、明確なBefore/Afterをしていません ↩︎

  6. Runnerの環境的にもダウンロード速度が比較的出るのもあって、「キャッシュをやりくりする時間」を変に考慮するより気楽です ↩︎