Vitaly Karasik

В целом все правильно.
Насчет деплоя - есть нюансы
- как CD pipeline знает адреса серверов? В современном "облачном" окружении они часто меняются, нужен какой-то метод для их динамического получения
- как обеспечить бесперебойную работу приложения во время деплоя?

В облаках (AWS/GCP/ наверно и Yandex) есть managed services, которые сами умеют решать эти и другие (autoscaling) проблемы. В AWS это ECS, Elastic Beanstalk, AWS App Runner, managed K8S.

Или технология эта все еще сырая.

Jenkins не сырая, а седая - 15 лет назад контейнеры не использовали. Я не использовал jenkins последние 4-5 лет, sshagent действительно выглядит некрасиво тут.

И стоит на что-то другое посмотреть?

Если можно использовать, то Github Actions, или другое "облачное" решение - тогда не нужно поднимать/конфигурировать build environment.

где, собственно, искать рекомендуемые настройки для "docker-compose.yaml"?

ошибка означает утечку персональных данных.

ИМХО и AFAIK, это не так - нет никакой опасности утечки информации, если мы говорим про коммуникацию между несколькими контейнерами на одном хосте. Я не вижу никакого сценария, при котором SSL (== encryption in transit) может помочь в такой архитектуре.

"Использовать докер в продакшене - нормальное решение?" - да, но есть несколько НО, если это действительно продакшен: нужно почитать любой "учебник" (статьи, youtube, ...) по Докер - как работать с логами, данными (если хотим запускать базу в докер), автоматически перезапускать, как докер использует диск и т.п.

И, разумеется, независимо от того, как запускаем базу - потренироваться в бэкапе и восстановлении, и настроить ав томатический бэкап.

Тут есть два не связанных вопроса:
1) как сделать CI/CD
2) на какой платформе (VM, Docker compose, Nomad, K8S, какой-нибудь cloud app server) оптимально поднимать сервис

Насчет первого - с помощью Github Actions легко сделать CI/CD ничего не меняя в архитектуре.

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

На мой взгляд - для доставки заказчикам CD (если имеется в виду инсталляция on-prem) не подходит.
Нужно по старинке выкладывать новые версии на сайт, или же встраивать возможность update в admin panel.

Советую проверить/посмотреть
1) "сразу укажу что сервера идентичны" - если на старом сервере апликация бежала без докера, то она использовала ресурсы целого сервера, в кубернетесе она ограничена заданными лимитами. Плюс есть overhead на остальное. Т.е. например, сервера с 8GB памяти может быть достаточно для апликации, но недостаточно для K8S+апликация. Попробуйте увеличить лимиты.
2) CPU/RAM usage
3) если тестовая страничка использует базу - то посмотреть на мониторинг базы

1. Проверить внутри контейнера что процесс запущен и отвечает
Если работает, то
2. Проверить что правильный порт экспортируется

Используйте ENV, ARG доступны только во время билда.

Если все работает надежно и автоматизировано, то не надо никуда переходить.
Ну или сделать небольшой PoC и посмотреть насколько легко-удобно получилось.
Насчет преимуществ - не согласен с Alexey Dmitriev - все это легко получить и без K8S. На мой взгляд преимуществ два - portability и работа с контейнерами. То есть если решили использовать контейнеры, то K8S выбор по умолчанию, так как самый популярный.

Во-первых, присоединяюсь к комментариям shurshur.
Во-вторых, советую прочитать пару статей по основам Докера, потом ""Docker best practices, плюс с примером контейниризации full-stack апликации.

1) Насчет поведения при монтировании volumes - это всегда работает как 'mount'. То есть содержимое подменяется. Возможно, был или есть еще один метод, который "накладывал" двух директорий.
2) Насчет пользователя - тут https://stackoverflow.com/questions/40462189/docke... есть советы как поправить.
Но если в целом работает - то я бы не трогал.

Проще всего (нет необходимости ничего устанавливать) - использовать GitHub Secrets.

Правильный (ИМХО и AFAIK) хотя и непопулярный ответ - надо проверять\мерять производительность при разном кол-че контейнеров. Теория тут не очень помогает. Скорее всего, как уже сказали, оптимальное кол-во контейнеров будет намного больше чем кол-во процессоров.