blog [dot] hook

С метками

«php»

Данная статья является копией публикации на хабре В данной статье я расскажу о своём опыте “заворачивания” Laravel-приложения в Docker-контейнер да так, что бы и локально с ним могли работать frontend и backend разработчики, и запуск его на production был максимально прост. Так же CI будет автоматически запускать статические анализаторы кода, phpunit-тесты, производить сборку образов. “А в чём, собственно, сложность?” - можешь сказать ты, и будешь отчасти прав. Дело в том, что этой теме посвящено довольно много обсуждений в русскоязычных и англоязычных комьюнити, и почти все изученные треды я бы условно разделил на следующие категории: “Использую докер для локальной разработки. Ставлю laradock и беды не знаю”. Круто, но как обстоят дела с автоматизацией и запуском на production? “Собираю один контейнер (монолит) на базе fedora:latest (~230 Mb), ставлю в него все сервисы (nginx, бд, кэш, etc), запускаю всё супервизором внутри”. Тоже отлично, прост в запуске, но как на счёт идеологии “один контейнер - один процесс”? Как обстоят дела с балансировкой и управлением процессами? Как же размер образа? “Вот вам куски конфигов, приправляем выдержками из sh-скриптов, добавим магических env-значений, пользуйтесь”. Спасибо, но как же на счёт хотя бы одного живого примера, который я бы мог форкнуть и полноценно поиграться? Всё, что ты прочитаешь ниже - является субъективным опытом, который не претендует быть истиной в последней инстанции. Если у тебя будут дополнения или указания на неточности - welcome to comments. Для нетерпеливых - ссылка на репозиторий, склонировав который ты сможешь запустить Laravel-приложение одной командой. Так же не составит труда его запустить на том же rancher, правильно “слинковав” контейнеры, или использовать продуктовый вариант docker-compose.yml как отправную точку.

Столкнулся с ситуацией, когда необходимо переопределить расположение .env файла, который используется, к примеру - для запуска phpunit тестов. Да, если в корне приложения имеется файл .env.testing - то он автоматически будет прочитан фреймворком при APP_ENV равным testing, но вот что делать, если этот файл необходимо разметить в какой-либо другой директории? Давай расположим его в ./env.d/ дабы, например, не “мусорить” в корне приложения.

Данный пост скорее заметка для самого себя, дабы не забыть чего при новой итерации. Нового в ней ничего нет, ставим пакеты да настраиваем. У нас имеется новый и девственно чистый сервер под управлением CentOS 7.2 (minimal). Задача - поставить на него nginx + php + php-fpm + mysql и чтоб всё это шустро работало, да обновлялось самостоятельно из репозиториев (при возможности). Так же необходим тот же phpMyAdmin и настроенная отправка почты с сервера. В общем - минимальный web-stack, на котором хоть разработкой занимайся, хоть что-то вордпресо-подобное разворачивай. Сервер, к слову, располагается на hetzner.de.

msmtp - это простой консольный клиент для отправки сообщений электронной почты по протоколу SMTP. Можно, конечно, пойти сложным путем и поставить полноценный почтовый сервер, но зачем? Нам ведь требуется просто позволить скриптам и демонам отправлять почту, а заморачиваться с DKIM, SPF, заголовками и прочим - крайне лень. Поэтому мы будем отправлять почту с помощью почтового ящика на yandex.ru, и поможет нам в этом приложение под названием msmtp.

Задался вопросом - при разработке web-приложений под какую версию php их “затачивать”? Ответ оказался проще некуда - достаточно посмотреть на календарь релизов и понять, что на данный момент поддерживаемой является версия 5.6.19:

Что я подразумеваю под сборкой? Сборка - это процесс действий, которые выполняются над кодом проекта перед его деплоем. Она может включать в себя создание копии проекта, очистка директории с кэшем, минификация CSS и JS файлов, упаковка результата в один zip-архив. Так же возможно ещё и автоматическое развертывание проекта а удаленном сервере, но сегодня речь об этом идти не будет.

Кэп, “по умолчанию” все сниппеты добавляются в ./wp-content/%theme%/functions.php твоей темы Изменяем путь к статике темы В ряде случаев полезно вынести всю статику на отдельный субдомен или директорию в корне сайта. Так мы и путь к теме скрываем, и располагаем статический контент “поближе” да поудобнее: