Distribuire le variabili

Le seguenti variabili deploy controllano le azioni nella fase di distribuzione e possono ereditare ed eseguire l’override dei valori dalle variabili globali. Inserisci queste variabili nella fase deploy del file .magento.env.yaml:

stage:
  deploy:
    DEPLOY_VARIABLE_NAME: value

Per ulteriori informazioni sulla personalizzazione del processo di compilazione e distribuzione:

CACHE_CONFIGURATION

Utilizzare CACHE_CONFIGURATION per unire o sostituire le opzioni front-end e back-end della cache generate durante la distribuzione.

Per Adobe Commerce sull’infrastruttura cloud, non modificare direttamente app/etc/env.php. Il pacchetto ece-tools genera la configurazione di distribuzione da .magento.env.yaml, le relazioni di servizio e le variabili di distribuzione supportate.

Utilizza VALKEY_BACKEND o REDIS_BACKEND per selezionare la cache supportata o l’implementazione L2 per la versione esatta di Adobe Commerce. Utilizza CACHE_CONFIGURATION per personalizzare opzioni quali nuovi tentativi di connessione, timeout di lettura, prefissi di cache o chiavi di precaricamento.

La combinazione di back-end e servizio cache supportata dipende dal livello di versione e patch di Commerce. Redis non è supportato per Adobe Commerce 2.4.9 o per versioni patch successive a 2.4.5-p16, 2.4.6-p14, 2.4.7-p9 e 2.4.8-p4. Utilizza Valkey per le versioni in cui requisiti di sistema lo richiedono.

Per impostazione predefinita, il processo di distribuzione sovrascrive la configurazione della cache corrispondente. Per unire i valori specificati alla configurazione generata, impostare _merge su true:

stage:
  deploy:
    CACHE_CONFIGURATION:
      _merge: true
      frontend:
        default:
          backend_options:
            connect_retries: 3
          remote_backend_options:
            read_timeout: 10

Per sostituire la configurazione esistente con i valori specificati in CACHE_CONFIGURATION, impostare _merge su false.

Nell’esempio seguente le assegnazioni di database vengono unite in una configurazione cache esistente. Utilizza questo tipo di sostituzione solo se il backend selezionato e la versione di Commerce lo supportano. Applica le impostazioni front-end a symfony_l2 solo se la documentazione corrente di Symfony L2 supporta esplicitamente l’opzione.

stage:
  deploy:
    CACHE_CONFIGURATION:
      _merge: true
      frontend:
        default:
          backend_options:
            database: 10
        page_cache:
          backend_options:
            database: 11

Nell’esempio seguente viene utilizzata la funzionalità di precaricamento Redis definita nella Guida alla configurazione. Per le versioni che utilizzano Valkey, utilizza le linee guida di Valkey corrispondenti.

stage:
  deploy:
    CACHE_CONFIGURATION:
      _merge: true
      frontend:
        default:
          id_prefix: '061_'
          backend_options:
            preload_keys:
              - '061_EAV_ENTITY_TYPES:hash'
              - '061_GLOBAL_PLUGIN_LIST:hash'
              - '061_DB_IS_UP_TO_DATE:hash'
              - '061_SYSTEM_DEFAULT:hash'

Per utilizzare un modello REDIS_BACKEND personalizzato non incluso nell’elenco Consentiti, impostare _custom_redis_backend su true in modo che gli strumenti ece applichino la convalida appropriata:

stage:
  deploy:
    CACHE_CONFIGURATION:
      frontend:
        default:
          _custom_redis_backend: true
          backend: '\CustomRedisModel'

CLEAN_STATIC_FILES

Abilita o disabilita la pulizia di file di contenuto statico generati durante la fase di compilazione o distribuzione. Utilizza il valore predefinito true nello sviluppo come best practice.

Se modifichi il contenuto statico tramite un processo separato, imposta il valore su false.

stage:
  deploy:
    CLEAN_STATIC_FILES: false

