こんにちは！てつです！
前回の連載第0回では、手動運用の限界を卒業し、インフラをコードで管理するIaC（Infrastructure as Code）の第一歩として、自宅サーバーとGitHubをSSHで安全に連携する土台を構築しました。
🔗 関連記事: [【第0回：GitHubで『自宅DevOps』構築編！】手動運用を卒業せよ！自宅サバ×GitHubで切り拓く自動化の未来]
「GitHubと自宅サバが繋がった！でも、ここからどうやってDevOps化していくの？」と思っている方も多いのではないでしょうか。
連載第1回となる今回は、いよいよ本格的な「インフラのコード化（資産化）」に踏み込みます。ターゲットは、モダンな自宅サーバー運用の主役である「Docker Compose（ドッカー・コンポーズ）」です。
この記事を読めば、自宅サバで動かしているコンテナの設定をGitHubで美しく管理できるようになり、万が一サーバーが物理的に壊れても「コマンド一発で10分以内に全く同じ環境をリビルドできる魔法」が手に入ります。
さらに、プロの現場では絶対に欠かせない「セキュリティ（機密情報の保護）」の鉄則についても、現役インフラエンジニアの視点から徹底的に噛み砕いて解説します。
趣味の領域を一歩超えて、実務でも通用する「プロ仕様の管理術」を一緒に身につけましょう！
1. なぜDocker Composeの設定ファイルをGitHubで「資産化」するべきなのか？
① 手動運用（職人芸）がもたらす2つの致命的リスク
具体的な手順に入る前に、インフラエンジニアとして「なぜこの作業を行うのか」というロジックを整理しておきます。ここが理解できていると、今後の応用力が劇的に変わります。
多くの初心者、あるいは中級者の方も、自宅サーバーで何かサービスを立ち上げる際、以下のような運用をしてしまいがちです。
- サーバーにSSHでログインし、その場で
docker-compose.ymlを直接書き換える。 - 「とりあえず動いたからよし」として、設定ファイルをサーバー内に放置する。
これらは、プロの現場では「構成のブラックボックス化（職人芸運用）」と呼ばれる最も避けるべき状態です。
サーバーのローカル環境だけに設定を眠らせておくと、以下のような致命的なリスクが生まれます。
- 再現性の喪失：ストレージの物理故障などでサーバーが死んだ際、過去の自分がどう設定したか思い出せず、二度と同じ環境を復元できなくなる。
- 変更履歴の迷宮入り：昨日まで動いていたのに、今日動かなくなった。自分が「どこの行をどう書き換えたか」を追跡できない。
② プロの現場で導入されている「GitOps」の思想とは？
企業のWebサービスやクラウドインフラ（AWSなど）の運用現場では、サーバーに直接ログインして設定を書き換える行為は原則として禁止されています。
すべての設定はまずGit（GitHubなど）という「コードの保管庫」に集約し、コードを修正・レビューした後にサーバーへ反映させます。
これをGitOps（ギットオプス）やCI/CD（継続的インテグレーション／継続的デプロイ）と呼びます。
今回は、自宅のDocker設定をGitHubに集約（資産化）することで、プロと全く同じ「インフラの履歴管理」と「絶対的な再現性」を自宅環境に持ち込みます。
インフラを単なる「動いている箱」から「いつでも再現可能なデジタル資産」へと昇華させるのが、今回の最大の目的です。
2. 自宅サーバー自動化に向けた前提条件・環境構成
作業をスムーズに進めるための前提条件を確認します。前回の設定が完了していれば、すぐにスタートできます。
前提条件
●自宅サーバー（Linux OS / Ubuntu等）が稼働していること
●Docker および Docker Compose がインストールされていること
●連載第0回で作成した、GitHubのプライベートリポジトリ（例：home-ops）が自宅サーバーの /opt/homelab（または任意の作業ディレクトリ）にクローンされていること
3. 【ステップ解説】Docker ComposeをGitHubで管理・資産化する3つの手順
それでは、ステップバイステップで作業を進めていきましょう。
今回は、自宅サーバー運用の定番ツールである「Nginx（エヌジックス：軽量なWebサーバー）」を例に、設定ファイルをコード化していきます。
作業1：自宅サーバー側でDocker Composeファイル（docker-compose.yml）を作成する
まずは、自宅サーバーのローカル環境でGitの管理下に置くためのDocker設定ファイルを作成します。
前回クローンしたリポジトリのディレクトリへ移動して作業を行います。
# 1. 前回の連載で作成したGit管理ディレクトリへ移動します
cd /opt/homelab
# 2. サービスごとにフォルダを分けるのがプロの鉄則。nginx用のフォルダを作ります
mkdir nginx
# 3. nginxフォルダの中に移動します
cd nginx
# 4. Docker Composeの設定ファイルを作成・編集します
nano docker-compose.ymldocker-compose.yml ファイルが開いたら、以下の内容を記述して保存してください。
version: '3.8'
services:
web-server:
image: nginx:latest
container_name: home-nginx
ports:
- "8080:80"
volumes:
- ./html:/usr/share/nginx/html
restart: always初心者向け：コードの1行ずつの意味と理由
version: '3.8'- 意味：Docker Composeのファイルの書き方のルール（フォーマット）のバージョンを指定しています。
- 理由：バージョンによって使える機能や構文が異なるため、最初に明記してDockerに解釈の基準を教えます。
services:- 意味：ここから下に、起動したいコンテナ（サービス）の具体的な中身を書いていくよ、という宣言です。
web-server:- 意味：今回のコンテナにつける、このファイル内での識別名（任意の名前）です。
image: nginx:latest- 意味：インターネット上の公式保管庫から、最新版（
latest）のNginxのイメージ（コンテナのひな形）をダウンロードしてくるという指示です。
- 意味：インターネット上の公式保管庫から、最新版（
container_name: home-nginx- 意味：実際にサーバー上で起動したときのコンテナの名前を
home-nginxに固定します。 - 理由：名前を固定しておくことで、後からログを確認したり停止したりするコマンドが叩きやすくなります。
- 意味：実際にサーバー上で起動したときのコンテナの名前を
ports:/- "8080:80"- 意味：自宅サーバーの「8080番ポート」にアクセスが来たら、コンテナの中の「80番ポート（Nginxの標準）」へ転送するという架け橋（ポートマッピング）の設定です。
volumes:/- ./html:/usr/share/nginx/html- 意味：サーバー上の「今いる場所の
htmlフォルダ」と、コンテナの中の「Webページを格納するフォルダ」を同期（マウント）させる設定です。 - 理由：これをしないと、コンテナを再起動したときに中に保存したホームページのデータがすべて消えてしまうため、データの永続化を行っています。
- 意味：サーバー上の「今いる場所の
restart: always- 意味：自宅サーバーが停電などで再起動した際、このDockerコンテナも自動的に巻き取って起動させる設定です。
- 理由：手動で毎回起動コマンドを叩く手間を減らし、自宅サバの可用性（止まりにくさ）を高めるためのプロの必須設定です。
設定ファイルが書けたら、同期用のフォルダとテストページも作っておきましょう！
# 同期用のhtmlフォルダを作成
mkdir html
# テスト用のWebページを作成
echo "<h1>Welcome to Home DevOps!</h1>" > html/index.html
# Dockerコンテナを起動（-dはバックグラウンド実行のプロの常套句）
docker compose up -dブラウザで http://[自宅サーバーのIPアドレス]:8080 にアクセスし、「Welcome to Home DevOps!」と表示されれば、ローカルでのコンテナ起動は成功です！
作業2：機密情報を守る「.gitignore」の設定と書き方（最重要！）
ここからが、本記事で最もお伝えしたい「プロ仕様のセキュリティ対策」です。
Docker Composeを運用していると、データベースのパスワードや、APIのアクセスキーといった「絶対に他人に知られてはいけない機密情報」を扱うようになります。 これらをそのままGitHubにプッシュ（アップロード）してしまう事故が、世界中の開発現場で後を絶ちません。今回はプライベートリポジトリですが、「機密情報はGitに入れない」を徹底するのがプロの鉄則です。
環境変数やパスワードを切り分けるためのファイル（.env ファイル）などをGitの監視対象から外すため、.gitignore（ギット・イグノア）という特殊な設定ファイルを作ります。
# リポジトリのルート（根本）のディレクトリに移動します
cd /opt/homelab
# .gitignoreファイルを作成・編集します
nano .gitignoreファイルの中に、以下の内容を書き込んで保存してください
# 各種パスワードや環境変数が書かれたファイルは絶対に除外
*.env
.env.*
# OSが自動生成する不要な隠しファイルを除外
.DS_Store
Thumbs.db
# データベースの実データなど、Gitで管理すべきでない大容量データを除外
**/data/
**/db_data/初心者向け：記述の意味と理由
*.envや.env.*- 意味：末尾が
.envで終わるすべてのファイル（例：db.env、.env.local）をGitの追跡対象から完全に無視します。 - 理由：ここにはパスワードやトークンが生データで書かれるため、クラウド（GitHub）へ誤って送信されるのを物理的に防ぎます。
- 意味：末尾が
/data/- 意味：リポジトリ内のどこであっても、
dataという名前のフォルダとその中身をすべて無視します。 - 理由：Gitは「設定（コード）」を管理するツールであり、写真データやデータベースの生データといった「コンテンツ」を管理すると、容量が肥大化して動作が極端に重くなるためです。
- 意味：リポジトリ内のどこであっても、
作業3：GitHubへのプッシュ（Push）とリポジトリでの動作確認
土台が整ったので、作成した docker-compose.yml と .gitignore をGitHubのクラウド上へ送り届け（Push）、安全に「資産化」されたか確認しましょう。
# 1. 現在のGitの状態を確認します（追加されたファイルが赤字で表示されます）
git status
# 2. すべての変更ファイルを、次のコミットの「記録対象（ステージング）」に載せます
git add .
# 3. 何を変更したかのメモ（コミットメッセージ）を添えて、ローカルに記録します
git commit -m "feat: add nginx docker-compose and setup .gitignore"
# 4. クラウド（GitHub）のリポジトリへデータを送信します
git push origin mainプロのワンポイント
コミットメッセージの先頭に feat:（機能追加）や fix:（バグ修正）といったプレフィックス（接頭辞）をつける習慣を意識してみてください。
これはConventional Commitsと呼ばれるプロの共通言語で、後から履歴を振り返る際、誰が見ても一目で変更内容がわかる美しいリポジトリになります。
コマンド実行後、ブラウザで自身のGitHubリポジトリを開いてみてください。 作成した nginx/docker-compose.yml が美しく保管されていれば、インフラの資産化は完璧に成功です！
4. 現役インフラエンジニアの視点：なぜこの設定が「プロ仕様」なのか
今回構築した環境の裏側にある、プロの設計思想を解説します。
「設定」と「データ」の完全な分離
インフラエンジニアが美しい環境を作る際、最もこだわるのが「ステートレス（状態を持たない）」な設計です。
今回、.gitignore を使ってデータベースの実データやWebのコンテンツ（大容量データ）をGitから排除し、docker-compose.yml という「ピュアな設定（設計図）」だけをGitで管理するようにしました。
これにより、GitHub軽量に保たれ、もし自宅サバのハードウェアが全損しても、新しいPCを用意して git clone し、docker compose up -d を叩くだけで、寸分違わぬサーバー構成が即座に組み上がります。
「いつでも捨てられて、いつでも10分で生やせるサーバー」。これこそが、モダンDevOpsの真髄です。
5. 【補足】自宅サーバー自動化でよくあるエラーとトラブルシューティング
ケース1：git pushを実行した際に権限エラー（Permission denied）が出る
エラーメッセージの注目すべき場所： error: failed to push some refs to 'github.com:...' や Permission denied (publickey).
原因とチェックポイント： 前回の連載第1回で設定した「SSH鍵」の認証が、セッション切れや設定ミスで外れている可能性があります。
解決策： 自宅サーバー上で ssh -T git@github.com を実行してください。 Hi [アカウント名]! You've successfully authenticated... と返ってくれば正常です。エラーが出る場合は、前回の記事に戻り、/home/[ユーザー名]/.ssh/id_rsa などの鍵のパーミッションが 600 になっているか、GitHub側に公開鍵（.pub）が正しく登録されているかを再確認してください。
ケース2：.envファイルを作ったのにGitHubにアップロードされてしまう
原因とチェックポイント： .gitignore を作成する前に、一度でもそのファイルを git add してコミットしてしまっている場合、Gitがすでにそのファイルを「追跡対象」として記憶してしまっています。後から .gitignore に書いても無視されません。
解決策： Gitの追跡記憶だけを消去する（ファイル自体は消えません）ために、以下のコマンドを叩いてから、再度コミット＆プッシュしてください。
git rm --cached .env6. まとめと次回予告：次ステップは「GitHub Actions」による自動更新
お疲れ様でした！
連載第1回の今回は、手動で散らばりがちだったDockerの設定をGitHubへ集約し、プロ仕様の .gitignore を使って安全にコード資産化する方法をマスターしました。
これで、あなたの自宅サーバーの設計図は常にクラウド（GitHub）上で安全にバックアップされ、履歴が管理される状態になりました。
しかし、今の状態だと、「ローカルのファイルを書き換える」$\rightarrow$「GitHubにPushする」$\rightarrow$「サーバー側で手動でPullして再起動する」という、人間の手作業（手動運用）がまだ間に挟まっていますよね。
これではまだ「フルオート（DevOps）」とは言えません。
そこで次回（第2回）は、この連載の最大の核となる自動化ロジック「GitHub Actions（ギットハブ・アクションズ）」をいよいよ導入します！
GitHubからの命令を受け取って自宅サーバーを自動でコントロールするための橋渡し役、「Self-hosted Runner（セルフホステッド・ランナー）」の構築ガイドをお届けします。
これが組み上がると、手元のPCからGitHubにコードを1行送るだけで、自宅のサーバーが全自動でアップデートされる「魔法の環境」の心臓部が完成します。お楽しみに！
あなたのホームラボを教えてください！
今回の記事はいかがでしたでしょうか？
「無事にGitHubにDocker Composeを資産化できたよ！」「こんな.gitignoreの設定もおすすめ！」など、あなたの進捗やご意見をぜひコメントやX（旧Twitter）でハッシュタグ #てつログ をつけて教えてください！
インフラ仲間からの熱い報告を楽しみに待っています。
また、今回の連載で構築する「自宅自動化環境」のより高度なエラーハンドリング集や、ワンクリックで環境を爆速構築できる「自動化シェルスクリプトの完成版テンプレート」は、将来的にnoteにて販売も予定しています。
気になる方は今のうちにブログのブックマークとnoteのフォローをお願いします！
それでは、また次回の記事でお会いしましょう！
コメント