🧭 背景とスタート地点
- 元々はバラけた構造と断片的なスクリプトの中で テストネットBotの再稼働に取り組む状況だった。
- 特に「Docker + Compose での一貫運用」と「config生成の自動化」「環境切り替えの安全性」を確保するには、構成の全面的な見直しが必要だった。
🛠️ リポジトリ再構築フェーズで乗り越えた課題
① コンテナが即終了する問題の原因特定と修正
- 症状：
docker compose up -dでBotが即終了、ログはほとんど出ず。 - 原因：
.env.testnet内の環境変数とテンプレート変数名（BYBIT_APIKEYvsBYBIT_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 連携設計