Le participant arrive au cours ou à l'intensif. Il voit des rangées bien ordonnées du support technique, des câbles d'alimentation soigneusement installés, un aménagement harmonieux de la salle de conférence, des images vives et des schémas sur les diapositives. Les intervenants transmettent l'information avec humour et sourire, et il n'y a qu'à suivre. Les stands sont prêts, les exercices pratiques se font sans effort, bien qu'il faille parfois demander de l'aide au support technique.
Il y a aussi des pauses café avec des personnes partageant les mêmes idées, une atmosphère dynamique et inspirante, des échanges d'expériences, et des questions les plus inattendues pour les intervenants. Des réponses et des informations que l'on ne trouve pas dans les manuels, mais uniquement dans la pratique.
Que pensez-vous, combien de temps, d'efforts et de nerfs a été nécessaire pour que cela ressemble à cela ?
Merci à Volodya Guryanov, administrateur certifié Kubernetes et ingénieur/leader d'équipe chez Southbridge, qui a été témoin et participant actif dès le début de la création de nombreux cours de Slyerma.
Il a vu les coulisses de la création des cours — les difficultés et les obstacles, les idées et les solutions inattendues. Et les sessions désormais habituelles sur Kubernetes, comme Slyerma Base et Slyerma Mega. Et un nouveau cours, largement retravaillé. , qui approche sans relâche et commencera le 19 août.
Mais bon, assez de lyrisme, passons à l'histoire elle-même. Comment, à partir de quelques thèmes d'intensif, s'est progressivement développé un cours à part entière, autonome et diversifié. . Je vais donc commencer à raconter comment les cours sont créés et se développent — littéralement "Il y a longtemps, dans une galaxie lointaine, très lointaine…"
Et que se passe-t-il en coulisses ?
Si vous demandez comment nous créons des cours et par où tout commence, je répondrai simplement : "Tout commence par une idée".
En général, l'idée vient de nulle part — nous ne sommes pas enchaînés dans un sous-sol en attendant de penser : « Quel sujet devrions-nous choisir pour le cours ? ». Les idées viennent naturellement de sources extérieures. Parfois, les gens commencent à demander activement : « Que savez-vous sur telle technologie spécifique ? ». Ou comme pour Docker, où il était impossible de l'inclure dans le timing de l'intensif — il fallait clairement l'externaliser pour pouvoir aborder quelque chose dans le cadre de l'intensif.
C'est ainsi qu'une idée apparaît.
Une fois qu'elle se manifeste, commence, à mon avis, le moment le plus difficile — comprendre ce qu'il faut inclure dans ce cours — c'est très comparable à la préparation des intervenants pour toutes sortes de conférences.
Il y a une douleur principale lorsque tu choisis un thème et que tu penses : « 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 souvent que ce qui te semble évident ne l'est pas nécessairement pour ceux qui viendront t'écouter ou suivre le cours. Cela soulève un grand nombre de questions et de conflits internes sur ce qu'il faut inclure dans le cours. Au final, cela donne une liste de chapitres esquissée, sur ce que sera le cours.
Ensuite, commence le travail de routine simple :
- Sélection de matériel
- Lire attentivement la documentation de la version actuelle, car le monde de l'informatique évolue à une vitesse fulgurante. Même si tu travailles sur quelque chose et que tu fais un cours à ce sujet, tu dois consulter la documentation pour voir ce qui est nouveau, ce qu'il est intéressant de partager et ce qu'il pourrait être particulièrement utile de mentionner.
- Et un certain squelette du cours émerge, où la plupart des sujets sont déjà en quelque sorte rédigés et on se dit un peu : enregistre les vidéos et mets-les en production.
- Mais en réalité, non, un travail difficile commence, mais ce n'est plus pour les auteurs du cours, mais pour ceux qui testent. En général, notre support technique effectue les tests alpha, qui relisent les cours pour détecter les erreurs syntaxiques et grammaticales. De plus, ils nous frappent de plein fouet et se plaignent lorsqu'il y a des passages vraiment pas évidents ou incompréhensibles. Ils examinent tout cela minutieusement.
- Ensuite, commence la phase de test pratique, où des éléments manifestement non fonctionnels sont également identifiés et des points sont montrés, qui peuvent être simplifiés, car il n'est pas très intéressant de juste copier. De plus, des endroits difficiles apparaissent, et nous attendons beaucoup de ceux qui suivront ce cours. Et alors viennent les recommandations : « Simplifiez, les gars, cela sera plus facile à comprendre et apportera plus de bénéfices. »
- Une fois que ce volume de travail est réalisé, la partie relative à la vidéo est écrite, et tout semble bon. On pourrait déjà le lancer en publicité pour ce cours. Mais encore une fois, c’est trop tôt — car dernièrement, nous avons un peu cessé de nous faire confiance et avons commencé à travailler davantage avec les retours. Un nouveau concept est apparu, le bêta-test – c'est lorsque des personnes extérieures, qui n'ont aucun lien avec notre entreprise, sont invitées à découvrir toutes les parties du cours, vidéos, textes, exercices pratiques, afin d'évaluer la qualité et l'accessibilité du matériel et de nous aider à rendre le cours aussi bon que possible.
- Et quand plusieurs itérations passent, avec les présentateurs, le test alpha sous forme de support technique, le bêta-test, et les améliorations. Puis tout recommence — support technique, bêta-test, améliorations.
- À un certain moment, on réalise qu'il faut soit arrêter les améliorations, car il est impossible de plaire à tout le monde, soit prendre des décisions radicales. Quand de nombreuses remarques sur certains points sont critiques — il faut les retravailler de manière globale, parce que quelque chose a mal tourné.
- Ensuite vient le temps des corrections mineures — où une phrase n'est pas très bien formulée, où quelqu'un n'aime pas la police de 14,5 et préférerait du 15,7.
- Lorsque seules des remarques de ce genre restent, le cours s’ouvre davantage, et les ventes officielles commencent.
À première vue, la tâche de créer un cours semble courte et simple, mais elle se révèle être tout sauf simple et prend énormément de temps.
Il y a encore un point important : le travail sur le cours ne s'arrête pas une fois celui-ci publié. D'une part, nous lisons attentivement les commentaires laissés sur les différentes parties. Et même avec tous les efforts que nous avons fournis, certains défauts et erreurs sont néanmoins identifiés, et sont corrigés en temps réel, pour que chaque utilisateur suivant bénéficie d'un service de meilleure qualité.
Chaque cours a son propre product owner, qui, en plus de définir le concept général et de vérifier les délais, prend des notes en marge. Quand viendra le temps de réécrire complètement le cours, ce moment arrivera sûrement, car dans deux ans, voire un an, une partie de ce que nous enseignons deviendra obsolète simplement parce qu'elle sera moralement désuète. Le product owner note ce que les gens demandent le plus souvent, quels points étaient flous, quelles tâches semblaient très difficiles, et lesquelles semblaient, au contraire, très simples. Tout cela est pris en compte lors de la réécriture du cours, dans un processus de refactorisation, afin que chaque itération du cours devienne meilleure, plus pratique et plus confortable.
C'est ainsi que les cours apparaissent.
Comment est né le cours sur Docker
C'est un sujet à part, et même inhabituel pour nous. Car d'un côté, nous ne prévoyions pas de le faire, étant donné que de nombreuses écoles en ligne le proposent. D'un autre côté, il s'est imposé de lui-même et a trouvé sa place logique dans notre concept de formation des spécialistes IT en Kubernetes.
Pour être très général, tout a commencé avec le cours sur Kubernetes, lorsqu'il a été lancé, je crois, après le premier Slurm. Nous avons recueilli des retours et avons constaté que beaucoup de gens voulaient en savoir plus sur Docker et, en général, beaucoup viennent à la formation de base sur Kubernetes sans savoir ce qu'est Docker. .
C'est pourquoi, lors du deuxième Slurm, nous avons créé un cours — en fait, pas un cours, mais quelques chapitres sur Docker. Où nous avons parlé des notions les plus basiques, pour que les personnes qui viennent à l'intensif ne se sentent pas perdues et comprennent ce qui se passe.
Ensuite, les événements se sont enchaînés ainsi. La quantité de matériel a augmenté et ne tenait plus en trois jours. Et une idée logique et évidente est apparue : pourquoi ne pas faire à partir de ce que nous enseignons dans le Slurm de base, un petit cours vers lequel nous pourrions diriger les gens qui souhaitent, avant l'intensif sur Kubernetes, voir quelque chose sur Docker.
Le Slurm Junior — c'est, en fait, la combinaison de plusieurs de ces cours de base. Au final, le cours sur Docker est devenu une partie du Slurm Junior. C'est-à-dire que c'est une sorte de première étape avant et . Et ensuite, il y avait des abstractions vraiment très basiques.
À un moment donné, les gens ont commencé à demander : « Les gars, tout cela est super, c’est suffisant pour comprendre ce que vous enseignez lors des sessions. Mais où peut-on lire plus en détail ce que Docker peut faire, comment travailler avec lui et de quoi il s'agit vraiment ? ». C'est ainsi qu'est née l'idée de créer , afin que, d'une part, nous puissions toujours diriger les personnes qui viennent sur Slyrm pour Kubernetes, et, d'autre part, pour ceux que Kubernetes n'intéresse même pas à ce stade. Pour qu'un spécialiste en informatique puisse venir voir notre cours sur Docker et commencer son chemin évolutif simplement avec Docker. Pour que nous ayons ce cours complet et abouti – et beaucoup de gens, après avoir suivi ce cours et travaillé un certain temps avec Docker, atteignent un niveau où ils ont besoin de Kubernetes ou d'un autre système d'orchestration. Et viennent, par exemple, à nous.
On pose parfois la question : "Mais à qui Kubernetes n'est-il pas utile en ce moment ?" Mais cette question ne concerne pas les personnes, c'est plutôt une question sur les entreprises. Il faut comprendre que Kubernetes a des cas d'utilisation spécifiques où il est bien adapté et des tâches qu'il résout efficacement, tandis qu'il existe aussi des scénarios d'utilisation de Kubernetes où il cause plus de douleur et de souffrance. Donc, cela dépend même moins des gens que de ce que les entreprises développent et depuis combien de temps.
Par exemple, un gros monolithe Legacy – il n’est probablement pas judicieux de l’intégrer à Kubernetes, car cela poserait plus de problèmes que cela n’apporterait d'avantages. Ou, par exemple, s'il s'agit d'un petit projet – avec peu de charge ou avec peu de moyens et de ressources en général. Dans ce cas, il n'a aucun sens de l'emmener dans Kubernetes.
Et en général, comme beaucoup l'ont déjà dit, si vous vous demandez : « Ai-je besoin de Kubernetes ? », alors il est fort probable que vous n'en ayez pas besoin. Je ne me souviens pas qui a d'abord proposé cela, je pense que c'était Pasha Seliwanov. Je suis d’accord à 100%. Et il faut grandir avant de passer à Kubernetes – et c'est quand on comprend déjà que Kubernetes est vraiment nécessaire pour notre entreprise et qu'il aidera à résoudre certains problèmes, que c'est probablement le moment d'apprendre et de se pencher sur comment bien le configurer afin que le processus de transition vers Kubernetes ne soit pas trop douloureux.
Il est possible de découvrir certaines maladies infantiles ainsi que des choses simples, voire des choses un peu plus complexes, notamment chez nous, plutôt que de passer par ses propres erreurs et douleurs.
De nombreuses entreprises ont suivi un parcours où, au départ, il y avait simplement une infrastructure sans conteneurisation. Ensuite, elles ont constaté qu'il devenait difficile de tout gérer et ont opté pour Docker. À un moment donné, elles ont réalisé que, dans le cadre de Docker et de ce qu'il propose, cela devenait étroit. Elles ont alors commencé à examiner les systèmes environnants qui résolvaient ces problèmes, et Kubernetes est l'un de ces systèmes qui permettent de surmonter les défis quand on se sent limité dans du Docker pur. C'est un bon exemple de personnes qui avancent progressivement, comprenant que cette technologie n'est pas suffisante et évoluant vers le niveau suivant. Elles utilisent quelque chose, cela ne suffit plus — et elles avancent.
C'est un choix conscient — et c'est vraiment génial.
Je vois en effet que notre système se structure de manière très harmonieuse, par exemple, , même à travers des cours vidéo. Ensuite, après Docker, il y a , puis , puis . Tout s'agencent logiquement — la personne suit son parcours et acquiert une profession cohérente.
En principe, l'ensemble des cours permet de couvrir un grand nombre de cas, vraiment modernes. Il y a encore des zones qui restent des zones d'ombre, j'espère que nous mettrons bientôt en place des cours qui permettront d'éclaircir ces zones grises, notamment en matière de sécurité. Cela devient très pertinent.
Pour résumer, nous avons certaines zones grises qu'il serait vraiment bien de combler, afin d'avoir une vue d'ensemble cohérente — et que les gens puissent venir, comme Kubernetes se présente comme un constructeur Lego, permettant d'assembler différentes choses, et s'il manque quelque chose — de compléter, tout comme avec nos cours, afin que les gens puissent comprendre ce dont ils ont besoin, assembler un puzzle, un constructeur à partir de nos cours.
Si l'on se pose la question juste et honnête : "À qui un cours de Docker actif pourrait-il profiter actuellement ?", alors :
- Aux étudiants qui commencent tout juste à s'y intéresser.
- Aux employés du département de test.
- En réalité, il existe de nombreuses entreprises où, non seulement on n'utilise pas de Docker, mais personne n'a entendu parler de cette technologie et ne sait comment l'utiliser. Je connais même plusieurs grandes entreprises à Saint-Pétersbourg qui développent depuis de nombreuses années, et elles continuent à utiliser des technologies obsolètes, s'orientant dans cette direction. En particulier, pour ces entreprises et leurs ingénieurs, ce cours peut être très intéressant, car il permettra d'immerger rapidement dans cette technologie. De plus, dès qu'il y a quelques ingénieurs qui comprennent comment cela fonctionne, ils peuvent introduire cela dans l'entreprise et développer cette culture et ces compétences en interne.
- À mon avis, ce cours peut également être utile pour ceux qui ont déjà travaillé avec Docker, mais très peu, et plus dans le style « fais une fois, fais deux fois » - et maintenant ils envisagent d'interagir d'une manière ou d'une autre avec Kubernetes. Cela leur impose certaines obligations. S'ils ont des connaissances très superficielles sur ce qu'est Docker, comment le lancer, mais ne savent pas comment cela fonctionne en interne, ni ce qu'il faut faire ou éviter avec, alors ce cours conviendra parfaitement pour systématiser et approfondir leurs connaissances.
Mais si vous avez des connaissances au niveau de : « Je ne sais pas comment écrire correctement des fichiers Docker, j'ai une idée de ce que sont les namespaces, comment fonctionnent les conteneurs, comment ils sont réellement implémentés au niveau du système d'exploitation » - alors il n'est pas du tout utile de venir chez nous, vous ne découvrirez rien de nouveau et vous serez un peu triste pour l'argent et le temps dépensés.
Pour résumer, quels sont les avantages de notre cours ?
- Nous avons essayé de concevoir ce cours avec un nombre suffisant de cas pratiques qui vous permettront non seulement de maîtriser la partie théorique, mais aussi de comprendre pourquoi c'est important pour vous et comment vous allez l'utiliser à l'avenir ;
- Il existe plusieurs sections qui se rencontrent très rarement ailleurs — et il n'y a pas vraiment tant de matériel à ce sujet. Elles concernent l'interaction de Docker avec le système d'exploitation, même un peu différemment. Quels mécanismes Docker a-t-il empruntés à l'opérationnel pour réaliser un système de conteneurisation — et cela offre une compréhension plus profonde de l'ensemble de la question du lancement de conteneurs dans le cadre du système d'exploitation Linux. Comment cela fonctionne, comment cela interagit les uns avec les autres à l'intérieur du système d'exploitation, à l'extérieur, etc.
C'est un regard vraiment profond, qui est plutôt rare, et à mon avis, c'est très important. Si vous souhaitez vraiment bien comprendre n'importe quelle technologie et savoir quels en attendre, vous devez au moins avoir une idée générale de son fonctionnement à un niveau bas.
Notre cours montre et explique comment cela fonctionne du point de vue du système d'exploitation. D'un côté, toutes les systèmes de conteneurisation utilisent les mêmes mécanismes du système d'exploitation. D'un autre côté, ils prennent ce qui existe dans le système d'exploitation Linux, comme Docker. D'autres systèmes de conteneurisation n'ont rien inventé de nouveau — ils ont simplement utilisé ce qui existe déjà dans Linux et ont écrit une interface qui permet de l'appeler rapidement, de le lancer ou d'interagir avec. Docker, c'est une couche relativement mince entre le système d'exploitation et la ligne de commande, c'est un utilitaire qui permet d'éviter d'écrire des tonnes de commandes, ou un code en C, pour créer un conteneur, mais de le faire en entrant juste quelques lignes dans le terminal.
Et de plus, si nous parlons spécifiquement de Docker, ce que Docker a réellement apporté au monde de l'IT, ce sont les standards. Comment une application doit être lancée, comment elle doit fonctionner, quelles sont les exigences en matière de logs, quelles sont les exigences pour la mise à l'échelle et la configuration de l'application elle-même.
En grande partie, Docker concerne les standards.
Les standards se déplacent également dans Kubernetes — et ce sont exactement les mêmes standards, si vous savez exécuter votre application correctement dans Docker, elle fonctionnera à 99 % aussi bien dans Kubernetes.
Si vous êtes intéressé non seulement par la façon dont le cours Docker a été créé, mais aussi par d'autres cours, et si le cours vous intéresse également d'un point de vue pratique, alors
Nous serons ravis de vous voir !
Source : habr.com
