请问这是必须的么,如果是这样的话,是要用docker compose-up 自动简化这个过程?
如果不是必须的话,因为我的dockerfile的问题么?
dockerfile如下:
FROM ubuntu
MAINTAINER Tarty.Phoenix <tartyphoenix@gmail.com>
RUN apt-get update
RUN apt-get install -y -q python-all python-pip libffi-dev
RUN apt-get install -y -q python-dev build-essential
ADD ./flask_pure/requirements.txt /tmp/requirements.txt
RUN pip install -qr /tmp/requirements.txt
ADD ./flask_pure /opt/flask_pure/
WORKDIR /opt/flask_pure
EXPOSE 80
CMD ["python", "manage.py", "runserver"]
まず、workdirで表されるディレクトリは、ホストではなくコンテナ内のディレクトリです。
次のコンテンツの変更にはイメージの再構築が必要です
Dockerfile自体が変更されます
COPY / ADD命令のためのソースファイルの変更
docker-compose は操作中のイメージの再構築をサポートします
リーリーあなたの質問の中で説明しなければならない点が 1 つあります。
dockerfileを作成・編集した後、buildでイメージ(ミラー)を作成し、イメージを実行してコンテナ(コンテナ)を生成すると、イメージとコンテナは1対1に対応します。その後、dockerfile を編集して workdir を変更すると、作成したコンテナーは当然デフォルトで新しい workdir に入ります。したがって、質問のタイトルは質問を説明するものではなく、正しい論理的な説明をする必要があります。
docker についてのあなたの理解は間違っています。あなたがやっているのは、特定のフォルダーの内容をイメージにパッケージ化するだけです。
docker の VOLUME ボリュームの概念を理解することをお勧めします。コンテナーの起動時に -v パラメーターを指定するか、docker-compose.yml で VOLUME パラメーターを指定することによってのみ、コンテナーはローカル ディレクトリをマウントできます。
それでは、コンテナをローカルディレクトリにマウントする必要があるかどうかを区別するにはどうすればよいでしょうか? 私の理解では、コンテナが開発ステータスであるか運用ステータスであるかということです。
開発段階にあり、コードを頻繁に変更する必要がある場合、コードが変更されるたびにイメージに再パッケージ化する必要があることを受け入れるのは困難です。
実稼働環境を使用している場合、Docker Hub が多数のイメージを提供していることを想像してください。これらのイメージがインストール環境とソース コードを提供する場合は、ボリュームを手動で指定してソース コード ディレクトリをマウントし、コンテナーを起動する必要があります。これをコンパイルしてインストールします。この経験についてどう思いますか?