Как я собираю php приложение в докере (Часть 1)

С небольшим отрывом победили лучшие практики написания Dockerfile для php.

Начнем. На примере symfony приложения:

1. Указываем все необходимые секции FROM. Их может быть сколько угодно.
В данном случае это будет composer, roadrunner, php-extension-installer (Удобная штука, чтобы самому не прописывать зависимости расширений php) и сам php на базе Debian bookworm. Здесь мы указываем первые две цифры версии, чтобы не получить breaking changes, но получать обновления безопасности. И редакцию ОС для php образа.

FROM composer:2.7 as composer
FROM spiralscout/roadrunner:2024.1 AS roadrunner
FROM mlocati/php-extension-installer:2.2 as php-extension-installer
FROM php:8.3-cli-bookworm as builder

2. Прописываем UID и GID для пользователя, под которым будет запускаться приложение. Для production окружений считается безопасным выбирать ID выше 10000, чтобы не получить случайно id пользователя, который будет совпадать с пользователем хост системы и избежать эскалации привилегий.

ARG UID=10001
ARG GID=10001

3. Копируем из FROM образов бинарники, которые нам понадобятся для сборки

COPY --from=composer /usr/bin/composer /usr/bin/composer
COPY --from=roadrunner /usr/bin/rr /usr/bin/rr
COPY --from=php-extension-installer /usr/bin/install-php-extensions /usr/bin/install-php-extensions

Как я собираю php приложение в докере (Часть 2)

4. Далее идет большой блок, где мы одной огромной командой ставим нужный нам софт, расширения php, тут же удаляем лишнее, чтобы в текущем слое docker образа не добавилось лишнего объема, вносим необходимые настройки php и присваиваем пользователю www-data выше определенные UID и GID.

RUN apt-get update && apt-get install --no-install-recommends --no-install-suggests -q -y \
            unzip \
 && install-php-extensions opcache intl sockets zip \
 && rm /usr/bin/install-php-extensions \
 && apt-get clean  \
 && apt-get remove -q -y \
            $PHPIZE_DEPS \
            $BUILD_DEPENDS \
 && echo 'date.timezone = Europe/Moscow' >> /usr/local/etc/php/conf.d/project.ini \
 && echo 'opcache.max_accelerated_files = 20000' >> /usr/local/etc/php/conf.d/project.ini \
 && echo 'realpath_cache_size = 4096K' >> /usr/local/etc/php/conf.d/project.ini \
 && echo 'realpath_cache_ttl = 600' >> /usr/local/etc/php/conf.d/project.ini \
 && echo 'short_open_tag = off' >> /usr/local/etc/php/php.ini \
 && groupmod --gid=${GID} www-data \
 && usermod --uid=${UID} --gid=${GID} www-data

5. Определяем рабочую директорию приложения.

WORKDIR /app

6. Указываем env переменную, которая определяет, где будет хранится кэш composer. Она нам дальше понадобится, когда мы будем проделывать один фокус :)

ENV COMPOSER_CACHE_DIR="/tmp/composer/cache"

7. Копируем файлы, необходимые для установки зависимостей приложения. Пока только их. Они изменяются реже, поэтому установка зависимостей идет до копирования файлов всего приложения, иначе при изменении любого файла в проекте - каждый раз будут устанавливаться зависимости, чего мы хотим избежать.

COPY ./composer.json ./composer.lock ./symfony.lock ./

8. Делаем владельцем директории /app нашего пользователя www-data.

RUN chown www-data:www-data /app

9. Переключаем пользователя, от которого выполняются дальнейшие команды Dockerfile.

USER www-data

10. А дальше делаем фокус :) Монтируем директорию кэша композера с помощью специальной инструкции. Это позволяет переиспользовать кэш при сборках приложения и не качать зависимости каждый раз заново. Ну и ставим зависимости собственно. При установке зависимостей пока отключаем генерацию файлов для autoload, отключаем скрипты и делаем все это в неинтерактивном режиме.

RUN \
    --mount=type=cache,uid=${UID},gid=${GID},target=/tmp/composer/cache \
    composer install --no-dev --no-scripts --no-autoloader --prefer-dist --no-progress --no-interaction

