かまたま日記3

プログラミングメイン、たまに日常

退職しました３

日記

4月で約2年半所属した前職を退職しました。お世話になった皆さんありがとうございました。

これまで

SREチームとしてインフラ周りを幅広く見ていました。アプリケーション開発以外の仕事は大体やったと思います。一部ですが具体的には以下の様なことをやってました。

また、SREからロールチェンジを希望して半年ほどReactを使った新規のアプリケーション開発を経験させてもらったり、それに合わせてフィリピンに出張に行ったりしました。フィリピン出張は会社生活の中で一番印象に残ってる出来事です。

退職/転職の理由とか

一番大きなトリガーになったのは、昨年子供が誕生したことです。仕事以外のプライベートの時間がほぼ子育てに費やされることになり、勉強時間や趣味プログラミングの時間がが激減しました。その上で、今後の自分のキャリアをどうしたいかと考えたとき、インフラではなくもっと直接的なソフトウェア開発の方に重きを置きたいと考えるようになりました。また、経済面においても子供にかかる費用(消費財系, 保育料, 将来に向けた教育費, 第2子など)を考えると、今までより多くの給与をいただきたくなった次第です。

これから

5月からTD社のお世話になっています。Hosted EmbulkであるData Connector/Result Outputを提供しているIntegrationチームというところに所属しています。技術力や英語力的なところで足りない部分も多いと思いますが、早くバリュー出せるように頑張ります。

例のもの

http://amzn.asia/b8ubFYx

*1:https://kamatama41.hatenablog.com/archive/category/Embulk

embulk-input-remote v0.4.1 リリース

Embulk

約1年ぶりのリリース、0.4.0はGemはリリースできたのですが、CircleCIからの自動タグ付けに失敗したので新しいのをリリースしました..w
0.3系から仕様は変わってませんがEmbulk 0.9にあげたりKotlinとかその他の依存ライブラリやGradleのバージョンを全部最新にしました。

CircleCI上のRSpecのテスト時間をparallel_split_testを使って短縮する

Ruby CircleCI テスト

CircleCIを使ってテストを実行する場合、テストはcircleci tests splitコマンドで分割した上で複数コンテナを使うことでテストの実行時間を短縮することができます(参考リンク)。ただ、コンテナ数を増やすのも限界がありますし*1、少し前までtiming-based splittingがCircleCI Workflowでは有効にならないという問題もあり、コンテナごとのテストケース数や実行時間に偏りがあって、結局一番遅いコンテナに引きづられてスループットが思ったより上がらないという問題がありました。*2

そこで、コンテナ上でさらにテスト(RSpec)を並列実行することで、コンテナごとの実行時間を短縮し、それによって全体のスループットを上げるというのを試みてみました。

Gem探し

RSpecを並列実行するGemは何個かあって、rrrspec, parallel_tests, rspec-parallelなどがありますが、一長一短があり、どれもしっくり来ない感じでした。悩みポイントとしては、こちらのqiitaの記事で書かれていることがかなり近いです。

qiita.com

こちらの記事のyuku_tさんがが作られたparallel-rspecも試してみたのですが、まだProduction Readyでないようで通常のRSpecの挙動と違うところがあり、自分のケースでは使えませんでした。

それで色々他を探した結果 parallel_split_test というGemに行き着きました。こちらは最小限のハックでRSpecを拡張していて、なおかつファイルベースではなくspecベースでテストを分散できるという、まさに自分の求めるものでした。*3

使ってみる on CircleCI

使い方は至ってシンプルで、 rspec コマンドを parallel_split_test に変えるだけです、rspecで使っているオプションは全部使える(はず)です。 CircleCI的な実行の仕方としてはこんな感じになると思います。デフォルトのmediumコンテナは2CPUなので並列実行数(PARALLEL_SPLIT_TEST_PROCESSES)は2を指定しています。

export PARALLEL_SPLIT_TEST_PROCESSES=2
bundle exec parallel_split_test --profile 10 \
  --format RspecJunitFormatter \
  --out /tmp/test-results/rspec.xml \
  --no-merge \
  --format progress \
  $(circleci tests glob "spec/**/*_spec.rb" | circleci tests split --split-by=timings)

--no-merge オプション

