Descargar como PDF, PPTX
![#netcoreconf
El Pod no inicia
• get pods
• describe pod [pod_id]
• El pod se reinicia
• Entrar en el pod
• Exec –it
• Si no levanta no podemos
• Sobre escribir el comando en el deployment](https://image.slidesharecdn.com/dockerk8sleccionesnetcoreconf2022-221118102414-5aa95b52/75/Docker_K8S_lecciones_netcoreconf_2022-pdf-36-2048.jpg)
Subido porLeonardo Micheloni
Docker_K8S_lecciones_netcoreconf_2022.pdf
Este documento presenta las lecciones aprendidas por un desarrollador sobre el uso de Docker y Kubernetes. Explica que es importante tener conocimientos básicos en diferentes áreas para resolver problemas de forma ágil. También describe algunas técnicas como usar Docker compose para ejecutar servicios dependientes localmente, inspeccionar logs y entrar en contenedores para depurar, y montar configuraciones como volúmenes en Kubernetes. El objetivo es compartir recetas y consejos prácticos basados en la experiencia del autor.
![DevOps+[Chef/Docker]](https://cdn.slidesharecdn.com/ss_thumbnails/presentacion-140627224604-phpapp02-thumbnail.jpg?width=640&height=640&fit=bounds)
Docker_K8S_lecciones_netcoreconf_2022.pdf
- 1. Agenda #netcoreconf Docker yK8S lecciones aprendidas • De un developer
- 2.
- 4. #netcoreconf Como developer • Estono es así el 95% del tiempo • Ser super especialista tiende a hacer todo más lento • Las interdependencia generan demoras • La falta de conocimiento, al menos mínimo, el otras áreas atenta contra la resolución de problemas • Ser extremistas en cuanto a “como se deben hacer las cosas” no nos lleva a ninguna parte
- 5. Agenda #netcoreconf Docker yK8S lecciones aprendidas • De un developer
- 6. Agenda #netcoreconf ¿Quién soy? •Leonardo Micheloni • Developer +18 años • Trabajo en Tokiota Madrid • Microsoft MVP 8 años • Auth0 Ambassador • CSM 10 años • https://twitter.com/leomicheloni
- 7. ¿Tenemos que preocuparnosde todas estas cosas?
- 8. #netcoreconf Contexto • Developer • Fullstack? Viejos tiempos • Consultora • Todo tipo de proyectos • Entregar valor • Agilidad • Resolver • “Shipear”
- 9. #netcoreconf De qué vamosa hablar entonces? • La vida real • Mi, vida real • Aprendizajes • Experiencia • Dar soluciones • Ser ágiles • Que mis tareas funcionen en el entorno que deben • Cuaderno de recetas
- 10.
- 11. #netcoreconf ¿De qué NOvamos a hablar? • Arquitectura “correctas” • Buenas prácticas • “En un mundo ideal” • “Esto es un anti-patrón” • “No es la forma de hacer las cosas” • “Esa es responsabilidad de…” • No vamos a juzgar nada • Show me the code running in the correct environment
- 12. #netcoreconf Escenarios • Existe algohecho • El cliente tiene know how de todo • El cliente solo sabe que quiere usar eso • Existe microservicios • Escucharon la palabra “Docker” por ahí (o Kubernetes)
- 13. #netcoreconf ¿Qué nos vamosa llevar? • Un conjunto de recetas • Tips • Reflexiones
- 14.
- 15.
- 16.
- 17. #netcoreconf Docker • Dockerfile • Crearimagen • Ejecutar container • Puede tener comandos que debemos saber • Puede depender de ficheros que deben copiarse durante el build • Puede tener muchas variables de entorno • Depende de runtimes que debemos especificar
- 18. #netcoreconf Docker • Usar siempreel mismo Dockerfile de producción • Usar multistage
- 19.
- 20. #netcoreconf Docker-compose • Variables deentorno • Comandos
- 21. #netcoreconf • Docker composecon imagen local • Con variables • Comandos • Podemos “escriptear” publish + Docker build + Docker-compose up
- 22. #netcoreconf Entonces • Tenemos quesaber Docker • Comandos de build, push, pull • Dockerfile • Tenemos que saber Docker-compose • Creación • Comandos • Opciones
- 23.
- 24. #netcoreconf Dependencias propias • Nuestroservicio utiliza otros servicios propios • Levantar esos otros servicios • Probar resilencia • Docker-compose • Abrir puertos • Tirar de las imágenes de desarrollo (autorización) • Incluir ambos en la misma red de Docker
- 25.
- 26.
- 27. #netcoreconf Servicios de terceros •Qué pasa si dependemos de servicios de terceros? • Base de datos • Message brokers • Docker-compose • Usando las mismas versiones • Estamos limitados si se usan clusters o cosas similares
- 28.
- 29. #netcoreconf Kubernetes • Nuestra aplicaciónse va a ejecutar en K8S • Lo ideal es utilizar un deployment local para probar • Combinar Docker-compose con K8S Docker Desktop para • Servicios de los que depende • Servicios de terceros • En estos casos es indispensable abrir los puertos en el Docker-compose
- 30. #netcoreconf Kubernetes • Configuración • UtilizarConfig maps • Montar configuraciones como volúmenes • En general en entornos productivos los yaml cambian por temas de recursos, user accounts, etc.
- 31. #netcoreconf Desarrollo resumen • Serviciosde terceros • Docker-compose • Servicios que no estamos desarrollando ahora • Docker-compose • K8S docker desktop • Probar escalamiento horizontal • Tips • Build local desde compose • Push al registry de desarrollo • Probar algo en dev con un tag temporal
- 32.
- 33. #netcoreconf El Pod sereinicia / no inicia • Exec -it • Get logs • Describe pod • Exec $print • Cp de configuración carpeta, etc.
- 34.
- 35.
- 36. #netcoreconf El Pod noinicia • get pods • describe pod [pod_id] • El pod se reinicia • Entrar en el pod • Exec –it • Si no levanta no podemos • Sobre escribir el comando en el deployment
- 37.
- 38. #netcoreconf Leer un ficherodentro del Pod
- 39. #netcoreconf Ejecutar un comandodentro del Pod
- 40.
- 41. #netcoreconf Copiar ficheros desdey hasta un Pod
- 42. #netcoreconf Sobre-escribir el comandode inicio del Dockerfile
- 43. #netcoreconf Montar parte comúndel appsettings como volume
- 44. #netcoreconf Reflexión final • Enel mundo de la consultoría • >Agilidad • <Especialización • -Silos de conocimiento • +Velocidad de resolución de problemas • +Capacidad de proponer diferentes soluciones • >Ownership
- 45.
- 46.
- 47. #netcoreconf Referencias • https://docs.docker.com/build/building/multi-stage/ • https://github.com/dotnet-architecture/eShopOnContainers •https://docs.docker.com/compose/networking/ • https://kubernetes.io/docs/concepts/storage/volumes/