container-bauen/README.md
2019-05-09 04:11:51 +02:00

178 lines
3.1 KiB
Markdown
Raw Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# Ich
erkan@linsenraum.de
@erkuleswastaken
xing/linkedin
https://devops-training.de/
https://devops-kubernetes-camp.de/
Und ja: Freiberufler
# Ziel
* Docker/LXC/systemd-nspawn/Rkt
* Alles nur Linux
* Jeder gute Admin sollte eh alles kennen was jetzt kommt.
# Container vs. VM
* VMs eumulieren Hardware
* Ein Container ist nur ein Prozess auf dem Host
* Was immer das auch heißt
# Docker
Was haben wir?
Ist doch wie eine VM
~~~
docker container run --rm -ti --name vorlage ubuntu
~~~
* Prozessraum
* Prozesse
* Filesystem
# Filesystem? chroot!
~~~
mkdir /tmp/container
docker container export vorlage | tar xf - -C /tmp/container
~~~
Warum wollte ich?:
~~~
chroot /tmp/container zsh
~~~
Problem mit chroot?
Wir haben quasi keine Isolierung `¯\_(ツ)_/¯`
# Namspaces
Genereeller Überblick:
~~~
readlink /proc/self/ns/*
~~~
Schauen wir uns das erst mal ohne
chroot an.
Aber am Ende:
Imho noch ein `pstree` mitlaufen lassen:
~~~
unshare -p -f -m -u -n -i
chroot /tmp/container
ps ax .. und ein Hups
~~~
Genau das machen was da steht.
Und schauen ob andere Prozess was in /tmp/container/proc sehen :)
# Mount
Wo wir schon bei Mount sind.
~~~
docker container run --volume /var/tmp:/srv --rm -ti ubuntu
~~~
* Oben beim /proc haben wir ja schon einen mount gesehen.
* Hier ist es genau so nur *vor* dem chroot
* Und ja nach dem unshare damit sonst niemand den mount mitbekommt \o/
# Cgroups
Am Beispiel pids (limit)
~~~
docker container run --rm -ti --pids-limit 5 ubuntu
~~~
Achso: wieder ein `pstree` mitlaufen lassen :)
~~~
mkdir /sys/fs/cgroup/pids/lala
echo 5 >/sys/fs/cgroup/pids/lala/pids.max
echo $$ >/sys/fs/cgroup/pids/lala/tasks
besser?
echo ContainerPid >/sys/fs/cgroup/pids/lala/tasks
~~~
# Artefakt
Aber jeder Container schreibt doch ein einen eigenen Layer
~~~
docker container run --rm -d --name www erkules/nginxhostname
docker container ps -s -f name=www
~~~
Gleich 2x
~~~
mkdir /tmp/upper1 /tmp/work1 /tmp/runningcontainer1
mount -t overlay overlay -o lowerdir=/tmp/container,upperdir=/tmp/upper1,workdir=/tmp/work1 /tmp/runningcontainer1
~~~
~~~
mkdir /tmp/upper2 /tmp/work2 /tmp/runningcontainer2
mount -t overlay overlay -o lowerdir=/tmp/container,upperdir=/tmp/upper2,workdir=/tmp/work2 /tmp/runningcontainer2
~~~
dd
:
# Netzwerk?
FYI: Das ist jetzt total abgedreht!
FYI: `ip netns` macht auch nur `unshare` `¯\_(ツ)_/¯`
Vielleicht statt <<ContainerPID>> irgend ein `unshare -n`?
Oder wir haben pstree noch am Laufen ...
~~~
mkdir /var/run/netns <- Falls nicht vorhanden. Braucht iproute2
ln -s /proc/<<ContainerPID>>/ns/net /var/run/netns/hallo
ip netns exec hallo ip a s
ip link add hostende type veth peer name containerende
ip link set containerende netns hallo
ip netns exec hallo ip a s
ip netns exec jax ip link set containerende up
ip netns exec jax ip a add 172.40.1.1/26 dev containerende
ip link set hostende up
ip a add 172.40.1.2/26 dev hostende
~~~
Pingt ...
aber noch lange nicht fertig ... ;)
# nsenter
Haben wir noch Zeit?
Und wenn schon!
# Conclusio
* Wir haben die ganz Zeit *einen* Prozess geändert
* Von wegen VM :)