Docker était une chose cool et jeune en soi. Et puis, en quelque sorte, le docker a cessé d'être intéressant: il l'est, il est en chacun et en tout. Il a tous les microservices, Kubernetes, devops - n'importe quoi. Cependant, les gens traînent des conteneurs dans leur bouche de n'importe où. Souvent, ils ne savent même pas ce qu'il y a à l'intérieur.
Qu'est-ce qui est maintenant intéressant pour les ingénieurs DevOps? L'équipe de super-héros - le comité du programme de la conférence DevOops - est tombée dans un piège diabolique sur Hangouts et a répondu aux questions pendant une heure. (Qui sont toutes ces personnes - écrites
en détail
ici ).
Under the cut - une interview, colorée avec des crayons. Chaque expert a sa propre couleur:
Baruch, que pensez-vous qu'il s'est passé dans le monde depuis les derniers DevOops? 
Il me semble que le plus intéressant, de l'évidence, est le décollage de Kubernetes dans tous les domaines, et de la consumérisation non évidente - moins perceptible, mais non moins importante, du docker. 
Autrement dit, avant que docker n'était pas pour tout le monde?
Non. Docker était une chose cool et jeune en soi. Et puis, en quelque sorte, le docker a cessé d'être intéressant, c'est-à-dire qu'il est là, tout le monde et tout l'a, il a tous les microservices, Kubernetes, devops, tout, n'importe quoi. Mais le docker lui-même, en tant que technologie, n'intéresse soudainement plus personne. Ne pas exécuter le même Java sur les serveurs, il est clair que les conteneurs. Cela me fascine vraiment.
Les gens discutent généralement avec quoi ils ont des problèmes ou des tâches directes. Il n'y avait aucun problème dans le docker et étaient-ils là?
Il y avait beaucoup de problèmes dans le docker, et ils ont vraiment été résolus. De plus, nous avons cessé d'utiliser les parties du docker qui étaient douloureuses. Le docker avait des choses qu'il pouvait très bien faire. Et il y a ceux qui sont mauvais.
Donnez un exemple.
Par exemple, les prisons dans les processus Unix - tout y est très bien et intelligent. Cela fonctionne vraiment vraiment cool. Mais par exemple, la connectivité entre les microservices qui s'exécutent dans des conteneurs, des clusters, des déploiements, c'était tout l'enfer et un cauchemar.
Voulez-vous dire l'Essaim qu'ils ont essayé de suivre les Kubernetes? 
Oui, je veux dire Composer, tout était un cauchemar et un enfer. Et nous avons décidé de ne pas l'utiliser, mais d'utiliser uniquement ce qui fonctionne bien, ce qui est compréhensible et gratuit. Et le docker est devenu très cool d'une part, et d'autre part a cessé d'être intéressant. Docker et docker - bien et bien.
Maintenant, quand vous regardez un nouveau logiciel, vous regardez d'abord s'il y a un conteneur prêt à l'emploi. De préférence auprès du fabricant de ce logiciel. Ensuite, vous regardez comment le déplier et le pousser avec une baguette. Docker nous a fourni des services complexes pour pousser sur une machine qui fonctionne. Maintenant, ce n'est plus si important que vous soyez coquelicot ou Linux. La même sentinelle se compose de 5-6 composants que vous commencez à exécuter séparément. Et si vous avez une tâche juste pour voir à quoi cela ressemble, envoyez un signal et regardez comment il se décompose là-bas. Cela va maintenant prendre 15 minutes - il est lancé, il est déployé, et la pièce sera en Ruby, la pièce en Java, Dieu nous en préserve, certains Elasticsearch - qui mourra avec le même docker.
Plus important encore, il mourra plus tard. 
Oui, c'est un charme distinct. Auparavant, vous pouviez vous falsifier dans le système afin que dans / usr / local il n'y ait rien. Et ça monte toujours - quelqu'un dans / opt, quelqu'un dans / usr / local, quelqu'un d'autre quelque part. Et votre système gonfle, envahit avec tout ce qui n'est pas nécessaire. C'est un, et le second - plus vous avez inutile, plus le vecteur d'attaque sur vous est grand, à cause duquel vous pouvez être offensé. Et puisque nous lançons maintenant tout cela dans les dockers, la sécurité ici et la propreté n'emportent rien de méchant avec nous.
Écoutez, mesdames et messieurs, vous faites des conférences sur les devops, et là, si le docker est devenu ennuyeux et sans intérêt, et maintenant, il n'y aura plus de docker?
Premièrement, le docker sera partout. Ce n'est pas parce qu'il est devenu ennuyeux et inintéressant qu'il cessera d'être utilisé. Au contraire, cela signifie que nous l'utilisons maintenant et n'y prêtons pas attention. Autrement dit, il est partout. Ce n'est pas un sujet pour une discussion séparée lors des conférences.
At-il des rapports? Si j'entre dans le programme maintenant et que j'écris le mot docker, n'y aura-t-il rien?
Écrivez. Faisons cette merveilleuse expérience.
A écrit et il dit: étapes pratiques pour sécuriser le déploiement de votre conteneur
Cela reflète le fait que docker permet à nos systèmes modernes d'être plus sécurisés de manière naturelle. De plus, cela reflète une autre chose, qui a peut-être aussi changé récemment ... Devops est devenu plus. Disons simplement que les grandes entreprises ont commencé à les pénétrer de plus en plus. Et avec eux, de plus en plus de discussions ont commencé sur le thème de la sécurité, qui peut être amené par les devops, ou, inversement, pour briser cette sécurité. Le rapport de Liz porte sur la façon de préparer correctement cette démonstration pour garder vos gardes heureux. 
Connaissez-vous personnellement les intervenants? Qui est Liz Rice?
Liz est une figure importante du paysage dévopien. Elle est à la tête de toutes les KubeCons. En fait, Liz, tout d'abord, est un très bon orateur. Deuxièmement, elle travaille pour Aqua Security, une entreprise qui s'occupe de la sécurité des conteneurs. Nous ne trouverons pas de meilleure personne pour l'histoire de la sécurité des conteneurs que ceux qui sont spécialement engagés dans ce domaine. Ce qui est particulièrement intéressant dans les rapports de Liz, j'ai vu beaucoup de ses rapports, c'est qu'elle essaie de résoudre un problème assez compliqué. Le problème est qu'aujourd'hui, la sécurité est, tout d'abord, complexe et rendue de plus en plus compliquée, les attaques devenant plus sophistiquées. En conséquence, il devient plus difficile de se défendre contre eux, nous devons crypter nos informations sur REST, nous devons crypter le trafic, toutes sortes de TLS, https, certificats, protocoles ... tout cela est compliqué . Avec la lettre A à la fin. Premièrement, c'est difficile, et deuxièmement, il n'y a pas moyen d'y échapper, car vous ne pouvez pas dire maintenant: "Oh, je ne sais pas cela, ne faisons pas https. Eh bien, qui se soucie de qui j'ai besoin. " Étant donné que le même vil Chrome va immédiatement crier à tous vos utilisateurs que tout n'est pas sécurisé avec vous. Et cette combinaison de complexité et de nécessité, ça fige, car ce n'est pas notre souci, nous ne sommes pas tous en sécurité. D'un autre côté, cela nous appartient, car nous ne pouvons tout simplement pas ignorer ces aspects. Liz dans ses rapports essaie de transmettre simplement et clairement les aspects clés de la sécurité des conteneurs aux personnes qui sont loin de la sécurité, et c'est très cool.
Il y a un autre problème: les gens traînent des conteneurs dans leur bouche de n'importe où. Souvent, ils ne savent même pas ce qu'il y a à l'intérieur. C'est une chose si vous voulez coller votre baguette sur votre ordinateur portable. Et une autre chose est de le faire glisser en production. Et, malheureusement, beaucoup traînent quelque chose. Autrement dit, vous avez besoin de quelque chose qui est difficile à assembler, ils prennent le fini et bien, si du fabricant, qui a pris soin et pris les conteneurs de base normaux. Et c'est le même vecteur d'attaque. Par exemple, dans un avenir proche, nous pouvons ratisser dans une nouvelle vague de conteneurs du même nom, comme ce fut le cas avec les modules pip, avec les modules get. Comme pour les domaines, tout est pareil. Autrement dit, ce n'est pas un nouveau problème, c'est toujours le même ancien. Et quand un service devient marchandise, quand il est ainsi distribué, des gens viennent punir ceux qui ne surveillent pas la sécurité. Soit dit en passant, à cause de cela, nous avons beaucoup de rapports sur la sécurité.
Qu'y a-t-il d'autre?
Il nous reste à gérer les secrets de Seth Vargo. Soit dit en passant, il y aura une table ronde sur la sécurité avec lui.
Seth est-il la même personne de Google qui travaillait chez HashiCorp?
Avant cela, il a travaillé chez Chef Software et était une star là-bas lorsque Chef était au sommet de sa popularité. Il a laissé une marque dans presque tous les livres de cuisine. Certains ne l'aimaient même pas pour cette activité. Ensuite, il a hérité de beaucoup à HashiCorp. Et ce train HashiCorp s'étire toujours après lui. Ici, il parlera du produit HashiCorp. Il ne parlera pas de Google. Mais dans le titre, il aura Google, donc cela ajoute du poids.
Au fait, qu'est-il arrivé au chef?
Dans certains endroits, le chef a été tué par les conteneurs mêmes.
Les applications Chef où elles ont été écrites et fonctionnent - pour autant que je sache, peuvent continuer à fonctionner pendant longtemps, car la gestion de la configuration elle-même n'est pas morte.
Les gars, je peux vous dire avec un exemple vivant. Nous avons quelque chose qui n'est pas dans le docker, puis sous le chef. Parce que les flocons de neige du serveur ne sont allés nulle part.
Vous venez de dire ce qui est arrivé au chef. Ce qui n'est pas sous le docker est sous le chef. Mais sous Docker, nous avons presque tout.
Tout est correct, mais il y a toujours des serveurs à longue durée de vie, des serveurs avec des données que personne ne veut pousser. Ici, ils vivront toujours avec Chef pendant un certain temps, car tous ceux qui ont été dans un monde normal ne veulent pas retourner dans l'arène du contrôle manuel.
Soit dit en passant, quelqu'un est-il présent sur Ansible?
Oui, Ansible est là aussi.
Nous utilisons.
Et comment? Pourquoi Ansible?
Capacité incroyable de se transformer en ordures à une vitesse folle. C'est l'impression qu'Ansible laisse. Je n'ai jamais rencontré une telle convergence vers l'enfer de ma vie.
Il semble que nous ayons un rapport à ce sujet!
Exactement. Et cela aide non seulement à transformer le résultat du travail avec Ansible en ce que j'ai mentionné. Et c'est étonnant, désolé, je ne l'ai pas vu quand nous avons écrit tout cela est bien .
Vous dites que tout commence sous le docker, mais les serveurs eux-mêmes doivent être configurés d'une manière ou d'une autre pour exécuter l'hyperviseur sur eux?
Non, tu le prends sur Amazon ...
Ah, tricheur, en Amazonie. Je vois.
Ou Terraform - n'importe où.
Le plus avancé. Et à ce sujet, nous avons également un rapport .
Terraform supprime ce besoin, qu'il existe un tas de fournisseurs, leurs machines virtuelles démarrent différemment et vous utilisez Terraform pour fermer la couche lorsque votre machine apparaît. Ensuite, vous avez un approvisionneur dans Terraform, le même chef, le même Ansible. Un approvisionneur verse la couche suivante, puis Docker s'envole vers cette machine minimale prête à l'emploi. Bénéfice
Et le rapport est dirigé par la personne qui a fait des modules aws pour Terraform?
Il a fait beaucoup pour les modules Amazon, mais c'est une partie communautaire. Et cette personne est également intéressante comme suit: depuis qu'il vit avec Terraform depuis longtemps, certaines meilleures pratiques se sont formées dans la communauté où il traîne toutes ces années, et ces meilleures pratiques ne sont tout simplement pas suffisantes autour de Terraform, parce que par endroits c'est si simple et si ne vous permet pas de faire des mouvements inutiles, que parfois la description est trop compliquée. Vous aurez soit un chausson, ou vice versa, une structure interconnectée très complexe. Et nous espérons qu'Anton Babenko, qui ne fera que parler de tout cela, aidera à comprendre comment vivre avec Terraform et ne pas en souffrir. Comment développer vos modules pour des besoins personnels, afin qu'ils continuent d'être propres, lisibles et, au fait, là, bien sûr, personne ne teste rien non plus.
Personne n'a essayé ces chaussons Terraform à partir d'un métalangage plus pratique à générer?
Il y a de telles idées. Et nous essayons de ne pas faire ça. Là, en fait, Terraform a des structures de données qui peuvent encore se passer de génération, mais c'est difficile. Imaginez que vous ayez plusieurs vpc en Amazonie dans différentes régions, que vous ayez besoin de regarder entre eux, et ici vous commencez l'aventure. Dans chaque région de l'API, le point d'entrée est différent et Terraform vous en parlez. Autrement dit, vous devez résoudre ces points d'entrée dans la description, décrire chaque vpc et également l'homologation, la connexion entre ces vpc dans différentes régions. Et tout cela doit en quelque sorte être décrit. Nos gars l'ont fait avec leurs modules, et avec cela au moins en quelque sorte, il est devenu possible de vivre. En général, dur, difficile. Mais si Terraform donnait encore plus de possibilités, s'il y en avait ... Comment ça s'appelle quand la variable à l'intérieur de la variable est réchauffée?
Kotlin DSL. 
<tout le monde rit horriblement>
Variable variable, ou interpolation - selon ce que vous voulez dire.
En général, ce n'est pas une langue à part entière, elle est très tronquée. Il vous fait écrire le plus simplement possible, contrairement au DSL Kotlin, où vous avez un Kotlin à part entière entre les mains.
Eh bien, comment, avec toutes les limitations de la DSL Kotlin, que vous comprenez vous-même, par quoi?
Quoi?
Groovy DSL résolu naturellement!
Beaucoup ont utilisé TeamCity parmi ceux présents ici?
Oui bien sûr. Groove DSL, Kotlin DSL, nous avons un rapport à ce sujet!
Et bien sûr, vous le faites?
Ce n'est pas moi qui le fais, non! Nous aurons juste TeamCity avec le DSL Kotlin et sa comparaison avec le DSL Groovy à Jenkins.
Quelqu'un de JetBrains est arrivé?
Non. Ceci est un charme séparé.
Nous avons de vrais utilisateurs, pas de marketing.
Tout le monde, j'abandonne, qui d'autre peut faire un rapport sur TeamCity?
Une petite entreprise, largement connue en Russie sous le nom de Tinkoff, utilise. Ici, il est au programme .
Oui, et dites un peu, comparez avec tous les Jenkins détestés, mais universellement utilisés et son DSL Groovy.
Nous devons aller, écouter et découvrir quel rôle le charisme de Baruch a joué dans le choix de la technologie.
Aucun. Je me suis complètement éloigné de tout cela. Tout sera honnête, sans muhlezh.
Je veux dire que Tinkoff a pris toutes ces technologies hipster pour une raison, TeamCity n'est pas une sorte d'entreprise il y a vingt ans, comme c'est généralement le cas avec les banques.
Tinkoff est une banque qui l'a fait depuis le tout début. Banque de hipsters de hipsters. En conséquence, les technologies y sont fraîches et correctes.
Les gars, j'utilise vraiment TeamCity tous les jours, et dans la dernière version, c'est devenu super. TeamCity DSL est maintenant disponible. Voir quel était le problème jusqu'à la dernière version. Dans la version précédente, si vous passiez à Kotlin DSL, vous n'aviez pas la possibilité de continuer à utiliser l'interface. Dès que vous avez franchi la ligne, la seule façon d'écrire davantage était uniquement sur Kotlin.
C'est tout, vous avez marché du côté obscur.
Oui, il y avait un minimum de documentation, et c'était un adok. Nous avons donc essayé de revenir à la configuration XML. Dans la dernière version, lorsque vous passez à Kotlin DSL, vous continuez à utiliser l'interface Web, et elle forme des correctifs sous le capot, corrige ces structures directement dans le référentiel. Ensuite, vous pouvez continuer à écrire en Kotlin en toute sécurité si vous avez déjà maîtrisé quelque chose quelque part. Ceux qui ne sont pas encore dédiés peuvent continuer à fouiner dans l'interface. Ce sont des gars formidables!
C'est l'influence bénéfique d'Anton Arkhipov.
Soit dit en passant, toutes sortes de pratiques ont été mentionnées ici. Avons-nous des rapports dédiés non pas au réglage, mais à certains processus, à la culture, au côté humain?
Naturellement. Premièrement, nous avons une merveilleuse allocution de clôture de Sasha Titov et Kirill Tolkachev, dans laquelle ils discuteront si tout est mauvais en devoop ou s'il y a encore de l'espoir. 
Il me semble important de dire que DevOops est probablement à l'heure actuelle presque la seule conférence professionnelle organisée par le groupe JUG.ru, dans laquelle il est permis de parler de choses sociales et de processus, et au niveau officiel.
Pour ce faire, nous avons dû discuter étroitement avec la direction du groupe JUG.ru, mais le résultat est en personne.
En plus de cette belle keynote, nous avons également un rapport de Dell EMC, qui a également beaucoup à voir avec les processus. Il s'agit d'une équipe au sein d'une entreprise qui écrit des services à usage interne. C’est une chose d’écrire ce service, et une autre de commencer à l’utiliser, car tout le monde est occupé, il n’a pas le temps de maîtriser les technologies hipster. En conséquence, écrivez un service, puis vendez-le à l'intérieur de l'entreprise. Les utilisateurs viendront à vous, toutes sortes de besoins non standard commenceront à apparaître, et ici vous avez un dilemme - développer un service afin que beaucoup puissent l'utiliser ou satisfaire cette équipe particulière. Nous attendons là aussi une lumière.
Il y aura une description d'une terrible histoire de deux ans, qui n'est plus aussi malade qu'au début.
Baruch, dites-vous aussi quelque chose de très social?
Lenya Igolnik et moi avons un rapport sur la façon de commencer à mesurer en ce moment c'est toute la honte qui se produit dans nos devops. Naturellement, nous avons une sorte de métriques que nous apportons avec nous de la part des développeurs et que nous n'utilisons pas et n'avons jamais utilisées. Nous avons des métriques auxquelles nous apportons des opérations, avec lesquelles cela a toujours été beaucoup mieux. La question est, quelles sont exactement les métriques devops? Qu'est-ce que cela signifie? S'agit-il simplement de prendre ceux-ci et d'en prendre d'autres, ou est-ce quelque chose de nouveau, de nouvelles mesures? En bref, les devops basés sur les données .
Baruch, parfois lecteurs, visiteurs s'indignent que les camarades du comité de programme lisent leurs rapports, ils considèrent cela comme quelque chose de malhonnête.
Nous avons vraiment pris tout cela en compte. Au moins, nous nous efforçons de faire venir autant de conférenciers diversifiés que possible, qui ne sont pas seulement du comité de programme. Mais en même temps, nous voulons toujours voir certains participants PC comme des orateurs. Par exemple, Alena Prokhorchik, ingénieur principal chez Rancher Labs, qui a probablement la plus grande expérience au monde avec les déploiements Kubernetes multicloud. Je pense que tout le monde veut en entendre parler, et elle a quelque chose à dire . Et nous, en tant que comité de programme, apprécions son expertise dans l'évaluation des rapports. Probablement, lorsque toute la conférence se compose de conférenciers du comité de programme et que chacun d'eux a cinq rapports, ce n'est vraiment pas bon. Mais si nous avons un bon orateur qui veut aider le comité de programme, je ne comprends vraiment pas pourquoi nous devrions choisir l'un ou l'autre.
Baruch, vous travaillez, vous voyagez constamment avec des rapports et vous travaillez au sein du comité de programme. Avez-vous une vie? Comment arrivez-vous à tout faire?
Le bénévolat pour les conférences du Groupe JUG.ru est très agréable car il donne beaucoup de plaisir - et en plus j'en apprends un nouveau. Les rapports de personnes qui en savent beaucoup plus que moi sont très utiles.
Je vois. Quelqu'un veut-il ajouter quelque chose à notre monologue avec Baruch?
Je dis souvent que j'ai entendu des rapports que personne n'entendra jamais .
Oui, le comité de programme entend non seulement ce qui se passe ensuite à la conférence. Le concours était un sur trois. Nous pouvons dire que cela s'est produit, car parmi les applications, il y en avait de nombreuses très intéressantes. Une partie de ce que nous avons filtré, nous l'avons recommandé lors d'autres conférences.
Y avait-il des sujets que vous deviez filtrer par quantité? Kubernetes, par exemple. Y a-t-il autre chose?
Suivi Nous avons eu une bataille pour la surveillance.
Un tas de rapports. Tout le monde aime surveiller.
Qui a remporté ce roi de la colline?
Alexey Kirpichnikov, rapporte «Qu'avons-nous appris lorsque nous avons créé notre propre système de notification d'urgence» .
Y a-t-il quelque chose que j'aimerais avoir dans le programme, mais pas d'experts?
Vous avez enlevé la langue. Il y a un revers à la médaille, notre bien-aimé sans serveur, qui semble être sous le battage médiatique, mais personne qui pense bien et a pratiquement appliqué tout cela n'est pas apparu. J'espère que nous en aurons au moins un. Mais en général, les entreprises ont peu d'expérience industrielle. Baruch, qu'en est-il des experts évangéliques? Ils ne sont pas là non plus? Ou tout simplement personne n'est venu nous voir?
Toute l'histoire du visa a vraiment gâché la situation pour nous à bien des égards, y compris avec les défenseurs des développeurs qui voulaient venir parler sans serveur, en particulier d'Amazon, des lambdas. Sur les visas, malheureusement, tout a calé.
Et il y avait des rapports dans lesquels vous avez vraiment appris quelque chose de nouveau pour vous-même, que vous n'aviez pas auparavant? Ou des choses révolutionnaires dont vous vous souvenez?
En tant que membre le plus technique du comité de programme, je découvre constamment un tas de nouvelles choses que j'apporte à mes ingénieurs plus tard, et ils disent oui, c'est 101 que vous m'avez apporté. Mais pas toujours!
, , , ?
, , . , . - . , 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, - .
Merci à tous pour l'interview! Nous vous rencontrerons à plusieurs reprises lors de la préparation d'articles, mais avec nos lecteurs de Habr, nous nous rencontrerons uniquement chez DevOops. Meilleurs voeux et à bientôt!
La conférence DevOops se tiendra le 14 octobre 2018 à Saint-Pétersbourg. Si vous avez soudainement aimé le programme dont nous parlions ici, alors assurez-vous de venir. Les billets sont ici .