La mancata pulizia dei file di visualizzazione statica prima della distribuzione può causare problemi se si distribuiscono aggiornamenti ai file esistenti senza rimuovere le versioni precedenti. A causa di regole di fallback del file statico, le operazioni di fallback possono visualizzare il file errato se la directory contiene più versioni dello stesso file.

CRON_CONSUMERS_RUNNER

Utilizzare questa variabile di ambiente per verificare che le code di messaggi siano in esecuzione dopo una distribuzione.

Nell’esempio seguente vengono eseguiti i consumatori selezionati e vengono avviati più processi per ciascuno di essi:

stage:
  deploy:
    CRON_CONSUMERS_RUNNER:
      cron_run: true
      max_messages: 1000
      consumers:
       example_consumer_1
       example_consumer_2
      multiple_processes:
        example_consumer_1: 4
        example_consumer_2: 3

Nell’esempio seguente vengono eseguiti tutti i consumer:

stage:
  deploy:
    CRON_CONSUMERS_RUNNER:
      cron_run: true
      max_messages: 1000
      consumers: []

Per impostazione predefinita, il processo di distribuzione sovrascrive le impostazioni corrispondenti nel file env.php. Consulta Gestione delle code di messaggi nella Guida alla configurazione di Commerce per Adobe Commerce locale.

CONSUMERS_WAIT_FOR_MAX_MESSAGES

Configurare il modo in cui consumers elabora i messaggi dalla coda di messaggi scegliendo una delle opzioni seguenti:

stage:
  deploy:
    CONSUMERS_WAIT_FOR_MAX_MESSAGES: false

CRYPT_KEY

Quando si sposta il database da un ambiente a un altro senza un processo di installazione, è necessario disporre delle informazioni di crittografia corrispondenti. Adobe Commerce utilizza il valore della chiave di crittografia impostato in Cloud Console come valore crypt/key nel file env.php.

DATABASE_CONFIGURATION

Se hai definito un database nella proprietà relations del file .magento.app.yaml, puoi personalizzare le connessioni al database per la distribuzione.

stage:
  deploy:
    DATABASE_CONFIGURATION:
      some_config: 'some_value'

Per impostazione predefinita, il processo di distribuzione sovrascrive tutte le impostazioni nel file env.php. Tuttavia, è possibile scegliere di unire uno o più valori per una configurazione del servizio senza sovrascrivere tutti i valori.

Impostare l’opzione _merge su una delle opzioni seguenti:

Nell’esempio seguente i nuovi valori vengono uniti a una configurazione esistente:

stage:
  deploy:
    DATABASE_CONFIGURATION:
      some_config: 'some_new_value'
      _merge: true

È inoltre possibile configurare un prefisso di tabella.

Nell’esempio seguente viene utilizzato il prefisso della tabella ece_ con le impostazioni di connessione predefinite anziché l’opzione _merge:

stage:
  deploy:
    DATABASE_CONFIGURATION:
      connection:
        default:
          username: user
          host: host
          dbname: magento
          password: password
      table_prefix: 'ece_'

Output di esempio:

MariaDB [main]> SHOW TABLES;
+-------------------------------------+
| Tables_in_main                      |
+-------------------------------------+
| ece_admin_passwords                 |
| ece_admin_system_messages           |
| ece_admin_user                      |
| ece_admin_user_session              |
| ece_adminnotification_inbox         |
| ece_amazon_customer                 |
| ece_authorization_rule              |
| ece_cache                           |
| ece_cache_tag                       |
| ece_captcha_log                     |
...

ELASTICSUITE_CONFIGURATION

Mantiene le impostazioni personalizzate del servizio Elastic Suite tra le distribuzioni e le utilizza nella sezione ‘system/default/smile_elasticsuite_core_base_settings’ della configurazione principale di Elastic Suite. Se il pacchetto del compositore Elastic Suite è installato, viene configurato automaticamente.

stage:
  deploy:
    ELASTICSUITE_CONFIGURATION:
      es_client:
        servers: 'remote-host:9200'
      indices_settings:
        number_of_shards: 1
        number_of_replicas: 0

          indices_settings:
                  number_of_shards: 1
                  number_of_replicas: 2