このオプションはparallel_split_test独自のオプションです。これを付けない場合、 アウトプットで指定したファイル*4に各プロセスの実行結果がすべてマージされます。 RspecJunitFormatter の場合各プロセスの実行結果それぞれが個別のxmlファイルになって、マージされるとxmlのフォーマットではなくなってしまうので、--no-mergeオプションをつけることで別々のファイルに書き出します。ファイル名は、もともと指定したものにプロセス番号が追加されます*5。CircleCIは複数の結果ファイルをよしなにマージして集計してくれるので、この方法で全部のテスト結果を集計できます。

パッチ当てた

また、使ってる中で何個かはまったポイントはPRだして修正したりして、自分の使っているケースでは今はちゃんと動いています。 https://github.com/grosser/parallel_split_test/pull/13 https://github.com/grosser/parallel_split_test/pull/14 https://github.com/grosser/parallel_split_test/pull/15

よかったら、使ってみて下さい！

*1:お金が無限にあればその限りではない

*2:time-based効かない問題は2018/01ごろに解決しています、参考リンク

*3:ちょっとgemの名前がジェネラル過ぎるんじゃないかとか、このGem自体のテストが難しいというのもあったりしますが...w

*4:ここでは /tmp/test-results/rspec.xml

*5:この例の場合 /tmp/test-results/rspec.1.xml のようになる

envsubstで簡易テンプレートを実現する

linux ShellScript

設定ファイルとかで一部だけ可変にしたテンプレートを使いたいんだけど、RubyとかPerlみたいな別言語を使うまでも無くシェルスクリプトだけで完結したい場合、envsubstコマンドを使うとテンプレートに環境変数を埋め込むことが出来ます。

インストール (on Ubuntu)

% docker run -it --rm ubuntu:16.04 

root@a70695314424:/# apt-get update
root@a70695314424:/# apt-get install gettext-base -y
root@a70695314424:/# envsubst --version
envsubst (GNU gettext-runtime) 0.19.7
Copyright (C) 2003-2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by Bruno Haible.

使い方

root@a70695314424:/# envsubst --help
Usage: envsubst [OPTION] [SHELL-FORMAT]

Substitutes the values of environment variables.

Operation mode:
  -v, --variables             output the variables occurring in SHELL-FORMAT

Informative output:
  -h, --help                  display this help and exit
  -V, --version               output version information and exit

In normal operation mode, standard input is copied to standard output,
with references to environment variables of the form $VARIABLE or ${VARIABLE}
being replaced with the corresponding values.  If a SHELL-FORMAT is given,
only those environment variables that are referenced in SHELL-FORMAT are
substituted; otherwise all environment variables references occurring in
standard input are substituted.

When --variables is used, standard input is ignored, and the output consists
of the environment variables that are referenced in SHELL-FORMAT, one per line.

Report bugs to <bug-gnu-gettext@gnu.org>.

標準入力が標準出力にアウトプットされます。標準入力中の $VARIABLE もしくは ${VARIABLE} が実際の環境変数に置換されます。

root@a70695314424:/# echo 'pwd=${PWD}' > sample.tpl
root@a70695314424:/# envsubst < sample.tpl
pwd=/

基本的にはファイルに書き込んで使います

root@a70695314424:/# envsubst < sample.tpl > sample.txt
root@a70695314424:/# cat sample.txt
pwd=/

SHELL-FORMAT が指定されてる場合、そこに書かれている変数だけが使われます、デフォルトは全環境変数が利用可能

root@a70695314424:/# echo 'pwd=${PWD} home=${HOME}' > sample.tpl
root@a70695314424:/# envsubst '$HOME' < sample.tpl
pwd=${PWD} home=/root

--variables が指定されてる場合、標準入力は無視されて SHELL-FORMAT で指定されている変数名が出力されます (値ではない)。

root@a70695314424:/# envsubst --variables '$HOME $PWD FOO'
HOME
PWD

クラスインスタンス変数はそのクラスからしか参照できない

Ruby

RubyのクラスはClassクラスのオブジェクトなので、インスタンス変数を持てます。クラスレベルとかクラスメソッドの中で定義された@付きの変数はクラスインスタンス変数(Class Instance Variable)と呼ばれ、そのクラスからしか参照できません、継承されてる場合、継承先でも参照できません。仕事中に継承しているクラスでBaseの値を参照しようとしてちょっとハマった次第であります。

