oinume journal

Scratchpad of what I learned

Goのcontextによるキャンセルやタイムアウト

これはなに?

Go言語におけるcontextパッケージを使ったキャンセルやタイムアウトについて説明する。この記事を読むと以下について詳しくなれるはず...!

  • context.WithCancel
  • context.WithTimeout
  • context.Done
  • context.Err

とはいいつつも、かなり自分向けのまとめではあるし既出のトピックなので以下の記事を読むともっとわかりやすいはず。

done channelを使ったキャンセルの実装

contextがあると何が嬉しいのかを説明するために、まずはdone channelを使ってキャンセルを行うコードを書いてみる。これはGo言語による並行処理のP.137に記載されていたサンプルプログラムを少し修正したものである。

このプログラムでやりたいことは、close(done)によってprintGreeting, printFarewell, genGreeting, genFarewell, localeの関数をキャンセルしたい、ということである。

このプログラムを実行すると以下の出力が得られる(場合によっては先にhello world!が出力されるかもしれない)。

$ go run context/done_chan/main.go
goodbye world!
hello world!

実行の流れとしては以下のようになっている(この図もGo言語による並行処理から引用)。

この図をより詳細に説明すると

  • main関数からprintGreetingとprintFarewellをgoroutineを起動して呼び出し、sync.WaitGroup.Waitを使って待つようにしている(L38)
  • printGreetingはgenGreeting -> locale の順番で関数を呼び出す
    • localeは select の中で <-time.After(5 * time.Second) で5秒待ち、EN/USを返す
    • genGreetingはlocale()の呼び出しがEN/USの場合 hello を返す
    • printGreetingはgenGreetingの戻り値を出力する
  • printFarewellもgenFarewell -> locale の順番で関数を呼び出す
    • localeは select の中で <-time.After(5 * time.Second) で5秒待ち、EN/USを返す
    • genFarewellはlocale()の呼び出しがEN/USの場合 goodbye を返す
    • printFarewellはgenGreetingの戻り値を出力する
  • printGreeting, printFarewellのgoroutineが終了したので、main関数は処理を抜ける。つまり defer close(done) が実行される(L12)

では、以下のように defer close(done) の部分を、close(done)した後にprintGreetingを呼び出すようにしたらどうなるだろうか?

defer func() {
    close(done)
    if err := printGreeting(done); err != nil {
        fmt.Printf("err=%v\n", err)
    }
}()

上のように修正して再度プログラムを実行すると、以下のように出力される。

$ go run context/done_chan/main.go
goodbye world!
hello world!
err = canceled

canceledがprintGreetingのerrorとして返ってきた。このerrorはlocale関数の以下の部分で生成されたもので、done channelがすでにcloseされたため、selectのこのcaseに処理が来たということである。

select {
case <-done:
    return "", fmt.Errorf("canceled")
    ...
}

このようにprintGreetingやprintFarewellをchannelをcloseすることでキャンセルを実現することができた。それでは次に、contextパッケージを使ったキャンセルのやり方を見てみよう。

contextを使ったキャンセルの実装

それでは、さきほどのdone channelの例をcontextを使って実装し直してみよう。

done channelの実装と比べた場合のポイントとしては以下である。

  • context.Background でroot contextを作成
  • context.WithCancel(ctx) では戻り値として子のcontextとキャンセルするための関数が返ってくる
  • このキャンセルするための関数 cancel を呼び出すことでキャンセル処理を実行する
  • printGreetingなどの関数の引数に ctx を渡す。これによって末端のlocaleまでctxを引き回している

このプログラムを実行してみると、以下のような出力になりcontextを使ってキャンセルが実装できたことが確認できた。これがcontextパッケージの大きな機能の一つである。

$ go run context/with_cancel/main.go
goodbye world!
hello world!
err = context canceled
  • ctx.Doneはcontextがキャンセルされるまでブロックされる受信専用のchannelを返す。このchannelからデータを取得できたということはキャンセルされたということなので、ctx.Err() でエラーを返すようにしている
  • context canceled というエラーはlocale関数のctx.Err() の戻り値である。contextパッケージにはCanceledというグローバル変数が定義されており、これが返却されている

タイムアウト

一番最初のdone channelのプログラムでは単純にprintGreetingやprintFarewellなどの関数の実行をキャンセルしたいタイミングでclose(done)しているだけだが、例えばprintGreetingやprintFarewell(およびこれらが呼び出す関数)の呼び出しを、一定時間が経過した場合にキャンセルしたいと思った場合はどうすればよいだろうか? context.WithTimeoutを使うことでそのような実装が簡単にできる。

  • genGreetingでcontext.WithTimeoutで1秒後にタイムアウトするようにして新しい子のcontextを生成する。そしてlocaleにそれを渡し、 defer cancel() する
  • main関数のprintGreetingを呼び出すgoroutineで、printGreetingが失敗したら他の関数呼び出しをキャンセルするためにcancelを呼び出す

