Всё верно говорите: недодокер и недокубер. Зачем писать кубер и докер, когда они уже есть и они то как раз не нужны!
В документации по кубу есть информация об Aggregation Layer, там как раз описано как сделать недокубер. Так же там есть информация, как сделать недодокер и настроить его для работы с кубом.
никем не проверенным на безопасность API
думаете у куба проверен и на 100% безопасный?
В результате система состоит всего из двух компонентов
Да, действительно только контроллер и агент. Оно работает абсолютно без каких-либо зависимостей!
Много где использую Prometheus, VictoriaMetrics и Zabbix (даже живой graphite имеется), но для их работы нужны ресурсы, которые в моём случае сильно ограничены. Разворачивать дополнительную инфраструктуру мониторинга, чтобы посмотреть метрики раз в месяц или реже – выглядит затратно.
В остальном вы решили свою задачу одним способом, я другим. Можете поделиться своими наработками в статье.
curl/wget — скачать слои образа tar — распаковать слои mount — смонтировать rootfs systemd — запустить приложение как сервис
Ни в одном из этих пунктов нет Docker/Podman. OCI-образ — это просто tar-архив с корневой файловой системой и JSON-манифестом. И работает этот механизм начиная с версии ядра 3.18. В случае, если у клиента контейнеры под запретом и нет registry, то мы всегда можем принести на флешке OCI-layout, который после создания systemd .mount и .service будет работать абсолютно так же, как и после запуска через docker compose up или установки системного пакета.
Решает — и не только он один. Все они имеют одну общую базу: это просто обёртки над Linux Namespaces, cgroups и файловыми системами (overlayfs). По сути, CRI-O, Docker (containerd) и Podman, в основе работают с одними и теми же примитивами ядра. Технологически — да, это прекрасно работает, когда контейнеры разрешены и есть инфраструктура под них.
Но проблема, которую я описываю в статье, находится на уровень выше. Она не в том, как запустить изолированный процесс, а в том:
как доставить артефакт (образ, бинарник, пакет) в произвольное окружение, где может не быть registry;
как применить конфигурацию, уникальную для каждого заказчика (сети, прокси, хранилища, сертификаты);
как обеспечить обратную совместимость, когда на одной версии ОС работает один набор зависимостей, а на другой — другой.
Docker Compose справляется со своей задачей — описать многоконтейнерное приложение в среде Docker. Но даже если контейнеры разрешены, Compose не рассчитан на развертывание на 10+ машинах (а есть 100 и 200, такие случаи не редки) — это инструмент для локальной разработки или небольших кластеров, а не для массового продакшена.
Не логичнее ли поставлять для каждого свой способ установки.
Это мы и делаем сейчас, и именно это приводит к разрастанию инфраструктурной кодовой базы. Helm-чарт, Docker-образ, RPM, DEB, плюс скрипты для Alt Linux, Astra, РЕД ОС — и вот у вас уже не один способ установки, а пять, и каждый нужно тестировать, поддерживать и синхронизировать с новой версией приложения. Количество ресурсов для поддержки ограничено. А если заказчик вообще не использует контейнеры, Compose и Helm становятся бесполезны.
Поэтому я и предлагаю не плодить способы установки, а подумать о том, как унифицировать процесс доставки так, чтобы он не превращался в ещё один продукт, который нужно разрабатывать и поддерживать. В таком случае мы всегда будем работать с одним и тем же артефактом, но в абсолютно разных окружениях
сконцентрируйтесь на парочке дистрибутивов
в enterprise так не работает. Заказчик платит деньги и хочет, чтобы работало на его инфраструктуре.
Шестой до сих пор живёт на CentOS 7, потому что обновление инфраструктуры — отдельный многолетний проект.
Это реальный кейс. Каждый такой кейс добавляет ещё один виток сложности в наши сценарии развёртывания.
По поводу контейнеров — причины бывают разные, и не всегда они рациональны с технической точки зрения, но они напрямую диктуются моделью угроз конкретной организации. Комментарии к требованиям ИБ получить, чаще всего, не удаётся — это внутренняя политика, и спорить с ней бесполезно. Приходится принимать как данность и искать обходные пути.
Про ПАК — да, это один из вариантов и мы его используем, но ПАК тоже не панацея. Он решает проблему совместимости на уровне ОС, но не решает проблему доставки самого приложения и его зависимостей. Плюс ПАК — это ещё один слой, который надо внедрять и поддерживать. А обновление ПАК никто не отменял: новая версия ОС, новый патч безопасности — и вы снова проходите весь цикл тестирования и согласования.
Придумывать ничего не надо, всё уже придумано до нас, мы только пользуемся.
Видимо вы пропустили главу "Когда начинается ансиБОЛЬ". Конечный набор сценариев подразумевает конечный набор фичей. С такой политикой вы быстро бы покинули рынок, если бы были вендором ПО.
Рассматривается же запуск Postgres/Neon на ноде куба, т.е. тарифицируется нода куба, а не запущенные поды/контейнеры на ней. Если действительно это запускается в кубе, то к стоимости ноды придется добавить сумму за использование S3. Если 10 rps, то выходит копейки за месяц, если же 100+ rps, то сумма за использование S3 уже будет начинать ощущаться. В какой-то момент и Neon начнет "затыкаться", это произойдет сильно раньше, чем постоянно работающий Postgres.
Neon выглядит интересно, но кейсы использования его более узки, чем нативная Postgres.
поднятие Compute из idle приводит к апдейту c нужным конфигом, а не к созданию нового пода
Так если он и так поднят и как выше написал, мы платим за целую ноду куба, то какой профит от него вне бессерверных контейнерах?
Критерий успеха прост: idle-время значимо, а бизнес доволен, когда платит только за активные минуты.
А бизнесу никто не сказал, что теперь каждый запрос к БД (S3) будет не бесплатным? Выглядит так, что на нагруженных проектах, нововведение приведет к увеличению ежемесячного счёта в облаке
«Пробуждение» compute из idle-состояния занимает сотни миллисекунд
Которая в итоге выльется в 1-2 секунды. Т.к. трафик не будет направлен в под до тех пор, пока тот не перейдет в состояние "Ready". Все пробы в Kubernetes имеют минимальное значение 1 сек.
from math import gcd
from sympy import primefactors
def is_primitive_root(g, p):
if gcd(g, p) != 1:
return False
order = p - 1
for q in primefactors(order):
if pow(g, order // q, p) == 1:
return False
return True
def min_primitive_root(p):
for g in range(2, p):
if is_primitive_root(g, p):
return g
if __name__ == '__main__':
sess_const = 23 # Большое простое число (в реальности 2048+ бит)
pr = min_primitive_root(sess_const) # Первообразный корень по модулю sess_const
a = 6 # Секретный ключ Алисы
A = pow(pr, a, sess_const) # Публичный ключ Алисы (отправляется Бобу).
b = 15 # Секретный ключ Боба
B = pow(pr, b, sess_const) # Публичный ключ Боба (отправляется Алисе)
K_alice = pow(B, a, sess_const)
K_bob = pow(A, b, sess_const)
print(f"Публичные параметры: p = {sess_const}, g = {pr}")
print(f"Алиса: приватный a = {a}, публичный A = {A}")
print(f"Боб: приватный b = {b}, публичный B = {B}")
print(f"Общий секретный ключ у Алисы: {K_alice}")
print(f"Общий секретный ключ у Боба: {K_bob}")
Здесь есть подробное объяснение как это работает, но без подготовки это скорее всего не осилить. Тут можно закончить словами автора: Всё, что вам нужно понять на данном этапе, – это то, что технология работает
После прочтения Асимметричное шифрование и ECDH магия осталась магией из-за пропущенного процесса вычисления общего секретного ключа. Потому что
Голову можно ломать долго и безрезультатно, пока не поймем, что такое асимметричное шифрование и протоколы обмена ключами.
Если не погружаться в самые дебри, то:
У Алисы есть приватный ключ (a) и публичный ключа (A). Публичный ключ высчитывается из приватного ключа A = a x G
У Боба так же приватный (b) и публичный (B = b x G)
G – это базовая точка на эллиптической кривой, общая для всех. Алиса и Боб заранее договорились какую кривую будут использовать. За нас уже всё посчитано, точка описана в стандарте, просто берем её оттуда.
Алиса и Боб обменялись публичными ключами и каждый из них умножает свой приватный ключ на публичный ключ собеседника:
Алиса: a x B => a x (b x G) = ab x G
Боб: b x A => b x (a x G) = ba x G => ab x G
Вот и вся "магия" получения общего секретного ключа
Можете попробовать pyinstaller. Он соберет только необходимые файлы для вашего приложения в один бинарь. Решение спорное, но вроде все ваши потребности закрывает и более безопасным способом
Gitlab и Verdaccio можно сконнектить через OpenID и не мучаться с паролями в htpasswd. Даст возможность использовать CI_JOB_TOKEN в джобах и авторизовываться в web-интерфейсе по кнопке
Какие-то абстрактные цифры про средний пробег в 20 км в день. Мне ребенка в школу отвезти и забрать это почти 20 км. Так же у нас холодно, 2 недели было -25 ... -30, это дополнительный расход.
Не хватает зарядки за ночь от розетки, покрывающий мой дневной расход/пробег!!! Зарядка от розетки позволяет реже бывать на зарядной станции. А про очередь и время зарядки проще промолчать. С розеткой мне повезло, удалось договориться с УК чтобы подключиться у охранника.
Доя экстренных случаев есть быстрые зарядки до 500 КВт
Всё верно говорите: недодокер и недокубер. Зачем писать кубер и докер, когда они уже есть и они то как раз не нужны!
В документации по кубу есть информация об Aggregation Layer, там как раз описано как сделать недокубер. Так же там есть информация, как сделать недодокер и настроить его для работы с кубом.
думаете у куба проверен и на 100% безопасный?
Да, действительно только контроллер и агент. Оно работает абсолютно без каких-либо зависимостей!
Много где использую Prometheus, VictoriaMetrics и Zabbix (даже живой graphite имеется), но для их работы нужны ресурсы, которые в моём случае сильно ограничены. Разворачивать дополнительную инфраструктуру мониторинга, чтобы посмотреть метрики раз в месяц или реже – выглядит затратно.
В остальном вы решили свою задачу одним способом, я другим. Можете поделиться своими наработками в статье.
на днях завершил переход на всех серверах на вторую версии AmneziaWG только из-за AWG Admin. А первая версия по-прежнему работает.
curl/wget — скачать слои образа
tar — распаковать слои
mount — смонтировать rootfs
systemd — запустить приложение как сервис
Ни в одном из этих пунктов нет Docker/Podman. OCI-образ — это просто tar-архив с корневой файловой системой и JSON-манифестом. И работает этот механизм начиная с версии ядра 3.18. В случае, если у клиента контейнеры под запретом и нет registry, то мы всегда можем принести на флешке OCI-layout, который после создания systemd .mount и .service будет работать абсолютно так же, как и после запуска через docker compose up или установки системного пакета.
Решает — и не только он один. Все они имеют одну общую базу: это просто обёртки над Linux Namespaces, cgroups и файловыми системами (overlayfs). По сути, CRI-O, Docker (containerd) и Podman, в основе работают с одними и теми же примитивами ядра. Технологически — да, это прекрасно работает, когда контейнеры разрешены и есть инфраструктура под них.
Но проблема, которую я описываю в статье, находится на уровень выше. Она не в том, как запустить изолированный процесс, а в том:
как доставить артефакт (образ, бинарник, пакет) в произвольное окружение, где может не быть registry;
как применить конфигурацию, уникальную для каждого заказчика (сети, прокси, хранилища, сертификаты);
как обеспечить обратную совместимость, когда на одной версии ОС работает один набор зависимостей, а на другой — другой.
Docker Compose справляется со своей задачей — описать многоконтейнерное приложение в среде Docker. Но даже если контейнеры разрешены, Compose не рассчитан на развертывание на 10+ машинах (а есть 100 и 200, такие случаи не редки) — это инструмент для локальной разработки или небольших кластеров, а не для массового продакшена.
Это мы и делаем сейчас, и именно это приводит к разрастанию инфраструктурной кодовой базы. Helm-чарт, Docker-образ, RPM, DEB, плюс скрипты для Alt Linux, Astra, РЕД ОС — и вот у вас уже не один способ установки, а пять, и каждый нужно тестировать, поддерживать и синхронизировать с новой версией приложения. Количество ресурсов для поддержки ограничено. А если заказчик вообще не использует контейнеры, Compose и Helm становятся бесполезны.
Поэтому я и предлагаю не плодить способы установки, а подумать о том, как унифицировать процесс доставки так, чтобы он не превращался в ещё один продукт, который нужно разрабатывать и поддерживать. В таком случае мы всегда будем работать с одним и тем же артефактом, но в абсолютно разных окружениях
в enterprise так не работает. Заказчик платит деньги и хочет, чтобы работало на его инфраструктуре.
Шестой до сих пор живёт на CentOS 7, потому что обновление инфраструктуры — отдельный многолетний проект.
Это реальный кейс. Каждый такой кейс добавляет ещё один виток сложности в наши сценарии развёртывания.
По поводу контейнеров — причины бывают разные, и не всегда они рациональны с технической точки зрения, но они напрямую диктуются моделью угроз конкретной организации. Комментарии к требованиям ИБ получить, чаще всего, не удаётся — это внутренняя политика, и спорить с ней бесполезно. Приходится принимать как данность и искать обходные пути.
Про ПАК — да, это один из вариантов и мы его используем, но ПАК тоже не панацея. Он решает проблему совместимости на уровне ОС, но не решает проблему доставки самого приложения и его зависимостей. Плюс ПАК — это ещё один слой, который надо внедрять и поддерживать. А обновление ПАК никто не отменял: новая версия ОС, новый патч безопасности — и вы снова проходите весь цикл тестирования и согласования.
Придумывать ничего не надо, всё уже придумано до нас, мы только пользуемся.
Видимо вы пропустили главу "Когда начинается ансиБОЛЬ". Конечный набор сценариев подразумевает конечный набор фичей. С такой политикой вы быстро бы покинули рынок, если бы были вендором ПО.
Из релиза агента. Либо скачать к себе файл и указать локальный путь
Мы ведь про облака?
Рассматривается же запуск Postgres/Neon на ноде куба, т.е. тарифицируется нода куба, а не запущенные поды/контейнеры на ней. Если действительно это запускается в кубе, то к стоимости ноды придется добавить сумму за использование S3. Если 10 rps, то выходит копейки за месяц, если же 100+ rps, то сумма за использование S3 уже будет начинать ощущаться. В какой-то момент и Neon начнет "затыкаться", это произойдет сильно раньше, чем постоянно работающий Postgres.
Neon выглядит интересно, но кейсы использования его более узки, чем нативная Postgres.
Так если он и так поднят и как выше написал, мы платим за целую ноду куба, то какой профит от него вне бессерверных контейнерах?
А бизнесу никто не сказал, что теперь каждый запрос к БД (S3) будет не бесплатным? Выглядит так, что на нагруженных проектах, нововведение приведет к увеличению ежемесячного счёта в облаке
Которая в итоге выльется в 1-2 секунды. Т.к. трафик не будет направлен в под до тех пор, пока тот не перейдет в состояние "Ready". Все пробы в Kubernetes имеют минимальное значение 1 сек.
число может быть любым простым. Этот скрипт у меня давно уже и вроде как он писан на основе какого-то учебного пособия, скорее всего цифры оттуда
более простого объяснения не знаю
Здесь есть подробное объяснение как это работает, но без подготовки это скорее всего не осилить.
Тут можно закончить словами автора:
Всё, что вам нужно понять на данном этапе, – это то, что технология работаетПосле прочтения Асимметричное шифрование и ECDH магия осталась магией из-за пропущенного процесса вычисления общего секретного ключа. Потому что
Если не погружаться в самые дебри, то:
У Алисы есть приватный ключ (a) и публичный ключа (A). Публичный ключ высчитывается из приватного ключа A = a x G
У Боба так же приватный (b) и публичный (B = b x G)
G – это базовая точка на эллиптической кривой, общая для всех. Алиса и Боб заранее договорились какую кривую будут использовать. За нас уже всё посчитано, точка описана в стандарте, просто берем её оттуда.
Алиса и Боб обменялись публичными ключами и каждый из них умножает свой приватный ключ на публичный ключ собеседника:
Алиса: a x B => a x (b x G) = ab x G
Боб: b x A => b x (a x G) = ba x G => ab x G
Вот и вся "магия" получения общего секретного ключа
Можете попробовать pyinstaller. Он соберет только необходимые файлы для вашего приложения в один бинарь. Решение спорное, но вроде все ваши потребности закрывает и более безопасным способом
если следовать настройкам из доки яндекса, то доступны все
https://hashicorp-releases.yandexcloud.net/terraform-provider-aws/
Без ВПН можно использовать зеркала Яндекс и Селектел (возможно не только их)
Как это развернуть у себя?
Если это пошаговое how-to, то где шаги для воспроизведения?
Какие плюсы по сравнению с Gitea Actions или Drone?
Почему это называется "платформа"?
В голосовалке отсутствует ещё один вариант
Gitlab и Verdaccio можно сконнектить через OpenID и не мучаться с паролями в htpasswd. Даст возможность использовать CI_JOB_TOKEN в джобах и авторизовываться в web-интерфейсе по кнопке
Я не из США или ЕС
Какие-то абстрактные цифры про средний пробег в 20 км в день. Мне ребенка в школу отвезти и забрать это почти 20 км. Так же у нас холодно, 2 недели было -25 ... -30, это дополнительный расход.
Не хватает зарядки за ночь от розетки, покрывающий мой дневной расход/пробег!!! Зарядка от розетки позволяет реже бывать на зарядной станции. А про очередь и время зарядки проще промолчать. С розеткой мне повезло, удалось договориться с УК чтобы подключиться у охранника.
в Москве возможно и есть)