Per impostazione predefinita, il processo di distribuzione sovrascrive tutte le impostazioni nel file env.php. Tuttavia, è possibile scegliere di unire uno o più valori per una configurazione del servizio senza sovrascrivere tutti i valori.

Impostare l’opzione _merge su una delle opzioni seguenti:

L’esempio che segue unisce un nuovo valore alla configurazione esistente:

stage:
  deploy:
    ELASTICSUITE_CONFIGURATION:
      indices_settings:
        number_of_shards: 1
        number_of_replicas: 2
      _merge: true

Limitazioni note:

ENABLE_GOOGLE_ANALYTICS

Abilita e disabilita Google Analytics durante la distribuzione in ambienti di staging e integrazione. Per impostazione predefinita, Google Analytics è true solo per l’ambiente di produzione. Per abilitare Google Analytics negli ambienti di gestione temporanea e integrazione, impostare questo valore su true.

Aggiungere la variabile di ambiente ENABLE_GOOGLE_ANALYTICS alla fase deploy nel file .magento.env.yaml:

stage:
  deploy:
    ENABLE_GOOGLE_ANALYTICS: true

FORCE_UPDATE_URLS

Durante la distribuzione negli ambienti Pro o Starter di staging e produzione, questa variabile sostituisce gli URL di base di Adobe Commerce nel database con gli URL del progetto specificati dalla variabile MAGENTO_CLOUD_ROUTES. Per ignorare il comportamento predefinito della variabile di distribuzione UPDATE_URLS, utilizzare questa impostazione.

stage:
  deploy:
    FORCE_UPDATE_URLS: true

LOCK_PROVIDER

Il provider di blocchi impedisce l’esecuzione di processi cron duplicati e di gruppi cron. Adobe Commerce on Cloud supporta i provider di blocchi file e db.

Negli ambienti di staging e produzione Pro, MAGENTO_CLOUD_LOCKS_DIR configura il provider file. Non è possibile ignorare questa impostazione. Negli ambienti Pro Integration e Starter, ece-tools imposta il provider db per impostazione predefinita. Per ottimizzare le prestazioni locali ed eseguire il mirroring dell’architettura di produzione, impostare il provider su file in tali ambienti.

stage:
  deploy:
    LOCK_PROVIDER: 'file'

MYSQL_USE_SLAVE_CONNECTION

Adobe Commerce può leggere più database in modo asincrono. Impostare su true per utilizzare automaticamente una connessione di sola lettura al database per ricevere traffico di sola lettura su un nodo non principale. Questa connessione migliora le prestazioni tramite il bilanciamento del carico, perché solo un nodo gestisce il traffico di lettura-scrittura. Per rimuovere qualsiasi array di connessione di sola lettura esistente dal file env.php, impostare su false.

stage:
  deploy:
    MYSQL_USE_SLAVE_CONNECTION: true

Quando la variabile MYSQL_USE_SLAVE_CONNECTION è impostata su true, il sistema imposta il parametro synchronous_replication su true per impostazione predefinita nel file env.php negli ambienti di staging e produzione Pro. Quando MYSQL_USE_SLAVE_CONNECTION è impostato su false, il parametro synchronous_replication non è configurato.

QUEUE_CONFIGURATION

Utilizzare questa variabile di ambiente per mantenere le impostazioni personalizzate del servizio di coda tra le distribuzioni. Questa variabile supporta sia i protocolli AMQP (per RabbitMQ) che STOMP (per ActiveMQ Artemis). Ad esempio, se preferisci utilizzare un servizio di coda messaggi esistente invece di affidarti all’infrastruttura cloud per crearlo, utilizza la variabile di ambiente QUEUE_CONFIGURATION per connetterlo al sito:

stage:
  deploy:
    QUEUE_CONFIGURATION:
      amqp:
        host: test.host
        port: 1234
      amqp2:
        host: test.host2
        port: 12345
      mq:
        host: mq.host
        port: 1234

