Avis sur Oracle Cloud

Cette première partie est un peu auxiliaire mais n'ayant jamais utilisé Oracle Cloud Infrastructure, je me dis que c'est le moment de rédiger un avis. Si cette partie ne vous intéresse pas, il est tout à fait possible d'aller directement à la prochaine partie.

Pour information, je précise où je me place, j'ai déjà utilisé (pour mon compte ou pour la clientèle) :

• Amazon Web Services ;
• Microsoft Azure ;
• Google Cloud Platform, dans une moindre mesure ;
• Orange Flexible Engine, qui se base sur la plateforme développée par Huawei et qui n'est franchement pas terrible ;
• Scaleway ;
• OVH ;
• Hetzner ;
• Exoscale, de manière très succinte ;
• OpenStack chez Infomaniak, juste pour de l'object storage.

Il me surprend que la liste soit si longue, certes en comptant les utilisations « moindres ». Un de ces jours, il faudrait vraiment que je fasse un comparatif entre OVH et Scaleway, il y a des choses à raconter ! 🤔

Déjà, j'apprécie beaucoup la page de free tier qui est très précise. Pour les besoins au delà, il y a un calculateur comme chez les « grands fournisseurs » cloud (et son ergonomie est discutable mais je n'ai jamais trouvé de calculateur de coûts qui me sied parfaitement chez les fournisseurs, c'est déjà bien quand ça existe).

J'ai uniquement utilisé le module Opentofu/Terraform qui m'intéressait, il est plutôt bien si on exclue le besoin de faire le tofu apply en plusieurs fois (je l'avais évoqué dans mon précédent article).

Le nombre de services a l'air intéressant, pas aussi grand que chez AWS ou Azure mais il y en a suffisamment pour couvrir tous les besoins de base et même un peu plus.

L'interface web

J'ai navigué un peu sur l'interface web d'Oracle Cloud (que j'appellerai aussi « console ») pour observer un peu les ressources qui étaient créées et chercher quelques informations sur mon utilisation des crédits offerts. Je n'ai initié la création d'aucune ressource via ce portail, j'ai uniquement utilisé OpenTofu pour ça.

Avant de parler d'ergonomie, je note que le « style » est basique. Pas très beau mais pas spécialement laid. Oui, c'est un avis un peu nul. Je dirais que ça ressemble à la console d'AWS en 2018, donc un peu austère et « vieillot », mais sans les dégradés de gris qui laissaient croire (à l'époque) à un retard de 10 ans chez la direction artistique.

Mais le vrai problème des console des fournisseurs cloud, ce n'est pas d'avoir de jolies couleurs, c'est surtout de faire en sorte que les gens se retrouvent dans les services, les ressources, les options et tout ce que le fournisseur propre.

Commençons par un bon point : Oracle n'a pas mis des icônes dans tous les sens, c'est très textuel et j'apprécie vraiment. Mon cerveau se sent à l'aise pour trouver l'information sur une page.

Aussi, la catégorisation des services est plutôt bien, sauf pour quelques outils. Notamment, OKE (le service de Kubernetes auto-géré) est dans la catégorie « Developers services » qui a l'air d'être le fourre-tout pour tout ce qui ne rentre pas dans une autre catégorie.

Enfin, la vue d'une ressource est… Particulière mais fonctionnelle. On s'y fait et on comprend vite le fonctionnement de la page qui est d'ailleurs très cohérente entre tous les services (les gens qui ont utilisé AWS Beanstalk savent qu'il peut y avoir des produits qui ont une interface différente des autres chez un même fournisseur, en tout cas en 2016 c'était ça). Et je dirais même que j'ai fini par apprécier cette ergonomie car je trouvais facilement les informations que je cherchais sur les ressources.

Petit point bonus : les liens internes sont bien pensés et certains s'ouvrent dans un nouvel onglet quand ça mène vers une ressource d'un autre service. Par exemple, quand on clique sur le nom d'une machine virtuelle qui est listée dans un groupe de nœuds du cluster Kubernetes, alors ça ouvre la ressource dans un nouvel onglet car on passe sur le service « Compute ». On aime ou on n'aime pas, personnellement j'apprécie ce point.

Entrons maintenant dans le vif du sujet !

Gratuit, vraiment ?

Sachant qu'on a 250€ de crédits offerts sur un mois, comment savoir si le cluster avait un coût ? Il suffit de regarder ce qui est consommé dans le crédit.

Du coup : est-ce que j'ai pu utiliser le cluster sans que ça ne touche les crédits offerts par Oracle ? La réponse est : presque ! J'ai consommé 5,65€ au 4 mai (dernier jour de mon crédit), apparemment à cause d'un load balancer que j'aurais créé le 22 avril. Ce qui me surprend, c'est qu'on a normalement droit à un load balancer gratuit.

En tout cas, c'était un service Kubernetes de type LoadBalancer qui a créé la ressource sur Oracle Cloud, lorsque j'ai installé ma gateway. Le load balancer créé de manière automatique doit être d'une puissance qui va au delà de ce à quoi on a droit gratuitement. J'avais pourtant changé la configuration pour utiliser un autre type de service mais il semblerait que le changement ne se soit pas passé comme prévu. J'ai donc manuellement supprimé le service Kubernetes en question puisqu'il n'était plus censé servir.

