
##### Why containers ?

If we want to run a web server, we can either set up our own or rent a server.The problem with the first approach is that
if we want to spin up another server , we require time to install,setup and bring the server into the server farm.
Then we have to worry about upgrading it.Also we have to worry about capacity ,as we may need to increase server capacity for festive season and then we have bunch of services sitting idle the rest of the year.

##### Virtual Machines

Virtual machines (VMs) are an abstraction of physical hardware turning one server into many servers.
The hypervisor allows multiple VMs to run on a single machine. Each VM includes a full copy of an operating system, the application, necessary binaries and libraries - taking up tens of GBs.
VMs can also be slow to boot.
They adds a layer of abstraction between us and the processor.Now instead of having one instance of Linux ,we have multiple guest instances of Linux running inside of a host instance of Linux. This allows us more flexibility , so if i am adding a new service, I can just spin up a new VM on one of my servers.
The host OS offers VM certain amount of resources and if VM runs out, they don't affect other guest OS running on server.
If the guests crash their server,they crash their guest OS and not affect others.
They also can't peek into other's file as VM has no concept of any sibling VM on machine hence its secure.

![Containers and Docker](https://www.docker.com/wp-content/uploads/2021/11/docker-containerized-and-vm-transparent-bg.png)

##### Containers

Containers are an abstraction at the app layer that packages code and dependencies together.
Multiple containers can run on the same machine and share the OS kernel with other containers, each running as isolated processes in user space.
Containers take up less space than VMs (container images are typically tens of MBs in size), can handle more applications and require fewer VMs and Operating systems.

Containers give us many of the security and resource management features of VM's but without the cost of having to run a whole operating system.It instead uses chroot,namespace and cgroup to seperate a group of process from each other.

###### chroot

In our container use case, we just set the root directory to be where ever the new container's new root directory should be. And now the new container group of processes can't see anything outside of it, eliminating our security problem because the new process has no visibility outside of its new root.

If we are in Windows and using WSL,open a new WSL terminal in Ubuntu.

```console
docker run -it --name docker-host --rm --privileged ubuntu:bionic

```

Okay, so let's attempt to use chroot right now.

- Make a new folder in our home directory via mkdir /my-new-root.
- Now try to run chroot /my-new-root bash and see the error it gives us.

This will give error as we don't have OS inside of this directory.
We have to make a copy of OS inside of this directory.

- cp /bin/bash /bin/ls /my-new-root/bin/
- chroot /my-new-root bash

Still not working ??

The problem is that these commands rely on libraries to power them and we didn't bring those with us. So let's do that too. Run ldd /bin/bash. This print out something like this:

```console
  ldd /bin/bash
  linux-vdso.so.1 (0x00007fffa89d8000)
  libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f6fb8a07000)
  libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f6fb8803000)
  libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6fb8412000)
  /lib64/ld-linux-x86-64.so.2 (0x00007f6fb8f4b000)
```

These are the libraries we need for bash. Let's go ahead and copy those into our new environment.

```console
mkdir /my-new-root/lib /my-new-root/lib64

cp /lib/x86_64-linux-gnu/libtinfo.so.5 /lib/x86_64-linux-gnu/libdl.so.2 /lib/x86_64-linux-gnu/libc.so.6 /my-new-root/lib
cp /lib64/ld-linux-x86-64.so.2 /my-new-root/lib64
```

Do it again for ls. Run ldd /bin/ls

Follow the same process to copy the libraries for ls into our my-new-root.

```console
cp /lib/x86_64-linux-gnu/libselinux.so.1 /lib/x86_64-linux-gnu/libpcre.so.3 /lib/x86_64-linux-gnu/libpthread.so.0 /my-new-root/lib
```

Now, finally, run chroot /my-new-root bash and run ls. We should successfully see everything in the directory. Now try pwd to see our working directory. We should see /.**Containers!!!**

##### Namespaces

**Problem**:

- chroot in a terminal into our environment
- In another terminal, run docker exec -it docker-host bash. This will get another terminal session #2 for us (I'll refer to the chroot'd environment as #1)
- Run tail -f /my-new-root/secret.txt & in #2. This will start an infinitely running process in the background.
- Run ps to see the process list in #2 and see the tail process running. Copy the PID (process ID) for the tail process.
- In #1, the chroot'd shell, run kill <PID copied>. This will kill the tail process from inside the chroot'd environment.

This is a problem because that means chroot isn't enough to isolate someone. We need more barriers. This is just one problem, processes, but it's illustrative that we need more isolation beyond just the file system.

**Solution**:

Namespaces allow us to hide processes from other processes. If we give each chroot'd environment different sets of namespaces, now everyone can't see each others' processes (they even get different process PIDs, or process IDs, so they can't guess what the others have) and we can't steal or hijack what we can't see!