11. Копируем файлы приложения, одновременно делая их владельцем www-data.

COPY --chown=www-data:www-data ./ ./

12. Теперь можно сгенерировать autoload, собрать env переменные в один файл и скомпилировать DI контейнер.

RUN composer dump-autoload --classmap-authoritative --no-dev \
 && composer dump-env prod \
 && bin/console c:c

13. Остается только определить команду запуска roadrunner.

CMD rr serve -d -c ./docker/php-prod/.rr.yaml

Дополнительно можно тут сразу указывать секцию HEALTHCHECK, но я предпочитаю это делать за пределами Dockerfile.

Вот и всё. Мы получили быстро собирающийся Dockerfile, который без лишней необходимости не пересобирает медленные слои.

P.S. Обратите внимание также на файл .dockerignore, он позволяет поместить в docker образ только те файлы приложения, которые действительно нужны в production среде.

Мониторим железо вместе с Prometheus

Сегодня займемся добавлением Prometheus к нашей графане и подключим мониторинг железа host машины, на которой она работает.

1. На саму host машину ставим prometheus-node-expoter. Либо ручками, либо, как мы любим, автоматически. Можно использовать мой ansible playbook, там есть команда make node-exporter

2. Добавляем конфиг для prometheus. Говорим, что надо раз в 15 секунд дергать node_exporter и запрашивать у него данные. ip опять же указываем docker gateway, как это было с loki

3. Добавляем datasource для графаны.

4. Добавляем provider для дашбордов.

5. Добавляем сам dashboard. Он скачан отсюда.

6. Правим .gitlab-ci.yml, чтобы все нужное копировалось на сервер.

7. Правим docker-compose.yaml. Тут добавляем сам prometheus. Под него создаем отдельный volume для данных, указываем, что данные нужно чистить раз в неделю и пробрасываем дашборды для графаны

8. Пушим всё в репозиторий. Дожидаемся выполнения pipeline, заходим в графану в раздел Dashboards и видим там наш Node exporter.

Готово! Рисуются красивые графики, где мы можем наблюдать за всеми нужными показателями сервера.

В следующий раз поговорим как на основе проделанного настроить алерты на почту, в случае достижения критических показателей

PostgreSQL 16 Internal

Пост про алерты пока не готов, скорее всего будет в следующие выходные. А пока предлагаю посмотреть интереснейший материал про всеми нами любимый postgres:
https://www.youtube.com/watch?v=2gcBOhY6Xe8&list=PLlghaO_0b1OepxMpMZAIoI3dHgozIEyLp

Настраиваем алерты вместе с Grafana

Сегодня наша задача в том, чтобы настроить уведомления на почту при достижении критических показателей по железу на наш email.
Алерты будем рассылать с помощью самой графаны, настраивать все будем как всегда с помощью подхода Infrastructute as a code.

1. В конфиг datasource-prometheus.yaml вносим идентификатор uid, чтобы потом его задействовать в настройке алертов. Так как мы уже ранее настраивали этот datasource - я просто взял и прописал сюда uid существующего datasource из графаны. Апдейтить uid при provisioning графана не умеет.

2. В grafana.ini в секцию [smtp] прописываем настройки отправки почты. SMTP сервер, юзер, пароль и т.д.

3. Создадим папку alerting в корне проекта. Добавим туда файл contact-point.yaml. Здесь задается на какие email отправлять письма с алертами.

4. Добавим файл notification-policy.yaml чтобы связать новый contact point с дефолтной политикой отправки алертов.

5. Добавим файлы cpu.yaml, ram.yaml и rootfs.yaml - это алерты по нагрузке на процессор, процент занятой ОЗУ и процент заполненности диска на сервере. Здесь указываем uid datasource прометеуса, который мы задали в конфиге выше. И в разделе expr ip нашего docker host, на котором у нас работает node-exporter. Содержимое самого expr я взял из дашборда, который мы создавали в прошлый раз. В каждом показателе там можно щелкнуть на ... -> More -> New alert rule и подсмотреть какие expr используются для построения графика. Там же можно и указать процент, после которого будет срабатывать алерт. После этого в разделе Alerting -> Alert Rules правила можно экспортировать для provisioning через код.

