В декабре буду выступать с докладом на PHP Russia 2024!
Расскажу как подготовить своё PHP приложение к работе в облаке.

Если кто-то планирует быть оффлайн - с радостью пообщаюсь.

Шифрованные секреты в инфраструктурном репозитории

Мне не давала покоя мысль о том, что в нашем инфраструктурном git репозитории не должно быть секретов в открытом виде. Все best practice твердят нам это. Я почитал доку и сейчас мы будем делать шифрованные секреты в репозитории, чтобы затем они расшифровывались в кластере и попадали в нужное место. Я выбрал вариант с использованием gpg и утилиты sops.
Приступим:

1. Заходим на мастер машину нашего кластера и создаем там gpg ключ

export KEY_NAME="cluster.yourdomain.com"
export KEY_COMMENT="flux secrets"

gpg --batch --full-generate-key <<EOF
%no-protection
Key-Type: 1
Key-Length: 4096
Subkey-Type: 1
Subkey-Length: 4096
Expire-Date: 0
Name-Comment: ${KEY_COMMENT}
Name-Real: ${KEY_NAME}
EOF

2. Получаем отпечаток нашего ключа
gpg --list-secret-keys "${KEY_NAME}"
Видим следующее:

pub   rsa4096 2024-09-23 [SCEA]
      AD02237C200DCF7465E0FA88AF8CB328D6E19757
uid           [ultimate] dev flux (flux secrets)
sub   rsa4096 2024-09-23 [SEA]

3. Сохраняем его в env переменную export KEY_FP=AD02237C200DCF7465E0FA88AF8CB328D6E19757
4. Экспортируем ключ в кластер

gpg --export-secret-keys --armor "${KEY_FP}" |
sudo kubectl create secret generic sops-gpg \
--namespace=flux-system \
--from-file=sops.asc=/dev/stdin

5. Экспортируем публичную часть ключа и сохраняем его в репозитории в файл cluster/flux-system/.sops.pub.asc
gpg --export --armor "${KEY_FP}" > /home/user/.sops.pub.asc
6. Удаляем ключи с мастер машины кластера. Они тут нам больше не нужны
gpg --delete-secret-and-public-keys "${KEY_FP}"
rm /home/user/.sops.pub.asc
7. Теперь пришло время зашифровать наши секреты и настроить flux так, чтобы он их расшифровывал и в расшифрованном виде сохранял в кластер. Первым делом добавляем в 03-app.yaml следующие строчки:

decryption:
        provider: sops
        secretRef:
            name: sops-gpg

Здесь мы указываем кластеру имя секрета, где хранится секретный ключ gpg, который будет использоваться для расшифровки файлов из репозитория
8. Из файла hr-app.yaml убираем секрет и кладем его в helm-pull-secret.yaml
9. Импортируем публичную часть ключа уже на нашей рабочей машине
gpg --import cluster/flux-system/.sops.pub.asc
10. Ставим утилиту sops. И шифруем наши секреты

cd components/app-example
sops --encrypt --encrypted-regex '^(data|stringData)$' --pgp 'AD02237C200DCF7465E0FA88AF8CB328D6E19757' --in-place helm-pull-secret.yaml
sops --encrypt --encrypted-regex '^(data|stringData)$' --pgp 'AD02237C200DCF7465E0FA88AF8CB328D6E19757' --in-place image-pull-secret.yaml

Получаем зашифрованные версии наших конфигов секретов. helm-pull-secret.yaml и image-pull-secret.yaml
11. Вот и все. Пушим в репо и проверяем статус командой flux get all -A

Для того, чтобы проверить все ли работает - можно запустить деплой приложения в гитлабе и убедиться, что все по прежнему деплоится и функционирует. Конечно это нужно было сделать с самого начала и у нас в истории коммитов остались открытые секреты, но больше мы так делать не будем.

Stay tuned ;)

Видео с конференции по безопасности контейнеров и контейнерных сред (БЕКОН)

Пока что адски перегружен и никак не могу продолжить писать следующий пост. Но без контента вас не оставлю :)
Держите офигенные доклады по безопасности с конференции БЕКОН 2024

https://www.youtube.com/watch?v=V7wOfQeghpQ&list=PL80eyh4Ug9W-bg3wco8e9UNpawrQlnkAk

Идеальный Dockerfile

