Comment déployer / gérer des sites similaires à partir d'un profil unique, sans vidage?

15

Je n'aime pas les solutions de "site de clonage " qui impliquent de vider une base de données et d'importer ce vidage dans un autre environnement. Cela ne ressemble pas à une manière réelle de déployer plusieurs instances du même site Web (staging / prod / dev / etc).

Avec D7, nous avons généralement utilisé des profils personnalisés et utilisé drush pour installer des sites Web à partir de ces profils (et peut-être utiliser des fonctionnalités pour des synchronisations de site ultérieures). Cela nous a fourni de nouvelles installations, aucun contenu de test, mais le partage de paramètres importants. La synchronisation de contenu commune serait effectuée avec migrate, par exemple.

J'ai essayé de gérer plusieurs instances D8 partageant les mêmes profils d'installation. Où l'objectif final serait de partager et de synchroniser les configurations de sites. Et chaque installation a un UUID de site différent. Je n'ai pas réussi à appliquer la system.site uuidvariable de configuration au moment de l'installation (bien sûr, je peux modifier la valeur plus tard, mais il me semble que c'est trop tard, et tous les objets sont déjà créés avec des UUID différents, ce qui fait de la première synchronisation un cauchemar , où certains contenus par défaut doivent être supprimés, ou la langue par défaut bloque la synchronisation car elle ne peut pas être supprimée, etc.).

Pour appliquer cet UUID, j'ai essayé d'utiliser un fichier settings.php généré avec une $config['system.site']['uuid']valeur à l'intérieur, gros échec (le paramètre a été complètement ignoré, même après l'installation du site).

J'ai également examiné le profil d' installation de la configuration , que je ne comprends pas complètement, en particulier la façon de mélanger cette solution avec un autre profil d'installation.

La question est donc de savoir quelle est la meilleure façon de déployer de nouveaux sites à partir d'un profil d'installation:

sans "clonage de sites Web" et sans manipulation des vidages SQL lors de la création de sites (comme dans le cas des sites clonés ).
avec une nouvelle installation propre (sans les ordures du contenu des développeurs), en utilisant uniquement la configuration et le code exportés
qui peut gérer à la fois les paramètres de configuration par défaut de l'installation et les synchronisations ultérieures

8 configuration-management deployment

— regilero
source

3

Les fonctionnalités peuvent aider à contourner le problème UUID. C'est toujours bogué, ce qui nous empêche d'automatiser complètement le processus, mais nous pouvons au moins décaler et maintenir la configuration manuellement.

Les fonctionnalités créent toujours des modules, il exporte la configuration dans le répertoire config / install du module de fonctionnalités donné. Cela sera détecté lorsque vous installerez la fonctionnalité, et vous pouvez continuer à mettre à jour la configuration de votre site (de la même manière que les anciennes fonctionnalités drush-revert) à mesure que vos fonctionnalités exportent des modifications.

Vous pouvez également importer la configuration directement via drush, assurez-vous d'utiliser l'indicateur --partial, pour éviter de remplacer la configuration qui ne se trouve pas dans le dossier config. En utilisant --source, vous pouvez également définir un emplacement de dossier de configuration personnalisé, afin de pouvoir faire quelque chose comme drush cim --partial --source=docroot/modules/features/myfeature/config/install.

— Balazs Dianiska
source

ok, si je comprends bien, vous utilisez la fonction pour synchroniser les configurations de sites Web sur soime touches fonctions . Sans autoriser la synchronisation complète de la configuration des sites Web clonés.

— regilero

2

Exactement. Pour nous, le problème fondamental avec la synchronisation de configuration complète est qu'il suffit d'avoir un seul paramètre que les administrateurs peuvent changer, et vous ne pouvez plus synchroniser, car cela annulerait leur changement. Le décomposer en zones de fonctionnalités nous permet de a) maintenir un ensemble de configuration (en partie, parce que nous comprenons ce que c'est) et b) rester flexible sur le reste des fonctionnalités et comment nous gérons leur configuration.

— Balazs Dianiska

Ok, ce n'est peut-être pas la réponse définitive mais je vais vous donner la prime. Si quelqu'un veut ajouter une réponse mise à jour plus tard (au fur et à mesure que les choses bougent), je rouvrirai peut-être une autre prime pour cela.

— regilero

1

Une autre option:

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

— Achton
source

1

Basé sur l'indice @Ivan Jaros, vous pouvez définir certaines options de configuration lors de l'installation d'un profil. Évidemment, cela ne fonctionne que lors de l'installation et pas une fois qu'un site est déjà installé.

Dans le fichier .install de votre profil, vous pouvez ajouter des paramètres de configuration par défaut dans hook_install():

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

J'ai essayé cela localement et cela fonctionne. J'ai pu tirer la configuration d'un autre site vers un site local fraîchement installé en utilisant le code ci-dessus (avec le bon UUID) sans utiliser drush csetpour changer l'UUID du site.

Vraisemblablement, vous pouvez définir votre UUID pour qu'il soit extrait d'un fichier de votre environnement quelque part, ou d'une variable d'environnement ou d'un service, et ainsi ils seraient tous les mêmes sur n'importe quel site avec ce profil installé.

J'espérais faire une chose semblable de , settings.phpmais la ConfigFactoryclasse n'est pas disponible à ce moment et comme vous le mettre dans votre question via $configen settings.phpn'a pas d' effet.

— Jesse Boyd
source