はじめに システムやアプリの開発をする際、Github上にリポジトリを作ってそこでソース管理することが多いが、実行環境がこれらのソースを直接的に見ていなかったり、開発環境はローカルで立てたりするため、手元では動いたが本番環境にアップロードすると失敗といった事が頻繁に起こっていた。 今回、ソースコードをGithub上に置き、そのソースコードを参照する様なWebサーバーコンテナができないかを試してみたので、本記事ではその内容をまとめる。 実行環境 【Docker導入環境】 ・Ubuntu20.04 LTS（GCP上） ・docker19.03.13 【コンテナ環境】 ・Image Ubuntu:20.04 ・Apache2.4.41 試してみる事 docker上に2つのWebサーバー用コンテナを作成して、1つを本番用、もう1つを開発用とする。 本番用のコンテナはビルドする度に、Githubリポ

本番環境用のdocker-compose 従来、コンテナの作成は開発環境でのみ行われることが多かったが、これを本番環境でも利用することで、開発環境と同一の環境での運用を可能とし、サービスの冗長性を高め、環境の違いによる不具合を軽減する事例が増えているそうだ。 コンテナを構築するための情報が記載されているファイルがdocker-compose.ymlである。そしてこのファイルは、本番環境と開発環境で使い分けが可能である。 今回実施する内容は、使い分けというよりは、本番環境用にファイルの内容を上書きするという言い方が正しいかも知れない。具体的にはdocker-compose.ymlとは別に、docker-compose-prod.ymlという名称のファイルを作成し、コンテナの構築時に以下のように-fオプションで参照するdocker-composeファイルを指定する方法である。

今回はある案件でのDocker使用事例を簡単に紹介しようと思います。 問題点 Webシステムのテスト環境、本番環境が同一のマシンに存在していた。 ディレクトリ、Webパス、DB名等をテスト用、本番用に用意し切り分けて使用していた為、 次の様な問題が起こった。 ・テスト環境用のディレクトリにリソース配備する際、誤って本番環境のディレクトリに配備。 ・設定ファイルの記述ミスで本番環境のDBにアクセス。 ・Webサーバ、DBサーバの再起動などが必要な場合、両方の環境に影響を与えてしまう。 サーバの環境イメージ 1つのWebサーバに2つのWebシステム、1つのDBサーバに2つのDBを作成し運用しています。 Webシステムへの接続はパスをそれぞれ分けて設定しています。 解決策 本番用環境、テスト用環境をDockerイメージとして定義し、それぞれ独立した環境を作る事により、 本番環境、テスト環境とも相