В очередной раз переосмыслил для себя каким должен быть Dockerfile.
Вовсе не обязательно делать отдельно под локальную разработку и под prod.
Достаточно использовать мультистадийную сборку и локально собирать с одним target, а для прода с другим.
По сути мы наследуем все что собираем для локалки и добавляем слои, которые нужны для прода.
А CMD можно вынести за скобки в docker-compose.yaml, .gitlab-ci.yml и т.д.

Healthcheck для php-fpm

Я уже несколько лет везде использую roadrunner. Но не так давно пришлось поработать с php-fpm в докере.

Думал как же проверять его здоровье, но оказалось, что уже все придумано. Есть такой вот скрипт - php-fpm-healthcheck.

Использование предельно просто:

healthcheck:
    test: [ "CMD", "php-fpm-healthcheck" ]
    interval: 5s
    timeout: 5s
    retries: 5

Чтобы это работало - в php-fpm должен быть включен status и в докер образе должна стоять библиотечка для работы с fcgi. Для Debian ставим libfcgi-bin

Symfony + docker. Когда компилировать DI контейнер?

Недавно созванивались с Валентином Удальцовым и обсуждали этот вопрос.
Сначала я компилировал DI контейнер сразу в Dockerfile, что обеспечивало быстрый запуск docker контейнера с приложением из уже подготовленного образа.
Потом вынес этот момент из Dockerfile в запуск приложения, т.е. сначала делаем cache:clear, а потом запускаем roadrunner. Но это замедляет старт docker контейнера.

Когда же лучше это делать?

Если у вас нет специфичных настроек DI, зависящих от переменной APP_ENV или еще каких-то переменных окружения, которые влияют на сборку DI контейнера - можно и нужно компилировать DI контейнер в Dockerfile.

Если такие настройки есть - то компиляцию DI контейнера лучше вынести вне сборки образа и сделать при запуске приложения.

P.S. Когда я это все тестировал - обнаружил любопытный момент. Linux кэширует ENV переменные для запущенного процесса и если мы поменяем переменную в уже запущенном docker контейнере, то в приложении ничего не изменится, так как значение переменной уже закэшировано для процесса, который запускает php скрипты, будь то roadrunner или php-fpm

На канале FartTime сегодня стрим по нашей излюбленной тематике!

PHP Russia 2024

Добиваю оставшиеся моменты по подготовке к конференции. До встречи на PHP Russia 2024, кто будет присутствовать оффлайн!

Ну и маленькое объявление:
Чтобы наверстать упущенное - ориентировочно в середине декабря планирую провести стрим. Закрепим уже вышедшие посты про кубер и посмотрим как это все делается вживую. Думаю так материал будет усвоен лучше. Ну и пообщаемся в чате трансляции.

Stay tuned!

Production конфигурация php в докере

Доделываю сегодня последний шаблон приложения как дополнение для моего выступления на конференции. Стал проверять один момент и с удивлением обнаружил, что php работает в конфигурации по умолчанию и никакой базовый php.ini для него не загружен. Я думал, что умолчание - production ready конфигурация. Но нет :)

Чтобы переключить php в prod режим нужно сделать следующее:

RUN mv "$PHP_INI_DIR/php.ini-production" "$PHP_INI_DIR/php.ini"

И об этом написано в документации к официальному php образу на docker hub.

Будьте внимательны, всегда читайте доку!

Хозяйке на заметку

Небольшое напоминание, что в этом мире есть команда timeout, чтобы ограничивать выполнение команд по времени. Типа, пишешь timeout 30s ping pelmeni и пинговалка будет убита через 30 секунд, а не будет долбиться в хост до скончания времён.

https://www.cyberciti.biz/faq/linux-run-a-command-with-a-time-limit/

Вот и прошла PHP Russia 2024! Это было очень круто! Надеюсь в следующем году тоже будет о чем рассказать.

В воскресенье 15 декабря в 18:00 Мск планирую провести стрим по развертыванию куба и накатыванию всех тех штук, что мы уже успели обсудить на канале.

Завтра стрим!

Как и договаривались - завтра будем проводить стрим. В 18 Мск.
Покажу на практике развертывание dev кластера k8s, покажу все то, что было уже описано в постах здесь, на канале.
В опросе победили две площадки - youtube и telegram. Поэтому будем стримить на них.
Сегодня будет несколько тестовых трансляций, заходить на них не нужно, это просто мои тесты.

Держите ссылочку на ютуб:
https://www.youtube.com/watch?v=dDfWQp3JRqg