Il ne serait pas faux de dire que les meilleurs des gens
trouver la joie à travers la souffrance.
Ludwig van Beethoven
Je m'appelle Sergey et je travaille chez Yandex.Money au sein de l'équipe de recherche sur les performances. Je souhaite vous raconter le début 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 décrits dans cet article se déroulent en temps réel, vous permettant ainsi, chers lecteurs, de suivre l'évolution de la situation quasiment en direct.
Pourquoi avons-nous besoin d’un chef d’orchestre dans l’équipe ?
Qu'est-ce qu'un chef d'orchestre ? Du français « diriger » — gérer, diriger, mener —, dans le monde de la musique, il s'agit d'une personne qui dirige l'apprentissage et l'interprétation de la musique d'ensemble. Dans notre cas, ce rôle est occupé par les systèmes d'orchestration et d'automatisation.
Leur rôle n’est pas différent de celui d’un chef d’orchestre : ils sont là pour aider l’équipe, diriger et organiser sa performance.
En règle générale, une équipe dispose d'un certain ensemble de capacités - appelons-les serveurs - sur lesquelles elle implémente ses projets.
L'approche pour obtenir et exploiter ces serveurs varie. Voici quelques exemples :
- L'équipe fait une demande, par exemple au groupe des opérations, pour lui fournir des ressources avec certains paramètres.
- L'équipe d'exploitation leur fournit la quantité requise (cloud ou matériel nu) et s'engage à les maintenir en bon état conformément au SLA. La configuration est également assurée par l'équipe d'exploitation.
- L'équipe reçoit uniquement des ressources cloud ou bare metal du groupe d'exploitation et effectue elle-même la configuration.
- L’équipe elle-même « achète » les ressources et les maintient/configure de manière totalement indépendante.
Notre équipe utilise des serveurs qui doivent être maintenus - mises à jour du système d'exploitation, nouveaux packages installés, etc.
Pour notre part, nous les avons identifiés en deux types principaux :
- groupe de chars,
- groupe de service.
Le groupe de réservoirs est composé d'hôtes avec Yandex.Tank.
Le groupe de services comprend tout ce qui concerne la maintenance : il s'agit de divers services permettant de fournir un support pour le cycle de publication, de générer des rapports automatiques, etc.
À un moment donné, il est devenu gênant de gérer tout cela manuellement, et nous avons commencé à réfléchir à l’automatisation de l’ensemble du processus, du « chargement » des serveurs au développement, au déploiement et au lancement de notre service interne.
Pourquoi un chef d’orchestre est-il nécessaire, même si l’orchestre lui-même peut jouer ?
Pour commencer, nous avons maîtrisé Ansible et commencé à « réduire » la dépendance de nos serveurs bare metal aux administrateurs système. Tout le monde y gagne : nous acquérons de nouvelles compétences et déchargeons les administrateurs d'une partie du travail qu'ils ont toujours assez à faire sans nous. Nous nous efforçons autant que possible de développer des compétences en dehors de notre spécialité et de préserver l'autonomie de l'équipe.
L'entreprise travaille avec Ansible depuis un certain temps déjà, il est donc facile pour nous d'intégrer notre solution dans ce processus.
Actuellement, le provisionnement de l'hôte se compose de trois rôles Ansible :
- le premier rôle installe le système d'exploitation,
- le second exécute les paramètres de base pour l'hôte, l'autorisation LDAP, par exemple,
- et le troisième installe Yandex.Tank et les dépendances associées dans un conteneur Docker.
Passons maintenant aux services que nous utilisons au sein de l'équipe.
Pour nos tâches, nous utilisons Kotlin et Python à parts égales, ainsi qu'un peu de Golang. Afin d'unifier le développement et le déploiement de nos services, nous avons décidé de les intégrer dans des conteneurs Docker. Cela nous permet de choisir librement le langage de programmation et de garantir un format unique pour la livraison de votre application.
Une petite note sur IPv6 dans Docker
Certains des services avec lesquels nous interagissons ne sont disponibles que via IPv6, nous avons donc dû trouver comment créer IPv6 pour les conteneurs.
Selon la documentation IPv6 sur le site officiel de Docker, IPv6 est activé en ajoutant des paramètres à daemon.json :
{
"ipv6": true,
"fixed-cidr-v6": "2001:db8:1::/64"
}Dans ce cas, le fournisseur doit émettre un sous-réseau IPv6, que vous enregistrerez dans fixed-cidr-v6.
Cependant, nous avons choisi une autre option : ipv6 NAT, et voici pourquoi :
- Maintenant docker uniquement avec ipv6.
- Avoir une adresse routable globalement sur chaque conteneur signifie que tous les ports (même ceux non publiés) sont accessibles à tous, à moins qu'un filtrage supplémentaire ne soit effectué.
- proxy utilisateur pour la publication des ports, .
ipv6 NAT est , qui gère lui-même les règles dans ip6tables et les modifie lors de l'ajout d'un nouveau conteneur.
Pour que cette solution fonctionne correctement, plusieurs manipulations ont été nécessaires. Il est nécessaire d'initialiser ip6table_nat dans le système. L'installation d'un module ne garantit pas son chargement dans le noyau au démarrage. Nous avons rencontré ce problème lors du démarrage 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é l'initialisation au rôle Ansible à l'aide du module modprobe et le chargement au démarrage du système d'exploitation à l'aide de 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 en a un bon sur Habr , qui décrit brièvement et clairement les avantages et les inconvénients de telle ou telle méthode 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 lui-même peut jouer ?
Maintenant, tout le monde sait comment jouer dans notre équipe :
- le processus de « remplissage » des serveurs a été créé,
- le développement et le déploiement des services sont unifiés.
Une question raisonnable se pose : comment déployer, mettre à jour et contrôler nos services dans les conteneurs Docker de manière efficace et la plus automatisée possible ?
Bien que chaque membre de l'orchestre connaisse sa partie, il peut se perdre et s'écarter de l'idée initiale. 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 de la performance, de l'harmonie de l'ensemble, du tempo et de l'ambiance.
Comment obtenir un bon chef d’orchestre avec un investissement minimal ?
L'orchestration est un sujet assez répandu sur le marché. Mais commençons par les outils auxiliaires qui peuvent aider le chef d'orchestre.
— un système qui fournit deux fonctions principales :
- découverte de services,
- magasin de clés-valeurs distribué.
Dans notre orchestre, Consul sera responsable de l'enregistrement des services et du stockage de leurs configurations. Deux options d'enregistrement sont disponibles :
- Actif - c'est lorsque le service s'enregistre à l'aide de l'API HTTP ;
- Passif - le service doit être enregistré manuellement.
Vault est un stockage qui standardise et unifie le stockage sécurisé et la gestion des secrets - mots de passe, certificats.
Voici les avantages que nous obtiendrons en utilisant cet outil :
- Un centre unique pour créer et stocker des secrets, gérant leur cycle de vie via l'API HTTP.
- Transit Secrets Engine — chiffrement/déchiffrement des données sans enregistrement. Possibilité de transmettre des données chiffrées via des canaux de communication non protégés.
- Accédez à des politiques faciles à configurer.
- Audit des accès aux secrets.
- Possibilité de créer votre propre CA (Certificate Authority) pour gérer les certificats auto-signés au sein de votre infrastructure.
Compte tenu de toutes nos exigences, deux options étaient adaptées au rôle de chef d’orchestre : Kubernetes et Nomad.
Kubernetes
Combien d'articles et de livres ont déjà été écrits sur lui (ici (par exemple), des rapports, que j'écrirai brièvement, indiquent qu'il s'agit d'une moissonneuse-batteuse universelle capable de presque tout faire. Le prix à payer est la configuration et la prise en charge parfois difficiles du cluster sur Kubernetes.
Nomade
de HashiCorp, la société connue pour le consul et le coffre-fort susmentionnés.
Nous avons trouvé Nomad plus facile à installer et à configurer que Kubernetes. Un binaire fonctionne à la fois comme serveur et comme client. De plus, Nomad couvre l'ensemble des tâches que nous souhaitons lui confier : gestion des clusters, ordonnanceur rapide et prise en charge multi-datacenters. De plus, l'utilisation de consul et de vault nous permet de bénéficier d'une intégration plus étroite pour l'orchestration de nos services.
Ce qui est en préparation actuellement :
- serveurs préparés pour le déploiement de Consul,
- Consul sera rempli avec la configuration du cluster nomade, qui devrait déployer nomad automatiquement,
- En parallèle, nous installerons un coffre-fort pour stocker les secrets.
Question au public : est-il utile d'avoir un chef d'orchestre pour de telles tâches ou l'orchestre peut-il se passer de lui ? Dites-nous ce que vous en pensez dans les commentaires.
Abonnez-vous à notre blog et restez en contact - nous vous dirons bientôt ce qui s'est passé au final et si nous avons mis en place le cluster nomade comme nous le souhaitions.
Entrez dans notre chaleureux , où vous pouvez toujours demander des conseils, aider vos collègues et simplement discuter de la recherche sur la productivité et plus encore.
Source: habr.com
