「運用」の記事 - Crieit

const admin = require("firebase-admin");  

// *** 移行元のプロジェクトの設定
const srcSA = require("./key/XXXXX.json");   // サービスアカウントの秘密鍵を取得
// firebase-adminの初期化
admin.initializeApp({ credential: admin.credential.cert(srcSA) }); 
const srcDB = admin.firestore();          // firestoreのインスタンスを取得

// ** 移行先のプロジェクトの設定
const destSA = require("./key/XXXXX.json");  // サービスアカウントの秘密鍵を取得
// ※同じadminを使って、別のAppを作成しないといけない※
// ※2つ目を初期化する場合は、"dest"など名前をつけないといけない※
const destAdmin = admin.initializeApp( { credential: admin.credential.cert(destSA) }, "dest");
const destDB = destAdmin.firestore();        // firestoreのインスタンスを取得

// ****************************
// * MAIN
// ****************************
async function main() {
  console.log(`***** START MAIN`);

  // 移行元からデータを取得
  const snaps = await srcDB.collection("data").get()
  const srcData = snaps.docs;

  for (let v of data) {
    try {
      // 移行先からデータを保存
      const destDataRef = destDB.collection("data").doc(v.id);
      await destDataRef.set(v.data());
    } catch (error) {
      console.errror(`Error: ${error}`, error);
    }
  }

  console.log(`***** END   MAIN`);
  process.exit(0);
}

main().then();

雛形はこんな感じ。

以前書いた以下の記事だと丸々移行するので、UIDが変わるとめんどくさいことになる。。

この方法であれば、

whereで一部のだけに絞り込んだり、
set()するときに、UIDを差し替えたり

できるので、開発用に使うにはよいかんじ。

注意1: 2つ目を初期化する場合は別の名前に

そのまんまコピペで2つのfirebase-adminを作るとエラーに。。
2つ目を初期化する場合は、"dest"など名前をつけないといけないいけないらしい。。

公式ドキュメントの「複数のアプリを初期化する」に書いてあった。

これで、2つのfirebase-adminが起動できるので、データ移行などもできそう(´ω｀)

注意2: メモリを大量に使いそうな場合はオプションを指定

データが多く、メモリを大量に使いそうな場合は、
--max_old_space_sizeオプションを指定しないといけない。。

途中で失敗すると(読み込み/書き込み件数的に)悲しいことになるので、
大きめのサイズを指定しておくと良さそう。

node --max_old_space_size=8192 index.js

注意3: 件数が多い場合は、limitを指定して再帰処理

大量のデータを一度に取得しようとすると、

Deadline Exceeded error

が出て怒られるので、少しずつ実行するのがよいかんじ。

const BATCH_SIZE = 300
async function moveData(lastItem) {
  // 移行元からデータを取得
  const colRef = srcDB.collection("data");
  let query = colRef.orderBy("createAt", "asc");
  if (lastItem != null) query = query.startAfter(lastItem.createAt);
  const snap = await query.limit(BATCH_SIZE).get();

  if (snap.docs.length === 0) return; // 0件なら終了する
  const srcData = snaps.docs;

  for (let v of data) {
    try {
      // 移行先からデータを保存
      const destDataRef = destDB.collection("data").doc(v.id);
      await destDataRef.set(v.data());
    } catch (error) {
      console.errror(`Error: ${error}`, error);
    }
  }

  // 最後の要素を渡して、そこから継続する
  await moveData(data[data.length - 1]);
}
// ****************************
// * MAIN
// ****************************
async function main() {
  console.log(`***** START MAIN`);

  await moveData(null);

  console.log(`***** END   MAIN`);
  process.exit(0);
}

注意4: 複数の場所に反映する場合は、batchやtransactionを使う

途中でエラーになる場合もあるので、batchやtransactionを使うとよさそう。

公式ドキュメントだと、このあたり
- トランザクションと一括書き込み | Firebase

  for (let v of data) {
    try {
      const batch = destDB.batch();

      // 移行先からデータを保存
      const destDataRef = destDB.collection("data").doc(v.id);
      batch.set(destDataRef, v.data());

      // 移行先からデータを保存: その2
      const destData2Ref = destDB.collection("data2").doc(v.id);
      batch.set(destData2Ref, v.data());

      // コミット
      await batch.commit();
    } catch (error) {
      console.errror(`Error: ${error}`, error);
    }
  }

ループ外で使うほうのもいい感じ。

ただ、一括で書き込めるドキュメント数は500までと制限があるので、
一度に書き込む範囲は適宜調整が必要。

1 回のトランザクションまたは一括書き込みでは、
最大500のドキュメントに書き込みを行うことができます。
トランザクションと一括書き込み | Firebase

まとめ

firebase-adminは複数のプロジェクトでも扱える。
部分的なデータ移行や一部を書き換えながらの移行もできる(´ω｀)

ただ、件数が多かったり、複数の書き込みがある場合は、いろいろ必要。。

こんなのつくってます!!

積読用の読書管理アプリ『積読ハウマッチ』をリリースしました！
積読ハウマッチは、Nuxt.js+Firebaseで開発してます!