バージョンは2.5.0です。

class Base
  def self.get
    @keys
  end

  def self.add(key)
    @keys ||= []
    @keys << key
  end

  add("Base")
end

class A1 < Base
  add("A1-1")
  add("A1-2")
end

class A2 < A1
  add("A2")
end

class B1 < Base
  add("B1")
end

class B2 < B1
  add("B2")
end

puts "Base=#{Base.get}"
puts "A1=#{A1.get}"
puts "A2=#{A2.get}"
puts "B1=#{B1.get}"
puts "B2=#{B2.get}"

出力はこんな感じになります。

Base=["Base"]
A1=["A1-1", "A1-2"]
A2=["A2"]
B1=["B1"]
B2=["B2"]

なので、継承ツリー上にある全部の @keys の値が欲しい場合、全部で get をしてやる必要があります。

p A2.ancestors.select{|k| k <= Base}.inject([]){|sum, k| sum + k.get}
=> ["A2", "A1-1", "A1-2", "Base"]

JenkinsでJobを起動して、終了まで待つシェルスクリプト

ShellScript Jenkins

jqとcurlがインストールされている必要があります。Jenkinsのバージョンは 2.46.3 で認証を有効にしています。

#!/bin/bash
#
# Trigger a Jenkins build and wait for the build to finish.
#
set -eu

JENKINS_HOST="jenkins.kamatama41.com"
JENKINS_USER=kamatama41
JENKINS_TOKEN=xxxxxxxxxx
JENKINS_JOB="a-jenkins-job"
BODY=$(cat << EOS
{"parameter": [
  {"name":"FOO", "value":"BAR"}
]}
EOS
)

get_build_status() {
  local build_number=$1
  curl -sS --fail \
    --user ${JENKINS_USER}:${JENKINS_TOKEN} \
    https://${JENKINS_HOST}/job/${JENKINS_JOB}/${build_number}/api/json
}

echo "Start to build ${JENKINS_JOB} with ${BODY}"

last_build_id=$(get_build_status lastBuild | jq -r .id)
echo "Last build_id is #${last_build_id}"

# Trigger the Job
curl -sS --fail -X POST \
  --user ${JENKINS_USER}:${JENKINS_TOKEN} \
  --data-urlencode json="${BODY}" \
  https://${JENKINS_HOST}/job/${JENKINS_JOB}/build

# Wait for new build to start
build_id=$(get_build_status lastBuild | jq -r .id)
wait_seconds=3
while [ "${build_id}" == "${last_build_id}" ]; do
  echo "New build is not running yet, wait for ${wait_seconds} seconds..."
  sleep ${wait_seconds}
  build_id=$(get_build_status lastBuild | jq -r .id)
done

echo "A new build has been started."
echo "https://${JENKINS_HOST}/job/${JENKINS_JOB}/${build_id}/"

# Wait for the build to end
result=$(get_build_status ${build_id} | jq -r .result)
wait_seconds=30
while [ "${result}" == "null" ]; do
  echo "Build is not finished yet, wait for ${wait_seconds} seconds..."
  sleep ${wait_seconds}
  result=$(get_build_status ${build_id} | jq -r .result)
done

if [ "${result}" != "SUCCESS" ]; then
  echo "Not succeeded, result is ${result}."
  exit 1
else
  echo "Succeeded!"
fi

解説

  • /job/${JOB_NAME}/${BUILD_ID}/api/json でビルドのステータスをJSONで取得出来ます。 lastBuild をIDに指定すると、最後に実施された(or 実施中の)ビルド状態を取得できます
  • /job/${JOB_NAME}/build にPOSTすると、新しいビルドをトリガー出来ます、JSONでビルドパラメタを渡すことも可能です。 トリガーされたビルドは開始されるまで数秒のタイムラグがあるので、最初にlastBuildのidを取得しておき、ポーリングして番号が変わったらそれが今回起動されたビルドだと判断しています。*1
  • その後はビルドステータスをポーリングし、resultがnullで無くなったらビルド完了と判断します。

*1:並列にバンバンビルドが起動されている環境だとこのやり方は誤検知の可能性があります。厳密にチェックする方法も無くはないのですが、面倒なので今回のケースではこういう方法を選びました。