Сказ о том, как мы Python-микросервисы для облака шаблонизировали

[funca]

в репозитории с terraform, которым управляют DevOps

Интересно, как выкрутились DevOps когда hashicorp ограничили доступ к реестру terraform?

[Bahusss]

На своем проекте мы реализовали доступ через прокси сервер, который расположен в окружении для которого реестр доступен :)

В общем случаем можно воспользоваться зеркалом Яндекса: https://cloud.yandex.ru/blog/posts/2022/03/terraform-and-packer

[DrrRos]

Пара вопросов, blue-green или canary деплойменты не используете?

Как боретесь с миграциями БД? Только родные инструменты используете (django / alembic) или что-то кастомное ещё?

[Bahusss]

В данный момент используем только стандартный куберовский rolling-update, canary релизы в далеких планах.

Мы используем ORM peewee и инструмент для миграций созданный внутри QIWI: https://github.com/aachurin/peewee_migrations, он позволяет автоматизировать создание миграций и конвертирует их в безопасные с ключом --autocommit.

[DX28]

А почему все еще gevent в 2022?

[Bahusss]

А какие есть альтернативы gevent'у в 2022?

Под альтернативами я имею ввиду фреймворк, который за пару строк превращает приложение написанное в синхронном стиле в асинхронное.

[DX28]

Обычно это называется opinion-based, но я обычно голосую на проектах за asyncio. Дэвид Бизли и К достаточно много труда вложили чтобы сделать этот раздел Python более maintainable and easy. Но если Вам в Вашем случае так быстрее и проще то это тоже хороший выход.

[oxdef]

Интересная статья, спасибо, что поделились опытом!

Второй момент — необходимость избегать уязвимости 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)?