Deux hommes marchent-ils ensemble sans s'être concertés ? [Amos 3:3]
La semaine dernière, Amazon a annoncé la prise en charge des ressources tierces dans AWS CloudFormation.
Chez DoiT International, nous travaillons aussi bien avec AWS qu'avec Google Cloud, et nous adorons tout automatiser. AWS CloudFormation est un excellent outil quand on est client AWS, mais aujourd'hui de nombreuses entreprises s'appuient sur plusieurs fournisseurs cloud. Nous nous sommes donc posé la question : pourquoi ne pas créer des clusters Google Kubernetes Engine via CloudFormation, en guise de preuve de concept pour les clients qui s'intéressent à l'infrastructure-as-code dans des environnements multi-cloud ?
Vous trouverez un bon tutoriel pour développer des ressources personnalisées dans la documentation de la CloudFormation CLI ainsi que dans cet article de blog. Je vais surtout revenir ici sur quelques difficultés rencontrées pendant le développement.
Nous allons utiliser l'API Kubernetes Engine pour lancer de nouveaux clusters. Il vous faudra créer un compte de service et lui attribuer les rôles appropriés à l'aide de la commande suivante :
gcloud projects add-iam-policy-binding my-project —-member serviceAccount:[email protected] —-role roles/iam.serviceAccountUser —-role roles/container.adminRendez-vous dans la console IAM > Service Account Key et téléchargez la clé au format JSON. Copiez le contenu du fichier JSON et ouvrez la console AWS Secret Manager. Créez un nouveau secret en texte brut et collez-y le contenu du fichier.
Pour utiliser l'API Secret Manager dans votre code, vous devrez passer par AmazonWebServicesClientProxy.
Attention : pour les tests locaux avec SAM , il vous faudra remplacer la ligne :
getSecretValueResult = clientProxy.injectCredentialsAndInvoke(getSecretValueRequest, client::getSecretValue);par
getSecretValueResult = client.getSecretValue(getSecretValueRequest);L'appel d'API qui crée le cluster renvoie une réponse immédiatement, alors que la création du cluster prend en réalité 2 à 3 minutes. Nous voulons suivre la progression et ne renvoyer un résultat qu'une fois la création aboutie (ou échouée). C'est pourquoi nous utilisons le CallbackContext pour remonter l'état de la création.
Une fois le principe des ressources personnalisées maîtrisé pour la création d'un cluster, ajouter d'autres opérations comme list, delete ou update devient trivial. Vous pouvez d'ailleurs réutiliser ce code pour créer vos propres ressources personnalisées pour d'autres services Google Cloud.
Le code est disponible ici.
Envie d'en lire davantage ? Jetez un œil à notre blog, ou suivez Aviv sur Twitter.