Get best of the week

Kubernetes, microservices, CI / CD et Dockers pour rétrogrades: conseils d'apprentissage

Il semble que le sujet «pourquoi avons-nous besoin de Kubernetes» est déjà ennuyeux. Je veux dire: "tous ceux qui en ont besoin ont depuis longtemps compris", mais je diviserais les travailleurs techniques (et quasi-techniques) en ceux qui "ont compris et savent comment utiliser", et ceux qui "ont compris, mais veulent savoir comment rendre les connaissances pertinentes ".

Vous êtes peut-être un manager qui travaille sur la même pile depuis 10 ans; vous pouvez être un développeur qui prend en charge l'ancienne solution ou écrit dans une langue familière dans un environnement familier. Peut-être que vous venez de passer de la gestion technique à la gestion organisationnelle et que vous avez soudainement découvert que tout ce que vous saviez n'était plus pertinent, et je veux comprendre s'il existe un scénario relativement simple pour savoir comment cela peut être rattrapé. Je vais essayer de donner des conseils basés sur ma propre expérience - d'une personne qui s'est rendu compte que le fait d'être dans la gestion organisationnelle sera bientôt exprimé par les mots «Kubernetes est une technologie efficace, nous devons nous efforcer pour son application», ne comprenant pas pleinement ce qui se cache derrière avec ces mots et derrière toute la culture technique qui s'est développée récemment.

Pourquoi est-ce que je trouve important de pouvoir changer le paradigme de la pensée technologique?

La chose la plus difficile pour ceux qui travaillent dans la technologie depuis longtemps est d'accepter que la nouvelle tendance soit devenue permanente. Plus de 20 ans de travail, j'ai vu comment les différentes technologies vont et viennent, et certaines d'entre elles étaient «super pertinentes» pendant plusieurs mois.

J'ai lu Joel Spolsky sur la façon dont Microsoft invente systématiquement une nouvelle pile pour les développeurs afin de les empêcher généralement de regarder autre chose. Comme SRE, j'avais doublement peur de chaque nouvelle technologie: tout ce qui est nouveau est brut, tout ce qui est brut est instable. Eh bien, tout ce qui est instable entraînera des problèmes de production, et la stabilité de la production est la principale chose.

