En general, un desarrollador se preocupa por satisfacer los requisitos comerciales. Él / ella puede tener la experiencia en una pila particular o un marco. ¿Pero debería él / ella hacer un esfuerzo para aprender Docker y sus diversos métodos de despliegue (enjambre, kube, mesos, etc.)?
En pocas palabras, ¿por qué un desarrollador debería preocuparse por Docker?
PD: La pregunta principal para esta publicación es Implicación de presentar docker al equipo de desarrollo
Respuestas:
Probablemente no sea la respuesta que estás buscando, pero una respuesta no obstante :)
Aprender acerca de Docker y sus métodos de implementación podría incluirse en los requisitos comerciales al hacer que forme parte del entorno de desarrollo del proyecto o del equipo, al igual que los lenguajes de código, el sistema de control de versiones, los compiladores, la infraestructura de prueba, etc., para trabajar en ese equipo o en ese proyecto uno necesita conocer y usar todo esto, no puede "traer el suyo" (en la mayoría de los casos).
Las cosas se vuelven un poco más complicadas si por "desarrollador" te refieres a la mayoría o incluso a todo el equipo de desarrollo. Impulsar una herramienta en el entorno de desarrollo sin que ninguno de los desarrolladores lo respalde será realmente difícil. Dedique tiempo a crear uno de esos partidarios primero del liderazgo técnico del equipo.
Nota al margen: también podría no ser necesario que todos y cada uno de los desarrolladores del equipo se conviertan en expertos en acopladores. Las recetas de uso preestablecidas envueltas en comandos simples y preparados para hojas de trucos a menudo permiten a los desarrolladores usar soluciones basadas en docker sin saber demasiado sobre su funcionamiento interno, lo que podría ser bastante aceptable, especialmente en equipos grandes. Al igual que poder contribuir con código sin conocer todos los detalles sobre cómo se está construyendo el producto final.
Te daré mi perspectiva. Los desarrolladores deben preocuparse por Docker ya que hay otros desarrolladores que están dispuestos a usar Docker y ya han desarrollado una experiencia en él. Están dispuestos a asumir los roles de un ingeniero DevOps junto con ser un desarrollador. Entonces, la parte de Ops de DevOps es en lo que ahora están construyendo experiencia.
En estos días, encontrará más y más personas que pueden desarrollar, orquestar, automatizar pruebas, automatizar trabajos y crear herramientas para monitorear y llevar este paquete completo a producción sin ayuda. Estos son los tipos que están empujando Docker y otras herramientas entre la comunidad de desarrolladores.
Además, la marea del mercado es hacia la virtualización, el autoescalado, la automatización, el aprendizaje automático y el docker encaja en todo esto. Se ha vuelto muy imperativo usar Docker. Las empresas están dispuestas a pagar 2 veces por un hombre soltero que asuma todas estas responsabilidades y, cuando exista demanda para tales hombres, la oferta también comenzará. Esto es desde el punto de vista de un empleado-empleador.
Técnicamente, en las organizaciones en las que he trabajado, hay equipos de desarrollo y DevOps separados, aunque trabajan muy de cerca para las entregas. Los ingenieros y desarrolladores de DevOps comparten una gran mayoría de conjuntos de habilidades aquí y, por lo tanto, a veces hay una negociación de deberes.
Lo mínimo que puede hacer un desarrollador es compartir sus archivos binarios, pero debe comprender que los archivos binarios se utilizarán para ejecutarse dentro de un contenedor acoplable y para eso necesita comprender cómo funciona el acoplador. Para kubes, enjambres, mesos, etc., el desarrollador puede no preocuparse por lo que se está utilizando, pero el desarrollador debe entender muy bien los conceptos básicos de Docker y debe haber una mentalidad desde el principio para construir la aplicación acoplada libremente para su reutilización como microservicios Si la aplicación se crea a partir de esa mentalidad (que requiere conceptos básicos de Docker), los ingenieros de DevOps pueden utilizarla desde allí para autoescalar, orquestar, probar, implementar y monitorear.
Además, la mayoría de las veces no hay una talla única para todo tipo de cosas. Un desarrollador no sabe claramente cómo construir una aplicación compatible con Docker y un ingeniero de DevOps con toda razón no conoce los aspectos internos del proceso de construcción de la aplicación. Por lo tanto, la mayoría de las veces, las organizaciones prefieren asignar ambas tareas al mismo tipo para acelerar las cosas. Si hay cosas separadas, entonces se requiere un mecanismo de retroalimentación continua del equipo de DevOps al equipo de desarrollo para que las aplicaciones sean más futuristas y estén listas para acoplarse / en la nube / escalar.
No se trata de Docker ni de ninguna otra tecnología de contenedorización existente.
Los contenedores como Docker, rkt, etc. son solo una forma de entregar su aplicación de manera similar al binario estático. Está construyendo su implementación que contiene todo lo que necesita dentro y el usuario final no necesita nada más que tiempo de ejecución.
Estas soluciones son similares a los JAR gordos en Java, donde todo lo que (en teoría) necesita es solo tiempo de ejecución (JRE) preinstalado y todo Just Works ™.
La razón por la cual los desarrolladores necesitan entender (no necesitan aprender cómo operar dicha herramienta, solo por qué es necesario) las herramientas de orquestación es que esto le permite tener algunas ventajas sobre la implementación "tradicional".
EngineYard ha escrito un buen artículo sobre eso. El punto principal de eso es que cuando su servidor muere, entonces se encoge de hombros y espera a que aparezca nuevo. Los tratas como ganado, tienes decenas, cientos, miles de ellos corriendo y cuando uno cae, ni tú ni tus clientes deberían ser conscientes de eso.
Las herramientas de orquestación logran eso al monitorear el estado de todas las aplicaciones (pods / trabajos, lo que sea) en el clúster, y cuando ve que uno de los servidores deja de responder (se cae), automáticamente mueve todas las aplicaciones que se estaban ejecutando en ese servidor en otro lugar.
Gracias a la orquestación, puede ejecutar múltiples aplicaciones en un servidor y el orquestador hará un seguimiento de los recursos por usted. Reorganizará las aplicaciones cuando sea necesario.
Gracias a la gestión automática de conmutación por error en los orquestadores, puede ejecutar sus imágenes personalizadas en la nube tal cual. Cuando necesite una actualización, simplemente cree una nueva imagen, configure su Configuración de inicio para usarla ahora y simplemente avance. Todo se manejará por ti:
TL; DR Todo el asunto no se trata de Docker sino de la orquestación. Docker es solo una versión extendida de JAR tarball / fat que se requiere para una correcta orquestación.
Aquí hay, por ejemplo, algunos argumentos de una publicación de blog publicada en 2014 y titulada de manera bastante similar a su respuesta:
- Inyección mucho más flexible de nuevas tecnologías en el medio ambiente.
- Todavía hay un gran problema entre confirmar el código final probado y luego ejecutarlo en los servidores de producción finales. Docker simplifica enormemente este paso final
- Docker lo hace trivial para mantener el sistema operativo heredado, sin importar el sabor de Linux que esté ejecutando
De: https://thenewstack.io/why-you-should-care-about-docker/
Si está ejecutando su producción en el contenedor de Docker, es crucial que esos contenedores estén hechos por los mismos desarrolladores que han creado la aplicación que se ejecuta en ellos. ¿Quién más es el mejor lugar para saber qué dependencia externa se necesita, etc.?
Además, la canalización puede fallar en cualquier paso durante un CD, particularmente cuando es el paso de compilación de la imagen del acoplador, a veces es un archivo que falta o una lib que se necesita.
En el trabajo, presentamos a todos los desarrolladores de Docker explicándoles los conceptos básicos para compilar el dockerfile con el fin de servir su aplicación, también facilitamos la canalización para que solo se pueda agregar un nombre y un dockerfile y su aplicación se construirá automáticamente en el siguiente impulso, independientemente de la tecnología que lo ejecute.
El inicio rápido de Docker es realmente una gran introducción para hacerlo, después de lo que el equipo de devOps guía al desarrollador en su elección de distribución (muchos de ellos no saben cosas como alpine).
Nuestro trabajo es proporcionarles un acceso fácil a las herramientas, ellos hacen el resto para que puedan solucionarlo cuando algo está mal. Docker es realmente una parte del proceso de desarrollo y el equipo de devOps les proporciona imágenes de docker que satisfacen nuestras necesidades y que son lo suficientemente fáciles, por lo que solo lleva un par de minutos crear una nueva aplicación e implementarla sin ayuda.
Docker recibe muchas menciones de prensa y blog, lo que lleva a los desarrolladores a interesarse en usarlo. Para algunas personas es el interés en jugar con una nueva tecnología o comprender cómo funcionan las cosas. Para otros, es un deseo agregar palabras clave a su currículum. De cualquier manera, cuanto más sepan los desarrolladores cómo funcionan las cosas y cómo se implementan, menos sorprendidos estarán más tarde. Por lo que he visto, hay una cantidad decente de interés preexistente en esto, por lo que no debería ser tan difícil alentarlo aún más.
Bueno, si alguna vez usó máquinas virtuales para las pruebas, es posible que desee intentar usar contenedores y la ventana acoplable es realmente una gran cosa para las pruebas y es mucho más simple de usar en lugar de LXC :)