Kubernetes как PaaS: максимум возможностей без разработки. Часть 2

В данной серии я не показываю как именно все устроенно у нас, а пытаюсь раскрыть возможности kubernetes и всего что вокруг него, чтобы можно было построить в том числе внутреннюю платформу.
Инструменты в данном случае я беру по формуле (популярность + (хотел попробовать, но руки не доходили)). GitOps сознательно не беру, потому что он решает только доставку и синхронизацию состояний, а не пытается собрать из разных инструментов платформу.

Вы спрашиваете правильные вещи, какие-то я собираюсь точно раскрыть в следующих частях, над некоторыми подумаю.

Use case использования Kubernetes при построении Cloud-Native-платформы данных

1. На данный момент это high-ops сетевые.

2. В общей namespace, но скорее всего придется этим управлять, потому что разные версии операторов обычно поддерживают разные версии приложений.

3. Безопасность достойна отдельной статьи и после review с стороны безопасников

4. Стараемся автоматически, но все индивидуально, если с кафкой можно заскалировать node group и перевести брокер, потом потушить старую ноду, то с тем же Postgres все так просто не получится.

5. На данный момент кластера не сильно большие и проблем нет, мультенант пока решается отсутствием коммуналки.

Конкретно эта статья не про тонкости, про них мы обязательно расскажем позднее.

Use case использования Kubernetes при построении Cloud-Native-платформы данных

У каждого может свое мнение на этот счет, для наших задач был выбран инструмент, который закрывает наши потребности и не важно сколько в нем слоев абстракций. И это один инструмент, а не несколько.

Use case использования Kubernetes при построении Cloud-Native-платформы данных

1. Нет, я именно сравниваю с теми инструментами, которые написал, потому что чаще всего при помощи них решают DevOps задачи.

2. Helm пакетный менеджер для работы с kubernetes, а не отдельный инструмент, поэтому нет я с ним не сравнивал.

3. Этом меме совсем про другое, kubernetes это не новый стандарт.

Use case использования Kubernetes при построении Cloud-Native-платформы данных

Конечно знаю, по сравнению со всем остальным (ansible, bash, terraform) это точно упростить.

Python (+numba) быстрее Си — серьёзно?! Часть 2. Практика

Для меня одной из самых приятных вещей оказалось @njit(parallel=True)

Используйте GIT при документировании

В markdown+git я вижу такие преимущества.

1. Документацию можно положить рядом с кодом, по моему мнению ему там и место.
2. Изменение документации (при нормальном flow) привязывается к коду и коммиту которые его порадили
3. Не требует дополнительного ПО, любой git SaaS умеет ренедерить Markdown
4. Для редактирования не надо вылазить из привычного редактора (VSCode, IntelliJ)
5. И главное это подсветка синтаксиса (если есть кто видел такую тулзу для google docs, скажите пожлайста)

Мелкая питонячая радость #3: Poetry

Не любитель тащить стороние зависимости ради пары строчек кода.
get_requirements.py

import sys

for line in sys.stdin:
    name, version = line.strip().split()[:2]
    print('%s==%s' % (name, version))

freeze.sh

#!/usr/bin/env bash

poetry show | python scripts/get_requirements.py > requirements-dev.txt
poetry show --no-dev | python scripts/get_requirements.py > requirements.txt

Мелкая питонячая радость #3: Poetry

У poetry есть одна проблема, нет команды перевести зависимости в обычный requirements.txt и для установки зависимостей надо установить сам poetry. И если вы все-таки решили ставить зависимости через него, встает другая проблема. В нашей практике мы собираем приложения в Dockerfile и обычное дело копировать файл зависимостей и их устанавливать где-то перед копированием кода, чтобы слой закешировался. Так вот если вдруг внесете изменения в pyproject.toml не касающейся зависимостей у вас все равно будет пересобираться слой с ними. В итоге пришлось написать скрипт, который читает stdin из poetry show и poetry show --no-dev и генерить два *.txt файла. Мелочь, а не приятно.

Указатели в Python: в чём суть?

Вы забыли про bytesarray указать в списке изменяемых.