Optimización de equipos de desarrollo
El concepto de cadena suministro software no está tan extendido como el de DevOps.
Supongo que será porque el término DevOps es mas corto y hace hincapié en la necesidad de que exista buena sintonía entre dos áreas que normalmente han estado separadas. Los desarrolladores y los operadores.
Sin quitarle mérito al concepto de DevOps yo personalmente prefiero el concepto de cadena de suministro de software.
Prefiero este concepto porque me parece que refleja mejor el encadenado de pasos o fases por las que tiene que pasar el software desde que nuestros clientes nos realizan una petición hasta que esta petición llega a producción.
Aquí seguido encontraras todas las entradas que tengo publicadas referidas a la cadena de suministro de software.
¿Sabías que se está dejando de usar Docker? En este episodio te voy a contar porque y que es lo que se está utilizando en su lugar, y si efectivamente kubernetes tiene algo que ver.
El vídeo de pelado nerd al que hago referencia es este: https://www.youtube.com/watch?v=2LgiAWtqOoA
Algunos de mis alumnos del curso de Kubernetes y de OpenShift me comentan que quieren conocer más sobre la instalación de Kubernetes y yo siempre les digo lo mismo, que kubernetes es eminentemente de infraestructura no de desarrollo.
Kubernetes no es algo que se pueda instalar a la ligera en una instalación real, porque tiene muchas dependencias.
En este episodio te desarrollo un poco más la argumentación.
Kubernetes se va a ir llevando por delante muchas cosas y Jenkins va a ser una de ellas. En esta píldora del podcast Optimización de equipos de desarrollo te cuento con más detalle él porque de esta afirmación probablemente tan sorprendente.
Después del éxito de la anterior entrada sobre jib, en esta te voy a mostrar la otra alternativa que comentaba en la entrada anterior. Source To Image (s2i) se usa en OpenShift.
Es una alternativa para construir imágenes de tecnología Docker. Tiene sus ventajas e inconvenientes, como todo. Para mi el inconveniente sobre todo si usas java y maven es que cada vez se baja las dependencias, al ejecutarse dentro de un contenedor nuevo.
La ventaja es que si tu imagen la vas a desplegar en OpenShift vas a usar en tu local la misma herramienta que luego se usará en OpenShift.
Pero mejor te dejo el video para que puedas verlo en acción, y recuerda pasarte por mis cursos si quieres formarte en estos temas de Docker, OpenShift, Kubernetes, etc
Si, existen alternativas para los Dockerfiles. Ya vimos hace unos pocas semanas la posibilidad de utilizar podman, que es un remplazo completo a Docker y hoy quiero enseñarte otra alternativa, pero restringida a la construcción de las imágenes.
No sé tú, pero yo he llegado al mundo de los contenedores, Kubernetes, OpenShift y en general a la cultura DevOps desde la parte de desarrollo. Así que me preocupa mucho que el equipo de desarrollo pueda aprovechar la tecnología de contenedores de una forma fácil.
Podemos usar la herramienta s2i que vimos en el curso de OpenShift pero realmente implica un paso más.
Jib es una alternativa para Dockerfile creada por Google, que para mí tiene un importante beneficio y es que se integra con maven de tal forma que podemos crear una imagen Docker con la misma herramienta con la que generamos nuestro aplicativo.
Te invito a echarle un vistazo en el siguiente vídeo
Y no olvides que si necesitas aprender sobre OpenShift o Kubernetes tienes disponibles mis cursos sencillos y orientados a desarrolladores.
Si usas varios namespaces en kubernetes y te resulta un incordio andar cambiando entre ellos ene esta entrada te voy a contar una forma de hacer esas tareas de forma más sencilla.
Kubectx y kubens son dos herramientas de linea de comandos que nos simplifican enormemente la tarea de manejar diferentes contextos y namespaces de kubernetes.
En este video te enseño como instalarlos y un breve ejemplo de uso, espero que te guste.
Y si quieres aprender sobre kubernetes pásate por mi curso Kubernetes sencillo para desarrolladores
Kubernetes en Visual Studio Code, dos de las herramientas del momento juntas.
El orquestador de contenedores estándar de facto en el mercado es Kubernetes. Cada día que pasa van tomando más importancia los contenedores y con ello la necesidad de gestionarlo adecuadamente.
En estas labores Kubernetes se destaca como el mejor orquestador, incluido en multitud de nubes, como la de Azure, Google y Amazon y en productos de nube hídrica como OpenShift.
Sin duda una herramienta que hay que conocer.
Probablemente el editor de código más en boga actualmente. Lejos van quedando los pesados entornos de desarrollo como Eclipse y Netbeans. Hoy día empiezan a predominar este tipo de editores más ligeros basados en HTML.
Si quieres aprender más sobre Kubernetes no dejes de pasarte por mi curso Kubernetes sencillo para desarrolladores
En este video te enseño como puedes utilizar Kubernetes dentro del Visual Studio Code.
¿Alternativas a docker? Pues si efectivamente las hay.
Os voy a contar alguna opcion que hay para tener alternativas a docker.
Lo primero que tenemos que aclarar es: ¿que es lo que entendemos por docker? Hay dos formas de entender docker.
Realmente la primera es entender docker como contenedor. Docker es simplemente como la tecnología de contenedores.
En este caso Docker es una parte de lo que es el instalable que
nos podemos bajar y tener los contenedores, los dockers, en nuestro ordenador.
La alternativa más típica viene a ser el CRI o el CRI-O, que es la máquina que ha desarrollado Google muy orientado a orquestador Kubernetes.
Igual que nosotros podemos bajarnos el docker community edition para utilizarlo en nuestro portátil, en nuestro equipo de trabajo, hay una versión que lleva implementada la máquina de ejecución de contenedores del CRI que os comentaba, que se llama minishift.
Que al final lo que nos da es lo que sería la tecnología de contenedores más el orquestador. Viene a ser una versión para trabajo en el local del openshift, que ahora vamos a hablar.
Y por otra parte si lo que vemos o entendemos como docker es lo que sería la empresa que nos da los productos. como la versión enterprise de Docker, también hay más alternativas.
Realmente podemos tener alternativas en la nube tanto de google como de amazon etcétera etcétera y lo que sería más para instalar onpremise, instalar en nuestros ordenadores, en nuestros servidores, en nuestro cpd, la opción es openshift.
Openshift es de redhat. Hay una versión que es de la comunidad y luego hay otra versión que la distribuye redhat con un servicio de subscripciones y soporte.
Entonces OpenShift es lo que vendría a ser el equivalente a docker enterprise que nos da, ya no sólo la tecnología de contenedores, sino también lleva incorporado el kubernetes como el orquestador y toda una serie de servicios que necesitamos para desplegar contenedores en un entorno empresarial.
Tengo una entrada en la que explico por qué los contenedores en una empresa no son suficientes y también alguna serie de consideraciones de seguridad que hay que tener en cuenta con respecto a los contenedores.
La ventaja que tiene redhat es que proporciona tanto el sistema operativo como la tecnología de contenedores como el sistema operativo sobre el que corren esos contenedores. Incluso en muchos casos pues los servidores de aplicaciones.
Es el típico jboss o el Fuse para colas, infinispan para lo que sería o datagrid para lo que sería caché etcétera.
Si queréis ampliar conocimientos sobre openshift tengo un curso de openshift con un descuento bastante importante, el precio más barato que vais a poder encontrar.
Os dejo el video
¿Un curso de docker gratis? Os estáis preguntando si hay algo mal… Pues no, no hay nada mal.
Hoy os quiero anunciar que he hecho público, en YouTube mi curso Docker sencillo para desarrolladores. Así que vais a poder tener acceso a un curso de docker gratis.
Lógicamente en YouTube no se puede tener un certificado de finalización del curso. Para obtenerlo tendríais que recurrir a mi curso. Sí que es cierto que es de pago pero es muy económico.
En mi web vais a encontrar el precio más barato y ahí sí que podéis tener un certificado de finalización.
Si solo os interesa el conocimiento en YouTube podéis tener el mismo curso, exactamente el mismo curso.
Este curso se compone de una serie de secciones.
Hay una primera parte que es teórica, en la que pues explica lo que es el docker, qué problemas o qué situaciones se solventa.
Ya sé que la parte teórica no es la parte que más suele gustar. Pero creo que es importante para entender un poco y contextualizar lo que es el producto.
Luego hay otra parte que es de instalación. Vamos a instalar el Docker tanto en Linux, como en windows, como en mac.
Y como entorno de desarrollo vamos a utilizar el eclipse. Básicamente porque es el entorno típico en entornos de desarrollo java, que es en donde yo más me muevo.
Luego viene una parte que básicamente lo que vamos es a aprender cómo utilizar contenedores o imágenes docker que ya existen.
Vamos a bajarnoslas y vamos a ejecutarlas. Vamos a utilizar el WildFly y una base de datos mysql o maría db.
Luego hay otra sección que en la que lo que vamos a ver es cómo crear nuestros propios contenedores.
No vamos a coger un contenedor ya hecho sino que en base a un nuevo existente lo vamos a personalizar.
Y luego ya por último lo que hay es una sección en la que lo que vamos a ver son unas pinceladas de lo que sería Docker dentro de la cadena de suministro de software. Con github, docker compose etcétera etcétera.
Esta parte no la he desarrollado mucho porque creo que el futuro, o más bien el presente son las distribuciones de Kubernetes como OpenShift ahora renombrada a OKD, pero eso en otra entrada 😉
Espero que os resulte interesante, si es así dejármelo en los comentarios que os lo agradecería. Podéis subscribiros al canal y así os llega notificaciones y de paso me ayudáis a propagar el contenido.
https://www.youtube.com/watch?v=yVey-R8MWHU
En esta ocasión os quiero hablar de una cosa que normalmente se nos suele pasar por alto a la mayoría de nosotros cuando trabajamos con los contenedores Docker.
Y es el sistema operativo sobre el que se ejecutan los contenedores, no tanto sobre el que se ejecuta el motor de contenedores, sino sobre el sistema operativo sobre el que se ejecuta nuestro contenedor.
Sobre el contenedor que nos basamos a la hora de crear la imagen.
Esto de los contenedores está muy bien porque realmente nos proporcionan un servidor que no tenemos que configurar, ya está configurado y simplemente nosotros metemos nuestra aplicación.
Con lo cual como desarrolladores esto lógicamente es una funcionalidad muy interesante.
Sí que es cierto que normalmente los desarrolladores solemos tener una cierta tendencia a no preocuparnos de estas cosas de infraestructura.
Pero realmente esa aplicación que nosotros estamos corriendo sobre un servidor de aplicaciones, típicamente por ejemplo un JBoss eap o un Wildfly etcétera, tienen por debajo unas librerías de un sistema operativo.
La cuestión es que ese sistema operativo nos puede afectar. Ya que tenemos que tener en cuenta que ese sistema operativo tiene bugs y tiene normalmente parches de seguridad que van saliendo.
Con lo cual si nosotros no nos preocupamos de mantener actualizado el sistema operativo sobre el que está ejecutándose en nuestro contenedor podemos tener unos problemas de seguridad.
Se puede ver un ejemplo en las imágenes que están en el Docker Hub, que es el repositorio más popular de imágenes de contenedores. La mayor parte de las imágenes tienen serios problemas de librerías.
Quizás normalmente la última versión es la que puede tener los parches más actualizados.
Lógicamente porque normalmente se han generado hace poco tiempo con lo cual se basa en un sistema operativo que ya tiene corregido todas las vulnerabilidades.
Pero realmente las versiones un poquito más viejas podemos ver que realmente suelen tener bastantes problemas.
Para verlo simplemente tenemos que entrar en el hub de docker. Loguearnos. Ir a la imagen que estemos utilizando, que queramos utilizar y ver cuál es el estado de la seguridad.
Lógicamente si somos mínimamente exigentes con la seguridad de nuestra infraestructura estas imágenes no las podríamos utilizar en producción.
En el resto internos sí que se pueden utilizar pero no en producción.
Cuando queramos utilizar contenedores tenemos que tener la seguridad de que tenemos un soporte sobre el sistema operativo sobre el que se están ejecutando esos contenedores. Y en general de toda la infraestructura que está por debajo de nuestra aplicación.
Podemos encargarnos nosotros o utilizar un proveedor que nos proporcione esta base actualizada.
Si queréis pues ampliar conocimientos sobre el tema de los contenedores podéis echar un vistazo a mis cursos sobre contenedores y sobre openshift.
OpenShift es un poco la evolución de los contenedores más orientados a entornos empresariales. Por qué sí que es cierto que un contenedor lo podemos utilizar en nuestro portátil para hacer unas pruebas a nuestro desarrollo. Pero cuando ya entramos en lo que es el uso en entornos empresariales, entornos grandes pues los contenedores se nos quedan un poquito cortos y necesitamos herramientas como openshift
Os dejo el video en el que comentos más sobre este tema