github.com/niedbalski/juju@v0.0.0-20190215020005-8ff100488e47/acceptancetests/repository/xenial/wordpress/README.md (about)

     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