more docker notes
This commit is contained in:
parent
493a591e0c
commit
7f81cb18fb
9 changed files with 211 additions and 108 deletions
7
.vscode/markdown-styles.css
vendored
7
.vscode/markdown-styles.css
vendored
|
@ -1,8 +1,9 @@
|
|||
body {
|
||||
font-size: 16px;
|
||||
/* font-size: 16px; */
|
||||
}
|
||||
|
||||
code {
|
||||
font-family: "Fira Code";
|
||||
font-size: 14px !important;
|
||||
font-family: "PragmataPro Mono";
|
||||
|
||||
/* font-size: 14px !important; */
|
||||
}
|
||||
|
|
|
@ -1,10 +1,10 @@
|
|||
---
|
||||
categories:
|
||||
- DevOps
|
||||
tags: [docker, containerization]
|
||||
tags: [docker, containerization, Linux]
|
||||
---
|
||||
|
||||
# Containers in general
|
||||
# Containerizaton
|
||||
|
||||
> In this entry we look at containerization as a general technology that is distinct from its particular implementation by Docker.
|
||||
|
||||
|
@ -32,7 +32,7 @@ A key feature of the Linux kernal is the existence of **cgroups** (control group
|
|||
In ordinary [user space](/Operating_Systems/User_Space.md) applications share the _same_ processor, memory and file system resources. This increases the likelihood of resourcing challenges, dependency conflicts and security threats. Without modularisation and the titration of resources, you are opened up to much greater possibility of failure.
|
||||
|
||||
For example one application could fill up the harddrive preventing other applications from writing to it. One application can "bring down" another applicaton.
|
||||
|
||||
standard-userspace.png
|
||||
Prior to containerization, in an enterprise environment most of the system administration consisted in managing resouces to avoid excessive resource expenditure and security challenges.
|
||||
|
||||
_Standard userspace_
|
||||
|
@ -62,3 +62,11 @@ A containerized system radically reduces this overhead. It just starts up the co
|
|||
| Slower and more difficult to run | Scale rapidly due to lightweight nature |
|
||||
|
||||

|
||||
|
||||
## Why use containers?
|
||||
|
||||
- portability
|
||||
- scalability
|
||||
- efficiency
|
||||
- isolation
|
||||
- DevOps agility
|
41
DevOps/Docker/Docker_architecture.md
Normal file
41
DevOps/Docker/Docker_architecture.md
Normal file
|
@ -0,0 +1,41 @@
|
|||
---
|
||||
categories:
|
||||
- DevOps
|
||||
tags: [docker, containerization]
|
||||
---
|
||||
|
||||
# Docker architecture
|
||||
|
||||
## Overview
|
||||
|
||||

|
||||
|
||||
- The Docker Client is a thin API for making [REST API](/Databases/REST/RESTful_APIs.md) to the Docker Server. Any CLI command beginning `docker...` is an API request to the server.
|
||||
- The internal process name for the server is `dockerd`.
|
||||
- On `docker run...`, `dockerd` calls `containerd`. This process starts the container runtimes and configures container-level storage and networking.
|
||||
- This then spawns `container-shim` procecesses which takes any output from you container and puts it in a logfile. (A redirection of `stdout` and `stderr`) One shim is spawned for each container.
|
||||
- The shim then launches a container runtime called `runc`. The `runc` performs all the complex configuration of cgroups and namespaces to create the container environment.
|
||||
- `containerd` is purely a bootstrapper. Once it has fulfilled its function by initiating `runc`, the Docker instance is up and running and the kernel takes it from there. It is like a launch scaffold that can be discarded.
|
||||
|
||||
> If you are running Docker desktop on Mac or Windows, Docker creates a Linux virtual machine, since it cannot run natively on Windows or Mac. In these cases the the Docker Server runs inside this VM adding an additional layer of abstraction.
|
||||
|
||||
> Docker server also creates an internal virtual network and assigns IP addresses to the containers. (This can be used to get containers to communicate to each other over TCP/IP, since they are isolated by default.)
|
||||
|
||||
## Images
|
||||
|
||||
Containers are created from images stored in a registry (either the public Docker Hub or privately). `containerd` uses the image to tell `runc` how to construct and build the image.
|
||||
|
||||
```sh
|
||||
docker run [image_name]
|
||||
```
|
||||
|
||||
The images you have pulled from the registry are stored in a local registry on your machine.
|
||||
|
||||
When you run `docker run`, Docker will look first for the image in your local registry. If it cannot find it there, it will attempt to pull it from the remote registry.
|
||||
|
||||
This assumes you are using a third-party image. You can also create your own images by writing a Dockerfile:
|
||||
|
||||
```sh
|
||||
docker build [docker_file]
|
||||
docker run [resulting_image]
|
||||
```
|
|
@ -5,3 +5,86 @@ tags: [docker, containerization]
|
|||
---
|
||||
|
||||
# Docker containers
|
||||
|
||||
## Launch a container
|
||||
|
||||
We launch a container by running, e.g
|
||||
|
||||
```sh
|
||||
docker run hello-world
|
||||
```
|
||||
|
||||
Docker looks for the `hello-world` image in order to start the container. If it cannot find it, it will fetch the image from DockerHub.
|
||||
|
||||
(`docker run` assumes you are saying "run image in container" but you can specify other Docker objects such as networks.)
|
||||
|
||||
The `docker run` command is actually a composite of the following two commands:
|
||||
|
||||
```sh
|
||||
docker create --name [my_container_name] hello-world
|
||||
docker start [my_container]
|
||||
```
|
||||
|
||||
Here is an applied example:
|
||||
|
||||
```
|
||||
docker run --name my-container debian /bin/echo "Hello, world"
|
||||
```
|
||||
|
||||
This creates and runs a container from the Debian image and executes `/bin/echo` inside of it. Once you have run the above line, if the process is successful it will exit. The container will stop running but it will remain in memory. Nothing will be output (no "Hello, world"), because when you run it, you are _outside_ of the container.
|
||||
|
||||
## Launch a container as a daemon
|
||||
|
||||
You can also run a container as a [daemon](). In this mode, the container will run in the background and detach from the console. For example:
|
||||
|
||||
```sh
|
||||
docker run -d debian /bin/sh -c /bin/sh -c "while true; do echo 'Hello!'; sleep 1; done"
|
||||
```
|
||||
|
||||
Inside the container, this will echo "Hello!" every second in an infinite loop whilst the daemon is active.
|
||||
|
||||
The above command will not actually output anything. Instead it wil ouput the container ID, e.g:
|
||||
|
||||
```
|
||||
2749d796cbd64e9cf57307329e792587c39d8244f2377e62d78f3f3f77eecdb4
|
||||
```
|
||||
|
||||
You can use this to access the log for the container. When you do so, you will then see the output:
|
||||
|
||||
```sh
|
||||
docker log 2749
|
||||
hello
|
||||
hello
|
||||
hello
|
||||
...
|
||||
```
|
||||
|
||||
(We could also use the container name to reference the container, if we launched it with the `--name` param.)
|
||||
|
||||
## Stopping a container
|
||||
|
||||
```
|
||||
docker stop 2749
|
||||
```
|
||||
|
||||
There will be a delay because it shuts down gracefully. It sends a SIGINT to the process in the container with PID 1 (i.e the root or parent process for the container).
|
||||
|
||||
`stop` will keep the container in memory. This means you can still refer back to the logs and that it can be restarted.
|
||||
|
||||
Instead of `stop`, if you were to use:
|
||||
|
||||
```
|
||||
docker rm 2749
|
||||
```
|
||||
|
||||
The container will be stopped and deleted. The logs are deleted and the container cannot be recovered.
|
||||
|
||||
We can also tell Docker to immediately remove a container after it exits:
|
||||
|
||||
```
|
||||
docker run --rm [image]
|
||||
```
|
||||
|
||||
## Container lifecycle
|
||||
|
||||
## Interacting with containers
|
||||
|
|
|
@ -5,3 +5,50 @@ tags: [docker, containerization]
|
|||
---
|
||||
|
||||
# Docker: general overview
|
||||
|
||||
> Docker is an ecosystem of tools for creating, running and transporting containers.
|
||||
|
||||
The main product of the Docker company is Docker Desktop - a UI for running containers however the actual `docker` software is free and open source.
|
||||
|
||||
Docker standardised the use of containers set up the open-source Open Container Initiative which is a convention agreed upon by the major tech companies. It codifies the following:
|
||||
|
||||
- Docker runtime specification
|
||||
- Docker image specification
|
||||
- Docker registry specification
|
||||
|
||||
## Main components
|
||||
|
||||
- **Docker Engine**
|
||||
- The core component
|
||||
- Exposes the Docker API and manages the entire workflow around creating, running and deploying containers
|
||||
- **Docker Client**
|
||||
- The Docker CLI
|
||||
- The primary means of interacting with the Docker Engine
|
||||
- Provides commands for managing images, containers and other Docker objects
|
||||
- **Docker Compose**
|
||||
- A tool for defining and running multi-container applications
|
||||
- Define the configuration for all of the containers that make up the application in a single YAML file
|
||||
- **Docker Images**
|
||||
- See below
|
||||
- **Docker Containers**
|
||||
- See below
|
||||
- **Docker Registry**
|
||||
- A centralised location where Docker iamges can be stored and shared
|
||||
- DockerHub is the registry provided by Docker
|
||||
- Organisations can set up their own private registries
|
||||
|
||||
## Docker images
|
||||
|
||||
An image is a blueprint that contains the instructions to build a container. It's an immutable snapshot of the file system and configuration of an application. Images can be easily shared between developers.
|
||||
|
||||
They are runnable packages that contain everything needed to run an application including the binaries, libraries, resources and other dependencies.
|
||||
|
||||
It does not contain an operating sytem but may include a particular Linux distribution.
|
||||
|
||||
## Docker containers
|
||||
|
||||
A container is a runnign instance of a Docker image. Multiple, identical containers can be launched from the same, single image.
|
||||
|
||||
## Docker architectural overview
|
||||
|
||||
See [Docker architecture](/DevOps/Docker/Docker_architecture.md).
|
||||
|
|
|
@ -1,105 +1,3 @@
|
|||
## Difference with virtual machines
|
||||
|
||||
VMs require an OS. Containers do not. A VM contains a complete installation of a guest OS. Also provides isolation of resources (because you have an entirely separate OS).
|
||||
|
||||
The different OSs are managed by a hypervisor.
|
||||
|
||||
// TODO: Comparison table.
|
||||
|
||||
VMs are more heavyweight than a container runtime, slower and consume more resources.
|
||||
|
||||
The container runtime doesn't add overhead. It just starts up the container but after that, it is done since container handling is native to Linux. The kernel handles the rest.
|
||||
|
||||
## What is Docker ?
|
||||
|
||||
> Docker is an ecosystem of tools for creating, running and shipping containers.
|
||||
|
||||
Main product is Docker Desktop, a UI for running containers but the actual `docker` software is free and open source.
|
||||
|
||||
Docker standardised the use of containers and set up the open source Open Container Initiative, handing over its processs. The OCI is comprised of the major tech companies.
|
||||
|
||||
The OCI standardises the follwoing:
|
||||
|
||||
- Docker runtime specification
|
||||
- Docker image specification
|
||||
- Docker registry specification
|
||||
|
||||
Docker company used to offer a platform for companies to run docker containers but they eventually sold this and focused solely on Docker desktop (local running of images for development).
|
||||
|
||||
> An image is a blueprint that contains the instructions to build a container. It's an immutable snapshot of the file system and configuration of an application. Images can be easily shared between developers.
|
||||
|
||||
> A container is a executable package that contains everything needed to run an application. It will always run the same, regardless of infrastructure, in a sandboxed environment. It is a running instance of an image.
|
||||
|
||||
## Why use containers?
|
||||
|
||||
- portability
|
||||
- scalability
|
||||
- efficiency
|
||||
- isolation
|
||||
- DevOps agility
|
||||
|
||||
# Unit 2
|
||||
|
||||
Main components of Docker:
|
||||
|
||||
- docker engine
|
||||
- daemon that exposes the Docker API.
|
||||
- manages entire workflow aroung creating ,running and deploying containers.
|
||||
- docker client
|
||||
- The CLI through which you interact with the docker engine
|
||||
- use it to manage images, containers and other docker objects
|
||||
- docker compose
|
||||
- Sends REST requests to the engine. Two communicate over REST API principles
|
||||
- tool for running multi-container applications
|
||||
- run multiple containers for an application through a single YAML file (`docker compose`)
|
||||
- docker image
|
||||
- contain everything needed to run an application
|
||||
- can be exchanged and run on multiple systems
|
||||
- includes application binaries, libraries, resources
|
||||
- no OS but may include a particular distro
|
||||
- container
|
||||
- simply a running image instance
|
||||
- multiple identical containers can be launched from a single image
|
||||
- registry
|
||||
|
||||
// TODO: Add diagram of architecture
|
||||
|
||||
Distinguish Docker CLient from Docker Server
|
||||
|
||||
Client is thin API for making REST API calls to the server
|
||||
Eg: (docker pull, docker build, docker run)
|
||||
|
||||
Server comprises `dockerd` - the docker engine, long-lived daemon process running continuously
|
||||
|
||||
On `docker run`, `dockerd` calls `containerd` which starts container runtimes and configuring container-level networking and storage. That's all it does. Another daemon process. It is a container _supervisor_
|
||||
|
||||
This spawns `containerd-shim` processes.
|
||||
|
||||
A shim takes any output from your container and puts it in a log file. This launches the runtime `runc` which handles cgroups and namespaces.
|
||||
|
||||
Once `runc` has created container, it's done and the container is self-standing in the kernel. It's like a launch scaffold that can be discarded. It is of course blind to the rest of the OS
|
||||
|
||||
Containers are created from images stored in a registry. Have local and remote registry. Locals are pulled from remote.
|
||||
|
||||
`containerd` then uses image to tell `runc` how to construct and build the image.
|
||||
|
||||
```
|
||||
docker run [image name]
|
||||
```
|
||||
|
||||
This assumes you are using remote images. You can also create your own local images by writing your own Dockerfile. If local:
|
||||
|
||||
```
|
||||
docker build [docker-file]
|
||||
docker run [resulting-image]
|
||||
```
|
||||
|
||||
Local images can then be distributed to remote registries.
|
||||
|
||||
Docker server also creates an internal virtual network and assigns IP addresses to the containers. (This can be used to get containers to communicate to each other over TCP/IP, since they are isolated by default.)
|
||||
|
||||
If you are running Docker desktop on Mac or Windows, Docker creates a Linux virtual machine, since it cannot run natively on Windows or Mac. In these cases the the Docker Server runs inside this VM adding an additional layer of abstraction.
|
||||
|
||||
## Basic usage
|
||||
|
||||
docker run hello-world
|
||||
|
|
|
@ -119,6 +119,23 @@ const roleDescriptions: UserRoleDescriptions = {
|
|||
};
|
||||
```
|
||||
|
||||
Here is a simpler example
|
||||
|
||||
```ts
|
||||
type Person = {
|
||||
name: string;
|
||||
nationality: string;
|
||||
};
|
||||
|
||||
type PersonInstance = Record<string, Person>;
|
||||
const thomasInstance: PersonInstance = {
|
||||
thomas: {
|
||||
name: "Thomas",
|
||||
nationality: "British",
|
||||
},
|
||||
};
|
||||
```
|
||||
|
||||
### Exclude
|
||||
|
||||
Creates a type by excluding specific properties from the given type.
|
||||
|
|
BIN
_img/dock-architecture.png
Normal file
BIN
_img/dock-architecture.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 155 KiB |
8
_meta/ChatGPT_prompt.md
Normal file
8
_meta/ChatGPT_prompt.md
Normal file
|
@ -0,0 +1,8 @@
|
|||
refactor the following methods. consider the following:
|
||||
|
||||
- reduce repetition and use greater abstraction where possible
|
||||
- do not use then clauses
|
||||
- do not use for loops, use maps, filter, reduce instead
|
||||
- break complex functionality up into smaller functions
|
||||
- increase efficiency
|
||||
- increase readability
|
Loading…
Add table
Reference in a new issue