🧭 背景とスタート地点
- 元々はバラけた構造と断片的なスクリプトの中で テストネットBotの再稼働に取り組む状況だった。
- 特に「Docker + Compose での一貫運用」と「config生成の自動化」「環境切り替えの安全性」を確保するには、構成の全面的な見直しが必要だった。
🛠️ リポジトリ再構築フェーズで乗り越えた課題
① コンテナが即終了する問題の原因特定と修正
- 症状:
docker compose up -d
でBotが即終了、ログはほとんど出ず。 - 原因:
.env.testnet
内の環境変数とテンプレート変数名(BYBIT_APIKEY
vsBYBIT_API_KEY
)の不一致。- Slack URLに改行が混入 → JSON 生成が壊れ
mmbot.cli
が静かに終了。 entrypoint.sh
を通さずrun
で確認していたため、JSON 未生成で混乱。
- 対処:
.env.testnet
を修正 → 変数名統一+改行除去。entrypoint.sh
のトレース実行(bash -x
)でどこで止まっているか可視化。jq
による構文検証+ログ出力強化。
② MMBOT_MODE
の二重定義問題と環境切り替え設計の確立
- 問題:
.env.testnet
とcompose.yml
の両方にMMBOT_MODE
が定義され、切り替えのつもりが上書きされていた。
- 対処:
.env.testnet
側のMMBOT_MODE
をコメントアウト。compose.yml
で${MMBOT_MODE:-testnet}
を使い、明示的に切り替える方式に統一。- 本番切り替えは
MMBOT_MODE=production docker compose up -d
の一撃に。
③ コンテナ内での構成検証とファイル出力の可視化
- ステップ:
docker compose run --entrypoint bash mmbot
でシェルに入る。bash -x /entrypoint.sh
で1行ずつ実行トレース。/app/config_testnet.json
の生成確認 →jq .
で内容を検証。
- 学び:
- “何が原因か分からない”ときは プロセスに潜って目で見ることが最短。
🚀 Bot再稼働に成功した瞬間
- 「📌 NEW SESSION: mode=testnet」ログが表示。
- Slack通知が飛び、テストネットUIでも注文が確認できた。
- これにより env → tpl → json → cli →通信の全ルートが通ったことを確認。
- 現時点で
docker compose up -d
から自律稼働までが完全再現可能な状態になった。
🔁 ローカル開発とGit運用の統一に向けた学びと課題
🔄 Gitとの整合
main
とのブランチ差分により、作業ブランチが吹き飛びかけるトラブル発生。git stash
とreflog
を活用して、安全にブランチを復元。- いまやるべきこと:ブランチ整理と commit 範囲の明確化(削除されそうなファイルの選別)
📌 この再構築フェーズで得た本質的な学び
課題 | 本質的な気づき |
---|---|
コンテナが即終了する | 「起動していないのではなく、静かに死んでいるだけ」 |
JSON未生成 | envsubst や jq を shellデバッグで追うことの重要性 |
構成崩壊 | tpl ↔ env ↔ JSON ↔ CLI の流れを明示し、トラブルは一段階上流で起きていると仮定せよ |
モード切替ミス | 「どこで定義して、どこで参照しているか」を明文化するだけでミスは半減する |
Git混乱 | 変更の意図と履歴は、粒度を持って管理されるべきであると実感 |
🏁 現在地と次のフェーズへ
✅ 現在
- テストネットで Botの再稼働に成功
- 起動構成/構造/再現手順をすべて掌握
.env
とtpl
の整合性が取れた構成でentrypoint → JSON生成 → Bot起動
が確実に再現可能
⏭️ 次のステップ
.env.production.example
の整備とドキュメント化- log rotation / restart / watchdog など 運用ガードの実装とテスト
- Git上の整理(featureブランチへの整理/不要ファイルの復旧または削除)
- CI への
--dry-run
テスト導入と GitHub Actions 連携設計