strategy for setup and migrate

[cezarneaga]

Hi Carl, Community

wanted your advice on something. I have a live site i want to migrate to a debops-wordpress setup. on creation, i know it's best to use as host the actual domain. but until i set up server, copy data and db and ensure everything is working fine i would prefer not to have the live site under maintenance.

how would you advise me to go about it?

1. temporary live site maintenance, change A records to debops server, run server setup then when finished move back A records to live, migrate data, change db urls to a subdomain and test its fine. then get new copy of db from live site under maintenance and set A record to debops
2. run debops on dev.example.com do migration, check its fine, change db links to example.com and re-run debops wordpress this time with example.com to get ssl ... (would this delete files and db?)
3. any other way?

thanks, C

[carlalexander]

I'm actually thinking about that too. My experience is limited to a migration for carlalexander.ca this summer. But I have this exact situation coming up again.

The main problem is let's encrypt SSL. As far as I know, it needs to be able to contact the domain it's issuing the certificate for. This means that you're somewhat limited by what you can do. @drybjed probably has a better idea than me. I don't know the ins and outs of debops-pki.

From what I remember, I worked around it is by using www.carlalexander.ca for the new server. I left the default @ record pointing to old server. This worked since everything was https://carlalexander.ca.

The only thing that broke was the www redirect. Once the new server was up, I changed the @ record to point to the new server and that was it.

[cezarneaga]

couldn't you run letsencrypt manually afterwards?

[carlalexander]

You could, but @drybjed wrapped it up in some other stuff in debops-pki. You could do no SSL and then turn it on after and run the playbook. But I've had mixed success with that.

[drybjed]

Hmmm, live site? Do you have existing SSL certificates for the domain (Let's Encrypt or otherwise)? You can deploy them as external certificates through debops.pki role. The scenario would be, when moving from bravo.example.com (existing host) to charlie.example.com (new host):

• configure charlie with DebOps, everything that you need, debops.nginx, debops.pki especially.
• deploy existing certificates in a temporary PKI realm with debops.nginx configuration using it for now.
• redirect the DNS from the bravo webserver to the charlie webserver. SSL should still work properly.
• re-run the debops.pki role on the charlie webserver with enabled ACME on the actual PKI realm you want to use, you should get Let's Encrypt certificates.
• switch debops.nginx role to use the new realm.

I would probably do it this way. Haven't tested that scenario out, so let me know if you do and how it went.

[cezarneaga]

live site doesn't have ssl. your explanation uses subdomains. would it be the same in the case of example.com to www.example.com as @carlalexander suggested?

if we get this to an easy to understand and manage process i would be happy to PR the wiki with the flow. but i must admit at the moment i do not understand how to translate the steps above into a wiki. :)

[drybjed]

Keep in mind, that DebOps uses ansible_fqdn and ansible_domain variables all over the place. The project is designed with a proper server naming scheme in mind.

With an example.com being an apex domain, you should name your hosts as <hostname>.example.com. In this case, Ansible will correctly detect example.com as your main domain and hostname.example.com as the host's FQDN. When you do that, you are free to point example.com and www.example.com addresses to whichever host you want. The host FQDN names should never change if possible

When you use this setup, you should be able to easliy move your website DNS domains between the two hosts.

If your site doesn't have SSL, then you should still be able to get the ACME certificates. Make sure the the initial debops.nginx configuration has disabled SSL configuration, or disable automatic SSL redirect. When you get the certificates, you can enable SSL redirect. I would test that first on a spare site to know what you are doing.

[carlalexander]

If you don't need SSL, the steps are more straightforward. You can create and configure a server called wordpress.example.com. But you have to make sure that, it's configured for example.com like so:

wordpress__domain: 'example.com'

Now, when DebOps configures the wordpress.example.com, it'll configure it to respond to example.com. You can test it by editing your local hosts file (This varies per OS) to point example.com to the IP of wordpress.example.com. You should be able to access your DebOps site. If that works, you can then change the DNS entries to point to the new server.

