Il ne serait guère faux de dire que les meilleurs des hommes
trouvent la joie à travers la souffrance.
Ludwig van Beethoven
Je suis Sergey, je travaille chez Yandex.Money dans l'équipe de recherche sur les performances. Je souhaite vous raconter le début de l'histoire de notre parcours vers l'utilisation de l'orchestration – comment nous avons choisi les outils et ce que nous avons pris en compte. Tous les événements de l'article se déroulent en temps réel, donc vous, chers lecteurs, suivez l'évolution de la situation presque en direct.
Pourquoi avons-nous besoin d'un chef d'orchestre dans l'équipe ?
Qui est donc ce chef d'orchestre ? Du fr. diriger – gérer, orienter, diriger – dans le monde de la musique, c'est une personne, le responsable du travail et de l'exécution de la musique d'ensemble. Dans notre cas, ce rôle est occupé par des systèmes d'orchestration et d'automatisation.
Leur rôle n'est pas différent de celui d'un chef d'orchestre dans la musique – ils sont nécessaires pour aider l'équipe, diriger et organiser son jeu.
En règle générale, l'équipe dispose d'un certain ensemble de capacités – appelons-les des serveurs, sur lesquels elle réalise ses projets.
L'approche pour obtenir et exploiter ces serveurs est variée. Plusieurs exemples :
- L'équipe fait une demande, par exemple à l'équipe d'exploitation, pour qu'on leur fournisse des ressources avec des paramètres spécifiques.
- L'équipe d'exploitation leur fournit le nombre nécessaire – cloud ou bare metal (« matériel nu ») – et s'engage à les maintenir en bon état selon le SLA. La configuration est également effectuée par l'équipe d'exploitation.
- L'équipe ne reçoit que des ressources cloud ou bare metal de l'équipe d'exploitation, la configuration est faite par elle-même.
- L'équipe « achète » elle-même les ressources et les maintient/configure entièrement de manière autonome.
Dans notre équipe, nous utilisons des serveurs qui nécessitent un entretien – mise à jour du système d'exploitation, installation de nouveaux paquets, etc.
Nous les avons classés en deux types principaux :
- groupe de chars,
- groupe de services.
Le groupe de chars se compose d'hôtes avec Yandex.Tank.
Le groupe de services comprend tout ce qui concerne le support, – ce sont divers services liés au soutien du cycle de livraison, à la génération de rapports automatiques, etc.
À un moment donné, il est devenu difficile de gérer tout cela manuellement, et nous avons pensé à automatiser tout le processus, depuis le "déploiement" des serveurs jusqu'à la conception, la mise en ligne et le lancement de notre service interne.
Pourquoi un chef d'orchestre est-il nécessaire, même si l'orchestre sait jouer tout seul ?
Pour commencer, nous avons maîtrisé Ansible et avons commencé à "déployer" nos serveurs bare metal, afin d'être moins dépendants des administrateurs système. Tout le monde y gagne, nous acquérons de nouvelles compétences et nous soulageons les administrateurs d'une partie du travail qui leur prend déjà beaucoup de temps. Nous nous efforçons de nous développer en dehors de notre spécialité et d’atteindre autant que possible l'autonomie de l'équipe.
Dans l'entreprise, le travail avec Ansible est déjà bien configuré et régulé depuis un certain temps, nous avons donc facilement intégré notre solution dans ce processus.
Actuellement, le déploiement des hôtes se compose de trois rôles Ansible :
- le premier rôle installe l'OS,
- le deuxième applique les configurations de base pour l'hôte, comme l'autorisation LDAP par exemple,
- et le troisième installe Yandex.Tank dans un conteneur Docker ainsi que les dépendances associées.
Passons aux services que nous utilisons au sein de l'équipe.
Pour nos besoins, nous utilisons autant Kotlin que Python, et un peu de Golang. Pour unifier le développement et le déploiement de nos services, nous avons décidé de les empaqueter dans des conteneurs Docker. Cela nous donne la liberté de choisir le langage de programmation tout en maintenant un format de livraison uniforme pour notre application.
Une petite remarque sur IPv6 dans Docker
Une partie des services avec lesquels nous interagissons n'est accessible qu'en IPv6, nous avons donc dû comprendre comment configurer l'IPv6 pour les conteneurs.
Selon la documentation sur l'IPv6 sur le site officiel de Docker, l'IPv6 s'active en ajoutant des paramètres dans daemon.json :
{
"ipv6": true,
"fixed-cidr-v6": "2001:db8:1::/64"
}Dans ce cas, le fournisseur doit fournir un sous-réseau IPv6 que vous devez indiquer dans fixed-cidr-v6.
Cependant, nous avons choisi une autre option — NAT IPv6, et voici pourquoi :
- Actuellement, Docker uniquement avec IPv6.
- La présence d'une adresse globalement routable dans chaque conteneur signifie que tous les ports (même ceux non publiés) deviennent accessibles à tous, sauf si un filtrage supplémentaire est effectué.
- proxy userland pour la publication des ports, .
NAT IPv6 est , qui gère lui-même les règles dans ip6tables et les édite lors de l'ajout d'un nouveau conteneur.
Pour que cette solution fonctionne correctement, il était nécessaire d'effectuer plusieurs autres manipulations. Il faut obligatoirement initialiser ip6table_nat dans le système. La présence du module installé dans le système ne garantit pas que le module sera chargé dans le noyau lors du démarrage. Nous avons rencontré ce problème lorsque nous avons reçu l'erreur suivante lors du lancement d'un conteneur avec NAT sur un nouvel hôte :
2019/01/22 14:59:54 running [/sbin/ip6tables -t filter -N DOCKER --wait]: exit status 3: modprobe: can't change directory to '/lib/modules': No such file or directory
ip6tables v1.6.2: can't initialize ip6tables table `filter': Table does not exist (do you need to insmod?)Le problème a été résolu après avoir ajouté dans le rôle Ansible l'initialisation à l'aide du module modprobe et le chargement au démarrage du système avec lineinfile :
- name: Add ip6table_nat module
modprobe:
name: ip6table_nat
state: present
- name: Add ip6table_nat to boot
lineinfile:
path: /etc/modules
line: 'ip6table_nat'Au fait, il y a un bon article sur Habr , qui décrit brièvement et clairement les avantages et inconvénients des différentes méthodes pour travailler avec ipv6 dans docker.
Mais revenons à notre question posée au début :
Pourquoi un chef d'orchestre est-il nécessaire, même si l'orchestre sait jouer tout seul ?
Maintenant, tout le monde comprend comment jouer dans notre équipe :
- le processus de "nappe" des serveurs est établi,
- le développement et le déploiement des services sont unifiés.
Une question légitime se pose — comment déployer, mettre à jour et contrôler nos services dans des conteneurs docker de manière efficace et aussi automatisée que possible ?
Bien que chaque membre de l'orchestre connaisse sa partie, il peut s'égarer, s'éloigner de l'idée initiale. C'est ici que nous en venons au fait que sans chef d'orchestre, notre orchestre ne pourra pas répéter efficacement et jouer harmonieusement. Le chef d'orchestre est responsable de tous les paramètres d'exécution, veillant à ce que tout soit réuni dans un seul tempo et une seule humeur.
Comment obtenir un bon chef d'orchestre avec un investissement minimal ?
Le thème de l'orchestration est assez bien développé sur le marché. Mais d'abord, parlons des outils auxiliaires qui peuvent aider le chef d'orchestre.
— un système qui fournit deux fonctions principales :
- découverte de services (service discovery),
- stockage clé-valeur distribué.
Dans notre orchestre, Consul sera responsable de l'enregistrement des services et du stockage de leurs configurations. Il existe deux options d'enregistrement :
- Active — c'est lorsque le service s'enregistre lui-même en utilisant l'API HTTP ;
- Passive — le service doit être inscrit manuellement.
Vault est un stockage qui standardise et unifie la sauvegarde sécurisée et l'utilisation des secrets – mots de passe, certificats.
Voici les avantages que nous obtiendrons en utilisant cet outil :
- Un centre unique de création et de stockage de secrets, gérant leur cycle de vie via une API HTTP.
- Transit Secrets Engine – chiffrement-déchiffrement des données sans leur conservation. Possibilité de transmettre des données de manière chiffrée sur des canaux de communication non sécurisés.
- Des politiques d'accès facilement configurables.
- Audit des accès aux secrets.
- Possibilité de créer une propre CA (Autorité de Certification) pour gérer les certificats auto-signés au sein de votre infrastructure.
En tenant compte de toutes nos exigences, deux options convenaient pour le rôle de chef d'orchestre – Kubernetes et Nomad.
Kubernetes
Combien d'articles et de livres ont déjà été écrits à ce sujet (voici , par exemple), de conférences ont été tenues, donc je vais écrire brièvement – c'est une combinaison universelle qui peut pratiquement tout faire. Le prix à payer est que la configuration et le maintien d'un cluster sur Kubernetes ne sont pas toujours simples.
Nomad
de HashiCorp, une entreprise connue notamment pour consul et vault mentionnés ci-dessus.
Nomad nous a semblé suffisamment simple à installer et à configurer, comparé à Kubernetes. Un seul fichier binaire fonctionne à la fois en mode serveur et client. De plus, Nomad couvre toute la liste des tâches qu'on souhaite qu'il résolve : gestion de cluster, planificateur rapide, support multidatacenter. De plus, en utilisant consul et vault, nous bénéficions d'une intégration plus étroite pour l'orchestration de nos services.
Ce qui est actuellement en cours :
- nous avons préparé les serveurs pour le déploiement de Consul,
- la configuration du cluster nomad sera intégrée dans Consul, ce qui permettra un déploiement automatique de nomad,
- nous allons parallèlement installer vault pour le stockage des secrets.
Question au public – faut-il un chef d'orchestre pour de telles tâches ou l'orchestration fonctionne-t-elle bien sans lui ? Dites-nous dans les commentaires ce que vous en pensez.
Abonnez-vous à notre blog et restez en contact – nous vous révélerons bientôt le résultat et si nous avons configuré le cluster nomad comme nous le souhaitions.
Rejoignez notre agréable , où vous pouvez toujours demander des conseils, aider vos collègues et simplement discuter des recherches en matière de performance et plus encore.
Source : habr.com
