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.
Configure the Swift Mailer module by using the “t” mode
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.
Reduce the frequency of cron jobs
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.
- Sign in to the Cloud Platform user interface.
- Select an application and an environment.
- Click Scheduled Jobs.
- Locate all jobs with frequency:
* * * * *orEvery Minute. - Update the frequency for such jobs to:
*/5 * * * *. - Test your application to verify that it works as expected.
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.
Disable the Memcached binary protocol
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;Use the Drupal Memcache module later than 8.x-2.0
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.
Update SimpleSAMLphp code
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.
Limit code repository size to 2 GB
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.
Disable live development
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.
Limit the size of PHP directives
| 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.
Limit the PHP Max File Upload concurrency to 20
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.
Avoid sharing database tables
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.
Remove dependency on custom PHP extensions
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.
Avoid using MyISAM database tables
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';
Apply Cloud Platform’s limitations for custom environment variables
Cloud Platform has the following limitations for custom variables:
- Maximum 5000 bytes for each variable value
- Maximum 255 bytes for each variable name
- 100 kilobytes in total (all variables with their names and values)
- Variable name and value must not contain tabs, spaces, or quotation marks.
For more information, see Creating custom environment variables.
Check dependencies
- Cloud Next environments use Ubuntu 20.04 or 22.04 while Cloud Classic environments use Ubuntu 16.04. For more information, visit Configuring OS versions.
- Before upgrading to Cloud Next, note that Python2, rssh, Drush 9, and Drush 10 binaries are unavailable in Ubuntu 20.04 and 22.04. If you depend on global Drush 9 or Drush 10, you must start using vendored Drush.
- Before upgrading to Ubuntu 22.04, you must verify that SimpleSAML is configured as documented in Using SimpleSAMLphp with Drupal 10.
Confirm Drupal and MySQL version compatibility
Acquia will upgrade the MySQL version for Cloud Next infrastructure from Aurora MySQL 5.7 to 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 your application is compatible with MySQL 8.0. For more information, see Amazon Aurora major versions.
Review Acquia contract revisions
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.
Review MySQL Workbench compatibility
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:
- Locate the database credentials listed on your Databases page.
Open Terminal on your local machine and run:
{ssh -L $LOCAL_PORT:$DB_HOST:3306 $SSH_STRING}Here,
LOCAL_PORTis the port to which Workbench must connect when using localhost.DB_HOSTis the hostname obtained from the Cloud Platform user interface.SSH_STRINGis the full connection string from the Cloud Platform user interface. For example,user@something.
Retrieve legacy keys
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.
Use different directory for custom log storage
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.
Review slow queries
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.
Test Remote Administration patches
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.