I'll document my next migration with SSL. This should happen in a week or so. It'll be good to have this written somewhere. 😄

[carlalexander]

So I just migrated http://productpress.me from WP Engine to DebOps. I'm writing down some rough notes about it. I'm sure there's stuff I might have missed.

ProductPress server config:

wordpress__domain: 'productpress.me'
wordpress__root: '{{ wordpress__nginx__www }}/{{ wordpress__domain }}/current'

wordpress__user_allow_remote: true

wordpress__ssl: True

Here are the steps that I did to migrate the server:

1. Back up files and database
2. Create a server with same domain (e.g. www.productpress.me)
3. Point www hostname to server. Leave @ hostname pointing to old server.
4. Run debops bootstrap -u root --limit www.productpress.me
5. Run debops --limit www.productpress.me
6. Run debop wordpress --limit www.productpress.me
7. Create a template project using template
8. Merge back up files into template and push to GitHub
9. Add wordpress user public SSH key as deploy key to GitHub repo
10. Run dep setup
11. Run dep deploy
12. Change DNS entries to point to new server
13. Remove error.log in /etc/pki/realms/productpress.me/acme
14. Run /usr/local/lib/pki/pki-realm schedule
15. Restore database

Steps 12-14 might be because I chose www.productpress.me as the hostname. If I chose a better hostname, the Let's Encrypt certificates might have been created. @drybjed can probably confirm this.

For step 15, I also had to edit the backup to remove everything related to wp_users and wp_usermeta. Otherwise, it would have overwritten the user created by DebOps. You might not need to do this.

[felixfrtz]

I need to move a site to a different hoster (the debops Droplet), it's currently at siteground. The domain needs to stay the same (www.example.com, www is important since we are planning on using cloudflare), in addition SSL is needed, the current page has a Let's Encrypt certificate. Now I made a copy of the site and deployed it like described in the wiki, but with a temporary domain (without SSL), currently I'm busy fixing some bugs on it. So basically, everything needs to stay the same, the site just needs to switch to the debops server.

@carlalexander Could you elaborate a little on the following: Now the question is if I can follow your last reply here, I have a few questions regarding this: At 3, what is meant by pointing @ hostname to old server? Similar at 12, I am unsure what needs to be pointed where. And where does Let's Encrypt fit into this?

[carlalexander]

In your DNS admin panel, you can set an ip for @. This is the default address for the domain. Like the IP that you'll get if you do https://productpress.com. I started by only changing the IP of https://www.productpress.com, but https://productpress.com still went to the old server. Once I was done setting up the new server, I switched the IP for @ to point to the same one as https://www.productpress.com.

Let's Encrypt was handled by doing things this way. I didn't have to do anything else.

[cezarneaga]

Hi Carl,

rechecked migration topic and came across your comment above. i need a few minutes of your time to clarify a few points. 7. no readme on that repo but i assumed you mean cloning the repo, and editing the deploy.php and servers.yml 8. adding my themes and plugins and pushing to github. 9. here we talk of the key from the server i assume. done without issues :) 10. and 11. is where i am lost. where do i install deployer? should it be on local machine? in the new template project folder? after doing this i get this error:

[Error] Call to undefined function Deployer\serverList()

 #0 phar:///usr/local/bin/dep/src/Deployer.php(318): require()
 #1 [internal function]: Deployer\Deployer::Deployer\{closure}()
 #2 phar:///usr/local/bin/dep/src/Deployer.php(319): call_user_func(Object(Closure))
 #3 phar:///usr/local/bin/dep/bin/dep(119): Deployer\Deployer::run('6.0.2', '/Users/cezar/Do...')
 #4 /usr/local/bin/dep(4): require('phar:///usr/loc...')
 #5 {main}

thanks for any help

C

[cezarneaga]

slept over it and found my answers. :) will push a PR with updated code for deployer v6. not sure why you have a staging host too though. maybe you can help with that?

[carlalexander]

What do you mean by staging host? You mean in the template project.

[cezarneaga]

yes. in servers.yml