@wjma90
DevOps
Monitoreo de Contenedores Docker
Ver Contenedores
Ver Características
con -a se visualiza todos los
Ver información como IP,
containers (detenidos y en
volumen, driver logs, etc
ejecución)
docker ps -a docker top [container] docker inspect [container] docker stats [container]
Ver PID - UID Ver Consumo
Ver el identificador del Cuánto consumo de CPU,
proceso memoria, límites, disco IO
Monitoreo de Contenedores Docker
$ docker container run -d nginx
f050ac5534f7ad9f19d9db7de41fc5d13aab39964bd83704c9d35b9bed079dfc
$ docker container run -d -e MYSQL_RANDOM_ROOT_PASSWORD=true mysql
94896b5c9d6f2a1e49c1e7c8a873fdb6e8ed8aa9c1a87fce0c4aa258b580eddc
1 $ docker container ps -a
2 $ docker container inspect 948
3 $ docker container stats 948
Shell en un Container y publicando puertos
-it hace que sea interactivo y emula una shell interna
del contenedor
$ docker run -p 80:80 -it --name proxy nginx bash
root@e635ccd51489:/# exit
$ docker container ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS
NAMES
9b3ae83870dd nginx "bash" 9 minutes ago Exited (0) 4 seconds ago
proxy
$ docker run -d -p 80:80 --name proxy2 nginx cambiar el comando de inicio hace que no se lance el
script de inicio por defecto, tener cuidado!!
cab07715cc8604460e00fa3147ca8f1d4cf22eaeb3740e38b77d5cec9059a4d8
$ docker stop proxy2
CONTAINER ID IMAGE COMMAND CREATED STATUS
PORTS NAMES
cab07715cc86 nginx "nginx -g 'daemon of…" 4 minutes ago Exited (0) 4 seconds ago
Imágenes
Docker
¿Cómo se crea una imagen?
Entendiendo nuestro Dockerfile
FROM ENV COPY CMD
Construyendo nuestra imagen | TAG’s
Básicamente se trata de extender imágenes para agregarles las funcionalidades que necesitamos, por ejemplo queremos usar un api
restful spring boot dentro de un contenedor docker base que tenga java 8. La sintaxis de construcción de una imagen es:
DOCKER BUILD --TAG [IMAGEN_NAME] [CONTEXTO]
ejemplo: docker build -t wjma90/apirestdemo .
$ cd PATH-DOCKERFILE
$ docker build -t wjma90/demodb:1.0.0 .
$ docker run -d -p 3333:3306 --name mysql_server wjma90/demobd:1.0.0
$ mvn spring-boot:run
-Dspring-boot.run.arguments=--host=localhost,--port=3333,--database=demobd,--username=root,--password=toor
$ curl -X POST -H "Content-Type: application/json" -d '{"nombre":"wjma90", "edad":29, "sexo":"M"}'
http://localhost:8080/api/personas/registrar
$ docker stop mysql_server
$ docker start mysql_server (los datos aún están persistentes porque no se ha dañado / eliminado el container)
Dockerfile un poquito más complejo
Creando
Dockerfiles
Buenas prácticas en Dockerfiles
1 ORDEN DE COMANDOS 4 CONSTRUIR COMPILADOS
EN UN ENTORNO
INMUTABLE
2 USAR COPY vs ADD
5 CACHE A LAS
DEPENDENCIAS
3 USAR IMAGENES OFICIALES
6 MULTISTAGE PARA
DIFERENTES OBJETIVOS O
ENVIRONMENTS
Hay más recomendaciones que se pueden seguir como por
ejemplo: healthchecks, memory_limits, dockerignore, etc, en
resumen, siempre es mejor seguir la documentación oficial. aqui
Enlazando Containers
--link
Enlace entre Containers
$ docker run -d -p 3333:3306 --name mysql_server wjma90/demobd:1.0.0
$ cd PATHDOCKERFILE/api-persona
$ mvn clean package -Dmaven.test.skip=true
$ docker build -t wjma90/apipersonademo:1.0.0 . (verificar que las variables de entorno apunta correctamente a mysql)
$ docker run -d -p 8080:8080 --link mysql_server --name apipersona wjma90/apipersonademo:1.0.0
$ docker logs apipersona
$ curl -X GET http://localhost:8080/api/personas/find/1 && echo " .... terminado "
….
….
….
….
….
….
….
Docker Network
Driver Bridge, Host y None
Docker None hace que el contenedor no tenga salida hacia el
host ni hacia otros containers
Driver Bridge
Por defecto, Docker instala una
interface en nuestro host. El
driver bridge tiene rango de red:
172.17.0.0/16
Explorando el enlace entre containers
$ docker ps -a $(docker ps -aq) (si tienen contenedores, eliminarlos previamente)
$ docker run -d -p 3333:3306 --name mysql_server wjma90/demobd:1.0.0
$ docker run -d -p 8080:8080 --link mysql_server --name apipersona wjma90/apipersonademo:1.0.0
$ docker network ls
$ docker exec -it apipersona sh
root@7d57ccc5:# cat /etc/hosts ¿Qué info muestra?
$ docker network inspect bridge
[{
"Name": "bridge",
"Id": "ffe1a880c250b9d85c3772f9e4171dbe112bfbed3c16bdb7dc9477a21e6570ec",
"Created": "2019-04-01T09:55:45.782870497-05:00",
"Scope": "local",
""Driver": "bridge",
"EnableIPv6": false,
"IPAM": {
"Driver": "default",
"Options": null,
"Config": [
{
"Subnet": "172.17.0.0/16",
"Gateway": "172.17.0.1"
}
]
Docker
Compose
¿Qué es Docker Compose?
Es una herramienta que nos permite definir y “correr” múltiples
contenedores. Simplificando la utilización de comandos docker
Estructura básica de un
archivo docker compose
Versión docker compose
Definición de ejecución de un container
Estructura básica de un archivo docker compose
1 4
Version: Indica la versión del archivo docker compose, Ports: Es el equivalente a -p en docker run. Nos permite usar un
dependiendo de ésta, usaremos algunas propiedades permitidas puerto interno del contenedor en un puerto de nuestro host
2 5
Services: Aquí indicaremos las propiedades de los contenedores Environments: Equivalente a -e en docker run. Permite inyectar
que podemos etiquetarlos como db , wp. Imagine que son los variables de entorno al contenedor. Puede sobre-escribir lo
docker run indicado en el dockerfile
3 Image: Indicamos la imagen docker a utilizar, también podemos
utilizar un dockerfile mediante un propiedad más llamada build 6 Volumes: Equivalente a -v en docker run. Nos permite relacionar
una carpeta de nuestra máquina con una interna del contenedor.
1er Docker Compose
version: '3.1'
services:
wordpress:
image: wordpress
restart: always
ports:
- 80
environment:
WORDPRESS_DB_HOST: db
WORDPRESS_DB_USER: exampleuser
WORDPRESS_DB_PASSWORD: examplepass
WORDPRESS_DB_NAME: exampledb
depends_on:
- db
db:
image: mysql:5.7
restart: always
environment:
MYSQL_DATABASE: exampledb
MYSQL_USER: exampleuser
MYSQL_PASSWORD: examplepass
MYSQL_RANDOM_ROOT_PASSWORD: '1'
Comandos Básicos en Docker Compose
$ docker-compose build
$ docker-compose up -d
$ docker-compose ps
$ docker-compose down -v
$ docker-compose up -d wordpress --no-build --no-deps
$ docker-compose stop wordpress
$ docker-compose scale appweb=2, appbackend=3
Diferencia entre versión 2 y 3 de
Compose
A. Fines de desarrollo / Testing A. Fines de desarrollo / Testing & Cluster
Swarm
B. Propiedades soportadas son diferentes
a la versión 3. Ejemplo --memory-limit B. La limitación de recursos es para fines
swarm. No se soporta limites de
recursos en modo “sin enjambre”
C. No es antiguo o desfasado como se
menciona o se pueda entender, la
versión 2.3 salió a la par con la version C. Lo recomienda el mismo Docker ya que
3.4 de docker compose a futuro se integrará limpiamente a
Kubernetes
D. No orientado a SWARM
D. Orientado a SWARM
Tipos de Test
La clave es encontrar el correcto balance entre las
pruebas unitarias, de integración y end to end.
Google recomienda la relación 70/20/10: 70% unit tests, 20%
integration tests, and 10% end-to-end tests. NO es un regla
general
Aunque la recomendación es 70, 20, 10, se evalúa qué tipo de
prueba da más valor para el equipo donde quizá prevalezca la
prueba de integración o la prueba unitaria (cubriendo lógica -
métodos - cuya lógica es crucial en el software)
Beneficios del testing automatizado
Manual Testing Automated Testing
● La prueba manual no es precisa en todo momento ● Las pruebas automatizadas son más confiables, ya
debido a un error humano, por lo que es menos que se realizan mediante herramientas y / o scripts.
confiable.
● Las pruebas automatizadas se ejecutan mediante
● Las pruebas manuales llevan mucho tiempo, herramientas de software, por lo que son
ocupando recursos humanos. significativamente más rápidas que un enfoque
manual.
● La inversión es necesaria para los recursos
humanos. ● Se requiere inversión para probar herramientas.
● La prueba manual solo es práctica cuando los ● La prueba automatizada es una opción práctica
casos de prueba se ejecutan una o dos veces, y no cuando los casos de prueba se ejecutan
se requieren repeticiones frecuentes. repetidamente durante un largo período de tiempo.
● Las pruebas manuales permiten la observación ● Las pruebas automatizadas no implican la
humana, que puede ser más útil si el objetivo es la observación humana y no pueden garantizar la
facilidad de uso o la mejora de la experiencia del facilidad de uso o la experiencia positiva del cliente.
cliente.
¿Dónde estamos en el flujo?
Dev Ops
Plan Code Build Test Release Deploy Operate
Testing Testing de Testing
Unitario Integración End-2-End
selenium
JUNIT
Tests isolated Java components
Allows to verify java component
implementations
- Environment independent
- Third party independent
Integrantes with standard building
tools: maven, gradle, etc..
JACOCO
Java coverage tool
Sonar Integration
- Historical reporting accessible
from Sonarqube
- Cuscom Quality Gates related
with Test coverage
Standard build tools Integration
- Execution using common build
tools like maven, gradle, etc.
- Can be verified locally
https://github.com/jacoco/jacoco
¿Dudas?
devops@mitocodenetwork.com
