~sinzui/juju-ci-tools/repository

« back to all changes in this revision

Viewing changes to xenial/wordpress/README.md

  • Committer: Curtis Hovey
  • Date: 2015-11-06 15:43:36 UTC
  • Revision ID: curtis@hovey.name-20151106154336-soncn5peue27jtr0
Added xenial.

Show diffs side-by-side

added added

removed removed

Lines of Context:
 
1
# Overview
 
2
 
 
3
WordPress is a powerful blogging platform written in PHP. This charm aims to deploy WordPress in a fashion that will allow anyone to scale and grow out
 
4
a single installation.
 
5
 
 
6
# Usage
 
7
 
 
8
This charm is available in the Juju Charm Store, to deploy you'll need at a minimum: a cloud environment, a working Juju installation,
 
9
and a successful bootstrap. Please refer to the [Juju Getting Started](https://juju.ubuntu.com/docs/getting-started.html) documentation before continuing.
 
10
 
 
11
Once bootstrapped, deploy the MySQL charm then this WordPress charm:
 
12
 
 
13
    juju deploy mysql
 
14
    juju deploy wordpress
 
15
 
 
16
Add a relation between the two of them
 
17
 
 
18
    juju add-relation wordpress mysql
 
19
 
 
20
Expose the WordPress installation
 
21
 
 
22
    juju expose wordpress
 
23
 
 
24
## Scaled Down Usage for Personal Use
 
25
 
 
26
If you're just looking to run a personal blog and want to save money you can run all of this on a single node, here's an entire single node installation from scratch: 
 
27
 
 
28
    juju bootstrap
 
29
    juju deploy --to 0 wordpress
 
30
    juju deploy --to 0 mysql
 
31
    juju add-relation wordpress mysql 
 
32
    juju expose wordpress
 
33
 
 
34
This will run everything on one node, however we still have the flexibility to grow horizontally. If your blog gets more traffic and you need to scale:
 
35
 
 
36
    juju add-unit wordpress
 
37
 
 
38
Since we're omitting the `--to` command Juju will fire up a new dedicated machine for Wordpress and relate it. You can also `remove-unit` when the surge is over and go back to a cheaper one node set up. 
 
39
 
 
40
# Scale Out Usage 
 
41
 
 
42
You can deploy a memcached server and relate it to your WordPress service to add memcache caching. This will 
 
43
automagically install [WP-FFPC](http://wordpress.org/extend/plugins/wp-ffpc/) (regardless of your tuning settings) and configure it to cache 
 
44
rendered pages to the memcache server. In addition to this layer of caching, Nginx will pull directly from memcached bypassing PHP altogether. 
 
45
You could theoretically then turn off php5-fpm on all of your servers and just have Nginx serve static content via memcached (though, you 
 
46
wouldn't be able to access the admin panel or any uncached pages - it's just a potential scenario).
 
47
 
 
48
    juju deploy memcached
 
49
    juju add-relation memcached wordpress
 
50
    
 
51
This setup will also synchronize the flushing of cache across all WordPress nodes, making it ideal to avoid stale caches.
 
52
 
 
53
A small note, when using the Apache2 engine and memcache, all request will still be sent to WordPress via Apache where typical caching 
 
54
procedures will take place and wp-ffpc will render the memcached page.
 
55
 
 
56
# Configuration
 
57
 
 
58
This WordPress charm comes with several tuning levels designed to encompass the different styles in which this charm will be used.
 
59
 
 
60
A use case for each tuning style is outlined below:
 
61
 
 
62
## Bare
 
63
 
 
64
The Bare configuration option is meant for those who wish to run the stock WordPress setup with no caching, no manipulation of data, 
 
65
and no additional scale out features enabled. This is ideal if you intend to install additional plugins to deal with coordinating
 
66
WordPress units or simply wish to test drive WordPress as it is out of the box. This will still create a load-balancer when an additional
 
67
unit is created, though everything else will be turned off (WordPress caching, APC OpCode caching, and NFS file sharing).
 
68
 
 
69
To run this WordPress charm under a bare tuning level execute the following:
 
70
 
 
71
    juju set wordpress tuning=bare
 
72
 
 
73
## Single
 
74
 
 
75
When running in Single mode, this charm will make every attempt to provide a solid base for your WordPress install. By running in single
 
76
the following will be enabled: Nginx microcache, APC OpCode caching, WordPress caching module, and the ability to sync files via NFS.
 
77
While Single mode is designed to allow for scaling out, it's meant to only scale out for temporary relief; say in the event of a large
 
78
traffic in-flux. It's recommended for long running scaled out versions that optimized is used. The removal of the file share speeds up
 
79
the site and servers ensuring that the most efficient set up is provided. 
 
80
 
 
81
To run this WordPress charm under a single tuning level execute the following:
 
82
 
 
83
    juju set wordpress tuning=single
 
84
 
 
85
## Optimized
 
86
 
 
87
If you need to run WordPress on more than one instance constantly, or require scaling out and in on a regular basis, then Optimized is the
 
88
recommended configuration. When you run WordPress under an Optimized tuning level, the ability to install, edit, and upgrade themes and plugins
 
89
is disabled. By doing this the charm can drop the need for an NFS mount which is inefficient and serve everything from it's local disk.
 
90
Everything else provided in Single level is available. In order to install or modify plugins with this setup you'll need to edit and commit
 
91
them to a forked version of the charm in the files/wordpress/ directory.
 
92
 
 
93
To run this WordPress charm under an optimized tuning level execute the following:
 
94
 
 
95
    juju set wordpress tuning=optimized
 
96
 
 
97
### Handling wp-content
 
98
 
 
99
In order to allow for custom WordPress content within the Juju charm a separate configuration option exists for pointing to any Git or Bzr 
 
100
repository. An example of a valid formed wp-content repository can be found on the [Juju Tools Github page](https://github.com/jujutools/wordpress-site). 
 
101
To set the wp-content directive to a git repository, use one of the following formats making sure to replace items like `host`, `path`, and `repo` with their 
 
102
respective names:
 
103
 
 
104
    juju set wordpress wp-content=git@host:path/repo.git
 
105
 
 
106
or
 
107
 
 
108
    juju set wordpress wp-content=http://host/path/repo.git
 
109
    
 
110
or
 
111
 
 
112
    juju set wordpress wp-content=git://host/path/repo.git
 
113
    
 
114
If you wish to use a bzr repository, then apply one of the following schemes replacing items like `host`, `username`, `path`, and `repo` with their respective values:
 
115
 
 
116
For LaunchPad hosted repostiories:
 
117
 
 
118
    juju set wordpress wp-content=lp:~username/path/repo
 
119
    
 
120
For other Bzr repositories:
 
121
 
 
122
    juju set wordpress wp-content=bzr://host/path/repo
 
123
 
 
124
or
 
125
 
 
126
    juju set wordpress wp-content=bzr+ssh://host/path/repo
 
127
    
 
128
Setting the wp-content option to an empty string ("") will result in no further updates being pulled from that repository; however, the last pull will remain 
 
129
on the system and will not be removed.
 
130
 
 
131
## debug
 
132
 
 
133
This option will create a directory `_debug` at the root of each unit (`http://unit-address/_debug`). In this directory are two scripts: info.php (`/_debug/info.php`) 
 
134
and apc.php (`/_debug/apc.php`). info.php is a simple phpinfo script that will outline exactly how the environment is configured. apc.php is the APC admin portal which 
 
135
provides APC caching details in addition to several administrative functions like clearing the APC cache. This should never be set to "yes" in production as it exposes 
 
136
detailed information about the environments and may provide a way for an intruder to DDoS the machine.
 
137
 
 
138
    juju set wordpress debug=yes
 
139
 
 
140
to disable debugging:
 
141
 
 
142
    juju set wordpress debug=no
 
143
 
 
144
The debugging is disabled by default.
 
145
 
 
146
## Engine
 
147
 
 
148
By default the WordPress charm will install nginx and php5-fpm to serve pages. In the event you do not wish to use nginx - for whatever reason - you can switch to Apache2.
 
149
This will provide a near identical workflow as if you were using nginx with one key difference: memcached. In nginx, the cached pages are served from memcached prior to
 
150
hitting the php contents, this isn't possible with apache2. As such memcached support still works, since it falls back to the WordPress caching engine, but it's not as robust.
 
151
Otherwise, Apache2 will still perform balancing and everything else mentioned above. You can switch between engines at will with the following:
 
152
 
 
153
    juju set wordpress engine=apache2
 
154
 
 
155
Then back to nginx:
 
156
 
 
157
    juju set wordpress engine=nginx
 
158
 
 
159
Any other value will result in the default (nginx) being used.
 
160
 
 
161
# Known Limitations and Issues
 
162
 
 
163
## HP Cloud 
 
164
 
 
165
At this time WordPress + Memcached don't work on HP Cloud's standard.xsmall. To get around this deploy the WordPress charm with the 
 
166
charm to at least a `standard.small`, to do this:
 
167
 
 
168
    juju deploy --constraints "instance-type=standard.small" wordpress
 
169
 
 
170
This only is a problem when attempting to relate memcached to WordPress, otherwise an xsmall is _okay_ though it's really not the best 
 
171
sized platform for running a stable WordPress install.
 
172
 
 
173
## Single mode and the scale-out
 
174
 
 
175
If you're in Single mode and you want to/need to scale out, but you've been upgrading, modifying, and installing plugins + themes like
 
176
a normal WordPress user on a normal install; you can still scale out but you'll need to deploy a shared-fs charm first. At the time of
 
177
this writing only the NFS charm will work, but as more shared-fs charms come out (gluster, ceph, etc) that provide a shared-fs/mount 
 
178
interface those should all work as well. In this example we'll use NFS:
 
179
 
 
180
    juju deploy nfs
 
181
    juju add-relation nfs wordpress:nfs
 
182
 
 
183
By doing so, everything in the wp-contents directory is moved to this NFS mount and then shared to all future WordPress units. It's strongly
 
184
recommended that you first deploy the nfs mount, _then_ scale WordPress out. Failure to do so may result in data loss. Once nfs is deployed, 
 
185
running, and related you can scale out the WordPress unit using the following command:
 
186
 
 
187
    juju add-unit wordpress
 
188
    
 
189
In the event you want more than one unit at a time (and do not wish to run the add-unit command multiple times) you can supply a `-n` number
 
190
of units to add, so to add three more units:
 
191
 
 
192
    juju add-unit -n3 wordpress
 
193
 
 
194
# Contact Information
 
195
 
 
196
## WordPress Contact Information
 
197
 
 
198
- [WordPress Homepage](http://www.wordpress.org)
 
199
- [Reporting bugs](http://codex.wordpress.org/Reporting_Bugs) on WordPress itself
 
 
b'\\ No newline at end of file'