Per ActiveMQ Artemis con protocollo STOMP:

stage:
  deploy:
    QUEUE_CONFIGURATION:
      stomp:
        host: activemq.host
        port: 61616
        user: username
        password: password

Per impostazione predefinita, il processo di distribuzione sovrascrive tutte le impostazioni nel file env.php. Tuttavia, è possibile scegliere di unire uno o più valori per una configurazione del servizio senza sovrascrivere tutti i valori.

Impostare l’opzione _merge su una delle opzioni seguenti:

Nell’esempio seguente i nuovi valori vengono uniti a una configurazione esistente:

stage:
  deploy:
    QUEUE_CONFIGURATION:
      _merge: true
      amqp:
        host: changed1.host
        port: 5672
      amqp2:
        host: changed2.host2
        port: 12345
      mq:
        host: changedmq.host
        port: 1234

REDIS_BACKEND

Specifica la configurazione del modello back-end per la cache Redis.

La cache Redis non è supportata per Adobe Commerce 2.4.9 o per versioni patch successive a 2.4.5-p16, 2.4.6-p14, 2.4.7-p9 e 2.4.8-p4. Per queste versioni, utilizzare Valkey e la configurazione VALKEY_BACKEND corrispondente. Verificare sempre il servizio cache supportato nei requisiti di sistema.

Per le versioni supportate da Redis, i modelli di back-end disponibili includono:

L’esempio seguente abilita il back-end della cache sincronizzata in remoto e la cache L2:

stage:
  deploy:
    REDIS_BACKEND: '\Magento\Framework\Cache\Backend\RemoteSynchronizedCache'

REDIS_USE_SLAVE_CONNECTION

Adobe Commerce può leggere più istanze Redis in modo asincrono. Impostare questa variabile su true per utilizzare una connessione di sola lettura a una replica Redis per il traffico di lettura mentre l’istanza primaria gestisce il traffico di lettura/scrittura. Per rimuovere un array di connessione di sola lettura esistente da env.php, impostarlo su false.

stage:
  deploy:
    REDIS_USE_SLAVE_CONNECTION: true

Devi avere un servizio Redis configurato nei file .magento.app.yaml e services.yaml.

ECE-Tools versione 2002.0.18 e successive utilizza impostazioni più a tolleranza di errore. Se Adobe Commerce non è in grado di leggere i dati dalla replica Redis, viene eseguito il fallback all’istanza primaria Redis.

La connessione di sola lettura non è disponibile nell’ambiente di integrazione. Se si utilizza CACHE_CONFIGURATION, unire le modifiche nella configurazione generata e verificare che la configurazione risultante mantenga la connessione di replica.

VALKEY_BACKEND

VALKEY_BACKEND specifica il modello di back-end per la configurazione della cache di Valkey. Il valore predefinito utilizza un nome di classe legacy compatibile con Redis; ciò non significa che il servizio debba essere Redis.

Per le versioni di Adobe Commerce precedenti alla 2.4.9 che supportano Valkey, i modelli di back-end includono:

Adobe Commerce 2.4.9 e versioni successive supportano anche symfony_l2, l’implementazione L2 basata su Symfony Cache. symfony_l2 è supportato solo con Valkey.

Configurare la cache sincronizzata remota

Per Adobe Commerce 2.4.8, utilizza la seguente configurazione quando è appropriata l’implementazione della cache sincronizzata in remoto:

stage:
  deploy:
    VALKEY_BACKEND: '\Magento\Framework\Cache\Backend\RemoteSynchronizedCache'

Se si specifica il back-end sincronizzato in remoto, la cache L2 verrà attivata e ece-tools genererà automaticamente la configurazione della cache. Vedere il file di configurazione di esempio. Per personalizzare la configurazione generata, utilizzare CACHE_CONFIGURATION.

Configurare l’implementazione della cache L2 di Symfony moderna

Per Adobe Commerce 2.4.9 e versioni successive, utilizza l’implementazione di Symfony L2:

