Java DevOps 2

Descargar como pdf o txt
Descargar como pdf o txt
Está en la página 1de 30

@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?

[email protected]

También podría gustarte