Docker + Kubernetes + OpenShift

¿Qué son los microservicios?

● Microservicios son servicios de grano fino
● Servicio entendido como funcionalidad accesible por Internet
○ No como “Web Service” estilo SOAP
○ Pero sí relacionado con Web Services estilo REST
● No está estandarizado
○ El cloud microservicio puede ser también el aprovisionamiento de recursos
Microservicios en la práctica
● AWS llama microservicios a su infraestructura cloud
Microservicios en la práctica
● En AWS puedes montar un [Link] con todo eso (???)
Microservicios en la práctica
● En ciertos lugares un microservicio debe ser REST
● Es posible componer los microservicios en un “API Gateway”
● El siguiente diagrama es de Microsoft Azure pero aplica a cualquier vendor
de cloud
 Microservicios en este curso
● Este curso es de docker y kubernetes
● Nos centraremos en servicios de aprovisionamiento
● Realmente Docker no es para montar microservicios, sino para contener
nuestros servicios y moverlos más agilmente
● Docker es una solución de “contenerizacion” o containerization
○ Se suele decir que es un “gestor de contenedores”

De donde venimos y el porque de contenedores + microservicios: [Link]

Aclarar terminos
● Docker como tecnologia: Contenedores y volúmenes
○ Composer: Organizar en ficheros YAML
○ Swarm: Multihost
○ Cloud: Pagar por recursos en cloud a Docker INC
● Kubernetes es de Google
● ¿Docker como empresa?
○ Mirantis quizas lo arregle
○ Pero da igual como con Java y Oracle
¿Dónde está el dinero de los contenedores?
● En plataformas cloud rentables
○ AWS
○ Azure
○ … y el resto muy por detrás
● En appliances on-site de vendors tradicionales
○ Oracle Cloud appliance
○ VendorX API Gateway
○ VendorY On-premises Cloud
○ ...
Introducción a Docker
● Lanzado en 2013
● Escrito en lenguaje Go
● Ideado para poder portar contenedores ligeros
○ El programador se centra en su IDE + BBDD de desarrollo
○ El administrador se preocupa de su cluster de servidores y backups
● Muy usado para portar aplicaciones entre entornos y hacer diferentes
operaciones típicas de desarrollo de proyectos
● Proporciona un contenedor para procesos (y su memoria compartida)
aislados del SSOO que contiene Docker y aislado también de otros procesos
○ Sin embargo tiene importantes diferencias con respecto a las máquinas virtuales
Containers vs. VMs
● Docker no es un hypervisor
● Un contenedor no es una máquina virtual
Docker Engine
● Es el soporte fundamental de Docker
● Estaba originalmente basado en LCX (sandboxing tradicional de Linux) y
después en libContainer... extendiendo su potencial
○ [Link] (LCX)
● Está más orientado al despliegue de aplicaciones que de máquinas
¿Que aporta con respecto a libContainer?
Piensa en las situaciones típicas del programador
[...] let's say you have thousands of tests that need to connect to a database,
and each test needs a pristine copy of the database and will make changes to
the data. The classic approach to this is to reset the database after every test
either with custom code or with tools like Flyway - this can be very
time-consuming and means that tests must be run serially. However, with
Docker you could create an image of your database and run up one instance
per test, and then run all the tests in parallel since you know they will all be
running against the same snapshot of the database. Since the tests are
running in parallel and in Docker containers they could run all on the same
box at the same time and should finish much faster. Try doing that with a full
VM.

[Link]
Versiones de Docker
Docker en Windows versus Docker con Windows
● Existe confusión sobre el uso de Windows y Docker, resumiendo:
○ Docker en producción se pone por norma general en Linux
○ Docker para demos, desarrollo y cursos lo puedes poner en Windows a dia de hoy
○ Si solo tienes contenedores Windows, es razonable usar Host Windows
● La aparicion de Windows Subsystem for Linux, ¿cambio esto?
○ Con la versión 1 la opinión general fue que no
○ Con la versión 2 en algunos sitios se comenta que sí
○ Hay que estar atento a la evolución en los próximos 2 años

