[Notes:Docker] #notes #docker
The fundamental difference between ADD and the Voluem is ADD makes whatever you're adding,be it a folder or just a file are actually part of your image.
Anyone who uses the image you've built afterwards will have access to those folders and files.
If you remove those files and folders afterwards, It will still presist because Docker works in layers and the ADD layer will still exist as part of the image.
To be clear, you only ADD something at build time and cannot ever ADD at run-time.
You have some requirements in a file requirements.txt
.
you want to reference and install in your Dockerfile.
You can then do
ADD ./requirements.txt /requirements.txt
RUN pip install -r /requirements.txt
Another story is,
You can copy your project into the docker machine by adding it to the Dockerfile.
for this, you can do
# copies your current working directory into docker machine path /usr/local/git/my_app
ADD ./ /usr/local/git/my_app
# set that directory as your current working directory inside the docker machine
WORKDIR /usr/local/git/my_app
# default command to run while creating the container
CMD python ./main.py
Volume allows a container run which from your image to have access to some file and folders on your local machine.
You cannot use those files from your VOLUME directory in your Dockerfile.
Anything in your VOLUME directory will not be accessible at build-time but will be accessible at run-time.
A few examples of cases where you'd want to use VOLUME:
The app being run in your container makes logs in /var/log/my_app.
You want those logs to be accessible on the host machine and not to be deleted when the container is removed.
You can do this by creating a mount point at /var/log/my_app by adding VOLUME /var/log/my_app to your Dockerfile and then running your container with docker run -v /host/log/dir/my_app:/var/log/my_app some_repo/some_image:some_tag
You have some local settings files you want the app in the container to have access to.
Perhaps those settings files are different on your local machine vs dev vs production.
Especially so if those settings files are secret, in which case you definitely do not want them in your image.
A good strategy in that case is to add VOLUME /etc/settings/my_app_settings to your Dockerfile, run your container with docker run -v /host/settings/dir:/etc/settings/my_app_settings some_repo/some_image:some_tag, and make sure the /host/settings/dir exists in all environments you expect your app to be run.
copies a file into the image but supports tar and remote url
copy the files into the image, preferred over ADD
creates a mount point as defined when the container run
the executable runs when a conatiner is to run.
- documents the ports that should be published
- provides argument for the entrypoint
- only one CMD is allowed.
- used to define the environmental variables
- defines the base image from which the docker image was build
- it must be the first instruction in the Docker file
- only used as a trigger when this image is used to build other images
- will define commands to run "on build"
- runs a new command in a new layer
- defines the working directory of the container