ncdu

Я немного приболел, поэтому на этой неделе продолжения по настройке логов не будет.
Но спешу с вами поделиться ещё одной полезной утилитой.
Наверняка многие знают команду du. А вот про ncdu не все слышали.
Запускаем в нужной директории и видим вот такую красоту. Плюс можно перемещаться по файловой системе, как в mc

Grafana loki

Сегодня мы добавляем loki для сбора и хранения логов + добавляем datasource в графану, чтобы она увидела loki. Loki наружу не пробрасываем, так как логи должны (в идеале) литься внутри локальной сети.

1. Делаем свой Dockerfile для loki. Нам нужно создать папку для хранения данных и выдать ей соответствующие права, иначе при монтировании named volume в контейнер у пользователя в контейнере не будет прав на запись. Плюс добавляем curl, для того чтобы сделать healthcheck.
2. Пишем конфиг для loki. Я руководствовался вот этой статьей и добавил немного отсебятины, вроде зачистки данных в хранилище логов старше 1 недели.
3. Пишем datasource для графаны, чтобы она увидела loki. Ничего не добавляем ручками, все можно сделать с помощью кода!
4. Правим docker-compose.yaml и .gitlab-ci.yml, чтобы это добро заработало.
5. Пушим все в репозиторий, дожидаемся выполнения pipeline.
6. Заглядываем в графану в раздел Connections -> Data sources и убеждаемся, что loki подключился.

Всё готово! В следующей статье будем учиться лить логи приложения в loki.

Льем логи приложения в loki

Сегодня учимся отправлять логи приложения в наш loki. Для примера задеплоим приложение на тот же сервер.

1. Устанавливаем на сервер docker driver client для loki.
2. Открываем 3100 порт на хост машине, так как лить логи, используя только сеть докера не получилось (В продовом окружении все равно порт будет открыт в локальную сеть, так как графана и локи, вероятнее всего, будут стоять на отдельной машине для сбора логов от всех систем).
3. Берем обычное приложение на symfony и конфигуриуем его так, чтобы логи писались в файл в формате json

when@prod:
    monolog:
        handlers:
            main:
                type: stream
                path: '%kernel.logs_dir%/%kernel.environment%.json'
                formatter: monolog.formatter.json

4. В продовом конфиге docker compose создаем отдельный контейнер, который будет лить логи приложения в loki (Основной контейнер в stdout шлет логи RoadRunner, с помощью которого запускается наше приложение, их тоже можно лить в loki, если требуется). За отправку в loki отвечает эта секция:

logging:
            driver: loki
            options:
                loki-url: http://172.17.0.1:3100/loki/api/v1/push

Тут вписан ip docker host, в реальном приложении впишите сюда ip сервера, где крутится ваш loki.
5. Пушим изменения, дожидаемся выполнения pipeline.
6. Заходим в графану, раздел Explore, делаем запрос {compose_project="app-example"} |= `` | json и видим наши логи.

Всё готово! На этом завершаю цикл постов про графану и локи. Если есть непонятные моменты - велкам в комментарии. Также в комментах можете предлагать темы для следующих постов, которые вам интересны

Как правильно лить логи приложения из контейнера с RoadRunner?

В варианте с docker compose я делал так, как описано в посте выше. Отдельный контейнер, который связан с основным через volume. Основной контейнер стримит логи RoadRunner, второй стримит логи приложения. И все бы хорошо, но в кластере (если это не k8s) такой вариант не пройдет. Контейнеры там никак не связаны и могут гулять по разным нодам кластера.

Какой выход? Оказывается RoadRunner умеет сам через себя стримить логи приложения. Чтобы это корректно работало - нужно настроить приложение так, чтобы оно писало логи в stderr (Пример для Symfony + Monolog):

main:
    type: stream
    path: php://stderr
    formatter: monolog.formatter.json

И настроить RoadRunner, чтобы он не оборачивал логи приложения в свой json:

logs:
    mode: production
    output: stdout
    channels:
        server:
            mode: raw

И всё! Теперь, посмотрев docker logs, вы увидите и логи RoadRunner и логи приложения, всё в формате json.

Как я собираю 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