Комментарии 18
Не используйте BillManager от ispsystem, ведь цена может вырасти на 100%.
Не используйте VmManager от ispsystem, ведь все ваши VPS можно будет удалить и мы даже не расскажем детали и причину.
Нам жаль, что у вас сложилось такое впечатление о сервисе. Тарифы BILLmanager не менялись, а баги и ошибки продуктов оперативно устраняются. Так, 10 сентября мы обнаружили уязвимость платформы VMmanager, которую исправили в релизе 2021.09.1-1 от того же дня. Кроме того, каждый пользователь может стать участником программы выплат за сообщения о выявленных ошибках, сделать продукт безопаснее и удобнее, получив вознаграждение. По вопросам работы и тарификации продуктов компании вы можете в любой момент обратиться в службу поддержки: по телефону, через Telegram, онлайн-чаты или по электронной почте, а также через заявку в личном кабинете. Все доступные контакты размещены на нашем сайте в разделе «Центр Помощи»: https://www.ispsystem.ru/support. Спасибо за интерес к нашему продукту!
Сейчас вы подписаны на тариф BILLmanager Corporate, стоимость которого — 48 € в месяц, без учета персональных скидок. С 1 мая стоимость лицензионного вознаграждения увеличивается до 150 € в месяц. Это первое обновление стоимости с момента запуска продукта, которое состоялось 7 лет назад.
Да. Был не прав. не на 100%, а на 300%
Так, 10 сентября мы обнаружили уязвимость платформы VMmanager
Так в чем она заключалась? Где детали?
По вопросам работы и тарификации продуктов компании
Не можете. любой вопрос, кроме как потратить у вас деньги => пишите на емайл => это не ошибка, это вы криворукие => через 2 недели => да это ошибка, мы ее когда нибудить исправим (нет - уже год прошел)
А как же прекращение возможности продления лицензий ISPManager 5 версии и форсирование перехода на 6-ую, которая существенно дороже?
Никто не знает, как правильно устанавливать и упаковывать Python-приложения
Извините, что?
Про упаковку есть более чем понятный официальный мануал. Можно даже собственный репозиторий поднять в несколько кликов, потом
pip install somethingИли вы про такие Python-приложения которые содержат код на C, например?
Сюда можно добавить и сборку в один бинарник, со всеми зависимостями.
думаю речь шла о том что упаковывать и устанавливать правильно в виде deb/rpm/ebuild/etc а не pip
и тут я пожалуй бы согласилься если речь идёт про софт живущий в хостовой ОС а не в контейнере
но тоже не понимаю в чём проблема пнуть одной командой py2pack и покурить пока он шуршит
и там дичь в setup.py и приплыли... не надо pip install :-)
А еще pip до последнего времени буквально ничего нормально не резолвил, если два пакета требовали две разные версии зависимости
думаю речь шла о том что упаковывать и устанавливать правильно в виде deb/rpm/ebuild/etc а не pip
тоже хороший вариант, но он не очень подходит для среды разработки... И вот этот переход - из мира python (с pip install) в мир пакетного менеджера операционки и назад - очень больной
классический пример сервиса с высокими рисками и низкой отдачей. Задачи клиентов он не решает, руководителей не впечатляет, а для его разработки требуются уйма времени и набор специфических знаний.
Таковы вообще все инфраструктурные сервисы.
Не цельтесь сразу в нескольких облачных провайдеров
Parler с этим категорически не согласен.
Хорошо бы еще знать модель угроз для бизнеса, в рамках которых даны эти рекомендации. Решение о принятии, скажем, vendor-lock риска не может приниматься на уровне девопс или в угоду разработчикам. Погоны не те. В рунете есть переведенные стандарты ISO по управлению рисками. Совсем не обязательно реализовывать их целиком, достаточно не изобретать свои. Главное, структурировать подход для оценки и выбора мер.
Ха, мы совершили все эти ошибки. С выводами согласен полностью. Особая боль это собственный k8s. Брр.. Но вот самое интересное, даже если бы я эту статью прочитал лет 5 назад, уверен, что проигнорировал бы. Подумал бы - со мной такого не случится, это просто другие люди глупые, а я молодец, у меня такого не будет. К сожалению, опыт подобных ошибок не всегда можно передать кому-то, кто сам не попробовал.
Пишите статью со списком граблей, которые вы словили с собственным k8s ;)
Да, грабли k8s интересны. Тоже грешным делом думаю завести себе такие, вот ищу причину чтобы этого не делать.
Грабли, которые были у нас:
Очень капризный в плане зависимостей: ядро, операционка, компоненты, драйвера должны быть совместимы. Когда перешли на EKS и GCP, забыли про это.
Сталкивались с багами в файловом драйвере и в сетевом слое. Сталкивались с багами в ядре. Если у нас в приложении что-то не работало, то приходилось еще и проверять k8s помимо приложения. То есть не было уверенности, что наши кластеры стабильны. У вендоров есть свои проблемы, например, у EKS поды иногда застревают в Terminated, но это не так страшно, как когда на своем кластере просто ломалась сеть или отваливался драйвер overlayfs.
Файловая система: мы так и не смогли нормально сделать persistence volumes. Пробовали Ceph, пробовали glusterfs, пробовали local volumes. Везде свои минусы. У GCP/EKS проблем нет - gp2/gp3 EBS, или аналог у гугла. "просто работает".
Практически нигде мы не запускали HA control plane - сложно, да и жалко было серверов.
Обновления это боль. С частыми релизами k8s, версии становятся EOL через 9 месяцев. Если кластеров много, это очень геморно. Плюс, пункты 1 и 2 - при обновлении обычно что-то отваливалось. У вендоров обновление происходит одной кнопкой.
Практически нигде мы не запускали HA control plane - сложно, да и жалко было серверов.
ну, такое. Ничего сложного в HA control plane не вижу - и всегда делаем так. Насчёт жалко серверов - это вообще какой-то очень странный аргумент, т.к. если проект хоть сколько-нибудь серьезный, то отказоустойчивость необходима
Не повторяйте: мои инфраструктурные ошибки