How to create subdomain on digital ocean correctly?

I’m trying to create a subdomain on one digital ocean droplet. It appears that in the roots-example-project, staging and production both point to the same IP address. Does this require setting up virtual hosts on digital ocean as well as the subdomain DNS?

Here’s what’s happening for me so far.

–I have set up a subdomain in my DO DNS settings.
–I can provision and deploy to staging and staging.mydomain.com works, but then mydomain.com doesn’t work
–I can provision and deploy to production and mydomain.com works, but then staging.mydomain.com doesn’t work
–should I be able to ssh into my droplet and see a folder for the subdomain somewhere?

Thanks for your help!!

@ericgauvin Although the default wordpress_sites list has just one site, you may list multiple sites/subdomains for your DO droplet. The list is per environment, so the idea is that if a given Trellis project has multiple sites, the staging versions of those sites will go on one DO droplet and the production versions of the sites will go on a separate DO droplet.

However, it sounds like your goal is to put a given site’s staging and production versions on a single DO droplet. You can do so, but you’ll have to adjust your Trellis setup slightly. See if these tips help (and this).

1 Like

I think the example project lists the same example IP of 192.168.50.5 in the staging and production hosts files just because it is understood to be an example IP (being from the private network IP range) – an IP to be changed in your project – but not to indicate that staging and production should use the same IP.

So, this example IP happens to be the same, but I’m pretty sure the idea is that a default Trellis setup would have different IPs for staging and production (unless you make the modifications I mentioned).

@fullyint

Okay. That makes sense about separate droplets per environment.

The other part about having multiple sites under one trellis project doesn’t make sense.

I was following the github readme for trellis and it shows this structure:

example.com/ - Primary folder for the project
├── ansible/ - Your version of this repo (renamed to just ansible)
└── site/ - A Bedrock-based site (suggested to name this the generic site since your project name is already at the top level)

So I was thinking that each project (website) would have its own ansible and bedrock. However, I was also wondering about the yml filename “wordpress_sites.yml” and if we’re supposed to put more than one site for one ansible folder (or is it named like that for multisite implementations). Just doesn’t make sense to me if it’s in the “domainname.com” folder. I’m confused. (but inching forward)

Thanks for your help.

I’ll let someone else comment on multisite potential because I haven’t implemented multisite yet. I’ll grant you that having the top level folder be the site name example.com makes it seem that “each project (site) would have its own ansible and bedrock,” as you said.

However, I think it’s just an example and in the case of this example there’s a bit of flexibility. Here’s an alternative example that might demonstrate having multiple sites.

Imagine you have several website clients whose sites you’ve found a good reason to put on the same DO droplet. Perhaps they are all hair salons. Instead of naming the project root example.com, you could name it salons or whatever works for you. Then you’d have separate bedrock projects/folders (WP + theme) per site, but one ansible folder.

salons/
├── ansible/
├── allclips/
├── beautiesalon/
└── cutswell/

Your wordpress_sites might then look like this:

wordpress_sites:
  allclips:
    site_hosts:
      - allclips.com
    local_path: ../allclips # path targeting local Bedrock site directory (relative to Ansible root)
    repo: git@github.com:username/salons.git
    branch: master
    subtree_path: allclips # relative path to your Bedrock/WP directory in your repo (above) if its not the root (like the roots-example-project structure)
    ⋮
    env:
      wp_home: http://allclips.com
      wp_siteurl: http://allclips.com/wp
      ⋮
  beautiesalon:
    site_hosts:
      - beautiesalon.com
    local_path: ../beautiesalon # path targeting local Bedrock site directory (relative to Ansible root)
    repo: git@github.com:username/salons.git
    branch: master
    subtree_path: beautiesalon # relative path to your Bedrock/WP directory in your repo (above) if its not the root (like the roots-example-project structure)
    ⋮
    env:
      wp_home: http://beautiesalon.com
      wp_siteurl: http://beautiesalon.com/wp
      ⋮
  cutswell:
    site_hosts:
      - cutswell.com
    local_path: ../cutswell # path targeting local Bedrock site directory (relative to Ansible root)
    repo: git@github.com:username/salons.git
    branch: master
    subtree_path: cutswell # relative path to your Bedrock/WP directory in your repo (above) if its not the root (like the roots-example-project structure)
    ⋮
    env:
      wp_home: http://cutswell.com
      wp_siteurl: http://cutswell.com/wp
      ⋮

When you ssh into the server you’d find the separate bedrock installs at
srv/www/allclips/current/
srv/www/beautiesalon/current/
srv/www/cutswell/current/

6 Likes

Okay. That makes sense. If that’s the intended usage, the trellis example is perplexing.

I would set them up like two completely different sites if you want to have your staging and production on the same droplet.

So DNS should have a regular A record pointing to the IP, then also you want to either independently set up the DNS for staging as well

A Record
@ points to IP
staging points to IP

Then go in and set up another virtual host only use staging.example.com just like it was the root domain and you should be fine as long as you don’t try and have wildcard DNS set up on the root domain because that may or may not cause an issue, I have never tried.

What I would do is just launch up a droplet while you are testing then shut it down after your done.

Also another much easier solution for you may be to use this…
https://premium.wpmudev.org/project/cloner/

Basically you click one button and it clones your main multisite (or any subdomain site) onto another subdomain for testing. I have used it a couple times before because I have the subscription for them and it works really good if you just want to check something out real quick before you try it on your live site.

Also their multi-domain and domain mapping plugins are huge if you just want to run one multisite and have completely different domains mapped to the subsites.

+1
Thank you for your excellent example.

Hi All,

Thank you for all the info. I now have everything up and running. My question now is how do you setup the build-before.yml. I have 2 sites currently that each use a sage theme. Would I just duplicate this the code below and adjust for the theme name in the same file?.. or create an additional yml file? Thank you in advance.

---
- name: Install npm dependencies
  command: yarn
  connection: local
  args:
    chdir: "{{ project_local_path }}/web/app/themes/sage"

- name: Install Composer dependencies
  command: composer install --no-ansi --no-dev --no-interaction --no-progress --optimize-autoloader --no-scripts
  args:
    chdir: "{{ deploy_helper.new_release_path }}/web/app/themes/sage"

- name: Compile assets for production
  command: yarn build:production
  connection: local
  args:
    chdir: "{{ project_local_path }}/web/app/themes/sage"

- name: Copy production assets
  synchronize:
    src: "{{ project_local_path }}/web/app/themes/sage/dist"
    dest: "{{ deploy_helper.new_release_path }}/web/app/themes/sage"
    group: no
    owner: no
    rsync_opts: --chmod=Du=rwx,--chmod=Dg=rx,--chmod=Do=rx,--chmod=Fu=rw,--chmod=Fg=r,--chmod=Fo=r