最近業務でDockerをさわる機会が多いので、何回かに分けて基本的な考え方をまとめておこうと思います。
初回として、Dockerに対する考え方には２種類あるぞ、という話をまとめます。
実際のDockerの使い方は出てきません。
第２回は、こちらです。
※ 本記事は、2022/02/22に弊社スタッフブログに投稿した記事をQiitaに転載しています。
TL;DR
- Dockerでの処理には2通りの考え方がある
- 仮想マシンおよび仮想ネットワークとしてのDocker
- 特定の処理を動作させるための安定環境としてのDocker
承前
Dockerの使用方法はググるとたくさんでてきます。
ネット上の記事を見れば、Dockerを使用して何かを動かすことはできるようになります。
しかし、実際に業務で使用するとなると
-
どの部分をDockerで仮想化すべきか
-
DockerとDocker Composeの使い分けはどのようにすべきか
等で迷うことが多いと思います。
もちろん、唯一の正解があるわけでなく、それぞれの状況に応じた設計をする必要があるのですが、とっかかりとしてDockerに対して、下記２つの考え方を持っていると切り分けがしやすいと感じます。 -
仮想マシンおよび仮想ネットワークとしてのDocker
-
特定の処理を動作させるための安定環境としてのDocker
仮想マシンおよび仮想ネットワークとしてのDocker
一般にDockerでググると出てくるのは、こちらの考え方に沿った情報だと思います。
Docker Composeを使用すると複数のコンテナを仮想ネットワーク上で協働させることができるため、例えばひとつのWebサービスを
- Webサーバ
- アプリケーションサーバ
- データベースサーバ
の3つのコンテナを使用して実現したりします。
考え方は従来のシステム設計と同一で、各コンテナを仮想的な一台のサーバとみなし、必要なOSやパッケージをインストールして起動します。
nginxやMySql等標準的なアプリケーションの場合、立ち上げるだけで動作するコンテナが公式に公開されていますので、Docker Composeに組み込むだけで仮想システムを構築することができます。
特定の処理を動作させるための安定環境としてのDocker
もうひとつの考え方は、特定の処理を安定動作させるための環境としてDockerを使用する、というものです。
Docker単体で動作させる場合、こちらの考え方が根底にあるように思います。
古来から、ある処理を安定して動作させるのは大きな課題でした。
- OSのバージョンが合わない
- 必要なパッケージがインストールされていない
等の理由で、ある環境で動作した処理が別の環境では動作しない、という事はよくあります。
DockerはOSごと仮想化しますので、上記のような環境齟齬が発生しなくなります。
例えば、定期的な処理についてcronからDockerコンテナ上でコマンドを実行するような使い方の場合、こちらの考え方になると思います。
AWS Lambdaとかを使用していると、違和感のない考え方かと思います。
設計する時に考えること
最終的に欲しいものが
- アプリケーションとしての動作
- コマンドの実行結果
のどちらなのかを意識する、という、すごく当たり前の話でした。