Cloud Platform
Additional changes for Cloud Next readiness
This page lists the changes that you must make so that your application can be upgraded to Cloud Next. These changes do not break the existing functionality in Cloud Classic. You must perform these changes prior to your application upgrade. These development best practices help you to ensure a smooth upgrade.
To use the sendmail transport, you must configure the Swift Mailer module by using the t mode. For more information, see Swift Mailer settings for Cloud Platform.
When using the flock command to prevent commands from executing concurrently, ensure that the lock file is written to a location that is writable and not ephemeral. In Cloud Classic, paths such as /tmp could be used for flock since all the jobs would execute on the same servers. However, that directory is not shared across multiple containers on Cloud Next. Therefore, Acquia recommends that you use the Drupal private files directory located at /mnt/data/${AH_SITE_NAME}/files-private.
An example usage of flock on Cloud Next that is also compatible with Cloud Classic:
Cloud Platformflock -x -n /mnt/data/${AH_SITE_NAME}/files-private/flock.example -c "echo 'hello world'"The MyISAM table engine is unavailable in Cloud Next. Although InnoDB is the default database for Drupal since the release of Drupal 7.0, Cloud Platform supports MyISAM tables prior to Cloud Next.
To determine if your current database tables use the MyISAM engine, use:
SELECT TABLE_SCHEMA, TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE ENGINE = 'MyISAM';Cloud Platform has the following limitations for custom variables:
For more information, see Creating custom environment variables.
Cloud Next does not support scheduled cron jobs running every one minute. If you have any scheduled jobs that run at a frequency of 1 minute, you must reduce their frequency so that they do not run more than once every 5 minutes.
* * * * * or Every Minute.*/5 * * * *.If you do not make this change by the time your environments are upgraded, any cron jobs running too frequently are automatically set to a lesser frequency. This might impact the normal operations of your sites if not tested beforehand.
The Memcached binary protocol is not supported in Cloud Next environments. It is a deprecated feature of Memcached since Memcached 1.6.0, but is still supported in Cloud Classic.
If you enable binary protocol in Cloud Next environments, Drupal and PHP cannot communicate with Memcached. The application fails to set or get cache items, but does not return an error message.
In your settings.php file or any file included in the settings.php file that contains Drupal Memcache module configurations, remove or comment out any lines similar to the following that set the OPT_BINARY_PROTOCOL parameter to true:
$settings['memcache']['options'][Memcached::OPT_BINARY_PROTOCOL] = TRUE;Include files used in Cloud Next reference the MemcacheTimestampInvalidator class, which is not provided by the Memcache module prior to 8.x-2.0-beta1. Therefore, using older versions of the Memcache module triggers a fatal PHP error when bootstrapping Drupal.
You must update applications to the latest stable release of the Memcache module.
Customers with SimpleSAMLphp in an application must make a few changes before upgrading to Cloud Next to ensure ongoing compatibility with both Cloud Classic and Cloud Next. For more information, visit Using SimpleSAMLphp with Drupal 10.
To ensure reliable deployments in Cloud Next, application codebases must not exceed 2 GB. Application codebases that exceed 2 GB experience timeouts or failure during deployments. In addition, code in a single branch must not exceed 500 MB to avoid the risk of code deployment failures.
You must review your repository for any files that can be stored in a public files directory. For example, large image assets, audio/video files, and PDFs.
Additionally, you must verify that public files directories, such as sites/default/files, are not committed to the repository. Once deployed to Cloud Platform, the distributed file system is mounted in that location. This hides anything that you commit to the repository.
The live development feature is deprecated and is unavailable for environments running on the Cloud Next infrastructure or Site Factory. Acquia recommends that you use Cloud IDE instead. For more information, see disabling live development.
| Directive | Max size | Default value |
|---|---|---|
upload_max_filesize | 1024 MB | 256 MB |
client_max_body_size | 1024 MB | 256 MB |
post_max_size | 1024 MB | 256 MB |
memory_limit | 1024 MB | 128 MB |
During your upgrade to Cloud Next, these values are adjusted as needed so that they are within the limits.
In Cloud Next, the max_file_uploads PHP directive is limited to the default value of 20. During your upgrade, your application is adjusted to match this limit.
In Cloud Next, you cannot configure your multisite installation to share database tables, such as users, sessions, and profiles tables, across multiple websites. Therefore, you must adjust your application to not use shared tables.
Custom PHP extensions, including the ones that are compiled and included in your codebase, are not supported in Cloud Next. You must change your application to remove dependency on custom extensions, or contact your Acquia account team for assistance.
The MySQL version in Cloud Next infrastructure is Aurora MySQL 8.0. Drupal 7 versions earlier than 7.76 and Drupal 8 versions earlier than 8.6 are incompatible with MySQL 8.0. Before you plan to upgrade your application to Cloud Next, you must ensure that the Drupal version in your application is compatible with MySQL 8.0. For more information, see Amazon Aurora major versions.
All environments, applications, and subscriptions upgraded to Cloud Next are subject to the March 31st, 2021 revisions to Acquia’s Support Users Guide and Acquia’s Products & Services Guides (Legacy Server-based Pricing Model, Current Views/Visits Pricing Model), especially as they pertain to Acquia’s Resource Limits on dynamically auto-scaling infrastructure. See all sections related to the use of shared resources, infrastructure capacity, and capacity management for more details.
If you have MySQL Workbench installed locally, you might not be able to connect to Cloud Next environments. This issue occurs for a few versions of MySQL Workbench.
If you face issues connecting to Cloud Next environments from MySQL Workbench:
Open Terminal on your local machine and run:
{ssh -L $LOCAL_PORT:$DB_HOST:3306 $SSH_STRING}
Here,
LOCAL_PORT is the port to which Workbench must connect when using localhost.DB_HOST is the hostname obtained from the Cloud Platform user interface.SSH_STRING is the full connection string from the Cloud Platform user interface. For example, user@something.SSH keys that were manually added to an environment before the October 2018 EOL of per-environment SSH key management will not persist after the upgrade to Cloud Next. If your application was running on Cloud Platform Enterprise before that date, visit the Users & Keys page for each of your application’s environments before they are upgraded. You must ensure that all necessary SSH keys are properly associated with users in your subscription’s Teams & Permissions console.
Failure to do so may result in errors whenever users, scripts, development software, automations, or remote services attempt to access those environments after they are upgraded.
The /var/log/sites directory is no longer available for direct log access or custom log storage. Use /shared/logs for custom log storage instead.
Acquia reserves the right to terminate queries at a certain threshold to preserve the overall experience. As a best practice, Acquia recommends that queries do not run longer than 60 seconds for non-production environments and 5 minutes for production environments. To ensure that your environments complete all long-running transactions as expected, wrap them in a MySQL transaction to avoid the risk of data loss or corruption. If your environments require long-running MySQL queries to complete reports or other complex data management processes, contact your Acquia Accounts team to request a delay to your upgrade to Cloud Next.
Applications running on Cloud Next should test all Remote Administration patches in a Cloud Next non-production environment before pushing changes to the production environment. This ensures that no differences in Cloud Next and Cloud Classic logic impact the way patches behave after deployment in a Cloud Next environment.
Logic requiring access to a tmp or persistent shared directory must be redirected to $HOME on Cloud Next.
If this content did not answer your questions, try searching or contacting our support team for further assistance.
Cloud Next does not support scheduled cron jobs running every one minute. If you have any scheduled jobs that run at a frequency of 1 minute, you must reduce their frequency so that they do not run more than once every 5 minutes.
* * * * * or Every Minute.*/5 * * * *.If you do not make this change by the time your environments are upgraded, any cron jobs running too frequently are automatically set to a lesser frequency. This might impact the normal operations of your sites if not tested beforehand.
The Memcached binary protocol is not supported in Cloud Next environments. It is a deprecated feature of Memcached since Memcached 1.6.0, but is still supported in Cloud Classic.
If you enable binary protocol in Cloud Next environments, Drupal and PHP cannot communicate with Memcached. The application fails to set or get cache items, but does not return an error message.
In your settings.php file or any file included in the settings.php file that contains Drupal Memcache module configurations, remove or comment out any lines similar to the following that set the OPT_BINARY_PROTOCOL parameter to true:
$settings['memcache']['options'][Memcached::OPT_BINARY_PROTOCOL] = TRUE;Include files used in Cloud Next reference the MemcacheTimestampInvalidator class, which is not provided by the Memcache module prior to 8.x-2.0-beta1. Therefore, using older versions of the Memcache module triggers a fatal PHP error when bootstrapping Drupal.
You must update applications to the latest stable release of the Memcache module.
Customers with SimpleSAMLphp in an application must make a few changes before upgrading to Cloud Next to ensure ongoing compatibility with both Cloud Classic and Cloud Next. For more information, visit Using SimpleSAMLphp with Drupal 10.
To ensure reliable deployments in Cloud Next, application codebases must not exceed 2 GB. Application codebases that exceed 2 GB experience timeouts or failure during deployments. In addition, code in a single branch must not exceed 500 MB to avoid the risk of code deployment failures.
You must review your repository for any files that can be stored in a public files directory. For example, large image assets, audio/video files, and PDFs.
Additionally, you must verify that public files directories, such as sites/default/files, are not committed to the repository. Once deployed to Cloud Platform, the distributed file system is mounted in that location. This hides anything that you commit to the repository.
The live development feature is deprecated and is unavailable for environments running on the Cloud Next infrastructure or Site Factory. Acquia recommends that you use Cloud IDE instead. For more information, see disabling live development.
| Directive | Max size | Default value |
|---|---|---|
upload_max_filesize | 1024 MB | 256 MB |
client_max_body_size | 1024 MB | 256 MB |
post_max_size | 1024 MB | 256 MB |
memory_limit | 1024 MB | 128 MB |
During your upgrade to Cloud Next, these values are adjusted as needed so that they are within the limits.
In Cloud Next, the max_file_uploads PHP directive is limited to the default value of 20. During your upgrade, your application is adjusted to match this limit.
In Cloud Next, you cannot configure your multisite installation to share database tables, such as users, sessions, and profiles tables, across multiple websites. Therefore, you must adjust your application to not use shared tables.
Custom PHP extensions, including the ones that are compiled and included in your codebase, are not supported in Cloud Next. You must change your application to remove dependency on custom extensions, or contact your Acquia account team for assistance.
The MySQL version in Cloud Next infrastructure is Aurora MySQL 8.0. Drupal 7 versions earlier than 7.76 and Drupal 8 versions earlier than 8.6 are incompatible with MySQL 8.0. Before you plan to upgrade your application to Cloud Next, you must ensure that the Drupal version in your application is compatible with MySQL 8.0. For more information, see Amazon Aurora major versions.
All environments, applications, and subscriptions upgraded to Cloud Next are subject to the March 31st, 2021 revisions to Acquia’s Support Users Guide and Acquia’s Products & Services Guides (Legacy Server-based Pricing Model, Current Views/Visits Pricing Model), especially as they pertain to Acquia’s Resource Limits on dynamically auto-scaling infrastructure. See all sections related to the use of shared resources, infrastructure capacity, and capacity management for more details.
If you have MySQL Workbench installed locally, you might not be able to connect to Cloud Next environments. This issue occurs for a few versions of MySQL Workbench.
If you face issues connecting to Cloud Next environments from MySQL Workbench:
Open Terminal on your local machine and run:
{ssh -L $LOCAL_PORT:$DB_HOST:3306 $SSH_STRING}
Here,
LOCAL_PORT is the port to which Workbench must connect when using localhost.DB_HOST is the hostname obtained from the Cloud Platform user interface.SSH_STRING is the full connection string from the Cloud Platform user interface. For example, user@something.SSH keys that were manually added to an environment before the October 2018 EOL of per-environment SSH key management will not persist after the upgrade to Cloud Next. If your application was running on Cloud Platform Enterprise before that date, visit the Users & Keys page for each of your application’s environments before they are upgraded. You must ensure that all necessary SSH keys are properly associated with users in your subscription’s Teams & Permissions console.
Failure to do so may result in errors whenever users, scripts, development software, automations, or remote services attempt to access those environments after they are upgraded.
The /var/log/sites directory is no longer available for direct log access or custom log storage. Use /shared/logs for custom log storage instead.
Acquia reserves the right to terminate queries at a certain threshold to preserve the overall experience. As a best practice, Acquia recommends that queries do not run longer than 60 seconds for non-production environments and 5 minutes for production environments. To ensure that your environments complete all long-running transactions as expected, wrap them in a MySQL transaction to avoid the risk of data loss or corruption. If your environments require long-running MySQL queries to complete reports or other complex data management processes, contact your Acquia Accounts team to request a delay to your upgrade to Cloud Next.
Applications running on Cloud Next should test all Remote Administration patches in a Cloud Next non-production environment before pushing changes to the production environment. This ensures that no differences in Cloud Next and Cloud Classic logic impact the way patches behave after deployment in a Cloud Next environment.
Logic requiring access to a tmp or persistent shared directory must be redirected to $HOME on Cloud Next.
If this content did not answer your questions, try searching or contacting our support team for further assistance.