Выше писал, что Яндекс Облако посылает сигнал за 30 секунд до выключения ВМ, этого времени недостаточно чтобы что-то успеть сделать. По этому эту идею в начале откинули.
Да, прерываемая ВМ может быть выключена в любое время, по этому пока используем в тестовых кластерах. Но за несколько месяцев использования еще не было ситуации чтобы это повлияло на работу кластера. И да, сигнал посылается и его даже можно отследить, то он отправляется за 30 секунд до отключения, так что толком ничего успеть не получится.
Такая ситуация тоже возможна, но пока ниразу не сталкивались. Для обработки подобных сценариев дорабатываем оператор, чтобы он за раз не кордонил больше одной ноды и следил, чтобы новые ноды появляись во время. Возможно в будущем продумаем возможность переводить нагрузку на обычные ноды в случаи невозможности создать прерываемую.
В виде cli-утилиты это сделать будет сложно. Надо либо собирать через API все ресурсы и считать их, либо отчет билинга парсить и генерить отчет. Но без истории изменений думаю не очень полезно будет.
Cost Optimizer for Clouds - finops инструмент для оптимизации расходов в публичном Облаке. Поможем сократить расходы на 10-30% - просто, убрав overrequest. И до 70% за счёт автоматического управления - выключайте ресурсы, которые не используются в данный момент.
Тогда почему регистри не HA? Ваш регистри упал, сломался, не справился с нагрузкой и все стейджы встали, ни сборку сделать, ни выкатить новую версию. Да еще и в проде под решил переехать на другую ноду, а там нет образа и ваш прибыльный сервис начал терять деньги.
Пока вы предлагает откровенно непригодное для прода решение.
То есть, вы предлагаете для каждого стейджа свой регистри делать? А потом еще их синхронизировать между собой? Удаление руками, в WebUI! вы точно про продакшен рейди продукт говорите?
По размеру уже приемлемо. Жду релиз или краудфандинг. С удовольствием куплю такую штуку. Надоело таскать с собой ворох ключей и вспоминать какой от чего)
Отличный проект. Надеюсь сможете его развить и улучшить. Хотелось бы увидеть больше авторов, в том числе современных, возможность включать/исключать авторов из своей ленты, и возможность делиться стихом по ссылке.
Распределенный кэш уже позже добавлял, после написания статьи. Реализовано через "файловое хранилище" (аля NFS от Яндекс Облако). Правда пришлось дописывать docker-machine провайдер от яндекса(пока не хватает времени завершить МР), чтобы динамические раннеры умели при создании подхватывать и монтировать ФХ. В результате как раз у раннеров, где собирается nodejs есть общая папка, которая используется для хранения разнообразного кэша или общих файлов.
Да, пока еще не успели подвести итоги и вывести какие-то конкретные цифры.
Если кратко, то:
Скорость сборок выросла за счет того, что каждая джоба запускается в изолированной среде и на нее не влияют другие процессы. Плюс смогли значительно увеличить характеристики ранера, что ускорило сборку особенно для nodejs проектов. Так же исчезли очереди, поскольку динамические раннеры создаются по требованию и и легко масштабируются и даже в пике все пережевывается быстро.
По деньгам тут сложно сказать. Но динамические раннеры точно дешевле, поскольку работают только когда нужно. Так например, ночью и в выходные они соверешенно не тратят деньги. Плюс они коротко живущие, у нас каждый раннер живет не более 30 минут, если на него не прилетает нового задания.
Добрый день. Пока не планируем выпускать в мир. Просто не хватает сил, чтобы довести оператор до публичного вида.
Выше писал, что Яндекс Облако посылает сигнал за 30 секунд до выключения ВМ, этого времени недостаточно чтобы что-то успеть сделать. По этому эту идею в начале откинули.
Да, мы тоже такой подход используем для ВМ разработчиков и части инфровых ВМ.
Да, прерываемая ВМ может быть выключена в любое время, по этому пока используем в тестовых кластерах. Но за несколько месяцев использования еще не было ситуации чтобы это повлияло на работу кластера. И да, сигнал посылается и его даже можно отследить, то он отправляется за 30 секунд до отключения, так что толком ничего успеть не получится.
Такая ситуация тоже возможна, но пока ниразу не сталкивались. Для обработки подобных сценариев дорабатываем оператор, чтобы он за раз не кордонил больше одной ноды и следил, чтобы новые ноды появляись во время. Возможно в будущем продумаем возможность переводить нагрузку на обычные ноды в случаи невозможности создать прерываемую.
В виде cli-утилиты это сделать будет сложно. Надо либо собирать через API все ресурсы и считать их, либо отчет билинга парсить и генерить отчет. Но без истории изменений думаю не очень полезно будет.
Cost Optimizer for Clouds - finops инструмент для оптимизации расходов в публичном Облаке. Поможем сократить расходы на 10-30% - просто, убрав overrequest. И до 70% за счёт автоматического управления - выключайте ресурсы, которые не используются в данный момент.
Тогда почему регистри не HA? Ваш регистри упал, сломался, не справился с нагрузкой и все стейджы встали, ни сборку сделать, ни выкатить новую версию. Да еще и в проде под решил переехать на другую ноду, а там нет образа и ваш прибыльный сервис начал терять деньги.
Пока вы предлагает откровенно непригодное для прода решение.
То есть, вы предлагаете для каждого стейджа свой регистри делать? А потом еще их синхронизировать между собой? Удаление руками, в WebUI! вы точно про продакшен рейди продукт говорите?
А где будут данные хранится? На дисках очень дорого.
А как происходит очистка старых образов? Все хранить опять же дорого, да и не нужно
А как на счет HA? Сервис максимально критичный, поскольку если он встанет, то колом встанет все
Выглядит как лабораторная работа студента. Даже для небольшого проекта в прод я бы это не пустил.
По размеру уже приемлемо. Жду релиз или краудфандинг. С удовольствием куплю такую штуку. Надоело таскать с собой ворох ключей и вспоминать какой от чего)
Отличный проект. Надеюсь сможете его развить и улучшить. Хотелось бы увидеть больше авторов, в том числе современных, возможность включать/исключать авторов из своей ленты, и возможность делиться стихом по ссылке.
Тогда я бы назвал "универсальный", а то уникальный вводит в некоторое заблуждение.
Вы пишите, что разработали "уникальный chart". А в чем его уникальность?
Интересная история. А для тех кто собирается вкатываться я бы заострил внимание на двух моментах, которые затронул автор:
ИТ должно нравится и сильно, чтобы преодолеть все сложности
Надо вкалывать очень много, особенно на старте
Когда нужен полный доступ к хостовой машине. Например, когда для сборки используется GPU
Тоже сталкивался с такой задачей. Оно гуглится в пару секунд, к чему целую статью для этого писать?
Абсолютно бесполезный велосипед, но зато есть в Роспатенте.
Распределенный кэш уже позже добавлял, после написания статьи. Реализовано через "файловое хранилище" (аля NFS от Яндекс Облако). Правда пришлось дописывать docker-machine провайдер от яндекса(пока не хватает времени завершить МР), чтобы динамические раннеры умели при создании подхватывать и монтировать ФХ. В результате как раз у раннеров, где собирается nodejs есть общая папка, которая используется для хранения разнообразного кэша или общих файлов.
Да, пока еще не успели подвести итоги и вывести какие-то конкретные цифры.
Если кратко, то:
Скорость сборок выросла за счет того, что каждая джоба запускается в изолированной среде и на нее не влияют другие процессы. Плюс смогли значительно увеличить характеристики ранера, что ускорило сборку особенно для nodejs проектов. Так же исчезли очереди, поскольку динамические раннеры создаются по требованию и и легко масштабируются и даже в пике все пережевывается быстро.
По деньгам тут сложно сказать. Но динамические раннеры точно дешевле, поскольку работают только когда нужно. Так например, ночью и в выходные они соверешенно не тратят деньги. Плюс они коротко живущие, у нас каждый раннер живет не более 30 минут, если на него не прилетает нового задания.
А зачем бэкапить стейт? И если бэкапим, то стоило б указать как восстановить из такого бэкап.