ngrokが最近メジャーバージョンアップして、バージョン3がリリースされましたので、アップグレード手順を紹介します。

なお、設定ファイルは、下位互換性がなくなっているので、ngrok本体のアップグレード後には、設定ファイルのアップグレードが必要になります。

ngrok本体のアップグレード

当サイトの導入記事で紹介したように、Homebrewでcask（Mac用アプリケーション）としてngrokをインストールしている場合は、以下のコマンドで本体をアップグレードします。

% brew upgrade ngrok

ちなみに、ngrokには、ngrok update コマンドもありますが、このコマンドではメジャーバージョンアップはされません。

アップグレード後にバージョンを確認するには、以下を実行します。

% ngrok version
ngrok version 3.0.6

なお、この直後に、ngrokを起動すると以下のようなエラーが出るため、後述の設定ファイルのアップグレードが必要になります。

% ngrok http 3000
ERROR:  Error reading configuration file '/Users/<your-os-user>/.ngrok2/ngrok.yml': `version` property is required.
ERROR:  
ERROR:  If you're upgrading from an older version of ngrok, you can run:
ERROR:  
ERROR:      ngrok config upgrade
ERROR:  
ERROR:  to upgrade to the new format and add the version number.

設定ファイルのアップグレード

% ngrok config upgrade

これで、~/.ngrok2/ngrok.ymlファイルが更新されて、通常通りngrokが使用できるようになります。

Precena Tech Bookとは

株式会社プレセナ・ストラテジック・パートナーズのエンジニアのための知識ベースとして使用しているオンラインサイトです。

株式会社プレセナ・ストラテジック・パートナーズにおけるシステム開発で発生した各種調査、検討結果や他のメンバーへ共有したいノウハウなどのうち、社外にも公開できるものをコンテンツとして蓄積しています。

掲載コンテンツ

以下のような分野に関係するコンテンツを記載しています。

• ソフトウェア開発

• インフラ開発

• セキュリティ

上記以外も、システム開発時に新たに進出した分野があれば追加していく予定です。

想定読者

• 株式会社プレセナ・ストラテジック・パートナーズ社内のエンジニア、デザイナー

• 社外のシステムエンジニア、デザイナー

免責事項

本サイトのコンテンツは可能な限り正確を期して記載していますが、本サイトのコンテンツに基づく運用結果については、株式会社プレセナ・ストラテジック・パートナーズは責任を負いかねますので、ご了承の上、内容を閲覧してください。

更新情報

この記事は、独特なネーミングがされていて、知っているようで知らないHomebrewの用語の意味を正しく理解するために書きました。

用語一覧

Homebrewは「自家醸造」の意味です。この「醸造」の世界観の元で、Homebrewで扱う一部の概念の名前がつけられていて、直感的に何を指すのかが少しわかりにくいことがあります。

インストール関連のトラブルやPATHを通すパッケージのバージョンを調整したいときに、これらの用語を知っていると、エラー・警告メッセージの内容や、brew info コマンドなどで説明されている内容を理解しやすくなると思います。

ngrokとは

ngrokでホストされるURL（例：http://xxxx.ngrok.io/ ）へのアクセスをローカル環境のwebサーバー（http://localhost:3000 など）にトンネリングしてくれます。

例えば、stripeやLINE、その他クラウドサービスのwebhook処理を開発する際に、インターネット上に本番やステージングのwebサーバーを構築する前に、ローカル開発環境でwebhookへの対応コードを実装、テストすることができるようになります。

この記事では、ngrokの開発環境を用意する手順を紹介します。

ngrokのインストール

% brew install --cask ngrok

ngrokアカウントのサインアップ

auth tokenの設定

% ngrok authtoken <your-token>

そうすると、~/.ngrok2/ngrok.yml にtokenの値が書き込まれてサインアップしたngrokアカウントが認識されるようになります。

ngrokエージェントの起動

トンネリングを開始するためには、以下のようなコマンドを実行します。

% ngrok http 3000

これで、以下のような情報がコンソールに表示され、トンネリングに使えるURLが分かります。

ngrok by @inconshreveable                                                                                                                                                                                       (Ctrl+C to quit)
                                                                                                                                                                                                                                
Session Status                online                                                                                                                                                                                            
Account                       <your account name>(Plan: Basic)                                                                                                                                                                        
Update                        update available (version 2.3.40, Ctrl-U to update)                                                                                                                                               
Version                       2.3.35                                                                                                                                                                                            
Region                        United States (us)                                                                                                                                                                                
Web Interface                 http://127.0.0.1:4040                                                                                                                                                                             
Forwarding                    http://<your-random-subdomain>.ngrok.io -> http://localhost:3000                                                                                                                                             
Forwarding                    https://<your-random-subdomain>.ngrok.io -> http://localhost:3000                                                                                                                                            
                                                                                                                                                                                                                                
Connections                   ttl     opn     rt1     rt5     p50     p90                                                                                                                                                       
                              0       0       0.00    0.00    0.00    0.00                                                                                                                                                      
                                                                                               

この記事では <your-random-subdomain> と記載しましたが、ここに、トンネリングで使えるインターネットアクセス可能なURLが表示され、また、そのURLがローカルのhttp 3000番ポートにトンネリングされているのが分かります。

この一般公開されているURLをクラウドサービスのwebhookのエンドポイントとして指定しておけば、ローカル環境のwebサーバーを使って動作確認をしながら開発を行うことができます。

ngrokのサブドメインの固定

無償のアカウントでは、ngrokを起動するたびに、http://<your-random-subdomain>.ngrok.io の <your-random-subdomain> の部分がランダムなサブドメインになってしまい、そのたびに、クラウドサービス側の呼び出し先設定を更新しなければなりません。

これは、ngrokの有償登録をすることで固定化できます。有償登録をすると、以下のようにサブドメインを他のユーザーが使っていない任意の文字列に固定できます。

% ngrok http 3000 -subdomain=<任意の固定したいサブドメイン>

ngrokのアップデート

ngrok起動中のコンソールでCtrl+U でアップデートが開始されます。

当社の日常業務の中で、Slackのリマインダーを設定することは、頻繁にあります。

しかし、Slackのコマンドを使ってリマインダーを指定する際、とくに、日時の指定の仕方を中々覚えられず、公式ヘルプを見に行くことが多いです。

公式ヘルプにも詳しく載ってはいるのですが、特に「When」を指定する部分について、この記事では、一覧で分かるように紹介します。チートシート的な使い方を想定しています。

/remind コマンドの形式

/remind コマンドのフォーマットは以下です。

