Get best of the week

Comment devenir ingénieur DevOps en six mois ou plus vite. Partie 6. Lancement de l'application

Comment devenir ingénieur DevOps en six mois ou plus vite. Partie 1. Introduction
Comment devenir ingénieur DevOps en six mois ou même plus rapidement. Partie 2. Configuration
Comment devenir ingénieur DevOps en six mois ou même plus rapidement. Partie 3. Versions
Comment devenir ingénieur DevOps en six mois ou même plus rapidement. Partie 4.
Packaging logiciel Comment devenir ingénieur DevOps en six mois ou même plus rapidement. Partie 5. Déploiement



La photo ci-dessus montre la vitesse de déploiement d'applications traditionnelles. Et si vous avez passé un mois à vous entraîner, vous êtes maintenant à l'étape 5 de la feuille de route:



Prêt à lancer?


Donc, nous avons notre code écrit, empaqueté et déployé quelque part. J'ai décidé d'ignorer le déploiement de code en tant qu'artefacts immuables de la machine (comme EC2) et de me concentrer sur les conteneurs. Pourquoi?

Parce que cuire une AMI immuable dans le code source, la copier partout puis l'exécuter est très difficile. C'est un bon modèle, mais seulement si c'est absolument nécessaire. Par conséquent, je vous exhorte à vous demander si vous avez vraiment besoin de faire exactement cela, et sinon, essayez de réorganiser vos microservices en conteneurs ou en fonctions sans serveur.

Dans le cas où les conteneurs ne sont pas possibles, puisque vous décidez d'écrire, d'empaqueter et de déployer votre logiciel en tant qu'application monolithique, alors considérez le modèle AMI immuable. Faites de même si vous devez exécuter vos propres applications non cloud ou logiciels commerciaux livrés tels quels (tels quels). Cependant, ce n'est pas le sujet principal de cet article.

Si nous avons des conteneurs soigneusement emballés, comment les lancer?

Des conteneurs vraiment fonctionnels


La chose la plus simple que vous puissiez faire est d'exécuter simplement la commande docker run myImage et de la terminer. Mais ce n'est pas une bonne idée, car une telle solution ne fonctionne pas si:

  • ce conteneur "meurt" subitement;
  • vous devez avoir plus d'un conteneur pour gérer la charge
  • vous devez implémenter un déploiement sans temps d'arrêt;
  • Vous voulez un contrôle complet sur vos microservices
  • vous souhaitez utiliser le convoyeur CI / CD pour livrer rapidement le produit aux clients
    , etc ...

En d'autres termes, que se passe-t-il lorsque vous devez créer une véritable application distribuée au niveau de l'entreprise? De toute évidence, il s'agit d'un processus si complexe que la commande primitive docker run ne peut tout simplement pas le gérer.

Notez que la technologie de commande docker-compose souffre d'un ensemble de problèmes très similaires. Docker-compose, qui vous permet d'exécuter de nombreux services avec une seule commande, n'est pas destiné aux déploiements de production. Son objectif est le prototypage local, les tests fonctionnels rapides ou les déploiements à très petite échelle (par exemple, à domicile). En bref, c'est un outil pour les charges de travail des utilisateurs qui ne génèrent pas de revenus commerciaux.

Ainsi, l'orchestration de conteneurs se précipite à la rescousse!

Un aperçu des méthodes d'orchestration de conteneurs


Comme pour tout le reste de la vie, il existe plusieurs façons de résoudre le problème. Le premier et le plus évident est Kubernetes . Né d'un projet interne à Google, Kubernetes est la norme de facto pour l'orchestration de conteneurs.



En outre, c'est la seule option si vous exécutez votre application dans:

  • centre de données privé;
  • Google Cloud
  • Microsoft Azure
  • tout autre cloud public.

Cependant, si vous travaillez dans AWS, vous avez une option supplémentaire - ECS. Bien que, à proprement parler, ce ne soit pas tout à fait vrai: vous avez Nomad de Hashicorp (ce sont les mêmes personnes qui vous ont donné Terraform) et vous avez Docker Swarm de Docker. Le problème est qu'il existe de nombreuses plates-formes de niche avec une mise en œuvre minimale, donc pour une croissance rapide de carrière, nous les ignorons.
Quoi qu'il en soit, revenons à AWS Elastic Container Services (ECS). Il s'agit d'un service d'orchestration de conteneurs entièrement géré, assez simple à démarrer, qui est étroitement intégré au reste de l'écosystème AWS. Il fait juste quelques petites choses, mais il les fait bien. En bref, c'est à peu près le contraire de Kubernetes, et si ECS était assez bon pour McDonald's, alors c'est probablement assez bon pour vous aussi.

Cependant, uniquement en termes d'avancement professionnel immédiat, il ne fait aucun doute que Kubernetes est le meilleur choix. Bien que je parie que 99% des entreprises travaillant dans AWS satisferont également parfaitement ECS.

Alors maintenant, vous pouvez faire un choix. Si vous êtes un noob complet dans ce domaine, vous pouvez vous tempérer avec Kubernetes, car en dehors de l'équipe d'ingénieurs DevOps partageant les mêmes idées qui peuvent vous soutenir dans votre voyage n'est pas une tâche facile! L'image ci-dessous montre comment un futur ingénieur DevOps explore un système d'accès basé sur les rôles Kubernetes.



