dockerを用いた開発、デプロイについての疑問

Question

Dockerについて理解している事

・コンテナ内にOS無く、ホストOSのカーネルを利用している
・imageをpullしてくることで、複雑な環境構築をしなくても開発ができる
・コンテナを本番環境へデプロイすることもできる？（話を聞いただけで未調査です）

浮かび上がった疑問点

#####１、「centOSのimageをpullしてきて使う」とはどういう状態なのか？
virtualboxなどの場合、仮想環境に実際にゲストOSとしてcentOSをインストールしその上に構築していくのでやっていることが分かるのですが、dockerの場合OSはホストOSを利用するのでcentOSのimageを引っ張ってきてもcentOSを使用しているわけではないですよね？
あくまで「centOSの環境っぽくしてる」というように調べてみて感じたのですが、そうなるとcentOSのimageを使って開発するメリットってあるのでしょうか？
osの部分は無視してアプリケーションサーバーや言語のインストールだけした方が良いのではと感じてしまいます。

２、本番環境へのデプロイについて

私が今理解している知識から考えると、デプロイの方法については
・本番環境でもdockerをインストール、開発していたimageをそのまま利用するだけで完了
・本番環境ではdockerはインストールせず、開発に使った言語に合わせた環境構築を行う。プロジェクトだけをGitからpullしてきて完了
の２つがあるのかなと思っています。
そしてそのうえで後者の方法を取りたいのですが、何か問題やdockerを使用する事の意義が失われるなどはありますでしょうか？

あくまで、「余計なものがインストールされていないまっさらな環境で開発を行いたい」からdockerを使用する、という使い方を考えています。（virtualboxなどは重いため）

dockerコンテナをそのまま使ったデプロイについてのメリットやデメリットといった記事はたくさん出てくるのですが、そもそもどんなデプロイ方法があるかといった記事がなかなか見つからなかったので質問をしました。
よろしくお願いします。

Answer 1

質問の１つめのほうだけ回答します。

dockerの場合OSはホストOSを利用するのでcentOSのimageを引っ張ってきてもcentOSを使用しているわけではないですよね？

「dockerの場合OSはホストOSを利用する」の「ホストOS」はディストリビューションの内のカーネルと呼ばれる部分を指していると思います。
ディストリビューションで提供されるのはカーネル以外にもユーザランドと呼ばれるコマンド群があり、ユーザランドはコンテナに入っているものを使用するという状態になります。
言い換えると、dockerコンテナはホストOSのカーネルとdockerコンテナ内のユーザランドの組み合わせで動作することになります。
これが「「centOSのimageをpullしてきて使う」とはどういう状態なのか？」の回答になるかと思います。

ディストリビューションを特徴づけるものはカーネルよりもユーザランドによるものが大きく、ユーザランドのコマンド群(管理コマンドやパッケージ管理システムやインストール可能なパッケージなど)がCentOSのものであれば、ホストOSがCentOSを使用している場合と比較して使用感はほぼ同じであるはずで、それは(dockerコンテナ内で)「CentOSを使用している」と言えるのではないでしょうか？

osの部分は無視してアプリケーションサーバーや言語のインストールだけした方が良いのではと感じてしまいます。

認識違いがあるかもしれないので念のために書きます。(以下、認識が合っているのならすみません。)
ホストOSのパッケージ管理システムがなんであるかは関係なく、CentOSコンテナ内ではユーザランドのパッケージ管理システムはyumであり、コンテナ内では基本的にコンテナ内に用意されているyumを使用してアプリケーション等をインストールすることになります。

Answer 2

１、「centOSのimageをpullしてきて使う」とはどういう状態なのか？

Docker を使っているとはいえ、OS の違いを無視できない状況も、ないわけではありません

Docker は、
現在では Alpine という OS をベースにしたイメージを使うことが推奨されています

参考: Best practices for writing Dockerfiles | Docker Documentation

We recommend the Alpine image as it is tightly controlled and small in size (currently under 5 MB), while still being a full Linux distribution.

とはいえ、例えば、CentOS と Alpine では次のような違いがあります:

項目|CentOS|Alpine
---|---
シェル|Bash|Ash
パッケージマネージャー|yum/dnf|apk

Alpine 以外の OS を使う例

非 Docker から移行するとき

今までの非 Docker 環境からの移行であれば、
シェルやパッケージマネージャーの違いが原因で
構築手順を一度に Alpine 用に改めることは難しいかもしれません

そのような場合は Alpine 以外のイメージを使うと移行がある程度しやすくなるかもしれません

本番環境が OS の違いに依存している場合

本番環境は Alpine でないOSのまま変えられない状況で
本番環境で実行する処理が、たとえば Bash であったり、
apk ではインストールできないパッケージに依存している場合は、
開発環境として Alpine 以外のイメージを使うと構築が楽です

２、本番環境へのデプロイについて

• 本番環境でもdockerをインストール、開発していたimageをそのまま利用するだけで完了
• 本番環境ではdockerはインストールせず、開発に使った言語に合わせた環境構築を行う。
  プロジェクトだけをGitからpullしてきて完了

後者の方法を取りたいのですが、
何か問題やdockerを使用する事の意義が失われるなどはありますでしょうか？

ひとまず後者でも良いかもしれませんが、
そのうち前者、というか Docker でデプロイ可能なマネージドサービスを使いたくなると思います

開発が順調に進めば、本番環境を楽に何度も更新したくなるからです
前者であれば、本番環境を更新するときは、開発環境を更新するだけでなく
本番環境も構築し直す必要がありますが、
Docker でデプロイ可能なマネージドサービスであれば
本番環境でもイメージが流用でき、環境ごとに構築し直す必要がありません

ただし、イメージの設計を次のように変える必要があります:

• 開発環境に依存する内容を取り除きます
• イメージからコンテナを実行するときに与える環境変数で
  アプリケーションの振る舞いを各環境に適応させられるようにします

そもそもどんなデプロイ方法があるかといった記事がなかなか見つからなかったので質問をしました。

本番環境は
Docker でデプロイ可能なマネージドサービスを使うと楽です
ほんの一部ですが、例えば、以下のようなものがあります:

• Heroku
• AWS Fargate
• AWS Elastic Beanstalk
• GCP Cloud Run
• 他

具体的なデプロイ方法はそれぞれのサービスの公式ドキュメントを参照します