Opérations sur AWS

Cette page décrit les différentes étapes et configuration pour le déploiement des backends en mode serverless sur AWS API Gateway et AWS Lambda

Déploiement avec SAM et Github Actions

Pipeline GitHub Actions

Le déploiement des microservices est réalisé directement dans GitHub Actions du projet

La description des étapes est décrite dans le fichier Build on Master pour les versions Snapshot et dans le fichier build on Tag pour les versions Release

Ces pipelines sont représentées dans la figure suivante :

• Build Communs : construit le package Java commun à tous les microservices, et prépare les fichiers de configuration SAM
• Build µS : construit les packages Quarkus natifs de chacun des microservices et les packages sous forme de fonction Lambda
• Deploy Lambda Functions : exécute le déployement sur AWS via SAM

Configurations

Pour que le déploiement via SAM fonctionne, des paramètres sont définis dans la configuration settings/secrets/actions de GitHub:

Identifiant	Valeur
AWS_ACCESS_KEY_ID	L'identifiant de l'accès AWS (défini dans IAM )
AWS_SECRET_ACCESS_KEY	La clé de l'accès AWS (défini dans IAM )
DATABASE_NAME	Nom de la base de données
DATABASE_URL	URL de la base de données
OIDC_JWT_ID_APPUSERCONTENT	l'id de la AppUser chez Google

Remarque : pour que la transformation SED fonctionne correctement, la variable DATABASE_URL doit être structurée de la façon suivante : mongodb\+srv:\/\/<login>:<mot_de_passe>@<url_du_cluster_atlas>.mongodb.net\/?retryWrites=true\&w=majority

Pour que le déploiement via SAM fonctionne, des paramètres sont définis dans la configuration settings/variables/actions de GitHub:

Identifiant	Valeur
APP_CONFIG_URL_IHM	URL(s) de la partie IHM pour la configuration CORS
APP_CONFIG_URL_BACKENDS	URL vers l'API Gateway pour les flux inter-µServices

Remarque : pour que la transformation SED fonctionne correctement, les variables APP_CONFIG_URL_IHM et APP_CONFIG_URL_BACKENDS doivent être structurées de la façon suivante : http:\/\/localhost:3000,http:\/\/localhost:4011,,http:\/\/<nom_du_bucket_S3>\.s3-website\.eu-west-3\.amazonaws.com

CloudFormation - Déploiement avec SAM

Une fois exécutée, le déploiement créé et met à jour une pipeline CloudFormation :

Cette pipeline construit

• une API Gateway
• une fonction Lambda pour chaque microservice.

Pour chaque fonction Lambda, l'API Gateway est positionnée en frontal pour configurer et sécuriser les sollicitations aux Lambda

API Gateway

Déploiement de l'API Gateway

Une fois déployée, l'API Gateway est privée et ne permet pas d'être sollicitée depuis l'extérieur. Il faut compléter la configuration de l'API Gateway pour exposer les endpoints

Pour cela, aller dans la console API Gateway / Ressources et dans le menu Actions, cliquer sur Déployer l'API

Les API sont maintenant exposées via l'URL définie dans l'étape associée.

Configuration du plan d'utilisation et des clés d'API

Plan d'utilisation

Dans la configuration, le plan d'utilisation permet de définir les limites d'utilisation, et les clés d'API associées

Configuration de l'API Key

Pour chacune des ressources, il est nécessaire de configurer la Clé API obligatoire

Ensuite, redéployer les ressources.

Virtual Private Cloud

Création d'un VPC complet

• Sur VPC

  • Créer un VPC complet avec
    • 2 zones de disponibilité
    • 2 sous réseaux public
    • 2 sous réseaux privés
    • 1 passerelle NAT
    • 0 point de terminaison VPC

Cela donne la structure suivante :

• Sur la passerelle NAT

  • Relever l'IP publique de sortie, sur la passerelle NAT - c'est cette IP qui est utilisée par les lambdas pour sortir vers Internet et notamment la BDD Atlas.
  • Cette IP doit être configurée pour être un point d'entrée de la base de données correspondante, dans Atlas

Lambda

Configuration dans un VPC

Afin de limiter les accès réseaux autour des Lambda, et notamment l'interface entre les lambdas et la base de données Atlas; les Lambdas sont intégrés dans un VPC

• Sur Lambda / Configuration / Autorisation

  • Ajouter le rôle AWSLambdaVPCAccessExecutionRole (cf. ci dessous)

• Sur Lambda / Configuration / VPC

  • Sélectionner le VPC créé, les 2 sous-réseaux privés et le sécurity group par défaut

• Réaliser cette opération pour toutes les lambdas

Gestion des rôles

APIGateway - Rôle pour utiliser Cloudwatch

• Sur IAM
  • créer un nouveau rôle pour API GAteway

• Vérifier les droits pour créer des logs sur CloudWatch

• Finaliser la création du rôle sur IAM
• Copier l'ARN du service

• Dans le service API Gateway

  • Aller dans Paramètres et ajouter l'ARN du rôle

Lambda - Rôle pour associer à un VPC

• Dans le service Lambda

  • Aller dans Paramètres / Autorisations, et suivre le nom du rôle associé, dans IAM

• Dans IAM

  • Ajouter l'autorisation AWSLambdaVPCAccessExecutionRole-xxx au rôle

• Réaliser cette opération pour toutes les lambdas