Як подружити PHPstorm, xDebug і віддалені гілки, зібрані через Docker? Занадто просто…

Доброго часу доби, Хабр!

Ще рік тому мій процес налагодження коду PHP полягав у двох рядках:

var_dump($variable);
die();

Періодично, звичайно, доводилося використовувати більш складні конструкції:

console.log(data);

 

echo json_encode($variable, JSON_UNESCAPED_UNICODE);
exit();

Ні, що ви! Я знав — в наш час не личить культурному програмісту займатися цим древнім ремеслом жарт про інше найдавніше ремесло

Але, чесно кажучи, я завжди боявся того, що не розумію. В тому числі і принтерів xDebug, в особливості, як всю цю справу налаштувати. В один прекрасний день у мене вийшло це зробити на своїй машині і в локальному проекті — радості не було меж. Через багато місяців я зіткнувся з новою проблемою, як займатися налагодженням в PHPstorm через xDebug, якщо проект збирається віддалено докером через CI.

Якщо Ви так само, як і я, відчуваєте труднощі з налаштуванням різних штук, ласкаво просимо під кат, я розповім про свій досвід налаштування оточення налагодження з такими страшними словами, як Docker, xDebug, CI.

Для тих, хто не любить воду і хоче перейти безпосередньо до суті налаштування.

Чому варто піти від запліснявівших методів налагодження і перейти на адекватні технології?

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

В якийсь момент, я для себе усвідомив, що мені вже просто незручно, і спробував подружити xDebug і PHPstorm при роботі над локальним проектом. Біда в тому, що більшість документацій та гайдів, які я знайшов, мають на увазі, що читає їх людина досить добре розбирається в предметній області і все розуміє, в моєму випадку це було не так і на своє перше налаштування xDebug я в сумі витратив 4-5 годин за 2 вечора. Це було досить важко морально, я відчував себе нескінченно тупим. Тим не менш, налаштувати вийшло, все працювало!

Читайте також  Американець першим в історії поодинці перетнув Антарктиду

Так, стало зручніше, локально, але на основній роботі я займався сайтами віддалено, і найчастіше у мене не було можливості або вивантажити сайт локально (через слабку машину або незручність процесу розгортання), або впливати на налаштування сервера через хостинги, тому вносив правки «на живу» і займався налагодженням через html-коментування print_r (на тій роботі це було «нормально», хоч і не пишаюся цим досвідом).

Однак, 3 місяці назад я перейшов у більш круту компанію і став займатися дійсно серйозним проектом з високим навантаженням. І тут для мене багато що змінилося. Інфраструктура і процес розробки приблизно такі: є свій сервер GitLab, у кожного проекту є свій репозиторій, в Jira приходять завдання, за номерами завдання створюєш гілку, при створенні гілки з допомогою CI автоматично створюється своя пісочниця з сайтом, де ти спокійно працюєш, кожен push перезбирає гілку, по закінченню робіт віддаєш на код-рев’ю, вливаєш гілку в майстер.

Все круто за винятком одного АЛЕ, кожен пересбір гілки в моєму випадку займає приблизно 10 секунд. В процесі самої розробки це несуттєвий час, так як я вже перейшов ту стадію, коли доводилося перевіряти працездатність коду чи не кожну сходинку з-за невпевненості і малого досвіду. Однак, коли я переходив до налагодження, ці 10 секунд почали грати відчутну роль. Процес подібного налагодження виглядав у підсумку так:

  • Додаю 2 рядки
  • Пушу комміт
  • Чекаю 10 секунд
  • Перевіряю, дивлюся, що не так
  • Repeat

За приблизними підрахунками, готова до мержу гілка мала приблизно 20% корисних комітів і 80% комітів налагодження. Припустимо, я закінчив роботу над гілкою з 300 коммітами, з них 240 комітів по суті просто отжирали 40 хвилин мого робочого часу (і це тільки час очікування складання гілки, не враховуючи ті секунди, які складаються в хвилини на те, щоб додати 2 рядки і потім їх видалити).

У якийсь момент мені це набридло і я вирішив-таки налаштувати xDebug, щоб процес налагодження став менш витратним. До нещастя, мої нинішні колеги або не користувалися цією технологією (чекаю жарти про «Влаштувався в круту компанію, де ніхто не користується xDebug’ом»), або не знали не пам’ятали, як подружити IDE з xDebug’ом, у разі коли гілка збирається віддалено через CI, а так як я ні разу не devOps і як я згадав вище, процес налаштування чого-небудь є для мене досить болісним процесом, це вилилося приблизно в 6 годин чистого часу, щоб нарешті все запрацювало, і я розумів процес, і це було б досить зручно.

Читайте також  Застосування методології OWASP Mobile TOP 10 для тестування Android додатків

Процес налаштування

Я не буду вдаватися в подробиці, як прикручувати CI, Docker, загалом, як зібрати інфраструктуру, передбачається, що це вже все готово, залишилося тільки налаштувати своє особисте оточення.