En tant que programmeur et entrepreneur, je voulais créer un produit plus rapidement - je dois tout apprendre de nouveau, changer les approches habituelles, ce qui signifie - déployer les fonctionnalités plus lentement. Si certaines nouvelles technologies étaient adoptées rapidement, alors tout ce qui concernait le développement orienté microservices (appelons-le l'ensemble de la pile moderne) devait être enseigné. Et chaque année pour apprendre plus longtemps; il est beaucoup plus facile d'écrire à l'ancienne et de livrer le produit plus rapidement.

Mais le fait demeure: parfois de nouvelles technologies subsistent et changent complètement le paradigme. Et ici, un choix se pose: rester dans l'ancien paradigme ou passer à un nouveau. Les développeurs de Cobol peuvent toujours obtenir un emploi, les développeurs de Perl se souviennent de la réservation, mais les moyens alternatifs pour ces personnes deviennent de moins en moins. Et puis «rétrograde» au nom de la stabilité devient une limitation. Avec toute la pile moderne, si vous ne voulez pas vous limiter, le temps n'est pas venu, mais nous sommes déjà en retard. Et, si nous ne voulons pas rester coincés dans Perl, nous devons apprendre. Cela prend beaucoup de temps. Je vais essayer de raconter mon expérience étape par étape dans l'apprentissage.

Directions de plongée


Comprendre comment exécuter des applications dans Docker. Tout d'abord, les vétérans doivent comprendre que la façon de «stocker» et de «lancer» des applications a changé pour toujours. Très probablement, un développeur qui a appris à se développer ces dernières années ne sait pas comment exécuter une application en production sans docker. À la tête d'un tel développeur, il n'y a probablement pas de concept de «stockage de fichiers localement», à l'exception de rares cas de stockage partagé, mais la principale chose qu'un «vétéran» doit comprendre est: docker est un nouvel exe. Le format exe peut avoir ses inconvénients, mais personne n'y pense vraiment.

Oui, l'approche microservice est devenue la norme. Comme une fois, la POO a semblé faciliter l’écriture de gros logiciels par de grandes équipes; maintenant les microservices sont devenus la même norme. Ils sont même cultivés par les mêmes personnes (voir Fowler) Ceci est raisonnable: si l'API d'application est versionnée, il est plus facile pour des équipes individuelles d'écrire des applications autonomes qu'une seule grande. Pourquoi les petites applications sont microservicables, on peut argumenter, mais à un moment donné, tout le monde a commencé à les écrire en style OOP - tellement familier (voir ci-dessus à propos de exe). Il y a beaucoup à dire que la communication interprocessus (en particulier celle basée sur la pile TCP) a un million de défauts de performance (un service ira à l'autre via TCP au lieu de simplement faire un appel assembleur - vous pouvez imaginer quelle est la différence dans productivité?), mais il n'en demeure pas moins que les microservices ont l'avantage de développer des projets de moyenne et grande envergure, et ils sont également devenus la norme. Comprendre comment les microservices interagissent entre eux (API HTTP, grpc,interaction asynchrone à travers la file d'attente - un million de façons), en prime - comprendre ce qu'est un maillage de service. (Un moment d'humour en colère: Dieu, les gars, ils ont eu l'idée de partager l'application, et il s'est avéré que la communication entre les applications divisées est une blague difficile, alors ils ont ajouté une autre couche pour soulager l'horreur interprocessus, qu'est-ce que c'est pour nous?)

, .Ainsi, nous nous sommes réconciliés que nous lançons maintenant les applications dans le docker et que nous partageons l'application dans des microservices. Maintenant, nous devons gérer les dockers en cours d'exécution. Vous pouvez le faire vous-même sur des serveurs dédiés (et piloter, par exemple, Docker Swarm, ou créer Kubernetes), ou vous pouvez utiliser les services fournis par les clouds - des services de conteneur AWS ou Kubernetes. Il y a un très gros avantage à utiliser les nuages. En fait, vous arrêtez de penser à la couche qui se trouve sous le gestionnaire de conteneurs (SRE rit maintenant, mais admettons - quand tout est stable, nous ne montons pas sur les nœuds GKE dans la plupart des cas). Ainsi, en fait, le gestionnaire de conteneurs, dont Kubernetes est devenu le standard, se transforme en système d'exploitation. Il a des gestionnaires de paquets, vous pouvez y "installer des logiciels", vous pouvez y exécuter "exe-shniki" - dockers,il a kronjoby. Kubernetes est un nouvel OS.

Comprendre comment les conteneurs dockers devront être livrés. La mise en page d'un site simple prend maintenant 5 minutes, et les gens considèrent cela comme la norme. Nous devons collecter le docker, le tester, le mettre dans le registre et le mettre dans le gestionnaire de docker (parlons plus de Kubernetes). C'est la sauvagerie (?) À laquelle tout le monde est habitué, elle est optimisée et c'est la norme. Les systèmes CI / CD sont devenus la disposition standard, et vous devez les comprendre. Tout comme avec GitOps.

Comprenez que l'hébergement sur site pour la plupart des applications sera une chose du passé (en Occident - déjà disparu).Il était une fois, c'était la norme d'acheter des serveurs, de les assembler, de les amener à DC, de les mettre en colocation et de les changer. Même pour un petit projet. Viennent ensuite les serveurs dédiés. Combien de personnes pensent maintenant à tourmenter, acheter et collecter du fer sur des projets de petite et moyenne taille? Dédié - en Occident maintenant, et dans la Fédération de Russie bientôt - sera remplacé par des nuages. On en parle depuis cent ans, j'utilise AWS depuis 2008, et ça a des problèmes, mais quand on parle du service qui prend en charge la gestion de Kubernetes (EKS, GKE, Kubernetes de Yandex ou Selectel), je ne comprends pas pourquoi gérer Kubernetes et Dediks eux-mêmes, si d'autres gars le font? Je ne change plus de glacières dans les Dediks ... La question de la prévalence des distributions Kubernetes sur site en Fédération de Russie est une question de taux de change du dollar,la loi sur les persdans et les "jeunes" de l'hébergement cloud russe. Tôt ou tard, cela sera décidé et sur place deviendra le délire que veulent les entreprises et les grands projets chargés. Avec des bases identiques. Si nous parlons de la plupart des applications qui ne nécessitent pas une charge très élevée ou un réglage super puissant, alors PostreSQL / MongoDB / MySQL basé sur le cloud offre un grand nombre d'avantages. Pas besoin de penser au réglage, pas besoin de penser aux sauvegardes. Créez un serveur de développement à partir d'un serveur de production - quelques commandes dans la console cloud. Je comprends que toute cette idée peut provoquer de la colère chez l’administrateur: les gars, je suis moi-même l’administrateur, mais pour la plupart des tâches non mauvaises, la gestion de la base de données n’est cependant pas nécessaire. Peut-être qu'AWS et GKE sont chers et inaccessibles pour nous à cause de la loi persane, mais ce n'est qu'un temps supplémentaire à retarder: tôt ou tard, Yandex ou Selectel auront les mêmes fonctionnalités,et le paradigme va changer.

Comprenez quelle infrastructure est maintenant écrite. Je n'aimais pas IaaC quand il était chef et marionnette, mais, Dieu merci, ils ont été remplacés par Terraform et Pulumi plus adéquats pour décrire ce que vous voulez élever dans le cluster, et Ansible pour travailler à l'intérieur. Entrez et mettez quelque chose dans la coquille - maintenant une sauvagerie absolue. Oui, c'est plus rapide et plus pratique, mais dans le nouveau paradigme, c'est de la folie: rappelez-vous d'exe.

Cours de plongée profonde


Comment puis-je voir une manière technique spécifique afin de comprendre comment travailler avec une pile moderne?

1) Créez un compte d'essai sur l'hébergement cloud. Tous les hébergeurs les fournissent. J'ai commencé avec GKE, mais vous pouvez, par exemple, prendre un compte sur les services d'hébergement russes, si vous vous attendez à travailler, très probablement, sur ce territoire.
Si Terraform / Pulumi prend en charge votre cloud, décrivez l'infrastructure que vous souhaitez y créer. Si vous avez des compétences en programmation, je recommande Pulumi: au lieu de votre propre Terraform SDL, vous pouvez écrire dans des langages et des constructions familiers.

2) Trouvez l'application et emballez-la dans le docker. Qu'y a-t-il à emporter - à vous de choisir. J'ai soudain découvert par moi-même comment NodeJS s'est généralisé et j'ai décidé de faire une étude approfondie de son fonctionnement, alors je continue à travailler avec le nœud. Voici, par exemple, un blog sur NodeJS , qui peut être soulevé, mais en général tout est à votre discrétion.