もしよかったら、遊んでみてくださいヽ(=´▽`=)ﾉ

要望・感想・アドバイスなどあれば、
公式アカウント(@MemoryLoverz)や開発者(@kira_puka)まで♪

Crieitの普段の運用方法について色々

2018-12-03T08:00:40+09:00

個人開発のWebサービスの技術紹介となると「こういうふうに作りました！」というのが多くQiitaのAdvent Calendarも含めると色々かぶる気がするため、運用周りについての色々を書いてみることにしました。（実際に作った系は自分が今まで書いた記事にもう既に書いてしまっているものも多く、そもそもそことほとんどかぶってしまうと思いますし）

はじめに

個人開発サービスに用いられている技術 Advent Calendar 2018 の3日目です。昨日は @morix1500 さんの Nyaaanを支える技術でした。

ローカルでの開発

docker-composeを使っているのでとりあえずコンテナを起動し、ローカルのURLで開発を行います。1

フロント側も開発する場合、Node関連は全部WSLに入れているのでとりあえずwslを実行してあとはLaravel標準で入っているコマンドのyarn run hotによるホットリローディング状態で開発していきます。

フロント側のビルド

フロント側で何かしらを対応した時は、ビルドしておく必要があります。ビルドするとmix-manifest.json、js、cssファイルが更新されます。

Crieitの場合は現在これらをcommitしています。こうすることで本番ではpullするだけで全て完了しますし、なにか本番で問題が見つかった場合はpullする前の状態に戻せばすぐ復旧できます（バージョニングをしているため）。業務などでCIでデプロイまでしっかり作るのであればそれでいいと思いますが、個人開発であればこれがフットワークが軽くて一番良いと思います。

デプロイ

開発した内容をサーバーにデプロイする場合はssh接続します。今使っているのはGoogle Compute Engineなのですが、gcloudというシェルで色々操作することができます（予めインストールしてシェル上にログインする形です）

ログインのコマンドはGCPのコンソールのGCEインスタンス一覧のところでコピーしてこれるので、何も考えなくても簡単にログインできます。コマンドは下記のような感じです。

gcloud compute --project "プロジェクトID" ssh --zone "ゾーン" "インスタンス名"

あとは普通にユーザーを切り替えてフォルダ移動してgit pullや必要であればマイグレーションを実行するだけです。

CI

デプロイは前述の通り手動ですが、テストだけCIしています。Werckerという無料のものを使っていて、リポジトリはBitBucketを使っているのですが簡単に連携ができます。

とはいえ、個人開発ですしあまりテストにまでガッツリ時間を書けている余裕はないため、基本的には他のアプリケーションを作る時も含め、テストはほとんど書きません。一応CI成功して嬉しい～というところまでは味わいたいので最小限だけ書いており、例えばCrieitでは下記を書いています。

トップページのレスポンスが200か
記事詳細ページのレスポンスが200か
匿名コメントでユーザーの名前が表示されてしまったりしないか、というプライバシー面

等。それ以外は、今後何かしら修正や機能拡張が必要だった時に、

修正前に正常系のテストを書く
開発
開発完了したらテストがちゃんと動くか確認及び調整

という感じでテストを増やしていけばいいと思っています。

デプロイもすれば良いのですが、設定するのが面倒なのでやっていないだけだったりします。

データの閲覧や操作

データはMySQLで、元々は本番に適当にphpMyAdminを入れていました。むちゃくちゃ長いフォルダ名にしていたので問題はないと思うのですが、仕事でも何度かいつの間にか非公開URLがGoogleにインデックスされる現象を見てきたので一応今は削除してあります。

前述のsshとほぼ同じ方法でポートフォワーディングができるので、手動でそれを実行してPC上のクライアントで見ています。（下記を実行したあと接続）

gcloud compute --project "プロジェクトID" ssh --zone "ゾーン" "インスタンス名" -- -L 13306:localhost:3306

Windowsでよく使われるクライアントといえばWorkbenchだと思うのですが、見た目があまり好きではなくデータのセルも変なふうに見えるのであまり使っていません。（今回は関係ないのですが）sshトンネルができれば何でも良いので、適当に最近流行ってそうなクライアントを使っています。

今はHeidiSQLというやつで、Linux Mintの時はたしかTeamSQLとかだったと思います。

アクセス解析

深夜0時まで起きてたら前日の参照元を見たりしてます。Search Consoleは更新が1時くらいで大体起きてないので翌日の朝に最新の日の流入キーワードとかを見てます。あまり変わり映えしないので飽きてきましたが。

ヒートマップも一応入れているのですが、サービスの特性上読まれるところが読まれて、クリックされるところがされて、という感じでたいして驚きのある結果にはならないのであまり見ていません。

まとめ

個人開発なので超適当です！

時間もないですし適当に手を抜けるところはガンガン抜いてサービスの改善に努めましょう！！！

明日は @kame_f_no7 さんです！

注釈

1: 以前こちらに書いています。 Qiitaの様なサービス作成中ローカル環境構築連載(1)