So let's create a chroot'd environment now that's isolated using namespaces using a new command: unshare. **unshare** creates a new isolated namespace from its parent.

```console
exit # from our chroot'd environment if you're still running it, if not skip this

# install debootstrap
apt-get update -y
apt-get install debootstrap -y
debootstrap --variant=minbase bionic /better-root

# head into the new namespace'd, chroot'd environment
unshare --mount --uts --ipc --net --pid --fork --user --map-root-user chroot /better-root bash # this also chroot's for us
mount -t proc none /proc # process namespace
mount -t sysfs none /sys # filesystem
mount -t tmpfs none /tmp # filesystem

ps aux
```

This will create a new environment that's isolated on the system with its own PIDs, mounts (like storage and volumes), and network stack. Now we can't see any of the processes!

##### cgroups

Every isolated environment has access to all physical resources of the server. There's no isolation of physical components from these environments.

cgroups, or control groups. Google saw this same problem when building their own infrastructure and wanted to protect runaway processes from taking down entire servers and made this idea of cgroups so we can say "this isolated environment only gets so much CPU, so much memory, etc. and once it's out of those it's out-of-luck, it won't get any more."

![cgroup](https://miro.medium.com/max/570/0*y8AuUHSoTGRqX40h.jpeg)

```console
# outside of unshare'd environment get the tools we'll need here
apt-get install -y cgroup-tools htop

# create new cgroups
cgcreate -g cpu,memory,blkio,devices,freezer:/sandbox

# add our unshare'd env to our cgroup
ps aux # grab the bash PID that's right after the unshare one
cgclassify -g cpu,memory,blkio,devices,freezer:sandbox <PID>

# list tasks associated to the sandbox cpu group, we should see the above PID
cat /sys/fs/cgroup/cpu/sandbox/tasks

# show the cpu share of the sandbox cpu group, this is the number that determines priority between competing resources, higher is is higher priority
cat /sys/fs/cgroup/cpu/sandbox/cpu.shares

# kill all of sandbox's processes if you need it
# kill -9 $(cat /sys/fs/cgroup/cpu/sandbox/tasks)

# Limit usage at 5% for a multi core system
cgset -r cpu.cfs_period_us=100000 -r cpu.cfs_quota_us=$[ 5000 * $(getconf _NPROCESSORS_ONLN) ] sandbox

# Set a limit of 80M
cgset -r memory.limit_in_bytes=80M sandbox
# Get memory stats used by the cgroup
cgget -r memory.stat sandbox

# in terminal session #2, outside of the unshare'd env
htop # will allow us to see resources being used with a nice visualizer

# in terminal session #1, inside unshared'd env
yes > /dev/null # this will instantly consume one core's worth of CPU power
# notice it's only taking 5% of the CPU, like we set
# if you want, run the docker exec from above to get a third session to see the above command take 100% of the available resources
# CTRL+C stops the above any time

# in terminal session #1, inside unshare'd env
yes | tr \\n x | head -c 1048576000 | grep n # this will ramp up to consume ~1GB of RAM
# notice in htop it'll keep the memory closer to 80MB due to our cgroup
# as above, connect with a third terminal to see it work outside of a cgroup

```

#### DOCKER

###### Docker Desktop

Docker Desktop runs the Docker daemon (daemon just means a program that runs in the background all the time) so that we can download, run, and build containers.

###### Docker Hub

Docker Hub is a public registry of pre-made containers. Think of it like an npm for containers. Instead of having to handcraft everything ourself, we can start out with a base container from Docker Hub and start from there. For example, instead of having to start with Ubuntu and install Node.js on it ourself, we can just start with a container that has Node.js already on it!

###### Images

Pre-made containers are called images. They basically dump out the state of the container, package that up, and store it so we can use it later

###### Docker Images without Docker

```console
# start docker contanier with docker running in it connected to host docker daemon
docker run -ti -v /var/run/docker.sock:/var/run/docker.sock --privileged --rm --name docker-host docker:18.06.1-ce

# run stock alpine container
docker run --rm -dit --name my-alpine alpine:3.10 sh

# export running container's file system
docker export -o dockercontainer.tar my-alpine

# make container-root directory, export contents of container into it
mkdir container-root
tar xf dockercontainer.tar -C container-root/

# make a contained user, mount in name spaces
unshare --mount --uts --ipc --net --pid --fork --user --map-root-user chroot $PWD/container-root ash # this also does chroot for us
mount -t proc none /proc
mount -t sysfs none /sys
mount -t tmpfs none /tmp

# here's where you'd do all the cgroup rules making with the settings you wanted to
```

###### Docker Images with Docker

```console
docker run --interactive --tty alpine:3.10 # or, to be shorter: docker run -it alpine:3.10
```

This will drop us into a Alpine ash shell inside of a container as the root user of that container.

The -it part says you want to be dropped into the container interactively so you can run commands and inspect the container. By default containers run and then exit as soon as they're done.

So now what if we want to detach the container running from the foreground?

```console
docker run --detach -it ubuntu:bionic # or, to be shorter: docker run -dit ubuntu:bionic
```

```console
docker attach <ID or name> # e.g. `docker attach 20919c49d6e5` would attach to that container
```

This allows us to attach a shell to a running container and mess around with it.
Useful if we need to inspect something or see running logs.

Feel free to type exit to get out of here. Run docker run -dit ubuntu:bionic one more time. Let's kill this container without attaching to it. Run docker ps, get the IDs or names of the containers you want to kill and say:

```console
docker kill <IDs or names of containers> # e.g. `docker kill fae0f0974d3d 803e1721dad3 20919c49d6e5` would kill those three containers
```

A fun way to kill all running containers would be

```console
docker kill $(docker ps -q)
```

The $() portion of that will evaluate whatever is inside of that first and plug its output into the second command. In this case, docker ps -q returns all the IDs and nothing else. These are then passed to docker kill which will kill all those IDs.

###### --name and --rm

Let's make it a bit easier to keep track of these.

```console
docker run -dit --name my-ubuntu ubuntu:bionic
docker kill my-ubuntu
```

Now you can refer to these by a name you set.
But now if you tried it again, it'd say that my-ubuntu exists.

If you run docker ps --all you'll see that the container exists even if it's been stopped.

That's because Docker keeps this metadata around until you tell it to stop doing that.

You can run docker rm my-ubuntu which will free up that name or you can run docker container prune to free up all existing stopped containers (and free up some disk space.)

In the future you can just do

```console
docker run --rm -dit --name my-ubuntu ubuntu:bionic
docker kill my-ubuntu
```

![Ship machine](https://external-preview.redd.it/aR6WdUcsrEgld5xUlglgKX_0sC_NlryCPTXIHk5qdu8.jpg?auto=webp&s=5fe64dd318eec71711d87805d43def2765dd83cd)

##### Node.js on Containers

```console
docker run -it node:12-stretch
```

Notice this drops us into the Node.js REPL which may or may not be what we want. To dropped into bash of that container we do :

```console
docker run -it node:12-stretch bash
```

_Reference_ : https://btholt.github.io/complete-intro-to-containers/
