Комментарии 8
в репозитории с terraform, которым управляют DevOps
Интересно, как выкрутились DevOps когда hashicorp ограничили доступ к реестру terraform?
На своем проекте мы реализовали доступ через прокси сервер, который расположен в окружении для которого реестр доступен :)
В общем случаем можно воспользоваться зеркалом Яндекса: https://cloud.yandex.ru/blog/posts/2022/03/terraform-and-packer
Пара вопросов, blue-green или canary деплойменты не используете?
Как боретесь с миграциями БД? Только родные инструменты используете (django / alembic) или что-то кастомное ещё?
В данный момент используем только стандартный куберовский rolling-update, canary релизы в далеких планах.
Мы используем ORM peewee и инструмент для миграций созданный внутри QIWI: https://github.com/aachurin/peewee_migrations, он позволяет автоматизировать создание миграций и конвертирует их в безопасные с ключом --autocommit
.
А почему все еще gevent в 2022?
А какие есть альтернативы gevent'у в 2022?
Под альтернативами я имею ввиду фреймворк, который за пару строк превращает приложение написанное в синхронном стиле в асинхронное.
Интересная статья, спасибо, что поделились опытом!
Второй момент — необходимость избегать уязвимости Dependency Confusion, и для этого мы используем параметр default = true (pyproject.toml), который запрещает использовать в сборке неглобальные PYPI. То есть мы запрещаем доступ напрямую и создаем свой дефолтный приватный репозиторий с нашими библиотеками. Благодаря чему код злоумышленника не может проникнуть в инфраструктуру, выполниться и натворить бед с безграничными возможностями.
Не совсем понятно, что понимается под "неглобальными PyPI", но этот параметр устанавливает указанный источник как дефолтный при поиске пакетов вместо PyPI. Чтобы этот параметр помогал с Dependency Confusion атаками, у вас должен быть указан только этот источник (в котором мы можете, например, проксировать PyPI с фильтром на приватные пакеты по префиксу). Либо уж использовать "Package source constraints" и явное указание источника для каждого пакета.
При этом у вас схема с 2 источниками пакетов и второй источник для пакетов, кажется, как раз прокси на PyPI:
[[tool.poetry.source]]
name = "acme-pypi"
url = "https://registry.acme.com/repository/pypi-acme-pay/simple/"
default = true
[[tool.poetry.source]]
name = "acme-pypi-proxy"
url = "https://registry.acme.com/repository/pypi-proxy/simple/"
Не получится ли так, что при резолвинге версий для приватного пакета, Poetry будет учитываться и наличие более высокой версии фейкового пакета с таким именем, но опубликованном в PyPI (который вы проксируете в acme-pypi-proxy
)?
Сказ о том, как мы Python-микросервисы для облака шаблонизировали