Доступен выпуск свободной PaaS-платформы Cozystack 0.33, построенной на базе Kubernetes. Проект нацелен на предоставление готовой платформы для хостинг-провайдеров и фреймворка для построения частных и публичных облаков. Платформа устанавливается напрямую на серверы и охватывает все аспекты подготовки инфраструктуры для предоставления управляемых сервисов. Cozystack позволяет запускать и предоставлять кластеры Kubernetes, базы данных и виртуальные машины. Код платформы доступен на GitHub и распространяется под лицензией Apache-2.0...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=63589
Этот ваш PaaS не нужон!
Мы просто в гуе проксмокса виртуалочку подняли да постгрес установили!
God bless you!:))
Этот ваш proxmox не нужон. В пару команд накатил paas и в 1 клик установил HA постгрес с pgbouncer и бекапами
И потом весь этот винегред на***тся и будешь копать разбираться, как эта шляпа работает.
Всякая HA херня настраивается на шлюзе при помощи HAPROXY и этого достаточно. Сетевучку проще вставить на 10G, чем этот велосипед ковырять. Смузихлебное гавнище.
> И потом весь этот винегред на***тся и будешь копать разбираться, как эта
> шляпа работает.
> Всякая HA херня настраивается на шлюзе при помощи HAPROXY и этого достаточно.
> Сетевучку проще вставить на 10G, чем этот велосипед ковырять. Смузихлебное гавнище.Я, видимо, говорю с кем-то типа сталлоне, которого только что в разрушителе разморозили. Опеншифты, ранчеры, кубернетесы никому не нужны, ага:) Это просто злые люди придумали, чтобы портить жизнь людям добрым:)
Если с пятью демонами и rbac не можешь разобраться, может вообще не стоит в системное администрирование лезть?
А почему вы считаете, что это задачи именно для системных администраторов? Почему бы не делегировать рутину платформе? Много вы инфры настроите своими руками в современном банке или чем-тот таком? При этом внутренние пользователи смогут по кнопке заказывать себе готовые кластеры, виртуалки и другие окружения? И при этом будет всё это не на башизмах, которые со временем будет невозможно прочитать, а знать, как всё это устроено, будете только вы? Если вы живёте в таком мире, то у меня для вас плохие новости:)
Воу-воу, палехчи, не в ту сторону воюешь. Я за вашей платформой слежу с корыстным интересом — время от времени появляются клиенты, которым что-то подобное нужно. С блеском и нищетой однокнопочных решений знаком не по наслышке, приходилось реализовывать с нуля для OpenStack и LXD. Не так страшен чёрт как его малюют, тем более что сабж тоже так — в одну кнопку — не очень-то умеет, что-то да придётся делать чтобы это работало. Да и платформа сама с неба не упадёт, кто-то должен её забутстрапить. Так что выдыхай и смотри внимательно на что отвечаешь.
Я не про кози говорил, а про принцип автоматизации в принципе. В кози как раз гуишка совсем не главное и скиллы нужны (и немало))
>И при этом будет всё это не на башизмах, которые со временем будет невозможно прочитать, а знать, как всё это устроено, будете только вы?Как будто в неработающих кубернатесах разобраться проще, ага. Ох уж эти сказочники-автоматизаторы.
Если софт изначально нормальный (согласен, это сейчас большая редкость), то ему вот эта вся контейнеризация просто ненужна. Его поставил, и он работает. И да, порою пара строчек на шелле гораздо проще кубернетовых дебрей, как показывает практика (не моя, просто читал в Инете).
По ним специалистов всё же несоизмеримо больше, чем по легаси, написанному одним человеком для одной компании.Контейнеризация не нужна? А как вы будете менеджить то, что он должен скейлиться горизонтально и вертикально, как микросервисы крутить и т.п.? Ну утопия же то, что у вас описано. Софт кривой не из-появления кубернетеса, а потому что бабло всегда будет важнее хорошего кода. И если этот софт сделать прямым, необходимость в контейнерах и оркестрами никуда не денется.
А на что лучше быть завязаным? На то, по чему есть специалисты и комьюнити? Или на единичное решение для одной компании, которое написали несколько лет назад, а теперь даже тронуть боятся, потому что хз, где там отстрелит?
По ним специалистов всё же несоизмеримо больше, чем по легаси, написанному одним человеком для одной компании.Контейнеризация не нужна? А как вы будете менеджить то, что он должен скейлиться горизонтально и вертикально, как микросервисы крутить и т.п.? Ну утопия же то, что у вас описано. Софт кривой не из-появления кубернетеса, а потому что бабло всегда будет важнее хорошего кода. И если этот софт сделать прямым, необходимость в контейнерах и оркестрами никуда не денется.
А на что лучше быть завязаным? На то, по чему есть специалисты и комьюнити? Или на единичное решение для одной компании, которое написали несколько лет назад, а теперь даже тронуть боятся, потому что хз, где там отстрелит?
единственно адекватный комент, и то заминусилине модно вы батенька работаете )))
Если наброс в мою сторону или в сторону мейнтейнеров, то мы такие комменты никогда не минусуем. Набросы и критика — это же прям очень хорошо. Это повод глубже разобрать тему и возможность повлиять на тех, кто читает эти самые набросы в комментах.
> Если наброс в мою сторону или в сторону мейнтейнеров, то мы такие
> комменты никогда не минусуем. Набросы и критика — это же прям
> очень хорошо. Это повод глубже разобрать тему и возможность повлиять на
> тех, кто читает эти самые набросы в комментах.я не знаю кто его минусил, если ты, то тогда да ))
"Опеншифты, ранчеры, кубернетесы никому не нужны, ага" ну как тебе сказать, вообще-то да, возникновение этого дэрма стало следствием других событий и желаний, например продать тебе облачную хрень за дорого, под соусом скейлишься вместе со своим приложением.
Так что да, оно конечно нужно, тому, кто его продает... еще бы! такие бабки )))
Да все это херня. Никто адекватный не делает реальной рабочей инфраструктуры на такой фигне.
Везде где я ходил в очень серьезные конторы с очень серьезными людьми - там везде старая школа, freebsd, debian + qemu. И никто никогда не перейдет туда, пока это работает и выполняет свою функцию.
Поздравляю тебя, Шарик - ты только что переместил единую точку отказа с postgresql на haproxy. Ой, нет - не переместил, postgres в multimaster не то, чтобы умеет - а о failover'е ты не подумал...
Но в общем-то для части решений "И та-ак сойдет!"
Да ты чо? А без шлюза граничного как твой postgresql вообще будет работать не подскажешь?
Шарик здесь только ты, смузи иди попей
> Да ты чо? А без шлюза граничного как твой postgresql вообще будет
> работать не подскажешь?
> Шарик здесь только ты, смузи иди попейТю! Та то ж ты на стол вылез, что "всю HA одним haproxy" обеспечишь - вот тебе Родос, здесь и прыгай.
Что все остальные предлагают от "граничного шлюза"(ТМ) отказываться - это твои личные, ни на чем не основанные проЭкции.
пара бакапов и денюжка на карточке закончилась.
Куб, в подах которого виртуалки, поверх которого кубы. Я так сильно отстал от жизни, что это считается валидной реализацией в 21 веке??? Звучит как лютый .....
Рассказывай как надо делать. Каждому кастомеру отдельные серверы для его кластеров? Поставить какую-то другую систему виртуализации и в ней реализовать 3/4 кубернетеса? Вообще не пользоваться автоматизацией и вручную солнце закатывать? Что предлагаешь?
Ничего, я ж по этому и спрашиваю шарящих.
Это распространённая схема. OpenStack тоже удобнее так деплоить чтобы «нижний» минимальный деплой менеджил «верхний» полноразмерный для прода. Не заводить же два разных инструмента для одной и той же работы.
Любопытно, пойду ка почитаю про такой подход.
Там платишь за удобство памятью хоста, которую ужирают ОС в kvm под pagecache'ы
Как минимум, удобно рулить и виртуалками, и родами в единой парадигме. Курьер по факту становится стандартом, девопсы и сисадмина всё больше его изучают, всё проще найти на него спецов. Удобно управлять всеми сущностями через единый понятный всё большему количеству специалистов Kubernetes API. Мы думаем, что за кубер апи будущее.
ИМХО, это и есть лютый трэш. Сначала кажется: "Ой как удобно, быстро разворачиваются кластеры, никаких bash скриптов." Но ровно до тех пор, пока не нужно найти причину нестабильности, тормозов или какого-то бага. И вот тут выясняется, что разобраться во всем этом и отдебажить - вообще ни разу не просто. А уж если, ну я не знаю, какой-то элемент кластера случайно повредился(удалили, сломали конфигурацию), то проще раскатать из бэкапа, чем искать причину и восстанавливать.
Сами же описали, что без дебага можно решать вопросы. Всегда говорят деньги. Надо принять этот факт. Красивые инженерные решения никому не нужны.
> Добавлена опция cluster-domain для переопределения домена cozy.local.Кроме тщеславия есть какие-то объективные причины менять дефолт? Теперь чтобы накатить что-то нужно не забывать менять домен везде, где он используется. А где-то бывает и вовсе захардкожено, что отстой и фу, но реальность такова, что не всегда есть возможность исправить без форка и пересборки всего проекта. И всё это ради чего? Чтобы где-то в недрах кубера красивенько название проекта засветилось?
На старте разработки это казалось правильно, сейчас как раз откатили до дефолтного куберовского значения. Вопрос не тщеславия, просто казалось, что это архитектурно правильнее, чтобы отличать домены в Кози от доменов других кластеров. Потом увидели, что это не очень и сделали нормально.
> казалось, что это архитектурно правильнее, чтобы отличать домены в Кози от доменов других кластеров.Жаль, меня там не было, где это решение принималось, я бы вас от этого отговорил в самом начале. Архитектурно правильно не создавать особенных случаев и не менять дефолты без доказательного эксперимента того, что иначе невозможно. Я рад, что здравомыслие возобладало.
И отдельно рад, что проект в CNCF переехал. Теперь когда он под крылом известного фонда с десятилетней историей и серьёзными участниками, решение на сабже можно наконец-то попытаться кому-то продать. Пока это был один AEnix было куда сложнее.
Фонды это так е же корпорации, только фонды.
Ну не совсем. Фонд может гарантировать, что свободная лицензия на проект сохранится и ее какая-то отдельная компания не сможет по своему усмотрению поменять (как с терраформом или монгой получилось).
В этом есть смысл, чтобы не было коллизий, когда под из managed-k8s внутри пытается обратиться к какому-то managed postgres снаружи. Интересно, как теперь это разруливается, ведь любому запросу теперь светит словить NXDOMAIN.
А можно пояснить почему каждый именно свой вариант пилит менеджеров. Здесь cozypkg, у соседей werf. Кто то argocd приделывает.
Cozypkg и werf прям решения совершенно разного уровня. werf полноценная крутая большая утилита. В то время как Cozypkg маленькая простенькая штучка внутри платформы, по сути. Вряд ли кто-то будет ее широко использовать отдельно от козистека, хотя это, конечно, возможно. ArgoCD завезём со временем тоже (это скорее для разрабов, которые к нему и к его гуишке привыкли), есть в довольно близких планах. А cozypkg не отменяет того, что у нас доставка на Flux построена.
Ох, linstor походу уже новый стандарт, да? Но почему поверх ZFS? В гиперконвергентном развертывании с памятью же проблемы будут - а делать отдельные storage nodes менее удобно с т.з. управления.
Metallb кмк тоже не бесспорный выбор - BGP требует поддержки оборудования, а на L2 в больших инсталляциях будет проблема с тем, что весь трафик фактически пойдет через одну ноду.
А чем заменить metallb? Без поддержки оборудования, я не представляю, что какие-то альтернативы будут лучше или функциональнее.
> А чем заменить metallb? Без поддержки оборудования, я не представляю, что какие-то
> альтернативы будут лучше или функциональнее.Тут вопрос в другом - если решение, которое ты предлагаешь _гарантированно_ не упирается в терминацию всего внешнего трафика в одну ноду - metallb на L2 хороший выбор. Если мы говорим про PaaS - то проще, наверное, вообще не закладываться.
Конечный пользователь или связку bgp-cillium\calico с поддержкой железа сделает, или железяку поставит или вот просто кластер haproxy'ей перед кубиком соберет - на что рук\денег хватит.