Créer une base PostgreSQL pour une application

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.

Une base relationnelle stocke les enregistrements dans des tables. PostgreSQL est le moteur de base de données ; Amazon RDS gère l’instance et son point de terminaison est l’adresse utilisée par les clients. Ce laboratoire démarre dans une nouvelle VM avec la connexion AWS déjà configurée.

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

Vue d’ensemble du laboratoire

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.

Ce cours utilise Terminal préparé pour les commandes AWS CLI et SQL, et AWS View pour examiner la base et les résultats applicatifs. AWS View 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.

Les vérifications suivantes répondent à deux questions : le client SQL peut-il joindre le moteur prévu, et l’application utilise-t-elle ce même moteur ? Le seul état RDS available ne répond à aucune des deux. Comparez la base et l’utilisateur renvoyés aux valeurs attendues avant de considérer la connexion prête.

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.

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)
echo "$DB_ENDPOINT"

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.

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.

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.

Pour approfondir ce sujet, consultez la documentation AWS : Endpoints de bases de données et connexions clientes.