Сам искал нечто похожее, крайне заинтересовался этой библиотекой, но, к сожалению, pip install elsie
error: legacy-install-failure
× Encountered error while trying to install package.
╰─> lxml
Для меня остается большой загадкой почему в зависимостях компилируемый пакет. OS: Arch Linux, Python: 3.11, Все upstream Так, что как нибудь в следующий раз. Спасибо.
"Чтобы решить эту проблему, нужно удалять чарт целиком или сделать Helm Rollback: откатить руками релиз на предыдущий. Но это ручные операции, которые ломают автоматизацию на корню."
Попробуйте удалить секрет, хранящий состояние последнего битого релиза и перезапустить Helm. Поды при этом не удаляются, как при удалении всего приложения.
Обычно, когда находят ошибку в рассуждении, дают понять человеку где же именно он ошибся и что в его рассуждениях не верно. Это считается хорошим тоном и уважением к собеседнику. И ни в коем случае не ссылаться на свою же статью, с которой собеседник очевидно не согласен. Я с таким же успехом могу предложить вам перечитать мой коментарий. Вашу статью я прочитал и вынужден заключить, что содержательного подхода там не содержиться, по крайней мере для меня. В любом случае, вы имеете право на свое мнение.
А теперь по существу. Вы действительно думаете, что раз данные определения и принципы не эволюционируют, не изменяются, и не обретают порой иное, иногда даже противоположное изначальному содержание?
Вам привели в коментариях пример FluxCD Image Automation controller, где слепое следование принципу Single Source of State приводит к абсурду и я не вижу причин разворачивать это еще больше. Считать за истину этот принцип сегодня может только тот, кто не работает с реальными системами в боевых окружениях и не понимает всю возникающую проблематику и ньюансы. Уже почти все интерпретируют GitOps шире и не загоняют сами себя в ненужные рамки, прикрываясь устаревшими понятиями. Хотя нужно признать, что одно это не делает эти понятия плохими. В свое время они являлись важными вехами в становлении и развитии нашей профессии. Вы цепляетесь за устаревшую концепцию и, указывая на это, хотите доказать, что она не работает. Но дело в том, что практическая деятельность уже давно решила эту проблему и сегодня никто уже не использует GitOps в контексте "Гит как единственный источник правды", только если он по какой то причине не продолжает цепляться за догмы. Ибо не нужно.
Спасибо за статью, но у нее есть один существенный недостаток. Она не отвечает на тот вопрос, который выносит в заголовок.
Создается впечатление, что вы пытаетесь понять что такое GitOps, но сами для себя не можете это сделать. На мой взгляд это происходит потому, что вы изначально ограничиваете себя только техническими соображениями и не допускаете, что причиной может выступать что то еще. Технические детали важны и технические соображения приведенные вами верны, но в данном случае они не являются существенными.
GitOps, как и микросервисная архитектура, появились и быстро закрепились в индустрии потому, что решают управленческую задачу. Они позволяют создать в компании условия, при которых технические границы повторяют границы административные, разграничивая ответственность между отдельными командами и даже отдельными людьми. Как следствие, достигаются несколько целей. Например, снижается сложность управления людьми, а так же повышается прозрачность процессов. Что в итоге при правильном использовании выражается в деньгах.
Если быть конкретным, GitOps позволяет рассматривать процесс CI/CD как два независимых процесса, с разными зонами ответственности. И тем самым решить извечную боль всех сисадминов и программистов, когда вторым через систему автоматизации постоянно необходимо так или иначе предоставлять администраторский доступ к продакшену. Даже если это происходит не явно, границы ответственности тут несколько размыты и не могут быть жестко проведены. Используя GitOps, мы имеем отдельно CI процесс и отдельно CD процесс, причем их можно рассматривать как различные и не связанные во времени и пространстве. Команда эксплуатации и инфраструктуры, которая отвечает за Kubernetes, может спать спокойно не опасаясь, что кто то скопировав из системы автоматизации токен начнет "только на пять минут, очень надо" производить миграцию базы данных, менять конфигурацию системы и так далее. Причем это изменение никак в коде не отразится и о нем никак узнать будет нельзя.
Вы правы, только стоит добавить, что проработка архитектуры это никогда не завершающийся процесс. Один раз проработать архитектуру и забыть, увы, не получится.
В вашем определении сложность сугубо субьективна. У джуна она будет одна, у сеньора, корый посвящен в то, что рассматриваемый обьект парабола, другая. С таким определением сложно что либо сделать, кроме как сказать, что сложность есть, и более ничего.
Я понял вашу аналогию, позвольте дать другую. Есть программа для сжатия данных. Текст до сжатия занимает один мегабайт, после сжатия 100 килобайт. Учитывая, что современные алгоритмы пытаются учитывать не только универсальные свойства текста, но еще и его специфические особенности, эти 100 килобайт находятся очень близко к теоретическому пределу, к информации системы по Шеннону. В вашем примере, зная специфическую природу данных, эта информация свелась к 3 параметрам.
Так и сервис. Представим, что для конфигурации нашего сервиса можно задать 5 переменных, каждая из которых может находиться в 10 состояниях. Тогда, сервис имеет 10^5 состояний, каждое из которых уникально и может иметь свои побочные эффекты и особенности. Эти состояния(вернее его логарифм по степени 2) и есть энтропия системы, та мера хаоса, призванная оценить пространство возможных конфигураций. Возможных, так как сервис как правило будет находиться в одном из них в конкретный момент времени. Инженеру, как правило, эти состояния доступны и не скрыты. Заметим, что при таком определении сложность сугубо обьективна.
Проблема в другом. В том, что приходит задача поддержать некую фичу, которая нашей архитектурой не поддерживается. Вместо того, что бы менять архитектуру, вводится еще один параметр, где активируется фича - true или false. Таким образом, пространсво состояний умножается на два, а энтропия увеличивается на единицу. Такая система стала сложнее хотя бы потому, что разработчикам необходимо теперь учитывать при работе еще одну степень свободы, тестировать ее, что в масштабах большой системы невозможно. Поэтому, теряется контроль над системой, так как абстракций ее описывающих стало больше.
Прошу прощения за скомканный стиль, в коментариях тяжело подробно развертывать свою мысль.
Вы справедливо указали на то, что такое решение возвращает нас к необходимости жестко соблюдать модульность. В статье речь идет о компромисе, позволяющем не скатываться в крайности, но и сохраняющем при этом их недостатки. Насчет схем в PostgreSQL полностью согласен, не упомянул их только из за того, что не хотел привязываться к конкретному програмному решению. Не все базы данных такое поддерживают.
Что качается использованию разных портов для разных сервисов, это интересная идея. Я не думал об этом. Единственным припятствием к реализации такого решения вижу в отсутствии многопоточности. Что если используется однопоточный Python сервис, где нет возможности в подобном разделении? Хотя, это всего лишь догадка, необходимо поизучать эту тему.
Полностью согласен. Вы практически сформулировали второй закон термодинамики применительно к информационным системам. В лучшем случае энтропия системы не растет, но при небрежном разбитии на микросервисы, неоптимальном дизайне и прочих других факторах сложность будет только увеличиваться.
Позволю себе написать свое мнение по этому вопросу.
Все современное образование, как и производство, заточено под принцип разделения труда. В реальности математика в 99 процентах профессий не нужна, нужен конкретный список навыков.
Но ни в коем случае, если вы не хотите стать заложником своего диплома, не игнорируйте математику. Изучайте ее по максимуму, даже сферх того чему учат в академии. Математика расширяет кругозор, приобщает человека к лучшим достижениям человеческой мысли и тренирует мозги. Гораздо лучше и эффективней, чем это делает что либо другое. Если вы думаете, что using namespace std; это сложно, то спешу вас разуверить - сложности у этого совсем нет. Есть неправильно поставленный учебный процесс.
Современные вузы попали в ловушку. С одной стороны классическое образование должно давать фундаментальные знания, с другой рыночек порешал эту инициативу и все что не продается здесь и сейчас урезается. Так что мне искренне жаль, что вам и тысячам других студентов приходится получать образование в такой ситуации. Но это не мешает вам не впадать в заблужение и стараться изучать профессию не в глубь, а в ширь. Если вам когда либо придется заниматься задачами, которые требуют не использования готового фреймворка или библиотеки, а самостоятельной и творческой работы, без математики и понимания азов в смежных с программированием областях никуда.
И самое главное, подстраиваться под рынок труда и быть более релевантным для работодателя гораздо проще, когда обладаешь широким кругозором. Иначе, можно стать историей вместе с устареванием вашей области знаний.
Сегодня редко кто использует сам чистый TeX, хотя фанаты такого подхода все еще присутсвуют. Появился он в 1974 году, это правда. А вот LaTeX уже гораздо популярнее и всего 1984-й год, ровесник проекта GNU. А сегодня, зачастую, те, кто работает с этой технологией использует программы вроде LyX. А это уже 1995-й год. И развивается все это до сих пор. Так что "кто на ком стоял" это еще хороший вопрос.
Был ли .Net кроссплатформенным с самого начала или стал таким под давлением рынка свободного програмного обеспечения?
Git и TeX даны мной как пример технологий, которые не появились бы без Linux и того положительного вклада, который он принес. Они в полной мере отражают его подход к разработке ПО. То, что технологии кроссплатформенны это, конечно, замечательно.
systemd конечно относительно нов, я не мог об этом не знать. Я включил его как пример тех программ, которые наиболее часто вызывают негативную реакцию и отторжение у людей.
Действительно, это одна из причин. При написании статьи упустил этот аргумент из виду, так как сосредоточился на других аспектах.
Но лично мне не очень понятно как тогда быть с youtube, где некоторые весьма талантливые граждане имеют доступ к миллионной аудитории и активно этим пользуются, в том числе для откровенно политических акций. Не слышал что бы подобную линию рассуждений применяли к этому ресурсу, 3000 подписчиков это вообще ни о чем. Хотя возможно все еще впереди.
Спасибо за замечание, совершенно справедливо. Конечно же речь идет в первую очередь о Telegram, «у любого другого современного мессенджера» слишком сильное утверждение в этом контексте. Если мы, например, возьмем WhatsApp, то они утверждают, что весь их сервис защищен сквозным шифрованием.
Однако,
на этой же странице они пишут о том, что готовы сотрудничать с любыми органами безопасности
код мобильного клиента WhatsApp не открыт. Поэтому действительно ли переписка защищена остается открытым.
Из моего скромного опыта любой продукт корпоративного уровня со временем превращается в жуткое мессиво из старых и новых API, подпорок и заглушек. И что еще хуже, не документированных отладочных возможностей. Кто гарантирует, что соблюдены все требования безопасности хотя бы на уровне клиента, не говоря уже о сервер-сайд?
WhatsApp постоянно норовит предложить делать бекапы. Стоит нажать не на ту кнопку и вся переписка слита и никакое сквозное шифрование не поможет.
Сам искал нечто похожее, крайне заинтересовался этой библиотекой, но, к сожалению,
pip install elsie
Для меня остается большой загадкой почему в зависимостях компилируемый пакет.
OS: Arch Linux, Python: 3.11, Все upstream
Так, что как нибудь в следующий раз. Спасибо.
"Чтобы решить эту проблему, нужно удалять чарт целиком или сделать Helm Rollback: откатить руками релиз на предыдущий. Но это ручные операции, которые ломают автоматизацию на корню."
Попробуйте удалить секрет, хранящий состояние последнего битого релиза и перезапустить Helm. Поды при этом не удаляются, как при удалении всего приложения.
Обычно, когда находят ошибку в рассуждении, дают понять человеку где же именно он ошибся и что в его рассуждениях не верно. Это считается хорошим тоном и уважением к собеседнику. И ни в коем случае не ссылаться на свою же статью, с которой собеседник очевидно не согласен. Я с таким же успехом могу предложить вам перечитать мой коментарий. Вашу статью я прочитал и вынужден заключить, что содержательного подхода там не содержиться, по крайней мере для меня. В любом случае, вы имеете право на свое мнение.
А теперь по существу. Вы действительно думаете, что раз данные определения и принципы не эволюционируют, не изменяются, и не обретают порой иное, иногда даже противоположное изначальному содержание?
Вам привели в коментариях пример FluxCD Image Automation controller, где слепое следование принципу Single Source of State приводит к абсурду и я не вижу причин разворачивать это еще больше. Считать за истину этот принцип сегодня может только тот, кто не работает с реальными системами в боевых окружениях и не понимает всю возникающую проблематику и ньюансы. Уже почти все интерпретируют GitOps шире и не загоняют сами себя в ненужные рамки, прикрываясь устаревшими понятиями. Хотя нужно признать, что одно это не делает эти понятия плохими. В свое время они являлись важными вехами в становлении и развитии нашей профессии. Вы цепляетесь за устаревшую концепцию и, указывая на это, хотите доказать, что она не работает. Но дело в том, что практическая деятельность уже давно решила эту проблему и сегодня никто уже не использует GitOps в контексте "Гит как единственный источник правды", только если он по какой то причине не продолжает цепляться за догмы. Ибо не нужно.
Спасибо за статью, но у нее есть один существенный недостаток. Она не отвечает на тот вопрос, который выносит в заголовок.
Создается впечатление, что вы пытаетесь понять что такое GitOps, но сами для себя не можете это сделать. На мой взгляд это происходит потому, что вы изначально ограничиваете себя только техническими соображениями и не допускаете, что причиной может выступать что то еще. Технические детали важны и технические соображения приведенные вами верны, но в данном случае они не являются существенными.
GitOps, как и микросервисная архитектура, появились и быстро закрепились в индустрии потому, что решают управленческую задачу. Они позволяют создать в компании условия, при которых технические границы повторяют границы административные, разграничивая ответственность между отдельными командами и даже отдельными людьми. Как следствие, достигаются несколько целей. Например, снижается сложность управления людьми, а так же повышается прозрачность процессов. Что в итоге при правильном использовании выражается в деньгах.
Если быть конкретным, GitOps позволяет рассматривать процесс CI/CD как два независимых процесса, с разными зонами ответственности. И тем самым решить извечную боль всех сисадминов и программистов, когда вторым через систему автоматизации постоянно необходимо так или иначе предоставлять администраторский доступ к продакшену. Даже если это происходит не явно, границы ответственности тут несколько размыты и не могут быть жестко проведены. Используя GitOps, мы имеем отдельно CI процесс и отдельно CD процесс, причем их можно рассматривать как различные и не связанные во времени и пространстве. Команда эксплуатации и инфраструктуры, которая отвечает за Kubernetes, может спать спокойно не опасаясь, что кто то скопировав из системы автоматизации токен начнет "только на пять минут, очень надо" производить миграцию базы данных, менять конфигурацию системы и так далее. Причем это изменение никак в коде не отразится и о нем никак узнать будет нельзя.
Попробуйте подобным образом поиследовать и нарисовать логистическое отображение, это гораздо интереснее чем треугольник Серпинского
https://ru.wikipedia.org/wiki/Логистическое_отображение
Крайне приятно встретить в сети конспект по своему видео на Youtube трехлетней давности.
Вы правы, только стоит добавить, что проработка архитектуры это никогда не завершающийся процесс. Один раз проработать архитектуру и забыть, увы, не получится.
В вашем определении сложность сугубо субьективна. У джуна она будет одна, у сеньора, корый посвящен в то, что рассматриваемый обьект парабола, другая. С таким определением сложно что либо сделать, кроме как сказать, что сложность есть, и более ничего.
Я понял вашу аналогию, позвольте дать другую. Есть программа для сжатия данных. Текст до сжатия занимает один мегабайт, после сжатия 100 килобайт. Учитывая, что современные алгоритмы пытаются учитывать не только универсальные свойства текста, но еще и его специфические особенности, эти 100 килобайт находятся очень близко к теоретическому пределу, к информации системы по Шеннону. В вашем примере, зная специфическую природу данных, эта информация свелась к 3 параметрам.
Так и сервис. Представим, что для конфигурации нашего сервиса можно задать 5 переменных, каждая из которых может находиться в 10 состояниях. Тогда, сервис имеет 10^5 состояний, каждое из которых уникально и может иметь свои побочные эффекты и особенности. Эти состояния(вернее его логарифм по степени 2) и есть энтропия системы, та мера хаоса, призванная оценить пространство возможных конфигураций. Возможных, так как сервис как правило будет находиться в одном из них в конкретный момент времени. Инженеру, как правило, эти состояния доступны и не скрыты. Заметим, что при таком определении сложность сугубо обьективна.
Проблема в другом. В том, что приходит задача поддержать некую фичу, которая нашей архитектурой не поддерживается. Вместо того, что бы менять архитектуру, вводится еще один параметр, где активируется фича - true или false. Таким образом, пространсво состояний умножается на два, а энтропия увеличивается на единицу. Такая система стала сложнее хотя бы потому, что разработчикам необходимо теперь учитывать при работе еще одну степень свободы, тестировать ее, что в масштабах большой системы невозможно. Поэтому, теряется контроль над системой, так как абстракций ее описывающих стало больше.
Прошу прощения за скомканный стиль, в коментариях тяжело подробно развертывать свою мысль.
Вы справедливо указали на то, что такое решение возвращает нас к необходимости жестко соблюдать модульность. В статье речь идет о компромисе, позволяющем не скатываться в крайности, но и сохраняющем при этом их недостатки.
Насчет схем в PostgreSQL полностью согласен, не упомянул их только из за того, что не хотел привязываться к конкретному програмному решению. Не все базы данных такое поддерживают.
Что качается использованию разных портов для разных сервисов, это интересная идея. Я не думал об этом. Единственным припятствием к реализации такого решения вижу в отсутствии многопоточности. Что если используется однопоточный Python сервис, где нет возможности в подобном разделении? Хотя, это всего лишь догадка, необходимо поизучать эту тему.
Полностью согласен. Вы практически сформулировали второй закон термодинамики применительно к информационным системам. В лучшем случае энтропия системы не растет, но при небрежном разбитии на микросервисы, неоптимальном дизайне и прочих других факторах сложность будет только увеличиваться.
Позволю себе написать свое мнение по этому вопросу.
Все современное образование, как и производство, заточено под принцип разделения труда. В реальности математика в 99 процентах профессий не нужна, нужен конкретный список навыков.
Но ни в коем случае, если вы не хотите стать заложником своего диплома, не игнорируйте математику. Изучайте ее по максимуму, даже сферх того чему учат в академии. Математика расширяет кругозор, приобщает человека к лучшим достижениям человеческой мысли и тренирует мозги. Гораздо лучше и эффективней, чем это делает что либо другое. Если вы думаете, что using namespace std; это сложно, то спешу вас разуверить - сложности у этого совсем нет. Есть неправильно поставленный учебный процесс.
Современные вузы попали в ловушку. С одной стороны классическое образование должно давать фундаментальные знания, с другой рыночек порешал эту инициативу и все что не продается здесь и сейчас урезается. Так что мне искренне жаль, что вам и тысячам других студентов приходится получать образование в такой ситуации. Но это не мешает вам не впадать в заблужение и стараться изучать профессию не в глубь, а в ширь. Если вам когда либо придется заниматься задачами, которые требуют не использования готового фреймворка или библиотеки, а самостоятельной и творческой работы, без математики и понимания азов в смежных с программированием областях никуда.
И самое главное, подстраиваться под рынок труда и быть более релевантным для работодателя гораздо проще, когда обладаешь широким кругозором. Иначе, можно стать историей вместе с устареванием вашей области знаний.
Все так, только не забывайте, что с таким подходом придется платить деньги. И не вы будете решать сколько.
Я писал о том, что .Net доступен для Linux когда говорил про Mono.
Выше уже спрашивали про TeX и про 1974 год.
То, что вы процитировали это утверждение от обратного. Как бы то, с чем я не согласен. Из контекста предложения видно.
Насчет systemd нужно сказать "спасибо" RedHat. Очень многим это не понравилось и их можно понять. Хотя systemd был определенным шагом вперед.
В любом случае спасибо вам за конструктивную критику.
Сегодня редко кто использует сам чистый TeX, хотя фанаты такого подхода все еще присутсвуют. Появился он в 1974 году, это правда. А вот LaTeX уже гораздо популярнее и всего 1984-й год, ровесник проекта GNU. А сегодня, зачастую, те, кто работает с этой технологией использует программы вроде LyX. А это уже 1995-й год. И развивается все это до сих пор. Так что "кто на ком стоял" это еще хороший вопрос.
Был ли .Net кроссплатформенным с самого начала или стал таким под давлением рынка свободного програмного обеспечения?
Git и TeX даны мной как пример технологий, которые не появились бы без Linux и того положительного вклада, который он принес. Они в полной мере отражают его подход к разработке ПО. То, что технологии кроссплатформенны это, конечно, замечательно.
systemd конечно относительно нов, я не мог об этом не знать. Я включил его как пример тех программ, которые наиболее часто вызывают негативную реакцию и отторжение у людей.
Но лично мне не очень понятно как тогда быть с youtube, где некоторые весьма талантливые граждане имеют доступ к миллионной аудитории и активно этим пользуются, в том числе для откровенно политических акций. Не слышал что бы подобную линию рассуждений применяли к этому ресурсу, 3000 подписчиков это вообще ни о чем. Хотя возможно все еще впереди.
Однако,
А так да, мне нечего скрывать и я использую WhatsApp.