Introduction
Une application de commandes a besoin d’une base relationnelle pour stocker les commandes clients. Dans ce laboratoire, vous créerez une base PostgreSQL privée avec Amazon RDS, utiliserez un client SQL standard et configurerez l’application pour le nouveau point de terminaison.
Vous devez connaître les sous-réseaux VPC, les groupes de sécurité et les connexions applicatives des cours VPC et EC2 précédents. Le réseau, l’application et AWS CLI configurée sont fournis. Aucun compte AWS personnel n’est nécessaire. Vous supprimerez la base à la fin.
Liens avec les certifications
Ce laboratoire propose une pratique introductive des sujets d’examen suivants.
- Cloud Practitioner (CLF-C02) · Tâche 3.4 : Reconnaître Amazon RDS comme service de bases relationnelles géré.
- Solutions Architect – Associate (SAA-C03) · Tâche 3.3 : Comprendre les moteurs de bases et les connexions des applications.
Créer la base de l’application
Dans cette étape, vous créerez une instance PostgreSQL privée dans le réseau de bases préparé.
Amazon RDS gère des instances de bases relationnelles. PostgreSQL est le moteur qui stocke les tables et exécute SQL. AWS CLI gère la ressource RDS ; un client SQL se connecte au moteur pour travailler sur les données. Créer une instance RDS et interroger une table sont deux opérations distinctes.
AWS Management Console facilite l’exploration des services et l’inspection des ressources. La CLI convient aux requêtes précises, aux opérations répétables et à l’automatisation, mais sa syntaxe demande de la pratique. Ce cours utilise Terminal et AWS View préparés. AWS View affiche les ressources du laboratoire et les résultats applicatifs ; il est distinct d’AWS Management Console.
Placez-vous dans l’espace de travail et chargez les réglages fournis :
cd /home/labex/project
source database.env
DB_SECURITY_GROUP_ID identifie les règles d’accès réseau préparées pour la base. PGSERVICEFILE et PGPASSFILE indiquent au client PostgreSQL où trouver les fichiers habituels de connexion et de mots de passe. Gardez ces derniers privés ; inutile d’en afficher le contenu.
Examinez le groupe de sous-réseaux DB préparé :
aws rds \
describe-db-subnet-groups \
--db-subnet-group-name orders-subnets \
--query 'DBSubnetGroups[].{Name:DBSubnetGroupName,VPC:VpcId,Subnets:Subnets[].SubnetIdentifier}'
Un groupe de sous-réseaux DB désigne les sous-réseaux VPC disponibles pour placer RDS. Celui-ci contient des sous-réseaux privés de bases dans deux zones de disponibilité. Deux sous-réseaux ne suffisent pas, à eux seuls, à activer un déploiement Multi-AZ.
Créez l’instance :
aws rds \
create-db-instance \
--db-instance-identifier orders-db \
--db-instance-class db.t3.micro \
--engine postgres \
--engine-version 16.15 \
--allocated-storage 20 \
--master-username orders_admin \
--master-user-password "$(cat db-password.txt)" \
--db-name orders \
--db-subnet-group-name orders-subnets \
--vpc-security-group-ids "$DB_SECURITY_GROUP_ID" \
--no-publicly-accessible \
--backup-retention-period 0 \
--query 'DBInstance.{Identifier:DBInstanceIdentifier,Status:DBInstanceStatus,Engine:Engine}'
L’identifiant d’instance orders-db nomme la ressource RDS ; le nom de base orders nomme la base PostgreSQL qu’elle contient. db.t3.micro choisit une classe d’instance et 20 demande une capacité de stockage en GiB. L’accès privé maintient les connexions applicatives dans le réseau préparé. La rétention des sauvegardes automatiques est désactivée pour cet exercice court ; un laboratoire ultérieur présente un snapshot manuel.
$(cat db-password.txt) fournit le mot de passe préparé sans l’imprimer. Ne collez pas les mots de passe dans des notes ou captures.
Attendez la disponibilité, puis examinez le point de terminaison :
aws rds \
wait db-instance-available \
--db-instance-identifier orders-db
aws rds \
describe-db-instances \
--db-instance-identifier orders-db \
--query 'DBInstances[0].{Identifier:DBInstanceIdentifier,Database:DBName,Status:DBInstanceStatus,Endpoint:Endpoint}'
Vous devez obtenir la base orders, l’état available et le port PostgreSQL 5432. Le point de terminaison est l’adresse utilisée pour choisir cette instance. AWS View doit désormais afficher orders-db comme base primaire. Aucune table de commandes n’a encore été créée.
Connecter le client SQL et l’application
Dans cette étape, vous testerez le moteur et dirigerez l’application vers son point de terminaison.
psql est le client standard en ligne de commande de PostgreSQL. Le service préparé orders-db contient les paramètres de connexion de l’instance créée. Un nom de service est une entrée pratique de configuration du client, pas une ressource AWS.
Schéma conceptuel: Une connexion PostgreSQL privée exige un point de terminaison accessible et un port autorisé.
Interrogez le moteur :
psql \
"service=orders-db" \
--command 'SELECT current_database(), current_user;'
Vous devez obtenir la base orders et l’utilisateur orders_admin. Ce résultat provient d’une connexion à la base et non des métadonnées RDS. RDS gère l’hôte de la base ; les applications utilisent le protocole de base de données, pas une connexion SSH à cet hôte.
Récupérez le point de terminaison depuis RDS. --query sélectionne un champ, --output text produit une valeur simple et $(...) du shell l’enregistre dans DB_ENDPOINT :
DB_ENDPOINT=$(aws rds \
describe-db-instances \
--db-instance-identifier orders-db \
--query 'DBInstances[0].Endpoint.Address' \
--output text)
Examinez la configuration fournie :
cat app-config.json
read_host choisit la base pour les requêtes et write_host pour les modifications. Pour l’instant, les deux doivent utiliser le primaire. password_file référence un fichier privé plutôt que d’intégrer le mot de passe à ce document JSON.
Utilisez jq, un outil d’édition JSON, pour régler les deux champs d’hôte. Écrivez un nouveau fichier, puis remplacez la configuration une fois la modification réussie :
jq \
--arg host "$DB_ENDPOINT" \
'.read_host = $host | .write_host = $host' \
app-config.json > app-config.new
mv app-config.new app-config.json
Testez la connexion de l’application :
curl \
--silent \
--show-error \
--fail \
http://127.0.0.1:8080/application/connection
Vous devez obtenir database égal à orders, user égal à orders_admin et read_only égal à false. Le primaire accepte les écritures, mais ce laboratoire établit seulement la connexion. La liste des commandes d’AWS View restera indisponible jusqu’à la création d’une table dans le prochain laboratoire.
L’exemple montre l’application connectée à la base primaire orders et le point de terminaison RDS natif. La table de commandes n’existe pas encore. Vos identifiants de ressources peuvent différer.
Exemple de la console officielle : Endpoint et Port dans Connectivity & security correspondent à Endpoint.Address et Endpoint.Port de la CLI. L’exemple utilise MySQL et 3306 ; ce laboratoire utilise PostgreSQL et 5432 avec le point de terminaison renvoyé par votre commande. Ne copiez pas le nom d’hôte ni le port de l’exemple. Continuez dans Terminal et AWS View sans connexion à AWS.
Source: AWS RDS guide.
Supprimer l’instance de base
Dans cette étape, vous supprimerez la base temporaire en conservant l’application et le réseau préparés.
Supprimez l’instance sans conserver de snapshot final :
aws rds \
delete-db-instance \
--db-instance-identifier orders-db \
--skip-final-snapshot \
--query 'DBInstance.DBInstanceIdentifier'
--skip-final-snapshot abandonne la base d’exercice sans enregistrer de copie de récupération. Pour des données importantes, décidez comment préserver une sauvegarde avant de supprimer l’instance.
Attendez la suppression et examinez l’inventaire :
aws rds \
wait db-instance-deleted \
--db-instance-identifier orders-db
aws rds \
describe-db-instances \
--query 'DBInstances[].DBInstanceIdentifier'
Le résultat doit être []. AWS View ne doit plus afficher de base. L’ancien point de terminaison de l’application ne dessert plus de base : un échec de connexion est donc attendu après suppression. Conservez les groupes de sous-réseaux et de sécurité, ainsi que les fichiers applicatifs fournis.
Résumé
Vous avez créé une instance RDS PostgreSQL privée, distingué son identifiant du nom de base et examiné son point de terminaison. Vous avez interrogé le moteur avec psql et connecté l’application au même primaire. Enfin, vous avez supprimé l’instance en préservant le réseau préparé.
Le prochain laboratoire crée une table de commandes et utilise SQL pour stocker et interroger les commandes clients.
