smutek.netThis is the third in a series of screencasts that will document the process of moving a WordPress website from a shared hosting provider to a Digital Ocean droplet with Trellis, Bedrock, and Sage, with an SSL from Let’s Encrypt.
In the first screen-cast I setup Trellis & Bedrock.
In the second screen-cast I used Composer to get my theme & plugins installed, dealt with a couple of premium plugins, and migrated my data into my development environment.
In this screencast I setup my Digital Ocean droplet, prepare my project, provision the server and deploy the site. Yay! Thoughts and such below.
Suggestions
Read the docs carefully.
This is the best suggestion I have to offer. I read the docs carefuly and when my first deploy failed I realized I hadn’t read the docs carefully enough. The documentation is comprehensive, it’s your friend.
Make sure site keys have been added correctly
This tripped me up a couple of times but sure enough upon closer inspection of each failed deploy there was a stray ‘example.com’ in place of ‘smutek.net’. Generally if provisioning fails early on a missed site key is likely the culprit.
Do a couple dry runs with a spare domain
Unless you’re super comfortable with this I wouldn’t suggest your first deploy be on a mission critical or time sensitive site. It pays to be patient, not get frustrated, and go through it a couple of times until the process and concepts sink in. If things aren’t working out just destroy the DO box and try again. I’d say that I’ve done 5 or 6 deploys over the course of recording this screen-cast and at this point I’m comfortable enough with the process.
Notes
Here’s the order I did things:
Digital Ocean Setup
- Point DNS to DO
- Choose droplet : Ubuntu 14.0.4
- Add SSH Keys
- Create droplet
- Add domain to droplet (regular & www)
Provision & Deploy
- Make sure the project is added to github
- Set up variables in group_vars/production/wordpress_sites.yml
- Add the necessary settings for remote servers to group_vars/production/vault.yml
- Generate password for vault_mysql_root_password
- Generate crypted password for vault_sudoer_passwords
- Generate db_password
- Generate salts (be sure to use the Yaml, if using Trellis)
- Generate password for group_vars/all/vault.yml
- Set variables in group_vars/all/mail
- Set ‘sshd_permit_root_login: false’ ingroup_vars/all/security.yml
- Create a file called .vault_pass in /trellis. Generate a random password and save it in this file.
This is your vault password. Make sure it’s being git-ignored (it is, but double check .gitignore anyway)
- Inform Ansible of the vault password by adding vault_password_file = .vault_pass to trellis/ansible.cfg
- Encrypt vault.yml files. Use as needed, or encrypt all with:
ansible-vault encrypt group_vars/all/vault.yml group_vars/development/vault.yml group_vars/staging/vault.yml group_vars/production/vault.yml - Add server hostname to hosts/production
- Add public SSH keys for web & admin_user groups in group_vars/all/users.yml
Note, make sure your public key has been added to github, or wherever. In the case of github,
https://github.com/username.keys - If using deploy hooks, uncomment the buildhooks in ‘deploy-hooks/build-before.ym’ and replace ‘sage’ with the name of your theme directory
- Turn on caching if using it
- Verify you can ssh to your box
- Make sure all changes have been saved, committed, and pushed to VC
- Run
ansible-playbook sever.yml -e env=production - Run
./deploy.sh production yoursite.com - Go to your site & run through the WP Installer.
- Migrate database (I used DB Migrate Pro)
- Rejoice
Links
roots.io/trellis/
roots.io/bedrock/
roots.io/sage/
https://www.digitalocean.com/
https://letsencrypt.org/
Jimmy, fantastic screencast! Thank you for the light.
I was just finding the main reason to try Trellis (I’m already using Bedrock and Sage) and now completely understand it. Great job there!
Few questions on website maintenance. Are you planning to make a video on how to manage the maintenance of such setup (Trellis, Bedrock, and Sage)? I’m a little bit concern on how to pass the knowledge of handling these things to our developers (We’re an agency that do wordpress sites). I’m imagining I’m the one who will setup this and giving the repository to our developers where they can run ‘vagrant up’ only and start developing. What in my mind right now is when we have multiple sites to maintain (different soils stack), we’re gonna ‘vagrant halt’ to each trellis folder or else it will add up to one’s machine’s memory (you know, vagrant and virtual box consume hardly), but yeah, this is just my propositions.
I’m also concern of our developers using Windows Machines if they have similar experience using the stack than on using Mac. (Gosh, I have to dig more on this).
And oh, and the SSL if free using LetsEncrypt right? That’s perfect without spending too much effort on how to install one and making more visible to search engines.
Looking forward for your reply. 🙂
Hey Ruel, thanks for the comment, I’m glad you fond the screen-cast helpful.
I can definitely put something together about maintenance. It’s pretty straight forward, when plugin updates are available run
composer updatefrom the development environment, add, commit, and push the changes to version control, then deploy the environment. 🙂I’m also at an agency doing WordPress work and unfortunately we’re not using Trellis there. The reason for that is because the majority of our clients are coming to us with hosting in place and in most cases we are deploying to shared hosting. We do, however, use Sage for the majority of our sites.
We use VVV for local development, and we’ve been deploying with DployBot, which has been great. It allows us to manage our deployments with git and it runs build tasks in a docker container prior to deployment. So with each git push Deploy is running gulp –production then deploying the code for us.
If I were working with Trellis at work I’d definitely `vagrant halt` when switching to another project. Good thing with Trellis is it’s really fast, in my experience, when booting up and shutting down.
As for windows, I’m really not sure. We’re an all mac shop and if we bring on a contractor who is using Windows the expectation would be that they’d already have their environment configured, but it would also be made clear up front that the job requires familiarity with Roots tools. Requiring experience with Roots tools may cut down on the pool of available talent but, in my opinion, the amount of quality applicants would likely be much higher.
The SSL via LetsEncrypt is free. 🙂
Thanks again for checking out the screen-casts and feel free to reach out with any more questions or thoughts.
That’s pretty cool! I will definitely wait for that screencast.
Right now, we’re using AMPPS for local development for an ordinary WordPress install. It’s easy to install and configure.
I personally use Laravel Homestead if I have to use Bedrock.
I’m a fan of Laravel Forge (which is connected to Digital Ocean) and it’s deploying capabilities. If we have clients who insist on their shared hosting, then we use `git-ftp` for deployment.
I don’t know, I’m a bit leery on DployBot maybe because it will cost us up more. We have different repositories for our sage themes. We’d like it to be a submodule to have separate entity from the website itself to grab the latest updates from the official sage repo just in case. What’s your take on this?
Going to watch your screencast on VVV. 🙂
Hey Ruel, here you go: Maintaining the Roots stack.
🙂
Thanks! This was very helpful and obviously took a lot of work.