3) Traitez les constructions de base (pour, déploiement, service) de K8S et déployez l'application avec vos mains dans le cluster K8S.

4) Traitez avec Helm, rédigez un graphique Helm, déployez une application Helm.
Prenez un plan gratuit sur CircleCI en tant que CI-ke, qui n'a pas besoin d'être défini, et configurez: les configurations seront similaires à d'autres systèmes.

5) Corrigez l'application via CI-ku.
Séparez le CI (ce que l'application crée) et le CD. Créez un CD par GitOps (voir, par exemple, ArgoCD).

Et après


Quelque part à partir de maintenant, vous, en principe, serez au courant des principales bases de la pile moderne.
Où puis-je aller creuser plus loin?

  • Si vous cherchez un emploi / souhaitez travailler en Occident, vous pouvez aller à une connaissance plus approfondie du cloud computing: soumettre un certificat Google ou équivalent d'AWS à Cloud Architect (nous avons récemment reçu 3 de ces certificats chez ITSumma ). Cela vous donnera une idée des fonctionnalités offertes par Cloud et les aidera à naviguer. Bon cours sur la linuxacademy .
  • Passez au CKA: c'est un sujet difficile, mais qui en vaut la peine. La préparation à l'examen fournira un énorme ensemble de connaissances.
  • Apprenez à programmer si vous ne savez pas comment. Maintenant, je suis allé étudier le front et je suis étonné de voir comment tout a changé. Ma connaissance s'est terminée quelque part en 2012 ou même plus tôt, de retour dans jQuery, les gens rient. Le front est maintenant devenu plus compliqué que le backend, il y a une énorme quantité de logique d'application et en même temps complètement un paradigme pour moi inhabituel. Très intéressant!

Et je suis un peu plus régulier que le blog ici, je garde ma chaîne de télégramme , abonnez-vous :-)

More articles:


All Articles