Le festival RIT 2018 à Skolkovo était vaste et très diversifié. Le développement mobile, le backend, le frontend, le DevOps, la gestion de projet et même la psychologie sont des sujets pour tous les goûts et dans un horaire chargé du matin au soir. Les thèmes sont divisés en pistes séparées, les pistes sont liées aux salles. Si seuls des rapports spécialisés vous intéressent, vous pouvez vous installer dans la bonne pièce. Cependant, la salle des conférences a été utilisée au besoin par des conférenciers de divers sujets.
Dans l'ensemble, j'ai été informé des connaissances de DevOps et après avoir partagé mes impressions de la conférence avec mes collègues, j'ai formé une courte liste de rapports dont je me souvenais. Plusieurs mois se sont écoulés et je me souviens encore bien de quoi ils parlaient.
Donc, 3 rapports techniques dont je me suis souvenu au RIT 2018.
Surveillance et Kubernetes
Les outils de surveillance utilisés actuellement ne prennent pas si bien en charge les applications d'architecture de microservices. Plus le système est dynamique, plus il est difficile de configurer la surveillance pour celui-ci. La surveillance pratique des systèmes de clusters tels que Kubernetes, qui apportent une dynamique à l'extrémisme, est généralement une tâche non triviale. Pourquoi Dmitry Stolyarov, directeur technique de Flant, évoque les raisons de cette complexité et son impact sur la mission principale de suivi.
Les systèmes de surveillance traditionnels reposent sur le travail avec des serveurs statiques, qui sont relativement rarement ajoutés et supprimés de l'infrastructure d'application. Dans Kubernetes, la création et la suppression d'environnements de foyer et d'applications de service se produisent chaque seconde, de sorte que les procédures de découverte automatique existantes ne peuvent tout simplement pas gérer ce volume.
Le nombre d'environnements eux-mêmes est également de plusieurs dizaines et centaines. En conséquence, la quantité de télémétrie transmise augmente du même montant. Et elle doit encore être stockée quelque part.
Un problème distinct est la collision des mondes physique et virtuel: la consommation de ressources par les applications dans Kubernetes est assez éphémère et se reflète en termes de restrictions sur les foyers. Mais la consommation de ressources de pod a déjà un effet physique spécifique sur les capacités de serveur disponibles. Lorsque vous regardez des graphiques, vous devez toujours considérer de quel point de vue vous regardez les ressources. En pratique, peu de gens s'intéressent aux pods individuels. La consommation de ressources par l'application dans son ensemble présente un intérêt, ce qui nécessite déjà un regroupement flexible des modules de télémétrie selon certains critères définis par les utilisateurs.
Et vous devez augmenter le schéma résultant plusieurs fois pour les environnements de développement / de mise en scène / de production répandus!
Le rapport est recommandé à toute personne devant prendre en charge le cluster kubernetes.
Lien vers la présentation.
Devops de développement de boîtes
Il était extrêmement intéressant pour nous d'écouter le rapport de Maxim Lapshin, dans lequel il partageait la rare expérience de l'utilisation des devo-pratiques dans le développement de produits en boîte. Un produit en boîte est un logiciel traditionnel qui s'installe et s'exécute sur les capacités des utilisateurs.
Erlyvideo développe un serveur de streaming vidéo, nous sommes un serveur de configuration des services Internet. Nos problèmes sont à bien des égards similaires à ceux qui ont provoqué la transformation DevOps d'ErOlvideo.
Maxim commence le rapport par une réponse à la question la plus importante: "A quoi cela sert-il?" Tous les mêmes facteurs qui motivent l'introduction de la culture DevOps dans le développement des services sont également présents dans les industries où un développement plus traditionnel est en cours. Et l'influence de ces facteurs dans les produits en boîte sera probablement plus dramatique que lorsque vous travaillez sur un service. Par exemple, moins il y a de versions, plus le volume de modifications qui sera déployé est important. Si vous déployez un nouveau service, vous pouvez vous assurer ou simplement vous convaincre qu'il est sûr. Mais si vous publiez une distribution de produits avec un grand nombre de modifications, il ne vous suffit pas de vous convaincre de la sécurité de la mise à jour, vous devrez également convaincre vos utilisateurs de sa sécurité. Des petits changements, mais fréquents, viennent à la rescousse ici. Et ce n'est là qu'un des problèmes.
Le rapport approfondit cette question et de nombreuses autres raisons d'utiliser la livraison continue, de faire des parallèles et de souligner les différences par rapport au travail généralement plus simple en mode CI / CD avec les services.
Comment est-ce possible? Dans le rapport, Maxim décrit l'ensemble des pratiques utilisées dans Erlyvideo pour rendre réel la livraison continue du flux de changements. De nombreuses approches seront utiles telles quelles, quelque chose nécessitera une adaptation aux réalités de notre travail. Mais, dans tous les cas, cette merveilleuse réussite peut inspirer à repenser leurs problèmes et à trouver des solutions dans une variété de pratiques DevOps.
Le rapport sera très intéressant à voir pour tous ceux qui travaillent sur les distributions de produits.
Lien vers la présentation.
Bases de mise en réseau Kubernetes
Le guide de démarrage rapide, le cours intensif et les didacticiels omniprésents «Comment démarrer avec kubernetes» facilitent le passage dans cette voiture, déploient un cluster et déploient l'application. Étant donné l'incroyable popularité de ce sujet, beaucoup le font. Mais n'oubliez pas que, par essence, Kubernetes est un système assez complexe, dont l'entretien nécessite des connaissances spécifiques. Dans Ingram Micro Cloud, cette connaissance était requise lorsque la prochaine application est soudainement devenue indisponible sur le réseau. À partir de l'enquête sur cet incident, le fascinant voyage d'Alexander Khayorov à travers le sous-système réseau a commencé.
Le rapport nous présente les éléments de plus en plus complexes de la pile du réseau Kubernetes, expliquant comment le routage large et complexe est composé de blocs élémentaires. Cela s'avère particulièrement intéressant lorsque Alexander explique pourquoi cela est fait, et non autrement, en modélisant d'hypothétiques autres options de mise en œuvre.
C'est vraiment l'alphabet Kubernetes que la plupart des utilisateurs rencontreront. J'ai moi-même posé les questions "pourquoi nodePort?" et "pourquoi je ne vois pas l'IP de mon service sur l'interface?"
Intéressant et informatif.
Lien vers la présentation.