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.
Presesntación introductoria de cómo realizar la construcción de los contenedores Docker de nuestras aplicaciones Java y realizar el despliegue en Kubernetes para poder escalar automáticamente las aplicaciones.
Esta charla se realizón en el MeetUp de JUG - CS
Kubernetes es un proyecto open source de Google cuyo propósito es el de hacer de orquestador de containers. En este seminario se tratará de crear una base partiendo desde los principios más fundamentales, de forma que cualquiera con unos conceptos básicos de contenedores pueda entender cómo funciona kubernetes y qué utilidades nos ofrece a la hora de manejar contenedores.
Ponente: Alfredo Espejel, técnico de sistemas en Paradigma
Alfredo cuenta con casi 10 años de experiencia en administración de sistemas, principalmente Linux. Interesado también en las redes, pero sobre todo en las últimas tendencias y tecnologías.
Vídeo de la charla: https://www.youtube.com/watch?v=zI16fatmnVQ
Más información sobre el meetup: http://www.meetup.com/Cloud-Computing-Spain/events/226254765/
En esta charla conjunta con el Colegio de Ingenieros de Guatemala hablamos acerca de Kubernetes como plataforma de orquestación de contenedores, incluyendo:
- Motivaciones e historia de Kubernetes
- Arquitectura básica de funcionamiento
- Uso de objetos centrales -e.g. Container, Pod, Deployment, Service-
Para la charla se ejecutan diversas pruebas básicas con Minikube y Oracle Cloud con el objetivo de presentar Kubernetes a las personas que estan iniciando con la plataforma.
Presentación utilizada durante el seminario de actualización del Colegio de Ingenieros de Guatemala 2020.
Durante la charla se discuten principios básicos de Docker, Kubernetes y su necesidad/utilidad en microservicios con Java
Presesntación introductoria de cómo realizar la construcción de los contenedores Docker de nuestras aplicaciones Java y realizar el despliegue en Kubernetes para poder escalar automáticamente las aplicaciones.
Esta charla se realizón en el MeetUp de JUG - CS
Kubernetes es un proyecto open source de Google cuyo propósito es el de hacer de orquestador de containers. En este seminario se tratará de crear una base partiendo desde los principios más fundamentales, de forma que cualquiera con unos conceptos básicos de contenedores pueda entender cómo funciona kubernetes y qué utilidades nos ofrece a la hora de manejar contenedores.
Ponente: Alfredo Espejel, técnico de sistemas en Paradigma
Alfredo cuenta con casi 10 años de experiencia en administración de sistemas, principalmente Linux. Interesado también en las redes, pero sobre todo en las últimas tendencias y tecnologías.
Vídeo de la charla: https://www.youtube.com/watch?v=zI16fatmnVQ
Más información sobre el meetup: http://www.meetup.com/Cloud-Computing-Spain/events/226254765/
En esta charla conjunta con el Colegio de Ingenieros de Guatemala hablamos acerca de Kubernetes como plataforma de orquestación de contenedores, incluyendo:
- Motivaciones e historia de Kubernetes
- Arquitectura básica de funcionamiento
- Uso de objetos centrales -e.g. Container, Pod, Deployment, Service-
Para la charla se ejecutan diversas pruebas básicas con Minikube y Oracle Cloud con el objetivo de presentar Kubernetes a las personas que estan iniciando con la plataforma.
Presentación utilizada durante el seminario de actualización del Colegio de Ingenieros de Guatemala 2020.
Durante la charla se discuten principios básicos de Docker, Kubernetes y su necesidad/utilidad en microservicios con Java
En esta charla se discuten los distintos abordajes para lograr tolerancia a fallas en sistemas distribuidos y microservicios, especialmente con microservice chassis y service mesh.
Posteriormente se comentan algunas opciones para su implementación utilizando MicroProfile Fault Tolerance y Linkerd
En esta presentación se presenta una discusión acerca del nuevo glosario del ingeniero de software incluyendo:
- TDD
- DDD
- Cloud Native
- 12 factors
- DevOps
- CQRS
- Event Sourcing
Que significan todos esos términos y como pueden ayudarlos en su jornada cloud.
¿Cómo se despliega y autoescala Couchbase en Cloud? ¡Aprende de manera práctica!Paradigma Digital
En el pasado Meetup, presentamos Couchbase de manera general, pero ha llegado el momento de ir ahondando en los detalles del producto para conocer todas sus capacidades. Esto nos permitirá estar en mejor disposición para adoptarlo en nuestros proyectos.
En esta ocasión, se hablará de la capa de operaciones y despliegue de Couchbase aunque no con un enfoque tradicional en máquinas físicas, sino siguiendo las buenas prácticas del mercado. Explicaremos y haremos el despliegue en Google Cloud con escalabilidad horizontal elástica y automática.
Para llevar a cabo esto haremos uso, entre otras, de las siguientes tecnologías: Google Cloud, Kubernetes, Python y, por supuesto, Couchbase.
Pondremos a prueba nuestra infraestructura con una pequeña aplicación, si queréis ver los resultados, no os lo podéis perder!
Podemos construir entornos sencillos y complejos, de manera muy fácil y que se pueden ejecutar en cualquier máquina sin importar el sistema operativo que esta utilice.
Groovy es un lenguaje alternativo para la JVM, al ser un lenguaje dinámico, permite que usemos conceptos como metaprogramación; característica que sirve como base para manipular el código en tiempo de ejecución.
Groovy extiende las librerías estándar de Java con una colección de clases que son implementadas con metaprogramación para facilitar el uso de diversos APIs. Esta colección se llama GDK, mostraremos los diversos usos que tiene y como ayudan al desarrollador.
Para finalizar veremos como participar en manipulación del byte-code que genera el compilador de Groovy con simples anotaciones de Java. Mostrare las anotaciones que Groovy provee y como podemos implementar las propias.
Estas caracteristicas del lenguaje; forman una triada que permiten potenciar y elevar las capacidades de los desarrolladores que usen Groovy para sus aplicaciones.
Actualizando aplicaciones empresariales en Java desde Java 8 on premise hasta...Víctor Leonel Orozco López
Estos slides corresponden a la charla "Desde Java 8 on premise para Java 11 en la nube, hasta Java 14 en el infinito" en la cual exploramos cuales son las limitantes y caracteristicas técnicas que un proyecto debe considerar al momento de actualizar versiones de Java, especialmente desde Java 8 hasta Java 11.
La charla fue parte del Oracle #GroundBreakersTour 2020
En estas charla pongo un poco de orden en el mundo de Jenkins Pipeline, la nueva sintaxis para definir jobs en Jenkins. Hablaremos de las bases y progresaremos hasta llegar a las cosas más chulas que Pipeline nos proporciona.
Charla para la #PEUMConf2018.
Introducción a docker, cómo hemos evolucionado los entornos de desarrollo, desde la instalación de soluciones manualmente, uso de servidores, vagrant...
Realización de una demo práctica usando docker-compose para montar un entorno de desarrollo de algo tipo Php, Wordpress, Node...
En esta charla se discuten los distintos abordajes para lograr tolerancia a fallas en sistemas distribuidos y microservicios, especialmente con microservice chassis y service mesh.
Posteriormente se comentan algunas opciones para su implementación utilizando MicroProfile Fault Tolerance y Linkerd
En esta presentación se presenta una discusión acerca del nuevo glosario del ingeniero de software incluyendo:
- TDD
- DDD
- Cloud Native
- 12 factors
- DevOps
- CQRS
- Event Sourcing
Que significan todos esos términos y como pueden ayudarlos en su jornada cloud.
¿Cómo se despliega y autoescala Couchbase en Cloud? ¡Aprende de manera práctica!Paradigma Digital
En el pasado Meetup, presentamos Couchbase de manera general, pero ha llegado el momento de ir ahondando en los detalles del producto para conocer todas sus capacidades. Esto nos permitirá estar en mejor disposición para adoptarlo en nuestros proyectos.
En esta ocasión, se hablará de la capa de operaciones y despliegue de Couchbase aunque no con un enfoque tradicional en máquinas físicas, sino siguiendo las buenas prácticas del mercado. Explicaremos y haremos el despliegue en Google Cloud con escalabilidad horizontal elástica y automática.
Para llevar a cabo esto haremos uso, entre otras, de las siguientes tecnologías: Google Cloud, Kubernetes, Python y, por supuesto, Couchbase.
Pondremos a prueba nuestra infraestructura con una pequeña aplicación, si queréis ver los resultados, no os lo podéis perder!
Podemos construir entornos sencillos y complejos, de manera muy fácil y que se pueden ejecutar en cualquier máquina sin importar el sistema operativo que esta utilice.
Groovy es un lenguaje alternativo para la JVM, al ser un lenguaje dinámico, permite que usemos conceptos como metaprogramación; característica que sirve como base para manipular el código en tiempo de ejecución.
Groovy extiende las librerías estándar de Java con una colección de clases que son implementadas con metaprogramación para facilitar el uso de diversos APIs. Esta colección se llama GDK, mostraremos los diversos usos que tiene y como ayudan al desarrollador.
Para finalizar veremos como participar en manipulación del byte-code que genera el compilador de Groovy con simples anotaciones de Java. Mostrare las anotaciones que Groovy provee y como podemos implementar las propias.
Estas caracteristicas del lenguaje; forman una triada que permiten potenciar y elevar las capacidades de los desarrolladores que usen Groovy para sus aplicaciones.
Actualizando aplicaciones empresariales en Java desde Java 8 on premise hasta...Víctor Leonel Orozco López
Estos slides corresponden a la charla "Desde Java 8 on premise para Java 11 en la nube, hasta Java 14 en el infinito" en la cual exploramos cuales son las limitantes y caracteristicas técnicas que un proyecto debe considerar al momento de actualizar versiones de Java, especialmente desde Java 8 hasta Java 11.
La charla fue parte del Oracle #GroundBreakersTour 2020
En estas charla pongo un poco de orden en el mundo de Jenkins Pipeline, la nueva sintaxis para definir jobs en Jenkins. Hablaremos de las bases y progresaremos hasta llegar a las cosas más chulas que Pipeline nos proporciona.
Charla para la #PEUMConf2018.
Introducción a docker, cómo hemos evolucionado los entornos de desarrollo, desde la instalación de soluciones manualmente, uso de servidores, vagrant...
Realización de una demo práctica usando docker-compose para montar un entorno de desarrollo de algo tipo Php, Wordpress, Node...
Docker: la revolución en virtualizaciónMarcelo Ochoa
Durante el último año la evolución de proyectos como LXC concluyo en el mundialmente reconocido proyecto Docker, un sistema de virtualización open source ultra delgado que permite optimizar por medio de la automatización vía scripts la provisión de ambientes para desarrollo, test y producción.
Entre las principales ventajas de este ambiente de virtualización podemos encontrar:
– Nativo en Linux, sin requerimientos de virtualización hardware, cero impacto en la performance
– Definición/Creación del entorno vía scripts
– Ultra liviano, se pueden correr hasta 2048 maquinas virtuales con un servidor Web en un simple micro-computador Raspberry PI
– Disponible en otras plataformas como Windows/Solaris
Introduction to Docker. A brief description about Docker: architecture, what is Docker for, how do I start using Docker, what I need, docker ecosystem...
It was exposed in first meetup Cloud Computer Meetup Spain (http://www.meetup.com/Cloud-Computing-Spain/)
Linux Containers (LXC) es un sistema de virtualización con Software Libre nativo en GNU/Linux, que habilita aislar procesos y recursos sin la necesidad de correr software de interpretación y emulación, ni las complejidades de otros sistemas de virtualización.
3Redu: Responsabilidad, Resiliencia y Respetocdraco
¡Hola! Somos 3Redu, conformados por Juan Camilo y Cristian. Entendemos las dificultades que enfrentan muchos estudiantes al tratar de comprender conceptos matemáticos. Nuestro objetivo es brindar una solución inclusiva y accesible para todos.
Índice del libro "Big Data: Tecnologías para arquitecturas Data-Centric" de 0...Telefónica
Índice del libro "Big Data: Tecnologías para arquitecturas Data-Centric" de 0xWord escrito por Ibón Reinoso ( https://mypublicinbox.com/IBhone ) con Prólogo de Chema Alonso ( https://mypublicinbox.com/ChemaAlonso ). Puedes comprarlo aquí: https://0xword.com/es/libros/233-big-data-tecnologias-para-arquitecturas-data-centric.html
Inteligencia Artificial y Ciberseguridad.pdfEmilio Casbas
Recopilación de los puntos más interesantes de diversas presentaciones, desde los visionarios conceptos de Alan Turing, pasando por la paradoja de Hans Moravec y la descripcion de Singularidad de Max Tegmark, hasta los innovadores avances de ChatGPT, y de cómo la IA está transformando la seguridad digital y protegiendo nuestras vidas.
(PROYECTO) Límites entre el Arte, los Medios de Comunicación y la Informáticavazquezgarciajesusma
En este proyecto de investigación nos adentraremos en el fascinante mundo de la intersección entre el arte y los medios de comunicación en el campo de la informática.
La rápida evolución de la tecnología ha llevado a una fusión cada vez más estrecha entre el arte y los medios digitales, generando nuevas formas de expresión y comunicación.
Continuando con el desarrollo de nuestro proyecto haremos uso del método inductivo porque organizamos nuestra investigación a la particular a lo general. El diseño metodológico del trabajo es no experimental y transversal ya que no existe manipulación deliberada de las variables ni de la situación, si no que se observa los fundamental y como se dan en su contestó natural para después analizarlos.
El diseño es transversal porque los datos se recolectan en un solo momento y su propósito es describir variables y analizar su interrelación, solo se desea saber la incidencia y el valor de uno o más variables, el diseño será descriptivo porque se requiere establecer relación entre dos o más de estás.
Mediante una encuesta recopilamos la información de este proyecto los alumnos tengan conocimiento de la evolución del arte y los medios de comunicación en la información y su importancia para la institución.
Actualmente, y debido al desarrollo tecnológico de campos como la informática y la electrónica, la mayoría de las bases de datos están en formato digital, siendo este un componente electrónico, por tanto se ha desarrollado y se ofrece un amplio rango de soluciones al problema del almacenamiento de datos.
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.
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.
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.
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.
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
●
…
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.
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.
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
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
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.