RailsにRSpecを導入する

まずはRailsにRSpecを導入します。

実際にローカル環境でRSpecによるテストができるところまでの手順をまとめています。

「rspec-rails」、「factory_bot_rails」、「rails-controller-testing」のインストール

Gemfileを以下の3つのGemを追加しbundle installします。

・Gemfile

group :development, :test do
  gem 'rspec-rails'
  gem 'factory_bot_rails'
  gem 'rails-controller-testing'
end

RSpecに必要なファイルを生成する

以下のコマンドでRSpecに必要なファイルを生成します。

$ bundle exec rails generate rspec:install

成功すると以下の3つのファイルが生成されていることが確認できます。

.rspec
spec/spec_helper.rb
spec/rails_helper.rb

RSpec実行に必要な設定をする

Factory Botの設定をrails_helper.rbに追加します。

・spec/rails_helper.rb

RSpec.configure do |config|

  ...

  config.include FactoryBot::Syntax::Methods
end

Rails.loggerのログを出力するには以下を追加します。

Rails.logger = Logger.new(STDOUT)

rspec用のテストファイルを作成するために、application.rbに以下を追加します。

・application.rb

config.generators do |g|

...

  g.test_framework :rspec,
                   fixtures: true,
                   view_specs: false,
                   helper_specs: false,
                   routing_specs: false,
                   controller_specs: true,
                   request_specs: false
  g.fixture_replacement :factory_bot, dir: "spec/factories"
end

.rspecに以下を追加するとテストの実行結果が見やすくなります。

・.rspec

--format documentation

テストを作成する

factoriesやcontrollerを用意し、テストを作成していきます。

今回はテスト作成の過程は省略します。詳しくは以下の記事などを参考にしてください。

【Rails】基本的なAPIテストの書き方 #RSpec - Qiita

概要 Railsで作成されたAPIのテストについてこちらを参考に必要最低限の情報…

qiita.com

例として本のデータを取得するAPIの本コントローラのshowメソッドに対してテストを行います。

・spec/factories/books.rb

FactoryBot.define do
  factory :book do
    name {'テスト本'}
  end
end

・spec/controllers/books_controller_spec.rb

describe Api::BooksController, type: :controller do
  context '/api/books' do
    describe 'GET #show' do
      render_views

      before do
        @book = create(:book)
        get :show, params: { id: @book.id }
        @json = JSON.parse(response.body)
      end

      it '200チェック' do
        expect(response).to be_success
        expect(response.status).to eq 200
      end

      it '本データチェック' do
        expect(@json[name]).to eq(@book.name)
      end

    end
  end
end

ローカルでテストが実行できるか確認します。

$ docker-compose exec web bundle exec rspec

正常にテストが成功すると以下のようなログが出力されます。

Finished in 0.58604 seconds (files took 4.32 seconds to load)
2 examples, 0 failures

Cloud BuildでRSpecを組み込む

ローカルでのRSpecによるテストが確認できたら、Cloud BuildにRSpecを組み込んでCI/CDパイプラインを構築していきます。

Dockerfileの作成

Rubyの公式イメージを元に作成しています。

テストする際のDBの接続先はMariaDBを使用します。

・Dockerfile

FROM ruby:2.5.8-alpine3.11

RUN set -ex \
  && apk update \
  && apk upgrade \
  && apk add --no-cache \
    build-base \
    bash \
    curl \
    nodejs \
    tzdata \
    mariadb \
    mariadb-client \
    mariadb-dev \
    openrc \
    libc6-compat \
    gcompat \
  && mkdir -p /run/openrc \
  && touch /run/openrc/softlevel \
  && rc-status \
  && /etc/init.d/mariadb setup \
  && gem install bundler

RUN mkdir /app_name
ENV APP_ROOT /app_name
WORKDIR $APP_ROOT

ADD ./Gemfile $APP_ROOT/Gemfile
ADD ./Gemfile.lock $APP_ROOT/Gemfile.lock

RUN bundle install
ADD . $APP_ROOT

テスト用のDB設定

database.ymlに以下のようにテスト用のDBを設定します。

・database.yml

test:
  adapter: mysql2
  encoding: utf8
  reconnect: false
  pool: 5
  username: root
  password: password
  database: test_db

テスト実行用のシェルスクリプト作成

Cloud Buildで実行するシェルスクリプトを作成します。

MariaDBを起動して、DBを作成しテストを実行できる環境を整えます。その後、テストを実行します。

・rspec.sh

#!/bin/bash

# MariaDBの起動
rc-service mariadb start

# テスト用DB作成・マイグレーション
RAILS_ENV=test rails db:create db:migrate

# RSpecテスト実行
RAILS_ENV=test bundle exec rspec

Dockerイメージを作成し、RSpecのテストを行いGAEにデプロイする

cloudbuild-staging.yamlのスクリプトでDockerイメージの作成、RSpecのテスト、GAEのステージング環境にデプロイを行います。いわゆるCI/CDパイプラインを構築して、実行しています。

Gitでプッシュするとcloudbuild.yamlのスクリプトが自動で実行されるようにしています。

Cloud BuildとGitの連携方法に関してはここでは省略しています。

・cloudbuild-staging.yaml

steps:
- name: 'alpine'
  args: ['echo', '${_ENVIRONMENT}']
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'gcr.io/$PROJECT_ID/cloud-build-rspec', '.']
- name: 'gcr.io/$PROJECT_ID/cloud-build-rspec'
  args: ['/bin/bash', 'rspec.sh']
- name: 'gcr.io/cloud-builders/gcloud'
  args: ['app', 'deploy', 'app-staging.yaml']

Cloud BuildでRSpecによる自動テストの動作確認

テスト失敗時

テスト失敗した際の挙動を確認します。

テストが失敗するとCloud Buildのステップが停止し、デプロイされることはありません。

テスト成功時

テスト成功時の挙動を確認します。

テストが成功すると、そのままGAEへのデプロイが始まり、無事完了しました。

参考

Rails5へのRspec導入から実行確認まで #Ruby - Qiita

株式会社TECH LUCKという会社で代表兼エンジニアをしている齊藤です。 DX…

