Je voudrais partager mon histoire sur la migration d'une application vers Openshift. Par conséquent, je comparerai certaines des solutions et des outils les plus populaires pour gérer votre application dans Openshift. Il s'agit de la transcription de ma présentation au kubernetes SPB meetup # 3 .
Déployons sur Openshift
Que faut-il faire?
Tout d'abord, parlons de notre application. C'est une solution d'entreprise prête à l'emploi, elle prend en charge différentes bases de données, serveurs d'applications et interfaces d'intégration avec des systèmes tiers. Habituellement, nos clients installaient sur des serveurs dédiés, mais nous avons rencontré le problème. Nous avons dû régler l'application dans Openshift.
Prérequis
L'application est le produit avec une longue histoire, elle devrait fonctionner immédiatement dans des environnements complètement différents. En conséquence, il y a beaucoup de pages dans nos guides d'installation. Cependant, le schéma de niveau supérieur est simple comme bonjour, vous devriez juste:
- Appliquer le schéma DB.
- Préparez la configuration du serveur d'applications.
- Installez votre licence.
- Initialisez l'application.
Malheureusement, le monde est cruel, il y avait des conditions préalables importantes.
- Nous avons pu créer l'application uniquement sur un esclave Jenkins spécial, en raison de restrictions de sécurité
- Il n'y avait aucun accès depuis l'installation d'OpenShift du client au registre Docker des développeurs privés.
- Nous n'avons pas pu réutiliser les images Docker existantes, car elles ont été créées uniquement pour les besoins de développement et de test.
- Il y avait des playbooks ansibles pour le déploiement d'applications sur les machines virtuelles.
Démo du conteneur Ansible
Ansible Container est un projet open source qui vise à permettre l'automatisation de l'ensemble du processus de construction, de déploiement et de gestion de conteneurs. Mieux encore, il utilise le même langage d'automatisation Ansible simple, puissant et sans agent que vous utilisez déjà, ce qui vous permet d'automatiser l'ensemble du cycle de vie de l'application.
Nous avions déjà écrit quelques rôles Ansible pour installer l'application sur les machines virtuelles, nous les avons donc réutilisés avec ansible-container . Le conteneur Ansible est un ensemble d'outils pour la construction de conteneurs. Je ne suis pas sûr que ce soit vraiment un bon ensemble d'outils, mais il permet:
- Créez des conteneurs de la même manière que nous déployons nos serveurs.
- Arrêtez de chaîner les commandes shell dans Dockerfiles.
Il n'y avait pas de problème majeur avec ansible-container, car Openshift créant des lignes directrices d'images est génial. Cependant, je voudrais remarquer:
- Nous avons modifié nos rôles ansibles, car
Docker + systemd = pain . - Il n'y a pas de possibilité d'utiliser chroot, sudo dans Openshift par défaut, pour des raisons de sécurité. Lisez simplement CVE-2019-5736 .
- Pour des raisons de sécurité, Openshift est par défaut également générer un UID aléatoire pour chaque conteneur, en d'autres termes openshift ignore l'option USER d'un Dockerfile.
L'essentiel est que ansible-container nous a aidé à créer une démo très rapidement, à cause de la réutilisation.
Démo de plusieurs conteneurs
Le premier conteneur de démonstration a été construit via ansible-container. C'était assez bon pour la démo, cependant, nous avons décidé de ne pas l'utiliser. Nous avons divisé le conteneur monolithique en différents:
- Nous avons utilisé le conteneur Openshift PostgreSQL d'origine sans aucune modification.
- Nous avons construit le conteneur sans état de l'application.
Cependant, il n'était pas clair d'initialiser la base de données? Nous avons trouvé un excellent article sur la vie des POD à l' intérieur de Kubernetes. Nous avons donc décidé d'utiliser le conteneur init pour l'initialisation de la base de données.
Initialisez l'application
Comme je l'ai mentionné précédemment, l'application devrait fonctionner prête à l'emploi dans des environnements complètement différents, prendre en charge différents serveurs / bases de données d'application et interfaces d'intégration avec des systèmes tiers.
Il existe de nombreuses façons d'initialiser l'application:
- Passer la configuration via les variables d'environnement. Cela signifie ajouter toute notre documentation / connaissances sur la façon d'initialiser l'application pour chaque cas d'utilisation dans chaque conteneur. Ça ne sonne pas bien.
- Utilisez le crochet de démarrage, c'est à peu près le même que le premier.
- Initialiser lors de la mise à disposition d'OpenShift.
- Utilisez un conteneur externe avec une configuration individuelle pour chaque cas d'utilisation.
Nous avons choisi le dernier, nous avons créé un contrôleur de réplication supplémentaire pour initialiser l'application? Vraiment?
Nous avons relu 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, nous avons décidé d'exécuter 3 conteneurs dans un POD d'application
- Conteneur d'init pour une initialisation PostgreSQL.
- Le conteneur d'application.
- Conteneur d'initialisation d'application.
Cette approche permet de stocker notre configuration sous forme de code, il y a deux résultats intéressants: la configuration de l'application est testable et reproductible.
Il en existe déjà beaucoup pour la gestion d'OpenShift.
Pendant la migration, j'ai testé certains d'entre eux. J'aimerais partager mes résultats.
Modèles openshift
Modèles openshift
Avantages:
- Natif Il a une documentation impressionnante.
Inconvénients:
- Encore un autre modèle YAML.
- Journal horrible fichier YAML.
- Vous vous souciez des dépendances de services.
Scripts et modèle
Avantages:
Inconvénients:
Fournisseur Terraform K8s
Avantages:
- Ne vous souciez pas de créer de l'ordre.
- Réutilisez le code comme modules.
- Vous pouvez ajouter une logique d'initialisation.
Inconvénients:
- Pas de support OpenShift, uniquement des k8.
- Parfois dépassé.
- Encore un autre outil.
Conteneur Ansible
Conteneur Ansible
Avantages:
Inconvénients:
- D'énormes images, en raison d'une seule couche.
- Semble abandonné et obsolète.
Le conteneur Ansible a été remplacé par la cintreuse Ansible .
Module Ansible K8s
Module Ansible + k8s
Avantages:
- Playbook unique pour tous.
- Réutilisez le code comme rôles.
- Vous pouvez ajouter une logique d'initialisation.
Inconvénients:
- Pas de support proxy.
- Vous vous souciez d'enlever. Si vous souhaitez supprimer quelque chose, vous devez le déclarer.
- Vous vous souciez de créer de l'ordre. Vous devez déployer l'application avant l'initialisation.
Pack de livres de jeu Ansible
Un ensemble Ansible Playbook (APB) est une définition d'application légère (méta-conteneur). Ils sont utilisés pour définir et déployer des groupes complexes d'applications, de configurations de déploiement, de déploiements et de services sur un cluster OpenShift Origin exécutant Ansible Service Broker. Les APB offrent plus de puissance et une configuration simple en tirant parti de la puissance d'Ansible. Les APB ont les caractéristiques suivantes:
L'idée principale est que vous emballiez tout ce dont vous avez besoin dans un conteneur et que vous exécutiez le conteneur dans Openshift. Pack de livres de jeu Ansible
Avantages:
- Bundles tout.
- Testable et reproductible.
- Intégration du catalogue de services.
Inconvénients:
- Vous avez besoin des autorisations d'administrateur.
- La documentation est parfois obsolète.
Résultat
D'une part, je ne veux pas être l'autorité finale, mais d'autre part, je voudrais partager mon point de vue. Il n'y a pas de solution miracle.
PS