stage:
  deploy:
    VALKEY_BACKEND: 'symfony_l2'

Se si specifica symfony_l2 come modello di back-end Valkey, la cache L2 verrà attivata e ece-tools genererà automaticamente la configurazione della cache L2 dai dettagli di connessione al servizio Valkey, inclusi i front-end default e stale_cache_enabled. Definire CACHE_CONFIGURATION solo quando è necessario personalizzare le opzioni di back-end supportate, ad esempio la directory della cache locale. Consulta Implementazione della cache L2 di Symfony nella Guida alla configurazione di Adobe Commerce.

VALKEY_USE_SLAVE_CONNECTION

Adobe Commerce può leggere più istanze di Valkey in modo asincrono. Impostare VALKEY_USE_SLAVE_CONNECTION su true per utilizzare una connessione di sola lettura a una replica di Valkey per il traffico di sola lettura mentre l’istanza primaria gestisce il traffico di lettura/scrittura. Questa connessione migliora le prestazioni tramite il bilanciamento del carico, perché solo un nodo gestisce il traffico di lettura-scrittura. Per rimuovere un array di connessione di sola lettura esistente da env.php, impostarlo su false.

stage:
  deploy:
    VALKEY_USE_SLAVE_CONNECTION: true

Devi avere un servizio Valkey configurato in .magento.app.yaml e .magento/services.yaml. La disponibilità di una connessione di replica dipende dalla topologia del progetto e dalla versione installata di ece-tools.

Prima di affidarsi a questa impostazione, controllare il valore MAGENTO_CLOUD_RELATIONSHIPS decodificato e verificare che sia presente una relazione di replica. Ad esempio:

echo "$MAGENTO_CLOUD_RELATIONSHIPS" | base64 -d | json_pp

Per symfony_l2, il supporto delle repliche richiede gli aggiornamenti rilevanti di ece-tools e delle patch cloud. Eseguire l’aggiornamento alla versione ece-tools più recente prima di abilitare questa impostazione. Se dopo la ridistribuzione non è presente alcuna relazione di replica, contattare il supporto Adobe Commerce.

Quando si utilizza CACHE_CONFIGURATION, unire le sostituzioni supportate nella configurazione generata anziché sostituire la struttura di connessione generata.

RESOURCE_CONFIGURATION

Associa un nome di risorsa a una connessione al database. Questa configurazione corrisponde alla sezione resource del file env.php.

Per impostazione predefinita, il processo di distribuzione sovrascrive tutte le impostazioni nel file env.php. Tuttavia, è possibile scegliere di unire uno o più valori per una configurazione del servizio senza sovrascrivere tutti i valori.

Impostare l’opzione _merge su una delle opzioni seguenti:

Nell’esempio seguente i nuovi valori vengono uniti a una configurazione esistente:

stage:
  deploy:
    RESOURCE_CONFIGURATION:
      _merge: true
      default_setup:
        connection: default

SCD_COMPRESSION_LEVEL

Specifica il livello di compressione gzip (da 0 a 9) da utilizzare per la compressione del contenuto statico. Impostarlo su 0 per disabilitare la compressione.

stage:
  deploy:
    SCD_COMPRESSION_LEVEL: 5

SCD_COMPRESSION_TIMEOUT

Quando il tempo necessario per comprimere le risorse statiche supera il limite di timeout di compressione, il processo di distribuzione viene interrotto. Imposta il tempo massimo di esecuzione, in secondi, per il comando di compressione del contenuto statico.

stage:
  deploy:
    SCD_COMPRESSION_TIMEOUT: 800

SCD_MATRIX

È possibile configurare più impostazioni internazionali per tema. Questa personalizzazione velocizza il processo di distribuzione riducendo il numero di file dei temi non necessari. Ad esempio, puoi distribuire il tema magento/backend in inglese e un tema personalizzato in altre lingue.

L’esempio seguente distribuisce il tema Magento/backend con tre impostazioni internazionali:

stage:
  deploy:
    SCD_MATRIX:
      "magento/backend":
        language:
          - en_US
          - fr_FR
          - af_ZA