/remind [@someone or #channel] [what] [when]

この[what] の部分まではわかりやすいのですが、この記事では最後の[when] の部分を詳細に紹介します。

/remind コマンドの[when]の部分の形式

[when]の部分は、以下のように、細かく指定することが出来ます。

現在からの相対的な時間で指定する場合

x分後、x日後、x週間後など、現在からの相対的な時間で指定する場合、in を使います。

/remind #channel 2秒後の例 in 2 seconds

※秒を指定しても、そこまで正確なタイミングではリマインドされないようです。

/remind #channel 2分後の例 in 2 minutes

/remind #channel 2時間後の例 in 2 hours

/remind #channel 2日後の例 in 2 days

なお、時間を指定せずに相対的な日付を指定すると、指定した日の9:00になるようです。

/remind #channel 2週間後の例 in 2 weeks

2日後のX時、など細かい時間を指定したい場合は、atも併用します。

/remind #channel 2日後10時amの例 at 10:00am in 2 days

ワンタイムの日時を指定する場合

次ように、at とon を使って、時間と日付を指定します。

/remind #channel 日時指定の例 at 10:00am on 1st Feb

次のように曜日を指定すると、指定した曜日が次に来る日に投稿されます。

/remind #channel 曜日指定の例 at 10:00am on Mon

リマインドの頻度を指定する場合

この使い方が一番多い気がします。末尾にevery をつけて頻度を指定します。

毎月月初にやらないと行けないタスクをリマインドさせるなどに便利です。

/remind #channel 毎月1日の例 on 1st every month

この場合もat とon を併用できます

/remind #channel 毎月1日の10:00am at 10:00am on 1st every month

[what]にスペースを入れたい場合

以下のように、特に" で囲んだりせずに、普通に指定できます。

/remind #channel aaaaa bbbbb ccccc on 1st Feb

インストール

公式サイトでインストーラーをダウンロードしてインストールしてください。

設定

基本的に以下の公式サイトに従うだけです。

公式サイトにも載っている内容ですが、以下のコマンドを入力して、

% aws configure

以下4つの項目を設定すればOKです。

• AWS Access Key ID

• AWS Secret Access Key

• Default region name

• Default output format

追加の設定

次に、多くの場合に必要となるjqとSession Manager pluginをインストールします。

jqのインストール

% brew install jq

AWS Session Manager pluginのインストール

以上。

当社の開発で使うRubyのバージョンは、プロジェクトごとに異なることが多く、また、プロジェクトごとにRubyのアップデート状況も異なります。

したがって、プロジェクトごとにRubyのバージョンを切り替える仕組みとしてrbenvを導入して使います。

rbenvのインストール

直接rbenvをインストールするか、anyenv経由でインストールするかで手順が変わります。

anyenvでインストールする場合

anyenvがすでに導入されている場合、以下で簡単にrbenvをインストールできます。

% anyenv install rbenv

直接rbenvをインストールする場合

まずは、homebrewでrbenvをインストール。このとき、ruby-buildも同時にインストールされます。

% brew install rbenv

次に、

% rbenv init

を実行して、出力された手順にしたがって、シェルの設定を行います。zshを使っている場合、以下のように出力されるので、この内容に従います。

% rbenv init
# Load rbenv automatically by appending
# the following to ~/.zshrc:

eval "$(rbenv init -)"

つまり、.zshrcファイルに以下を追加します。

# rbenvの初期化
eval "$(rbenv init -)"

使いたいバージョンのRubyをインストール

rbenvがインストールされたら、次は、使いたいバージョンのRubyをインストールします。

まずは、インストール可能なRubyの安定バージョンを確認します。

% rbenv install -l
2.6.7
2.7.3
3.0.1
jruby-9.2.17.0
mruby-3.0.0
rbx-5.0
truffleruby-21.1.0
truffleruby+graalvm-21.1.0

Only latest stable releases for each Ruby implementation are shown.
Use 'rbenv install --list-all / -L' to show all local versions.

ここに表示されたバージョンを指定して、開発環境にインストールします。

% rbenv install 2.7.3

プロジェクトで使うRubyのバージョンを固定

プロジェクトで使うRubyのバージョンは、他の開発メンバーとも共有したいため、.ruby-versionファイルを作って、他のメンバーにも同じRubyのバージョンの使用を強制できるようにします。

プロジェクトルートで、以下を実行すれば.ruby-versionファイルがプロジェクトルート直下に作られます。

% rbenv local 2.7.3

Rubyのバージョンを上げる

Rubyのバージョンを上げる手順もanyenvでrbenvをインストールしたかどうかで異なります。

anyenvでrbenvをインストールした場合

rbenv install -lコマンドで、インストールしたいRubyのバージョンが表示されていない場合、anyenv内部のruby-buildのアップデートが必要です。このアップデートのコマンドを楽にしてくれるanyenv-updateを使うのをおすすめします。

anyenv-updateが設定してあれば、以下を実行するだけで、インストール可能なRubyのバージョン情報が最新化されます。

% anyenv update

このあとは、普通に特定のバージョンのRubyをインストールします。

直接rbenvをインストールした場合

同様に、インストールしたいRubyのバージョンが表示されていない場合、先に、rbenvとruby-buildをアップデートする必要があります。rbenvとruby-buildのアップデートにはhomebrewを使います。

% brew upgrade rbenv ruby-build

これで、インストール可能なRubyのバージョンが最新化されるので、特定のバージョンをインストールします。

Prettierとは

以下、開発プロジェクトへのインストール手順を説明します。

Prettierのインストール

開発プロジェクトにおいて、yarnでnodeパッケージが管理されている前提です。

まずは、開発環境のみの依存パッケージとして、prettier をインストールします。

% yarn add --dev prettier

prettier-rubyのインストール

必要に応じて、prettier-rubyもインストールします。

% yarn add --dev @prettier/plugin-ruby

Prettierの設定ファイルを追加

プロジェクトルートに以下のファイルを作成します。

{
  "semi": false,
  "singleQuote": true,
  "trailingComma": "none",
  "bracketSpacing": false,
  "endOfLine": "lf",
  "printWidth": 120
}

上記の設定は、当社で使っているデフォルトの設定です。例えば、printWidthは、デフォルトの80だと少し狭く、フォーマットしたときに、過度に改行が入ってしまうため、120にしています。

Prettierのignore設定を追加

Railsのroutesファイルなどのように、なるべく改行をせずに一行で書いてしまいたいような特殊なコードは、pretterでのフォーマットがかからないように、ignoreファイルをプロジェクトルートに追加します。

node_modules
yarn.lock
package-lock.json
public

/config/routes.rb

Linterとの競合回避

RuboCop

inherit_from:
  - node_modules/@prettier/plugin-ruby/rubocop.yml # rubocopのルールと衝突しないための設定

また、これ以外にも、rubyの後置ifや後置whileなどのフォーマットをprettierにまかせてしまいたいので、以下のように.rubocop.ymlにルールを追加します。

# 後置ifのフォーマットはprettier-rubyに任せたいので、rubocopのチェックは外す
Style/IfUnlessModifier:
  Enabled: false

# 後置while、untilのフォーマットもprettier-rubyに任せたいので、rubocopのチェックは外す
Style/WhileUntilModifier:
  Enabled: false

Editorの設定

以下、RubyMineやVisual Studio Codeの設定を各自行います。

RubyMine

JavaScriptやTypeScriptだけでなく、Rubyもフォーマットの対象にする場合は、設定画面で、Preferences -> Languages & Frameworks -> JavaScript -> Prettier から、Prettier Packageを{Project Root}/node_modules/prettierに設定した上で、Run for filesの部分でrbも含まれるように、以下のように変えておきます。

{**/*,*}.{js,ts,jsx,tsx,rb,rake}

On save のチェックをいれておくと、⌘S を押したときにフォーマットがかかります。 設定保存後もprettierが動作しない場合は、一度RubyMineを再起動するとうまくいきます。

Visual Studio Code

上記プラグインをインストールした上で、以下のように、.vscode/settings.jsonをプロジェクトルートに追加して、言語ごとにフォーマットの設定をします。チームメンバーのvscodeの設定状況によっては、このファイルはリポジトリにpushして他のメンバーと共有してもよいです。

{
  "[ruby]": {
    "editor.formatOnSave": true,
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  "[javascript]": {
    "editor.formatOnSave": true,
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  "[typescript]": {
    "editor.formatOnSave": true,
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  "[javascriptreact]": {
    "editor.formatOnSave": true,
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  "[typescriptreact]": {
    "editor.formatOnSave": true,
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  }
}

なお、editor.formatOnSaveは任意の設定で、保存時に自動的にフォーマットをかけるかを設定します。

想定環境

• OS：Mac

• Scala：2.13.6

Java と sbt のインストール

Scala を使うには Java と sbt が必要になります。バージョン管理ツールを2つ紹介しますが、どちらを使っても構いません。

• SDKMAN

  • Java と sbt どちらもこれ一つでインストールできるので、 anyenv を使っていないのであればこちらがおすすめです。

• anyenv + jenv + sbtenv

  • anyenv ですべて管理したい人向けです。

JDK と バージョンについて

また、Java には LTS バージョンが設定されており、このバージョンのみをサポートしているライブラリも多いです。特段の理由がなければ、最新版ではなく 8 や 11 といった LTS バージョンをインストールするのが良いと思います。

SDKMAN

% curl -s "https://get.sdkman.io" | bash

下記コマンドを実行してバージョンを確認してみます。 sdk-man-init.sh の実行は .bash_profile 等の末尾に追加されているので、次からはターミナルを開いた時に自動実行されます。

% source "$HOME/.sdkman/bin/sdkman-init.sh"
% sdk version

SDKMAN 5.12.2

バージョン管理ツールがインストールできたので、 Java と sbt をインストールします。

Java は 8系と 11系が LTS なので、どちらかをインストールします。選択肢が多いのですが、前項で述べた通り Temurin を選択します。

# インストール可能な Java のバージョン一覧を確認
% sdk list java

# 11.0.12-tem をインストール
% sdk install java 11.0.12-tem

# インストールできた事を確認
% java --version
openjdk 11.0.12 2021-07-20
OpenJDK Runtime Environment Temurin-11.0.12+7 (build 11.0.12+7)
OpenJDK 64-Bit Server VM Temurin-11.0.12+7 (build 11.0.12+7, mixed mode)

sbt はとりあえず新しいバージョンを入れておけば良いと思います。

# インストール可能な sbt のバージョン一覧を確認
% sdk list sbt

# 1.5.5 をインストール
% sdk install sbt 1.5.5

# インストールできた事を確認
% sbt --version
sbt version in this project: 1.5.5
sbt script version: 1.5.5

ディレクトリ内で特定のバージョンを有効にするには、 sdk env コマンドを利用します。

% sdk env init
.sdkmanrc created.

% cat .sdkmanrc
# Enable auto-env through the sdkman_auto_env config
# Add key=value pairs of SDKs to use below
java=11.0.12-tem

すると .sdkmanrc ファイルが生成され、デフォルトでカレントバージョンが設定されるので、これを利用したいバージョンに変えればOKです。ただ、コメントにもあるように ~/.sdkman/etc/config の sdkman_auto_env を true にしなければ自動的に適用されないので設定しておきましょう。

ちなみに Metals を使ったプロジェクトの場合、 sbt のバージョンに関しては project/build.properties を参照してくれるため、バージョン指定は不要です。

anyenv + jenv + sbtenv

anyenvを利用する場合、java, sbtのバージョン管理ライブラリはそれぞれjenv, sbtenvを利用することになります。jenvはrbenvやnodenvと違って言語のインストール機能は持っていないため、JDKは手動でインストールし、jenvに読み込ませる必要があります。

環境構築の流れは以下の通りです。

1. anyenvのインストール

2. JDKのインストール

3. jenvのインストール＆設定

4. sbtenvのインストール＆設定

anyenvのインストール

JDKのインストール

% brew tap homebrew/cask-versions

インストール可能なJDKを検索するとtemurin11が表示されるようになりますので、これをインストールします。複数のJavaバージョンを切り替えて利用したい場合、ここで必要な分だけインストールしておきましょう。

% brew search --cask temurin # インストール可能なバージョンを表示
% brew install --cask temurin11
% ls -l /Library/Java/JavaVirtualMachines # インストールされたJDKを確認

これでJDKのインストールは完了です。

jenvのインストール＆設定

anyenvの通常の使い方に沿い、以下コマンドでjenvをインストールします。

% anyenv install jenv
% exec $SHELL -l
% jenv --version # インストールされたことを確認

jenvのexportプラグインを有効化しておきましょう。

% jenv enable-plugin export
% exec $SHELL -l

インストールしたJDKのHomeディレクトリをjenvに認識させます。複数のJDKをインストールした場合はそれぞれ実施しましょう。ここで認識させたJDKがjenvのバージョン切り替え対象に加わります。

% jenv add /Library/Java/JavaVirtualMachines/temurin-11.jdk/Contents/Home
% exec $SHELL -l
% jenv versions # jenvで切り替え可能なJDKの一覧が表示される

jenvで利用するバージョンを指定します。

% jenv local 11.0.12

これを行うと実行したディレクトリに.java-versionというファイルが生成されます（中身は指定したバージョン番号だけ記述されたシンプルなファイルです）。このディレクトリに移動した際にはjenvがこれを読み込み、指定されたjavaのバージョンが自動的に参照されるようになります。

shをリセットすると、先ほど有効化したexportプラグインにより環境変数JAVA_HOMEも設定されます。

% exec $SHELL -l
% env | grep JAVA_HOME
JAVA_HOME=~/.anyenv/envs/jenv/versions/11.0.12

以下を実行すると、.java-versionファイルが存在しないディレクトリでデフォルトで適用するバージョンを設定することができます。必要があれば設定してください。

% jenv global 11.0.12

これでjenvのインストールと設定は完了です。

sbtenvのインストール＆設定

以下コマンドでsbtenvをインストールします。

% anyenv install sbtenv
% exec $SHELL -l
% sbtenv --version # インストールされたことを確認

sbtのインストールを行います。バージョンはSDKMANの項と同様に1.5.5をインストールする場合、以下のようにします。複数バージョンのsbtを切り替えて利用したい場合、ここで必要な分だけインストールします。

% sbtenv install sbt-1.5.5

※ gpgが必要 といったエラーが表示された場合、インストールしてsbtの公開鍵を設定してから再実行してください。

% brew install gpg
% gpg --keyserver hkps://keyserver.ubuntu.com:443 --recv 2EE0EA64E40A89B84B2DF73499E82A75642AC823

インストール完了後、jenvの時と同様に利用するバージョンのsbtを設定します。

% sbtenv versions # インストールしたsbtのバージョンが表示される
% sbtenv local 1.5.5

以上でanyenv + jenv + sbtenvの環境設定は完了です。

IDE の設定

Visual Studio Code + Metals

scalameta.metals という extension をインストールするだけです。

extension は Scala プロジェクト以外は有効化されないはずですが[1]、私の環境では ruby のワークスペースなどにも .metals ディレクトリが出来てしまいました。基本は disable にしておいて、Scala のワークスペースでだけ手動で enable にするのが良いと思います。

VS Code のサポートについてはこちらに詳しく書かれています。

参考文献

zsh-completionとは

zshを使うときに、補完用の情報を設定をしておくことで、例えば、git、aws-cli、dockerなどのコマンドやサブコマンドをTabキーで補完してくれるツールです。

公式サイトは、以下です。

zsh-completionのインストール

macOSを使っている前提ですが、homebrewで簡単にインストールできます。

zshのプロファイルスクリプトにzsh-completionの設定をする

zsh-completionをインストールすると、以下のようなメッセージがでます。

なお、このメッセージは、brew info zsh-completionコマンドで再表示できます。

このメッセージにしたがって、まずは、次のように .zshrc ファイル設定します。

zsh関連ファイルの権限設定を行う

次に、zsh関連ファイルの権限設定を行います。これも前述のbrew info で表示されるメッセージに従います。

前述の brew info で表示されるメッセージの /opt/homebrew の部分は、使用しているMacのCPUがIntel製かApple Siliconかによって異なります。

なので、環境に応じて次のようにコマンドを打ちます。

Intel Macの場合

M1などApple Silicon Macの場合

あるいは、以下のコマンドを打てばどちらの環境でもOKです。

なお、この go-w は、g(roup)とo(thers)から（つまりuser以外から）、書き込み権限を削除（-）しています。

各コマンドラインツールでの補完の設定

git

homebrewでgitをインストールすると、自動的に /usr/local/share/zsh/site-functions/ 以下に、git用の補完設定もインストールされるので、それ以上何もする必要はありません。

gitはmacOS標準のものもありますが、上記の補完設定のために、筆者はhomebrewでgitをインストールしなおしてしまいます。

設定がうまくいっている場合、以下のように補完されます。ブランチ名などは、覚えられないので補完を使うと便利になります。

docker

公式サイトに説明があるので、それに従います。手順は公式サイトに記載されていて、また、迷うところもないので、ここに手順を記載するのは省略します。

設定がうまくいっている場合、以下のような補完が使えます。

aws-cli

aws-cliも公式サイトに従うだけですが、少しわかりにくいので、補足説明を追加します。

公式サイトは、以下です。

前述の前提の場合、aws_completer はすでにPATHが通っているので、やることは以下の設定を.zshrcファイルに追加するだけです。

設定後は、zshを再起動します。

設定がうまくいっていれば、以下のようにawsコマンドの補完が効くようになります。

前置き

当社のエンジニアは全員フルリモートで働いているため、対面での相談は Google meet を使うことが多いです。

ただ、対面で相談するまでの準備に手間がかかると、気軽な相談はしづらくなりがちです。

そこで当社では、「Slackのカスタムレスポンスとemoji」にGoogle meetのURLを紐付けています。その結果、Slackでのやりとりが難しいと感じた時に、すぐ対面での相談へと移行できています。

必要なもの

• Google meet

• Slack

やりたいこと

1. Slackへ相談の前フリと :room: などのemojiをポストする

2. Slack botが相談用のGoogle meetのURLを案内する

設定手順

1. emojiの画像を用意

任意の画像を用意します。

なお、 生成履歴に絵文字を表示する のチェックボックスについては状況によりON/OFFします。

2. Slackにemojiを登録

3. Google meetの固定URLを取得

4. Slack botのカスタムレスポンスとして、emojiの文字列とGoogle meetのURLを設定

Slackbotタブに以下を入力し、保存します。

• When someone says に、上記2.のemojiの値 (例： :room:)

• Slackbot responds に、上記3.のGoogle meetのURL

以上で設定は完了です。

過去に書いたソースコードを読んでいて、仕様を理解するのに手間取ってハマったので、共有のために記事を書いておきます。

find_or_initialize_byメソッドの例

以下のようなコードを見かけたとします。

user = User.find_or_initialize_by(email: 'sample@precena.com') do |user|
  user.last_name = 'サンプル'
  user.first_name = '太郎'
end 

上のコードから、どのような仕様を想像するでしょうか？

筆者は、ユーザーが見つかった場合、または、初期化した場合、どちらもlast_name、first_nameがそれぞれ、サンプル と 太郎 に初期化されると思ってしまいました。

しかし、実際の挙動としては、以下でした。

ユーザーが見つかった場合は、ブロック内の処理は実行されず、

ユーザーをinitializeした場合は、ブロック内の処理が実行される。

def find_or_initialize_by(attributes, &block)
  find_by(attributes) || new(attributes, &block)
end

コードを見ても、上記の挙動が実装されているのが確認でき、find_byで該当レコードが見つかった場合には、&block 部分が無視されるのが分かります。

はじめに

この記事では、M1 Macでの開発環境構築でハマったところを共有するために、記載して行きます。今後、随時新しいハマりどころが発生した場合は、情報を追加していきます。

環境構築の前提

筆者の環境では、環境構築の検証もかねているので、Rosetta 2をインストールしていません。Rosetta 2をインストール済みの場合は前提が異なってくるため、ご注意ください。

また、以下のものはインストール済みとします。

• rbenv

• Docker Desktop(4.3.0以上)

• postgresql（実行用ではなく、gem pgのビルド時に利用する想定。brewでインストールする）

rbenvでの古いRubyのインストール

% rbenv install 2.6.5

のように、古めのRubyのバージョンをインストールすると、以下のようなエラーが発生しました。

Last 10 log lines:
compiling fiber.c
linking shared-object fiber.bundle
compiling closure.c
closure.c:263:14: error: implicit declaration of function 'ffi_prep_closure' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
    result = ffi_prep_closure(pcl, cif, callback, (void *)self);
             ^
1 error generated.
make[2]: *** [closure.o] Error 1
make[1]: *** [ext/fiddle/all] Error 2
make: *** [build-ext] Error 2

1. 環境変数RUBY_CFLAGSを指定してRubyをインストールする

以下のように、RUBY_CFLAGSを指定して、rbenvのインストールコマンドを実行すると上手く行きます。

RUBY_CFLAGS=-DUSE_FFI_CLOSURE_ALLOC rbenv install 2.6.5

筆者もこの方法を先に試して上手く行ったため、この後の2つめの方法を試せていません。

2. brew info libffiコマンドのガイドにしたがって、環境変数を指定する

brew info libffiコマンドを実行すると、以下のようなCaveatsが表示されます。

==> Caveats
libffi is keg-only, which means it was not symlinked into /opt/homebrew,
because macOS already provides this software and installing another version in
parallel can cause all kinds of trouble.

For compilers to find libffi you may need to set:
  export LDFLAGS="-L/opt/homebrew/opt/libffi/lib"
  export CPPFLAGS="-I/opt/homebrew/opt/libffi/include"

For pkg-config to find libffi you may need to set:
  export PKG_CONFIG_PATH="/opt/homebrew/opt/libffi/lib/pkgconfig"

これにしたがって、環境変数LDFLAGS、CPPFLAGS、PKG_CONFIG_PATHを指定して、以下のように実行すると良いとのことです（筆者は、試せていませんが掲載しておきます）。

% export LDFLAGS="-L/opt/homebrew/opt/libffi/lib"
% export CPPFLAGS="-I/opt/homebrew/opt/libffi/include"
% export PKG_CONFIG_PATH="/opt/homebrew/opt/libffi/lib/pkgconfig"
% rbenv install 2.6.5

※記事のみやすさのために、環境変数ごとにexportをしていますが、一気に複数の環境変数を指定しても良いと思います。

docker-composeコマンドを使わずに、docker compose コマンドを使う

% docker compose up -d

bundle installでネイティブ拡張が含まれるgemをビルドする

bundle install時にネイティブ拡張が含まれるいくつかのgemでインストールに失敗したのでgemごとの対処法を記載しておきます。

gem ffi

% export LDFLAGS="-L/opt/homebrew/opt/libffi/lib"
% export CPPFLAGS="-I/opt/homebrew/opt/libffi/include"
% export PKG_CONFIG_PATH="/opt/homebrew/opt/libffi/lib/pkgconfig"
% bundle install

gem pg

pgは、M1 Mac特有のエラーというよりかは、Intel Macでもよく発生する、Ruby開発者ならよく見たことあるエラーですが、以下のエラーが発生します。

checking for pg_config... no
No pg_config... trying anyway. If building fails, please try again with
 --with-pg-config=/path/to/pg_config
checking for libpq-fe.h... no
Can't find the 'libpq-fe.h header
*** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of necessary
libraries and/or headers.  Check the mkmf.log file for more details.  You may
need configuration options.

Provided configuration options:
        --with-opt-dir
        --without-opt-dir
        --with-opt-include
        --without-opt-include=${opt-dir}/include
        --with-opt-lib
        --without-opt-lib=${opt-dir}/lib
        --with-make-prog
        --without-make-prog
        --srcdir=.
        --curdir
        --ruby=/home/vagrant/.rbenv/versions/2.5.1/bin/$(RUBY_BASE_NAME)
        --with-pg
        --without-pg
        --enable-windows-cross
        --disable-windows-cross
        --with-pg-config
        --without-pg-config
        --with-pg_config
        --without-pg_config
        --with-pg-dir
        --without-pg-dir
        --with-pg-include
        --without-pg-include=${pg-dir}/include
        --with-pg-lib
        --without-pg-lib=${pg-dir}/lib

対処法もいつもどおりで、やり方はいくつかありますが、筆者は以下のようにbundleのbuild時のconfigを指定したのち、bundle install を実行しました。

% bundle config build.pg --with-pg-config=$(brew --prefix postgresql@13)/bin/pg_config

なお、このコマンドを実行すると設定が~/.bundle/configに書き込まれます。

gem rmagick

rmagickもM1固有の問題ではなく、毎回遭遇する以下のエラーが発生します。

./siteconf20220118-1858-ly2is3.rb extconf.rb
checking for clang... yes
checking for Magick-config... yes
checking for outdated ImageMagick version (<= 6.4.9)... no
checking for presence of MagickWand API (ImageMagick version >= 6.9.0)... no
Package MagickWand-6.Q16 was not found in the pkg-config search path.
Perhaps you should add the directory containing `MagickWand-6.Q16.pc'
to the PKG_CONFIG_PATH environment variable
No package 'MagickWand-6.Q16' found
Package MagickWand-6.Q16 was not found in the pkg-config search path.
Perhaps you should add the directory containing `MagickWand-6.Q16.pc'
to the PKG_CONFIG_PATH environment variable
No package 'MagickWand-6.Q16' found
Package MagickWand-6.Q16 was not found in the pkg-config search path.
Perhaps you should add the directory containing `MagickWand-6.Q16.pc'
to the PKG_CONFIG_PATH environment variable
No package 'MagickWand-6.Q16' found
Package MagickWand-6.Q16 was not found in the pkg-config search path.
Perhaps you should add the directory containing `MagickWand-6.Q16.pc'
to the PKG_CONFIG_PATH environment variable
No package 'MagickWand-6.Q16' found
checking for Ruby version >= 1.8.5... yes
Package MagickCore was not found in the pkg-config search path.
Perhaps you should add the directory containing `MagickCore.pc'
to the PKG_CONFIG_PATH environment variable
No package 'MagickCore' found
Can't install RMagick 2.16.0. Can't find the ImageMagick library or one of the dependent libraries. Check the mkmf.log file
for more detailed information.

これは、まず、imagemagickがインストールされていないことが原因で、もしインストール済でこのエラーが発生しているなら、convertコマンドへのPATHが未設定であったり、ビルドに必要なファイルが指定されていなかったりすることが原因です。

以下のように対処します。

まずは、必要なImageMagickをインストールします。Rmagickが対応しているバージョン6を、必ずインストールしてください。

% brew install imagemagick@6

次に、brew info imagemagick@6 コマンドを実行して表示される以下にしたがって、

==> Caveats
imagemagick@6 is keg-only, which means it was not symlinked into /opt/homebrew,
because this is an alternate version of another formula.

If you need to have imagemagick@6 first in your PATH, run:
  echo 'export PATH="/opt/homebrew/opt/imagemagick@6/bin:$PATH"' >> ~/.zshrc

For compilers to find imagemagick@6 you may need to set:
  export LDFLAGS="-L/opt/homebrew/opt/imagemagick@6/lib"
  export CPPFLAGS="-I/opt/homebrew/opt/imagemagick@6/include"

For pkg-config to find imagemagick@6 you may need to set:
  export PKG_CONFIG_PATH="/opt/homebrew/opt/imagemagick@6/lib/pkgconfig"

まず、実行時に必要と思われるconvertコマンドへのPATHを通しておきます。

% echo 'export PATH="/opt/homebrew/opt/imagemagick@6/bin:$PATH"' >> ~/.zshrc

念の為、以下のようにconvertコマンドが使えるかを確認しておくとよいでしょう。

% convert --version

次に、rmagickのビルドに必要な環境変数を指定してから、bundle installを実行します。

% export LDFLAGS="-L/opt/homebrew/opt/imagemagick@6/lib"
% export CPPFLAGS="-I/opt/homebrew/opt/imagemagick@6/include"
% export PKG_CONFIG_PATH="/opt/homebrew/opt/imagemagick@6/lib/pkgconfig"
% bundle install

ここまでで、gemのインストールまで出来ました。

さいごに

なお、2022年1月17日現在、筆者の環境では、この後、古いnodeをインストールしようとしてエラーが発生して失敗し、対応方法が調べきれず、まだRailsアプリケーションを実行するところまでたどり着いておりません。ただ、今後、nodeをバージョンアップさせる予定なので、新しいバージョンのnodeを利用することで、エラーを回避できる可能性があります。

上記については、後日、この記事をアップデートして共有しようと思います。

はじめに

この記事では、Railsの本番環境におけるアプリケーションサーバー（pumaやunicornなど）のプロセス数とスレッド数のパラメータ設定に関する情報をまとめます。

プロセスとスレッドの特徴概要

アプリケーションサーバーのパラメータを設定する際に、OSにおけるプロセスとスレッドは重要な要素になるので、あらかじめ概要を説明しておきます。

プロセスはOSで実行中のプログラムのことで、プロセス内には1つ以上のスレッドが含まれます。CPUのコアに命令をしているのがスレッドです。

複数のプロセス同士は、同じメモリ領域を共有できません。しかし、同じプロセス内のスレッド同士は、同じメモリ領域を共有できるので、プロセス内に複数のスレッドを作成した方がメモリの利用効率が上がります。

複数のスレッドが同じメモリ領域を共有すると、メモリの利用効率は上がりますが、誤って別のスレッドに影響する情報を書き換えてしまう可能性もあります。いわゆるスレッドセーフではない状態が起こるということです。

1つのスレッドしかないプロセスを複数使用すれば、スレッドセーフかどうかを考慮する必要はなくなりますが、複数のスレッドを使う場合と比較して、メモリの利用効率は下がってしまいます。

1つのプロセス内に複数のスレッドを作った場合のメリットとして、一部のスレッドがIO待ち（例えば、データベースへのリクエストとそのレスポンスを待っているような状態）になってしまっても、プロセス内の他のスレッドで別の処理を進めることができるという点があります。この場合、プロセスとしてのスループットが大きくなります。

もし、1つのプロセスで1つのスレッドしか用意しなかったとしたら、そのスレッドでIO待ちが発生すると処理がブロックしてしまいます。

pumaとunicornの違い

Railsで使うアプリケーションサーバーとして一般的なものにpumaとunicornがあります。

pumaは、マルチプロセス対応で、さらに、各プロセス内に複数のスレッドを作成することができます。

unicornは、マルチプロセス対応ですが、各プロセス内には複数のスレッドを作りません。

したがって、スレッド間でメモリを共有できる分、メモリ効率はpumaの方が良くなりやすいです。ただし、pumaを使う場合は利用しているgemも含めてスレッドセーフな実装でアプリケーションを作っておく必要があります。

一方、unicornは、メモリ効率はpumaと比較して良くありませんが、スレッドセーフであるかどうかを気にする必要がありません。また、詳細な説明は省略しますが、稼働中のサーバーにデプロイを行う際にゼロダウンタイムのデプロイをすることが可能、などの特徴もあります。

この記事では、Rails標準のアプリケーションサーバーであるpumaを使う想定で、以降の説明をします。

RubyのGVLの概要

Ruby には、Giant VM lock （GVL）とよばれるものが存在します。Giant VM Lockが効いている間は、ネイティブスレッドがロックされ、実質1つのスレッドしか同時に実行できません。

しかし、GVLについては、Ruby 3.0.0のリファレンスマニュアル（上のリンク先）には、以下のように記載されています。

ネイティブスレッドを用いて実装されていますが、現在の実装では Ruby VM は Giant VM lock (GVL) を有しており、同時に実行されるネイティブスレッドは常にひとつです。ただし、IO 関連のブロックする可能性があるシステムコールを行う場合には GVL を解放します。その場合にはスレッドは同時に実行され得ます。また拡張ライブラリから GVL を操作できるので、複数のスレッドを同時に実行するような拡張ライブラリは作成可能です。

詳細な説明は省略しますが、要するに、Rubyのスレッドは、IO関連のシステムコールを行う場合にはGVLを開放するので、その場合は複数のスレッドを実行できます。しかし、逆にIO関連以外のシステムコール（例えば数値計算など）の場合には、GVLが効いてしまい、同時に1つのスレッドしか実行されません。

Webアプリケーションにおいては、IO関連のシステムコール（例えばネットワーク越しのリクエスト・レスポンス処理）が使われることも多くなるため、アプリケーションサーバーが、マルチスレッド対応をすることのメリットはあると考えられます。

プロセス数とスレッド数の判断に必要な情報

前置きが長くなりましたが、ここからが本題です。

一般的なRailsアプリケーションを実行する本番環境のプロセス数とスレッド数を設定するには、以下を考慮に入れます。

• CPU数（環境によっては、vCPU数、仮想CPU数）

• 利用可能なメモリの量

• 1スレッドで必要なメモリの量

• Railsで設定しているコネクションプールの数

• webとjobワーカーの数

• データベースの同時接続数上限

CPU数

CPU数は、利用しているサーバーのCPUコアの数です。クラウドのような仮想環境を利用している場合は、物理的なコア数ではなく仮想CPU数（vCPU数）を把握する必要があるかもしれません。

（訳注：IO待ちの場合は、GVLが開放されるとはいえ）GVLを考慮するとCPUの機能をフル活用するなら、Rubyコードのプロセス数は、CPUのコア数に一致させるのがよい、と記載されています。

利用可能なメモリ量

利用しているサーバーのメモリ量も把握する必要があります。

スレッドごとにRailsアプリケーションの処理が実行されるので、スレッド数が増えればそれだけ必要なメモリ量も大きくなります。また、プロセス数が増えれば必然的に包含するスレッドも最低1つは増えますので、プロセス数を増やす場合も、必要なメモリ量は大きくなります。

利用しているサーバーのメモリ量は、プロセス数やスレッド数の上限を考えるのに必要です。

1スレッドで必要なメモリ量

1スレッドで必要なメモリ量も把握する必要があります。

1スレッドで必要なメモリ量が例えば、400MB前後だとすると、スレッド数を1、2…と増やしていった場合に、必要なメモリは概ね400MB、800MB…と比例して増えていきます。

1スレッドで必要なメモリ量は、アプリケーションの実装によって幅が出てきます。筆者の経験では、Railsアプリケーションの本番環境では、概ね300MB〜1GBくらいの幅で変わるように思います。

もしすでに本番環境やステージング環境を運用しているのであれば、その環境でメトリクス計測ツール（New RelicやHerokuのMetrix機能）で確認するのが確実です。

稼働している本番環境やステージング環境で、実際に合計何スレッドが動作しているのかが分かれば、本番環境で利用しているメモリ量をその合計スレッド数で割れば、1スレッドで必要なメモリの量を概算することができます（厳密には、スレッド間で共有しているメモリがあるはずです。ここで計算しているのは、あくまで概算値です）。

Railsで設定しているコネクションプールの数

Railsには、コネクションプールの仕組みがあり、以下のように、database.ymlのpoolの値で上限値を指定することができます。

default: &default
  adapter: postgresql
  host: localhost
  pool: 5
  timeout: 5000
  username: postgres
  password: postgres
  encoding: utf8

development:
  <<: *default
  database: sample_app_development

test:
  <<: *default
  database: sample_app_test

コネクションプールとは、Railsの処理がデータベースにアクセスするたびにコネクション接続と切断を行って負荷が高くなったり、パフォーマンスが低下するのを防ぐために、予め決められた上限数を考慮してデータベースとの間に作っておく接続のグループのことです。

また、このコネクションプールは、各プロセスごとに作られます。プロセス間で共有のプールを持つことはできません。

コネクションは、スレッドの処理でデータベースへの接続が必要になった場合に、コネクションプールからスレッドに1つ割り当てられ、処理が終わるとプールに戻されます。

コネクションプールの値がスレッド数より少ない場合、プール数よりも多いデータベースへのアクセスリクエストが発生した際に、新しいスレッドにデータベースとの接続を割り当てることができなくなり、コネクションの割当待ちのような状態になります。

したがって、この割当待ちによるスループットの低下を防ぎたい場合は、

のような関係を保つように、database.ymlを設定する必要があります。

アプリケーションサーバーとjobワーカーの数

一般的なRailsアプリケーションにおいて、データベースに接続するのは、pumaやunicornのようなアプリケーションサーバーからだけではなく、sidekiqのようなjobワーカーも存在します。

次節で説明するように、データベース側に接続上限数が存在するため、jobワーカーが存在するか、そして、それが存在する場合どれくらいの数があり、合計何スレッドくらい実行されるか、も考慮にいれる必要があります。

データベースの同時接続数

データベース側の同時接続数の上限値も把握しておく必要があります。

データベース側の同時接続数が分かれば、全サーバーの全プロセスで作られるスレッド数の合計値が、その同時接続数を超えないようにパラメータを調整しなければなりません。

したがって、結果的に、データベースの同時接続数は、各サーバーのプロセス数やスレッド数の上限値に影響します。

メモリ以外のパラメータの大小関係

これまでの説明を考慮すると、メモリに関するパラメータを除外すれば、少なくとも以下のような大小関係がなりたつように、各パラメータを設定する必要があります。

ただし、この大小関係を満たすという条件は変わりませんが、実際は、次の節で考慮に入れる利用可能なメモリ量で頭打ちになることが多いように思います。

メモリ関連のパラメータの大小関係

上記の大小関係とは別に、メモリによってもパラメータの大小関係が決まってきます。

これは、単純に、以下になります。

Heroku環境での設定例

最後に、当社で良く利用するHeroku環境の例をもとに、具体的な設定例を考えてみます。

前提とする環境

以下のような架空の本番環境を想定することにします。

前提環境で設定すべき値

CPU数は2なので、プロセス数の適切な値は2です。

ただし、メモリ関連のパラメータの大小関係を考慮すると、1スレッドで必要なメモリ量が600MBなので、合計スレッド数 × 600 <= 2500MB となるように、合計スレッド数を4にすると良さそうです。

したがって、仮にプロセス数を2とすると、設定可能なスレッド数は2です。もし、プロセス数を1とすると、スレッド数は4です。

おそらく、後者の方がメモリの利用効率は高そうですが、GVLを考慮すると、アプリケーションによっては前者の方がスループットが大きい可能性もあります。これは、実際にステージング環境などで、どちらが良さそうかを確認すると良いかもしれません。

ここでは、仮に、プロセス数を2、スレッド数を2にすると決めたことにします。また、これに合わせて、コネクションプール数は2にします。

web dynoは、2つ使用するので、各web dynoごとに2プロセス、2スレッド作る場合、プロセス数は、合計で2 x 2= 4だけ作成することになります。

さて、この前提で、合計のデータベース接続数を念の為に計算すると、

となるため、データベースの接続上限数の400には、まだまだ余裕があり、問題ありません（この前提の場合、もっとスペックの低いデータベースを使用してもいいのかもしれません）。

実際にプロセス数とスレッド数を指定する環境変数

pumaを使用する想定の場合、デフォルトでは、/config/puma.rbに以下のような起動設定が用意されています。

なお、実際には、説明用のコメントもつけられているはずですが、コードが長くなるので、以下では割愛しています。

threads_count = ENV.fetch("RAILS_MAX_THREADS") { 5 }
threads threads_count, threads_count

port        ENV.fetch("PORT") { 3000 }

environment ENV.fetch("RAILS_ENV") { "development" }

workers ENV.fetch("WEB_CONCURRENCY") { 2 }

preload_app!

plugin :tmp_restart

rackup DefaultRackup

この設定ファイルの

threads_count = ENV.fetch("RAILS_MAX_THREADS") { 5 }

の部分がスレッド数を指定している部分で、

workers ENV.fetch("WEB_CONCURRENCY") { 2 }

の部分がプロセス数を指定している部分です。

したがって、具体的なパラメータとしては、RAILS_MAX_THREADSを2に、WEB_CONCURRENCYを2に設定することになります。設定しない場合、このコードの例では、デフォルト値としてスレッド数5とプロセス数2が使われるので、サーバーのスペックが不十分な場合は、障害が発生するかもしれません。

はじめに

当社のRailsシステム間連携では、各システムで公開しているWeb APIを使っています。

今までは各システムを bin/rails s で起動し、開発を行ってきました。

ただ、 連携するシステムが増えたり、各システムで使うジョブワーカーが増えたりした結果、現在では各システムを起動する手間が増えてきました。

そこで、今後も効率的に開発できるよう、以下の設定を行いました。

• tmux + overmind にて、連携する各システムやワーカーを1つのコマンドで起動できるようにした

• RubyMine にて、 overmind で起動したプロセスにアタッチし、デバッグできるようにした

この記事では、複数システムを1コマンドで起動できるようにするために、 tmux + overmind + RubyMine にてどのような設定をしたか、チュートリアル形式で共有します。

前提となる環境について

システム全体の構成について

このチュートリアルでは、以下のシステム構成とします。

• mac上で、2つのRailsシステム(frontend_appとbackend_app)を開発している

  • frontend_app について

    • 外部からのHTTPリクエストを受け付ける

    • Delayed::Job でジョブを管理している

      • bin/rails jobs:work にて Delayed::Job Worker を起動する

• 各Railsシステムは、ローカルマシン上での bin/rails s 実行により起動する

• 各Railsシステムは、データベースを適切に設定している

ディレクトリ構成について

次の図のように、overmind ディレクトリの中に frontend_app と backend_app という2つのRailsシステムのリポジトリがあるものとします。

overmind/
├── backend_app/
│   ├── app/
│   ├── bin/
│   ...
└── frontend_app/
    ├── app/
    ├── bin/
    ...

用語について

tmuxとは

terminal multiplexer と呼ばれるソフトウェアのうちの1つです。

1つのターミナルの画面を、複数に分割して利用します。

overmindとは

Herokuで使う Procfile と同じ書式で定義することで、定義したプロセスを管理できます。

チュートリアル

tmux + overmind でシステム全体を起動できるようにする

tmux + overmind をセットアップする

% brew install tmux

% brew install overmind

tmuxの設定を行う

tmuxはデフォルト設定のままでも問題なく使えます。

ただ、慣れないうちはマウス操作はできたほうが便利なため、 tmux の設定を追加します。

~/.tmux.conf ファイルを追加し、以下を記載します。

set-option -g mouse on

Procfileを作成する

チュートリアルのルートディレクトリである overmind に、ファイル Procfile を作成します。

Procfile には、各Railsシステムやジョブワーカーを起動する時のコマンドを記載します。

なお、ワーキングディレクトリを考慮するため、 && を使ってコマンドをチェーンしています。

# frontendの設定
frontend_app: cd frontend_app && bin/rails s -b 0.0.0.0 -p 3030
frontend_worker: cd frontend_app && bin/rails jobs:work

# backendの設定
backend_app: cd backend_app && bin/rails s -b 0.0.0.0 -p 3031

tmuxにてovermindを起動する

macのターミナルから tmux を起動します。

% tmux

次に、 Procfile のあるディレクトリに移動し、overmind にて各プロセスを起動します。

% overmind s

tmux の画面では、 Procfile で定義した各プロセスの様子が表示されています。

動作確認

外部からのHTTPリクエストを受け付ける frontend_app に対し、 curl でアクセスします。

すると、 frontend_app からJSONレスポンスが返ってきます。

% curl http://localhost:3030/shops
{"shop":{"name":"スーパーマーケット","apples":[{"name":"シナノゴールド"},{"name":"シナノスイート"},{"name":"秋映"}]}}

tmuxを見ると、各システムやジョブワーカーが連携し、JSONレスポンスを返したことが分かります。

動作確認ができたため、いったん Ctrl + C にて overmind での実行を停止します。

1つのプロセスをtmuxの別ペインで表示する

現在はtmuxの1つのペインに、 Procfile で起動したすべてのプロセスのログが表示されています。

ただ、この状態のままでは各プロセスのログを追いづらいです。

そこで、別ペインで表示するよう設定します。

このチュートリアルでは、ウィンドウを上下ペインに分けます。

上ペインはここまで通り overmind のログを表示します。

一方、下ペインでは backend_app のログのみを表示するようにします。

別ペインで表示するための準備

以下の準備を行います。

• tmuxで Ctrl + b + " を入力し、水平ペインを開く

• 上ペインにて、以下の操作を行う

  • overmind s を実行し、各システム・ワーカーを起動する

• 下ペインにて、以下の操作を行う

  • Procfile のあるディレクトリに移動する

  • overmind connect backend_app を実行し、overmindで実行している backend_app のプロセスに接続する

動作確認

再びcurlで frontend_app にアクセスしてみます。

すると、上ペインでは、各システム・ワーカーのログが出力されています。

一方、矢印部分の下ペインでは、 backend_app のログのみ表示されています。

RubyMineにて、overmindで起動したプロセスのデバッグを行う

今までの操作にて、各システム・ワーカーを overmind s だけで起動できるようになりました。

ただ、何か不具合があった時には、各システムをデバッグしたくなるかもしれません。

もしRubyMineを使っている場合は、 overmind で起動したプロセスにアタッチ・デバッグできます。

このチュートリアルでは、RubyMineを使って backend_app のプロセスにアタッチしてみます。

RubyMineでの設定

以下の順番で設定を行います。

• RubyMineにて、プロセスにアタッチしたいシステムのリポジトリを開く

  • このチュートリアルでは backend_app リポジトリを開きます。

• RubyMineのメニューにて、 Run > Attach to Process を選択する

• 実行しているプロセスが表示されるため、 backend_app のプロセスを選択する

  • 下部のイメージ参照

• RubyMineでブレークポイントを設定する

以上で、デバッグの準備が整いました。

動作確認

curlで frontend_app にアクセスしてみます。

すると、RubyMineで設定したブレークポイントで停止します。

実行時の各変数の内容も表示され、デバッグできていることが分かります。

まとめ

tmux + overmind を利用して、連携する一連のシステムやワーカーを起動できるようにしたことにより、より開発を効率的に行うことができるようになりました。

今後も開発を効率的に行う方法をTechBookにて共有していこうと思います。

先日、Rails6.1系で動いていたシステムをRails7.0系にアップグレードしました。

そのシステムは

• Rails製APIアプリケーション

• コード量・利用者ともに小規模

• テストコードが充実している

と比較的アップグレードしやすかったこともあり、無事に完了しました。

この記事ではアップグレードの際に調べたことをまとめておきます。

リリースノートやRailsガイドのアップグレードガイドを読む

資料を読み終えたところで、対象のシステムは問題なさそうと判断し、準備を進めることにしました。

各gemがRails7.0対応しているか確認する

Rails7.0がリリースされた直後は、使っているgemがRails7.0対応していないものがありました。

そこで、定期的に各gemのリポジトリを見に行き、Rails7.0対応に関するissueやPull Requestを確認しました。

その後、使用しているすべてのgemがRails7.0対応がなされているのが確認できたため、具体的な作業に入りました。

各gemをバージョンアップする

今回は小規模だったこともあり、

• bundle outdated でバージョンアップできるgemを確認

• Rails以外を bundle update --conservative <gem名> でバージョンアップ
• Railsを bundle update --conservative rails でバージョンアップ

の順で作業をしました。

また、各gemをバージョンアップするごとに、テストを流してパスすることを確認した上でGitブランチにコミットしました。

各種設定ファイルを更新する

まず、削除された設定について見てみましたが、主に

• Rails7で config/initializers/ 以下が整理されたが、対象システムでは使っていない設定だった

ため、システムから削除しても問題なさそうでした。

次に、設定ファイルの変更で気になった点(後述)については調査を行いました。その結果、変更による影響がなさそうだったため、Rails7.0系での変更を各種設定ファイルに取り入れました。

ここでは、今回気になった点とその対応について以下にまとめます。

app/models/application_record.rb

class ApplicationRecord< ActiveRecord::Base
-  self.abstract_class = true
+  primary_abstract_class
end

config/environments/development.rb

+ config.server_timing = true

- config.assets.debug = true

- config.file_watcher = ActiveSupport::EventedFileUpdateChecker

一方、

• config.assets.debug は使っていないシステムだった

• config.file_watcher はDockerを使っていると影響ありそうな情報が散見されるものの、今回の環境では不要そうだった

ため、これらは設定ファイルから削除することにしました。

config/environments/production.rb

-  # Send deprecation notices to registered listeners.
-  config.active_support.deprecation = :notify
-
-  # Log disallowed deprecations.
-  config.active_support.disallowed_deprecation = :log
-
-  # Tell Active Support which deprecation messages to disallow.
-  config.active_support.disallowed_deprecation_warnings = []
+  # Don't log any deprecations.
+  config.active_support.report_deprecations = false

他の項目については、対象のシステムで無効にしていた設定だったため、対応は不要でした。

config/environments/test.rb

-  # Do not eager load code on boot. This avoids loading your whole application
-  # just for the purpose of running a single test. If you are using a tool that
-  # preloads Rails for running tests, you may have to set it to true.
-  config.eager_load = false
+  # Eager loading loads your whole application. When running a single test locally,
+  # this probably isn't necessary. It's a good idea to do in a continuous integration
+  # system, or in some way before deploying your code.
+  config.eager_load = ENV["CI"].present?

そのため、 config.eager_load は従来のまま false と明示的に設定しました。

デフォルト値の影響調査

そこで、Railsのデフォルト値の変更を調べることにしました。

上記の記事にある項目を確認しましたが、今回のシステムに対して影響するものはありませんでした。

次に、さきほどのQiitaの記事で触れられていなかったものについて調査しました。それらを以下にまとめます。

config.active_support.disable_to_s_conversion: true

ある種のRubyコアクラスに含まれる#to_sメソッドの上書きを無効にします。この設定は、アプリケーションでRuby 3.1の最適化をいち早く利用したい場合に使えます。

とあります。

今回は小規模なシステムだったこともあり影響がなかったため、デフォルト値の変更を受け入れました。

action_dispatch.return_only_request_media_type_on_content_type: false

active_storage.multiple_file_field_include_hidden: true

In Rails 7.1 and beyond, Active Storage has_many_attached relationships will default to replacing the current collection instead of appending to it.

とのことですが、今回のシステムには影響しなかったため、デフォルト値の変更を受け入れました。

おわりに

Rails7.0系にアップグレード後も開発・運用を継続していますが、今のところ大きな問題は発生していません。

今後もRailsのバージョンアップを継続して行うとともに、作業で気になったこと等はTechBookに記載していこうと思います。

背景

当社では、社内で共通に使いたい機能をgemに切り出し、機能の利用側のGemfileでプライベートリポジトリを参照しています。

gem "some_internal_library", git: "https://github.com/precena-dev/some_internal_library.git", tag: "v1.0.0"

ローカル端末でのみ利用する場合はgitのURLはgit@ やssh@ で始まるURLを使えば問題なくbundle installできます。しかしCI/CD環境でもbundle installするため、httpsで始まるURLで登録しています。

このプライベートリポジトリをbundle install時に参照する方法について記載します。

Personal Access Tokenを使う方法について

ローカル端末の場合

Github CLIを使う方法

まずCLIをインストールしておきます。Macの場合はbrewコマンドでインストールできます。

% brew install gh

次に以下のコマンドを実行するとブラウザが開きますので、Githubの認可を行います。

% gh auth login

これで、bundle installが成功します。

git configを使う方法

% git config url.git@github.com:.insteadOf https://github.com/

そうすると、sshで参照するようになるためbundle installが成功します。

CI/CD環境の場合

github actionsやAWS codebuildなどのCI/CD環境について記載します。

Github Appsの作成

パーミッションについては、プライベートリポジトリを参照してbundle installするだけであれば、「Contents：Read-only」を選択するだけで良いでしょう。

作成後にPrivate Keyを作れるようになりますので、ひとつ作成して秘密鍵をダウンロードしておきます。

画面上部に表示されているAppIDを控えます

作成したGithub Appのリポジトリへの導入

Github App 左メニューのInstall Appを選択し、歯車アイコンをクリックします。

必要なリポジトリを選択し、Saveします。

Github Actions

控えておいたGITHUB_APP_IDおよびGITHUB_APP_PRIVATE_KEYを、下図のようにActionのsecretsに、登録しておきます。

Github App経由でtokenを取得します。その値を、環境変数BUNDLE_GITHUB__COMに設定します。以下にGithub Actionsの設定例を掲載します。

    steps:
      - name: Generate github token
        id: generate_token
        uses: tibdex/github-app-token@v1
        with:
          app_id: ${{ secrets.APP_ID }}
          private_key: ${{ secrets.PRIVATE_KEY }}
      - uses: actions/checkout@5a4ac9002d0be2fb38bd78e4b4dbde5606d7042f
   ・・・中略・・・
      - name: Set up Ruby
        env:
          BUNDLE_GITHUB__COM: x-access-token:${{ steps.generate_token.outputs.token }}
        # To automatically get bug fixes and new Ruby versions for ruby/setup-ruby,
        # change this to (see https://github.com/ruby/setup-ruby#versioning):
        uses: ruby/setup-ruby@v1
        with:
          ruby-version: ${{ matrix.ruby-version }}
          bundler-cache: true # runs 'bundle install' and caches installed gems automatically

AWS CodeBuild

Github Actionsとやっていることは同じです。Github Appsを用意し、GITHUB_APP_IDとGITHUB_APP_PRIVATE_KEYを使って、Access Tokenを取得します。ただしgithub actionsのように公開された再利用可能ワークフローがないため、自前でスクリプトを実行してtokenを取得します。

以下が、buildspec.ymlから呼ぶスクリプトです。

# buildspec.ymlから呼ぶscript.
# github app経由でtokenを取得する
npm install axios jsonwebtoken
node ./get_github_token.js > $BUNDLE_GITHUB__COM

// github app経由でtokenを取得するスクリプト
// 成果物のtokenは標準出力に出す
// https://dev.classmethod.jp/articles/register-github-app-and-get-access-token/ を改変

const jwt = require("jsonwebtoken")
const axios = require("axios")

const githubAppId = process.env.GITHUB_APP_ID;
const githubAppPrivateKey = process.env.GITHUB_APP_PRIVATE_KEY;
const githubAppInstallationId = process.env.GITHUB_APP_INSTALLATION_ID;

const payload = {
  exp: Math.floor(Date.now() / 1000) + 60,  // JWT expiration time
  // ちょっとだけ時間を手前にしておくとアクセストークンの発行に失敗し辛いらしい。
  // https://qiita.com/icoxfog417/items/fe411b94b8e7ae229e3e#github-apps%E3%81%AE%E8%AA%8D%E8%A8%BC
  iat: Math.floor(Date.now() / 1000) - 10,       // Issued at time
  iss: githubAppId
}

const cert = githubAppPrivateKey;
const token = jwt.sign(payload, cert, { algorithm: 'RS256'});

axios.default.post(`https://api.github.com/app/installations/${githubAppInstallationId}/access_tokens`, null, {
  headers: {
    Authorization: "Bearer " + token,
    Accept: "application/vnd.github.machine-man-preview+json"
  }
})
  .then(res => {
    // 標準出力に出たものをシェルスクリプトでリダイレクトして使う想定
    console.log(`x-access-token:${res.data.token}`);
  })
  .catch(res => {
    console.error('error');
    console.error(res);
    throw new Error(res.data);
  })

OpenAPIとは

RESTfulなWebサービスを記述、生成、利用、可視化するためのインターフェースファイルの仕様です。 以前はSwaggerフレームワークの一部でしたが、2016年にOpenAPI Initiativeが統括する独立プロジェクトとなりました。 Swaggerや他のいくつかのツールは、インターフェースファイルを指定してコード、ドキュメント、テストケースを生成することが可能です。

プロジェクトでの利用法

プレセナの一部プロジェクトでは、API定義をOpenAPI仕様に従って記述するだけでなく、定義ファイル（openapi.yaml）からコードを自動生成して利用しています。

OpenAPI定義ファイルの分割

肥大化するopenapi.yaml

当初はAPI定義ファイルであるopenapi.yamlの1ファイルに全ての記述をしていました。 結果として、下記のような問題が発生しました。

1. ファイルサイズの増加（約2500行）

2. コンフリクトの頻発

3. 編集すべき記述を素早く見つけられない

これらの問題に対処するためにopenapi.yamlの分割をおこなうことにしました。

openapi.yamlファイルの構成

openapi.yamlのファイルは大きく分けると下の様なブロックに分かれています。

• バージョン情報といったメタ情報：info、serversなど

• エンドポイントのURLやリクエスト／レスポンス情報：paths

• 再利用可能なオブジェクト情報：components

openapi: "3.0.0"
info:
  version: 1.0.0
  title: Swagger Petstore
  license:
    name: MIT
servers:
  - url: http://petstore.swagger.io/v1
paths:
  /pets:
    get:
      summary: List all pets
      operationId: listPets
      tags:
        - pets
      parameters:
        - name: limit
          in: query
          description: How many items to return at one time (max 100)
          required: false
          schema:
            type: integer
            format: int32
      responses:
        '200':
          description: A paged array of pets
          headers:
            x-next:
              description: A link to the next page of responses
              schema:
                type: string
          content:
            application/json:    
              schema:
                $ref: "#/components/schemas/Pets"
・・・略・・・
components:
  schemas:
    Pet:
      type: object
      required:
        - id
        - name
      properties:
        id:
          type: integer
          format: int64
        name:
          type: string
        tag:
          type: string
    Pets:
      type: array
      items:
        $ref: "#/components/schemas/Pet"
・・・略・・・

主に記述量が肥大化してしまうのは pathsとcomponentsであったため、これらを別ファイルに分割しました。

ファイルの分割

ファイルの分割は簡単です。 定義内の他コンポーネントを参照できるようにするフィールドである$ref を相対パスで記述するだけです。

openapi.yaml

...（infoやserversは省略）...

paths:
  /pet:
    $ref: "./paths/pet.yaml"
  /pet/{petId}/upload-image:
    $ref: "./paths/upload-image.yaml"

/paths/pet.yaml

    get:
      summary: List all pets
      operationId: listPets
      tags:
        - pets
      parameters:
        - name: limit
          in: query
          required: false
          schema:
            type: integer
            format: int32
      responses:
        '200':
          content:
            application/json:    
              schema:
                $ref: "../schemas/Pet" # $refの記述
        default:
          description: unexpected error
          content:
            application/json:
              schema:
                $ref: "../schemas/Error" # $refの記述

/schemas/Pet.yaml

    Pet:
      type: object
      required:
        - id
        - name
      properties:
        id:
          type: integer
          format: int64
        name:
          type: string
        tag:
          type: string

フォルダ構造

openapi.yamlをルートファイルとして、同階層にpathとschemasのフォルダを作成しました。

.
├── openapi.yaml
├── paths # pathの定義ファイルを置く
│   ├── pet.yaml
│   ├── pet_find-by-status.yaml
│   ├── ...
│   └── pet_petId_upload-image.yaml
└── schemas  # schemasの定義ファイルを置く
    ├── Pet.yaml
    ├── User.yaml
    ├── ...
    └── Tag.yaml

paths配下のファイルの命名規則としては、シンプルにエンドポイントURLの「/」を「_」にするファイル名としました。

/paths/pet/find-by-status.yaml のように階層を深くするアイデアもあったのですが、schemasへの参照を$refで記述する際、"../../schemas/Foo", "../../../schemas/Bar" のように 「..」を書く回数の混乱が生じないように現在のような命名規則をとりました。

エンドポイントURLにidが含まれる場合（ex. /pet/{petId}/upload-image）、理想的にはpet_[petId]_upload-image.yamlのようにしたかったのですが、「[]」を含むと自動生成コードで問題が生じたため、シンプルにpet_petId_upload-image.yaml としました。

まとめ

Railsには、スキーマファイルと呼ばれる schema.rb があります。

Active Recordはマイグレーションの時系列に沿ってスキーマを更新する方法を知っているので、履歴のどの時点からでも最新バージョンのスキーマに更新できます。Active Recordは db/schema.rb ファイルを更新し、データベースの最新の構造と一致するようにします。

とあるように、schema.rb はデータベース関連の機能で使われます。

その schema.rb ですが、チームで開発をしている時に

• 自分の作業を中断して、プルリクエストのレビューをする

• 自分の作業に戻って、開発を続ける

を繰り返している中で、意図しない差分が schema.rb に発生していると気づき、戸惑うことがあるかもしれません。

そこで、schema.rb に差分が発生してしまうことについて

• 発生する事例

• 差分が発生していると何が起こるか

• どう復旧するか

を記事としてまとめます。

発生する事例

発生する事例として、「どのような流れで発生してしまうのか」を体験できるチュートリアルを用意しました。

チュートリアルは以下の流れで進めます。なお、Railsのバージョンは 7.0.4.2 を想定しています。

1. mainブランチで、Railsのモデルを作成

2. mainから派生した第2のブランチ（feature/add_unique_index）で、モデルの変更を伴うマイグレーションを適用

3. mainから派生した第3のブランチ（feature/add_column）で、モデルの変更を伴うマイグレーションを適用

1. mainブランチで、Railsのモデルを作成

最小構成で rails new します。後ほどgemを追加するため、現時点では bundle install を行いません。

% bundle exec rails new schemaapp --minimal --skip-bundle

% cd schemaapp

今回の動作確認をRSpecで行うため、 Gemfile の末尾に追加します。

group :test do
  gem 'rspec-rails', '~> 6.0.1'
end

Gemfileの準備ができたため、一連のgemをインストールします。

% bundle install

RSpecのセットアップも行います。

% bin/rails g rspec:install

続いてモデルを用意します。今回は isbn 列を持つBookモデルとします。

% bin/rails g model Book isbn:string

マイグレーション適用後に、状態を確認しておきます。

% bin/rails db:migrate

% bin/rails db:migrate:status

database: db/development.sqlite3

 Status   Migration ID    Migration Name
--------------------------------------------------
   up     20230306095752  Create books

ここまでをコミットします。 (もし vendor/bundle 以下をコミットしたくない場合は .gitignore に追加しておきます)

% git init
% git add .
% git commit -m "first commit"

2. mainから派生した第2のブランチ（feature/add_unique_index）で、モデルの変更を伴うマイグレーションを適用

main ブランチから第2のブランチ( feature/add_unique_index )を新しく作成し、「Bookの isbn にUNIQUE制約を追加する」ためのマイグレーションファイルを生成します。

% git checkout -b feature/add_unique_index

% bin/rails g migration AddIndexToBook

生成したマイグレーションファイルにて、Bookの isbnにUNIQUE制約を追加します。

class AddIndexToBook < ActiveRecord::Migration[7.0]
  def change
    add_index :books, :isbn, unique: true
  end
end

マイグレーションを適用後、状況を確認します。

% bin/rails db:migrate

% bin/rails db:migrate:status

database: db/development.sqlite3

 Status   Migration ID    Migration Name
--------------------------------------------------
   up     20230306095752  Create books
   up     20230306104025  Add index to book

作業が終わったため、コミットします。

% git add .

% git commit -m "add index"

3. mainから派生した第3のブランチ（feature/add_column）で、モデルの変更を伴うマイグレーションを適用

ここからが、意図しない差分を発生させてしまう手順になります。

本来ならば、第2のブランチ（feature/add_unique_index）を離れる前にマイグレーションをロールバックします。

ただ、今回は schema.rbに差分を発生させるため、マイグレーションを適用したまま、

• 第3のブランチ（feature/add_column）を新しく作成・切り替え

• モデルに列 nameを追加

• マイグレーションを適用

を行います。

% git checkout main

% git checkout -b feature/add_column

% bin/rails g migration AddColumnToBook name:string

% bin/rails db:migrate

続いて、マイグレーションの状態を確認します。作業2.のマイグレーションが適用されたまま、今回のマイグレーションも適用されているのが分かります。

% bin/rails db:migrate:status

database: db/development.sqlite3

 Status   Migration ID    Migration Name
--------------------------------------------------
   up     20230306095752  Create books
   up     20230306104025  ********** NO FILE **********
   up     20230306104231  Add column to book

schema.rb を見ると isbn 列にUNIQUE制約が定義されており、意図しない状態となっています。

ActiveRecord::Schema[7.0].define(version: 2023_03_06_104231) do
  create_table "books", force: :cascade do |t|
    t.string "isbn"
    t.datetime "created_at", null: false
    t.datetime "updated_at", null: false
    t.string "name"
    t.index ["isbn"], name: "index_books_on_isbn", unique: true
  end
end

最後に、「この状態に気づかずに、うっかりコミット」した想定にしておきます。

% git add .

% git commit -m "add column"

差分が発生していると何が起きるか

今回はテストコードを使って、何が起こるかを見ていきます。

「第3のブランチ（feature/add_column）ではまだUNIQUE制約を付けるマイグレーションがないから、テストはパスするだろう」と考え、以下のテストコードを書いたとします。

require 'rails_helper'

RSpec.describe Book, type: :model do
  describe 'schema.rbの確認' do
    before { Book.create!(isbn: '4797399848') }

    it 'UNIQUE制約がないこと' do
      expect { Book.create!(isbn: '4797399848') }.not_to raise_error
    end
  end
end

しかし、RSpecを実行すると

expected no Exception, got #<ActiveRecord::RecordNotUnique: SQLite3::ConstraintException: UNIQUE constraint failed: books.isbn> with backtrace:

とテストが失敗してしまいます。

今回の場合、UNIQUE制約を追加するマイグレーションファイルが存在しない第3のブランチ（feature/add_column）でも、UNIQUE制約付きでテスト用のデータベースが作成されてしまった結果、テストが失敗しました。

どう復旧するか

今回は、以下の流れで復旧していきます。

1. UNIQUE制約を追加した第2のブランチ（feature/add_unique_index）へ切り替え、UNIQUE制約のマイグレーション適用をロールバックする

2. 第3のブランチ（feature/add_column）へ切り替え、 db:migrate を実行する

順に見ていきます。

1. UNIQUE制約を追加した第2のブランチ（feature/add_unique_index）へ切り替え、UNIQUE制約のマイグレーション適用をロールバックする

UNIQUE制約を追加した第2のブランチ( feature/add_unique_index )へ切り替え、マイグレーションの状況を確認します。

Migration IDに対するNameのうち、NO FILE と表示されていたものが Add index to book という表示へと切り替わりました。

% git checkout feature/add_unique_index
% bin/rails db:migrate:status

database: db/development.sqlite3

 Status   Migration ID    Migration Name
--------------------------------------------------
   up     20230306095752  Create books
   up     20230306104025  Add index to book
   up     20230306104231  ********** NO FILE **********

続いて、第2のブランチ( feature/add_unique_index )上で、不要なマイグレーション適用を元に戻します。

なお、 db:migrate:rollback コマンドでは1ステップずつしか戻せないので、バージョンを指定できるコマンドで戻します。

% bin/rails db:migrate:down VERSION=20230306104025

再度マイグレーションの状況を確認すると、当該Migration IDが down という未適用状態になりました。

% bin/rails db:migrate:status    

database: db/development.sqlite3

 Status   Migration ID    Migration Name
--------------------------------------------------
   up     20230306095752  Create books
  down    20230306104025  Add index to book
   up     20230306104231  ********** NO FILE **********

ただ、この時点では schema.rb に変更が入っていることから、第3のブランチ（feature/add_column）へ切り替えようとしても

% git checkout feature/add_column
error: Your local changes to the following files would be overwritten by checkout:
	db/schema.rb
Please commit your changes or stash them before you switch branches.
Aborting

と、エラーになってしまいます。

そこで、 schema.rb の変更を、当ブランチのコミット時点に戻しておきます。

% git reset HEAD db/schema.rb
% git checkout db/schema.rb

2. 第3のブランチ（feature/add_column）へ切り替え、 db:migrate を実行する

あらためて第3のブランチ（feature/add_column）へ切り替えます。

% git checkout feature/add_column

ここでマイグレーション適用状況を確認すると、第3のブランチ(feature/add_column )のマイグレーションのみが適用・表示されています。

% bin/rails db:migrate:status    

database: db/development.sqlite3

 Status   Migration ID    Migration Name
--------------------------------------------------
   up     20230306095752  Create books
   up     20230306104231  Add column to book

ただ、まだ schema.rb にはUNIQUE制約の定義が残ったままになっています。

そこで、もう一回 db:migrate を実行し、 schema.rb を更新します。

% bin/rails db:migrate

ターミナルの実行結果には何も表示されないものの、git status ではschema.rb の更新が確認できます。

% git status
On branch feature/add_column
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   db/schema.rb

更新後の schema.rb を見ると、UNIQUE制約の定義が削除されています。

ActiveRecord::Schema[7.0].define(version: 2023_03_06_104231) do
  create_table "books", force: :cascade do |t|
    t.string "isbn"
    t.datetime "created_at", null: false
    t.datetime "updated_at", null: false
    t.string "name"
  end
end

これでようやく schema.rb が復旧しました。

あとは忘れずに schema.rbを第3のブランチ（feature/add_column）へコミットすれば、復旧は完了です。

おわりに

今回は schema.rbに差分が発生する事例とその復旧方法を見てきました。

復旧するのには手間がかかることから、もしプルリクエストにマイグレーションファイルが含まれている場合は、schema.rb に余分な更新がないかチェックするのが良さそうです。

環境

• RDB

  • PostgreSQL 13.3

  • トランザクション分離レベル read committed (デフォルト)

• 実験環境

  • IntelliJ IDEA 2024.3 (Ultimate Edition)

TLDR

PostgreSQLにおいて、トランザクション内で同一キーの行を delete - insert する場合、同時に実行される他のトランザクションからは当該の行が参照できない場合があります。

現象の説明

次のようなSQLを考えます。

begin;

-- delete-insertによってデータを更新する
delete from users where id = 1;  -- id が p_key
insert into users (id, name) values (1, 'jane doe');

commit;

実験のためIntellijを使い、2つのセッション分のクエリコンソールを開きます。 これら2つをそれぞれセッション１、セッション２とします。

1. セッション１で5行目まで実行する。この時 delete によってロックが獲得される

2. セッション２で4行目まで実行する。するとセッション１で行がロックされているため、待ち状態になる

3. セッション１で7行目の commit まで実行する。これによりセッション１で獲得されていたロックが解放される

4. セッション１のロックが解放されたことでセッション２の delete が実行される

この時、4 の結果セッション２では delete が空振りし、insert を実行するもすでに id = 1 の行が存在するため、 [23505] ERROR: duplicate key value violates unique constraint "users_pkey" となります。

比較実験

MySQLの場合

MySQL 8.0.28 で同様の実験を行ったところ、エラーは発生しませんでした。データの更新結果はcommitを後に実行している、セッション２の結果が保存されます。 MySQLのトランザクション分離レベルは repeatable read(デフォルト) です。

PostgreSQLでトランザクション分離レベルをrepeatable readとした場合

ひょっとしたら分離レベルに依存した挙動なのでは？ということでPostgreSQLにて分離レベルをrepeatable readとして実験を行いました。 結果前述4のステップで、以下のようなエラーが返されました。

[40001] ERROR: could not serialize access due to concurrent update

MySQLでトランザクション分離レベルをread committedとした場合

MySQLではrepeatable readの場合と挙動は変わらず、1行返却されました。

select for updateによるロック獲得の場合

PostgreSQLにおいて、delete 文ではなくselect for updateでロックを獲得した場合の挙動についても確認しました。

begin;

-- for update により、行ロックを取得する
select * from test where id = 1 for update;

-- delete-insertによってデータを更新する
delete from test where id = 1;
insert into test (id, name) values (1, 'jane doe');

commit;

この場合、セッション２は select for update の行で待ち状態となり、セッション１のcommit後、セッション2の select for update が実行され 0行 の返却となりました。

終わりに

今回、別の問題を調査していく中でたまたまこの現象に遭遇しました。 個人的には全く想定していない挙動でした。

改めてこちらの記事はPostgreSQLでの挙動になります。 前述の通りMySQLでは異なる挙動となりましたので、RDBMSの実装に依存するようです。

ご興味があれば、ぜひお手持ちの環境でも試してみてください。

Rails歴が長い人でも、意外とmigrationの追加用のコマンドを覚えていられず、毎回調べていているので、実装で使ったもの・使いそうなものを少しずつ追加しています。

この記事は定期的に内容が追加される予定です。

よく使うパターン

空のマイグレーションファイルを作成する

以下のように、マイグレーションの名前を指定しながらrails generate コマンドを入力します。

% rails g migration AddXXXXsToSomeRecords

特定の型のカラムを既存のテーブルに追加する

以下のようにコマンドでカラムと型を指定する（YYY はテーブル名）か、

$ rails g migration AddXXXXToYYY カラム名:データ型

class AddXXXXsToSomeRecords < ActiveRecord::Migration
  def change
    add_column :some_records, :column_name, :string
  end
end

ときどき使うパターン

既存のテーブルに、カラム名からは参照先を自動的に推定できない外部キーを追加する

some_master_records というテーブルがある前提で、別のsome_transaction_records テーブルにdefault_some_master_record_id というカラムを追加して、そのカラムを使ってsome_master_records テーブルを参照したい場合に使います。

やり方はいくつかあると思いますが、筆者が使うのは、以下です。

その後、以下のようにadd_reference メソッドにforeign_key オプションを指定し、そのオプションの中でto_table を指定します。

class AddXXXXsToSomeTransactionRecords < ActiveRecord::Migration
  def change
    add_reference :some_transaction_records, #カラムを追加したいテーブル
                  :default_some_master_record, #これでdefault_some_master_record_idカラムが作られる
                  {
                    foreign_key: {to_table: :some_master_records}
                  }  
  end
end

これで、some_transaction_records テーブルに、default_some_master_record_id カラムが追加され、some_master_records テーブルへの外部キー制約も作られます。

なお、この場合、ActiveRecordのモデルクラス（SomeTransactionRecord　クラス）にも参照に使う外部キーと参照先のモデルの設定が必要になります（この記事での説明は省略します）。

はじめに

弊社ではAWSリソースをTerraformやCloudFormationで管理し、plan/applyの実行にはGithub Actionsを使っています。本稿ではGithub ActionsからAWSリソースを操作するためのIAMロールの設定について説明します。

IAMロールを利用するメリット

Github ActionsからAWSリソースを操作するために利用する認証方法には以下のふたつが挙げられます。

• アクセスキーおよびシークレットキー

• IAMロール

アクセスキーによる方法にはセキュリティリスクが伴います。アクセスキーとシークレットキーがありさえすればどこからでも使え、漏洩すると不正利用される可能性があるためです。さらに、TerraformやCloudFormationによる処理に割り当てられるIAMポリシーは広大になりがちなので、漏洩した時の被害が甚大になる可能性があります。

一方、IAMロールを利用する方法では、一時的な認証情報（STSトークン）を発行することで、安全かつ柔軟にAWSリソースへアクセスできます。特に、GitHub ActionsのようなCI/CD環境では、OIDC（OpenID Connect）を活用することで、アクセスキーを不要にし、より安全な認証フローを実現できます。

設定手順

IAMロール（OIDC）の設定手順

OIDCプロバイダーをAWSに設定

IAMのメニューから「IDプロバイダ」を選択し「プロバイダを追加」をクリックします。

プロバイダのタイプで「OpenID Connect」を選択します。

以下を入力します。

• URLにtoken.actions.githubusercontent.com

• 対象者にsts.amazonaws.com

IAMロールの作成とポリシー設定

GitHub Actions用のIAMロールを作成します。

作成したロールに、必要十分なIAMポリシー（S3、CloudFormation、Lambda等）を設定します。

信頼ポリシーの設定（GitHubリポジトリを許可）

作成したロールの信頼関係タブで以下のように信頼ポリシーを設定します。PrincipalのARNやgithubのリポジトリ名は環境に合わせて変更してください。

GitHub ActionsでIAMロールを利用する

GitHub Actionsワークフローの更新

利用したいGithub Actionsのyamlに以下を記載します。

次に、Github ActionsのSecretsに AWS_ROLE_ARN を登録します。

AWS CLI / SDK での認証確認

これは必ずしも必須ではありませんが、Github Actionsが意図通りに動かない場合は、以下のコードをyamlに追記してIAMロールを適切に引き受けられているのかを確認すると良いです。

以上で設定完了です。アクセスキー方式より煩雑ではありますが、一度行えばセキュリティを保ってGithub Actionsを運用できます。

概要

AWS上で稼働するアプリが増えてくると、アプリごとにOrganizationを作りたくなります。この際、スイッチロールという機能を使うとOrganizationごとにIAMユーザーを作る必要がなくなり、ユーザー管理をシンプルにできます。本記事ではスイッチロールの方法について記載します。

以下、「スイッチ元Organization」および「スイッチ先Organization」のことを単に「スイッチ元」および「スイッチ先」と記載します。

スイッチ先ごとに一度だけやれば良い設定

スイッチ先での設定

管理者アカウントで、スイッチ先にログインします。

ロールを新規作成します。

「別のAWSアカウント」を選択し、アカウントIDにスイッチ元のAWSアカウントIDを入力します。「MFAが必要」にもチェックをつけた方が良いでしょう。

次に進み、スイッチ先で割り当てたい権限をつけます。この例では、Administrator権限を割り当てています。

最後にロール名をつけて、ロールの作成完了します。ロール名は「delegate_root_organization」といった分かりやすい名前が良いでしょう。

作成したロールのARNを控えておきます。

スイッチ元での設定

管理者アカウントで、スイッチ元にログインします。

ポリシーを新規作成します。Resourceには、スイッチ先で作成したロールのARNを入力します。

次へ進み、ポリシーの名前をつけて、ポリシーの作成を完了します。ポリシー名には「delegate_from_スイッチ先Organization名」といった分かりやすい名前が良いでしょう。また、複数のスイッチ先にスイッチできる権限を持つポリシーも作成できますが、スイッチ先ごとにポリシーを作成し各人が関わる必要最低限の権限を付与できるようにした方が良いでしょう。

スイッチ先を利用する各人が実施する必要のある設定

スイッチ元にログインします。

ポリシーの追加

スイッチしたいIAMユーザーに、「スイッチ元での設定」で作成したポリシーを追加します。

スイッチ実行

ではスイッチをしてみましょう。メニューから「ロールの切り替え」を選択します。

スイッチ先のアカウントID、ロール名、表示名を入力します。

「ロールの切り替え」ボタンをクリックすると、スイッチ先にログインしたのと同じ状態になります。

スイッチしていることは、右上のメニューで分かります。上部のバナー全体に色が変わるなどもう少し目立つと良いのですが。

スイッチ元に戻りたい場合は以下のようにメニューから選択します。

to_jsonメソッドの注意点

ActiveSupportには、to_jsonという便利なメソッドがあります。 Railsで開発しているときに使う場面としては、DBから取得したレコードをAPIのレスポンスとして返す場合があります。

出力される属性がこれだけなら、それほど大きな問題がないようにも見えます。しかし、userモデルには、サービスへの機能追加に伴ってプライベートな情報が追加されやすいため、そういった情報がto_jsonメソッドで出力されてしまったり、あるいは、本人以外のuser情報も併せて一覧で取得するような場合に、他人の emailやプライベートな情報が含まれてしまったりすると個人情報の漏洩問題になる可能性があります。

したがって、to_jsonメソッドで出力する属性を制限するべきかどうかについて、注意し検討する必要が出てきます。

解決策

幸い、to_jsonメソッドでは、オプションを指定することで、出力を絞り込むことができます。

methodsオプションは、特定の属性を絞り込むというよりかは、追加で情報を出力する用途に使いますが、関連する機能なので併せて説明します。

以下、各オプションの使用例を示します。

only

さきほどの例で、onlyを指定すると、以下のように指定した属性だけが出力されます。

except

さきほどの例で、exceptを指定すると、以下のように指定した属性以外のものが出力されます（※）。 ※読みやすくするために、改行を入れています。

include

さきほどの例で、includeを指定すると、以下のように指定したassociationの属性も併せて出力されます（※）。 ※ some_associationという属性がある前提です。

なお、includeで指定したassociation内でも出力する属性を制限したい場合は、以下のように書けます。

methods

さきほどの例で、methodsを指定すると、以下のように指定したメソッドの呼び出し結果も併せて出力されます（※）。 ※some_methodというメソッドがある前提です。

背景

上述のような危険な実装をコードレビューのみに頼らずに、Rubyの静的コード解析ツールであるRuboCopで機械的にチェックする方法を、当ページでは記載します。

手順

rubocop gemはインストール済みの前提で記載します。

チェック対象のコード

以下の4行目をエラーとすることを目標にします。

ASTの出力

rubocop gemを入れていれば使えるruby-parse というコマンドでASTを出力します。

検知したいのは、この

の部分です。また、renderメソッドの第二引数のstatusは省略可能な引数ですので、第二引数の有無にかかわらず検知できるようにしたいです。

カスタムルールの作成

• renderメソッドを呼び出していて

• その引数にはjsonという名前付き引数を指定しており

• 第二引数以降は問わない

というマッチャを記述しlib/custom_cops/dangerous_render_json.rb として配置します。

次に、.rubocop.ymlにて、今作ったカスタムルールを読み込む設定を追記します。

動作確認

rubocopコマンドを実行して動作確認をします。

うまくいけば、以下のように、エラーとして検知できます。

脆弱性診断の依頼内容

A社とB社の2社に、同時にある弊社Webシステムの脆弱性診断を依頼させていただきました。 A社はWebアプリケーション診断を得意とし、B社はソースコード診断を得意とする会社様です。 Webアプリケーション診断とソースコード診断は、それぞれ以下のような特徴を持ちます。

• Webアプリケーション診断

  攻撃者目線でWebアプリケーションに対して擬似的に攻撃を行う診断。 「脆弱性診断」と聞くとこちらをイメージする方が多いかもしれません。

• ソースコード診断

  ソースコードを直接目視にて確認する、ソースコードレビュー型の診断。 プログラム構造や設計に起因する問題を発見できる可能性が高く、外部からの攻撃による診断では発見が難しい脆弱性を発見できる可能性がある。

診断結果総評

Webアプリケーション診断、ソースコード診断、どちらも何点か指摘事項をいただきましたが、注目すべきは同じ指摘が1つもなかったことです。

詳しい指摘事項についてここで書くことはできませんが、外部からの攻撃で発見可能な問題と、内側からのソースコード診断で発見可能な問題は異なる可能性がある、ということが実感できました。

もちろんソースコード診断については外部から攻撃されることのない脆弱性であれば問題がない、という見方もできるかもしれません。しかし今回いただいた指摘に関しては、たまたま外部からの攻撃で発見されなかったと考えられるものもありました。

診断方法による特徴の比較

ソースコード診断もWebアプリケーション診断もそれぞれ特徴があることがわかりました。 以下にまとめてみたいと思います。

指摘の性質

診断を行う観点が異なるため、出てくる指摘事項の性質も異なります。

• Webアプリケーション診断 外部から実際に擬似攻撃を行うため、危険度の高低はあれど、確実な問題を指摘していただける。

• ソースコード診断 外部からの攻撃が成立するか否かに関わらず丁寧に診断いただけるため、ソースコードについても将来問題になる可能性を指摘していただける。

診断にかかる手間

Webアプリケーション診断の方が、脆弱性診断の依頼にかかる手間が大きいです。これは以下のような理由によります。

• Webアプリケーション診断

  • 診断対象がAPI単位になる。APIの本数で値段が変化するため、予算によっては対象のAPIを絞るといった作業が必要になる。

  • APIの仕様など、アプリケーションの仕様について連携する必要がある。

  • 脆弱性診断実施用の環境を用意したり、開発用のサーバーを一時的に脆弱性診断用に利用いただくのであれば診断予定日は開発者が利用しないようにするなど、調整が必要になる。

• ソースコード診断

  • 基本的にはソースコードを開示すれば良い。

  • アプリケーションの実行環境は用意するが、攻撃を行うわけではないため、サーバーのブロックなどが必要ない。

まとめ

今回診断を2社に依頼したところ、複数のご指摘をいただきましたが、重大な脆弱性につながる指摘はなく、アプリケーション自体はよくできている、との評価をいただくことができました。

いただいたご指摘は軽微なものであるものの、すでに対応を実施し、完了しています。

Webアプリケーション診断とソースコード診断は診断の手法および視点が異なるものであり、出てくる指摘事項も異なるものとなります。 目的に応じてベストな診断は変わってくるかと思います。 適切な診断方法を選択するのが良いでしょう。

概要

開発中にスイッチロール先でAWS CLIを利用したい場面もあるかと思います。 その場合の設定内容について記載します。

状況定義

以下のようにアカウント設定されているとします。

• スイッチ元アカウント

  • ID: 123456789012

  • aws configure でデフォルトのプロファイルに設定済

• スイッチ先アカウント1

  • ID: 210987654321

  • スイッチで引き受けるロール: arn:aws:iam::210987654321:role/delegate_root_organization

  • スイッチするときに使うプロファイル名: sw-staging

• スイッチ先アカウント2

  • ID: 111111111111

  • スイッチで引き受けるロール: arn:aws:iam::111111111111:role/delegate_root_organization

  • スイッチするときに使うプロファイル名: sw-production

準備: configファイルでの設定

スイッチ元のアカウントを aws configure で設定済みであれば、およそ以下のような設定になっているはずです。

[default]
region = ap-northeast-1
output = json

[default]
aws_access_key_id = ***
aws_secret_access_key = ***

~/.aws/config に設定を追記し、以下のようにします。

[default]
region = ap-northeast-1
output = json

[profile sw-staging]
source_profile = default
role_arn = arn:aws:iam::210987654321:role/delegate_root_organization
mfa_serial = arn:aws:iam::123456789012:mfa/your.mail@example.com

[profile sw-production]
source_profile = default
role_arn = arn:aws:iam::111111111111:role/delegate_root_organization
mfa_serial = arn:aws:iam::123456789012:mfa/your.mail@example.com

このとき、設定内容は以下のようにします。

• プロファイル名（sw-staging, sw-production）: 任意の名前で大丈夫です。CLIで利用するときにこの名前を指定します

• source_profile: スイッチ元のプロファイルを指定します

• role_arn: スイッチロールで引き受けるロールのARNを指定します

• mfa_serial: スイッチ元でMFAを設定している場合、MFAデバイスのARNを設定します

実行方法

インタラクティブに実行できるかどうかで方法が変わってきます。

CLIをインタラクティブに実行するとき

ユーザー自身が aws s3 ls を実行する場合など、インタラクティブに実行できる場合は、以下の2通りの方法が利用できます。

• --profile 引数にプロファイル名を指定

• AWS_PROFILE 環境変数にプロファイル名を指定

例としては以下のとおりです。

% aws --profile sw-staging s3 ls
Enter MFA code for arn:aws:iam::123456789012:mfa/your.mail@example.com: # MFAコード利用の場合、認証コードの入力を求められます
# ...スイッチ先アカウント1のS3バケットが表示されます

% AWS_PROFILE=sw-production aws s3 ls
Enter MFA code for arn:aws:iam::123456789012:mfa/your.mail@example.com:
# ...スイッチ先アカウント2のS3バケットが表示されます

個人的には、以下のように使い分けると便利かと思います。

• 引数: チーム内で同じアカウントは同じ名前に統一しておけば、コマンドを共有するだけでスイッチロールして実行させることができます

• 環境変数: シェルスクリプトにまとまっているときなど、コマンドを書き換えたくないときに便利です

CLIをバッチ実行する必要があるとき

role_wrapper.sh という名前で以下スクリプトを作成します（jq コマンドが必要です）。

#!/bin/bash

set -euo pipefail

code=$1
shift

# assume-role
aws_credentials=$(
  aws sts assume-role \
    --role-arn arn:aws:iam::210987654321:role/delegate_root_organization \
    --role-session-name session-staging \
    --serial-number arn:aws:iam::123456789012:mfa/your.mail@example.com \
    --token-code ${code}
)

# assume-roleの結果をAWS環境変数に展開
export AWS_ACCESS_KEY_ID=$(echo $aws_credentials | jq -r '.Credentials.AccessKeyId')
export AWS_SECRET_ACCESS_KEY=$(echo $aws_credentials | jq -r '.Credentials.SecretAccessKey')
export AWS_SESSION_TOKEN=$(echo $aws_credentials | jq -r '.Credentials.SessionToken')

# 処理を実行
$@

これを使って、以下のように実行します。

% ./role_wrapper.sh <MFAコード> aws s3 ls

ビジュアルリグレッションテスト（Visual Regression Test）とは

ビジュアルリグレッションテスト（以下、VRT）は、画像回帰テストとも呼ばれます。

VRTは、改修による予期せぬ UI のデザイン崩れを検出することを目的としています。 UIのスクリーンショットを撮り、それらをコミット間で比較して、変更を特定します。

Storybookの運用イメージ

当社のReactを利用したプロジェクトではデザインシステムの構築にStorybookを利用しています。 細かい運用はこの記事では割愛しますが、見た目上のバリエーションが存在するコンポーネントについては、1つのコンポーネントにつき下記の２画面を用意するようにしています。

• Basic: StorybookのControlsアドオンを利用して動作確認できる

• All: バリエーションが一覧できる

VRTの導入手順

導入するツール

• • reg-keygen-git-hash-plugin: 比較すべきコミットを特定します。

  • reg-notify-github-plugin: GitHubのPRにレポートを通知します。

  • reg-publish-s3-plugin: 差分レポートをS3にアップロードします

これらのツールを組み合わせることで、Pull Requestにテスト結果の通知が届くようになります。 通知内のリンクから、さらに詳細なレポートを確認することもできます。

package.jsonの記述

yarnやnpmを利用して、パッケージのインストールをおこなってください。 npm-scriptsにも、CIで動かすためのタスクを追加します。

{
    ...
    "scripts": {
      "build-storybook": "build-storybook",
      "ci:vrt": "reg-suit run",
      "ci:storybook-generate": "build-storybook -c .storybook -o dist-storybook -s public",
      "ci:storycap": "storycap --serverTimeout 60000 --captureTimeout 10000 --serverCmd 'npx http-server dist-storybook --ci -p 9009' http://localhost:9009",
    },
    ...
    "devDependencies": {
      ...
      "reg-keygen-git-hash-plugin": "0.10.16",
      "reg-notify-github-plugin": "0.10.16",
      "reg-publish-s3-plugin": "0.10.16",
      "reg-suit": "0.10.16",
      "storybook-addon-next-router": "3.0.5",
      "storycap": "3.0.4",
      ...
    },
}
  

GitHub Actions で正常に動かなったため、タスクを「Storybookのビルド（ci:storybook-generate）」と「スクリーンショットの撮影（ci:storycap）」に分割しています。

storycap --serverCmd "start-storybook -p 9001" http://localhost:9001

CIツールによっては、タスク分割せずに実行が可能かもしれません。

regconfig.jsonの記述

reg-suitの設定ファイルです。

% npx reg-suit init

のコマンドでひな形を生成することができます。

{
  "core": {
    "workingDir": ".reg",
    "actualDir": "__screenshots__",
    "thresholdRate": 0.001,
    "addIgnore": true,
    "ximgdiff": {
      "invocationType": "client"
    }
  },
  "plugins": {
    "reg-keygen-git-hash-plugin": true,
    "reg-notify-github-plugin": {
      "prComment": true,
      "prCommentBehavior": "default",
      "clientId": "$REG_NOTICE_CLIENT_ID"
    },
    "reg-publish-s3-plugin": {
      "bucketName": "your bucket name",
      "acl": "private"
    }
  }
}

GitHub Actions ワークフローの記述

ワークフローをトリガーするGitHubイベントは、pull_requestではなく、pushである必要があります。

ubuntu-latestのイメージには、日本語が含まれていないため、日本語フォントインストールのジョブを入れています。Storybook上で日本語を利用していない場合は不要です。

name: Visual Regression Testing
on: push
jobs:
  build:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [14.x]
    steps:
      - name: Checkout
        uses: actions/checkout@25a956c84d5dd820d28caab9f86b8d183aeeff3d
        with:
          fetch-depth: 0
      - name: Use Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@aa759c6c94d3800c55b8601f21ba4b2371704cb7
        with:
          node-version: ${{ matrix.node-version }}
          cache: yarn
      - name: Japanese Font Install
        run: sudo apt install fonts-noto-cjk
      - name: Install dependencies
        run: yarn --frozen-lockfile
      - name: workaround for detached HEAD
        run: git checkout ${GITHUB_REF#refs/heads/} || git checkout -b ${GITHUB_REF#refs/heads/} && git pull
      - name: run storybook generate
        run: yarn run ci:storybook-generate
      - name: run storycap
        run: yarn ci:storycap
      - name: run reg-suit
        run: yarn ci:vrt

env:
  REG_NOTICE_CLIENT_ID: ${{ secrets.REG_NOTICE_CLIENT_ID }}
  AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
  AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

これらのID/KEYは、GitHubのsecretに登録する必要があります。 以上でVRTのために必要な設定は完了です。

画面幅の異なるスクリーンショットを撮る設定

上記の設定だけでもVRTとして正しく機能しますが、プレセナでは画面幅に応じた見た目の変化など細かくUIを確認できるようにしています。

module.exports = {
  ...
  addons: [
    ...
    'storycap', // addonとして、storycapを追加
    ...
  ],
  ...
}