Donc il semblerait que l'objectif de gratuité puisse être atteint si on n'a pas besoin de load balancer. Mais « gratuit » ne veut pas dire « illimité » (personne n'a dit le contraire mais ça fait la transition pour la suite) !

Les limitations découvertes

Puissance disponible

Avec tous les outils que j'ai installé dans le cluster (je ne suis pas assez minimaliste en terme technologique), ça m'a fait manquer de ressources. Ça me fait penser que je devrais faire un petit wiki sur mon site avec la liste de mes logiciels essentiels.

En architecture ARM, on a droit à 4 OCPU (donc théoriquement l'équivalent de 8 vCPU) et 24Go de RAM. Je ne parle pas de l'architecture x86 car l'offre gratuite est très très faible et j'avais donc indiqué dans mon premier article que je m'intéressais qu'à l'offre ARM qui est assez généreuse.

Resources des pods

En premier lieu, j'ai changé pas mal de requêtes et limites de ressources sur certains outils qui n'ont pas besoin de leur puissance habituelle dans mon cas. Aussi, comme un OCPU est censé valoir « au moins deux vCPU », j'ai considéré que quand un pod a besoin d'au moins 1 CPU, il faut donc considérer qu'il a besoin que d'un demi-CPU chez Oracle. Pour retourner un peu la chose, j'ai considéré que 1 CPU vaut 500m (rappel : pour Kubernetes, 1 cœur de CPU vaut normalement 1000m donc mathématiquement, si 1 OCPU vaut deux cœurs, ça signifie que 1 OCPU vaut théoriquement 2000m).

Ça fait beaucoup de chiffres et d'unités, j'espère que c'est assez clair. 😅

Nombre de machines virtuelles

Aussi, à l'origine, j'avais créé un groupe de deux nœuds, chacun ayant 1 OCPU et 6Go de RAM ce qui faisait un total de 2 OCPU et 12Go de RAM. Gratuitement, on a droit à un total de 4 OCPU et 24Go de RAM donc j'ai ajouté un nœud de la même puissance ce qui fait que j'utilise 3 OCPU et 18Gi de RAM.

Une solution possible est de plutôt tourner avec deux nœuds chacun d'une puissance de 1 OCPU et 8Go de RAM mais du coup on garde une certaine limite en terme de processeur (on ne pourrait pas avoir 2 OCPU par nœud car le roulement ne pourrait pas se faire à cause de la limite à 4 OCPU qui serait dépassée lors de celui-ci). L'avantage de passer sur trois machines virtuelles est donc qu'on a 3 OCPU au total en temps normal et pas seulement 2 OCPU.

Mais du coup, ça crée un blocage sur les volumes, ce qui fait une transition parfaite pour mon point suivant.

Volumes

Si vous avez lu la partie précédente sur le CPU et la RAM, vous aurez noté que j'utilise trois machines en temps normal et que le roulement en cas de mise à jour ou de maintenance fait que les 200Go sont totalement utilisés. Cette limite semble avoir été parfaitement calculée par Oracle pour être bien frustrante et forcer un peu le passage à la caisse mais je ne juge pas, il faut bien vendre. 🙃

J'ai rapidement constaté que je n'arrivais plus à créer de PersistentVolumeClaim à cause de cette limitation du stockage qui est entièrement utilisée par mes machines et celle de roulement.

Trois choix s'offraient à moi :

• Accepter de payer (haha, vous me prenez pour qui ?) ;
• Utiliser des volumes de type hostPath là où c'était suffisant ;
• Installer Rook ou Longhorn pour pouvoir gérer moi-même les volumes.

Si vous n'avez pas envie de lire mes justifications et explications, je divulgâche : j'ai utilisé Longhorn (les raisons sont expliquées ci-dessous). Voilà, vous pouvez aller directement à la conclusion si vous n'avez pas besoin ni envie d'en savoir plus.

En premier lieu, dans ma grande radinerie et mon habituelle flemme, j'ai choisi d'utiliser des hostPath à gogo.

En tout état de cause, ça m'a créé des problèmes avec les droits de certains outils sur les chemins montés dans les pods donc j'ai décidé que ce serait l'occasion de tester Rook (un collègue indépendant m'en avait parlé en bien). Sauf que, surprise (ou pas), Rook est un peu complexe (ça démarre et gère un cluster Ceph notamment) et j'ai vite déchanté en essayant d'apprendre son architecture alors que sur le moment je voulais juste faire mes volumes sans réfléchir. Toutefois, je donnerais une chance à Rook quand j'aurai du temps à lui donner, ça a l'air trop intéressant pour que je le laisse définitivement de côté ! 😀

Donc j'ai plutôt essayé Longhorn, l'architecture est assez simple : les volumes utilisent le disque des nœuds et les contenus sont répliqués pour la sûreté. Ici je l'utilise de manière très basique mais Longhorn peut être très puissant et proprement configuré en utilisant des serveurs avec des disques physiques supplémentaires qui lui seront dédiés.

Conclusion

Rappelons-nous que je n'ai fait que créer et utiliser un cluster Kubernetes (ainsi que le réseau et les sous-réseaux), qui lui-même crée des ressources annexes (comme les machines virtuelles).

Je pense avoir quatre points principaux à évoquer :

1. Oracle Cloud me satisfait pour ce que j'en ai essayé ;
2. La gratuité est réelle mais attention aux ressources annexes créées via Kubernetes (load balancers et volumes blocs par exemple) qui ne sont pas offertes ;
3. La puissance disponible peut être limitante si, comme moi, on installe beaucoup de choses pour servir de base ;
4. Il ne faut pas compter sur la possibilité de créer des volumes de type bloc, aussi je recommande d'installer Longhorn ou autre technologie du même genre pour compenser le manque de place.

D'ailleurs, ça m'a fait plaisir de tester Longhorn mais j'aurais aimé aller du côté de Rook. J'avais quand même testé l'installation mais ça prenait vraiment beaucoup de ressources. Longhorn démarre pas mal de pods lui aussi mais Rook semble encore plus consommateur.

Voilà, je me réserve la possibilité de faire une troisième partie ou une petite mise à jour si je découvre de nouvelles choses !