ロギングサービスコンテナ の構築「中編」です。
前回（前編）では、起動したコンテナへVSCodeから リモート接続 する環境を整えました。
今回は「Gitを操作するための環境構築」と「サンプルプログラムの作成＆デバッグ」を進めていきます。
前編
A. ファイルのエンコードと改行コード
B. ロギングサービス コンテナの作成
C. VSCode からのリモート接続
中編
D. コンテナ内からGitを操作するための環境構築
E. サンプルプログラムの作成
F. サンプルプログラムのデバッグ
後編
G. ロギングサービス メイン処理の作成
H. ログ出力のテスト
D. コンテナ内からGitを操作するための環境構築
VSCodeからコンテナにリモート接続した状態で、ソースコードのバージョン管理（コミットなど）を行えるように環境を整えます。
1. 現状の課題
コンテナにはホスト側の src フォルダのみがマウントされています。
そのため、プロジェクトのルートフォルダにあるGitの管理フォルダ（.git）をコンテナ内から参照できず、VSCodeのソース管理機能を使うことができません。
2. 解決策：プロジェクト全体をマウントし、作業フォルダを限定する
この課題を解決するため、以下の2つの設定を行います。
プロジェクトルートをコンテナにマウントする
ホストOSのプロジェクトルートフォルダ（sample-product）全体をコンテナにマウントします。これにより、コンテナ内から.gitフォルダへアクセスできるようになります。
VSCodeの作業フォルダを限定する
コンテナに接続したVSCodeのエクスプローラーに表示される範囲を、開発対象のloggingフォルダのみに限定します。これにより、誤ってコンテナ外のファイル（docker-compose.ymlなど）を操作してしまうリスクを低減できます。
作業フォルダ に.gitフォルダが無くても Git 操作は可能です。
現在の作業フォルダから親フォルダへと遡って.gitフォルダを探し始め、最初に見つかった.gitフォルダの配置場所を Git リポジトリのルート と認識してくれます。
3.設定ファイルの修正
前述の解決策を実現するために、docker-compose_dbg_log.ymlと.devcontainer/devcontainer.jsonを修正します。
docker-compose_dbg_log.yml の修正
volumesに2つのマウント設定を追加し、古いマウント設定（- ./logging/src:/app/src）を削除します。
volumes:
# 以下のマウント指定は 本番環境構築時には不要。
# Git操作のため、プロジェクトルートを「/workspaces」にマウントする。
# これにより、コンテナ内から .git フォルダにアクセス可能になる。
- .:/workspaces
# 開発/本番でパスを統一するため、loggingフォルダを「/app」にマウントする。
- ./logging:/app
loggingフォルダを/appにマウントすることで、開発用・本番用どちらのコンテナからでも、常に同じパス（/app）でファイルへアクセスできるようになります。
.devcontainer/devcontainer.json の修正
コンテナへリモート接続した VSCode からの誤操作を防ぐため、workspaceFolderへfiles.excludeを追加して .devcontainerフォルダや Dockerfile を非表示にしておきます。
// コンテナ内のワークスペース（作業フォルダ）
"workspaceFolder": "/workspaces/logging",
// (中略)
"settings": {
// (中略)
// エクスプローラーで特定のファイルやフォルダを非表示にする設定
"files.exclude": {
"**/.devcontainer/**": true, // .devcontainerフォルダ内のすべてを非表示
"**/Dockerfile": true // Dockerfileを非表示
}
}
修正後のファイルイメージ（docker-compose_dbg_log.yml）
services:
#----------------------------------------
# ロギング サービス
#----------------------------------------
logging-service:
build:
context: ./logging # Dockerfile 配置フォルダ
dockerfile: Dockerfile # Dockerfile 名
image: ${LOGGING_IMAGE_NAME} # ビルドイメージ名（タグ名）
container_name: ${LOGGING_CONTAINER_NAME} # コンテナ名
# サーバー再起動時やエラー発生時に自動でコンテナを再起動する。
# 開発作業に使用をきたす場合はコメントアウトすること。
#restart: always
# ★ 勝手に再起動されると支障が出るのでコメントアウト。
environment:
LOG_LEVEL: ${LOGGING_LOG_LEVEL} # ログ出力レベル
TZ: Asia/Tokyo # コンテナ全体を日本時間に設定
# PostgreSQL 接続情報
DB_HOST: db-service # サービス名
DB_PORT: 5432 # 既定のポート番号
DB_NAME: ${POSTGRES_DB} # データベース名
DB_USER: ${POSTGRES_USER} # データベースユーザー名
DB_PASSWORD: ${POSTGRES_PASSWORD} # データベースパスワード
# Valkey 接続情報
VALKEY_HOST: valkey-service # サービス名
VALKEY_PORT: 6379 # 既定のポート番号
VALKEY_PASSWORD: ${VALKEY_PASSWORD} # 認証パスワード
volumes:
# 以下のマウント指定は 本番環境構築時には不要。
# Git操作のため、プロジェクトルートを「/workspaces」にマウントする。
# これにより、コンテナ内から .git フォルダにアクセス可能になる。
- .:/workspaces
# 開発/本番でパスを統一するため、loggingフォルダを「/app」にマウントする。
- ./logging:/app
networks:
# コンテナ間 専用ネットワーク
- my_sample_network
# /dev/null ファイルを監視し続けるコマンド。
# 何もせずに待機し続けるため、コンテナがすぐに終了してしまうのを防ぐ。
# 本番環境 構築時には不要なので削除すること。
command: tail -f /dev/null
#********************************************************
# 独自ネットワークの定義
#********************************************************
networks:
my_sample_network:
修正後のファイルイメージ（devcontainer.json）
{
// VSCode は JSON with Comments (jsonc) をサポートしているため、
// コメント行を記述することが可能です。
// コンテナの名前（VS Code上での表示名）
"name": "logging service",
// プロジェクトルートにあるdocker-compose_dbg_log.ymlを指定
// （.devcontainerフォルダから見て２階層上にあるため '../../' を付加）
"dockerComposeFile": [
"../../docker-compose_dbg_log.yml"
],
// 接続するサービスの名前
"service": "logging-service",
// コンテナ内のワークスペース（作業フォルダ）
"workspaceFolder": "/workspaces/logging",
// VS Codeのカスタマイズ設定
"customizations": {
"vscode": {
// コンテナ内に自動でインストールする拡張機能
"extensions": [
"ms-python.python", // Python言語サポート
"ms-python.vscode-pylance", // 高機能なコード補完・分析
"charliermarsh.ruff", // 高速なリンター＆フォーマッター
"eamodio.gitlens", // Git機能の強化
"rooveterinaryinc.roo-cline" // Roo Code（開発用 AIエージェント）
],
// VS Codeエディタのコンテナ内での設定
"settings": {
// Ruffをデフォルトフォーマッターに設定
"[python]": {
"python.formatting.provider": "ruff",
"editor.formatOnSave": true
},
// Ruffの自動修正を有効化
"editor.codeActionsOnSave": {
"source.fixAll": "explicit"
},
// エクスプローラーで特定のファイルやフォルダを非表示にする設定
"files.exclude": {
"**/.devcontainer/**": true, // .devcontainerフォルダ内のすべてを非表示
"**/Dockerfile": true // Dockerfileを非表示
}
}
}
},
// 開発コンテナに接続するユーザーを指定
// Dockerfile で作成した 'devuser'ユーザーを指定する。
"remoteUser": "devuser"
}
4. Gitリポジトリの準備
次に、Gitリポジトリの初期化と設定を行います。
手順①： .gitignore ファイルの作成
バージョン管理の対象外とするファイルを指定する.gitignoreファイルを作成します。これにより、Pythonのキャッシュファイル（__pycache__）やVSCodeの設定フォルダ（.vscode）などが誤ってリポジトリに登録されるのを防ぎます。
プロダクトフォルダ（sample-product）直下に、以下の内容で.gitignoreファイルを作成します。
# バージョン管理から除外する Python 関連のフォルダ・ファイル
__pycache__/ # バイトコードキャッシュディレクトリ
*.py[cod] # コンパイル済みファイル（.pyc, .pyo, .pyd）
# バージョン管理から除外する VSCode 関連のフォルダ・ファイル
.vscode/
手順②： .gitattributes ファイルの作成
Gitがファイルの改行コードをどのように扱うかを定義する.gitattributesファイルを作成します。ホストOSとコンテナ間で改行コードの違いによる問題を防ぐため、リポジトリ内では常にLFに統一します。
プロダクトフォルダ（sample-product）直下に、以下の内容で.gitattributesファイルを作成します。
# すべてのファイルをテキストファイルとして扱い、改行コードは LF とする。
# ※ リポジトリには LF で格納。
# チェックアウトの際も 常に LF を維持する。
* text eol=lf
# LF コード変換を行わないファイルを「バイナリファイル」として宣言する。
# 必要に応じて追加すること。
*.jpg binary
*.jpeg binary
*.png binary
*.gif binary
*.bmp binary
*.ico binary
*.webp binary
*.svg binary
*.pdf binary
*.zip binary
*.tar binary
*.gz binary
*.7z binary
*.rar binary
*.exe binary
*.dll binary
*.obj binary
*.lib binary
*.bin binary
*.woff binary
*.woff2 binary
*.ttf binary
*.otf binary
*.eot binary
手順③： Gitリポジトリの初期化
VSCodeから ローカルリポジトリ（.gitフォルダ）を作成します。
① VSCodeを起動し、プロダクトフォルダ sample-product を開く
② VSCode サイドバーの「ソース管理」アイコンをクリック
③ ソース管理ペインの「リポジトリを初期化する」をクリック
手順④： リポジトリ固有の設定
ターミナルからgit configコマンドを実行し、このリポジトリ固有の設定を行います。
ここでの設定は、プロジェクト内の.git/configファイルに保存され、PC全体のGit設定（グローバル設定）には影響しません。
# コミットユーザー名とメールアドレス
# ★ user.name と user.email は、自身の使用する 名前 と メールアドレス に
# ★ 置き換えてください。
git config user.name "b-wind"
git config user.email "b-wind@example.dummy"
# 改行コードの自動変換を無効化
# VSCodeでLF強制、かつ.gitattributesでeol=lfを設定しているため、Gitによる自動変換は不要です。
git config core.autocrlf false
# コミットメッセージとログのエンコードをUTF-8に設定
# 日本語の文字化けを防ぎます。
git config i18n.commitencoding utf-8
git config i18n.logencoding utf-8
# 日本語ファイル名を正しく表示するため、パスのエスケープを無効化
git config core.quotepath false
# ファイル名の大文字・小文字を厳密に区別する設定
# Linuxコンテナとの整合性を高めます。
git config core.ignorecase false
コマンドの実行例
ローカルリポジトリへの初回コミット
リポジトリの初期化後、ソース管理ペインには「更新されたファイル」を示す "U" マーク付きのファイルが表示されます。
このすべてをローカルリポジトリへコミットします。
① ソース管理ペインを開き、未登録のファイル９本の存在を確認
③ 「メッセージ」欄に "初回登録" と入力後、「コミット」ボタンをクリック
④ 確認ダイアログが表示されたら「はい」ボタンをクリック
⑤ グラフペインにコミットした内容が表示されることを確認
環境構築結果の確認
コンテナへリモート接続し、エクスプローラペインの状態が想定どおりか否かを確認してみましょう。
① VSCode でコンテナ用フォルダ（loggingフォルダ）を開く
② 「コンテナーでリビルドして再度開く」でコンテナーをリビルドする
③ エクスプローラペインの表示内容を確認
リモート接続後のエクスプローラペイン
前回と似ていますが、ツリーの先頭項目が APPではなく、LOGGINGと表示されています。（devcontainer.jsonの"workspaceFolder"で指定したフォルダ名が表示されます）
上記以外のフォルダやファイルは表示されておらず、devcontainer.jsonに追加した設定によって うまく不可視化 されたようです。
他フォルダ内容の表示
ターミナルペインでlsコマンドを使うと、親フォルダ（/workspaces）直下のdocker-compose.yml や valkeyフォルダなどの存在を確認できます。
devcontainer.jsonに追加した 不可視化の設定 はターミナルペインに適用されず、「作業フォルダ（/workspaces/logging）」以外へ自由にアクセス可能という状態です。
コンテナフォルダ logging 以外のフォルダやファイルを誤って操作しないよう、十分に注意してください。
E. サンプルプログラムの作成
ここまでの作業により、リモート接続したVSCodeの中から ファイルの作成・編集 および ローカルリポジトリの操作 が可能となりました。
実際にテスト用のミニPythonプログラムを作成し、ローカルリポジトリへ登録（コミット）してみましょう。
① srcフォルダの下に test.py というファイルを作成する
② test.py にプログラムを記述する
import datetime
def main():
# プログラム開始ログ
print("INFO: プログラムを開始します。")
# 現在日時を成形して出力するINFOログ
current_time = datetime.datetime.now()
formatted_time = current_time.strftime("%Y-%m-%d %H:%M:%S")
print(f"INFO: 現在日時: {formatted_time}")
# HelloWorld的なサンプル処理
print("Hello, Docker & VSCode!")
print("これはリモート接続環境でのテストです。")
# プログラム終了ログ
print("INFO: プログラムを終了します。")
if __name__ == "__main__":
main()
③ 「ソース管理」ペインを開き、test.py をコミットする
④ 「グラフ」ペインを開き、コミットされたことを確認する
F. サンプルプログラムのデバッグ
作成したプログラムをデバッグ実行してみましょう。
print(f"INFO: 現在日時: {formatted_time}")の行に ブレークポイント を設定し、指定箇所での ブレーク と 変数内容の参照 が可能であることを確認します。
① 行番号をクリックして、ブレークポイントを設定する
② [実行]メニューの [デバッグの開始] をクリックする
③ [Python Debugger] をクリックする
④ [現在アクティブな Python ファイルをデバッグする] をクリックする
実行のブレーク
デバッグ実行が始まると、指定行ですぐにブレークします。
ブレーク行が黄色く反転しています。
「実行とデバッグ」ペインの [変数]-[Locals]には プログラム中で宣言した二つの変数名 および その格納値が表示されます。
続行 (F5) をクリックすると、ブレーク行の次行からプログラムの実行が続行されます。
出力結果の確認
プログラム内で print文から出力した内容は、ターミナルペインにそのまま出力されます。
終わりに
ようやくテストプログラムのデバッグ実行までたどり着きました。
次回はいよいよロギングサービスの作成ですが、こちらは AI によるコーディング作業も併用していくつもりです。ミニマムですが機能仕様を作成して AI へ指示することになると思われ、いわゆる バイブコーディング とは少し趣が異なる形になるかもしれません。