Тут ещё стоило написать про ущербный набор сторадж-классов, поставляемых «из коробки». Например, если кубик многозонный, а вы используете обычные сетевые диски, то они не умеют в миграцию между зонами. Вытеснило под по ресурсам на другую ноду в другой зоне и привет.
По поводу повторного запуска и скорости его работы. Всё зависит от количества изменённых фалов и объёма изменений, но в целом скорость уменьшается не глобально, как минимум потому, что требуется перебрать все файлы. Время в таблице приведено усреднённое после нескольких запусков, первый запуск выполнялся дольше.
По поводу объёма итоговых данных. Если сравнивать инкрементный бэкап tar и слой/коммит созданный restic, то restic сильно проигрывает. В нашем случае после первого запуска бэкап tar получался порядка 250Мб, у рестик объём полученного каталога сотавил чуть больше 2Гб. Прирост инкремента будет зависеть от объёма данных.
Если рассматривать restic как инструмент используемый исключительно для копий файлов, то, безусловно он отлично справляется со своей задачей. Он реализует классный подход к хранению и, что действительно круто, даёт очень простой способ восстановить файловые данные на нужную дату вообще не напрягаясь.
В нашем случае есть определённые требования, под которые restic, к сожалению, не подходит. Это, в частности, создание копий БД. Отчасти это можно обойти, передавая поток данных в stdin, но это существенно осложняет процесс настройки регулярных бэкапов и, что важнее, восстановления из таких копий.
Резюмируя, сам по себе инструмент интересный и перспективный, но не в наших сценариях работы.
На этот раз взяли диск на 500 ГБ, сгенерировали на нем 30 файлов по 9,8 ГБ. Вместе с данными ОС все вышло на 296 ГБ данных.
Данная конфигурация дампилась около часа, значит реальная скорость составила около 100Мбайт/с или ~800МБит/с. Думаю, вас ввело в заблуждение то, что у автора «800Мб/с» с графиков - это Мегабит/с.
Исходя из полученного результата, получаетя на 9Тб, действительно, потребуется около 18 часов. А учитывая, что тесты проводились не на продуктовой (а значит, не нагруженной) среде, итоговые значения на проде могут отличаться в худшую сторону.
В первую очередь мы двигались от собственных потребностей, поэтому у нас есть некоторые удобные наработки.
Структура у нас попроще, но наши потребности она закрывает.
Разработка локализована в РФ, можно сказать, что это "импортозамещение", в некотором роде.
В вашем случае нужно отталкиваться от ваших потребностей. Если наш чарт их закрывает, отлично, если нет, вы можете описать ваш запрос в Issue на GitHub и мы постараемся его решить.
По поводу сабчарта . Если речь идёт об использовании в чарте "зонтике", да без проблем можно использовать, собирая необходимый вам набор приложений, включая несколько универсальных для разных прилож.
По поводу лицензии, спокойно можете использовать в коммерческих целях:
Разумеется, Вы можете использовать те инструменты, которые решают Ваши задачи наилучшим образом при минимуме затрат. В случае с Helm он даёт существенно больше возможностей относительно Kustomize, кроме того, Helm мы начали использовать ещё до появления Kustomize. И это именно та причина, по которой у себя в Nixys мы выбрали Helm и готовы мириться с недостатками.
Мы уже попробовали внедрить prometheusrule для джобов, которые выполняются дольше заданного времени, но данный кейс мы широко практикуем в клиентских проектах. Для других, частных случаев часто требуется определённая логика, которая учитывает особенности конкретного проекта. Именно для этого реализован механизм extraDeploy, чтобы можно было добавить необходимые манифесты или шаблоны Helm, включая prometheusrule и hpa, networkpolicy и пр.
В некоторых случаях решение реализованное на отдельном проекте может оказаться удобным в использовании и тогда оно может быть включено в состав чарта "из коробки".
Вы можете предложить свои варианты реализации, вполне может оказаться, что это будет отличное и удобное решение, которое войдёт в состав чарта))
Была такая мысль в тот момент, когда ещё рассматривали варианты нескольких чартов, но т.к. в конечном итоге удалось реализовать даже простые варианты используя только один чарт, то решили оставить всё как есть.
Тут всё сильно зависит от сценария использования Jenkins. Если только сборка и доставка, то похоже, что этот инструмент может быть рассмотрен как замена.
По поводу необходимости читать секреты именно из переменных окружения готов поспорить.
Для большинства приложений и фреймворков без разницы откуда получать данные, более того, большинство «из коробки» именно из файла получает конфиг, а уже потом разработчики прикручивают переменные окружения, с разными параметрами и секретами, просто потому что им так кажется удобней/привычней.
Поэтому, тут скорее вопрос вкусов, кому как больше нравится работать, тот так и делает.
Тут ещё стоило написать про ущербный набор сторадж-классов, поставляемых «из коробки». Например, если кубик многозонный, а вы используете обычные сетевые диски, то они не умеют в миграцию между зонами. Вытеснило под по ресурсам на другую ноду в другой зоне и привет.
Так что нужно быть готовом решать и эту задачу.
Тестировали restic версии 0.12.1.
По поводу повторного запуска и скорости его работы.
Всё зависит от количества изменённых фалов и объёма изменений, но в целом скорость уменьшается не глобально, как минимум потому, что требуется перебрать все файлы. Время в таблице приведено усреднённое после нескольких запусков, первый запуск выполнялся дольше.
По поводу объёма итоговых данных.
Если сравнивать инкрементный бэкап tar и слой/коммит созданный restic, то restic сильно проигрывает. В нашем случае после первого запуска бэкап tar получался порядка 250Мб, у рестик объём полученного каталога сотавил чуть больше 2Гб. Прирост инкремента будет зависеть от объёма данных.
Если рассматривать restic как инструмент используемый исключительно для копий файлов, то, безусловно он отлично справляется со своей задачей. Он реализует классный подход к хранению и, что действительно круто, даёт очень простой способ восстановить файловые данные на нужную дату вообще не напрягаясь.
В нашем случае есть определённые требования, под которые restic, к сожалению, не подходит. Это, в частности, создание копий БД. Отчасти это можно обойти, передавая поток данных в stdin, но это существенно осложняет процесс настройки регулярных бэкапов и, что важнее, восстановления из таких копий.
Резюмируя, сам по себе инструмент интересный и перспективный, но не в наших сценариях работы.
Хорошее замечание, спасибо. Будем думать в этом направлении тоже.
Данная конфигурация дампилась около часа, значит реальная скорость составила около 100Мбайт/с или ~800МБит/с. Думаю, вас ввело в заблуждение то, что у автора «800Мб/с» с графиков - это Мегабит/с.
Исходя из полученного результата, получаетя на 9Тб, действительно, потребуется около 18 часов. А учитывая, что тесты проводились не на продуктовой (а значит, не нагруженной) среде, итоговые значения на проде могут отличаться в худшую сторону.
Спасибо за интересную статью.
Вариант сжатия потока данных при экспорте в пайп в вашем случае не приемлем?
Вопрос субъективный.
В первую очередь мы двигались от собственных потребностей, поэтому у нас есть некоторые удобные наработки.
Структура у нас попроще, но наши потребности она закрывает.
Разработка локализована в РФ, можно сказать, что это "импортозамещение", в некотором роде.
В вашем случае нужно отталкиваться от ваших потребностей. Если наш чарт их закрывает, отлично, если нет, вы можете описать ваш запрос в Issue на GitHub и мы постараемся его решить.
По поводу сабчарта . Если речь идёт об использовании в чарте "зонтике", да без проблем можно использовать, собирая необходимый вам набор приложений, включая несколько универсальных для разных прилож.
По поводу лицензии, спокойно можете использовать в коммерческих целях:
Разумеется, Вы можете использовать те инструменты, которые решают Ваши задачи наилучшим образом при минимуме затрат.
В случае с Helm он даёт существенно больше возможностей относительно Kustomize, кроме того, Helm мы начали использовать ещё до появления Kustomize. И это именно та причина, по которой у себя в Nixys мы выбрали Helm и готовы мириться с недостатками.
Чарт опубликован на GitHub, ссылка есть в статье, продублирую тут https://github.com/nixys/nxs-universal-chart
Благодарю за предложения, мысли верные))
Мы уже попробовали внедрить prometheusrule для джобов, которые выполняются дольше заданного времени, но данный кейс мы широко практикуем в клиентских проектах. Для других, частных случаев часто требуется определённая логика, которая учитывает особенности конкретного проекта. Именно для этого реализован механизм extraDeploy, чтобы можно было добавить необходимые манифесты или шаблоны Helm, включая prometheusrule и hpa, networkpolicy и пр.
В некоторых случаях решение реализованное на отдельном проекте может оказаться удобным в использовании и тогда оно может быть включено в состав чарта "из коробки".
Вы можете предложить свои варианты реализации, вполне может оказаться, что это будет отличное и удобное решение, которое войдёт в состав чарта))
Да
Была такая мысль в тот момент, когда ещё рассматривали варианты нескольких чартов, но т.к. в конечном итоге удалось реализовать даже простые варианты используя только один чарт, то решили оставить всё как есть.
Тут всё сильно зависит от сценария использования Jenkins. Если только сборка и доставка, то похоже, что этот инструмент может быть рассмотрен как замена.
Поделитесь, пожалуйста, в чем именно у вас была проблема?
К сожалению, нет, с 4 всё ок
Для большинства приложений и фреймворков без разницы откуда получать данные, более того, большинство «из коробки» именно из файла получает конфиг, а уже потом разработчики прикручивают переменные окружения, с разными параметрами и секретами, просто потому что им так кажется удобней/привычней.
Поэтому, тут скорее вопрос вкусов, кому как больше нравится работать, тот так и делает.