AWS Database Migration Service (DMS) est conçu pour migrer les bases de données sur AWS de manière fiable, sans aucun temps d'arrêt. Initialement, DMS ne prenait en charge que les bases de données relationnelles, y compris AWS Redshift. En avril 2017, DMS a ajouté deux bases de données NoSQL :MongoDB comme base de données source et AWS DynamoDB comme base de données cible. Dans ce didacticiel de deux articles, nous aborderons la migration d'une base de données MongoDB vers DynamoDB sur DMS. L'une des conditions requises pour utiliser MongoDB en tant que source DMS est que MongoDB doit s'exécuter en tant que jeu de répliques, que nous créerons à l'aide d'une image Docker dans le premier de ces deux articles.
Cet article comporte les sections suivantes :
- Configuration de l'environnement
- Création d'un utilisateur IAM pour le service de migration de base de données
- Création d'une clé de chiffrement
- Création d'une base de données MongoDB
- Créer une table DynamoDB
- Conclusion
Configuration de l'environnement
Le seul prérequis est un compte AWS, qui peut être créé sur https://aws.amazon.com/resources/create-account/. Nous exécuterons les bases de données source et cible sur AWS. Pour la source MongoDB, nous utiliserons Docker, pour lequel nous lancerons une instance EC2 avec AMI Container Linux by CoreOS (Stable) sélectionné dans AWS Marketplace, comme illustré à la figure 1. CoreOS est choisi comme plate-forme Linux car il dispose de Docker pré-installé dessus.
Figure 1 : Sélection de l'AMI CoreOS pour lancer une instance EC2
Le groupe de sécurité utilisé par l'instance CoreOS EC2 doit avoir des règles entrantes/sortantes définies pour accepter tout le trafic. Cela implique le trafic de tous les protocoles sur tous les ports entre toutes les sources et destinations (0.0.0.0/0,::/0 ).
Création d'un utilisateur IAM pour le service de migration de base de données
Dans cette section, nous allons créer un utilisateur IAM pour accéder aux différents services AWS utilisés lors de la création d'une migration, notamment DMS, EC2, DynamoDB, KMS, IAM et CloudWatch. Tout d'abord, nous devons créer une stratégie avec les autorisations requises. Par la suite, nous créerons un utilisateur et attribuerons la politique à l'utilisateur. Pour créer une stratégie IAM, sélectionnez Politiques dans la console IAM et cliquez sur Créer une stratégie . Dans Créer une politique, sélectionnez Créer votre propre politique . Dans Politique de révision, spécifiez un nom de politique (DMS par exemple) et copiez et collez le document de politique suivant dans le champ Document de politique.
{ "Version":"2012-10-17", "Statement":[ { "Effect":"Allow", "Action":"dms:*", "Resource":"*" }, { "Effet":"Autoriser", "Action":"dynamodb :*", "Ressource":"*" }, { "Effet":"Autoriser", "Action":"kms :*", "Ressource":"*" }, { "Effet":"Autoriser", "Action":"iam:*", "Ressource":"*" }, { "Effet":"Autoriser", "Action":"ec2 :* ", "Resource":"*" }, { "Effet":"Autoriser", "Action":"cloudwatch :*", "Ressource":"*" }, { "Effet":"Autoriser", "Action" ":"aws-marketplace :*", "Resource":"*" }, { "Effet":"Autoriser", "Action":"journaux :*", "Ressource":"*" }, { "Effet " :"Autoriser", "Action":[ "redshift:Describe*", "redshift:ModifyClusterIamRoles" ], "Resource":"*" } ]}
Cliquez sur Valider la politique . Si le résultat est "Cette règle est valide", cliquez sur Créer une règle , comme illustré à la figure 2.
Figure 2 : Création d'une stratégie IAM
Une nouvelle stratégie IAM est créée, comme illustré à la figure 3.
Figure 3 : Politique IAM "DMS"
Ensuite, créez un utilisateur IAM. Sélectionnez Utilisateurs et cliquez sur Ajouter un utilisateur , comme illustré à la figure 4.
Figure 4 : Ajouter un utilisateur
Dans Ajouter un utilisateur , spécifiez un Nom d'utilisateur , comme illustré à la Figure 5. Pour le type d'accès , sélectionnez Accès programmatique et l'accès à la console de gestion AWS .
Figure 5 : Ajouter un utilisateur
Pour le mot de passe de la console , sélectionnez Mot de passe personnalisé et spécifiez un mot de passe (voir Figure 6). Cliquez sur Suivant.
Figure 6 : Sélectionnez Type d'accès AWS>Suivant
Dans Définir les autorisations, cliquez sur Joindre directement les règles existantes , comme illustré à la figure 7.
Figure 7 : Définition des autorisations
Sélectionnez la stratégie DMS créée précédemment, puis cliquez sur Suivant, comme illustré à la figure 8.
Figure 8 : Sélection de la politique DMS
Dans Révision, cliquez sur Créer un utilisateur , comme illustré à la figure 9.
Figure 9 : Réviser>Créer un utilisateur
Un utilisateur IAM est créé. Copiez l'URL illustrée à la figure 10 pour vous connecter à AWS Management Console en tant qu'utilisateur créé.
Figure 10 : URL de l'utilisateur IAM
Un nouvel utilisateur est répertorié dans Utilisateurs (voir Figure 11).
Figure 11 : URL de l'utilisateur IAM
Création d'une clé de chiffrement
Ensuite, créez une clé de chiffrement à utiliser pour la migration DMS. Connectez-vous en tant qu'utilisateur IAM créé et utilisez l'URL copiée dans la figure 10. Sélectionnez IAM service dans la console de gestion AWS et sélectionnez Clés de chiffrement . Cliquez sur Créer une clé pour lancer un assistant pour créer une clé de chiffrement. Utilisez l'assistant pour créer une clé de chiffrement (dms ), comme illustré à la Figure 12.
Figure 12 : Nouvelle clé de chiffrement
Création d'une base de données MongoDB
Dans cette section, nous allons créer une base de données MongoDB que nous migrerons ensuite vers DynamoDB. Nous utiliserons Docker pour exécuter une instance MongoDB, pour laquelle une instance CoreOS a été lancée. Pour vous connecter à une instance CoreOS, obtenez l'adresse IP publique de l'instance CoreOS, comme illustré à la figure 13.
Figure 13 : Adresse IP publique de l'instance CoreOS
Connectez-vous en SSH à l'instance CoreOS à l'aide de la paire de clés et de l'adresse IP publique.
ssh -i "docker.pem" [email protected]
L'invite de ligne de commande de l'instance CoreOS s'affiche, comme illustré à la figure 14.
Figure 14 : Instance CoreOS
Ensuite, exécutez la commande suivante pour démarrer un conteneur Docker pour MongoDB à l'aide de l'image MongoDB "mongo". Le port de conteneur Docker 27017 est également exposé sur l'hôte en tant que 27017 à l'aide de -p option pour exécuter docker . Le nom du conteneur est défini sur "mongo1" et la commande mongod --replSet repl0 est exécuté dans le conteneur créé pour démarrer un jeu de répliques MongoDB appelé "repl0". Comme mentionné précédemment, pour utiliser MongoDB comme source DMS, un jeu de réplicas MongoDB est requis et un MongoDB autonome n'est pas utilisable comme source.
docker run -p 27017:27017 mongo mongod --replSet repl0
L'image Docker mongo est extrait et, comme indiqué par le message "Démarrage de MongoDB" dans la figure 15, MongoDB commence à démarrer.
Figure 15 : Téléchargement Docker Image docker
Une instance MongoDB démarre sur le port 27017 (voir Figure 16). Un jeu de répliques n'a pas encore été créé et nous allons ensuite initialiser un jeu de répliques.
Figure 16 : Démarrage de l'instance Mongo
Un conteneur Docker est répertorié avec le docker ps commande, comme illustré à la Figure 17.
Figure 17 : Répertorier le conteneur Docker pour Mongo
Utilisez la commande suivante pour démarrer un shell de commande pour l'interface de ligne de commande Mongo (CLI).
docker exec -it mongo1 mongo
La version 3.4.4 du shell MongoDB se connecte à l'URL mongodb://127.0.0.1:27017 , comme illustré à la Figure 18.
Figure 18 : Connexion du shell MongoDB
L'invite de commande Mongo CLI s'affiche, comme illustré à la figure 19.
Figure 19 : Invite de commande Mongo Shell
Définir la base de données MongoDB à utiliser comme test avec le test d'utilisation commande, comme illustré à la Figure 20.
Figure 20 : Définir la base de données comme test
Ensuite, nous allons initialiser un jeu de répliques pour lequel nous devons définir les membres ou les instances du jeu de répliques. Obtenez l'adresse IP privée de l'instance CoreOS EC2 sur laquelle le conteneur Docker pour MongoDB s'exécute (voir Figure 21).
Figure 21 : IP privée de l'instance CoreOS
Dans la CLI Mongo, spécifiez la configuration suivante pour la configuration du jeu de répliques.
config ={ "_id" :"repl0", "members" :[ { "_id" :0, "host" :"172.30.2.20:27017" } ]}
La configuration du jeu de répliques est définie, comme illustré à la figure 22.
Figure 22 : Définition de la configuration de l'ensemble de répliques
Lancez la configuration du jeu de répliques à l'aide de la configuration.
rs.initiate(config)
Le jeu de répliques est initialisé, comme illustré à la figure 23.
Figure 23 : Jeu de répliques initialisé
Générez la configuration du jeu de répliques.
rs.conf()
Le repl0:PRIMARY L'invite de commande indique que le jeu de répliques a été initialisé et que le membre principal du jeu de répliques a été défini pour exécuter les commandes CLI Mongo. Le primaire est le seul membre d'un jeu de répliques pour les opérations d'écriture. Créez une collection MongoDB appelée wlslog avec db.createCollection() commande.
db.createCollection("wlslog")
Une collection MongoDB est créée, comme illustré à la figure 24. Une collection MongoDB est une collection de documents. Les documents sont au format BSON (binary JSON).
Figure 24 : Création d'une collection
Exécutez les instructions suivantes qui définissent les documents JSON dans la CLI Mongo.
doc1 ={"timestamp":"8 avril 2014 19:06:16 PDT", "category":"Notice","type":"WebLogicServer", "servername":"AdminServer","code ":"BEA-000365", "msg":"L'état du serveur est passé à STANDBY"}doc2 ={"timestamp":"8 avril 2014 19:06:17 PDT", "category":"Notice"," type":"WebLogicServer", "servername":"AdminServer","code":"BEA-000365", "msg":"L'état du serveur est passé à STARTING"}doc3 ={"timestamp":"8 avril 2014 7 :06:18 PM PDT", "category":"Notice","type":"WebLogicServer", "servername":"AdminServer","code":"BEA-000365", "msg":"L'état du serveur a changé à ADMIN"}doc4 ={"timestamp":"8 avril 2014 19:06:19 PDT", "category":"Notice","type":"WebLogicServer", "servername":"AdminServer"," code":"BEA-000365", "msg":"L'état du serveur est passé à RESUMING"}doc5 ={"timestamp":"8 avril 2014 19:06:20 PDT", "category":"Notice", "type":"WebLogicServer", "servername":"AdminServer","code":"BEA-000331", "msg":"Serveur d'administration WebLogic démarré"}doc6 ={"timestamp":"8 avril 2014 7 :18:21 HAP", "category":"Notice","type":"WebLogicServer", "servername":"AdminServer","code":"BEA-000365", "msg":"L'état du serveur est passé à RUNNING"}doc7 ={" timestamp":"8 avril 2014 19:06:22 PDT", "category":"Notice","type":"WebLogicServer", "servername":"AdminServer","code":"BEA-000360" , "msg":"Serveur démarré en mode RUNNING"}
Les variables des documents JSON sont définies, comme illustré à la Figure 25.
Figure 25 : Définition de variables pour les documents JSON
Ajoutez les documents JSON au wlslog collecte.
db.wlslog.insert([doc1,doc2,doc3,doc4,doc5,doc6,doc7])
Comme indiqué par la sortie de la figure 26, sept documents sont ajoutés au wlslog collecte.
Figure 26 : Documents JSON ajoutés à la collection
Lister les documents ajoutés au wlslog collecte.
db.wlslog.find()
Les sept documents ajoutés sont répertoriés, comme illustré à la figure 27.
Figure 27 : Trouver ou obtenir des documents d'une collection Mongo
Créer une table DynamoDB
Après avoir créé un jeu de réplicas MongoDB pour la source DMS, nous allons ensuite créer une table DynamoDB pour la cible DMS. Connectez-vous en tant qu'utilisateur IAM (dvohra) créé précédemment et auquel une stratégie a été attribuée. Sélectionnez le service DynamoDB dans la console de gestion AW et sélectionnez Créer une table , comme illustré à la Figure 28.
Figure 28 : DynamoDB>Créer une table
Dans la table Créer DynamoDB, spécifiez un nom de table et spécifiez la clé primaire , qui est également la clé de partition, sous la forme _id , comme illustré à la Figure 29. Bien que le nom de la table soit arbitraire et défini sur wlslog , qui est identique à la collection MongoDB créée dans le jeu de répliques MongoDB, la clé primaire doit être définie sur _id car chaque document MongoDB se voit attribuer le champ de clé primaire _id .
Figure 29 : Création d'une table DynamoDB
La table DynamoDB wlslog est créé, comme illustré à la Figure 30.
Figure 30 : Table DynamoDB wlslog créée
Cliquez sur la table DynamoDB wlslog dans le tableau de bord et les détails du tableau, y compris la clé primaire _id , s'affichent (voir Figure 31).
Figure 31 : Détails wlslog de la table DynamoDB
Lorsqu'une migration DMS est créée, un rôle IAM dms-vpc-role avec la stratégie gérée AmazonDMSVPCManatageRole est créé automatiquement. Pour que le service DMS accède au service DynamoDB, nous devons modifier le rôle d'accès au service dms-vpc-role pour ajouter le document de stratégie suivant, qui permet d'accéder à DynamoDB à partir de DMS.
{ "Version":"2012-10-17", "Statement":[{ "Effet":"Autoriser", "Action":[ "dynamodb:*" ], "Ressource":["*" ] }]}
En utilisant la même procédure que celle utilisée pour créer la stratégie DMS, créez une stratégie DynamoDB et spécifiez le document de stratégie précédent dans la zone de champ Document de stratégie, comme illustré à la Figure 32. Cliquez sur Créer une stratégie .
Figure 32 : Examiner la politique>Créer une politique
La stratégie DynamoDB est créée, comme illustré à la figure 33.
Figure 33 : Stratégie IAM DynamoDB créée
Le dms-vpc-role auquel la stratégie DynamoDB doit être ajoutée est illustré à la figure 34.
Figure 34 : Rôle VPC DMS
Cliquez sur dms-vpc-role et ajoutez la stratégie DynamoDB à l'aide de Attach Policy. Les stratégies AmazonDMSVPCMananagementRole et DynamoDB doivent être répertoriées en tant que stratégies gérées, comme illustré à la Figure 35.
Figure 35 : Politiques d'autorisations dans le rôle VPC DMS
Conclusion
Dans cet article, nous avons présenté l'utilisation d'AWS Database Migration Service (DMS) pour la migration de MongoDB vers Amazon DynamoDB. Nous avons commencé par créer un ensemble de réplicas MongoDB comme source de données à migrer et avons également créé une table DynamoDB comme table de destination. Dans un article ultérieur, nous discuterons de la création et de l'exécution d'une migration DMS pour migrer des données.
