T-CREATOR

社内開発でDockerを導入する際に考えるべき運用ポイント

社内開発でDockerを導入する際に考えるべき運用ポイント

Dockerの導入は社内開発の効率を大きく改善しますが、単に使い始めるだけでは本質的な効果を得ることはできません。

実際には開発・検証・運用といった各フェーズで、環境管理・セキュリティ・パフォーマンスといった多面的な視点からの検討が求められます。

本記事では、社内でDockerを導入・運用する際に必ず押さえておくべきポイントを、サンプルコードや設定例を交えて詳しく解説いたします。

導入目的の明確化

Dockerは魔法のツールではありません。導入の意義を明確にしないまま使い始めると、逆に運用負荷が増す恐れもあります。

以下のような目的を明文化することが最初のステップとなります。

導入目的具体的なメリット
環境構築の自動化ローカル環境差異の排除、Onboardingの迅速化
CI/CDとの連携テストやビルドの自動化と一貫性の確保
インフラの抽象化複数OS対応やクラウド環境への移行性の向上

開発環境構築のベストプラクティス

Dockerfileの書き方

まず、基本となるDockerfileの構文から確認しておきましょう。

Dockerfile# Node.jsアプリケーション用Dockerfileの例
FROM node:20-alpine

WORKDIR /app

COPY package.json yarn.lock ./
RUN yarn install --frozen-lockfile

COPY . .

CMD ["yarn", "dev"]

解説

  • FROM：ベースとなるイメージを指定します。Alpineを利用するとイメージサイズが小さく高速です。
  • WORKDIR：以降の作業ディレクトリを設定します。
  • COPY：依存関係のインストール前にpackage.jsonだけをコピーすることで、ビルドキャッシュを活かせます。
  • CMD：コンテナ起動時のデフォルトコマンドを指定します。

公式ドキュメント（https://docs.docker.com/engine/reference/builder/）でも命令の詳細が確認できます。

.dockerignoreの活用

Dockerイメージを作る際に不要なファイルを除外するために.dockerignoreを使いましょう。

dockerignorenode_modules
dist
.git
.env

これにより、不要なファイルがコンテナに含まれることを防ぎ、ビルド時間の短縮とセキュリティ向上につながります。

docker-composeによる複数サービスの管理

社内開発では、アプリケーション本体以外にもDBやキャッシュ、外部APIのモックなど複数のサービスが必要になることがよくあります。

その際に便利なのがdocker-composeです。

yaml# docker-compose.yml の例
version: '3.8'
services:
  app:
    build: .
    ports:
      - "3000:3000"
    volumes:
      - .:/app
    environment:
      - NODE_ENV=development

  db:
    image: postgres:15
    environment:
      POSTGRES_USER: dev
      POSTGRES_PASSWORD: password
    ports:
      - "5432:5432"

解説

  • volumesによりホットリロードを実現し、開発効率を上げることが可能です。
  • dbサービスでローカル開発用のPostgreSQL環境を簡単に立ち上げられます。

Composeの仕様は公式ドキュメントに詳細があります。

開発環境の共通化とOnboarding

開発者ごとのローカル環境差異が不具合の原因になることは珍しくありません。そこでDockerによって「誰がどこで開発しても同じ環境」を実現します。

Makefileによる開発コマンドの共通化

Makefileup:
	docker-compose up -d

down:
	docker-compose down

logs:
	docker-compose logs -f --tail=100

このようにすることで、make up だけで誰でも開発環境を立ち上げられるようになります。

READMEへの環境構築手順の明記

以下のような手順をドキュメント化しておくと、初期セットアップの属人化を防げます。

shell$ git clone https://github.com/your-org/sample-project.git
$ cd sample-project
$ make up
→ http://localhost:3000 にアクセス

ボリューム管理とデータ永続化

社内開発でPostgreSQLやMySQLなどを用いる場合、コンテナの再作成によりデータが失われるのを防ぐ必要があります。

yaml  db:
    image: postgres:15
    volumes:
      - db_data:/var/lib/postgresql/data

volumes:
  db_data:

解説

  • 名前付きボリューム（db_data）を使うことで、コンテナのライフサイクルに関係なくデータを保持できます。

より詳しいボリュームの使い方はこちらで確認できます。

セキュリティ対策とイメージ管理のポイント

Docker環境を社内で安全に運用するためには、不要な権限の排除・脆弱性のあるベースイメージの使用回避が欠かせません。

ユーザー権限の制限

Dockerfileではroot以外のユーザーを明示的に作成し、権限を分離します。

DockerfileFROM node:20-alpine

RUN addgroup -S app && adduser -S app -G app
USER app

WORKDIR /app
COPY . .

CMD ["yarn", "start"]

解説

  • adduserにより非rootユーザーを作成し、USER命令で以後のプロセスをそのユーザーで実行します。
  • root権限のままだと、アプリの脆弱性がホストにも波及するリスクがあります。

脆弱性スキャンの導入

CIの中で以下のようなスキャナを実行し、ビルド時にセキュリティチェックを自動化します。

bash$ trivy image my-app:latest

不要なレイヤーやキャッシュの除去

