Dans le prolongement de son premier blog consacré à Kubernetes en tant que fournisseur de services Cloud, Brad Campbell explique comment déployer une simple application « to-do » avec des définitions de ressources personnalisées.
Dans l’article précédent, nous avons abordé la question des définitions de ressources personnalisées et de leur utilité dans l’écosystème Kubernetes. Dans cet article, nous allons utiliser les définitions de ressources personnalisées de Crossplane pour les ressources AWS afin de déployer une simple application « to-do » avec ses ressources cloud directement via Kubernetes.
Déploiement d’une application avec des définitions de ressources personnalisées
Contexte
L’application elle-même s’inspire de l’application « Docker 101 Tutorial » de Docker. Il s’agit d’une petite liste de choses à faire SPA utilisant React. En fait, il s’agit essentiellement de la même application, avec une particularité : dans ma version de l’application, j’ai introduit l’utilisation d’AWS SNS pour publier les changements d’état des éléments individuels de la liste des tâches vers un (ou plusieurs) sujet(s). Bien que les possibilités d’intégration soient nombreuses avec ce type d’architecture (vous pouvez par exemple envoyer l’événement vers une fonction Lambda pour un traitement supplémentaire), j’ai simplement abonné mon téléphone portable au sujet et je reçois un message texte à chaque changement d’état d’un élément (par exemple : élément ajouté, élément marqué complet, élément marqué incomplet, élément supprimé).
Même s’il s’agit uniquement d’un exemple d’application intégrée au service géré d’un fournisseur de services Cloud dans le but de faire la démonstration d’un CRD, j’envisage de demander à mon fils aîné (qui suit ses cours à la maison cette année pour des raisons évidentes) d’utiliser cette application de tâches à faire avec l’intégration du SNS afin que je reçoive des notifications en temps réel lorsqu’il a terminé ses devoirs.
Conteneurisation
Dans mon dépôt, j’ai créé un Makefile spécifique pour gérer le cycle de vie d’une image de conteneur – n’hésitez pas à y jeter un œil. Mais j’ai déjà fait le plus gros du travail ici : l’application avec toutes mes modifications est déjà empaquetée et poussée vers Dockerhub, ce qui rendra sa consommation dans notre cluster assez facile.
Orchestration
Avant Kubernetes et des concepts puissants tels que les définitions de ressources personnalisées (peut-être dans un scénario Docker auto-hébergé ou avec un service comme ECS), le paradigme aurait été de provisionner tous les services Cloud via Terraform (ou similaire), puis d’obtenir l’ARN du sujet SNS pour le conteneur, peut-être en le définissant comme une variable d’environnement dans une définition de tâche. Dans ce cas, nous allons cependant laisser Kubernetes orchestrer cela pour nous par le biais du Crossplane AWS CRD for SNS Topics. Mas sachez que cette approche nécessite des compromis. Tout en restant parfaitement subjectif, je classe chacun d’entre eux dans la catégorie des avantages ou des inconvénients de l’approche.
Avantages
- Aucun outil distinct n’est nécessaire pour l’orchestration de services tiers. En d’autres termes, dans un modèle purement libre-service, un développeur écrit un peu de YAML supplémentaire avec sa définition de service pour se procurer les services Cloud dont il a besoin, au lieu de YAML pour définir le service (d’application), Terraform pour se procurer les services (de plateforme), parfois du code pour récupérer les ARN ou d’autres identifiants de service vers le cluster, etc.
- Le cycle de vie des services de plateforme spécifiques aux applications est plus étroitement lié aux applications et aux environnements auxquels ils sont associés.
- En conséquence de ce dernier point, les déploiements d’applications deviennent moins liés aux contextes environnementaux et plus portables entre ces contextes.
Inconvénients
- Les clusters Kubernetes ont besoin d’une plus grande marge de manœuvre du point de vue de l’IAM pour gérer les services basés sur les fournisseurs. Puisque le cluster crée lui-même les ressources, il a besoin des autorisations appropriées à cet effet.
- L’optimisation des coûts devient un exercice beaucoup plus difficile, car ce modèle de déploiement entraînera probablement une diminution de l’utilisation des services partagés dans l’ensemble du parc Cloud.
Déploiement de l’application
Maintenant que vous comprenez les avantages potentiels de l’utilisation des CRD pour gérer les ressources Cloud, essayons de déployer notre application. J’ai inclus une série de scripts dans le référentiel de l’application pour nous aider à la déployer. Une fois de plus, j’utiliserai minikube pour la durée de cet article. Tous les scripts se trouvent dans le dossier k8s_deploy/sns. Avec un démarrage de minikube, tout fonctionne localement, travaillons sur le déploiement.
Créer l’espace de noms
L’espace de noms est une structure organisationnelle qui nous permet de rassembler nos ressources. Pour le créer :
$ ./01_namespace.sh namespace/101-todo created
Créer un Persistent Volume (PV)
Par défaut, l’application todo utilise SQLite pour stocker ses données (elle propose également MySQL, mais nous nous en tenons ici à SQLite). Créons une ressource PersistentVolume pour y enregistrer la base de données :
$ kubectl apply -f 02_pv.yml persistentvolume/todos-db created
Créer un Persistent Volume Claim (PVC)
Afin d’utiliser le PV créé à l’étape précédente, nous devons créer un Claim :
$ kubectl apply -f 03_pvc.yml persistentvolumeclaim/todos-db-pvc created
Installer Crossplane
Crossplane possède à la fois des composants internes au cluster et des composants externes au cluster (comme un plugin kubectl) qui doivent être installés. L’installation de Crossplane requiert également des identifiants AWS. Ces identifiants sont enregistrés en tant que Kubernetes Secret dans le cluster. Les identifiants fournis dans cette étape doivent avoir la capacité de créer, mettre à jour et supprimer toutes les ressources AWS que vous souhaitez gérer avec Crossplane. Dans ce cas, les identifiants que je fournis sont enregistrés dans mon fichier d’identifiants local sous l’entrée brad-pers-infrabook :
$ ./04_install_crossplane.sh brad-pers-infrabook + kubectl create ns crossplane-system namespace/crossplane-system created ... [additional output] ...
Cela installe tous les composants de Crossplane et configure Crossplane avec les identifiants nécessaires pour provisionner les ressources dans le compte associé.
Configurer App Credentials Secret
Notre application publie des messages sur un sujet SNS. Une fois encore, nous nous appuyons sur les identifiants IAM à cet effet. Tout d’abord, copiez le fichier d’exemple dans un nouveau fichier :
$ cp 05_secret.example.yml 05_secret.yml
Rassemblez un ensemble approprié d’identifiants et placez-les dans le fichier 05_secret.yml, puis appliquez la configuration :
$ kubectl apply -f 05_secret.yml secret/aws-creds created
Créer la rubrique SNS
C’est maintenant que cela devient intéressant. En utilisant kubectl et un fichier de configuration, nous créons le sujet SNS que notre application utilise comme bus de messages :
$ kubectl apply -f 06_sns.yml snstopic.notification.aws.crossplane.io/101-todo-app created
Dans mon compte, je vois maintenant la rubrique :
Déployer l’application
L’ARN de la rubrique est disponible en tant qu’annotation sur la ressource. Le script 07_deployment_subst.sh saisit cette annotation en décrivant la ressource avec kubectl puis l’injecte dans le fichier modèle du déploiement (08_deployment.tpl.yml) pour créer le fichier de configuration du déploiement qui sera appliqué (08_deployment.yml). Tout ce processus est aussi simple que l’exécution du fichier 07 :
$ ./07_deployment_subst.sh deployment.apps/101-todo-deployment created
Enfin, créons le service pour le déploiement :
$ kubectl apply -f 09_service.yml service/todo-svc created
Accéder à l’application
Maintenant que le service est créé, accédons-y. La dernière chose à faire est d’exécuter le script 10_access_service.sh, qui crée un tunnel vers la VM qui exécute le nœud minikube accessible localement :
$ ./10_access_service.sh Démarrage du tunnel pour le service todo-svc. |-----------|----------|-------------|------------------------| | ESPACE DU NOM | NOM | PORT CIBLE | URL | |-----------|----------|-------------|------------------------| | 101-todo | todo-svc | | http://127.0.0.1:61933 | |-----------|----------|-------------|------------------------| http://127.0.0.1:61933
❗ Comme vous utilisez un pilote Docker sur darwin, le terminal doit être ouvert pour l’exécuter.
Et voici l’application !
Pendant ce temps, j’ai inscrit mon numéro de téléphone portable dans la rubrique SNS afin de recevoir des notifications sur les nouveaux événements.
Ajouter un élément
En ajoutant un message, je le vois apparaître dans l’interface utilisateur :
Et voici le message !
L’application dispose également d’un code permettant d’envoyer des notifications sur les éléments marqués comme complets, incomplets ou supprimés. Dans la configuration décrite ici, je m’appuie sur une fonctionnalité qui repose sur une rubrique par défaut pour les notifications de plusieurs fonctions. Cependant, si vous le souhaitez, vous pouvez configurer des rubriques distinctes pour les fonctions d’ajout, de suppression et de mise à jour : consultez les fichiers du répertoire app/src/routes pour connaître les variables d’environnement à définir si vous voulez essayer (remarque : vous devrez également modifier les spécifications des pods dans le modèle de déploiement pour prendre en compte les nouvelles variables, ainsi que les nouveaux sujets dans les fichiers 06 et 07).
Conclusion
Pour résumer, nous avons installé Crossplane, nous l’avons configuré pour l’utiliser dans notre compte AWS, puis nous avons déployé une application et ses dépendances AWS à l’aide des processus de déploiement Kubernetes standard. Même si le cas d’utilisation de la rubrique SNS dans l’application était un peu tiré par les cheveux (à titre d’illustration), j’espère qu’il vous a fait découvrir les possibilités de regrouper les dépendances basées sur le Cloud pour les applications fonctionnant sur Kubernetes, en plus de vos outils de déploiement.
Il convient également de mentionner qu’AWS est en train de mettre au point son propre ensemble de CRD pour la gestion des ressources, mais à l’heure où nous écrivons ces lignes, ils sont encore en phase de développement.
Bien que mon mélange de scripts shell et de fichiers YAML ne soit pas des plus élégants, j’espère qu’il a permis de clarifier un peu le processus. Si vous recherchez quelque chose d’un peu plus élégant, je vous recommande d’essayer Helm.
Et à propos de Helm, restez à l’écoute – nous allons bientôt examiner la création de graphiques Helm ici !
Découvrez comment Kubernetes peut aider votre entreprise à se moderniser
Notre Kubernetes Launchpad est une solution à fort impact qui aide les équipes d’entreprise à découvrir rapidement les avantages du développement d’applications Cloud natives en déployant rapidement une plateforme DevOps et en replatformant une application sur la plateforme cloud de votre choix : AWS, GCP ou Azure.
