Docker basics

Docker.txt

Dockerfile Best Practice:

* Keep no. RUN directoves to a minimum:
	- Reduces filesize of generated image
	- Ensures that changes to the command, regenerates the image properly (viz Dockerfile caching)
	- Each command creates a new layer which is itself a separate image
* Security:
	- Each service should have a dedicated user+group to use, to minimuse "leakage" from hacks in one service into other services
	- Check snyk.io for additional security best-practices
* Images share commonalities, so makes sense ot use the same Base OS as the O/S' required by services themselves
* Avoid "ADD" use "COPY" instead. "ADD" has some overhead over "COPY"
* Use CMD with exec style commands (JSON arrays) vs straight out "exec" (Shell calls) commands.
	- One advantage is that the same PID used to run the container is NOT the one used to run initial/any of the container's commands
* Use mounted volumes where required for caching, temporary app-specific files and DB data
	- Use e.f. NFS or Cloud API's from the app itself
	- Volumes can be named and declared as an independent block within docker-compose.yml, then referenced by >=1 service that uses it (e.g same volumn for app config required by a frontend and a backend app)
* Use environment variables for app config, don't commit docker-compose-override.yml or .env files (of course)
* One process (container) per service aka separate Dockerfiles ergo "apps" ergo "services" per container (which is named a "service")
	
Deployment:

* Done through CI/CD where images are genered and pushed to a private registry and then pulled down as the final CD step

Docker Compose	

* Use docker-compose.yml
	- Can be extended (Usually in dev-envs only), with a docker-compose-override.yml file

General:

* Containers are comprised of "layers" where each "layer" is itself an "image"
* Containers share what they can, of other layers e.g. libs from the Base O/S
* Compared to VMs, utlise far less RAM and CPU than is required to bootstrap a VM making containers far faster in comparison
* Using ENTRYPOINT in Dockerfile to _always_ call that command. Subsequent commands should call RUN (or CMD, but ENTRYPOINT provides a command "context" so the next time a comand is run as CMD, Docker will attempt to append the value given to CMD as an argument to the command given in ENTRYPOINT --> this may or may not be what was intended

Commands:

	# Interactive shell into a container created from a Dockerfile which is located in the current dir:
	$> docker run -it /bin/sh
	
	$ Ditto, but the container has already been built and tagged as e.g. "foo/bar":
	$> docker run -it foo/bar /bin/sh