一時ファイルを消し忘れると脆弱性の温床になることもあります。

DockerfileRUN apk add --no-cache git \
 && git clone https://github.com/sample/repo.git \
 && cp -r repo/lib ./lib \
 && rm -rf repo

このように&&でチェーンして不要ファイルを即時削除します。

マルチステージビルドで本番サイズを最小化

開発用と本番用のビルド成果物を切り分けることで、軽量・安全・高速な本番イメージが作れます。

Dockerfile# 開発用ビルド
FROM node:20-alpine as builder
WORKDIR /app
COPY . .
RUN yarn install && yarn build

# 実行用イメージ
FROM node:20-alpine
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/package.json ./
RUN yarn install --production

CMD ["node", "dist/index.js"]

解説

  • builderでのみ開発ツールやライブラリを使い、最終イメージには成果物だけをコピー。
  • --productionで不要な依存を除外。

公式ガイドでも実例が確認できます。

CI/CDとの統合による品質向上

Docker導入の真価はCI/CDとの組み合わせにあります。

GitHub Actionsを例に、以下のようにdocker-compose環境でテストを実行できます。

yaml# .github/workflows/test.yml
name: Run tests

on: [push]

jobs:
  test:
    runs-on: ubuntu-latest

    services:
      postgres:
        image: postgres:15
        env:
          POSTGRES_USER: test
          POSTGRES_PASSWORD: secret
        ports:
          - 5432:5432
        options: --health-cmd pg_isready --health-interval 10s --health-timeout 5s --health-retries 5

    steps:
      - uses: actions/checkout@v3
      - name: Set up Node
        uses: actions/setup-node@v3
        with:
          node-version: 20

      - run: yarn install
      - run: yarn test

このようにCIの中でDBなども含めたE2Eテストが簡単に再現可能になります。

GitHub Actionsの公式ドキュメントはこちら。

イメージの社内配布とレジストリ運用

社内ネットワーク内でイメージの共有や更新を行うためには、プライベートレジストリの運用が現実的です。

自前のDocker Registryを立てる

bashdocker run -d -p 5000:5000 --restart=always --name registry registry:2

その上で以下のようにタグを付けてpushできます。

bashdocker tag my-app localhost:5000/my-app
docker push localhost:5000/my-app

より大規模には、HarborやAWS ECRなどの利用も検討可能です。

Docker Desktop導入時のライセンス確認

2021年以降、Docker Desktopには商用利用時のライセンス制限があります。

中規模以上の組織で使用する場合は以下のリンクからDocker Subscription Service Agreementを確認の上、ProやTeamプランの導入を検討ください。

監視・ログの取り扱いとトラブルシュート

コンテナログの収集方法

標準出力に出るログは次のように確認できます。

bashdocker logs app_container

また、ログ基盤との連携にはfluentdやlogspoutが用いられます。

実行中のコンテナの確認と操作

bashdocker ps              # 稼働中のコンテナ一覧
docker stats           # リソース使用状況
docker exec -it [id] sh # コンテナへ入って調査

本番環境での監視はPrometheus + Grafanaの組み合わせなどが代表的です。

まとめ

Dockerを社内開発に導入することは、開発効率や環境整備の観点で非常に有効です。しかし、単なるツール導入にとどまらず、「継続的かつ安全な運用」を見据えた設計と実践が求められます。

本記事では、前半と後半に分けて、以下のような視点で具体的なポイントを掘り下げてきました。

導入・開発フェーズでの要点

トピック内容
目的の明文化導入目的を明確にし、方向性のブレを防止
Dockerfile設計キャッシュ効率やセキュリティを意識した記述
.dockerignore不要ファイルの除外でビルド最適化
docker-compose運用複数サービスを一元管理し、開発の統一性を確保
MakefileやREADME活用Onboardingの簡素化と属人化の排除
データ永続化名前付きボリュームの利用でDBデータの保全

運用・セキュリティ・自動化フェーズでの要点

トピック内容
非rootユーザー実行コンテナ内からの侵害リスクを軽減
脆弱性スキャンTrivy等のツールでCI内セキュリティチェックを自動化
マルチステージビルド最小構成のイメージにより軽量・高速・安全を両立
GitHub Actions連携docker-composeと合わせてCI/CDパイプラインを構築
プライベートレジストリ社内でのDockerイメージ共有とバージョン管理を安全に
ライセンス確認Docker Desktopの使用に伴う契約と制限の理解
ログ・監視docker logsやPrometheus連携で可視化とトラブル対応

実践的な開発運用の指針

  • 属人化の排除と手順の共通化：MakefileやREADMEを通じて、誰が触っても同じ動作環境を保証
  • セキュアなコンテナ設計：非root実行、不要ファイル除去、スキャン導入が鍵
  • スケーラブルな体制構築：CI/CD、自前レジストリによる自動化・展開の基盤づくり

Dockerは「環境を揃えるツール」であると同時に、「運用文化を整えるきっかけ」でもあります。

この機会に、開発環境だけでなくチーム全体の開発体験と品質を見直す足掛かりとして、Dockerの導入・運用を戦略的に進めてみてはいかがでしょうか。

Dockerの記事Docker

記事Article

もっと見る