1. [Link]
or-windows-and-docker-on-windows
2. [Link]
3. [Link]
Funcionamiento básico de Docker
● Docker funciona como
un demonio (también
llamado servidor)
● Expone una interfaz
REST
● Y tiene su propio cliente
Funcionamiento básico
● Cada contenedor es una combinación de librerías
○ Contenedor 1: Hello-World (como un mini-linux)
○ Contenedor 2: Ubuntu
○ ...
○ Contenedor n: Ubuntu + Apache + MySQL

docker --version
docker info
docker run hello-world
docker images
docker run -it ubuntu bash
Arquitectura Docker
Imágenes
● Una imagen es una plantilla de solo lectura usada para crear contenedores
Imágenes
● Podemos listar versiones diferentes de las imágenes que tenemos
disponibles en los repositorios a los que estemos conectados
Imágenes
● Las imágenes se apoyan unas en otras (capas de imágenes)
Comandos sobre imágenes
● images: Lista todas las imágenes locales
● run: Crear un contenedor desde una imagen y ejecutar una orden en él
● tag: Etiquetar una imagen
● pull: Descargar una imagen de un repositorio
● rmi: Borrar una imagen local
Contenedores
● Un contenedor es una instancia de una imagen
● Los contenedores que creamos en Docker TAMBIÉN funcionan en el SSOO
(no ‘sobre Docker’ como si fuera una VM).
● Nota: VMWare obviamente ya tiene soluciones con Docker

[...] This means containers make more efficient use of system

resources than virtual machines. The latter generally require memory
and storage space to be assigned to them before they start. Even if
the apps running inside a virtual machine are not actually using all of
the resources assigned to it, the virtual machine still monopolizes
those resources. That’s not efficient. [...]

[Link]
Comandos sobre contenedores
● ps: Listar todos los contenedores en ejecución
● ps –a: Listar contenedores (incluyendo los detenidos)
● top: Muestra procesos de un contenedor
● start: Arrancar un contenedor parado
● stop: Parar un contenedor
● pause: Pausar todos los procesos de un contenedor
● rm: Borrar un contenedor
● commit: Crear una imagen desde un contenedor
Algunos parametros y caracteristicas
● Detached / -d: El proceso docker lanzado se “separa” del terminal y nos
devuelve el prompt
● -p / -P: Suele referirse a port en el que el contenedor escuchará con algún
servicio (HTTP habitualmente)
Instalación en Windows
● Docker for Windows es una versión más pensada para “usuario final” de
Docker
● Es muy fácil de usar
Instalación en Windows
● Es una aplicación con muchas dependencias sobre librerías de sandboxing
que no están disponible en todos los Windows
○ 10 Pro no es típico de ordenadores personales
 Instalación en Windows
● Los comandos básicos son
parecidos a los de Windows
● La instalacion actualmente
(2020) tiene una dependencia
sobre WSL2 Linux Kernel
● Una vez funcione podemos
usar el powershell para ejecutar
comandos docker

[Link]

[Link]
Registros de Docker
● Un registro de Docker almacena
imágenes
● Docker Hub y Docker Cloud son
registros públicos que
cualquiera puede usar, y Docker
está configurado para buscar
imágenes en Docker Hub por
defecto
● Docker Hub es la base, Cloud
tiene más funcionalidades
Registros de Docker
● Puedes crear tu propio registro
● Antes de buscar imágenes en el registro, se buscan localmente
● Puedes crear tus propias imágenes con un fichero llamado Dockerfile
● Es como hacer un “make” pero añadiendo imágenes preexistentes y encima
lo que tu quieras
○ Comandos
○ Metadatos
○ Más imágenes
Comandos de Dockerfile
● From: De qué imagen viene (scratch para “nada”)
● Maintainer: Quien ha generado la imagen
(metadatos)
● Run: Ejecutar
● Add: Añadir
● Env: Configurar entorno
● Expose: Abrir puerto
● EntryPoint / CMD: Habitualmente abrir un prompt

