Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Running multiple wordpress? #41

Open
doct15 opened this issue Dec 14, 2016 · 1 comment
Open

Running multiple wordpress? #41

doct15 opened this issue Dec 14, 2016 · 1 comment

Comments

@doct15
Copy link

doct15 commented Dec 14, 2016

If I wanted to have several of this wordpress deployed to Joyent at the same time, let's say three instances, what values in instance 2 and 3 should I change to accomplish this?
MANTA_BUCKET, I assume is one.

Any guidance is appreciated.

@misterbisson
Copy link
Contributor

misterbisson commented Dec 14, 2016

@doct15: a similar question was asked in TritonDataCenter/containerpilot#260 shortly after yours. The use case here is probably different from there, but that discussion may also be useful.

To your question:

If I wanted to have several of this wordpress deployed to Joyent at the same time, let's say three instances

You'll have to separate two basic parts: the running containers and the database backups in Manta.

You identified the Manta piece, and a specific MANTA_BUCKET for each WordPress instance is probably all you'd need. I say "probably" because you might want to create separate sub-users and permissions for those backups, but that's only if you have different operators that you isolate from each other. If the same people are operating all three sites, then I wouldn't bother with that (you could still separate them later, if you wanted).

Separating the running instances is what's discussed in TritonDataCenter/containerpilot#260. The scenarios I outlined in TritonDataCenter/containerpilot#260 (comment) don't directly apply to this, but the solutions do. Which of the solutions would work better for you depends on a few questions, and in some ways your preference.

You basically have two choices: complete isolation or partial isolation.

Complete isolation

Complete isolation would start with running separate Consul clusters. Each Consul cluster would have a different CNS service name (you'd have to set that here). You'd then have to set a matching name in the CONSUL variable in your _env (which is set from here). Once you do that (and set a separate MANTA_BUCKET), the different WordPress environments will operate independently.

Partial isolation

However, you might point out that you'd like to save money by running a shared Consul cluster and maybe, Nginx instances (with an nginx.conf that has all the details for all three WordPress sites). To make that work you'll have to namespace the service names each container announces itself as, and upstreams each container watches for. Those are set in the containerpilot.json, and it's possible to use environment variables there so they can be set dynamically (that's where the discussion in TritonDataCenter/containerpilot#260 starts).

Thinking through the costs and savings from the above, the Consul cluster costs about $7.20 per month per WordPress site if you completely isolate everything. To save money, you might decide to run a single node of Consul (all the data can be regenerated if the Consul node dies), in which case the cost for Consul is just about $2.40 per month per WordPress site. So, we have four options:

  1. Complete isolation, full HA Consul: A three node Consul cluster for every WordPress site, about $7.20 per month per site, $21.60 for three sites
  2. Complete isolation, "stateless" Consul: A single node of Consul for every WordPress site, about $2.40 per month per site, $7.20 for three sites
  3. Partial isolation, full HA Consul: A three node Consul cluster for all three WordPress sites, about $7.20 per month for three sites
  4. Partial isolation, "stateless" Consul: A single node of Consul for all three WordPress sites, about $2.40 per month for three sites

Which one you choose might depend on what else you're doing with Consul (storing other configuration details that can't be recovered, for example).

The savings opportunity by sharing the Nginx instances might be greater, but hat complexity is higher.

Bonus: WordPress multisite

Finally, you can also skip all of the above and run multiple WordPress sites using WordPress multisite. This Docker image does not have support for that now, but we'd be willing to work with somebody to implement it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants