質問: ##### 1、「centOSのimageをpullしてきて使う」とはどういう状態なのか? virtualboxなどの場合、仮想環境に実際にゲストOSとしてcentOSをインストールしその上に構築していくのでやっていることが分かるのですが、dockerの場合OSはホストOSを利用するのでcentOSのimageを引っ張ってきてもcentOSを使用しているわけではないですよね? あくまで「centOSの環境っぽくしてる」というように調べてみて感じたのですが、そうなるとcentOSのimageを使って開発するメリットってあるのでしょうか? osの部分は無視してアプリケーションサーバーや言語のインストールだけした方が良いのではと感じてしまいます。 ##### 2、本番環境へのデプロイについて 私が今理解している知識から考えると、デプロイの方法については ・本番環境でもdockerをインストール、開発していたimageをそのまま利用するだけで完了 ・本番環境ではdockerはインストールせず、開発に使った言語に合わせた環境構築を行う。プロジェクトだけをGitからpullしてきて完了 の2つがあるのかなと思っています。 そしてそのうえで後者の方法を取りたいのですが、何か問題やdockerを使用する事の意義が失われるなどはありますでしょうか? あくまで、「余計なものがインストールされていないまっさらな環境で開発を行いたい」からdockerを使用する、という使い方を考えています。(virtualboxなどは重いため) dockerコンテナをそのまま使ったデプロイについてのメリットやデメリットといった記事はたくさん出てくるのですが、そもそもどんなデプロイ方法があるかといった記事がなかなか見つからなかったので質問をしました。 よろしくお願いします。
回答: 1、「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` 以外のイメージを使うと構築が楽です 2、本番環境へのデプロイについて > > - 本番環境でもdockerをインストール、開発していたimageをそのまま利用するだけで完了 > > - 本番環境ではdockerはインストールせず、開発に使った言語に合わせた環境構築を行う。 > > プロジェクトだけをGitからpullしてきて完了 > > > 後者の方法を取りたいのですが、 > > 何か問題やdockerを使用する事の意義が失われるなどはありますでしょうか? > > > ひとまず後者でも良いかもしれませんが、 そのうち前者、というか Docker でデプロイ可能なマネージドサービスを使いたくなると思います 開発が順調に進めば、本番環境を楽に何度も更新したくなるからです 前者であれば、本番環境を更新するときは、開発環境を更新するだけでなく 本番環境も構築し直す必要がありますが、 Docker でデプロイ可能なマネージドサービスであれば 本番環境でもイメージが流用でき、環境ごとに構築し直す必要がありません ただし、イメージの設計を次のように変える必要があります: * 開発環境に依存する内容を取り除きます * イメージからコンテナを実行するときに与える環境変数で アプリケーションの振る舞いを各環境に適応させられるようにします > > そもそもどんなデプロイ方法があるかといった記事がなかなか見つからなかったので質問をしました。 > > > 本番環境は Docker でデプロイ可能なマネージドサービスを使うと楽です ほんの一部ですが、例えば、以下のようなものがあります: * Heroku * AWS Fargate * AWS Elastic Beanstalk * GCP Cloud Run * 他 具体的なデプロイ方法はそれぞれのサービスの公式ドキュメントを参照します