Básicamente cambió todo el paradigma porque anuló la típica justificación dev: "that's weird, it works on my machine!", que sería "que raro, en mi máquina funciona!".
¿Qué hizo Docker?
Docker supo abstraer, de forma moderna y efectiva, una teconología popularmente desconocida llamada LXC (LinuX Containers), asimismo integrar aderezos tales como una capa de FS reutilizable, una API REST (via HTTP/S), limitación de recursos (cgropus, cosa de google), facilidades sobre la exposición de servicios bindeados en puertos (managea IPtables), la posibilidad de forwardear logs a stacks dedicados (gelf -> ELK) y otras bondades más.
¿Los contenedores son VMs?
No, no lo son. Una VM bootea un kernel, el container no lo hace, utiliza el kernel del host.
Esto significa que el overhead de la máquina virtual queda erradicado, por otro lado si lo que ejecuta ese container genera un kernel panic, se va todo al pasto; cosa que hoy en día con la estabilidad proporcionada por el kernel Linux hace prácticamente algo impensado.
El problema con LXC pelado fue que las librerías que tenían que utilizar estos container si o si tenían que estar instaladas en el host. Por eso Docker implementó una manera de (re)utilizar capas de FS que contienen binarios y librerías necesarios para cada necesidad. Por ejemplo si en Fedora se corre 'docker run -it ubuntu:14:04' tenemos un container que "corre" Ubuntu y allí mismo se puede tirar "apt-get update", sin dejar de ser la distro Fedora.
Recuerden: Linux es un kernel, no un sistema operativo.
El concepto de container es poder abstraer uno o más procesos (lo ideal es uno) en un namespace distinto al de ejecución común. Esto es clave porque puede hacer entender de que un contenedor (container) no es una máquina virtual, si no un proceso ejecutado sobre el kernel pero en un namespace diferente
Quizás esto tenga sentido para los ops que les interesa el rendimiento, aunque es cuestionable en throughtput de red a comparación de una VM en KVM ¡Pero es tranquilo que es hablando de la implementación básica!
Ejemplo práctico
$ cat "<h1>Ejemplo Taringa</h1>" > index.html && docker run -it -p 80:80 -v $PWD/index.html:/usr/share/apache2/htdocs/index.html httpd
Agregar :z despues del html si son users de distros con SELinux
¿Cómo me simplifico la vida siendo dev?
1. Instalá docker (está en los repo oficiales de cualquier distro, y también te proveen uno para versiones nuevas, igual para Win y macOSX)
2. Entendé lo que hace una Dockerfile
3. Generá tu imagen
4. Profit
¿Cómo me simplifico la vida siendo op?
1. Instalá docker
2. Creá un repositorio de imágenes
3. Enforceá que los devs deployeen su aplicación en containers
4. Asegurate que los recursos que accede la aplicación no comprometen la seguridad
5. Proporcioná un medio común para los logs
6. ¡Tomá métricas y monitoreá!
¿Por qué esto es una especie de imposición?
Por las necesidades del mercado... Hoy en día todo apunta a microservicios donde ese choclo de código aborreciente de milllones de líneas se dividió en partes, ej: autenticación, consulta de datos, persistencia en base de datos; todo conectado vía http, en una red donde esos servicios "se hablan". Esto también es bueno para los devs, porque se fraccionan las funcionalidades y pueden distribuir el trabajo de programar.
¿Ves como todo cobra sentido? Y más que nada porque el mercado neesita software de cálidad en poco tiempo y seguro.
La posta la tenés acá:
Versionado y repositorio
Las imágenes de docker manejan un sistema de tags parecido al de git, de hecho una práctica común es tagear la imagen con el id del commit, por ejemplo taringa:e4437a74.
A su vez las imagenes pueden ser alojadas en un repositorio privado o público con el que se interactua vía comandos similares a git: docker pull, docker push, docker tag y docker commit.
El repo público de docker contiene imágenes oficiales de empresas o fundaciones que se involucraron, como por ejemplo Apache httpd, Neo4J, las distro más comunes, entre otras que también son de usuarios que se coparon y subieron una implementación propia de algo.
Persistencia de datos y backup
La idea de esto es que se corran aplicaciones stateless. Si es necesario se puede bindear un dir del sistema operativo base o utilizar un "driver" para volúmenes. Por default los volúmenes de los contenedores usan loop (/dev/loop), cosa que no es muy ajonsecable para prod, existen otros como overlayfs, ZFS, NFS (convoy), S3 (para Amazon) y LVM.
Respecto al backup lo de los volumenes resuelve prácticamente todo.
¿Cómo tienen red y como se exponen los puertos?
Cuando instales docker se autocreará un bridge llamado docker0 con la IP 172.17.0.1 generalmente. Todos los containers van a tener una IP en esa red. Existen "drivers" para red que hacen que los containers se vean entre hosts, cosa muy común en un cluster, ejemplo VXLAN con flannel o IPSEC con rancher.
Se pueden crear y manipular redes on demand con docker network, incluso que el contenedor no corra con el bridge docker0 si no en la misma red que el host.
El bindeo de puertos lo hace iptables.
Security y limitación de recursos
El uso de CPU puede ser limitado (cgroups) al igual que la memoria. Las capacidades de acceso al host pueden ser tuneadas finamente, esto con SELinux (por más que muchos lo odien) garantiza un nivel de seguridad máas que consistente.
Eso si... si por alguna casualidad X container genera un kernel panic les va a planchar el host, recuerden que los containers no son VMs con kernel propio si no procesos en un namespace distinto sobre el mismo kernel.
Si no me equivoco hace relativamente poco se mergeo una rama de código que incluye la posibilidad de que las fork bombs no rompan el host cuando se corren en un container.
¿Donde está la API?
La encontrás en /var/run/docker.sock, si se configura puede ser bindeada a un puerto (generalmente el 2375 para http y 2376 para https).
Clustering
Por defecto docker implementa su modelo de cluster llamado swarm, hay otros proyectos geniales que imponen su propio modelo de cluster e incluso extienden las capacidades de docker, por ej:
- Kubernetes de Google
- Mesos de Apache
- Cattle de Rancher
Necesito una UI
https://github.com/portainer/portainer , es excelente proyecto, acá la demo:
Toda la info de X container la obtenes con docker info nombredelcontainer desde la terminal
Quiero instalar docker en mi distro
o buscala en tus repo, se que en Debian el paquete está como docker.io porque hay un dock que se llama igual.
Windows
Windows Server 2016 implementa docker y la pelotudez de "Windows Containers" que es casi lo mismo... También se puede bajar docker.
Win10 tiene soporte para docker, antiguamente usaba VirtualBox, ahora HyperV y funciona bien.