Amélioration de l'intégration continue automatisée de la base de données avec AWS CodeBuild et Amazon RDS Database Snapshot: idk.dev – Serveur d’impression

Dans les fusions d’intégration majeures, il est parfois nécessaire de vérifier les modifications avec les données en ligne existantes. Inspecter les modifications avec une base de données clonée peut nous donner confiance pour déployer sur la base de données de production. Cet article montre comment utiliser AWS CodeBuild et Amazon RDS Database Snapshot pour vérifier vos révisions de code à la fois dans la couche d'application et la couche sous-jacente, garantissant que vos données existantes fonctionnent de manière transparente avec votre code révisé.

Pour effectuer des révisions de code à l'aide d'une intégration continue, vous devez exécuter une vérification périodique pour vous assurer que votre nouveau livrable fonctionne de manière fonctionnelle et fiable. Il est facile de concentrer l'attention uniquement sur les modifications de niveau de surface apportées à la couche d'application. Cependant, n'oubliez pas d'inspecter également les modifications apportées à la couche de données sous-jacente.

À partir de la couche application, les utilisateurs modifient le modèle de données pour différentes raisons. Tout changement de définition de modèle de données dans la couche d'application correspond à un changement de schéma dans la base de données. Pour les services soutenus par une base de données relationnelle (RDBMS), un utilisateur peut effectuer des opérations DDL (Data Definition Language) directement vers un schéma de base de données ou s'appuyer sur une bibliothèque de mappage relationnel objet (ORM) pour migrer le schéma en fonction de la révision de l'application. Ces modifications de schéma (CRÉER, LAISSEZ TOMBER, MODIFIER, TRONQUER, etc.) peut être très critique, en particulier pour les services au service de clients réels.

La vérification et la simulation appropriées de ces changements atténuent le risque de mettre fin aux services. Une fois les modifications appliquées, les tests de fonctionnement fondamentaux (CRUD – CRÉER, LIS, METTRE À JOUR, SUPPRIMER) vers les modèles de données est obligatoire; cela conduit à des opérations de langage de contrôle des données (DCL) (INSÉRER, SÉLECTIONNER, METTRE À JOUR, SUPPRIMER, etc.). Après toutes les étapes nécessaires, un utilisateur peut passer à l'étape de déploiement.

À propos de cette page

• Temps de lecture: 6 minutes
• Durée: 30 minutes
• Coût de réalisation (estimé): moins de 1 $ pour un instantané de base de données de 1 Go et une instance restaurée
• Niveau d'apprentissage: Avancé (300)
• Services utilisés: AWS CodeBuild, IAM, RDS

Vue d'ensemble de la solution

Cet exemple utilise un fichier buildspec dans CodeBuild. Configurez un projet de génération qui pointe vers un référentiel de contrôle source contenant ce fichier buildspec. L'environnement d'exécution CodeBuild restaure le serveur de base de données à partir d'un instantané RDS. Nous restaurons un instantané sur un cluster Amazon Aurora, par exemple via AWS Command Line Interface (AWS CLI). Une fois la base de données restaurée, le processus de génération commence à exécuter votre processus d'intégration, qui se trouve dans le code factice dans la définition de buildspec. Après l'étape de vérification, CodeBuild supprime la base de données restaurée.

Conditions préalables

Les composants suivants sont requis pour implémenter cet exemple:

Procédure pas à pas

Suivez ces étapes pour exécuter la solution.

Préparez votre fichier de spécifications de construction

Avant de commencer, préparez votre fichier de spécifications de construction CodeBuild avec les informations suivantes:

• db-cluster-identifier-prefix
• db-snapshot-identifier
• ID-région
• identifiant de compte
• vpc-security-group-id

le db-cluster-identifier-prefix crée une base de données temporaire suivie d'un horodatage. Assurez-vous que cette valeur ne chevauche pas d'autres bases de données. le db-snapshot-identifier pointe vers l'instantané que vous appelez pour exécuter avec votre application. ID de région et identifiant de compte décrire le compte sur lequel vous exécutez. le vpc-security-group-id indique le groupe de sécurité que vous utilisez dans l'environnement CodeBuild et la base de données temporaire.

YAML
Version: 0,2
phases:
  installer:
    versions d'exécution:
      python: 3,7
pre_build:
  commandes:
    - pip3 install awscli --upgrade --user
    - date d'exportation = `date +% Y% m% d% H% M`
    - export DBIDENTIFIER = db-cluster-identifier-prefix- $ DATE
    - echo $ DBIDENTIFIER
    - aws rds restore-db-cluster-from-snapshot --snapshot-identifier arn: aws: rds: region-ID: account-ID: cluster-snapshot: db-snapshot-identifier –vpc-security-group-ids vpc- security-group-id --db-cluster-identifier $ DBIDENTIFIER --engine aurora
    - tandis que [ $(aws rds describe-db-cluster-endpoints --db-cluster-identifier $DBNAME | grep -c available) -eq 0 ]; faire écho "sommeil 60s"; dormir 60; terminé
    - écho "Temp db ready"
    - export ENDPOINT = $ (aws rds describe-db-cluster-endpoints --db-cluster-identifier $ DBIDENTIFIER | grep "" Endpoint "" | grep -v "-ro-" | awk -F '"' 'print $ 4 ')
    - echo $ ENDPOINT
construire:
  commandes:
    - echo Build a commencé le `date`
    - echo continue la connexion db vers $ ENDPOINT
    - echo procéder à la mise à jour de db migrate, DDL procéder ici
    - écho procéder au test d'application, test CRUD exécuté ici