Inoltre, puoi scegliere di non distribuire un tema:

stage:
  deploy:
    SCD_MATRIX:
      "magento/backend": [ ]

SCD_MAX_EXECUTION_TIME

Consente di aumentare il tempo massimo di esecuzione previsto per la distribuzione del contenuto statico.

Per impostazione predefinita, Adobe Commerce imposta l’esecuzione massima prevista su 900 secondi, ma alcuni scenari richiedono più tempo per completare la distribuzione di contenuto statico per un progetto Cloud.

stage:
  deploy:
    SCD_MAX_EXECUTION_TIME: 3600

SCD_NO_PARENT

Nella fase di distribuzione, impostare SCD_NO_PARENT: true in modo che la generazione di contenuto statico per i temi principali non venga eseguita durante la fase di distribuzione. Questa impostazione consente di ridurre al minimo i tempi di distribuzione e di evitare i tempi di inattività del sito che possono verificarsi se la generazione di contenuto statico non riesce durante la distribuzione. Vedi Distribuzione di contenuto statico.

stage:
  deploy:
    SCD_NO_PARENT: true

SCD_STRATEGY

Consente di personalizzare la strategia di distribuzione per il contenuto statico. Vedere Distribuire i file di visualizzazione statici.

Utilizza queste opzioni only se hai più di una lingua:

stage:
  deploy:
    SCD_STRATEGY: "compact"

SCD_THREADS

Imposta il numero di thread per la distribuzione del contenuto statico. Il valore predefinito è impostato in base al numero di thread CPU rilevati e non supera il valore 4. L’aumento del numero di thread velocizza la distribuzione dei contenuti statici. La riduzione del numero di thread ne rallenta il rallentamento. Puoi impostare il valore del thread, ad esempio:

stage:
  deploy:
    SCD_THREADS: 2

Per ridurre ulteriormente il tempo di distribuzione, utilizzare Gestione configurazione con il comando scd-dump per spostare la distribuzione statica nella fase di compilazione.

SEARCH_CONFIGURATION

Utilizza questa variabile di ambiente per mantenere le impostazioni del servizio di ricerca personalizzate tra le distribuzioni. Ad esempio:

Configurazione Elasticsearch:

stage:
  deploy:
    SEARCH_CONFIGURATION:
      engine: elasticsearch
      elasticsearch_server_hostname: http://elasticsearch.internal
      elasticsearch_server_port: '9200'
      elasticsearch_index_prefix: magento2
      elasticsearch_server_timeout: '15'

Configurazione di OpenSearch (per Commerce 2.4.6 e versioni successive):

stage:
  deploy:
    SEARCH_CONFIGURATION:
      engine: opensearch
      opensearch_server_hostname: 'http://opensearch.internal'
      opensearch_server_port: '9200'
      opensearch_index_prefix: 'magento2'
      opensearch_server_timeout: '15'

Per impostazione predefinita, il processo di distribuzione sovrascrive tutte le impostazioni nel file env.php. Tuttavia, è possibile scegliere di unire uno o più valori per una configurazione del servizio senza sovrascrivere tutti i valori.

Impostare l’opzione _merge su una delle opzioni seguenti:

L’esempio che segue unisce un nuovo valore alla configurazione esistente:

stage:
  deploy:
    SEARCH_CONFIGURATION:
      engine: elasticsearch
      elasticsearch_server_port: '9200'
      _merge: true

SESSION_CONFIGURATION

Utilizzare SESSION_CONFIGURATION per configurare l’archiviazione della sessione. L’esempio seguente utilizza la struttura di configurazione delle sessioni compatibile con Redis. Utilizzala solo con la combinazione di denominazione e servizio archiviazione sessione supportata dalla versione esatta di Commerce. Per le sessioni con Valkey, seguire l’esempio Sessione Valkey-Storage.

