Setting Up a CrafterCMS Production Environment
This section lets you get started on setting up your CrafterCMS for production. A production environment normally consists of one authoring instance and one or more delivery instances.
Before we begin, please review the following for requirements and supported platforms: Requirements
Setting up the production environment
We’ll first install the authoring instance. You can follow the instructions here to install and start authoring.
Create your project in authoring. You can follow the guide Your First Project (templated) to use one of the out-of-the-box blueprints provided by CrafterCMS.
Now that you have a project setup in authoring, the next thing to do is to setup your project in the delivery instance(s). Let’s begin the delivery installation.
Installing the delivery instance is almost the same as installing the authoring instance. The difference is, you need to download/use
crafter-cms-delivery-VERSION.tar.gz. Follow the same steps used to install your authoring environment using the delivery binary files.
After starting delivery, we’ll setup the project we created in step 2 in our delivery instance. CrafterCMS comes with a script,
init-site.sh, to help us setup our project for delivery.
./init-site.sh [options] [project] [repo-path]
Remember that when using private key SSH authentication, the private key path must be set explicitly using the
-koption. Here’s an example:
init-site -k ~/.ssh/jdoe_key myeditorial ssh://myserver/opt/crater/sites/myeditorial
See the guide Setup Project for a Delivery Environment for more information on setting up your project for delivery.
For the rest of the delivery instances, you can just repeat the previous 2 steps for each one of them, or alternatively just duplicate the delivery installation directory for each instance.
Your production environment is now ready.
For more information on using gradle, please see CrafterCMS.
Server Hardware Configuration Consideration
CrafterCMS performs multiple reads/writes to disk from various concerns such as the database, the repository, logs, etc. with very different I/O patterns. One of the primary factor for hardware bottlenecks is disk I/O.
For optimal performance, the server should have different storage systems (disks) mounted for different concerns, for example:
For more information on tuning your authoring environment for better performance, please see: Authoring Environment Performance Tuning
System Configuration for Elasticsearch
Elasticsearch uses a lot of file descriptors or file handles. Elasticsearch recommends increasing the number of open file descriptors for the user running Elasticsearch to 65,536 or higher.
CrafterCMS uses the .zip ELasticsearch package. When using the .zip package, the system settings for increasing the number of open file descriptors can be configured:
Set Temporary Limits
To set temporary limits for the open file handles (ulimit -n) to 65,536:
1sudo su 2ulimit -n 65535 3su elasticsearch
Here’s what the above lines of code is doing:
Change the max number of open files.
Become the elasticsearch user in order to start Elasticsearch.
Remember that this new limit is only valid for the current session.
Set Persistent Limits
To set persistent limits, edit the
/etc/security/limits.conf file. To set the maximum number of open files for the
elasticsearch user to 65,536, add the following line to the
elasticsearch - nofile 65535
Remember to restart your system as this change will only take effect the next time the
elasticsearch user opens a new session.
Ubuntu ignores the
limits.conf file for processes started by init.d. To enable the
limits.conf file, edit
/etc/pam.d/su and uncomment the following line:
# session required pam_limits.so
For more information on configuring system settings in Elasticsearch, see: https://www.elastic.co/guide/en/elasticsearch/reference/current/setting-system-settings.html
For more information on file descriptors in Elasticsearch, see: https://www.elastic.co/guide/en/elasticsearch/reference/current/file-descriptors.html