Не согласен, выше приведенные примеры как раз решают проблему с отображением длинных строк, размещая их в виде списка. А в pq, мы всё также вынуждены все ячейки одной строки, разместить в одной исходной строке. Большой объем содержимого здесь так же нарушит читаемость исходника.
Я уверен, что это ни как не скажется на Андрее, и он по прежнему будет делать мир лучше. Статья всё же не про утилиту, а про таблицы. Да, можно конечно добавить и 4й столбец, но лучше от этого не станет, а вот проблем от этого новых добавит. Как минимум, это потребует описать некий стандарт комментария, что бы описать данные 4-го столбца, и прочие вытекающие последствия.
Вы совершенно верно подметили, в разделе "Форматирование таблицы" я как раз писал про автоматическое форматирование таблиц, а также о негативных последствиях.
Еще можно добавить, что страницы памяти будут выделятся не по требованию, и на каждый экземпляр запущенного приложения будет выделен как минимум объем памяти = размеру бинарника.
Спасибо за ответ, надеюсь в комментариях удастся собрать все плюсы и минусы, а также знающие люди предложат альтернативы, по типу 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 как инсталятор распространяется? Если да, то ваши сертифицированные скрипты деплоят несертифицированное ПО. И в чем тогда суть всей затеи?
Тогда да, спасибо за пояснение, из беглого обзора приведенной выше статьи подумал об обратном.
Не согласен, выше приведенные примеры как раз решают проблему с отображением длинных строк, размещая их в виде списка.
А в pq, мы всё также вынуждены все ячейки одной строки, разместить в одной исходной строке. Большой объем содержимого здесь так же нарушит читаемость исходника.
Я уверен, что это ни как не скажется на Андрее, и он по прежнему будет делать мир лучше.
Статья всё же не про утилиту, а про таблицы. Да, можно конечно добавить и 4й столбец, но лучше от этого не станет, а вот проблем от этого новых добавит. Как минимум, это потребует описать некий стандарт комментария, что бы описать данные 4-го столбца, и прочие вытекающие последствия.
Солидарен с Вами, всегда смотрю, что на самом деле коммичу и всем того же советую. Нужно было придумать какой-то пример похожий на реальный случай.
Вы совершенно верно подметили, в разделе "Форматирование таблицы" я как раз писал про автоматическое форматирование таблиц, а также о негативных последствиях.
Спасибо, исправил.
Сожалею, что раньше не смог добраться добраться с ответом и это породило столько волнений.
вот так работает, еще можно сходить в трекер к разработчику
Спасибо, учту в следующий раз при написании статей.
Взял первый попавшийся под руку образ, ведь итоговый получаем на базе
scratchЕще можно добавить, что страницы памяти будут выделятся не по требованию, и на каждый экземпляр запущенного приложения будет выделен как минимум объем памяти = размеру бинарника.
Спасибо за ответ, надеюсь в комментариях удастся собрать все плюсы и минусы, а также знающие люди предложат альтернативы, по типу Cython, Nuitka, PyOxidizer, py2exe.
И возможно узнаем правду, что же лучше использовать для таких задач, Go, Rust или всё же дальше мучать Python.
Еще могу предложить канал заметками на тему 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 как инсталятор распространяется? Если да, то ваши сертифицированные скрипты деплоят несертифицированное ПО. И в чем тогда суть всей затеи?