This section contains a set of recommendations around setting up a production environment. Your requirements will of course depend on the expected volumes and required resilience, so treat this as a guide.
Note: The traffic to these servers is extremely spiky as the apps will all be woken up after a push notification and attempt to download the edition packages.
If you do not wish to host this yourselves, we recommend our excellent Hosting partner Sleek Networks:Sleek Pugpig Hosting
Using the Varnish Accelarator and Authentication
In order to reduce the load on origin, we recommend using Varnish as an accelerator. We provide a starting configuration file (VCL) to help ensure the correct items are cached.
If you want to protect your content securely, you MUST use Varnish.
You need to ensure this VCL makes sense for your environment, especially if you have other sites/systems running behind the same Varnish config. We would recommend not having anything else served from the same domains as your Pugpig site to simply items.
Internal CMS vs External API domains
We recommend you provide separate domains for internal, editorial use and public facing, external use. For example, we would suggest:
- cms.app.yoursite.com - used by CMS authors
- api.app.yoursite.com - used by the Pugpig Apps
- cdn.app.yoursite.com - points to the CDN
If you already have a web site running on the same Drupal instance, it should be on something separate such as:
- www.yoursite.com - something other than the two above
It normally only allows people to log into the CMS using the cms. domain, and restrict access to the cms. domain at the firewall level, possibly only to trusted IP addresses.
You CANNOT use Basic Authentication on the domain the app will use (api.) or this will interfere with the purchasing of content by end users.
The packager will make CURL requests to itself, so it needs to be able to resolve it's own domain name from the server.
Using a Content Delivery Network
We recommend using a Content Delivery Network to reduce the load on the origin servers, and to improve performance to the end users, especially those that are not in the same country as the origin server.
Once you have set up your CDN, you need to add it into the Pugpig Setting. You are responsible for ensuring items are decached as required, although the module does ensure content packages have a different file name each time something is repackaged. Cover images might need to be manually purged if updated.
Note that the module comes with an integration for Amazon Cloudfront invalidaton. See our instructions for setting up Cloudfront.
Providing a staging environment
We recommend you provide 2 environments. The production environment is where all the authoring of content will happen. However, in order to test new code releases, module upgrades or provide training, a second environment is suggested. Ideally this environment mirrors production (including the use of Varnish and the CDN).
Suggested domains could be something like:
- cdn.stage.app.yoursite.com (pointing to the CDN)
Apache Rewrite Rules
In order to improve performance, we recommend using Apache to do the required URL rewrites. If you do not use this, Drupal does the rewriting instead and doesn't set the correct cache headers.
We strongly recommend testing your setup using the app (or Pugpig Reader) using the Charles Proxy to ensure everything is working as expected.
If you're using a package feed, you should expect to see:
- A request to the top level OPDS feed every time the app is started (/feed/opds)
- Requests to cover images the app has not yet downloaded
- A request to the package manifest file (package.xml) for the edition when download starts
- Requests to each of the ZIP files the make up a package. By default there will be two zip files. One for the HTML and one for the assets.
For a published edition, requests to cover images and the large, asset ZIP file should be via the CDN if you have set one up.
Note that if you're using iOS Newsstand you should see both a HEAD and GET request to each item.