6. Остается только поправить .gitlab-ci.yml и docker-compose.yaml, чтобы все конфиги копировались при деплое на сервер и подтягивались в графану при поднятии сервисов в докере.

7. Пушим всё в репозиторий, дожидаемся выполнения pipeline и проверяем в разделе Alerting -> Alert Rules, что правила добавились и работают корректно.

Корректная настройка retention в loki

Как оказалось, в прошлый раз мы некорректно настроили удаление старых логов в loki.
Table manager не работает на одном инстансе и с недавних пор стал deprecated.
Давайте исправлять ситуацию.

Внимательно читаем доку и вносим изменения:

1. Добавляем в конфиг секцию compactor:

compactor:
    working_directory: /data/loki/retention
    compaction_interval: 10m
    retention_enabled: true
    retention_delete_delay: 2h
    retention_delete_worker_count: 150

2. В limits_config добавляем желаемый период хранения логов:

retention_period: 7d

3. Ну и закомментируем секцию table_manager.

4. Пушим изменения в репо, дожидаемся выполнения pipeline.

Готово, теперь удаление старых логов будет происходить корректно. Хочу заметить, что удаление произойдет не сразу, нужно какое-то время, чтобы loki занялся очисткой старых данных

Отпуск

Ухожу на пару недель в отпуск :) Посты продолжу писать после отпуска, не теряйте

Блокировка docker hub

Проснулись, потянулись и обнаружили, что докер хаб теперь не работает в РФ :) Ci/Cd встал колом, образы не скачиваются.
Но паниковать рано. На серверах вносим изменения в файл /etc/docker/daemon.json

Добавляем:

{
  "registry-mirrors": ["https://mirror.gcr.io"]
}

Делаем sudo systemctl restart docker

Все снова работает, но советую все нужные образы скачать во внутренний registry, чтобы избежать новых приключений :)

10 лет Kubernetes!

Сегодня исполняется ровно 10 лет с момента первого коммита в репозиторий кубера. Это, без сомнения, самый интересный и крутой инструмент для управления контейнерными нагрузками. Коллеги из компании Флант написали хороший пост о том, как все начиналось - https://habr.com/ru/companies/flant/articles/820153

PHP исполнилось 29!

На днях нашему любимому пыху исполнилось 29. По этому случаю Роман Пронский собрал и запустил 1 версию. Сам я начинал с 4-ки в далеком 2008. С тех пор php сильно вырос как язык, очень серьезно подросла и экосистема вокруг. Появились такие классные инструменты как psalm, php-cs-fixer, rector, deptrac. Live long and prosper, php!

FluxCD в действии! Воркшоп от Георга Гаала

Пока собираюсь с мыслями и думаю о чем еще написать - поделюсь с вами отличным воркшопом по использованию Gitops инструмента FluxCD.

https://www.youtube.com/live/T4fkWIGahiQ

Зависимости при сборке образа приложения

Важная, но не очень очевидная, мысль - ваше приложение при сборке образа не должно зависеть ни от чего, кроме кода приложения и рантайма, который его запускает. Все настройки под конкретные окружения (prod, stage, dev) должны осуществляться только через переменные среды (env). Мы собираем только один образ и используем его в разных окружениях. Если этого не делать - увеличится время сборки, так как мы будем собирать приложение под разные среды, увеличится объём хранимых в registry образов. А это доп. расходы времени и финансов на дисковое пространство

Кубер. Зачем?

Постам про кубер быть. И прежде чем тащить технологию к себе в компанию, нужно ответить на вопрос - зачем?

Кубер вам не нужен, если:
1. Проект только зарождается и вы не прогнозируете со старта бурный рост
2. У вас простая серверная архитектура и ей можно запросто управлять вручную или с простой автоматизацией
3. У вас нет жестких требований к простою во время обслуживания. Если сервер ночью приляжет на полчасика - ничего страшного
4. Нет высоких нагрузок и нет требований к автоматическому скейлингу инстансов приложения
5. У вас не микросервисы

