Часто начинающие админы в своих руководствах советуют менять порт SSH и вместо 22 устанавливать какой-то нестандартный вроде 2222. На мой взгляд это плохая практика, не добавляющая никакой безопасности.
Обычно это делается не для безопасности, а для того, чтобы логов меньше было. На 22й порт в любом случае будут чаще стучаться боты чем на 2222.
Использовали ли для импорта что-то? Например terraformer или terraforming?
Как у вас устроена структура репозитория? А стейтов? Использовали ли интеграцию с Atlantis? Пишете ли тесты?
Да, Bucardo это триггерная репликация.
Конкретно в нашем случае из-за того что база на RDS мы не могли ничего использовать кроме Bucardo.
Проблема вторая — если реально хочется бесшовную миграцию с мультимастерами, приложение должно уметь с этим работать.
Вывод — если у вас есть база в RDS и вы хотите ее обновить на один мажорный релиз, то не стоит париться с попытками репликации, а просто уложить сайт на maintenance на несколько минут.
Спасибо за статью.
У нас был чем-то похожий кейс, только база у нас в AWS RDS (соответственно ни о какой нормальной мастер-мастер репликации не может быть и речи). Использовали Bucardo для мастер-мастер «репликации», скажем так, не все так радужно.
Не замеряли лаг при использовании логической репликации? То что база у Вас большая это видно, но вот насколько она нагружена?
Как поведет себя репликация, если я на новый хост переключу приложение налету? То есть например запрос А пошел на старый хост, который еще не успели реплицировать на новый, а запрос Б пошел уже на новый сервер? Или же пока работает pgrepup, новая база в режиме read-only?
В идеале хотелось бы иметь возможность использования именно авторизации, а конкретно — разграничение доступа по группе пользователя с помощью dex и groups.
Dex это умеет для групп (организации и команды в GitHub, группы в Microsoft accounts), для каждой группы будет своя RBAC-политика. Мы хотели сделать такое с гуглом, но не заработало. Хотели отказаться от basic auth и закрыть все с белым листов айпишников, но нужно в вайтлист добавлять много айпишников и создавать internal LB.
Кейс у Вас в принципе похож с нашим.
По ссылке отличное решение, но у нас немного по-другому, у нас на приложение стоит basic auth, которое конфиг-сниппетом отключается его для офисных адресов и VPN.
Вам нужна именно авторизация (не аутентификация)?
Аутентификация с помощью oauth2 включается легко для ингресса. А вот авторизацию уже надо реализовывать на уровне приложения или RBAC.
Решение oauth2_proxy требует деплоя сервиса в каждый namespace(поправьте если не прав), очень не хотелось бы это делать.
Да, у нас для внутренних сервисов в кубере включена аутентификация для всех ингрессов (prometheus, grafana, alertmanager, kibana, etc). Какой-то проблемы раскатывания для каждого неймспейса не вижу для себя (возможно у Вас совсем другой кейс).
Всю жизнь использую ноутбуки и практически никогда не пользовался нампадом со всеми этими клавишами, а с переходом на макбук так вообще забыл что это такое.
Но не беда, теперь буду знать.
Изначально я хотел ее сверстать, но оказалось что она должна была соответствовать шаблону на 100%. В связи с кучей различных шрифтов, подчеркиваний и прочих нелогичных как по мне артефактов, решено было с ней не запариваться, а оставить как есть.
Сервис на Django если вдруг кому пригодится.
Обычно это делается не для безопасности, а для того, чтобы логов меньше было. На 22й порт в любом случае будут чаще стучаться боты чем на 2222.
Как у вас устроена структура репозитория? А стейтов? Использовали ли интеграцию с Atlantis? Пишете ли тесты?
Пока только так, к сожалению: habr.com/en/post/468345
Но это дело времени, сервис-то пока в бете, наверняка скоро напишет Action для докера.
Мы, если что, используем GraphQL.
Конкретно в нашем случае из-за того что база на RDS мы не могли ничего использовать кроме Bucardo.
Проблема вторая — если реально хочется бесшовную миграцию с мультимастерами, приложение должно уметь с этим работать.
Вывод — если у вас есть база в RDS и вы хотите ее обновить на один мажорный релиз, то не стоит париться с попытками репликации, а просто уложить сайт на maintenance на несколько минут.
У нас был чем-то похожий кейс, только база у нас в AWS RDS (соответственно ни о какой нормальной мастер-мастер репликации не может быть и речи).
Использовали Bucardo для мастер-мастер «репликации», скажем так, не все так радужно.
Не замеряли лаг при использовании логической репликации? То что база у Вас большая это видно, но вот насколько она нагружена?
Как поведет себя репликация, если я на новый хост переключу приложение налету? То есть например запрос А пошел на старый хост, который еще не успели реплицировать на новый, а запрос Б пошел уже на новый сервер? Или же пока работает pgrepup, новая база в режиме read-only?
Dex это умеет для групп (организации и команды в GitHub, группы в Microsoft accounts), для каждой группы будет своя RBAC-политика. Мы хотели сделать такое с гуглом, но не заработало. Хотели отказаться от basic auth и закрыть все с белым листов айпишников, но нужно в вайтлист добавлять много айпишников и создавать internal LB.
Кейс у Вас в принципе похож с нашим.
По ссылке отличное решение, но у нас немного по-другому, у нас на приложение стоит basic auth, которое конфиг-сниппетом отключается его для офисных адресов и VPN.
Аутентификация с помощью oauth2 включается легко для ингресса. А вот авторизацию уже надо реализовывать на уровне приложения или RBAC.
Да, у нас для внутренних сервисов в кубере включена аутентификация для всех ингрессов (prometheus, grafana, alertmanager, kibana, etc). Какой-то проблемы раскатывания для каждого неймспейса не вижу для себя (возможно у Вас совсем другой кейс).
Но не беда, теперь буду знать.