okhttpのCacheControl.Builder.maxStale()
okhttpのCacheControl.Builder.maxStale()の挙動を勘違いしてた。
たとえばこんなコードを書いたとする。
val CACHE_CONTROL = CacheControl.Builder() .maxAge(5, TimeUnit.MINUTES) .maxStale( Integer.MAX_VALUE, TimeUnit.SECONDS) .build() val call = okhttpClient.newCall( Request.Builder() .cacheControl(CACHE_CONTROL) .url(url) )続きを読む
Toastの再利用
Androidで、サービス等のUIを持たないコンポーネントから画面にテキストを表示するToastというAPIがある。
割と昔からあるものなので挙動も同じだろうと思っていたら、某社の端末(未発売)でトラブルがあった。
その端末のバグっぽい印象だったので割と邪道な対応で済ませたが、それについてはあまり詳しく書けない。
ついでに手持ちの他の端末でも簡単なテストを行ってみた。
- トースト を表示して4秒経過したらトーストをキャンセルして、トーストへの参照をnullで上書きする。
- トースト を前回表示してから4秒未満で再度トーストを表示した時に、以下のいずれかの処理を行う。
- キャンセルした後に再利用(setTextして再度show)
- キャンセルせずに再利用(setTextして再度show)
- キャンセルした後に新しくmakeTextしてshow
- キャンセルせずに新しくmakeTextしてshow
結果
キャンセルして再利用
-
- 4.4.2～9.0 でうまくいかない。文章は更新されるが、最初のトーストが表示されてから4秒で消えてしまう。
キャンセルせずに再利用
-
- 4.4.2の端末ではOK。最後に文章を更新してshowしてから4秒でトーストが消える。
- 7.1.1の端末ではNG。文章は更新されるが、最初のトーストが表示されてから4秒で消えてしまう。
- 8.0.0の端末ではNG。文章は更新される(+トーストの表示がちらつく)が、最初のトーストが表示されてから4秒で消えてしまう。
- 9.0.0の端末ではNG。文章は更新される(+トーストの表示がちらつく)が、連打するとすぐにトーストが消えてしまう。
キャンセルした後に新しくmakeTextしてshow
-
- 特に問題は見られなかった
キャンセルせずに新しくmakeTextしてshow
-
- 端末によってはトーストがキューに溜まり遅延が発生する
コード例
package jp.juggler.toastsample import android.os.Bundle import android.os.Handler import android.support.v7.app.AppCompatActivity import android.util.Log import android.view.Gravity import android.view.View import android.widget.Toast class MainActivity : AppCompatActivity() { companion object { private const val LOGTAG = "ToastSample" } lateinit var handler : Handler lateinit var btnCancel : View private var nCount = 0 private var lastToast : Toast? = null override fun onCreate(savedInstanceState : Bundle?) { super.onCreate(savedInstanceState) setContentView(R.layout.activity_main) handler = Handler() btnCancel = findViewById<View>(R.id.btnCancel) btnCancel.setOnClickListener { toastRemover.run() } btnCancel.isEnabled = false findViewById<View>(R.id.btnShow1).setOnClickListener { showToast(1) } findViewById<View>(R.id.btnShow2).setOnClickListener { showToast(2) } findViewById<View>(R.id.btnShow3).setOnClickListener { showToast(3) } findViewById<View>(R.id.btnShow4).setOnClickListener { showToast(4) } } private val toastRemover : Runnable = object : Runnable { override fun run() { handler.removeCallbacks(this) lastToast?.cancel() lastToast = null btnCancel.isEnabled = false } } private fun showToast(type : Int) { try { val gravity = Gravity.BOTTOM or Gravity.CENTER_HORIZONTAL val text = "Toast ${++ nCount}" val duration = Toast.LENGTH_LONG var toast = lastToast if(toast != null) { when(type) { 1 -> { // キャンセルして再利用 toast.cancel() toast.setText(text) toast.duration = duration } 2 -> { // キャンセルせずに再利用 toast.setText(text) toast.duration = duration } 3 -> { // キャンセルして新しく作成 toast.cancel() toast = Toast.makeText(this, text, duration) lastToast = toast } 4 -> { // キャンセルせず新しく作成 toast = Toast.makeText(this, text, duration) lastToast = toast } } toast?.setGravity(gravity, 0, 0) toast?.show() } else { toast = Toast.makeText(this, text, duration) lastToast = toast toast.setGravity(gravity, 0, 0) toast.show() } handler.removeCallbacks(toastRemover) handler.postDelayed(toastRemover, 4000L) btnCancel.isEnabled = true } catch(ex : Throwable) { Log.e(LOGTAG, "showToast failed.", ex) } } }
ToastCompat
API level 25 以上で BadTokenException が出る不具合は ToastCompat https://github.com/drakeet/ToastCompat を使うと改善する。
KotlinのCoroutineScopeのメモ
やっとexperimental が外れたのでボチボチ使っていきたい。
https://github.com/Kotlin/kotlinx.coroutines/blob/master/coroutines-guide.md や http://kotlinlang.org/docs/reference/coroutines/exception-handling.html を読みながら理解しようとしたが、サンプルを見ても「なぜこういう挙動になるのか」が分からないのでソースコードを読んでみた。
コルーチンとは何か
コルーチンは停止(yield)と再開(resume)が可能な実行単位である。スレッドと異なり停止中はリソースを占有しないように考慮されているし、Dispatcherが抽象化されているので、必要ならAndroidのメインスレッド上でコルーチンを動かすこともできる。
意外なことに、Coroutine そのものが名づけられた クラスやインタフェースは 存在しない。存在するのは Continuation
コルーチンの開始。CoroutineStart.invoke() の内部から startCoroutine が呼ばれ、組み込み関数の createCoroutineなんたら() により 「サスペンド可能なラムダ式」が「Continuation
コルーチンがどのスレッドで実行されるかはDispatcherによって異なる。 runBlocking{} は呼び出し元スレッドでイベントループを回す。 launch{},async{}はcontextに指定されたDispatcherがなければ Dispatchers.Default を使う。Dispatchersには数種類のDispatcherが定義されている。
Continuation
https://github.com/JetBrains/kotlin/blob/master/libraries/stdlib/coroutines/jvm/src/kotlin/coroutines/intrinsics/IntrinsicsJvm.kt#L155 によると completion 引数のcontext が使われるらしい。
CoroutineContext
https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.coroutines/-coroutine-context/index.html
コルーチン(Continuation
- 属性のキーは CoroutineContext.Key である。参照アドレスでの比較が行われる。
- 属性の値は CoroutineContext.Element である。ElementそのものもCoroutineContextである。
- キーの定数はJobやContinuationInterceptorのコンパニオンオブジェクトが使われる
- EventLoopBase は CoroutineDispatcher である。 CoroutineDispatcher は ContinuationInterceptor である。
- CoroutineContext は合成できる。左辺の属性の一部が右辺の属性で上書きされる。
- 派生クラス CombinedContextなど
kotlin.coroutines パッケージに coroutineContext という suspend property が定義されている。
coroutine か suspend function からのみ suspend property にアクセスできる。
suspend fun の内部から現在のCoroutineContextを取得することができる。
Job
https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines/-job/
Jobはコルーチンの実行状態を示す。キャンセルや完了待機などの状態を持つ。
JobはCoroutineContextの一部として扱われるため、Job のベースクラスは CoroutineContext.Element と CoroutineContext である。Job どうしを合成することは可能だが、意味がないので合成結果は右辺そのものとなる。
Jobオブジェクトを扱う機会
- キャンセルのための親ジョブを作る時
- launch{} や async{} の戻り値
Jobオブジェクトへの操作
- join(), joinAll(), cancel(), cancelAndJoin()
Jobには親子関係がある。
コード中のコメントから引用
coroutineContext内のJobインスタンスは、コルーチン自体を表します。
ジョブは親ジョブを持つことができます。
親を持つジョブは、その親が取り消されるとキャンセルされます。
親ジョブは すべての子プロセスが完了するまで_completing_ または _cancelling_ 状態で待機します。
_completing_状態は、ジョブの純粋な内部状態であることに注意してください。
_completing_ ジョブは外部から観察したらまだ _active_ なように見えますが、内部的には子たちのために待機しています。ジョブの失敗と通常のキャンセルはキャンセル例外のcauseの種別により区別されます。
キャンセル例外のcauseが[CancellationException]の場合、ジョブ通常のキャンセルされたと解釈されます。
追加パラメータなしでキャンセルが呼び出された時にこれは発生します。
もしキャンセル例外のcauseがその他の例外だった場合、ジョブは失敗したと解釈されます。
ジョブのコードで問題が起きて例外が投げられた時にこれは発生します。Jobインタフェースと派生した全てのインタフェースの関数はスレッドセーフであり
外部の同期なしで並行するコルーチンから安全に呼び出すことができます。
キャンセル時の例外ハンドリングではcauseも表示しておくべきか。
Job() ヘルパ関数は JobImpl(parent=null) を作成する。JobImpl はJobSupportである。
JobSupport クラスには cancelsParent プロパティがあり、キャンセル発生時に親をキャンセルするかどうかを決定する。
JobImpl cancelsParent=true, onCancelComplete=true, handlesException=false のプロパティがJobSupportと異なる。
コード中のコメントから引用
private fun cancelParent(cause: Throwable): Boolean {
// (causeが)CancellationExceptionなのは "通常"と解釈され、子供がそれを生成した場合は親はキャンセルされない。
// これにより、子がクラッシュしてその完了時に他の例外が生成されない限り、親は自身をキャンセルせずに子を（通常の）キャンセルすることができます。
...
}
Structured concurrency https://medium.com/@elizarov/structured-concurrency-722d765aa952 の正体は、Jobの親子関係と JobSupport の cancelsParent プロパティだった。
CoroutineScope
CoroutineScope は通常、ラムダ式へのレシーバ変数として提供される。
- coroutineContextプロパティへのアクセス
- 拡張関数 actor, async, broadcast, launch, newCoroutineContext, plus, produce, promise
- 派生クラス GlobalScope, ActorScope, ProducerScope
- CoroutineScope + CoroutineContext でスコープを合成できる
スコープの絶縁
runBlocking,coroutineScope,launch,async等のスコープ作成関数で作成したスコープ(ジョブ)は、その内部で作成した子スコープ(ジョブ)が全て終了するまでは終了しない。これはこれで便利なのだが、ライフサイクル的には親子のスコープ(ジョブ)を絶縁したい場合がある。
間違った例 coroutineScope{}
coroutineScope{} はコード外側のコンテキストからJob以外を継承してJobを新しくしたスコープを作成してblockを実行する。内部のJobのキャンセルがcoroutineScopeよりも外側に影響しないので絶縁できたかのように思えるが、他のスコープ作成関数と同様、coroutineScope{}自体は内部で作成した子ジョブが全て終了するまでブロックしてしまう。
val producer = coroutineScope{ produce<Int>{ (1..3).forEach { channel.send(it) } } }
この例は外側のスコープとproducerを分離しようとしているが、coroutineScope{} は produceのコードブロックが完了するまでブロックする。この時点ではproducer変数からデータを読む処理は開始しないので、ここで永遠にブロックしてしまう。
正しい例1 GlobalScope
GlobalScopeはEmptyCoroutineContext を持つグローバル定数。JobもDispatcherも割り当てられていない。
CoroutineScope(context) と同様、親スコープと子ジョブを分離する際に使われる。
val producer = GlobalScope.produce<Int>{ (1..3).forEach { channel.send(it) } }
この例ではGlobalScopeを親にすることで、コードの外側のスコープとproducerのスコープを完全に分離する。
実際には必要に応じてproduceの引数にDispatcherやJob等のコンテキストを追加する。
正しい例2 CoroutineScope(context) ヘルパ関数 と SupervisorJob()
https://github.com/Kotlin/kotlinx.coroutines/blob/master/docs/exception-handling.md#supervision
val supervisor = SupervisorJob() with(CoroutineScope(coroutineContext + supervisor)) { val producer = produce<Int>{ (1..3).forEach { channel.send(it) } } }
CoroutineScope() はコードの外側のスコープの影響を受けない。
また、もし引数のコンテキストにJobが含まれなければ空のジョブを追加する。
スコープを絶縁した後の注意
スコープの絶縁はコルーチンをリークさせる可能性がある。上の例ではproducer 変数のチャネルはcapacity=0 で作成されるため、チャネルからデータが読み取られるまでsend() の部分でブロックする。作成したコルーチンのライフサイクルをプログラマが管理する必要がある。
AbstractCoroutine
@InternalCoroutinesApi なのでユーザがこのクラスを直接利用することはないが書いておく。
runBlocking などのレシーバ変数(is CoroutineScope) は実際には BlockingCoroutine 等の、AbstractCoroutine の派生クラスである。
AbstractCoroutine はJobSupportであり、Jobであり、Continuationであり、CoroutineScope である。
１つのクラスに複数の役割が持たせられている理由はおそらくオブジェクト確保を減らすためだろう。
Continuation
AbstractCoroutine作成時の引数 parentContext の指定は runBlocking() 等ではデフォルト値 EmptyCoroutineContext となっている。AbstractCoroutineのJobSupportには cancelsParent=true が設定されているので、もし parentContextが存在すればブロック内部で発生したキャンセルは親に伝達される。
asyncとlaunch
https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines/async.html
https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines/launch.html
launchはコルーチンを開始してJobを返す。
asyncはコルーチンを開始してDeferredを返す。DeferredはJobであるが戻り値の扱いが多少異なる。
asyncとlaunchはどちらも newCoroutineContext() を使って外側のコンテキストを引き継ぎ、指定がなければディスパッチャをDispatchers.Defaultにする。親Jobがあればキャンセル発生時にキャンセルの伝達が起きる。
newCoroutineContext() は外側のコンテキストと引数(省略時はEmptyCoroutineContext)のコンテキストを合成し、ディスパッチャの指定がなければDispatchers.Defaultを補う。
asyncとlaunch はそっくりだが少しだけ異なる。
- launch は StandaloneCoroutine か LazyStandaloneCoroutine を生成、startしてそれを返す
- async は DeferredCoroutine かLazyDeferredCoroutine を生成、startしてそれを返す
そして StandaloneCoroutine と DeferredCoroutine もそっくりだ。
- どちらもAbstractCoroutineである。cancelsParent=trueに設定される。
- DeferredCoroutine はDeferred
, SelectClause1 である。await() と onAwait と registerSelectClause1() が用意される。
CoroutineExceptionHandler
launch で非同期処理を行う際に CoroutineExceptionHandler というCoroutineContextを追加することで例外を補足できる。
しかし実際に試してみると Structured Concurrency と相性が悪く、親スコープが例外を処理してしまうとそこで例外が再送出されてしまう。
直接の親のジョブをSupervisorJobにするだけでは足りない。 GlobalScope、親ジョブのないCoroutineScope(SupervisorJob)、SupervidorScopeなどを使う。
val handler = CoroutineExceptionHandler { _, exception -> println("handler caught $exception") println("thread ${Thread.currentThread().name}") } val supervisor = SupervisorJob() // NG // coroutineScope { // launch(handler) { // error("inside launch1") // } // delay(1000) // } // NG // runBlocking(supervisor) { // launch(handler) { // error("inside launch2") // } // delay(1000) // } // OK GlobalScope.launch(handler) { error("inside launch3") } delay(1000) // OK with(CoroutineScope(supervisor)){ launch(handler) { error("inside launch4") } delay(1000) } supervisorScope{ launch(handler) { error("inside launch5") } delay(1000) }
Docker構成のMastodonに組み込んだpgbouncerの監視をmuninに追加する
「Docker構成のMastodonに後からpgBouncerを組み込む http://d.hatena.ne.jp/tateisu/20170418/1492457904 」の続きです。
https://github.com/munin-monitoring/contrib/blob/master/plugins/postgresql/pgbouncer_ を使ってみたというただそれだけの記事です。
pgbouncer への接続に必要な情報を確認する
まず mastodonの.env.productionに指定ているDB接続情報を確認します
例
DB_HOST=db DB_USER=bouncer DB_NAME=postgres DB_PASS=XXXXXXXXXXXXXXXXX DB_PORT=5432 DB_POOL=20
この例では DB_HOSTが'db' になっています。
これはdockerが内部で管理するホスト名なのでdockerの外からはそのままではアクセスできません。
pgbounderを動かしてるコンテナのポートマッピングを確認します。
例
$ docker ps (略) XXXXXXXX gavinmroy/alpine-pgbouncer "/bin/sh -c /start.sh" (略) 172.17.0.1:5432->5432/tcp, 6432/tcp mastodon1_db_1 (略)
この例では 172.17.0.1:5432 に接続できそうです
pgbouncer に管理ユーザを追加する
pgboucer には管理用の疑似データベース pgbouncer があります。
そのデータベースに接続すると管理用コマンドを使えます。
pgbouncer の userlist.txt に下記の行を追加
"bouncer_admin" "XXXXXXXXXXXXXXXXXX"
パスワード部分は適当に生成するなりダイジェスト化するなりしてください
pgbouncerのpgbouncer.ini を編集
; comma-separated list of users, who are allowed to change settings ;admin_users = user2, someadmin, otheradmin admin_users = bouncer_admin
pgbouncer にHUPシグナルを送って設定をリロード
pkill -HUP pgbouncer
接続プールの名前を確認する
psql -h 172.17.0.1 -p 5432 -U bouncer_admin pgbouncer -c 'show pools;' (略) database | user | cl_active | cl_waiting | sv_active | sv_idle | sv_used | sv_tested | sv_login | maxwait | pool_mode -----------+-----------+-----------+------------+-----------+---------+---------+-----------+----------+---------+------------- pgbouncer | pgbouncer | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | statement postgres | postgres | 65 | 0 | 0 | 3 | 4 | 0 | 0 | 0 | transaction (2 rows)
この例だと postgres が接続プールの名前になるようです
pgbouncer プラグインをインストール
https://github.com/munin-monitoring/contrib/blob/master/plugins/postgresql/pgbouncer_
をRAW表示して/etc/munin/plugins にコピーしてchmod 755 します。
また、ファイル名は pgbounder_(プール名) にしておきます
pgbouncer プラグインの設定
/etc/munin/plugin-conf.d/munin-node に以下のセクションを追加します
[pgbouncer_postgres] env.pgbouncer_host 172.17.0.1 env.pgbouncer_port 5432 # env.pgbouncer_pool postgres env.pgbouncer_user bouncer_admin env.pgbouncer_pass XXXXXXXXXXXXXXXXXX
セクション名の部分は pgbouncer プラグイン のファイル名と揃えます。
接続情報の部分は 接続プールの名前を確認した時の情報と揃えます。
env.pgbouncer_pool はスクリプト名末尾と実際のプール名が異なる場合だけ指定するのが良いようです。
動作確認
以下のコマンドを実行してプラグインの動作を確認します。
munin-run pgbouncer_postgres config munin-run pgbouncer_postgres
私の環境ではパッケージの追加インストールが必要でした。
apt install libdbd-pg-perl
munin-nodeの再起動
sudo /etc/init.d/munin-node try-restart
今すぐグラフを生成する
su - munin --shell=/usr/bin/munin-cron
作成直後は数値がNaNになるみたいですが、5-10分ほど待ってリロードすると解決します
Docker構成のMastodonでImageMagickのポリシーを変えてGhostscriptの脆弱性に対応する
Ghostscript に緊急レベルの脆弱性、悪用攻撃も発生
https://japan.zdnet.com/article/35100535/
MastodonではImageMagick経由でGhostscriptが呼び出される場合があります。
今回はImageMagickの設定ファイルを変更することでGhostscriptの呼び出しを回避します。
また、今回は行いませんが ImageMagick の policy.xml ではメモリリソースの使用量の調整も可能です。
コンテナからImageMagickの設定フォルダを取り出す
cd (docker-compose.yml のあるフォルダ) docker cp mastodon1_web_run_1:/etc/ImageMagick-7 . mv ImageMagick-7 etc-ImageMagick-7
policy.xml を編集
emacs ./etc-ImageMagick-7/policy.xml
policy.xml のコメント部分におすすめの設定が書いてあります
Rules are processed in order. Here we want to restrict ImageMagick to only
read or write a small subset of proven web-safe image types:
<policy domain="delegate" rights="none" pattern="*" />
<policy domain="coder" rights="none" pattern="*" />
<policy domain="coder" rights="read|write" pattern="{GIF,JPEG,PNG,WEBP}" />
この3行を の手前にコピペします
変更した設定フォルダをボリュームに指定する
docker-compose.yml を編集します
web とsidekiqのコンテナのvolumes の指定に追加します
- ./etc-ImageMagick-7:/etc/ImageMagick-7
再起動
一度コンテナを削除してから作り直すため、まだDBの永続化を行っていない方は行っておいてください。少し前の記事で説明しています。 http://d.hatena.ne.jp/tateisu/20170416/1492341633
dockerのコンテナを再起動します。
# stop じゃなくてdown。コンテナはrmされる docker-compose down # 起動 docker-compose up -d
sidekiq コンテナを増やしている方は docker-compose scale もお忘れなく
Subway Tooter
Subway Tooter
https://play.google.com/store/apps/details?id=jp.juggler.subwaytooter
Android用のMastodonクライアントアプリです。
2017年4月23日に Playストアで公開しました。
(某所の「アプリを最速でリリースした話」よりさらに早い&速い)
当時の痕跡 https://mastodon.juggler.jp/@tateisu/450607
マルチカラム
公開当時から複数アカウントに対応してます。アカウントの切り替え操作も不要。画面を左右にフリックして複数のカラムを閲覧できます。カラムは好きなように追加/削除できます。並び順も変更可能です。これはTweetDeckやJanetterやtwitcle plusに似た操作性ですね。
絵文字対応
絵文字対応も頑張りました。私はMastodonの自分のアカウントの表示名に :juggling: などの絵文字を設定しているのですが、これを絵文字に変換して表示してくれるスマホアプリはまだSubway Tooterだけだと思います。
cross-account operation
複数アカウント対応の応用として「別のアカウントでフォロー」「(同タンスの)別のアカウントでお気に入り/ブースト」ができるようにしました。
メディアつき発言のみ表示
v0.1.5から、メディアつき発言のみ表示を任意のタイムラインで行うことができるようになりました。某アプリと違ってアプリ側で無理矢理実装してるので負荷はやや高いですが、どのインスタンスでもローカルTLでも連合TLでもハッシュタグでも使えるのが良いところです。
ソース公開
今後について
現状では開発に回せるリソースがさほどある訳でもないので、時間のある間に自分の欲しい機能を一通り実装してしまいたいです。アップデートは不定期になると思います。
追記
Subway Tooter の 説明/宣伝用のblog を用意しました http://subwaytooter.hatenadiary.jp/
Docker構成のMastodonに後からpgBouncerを組み込む
背景
mastodon.juggler.jp はここ数日はサーバの人数1100〜1050、1日間のアクティブユーザ270人くらいで人数はあまり変わってません。しかしユーザ間のフォローが増えるにつれて、発言、ブースト、お気に入りで発生するFan-outが大量にsidekiqのキューに積まれるのが目立ってきました。特にdefaultキューに処理が溜まるとユーザへの応答性が低下します。
Push通知は計算よりも通信待機が多いのでキューを処理するスレッドを増やすのが効果的です。
それに必要なのがCPU、メモリ、そしてDBサーバへの接続数です。
今回はDBサーバへの接続数を稼ぐために、DBサーバとアプリケーションの間にpgBouncerを設置してみます。
期待される効果
Docker構成のMastodon で使われているDBサーバの初期設定では max_connectionが100 になっていますが、この接続一つごとにプロセスを一つ使ってしまいます。
pgBouncerを使ってDB接続の中継を行うと、アプリ側に必要な接続数を増やしつつもDBサーバ側のプロセス数を節約することができます。
pgbouncerイメージの取得
pgbouncerイメージの取得と設定ファイルの雛型の抽出を行います。
docker run --rm --name test-pgbouncer -it gavinmroy/alpine-pgbouncer sh
でコンテナ中にログインできたら、以下の作業を行います。
Mastodonの停止とコンテナの削除
あらかじめdbサーバはデータをホスト側のフォルダに出して永続化しておいてください。
このあたりは前回の記事で説明しています。 http://d.hatena.ne.jp/tateisu/20170416/1492341633
また、データベースにはMastodonに必要なデータが既に一通り定義されているものとします。
docker-compose down
でMastodonの停止と関連コンテナの削除が行われます。
データベースのサービス定義の名前変更
docker-compose.ymlを編集します。サービス定義の内、名前が「db:」となっているものを「db_backend:」という名前に変更します。
pgbouncer設定ファイルの用意
.env.production にある DB_で始まる設定値をテキストエディタにコピーしておきます。
docker-compose.ymlがあるフォルダの下に pgbouncerフォルダを作成します。
その中に pgbouncer.ini と userlist.txt を作成します。
パーミッションと内容は先ほどメモしたものに合わせてください。
userlist.txt には「"bouncer" "(新パスワード)" 」という行を記述します。パスワードは適当に生成してください。
pgbouncer.iniには以下の編集を行います。
[database]セクションにバックエンドへの接続を書きます。
「postgres = host=db_backend port=5432 dbname=postgres user=postgres password=(DBパスワード)」
- hostに指定するのは、データベースサーバのサービス定義の名前です。先ほどdb_backendに変更しましたね？
- port,dbname,user,passwordに指定するのは、これまでDB接続に使っていたのと同じ情報です。先ほど .env.production からメモしましたね？
[pgbouncer]セクションの以下の情報を編集します。
listen_addr = 0.0.0.0 listen_port = 5432 auth_type = plain auth_file = /etc/pgbouncer/userlist.txt pool_mode = transaction max_client_conn = 900 default_pool_size = 20
pgBouncerのサービス定義を追加
docker-compose.ymlを編集します。以下のようなサービス定義を追加します。
db:
restart: always
image: gavinmroy/alpine-pgbouncer
volumes:
- ./pgbouncer:/etc/pgbouncer
expose:
- "5432"
depends_on:
- db_backendpgbouncer.ini のlisten_post とdocker-compose.ymlの exposeの指定が同じポート番号か確認しましょう。
.env.production の編集
.env.production の設定値を、bouncerへの接続に適したものに変更します。
- DB_HOSTに指定する名前は、docker-compose.ymlのpgBouncer用サービス定義の名前と一致させます。
- DB_NAMEに指定する名前はpgbouncer.ini の[database]セクションに指定した接続情報の左端の名前と一致させます。
- DB_USERに指定する名前はuserlist.txt に指定したユーザと一致させます。
- DB_PASSに指定するパスワードはuserlist.txt に指定した新パスワードと一致させます。
- 末尾にある PREPARED_STATEMENTS=false をアンコメントします。
データベースを利用するアプリはこれらの環境変数を使って接続するようになります。
動作確認
docker-compose up -d して問題がなければ成功です。
うまくいかない場合は以下をチェックしてください
- docker ps -a で出るポート指定は期待通りになっているか。expose漏れはないか。
- docker-compose logs -f db でログイン周りのエラーが出ていないか
- docker-compose logs -f db_backend でログイン周りのエラーが出ていないか
- docker-compose logs -f で prepared statement に関するエラーが出ていないか。PREPARED_STATEMENTS=false を設定し忘れてないか
関連記事
- Docker構成のMastodonに組み込んだpgbouncerの監視をmuninに追加する http://d.hatena.ne.jp/tateisu/20171014/1507969046