Для всех вышеперечисленных случаев подойдет docker swarm или docker-compose. Или вообще по старинке без контейнеров

Кубер вам пригодится, если:
1. Серверов стало слишком много и ими довольно сложно управлять
2. Высокие требования к простою. Нужна отказоустойчивость. SLA 99.9
3. Highload
4. Куча микросервисов

Почему кубер, а не что-то другое (Docker swarm, Hashicorp nomad, etc):
1. Это уже индустриальный стандарт и вам будет гораздо проще найти специалиста для поддержки на рынке
2. Просто огромное количество инструментов на все случаи жизни, поддержка со стороны софта из коробки (RabbitMQ, Grafana, etc)
3. Возможность автоскейлинга. Причем при определенных настройках и поддержке со стороны облачного провайдера - кубер даже сам может заказывать виртуалки, когда нужно и потом их гасить, если они больше не требуются
4. Kubernetes ориентированные ОС, где нет ничего лишнего, они созданы, чтобы только запускать кубы. Если у вас жесткие требования по безопасности - это может быть хорошим решением. Самый яркий представитель таких ОС сейчас - Talos Linux
5. Если вы доросли до собственного ЦОД - куб даже можно использовать для построения своего приватного облака. С интересом наблюдаю за проектом cozystack

Mailpit вместо Mailhog

Чтобы тестировать отправку писем локально при разработке есть удобный инструмент - mailhog.
Отправляешь ему письма по протоколу SMTP и смотришь в веб-интерфейсе что пришло. В интеграционных тестах можно использовать api, чтобы проверить, что письмо корректно отправилось.
Однако проект заброшен, баги не фиксятся (Привет сортировка писем в режиме maildir).
Сегодня нашел вариант на замену - mailpit. Он вдохновлен мэйлхогом и поддерживает все те же фишки и имеет более приятный интерфейс. Ну и самое главное - проект активно развивается и поддерживается.

Php cs fixer научился в параллельность

php-cs-fixer наконец-то научили в распараллеливание проверок. И если на рабочей машине обычно с этим нет проблем, так как есть кэш, то в CI мы проверяем без кэша и на большом проекте проверка может занять довольно продолжительное время. Ранее я распараллеливал этот процесс костылями, но теперь достаточно добавить в конфиг ->setParallelConfig(ParallelConfigFactory::detect()) и фиксер начнет использовать все доступные ядра процессора для проверки кодстайла. Можно этот параллелизм настроить и более гибко. Подробнее в документации - https://cs.symfony.com/doc/usage.html

Создаем "виртуалки" для нашего Dev кластера с помощью Terraform

И так. Мы захотели завести себе k8s кластер. И чтобы как следует со всем разобраться мы начнем с Dev кластера. В прод пихать кубы пока рано. У нас будет две машины: k8s-master для служебных нужд и управления кластером (В терминах кубера это называется control-plane) и k8s-worker для нашей прикладной нагрузки.

Чтобы не возиться ручками - создавать "виртуалки" мы будем как всегда с применением подхода Infrastructure as a Code. Для этого есть прекрасный инструмент под названием Terraform от компании Hashicorp.
Сервера мы будем заказывать у нашего доморощенного облака на базе Proxmox (Это специализированный дистрибутив линукса, который делает из вашего железного сервера/серверов среду для выполнения виртуальных машин и не только).

Приступим:
1. Устанавливаем на нашу рабочую машину terraform. Пакет есть во всех популярных дистрибутивах линукса
2. Создаем файлик main.tf. Здесь в начале идет секция с провайдерами (У каждого уважающего себя облака есть провайдер для терраформа). Дальше описываем параметры подключения к proxmox. Юзер и пароль задается в переменных окружения. Это подробно описано в документации. Ну и дальше описываем какие машины мы хотим получить, думаю там все очевидно. Если нет - добро пожаловать с вопросами в комментарии к посту. Ранее я написал виртуалки в кавычках, потому что это не совсем виртуальные машины. Это LXC контейнеры, предшественники докера. Они не используют виртуализацию и запускаются на ядре хост машины.
3. Открываем консоль и набираем terraform init. Здесь терраформ будет качать нужные провайдеры и создавать свои служебные файлики. Из РФ репозиторий с провайдерами недоступен, поэтому на этом шаге потребуется VPN.
4. Далее запускаем terraform plan и смотрим на план, который был для нас построен.
5. Если все окей и нас устраивает - делаем terraform apply. Подтверждаем и ждем. Через некоторое время запрошенные машины будут созданы. Провайдер немного глючный, поэтому иногда приходится после создания писать start = false, делать apply, потом снова ставить start = true и снова применять изменения, чтобы машины стартанули.

