Встановлення CMS Drupal: налаштування сервера, модулів і безпеки

Установка Drupal: вузькі місця та типові відмови

Установка Drupal ламається зазвичай не на розпакуванні дистрибутива, а на першому переході з локальної машини на бойовий сервер: сайт віддає 500, частина сторінок порожня, завантаження файлів не працює.

Зовні це виглядає як збій самої системи керування, хоча причина майже завжди — непідготовлене середовище та налаштування, що розійшлися між стендами.

Вимоги до середовища перевіряють до запуску інсталятора: актуальну гілку мови виконання, потрібні розширення (обробка зображень, з'єднання з базою, робота з рядками), ліміти пам'яті та максимальний час виконання скрипту.

Пропущене розширення дає помилку в середині процесу — таблиці вже частково створені, і повторний запуск іде по неконсистентному стану.

Налаштування бази даних — окремий крок, який часто роблять «за залишковим принципом»: окремого користувача з обмеженими правами не заводять, кодування та правила порівняння залишають за замовчуванням, а доступи прописують прямо у файлах сайту, а не в конфігурації підключення.

Права на файли — друга типова відмова. Веб-сервер, інтерпретатор і власник каталогів працюють під різними обліковими записами; каталог завантажень і службові каталоги мають бути доступні на запис, а код — лише на читання.

Коли права виставляють широко «аби тільки працювало», сайт відкривається, але кожна завантажена користувачем сторінка стає потенційно виконуваною.

Завершує список помилок при розгортанні розсинхронізована конфігурація та перенесення чинного сайту: правки, внесені вручну в панелі, не потрапляють до репозиторію, а база й файли переїжджають різними людьми в різний час. Відтворюваної схеми немає, кожне оновлення — лотерея.

Розбираємо, як це закривається: підготовка сервера під сайт, поетапне розгортання з перевірками, контрольоване перенесення без втрати даних.

Що змінюється після налаштування сервера та модулів

Кеш віддачі та прошарок перед застосунком налаштовуються так, щоб анонімний трафік не доходив до ядра Drupal: сторінки віддаються зі спільного кешу, статика — з шару роздачі, а до самого застосунку добираються лише динамічні маршрути.

Інвалідація прив'язана до тегів сутностей, тому правка матеріалу оновлює пов'язаний фрагмент, а не скидає кеш повністю. Медіана віддачі сторінки на повторних запитах скорочується в рази за того самого сервера.

Під піковим навантаженням поведінка перестає бути сюрпризом. Пул воркерів обмежено явно, у черги запитів є межа, а надлишкові звернення отримують швидку відмову замість утримання з'єднань до таймауту — ті, хто вже на сайті, продовжують працювати.

Пул з'єднань до бази та розподіл запитів між процесами знімають падіння «на рівному місці» під час сплеску.

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

Повернення з гарячої копії вкладається в десятки хвилин замість годин ручного розбору. Втрати від простою падають пропорційно до скорочення вікна недоступності.

Окремо зникає клас відмов, який зазвичай і з'їдає нерви: п'ятисоті через права на директорії після оновлення модулів, розсинхрон кешу після релізу, вичерпання пам'яті воркерами, недоступність через закритий порт або прострочений сертифікат.

Кожен закритий на своєму рівні — перевірками перед викладкою, зовнішнім спостереженням за доступністю та регламентом оновлень, а не героїчним гасінням за фактом.

Варіанти установки Drupal: порівняння підходів

Спосіб установки вибирають не за зручністю майстра встановлення, а за тим, що вже є на руках: порожній сервер, готовий сайт на іншому хостингу, типовий профіль під стандартну задачу або працюючий проєкт під оновлення.

Від цього залежить сумісність середовищ — версія мови, бази даних, набір розширень і права на файлову систему.

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

Порядок робіт: аудит, схема, налаштування, перевірка

Перш ніж щось змінювати на робочому сервері, ми відновлюємо картину загалом: яка версія ядра і як оновлювалося ядро, що реально встановлено поверх стандартної збірки, які модулі перевизначають поведінку системи, де лежать файли і як влаштовано резервне копіювання.

Без цього списку будь-яка правка перетворюється на лотерею — конфлікт модулів або застарілий шаблон дає збій через кілька годин після запуску, коли причина вже неочевидна.

Послідовність етапів

1. Аудит середовища. Фіксуємо версії ядра, PHP і бази даних, склад модулів і тем, права на каталоги, налаштування веб-сервера та поточні точки відмови — від повільних запитів до незакритих прав доступу до службових розділів.
2. Схема конфігурації. Описуємо цільову конфігурацію: які модулі залишаються, які замінюються, як розділяються налаштування середовищ, де зберігаються секрети і як конфігурація потрапляє до системи контролю версій.
3. Складання тестового контуру. Розгортаємо копію на окремому контурі з тими самими версіями й налаштуваннями, переносимо дані та файли — отримуємо майданчик, де будь-яку правку можна відкотити без ризику для сайту.
4. Налаштування на тестовому контурі. Ставимо й налаштовуємо модулі, переносимо контент, налаштовуємо кешування, права ролей, поштові відправлення та захист форм від автоматичного спаму.
5. Перевірка. Проходимо ключові сценарії — вхід, реєстрація, публікація, пошук, оплата, вивантаження файлів, — звіряємо розмітку та швидкість відповіді, фіксуємо результат замірів до і після.
6. Перемикання на робочий контур. Переносимо перевірену конфігурацію, синхронізуємо дані, вмикаємо резервне копіювання та переводимо трафік із мінімальним вікном недоступності.
7. Передача проєкту. Віддаємо доступи, схему конфігурації, інструкції з оновлення та відкату, проводимо розбір із вашою командою — вона далі супроводжує сайт самостійно або з нашою підтримкою.

Уже на етапі аудиту видно, які правки безпечні, а які тягнуть за собою перебудову. Такий порядок прибирає головний ризик установки — невиявлений конфлікт, який проявиться вже на живому трафіку.

Що залишається в проєкті: конфігурації, схеми, регламенти

Передаємо проєкт не як «сервер із доступом», а як комплект, за яким інша команда зможе продовжити роботу без нас.

Кожен артефакт звіряємо з фактичним станом стенда: конфігурація вивантажена до системи контролю версій, схема відображає реальні зв'язки, а інструкції перевірені на тестовому середовищі — не написані «з пам'яті».

Окремо фіксуємо рішення та їхні причини: чому вибрано такий режим кешування, де стоїть обмеження на розмір завантажуваних файлів, які модулі вимкнені навмисно. Через пів року це знімає головний ризик підтримки — залежність від людини, яка «пам'ятає, як тут усе налаштовано».

• Конфігураційні файли — експорт налаштувань ядра та модулів до репозиторію; розгортання середовища повторюється за кроками, а не відновлюється вручну.
• Схема інфраструктури — веб-шар, база даних, файлове сховище, балансувальник, зовнішні сервіси, точки відмови та залежності між вузлами.
• Політики доступу — ролі та права в панелі керування, розмежування прав на рівні файлової системи, перелік ключів, порядок видачі та відкликання доступів.
• Регламент резервного копіювання — що і як часто копіюється, термін зберігання, де лежать копії, як перевіряється відновлення і скільки воно займає.
• Інструкції для команди — запуск і зупинка сервісів, оновлення ядра та модулів, типові збої та перші дії при них.
• Порядок оновлень — викат на тестове середовище, перевірка перед публікацією, точка повернення до попередньої версії.
• Карта моніторингу — які показники знімаються, за яких порогів спрацьовує оповіщення і кому воно надходить.

Кейс: скоротили час відновлення та прибрали простої

Проєкт — корпоративний портал на Drupal: десятки модулів, частина з правками під задачі бізнесу, накопиченими за кілька років. Конфігурація сервера збиралася вручну й існувала лише на бойовій машині, тому відновлення після збою займало близько чотирьох годин.

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

Що змінили

Ми перенесли налаштування сервера, модулів і прав доступу в декларативні файли під контролем версій — середовище тепер розгортається за одним описом, без ручних правок.

Резервне копіювання пов'язали з автоматичною перевіркою відновлення на окремому контурі: копія вважається придатною, лише якщо з неї справді піднімається робочий сайт.

Оновлення ядра та модулів спочатку проходять на передпродуктивному середовищі, відкат виконується за міткою попереднього релізу.

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

Метрики до і після: час відновлення — з чотирьох годин до 15 хвилин, частка відмов у пікові години — з 5–6% до 0,3%. Стабільність віддачі збереглася при двократному перевищенні попереднього піку: час відповіді для основної маси запитів залишився в попередніх межах.

Чим відрізняється новий проєкт від перенесення чинного сайту?

Різниця не в установці, а у вихідному стані проєкту. На новому сайті конфігурація збирається з нуля: чисте ядро Drupal, лише потрібні модулі, ролі та права описані одразу.

Під час перенесення спочатку йде інвентаризація — мажорна версія ядра, набір модулів, обсяг кастомного коду, розмір бази та файлового сховища.

Сумісність версій — головне джерело ризику. Модулі, написані під стару гілку ядра, на актуальній не запускаються: частина замінюється підтримуваними аналогами, частина доопрацьовується, самописні шаблони та хуки переписуються. Тому оцінка починається з аудиту, а не зі встановлення.

Переїзд без простою робимо на копії: новий контур піднімається поруч, база та файли переносяться, адреси звіряються за картою редіректів із кодом 301. Перемикання займає хвилини — заздалегідь знижуємо TTL домену.

Ризики перенесення передбачувані: розбіжність адрес, несумісні модулі, втрачені поля та права. Закриваємо їх прийманням — звірка URL, обхід ключових сценаріїв, порівняння вивантажень до і після. Що не переноситься штатно, узгоджуємо до старту.

Сумніви щодо безпеки, оновлень і навантаження

Перед стартом зазвичай звучать ті самі технічні питання: чи не відкриє CMS зайві входи, чи переживе сайт пік відвідувань, що відбувається із сайтом під час оновлення. Відповідаємо по суті — так, як це вирішується в проєкті.

Оновлення проходять без простою?

Ядро та модулі оновлюємо на копії, проганяємо регрес-перевірки та звірку конфігурації, потім перемикаємо трафік на нову версію. Відкат — повернення попереднього релізу за хвилини.

Як розмежовуються права доступу?

Ролі описуємо під реальні обов'язки: редактор править матеріали, але не чіпає структуру та налаштування. Адміністративні операції — лише за іменними обліковими записами, з журналом дій і двофакторною перевіркою.

Що з резервними копіями та навантаженням?

Копії бази та файлів знімаються за розкладом на зовнішнє сховище, відновлення перевіряємо на тестовому контурі. Під навантаження кешування сторінок і об'єктів увімкнено заздалегідь, статика віддається окремо, читання йде з реплік.

Обговоримо задачу: надішлемо план робіт та оцінку

Щоб оцінка строків спиралася на факти, а не на здогади, для обговорення задачі достатньо кількох вступних. Ми дивимося на поточний стан проєкту, інфраструктуру та вимоги до навантаження — із цього складається склад робіт і реалістичний план.

• що вже є: сервер або лише домен, поточна версія системи керування, перелік установлених модулів;
• куди планується встановлення: власний сервер, віртуальна машина у хостера або контейнери;
• вимоги до сайту: типи контенту, мультимовність, інтеграції із зовнішніми системами, пошук;
• очікуване навантаження: скільки відвідувачів і медіафайлів, чи потрібні кешування та окремий шар для файлів;
• ролі та безпека: хто редагує, чи потрібні узгодження публікацій і журнал дій;
• резервне копіювання: як часто знімати копії і який простій допустимий при відновленні.

У відповідь ви отримуєте план робіт за етапами, оцінку строків за кожним із них і склад робіт із межами відповідальності.

Окремим пунктом іде перелік документації, яка передається після завершення: конфігурація сервера, список модулів та їхніх налаштувань, політики доступу, порядок відновлення з копій. Якщо під час розбору з'ясується, що частину задач вирішують інакше, скажемо про це прямо.

Далі — розмова по суті: опишіть задачу, і ми повернемося з оцінкою та планом. Починати роботи чи ні, вирішуєте ви.