Docker
Docker
Docker creates and runs containers, which are sand-boxed processes, isolated from all other processes, with their own allocated cpu/memory/etc.
Docker Sub Parts
Core Parts:
- Image - A definition of docker logic, which can be spun up and run as a container.
- Due to how docker works, any number of containers can be build from this image, and it will run on any OS that supports docker.
- Container - A unique, running instance of a docker image.
- Multiple containers can be created from a single image.
- Volume - An location for docker to persist data to long-term.
- Allows data to last even as a container is started, stopped, and restarted.
- Also allows multiple containers to share a set of data, so long as the data is put into the volume.
Setup:
- docker-compose.yml - A file that defines the docker service to run.
- Dockerfile - A file that defines the actual commands the docker instance should execute once it is created, in order to setup the intended container service.
These two files should be put into the same directory. Then cd
into the directory and build it with docker-compose run
.
Finally, start the service with docker-compose up -build -d
.
Docker Commands
Commands to Launch Containers
Launch a built image as a new container instance:
docker run -dp <ports_to_map> <optional_mount_command> <image_name>
Where:
ports_to_map
corresponds to theHOST:PORT:PORT
values to map the container ports to the host.- Ex: A value of
127.0.0.1:3000:3000
would map port 3000 on localhost to port 3000 on the container.
- Ex: A value of
optional_mount_command
- Optional. See below for mount command explanations.image_name
- Corresponds to the name of the image you wish to create a container of.
Example:
docker run -dp 127.0.0.1:3000:3000 my-cool-image
Command Mount Subsection
To persist data long term, we need to add some form of mount subcommand.
Volume Mount:
- Volume Mount - Allows persisting data for docker instances.
- Follows the format
--mount type=volume,src=<volume_name>,target=<filepath_in_container>
.- Where:
volume_name
- Corresponds to the name of the already-created docker volume to mount.filepath_in_container
- Corresponds to the filepath the volume should mount to, within the container. Ex:/etc/my_volume
.
- Where:
- Follows the format
Example:
docker run -dp 127.0.0.1:3000:3000 --mount type=volume,src=my-volume,target=/etc/my_volume my-cool-image
Bind Mount:
- Bind Mount - Allows sharing data between host machine and container, via linking filepaths (similar to a symlink).
- Follows the format
--mount type=bind,src=<filepath_on_host>,target=<filepath_in_container>
.- Where:
filepath_on_host
- Corresponds to a folder located on HOST machine, to share with container.filepath_in_container
- Corresponds to the filepath the volume should mount to, within the container. Ex:/etc/my_volume
.
- Where:
- Follows the format
Example:
docker run -dp 127.0.0.1:3000:3000 --mount type=bind,src=/srv/my_project/share_folder,target=/etc/my_volume my-cool-image
General Commands
List all docker containers:
docker ps
Access a given running container:
docker exec <container_id>
Where container_id
is the id of the container you wish to access.
Build docker image from the Dockerfile
in current directory:
docker build -t <image_name>
Where image_name
is the name you wish to give the image.
Stop running docker container:
docker stop <container_id>
Where container_id
is the id of the container you wish to stop.
Remove existing docker container:
docker rm <container_id>
OR combine the above two commands with:
docker rm -f <container_id>
Where container_id
is the id of the container you wish to stop.
Create a new volume to allow persisting data long-term:
docker volume create <volume_name>
Where volume_name
is the name the volume should use.
Kubernetes
Kubernetes is a an architecture that runs and manages docker-like containers for applications.
Kubernetes Sub Parts
- Control Plane - Where decisions are made.
- Generally has 3 of these running, to ensure availability.
- Worker Node - A location where something might be running.
- Can have any number of these, as needed.
- Parts:
- Kubletes - Manages one or more PODS, each POD being a group of docker-style containers.
- Kube Proxy - Ensures communication is fluid between all parts.
- Controller - Helps control all other aspects, to ensure it does what it's meant to.
- External Resources - Various outside resources that the Control Plane and Worker Nodes do work with.
- Ex: Storage, load balancers, etc.
- API - An interface for humans to interact with the Control Planes.
- Most interactions with the API involve telling Kubernetes "this is the state I want everything to be in". Kubernetes then figures out how to make that happen.
- Parts:
- Scheduler - Determines what should happen, when, and where.
- Controller Manager - Manages the controllers.
- Key-Value Store - Effectively a "database of possible states".