LXC, Docker, LXD &snaps
•Descargar como ODP, PDF•
1 recomendación•479 vistas
Este documento proporciona una introducción a los contenedores en diferentes sistemas operativos como Solaris, FreeBSD y Linux. Explica las características clave de los contenedores en Linux como namespaces, cgroups, capabilities y LSM. También resume diferentes runtimes de contenedores como LXC, Docker y LXD, y aborda temas de seguridad como AppArmor, SELinux y Seccomp. Por último, introduce snaps como una alternativa de empaquetado y distribución de software que ofrece confinamiento y aislamiento.
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a LXC, Docker, LXD &snaps
Similar a LXC, Docker, LXD &snaps (20)
Último
Último (20)
LXC, Docker, LXD &snaps
- 1. LXC, Docker, LXD & snaps Containers, Containers, Containers Sergio Schvezov
- 3. Contenedores en distintos sistemas operativos Canonical Como esta implementado en el kernel ● Solaris tiene zones ● FreeBSD tiene jails ● Linux tiene un monton de cosas agregadas a las que despues llaman contenedor.
- 4. chroot Canonical ● syscall ● Requiere CAP_SYS_CHROOT. ● No es seguro.
- 5. pivot_root Canonical mount /dev/hda1 /new-root cd /new-root pivot_root . old-root exec chroot . sh <dev/console>dev/console2>&1 umount /old-root
- 6. Contenedores en Linux Canonical Formado por el conjunto de ● namespaces. ● cgroups. ● Linux capabilities. ● LSM. ● Seccomp. ● Networking.
- 8. capabilities Canonical ● Érase una vez o eras root o no lo eras. ● Capabilities pueden ser asignadas a threads o archivos. ● SUID root o ser root implica todas las capabilities. ● Capabilities tienen nombres como CAP_SYS_ADMIN, CAP_NET_ADMIN, CAP_FOWNER… ● Capabilities asignados se pueden ver en /proc/$PID/status. ● Capabilities en archivos son guardados en xattr.
- 10. namespaces: syscalls Canonical ● clone clona un proceso y namespace. El nuevo proceso se une a ese namespace. ● unshare crea nuevos namepaces y los une al proceso llamante. ● setns une procesos existentes a namespaces.
- 11. namespaces Canonical ls -al /proc/<pid>/ns lrwxrwxrwx 1 root root 0 Apr 24 17:29 ipc -> ipc: [4026531839] lrwxrwxrwx 1 root root 0 Apr 24 17:29 mnt -> mnt: [4026531840] lrwxrwxrwx 1 root root 0 Apr 24 17:29 net -> net: [4026531956] lrwxrwxrwx 1 root root 0 Apr 24 17:29 pid -> pid: [4026531836] lrwxrwxrwx 1 root root 0 Apr 24 17:29 user -> user: [4026531837] lrwxrwxrwx 1 root root 0 Apr 24 17:29 uts -> uts: [4026531838]
- 12. namespaces: user Canonical ● El proceso tendrá un nuevo set de UIDs, GUIDs y capabilties en este namespace. ● La base para contenedores sin privilegios. ● Aplicado pasando el flag CLONE_NEWUSER en la llamada clone() o unshare().
- 13. namespaces: mount Canonical ● Montaje y desmontaje dentro del namespace no afectará al resto del sistema. ● Excepto cuando se use mount –make-shared. ● Aplicado pasando el flag CLONE_NEWNS en la llamada clone() o unshare(). ● Requiere CAP_SYS_ADMIN.
- 14. namespaces: PID Canonical ● Hijos tendrán un conjunto distinto de mapeos de PID-a-proceso que su padre. ● Aplicado pasando el flag CLONE_NEWPID en la llamada clone() o unshare(). ● Requiere CAP_SYS_ADMIN.
- 15. namespaces: ipc Canonical ● Permite que un proceso tenga su propio espacio para objectos IPC System V y POSIX message queues. ● Aplicado pasando el flag CLONE_NEWIPC en la llamada clone() o unshare(). ● Requiere CAP_SYS_ADMIN.
- 16. namespaces: UTS Canonical ● Permite que un proceso tenga su propio nodename y domainname. ● Aplicado pasando el flag CLONE_NEWUTS en la llamada clone() o unshare(). ● Requiere CAP_SYS_ADMIN.
- 17. namespaces: network Canonical ● Permite que un proceso tenga su propio stack de red. ● Aplicado pasando el flag CLONE_NEWNET en la llamada clone() o unshare(). ● Requiere CAP_SYS_ADMIN.
- 18. Ejemplos
- 20. cgroup: memory Canonical ● Accounting: registro de las páginas usadas por el grupo. ● Soft limit → solo cuando el sistema esta bajo presión. ● Hard limit → OOM killer por grupo.
- 21. cgroup: cpu Canonical ● Accounting: registro de tiempo de usuario/sistema en el grupo. ● Accounting: registro de uso por CPU. ● Asignar grupos a CPUs específicas. ● Reservar CPUs para procesos. ● Prevenir rebote de procesos entre CPUs.
- 22. cgroup: blkio Canonical ● Accounting: registro de I/O en el grupo. ● Hacer throtling por grupo.
- 23. cgroup: devices Canonical ● Controla lo que el grupo puede hacer con device nodes (r/w/mknod).
- 24. cgroup: freezer Canonical ● Permite congelar un grupo de procesos. ● Como un SIGSTOP/SIGCONT masivo. ● No puede ser interferido por procesos.
- 25. Ejemplos
- 26. Seguridad Seccomp, AppArmor & SELinux
- 27. seguridad: apparmor Canonical ● Confina programas a un conjunto de recursos. ● A traves de perfiles levantados en el kernel. ● Dos modos: enforce y complain. ● Puede mediar: ● acceso a archivos ● bibliotecas. ● capabilities. ● dbus. ● redes (protocolo, tipo, dominio). ● unix sockets ● …
- 28. seguridad: selinux Canonical ● inodes en vez de paths. ● es mucho mas complejo…
- 29. seguridad: seccomp Canonical ● Secure Computing Mode ● De forma predeterminada solamente permite exit(), sigreturn(), read() & write() ● Procesos reciben SIGKILL si usan un syscall no permitido.
- 32. container runtimes: lxc Canonical ● Herramientas de userland ● Los contenedores son un directorio en /var/lib/lxc ● Tiene un pequeño archivo de configuración + rootfs ● Fácil de usar por sysadmins.
- 33. container runtimes: docker Canonical ● Daemon con API RESTish. ● Primeras versiones basadas en lxc. ● Ya saben…
- 34. container runtimes: lxd Canonical Qué es: ● Daemon con API REST simple. ● cli simple. ● Usa todos las caracteristicas de seguridad del kernel. ● Usa la API de lxc para manejar contenedores. ● Solo trabaja con contenedores de sistema completo. ● Contenedores sin privilegio por defecto.
- 35. container runtimes: lxd Canonical ● Probalo → https://linuxcontainers.org/lxd/try-it/
- 36. Snaps Overview
- 37. snaps: pitch Canonical ● confinados. ● transaccionales. ● inmutables.
- 38. snaps: confinamiento Canonical ● docker y lxc/lxd contienen. ● snaps estan confinados. ● hace pivot_root. ● solamente usa mount namespace. ● el namespace de red y procesos es el global. ● hace uso de LSM si esta disponible. ● espacios de escritura segregados.
- 39. snaps: lo que ve un snap Canonical versioned root writable area (for services) $SNAP_DATA common root writable area (for services) $SNAP_COMMON versioned user writable area $SNAP_USER_DATA /tmp (per service and app)/tmp (per service and app) /tmp (per service and app process) ~ /dev/<device> /sys / (from core snap) /var/lib/snapd/hostfs (/ from host) snap code & assets (squashfs, RO bind-mounted in /snap/<snap_name>/<version>) $SNAP Service common user writable area $SNAP_USER_COMMON Service CLI GUI
- 40. snaps: cómo interactuan Canonical app snapapp snap app writable area app writable area app snap app writable area app snap app writable area
- 41. snaps: all snaps Canonical Kernel snap Core snap Gadget snap App snap App snap App snap Content interface snap
- 42. snaps: comparación Canonical Host Linux Filesystem Machine Containers Process Containers Snap extends host Virtual Machines Traditional operations Traditional operations Mesos / Kubernetes / Swarm KVM LXD Docker / RunC / Rkt
- 43. snaps: all snaps Canonical Kernel snap Core snap Gadget snap App snap App snap App snap Content interface snap
- 44. Ejemplos
- 46. bibliografía Canonical ● Herramientas de userland ● Los contenedores son un directorio en /var/lib/lxc ● Tiene un pequeño archivo de configuración + rootfs ● Fácil de usar por sysadmins.
Notas del editor
- Que es un contenedor? Elevator pitch: - algo a lo que le puedo hacer ssh - algo a lo que se parece a una VM Mas bajo nivel: - usa el kernel del host - no puede levantar sus propios modulos. - no necesita init como PID1
- initrd usa esto
- Threads: Permitted, Inheritable, Effective, Ambient. Files: Permitted, Inheritable, Effective.
- Lo que ve un proceso. Como lo ve
- Cada namespace tiene asignado su propio inode El namespace se termina cuando todos sus procesos se terminan y nadie se agarra del inode.
- unshare --map-root-user --user bash touch s ls -l s exit ls -l s
- unshare -m --map-root-user --user bash cat /proc/self/mounts mount -n -o size=1m -t tmpfs tmpfs $(mktemp -d –tmpdir=/tmp) cat /proc/self/mounts|tail -1
- No se si este lo usa docker. Nesting de hasta 32 Sirve para containers o para facilitar process migration, por ej usando CRIU Evitamos colisiones si los procesos que se migran viven en su propio ns. CRIU → Checkpoint-Restore In Userspace. openVZ tiene su propia implementacion
- When an IPC namespace is destroyed (i.e., when the last process that is a member of the namespace terminates), all IPC objects in the namespace are automatically destroyed.
- El mas simple de implementar en el kernel. Su estructura de datos tiene solamente 6 miembros: - sysname - nodename - release - version - machine - domainname
- kernel struct es gigante loopback device SNMP todas las tablas de red. network fs profs sysfs sockets Para comunicar namespaces usamos veth, todos los veth se conectan a un bridge (docker0). al crearse se crea un dispositivo de loopback un socket pertenece a un solo namespace When a network namespace is freed (i.e., when the last process in the namespace terminates), its physical network devices are moved back to the initial network namespace (not to the parent of the process).
- # user unshare --map-root-user --user bash ls -l /proc/self/ns cat /proc/self/uid_map touch s ls -l s exit ls -l s mount -n -o size=1m -t tmpfs tmpfs $(mktemp -d –tmpdir=/tmp) #fail ping google.com #fail # mount unshare -m --map-root-user --user bash cat /proc/self/mounts mount -n -o size=1m -t tmpfs tmpfs $(mktemp -d –tmpdir=/tmp) cat /proc/self/mounts|tail -1 # pid unshare --pid --fork --mount-proc --user –map-root-user ps aux # uts unshare --uts --user --map-root-user bash hostname mordor
- control groups es un subsistema para Manejar los recursos, hacer accounting y seguimient (accounting and tracking). Maneja recursos tales como memoria, cpu, redes, dispositivos. En cuanto a contenedores limita lo que podes usar (a diferencia de namespaces que limita lo que podes ver). Interfaz en el filesystem, interfaces mas altas a traves de cgmanager o systemd es un arbol, arrancamos con un nodo, cada proceso esta atado a uno de estos nodos. Siempre estamos en un cgroup.
- Cada pagina se cobra a un grupo, si la pagina se comparte se cobra a uno solo.
- No hay limites, throttling y demas hacen que sea impreciso. knobs: poner peso a la migracion de procesos.
- usado para process migration
- sudo cgm create all valinor ls /sys/fs/cgroup sudo cgm chown all valinor $(id -u) $(id -g) cgm movepid all valinor $$ cgm setvalue freezer valinor freezer.state FROZEN
- confinamiento a un contenedor.
- confinamiento a un contenedor.
- confinamiento a un contenedor.
- sudo aa-status cat /var/lib/snapd/apparmor/profiles/snap.docker.dockerd cat /var/lib/snapd/apparmor/profiles/snap.vim.vim less /var/lib/snapd/seccomp/profiles/snap.docker.dockerd
- openvz esta tambien desde mucho antes. systemd-nspawn es reciente.
- openvz esta tambien desde mucho antes. systemd-nspawn es reciente.
- sudo aa-status cat /var/lib/snapd/apparmor/profiles/snap.docker.dockerd cat /var/lib/snapd/apparmor/profiles/snap.vim.vim less /var/lib/snapd/seccomp/profiles/snap.docker.dockerd
- openvz esta tambien desde mucho antes. systemd-nspawn es reciente.