¿Por qué un desarrollador debería preocuparse por Docker?

11

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

docker project-management orchestration Abhay Pai
fuente

Respuestas:

7

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.

Dan Cornilescu
fuente
Además, puede aprovechar la tecnología que desee, lo que le otorga menos restricciones y menos dolor de cabeza para que los administradores de sistemas admitan todas las tecnologías diferentes. Y dado que el "desarrollador" decide la tecnología, le corresponde a él configurar el entorno del acoplador.
DarkMukke
@DarkMukke El "desarrollador" no siempre decide la tecnología ... Todo lo contrario a menudo es cierto en los equipos de desarrollo más grandes: el "desarrollador" solo usa cualquier tecnología que el equipo use. Se pueden tolerar excepciones si no interfieren o afectan negativamente las actividades del equipo.
Dan Cornilescu
Estoy de acuerdo en parte, pero he visto grandes empresas de desarrollo (más de 200) trabajar con Docker en la forma que describí. Creo que es una cuestión de elección personal no solo de los equipos de desarrollo sino también del personal administrativo que está por encima de ellos. Si hay devops decentes, la cantidad de docker que necesita un desarrollador suele ser trivial.
DarkMukke
6

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.

lakshayk
fuente
5

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".

Ganado, no mascotas

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.

Mejor utilización de los recursos.

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.

Infraestructura inmutable

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:

  1. Crear nuevo servidor con nueva configuración.
  2. Mata a un servidor en ejecución.
  3. Su orquestador moverá todo a otras máquinas (incluida una nueva).
  4. Si quedan servidores antiguos, vaya al 1.

Operaciones más simples

  • ¿No hay suficientes recursos? Agregar nueva máquina al clúster.
  • ¿Necesita más instancias de aplicación? Aumenta el número y continúa.
  • ¿Vigilancia? Hecho.
  • Gestión de registros? Hecho.
  • ¿Misterios? Adivina qué.

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.

Hauleth
fuente
Ahora eso es lo que estoy preguntando y de eso se trata toda la pregunta. ¿Deberían los desarrolladores preocuparse por una mejor utilización de los recursos, una infraestructura inmutable y operaciones más simples? ... Lo que creo es que deberían centrarse en cumplir con los requisitos comerciales y la optimización del código que conduciría a una mejor utilización de los recursos. Incluso Docker no ayudará en una mejor utilización si es un código escrito mal / promedio. Aceptemos el hecho de que los requisitos comerciales hacen que los desarrolladores entreguen las cosas más rápido. Y al hacer esto, no tienen tiempo para optimizar el código. ¿Por qué agregar la responsabilidad de Docker sobre ellos?
Abhay Pai
El hecho es que tener una visión general de toda la pila, desde las pruebas hasta la implementación y finalmente hasta la implementación, le permitirá ver cómo se usa su software, cuáles son los casos extremos, qué se está bloqueando. Te ralentizará en el LOC que escribes, pero mejorará en gran medida su calidad. A la larga, ahorrando tiempo
Moritz
4

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/

Peter Muryshkin
fuente
Estoy de acuerdo con la inyección de nuevas tecnologías. Pero también hay algunos problemas con esto. Como usar docker para bases de datos ( percona.com/blog/2016/11/16/is-docker-for-your-database ). No son estables en este momento y probablemente lo sean en el futuro. Esperemos lo mejor. De todos modos, podemos lograr impulsar el código probado para producir usando CI / CD. Entonces, ¿por qué docker? A los desarrolladores no les importa en qué sistema operativo estamos ejecutando. ¿Por qué deberían molestarse en aprender docker en primer lugar? ¿Hacer la vida de DevOps más fácil?
Abhay Pai
en primer lugar, solo pienso en el siguiente escenario "MVP": dev prueba alguna nueva configuración / herramienta para el entorno como componente de infraestructura, por ejemplo, imagemagick. Sin Docker, esta información puede perderse u olvidarse, o necesita comunicación junto con muchas otras cosas pequeñas. Compartir un Dockerfile es una configuración comprobable por la máquina de una cosa que funciona y que incluso se utiliza para crear manualmente una configuración libre de Docker es más valiosa que una simple documentación. Seguro que también puedes ir a por Puppet; Lo bueno de Docker es en mi humilde opinión cómo permite escenarios autocontenidos.
Peter Muryshkin
Convenido. Pero el problema surge durante la orquestación. El desarrollador necesita tener experiencia en la orquestación de docker para cumplir con las mejores prácticas y cumplir con los requisitos comerciales. Considere su escenario donde el desarrollador necesita imagemagick como servicio. Ahora, mientras crea un dockerfile, él / ella obtiene un control completo sobre los paquetes que puede instalar en la imagen del docker. ¿Qué sucede si instalan sshd a ssh en la ventana acoplable en lugar de usar los registros de la ventana acoplable? ¿Qué sucede si instalan herramientas que no tienen nada que ver con la lógica empresarial sino que comprometen la seguridad? ¿Los desarrolladores necesitan experiencia en Docker?
Abhay Pai
hm, pero ¿y si implementan una puerta trasera basada en socket? docker no reemplaza el firewall de la empresa, creo
Peter Muryshkin
Cierto. Pero eso sería una intención maliciosa del desarrollador en cualquier caso. Ya sea docker o no docker. Pero cuando Docker se presenta a los desarrolladores, pueden causar percances solo porque carecen del conocimiento adecuado. ¿Por qué deberían incluso molestarse en aprender docker (teniendo en cuenta que el orquestador también agregará la complejidad) cuando puede causar percances y complicaciones? Por favor no te preocupes por mis preguntas. Incluso yo amo a Docker. Pero estoy tratando de entender la perspectiva de un desarrollador. Yo mismo he sido desarrollador durante los últimos 3 años y ahora soy ingeniero de DevOps.
Abhay Pai
4

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.

Juub
fuente
Entonces, de acuerdo con un desarrollador, ¿el uso de docker en un proyecto solo debe tomarse si el proyecto exige dependencia externa? Creo que Docker se ha convertido en parte de nuestro proceso de desarrollo porque lo aplicamos a los desarrolladores o porque pensamos que es genial. También el problema surge durante la orquestación. ¿Tienen que aprender orquestador como enjambre, kubernetes o mesos? La implementación de todas estas orquestaciones es diferente. ¿Qué sucede si la orquestación se bloquea debido a una mala implementación? Quién tiene la culpa ? PD: No te preocupes por mis preguntas. Solo estoy jugando al abogado de Devli. Yo también amo docker :)
Abhay Pai
2

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.

polluelos
fuente
0

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 :)

YV
fuente
Convenido. No estoy en contra del uso de Docker o sus diversas herramientas de orquestación. También los amo. Lo que estoy tratando de entender es simple. De quién es la contenedorización de la aplicación. Devs? O DevOps? O ambos ? Si ambos, ¿cuánto debería contribuir cada uno de ellos? Cuando las cosas fallan debido a la orquestación de docker o docker, ¿quién debería ser responsable? Eficiencia del código frente a ayudar a los desarrolladores a facilitarles la vida. Mi pregunta se inclina hacia el papel de un individuo en lugar de la tecnología en sí.
Abhay Pai