qiita.com

Google Cloud BuildでRSpecのテストを行う #Rails - Qiita

先日、Google Cloud BuildとGithubの連携が発表され、CIの…

qiita.com

Cloud Runに紐づけるドメインのリソースをデプロイ

事前に独自ドメインに紐づけるリソースをCloud Runにデプロイしておきます。デプロイすると上の画像のようにサービスが追加されていることが確認できます。

マッピングの追加

Cloud Runのカスタムドメインを管理からマッピングの追加を行います。

Cloud Runにデプロイした独自ドメインと紐付けたいリソースを選択し、紐づける独自ドメインを入力します。

ドメインの確認ができていない場合は、ウェブマスターセントラルに進んで確認を完了させます。

DNSレコードの更新

所有権の証明が完了したら、DNSレコードを更新します。表示されたDNSレコードをCloud DNSに登録します。

今回は既に設定する独自ドメインがFirebase Hostingに紐づいているため、そのDNSレコードを削除して登録します。このタイミングでFirebase Hostingされている既存のサイトが見れなくなるので注意が必要です。

大体15分ほど経つと、Cloud Runのリソースに設定した独自ドメインが紐づきます。

上の画像のようにCloud Runのサービス詳細画面のURLにあるカスタムドメインの欄に紐付けたいドメインが表示されていれば完了です。

Firebase Hostingの画面で独自ドメインの設定が解除されたか確認

Firebase Hostingの画面にアクセスすると、ドメインの紐付けが解除されており、「設定が必要です」となっているため、後は必要に応じてドメインを削除しましょう。

Nuxt.jsのアプリをコンテナ化し、Container Registryに登録し、Cloud Runにデプロイする方法

Cloud BuildとCloud Runの有効化

まずはCloud Build APIとCloud Run APIを有効化しておきます。

# Cloud Buildの有効化
$ gcloud services enable cloudbuild.googleapis.com

# Cloud Runの有効化
$ gcloud services enable run.googleapis.com

nuxt.config.jsの変更

nuxt.config.jsにserverオプションを追加します。

hostはlocalhostや127.0.0.1ではなく、0.0.0.0に設定する必要があります。

・nuxt.config.js

export default {
  server: {
    port: 3000, // default: 3000
    host: '0.0.0.0', // default: localhost,
    timing: false
  }
}

cloudbuild.yamlを作成する

cloudbuild.yamlの書き方は以下の公式サイトを参考にしています。

コンテナイメージをビルドして、Container Registryにプッシュしています。その後、Container RegistryからCloud Runにデプロイしています。

参考：

Cloud Build を使用した Cloud Run へのデプロイ  |  Google Cloud Documentation

cloud.google.com

・cloudbuild.yaml

steps:
  # Build the container image
  - name: 'gcr.io/cloud-builders/docker'
    args: ['build', '-t', 'gcr.io/test-staging/nuxt-ssr', '.']
  # Push the container image to Container Registry
  - name: 'gcr.io/cloud-builders/docker'
    args: ['push', 'gcr.io/test-staging/nuxt-ssr']
  # Deploy container image to Cloud Run
  - name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
    entrypoint: gcloud
    args: ['run', 'deploy', 'nuxt-ssr-test', '--image', 'gcr.io/test-staging/nuxt-ssr', '--region', 'asia-northeast1', '--platform', 'managed', '--port', '3000']
images:
  - gcr.io/test-staging/nuxt-ssr

Dockerfileを作成する

次にNuxt.jsのアプリをコンテナ化するためにDockerfileを作成します。

参考：

Nuxt 2 - Google Cloud Run

Nuxt を Google Cloud Run にどうやってデプロイするのか？

ja.nuxtjs.org

・Dockerfile

FROM node:14

# https://docs.docker.jp/engine/reference/builder.html#workdir
WORKDIR /usr/src/app

COPY package.json ./
RUN npm install

COPY . .

# https://docs.docker.jp/engine/reference/builder.html#expose
# EXPOSE 命令はコンテナの実行時に、所定ネットワーク上のどのポートをリッスンするかを指定
EXPOSE 3000

RUN npm run build

CMD [ "npm", "run", "start" ]

gcloud initした後に以下のコマンドでcloudbuild.yamlのコマンドが走ります。

$ gcloud builds submit

成功すると、Container Registryにコンテナイメージが登録され、Cloud Runにコンテナがデプロイされていることが確認できます。

・Container Registry

・Cloud Run

Cloud Runにデプロイしたリソースにメンバーとロールの追加

Cloud Runにデプロイしたままでは、デプロイしたアプリは誰もアクセスすることができません。

アクセスできるようにするために、Cloud Runにデプロイしたリソースにメンバーとロールを追加します。

ここでは全てのユーザが見れるようにメンバーを「allUsers」にし、ロールを「Cloud Run起動元」で追加します。「allUsers」すると、デプロイしたリソースは一般公開され、インターネット上から誰でもアクセスできる状態になるため、注意していください。

保存後、Cloud Runに記載されているURLにアクセすることができるようになります。

Firebase HostingからCloud Runにリクエストをリダイレクトする

Firebase HostingでホスティングしたNuxt.jsプロジェクトを一部Cloud RunでSSRします。Cloud RunでSSRしたいリソースをfirebase.jsonのrewritesに追加します。

今回の場合は、/testsをCloud Runのリソースを使うようにします。つまり、/testsへのアクセスがあった場合にFirebase Hostingのリソースを使わずに、Cloud Runのリソースを使うようリクエストをリダイレクトします。

なおFirebase Hostingの/testsのリソースは空にしておかないと、正常にリダイレクトされないので注意しましょう。

serviceIdは先ほどデプロイしたCloud Runのサービス、regionはCloud Runで使用しているリージョンを選択します。後はfirebase.jsonをデプロイして完了です。

・firebase.json

...

  "rewrites": [
  {
    "source": "/tests",
    "run": {
      "serviceId": "nuxt-ssr-test",
      "region": "asia-northeast1"
    }
  }
],

...

Google Analytics Reporting APIの設定準備

Google Analytics Reporting APIの設定は以下の記事を参考にしました。

