Docker を利用する場面について

自分は、Docker を利用する場面について、下記のように分類して考えています。

• 学習環境の構築
• 開発環境の構築
  • Docker 上
  • ローカルマシン上
• ステージング環境の構築
  • ローカルマシン上
  • サーバーマシンやクラウドサービス上
• 運用環境の構築
  • Docker がインストールされたサーバマシン上
  • Docker 対応のクラウドサービス

Docker を学ぶ場合は、学習環境の構築に利用することから始めるのが良いです。
学習環境はスクラップ＆ビルドしやすいので、ちょっと変な設定をしてしまったり、おかしな挙動があっても、学習に支障がない範囲なら大丈夫です。
そのため、利用にあたってのハードルが非常に低いです。

開発環境を構築する場合は、開発環境に必要なソフトウェアを Docker で動かしてみるのが良いです。
つまり、開発環境に必要なソフトウェアの学習環境を Docker で用意します。
使い方がわかったら、Docker で用意した学習環境をベースにして、開発環境を構築します。

開発環境をどこに構築するかについては、Docker 上に構築する場合とローカルマシン上に構築する場合とがあります。

最近は、Docker 上に開発環境を構築することが流行しつつあります。
簡単な開発環境なら、Docker 上に開発に必要な環境すべてを構築することが十分可能です。
複雑な環境を構築するのは、Docker についてそれなりの理解が必要となり、少しハードルが高いです

普通は、開発環境をローカルマシン上に構築することが多いです。
この場合は、開発に必要なエディタやツールはローカルマシン上に用意します。
Web アプリのように、実行時に必要なサーバーソフトウェアがある場合に、それらを Docker で用意して開発ができるようにします。
Docker がなかった頃は、ローカルマシンの OS に対応するサーバーソフトウェアをインストールするか、ローカルマシンとは別のマシンに Linux と必要なサーバーソフトウェアをインストールして環境を用意していました。

開発環境については、どの程度の環境を構築するのかにもよりますが、Linux に使い慣れている場合は Docker 上に開発に必要な環境すべてを構築したくなる気持ちが強くなるでしょう。そうでない場合は、普段使い慣れているローカルマシン上に構築したくなるでしょう。

ステージング環境を構築する場合は、開発環境構築で用意した Docker 関連ファイルをベースにして作成することになります。ここで、ソフトウェアを開発しやすい環境として用意するのではなく、ソフトウェアを実行しやすい環境として用意するように、意識を切り替える必要があります。

また、構築するときに使うマシンについても意識する必要があります。基本的にローカルマシン上に用意する場合とサーバーマシンやクラウド環境に用意する場合とに分かれます。

ステージング環境構築は開発担当がするのか、運用担当がするのかは意見が分かれるかもしれませんが、最近は DevOps といった用語が出てきたこともあって、開発担当が対応することが増えているようです。
開発しているソフトウェアを実際に運用環境で利用できるようにするには、運用環境で使用するサーバーソフトウェアの指定や、その設定についての説明が必要です。
ステージング環境へ開発担当が運用担当向けにリファレンス実装を用意すると考えるとわかりやすいでしょう。
Docker を使うと、開発者がローカルマシンでステージング環境を用意できるようになります。
それで環境構築に必要な Docker 関連のファイルを使って、運用担当がサーバーマシンやクラウド環境に用意するといった分担もできます。

運用環境を構築する場合は、ステージング環境構築で用意した Docker 関連ファイルをベースにして作成することになります。

運用担当が用意した Docker が動作するサーバーマシン上で運用できる Docker 関連のファイルを用意することになるので、運用について深い経験が必要です。
また、OS や Docker についても深い知識が必要となります。
このあたりは Docker を使い慣れて、自宅の LAN 環境でのサーバーマシンで実際に動かす経験をしてから、できるようになれば良いと考えています。

Docker が使えるクラウドサービスを使って運用環境を用意する場合は、Docker が動作するサーバーマシンを使うよりも作業のハードルは低くなりますが、Docker についての深い知識が必要であることは変わりません。
使用するクラウドサービスについても、理解が必要となります。
クラウドサービスを使うと利用した分だけの費用で済みますが、インターネット上のWeb サービスのように誰でもアクセスができる環境でソフトウェアを動作させる場合は、どれくらい利用するのかの見積もりが難しくなります。
使用するコンピュータのリソースを正しく制限しつつ、セキュリティ対策もしつつ利用できるスキルが必要になります。

ここでは、Docker を利用する場面について、自分がどのように分類して考えているかを説明しました。重要な点は、Docker 関連のファイルを用意する時は、学習環境構築、開発環境構築、ステージング環境構築、運用環境構築という順番で、利用する場面に応じてアップデートしていくということです。

それぞれの環境構築で使う Docker 関連のファイルはライフタイムが全然違いますが、一般的には「学習環境構築用 < 開発環境構築用 < ステージング環境構築用 < 運用環境構築用」となります。
使用目的も違うので、Docker 関連のファイルで指定したくなる設定も変わってきます。
ただし、学習環境構築用を除けば、開発しているソフトウェアを動作させるために必要な設定については、基本部分は共通になります。
こういったことを意識して、Docker を使うようにすると、Docker 関連のファイルをうまく整理できるようになると考えています。

ステージング環境について

ステージング環境は、開発したソフトウェアが実際に運用環境で動作するかを確認するには、それを検証するための環境が必要です。
この検証するための環境をステージング環境といいます。
開発のための環境は、ローカルマシンで開発しやすくするためのものですが、ステージング環境は運用環境で問題が起きないように動作確認をするためのものです。
そのため、基本的に設定は運用環境にできるだけ近いものにして、開発環境向けの設定とは別のものになることが多いです。

この環境を構築するためのインフラまわりは運用チームが用意しますが、実際に開発したソフトウェアが動作するような環境を構築するのは、一般的には開発チームが担当します。
マシンの用意から OS とサーバーソフトウェアのインストールまでは運用チームが担当します。
運用チームが用意した環境上へ開発したソフトウェアをインストールするのは開発チームが担当することが多いです。

ステージング環境では、インストール作業に限らず、アップデート作業といった、デプロイ作業について、開発チームが深く関与した方が、問題が起きにくくなります。
これは、開発チームの方が、現在開発しているソフトウェアが動作する環境について、正確に把握しているからです。

デプロイ手順の作成は開発チームが担当して、デプロイ作業は運用チームが担当するといった役割分担の方法もありますが、実際にデプロイ作業をしてみないとわからない事も多いので、ステージング環境では開発チームが担当した方が良い場合が多いです。

最近はデプロイ作業も自動化ができるようになってきているので、開発チームがステージング環境へのデプロイを自動化することも増えてきています。
ステージング環境でのデプロイ作業で開発チームが得たノウハウから、開発しているソフトウェアの安全なデプロイ手順が決まってきます。

それをベースにして、運用チームは運用環境でのデプロイ手順を検討します。
ステージング環境ヘは自動デプロイをしますが、運用環境へのデプロイは手動とする現場も多く有ります。
これは、障害時への対応のため運用チームが待機しながら行うことも多いためです。
デプロイ自体は自動化しても、デプロイの進行状況をしっかり監視できる運用チームが待機している状態で、デプロイの実行開始ボタンをクリックするようにします。
こうすることで、デプロイ時の問題に対処しやすくしているのです。