このプログラムの実行結果は以下のようになる。

$ go run ./context/with_timeout/main.go
cannot print greeting: context deadline exceeded
cannot print farewell: context canceled

まとめ

contextを使うことでキャンセルやタイムアウトが簡単に実装できることを説明した。この内容については以下のGo言語による並行処理にすべて書かれているし、よりgoroutineや並行処理について知りたい場合はこの本を読んでみることを強くオススメする。

Go言語による並行処理

Go言語による並行処理

Amazon

zshをやめてbashにした

TL;DR

  • Bashを使うにあたって、zshが持つ標準機能のレベルと同じにするには初期設定が面倒だったけどなんとかいける。Bashは進化していると感じた。
  • bash-itが便利
  • 設定は .bash_profile も含めてoinume/dotfilesに上げているので参考にどうぞ

動機

ターミナル環境を見直す(1) - zsh + prezto編 - oinume journal の記事でデフォルトのshellをzshに切り替えたけど、tmuxでバンバン新しいタブを開くと起動の遅さが気になっていてそろそろどうにかしたいと思っていた。また、zshは便利だけど設定項目を覚えたり調べるのが大変だし、ほとんどの機能は使いこなせていなかったので、これを機にシンプルなbashに乗り換えてみた。この記事はその際にやったことのメモ。

以下によると次期macOS Catalinaではbashに代わってzshがデフォルトになるらしく、時代と逆行していて面白い。

support.apple.com

macOS mojaveに最新のbashをインストール

maxOS mojaveのデフォルトのbashは3.2.57と古いので、まずは最新のbashをhomebrewでインストールする。

$ brew install bash

chshでログインシェルを変更

brewでインストールしたbashは /usr/local/bin/bash にあるので、これをログインシェルとして変更する。

$ chsh -s /usr/local/bin/bash
(パスワードを聞かれる)
chsh: /usr/local/bin/bash: non-standard shell

しかし、↑のようなエラーになってしまうので、 sudo vi /etc/shells して /usr/local/bin/bash を追記してもう一度 chsh コマンドで変更する。

$ chsh -s /usr/local/bin/bash

Prompt

やはり素のプロンプトだと味気ないので、Prompt関連はけっこう設定をいじった。以下に詳細を書く。

Powerline

定番のPowerline。bash-powerlineというものがあったので、これを以下のように少しカスタマイズして使っている。(Macの場合プロンプトの記号が$ではなくになるのがどうしても嫌だった)

export PS_SYMBOL='$'
[ -f ~/dotfiles/bash-powerline.sh ] && . ~/dotfiles/bash-powerline.sh

カレントディレクトリの表示

デフォルトだとカレントディレクトリだけがプロンプトに表示されて、同じディレクトリが複数あるとどこにいるのかわからなくなる問題がある。zshだと ~/go/src/github.com/oinume/playground-go にいる場合は ~/g/s/g/o/playground-go のようにいい感じに省略してくれるので似たようなことがやりたかった。調べたところ、bashでもPROMPT_DIRTRIMという環境変数で似たようなことができる。PROMPT_DIRTRIM=2 にした場合は ~/.../oinume/playground-go のようになる。一つ上のディレクトリ名がわかれば良いと思ったので、自分としてはこれで満足している。

コマンド履歴のターミナル間での共有

zshでは当たり前にできるやつ。以下を .bash_profile に追加すればOK。

function share_history {
    history -a
    history -c
    history -r
}

PROMPT_COMMAND='share_history'
shopt -u histappend
export HISTSIZE=2000

過去に移動したディレクトリの検索

Bash の小枝集のcdhist.sh + fzf で検索できるようにしている。.bash_profileでの設定は以下のようになっていて、Ctrl+@で呼び出せるようにしている。

[ -f ~/dotfiles/cdhist.sh ] && . ~/dotfiles/cdhist.sh

_cd_cdhist() {
  cd "$(for i in "${CDHIST_CDQ[@]}"; do echo $i; done | fzf)"
}

bind -x '"\C-@": _cd_cdhist';

bash-it

様々なalias、補完、プラグインが用意されているbash-itというものを使ってみる。

以下のようにインストールする。

$ git clone --depth=1 https://github.com/Bash-it/bash-it.git ~/.bash_it
$ ~/.bash-it/install.sh

補完やプラグインを有効にする

