Come posso distribuire / gestire siti simili da un profilo univoco, senza dump?

15

Non mi piacciono le soluzioni del "sito Web di clonazione " che implicano il dumping di un database e l'importazione di questo dump in un altro ambiente. Questo non sembra un modo reale di distribuire diverse istanze dello stesso sito Web (messa in scena / prod / dev / etc).

Con D7 di solito usavamo profili personalizzati e usavamo drush per installare siti Web da questi profili (e forse usando funzionalità per successive sincronizzazioni di siti). Questo ci ha fornito nuove installazioni, nessun contenuto di test, ma condividendo impostazioni importanti. La sincronizzazione comune dei contenuti verrebbe eseguita con migrate, ad esempio.

Ho provato a gestire diverse istanze D8 condividendo gli stessi profili di installazione. Dove l'obiettivo finale sarebbe quello di condividere e sincronizzare le configurazioni del sito. E ogni installazione ha un UUID del sito diverso. Non riesco a far rispettare la system.site uuidvariabile di configurazione al momento dell'installazione (ovviamente posso modificare il valore in un secondo momento, ma mi sembra che sia troppo tardi e tutti gli oggetti sono già creati con UUID diversi, il che rende la prima sincronizzazione un incubo , in cui alcuni contenuti predefiniti devono essere eliminati o la lingua predefinita blocca la sincronizzazione perché non può essere rimossa, ecc.).

Per imporre questo UUID ho provato ad usare un file settings.php generato con un $config['system.site']['uuid']valore interno, grande errore (l'impostazione è stata completamente ignorata, anche dopo l'installazione del sito).

Ho anche esaminato il profilo del programma di installazione della configurazione , che non capisco completamente, in particolare il modo di mescolare questa soluzione con un altro profilo di installazione.

Quindi la domanda è: qual è il modo migliore per distribuire siti freschi da un profilo di installazione:

senza "clonare siti Web" e manipolare i dump SQL durante la creazione del sito (come nella domanda sui siti clonati ).
con una nuova installazione pulita (senza sviluppatori spazzatura contenuti), utilizzando la configurazione e il codice esportato solo
che può gestire sia le impostazioni predefinite di configurazione dell'installazione sia le successive sincronizzazioni

8 configuration-management deployment

— regilero
fonte

3

Le funzionalità possono aiutare a bypassare il problema UUID. È ancora difettoso, il che ci impedisce di automatizzare completamente il processo, ma possiamo almeno spostare e mantenere la configurazione manualmente.

Funzioni crea ancora moduli, esporta la configurazione nella directory config / install del modulo funzioni dato. Questo verrà raccolto quando installi la funzione e puoi continuare ad aggiornare la configurazione del tuo sito (in modo simile a quello che ha fatto il vecchio ripristino delle funzionalità di Drush) man mano che l'esportazione delle tue funzionalità cambia.

Puoi anche importare la configurazione direttamente tramite Drush, assicurati di usare il flag --partial, per evitare di sovrascrivere la configurazione non nella cartella config. Usando --source puoi anche definire una posizione della cartella di configurazione personalizzata, così puoi fare qualcosa di simile drush cim --partial --source=docroot/modules/features/myfeature/config/install.

— Balazs Dianiska
fonte

ok, se ho capito bene, si utilizza la funzionalità di configurazioni siti web Sincronizza soime tasti funzioni . Senza consentire la piena configurazione di sincronizzazione dei siti Web clonati.

— regilero,

2

Esattamente. Per noi il problema fondamentale con la sincronizzazione della configurazione completa è che è sufficiente avere solo un'impostazione che gli amministratori possono cambiare e che non è più possibile sincronizzare, perché ciò annullerebbe il loro cambiamento. La suddivisione in aree delle funzionalità ci consente di a) mantenere un set di configurazione (parzialmente, perché comprendiamo di cosa si tratta) eb) rimanere flessibili sul resto delle funzionalità e su come gestiamo la loro configurazione.

— Balazs Dianiska,

Ok, questa non è forse la risposta definitiva ma ti darò la generosità. Se qualcuno vuole aggiungere una risposta aggiornata in seguito (poiché le cose si stanno muovendo) forse riaprirò un'altra taglia per questo.

— regilero,

1

Un'altra opzione:

drush config-set system.site uuid 56974bf2-68c2-3453-a211-de8bc754cc23

— Achton
fonte

1

Sulla base del suggerimento di @Ivan Jaros, è possibile impostare determinate opzioni di configurazione durante l'installazione di un profilo. Ovviamente, questo funziona solo sull'installazione e non una volta che un sito è già installato.

Nel file .install del tuo profilo, puoi aggiungere le impostazioni di configurazione predefinite in hook_install():

\Drupal::configFactory()
  ->getEditable('system.site')
  ->set('uuid', 'this is my new uuid')
  ->save(TRUE);

Ho provato questo localmente e funziona. Sono stato in grado di estrarre la configurazione da un altro sito in un sito locale appena installato utilizzando il codice sopra (con il set UUID corretto) senza utilizzare drush csetper modificare l'UUID del sito.

Presumibilmente, potresti impostare il tuo UUID in modo che venga preso da un file sul tuo ambiente da qualche parte, o una variabile di ambiente o un servizio, e quindi sarebbero tutti uguali su qualsiasi sito con quel profilo installato.

Speravo di fare una cosa simile da settings.phpma la ConfigFactoryclasse non è disponibile a quel punto e come fai notare nella tua domanda impostandola tramite $configin settings.phpnon ha alcun effetto.

— Jesse Boyd
fonte