An Overview Of Containers And Containerizing Options
Containers.
"OS-like" pieces of code that are intended to "wrap" things like applications, functionalities, programs, databases, etc.
- An Overview Of Containers And Containerizing Options
Kubernetes Uses Containers
Each k8s node needs a container runtime on it.
Kubelet launches pods, which include containers, and every node that can run a pod (which is most likely all nodes) needs the container runtime to run the containers that live in the pods.
Kubernetes Relied On Docker
Kubernetes used docker, exclusively, as the container tool. Recently, kubernetes announced plans to move away from dockershim as the default.
Containers Need Container Runtimes
The Runtime runs the containerized "applications".
Docker Engine is a runtime.
containerd is another.
Kubelet Has An Interface For Container Runtimes
The Container Runtime Interface(CRI) is a "plugin" that kubelet uses to "talk to" the various container runtimes.
There Are A Bunch Of Container Tooling Options
Docker
Perhaps the longest-used container tool on the market.
It has grown in scope since it started - swarm, a desktop gui, the compose cli, etc.
Docker's increase in size, scope, and even $$ requirements, have led to other open-source tooling to be developed and relied on.
containerd
This tool is modular and "low-level". Per the github readme, it "...is available as a daemon for Linux and Windows, which can manage the complete container lifecycle of its host system...". This seems like a specialed tool for folks who will be tinkering with more than just building/running/deploying applications.
CRI-O
CRI-O looks like it is meant to be a one-size-fits-all interface between "... OCI conformant runtimes and the Kubelet". This does not currently use or offer a usable CLI.
rkt
rkt, pronounced "rocket", has ceased dev/maintenance efforts.
"Containerizing" an App
The more "stateless" the project, the easier it will be to "containerize" the project.
Imagine deploying the app on several hosts & identify changable "dependencies". These dependencies should be stored "outside" of the "containerized" app.
Key "dependencies" to consider when preparing an app for containerization:
- os versions (alpine, alpine 1.x, etc)
- code language version (node v 14, 16, 18, etc)
- reliant application connection parameters
- a database url might be unique per env (development, testing, production, red/blue, canary, etc)
- a logging service may be different
- a memory store
- security mechanism strength may vary
In K8s, these environment-based variables (env vars) can be stored in ConfigMaps Or Secrets.
Docker creates containers.
buildah creates containers. This even works with dockerfiles.
podman creates containers.
An Overview Of Containerizing an App
- create a dockerfile
- this holds the directions for docker to turn the repo into an image
- build the instructions to containerize the app
- these instructions go in the dockerfile
- for something like a rest api, start with a trusted "base" image (node), copy the api's needed files, add a run command (these details are out of scope for this)
- turn the project into an image
- the image gets used and ran later on
- this is a unit that is usable by a container runtime
- tag the image - deets elsewhere on tagging
- send the image to an image repo for you & others to use
- dockerhub exists
- for some trade-offs, hosting our own image repo can work:
- less network traffic
- less content available to the web (and/or less fees for others to maintain the repo)
- more internal administration (how long do we keep images around?)
- more security
An Overview of using images in K8s
kubectl create deployment my-deployment --image=my-repo/my-api:1.0.1- tell kubectl
- the name of the image to use
- the tag of the image to use
- the name of the docker image registry to use