installing/working with docker

okay, so yesterday we were trying to get docker set up, and we ran into some nasty stack trace upon opening docker desktop. today when i opened docker desktop, i didn't get the stack trace anymore. HM! so maybe the issue is gone. let's try to figure out how i'm supposed to use Docker. Luckily, there is a get started guide.

Getting Started

"a container is a runnable instance of an image". damn, this is a condensed statement in a few ways:

image referring to the snapshot of the state of a computer system
separates the concept of container and image
multiple containers can originate from the same image
the runnable part confuses me a little, but ok

there is also the concept of "container image," which is funny but makes sense. it's the image of the container (a particular instance of the original image), which will have changed from the original image once the container is instantiated.

Docker has their own definition of image for what it means in the context of Docker: "An image is a read-only template with instructions for creating a Docker container." A "template with instructions" is a nice way of putting it. the image is what allows you to reconstruct a computer state.

Anyway, on to actually building an image and containerizing an application:

I following the instructions on the next page using git bash to handle command line instructions. it works - docker installed a CLI and the docker command is available to me even in Git Bash.

so i created an image, but it's not stored in the same directory as my Dockerfile. so where is it? presumably the storage is being handled by Docker, and it looks like i can run whatever image i want by calling docker run [image tag]

wow, so i run basically that command (with a couple of extra flags), and that's it! i open port 3000 in my browser, and i'm able to see the application. and in the Docker Dashboard, i see that i'm running an instance of the getting-started image that i built earlier!

updating the app

requires me to:

update app code
build a new image that has the new code
ensure that the ports needed by the new image aren't in use (e.g. by deleting running containers using those ports, especially those built on prior versions of the image i just edited)
run the new container

apparently, this is a lot of steps for a small change, and there is a faster method

Question: if i use Docker containers as a part of my CI/CD pipeline, how often will i need to create new images? My guess is:

if the image is for all the dependencies aside from python, very seldom
if the image includes python dependcncies, somewhat moderate (basically only when a package breaks or we use a new one, doesn't happen every day, week, or even month)

we probably need to build the python image from requirements.txt then? which means i should make sure it's clean

ohh. perhaps we build an image which has the correct python version specified in a Dockerfile, and the Dockerfile will install the packages specified in requirements.txt

so there is a level of image-building that relies on Dockerfile, and there is a level of image-building that relies on the repo. seems to make sense to include as much of the dependency-building on the repo-level

now i'm wondering what app we'll be containerizing in our case. is it python? is it something else?

gave docker this command:
docker run -dp 3000:3000 -v todo-db:C:/docker-dbs/todos getting-started

getting this error message when trying to mount a volume to our instance of a docker image:
$ docker run -dp 3000:3000 -v todo-db:C:/docker-dbs/todos getting-started docker: Error response from daemon: invalid mode: /docker-dbs/todos. See 'docker run --help'.

ah looks like changing C: to /c/ works (had the idea since i'm using Git Bash)

oh, turns out i didn't understand the command. the mapping todo-db:/etc/todos will cause all files in /etc/todos to be captured by the database. i'm assuming /etc/todos is a path that the todo-list app is aware of (and to which it writes the list of things to do!). so i should not change that to my own custom folder path.