$ bash-it enable completion bash-it
$ bash-it enable plugin xyz

上記のコマンドを実行すると、~/.bash-it/enabled にsymlinkが作成される。以下のコマンドで alias, completion, pluginの一覧を見ることができるので、自分が使いそうなものを有効にしていくと良い。

bash-it show aliases
bash-it show completions
bash-it show plugins

[改訂第3版]シェルスクリプト基本リファレンス ──#!/bin/shで、ここまでできる (WEB+DB PRESS plus)

[改訂第3版]シェルスクリプト基本リファレンス ──#!/bin/shで、ここまでできる (WEB+DB PRESS plus)

2019年5月の振り返り

仕事

4月はもっぱら仕事が忙しく、最終的にGWは半分以上出勤するという体たらくだったので振り返りはスキップしてしまった。おかげでメルペイあと払いのリリースは何とかできたけど、技術的負債が多すぎて運用で死んでいる。

アウトプット

GCPのCloud PubSubをGoで動かしてみただけのメモ のみ。とにかく仕事が忙しくてプライベートで勉強したり何かをアウトプットすることを疎かにしてしまった。おかげで仕事は捗った。

英語

  • 8月にIELTSを申し込んだ。受験料が2万5千円もするのでなかなか気軽には受けられないので気合を入れて勉強する
  • 忙しくてDMM英会話が1回しか受講できていない
  • IELTSを申し込んで自分を追い込んだことで、英単語の学習は少しずつ進んでいる
    • 英単語の本をKindleで読むと便利。わからない単語にマークをつけて簡単に復習できる。

アルゴリズム

Graphは深さ優先探索を実装した

algo/datastructure/graph at master · oinume/algo · GitHub

読んでいる本

Go言語による並行処理

Go言語による並行処理

Go言語による並行処理

  • 作者: Katherine Cox-Buday,山口能迪
  • 出版社/メーカー: オライリージャパン
  • 発売日: 2018/10/26
  • メディア: 単行本(ソフトカバー)
  • この商品を含むブログを見る

まだ40ページしか読んでいないけど、並行処理の概念(CSP)についても詳しく書かれてあって良い本だと思う。ゴルーチンやチャネルについてはあまり体系的に理解していなかったので自分にとっては今年一番の買ってよかった本。

ターミナル環境の見直し

ずっとzshを使っていたけど、自分が使っているのは以下の機能しかないのでbashに乗り換えようかと思っている。

  • 補完
  • Ctrl+@によるcdr
  • コマンド履歴をpecoで検索

ついでにpeco -> fzfへの移行も試している。

ターミナル環境を見直す: pecoからfzfへ

コマンドの履歴やディレクトリ移動の履歴を選択するためのツールとして長らくpecoを使ってきたけど、fzfに移行してみた。理由は大したものではなく

  • pecoはshellで複数行のコマンドを検索して実行する場合に、 \\\ と2重になってしまうという問題があった
  • 日本国外だとpecoではなくてfzfの方が使われていそう

というもの。

インストール

github.com

リポジトリのREADMEに書いてあるので省略

設定

cdr

ディレクトリの移動履歴をfzfで検索するようにする。zshの設定は以下のような感じ。

function fzf_cdr () {
  local selected_dir=$(cdr -l | awk '{ print $2 }' | fzf --query "$LBUFFER")
  if [ -n "$selected_dir" ]; then
    BUFFER="cd ${selected_dir}"
    zle accept-line
  fi
  zle clear-screen
}

zle -N fzf_cdr
bindkey "^@" fzf_cdr

function fzf_select_history() {
    local tac
    exists gtac && tac="gtac" || { exists tac && tac="tac" || { tac="tail -r" } }
    BUFFER=$(fc -l -n 1 | eval $tac | peco --query "$LBUFFER")
    CURSOR=$#BUFFER         # move cursor
    zle -R -c               # refresh
}

zle -N fzf_select_history
bindkey '^R' fzf_select_history

感想

pecoはshellで複数行のコマンドを検索して実行する場合に、 \\\ と2重になってしまうという問題があった

この問題が解決されたので自分としてはこれだけでも満足度が高い。また、fzfは環境変数で見た目や挙動を変えられるのが良いと思っている。自分は以下のように設定している。

export FZF_DEFAULT_COMMAND='rg --files --hidden --glob "!.git"'
export FZF_DEFAULT_OPTS='--height 60% --border'

zsh最強シェル入門

zsh最強シェル入門

GCPのCloud Runを使って簡単なリダイレクタを作った話

今年5月にbetaとしてリリースされたGCPのCloud Runを使って、もともとGAEで運用していたリダイレクタを移植してみたのでその紹介。

Cloud Runとは

