Du 29 au 30 octobre, Saint-Pétersbourg accueillera DevOops 2019 - une conférence consacrée aux solutions d'ingénierie DevOps. Les principaux sujets sont les nuages en général, et Cloud Native en particulier, l'observabilité, la surveillance et l'audit, les CI / CD, la sécurité, etc. - en général, tout ce que vous pouvez attendre d'une conférence consacrée spécifiquement aux devops.
Ce pivot est une revue du programme DevOops, que nous avons écrit avec le comité du programme de la conférence.
En bref:
- Anton Weiss parlera des maillages de service;
- Burr Sutter et Oleg Nenashev - à propos de CI / CD;
- Dmitry Stolyarov et Sergey Fedorov - sur la surveillance;
- Il y a une énorme section sur les nuages et Kubernetes: Mete Atamel, Jessica Deen, Victor Gamov, Ivan Glushkov ...
Le programme est vaste, avec un total de 30 rapports.
Les keynotes sont dirigés par Tim Lister (co-auteur de Peopleware), Hadi Hariri (responsable du développement du plaidoyer chez JetBrains) et Roman Shaposhnik (membre du conseil d'administration de l'Apache Software Foundation et de la Linux Foundation LF Edge ).
Sous la coupe, nous parlerons de ce qui se passe dans le monde des devops, nous diviserons les événements en groupes et verrons comment tout cela s'intègre dans un programme de 30 rapports.
Etude de cas
Le premier groupe de rapports est une étude de cas. Récemment, la situation dans le monde a évolué rapidement, par exemple, la guerre de GitLab continue avec tout le monde: GitLab a tout, et ils vont le vendre comme un seul produit (comme indiqué dans un article scandaleux du PDG du Registre, Sid Sijbrandij).
Cependant, tout n'est pas si rose, et Nikita Sobolev veut juste dire comment ils sont passés de GitLab à GitHub et pourquoi. En bref, GitHub avait également tout, bien qu'en prévisualisation, mais les mêmes actions fonctionnent, le registre de packages fonctionne, la sécurité fonctionne également , etc. D'un autre côté, les actions continuent de pomper l'intégralité du référentiel, quelle que soit la demande d'extraction que vous testez dans quelle branche. Oui, à la fin, vous monterez sur Jenkins, car la vie est dure et pleine d'horreurs, mais au moins vous pouvez déjà assembler l'image de docker, et la plupart d'entre elles suffiront pour commencer. C'était un exemple de la catégorie Étude de cas, mais il y avait plusieurs rapports en général:
NB: Baruch Sadogursky continue de faire des présentations sur chaque nouveau DevOops. At-il de nouveau atteint le sommet? Nous faisons des paris.
Maillage de service
Dans les rapports de la catégorie Service Mesh, nous explorons les moyens de résoudre le problème de la complexité croissante. Nous sommes formidables, nous avons pensé à diviser les monolithes en microservices, mais au lieu de résoudre finalement le problème, nous avons été confrontés à l'incroyable complexité du monde des microservices. Les mailles ont été inventées pour réduire la complexité, mais au final ... ce qui s'est passé, ce qui s'est passé. Quelque chose me dit que ce n'est pas devenu plus facile avec les maillages, mais c'est un sujet pour une grande conversation séparée.
Vous pouvez maintenant trouver de plus en plus d'articles et de rapports sur le sujet: mais arrêtons le micro-codage en dur et revenons aux monolithes habituels. En fait, dès qu'il est devenu clair que les microservices réduisent la complexité de l'architecture, mais augmentent la charge des administrateurs, les gens sont venus et ont dit: «Oh, ce n'est peut-être pas toujours nécessaire»? Cette thèse n'a pas disparu, elle n'est pas toujours nécessaire. Par exemple, si votre système doit être intégré à quelque chose de grand et externe, avec une sorte de base de données épaisse, le nombre de problèmes résolus par les microservices est inférieur au nombre de problèmes créés - tout l'État passera par cette base de données et les microservices ne sont plus micro, car ils ne peuvent pas vivre l'un sans l'autre. Nous avons même de tels amateurs de monolithes dans le programme - par exemple, Alex Thissen avec le rapport « Signaler vos fonctionnalités» parle du fait que vous pouvez prendre une application monolithique, la couvrir avec des drapeaux de fonctionnalités et ensuite toujours rouler à partir de l'assistant.
Mais qui se battra avec les mailles de service? Demandez à nos conférenciers!
CI / CD
L'ancien Jenkins peut être exécuté sans Jenkins! Vous pouvez courir à Travis, n'importe où, comment aimez-vous cela, Elon Musk? (C'est assez grave maintenant). En général, puisque Kubernetes est maintenant partout, tous nos outils CI / CD s'adaptent à ce fait, Kubernetes doit être pris en charge. C'est pourquoi nous avons obtenu JenkinsX, donc de nouvelles puces apparaissent dans TeamCity, c'est pourquoi GitHubs et GitLabs déploient leurs CI - tout le monde a besoin de Kubernetes.
L'émergence de Kubernetes a changé l'approche de la CD. Au fur et à mesure que les CD étaient plus faciles, de nouvelles variantes ont commencé à apparaître sur la façon amusante de déployer des déploiements canaris, des déploiements bleu-vert, etc. - un tas d'abstractions prêtes à l'emploi que vous pouvez utiliser et profiter de la vie. Tekton est un exemple de CI / CD basé sur les principes du Cloud Native. Nous n'avons toujours rien sur Tekton (sauf que cela est mentionné dans les rapports d' Oleg Nenashev et Burr Sutter ), mais au printemps, nous essaierons de le faire. JenkinsX est exactement la même puce, créée sur la base de projets Cloud Native pour Cloud Native. Si quelqu'un s'intéresse à ce qu'est ce Cloud Native, il vaut la peine de lire sur les applications à 12 facteurs , c'est tout. Comme Kelsey a récemment plaisanté:
Rapports de catégorie CI / CD:
Suivi
Dans le monde de la surveillance, tout est beaucoup moins orageux, mais il y a des questions fondamentales. Par exemple, on dit souvent que personne n'a appris à surveiller les monolithes. Il semble que le problème ne soit pas cela - après tout, il n'y a rien à apprendre. Le problème est que la plupart des monolithes sont hérités, et le contrôle du vissage aux applications existantes est une douleur. S'ils vous le disent maintenant: écrivez un monolithe de manière à ce qu'il soit pratique de le surveiller, il est temps de cracher: vous prenez tout ce que nous aimons, à partir des journaux et des métriques et en terminant par le traçage, vous écrivez tout magnifiquement là-bas et obtenez une observabilité complète.
Le problème est qu'aujourd'hui, nous parlons de visser la surveillance sur les grands monolithes existants, et cela n'est pas anodin. Et quand tout se passe bien, vous devez en quelque sorte vivre avec le Frankenstein résultant. Par conséquent, nous avons un rapport de Dmitry Stolyarov sur la culture de la garde , ce n'est pas très technique, mais rappelez-vous, devops n'est pas seulement sur les outils! Philipp Krenn vous dira que lorsque nous évoluons, nous commençons à perdre des événements, et, en général, c'est normal, mais ici, les auditeurs viennent à nous et disent - nous voulons regarder des événements individuels! Comment marier la mise à l'échelle et l'audit n'est pas clair, un problème désagréable.
En général, nous n'avons pas encore appris à fixer la surveillance aux monolithes, et les microservices se sont empilés en plus des travaux. Les microservices et Cloud Native nous ont fait jeter un regard complètement différent sur l'observabilité, car nous comprenons que les anciennes méthodes comme la journalisation stupide, sur lesquelles nous continuons de faire cat, cessent de fonctionner. Récemment, une blague a glissé quelque part sur Twitter: "Si vous collez l'ID dans cinq outils différents, puis les recherchez en utilisant cet ID, alors vous êtes vous-même un outil d'observation." Dans les architectures de microservices évoluant vers un modèle réactif, l'observabilité se construit sur les événements avec lesquels elles sont transférées en interne. Et s'il s'agit d'une orchestration, il n'y a aucun événement et vous devez désassembler les journaux d'une manière différente. Le monde est devenu plusieurs fois plus difficile à observer, et tout le monde n'a pas appris à l'observer.
Rapports des sections de surveillance:
Nuage
Le cloud est le sujet le plus vaste et le plus volumineux. On croyait autrefois que les nuages publics sont «notre tout». Ensuite, il s'est avéré que pas tout. Il s'est avéré que ce n'était pas le nôtre non plus! De nombreux amateurs de nuages privés sont apparus, des nuages hybrides sont apparus. Cela n'a pas commencé cette année, mais bien plus tôt. Maintenant, l'une des principales questions est de savoir comment combiner tout cela. Par exemple, comment VMWare se combine avec AWS, car VMWare est venu sur Azure , ainsi que sur AWS , et c'est déjà une très grosse nouvelle toute l'année.
Bien sûr, partout, dans la plupart des rapports (pas seulement la section Cloud), Kubernetes est mentionné d'une manière ou d'une autre. Il s'est infiltré partout et quelqu'un commence même à attendre - quand le tueur Kubernetes apparaîtra-t-il? Jusqu'à présent, ce n'est pas visible. Il y a quelques années, la question principale était - comment vivre avec cette chose complexe et incompréhensible, mais maintenant tout le monde est déjà habitué à un mauvais voisin et a appris à négocier. Des opérateurs? Knative? Kotlin DSL?
Ce nouveau monde audacieux est si vaste et diversifié qu'il est inutile de tout lister ici, jetez un œil à cette liste de rapports:
Keynotes
Nous avons également trois keynotes. Ils occupent la plus grande salle disponible, il n'y a pas d'autres reportages en parallèle avec eux, et ils sont conçus pour un large public, ils sont dirigés par leurs conférenciers les plus célèbres.
La conférence s'ouvre avec Timothy Lister, co-auteur de Peopleware, Valse avec les ours, accros à l'adrénaline et modèles de zombies. Tous ces livres sont des classiques dans leur domaine et sont écrits avec des collègues de l' Atlantic Systems Guild . Dans le rapport «Personnages, communauté et culture: facteurs importants de prospérité», Tim parlera des meilleures pratiques pour les organisations, de la culture de travail, des aspects utiles et nuisibles du travail en entreprise. En général, de ce dont il parle depuis des décennies, mais mis à jour en fonction des réalités de 2019. Si les détails sont intéressants, tout récemment, nous avons fait une grande interview avec lui pour Habr . Écrivent-ils un nouveau livre - oui, ils lisent l'interview.
La première journée se termine avec Hadi Hariri, le leader légendaire de l'équipe Developer Advocacy chez JetBrains, développeur et conférencier open source depuis plus de 15 ans. Dans son rapport Supprimer les barrières, il suggère de réfléchir à la question: et si tous les barrières et problèmes habituels ont disparu, quelle est la prochaine étape? Cela entraîne-t-il vraiment une augmentation de la productivité et une solution garantie aux problèmes? Il s'avère que tout n'est pas si simple, et l'absence de barrières est en soi un sujet de discussion digne.
Enfin, la conférence se termine avec Roman Shaposhnik, membre du conseil d'administration de l'Apache Software Foundation et de la Linux Foundation LF Edge , qui a personnellement contribué au noyau Linux, Hadoop, ffmpeg et à d'autres projets populaires. Son discours principal «Pourquoi l'industrie informatique traverse des temps sombres, comment DevOps est à blâmer et pourquoi Capital peut-il aider» tentera de répondre à plusieurs questions philosophiques sur l'essor des plateformes cloud multimédias, des plateformes open source (Kubernetes et Cloud Foundry), Edge Informatique et ainsi de suite.
Et ensuite?
Le programme complet de la conférence est publié sur le site , il y a des descriptions détaillées partout, les commentaires du comité de programme sont partout, et des balises comme #kubernetes vous permettent de parcourir le contenu sans aller au bulletin.
Nous vous rappelons que DevOops 2019 aura lieu du 29 au 30 octobre à Saint-Pétersbourg, les billets peuvent être achetés sur le site officiel de la conférence . Vous pouvez prendre connaissance de toutes les actualités importantes soit sur notre blog sur Habré, soit en vous inscrivant à la liste de diffusion sur la page principale .