В целом все правильно.
Насчет деплоя - есть нюансы
- как CD pipeline знает адреса серверов? В современном "облачном" окружении они часто меняются, нужен какой-то метод для их динамического получения
- как обеспечить бесперебойную работу приложения во время деплоя?
В облаках (AWS/GCP/ наверно и Yandex) есть managed services, которые сами умеют решать эти и другие (autoscaling) проблемы. В AWS это ECS, Elastic Beanstalk, AWS App Runner, managed K8S.
Псевдо-кластер будет хуже чем один сервер - сделать надежный high availability "на коленке" не получится.
Поэтому только выбрать готовое решение и докупить необходимое железо.
Насколько понимаю, "старый" S3 Glacier сегодня неактуален и поддерживается для совместимости.
Здесь https://stackoverflow.com/a/65918160/499915 говорят, что у него более гибкие возможности для Vault Lock Policies, но похоже это очень нишевая вещь.
Сделать самому high availbility очень сложно, а с репликацией базы еще сложнее. Поэтому да - просто выбрать надежного хостера для вебсервера, а если есть деньги - хостера, который дает готовые решения для этого.
Например, multi-availability zone architecture in AWS.
Jenkins не сырая, а седая - 15 лет назад контейнеры не использовали. Я не использовал jenkins последние 4-5 лет, sshagent действительно выглядит некрасиво тут.
И стоит на что-то другое посмотреть?
Если можно использовать, то Github Actions, или другое "облачное" решение - тогда не нужно поднимать/конфигурировать build environment.
а текущем хостинге, как я понял, нужно самому создавать его, какой то самоподписной сертификат, я в этом не разбираюсь, мне надо чтобы работало по https.
Почитайте инструкцию еще раз - не может быть чтобы они рекомендовали самоподписной сертификат. Броузер такому не поверит, и правильно.
Если хостер не помогает в получение настоящего сертификата, и у вас "настоящий" линукс, а не shared hosting,
то можно воспользоваться бесплатным https://letsencrypt.org/getting-started/
Так же как и в любой клиент/сервер архитектуре, я не вижу разницы для микросервисов.
Должен быть протокол для API. Если в нем нужны изменения, то имплементировать их на стороне сервера и клиента так, чтобы обновления не сломали ничего.
Вам не нужен бинарный лог, если вам не нужна репликация. То есть просто отмените его.
Если есть репликация, то подумайте сколько времени хранить лог - в основном зависит от того насколько надолго может упать реплика и связь между мастером и репликой.