Cependant, cela est certainement possible, en particulier avec les offres gratuites Google et AWS, les didacticiels YouTube / Udemy et les prix au comptant AWS. Si vous avez choisi cette route, je vous recommande de commencer par le niveau gratuit ou le niveau kops gratuit de Google Cloud Platform, qui lance des instances AWS ponctuelles. Kubernetes (EKS) fonctionnant sur Amazon coûte de l'argent et, bien que adapté aux charges de travail de production, n'est pas un bon moyen pour commencer à apprendre à exécuter correctement les applications. Et je ne connais pas assez Azure pour le recommander.
Cependant, si vous n'êtes pas nouveau dans ce domaine et travaillez vraiment au sein de l'écosystème AWS, mon conseil est le suivant. Rendez vos microservices conteneurisés et déployez-les sur ECS pour dormir paisiblement la nuit et travailler en parallèle pour créer une plate-forme Kubernetes de classe mondiale. Le fait est que vous immerger dans Kubernetes est comme un "rasage de yaks", que vous ne pouvez même pas imaginer, et vous distraira inévitablement de votre véritable mission - livrer rapidement et efficacement des produits aux clients.

Remarque: «Yak shaving» est un terme de programmation qui signifie une série de tâches qui doivent être terminées avant qu'un projet puisse passer à son prochain jalon. Il a été inventé par Carlin Vieri, inspiré de l'épisode "The Ren & Stimpy Show". Le nom du terme fait allusion à la futilité apparente des tâches effectuées, même si elles peuvent être nécessaires pour résoudre un problème plus vaste.

Avez-vous vraiment besoin de Kubernetis? Non. Et si tu veux vraiment travailler avec lui? Alors oui". Clair? Le marché dit: «soit Kubernetes, soit rentre chez toi». Jetons donc un coup d'œil à ce à quoi vous vous abonnez en contactant cette chose.

Premièrement, malgré l'impression d'une technologie de pointe, l'idée de Kubernetes est relativement ancienne. Lorsque Google a supprimé les wrappers de Borg (le prédécesseur de Kubernetes) en 2015, c'était déjà une idée assez ancienne.

Lisez ceci: «Nous fournissons une brève description de l'architecture et des caractéristiques du système Borg, des décisions de conception importantes, une analyse quantitative de certaines de ses décisions politiques et une analyse qualitative des enseignements tirés de dix années d'expérience de travail avec lui.» Relisez-le! En 2015 (!), Google a partagé les détails du lancement d'un système similaire à Kubernetes, qui avait alors plus de dix ans.



Cependant, ils ne sont pas timides. Voici la première phrase de la page d'accueil de Kubernetes: «Kubernetes (K8s) est un système open source pour automatiser le déploiement, la mise à l'échelle et la gestion des applications conteneurisées. Il regroupe les conteneurs qui composent l'application en blocs logiques pour faciliter la gestion et la découverte. Kubernetes s'appuie sur ses 15 années d'expérience avec les charges de travail de Google, combinées aux meilleures idées et pratiques de la communauté. "

Donc, la prochaine fois que vous entendrez quelqu'un présenter Kubernetes comme une nouvelle idée «chaude», prête à conquérir le monde, rappelez-vous simplement qu'il représente une technologie qui a maintenant au moins quinze ans. N'est-ce pas un peu innovant?
Deuxièmement, pensez au public cible. Google crée des outils pour résoudre les problèmes de Google et de Google. Encore une fois, la page d'accueil de Kubernetes dit très clairement à ce sujet: "Échelle planétaire: conçue sur les mêmes principes qui permettent à Google de lancer des milliards de conteneurs par semaine, Kubernetes peut évoluer sans augmenter votre équipe d'opérations."

Enfin, l'un des développeurs originaux de Kubernetes et son partisan le plus actif, Kelsey Hightower, souligne également ce point: «Kubernetes est destiné aux personnes qui construisent des plateformes entières. Si vous êtes un développeur créant votre propre plate-forme (AppEngine, Cloud Foundry ou un clone Heroku), Kubernetes est ce dont vous avez besoin. »

Ainsi, si vous travaillez à l'échelle planétaire, lancez des milliards de conteneurs par semaine ou créez un cloud pour d'autres utilisateurs, Kubernetes est le bon choix. Et sinon, ce n'est pas la fin de l'histoire. Et je me fiche que votre grand-mère ait lu un tas de tweets Kelsey pendant la pause déjeuner, puis a converti son site Web de fleuriste en Kubernetes en une semaine en utilisant CI / CD et l'analyse automatisée des Canaries. Ce n'est pas le bon outil pour vous, sauf si la nature de votre produit vous oblige à l'utiliser.

Mais est-ce que c'est vraiment important? Kubernetes = $$$. Alors passez au niveau supérieur, profitez de votre voyage dans le monde DevOps et partagez vos expériences avec moi.
Note du traducteur: l'article n ° 7 sur la surveillance des applications basées sur ELK Stack n'a pas encore été publié.

A suivre très prochainement ...

Un peu de publicité :)


Merci de rester avec nous. Aimez-vous nos articles? Vous voulez voir des matériaux plus intéressants? Soutenez-nous en passant une commande ou en recommandant à vos amis, le cloud VPS pour les développeurs à partir de 4,99 $ , un analogue unique de serveurs d'entrée de gamme que nous avons inventé pour vous: Toute la vérité sur VPS (KVM) E5-2697 v3 (6 cœurs) 10 Go DDR4 480 Go SSD 1 Gbit / s à partir de 19 $ ou comment diviser le serveur? (les options sont disponibles avec RAID1 et RAID10, jusqu'à 24 cœurs et jusqu'à 40 Go de DDR4).

Dell R730xd 2 fois moins cher au centre de données Equinix Tier IV à Amsterdam? Nous avons seulement 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV à partir de 199 $ aux Pays-Bas!Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - à partir de 99 $! En savoir plus sur la création d'un bâtiment d'infrastructure. classe c utilisant des serveurs Dell R730xd E5-2650 v4 coûtant 9 000 euros pour un sou?

More articles:


All Articles