Docker solía ser algo genial y juvenil en sí mismo. Y luego, de alguna manera, el acoplador dejó de ser interesante: simplemente lo es, está en todos y en todo. Tiene todos los microservicios, Kubernetes, devops, cualquier cosa. Sin embargo, las personas arrastran contenedores a sus bocas desde cualquier lugar. A menudo ni siquiera saben lo que hay dentro.
¿Qué es ahora interesante para los ingenieros de DevOps? El equipo de superhéroes, el comité del programa de la conferencia DevOops, cayó en una trampa diabólica en Hangouts y respondió preguntas durante una hora. (¿Quiénes son todas estas personas? Escrito
en detalle
aquí ).
Debajo del corte: una entrevista, coloreada con crayones. Cada experto tiene su propio color:
Baruch, ¿qué crees que ha sucedido en el mundo desde el pasado DevOops? 
Me parece que lo más interesante, desde lo obvio, es el despegue de Kubernetes en todos los campos, y desde lo no obvio, menos notable, pero no menos importante, la consumerización del acoplador. 
Es decir, ¿antes de que Docker no fuera para todos?
No Docker solía ser algo genial y juvenil en sí mismo. Y luego, de alguna manera, el docker dejó de ser interesante, es decir, está allí, todos y todo lo tiene, tiene todos los microservicios, Kubernetes, devops, todo, cualquier cosa. Pero el docker en sí, como tecnología, de repente una vez y otra vez ya no le interesa a nadie. No ejecute el mismo Java en los servidores, está claro que los contenedores. Realmente me fascina.
Las personas generalmente discuten con qué tienen problemas o tareas directas. No hubo problemas en la ventana acoplable y ¿estaban allí?
Hubo muchos problemas en la ventana acoplable, y realmente se resolvieron. Además, dejamos de usar aquellas partes de la ventana acoplable que eran dolorosas. El estibador tenía cosas que puede hacer muy bien. Y hay aquellos que son malos.
Da un ejemplo.
Por ejemplo, cárceles en procesos unix: allí todo es muy bueno e inteligente. Realmente funciona muy bien. Pero, por ejemplo, la conectividad entre microservicios que se ejecutan en contenedores, clústeres, implementaciones, todo fue un infierno y una pesadilla.
¿Te refieres al Enjambre que intentaron seguir con los Kubernetes? 
Sí, quiero decir Componer, todo fue una pesadilla y un infierno. Y decidimos no usarlo, sino usar solo lo que funciona bien, lo cual es comprensible y gratuito. Y el docker se volvió muy genial, por un lado, y por otro dejó de ser interesante. Docker y docker, bien y bien.
Ahora, cuando mira un nuevo software, primero mira si hay un contenedor listo para usar. Preferiblemente del fabricante de este software. Luego observa cómo desplegarlo y pincharlo con una varita. Docker nos brindó servicios complejos para hurgar en una máquina que funciona. Ahora no es tan importante si eres poppy o Linux. El mismo Sentry consta de 5-6 componentes con los que comienza a encontrarse por separado. Y si tiene una tarea solo para ver cómo se ve este bien, envíe una señal y observe cómo se descompone allí. Ahora tomará 15 minutos: se lanza, se despliega y la pieza estará en Ruby, la pieza en Java, Dios no lo quiera, algunos Elasticsearch, que morirán con el mismo acoplador.
Lo más importante, morirá más tarde. 
Sí, este es un encanto separado. Anteriormente, podías engañarte en el sistema para que en / usr / local no hubiera nada. Y todavía se levanta: alguien en / opt, alguien en / usr / local, alguien más en algún lugar. Y su sistema se hincha, crece con todo lo innecesario. Este es uno, y el segundo: cuanto más innecesario tenga, mayor será el vector de ataque contra usted, por lo que puede ofenderse. Y dado que ahora estamos lanzando todo esto en los estibadores, la seguridad aquí y la limpieza no llevan nada desagradable con nosotros.
Escuchen, damas y caballeros, están haciendo conferencias sobre devops, y si la ventana acoplable se ha vuelto aburrida y sin interés, ¿qué pasará ahora, no habrá ventana acoplable?
En primer lugar, Docker estará en todas partes. El hecho de que se haya vuelto aburrido y poco interesante no significa que dejará de usarse. Por el contrario, esto significa que ahora lo estamos usando y no estamos prestando atención. Es decir, él está en todas partes. No es un tema para una discusión separada en las conferencias.
¿Tiene algún informe? Si entro en el programa ahora y escribo la palabra acoplador, ¿no habrá nada?
Escribir Hagamos este maravilloso experimento.
Escribió y dice: Pasos prácticos para asegurar la implementación de su contenedor
Esto es un reflejo del hecho de que Docker permite que nuestros sistemas modernos sean más seguros de forma natural. Además, refleja una cosa más, que también puede haber cambiado últimamente ... Devops se ha vuelto más. Digamos que las grandes empresas comenzaron a penetrarlas cada vez más. Y con ellos, comenzaron más y más discusiones sobre el tema de la seguridad, que los devotos pueden aportar o, por el contrario, para romper esta seguridad. El informe de Liz trata sobre cómo preparar adecuadamente este devo para mantener felices a tus guardias. 
¿Conoces personalmente a los hablantes? Quien es Liz Rice?
Liz es una figura importante en el paisaje devopian. Ella es la cabeza de todos los KubeCons. De hecho, Liz, en primer lugar, es una muy buena oradora. En segundo lugar, trabaja para Aqua Security, una empresa que se ocupa de la seguridad de los contenedores. No encontraremos una mejor persona para la historia sobre la seguridad de los contenedores que aquellos que están especialmente involucrados en esto. Lo que es interesante específicamente sobre los informes de Liz, vi muchos de sus informes, es que está tratando de resolver un problema bastante complicado. El problema es que hoy, la seguridad es, en primer lugar, compleja y se hace cada vez más complicada, a medida que los ataques se vuelven más sofisticados. En consecuencia, se hace más difícil defenderse de ellos, debemos encriptar nuestra información en REST, debemos encriptar en el tráfico, todo tipo de TLS, https, certificados, protocolos ... todo esto es complicado . Con la letra A al final. En primer lugar, es difícil, y en segundo lugar, no hay forma de escapar de eso, porque no puedes decir ahora: "Oh, no sé esto, vamos, no voy a hacer https. Bueno, a quién le importa a quién necesito ". Dado que el mismo vil Chrome le gritará inmediatamente a todos sus usuarios que no todo está asegurado con usted. Y esta combinación de complejidad y necesidad, se congela, porque no es nuestra preocupación, no todos estamos a salvo. Por otro lado, recae en nosotros, porque no podemos simplemente ignorar estos aspectos. Liz en sus informes trata de transmitir de manera simple y clara los aspectos clave de la seguridad de los contenedores a las personas que están lejos de la seguridad, y esto es muy bueno.
Hay otro problema que las personas arrastran contenedores a sus bocas desde cualquier lugar. A menudo ni siquiera saben lo que hay dentro. Una cosa es si quieres pegar tu varita en tu computadora portátil. Y otra cosa es arrastrarlo a producción. Y, desafortunadamente, muchos arrastran cualquier golpe. Es decir, necesita algo que sea difícil de ensamblar, toman el acabado y bien, si es del fabricante, que se encargó y tomó los contenedores de base normales. Y este es el mismo vector para el ataque. Por ejemplo, en un futuro cercano podemos generar una nueva ola de contenedores del mismo nombre, como fue el caso de los módulos pip, con los módulos get. Al igual que con los dominios, todo es igual. Es decir, este no es un problema nuevo, sigue siendo el mismo de siempre. Y cuando un servicio se convierte en mercancía, cuando está tan distribuido, vienen personas que castigan a quienes no controlan la seguridad. Por cierto, debido a esto, tenemos muchos informes sobre seguridad.
Que mas hay
Todavía tenemos sobre la gestión de secretos de Seth Vargo. Por cierto, habrá una mesa redonda sobre seguridad con él.
¿Seth es la misma persona de Google que solía trabajar en HashiCorp?
Antes de eso, trabajó en Chef Software y fue una estrella allí cuando Chef estaba en la cima de la popularidad. Dejó una marca en casi todos los libros de cocina. A algunos ni siquiera les gustaba para esta actividad. Luego heredó mucho en HashiCorp. Y este tren HashiCorp todavía se extiende detrás de él. Aquí hablará sobre el producto HashiCorp. No hablará sobre Google. Pero en el título tendrá Google, por lo que esto agrega peso.
Por cierto, ¿qué le pasó al chef?
En algunos lugares, Chef fue asesinado por los mismos contenedores.
Las aplicaciones de Chef donde fueron escritas y funcionan, hasta donde yo entiendo, pueden continuar funcionando durante mucho tiempo, porque la gestión de la configuración en sí no ha muerto.
Chicos, les puedo decir con un ejemplo vivo. Tenemos algo que no está en la ventana acoplable, luego debajo del Chef. Porque los copos de nieve del servidor no fueron a ninguna parte.
Acabas de decir lo que le pasó al chef. Lo que no está debajo de la ventana acoplable está debajo del Chef. Pero bajo Docker, tenemos casi todo.
Todo es correcto, pero aún hay servidores de larga duración, servidores con datos que nadie quiere meter. Aquí seguirán viviendo con Chef durante algún tiempo, porque todos los que han estado en un mundo normal no quieren volver al campo del control manual.
Por cierto, ¿hay alguien presente usando Ansible?
Sí, Ansible también está ahí.
Estamos utilizando
Y como? ¿Por qué Ansible?
Increíble capacidad de convertirse en basura a una velocidad salvaje. Esta es la impresión que deja Ansible. Nunca he conocido tal convergencia al infierno en mi vida.
¡Parece que tenemos un informe sobre esto!
Exactamente Y ayuda no solo convertir el resultado de trabajar con Ansible en lo que mencioné. Y esto es increíble, lo siento, no lo vi cuando escribimos que todo está bien .
¿Dice que todo comienza debajo de la ventana acoplable, pero los servidores deben configurarse de alguna manera para ejecutar el hipervisor en ellos?
No, lo tomas en Amazon ...
Ah, tramposo, en Amazon. Ya veo
O Terraform, en cualquier lugar.
El mas avanzado. Y sobre esto también tenemos un informe .
Terraform cierra esta necesidad, que hay un montón de proveedores, sus máquinas virtuales comienzan de manera diferente y usted usa Terraform para cerrar la capa cuando aparece su automóvil. Luego tienes un aprovisionador en Terraform, el mismo Chef, el mismo Ansible. Algún aprovisionador vierte la siguiente capa, y luego Docker vuela a esta máquina mínima lista para usar. Ganancia
¿Y el informe está dirigido por la persona que hizo aws-modules para Terraform?
Ha hecho mucho por los módulos de Amazon, pero esta es una parte de la comunidad. Y esta persona también es interesante de la siguiente manera: dado que ha vivido con Terraform durante mucho tiempo, se han formado algunas mejores prácticas en la comunidad donde ha estado pasando el tiempo todos estos años, y estas mejores prácticas simplemente no son suficientes en Terraform, porque en lugares es muy simple y tan no te permite hacer movimientos innecesarios, ya que a veces la descripción es demasiado complicada. Tendrá una tela para los pies o viceversa, una estructura interconectada muy compleja. Y esperamos que Anton Babenko, que solo hablará de todo esto, ayude a resolver cómo vivir con Terraform y no sufrirlo. Cómo desarrollar sus módulos para necesidades personales, para que sigan siendo limpios, legibles y, por cierto, allí, por supuesto, nadie prueba nada tampoco.
¿Nadie probó estos paños de Terraform desde un metalenguaje más conveniente para generar?
Hay tales ideas. Y tratamos de no hacer eso. Allí, de hecho, Terraform tiene estructuras de datos que aún pueden funcionar sin generación, pero es difícil. Imagine que tiene varios vpc en el Amazonas en diferentes regiones, necesita mirar entre ellos y aquí comienza la aventura. En cada región de la API, el punto de entrada es diferente, y Terraform está hablando de uno. Es decir, debe resolver estos puntos de entrada en la descripción, describir cada vpc y también la conexión entre estos vpc en diferentes regiones. Y todo esto debe ser descrito de alguna manera. Nuestros muchachos lo hicieron con sus módulos, y con esto al menos de alguna manera se hizo posible vivir. En general, duro, difícil. Pero si Terraform daba aún más posibilidades, si hubiera ... ¿Cómo se llama cuando la variable dentro de la variable se calienta?
Kotlin DSL. 
<todos se ríen infernalmente>
Variable variable o interpolación, según lo que quiera decir.
En general, este no es un lenguaje completo, está muy truncado. Te hace escribir lo más simple posible, a diferencia del Kotlin DSL, donde tienes un Kotlin completo en tus manos.
Bueno, ¿cómo, con todas las limitaciones de la DSL Kotlin, que tú mismo entiendes, se resuelven con qué?
Que?
Groovy DSL resuelto naturalmente!
¿Muchos usaron TeamCity de los presentes aquí?
Si por supuesto. Groove DSL, Kotlin DSL, tenemos un informe al respecto.
¿Y por supuesto que lo haces?
¡No soy yo quien lo hace, no! Tendremos solo TeamCity con Kotlin DSL y su comparación con Groovy DSL en Jenkins.
Alguien de JetBrains llegó?
No Este es un encanto aparte.
Tenemos usuarios reales, sin marketing.
Todos, me rindo, ¿quién más puede hacer un informe sobre TeamCity?
Utiliza una pequeña empresa, ampliamente conocida en Rusia como Tinkoff. Aquí, él está en el programa .
Sí, y cuente un poco, compárelo con todos los odiados, pero universalmente utilizados Jenkins y su DSL Groovy.
Debemos ir, escuchar y descubrir qué papel jugó el carisma de Baruch en la elección de la tecnología.
Ninguno. Me abstraje completamente de todo esto. Todo será honesto, sin muhlezh.
Quiero decir que Tinkoff tomó todas estas tecnologías hipster por una razón, TeamCity no es un tipo de empresa hace veinte años, como suele ser el caso con los bancos.
Tinkoff es un banco que lo ha hecho desde el principio. Banco para hipsters de hipsters. En consecuencia, las tecnologías allí son frescas y correctas.
Chicos, realmente uso TeamCity todos los días, y en la última versión se hizo genial. TeamCity DSL ya está disponible. Vea cuál era el problema hasta la última versión. En la versión anterior, si cambiaba a Kotlin DSL, no tenía opción para continuar usando la interfaz. Tan pronto como cruzaste la línea, la única forma de escribir más fue solo en Kotlin.
Eso es todo, pisaste el lado oscuro.
Sí, había un mínimo de documentación, y era un adok. Así que lo intentamos y volvimos a la configuración XML. En la última versión, cuando cambia a Kotlin DSL, continúa utilizando la interfaz web, y forma parches debajo del capó, parchea estas estructuras directamente en el repositorio. Entonces puedes seguir escribiendo en Kotlin con seguridad si ya has dominado algo en alguna parte. Aquellos que aún no están dedicados pueden continuar hurgando en la interfaz. ¡Esto es genial chicos!
Esta es la influencia beneficiosa de Anton Arkhipov.
Por cierto, aquí se mencionaron todo tipo de prácticas. ¿Tenemos algún informe dedicado no a la sintonía, sino a algunos procesos, cultura, lado humano?
Naturalmente En primer lugar, tenemos una maravillosa nota final de Sasha Titov y Kirill Tolkachev, en la que discutirán si todo está mal en devopa o si todavía hay esperanza. 
Me parece importante decir que DevOops es, en este momento, casi la única conferencia profesional organizada por el Grupo JUG.ru, en la que se le permite hablar sobre cosas sociales y de proceso, y a nivel oficial.
Para hacer esto, tuvimos que hablar de cerca con la gerencia del Grupo JUG.ru, pero el resultado es en persona.
Además de esta hermosa nota clave, también tenemos un informe de Dell EMC, que también tiene mucho que ver con los procesos. Se trata de un equipo dentro de una empresa que escribe servicios para uso interno. Una cosa es escribir este servicio y otra comenzar a usarlo, porque todas las personas están ocupadas, no tienen tiempo para dominar las tecnologías hipster. En consecuencia, escriba un servicio y luego véndalo dentro de la empresa. Los usuarios acudirán a usted, comenzarán a surgir todo tipo de necesidades no estándar, y aquí tiene un dilema: desarrollar un servicio para que muchos puedan usarlo o satisfacer a este equipo en particular. Esperamos una luz allí también.
Habrá una descripción de una terrible historia de dos años, que ya no está tan enferma como al principio.
Baruch, ¿también estás diciendo algo muy social?
Lenya Igolnik y yo tenemos un informe sobre cómo comenzar a medir en este momento, esta es toda la desgracia que ocurre en nuestros devops. Naturalmente, tenemos algún tipo de métrica que traemos con nosotros desde dev y que no usamos y nunca usamos. Tenemos métricas que llevamos con nosotros desde las operaciones, con las que siempre fue mucho mejor. La pregunta es, ¿qué son exactamente las métricas de DevOps? ¿Qué significa esto? ¿Es solo tomar esos y tomar otros, o es algo nuevo, algunas métricas nuevas? En resumen, devops basados en datos .
Baruch, a veces lectores, los visitantes están indignados de que los camaradas del comité del programa estén leyendo sus informes, consideran que esto es deshonesto.
Realmente tomamos todo esto en cuenta. Al menos, nos esforzamos por atraer a tantos oradores diversos como sea posible, que no sean solo del comité del programa. Pero al mismo tiempo, todavía queremos ver a algunos participantes de PC como oradores. Por ejemplo, Alena Prokhorchik, ingeniera principal de Rancher Labs, que probablemente tenga la mayor experiencia en el mundo con despliegues Kubernetes de varias nubes. Creo que todos quieren saber al respecto, y ella tiene algo que contar . Y nosotros, como comité del programa, disfrutamos de su experiencia en la evaluación de informes. Probablemente, cuando toda la conferencia está compuesta por oradores del comité del programa, y cada uno de ellos tiene cinco informes, esto realmente no es bueno. Pero si tenemos un buen orador que quiera ayudar al comité del programa, honestamente no entiendo por qué deberíamos elegir uno u otro.
Baruch, trabajas trabajando, además viajas constantemente con informes, además trabajas en el comité del programa. ¿Tienes alguna vida? ¿Cómo logras hacer todo?
Ser voluntario para las conferencias del Grupo JUG.ru es muy agradable porque me da mucho placer y, además, estoy aprendiendo uno nuevo. Hacer informes de personas que saben mucho más que yo es muy útil.
Ya veo ¿Alguien quiere agregar algo a nuestro monólogo con Baruch?
A menudo digo que he escuchado informes que nadie escuchará .
Sí, el comité del programa escucha no solo lo que llega a la conferencia. La competencia fue uno de cada tres. Podemos decir que esto sucedió, porque entre las aplicaciones había muchas interesantes. Parte de lo que filtramos, lo recomendamos en otras conferencias.
¿Hubo algún tema que tuvieras que filtrar por cantidad? Kubernetes, por ejemplo. ¿Hay algo más?
Monitoreo Tuvimos una batalla por el monitoreo.
Un montón de informes. A todos les encanta monitorear.
¿Quién ganó este rey de la colina?
Alexey Kirpichnikov, informe "¿Qué hemos aprendido mientras creamos nuestro propio sistema de notificación de emergencia" .
¿Hay algo que me gustaría tener en el programa, pero no hay expertos?
Te quitaste la lengua. Hay un reverso de la moneda, nuestro querido servidor, que parece estar exagerado, pero nadie que piense bien y prácticamente haya aplicado todo esto no ha aparecido. Espero que tengamos al menos uno. Pero, en general, las empresas tienen poca experiencia industrial. Baruch, ¿qué pasa con los expertos evangélicos? ¿No están allí tampoco? ¿O simplemente nadie vino a nosotros?
Toda la historia de la visa realmente nos estropeó la situación de muchas maneras, incluso con defensores de los desarrolladores que querían venir y hablar acerca de las lambdas sin servidor, específicamente de Amazon. En visas, desafortunadamente, todo se estancó.
¿Y hubo informes en los que realmente aprendiste algo nuevo para ti, que no tenías antes? ¿O algunas cosas innovadoras que recuerdas?
Yo, como una de las personas menos técnicas en el comité del programa, constantemente descubro un montón de cosas nuevas que les traigo a mis ingenieros más tarde, y dicen que es 101 lo que me trajiste. ¡Pero no siempre!
, , , ?
, , . , . - . , Ansible , . Ansible, . , , - . : , , , , . , , , .
, , . , , . .
.
?
. . , , , .
stateful , -, .
, . managed PostgreSQL … , - , — . , , , .
, - , . , ?
. Kubernetes , , . , , - , .
, . - , ? - , - , ?
— . , , , . , ( — , ) — , . JUG.ru Group , , . , , . . , (BOF). , , SRE. security, — , , , , . , , , -, , — , , :-)
- ?
, .
« , , » — , .
?
, , , . .
, , , - Java Virtual Machine, BOF . , , , - .
JVM, , , . , , , .
, — , , . , .
, . DevOops , . . , people + processes, , , .
, , TechTrain, .
, . , , , , . , TechTrain, . , TechTrain . JUG.ru Group, — . , . , . , , , .
, , — « » ( ).
, . -, , , . — , .
DevOops !
, , Joker , Java . , , — .
, , , DevOops - . , every company is a software company, - .
! , DevOops. , !
DevOops 14 2018 -. , , . .