Як розгорнути / керувати подібними сайтами з унікального профілю, без скидів?


15

Мені не подобаються рішення " клонування веб-сайту", що передбачає скидання бази даних та імпорт цього дампа в інше середовище. Це не схоже на реальний спосіб розгортання декількох екземплярів одного веб-сайту (staging / prod / dev / тощо).

За допомогою D7 ми зазвичай використовували власні профілі та використовували друку для встановлення веб-сайтів із цих профілів (і, можливо, використовуючи функції для пізніших синхронізацій сайту). Це дало нам свіжі установки, не тестовий вміст, але обмін важливими налаштуваннями. Наприклад, звичайна синхронізація вмісту буде здійснена з міграцією.

Я намагався керувати декількома екземплярами D8, які спільно використовували однакові профілі встановлення. Де кінцевою метою буде обмін та синхронізація конфігурацій сайту. І кожна установка має інший сайт UUID. У мене немає успіху в застосуванні system.site uuidзмінної конфігурації під час встановлення (звичайно, я можу змінити значення пізніше, але мені здається, що це вже пізно, і всі об'єкти вже створені з різними UUID, що робить першу синхронізацію кошмаром , де деякий вміст за замовчуванням повинен бути видалений або мова за замовчуванням призводить до збоїв синхронізації, оскільки його неможливо видалити тощо).

Щоб застосувати цей UUID, я спробував використовувати створений файл settings.php зі $config['system.site']['uuid']значенням всередині, великий збій (налаштування було повністю проігноровано навіть після встановлення сайту).

Я також переглянув профіль інсталятора конфігурації , який я не повністю розумію, особливо спосіб змішування цього рішення з іншим профілем установки.

Отже, питання полягає в тому, який найкращий спосіб розгортання нових сайтів із профілю встановлення:

  • без "клонування веб-сайтів" та маніпулювання дампами SQL при створенні сайту (як, наприклад, питання про клоновані сайти ).
  • зі свіжої чистої установкою (без розробників контенту для сміття), використовуючи експортовану конфігурацію і код тільки
  • який може керувати як встановленнями за замовчуванням конфігурації, так і пізнішими синхронізаціями

Відповіді:


3

Функції можуть допомогти обійти проблему UUID. Це все ще баггі, що заважає нам повністю автоматизувати процес, але ми можемо принаймні змінити та підтримувати конфігурацію вручну.

Функції все ще створюють модулі, вони експортують конфігурацію в каталог config / install даного модуля функцій. Це з’явиться під час встановлення цієї функції, і ви можете продовжувати оновлювати конфігурацію свого сайту (подібно до того, що робили старі функції перезавантажування), коли змінилися експорт функцій.

Ви також можете імпортувати конфігурацію безпосередньо за допомогою друку, переконайтеся, що використовується прапор --partial, щоб уникнути переосмислення конфігурації не в папці config. Використовуючи - джерело, ви також можете визначити місце власної папки конфігурації, щоб ви могли зробити щось на зразок drush cim --partial --source=docroot/modules/features/myfeature/config/install.


Добре, якщо я розумію , це добре, ви використовуєте функцію синхронізації веб - сайти конфігурації на soime ключі функцій . Не допускаючи повної конфігурації синхронізації клонованих веб-сайтів.
regilero

2
Саме так. Для нас основна проблема повного синхронізації конфігурації полягає в тому, що достатньо мати лише одне налаштування, яке можуть змінити адміністратори, і ви більше не можете синхронізувати, оскільки це відновить їх зміни. Розбиття його на області функцій дозволяє нам: a) підтримувати набір конфігурацій (частково, тому що ми розуміємо, що це таке) і b) залишатися гнучкими щодо інших функцій та того, як ми управляємо їх конфігурацією.
Балаш Діаніска

Гаразд, це, можливо, не остаточна відповідь, але я дам вам нагороду. Якщо хтось хоче додати оновлену відповідь пізніше (у міру того, як справи рухаються), я, можливо, знову відкрию ще одну винагороду за це.
regilero

1

Ще один варіант:

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

1

На основі підказки @Ivan Jaros, ви можете встановити певні параметри конфігурації після встановлення профілю. Очевидно, що це працює лише при встановленні, і не раз сайт уже встановлений.

У файлі .install свого профілю ви можете додати параметри конфігурації за замовчуванням у hook_install():

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

Я спробував це локально, і це працює. Мені вдалося перетягнути конфігурацію з іншого сайту на щойно встановлений локальний сайт, використовуючи вищевказаний код (з належним набором UUID), не використовуючи drush csetдля зміни UUID сайту.

Імовірно, ви можете встановити, що ваш UUID буде знятий з файлу, який знаходиться у вашому середовищі десь, або змінної середовища чи служби, і таким чином вони всі будуть однаковими на будь-якому веб-сайті із встановленим профілем.

Я сподівався зробити подібну річ від settings.phpале ConfigFactoryклас не доступний в цій точці , і як ви відзначаєте в вашому питанні встановити його з допомогою $configв settings.phpне має ніякого ефекту.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.