Non presumere che le variabili della cache come VALKEY_BACKEND o REDIS_BACKEND configurino le sessioni. La configurazione della cache e della sessione è indipendente. Nei progetti Cloud, utilizza la relazione di servizio e la configurazione generata laddove possibile; non codificare valori specifici dell’ambiente senza sostituire l’host e la porta di esempio.

stage:
  deploy:
    SESSION_CONFIGURATION:
      redis:
        bot_first_lifetime: 100
        bot_lifetime: 10001
        database: 0
        disable_locking: 1
        host: 'redis.internal'
        max_concurrency: 10
        max_lifetime: 10001
        min_lifetime: 100
        port: 6379
      save: redis

Sostituire redis.internal e 6379 con l’host e la porta del servizio sessione per l’ambiente di destinazione quando la configurazione della distribuzione richiede dettagli di connessione espliciti.

Per impostazione predefinita, il processo di distribuzione sovrascrive tutte le impostazioni nel file env.php. Tuttavia, è possibile scegliere di unire uno o più valori per una configurazione del servizio senza sovrascrivere tutti i valori.

Impostare l’opzione _merge su una delle opzioni seguenti:

L’esempio che segue unisce un nuovo valore alla configurazione esistente:

stage:
  deploy:
    SESSION_CONFIGURATION:
      _merge: true
      redis:
        max_concurrency: 10

SKIP_SCD

Imposta su true per saltare la distribuzione del contenuto statico durante la fase di distribuzione.

Nella fase di distribuzione, impostare SKIP_SCD: true in modo che la compilazione del contenuto statico non avvenga durante la fase di distribuzione. Questa impostazione consente di ridurre al minimo i tempi di distribuzione e di evitare i tempi di inattività del sito che possono verificarsi se la generazione di contenuto statico non riesce durante la distribuzione. Vedi Distribuzione di contenuto statico.

stage:
  deploy:
    SKIP_SCD: true

UPDATE_URLS

Durante la distribuzione, sostituire gli URL di base di Adobe Commerce nel database con gli URL del progetto specificati dalla variabile MAGENTO_CLOUD_ROUTES. Questa configurazione è utile per lo sviluppo locale, dove gli URL di base sono impostati per l’ambiente locale. Quando distribuisci in un ambiente Cloud, gli URL vengono aggiornati in modo da poter accedere alla vetrina e all’amministratore tramite gli URL del progetto.

Se è necessario aggiornare gli URL durante la distribuzione in ambienti di staging e produzione Pro o Starter, utilizzare la variabile FORCE_UPDATE_URLS.

stage:
  deploy:
    UPDATE_URLS: false

USE_LUA

Controlla l’opzione di back-end della cache use_lua in env.php per il front-end della cache predefinito (e, quando si utilizza il backend symfony_l2, le opzioni di back-end remoto del front-end stale_cache_enabled). Opzione non applicata al front-end page_cache.

Utilizzare il valore predefinito false a meno che il supporto Adobe non fornisca esplicitamente indicazioni diverse.

stage:
  deploy:
    USE_LUA: false

LUA_KEY

La variabile LUA_KEY è obsoleta. Se LUA_KEY è incluso in .magento.env.yaml, rimuoverlo durante la migrazione. Utilizzare le variabili USE_LUA e USE_LUA_ON_GC.

USE_LUA_ON_GC

Controlla l’opzione di back-end della cache use_lua_on_gc in env.php per il front-end predefinito della cache (e, quando si utilizza il backend symfony_l2, le opzioni di back-end remoto del front-end stale_cache_enabled) per la raccolta di oggetti inattivi. Opzione non applicata al front-end page_cache.

Utilizzare il valore predefinito true per mantenere la pulizia dei tag della cache atomica durante il processo cron backend_clean_cache.

stage:
  deploy:
    USE_LUA_ON_GC: true

VERBOSE_COMMANDS

Attiva o disattiva il livello di dettaglio di debug Symfony per i comandi CLI bin/magento eseguiti durante la fase di distribuzione.

Scegli il livello di dettaglio fornito nei registri:

stage:
  deploy:
    VERBOSE_COMMANDS: "-vv"