Это называется сатира. На самом деле это не просто соблюсти хронологию развития всяких *Ops и умудриться сделать в актуальном ключе (описанная история не совсем выдумка).
Не надо использовать Makefile в экосистеме Python, если только вы не пишете чистые C-API модули без зависимостей и т.д. И даже тогда не надо этого делать...
Есть прекрасный инструмент tox, который не только покрывает возможности Makefile, но и значительно обогащает его питонячьими плюшками (например, под каждую зависимость можно загнать свой набор зависимостей, собирать разом под несколько версий питона, сделать aio/all-in-one окружения, с учётом особенностей).
Makefile на фоне tox'а выглядит бедно, но это не так. Просто это гибкий инструмент для совершенно иной экосистемы.
Обычно разработчиков/админов 1С меньше чем пользователей, поэтому логичнее делать как удобнее пользователям.
Конфигурации, которые не поддерживают ws уже практически вымерли. Новые проекты точно на них не стоит делать, а старые скоро все перейдут.
Насчёт геморроя с Postgres поддерживаю, но как ниже сказали: вся статья набор антипаттернов и костылей. Поэтому мне интересно стало, почему не поднять всё на условной ubuntu server 22.04 с репой pgpro и 1C+ws(apache2.4)? Проще в обслуживании уже некуда.
Для ws нулевая настройка рабочих мест. Браузер есть абсолютно везде. Или просто так появились всякие Nextcloud/OwnCloud/Onlyoffice/etc. К тому же http экономичнее по трафику и быстрее. Разрешать и запрещать нужно только один порт. Куда проще?
Я когда в магазинах RDP на кассе вижу и как продавцы рыдают, так прям сердце разрывается. И что, никто на местах ничего не настраивает? Ещё как настраивают.
Мне кажется самая фишка этой статьи в описании реализации терминального сервера на свободных компонентах. Но вообще многое решается проще, если брать нужную ось и готовые пакеты.
Но непонятно чем не угодил ws с апачем? Хорошо работает, не требует иксов, пользователю окружение не нужно костылять (браузер есть и поехали), https с кучей заголовков для безопасности, brotli+gzip для экономии трафика. Уже даже видел драйвер для подключения ккм через http. Почему все возятся с терминалом?
Считаю ужасной практикой в livenessProbe делать http-запросы. Это проверка, что контейнер не зомби, т.е. запущены нужные процессы. Эту проверку надо делать максимально часто, чтобы мёртвый процесс действительно мёртв был. И эта проверка не должна ни в коем случае зависеть от нагрузки и сокетов. А то получится, что у вас нагрузка выросла и контейнер делает себе харакири. В итоге на другие распределяется нагрузка, и они тоже делают себе харакири. Кластер лежит, пользователи недоумевают, CTO порет ремнем SRE - такая себе картина.
Для readinessProbe это нормально и если сильно нагрузка бахнула, то они действительно могут и должны на время выпасть из обмена, пока не переварят. Такую проверку можно делать реже, чтоб тоже не загадить подключения. Но эта проверка действительно будет делать то, что нужно - проверять, что сервис может принимать подключения и обрабатывать их.
Например, в приведённом деплойменте nginx, можно было бы проверить наличие процесса nginx для проверки жизни в контейнере, что прям сложность O(1) имеет. Тогда период можно в одну секунду поставить, чтоб мгновенно пезагрузить. А читабельность оставить как есть. Но для Cloud Native лучше livenessProbe отдельно реализовывать: проверять, что нужный процесс не просто запущен, но имеется активность внутри. Если это какой-то циклический обработчик, то можно писать файлик (даже пустой) и проверять время последнего изменения.
Вы предлагаете дважды делать эту проверку или реализовать функционал, при котором в словаре можно будет бросать исключение при наличии ключа?
В любом случае это нафиг никому не нужно, поэтому никто не хочет усложнять код и синтаксис. Единственное, где это могло бы пригодиться - mypy. Но и тут это не нужно никому видимо.
Получилась бы сомнительная польза в ущерб производительности. Словарь в Python'е одна из самых проблемных и медленных сущностей, но на ней держится вся логика переменных. Каждая такая проверка замедлила бы код минимум процентов на 20-30%.
Единственный вариант, как я вижу, если и делать такую проверку, то с помощью mypy. Но кмк это просто никому не нужно, поэтому никто и не делает. Да и, опять же, кмк это только усложнило бы читабельность.
Остаются ручные тесты на дев, или таки есть варианты получше?!
Если говорить про результаты, то возможно testinfra, которая проверяет уже сам результат выкатки. Но это прям узкая часть.
Вот про боль со вводом стейджинга - не понял. Если речь про пайплайны, то как и зачем им отличаться от прод окружений с технической точки зрения? С коротко-живущими еще понятно..
Иногда с короткоживущими даже проще. Яркий пример из практики. Инфраструктура на проде у определённого проекта 60-80к облачных денег в месяц, а на тестовом сервере в подсобке - 0к/мес (ну фиг с ним, купим PC под нужды за 100к). Пример утрированный, но у условного облака один набор инструментов CD, а у стейджинга допустим этого нет (причин может быть больше, почему нет).
Если с короткоживущими можно поднять и опустить окружение потратив ресурсы за час, то стейджинг это условная "песочница", которая работает постоянно.
Вы как-то упрощаете. В субчартах уже нельзя использовать, для реализации внутренних услуг тоже в очень редких случаях подойдёт. Вообще советую разобраться с лицензией, потому что для вас она тоже вносит ограничения (либо контрибьютить вам должны с MIT). Вы зря минусите, лучше бы текст почитали. В РФ сейчас он конечно мало смысла имеет, хотя тут от судьи зависит. Не просто так LGPL придумали.
Выглядит достойно для тех, кто любит минимизировать ручной труд. А как универсальный чарт работает в качестве сабчарта?
Единственное чего я не понял, так это GPLv3. Потому что использование в коммерческих целях практически не возможно легально (к слову об субчартах) да и мало кто захочет с GPL связываться в принципе. Ну и для вас профита не понимаю. Можете объяснить?
А чем Cobbler не подошёл? Он ещё и репы в себе может держать (и обновлять), установка и настройка через кикстарт и подобные. Тот же Ubuntu MAAS тоже можно, но это больше про сервера. Зачем насиловать форточками пингвина?
Спасибо за развёрнутый комментарий и советы. Приятно получать такие комментарии как и дельные советы.
Руки не доходят. Вообще хочу прям лютую магию сделать на Cython или на крайний случай C-API, с ленивой инициализацией некоторых компонентов. Для некоторых кейсов это было бы очень полезно. Но в целом разбить на части нужно, просто нежно. Думаю так же сделать сам конфиг plug-able, чтобы какие-то части просто менять, а не делать ужасный import.
settings.ini ещё как используется. Может я вас не так понял, но именно им конфиг и настраивается. Если вы про тот, что в корне проекта, то да - его тоже надо доработать и возможно туда default values вынести. Рефакторинг большой я запланировал на следующий мажорный релиз, потому что надо будет убрать ооооочень много legacy.
Зачем? Команда tox в корне проекта прекрасно работает. Кому надо, те могут это сделать. Мы пользы от этого не увидели (хотя бы потому что тесты не сильно быстрые, а грузят проц весьма), потому что у нас всё в CI проверяется и культура выстроена на git flow (сокращённый для этого проекта).
Если вы про сам vstutils, то... Ну как бы мы под себя и делали) А внутри проектов каждый может сделать под себя индивидуально. Шаблоны трудновато поддерживать, но думаю это не такая большая проблема.
А в чём профит? Сам по себе BModel не содержит какой-то полезной функциональности в принципе. Всё живёт в метаклассе, который наверное было бы сложно да и бессмысленно отделять от экосистемы. Да и лично нам станет это труднее поддерживать.
Ну... Наверное сейчас даже правильнее сравнивать vstutils и nuxt (хоть и основан на Vue, но всё же выше уровнем), где компонент это страница. В этом сама философия. Чтобы более гибко делать, мы просто выделили функцию, которая принимает модель и набор метапараметров, которые нужно перегрузить. Так мы решили проблему гибкости. Всё же мы чуть выше по уровню абстракции к DRF, поэтому не уверен, что нам подойдёт на 100%. А вот система плагинов и модулей как в nuxt у нас зашла хорошо и думаю это направление дальше и развивать.
На момент, когда использовали работал полностью. Из минусов был только лаг с созданием нод связанный с их vmid. Но нам тогда это только раз мешало, поэтому забили. Поправить под себя и актализировать можете. 100% работало с 2.4 версией Rancher'а. А потом мы забили, потому что на какое-то время стало неактуально.
Я прям ждал этого комментария. Начнём с простого - переписывать все проекты и код на GraphQL, просто потому что он модный - дурная практика. Схему так же придётся передавать, правда есть одно "но". Сейчас мы можем эту схему модифицировать, чтобы определить что нужно или ненужно видеть конкретному пользователю "на лету". С GraphQL мы этого уже не сможем сделать. А если бы и могли, то тут приходит другой момент в виде принципа работы с данными в стиле REST API, который для интеграции даже с bash'ем подходит, в отличии от GraphQL. Проще говоря, это решение во многом уступит на выходе для наших задач, по сравнению с OpenAPI + DRF, а гемороя прибавит.
Однако, я не хочу чтобы вы думали, будто я против GraphQL. Это вполне себе годное решение для определённых задач и на базе него можно так же реализовать подобное решение. Но конкретно для эволюционного подхода развития проектов с текущими требованиями это не подходит.
Мы же почему хотим сделать NPM пакет с фронтовой частью. Постепенно, мы приведём код там к такому состоянию, что можно будет переписать логику под конкретный способ взаимодействия с большим количеством различных API на разных языках. Например, очень хочется подключить FastAPI+Pydantic, уверен что есть что-то удобное на Golang.
а чтобы весь этот компот связать с Django есть вдохновленным Fastapi реализация для джанги django-ninja
Мсье знает толк в извращениях...
чтобы еще меньше делать магию руками а использовать чужой труд
Я за то, чтобы держать баланс в этом вопросе. Если сейчас мы контролируем эту связку и можем просто форкнуть или помочь какому-то одному из проектов, контролируем зависимости и т.д., то с готовыми проектами всегда беда с поддержкой. Так наша совесть чиста перед заказчиками, что их сервисы с актуальными зависимостями и проверенными пакетами, а что происходит в чужом продукте мы не можем гарантировать им.
Если подвести итог, то вы накинули очень много годных идей, которые можно применить в каком-то другом проекте с подходящими под стек задачами, но нам пока не актуально.
Там нет какой-то магии. Просто драйвер нод подкидываете и деплоите кластер. Много всяких нюансов в плане proxmox есть, но в целом публичный драйвер уже рабочий или можно взять с гитхаба (можно через мой профиль выйти на организацию и драйвер).
У них куча драйверов есть уже, но некоторые нерабочие. Правда всё это пробовали только через их GUI. Консольный rke тоже можно подружить.
Самое интересное забыли сказать. Rancher умеет использовать любой, даже самописный, docker-machine driver для создания нод. Мы вот использовали в своё время proxmox для тестовых окружений. Удобненько.
Ужас какой! Крепостное право же отменили давно, зачем так жестоко? Первый пункт просто жесть какая-то. Насчёт второго. Мне кажется что переваливание работы с одного на другого пользы всё равно не принесёт. Либо код будет отстой, либо времени на это уйдёт туча, либо коллега будет демотивирован. Так или иначе, результат будет ужасный.
Это называется сатира. На самом деле это не просто соблюсти хронологию развития всяких *Ops и умудриться сделать в актуальном ключе (описанная история не совсем выдумка).
Наверное это для адептов мышкакликательных свидетелей гуя. Они же не умеют в cli и конфиги, им GUI подавай и 100500 кликов мышкой.
Не надо использовать Makefile в экосистеме Python, если только вы не пишете чистые C-API модули без зависимостей и т.д. И даже тогда не надо этого делать...
Есть прекрасный инструмент tox, который не только покрывает возможности Makefile, но и значительно обогащает его питонячьими плюшками (например, под каждую зависимость можно загнать свой набор зависимостей, собирать разом под несколько версий питона, сделать aio/all-in-one окружения, с учётом особенностей).
Makefile на фоне tox'а выглядит бедно, но это не так. Просто это гибкий инструмент для совершенно иной экосистемы.
Обычно разработчиков/админов 1С меньше чем пользователей, поэтому логичнее делать как удобнее пользователям.
Конфигурации, которые не поддерживают ws уже практически вымерли. Новые проекты точно на них не стоит делать, а старые скоро все перейдут.
Насчёт геморроя с Postgres поддерживаю, но как ниже сказали: вся статья набор антипаттернов и костылей. Поэтому мне интересно стало, почему не поднять всё на условной ubuntu server 22.04 с репой pgpro и 1C+ws(apache2.4)? Проще в обслуживании уже некуда.
Для ws нулевая настройка рабочих мест. Браузер есть абсолютно везде. Или просто так появились всякие Nextcloud/OwnCloud/Onlyoffice/etc. К тому же http экономичнее по трафику и быстрее. Разрешать и запрещать нужно только один порт. Куда проще?
Я когда в магазинах RDP на кассе вижу и как продавцы рыдают, так прям сердце разрывается. И что, никто на местах ничего не настраивает? Ещё как настраивают.
Мне кажется самая фишка этой статьи в описании реализации терминального сервера на свободных компонентах. Но вообще многое решается проще, если брать нужную ось и готовые пакеты.
Но непонятно чем не угодил ws с апачем? Хорошо работает, не требует иксов, пользователю окружение не нужно костылять (браузер есть и поехали), https с кучей заголовков для безопасности, brotli+gzip для экономии трафика. Уже даже видел драйвер для подключения ккм через http. Почему все возятся с терминалом?
Считаю ужасной практикой в livenessProbe делать http-запросы. Это проверка, что контейнер не зомби, т.е. запущены нужные процессы. Эту проверку надо делать максимально часто, чтобы мёртвый процесс действительно мёртв был. И эта проверка не должна ни в коем случае зависеть от нагрузки и сокетов. А то получится, что у вас нагрузка выросла и контейнер делает себе харакири. В итоге на другие распределяется нагрузка, и они тоже делают себе харакири. Кластер лежит, пользователи недоумевают, CTO порет ремнем SRE - такая себе картина.
Для readinessProbe это нормально и если сильно нагрузка бахнула, то они действительно могут и должны на время выпасть из обмена, пока не переварят. Такую проверку можно делать реже, чтоб тоже не загадить подключения. Но эта проверка действительно будет делать то, что нужно - проверять, что сервис может принимать подключения и обрабатывать их.
Например, в приведённом деплойменте nginx, можно было бы проверить наличие процесса nginx для проверки жизни в контейнере, что прям сложность O(1) имеет. Тогда период можно в одну секунду поставить, чтоб мгновенно пезагрузить. А читабельность оставить как есть. Но для Cloud Native лучше livenessProbe отдельно реализовывать: проверять, что нужный процесс не просто запущен, но имеется активность внутри. Если это какой-то циклический обработчик, то можно писать файлик (даже пустой) и проверять время последнего изменения.
Вы предлагаете дважды делать эту проверку или реализовать функционал, при котором в словаре можно будет бросать исключение при наличии ключа?
В любом случае это нафиг никому не нужно, поэтому никто не хочет усложнять код и синтаксис. Единственное, где это могло бы пригодиться - mypy. Но и тут это не нужно никому видимо.
Получилась бы сомнительная польза в ущерб производительности. Словарь в Python'е одна из самых проблемных и медленных сущностей, но на ней держится вся логика переменных. Каждая такая проверка замедлила бы код минимум процентов на 20-30%.
Единственный вариант, как я вижу, если и делать такую проверку, то с помощью mypy. Но кмк это просто никому не нужно, поэтому никто и не делает. Да и, опять же, кмк это только усложнило бы читабельность.
Если говорить про результаты, то возможно testinfra, которая проверяет уже сам результат выкатки. Но это прям узкая часть.
Иногда с короткоживущими даже проще. Яркий пример из практики. Инфраструктура на проде у определённого проекта 60-80к облачных денег в месяц, а на тестовом сервере в подсобке - 0к/мес (ну фиг с ним, купим PC под нужды за 100к). Пример утрированный, но у условного облака один набор инструментов CD, а у стейджинга допустим этого нет (причин может быть больше, почему нет).
Если с короткоживущими можно поднять и опустить окружение потратив ресурсы за час, то стейджинг это условная "песочница", которая работает постоянно.
Звучит отлично. Если не считать п.2
Вы как-то упрощаете. В субчартах уже нельзя использовать, для реализации внутренних услуг тоже в очень редких случаях подойдёт. Вообще советую разобраться с лицензией, потому что для вас она тоже вносит ограничения (либо контрибьютить вам должны с MIT). Вы зря минусите, лучше бы текст почитали. В РФ сейчас он конечно мало смысла имеет, хотя тут от судьи зависит. Не просто так LGPL придумали.
Выглядит достойно для тех, кто любит минимизировать ручной труд. А как универсальный чарт работает в качестве сабчарта?
Единственное чего я не понял, так это GPLv3. Потому что использование в коммерческих целях практически не возможно легально (к слову об субчартах) да и мало кто захочет с GPL связываться в принципе. Ну и для вас профита не понимаю. Можете объяснить?
А чем Cobbler не подошёл? Он ещё и репы в себе может держать (и обновлять), установка и настройка через кикстарт и подобные. Тот же Ubuntu MAAS тоже можно, но это больше про сервера. Зачем насиловать форточками пингвина?
Прикольный совет, особенно если учесть, что 14-16 сильно медленнее, например, 10-12 версий по отчётам бенчмарков.
Свежие версии далеко не всегда про производительность. Чаще всего это про какой-то синтаксический сахар или большую нативность.
Спасибо за развёрнутый комментарий и советы. Приятно получать такие комментарии как и дельные советы.
Руки не доходят. Вообще хочу прям лютую магию сделать на Cython или на крайний случай C-API, с ленивой инициализацией некоторых компонентов. Для некоторых кейсов это было бы очень полезно. Но в целом разбить на части нужно, просто нежно. Думаю так же сделать сам конфиг plug-able, чтобы какие-то части просто менять, а не делать ужасный import.
settings.ini ещё как используется. Может я вас не так понял, но именно им конфиг и настраивается. Если вы про тот, что в корне проекта, то да - его тоже надо доработать и возможно туда default values вынести. Рефакторинг большой я запланировал на следующий мажорный релиз, потому что надо будет убрать ооооочень много legacy.
Зачем? Команда tox в корне проекта прекрасно работает. Кому надо, те могут это сделать. Мы пользы от этого не увидели (хотя бы потому что тесты не сильно быстрые, а грузят проц весьма), потому что у нас всё в CI проверяется и культура выстроена на git flow (сокращённый для этого проекта).
Если вы про сам vstutils, то... Ну как бы мы под себя и делали) А внутри проектов каждый может сделать под себя индивидуально. Шаблоны трудновато поддерживать, но думаю это не такая большая проблема.
А в чём профит? Сам по себе BModel не содержит какой-то полезной функциональности в принципе. Всё живёт в метаклассе, который наверное было бы сложно да и бессмысленно отделять от экосистемы. Да и лично нам станет это труднее поддерживать.
Ну... Наверное сейчас даже правильнее сравнивать vstutils и nuxt (хоть и основан на Vue, но всё же выше уровнем), где компонент это страница. В этом сама философия. Чтобы более гибко делать, мы просто выделили функцию, которая принимает модель и набор метапараметров, которые нужно перегрузить. Так мы решили проблему гибкости. Всё же мы чуть выше по уровню абстракции к DRF, поэтому не уверен, что нам подойдёт на 100%. А вот система плагинов и модулей как в nuxt у нас зашла хорошо и думаю это направление дальше и развивать.
https://github.com/vstconsulting/docker-machine-driver-proxmox-ve
На момент, когда использовали работал полностью. Из минусов был только лаг с созданием нод связанный с их vmid. Но нам тогда это только раз мешало, поэтому забили. Поправить под себя и актализировать можете. 100% работало с 2.4 версией Rancher'а. А потом мы забили, потому что на какое-то время стало неактуально.
Я прям ждал этого комментария. Начнём с простого - переписывать все проекты и код на GraphQL, просто потому что он модный - дурная практика. Схему так же придётся передавать, правда есть одно "но". Сейчас мы можем эту схему модифицировать, чтобы определить что нужно или ненужно видеть конкретному пользователю "на лету". С GraphQL мы этого уже не сможем сделать. А если бы и могли, то тут приходит другой момент в виде принципа работы с данными в стиле REST API, который для интеграции даже с bash'ем подходит, в отличии от GraphQL.
Проще говоря, это решение во многом уступит на выходе для наших задач, по сравнению с OpenAPI + DRF, а гемороя прибавит.
Однако, я не хочу чтобы вы думали, будто я против GraphQL. Это вполне себе годное решение для определённых задач и на базе него можно так же реализовать подобное решение. Но конкретно для эволюционного подхода развития проектов с текущими требованиями это не подходит.
Мы же почему хотим сделать NPM пакет с фронтовой частью. Постепенно, мы приведём код там к такому состоянию, что можно будет переписать логику под конкретный способ взаимодействия с большим количеством различных API на разных языках. Например, очень хочется подключить FastAPI+Pydantic, уверен что есть что-то удобное на Golang.
Мсье знает толк в извращениях...
Я за то, чтобы держать баланс в этом вопросе. Если сейчас мы контролируем эту связку и можем просто форкнуть или помочь какому-то одному из проектов, контролируем зависимости и т.д., то с готовыми проектами всегда беда с поддержкой. Так наша совесть чиста перед заказчиками, что их сервисы с актуальными зависимостями и проверенными пакетами, а что происходит в чужом продукте мы не можем гарантировать им.
Если подвести итог, то вы накинули очень много годных идей, которые можно применить в каком-то другом проекте с подходящими под стек задачами, но нам пока не актуально.
Там нет какой-то магии. Просто драйвер нод подкидываете и деплоите кластер. Много всяких нюансов в плане proxmox есть, но в целом публичный драйвер уже рабочий или можно взять с гитхаба (можно через мой профиль выйти на организацию и драйвер).
У них куча драйверов есть уже, но некоторые нерабочие. Правда всё это пробовали только через их GUI. Консольный rke тоже можно подружить.
Что конкретно интересует?
Самое интересное забыли сказать. Rancher умеет использовать любой, даже самописный, docker-machine driver для создания нод. Мы вот использовали в своё время proxmox для тестовых окружений. Удобненько.
Ужас какой! Крепостное право же отменили давно, зачем так жестоко? Первый пункт просто жесть какая-то.
Насчёт второго. Мне кажется что переваливание работы с одного на другого пользы всё равно не принесёт. Либо код будет отстой, либо времени на это уйдёт туча, либо коллега будет демотивирован. Так или иначе, результат будет ужасный.