PodiCloudPodiCloud

PHP-проєкт

Обробник PHP: сайти і застосунки на PHP — власний код, Laravel, Symfony, WordPress, OpenCart. Нижче — що є всередині і як розгорнути власний проєкт; рецепти для популярних систем окремо: Laravel, WordPress, OpenCart.

Що всередині контейнера

  • PHP-FPM обраної версії (зараз пропонуються 8.4, 8.5, 8.6-rc) і вебсервер Caddy, який роздає файли з кореневого каталогу і передає .php у FPM. Гарні адреси працюють одразу: запит на неіснуючий файл іде в index.php, як із .htaccess у типовому фреймворку. Сам .htaccess не читається — див. власні директиви.
  • Розширення: bcmath, gd, intl, mbstring, mysqli, pdo_mysql, pdo_pgsql, zip, opcache, soap, exif, redis, imagick, xsl, sockets.
  • Інструменти: composer, git, unzip, curl — у вкладці «Термінал».
  • Налаштування PHP: memory_limit — половина пам’яті тарифу (від 64 до 1024 МБ), upload_max_filesize і post_max_size — 64 МБ, max_execution_time — 120 с, часовий пояс UTC, OPcache увімкнено (зміни у файлах підхоплюються за 2 с). Кількість процесів FPM підбирається під пам’ять тарифу.
  • Користувач. Усе працює від користувача проєкту, без root: завантажені вами файли доступні застосунку для запису, окремі права виставляти не треба.
  • Cron і фонові процеси — у блоці «Cron і процеси»; команди виконуються в контейнері, каталог проєкту — поточний.

1. Створити проєкт

У майстрі (як створити проєкт) оберіть плитку PHP, версію і заповніть налаштування:

Крок «Обробник» із PHP: версія, кореневий каталог, власні директиви Caddy
PHP: версія, кореневий каталог, директиви Caddy.
  • Версія. stable — поточна, old — попередня, next — наступна (RC). Змінити можна пізніше в блоці «Обробник».
  • Кореневий каталог — папка з index.php, від кореня проєкту. Для фреймворків це public; якщо репозиторій кладеться через Git-деплой у src — src/public.
  • Команда збірки (необов’язково) — виконується після кожного Git-деплою і кнопкою «Зібрати»: сюди йдуть composer install і міграції.
  • Власні директиви Caddy — редиректи та правила переписування адрес, якщо вони потрібні.

2. Власний проєкт: покроково

  1. Доставте код. Git-деплой у каталог src (кореневий каталог — src/public або src, залежно від структури) або завантаження через SFTP у public. Способи описані у загальному посібнику.
  2. Залежності Composer. Якщо vendor не в репозиторії, у «Терміналі»: 
    cd src
composer install --no-dev --optimize-autoloader
    Щоб це виконувалося саме після кожного деплою, впишіть ту саму команду в Команду збірки обробника.
  3. Конфігурація. Секрети й адреси — у блок «Змінні оточення» (застосунок читає їх через getenv() або $_ENV) або файлом .env через «Файли»: він не входить у репозиторій і переживає деплої.
  4. База даних. Створіть у розділі «Бази даних» → «База для цього проєкту»; хост, порт, ім’я, користувач і пароль — у картці бази. Під’єднуйтеся за хостом і портом із картки, а не за localhost.
  5. Домен. A-запис і HTTPS. TLS завершує проксі панелі, але PHP бачить захищене з’єднання як звичайно ($_SERVER['HTTPS'], REQUEST_SCHEME, SERVER_PORT): абсолютні адреси будуються з https:// без довіри до проксі. Адреса відвідувача — у заголовках X-Forwarded-For і X-Real-IP; REMOTE_ADDR — це проксі.
  6. Перевірте. «Відкрити» в шапці проєкту. Помилка 500 — дивіться вкладку «Логи»: туди потрапляють помилки PHP і вебсервера.

3. Власні директиви Caddy замість .htaccess

Поле Власні директиви Caddy (майстер або блок «Обробник») вставляється всередину сайту в контейнері. Типові правила:

# редирект назавжди
redir /old /new permanent

# усі неіснуючі адреси — в index.php з параметром (стиль RewriteRule із .htaccess)
@app {
	not file
	path_regexp p ^/(.+)$
}
rewrite @app /index.php?q={re.p.1}&{query}

# закрити службові папки
@private path /storage/* /vendor/*
respond @private 404

Без жодних директив неіснуючі адреси вже йдуть в index.php (шлях доступний застосунку в $_SERVER['REQUEST_URI']) — цього достатньо для Laravel, Symfony і WordPress.

Помилка в директивах зупиняє контейнер. Текст помилки — у «Логах»; поправте поле і збережіть.

4. Cron, черги, пошта

  • Cron. Блок «Cron і процеси» → задача з розкладом і командою, наприклад 0 3 * * * php src/bin/cleanup.php. Вивід задачі потрапляє в «Логи».
  • Фонові процеси. Там само — процес, який панель тримає запущеним і перезапускає після завершення: воркер черги, бот.
  • Пошта. У контейнері немає поштового сервера: відправляйте через SMTP вашого провайдера, налаштування — у змінних оточення.

5. Якщо щось не так

  • 500 або біла сторінка. «Логи» → помилка PHP з файлом і рядком. Найчастіше: немає vendor (виконайте composer install), немає .env або ключа застосунку, неправильний кореневий каталог.
  • 404 на всіх сторінках, крім головної. Кореневий каталог указано на папку без index.php, або застосунок чекає інших правил переписування — див. вище.
  • Завантаження понад 64 МБ не проходить. Це межа PHP у контейнері; діліть файл або завантажуйте через SFTP.
  • Composer не вистачає пам’яті. Для консолі memory_limit той самий — половина пам’яті тарифу. Запустіть COMPOSER_MEMORY_LIMIT=-1 composer install; якщо не допомогло — тимчасово підвищте тариф.
  • Файл змінили, а сайт показує старе. OPcache перевіряє файли раз на 2 с; якщо кеш робить сам застосунок (конфігурація, шаблони), очистіть його командами застосунку.
  • Застосунок будує http:// замість https://. Базова адреса в його налаштуваннях записана з http:// (APP_URL, WP_HOME, HTTP_SERVER тощо): PHP бачить HTTPS, заголовки проксі для цього не потрібні.