xedinunknown / divine-love-society-website-2017 Goto Github PK

DigitalOcean allows the usage of a provisioning system called cloud-init. This repository includes configuration for that system - a cloud-config - in do-provision.yml. While the format of configuration is standard for anything running cloud-init, different systems need to be configured differently. This file contains the YAML configuration specifically for use with DigitalOcean. While the same configuration may allow provisioning of systems with other VPS providers, it is not guaranteed to work with anything other than DigitalOcean.

When using the DigitalOcean API, one may want to retrieve the contents of that file programmatically. However, when using the web UI - the online control panel - it may be necessary to copy-paste the contents into the userdata field.

The Vagrantfile is based on ScotchBox 3, and will set up a local environment. However, the docroot of Bedrock is different to the default docroot of Apache, which is used by ScotchBox. Therefore, the Vagrantfile has been modified to run a provisioning script. This script changes the default web-server docroot and the docroot of the example virtualhost scotchbox.local to the one used by Bedrock.

It is unadvisable to commit the .env file, because it usually contains sensitive data, such as the encryption keys and database access credentials used on the site. However, this file is included here, and contains the credentials for working with the local ScotchBox installation. DO NOT COMMIT TO ACTUAL PROJECT.

This project uses bedrock-capistrano - a Capistrano configuration that allows structured and consistent deployment of Bedrock-powered WordPress to remote environments. To stick to the default setup, the remote environment is required to have a user with name deploy - the commands run by Capistrano in the target environment will be run under that username. The DigitalOcean cloud-config tells the environment to set up that user for SSH access. However, the authorized key will need to be added first. So, before creation of the remote environment, generate an SSH key pair (if you haven't already), and add the public key to the list of authorized keys; be sure to remove the example key. Then, point Capistrano to your private key by updating the SSH key path. While in the Capistrano environment config, also update the hostname of your server.

Capistrano does not upload local files to the target server, but instead uses Git to clone the remote repository of your project. The URL of the Git repository is normally the same for all your environments, and therefore are located in config/deploy.rb.

The WordPress config for the target host must be in the .env file. The file in this repo contains configuration that matches the local virtual environment created by ScotchBox. To configure it for the target server, it needs to be updated to match that server's environment, and uploaded manually to the shared folder of your application, which by default would be at /srv/www/html/shared.

git clone --depth=1 https://github.com/Dhii/scotch-on-rocks.git my-project
cd my-project

Just delete the .git folder, then run this:

git init

The above will initialize another repository. Now commit everything:

git add .
git commit

For example, you can create an empty repo on GitHub. Then, a command to point your local repo to the new remote could look like this:.

git remote add origin https://github.com/my-user/my-project.git

As per the sections above:

1. Set the repo URL to the URL of the repo created above.
2. Generate and set the authorized keys to the public key.
3. Set the path to the private key.
4. Set the target hostname.
5. Push your changes. This is necessary for Capistrano.
6. Configure the hosting.
   • For DigitalOcean, create a droplet with this user data. You may want to replace the values of mysqlPassword, wordpressDatabase, wordpressUser, wordpressPassword with actual credentials. However, it is not advisable to commit changes to this file for security reasons.
   • Watch out when using special shell characters: these values will be parts of shell commands, and therefore must be escaped.
7. Run bundle install as per bedrock-capistrano requirements.
8. Create an env config at /srv/www/html/shared/.en.
   • You can use the existing .env file as template. However, it is not advisable to commit changes to this file for security reasons.
   • You will need to SSH into the target server for this. It should be possible to use the deploy user that is created as part of provisioning, with one of the keys from step 4.2.

1. Before the first deployment, run bundle exec cap production deploy:check.
2. Then, deploy with bundle exec cap production deploy