post_build:
  commandes:
    - echo Build terminé le `date`
    - echo $ DBNAME
    - aws rds delete-db-cluster --db-cluster-identifier $ DBIDENTIFIER --skip-final-snapshot &

Une fois que vous avez terminé de modifier le fichier, nommez-le buildspec.yml. Enregistrez-le dans le répertoire racine avec lequel vous prévoyez de créer, puis validez le fichier dans votre référentiel de code.

1. Ouvrez la console CodeBuild.
2. Choisir Créer un projet de construction.
3. Dans Configuration du projet, entrez le nom et la description du projet de génération.
4. Dans La source, sélectionnez le fournisseur source de votre référentiel de code.
5. Dans Environnement image, choisissez Image gérée, Ubuntuet la dernière version d'exécution.
6. Choisissez le bon rôle de service pour votre projet.
7. dans le Configuration supplémentaire menu, sélectionnez le VPC avec vos instantanés de base de données Amazon RDS, comme indiqué dans la capture d'écran suivante, puis sélectionnez Valider les paramètres VPC. Pour plus d'informations, consultez Utiliser CodeBuild avec Amazon Virtual Private Cloud.
8. Dans Groupes de sécurité, sélectionnez le groupe de sécurité nécessaire à l'environnement CodeBuild pour accéder à votre base de données temporaire.
9. Dans Spécifications de construction, sélectionnez Utilisez un fichier buildspec.

Accorder l'autorisation pour le projet de construction

Suivez ces étapes pour accorder l'autorisation.

1. Accédez aux stratégies AWS Management Console.
2. Choisir Créer une politique et sélectionnez le JSON Pour donner à CodeBuild l'accès à la ressource Amazon RDS à l'étape de pré-construction, vous devez accorder RestoreDBClusterFromSnapshot et DeleteDBCluster. Suivez la directive de moindre privilège et limitez le point d'action DeleteDBCluster à «arn: aws: rds: *: *: cluster: db-cluster-identifier- *».
3. Copiez le code suivant et collez-le dans votre stratégie:

   
     "Version": "2012-10-17",
     "Déclaration": [
       
         "Sid": "VisualEditor0",
         "Effect": "Allow",
         "Action": "rds:RestoreDBClusterFromSnapshot",
         "Resource": "*"
       ,
       
         "Sid": "VisualEditor1",
         "Effect": "Allow",
         "Action": "rds:DeleteDBCluster*",
         "Resource": "arn:aws:rds:*:*:cluster:db-cluster-identifier-*"
       
     ]
   

4. Choisir Politique de révision.
5. Entrez un Nom et La description pour cette politique, puis choisissez Créer une politique.
6. Une fois la stratégie prête, associez-la à votre rôle de service CodeBuild, comme indiqué dans la capture d'écran suivante.

Utiliser la restauration d'instantané de base de données pour lancer le processus de génération

1. Revenez à CodeBuild et localisez le projet que vous venez de créer.
2. Donnez un paramètre de délai d'expiration approprié et assurez-vous de le définir sur la branche appropriée pour votre référentiel.
3. Choisir Lancer la construction.
4. Ouvrez le Journal de construction pour afficher le cluster de base de données à partir de votre instantané dans le pre_build étape, comme indiqué dans la capture d'écran suivante.
5. Au stade de la construction, utilisez $ ENDPOINT pour pointer votre application vers cette base de données temporaire, comme illustré dans la capture d'écran suivante.
6. dans le post_build, supprimez le cluster, comme indiqué dans la capture d'écran suivante.

Testez la modification de votre schéma de base de données

Après avoir configuré ce pipeline, vous pouvez commencer à tester la modification de votre schéma de base de données dans votre code d'application. Cet exemple définit plusieurs étapes dans le fichier Build Specifications pour migrer le schéma et s'exécuter avec le dernier code d'application. Dans cet exemple, vous pouvez vérifier que toutes les modifications correspondent de l'application à la base de données.

YAML
construire:
  commandes:
    - echo Build a commencé le `date`
    - echo continue la connexion db vers $ ENDPOINT
    # exécuter un script pour appliquer votre dernière modification de schéma
    - echo procéder à la mise à jour de db migrate
    # lancez le dernier code et lancez vos propres tests
    - écho procéder au test d'application

Après validation

Après avoir validé le changement de schéma de base de données dans les étapes ci-dessus, une stratégie appropriée pour le déploiement en production doit être utilisée qui s'aligne sur les critères pour satisfaire les objectifs commerciaux.

Nettoyer

Pour éviter des frais futurs, supprimez les ressources comme suit:

1. Ouvrez la console CodeBuild
2. Cliquez sur le projet que vous avez créé pour ce test.
3. Clique le supprimer le projet de construction et entrée supprimer pour confirmer la suppression.

Conclusion

Dans cette publication, vous avez créé un mécanisme pour configurer une base de données temporaire et limiter l'accès au runtime de génération. La base de données temporaire est autonome et isolée. Ce mécanisme peut être appliqué pour sécuriser le contrôle d'autorisation pour l'instantané de la base de données, ou pour ne casser aucun environnement existant. Le moteur de base de données s'applique à toutes les options RDS disponibles, y compris Amazon Aurora, PostgreSQL, MySQL, MariaDB, Oracle Database et SQL Server. Cela fournit des options, sans impact sur les environnements existants, pour les événements critiques déclenchés par des changements majeurs dans le schéma de la base de données de production ou des changements de format de données requis par les décisions commerciales.