Je veux raconter comment l'histoire a été lancée dans Openshift. Au cours de la lecture, nous considérons également des utilitaires pour gérer l'application dans Openshift. Ceci est une transcription de la performance au kubernetes SPB meetup # 3 ..
But
En règle générale, les clients sont déployés sur des serveurs distincts, mais la tâche est venue ici pour tester l'opportunité de s'exécuter dans openshift et de collecter le râteau.
Vous devez d'abord parler de notre application. Un projet avec une histoire riche. Utilisé dans de grandes organisations et probablement chacun de vous s'est indirectement recoupé. L'application prend en charge de nombreuses bases de données, intégrations, etc., etc.
Prérequis
L'application devrait fonctionner dans des environnements complètement différents. En conséquence, notre documentation d'installation est très complète. Mais si vous vous méprisez, alors rien de compliqué:
- Appliquer le schéma de base de données.
- Configurez le serveur d'applications.
- Installez une licence.
- Personnalisez l'application et l'intégration avec des systèmes externes.
Mais le monde est cruel, nous avons eu un certain nombre de restrictions:
- L'application ne peut être construite que sur Jenkins, qui est engagé dans la signature. Et seulement là.
- Il n'y a pas d'accès du client Openshift à l'environnement de développement.
- Pour un certain nombre de raisons idéologiques, il n'a pas été possible de réutiliser les images Docker existantes pour le développement.
- Nous avons des playbooks ansibles pour installer et configurer l'application sur les serveurs.
Démo du conteneur Ansible
Le conteneur Ansible est un logiciel open source qui vise à automatiser l'assemblage, le déploiement et le contrôle des processus du conteneur. Comme vous pouvez le deviner d'après le nom. Ansible est utilisé pour construire des conteneurs. Nous avons déjà écrit des rôles Ansible pour installer et déployer des applications sur des serveurs, nous avons donc décidé de ne pas réinventer la roue et de les réutiliser. Non seulement ce serait l'outil parfait, mais la réutilisation rapide des rôles existants a été un facteur décisif pour la démo.
Dans l'ensemble, afin de faire une démo, nous avons pris les rôles existants qui configurent tout et tout, et avons fait un "conteneur monolithique". Il n'y a eu aucun problème particulier lors de la collecte du conteneur, Openshift a quelques bonnes recommandations , mais je mentionnerai séparément:
- Les rôles devaient être finalisés. nous utilisons systemd.
- Par défaut, pour des raisons de sécurité, il est interdit d'utiliser certains appels système dans openshift. En conséquence, il y aura des nuances avec le chroot, le sudo. Salut CVE-2019-5736 .
- De même, pour des raisons de sécurité, le conteneur est lancé sous un utilisateur avec un ID aléatoire, il s'agit également d'un comportement personnalisé.
L'idée principale à ce stade est que nous avons fait une démo tellement vite.
Démo de plusieurs conteneurs
Le conteneur de démonstration a rempli son rôle et nous l'avons scié en composants séparés:
- Notre application.
- La base de données.
- Services externes, etc ...
La première chose que vous avez rencontrée, comment initialiser la base de données? Il est clair que nous utilisons des migrations, mais quand et comment les appliquer? Ici, il vaut la peine de donner un lien vers un merveilleux article décrivant le POD de l'appareil: la vie des POD . Dans l'ensemble, il existe plusieurs approches:
- Utiliser init-container
- Utilisez des systèmes d'orchestration qui détermineront l'ordre de déploiement des services et migreront les rouleaux si nécessaire.
Nous avons décidé de suivre le chemin du conteneur Init. C'est-à-dire dans le POD de notre application, avant le démarrage de notre application, un conteneur démarre qui effectue les migrations. Mais comment configurer l'application elle-même et les intégrations externes?
Initialisez l'application
Comme je l'ai déjà mentionné, notre application peut et doit fonctionner dans des environnements complètement différents, avec différentes bases de données et intégrations. Encore une fois, la question est de savoir comment tout configurer?
- Utilisez des systèmes d'orchestration qui déterminent l'ordre dans lequel les services sont déployés et appliquez la configuration après le démarrage de l'application.
- Passez les variables d'environnement au conteneur pour savoir comment configurer.
- Utilisez le crochet de démarrage.
- Créez un conteneur séparé qui contient la configuration et appliquez-le à l'application. Migration à peu près analogique pour la base de données.
Nous avons choisi la dernière approche, car il vous permet de rendre la configuration reproductible et autonome. Mais pour une raison quelconque, nous avons initialement créé ce conteneur dans un contrôleur de réplication séparé avec un facteur 1.
Ok, relisez la documentation.
Un pod (comme dans un pod de baleines ou de pois) est un groupe d'un ou plusieurs conteneurs (tels que les conteneurs Docker), avec un stockage / réseau partagé et une spécification sur la façon d'exécuter les conteneurs.
POD est un groupe de conteneurs. En conséquence, notre sous se composait de 3 conteneurs
- Initiez le conteneur pour initialiser un PostgreSQL.
- Conteneur avec application.
- Conteneur avec configuration d'application.
Boîte à outils
Nous avons obtenu un diagramme de l'apparence de l'application déployée. Il est maintenant temps de discuter des outils dans la nature, il y en a beaucoup qui sont déjà prêts, je vais examiner une partie de la liste ci-dessous et tirer des conclusions subjectives.
Modèles openshift
Modèles openshift
Avantages:
- Native et ils ont une excellente documentation.
Inconvénients:
- Un autre moteur de modèle.
- Fichiers YAML longs et terribles.
- Si vous avez des dépendances entre les services et leur ordre de démarrage, ce sera difficile.
Scripts et modèle
Avantages:
- Vous pouvez utiliser d'excellents outils et toute la puissance de la POO.
Inconvénients:
- Des béquilles qui soutiennent. Et pas seulement pour vous.
Fournisseur Terraform K8s
Avantages:
- Vous n'avez pas à vous soucier de la priorité de créer des éléments d'infrastructure.
- Vous pouvez réutiliser le code d'infrastructure en tant que modules.
- Vous pouvez ajouter une logique d'initialisation d'application.
Inconvénients:
- Pas de support pour Openshift, seulement k8s.
- Dock et modules parfois obsolètes.
- Une autre tula dans votre équipe.
Conteneur Ansible
Conteneur Ansible
Avantages:
Inconvénients:
- D'énormes images, car aller en une seule couche.
- Semble abandonné et non pris en charge. A été remplacé par la cintreuse Ansible .
Module Ansible K8s
Module Ansible + k8s
Avantages:
- Un playbook pour décrire toutes les infrastructures du projet dans Openshift.
- Réutilisation du code sous forme de rôles.
- Vous pouvez ajouter une logique d'initialisation d'application.
Inconvénients:
- Pas de support proxy.
- Vous vous occupez du déménagement. Si l'objet n'est plus nécessaire, décrivez son retrait.
- Vous décrivez vous-même la séquence de création des éléments d'infrastructure.
Pack de livres de jeu Ansible
L'utilitaire Ansible Playbook Bundle (APB) propose une approche: emballons les rôles ansibles pour déployer l'application dans k8s / openshift dans un conteneur et exécutons-le dans k8s / openshift.
Avantages:
- Je porte tout avec moi.
- Testable et reproductible.
- Intégration avec le catalogue de services (interface Web conviviale pour le lancement d'applications).
Inconvénients:
- Vous avez besoin de privilèges de niveau administrateur.
- La documentation laisse parfois beaucoup à désirer.
Résultat
Je ne veux pas être le dernier recours, mais je partagerai mes conclusions:
PS