• プロジェクトの作成
• サービスアカウントの作成
• 秘密鍵のJSONファイルを生成 ← あとで使います
• Googleアナリティクスにユーザ追加
• ビューIDの確認 ← あとで使います

参考：Google Analytics API を叩いてデータを取得するまでの流れ（Ruby）

RailsでGoogleアナリティクスレポートデータ取得処理をクラス化

Googleアナリティクスレポートデータ取得処理を独自クラス化し、コントローラで使えるようにします。

先程生成した秘密鍵のJSONファイルは「analytics_auth.json」として配置し、authメソッドでGoogleアナリティクスAPIに認証を行ってからレポートデータを取得しにいきます。

report_pv_count_by_dateメソッドで、取得開始日と取得終了日を引数(デフォルトは当日)で指定してその期間のレポートデータを取得できるようにします。

・lib/analytics.rb

require 'google/apis/analyticsreporting_v4'

class Analytics

  # レポート対象を指定してオブジェクトを生成
  # @param [String] base_url レポート対象サイトのURL
  # @param [String] view_id ビューID
  def initialize(base_url, view_id)
    @base_url = base_url
    @view_id = view_id
    @analytics = Google::Apis::AnalyticsreportingV4
    auth
  end

  # 指定した期間のページごとのPVを集計
  # @param [String] date 日付を表す文字列
  # @return [Hash] 累計PV及びページごとのPV
  def report_pv_count_by_date(start_date = 'today', end_date = 'today')
    date_range = @analytics::DateRange.new(start_date: start_date, end_date: end_date)
    metric = @analytics::Metric.new(expression: 'ga:users', alias: 'users')
    dimension = @analytics::Dimension.new(name: 'ga:pagePath')
    order_by = @analytics::OrderBy.new(field_name: 'ga:users', sort_order: 'DESCENDING')
    request = @analytics::GetReportsRequest.new(
      report_requests: [@analytics::ReportRequest.new(
        view_id: @view_id,
        metrics: [metric],
        date_ranges: [date_range],
        dimensions: [dimension],
        order_bys: [order_by],
      )]
    )
    response = @client.batch_get_reports(request)
    data = response.reports.first.data
    return {
      total: data.totals.first.values.first,
      pages: data.rows.map do |row|
        {
          url: @base_url + row.dimensions.first,
          dir: row.dimensions.first,
          views: row.metrics.first.values.first
        }
      end
    }
  end

  private

  # GoogleアナリティクスAPIに認証
  # 同ディレクトリにanalytics_auth.jsonを配置
  def auth
    scope = ['https://www.googleapis.com/auth/analytics.readonly']
    @client = @analytics::AnalyticsReportingService.new
    @client.authorization = Google::Auth::ServiceAccountCredentials.make_creds(
      json_key_io: File.open('analytics_auth.json'),
      scope: scope
    )
  end

end

独自クラスを作成したら、呼び出せるようにapplication.rbに以下を追記します。

・config/application.rb

require_relative 'boot'

require 'rails/all'

# Require the gems listed in Gemfile, including any gems
# you've limited to :test, :development, or :production.
Bundler.require(*Rails.groups)

