Déployer API Platform sur Kubernetes quand on ne l'a jamais fait - partie 5

Version utilisée : 3.1

Attention : Ce ne sera pas facile.
Connaitre le fonctionnement de API Platform n'est pas un pré-requis. Si vous n'avez jamais fait de Docker, pas de souci, je récapitule quelques concepts et fondamentaux lorsque je trouve que c'est nécessaire. Je vais les précéder du symbole :

Dans la partie 4 nous avons utilisé Minikube pour tester localement, mais il arrive souvent que les projets soient trop gros et qu'il faille déployer sur Kubernetes en développement. Lançons-nous !

Moment crucial ! A-t-on bien appris notre leçon ? Cette étape est source de douleur, alors plutôt que d'écrire en pensant que tout va bien, je vais volontairement utiliser un fournisseur qui m'est inconnu et partager mes peines. Lorsque vous les rencontrerez, vous aurez une idée de la raison.

Je constate que je pouvais mettre à jour la version de Postgresql, alors je modifie le chart.yaml https://github.com/bitnami/charts/blob/master/bitnami/postgresql/Chart.yaml au profit de la 12.6.0 au moment de l'écriture de ce document.
Pour que ce soit pris en compte, il faut mettre à jour les dépendances de Helm (https://github.com/helm/helm/issues/8036).

Il est temps de trouver un fournisseur de gestion de conteneur en ligne.

Alors, parmi les différents fournisseurs (GCP, AWS, etc), j’ai choisi Digital Ocean (ce n'est pas du tout sponsorisé, j'aurais pu opter pour notre offre PtitKube) pour sa facilité de mise en œuvre. Je n'aurais pas à créer le cluster moi-même. Je crée un compte. Puisque chaque fournisseur a son jargon, il faut que je m'adapte à celui-ci que je ne connais pas encore.

Après avoir lu les différentes descriptions des offres (il y a de quoi faire tourner directement des conteneurs via docker-compose, ou des serveurs classiques, des espaces de stockages, et enfin un onglet kubernetes pour créer un cluster.

Je sélectionne et choisis le datacenter le plus proche. Francfort ou Londres... Allez ! Londres. Ensuite, quelle capacité pour mon cluster ?

Chez DO, j'ai le choix entre 1gb de ram 1cpu, 1gb 2cpu, 2.5gb 2cpu ou 6gb 4cpu j'aime le dernier palier, mais il coûte 40 euros par mois, et je n'ai pas encore de client. Optons pour le moins cher et de redimensionner lorsque nécessaire. D'ailleurs, le moins cher, c'est le minimum nécessaire pour faire tourner nos applications, et 3GB de ram est conseillé. Pour adapter à vos besoins, un calcul back-of-the-enveloppe peux vous aider à chiffrer vos ressources.

Ensuite, c'est par Node. En effet, pour éviter d'avoir des services inaccessibles, 2 nodes minimum sont conseillés. Mais, ouch 48€ par mois. Oui, Le zero-down-time coûte cher.

Je nomme ce pool de 2 nodes pool-api-preprod et je nomme le cluster mon-app. D'ailleurs, je me projette en imaginant que c'est le même cluster qui portera prod et preprod, sous des nodes et namespace différents)

Sur l'interface, le projet s'appelle "first project", je change le nom. Oh, visiblement je peux assigner un projet a un environnement. Je suis en train de déployer du dev. Alors je suppose que j'aurai un autre projet dédié à la prod. Ça me permettra de mieux contrôler les coûts plus tard.

Je prends le parti de ne pas vous guider dans les interfaces de tous les fournisseurs possibles, ce sera à vous de vous adapter entre les connaissances que je vous partage, et votre expérience. Pendant ce temps-là, mon cluster semble être en cours de création (l'indicateur me dit 4min de délai en général, je vais me faire du thé).

Enfin, le thé est prêt, comme mon cluster. Désormais, un encart "get started" me recommande de configurer mon cluster et de m'y connecter pour le gérer, et deux approches sont proposées : le client de DO ou la méthode classique de kubernetes.

L'outil de DO est open source et pourra probablement m'aider plus tard, et je suppose qu'il n'est qu'une couche au-dessus de kubectl. Tentons. j'installe, et depuis l'admin API de DO, je crée un token pour m'y connecter.