Acquia provides Remote Administration (RA) clients with an additional RA environment at no added cost. This environment facilitates the deployment and testing of security updates without disrupting ongoing development in other environments. Updates are deployed based on your Preferences.
For Acquia Cloud Enterprise subscribers, the RA environment is hosted on RA-specific shared Acquia servers and will have no impact on development, staging, or production servers during step one of the update process. RA environments for Acquia Cloud Professional subscribers are configured to consume no critical system resources while the website sits idle, and all critical resources remain available to the production website.
Note
The RA environment is not another development environment, as it may be overwritten at any time. If you require more development environments for your website, either contact Acquia Support or contact your Account Manager to make the request.
Security update testing
Subscriber testing of the initial step (see Implementing security updates) takes place on the RA environment. Subscribers and Acquia Support can push code to the deployed branch for testing. Testing must take into account that the RA environment may not be configured with the same specifications as your Development, Stage, or Production environments. This environment will be overwritten by new security updates, and must not be used for any ongoing development, testing, or content creation. It’s not possible to deploy code to this environment using the workflow interface.
Important
After a security update has been tagged and is ready for deployment, the database tables will be dropped on the RA environment. If the WELCOME tag is available in your repository, it will be deployed on the RA environment until the next security release.
Any code or data deployed to this environment is periodically removed, and data is not backed up before removal. As a result, the RA environment must never be used for testing anything other than automated RA updates. Acquia does not guarantee the preservation of any data or code deployed to this environment.
Databases
Databases copied to the RA environment will only remain as long as a security update branch is deployed and undergoes testing.
You can use Cloud Hooks to scrub your databases to prevent sensitive data from being copied into the RA environment. For more information about using Cloud Hooks, see Automating with Cloud Hooks.
Automated database changes
To ensure compatibility and testability in the RA environment, certain changes are made to the copied database using drush. Database level changes on the RA environment, such as creating new content or disabling modules, have no effect on the code or data deployed to any other environment. The update workflow never copies an RA environment into either the testing or production environments.
If the updated website uses modules dependent upon modules modified by automation, full testing of the features must take place on another environment. In such cases, the branch can either be deployed to another environment upon request, or the features can be tested when the branch has been tagged (step two).
- Secure Pages and Secure Login: These modules are most often coded to point to the Production website, so leaving them enabled often confuses testing. As a result, these modules are disabled using drush when an update branch is deployed to RA. You must test modules dependent on Secure Pages and Secure Login on another environment.
- Stage File Proxy: This module is added and enabled. See the following information for details.
Subscription-specific database changes
In situations where specific modules must be restricted or disabled on the RA environment, Acquia recommends taking advantage of environment-level variables in the settings.php file that can control features for each environment. It’s possible to set either an environment-specific feature using the AH_SITE_ENVIRONMENT variable or to restrict changes to the non-production environment feature by using AH_NON_PRODUCTION. These variables can be used to redirect secure pages for each environment, or to set Acquia Search to read-only on the RA environment.
Given the unique needs of each website, the subscriber must set these variables. If needed, Acquia Support can offer suggestions and examples.
Important
You can use the environment examples to set up your variables. Systems with an RA environment must include that environment in their declaration of variables or drush pm-update will fail and your website will not be updated.
Installations using the Devinci module must configure that module to include an RA environment, or Drush updates will fail.
Deploy hooks
Hooks in the common directory (typically hooks) will run on all environments, including RA. Due to differences between the RA environment and the other environments, these hook scripts can result in unexpected behaviors or task failures, which can cause the RA automated update process to fail.
If you have scripts in the common directory, you can modify them slightly to prevent them from running on the RA environment. The following example includes an if statement to include in the scripts allowing them to run as expected on all environments except for RA:
#!/bin/sh
#
#Standard hook variables here
#
site="$1"
target_env="$2"
if [ "$target_env" != "ra" ]; then
drush @$site.$target_env updatedb --yes
fi
Alternately, move any hooks located in the common directory to the development, stage, and / or production directories instead.
Files and the Stage File Proxy module
Production files are not copied into the RA environment. Instead, the Stage File Proxy module is implemented. The module is added to the repository and enabled on the RA environment only. It has no effect on production environments. This module sends file requests to the production environment and copies the production file in the RA environment. This saves both time and space. Files uploaded by other means, or theme images or CSS using the Drupal file structure rather than a theme folder, won’t display in the RA environment.
Note
Files uploaded directly to the RA environment will not work as expected.
Stage File Proxy is incompatible with the following modules:
- FileField Sources
Fast 404: Adding the following code to your website’s
settings.phpfile will ensure Fast 404 doesn’t interfere with the features of Stage File Proxy:if (!isset($_ENV['AH_SITE_ENVIRONMENT']) || $_ENV['AH_SITE_ENVIRONMENT'] != "ra") fast_404_ext_check();
Stage File Proxy doesn’t support subfolders within your Drupal user files directory. Any images or other files within subfolders won’t be displayed as expected in the RA environment.
If you are running these modules, you must deploy the security update to a different testing environment as soon as it’s available.
Memcache disabled
Memcache is not enabled in the RA environment. It may be enabled in your other environments, but should result in minimal impact to your website(s) when testing in the RA environment. The recommended memcache include statement must already be present in your settings.php file. Select the configuration appropriate for your version of Drupal:
Note
Do not change the memcache_key_prefix or memcache_servers settings in settings.php. Cloud Platform adds the correct values for these directives in Acquia-specific code called by settings.php. When you set these values manually, unexpected behavior can result.
- Configuration for the current Drupal version
For recommended settings for the current Drupal version, see Enabling Memcached on Cloud Platform. Configuration for Drupal 7
The first two of these settings cause Drupal to use Memcached instead of MySQL for data typically stored in database caches. The third setting (cache_class_cache_form) ensures thecache_formtable is assigned to non-volatile storage.if (isset($conf['memcache_servers'])) { $conf['cache_backends'][] = 'sites/all/modules/contrib/memcache/memcache.inc'; $conf['cache_default_class'] = 'MemCacheDrupal'; $conf['cache_class_cache_form'] = 'DrupalDatabaseCache'; }Or
if (isset($conf['memcache_servers']) && ($_ENV['AH_SITE_ENVIRONMENT'] != 'ra')) { $conf['cache_backends'][] = 'sites/all/modules/contrib/memcache/memcache.inc'; $conf['cache_default_class'] = 'MemCacheDrupal'; $conf['cache_class_cache_form'] = 'DrupalDatabaseCache'; }
Be sure to check that the cache_backends path is the actual path to the Memcache module in your application’s docroot directory.
If you are using a different include statement related to memcache in your settings.php files, Acquia strongly recommends replacing it with the previous statement and deploying to your production environment. After the change is deployed to production, websites deployed to the RA environment during step one of the update process will no longer be dependent on memcache while running on that environment.
Domains
The RA environment is provisioned with a single Cloud Platform subdomain like your Development, Stage, and Production environments. Other domains can be added to the RA environment from the Cloud Platform Domains page. Instructions for adding domains are available at Managing domains.
Your DNS provider must point your domain names to the IP address of the RA environment ensuring requests for that domain name are directed to the correct location on the RA servers. You can add the domain names to your local hosts file to test locally.
Authentication issues
Subscribers using a Single Sign-On (SSO) solution for Drupal user authentication may encounter issues when signing in to websites on their RA environment that haven’t been configured with the SSO. Websites using LDAP, SAML, or SimpleSAML solutions can also encounter the same issue.
If authentication issues delay your testing in the RA environment, deploy the update branch to the preferred Testing environment as set in Preferences. When creating your update ticket, be sure to request the deployment of update code to an environment other than RA. The RA Team will deploy the update branch to your preferred environment and will tell you when you can continue testing.