Вот и всё, мы получили сервера под наш кластер. В следующем выпуске будем устанавливать k8s и настраивать его для дальнейшей работы с помощью инструмента ansible. При желании можно создание серверов тоже запихнуть куда-нибудь в CI/CD систему, чтобы вообще руками ничего не делать и только дождаться выполнения pipeline

Heredoc в Dockerfile

Недавно узнал, что в Dockerfile уже достаточно давно поддерживается Heredoc синтаксис.

Т.е. вместо того, чтобы писать амперсанды:

RUN set -xe \
 && apt-get update && apt-get install --no-install-recommends --no-install-suggests -q -y \
        gnupg2 \
        libicu-dev \
        libpq-dev \
        libzip-dev \
        postgresql-client \
        unzip \
        $PHPIZE_DEPS \
 && groupmod --gid=${GID} www-data \
 && usermod --uid=${UID} --gid=${GID} www-data \
 && chown www-data:www-data /var/www \
 && docker-php-ext-enable \
        opcache \
 && docker-php-ext-install \
        intl \
        pdo_pgsql \
        sockets \
        zip \

можно делать вот так:

RUN <<EOF
  set -xe
  apt-get update
  apt-get install --no-install-recommends --no-install-suggests -q -y \
        gnupg2 \
        libicu-dev \
        libpq-dev \
        libzip-dev \
        postgresql-client \
        unzip \
        $PHPIZE_DEPS
  groupmod --gid=${GID} www-data
  usermod --uid=${UID} --gid=${GID} www-data
  chown www-data:www-data /var/www
  docker-php-ext-enable \
        opcache
  docker-php-ext-install \
        intl \
        pdo_pgsql \
        sockets \
        zip
EOF

Пользуйтесь, очень удобно!

mkcert — удобный способ делать доверенные ssl сертификаты для локальной разработки

Когда мы разрабатываем проект локально — нам часто нужны самоподписанные ssl сертификаты. И желательно чтобы браузер/система им доверяла. Ранее я генерировал такие сертификаты через openssl и добавлял какими-то страшными костылями в доверенные системные серты. Это не всегда работало нормально. А потом моим страданиям пришел конец, я узнал про прекрасную утилиту — mkcert. Спешу и с вами поделиться.

Делаем:

mkcert -install
mkcert -cert-file ./some-dir/example.localhost.crt -key-file ./some-dir/example.localhost.key "*.example.localhost"

И всё! Генерируются сертификаты и добавляются в доверенные. Остается только нужные домены в /etc/hosts внести и пользоваться.

P.S. Посты про кубер на пару недель на паузе. С LXC контейнерами и разворачиванием в них k8s слишком много возни. Будем делать через обычные виртуалки. Я сейчас вдали от своего тестового стенда, а внутри VirtualBox Proxmox работает не совсем корректно с виртуалками, поэтому продолжим как только вернусь к настоящим железкам.

.dockerignore

Я уже ссылался на то, как пишу файлы .dockerignore в своих проектах в рамках статей по бест-практикам по сборке докер образов. Но решил все таки написать и разъяснить отдельным постом дополнительно про этот файл. Как удобно его писать? Вместо того, чтобы постоянно добавлять то, что мы игнорируем - можно сделать иначе. Заигнорить все, а потом добавить исключения, т.е. то, что попасть в образ все таки должно. Таким образом мы гарантируем, что в сборку не просочится мусор, который мы не учли. Делается это вот так (на примере проекта на symfony):

## Ignore all
*

## Except
!/bin
!/config
!/docker
!/public
!/src
!.env
!.env.local
!composer.json
!composer.lock
!symfony.lock