module AppName
  class Application < Rails::Application

    ...

    # 独自クラスパス指定
    config.autoload_paths += %W(#{config.root}/lib) ←追加

    ...

  end
end

uninitialized constantエラーで定義したクラスを読むことができない場合は、config/initializersディレクトリ配下にrequirements.rbファイルを作成し、以下を追記してください。

・config/initializers/requirements.rb

require Rails.root.join('lib/analytics.rb')

クラス化したGoogleアナリティクスレポートデータ取得メソッド呼び出し

実際にコントローラで呼び出してみます。初期化のBASE_URLとVIEW_IDは環境変数として.envに設定し呼び出して使うようにします。

フロントからパラメータ(取得開始日・取得終了日)をPOSTし、それらを引数にして実行しています。レスポンスはJSON形式で返すようにしています。

あとはroutes.rbにルーティングを設定して完了です。

・app/controllers/api/analytics_controller.rb

class Api::AnalyticsController < Api::ApplicationController

  def report
    analytics = ::Analytics.new(ENV['BASE_URL'], ENV['VIEW_ID'])

    render json: analytics.report_pv_count_by_date(params[:start_date], params[:end_date])
  end

end

以上、RailsでGoogle Analytics Reporting APIでレポートデータ取得する方法でした。

そもそもGoの本やGoに関する情報を読んだ感じ、多くのことが標準ライブラリでまかなえるため、基本はFWやORMを使わないのが「Goらしい手法」とのことなので、次は標準ライブラリのみでも実装してみたいと思います。

参考：https://employment.en-japan.com/engineerhub/entry/2018/06/19/110000

参考：https://golang.org/doc/effective_go.html

Ginとは

Ginとは軽量かつシンプルなインターフェイスが特徴のGoのWebアプリケーションフレームワークです。

また、GoのWebアプリケーションの中では比較的初期から開発されているので安定して使われています。

Gormとは

Goでよく使われているORMの一種です。

そもそもORM(O/Rマッピング)とは、オブジェクト指向言語におけるオブジェクトと、リレーショナルデータベースにおけるレコードとを対応づけることです。

ORMによって、リレーショナルデータベースのレコードがオブジェクトとして直感的に扱えるようになり、リレーショナルデータベースにアクセスするプログラムを記述する処理を容易にすることが可能になります。

プロジェクト構成

Getパラメータで本検索をして、その結果をJSON形式で返す簡単なAPIを実装していきます。

以下の記事を参考にプロジェクト構成を組んでみました。元々Railsを書いていたこともあり、この構成が今のところしっくりきました(今後勉強していくうちによりより構成が見つかる気がします)。

参考：https://qiita.com/Asuforce/items/0bde8cabb30ac094fcb4

sample-go-api
├── controller
│ └──book_controller.go
├── db
│ └── db.go
├── entity
│ └── book.go
├── main.go
├── server
│ └── server.go
├── service
│ └── book_service.go
├── .env.development
├── .env.production
├── .gcloudignore
├── .gitgnore
├── app.yaml
├── docker-compose.yml
├── go.mod
├── go.sum
├── main.go

DB・モデル実装

ローカル用にDockerでさくっとMySQLを立ち上げてDBを作成します。

・docker-compose.yml

version: '3'
services:
  mysql:
    image: mysql:5.7
    environment:
      MYSQL_ROOT_PASSWORD: password
      MYSQL_DATABASE: db
      MYSQL_USER: user
      MYSQL_PASSWORD: password
    ports:
      - "3306:3306"

docker-compose.ymlができたら、起動します。

$ docker-compose up -d

次にGormとMySQLをgo getでインストールします。

$ go get github.com/jinzhu/gorm
$ go get github.com/jinzhu/gorm/dialects/mysql

本モデルを作成します。

booksテーブルのカラムを定義します。

・entity/book.go

package entity

import (
  "time"
)

type Book struct {
  Id uint
  Title string `gorm:"size:128"`
  Category int
  Author string `gorm:"size:64"`
  CreatedAt time.Time
}

DB周りを実装していきます。今回はGAEに本番環境をデプロイするので、developmentとproductionと2つの環境を作りました。そのため、godotenvライブラリを使って実行する環境を取得します。

実行環境に合ったDB接続を行います。ローカルはDockerで立ち上げたMySQL、本番はCloud SQLを使っています。

DB初回起動時にマイグレーションが行われるようにしています。

・db/db.go

package db

import (
  "os"

  "github.com/jinzhu/gorm"
  _ "github.com/jinzhu/gorm/dialects/mysql"
  "github.com/joho/godotenv"

  "github.com/sample/sample-go-api/entity"
)

var (
  db *gorm.DB
  err error
)

// DB初期化
func Init() {
  // 実行環境取得
  env := os.Getenv("ENV")

  if "production" == env {
    env = "production"
  } else {
    env = "development"
  }

  // 環境変数取得
  godotenv.Load(".env." + env)
  godotenv.Load()

  // DB接続
  db, err = gorm.Open("mysql", os.Getenv("CONNECT"))

  if err != nil {
    panic(err)
  }

  autoMigration()
}

// DB取得
func GetDB() *gorm.DB {
  return db
}

// DB接続終了
func Close() {
  if err := db.Close(); err != nil {
    panic(err)
  }
}

// マイグレーション
func autoMigration() {
  db.AutoMigrate(&entity.Book{})
}

ローカル環境用のenv。

・.env.development

CONNECT=user:password@tcp(localhost:3306)/db?parseTime=true

本番環境用のenv。

・.env.production

CONNECT=user:password@unix(/cloudsql/sample-project:sample-zone:sample-instance)/sample_db?parseTime=true

Bookサービスの実装

検索処理を実装していきます。送られてきたGETパラメータからそれぞれのカラム検索を行います。

Gormを使っていますが、このくらいのSQLならわざわざORMを使わなくても良い気がしますね。

・service/book_service.go

package book

import (
  "github.com/sample/sample-go-api/db"
  "github.com/sample/sample-go-api/entity"
)

type Service struct{}

type book entity.Book

type Parameter struct {
  title string
  category int
  author string
}

// 検索
func (s Service) Search(title string, category int, author string) ([]Book, error) {

  // DB接続
  db := db.GetDB()

  // 本モデルから作成
  var book []Book

  // パラメータセット
  p := Parameter{title, category, author}

  // DB接続確認
  if err := db.Take(&book).Error; err != nil {
    return nil, err
  }

  // 本検索クエリ
  tx := db
  tx = tx.Find(&book)

  // タイトル
  if p.title != "" {
    tx = tx.Where("title = ?", p.title).Find(&book)
  }

  // カテゴリ
  if p.category != 0 {
    tx = tx.Where("category = ?", p.category).Find(&book)
  }

  // 著者
  if p.author != "" {
    tx = tx.Where("author = ?", p.author).Find(&book)
  }

  return book, nil
}

Bookコントローラの実装

Ginをgo getでインストールしておきます。

$ go get -u github.com/gin-gonic/gin

コントローラを実装します。*gin.ContextでGETパラメータを取得してサービスの検索メソッドに投げています。

検索結果を受け取ってJSON形式で返しています。

・controller/book_controller.go

package book

import (
  "fmt"
  "net/http"
  "strconv"

  "github.com/gin-gonic/gin"

  book "github.com/sample/sample-go-api/service"
)

type Controller struct{}

// 検索 GET /books
func (pc Controller) Index(c *gin.Context) {
  // パラメータ取得
  title := c.Query("title")
  category, _ := strconv.Atoi(c.Query("category"))
  author := c.Query("author")

  // 検索処理
  var s book.Service
  p, err := s.Search(title, category, author)

  // 検索結果を返す
  if err != nil {
    c.AbortWithStatus(http.StatusNotFound)
    fmt.Println(err)
  } else {
    c.JSON(http.StatusOK, p)
  }
}

サーバ周り実装

ルーティング・CORS設定・サーバ起動を実装しています。

・server/server.go

package server

import (
  "net/http"

  "github.com/gin-gonic/gin"

  book "github.com/sample/sample-go-api/controller"
)

// 初期化
func Init() {
  r := router()

  r.Run()
}

// ルーティング
func router() *gin.Engine {
  r := gin.Default()

  // CORS対応
  r.Use(CORS())

  // ルーティング
  u := r.Group("/books")
  {
    ctrl := book.Controller{}
    u.GET("", ctrl.Index)
  }

  return r
}

// CORS
func CORS() gin.HandlerFunc {
  return func(c *gin.Context) {
    c.Writer.Header().Set("Access-Control-Allow-Origin", "*")
    c.Writer.Header().Set("Access-Control-Allow-Credentials", "true")
    c.Writer.Header().Set("Access-Control-Allow-Headers", "Content-Type, Content-Length, Accept-Encoding, X-CSRF-Token, Authorization, accept, origin, Cache-Control, X-Requested-With")
    c.Writer.Header().Set("Access-Control-Allow-Methods", "GET, OPTIONS")

    if c.Request.Method == "OPTIONS" {
      c.AbortWithStatus(http.StatusNoContent)
      return
    }

    c.Next()
  }
}

main.goの実装

最後にmain.goからDBとサーバを起動して完了です。後は.gitignoreにenvファイルを追加しておきましょう。

package main

import (
  "github.com/sample/sample-go-api/db"
  "github.com/sample/sample-go-api/server"
)

func main() {
  db.Init()
  server.Init()
}

GAEにデプロイする

完成したAPIをGAEにデプロイします。

Goのバージョンは1.12、インスタンスクラスは一番下のF1を指定します(デフォルトF1ですが)。

正規表現 /.* にパスが一致するURLへのすべてのリクエストはmainパッケージのhandle関数で処理されます。

ENVでproductionを指定することでCloud SQLに接続するようにしています。

参考：https://cloud.google.com/appengine/docs/standard/go/config/appref?hl=ja

runtime: go112
service: sample-go-api-production
instance_class: F1
handlers:
  - url: /.*
    script: auto
env_variables:
  ENV: production

以下のコマンドでGAEにデプロイして完了です。

$ gcloud app deploy

Jamstack構成にあたり以下のサービスを活用しています。

• 静的サイトジェネレータ：Nuxt.js
• ヘッドレスCMS：microCMS
• ホスティングサービス：Firebase Hosting

Jamstackとは

Jamstack(ジャムスタック)とはウェブサイトを実現するためのJAMの頭文字からなる技術の組み合わせです。JAMはそれぞれJavaScript・API・ Markupを表しています。

Jamstackは、サーバとフロントを疎結合にし、サーバが担っていた機能を外部化してフロントだけで扱いやすくする構成となっています。

公式サイト：https://jamstack.org/

Jamstackの特徴

• Webサイトの各ページのHTMLファイルは事前に静的サイトジェネレータで生成
• ブラウザからアクセス時にCDNから配信
• Webサーバに依存しないサーバレスな構成

Jamstackは以上のような特徴が挙げられます。

閲覧専用でユーザごとにコンテンツの出し分けがないようなWebサービスに最も適していると考えられます。パッと思いつくのは、ユーザ認証等がないWebメディアやコーポレートサイトで効果を発揮しそうです。

Jamstackで使われるサービス

このようなJamstack構成を実現させるために、以下のようなサービスが使われます。

• 静的サイトジェネレータ
• ヘッドレスCMS
• ホスティングサービス

Jamstackアーキテクチャの採用にあたり今回開発した新規サービスでは、静的サイトジェネレータはNuxt.js、ヘッドレスCMSはmicroCMS、ホスティングサービスはFirebase Hostingを採用しています。

ホスティングサービスは他にNetlifyが有名(そもそもNetlifyのCEOがJamstack提唱したっぽい)で、そちらはWebhookによるトリガが可能(Firebase Hostingではできないっぽい？)なので、ヘッドレスCMSから記事投稿時にWebhookによる通知をして、自動ビルドできます。

Firebase Hostingでは調べた限りでは、Webhookによるトリガができないようなので、新規サービスではGitプッシュ時とスケジューリングで1日1回自動ビルドするように運用しています。どうしてもその日に公開したい記事の場合は手動でビルド・デプロイといった感じです。

Jamstack導入のメリット

Jamstackには以下のようメリットがあります。

・高パフォーマンス
→nuxt generateによってデプロイ前にあらかじめ静的ページを生成することでCDN配信が可能となり、より高いパフォーマンスを実現できました。

・高セキュリティ
→コンテンツ等はあらかじめ静的ファイルとしてホスティングしているため、サーバ側のプロセスが必要最低限のAPIに集約され、脆弱性に対する攻撃対象の減少が期待できます。

・コスト削減
→主にコンテンツ配信の手段として利用するため、コストの削減が可能となります。

・SEO向上
→SSGによるページ遷移の高速化・サーバ側でレンダリングしたHTMLを読み込むことにより、SEO向上が期待できます。

また、コンテンツにおけるAPIレスポンスは、ビルドのタイミングで全部取得してホスティングしているため、安定的な稼働が可能となります。

逆に言えば、ビルド時にAPIがおかしかったらエラーがでるため、デプロイ前に気づくことができるのも良い点かと思います。

Jamstack採用において

今回の新規サービスでは、認証機能やユーザ登録・更新処理などが追加実装されたため、完全なJamstack構成というより、部分的Jamstack構成になりました。

もし、認証機能やユーザ登録・更新処理などがなくコンテンツのみの場合は以下のような構成になります。

これが静的ファイルのみで構成される一般的なJamstack構成になると思います。Firebase HostingからCDN配信で完結しているため、サイトの高速化・高セキュリティ・サーバレスとなります。

なんとかヘッドレスCMSからの記事投稿をトリガに自動ビルド・デプロイできれば理想型って感じですかね。

実際の新規サービスでは認証機能等あるので、以下のような構成になります。

• コンテンツはあらかじめビルドしてある静的ファイルをFirebase HostingからCDN配信
• 認証はFirebase Authenticationを利用
• ユーザ登録やユーザ情報更新等は別途APIからやり取り

コンテンツの表示スピードの高速化やSEO向上、ユーザ情報登録・更新や検索のみサーバを使っているのでコストの削減もでき、Jamstackの恩恵を十分に受けられていると感じています。

まとめ

実際にJamstackアーキテクチャで新規サービスを開発してみて、サイトスピードが高速化し安定的に稼働していていい感じです。

毎回ビルドするといった手間はありますが、CI/CDツールを取り入れればそんな手間ではなくなります。

静的化できるファイルが多くある場合は、Jamstackアーキテクチャを取り入れるのが良さそうですね。

1つのFirebaseプロジェクトで複数サイトを登録することで、プロジェクト内のリソース(AuthenticationやStorageなど)を共有することができます。

参考：Share project resources across multiple sites

前提条件

前提条件として、既に1つのサイトがFirebase Hostingによって紐付けられデプロイされている状態として進めていきます。

また、プロジェクトを作成し定ない場合は、firebase initを実行して環境設定から行ってください。

また、Firebase CLIがインストールされてない場合は、以下のコマンドからインストールしてください。

$ npm install -g firebase-tools

Firebaseにてサイトの追加

既に1つサイトが存在し、2つ目以降のサイトを登録する場合、Firebase Hosting画面にてサイトを追加する必要があります。

Firebase Hosting画面の詳細設定から「別のサイトを追加」を押下します。

追加したサイト名を入力し、「サイトの追加」を押下します。

これで準備完了です。

デプロイターゲットの作成

複数のサイトを登録したら、それぞれにデプロイターゲットを作成する必要があります。

デプロイターゲットを作成し、サイトのホスティングを適用するには、プロジェクトのディレクトリのルートから以下のコマンドを実行します。

$ firebase target:apply hosting target-name resource-name

• target-name : デプロイ先であるHostingサイトの(自身で定義した)一意の識別子
• resource-name : Firebaseプロジェクトにリスト表示されるHostingサイトの名前

例えば、プロジェクトがsampleで先程のサイトの追加にsample-subを追加した場合、既にsample-siteがあり、sample-site2を追加する場合は、以下のコマンドで作成します。

・sample-siteの登録

サイト追加前の既にHostingされているsampleに対して、sample-siteを作成します。

$ firebase target:apply hosting sample-site sample

・sample-site2の登録

先程、サイト追加したsample-subに対して、新しく追加するsample-site2を作成します。

$ firebase target:apply hosting sample-site2 sample-sub

上記コマンドで作成が完了すると、.firebasercファイルに以下のように自動で追加されているのが確認できます。

・.firebaserc

...

  "targets": {
    "sample": {
      "hosting": {
        "sample-site": [
          "sample"
        ],
        "sample-site2": [
          "sample-sub"
        ]
      }
    }
  },

...

firebase.jsonをそれぞれのターゲットに合わせて編集

次に、先程作成したターゲットにあわせてfirebase.jsonを編集していきます。これでターゲットに合わせたデプロイが可能となります。

・firebase.json

{
  "hosting": [
    {
      "target": "sample-site",
      "public": "dist",
      "ignore": [
        "firebase.json",
        "**/.*",
        "**/node_modules/**"
      ],
      "rewrites" : [
        {
          "source": "**",
          "destination": "/index.html"
        }
      ]
    },
    {
      "target": "sample-site2",
      "public": "dist",
      "ignore": [
        "firebase.json",
        "**/.*",
        "**/node_modules/**"
      ],
      "rewrites" : [
        {
          "source": "**",
          "destination": "/index.html"
        }
      ]
    }
  ]
}

複数サイトのデプロイ方法

以下のコマンドで、指定したターゲットのリソースのみのデプロイします。

$ firebase deploy --only hosting:target-name

先程の例だと以下のコマンドを実行することで、それぞれをデプロイすることができます。

$ firebase deploy --only hosting:sample-site

$ firebase deploy --only hosting:sample-site2

「TypeError: Cannot read property ‘deploys’ of undefined」エラーで、デプロイが失敗する

「TypeError: Cannot read property ‘deploys’ of undefined」エラーで、デプロイが失敗する場合がありましたが、以下を参考にして解決しました。。

参考：Hosting deploy fails with multiple sites in the project · Issue #902 · firebase/firebase-tools

複数サイトのプロジェクトが別々の場合に発生しました。

登録する複数サイトが別々のプロジェクトであっても、同じFirebasenoプロジェクト内であれば、.firebaercとfirebase.jsonを共通に持っておく必要があります。

それぞれ別のプロジェクトだからそのプロジェクトだけのデプロイターゲットを作成するのではなく、FirebaseプロジェクトのHosting全てを設定ファイルを記載することで解決できました。

database.ymlの編集

database.ymlにステージング環境用と本番環境用のDB情報をそれぞれ追加します。

・database.yml

...

staging:
  adapter: mysql2
  encoding: utf8
  pool: 5
  timeout: 5000
  username: sample_stg
  password: sample_stg_pass
  database: sample_stg
  socket: /cloudsql/sample_stg:asia-northeast1:sample_stg

production:
  adapter: mysql2
  encoding: utf8
  pool: 5
  timeout: 5000
  username: sample_prod
  password: sample_prod_pass
  database: sample_prod
  socket: /cloudsql/sample_prod:asia-northeast1:sample_prod

...

app.yamlの編集

GAEにデプロイするステージング環境と本番環境のapp.yamlファイルを作成します。

今回はGAEのスタンダード環境で構築しています。「RAILS_ENV=」で環境を指定します。

また、env_variablesで環境変数を指定することもできます。

・app-staging.yaml

service: api--staging
runtime: ruby25
entrypoint: RAILS_ENV=staging bundle exec rails s -e staging
env_variables:
  SAMPLE_API_KEY: 'SAMPLE_STAGING_API_KEY'

・app-production.yaml

service: api--production
runtime: ruby25
entrypoint: RAILS_ENV=production bundle exec rails s -e production
env_variables:
  SAMPLE_API_KEY: 'SAMPLE_PRODUCTION_API_KEY'

dispatch.yamlの作成

dispatch.yamlを作成し、ドメインとサービスを紐づけます。これでGAEのサービスにデプロイした際に、指定したURLに割り当てることができます。

・dispatch.yaml

dispatch:
- url: "*stg.sample.com/*"
service: api--staging
- url: "*sample.com/*"
service: api--production

dispatch.yamlが作成できたら、以下のコマンドでデプロイします。

$ gcloud app deploy dispatch.yaml

Railsプロジェクトをステージング環境と本番環境にそれぞれデプロイ

ここまで準備が完了したら、実際にRailsプロジェクトをそれぞれの環境にデプロイします。

■ステージング環境

デプロイする前にRailsアセットをコンパイルします。

$ RAILS_ENV=staging bundle exec rails assets:precompile

app-staging.yamlを指定してデプロイします。

$ gcloud app deploy app-staging.yaml

■本番環境

ステージング環境と同様、デプロイする前にコンパイルします。

$ RAILS_ENV=production bundle exec rails assets:precompile

app-production.yamlを指定してデプロイします。

$ gcloud app deploy app-production.yaml

デプロイする際に、target serviceがそれぞれの環境が選択できているか確認しておきましょう。

target service: [api--staging]

マイグレーション・シードの実行

マイグレーションとシードもそれぞれの環境に合わせて行いますappengineを使ってマイグレーションを実行します。

シード処理は時間がかかることがあるので、デフォルトの10分を30分まで伸ばしています。

■ステージング環境

マイグレーション処理

$ bundle exec rake appengine:exec GAE_SERVICE=api--staging -- bundle exec rails db:migrate RAILS_ENV=staging

シード処理

$ bundle exec rake appengine:exec GAE_SERVICE=api--staging GAE_TIMEOUT=30m -- bundle exec rails db:seed RAILS_ENV=staging

■本番環境

マイグレーション処理

$ bundle exec rake appengine:exec GAE_SERVICE=api--production -- bundle exec rails db:migrate RAILS_ENV=production

シード処理

$ bundle exec rake appengine:exec GAE_SERVICE=api--production GAE_TIMEOUT=30m -- bundle exec rails db:seed RAILS_ENV=production

① ハマりポイント「Errno::EROFS: Read-only file system @ rb_sysopen – /srv/db/schema.rb」

追加のマイグレーションファイルを作成し、実行するときにエラー発生。schema.rbが読み取り専用のため(スタンダード環境だから？)、実行できずにハマる。。

$ bundle exec rake appengine:exec GAE_SERVICE=api--staging -- bundle exec rails db:migrate

[STDERR] rails aborted!
[STDERR] Errno::EROFS: Read-only file system @ rb_sysopen - /srv/db/schema.rb

解決策として、作成したマイグレーションファイルのバージョンを指定することで実行できました。

$ bundle exec rake appengine:exec GAE_SERVICE=api--staging -- bundle exec rails db:migrate:up VERSION=20200401000000

[STDOUT] == 20200401000000 AddColumnTests: migrating ===================
[STDOUT] -- add_column(:tests, :test_id, :string, {:null=>true, :after=>:sample_id})
[STDOUT] -> 0.0461s
[STDOUT] == 20200401000000 AddColumnTests: migrated (0.0462s) ==========
[STDOUT]

EXIT STATUS: 0

②ハマりポイント「Cannot run migrations because another migration process is currently running.」

マイグレーション対象のDBに接続した状態で、実行するとエラー発生。

[STDERR] rails aborted!
[STDERR] ActiveRecord::ConcurrentMigrationError:
[STDERR]
[STDERR] Cannot run migrations because another migration process is currently running.

DBにログインし、以下のコマンドで処理中のプロセスの一覧を表示し、該当のプロセスを終了させて再度実行すれば通ります。

$ SHOW PROCESSLIST

以上、GAEでRailsのステージング環境と本番環境を構築する方法を紹介しました。

参考：外部アプリケーションから Cloud SQL に接続する | Cloud SQL for MySQL

前提条件

Cloud SQLをローカルのクライアントツールに接続する前提として以下が当てはまっていることが条件です。

• Cloud SQL AdminAPIが有効化されていること
• Cloud SQLのインスタンスが作成されていること
• Cloud SQLにDB・ユーザが作成されていること

プロキシクライアントのインストール

ローカルから認証に必要なプロキシクライアントをインストールします。

Macの場合は以下のコマンドでダウンロードします。他のOSからのコマンドは以下の公式を参考にしてください。

参考：ローカルマシンにプロキシ クライアントをインストールする

$ curl -o cloud_sql_proxy https://dl.google.com/cloudsql/cloud_sql_proxy.darwin.amd64

プロキシの実行権限を付与します。

$ chmod +x cloud_sql_proxy

サービスアカウントの作成

次にローカルからCloud SQLに接続する際に、認証で必要となるサービスアカウントを作成します。

GCPの「IAMと管理」からサービスアカウントを選択します。「サービスアカウントを作成」を押下します。

以下の項目を入力し、作成を押下します。

• サービスアカウント名
• サービスアカウントID
• サービスアカウントの説明

役割は「Cloud SQL クライアント」を選択し、続行を押下します。

「キーを作成」を押下します。

キーのタイプは「JSON」を選択し、作成を押下します。すると認証ファイルがダウンロードされるので、保存します。今回は、sample-key.jsonというファイル名で保存します。

プロキシの起動

先ほどインストールしたプロキシを起動します。

• instances : インスタンス接続名
• tcp : 13306
• credential_file : 先ほど保存した認証ファイル

$ ./cloud_sql_proxy -instances=<インスタンス接続名>=tcp:13306 -credential_file=sample-key.json

起動し以下のように「Ready for new connections」が表示され、正常に起動できていることを確認します。

2020/03/10 19:56:57 using credential file for authentication; email=sample@<project_id>.iam.gserviceaccount.com
2020/03/10 19:56:58 Listening on 127.0.0.1:13306 for <インスタンス接続名>
2020/03/10 19:56:58 Ready for new connections

DBeaverに接続

いよいよDBeaver(クライアントツール)に接続します。

以下を入力して接続完了です。

• Server Host : ローカルループバックアドレス
• Port : 先ほど指定したポート
• Database : Cloud SQLで作成したDB名
• User name : Cloud SQLで作成したユーザ名
• Password : Cloud SQLで作成したユーザのパスワード

接続時に「Communications link failure」エラー

最後のクライアントからの接続時に以下のエラーでハマりました。

Communications link failure
The last packet sent successfully to the server was 0 milliseconds ago. The driver has not received any packets from the server.
Can not read response from server. Expected to read 4 bytes, read 0 bytes before connection was unexpectedly lost.

ログを確認すると以下のエラーが表示されていました。調べてみるとどうやら接続の問題のようですが、特に問題なさそう。

[Note] Aborted connection xxx to db: 'sample' user: 'sample' host: 'cloudsqlproxy~xxxxx' (Got an error reading communication packets)

タイムアウトやbuffer_sizeを増やしたり、あれこれ設定を変更するが解決できず。。

結局、原因は会社で使用しているWiFiでした。試しにWiFiをオフにして、テザリングを使ってみると、問題なく接続できました。

基本的には以下の公式を参考に環境構築しています。

• Running Rails 5 on App Engine flexible environment | Ruby
• Using Cloud SQL for MySQL with Rails 5 | Ruby

前提条件

デプロイするRailsプロジェクトが以下に当てはまっていることが前提条件です。

• Ruby バージョン2.3.4以降をインストール
• Rails 5 gem をインストール
• Bundler gem をインストール

必要なAPIを有効化

データストア、Pub / Sub、Cloud Storage JSON、Stackdriver Logging、およびGoogle+必要なAPIを有効にします。

app.yamlの作成

GAEにデプロイするRailsアプリのディレクトリ直下にapp.yamlを作成します。

今回はスタンダード環境なので「env: flex」はコメントアウトしておきます。またapp.yamlに環境変数を書くことでGAEに環境変数を渡せます。

secret keyは以下のコマンドで確認できます。

$ bundle exec rails secret

・app.yaml

entrypoint: bundle exec rackup --port $PORT
runtime: ruby25
# env: flex
env_variables:
    SECRET_KEY_BASE: < Your secret key>

GAEにデプロイしたアプリはDocker上で動くためDockerfileがプロジェクト直下にあるとruntime rubyでデプロイができません。

runtime rubyでデプロイする場合は、DockerfileをDockerfile-devなどに置き換えておきましょう。

.gcloudignoreの作成

デプロイしないファイルを指定するために.gcloudignoreファイルを作成します。

・.gcloudignore

.gcloudignore
#!include:.gitignore
.git
.gitignore

!/public/assets

MySQL用Cloud SQLをセットアップ

RailsアプリでCloud SQLを使用するために、mysql2とappenginegemをGemfileファイルに追加します

$ bundle add mysql2
$ bundle add appengine

以下のコマンドでインスタンス接続名を取得できます。
gcloud sql instances describe < インスタンス名 >

・database.yml

production:
    adapter: mysql2
    encoding: utf8
    pool: 5
    timeout: 5000
    username: < username >
    password: < password >
    database: < database >
    socket: /cloudsql/< インスタンス接続名 >

GAEにデプロイ

以下のコマンドで、GAEアプリを作成します。

$ gcloud app create

デプロイする前に、Railsアセットをプリコンパイルします。

$ bundle exec bin/rails assets:precompile

アセットのコンパイルが完了したらGAEにデプロイします。

$ gcloud app deploy

マイグレーションでテーブル作成

以下のコマンドでプロジェクトを一覧表示できます。アプリのデプロイに使用するプロジェクトを見つけ、プロジェクト番号をコピーします。

$ gcloud projects list

roles/editorデータベース移行を実行するロールのプロジェクトIAMポリシーに新しいメンバーを追加します。

$ gcloud projects add-iam-policy-binding < YOUR-PROJECT-ID > --member=serviceAccount: < PROJECT_NUMBER > @cloudbuild.gserviceaccount.com --role=roles/editor

先ほど追加したappengineを使用して、Cloud SQL上でのマイグレーションを実行します。

$ bundle exec rake appengine:exec -- bundle exec rake db:migrate

Cloud SQL画面の「Cloud Shellを使用して接続」から以下のコマンドで接続し、実際にテーブルが作成されたか確認してみましょう。

$ gcloud sql connect < インスタンス名 > --user=< username > --quiet

以降のデプロイ

以降、ソースを更新して再度デプロイする場合は以下のコマンドで実行する流れになります。

$ bundle exec bin/rails assets:precompile
$ gcloud app deploy
$ bundle exec rake appengine:exec -- bundle exec rake db:migrate

ハマりポイント

① コンパイル時にエラー

コンパイル時に以下のエラーが発生。

Note: Google::Cloud::Logging is disabled because it failed to authorize with the service.
Note: Google::Cloud::Debugger is disabled because it failed to authorize with the service.
Note: Google::Cloud::ErrorReporting is disabled because it failed to authorize with the service.
Note: Google::Cloud::Trace is disabled because it failed to authorize with the service.

develop環境では使用しないようfalseにすることで解決しました。

・development.rb

config.google_cloud.use_logging = false
config.google_cloud.use_debugger = false
config.google_cloud.use_error_reporting = false
config.google_cloud.use_trace = false

② MySQLに接続できない

以下のエラーによりCloud SQLのMySQLに接続できずハマり。。

[STDERR] rake aborted!
[STDERR] Mysql2::Error::ConnectionError: Unknown MySQL server host '/cloudsql/< インスタンス接続名 >' (2)

公式ではdatabase.yamlの「/cloudsql/< インスタンス接続名 >」の箇所がhostとなっていたため、hostで書いていたのですが、socketに変更することで解決しました。。

参考：

ruby-docs-samples/appengine/rails-cloudsql-postgres/config/database.yml at 0a6e898a1acd140ca04c63c7b68da1468acb4082 · GoogleCloudPlatform/ruby-docs-samples · GitHub

Ruby samples for Google Cloud Platform p…

github.com

・修正前

production:
    adapter: mysql2
    encoding: utf8
    pool: 5
    timeout: 5000
    username: < username >
    password: < password >
    database: < database >
    host: /cloudsql/< インスタンス接続名 >

・修正後

production:
    adapter: mysql2
    encoding: utf8
    pool: 5
    timeout: 5000
    username: < username >
    password: < password >
    database: < database >
    socket: /cloudsql/< インスタンス接続名 >

③ GAEのデフォルトTime Outが10分なためSeedが完了しない

GAEのデフォルトタイムアウトが10mのため、Seedが完了せず途中で終了してしまう。。

TIMEOUT: 10m

GAE_TIMEOUTオプションでタイムアウトを伸ばすことができました。1h23m45sの形式で指定できます。

bundle exec rake appengine:exec GAE_TIMEOUT=30m -- bundle exec rake db:seed

参考：

How to set the value of timeout? · Issue #26 · GoogleCloudPlatform/appengine-ruby · GitHub

Could not find this documented anywhere …

github.com

以上、Google App EngineのRuby 2.5 StandardでRails環境構築する方法とCloud SQLのMySQLとの接続方法でした。