Василий Банников

Какой существует бестпрактис при разворачивании lemp стека с точки зрения пользователей.

Обязательно нужен отдельный пользователь для работы веб-сервера, субд, php-fpm, redis итд - каждому из них выдать доступ только к тем директориям и файлам, к которым им доступ необходим.

Нельзя чтобы они работали от рута или имени обычного пользователя, тк таким образом ты увеличиваешь площадь для атаки.

А одном тг чатике сказали, что делают своего юзера, пусть будет app, через него запускают nginx и php-fpm и его же назначают владельцем и группой для файлов сайта (var/www/app), дают ssh авторизацию.

Не вижу смысла выдавать app-юзеру права на логин по ssh. Все настройки можно делать и от имени административного пользователя - главное потом проверить что права выданы корректно.

НО и надо помнить, что теперь нет нигде www-data и копипаст каких-то решений\конфингов может не завестись.

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

у меня все работает, но, возможно, я не вижу какой-то ошибки, которая потом, в ci\cd, jenkinse, ansible или еще где-то мне ногу отстреллит.

Значит потом для cicd / jenkins / ansible также заведёшь пользователя с нужными правами, как и у тебя, чтобы ворочать конфиги и файлы.

Можно поднять свой gitlab ci.
Но как он с виндой работает - хз.

1. Во время ci собираешь docker image и закидываешь в docker registry (как правило приватный)
2. Во время cd вызываешь API твоего оркестратора:
docker-compose/docker swarm/k8s и тд, чтобы он обновил запущенные сервисы

Оба этапа можно реализовать разными способами, хоть через гитлаб, хоть через кучу баш скриптов

PS: docker-compose не является оркестратором и не умеет на ходу обновлять образы

есть задача автоматически обновлять пакеты в node.js и react репозиториев, используя CI/CD.

Имхо, обновление пакетов не должно быть автоматическим, и тем более не должно быть частью CI/CD, тк приложение тестируется на вполне конкретных версиях пакетов, и вообще package-lock не для того придуман, чтобы его какая-то автоматика затирала.

Ещё более-менее ок вариант - подобие dependabot, который делает PR с обновлёнными пакетами, который можно принять, если все тесты прошли.

Так что renovate выглядит вполне нормальным решением для своевременных обновлений.
Snyk же - это какое-то решение полного цикла, чтобы ещё до принятия PR проверять зависимости и всё такое.

> как правильнее
Выбирай оптимальное соотношение, между простотой написания, скоростью выполнения, и покрытием.

Самые крутые по покрытию - end to end тесты, в рамках которых вы поднимаете всю инфраструктуру и делаете http запросы к тестируемому сервису.
Но они достаточно медленные, тиебуют сложеой инфраструктуры, да и при написании нужно думать, как сделать так, чтобы тесты друг на друга не влияли.

А теперь про свой опыт:
Имелся проект без тестов, но при этом было понятно, что его надо полностью рефакторить, и даже пару модулей с нуля переписать, ещё и переезд с одной субд на другую был. Но зато была документация на все ендпоинты.

В таком случае идеально подошёл подход с написанием тестов на HTTP.
Тогда я писал их на шарпе, но сейчас знаю, что в Postman можно не только запросы делать, но и писать тесты, которые потом запускать из консоли.

А теперь про остальное:

Все пишем по TDD, все тесты зеленые, а баги все равно появляются.

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

один из наших сервисов, который использует базу данных, отпарвляет SQL запрос с синкаксической ошибкой

Выносишь кусок кода, который генерирует этот SQL-запрос в новый сервис, и тестируешь, что он всегда даёт корректный синтаксис.

Советую почитать про чистую архитектуру