今日のバドミントン練習はお休み。

隔週の雑談⌗

顧問のはらさんと隔週の打ち合わせ。今日は先週末の開発合宿のふりかえりをした。

  • 1週間前ぐらいに参加者を集めて事前打ち合わせをして過ごし方の共有をした方がよかった
  • 周りと雑談してしまうので資料を合宿中に作るのはほとんど時間を取れない
  • もう3回目なのでお風呂へ入るのにも慣れが出てきてお気に入りの外湯へ行くようになった
  • 人数はどのぐらいが適正か？
    • 5人という人数は中途半端だったように思える
    • 8人は多過ぎた気はするから6人がちょうどよいのではないかと思える
  • 周辺の体験イベントにみんなで参加してみるのもよいかもしれない
    • あらかじめ希望をとっておく
  • 発表の時間を初日と2日目に分割したのはよかった
    • 夜に発表を固めなくてもよい
    • お昼でも夕方でもみんなが集まっている時間帯にさらに分散させるのがよさそう

細かいところはいろいろあるけれど、覚えているうちに意見をもらった。いつもはらさんが来てくれるから私の負担が低くなり本当に助かっている。

compose サービスの停止の振る舞い⌗

昨日の続き 。それぞれのサービスに depends_on を指定することで依存関係を定義できる。サービス起動時と停止時に依存するサービスが先に起動または停止するように順番を制御してくれる。但し、起動時のデフォルトはコンテナ起動をトリガーにするため healthcheck などを指定しないと厳密にサービスが起動しているかどうかはわからない。

compose サービスの起動は次の2つのコマンドがある。

  • up: すべての依存関係を調べてコンテナサービスを起動する、停止しているコンテナがなければ作成する
  • start: 停止しているコンテナのみを起動する

基本的には up を使っておけば運用上の問題は起きない。start を使う理由がなければ up を使うといった感覚でよい。一時的なメンテナンスなどで stop を使ってコンテナを停止し、そのコンテナだけ起動すればよいことがわかっていれば start を使った方がオーバーヘッドが少ないといったメリットはあるだろう。up と start の違いはそれほど気にしなくてもよい。

次に compose サービスの停止は次の2つのコマンドがある。

  • down: コンテナを削除する、関連するリソース (volume や network) もすべて削除する
  • stop: コンテナを削除せずに停止する

運用上どちらか一報を覚えておくなら down を使えばクリーンに再起動できると言える。コンテナが使うイメージのバージョンアップをするときなどはコンテナを削除する必要があるから down する方が手間がいらない。stop で停止したコンテナがあると、up でも start でもバージョンを自動的にあげてくれたりはせず、ただ停止したコンテナを起動するといった振る舞いになる。そのため、バージョンアップをするときは stop で停止した後に rm でコンテナを削除する必要がある。それなら最初から down で削除してしまってもよいと言える。compose の logs コマンドを使うと複数サービスのログを1つのストリームで監視できる。この状態で stop や down を実行してどういった振る舞いになるのかを検証できた。

$ docker compose logs -n 3 -f