HTTPリクエストを処理するためのFull ManagedなステートレスのContainerの実行環境。公式サイトには以下のように説明されている。

Cloud Run is a managed compute platform that enables you to run stateless containers that are invocable via HTTP requests

GCPでは、Full Managedな実行環境(PaaS)として

  • Google App Engine(Standard Edition)
  • Cloud Functions

が存在しているが、完全にContainerベースのCloud Runが新しく追加されたよ、という風に自分は認識している。

リダイレクタの詳細

というだけのもの。実際にはURLごとにリダイレクト先が異なるのでプログラムを書いている。もともとはGAE Standard Editionで動かしていた。

準備

  • GCPのプロジェクトを作る
  • gcloud components update を実施する
  • gcloud components beta を実施する
  • Cloud RunのRegionを設定する
    • gcloud config set run/region us-central1
  • Cloud Buildを有効にする
  • Container Registryを有効にする

Cloud Runで実行するコード

実際にCloud Runで実行するコードは以下のような感じ

Dockerfile

Cloud RunはContainerを実行するので、Dockerfileを用意する。やっていることは ./cmd/server/main.go をコンパイルして server というバイナリを生成しているだけ。

Cloud BuildでContainer Imageをdeployする

自動化も加味して、CircleCIからContainer Imageを生成してGCRにdeployするようにしてみる。CircleCIのconfig.ymlはこんな感じ。

実際は Makefile で実行しているのは以下のコマンドになる。

$ gcloud builds submit --project ${GCP_PROJECT_ID} \
  --tag gcr.io/$(GCP_PROJECT_ID)/server:${IMAGE_TAG}
  • GCP_PROJECT_ID: あなたのGCPのプロジェクトID
  • IMAGE_TAG: master-123 のような値になっている。CircleCI上でビルドするので IMAGE_TAG=$(echo "${CIRCLE_BRANCH}" | tr '._/' '-' | tr '[:upper:]' '[:lower:]')-"${CIRCLE_BUILD_NUM}" としている。ただこれはもっと良い生成方法があるかもしれない。

なお、CircleCIからgcloud buildsでGCRにimageをpushするときに以下のエラーが発生してハマった。

Uploading tarball of [.] to [gs://blog-lampetty-net-redirector_cloudbuild/source/1557916060.04-0e599d9522c1400ebb47e942a96cb9b2.tgz]
Created [https://cloudbuild.googleapis.com/v1/projects/blog-lampetty-net-redirector/builds/ec22748d-e4c6-4e10-ba89-f4e108cac0d8].
Logs are available at [https://console.cloud.google.com/gcr/builds/ec22748d-e4c6-4e10-ba89-f4e108cac0d8?project=310764868638].
ERROR: (gcloud.builds.submit) HTTPError 403: <?xml version='1.0' encoding='UTF-8'?><Error><Code>AccessDenied</Code><Message>Access denied.</Message><Details>circle-ci@blog-lampetty-net-redirector.iam.gserviceaccount.com does not have storage.objects.get access to 310764868638.cloudbuild-logs.googleusercontent.com/log-ec22748d-e4c6-4e10-ba89-f4e108cac0d8.txt.</Details></Error>

解決方法としてはここにあるように、Project ViewerのRoleをService Accountに対して付与しないといけない。もしくは、cloudbuild.yamlの設定で logsBucket を指定してここへのロールを追加すれば良い。

CircleCIからgcloudコマンドで最新のcontainer imageをCloud Runに反映する

これはまだ自動化していない。以下のコマンドで自分のマシンからCloud Runに反映している。

$ gcloud beta run deploy --project ${GCP_PROJECT_ID} --image gcr.io/${GCP_PROJECT_ID}/server:${IMAGE_TAG}

Service name (server):
Deploying container to Cloud Run service [server] in project [${GCP_PROJECT_ID}] region [us-central1]
✓ Deploying... Done.
  ✓ Creating Revision...
  ✓ Routing traffic...
Done.
Service [server] revision [server-00005] has been deployed and is serving traffic at https://xyz.a.run.app

コマンドを実行すると最後に表示される https://xyz.a.run.app がアプリケーションが動いているURLである。

独自ドメインの割り当て

Cloud Runによって自分のアプリケーションに割り当てられたURLを独自ドメインに変更することができる。以下のコマンドを使うか、Consoleから設定ができる。

$ gcloud beta run domain-mappings create

プログラマのためのGoogle Cloud Platform入門 サービスの全体像からクラウドネイティブアプリケーション構築まで

プログラマのためのGoogle Cloud Platform入門 サービスの全体像からクラウドネイティブアプリケーション構築まで

参考リンク