FROM ubuntu:15.04
COPY . /app
RUN make /app
CMD python /app/[Link]
Ejemplo complejo de Dockerfile
$ docker build -t svendowideit/ambassador .
Sending build context to Docker daemon 15.36 kB
Step 1/4 : FROM alpine:3.2
---> 31f630c65071
Step 2/4 : MAINTAINER SvenDowideit@[Link]
---> Using cache
---> 2a1c91448f5f
Step 3/4 : RUN apk update && apk add socat && rm -r /var/cache/
---> Using cache
---> 21ed6e7fbb73
Step 4/4 : CMD env | grep _TCP= | (sed
's/.*_PORT_\([0-9]*\)_TCP=tcp:\/\/\(.*\):\(.*\)/socat -t 100000000
TCP4-LISTEN:\1,fork,reuseaddr TCP4:\2:\3 \&/' && echo wait) | sh
---> Using cache
---> 7ea8aef582cc
Successfully built 7ea8aef582cc
Volumen
● Es un directorio en disco o un espacio “más o menos permanente” (según la
versión de Docker usada) en otro contenedor
○ Hay “ephemeral volumes” por ejemplo
● Por ejemplo
○ En Docker el almacenamiento se pierde al eliminar de ejecutar el contenedor
○ Kubernetes introdujo el concepto de Pod para gestionar la persistencia de los volúmenes con
respecto a los contenedores
3 formas de montar volumenes
● Volumenes
● bind mount
● tmpfs mount
Volumen versus bind mount
● Cuando usas un bind mount, un archivo o directorio en la máquina host se
monta en un contenedor
● Se hace referencia al archivo o directorio por su ruta absoluta en la máquina
host
● Cuando usa un volumen, se crea un nuevo directorio dentro del directorio de
almacenamiento de Docker en la máquina host, y Docker administra el
contenido de ese directorio
● Por varios motivos los volúmenes son mejores que el bind mount
○ [Link]
Volumen versus mount tmpfs
● A diferencia de los volúmenes y los montajes de enlace, un montaje tmpfs es
temporal y solo persiste en la memoria del host
● Cuando el contenedor se detiene, el montaje tmpfs se elimina y los archivos
escritos allí no se conservarán
● No se puede compartir tmpfs mounts entre contenedores
Gestión de Docker
● Docker es potente pero no se mete mucho en la gestión de la configuración,
ni el delivery, ni la automatización de despliegue ni la orquestación
○ Son cosas diferentes aunque muy solapadas en la práctica
● Existen muchas soluciones dependiendo de qué visión de la metodología
tenemos
○ Kubernetes: Gestión de la configuración
○ Swarm: Gestión de clusters
○ Mesos: Asignación y monitorización de recursos en grandes topologías
● Y existen muchas soluciones con un enfoque más de facilidad de uso y
mundo corporativo como OpenShift → Minishift
 ¡Buena
suert
la refere e con
Docker Compose técnica ncia
de esto
!

● Es el conjunto de librerías originales de

Docker para agrupar elementos de
configuración de Docker
○ Principalmente contenedores y volúmenes
● Usa notación YAML/DSL
● El services es el elemento fundamental
○ Suele referenciar una imagen
Docker Compose
● Por defecto Compose crea una red para cada app
● En el caso de la derecha (si el directorio es myapp)
○ Se crea una red myapp_default
○ Ambos contenedores se usen a esa red
● Atención a los puertos
○ HOST_PORT: 8001
○ CONTAINER_PORT: 5432 (el típico de postgres)
Docker Compose
● Se pueden crear redes a medida
● En el caso de la derecha hay dos redes
○ La app hace de puente
● Se pueden asignar IPs estáticas también
○ [Link]
Docker Compose
● El build especifica que
hay un dockerfile para
procesar
● Para procesar un
compose usamos up
● Posteriormente podemos
usar up, start o run

[Link]
Docker Compose
● Desde la 1.12 de Docker existe el subcomando stack que permite lanzar un
yaml desde el engine sin instalar compose aparte
● Docker stack no crea imágenes y ignora algunas cosas del YAML
● ¿Cual es la lógica de esto?

Más info
Docker Compose scale
● En versiones anteriores había un comando docker-compose scale
● Actualmente se hace con el parámetro scale en el yml o en
docker-compose up
Docker Compose remote ops
● Usando el subcomando context se pueden desplegar contenedores en
Docker Engines remotos
● No es complejo, internamente se hace un ssh sobre el host destino

[Link]
Docker Compose remote ops
● Podemos crear varios contextos y trabajar con uno o con otro usando el
comando docker context use
De Compose a Kubernetes
● Suele haber confusión al principio entre un yaml de Docker Compose y una
configuración Kubernetes
● kompose convert ayuda con eso
○ [Link]
Kubernetes
● Es una forma de organizar tus contenedores en entornos grandes
● Pods:
○ Tienen contenedores Docker had hoped to make
○ Tienen IPs container orchestration, with Docker
○ Tienen Volumenes Swarm, its profit center,[...] Then
along came Kubernetes, and that
was the end of that. Kubernetes
has become the container
orchestration of choice, leaving little
room for others. And, indeed,
Docker has adopted Kubernetes as
well.
Steven J. Vaughan-Nichols
Kubernetes
● El modelo "un contenedor por pod" es el caso de uso de Kubernetes más
común
● Los contenedores de un pod se ubican y programan automáticamente en la
misma máquina física o virtual del clúster
● El término cluster se usa de forma general, es “nuestro objetivo de
infraestructura”, “que deseamos tener montado”
● En kubernetes desplegamos “workload”, que puede ser
○ Pods
○ Controllers
Workload en kubernetes

Pods Controllers
Nuestros contenedores, Deployments (estado deseado de nuestra instalación)
volúmenes y ReplicaSet (como conseguir ese estado con copias)
configuraciones StatefulSets (garantiza unicidad de lo que creamos)
DaemonSet (mantiene la topología a largo plazo)
Jobs
Garbage Collection
TTL Controller for Finished Resources
CronJob
ReplicationController
Kubernetes
● Node: Máquina que
estás usando
● El kubelet es el "agente
de nodo" principal que
se ejecuta en cada nodo
○ Puede registrar el nodo
con el ApiServer usando
el nombre de host
Kubernetes
● Un Pod siempre se ejecuta
en un Node
● Un nodo es una máquina
de trabajo en Kubernetes y
puede ser una máquina
virtual o física, según el
clúster
● Cada nodo es
administrado por el master
Kubernetes
● Replication Controllers: Gestor de Pods
que asegura que están levantadas las
réplicas y permite escalar de forma fácil
● Service: Define como acceder a un grupo
de Pods

[Link]
/
Kubernetes
● A menudo task y job se
refieren a lo mismo
● Un Job crea uno o mas pods
○ El pod es la definición del
servicio
○ El Job es la configuración de su
ejecución
● Un Job necesita
○ apiVersion,
○ kind, y
○ metadata fields

[Link]
Kubernetes
Kubectl es el comando para lanzar tareas en kubernates

apiVersion: batch/v1 kubectl apply -f [Link]

kind: Job
metadata:
name: pi
spec:
template:
spec:
containers:
- name: pi
image: perl
command: ["perl",
"-Mbignum=bpi", "-wle", "print
bpi(2000)"]
restartPolicy: Never
backoffLimit: 4
 Kubernetes

[Link]
Más conceptos de Kubernetes
● Nodeports: Puertos donde escuchan nuestros servicios
● ConfigMaps: Objetos de la API usados para almacenar KV pairs sin
seguridad
● Secrets: Almacenan información que precisa de seguridad (credenciales,
tokens OAuth y similar)
● ReplicaSet: Garantiza que un número de pods corren en un momento
concreto
● Selector: Es la forma de agrupar elementos en kubernetes, label y selector no
son lo mismo
● Ingress: Objeto de la API que proporciona acceso a servicios
Conceptos en escenario práctico
● Analizar, comentar y diagramar el siguiente caso práctico con Kubernetes

[Link]
Minikube
● Minikube permite arrancar kubernetes en local
○ [Link]
● Es parecido a docker for desktop
○ [Link]
● Minikube incorpora soporte para
○ DNS
○ NodePorts
○ ConfigMaps and Secrets
○ Dashboards (GUI web para estadisticas)
○ Container Runtime: Docker, CRI-O, and containerd
○ Enabling CNI (Container Network Interface)
○ Ingress
Escalado con Kubernetes
● Kubernetes permite escalar los pods facilmente
Escalado con Kubernetes
Escalado con Kubernetes
● El reescalado se aplica
automáticamente al
retirar pods
● Completar ejemplo
○ [Link]
cs/tutorials/kubernetes-
basics/scale/scale-inter
active/
Autoescalado horizontal
● La configuración de escalado se puede
asociar a métricas
● Behavior: Trigger que captura eventos y
actúa en consecuencia
● Stabilization: Periodo de tiempo en el que
se observan las métricas antes de actuar
● Period: Periodo de tiempo antes de
“seguir actuando” ante métricas
● Policies: Posibles decisiones a evaluar
Autoescalado horizontal
For scaling down the stabilization window is 300 seconds [...].
There is only a single policy for scaling down which allows a
100% of the currently running replicas to be removed which
means the scaling target can be scaled down to the minimum
allowed replicas. For scaling up there is no stabilization
window. When the metrics indicate that the target should be
scaled up the target is scaled up immediately. There are 2
policies where 4 pods or a 100% of the currently running
replicas will be added every 15 seconds till the HPA
(Horizontal Pod Autoscaler) reaches its steady state.

Policy Max: Selecciona la política que

cause el máximo cambio en pods
Autoescalado horizontal
● Ejemplo completo:
○ [Link]
Persistencia en Kubernetes
● Los volúmenes en
Kubernetes tienen más
configuración que en
Docker
○ tienen un “lifetime” específico
● La especificación de
volumen es lo
suficientemente amplia
como para que existan
decenas de
implementaciones
Volumenes en Kubernetes
● Todos los servicios de cloud tienen
implementaciones de volumen
● También se puede usar un SSOO
local sin soporte de vendors
específicos
● Se pueden definir StorageClass para
crear nuevas implementaciones de
volumen
Volumenes en Kubernetes
● La parametrización cambia bastante entre tipos de contenedor
● El resultado siempre es el mismo, una conexión entre contenedores y
volumen, técnicamente llamado un “claim”
PersistentVolume
● Un PersistentVolume (PV)
es un espacio de
almacenamiento en el
clúster que ha sido
aprovisionado
estáticamente (por un
administrador) o
dinámicamente
PersistentVolume
● Un PersistentVolumeClaim (PVC) es una solicitud de almacenamiento por
parte de un usuario
● Es similar a un Pod.
○ Los pods consumen recursos del nodo y los PVC consumen recursos de disco.
○ Los pods pueden solicitar niveles específicos de recursos (CPU y memoria).
○ Los claims solicitan tamaños y modos de acceso específicos
■ ReadWriteOnce,
■ ReadOnlyMany o
■ ReadWriteMany
■ ...
Secrets
● Almacenan información segura
● Deben ser de tamaño limitado
● Se pueden usar para 3 cosas
○ Como archivos en un volumen montado en uno o más de sus contenedores.
○ Como variable de entorno de contenedor
○ Por el kubelet al extraer imágenes para el Pod
Secrets como ejemplo de info proyectada
● En kubernetes se
usa la expresión
“projected” para
referirse a datos que
son “empujados” de
un contenedor a otro
o de un pod a un
contenedor
● Habitualmente son
empujados al
cambiar
Secrets + inf. proyectada
● En este ejemplo proyectamos secretos
al volumen “all-in-one”
● Los datos “projected” son en el fondo
copias de datos que deben ser
actualizados cuando el volumen
original cambia
Secrets + inf. proyectada
Basicamente When a secret currently consumed in a volume is updated,
Kubernetes > Docker projected keys are eventually updated as well. The kubelet checks
whether the mounted secret is fresh on every periodic sync.
However, the kubelet uses its local cache for getting the current
value of the Secret. The type of the cache is configurable using the
ConfigMapAndSecretChangeDetectionStrategy field in the
KubeletConfiguration struct. A Secret can be either propagated by
watch (default), ttl-based, or simply redirecting all requests directly
to the API server. As a result, the total delay from the moment
when the Secret is updated to the moment when new keys are
projected to the Pod can be as long as the kubelet sync period +
cache propagation delay, where the cache propagation delay
depends on the chosen cache type (it equals to watch propagation
delay, ttl of cache, or zero correspondingly).
Ingress
● Ingress es el nombre bajo el que se definen las reglas de entrada para redes
● El ingress Controller es el elemento central, al igual que con los volúmenes
existen numerosas implementaciones (cloud principalmente)
● Vamos a ver un ejemplo
Ingress versus otras configuraciones
● ClusterIP: IP dentro del cluster balanceada entre pods del servicio
● NodePort: Exponer un puerto (bastante limitado)
Dependencias entre servicios
● Es habitual tener la necesidad de arrancar
contenedores dependientes de otros
○ Caso típico: BBDD antes que un servidor de
aplicaciones
● Los initcontainers permiten especificar este
tipo de dependencias
○ [Link]
init-containers/
Helm
● Gestor de paquetes para
kubernetes
● Tiene sus propios ficheros
de configuración llamados
charts
● Proporciona un potente
sistema de dependencias
Helm
● Ejemplos de dependencias
● Se pueden pasar valores de
propiedades de una chart hija a una
padre
Cert-manager
● Gestor automático de certificados TLS
Docker Swarm
● El orquestador aportado por Docker
○ Competidor de Kubernete
● El elemento central es un manager node o un grupo de ellos
● Al conjunto de engines que da un mismo servicio se le llama Cluster
Docker Swarm
● Se pueden añadir nuevos nodos a un cluster de swarm
● El Manager node es el que se encarga de mantener la sanidad del cluster
○ Manteniendo el número de las réplicas por ejemplo
● Se usa el algoritmo raft para decidir quién será el líder y mantener la salud
del cluster

$ docker swarm join \

--token SWMTKN-1-49nj1cmql0jkz5s954yi…
[Link]:2377
Swarm + Compose
Múltiples managers y workers con estado distribuido
Nodos del cluster
● Docker node ls devuelve el estado de los nodos disponibles en un
managed node
● El leader es el nodo que toma decisiones en el cluster de swarm
○ Reachable indica que eso nodo podría ser un líder. Vacío indica que es un worker
○ El estado drain indicaría que se están liberando los recursos de dicho nodo
Escalar un servicio
● Las operaciones sobre servicios se hacen con docker service
● El siguiente comando arranca en modo Swarm

● Si añadimos nuevos nodos al swarm, correrán los servicios de ese swarm

Borrar un servicio
● Docker service rm borra un servicio del swarm
● Esto no afecta la salud del manager o del swarm
○ El servicio se retira del swarm
Docker registry
● Servicio de directorio para publicación de imágenes
● El registro es en sí mismo una imagen que arrancamos

● Bajamos una imagen y la subimos a nuestro registro

docker pull ubuntu:16.04

docker tag ubuntu:16.04 localhost:5000/my-ubuntu
docker push localhost:5000/my-ubuntu
docker image remove ubuntu:16.04
docker image remove localhost:5000/my-ubuntu (borra copia local)
docker pull localhost:5000/my-ubuntu
Docker registry
● La ubicación del registry se especifica con un YAML

● Algunas propiedades se pueden modificar al ejecutar el contenedor

OpenShift
● OpenShift es una solución que
se apoya en Kubernetes para
proporcionar una
contenerización “simplificada”
● Realmente es una cuestión de
¿con quien quieres casarte en
tus soluciones de SW?
Competidores de OpenShift
● AWS ECS y AWS EKS
● Azure Container Instances (ACI) y Azure AKS
● Google Kubernetes Engine (GKE)
○ Tiene contenedores sueltos pero su esfuerzo comercial es sobre Kubernetes porque es su
producto
● IBM compró RedHat porque su cloud no funcionaba
○ Su apuesta es OpenShift como solución cross-cloud y portable
○ Tiene su propio hosting
○ Similitudes con la apuesta de Java en 1992
OpenShift
OpenShift como independizador de cloud
OpenShift
● Usar o no openshift es una
decisión de con quien
quieres estar cohesionado y
con quien acoplado
● Podrías argumentar que la
integración linux → cloud la
hará mejor RedHat que
ningún cloud [1]
OpenShift
● El “término paraguas”/marca que incluye la gama de productos de
contenedores de OpenShift es el “OpenShift Container Platform Architecture”
● Puede provisionarse en cloud o on-premises
● Admite cloud hibrido y cross-cloud
○ Su punto fuerte se puede argumentar que es el cross-cloud

$ ./openshift-install create cluster --dir=<installation_directory> \

--log-level=info

... select cloud provider...

OpenShift
● Openshift aporta diferentes utilidades que
○ Actúan de wrapper sobre clouds existentes
○ Proporcionan métricas adicionales a las proporcionadas por Kubernetes
○ Permiten operaciones administrativas de migración entre clouds
Soporte para OpenShift en cloud
Soporte hybrid-cloud
Topologia Openshift
● Control plane es el
conjunto de nodos
dedicados a controlar los
workers
OpenShift CLI
● El cliente de openshift da acceso a las librerías de Openshift y a los puentes
de integración con clientes de cloud y de docker
○ oc <command>
● Está disponible para Windows pero el setup es un poco complejo
○ [Link]
Comandos Openshift
● Hacer login
○ oc login -u user1
● Crear un proyecto
○ oc new-project <projectname>
● Crear una aplicación
○ oc new-app [Link]
● Revisar los logs de la construcción anterior
○ oc logs -f bc/ruby-ex
● Comprobar la creación de la imagen
○ oc status

[Link]
OpenShift template catalog
● Configuraciones
predefinidas de OpenShift
que podemos usar en
nuestros proyectos
Análisis de vulnerabilidades
● La gestión de vulnerabilidades es un aspecto importante en contenedores
○ Igual que en VMs, no estamos hablando de bugs de la contenedorización sino de los
productos que usamos en ella
● La lista de Common Vulnerabilities and Exposures (CVE) es una de las
principales fuentes de bugs identificables
○ Al analizar en docker ficheros se usan BBDD de síntomas de CVE y fuentes similares
● Se suele hablar de “vulnerabilidades de productos” y “debilidades en general”
○ [Link] y [Link]
Docker
● Docker usa Snyk
por defecto para
análisis de
vulnerabilidades
○ [Link]
com/engine/scan/
● Snyk tiene su
propia BBDD de
vulnerabilidades
(estilo CVE)
○ [Link]
Docker Hub
● El análisis con Snyk
también se puede
hacer en Docker
Hub con GUI sí
tienes modelos de
subscripción que lo
soporten
○ [Link]
om/docker-hub/vulne
rability-scanning/
Clair
● Clair es un proyecto Open Source mantenido por Red Hat similar a Snyk
● En Openshift al motor de análisis de vulnerabilidades se le llama Container
Security Operator y usa Clair internamente
○ Un Operator en Openshift es un tipo de Pod
○ Basicamente usamos contenedores para testear contenedores
Muchas gracias