Un participant vient à un cours ou un cours intensif. Il voit des rangées ordonnées de support technique, des câbles d'alimentation soigneusement acheminés, une disposition en damier de la salle de conférence, des images lumineuses et des diagrammes de diapositives. Les orateurs avec des blagues et des sourires diffusent des informations de telle manière que vous avez juste le temps de les comprendre. Les stands sont installés, les tâches d'entraînement s'envolent simplement de vos doigts, sauf que parfois vous avez besoin de l'aide du personnel technique. soutien.
Et aussi des pauses café avec des personnes partageant les mêmes idées, une ambiance joyeuse et énergique, des échanges d'expériences, les questions les plus inattendues des intervenants. Des réponses et des informations que vous ne trouverez pas dans les manuels, mais seulement dans la pratique.
Combien de temps, d'efforts et de nerfs pensez-vous qu'il a fallu pour que cela ressemble exactement à ceci ?
Merci à Volodia Guryanov, administrateur Kubernetes certifié et ingénieur/chef d'équipe chez Southbridge, qui a été témoin et a participé activement à la création de nombreux cours Slurm depuis le tout début.
Il a vu les dessous de la création : complexités et problèmes épineux, idées et solutions inattendues. Et les intensifs Kubernetes déjà familiers, tels que Slurm Basic et Slurm Mega. Et un nouveau cours largement revu , qui approche inexorablement et débutera le 19 août.
Mais peut-être, assez parlé des paroles, passons à l’histoire elle-même. Comment, à partir de quelques sujets intensifs, un projet complètement autonome et multiforme . Je vais donc commencer l'histoire de la façon dont les cours sont créés et développés - tout comme « Il y a longtemps, dans une galaxie lointaine, très lointaine... »
Qu'y a-t-il dans les coulisses ?
Si vous me demandez comment nous faisons des cours et où tout commence, je répondrai simplement « Tout commence par une idée ».
Habituellement, l'idée vient de quelque part - nous ne restons pas menottés dans le sous-sol jusqu'à ce que nous trouvions : « Sur quel sujet devrions-nous faire un cours ? Les idées viennent de quelque part d’elles-mêmes, provenant de sources externes. Parfois, les gens commencent à demander activement : « Que savez-vous de telle ou telle technologie spécifique ? Ou comment il était impossible pour Docker de l'adapter au timing du cours intensif - il fallait évidemment l'emmener dehors pour avoir le temps de raconter quelque chose pendant le cours intensif.
C'est ainsi qu'une idée apparaît.
Après son annonce, à mon avis, commence le moment le plus difficile - comprendre généralement ce qu'il faut inclure dans ce cours - c'est très comparable à la façon dont les conférenciers sont préparés pour n'importe quelle conférence.
Il y a une douleur principale lorsque vous semblez avoir choisi un sujet et que vous pensez : « Que puis-je en dire ? C’est trop simple, c’est évident, tout le monde le sait aussi.
Mais en réalité, ce n’est pas du tout le cas. Et je dis personnellement dans de nombreux endroits que ce qui semble évident pour vous, pour ceux qui viennent vous écouter ou suivre un cours, ne l'est pas du tout. Et ici, une telle couche de travail et de conflits internes surgit quant à savoir ce qu'il faut inclure dans le cours. En conséquence, nous obtenons une telle liste de chapitres avec des traits si vastes que le sujet du cours.
Et puis le simple travail de routine commence :
- Sélection de matériel
- Lisez attentivement la documentation de la version actuelle, car le monde informatique se développe désormais à une vitesse cosmique. Même si vous travaillez avec quelque chose et faites un cours à ce sujet, vous devez consulter la documentation et voir ce qu'il y a de nouveau, ce dont il est intéressant de parler, ce qui pourrait être particulièrement utile de mentionner.
- Et un certain squelette du cours apparaît, où la plupart des sujets, en général, sont déjà abordés et il semble que quoi qu'il en soit, enregistrez des vidéos et lancez-les en production.
- Mais en fait, non, alors le travail acharné commence, mais pas pour les auteurs du cours, mais pour ceux qui testent. Habituellement, nos alpha-testeurs sont un support technique qui, dans un premier temps, relit les cours pour détecter toute erreur syntaxique et grammaticale. Deuxièmement, ils nous battent douloureusement avec des bâtons et jurent lorsqu'il y a des endroits complètement invisibles et incompréhensibles. Lorsque des phrases subordonnées composées de manière complexe et d'une durée de quelques pages ou des absurdités évidentes apparaissent dans les textes. Ils lisent tout, font attention.
- Ensuite commence la phase de test pratique, où certaines choses évidentes qui ne fonctionnent pas sont également détectées et certains moments sont montrés qui peuvent soit être rendus plus difficiles, car cela devient peu intéressant - juste s'asseoir et copier - et sont identifiés les endroits où c'est très difficile et nous avons beaucoup à faire de la part des personnes qui suivront ce cours. Et puis viennent les recommandations : « Les gars, simplifiez les choses ici, ce sera plus facile à percevoir et il y aura plus d'avantages.
- Une fois cette quantité de travail effectuée, la partie relative à la vidéo est écrite, tout semble bien se passer. Et vous pouvez déjà en faire don pour la production, pour la publicité de ce cours. Mais encore une fois, non, c'est trop tôt - car récemment, nous avons un peu cessé de nous faire confiance et, en principe, avons commencé à travailler davantage avec les retours. Il existe des tests bêta - c'est lorsque des personnes extérieures sont invitées, sans aucun lien avec notre entreprise, et pour certains cadeaux, on leur montre toutes les parties du cours, des vidéos, des textes, des tâches pratiques, afin qu'ils évaluer la qualité du matériel, l'accessibilité du matériel et nous a aidé à rendre le cours aussi bon que possible.
- Et lorsque plusieurs itérations de ce type sont effectuées, des intervenants, des tests alpha sous forme de support technique, des tests bêta, des améliorations. Et puis tout recommence : support technique, tests bêta, améliorations.
- Et à un moment donné, on comprend que soit nous en avons fini avec les modifications, car il est complètement irréaliste de s'assurer que tout le monde l'aime, soit des décisions drastiques sont prises. Lorsque de nombreux commentaires sur certains endroits sont critiques, refaites-les globalement, car quelque chose s'est mal passé.
- Vient ensuite le moment des modifications mineures - quelque part la phrase n'est pas très bien formulée, quelque part quelqu'un n'aime pas la police, 14,5, mais aimerait 15,7.
- Quand ce type de commentaire demeure, alors ça y est, le cours s'ouvre plus ou moins, les ventes officielles commencent.
Et à première vue, la tâche courte et simple de création d'un cours s'avère pas du tout simple et prend un temps incroyablement long.
Et il y a un autre point important : le travail sur le cours ne se termine pas à la sortie du cours. Dans un premier temps, nous lisons attentivement les commentaires qui sont laissés sur certaines parties. Et même malgré tous les efforts que nous avons déployés, certains défauts sont encore identifiés, certaines erreurs sont corrigées et améliorées au fur et à mesure, en temps réel, afin que chaque utilisateur ultérieur reçoive un meilleur service.
Chaque cours a son propre product propriétaire, qui, en plus de définir le concept général, vérifie les délais, il note en marge que lorsque viendra le temps de réécrire complètement le cours, et cela viendra certainement, car dans deux ans, ou même un an plus tard, une partie de ce que nous disons deviendra hors de propos simplement parce qu’elle deviendra moralement obsolète. Le Product Owner note en marge que le plus souvent les gens demandent quels points n'étaient pas clairs, quelles tâches semblaient très difficiles, et lesquelles semblaient au contraire très simples. Et tout cela est pris en compte lors du réenregistrement du cours, lors d'une sorte de refactorisation, afin que chaque itération du cours global devienne meilleure, plus pratique et plus confortable.
C'est ainsi que les cours apparaissent.
Comment est né le cours Docker
Il s'agit d'un sujet distinct et même inhabituel pour nous. Parce que d’une part, nous n’avions pas prévu de le faire, car de nombreuses écoles en ligne le proposent. En revanche, il a lui-même demandé la liberté et a trouvé une place logique dans notre concept de formation d'informaticiens à Kubernetes.
De manière très globale, au départ, tout a commencé avec un cours sur Kubernetes, alors que cela venait juste de commencer, à mon avis, après le premier Slurm. Nous avons recueilli des commentaires et constaté que de nombreuses personnes souhaitent en savoir plus sur Docker ailleurs, et en général, beaucoup viennent au cours de base sur Kubernetes sans savoir de quoi il s'agit. .
Par conséquent, pour le deuxième Slurm, ils ont créé un cours - ou plutôt, même pas un cours, mais quelques chapitres sur les Dockers. Où ils ont raconté certaines des choses les plus élémentaires, afin que les personnes qui viennent au cours intensif ne se sentent pas démunies et comprennent généralement ce qui se passe.
Et puis les événements se sont déroulés à peu près ainsi. La quantité de matériau a augmenté et a cessé de s'adapter au bout de 3 jours. Et une idée logique et évidente est apparue : pourquoi ne pas transformer ce que nous couvrons chez Slurm Basic en une sorte de petit cours auquel vous pourriez envoyer les personnes souhaitant regarder quelque chose sur Docker avant de suivre un cours intensif sur Kubernetes.
Slurm Junior est en fait une combinaison de plusieurs cours de base de ce type. En conséquence, le cours Docker est devenu une partie de Slurm Junior. C'est-à-dire qu'il s'agit d'une étape tellement nulle avant и . Et puis il y avait juste des abstractions très basiques.
À un moment donné, les gens ont commencé à demander : « Les gars, tout cela est génial, c'est suffisant pour comprendre de quoi vous parlez dans les cours intensifs. Où puis-je lire plus en détail sur ce que Docker peut faire et comment l'utiliser, et de quoi il s'agit ? » Alors l'idée est venue de mettre les choses au clair , afin que, d'une part, les personnes qui viennent sur Slurm en utilisant Kubernetes puissent toujours y être envoyées, et d'autre part, pour ceux qui ne sont même pas intéressés par Kubernetes à ce stade de développement. Pour qu'un informaticien puisse venir suivre notre cours sur Docker et commencer son parcours évolutif simplement avec Docker pur. Nous avons donc un cours aussi complet et complet - et puis beaucoup, après avoir regardé ce cours, après avoir travaillé pendant un certain temps avec Docker pur, ont atteint le niveau où ils ont besoin de Kubernetes ou d'un autre système d'orchestration. Et ils sont venus vers nous en particulier.
Parfois, la question est posée : « Quel genre de personnes n’ont peut-être pas besoin de Kubernetes ? » Mais cette question ne concerne pas les personnes, mais plutôt les entreprises. Ici, vous devez comprendre que Kubernetes a certains cas où il est bien adapté et des tâches qu'il résout bien, mais au contraire, il existe certains scénarios d'utilisation de Kubernetes lorsqu'il provoque une douleur et une souffrance supplémentaires. Cela ne dépend donc même pas des personnes, mais de ce que les entreprises développent et depuis combien de temps.
Par exemple, un terrible monolithe Legacy - vous ne devriez probablement pas l'intégrer à Kubernetes, car cela poserait plus de problèmes que d'avantages. Ou, par exemple, s'il s'agit d'un petit projet, il comporte une petite charge ou, en principe, peu d'argent et de ressources. Cela ne sert à rien de le glisser dans Kubernetes.
Et en général, probablement, en général, comme beaucoup de gens l'ont déjà dit, si vous vous posez la question : « Ai-je besoin de Kubernetes ? », alors vous n'en avez probablement pas besoin. Je ne me souviens pas qui l'a inventé le premier, à mon avis, Pacha Selivanov. Je suis d'accord avec cela à 100%. Et vous devez grandir avec Kubernetes - et quand il devient déjà clair que j'ai besoin de Kubernetes et que notre entreprise en a besoin, et que cela aidera à résoudre tels ou tels problèmes, alors il est probablement logique d'aller apprendre et de comprendre exactement comment définir bien, de sorte que le processus de passage à Kubernetes ne soit pas très pénible.
Certaines maladies des enfants et certaines choses simples, et même pas très simples, peuvent être découvertes notamment auprès de nous, et ne pas passer par votre propre râteau et votre propre douleur.
De nombreuses entreprises ont suivi exactement le même chemin : au début, il n'existait qu'une sorte d'infrastructure sans conteneurisation. Ensuite, ils sont arrivés au point où il est devenu difficile de tout gérer, ils sont passés à Docker et à un moment donné, ils ont grandi au point où ils sont devenus à l'étroit dans le cadre de Docker et de ce qu'il propose. Et ils ont commencé à regarder ce qui existait, quels systèmes résolvaient ces problèmes, et en particulier Kubernetes - c'est l'un de ces systèmes qui vous permet de résoudre des problèmes lorsque Docker pur devient encombré et manque de fonctionnalités, c'est un très bon cas lorsque les gens Ils procèdent étape par étape, de bas en haut, comprennent que cette technologie ne suffit pas et passent au niveau supérieur. Ils ont utilisé quelque chose, celui-ci est redevenu rare et ils sont passés à autre chose.
C’est un choix conscient – et c’est très cool.
En général, je vois que notre système est très bien construit, par exemple, , même à travers des cours vidéo. Puis après Docker, ça va alors alors . Tout s'enchaîne logiquement : une personne décède et un métier solide émerge.
En principe, l'ensemble des cours permet d'aborder de nombreux cas, même modernes. Il y a encore des zones qui restent une zone grise, j'espère que nous créerons bientôt des cours qui nous permettront de fermer ces zones grises, en particulier, nous trouverons quelque chose sur la sécurité. Parce que cela devient très pertinent.
En bref, nous avons quelques zones grises qu'il serait très agréable de fermer, pour avoir une image complète, complète - et les gens pourraient venir, et tout comme Kubernetes lui-même est comme un constructeur de Lego, vous pouvez faire différentes choses à partir de il collecte, s'il n'y en a toujours pas assez - complète, de même avec nos cours, pour que les gens puissent en comprendre ce dont ils ont besoin ; ils doivent assembler une sorte de puzzle, une sorte de jeu de construction à partir de nos cours.
Si vous vous posez une question généralement correcte et honnête : « Qui pourrait utiliser un cours Docker actif maintenant ? », alors :
- Pour les étudiants qui commencent tout juste à s'y lancer.
- Employés du service de tests.
- En fait, de nombreuses entreprises non seulement n'utilisent toujours pas Docker, mais personne n'a entendu parler d'une telle technologie et, en principe, ne sait pas comment l'utiliser. Et je connais plusieurs grandes entreprises à Saint-Pétersbourg qui se développent depuis de nombreuses années et qui utilisaient des technologies anciennes, elles évoluent dans cette direction. En particulier, pour de telles entreprises, pour les ingénieurs de telles entreprises, ce cours peut être très intéressant, puisque, d'une part, il vous permettra de vous immerger rapidement dans cette technologie, et d'autre part, dès qu'apparaissent plusieurs ingénieurs qui comprennent comment tout cela se passe. fonctionne, ils peuvent l'apporter à l'entreprise et développer cette culture et ces orientations au sein de l'entreprise.
- À mon avis, ce cours peut encore être utile à ceux qui ont déjà travaillé avec Docker, mais très peu et plus dans le style « faire une fois, faire deux fois » - et maintenant ils vont d'une manière ou d'une autre interagir avec le même Kubernetes, et ce leur impose certaines obligations, si vous avez une connaissance très superficielle de ce qu'est docker, comment le faire fonctionner, mais en même temps vous ne savez pas comment il fonctionne de l'intérieur, vous ne savez pas ce qu'il y a de mieux à faire avec et ce qu'il vaut mieux ne pas faire, alors ce cours est bien adapté pour systématiser et approfondir les connaissances.
Mais si vous avez des connaissances au niveau : « Je ne sais pas comment écrire correctement les mêmes fichiers Docker, je peux imaginer ce que sont les espaces de noms, comment fonctionnent les conteneurs, comment ils sont réellement implémentés au niveau du système d'exploitation » - alors il y a ça ne sert à rien d'aller chez nous, vous n'apprendrez rien de nouveau et vous serez un peu triste pour l'argent et le temps passé.
Si nous formulons les avantages de notre cours, alors :
- Nous avons essayé de faire ce cours avec un nombre suffisant de cas pratiques qui vous permettront non seulement de comprendre la partie théorique qui existe, mais aussi de comprendre pourquoi vous en avez besoin et comment vous l'utiliserez dans le futur ;
- il existe plusieurs sections que l'on trouve très rarement nulle part - et en général, il n'y a pas beaucoup de matériel à leur sujet. Ils concernent l'interaction de Docker avec le système d'exploitation, même un peu différemment. Quels mécanismes Docker a-t-il tirés du système d'exploitation pour implémenter le système de conteneurisation - et cela donne une compréhension plus approfondie de l'ensemble du problème de l'exécution de conteneurs dans le système d'exploitation Linux. Comment cela fonctionne, comment ils interagissent les uns avec les autres à l'intérieur du système d'exploitation, à l'extérieur, etc.
C'est un regard tellement profond que cela arrive assez rarement, et en même temps, à mon avis, c'est très important. Si vous voulez bien comprendre une technologie et comprendre à quoi en attendre, vous devez au moins avoir une idée générale de son fonctionnement à bas niveau.
Notre cours montre et raconte comment cela fonctionne du point de vue du système d'exploitation. D'une part, tous les systèmes de conteneurisation utilisent les mêmes mécanismes de système d'exploitation. D'un autre côté, ils prennent ce qui se trouve dans le système d'exploitation Linux, comme Docker. D'autres systèmes de conteneurisation n'ont rien proposé de nouveau - ils ont pris ce qui existait déjà sous Linux et ont écrit simplement un wrapper pratique qui vous permet de l'appeler rapidement, de l'exécuter ou d'interagir d'une manière ou d'une autre avec lui. Le même Docker n'est pas une très grande couche entre le système d'exploitation et la ligne de commande, c'est une sorte d'utilitaire qui permet de ne pas écrire des kilotonnes de commandes ou une sorte de code C pour créer un conteneur, mais de le faire en entrant quelques lignes dans le terminal.
Et encore une chose, si nous parlons spécifiquement de Docker, ce que Docker a réellement apporté au monde informatique, ce sont les normes. Comment l'application doit être lancée, comment elle doit fonctionner, quelles sont les exigences en matière de journaux, quelles sont les exigences en matière de mise à l'échelle et de configuration de l'application elle-même.
À bien des égards, Docker est une question de normes.
Les standards migrent également vers Kubernetes - et il y a exactement les mêmes standards ; si vous savez comment bien exécuter votre application dans Docker, alors 99 % du temps, elle fonctionnera tout aussi bien dans Kubernetes.
Si vous vous êtes intéressé non seulement à la façon dont le cours Docker a été créé, mais également à d'autres cours, mais également au cours lui-même d'un point de vue pratique, alors
Nous serons heureux de vous voir!
Source: habr.com