Reputation: 15
What is the right way to deploy db from dev to prod, and to pull it back after some changes made in prod? Now I just keep the mongo dump in the repository, but I think there should be a more correct method.
Upvotes: 1
Views: 506
Reputation: 7572
Copying databases isn't an official built-in feature but I understand the workflow you are talking about. Around the time you hand the site over to your customer or make it live for the public, you'll usually want to push an existing database up to your production server. And later, you will often want to copy it down to your development computer.
There are sync-up
and sync-down
scripts here:
https://github.com/apostrophecms/apostrophe-boilerplate/tree/master/scripts
These scripts assume that you're using our Stagecoach deployment system, and that mongodb is running directly on the production server and will accept connections from itself (from localhost) without a password. These assumptions may not hold for you, so you may need to adapt these scripts to your needs.
The essential answer though, as you'll see in these short scripts, is (for this story I'm using the "sync down from production to development" use case):
Use mongodump
to make a portable copy of the database on the remote, production server. rsync it down and use mongorestore
to restore it.
ssh $remoteSSH mongodump -d $dbName -o /tmp/mongodump.$dbName &&
rsync -av $rsyncDestination:/tmp/mongodump.$dbName/ /tmp/mongodump.$dbName &&
ssh $remoteSSH rm -rf /tmp/mongodump.$dbName &&
mongorestore --noIndexRestore --drop -d $dbName /tmp/mongodump.$dbName/$dbName
rsync
to copy public/uploads
down as well.rsync -av --delete $rsyncDestination:/opt/stagecoach/apps/$projectName/uploads/ ./public/uploads
See the script for how the variables are initialized.
If you are hosting your production content in S3 then you could use the AWS CLI, in particular the aws s3 sync
command.
Hope this is helpful!
Upvotes: 3