Припустимо, наш репозиторій має приблизно таку структуру:

Для початку нам потрібно перевірити, чи є в поточному образі сам xDebug, для цього можете скористатися phpinfo();

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

Налаштовуємо php.ini

Для того, щоб у підсумку все запрацювало, нам важливі 2 налаштування xDebug:

  • xdebug.remote_enable
  • xdebug.remote_host

У підсумковій збірці віддаленої гілки remote_enable повинен бути включений, а в remote_host повинен бути присвоєно IP вашого комп’ютера в мережі. Давайте включимо ці налаштування в наш білд.

Для початку потрібно дізнатися де зберігаються налаштування php, вони можуть розташовуватися або в /usr/local/etc/php/conf.d/php.ini, або сам файл .ini може бути названий інакше, в моєму випадку це /usr/local/etc/php/conf.d/php-settings.ini. Дізнатися це можна з налаштувань зібраного образу.

Створюємо в нашій гілці свої додаткові налаштування через той же файл php-settings.ini, а розташуємо його у ./build_env/php/php-settings.ini
Прописуємо в ньому 2 вищезгадані параметри:
xdebug.remote_enable = on
xdebug.remote_host = IP.ВАШОГО.КОМП'ЮТЕРА.МЕРЕЖІ

Далі нам потрібно додати файл до «батьківських» налаштувань образу. Я роблю це через volumes шляхом додавання в ./build_env/docker-compose/docker-compose.tmpl рядки:
- ${PROJECT_DIR}/build_env/php/php-settings.ini:/usr/local/etc/php/conf.d/php-settings.ini

Приблизно так в підсумку виглядає docker-compose.tmpl в моєму проекті:

При наступній збірці гілки, можна перевірити прив’язалися нові налаштування через той же phpinfo();якщо так — відмінно, якщо ні — Вам не пощастило і доведеться пройти той же шлях, що зробив я в перший раз 🙁

Налаштовуємо маппінги в PHPstorm

Далі потрібно налаштувати сам PHPstorm. Я вирішив не використовувати DBgp Proxy, щоб не налаштовувати маппінги у спливаючому вікні кожен раз. В моєму випадку я використовую шаблон сервера, який буде містити в собі необхідні маппінги.

Читайте також  Коли в gcc 16-бітові адреси, а пам'яті раптово 256к

Переходимо в Settings / Preferences | Languages & Frameworks | PHP | Servers

  1. Створюємо шаблон сервера
  2. Name: BRANCH
  3. host: будь, він не впливає
  4. port: будь, він не впливає
  5. Debugger: xDebug
  6. Ставимо галку на Use path mappings
  7. Проставляємо відповідні маппинги, робочі локальні папки повинні відповідати папок на сервері, де розташовуються зібрані гілки, в моєму випадку зібрані білди знаходяться у теці /var/www/builds/your_namespace/your_project/your_branch

Зберігаємо ці налаштування, міняти ми їх будемо кожен раз, коли працюємо з новою гілкою. Наприклад, якщо сьогодні працюю з гілкою web-2233 то поміняю маппінг на /var/www/builds/шлях_до_білда/web-2233

Додаємо нову змінну оточення, щоб IDE автоматично підтягувала маппінги

Тепер досить важливий і не самий очевидний момент. Коли ми починаємо дебаг, PHPstorm повинен розуміти, які локальні файли відповідають файлів на віддаленому сервері. Якщо сервер не передав йому конкретну установку, то з’явиться спливаюче вікно, в якому потрібно проставити відповідності шляхів вручну. Для того, щоб PHPstorm відразу брав маппинги від сервера з назвою BRANCH потрібно додати у нашу збірку змінну оточення PHP_IDE_CONFIG

У ./build_env/docker-compose/docker-compose.tmpl створюємо нову змінну оточення в environment:
PHP_IDE_CONFIG: ${PHP_IDE_CONFIG}

В .gitlab-ci.yml задаємо цю змінну:
- export PHP_IDE_CONFIG="serverName=BRANCH"

Готово!

Нам не потрібні розширення для браузера, не потрібно передавати в get-параметри URL XDEBUG_SESSION_START=IDE_KEY, не потрібно додавати додаткові конфігурації.

Досить просто включити прослушку і оновити сторінку сайту, як тільки ми натрапимо на перший брейкпоінт, виконання додатку зупиниться на ньому

Спасибі за увагу, сподіваюся ця стаття буде корисна і хто-небудь заощадить час, не наступаючи на ті ж граблі, що і я 🙂

Джерела, які я використовував при первинній настройці:
https://gist.github.com/chadrien/c90927ec2d160ffea9c4
https://confluence.jetbrains.com/display/PhpStorm/Docker+Support+in+PhpStorm#DockerSupportinPhpStorm-DebuggingthePHPwebapplicationrunninginthedockercontainer

Степан Лютий

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

You may also like...

Залишити відповідь

Ваша e-mail адреса не оприлюднюватиметься. Обов’язкові поля позначені *