Еще можно добавить, что страницы памяти будут выделятся не по требованию, и на каждый экземпляр запущенного приложения будет выделен как минимум объем памяти = размеру бинарника.
Спасибо за ответ, надеюсь в комментариях удастся собрать все плюсы и минусы, а также знающие люди предложат альтернативы, по типу Cython, Nuitka, PyOxidizer, py2exe.
И возможно узнаем правду, что же лучше использовать для таких задач, Go, Rust или всё же дальше мучать Python.
Спасибо, русские имена файлов не тестировал, завел на это дело себе заметку.
Что касаемо моделей в формате *.archimate - данный механизм и не планировался, ведь какой смысл хранить один постоянно изменяемый файл в SCM? Теряется возможность коллективной работы и возможность выборочно управлять изменениями. По этому работает только с coArchi моделями, возможно я ошибаюсь, и стоит дать возможность работать с стандартными файлами моделей?
Да ничего особенного, если есть инцедент в ход идет bash или python на которм подсчитываю нужные метрики или gnuplot строит график. Благо нужно это не часто, но готового решения нет, всё как-то руки не доходят.
Exporter хороший, но к сожалению не вывозит графана десятки тысяч сборочных заданий на одном дашборде. Как я его не крутил, шардил неймспейсы, только релизные теги и мастер бранчи в статистику публиковал. Всё равно работает с большим объемом очень плохо. Да и нагрузку на API GitLab недурную создает.
По итогу имею полтора десятка упрощенных дашбордов, для определенных тегов. В таком режиме хоть как-то могу наблюдать за состоянием сборок, но увы страдает юзабилити.
Найти готового коробочного решения для больших объемов к сожалению не удалось пока, использую костыли.
Потому что если образ с докерхаба удалили, а мы им пользуемся, то если он исчезнет из кэша - мы получим неработоспособную систему (образа-то нет!)
Так он и не удалится, если мы не делали ротацию старого кеша или не настроили чего-то дополнительно для обраотки удаленных образов.
Касаемо latest, мне кажется это выбор каждого, и если мы указали postgres:13.5-bullseye за место postgres:13 , значит мы пошли на это осознанно, и кешем стандартный механиз поставки не нарушаем. Иначе могут возникнуть вопросы - "а почему мой latest не latest?".
Для жёсткой фиксации на версии, всегда можно указать конкретный манифест:
Не спорю, что в статье приведено нишевое решение, если абстрагироваться от облаков, в случае on-premise решений, особенно в совокупности таких факторов как: закрытый контур, строгая политика ИБ и медленный интернет канал, проксирование очень даже упрощает и ускоряет дистрибьюцию.
если образ удалили или подменили в удаленном регистри, то кэш тут может не помочь
Если подменили, то всё будет хорошо, прокси в первую очередь валидирует метаданные, сверяет их с удаленным реестром контейнеров, и только если изменений нет (или сервер не ответил) мы получим данные из кеша. Касаемо удаления, это вопрос хороший, в Nexus знаю есть отдельная опция для обработки и кеширования 404, а в Distrubution кеш для удаленного образа, скорее всего продолжит своё существование. В любом случае, для кеша полезно делать отдельную задачу в планировщике, для удаления старых и неиспользуемых образов, что от части решает вопрос удаления.
можно написать mutation webhook
А можно не писать, используя CRI-O/Podman и конфигурацию registries.conf :)
Мне кажется идея с mutation webhook для image может нарушить работу keel.sh и подобных решений, но это не точно, нужно проверять на практике.
Что еще мне не понравилось в конфигурации CRI - то, что это нужен полный доступ к узлам. А если дело происходит в облаке и нет возможности менять конфиги на узлах кубернетес кластера?
Подскажите, а как вы изменяете конфиги containerd на узлах где нет возможности их изменять?
А еще меня удивила стрелочка на диаграмме от Flux/Argo к podman.
А вы внимательный :)
Даже не знаю как она там оказалась, видимо это всё мои мечты под впечатлением новости, что podman теперь умеет не только Pod запускать но и Deployment.
Спасибо, ссылку на бесплатный container-registry в статью добавил, а вот рассматривать Artifactory не стал, также как и Quay, я посчитал, что это будет избыточно, достаточно упоминания в сравнении и ссылки на руководство.
Deckhouse включен в реестр как первое решение для контейнеризации, означает ли это, что все используемые вами компоненты, такие как: kubernetes, container.d, prometheus, dex и прочие, также автоматически стали внесены в реестр?
Или это только на сам Deckhouse как инсталятор распространяется? Если да, то ваши сертифицированные скрипты деплоят несертифицированное ПО. И в чем тогда суть всей затеи?
Именно картинки вы не получите, а скорее набор html+svg, если нужна именно png или jpg для конкретной схемы, вам подойдёт или jArchi который упомянут был немного выше, или какой нибудь bash однострочник для поиска нужной svg в файлах экспорта и последующей конвертации в нужный формат.
Круто, я вот всё подумываю купить себе сумеречную борьбу, останавливает только мысль, что будет она пылиться и опонента я так себе и не найду. Может быть это всё эффект от комментариев к посту на пикабу, и не всё так плохо.
вот так работает, еще можно сходить в трекер к разработчику
Спасибо, учту в следующий раз при написании статей.
Взял первый попавшийся под руку образ, ведь итоговый получаем на базе
scratch
Еще можно добавить, что страницы памяти будут выделятся не по требованию, и на каждый экземпляр запущенного приложения будет выделен как минимум объем памяти = размеру бинарника.
Спасибо за ответ, надеюсь в комментариях удастся собрать все плюсы и минусы, а также знающие люди предложат альтернативы, по типу Cython, Nuitka, PyOxidizer, py2exe.
И возможно узнаем правду, что же лучше использовать для таких задач, Go, Rust или всё же дальше мучать Python.
В тему TLS сертификатов, а все готовы начать распечатывать сертификаты и отправлять их Почтой Росии.
Как вам такая альтернатива, для ACME DNS Chalange?
Подробнее:
https://tlsgost.ru/index3.html
https://tlsca.cryptopro.ru/tls-dist.htm
Еще могу предложить канал заметками на тему DevOps/SRE https://t.me/devops_su
Спасибо, русские имена файлов не тестировал, завел на это дело себе заметку.
Что касаемо моделей в формате
*.archimate
- данный механизм и не планировался, ведь какой смысл хранить один постоянно изменяемый файл в SCM? Теряется возможность коллективной работы и возможность выборочно управлять изменениями. По этому работает только с coArchi моделями, возможно я ошибаюсь, и стоит дать возможность работать с стандартными файлами моделей?Да ничего особенного, если есть инцедент в ход идет bash или python на которм подсчитываю нужные метрики или gnuplot строит график. Благо нужно это не часто, но готового решения нет, всё как-то руки не доходят.
Exporter хороший, но к сожалению не вывозит графана десятки тысяч сборочных заданий на одном дашборде. Как я его не крутил, шардил неймспейсы, только релизные теги и мастер бранчи в статистику публиковал. Всё равно работает с большим объемом очень плохо. Да и нагрузку на API GitLab недурную создает.
По итогу имею полтора десятка упрощенных дашбордов, для определенных тегов. В таком режиме хоть как-то могу наблюдать за состоянием сборок, но увы страдает юзабилити.
Найти готового коробочного решения для больших объемов к сожалению не удалось пока, использую костыли.
Так он и не удалится, если мы не делали ротацию старого кеша или не настроили чего-то дополнительно для обраотки удаленных образов.
Касаемо
latest
, мне кажется это выбор каждого, и если мы указалиpostgres:13.5-bullseye
за местоpostgres:13
, значит мы пошли на это осознанно, и кешем стандартный механиз поставки не нарушаем. Иначе могут возникнуть вопросы - "а почему мой latest не latest?".Для жёсткой фиксации на версии, всегда можно указать конкретный манифест:
И в правду, скорее моя невнимательность.
Вот тоже подумал про DaemonSet и HostPath, благо ни разу не оказывался в такой ситуации и ноды подконтрольны мне.
Не спорю, что в статье приведено нишевое решение, если абстрагироваться от облаков, в случае on-premise решений, особенно в совокупности таких факторов как: закрытый контур, строгая политика ИБ и медленный интернет канал, проксирование очень даже упрощает и ускоряет дистрибьюцию.
Если подменили, то всё будет хорошо, прокси в первую очередь валидирует метаданные, сверяет их с удаленным реестром контейнеров, и только если изменений нет (или сервер не ответил) мы получим данные из кеша. Касаемо удаления, это вопрос хороший, в Nexus знаю есть отдельная опция для обработки и кеширования 404, а в Distrubution кеш для удаленного образа, скорее всего продолжит своё существование. В любом случае, для кеша полезно делать отдельную задачу в планировщике, для удаления старых и неиспользуемых образов, что от части решает вопрос удаления.
А можно не писать, используя CRI-O/Podman и конфигурацию registries.conf :)
Мне кажется идея с mutation webhook для image может нарушить работу keel.sh и подобных решений, но это не точно, нужно проверять на практике.
Подскажите, а как вы изменяете конфиги containerd на узлах где нет возможности их изменять?
А вы внимательный :)
Даже не знаю как она там оказалась, видимо это всё мои мечты под впечатлением новости, что podman теперь умеет не только Pod запускать но и Deployment.
Спасибо, ссылку на бесплатный container-registry в статью добавил, а вот рассматривать Artifactory не стал, также как и Quay, я посчитал, что это будет избыточно, достаточно упоминания в сравнении и ссылки на руководство.
Deckhouse включен в реестр как первое решение для контейнеризации, означает ли это, что все используемые вами компоненты, такие как: kubernetes, container.d, prometheus, dex и прочие, также автоматически стали внесены в реестр?
Или это только на сам Deckhouse как инсталятор распространяется? Если да, то ваши сертифицированные скрипты деплоят несертифицированное ПО. И в чем тогда суть всей затеи?
Да, две стороны конфликта, штаты и союз. Но вам ни кто не запрещает, сесть по три человека с каждой стороны и совместно продумывать тактику.
Именно картинки вы не получите, а скорее набор html+svg, если нужна именно png или jpg для конкретной схемы, вам подойдёт или jArchi который упомянут был немного выше, или какой нибудь bash однострочник для поиска нужной svg в файлах экспорта и последующей конвертации в нужный формат.
Я упомяну Вас, могу и в ЛС для уверенности написать.
Круто, я вот всё подумываю купить себе сумеречную борьбу, останавливает только мысль, что будет она пылиться и опонента я так себе и не найду. Может быть это всё эффект от комментариев к посту на пикабу, и не всё так плохо.
Я попробую сделать это, как только появится на это свободное время. Сами понимаете, пред новогодняя суета дома и на работе.