… в тех случаях, когда программисты пытаются пользоваться обезьяньими патчами...
Это когда лютый джун присылает тебе исправление бага на 100 строк, хотя должен был написать цикл в 4 строки? Не надо термины так переводить — на Хабре к куче переводов постоянно об этом пушут в комментариях.
А по самой статье — очень интересно. Вроде __slots__ уже давно использую, но никогда не применял strict-модули. Кто-нибудь замерял, влияет ли это на производительность в какую-нибудь сторону или только на безопасное программирование?
Пока ничем — используем кубик для "визуального тестирования" приложения. В остальных случаях тыкнуть мышкой для клонирования шаблона не проблема.
Смотрели в сторону github.com/Telmate/terraform-provider-proxmox?
Теперь точно посмотрим. Интересный проект. Раньше пользовались Ansible, потому что куча модулей для OpenStack, но в принципе ничего не мешает добавить слой terraform'а, который так же может вызывать Ansible на крайний случай (или наоборот)./
Спасибо за наводку.
Думаю всё же будущее за разумным подходом.
В ноутбуках 100% нужен SSD, чтобы меньше волноваться за механическое воздействие.
В PC и серверных решениях неплохо живут RAID'ы с writeback-кешем на SSD. В бюджетных решениях — lvmcache. Так получается производительность SSD, а предсказуемость HDD.
В различных "холодных" хранилищах могут даже ленточные накопители встречаться, но HDD сейчас там самое место.
Я надеюсь LVM доработают, чтобы можно было держать резервный SSD, чтобы при выходе из строя одного, данные писались на резервный. Тогда вообще идеально будет.
Во-первых, откуда вы её взяли? В статье поиском не нашёл.
Во-вторых, если всё же открыть документацию, то там очень понятно с примерами написано, что это ссылка на якорь. Это значит, что в это место подставится содержимое staging-deploy-common (если прям по простому объяснить).
Ну и вопросы лучше задавать на Тостер'е.
В Вашем случае я бы пользовал Software ZFS Raid 10
ZFS любит память… очень сильно. Меня просто замучила бы амфибиотропная асфиксия. Одна из причин, почему решил не заморачиваться. Ко всему, не проверял на ситуациях, когда резко пропадает питание на сервере — восстановится ли всё как надо?
Но самая главная причина была в том, что sas-провода только до контроллера дотягивались, а за новыми лень было ехать. Вот так вот решаются судьбы.
Но вообще есть в планах сервер развернуть на ZFS, чтобы "обкатать", так сказать.
Зачем мне менять всю инфраструктуру ради HTTPS, который мне не нужен внутри сети?
Зачем мне lb, если сервисы могут работать и без него?
Вы понимаете, что значит децентрализированная модульная инфраструктура? Мне на каждый сервис лезть в балансировщик? И только затем, чтобы использовать SW?
Сейчас куча независимых сервисов работают и легко разворачиваются и убиваются. Умрёт какой-то сервис — другие работают. Вы же предлагаете кучу сервисов засунуть за один-N балансировщиков, которые нафиг не нужны, кроме как принудительно загонять трафик в https? Это же ректальное удаление гланд автогеном костыль!
Каждый новый сервис будет требовать танцы с бубном и тревогу в сердце подсервиса для обновления сертификата и мониторинга ("дьявольская ромашка" или любит/не любит — отработает/сломается).
Нужду в AWS Route53, даже если есть своё "облако".
А все потому, что SW работает только по HTTPS, хотя мог бы прекрасно работать и без него. Я может старомоден, но чем меньше узлов для поломки, тем лучше, но это ведёт к зоопарку зависимостей.
Проблема больше наверное даже не в самом https, а в том, как делать те или иные сертификаты доверенными или получить их от доверенного.
А прикручивать certbot на каждый сервис то ещё удовольствие. У нас Кубик внутренний и dns-челлендж там не самый простой процесс (во всяком случае пока не нашёл ничего внятного, что завелось бы).
Может быть в том, что, как я уже написал, этому сервису не нужен https, а всё чему он нужен использует LE. Или вы предлагаете купить сертификат? Или нужно ставить проксю с wildcard-сертификатом, что тоже не всегда удобно и хорошо.
В общем о том и говорю: нет проблем, кроме боли с сертификатами.
У Service Workers есть один фатальный недостаток: нормально работает только по HTTPS. С одной стороны безопасность это прекрасно, но когда ты не контролируешь эту опцию это порой приводит к боли и страданиям.
Пример кейса, когда SW при использовании приносит боль:
Маленький сервис для внутренних нужд компании, с большой frontend-логикой. Он неплохо защищён во внутренней сети, хотя в этом и нужды нет. Но SW не регистрируется, если фронт не через https, поэтому кеширование не работает, установить как PWA — не работает. Для локальных машин можно было бы установить свой корневой сертификат, но как быть с Android/iOS?
Во-первых, wrapper тоже не async, а значит "мне не нужен async call" — решаемая проблема.
Во-вторых, оберните только async: для чего оборачивать обычный метод?
В этом месте вообще не вижу смысла в том, чтобы каждый раз возвращать wrapper и ещё и создавать его. Почему бы сразу не возвращать метод объекта?
Более того, каждый раз когда вызывается self., то Python ищет этот атрибут в словаре атрибутов. Если возвращать сразу метод, то это минус один сложный вызов (внутри wrapper'а).
Либо, как предложил ADR, логику запихнуть во wrapper, но создавать по методу на каждую декорацию мне кажется расточительным по памяти и немного нагромождённым для одного метода.
Но и git submodules, и вариант с checkout тега уступают использованию функционала пакетного менеджера.
Я наверное коряво задал вопрос. Чем уступают? Точнее что конкретно вам мешало в подходе с подмодулями? Вы просто написали, что это было похоже на обходной путь, но без пояснений, поэтому и спрашиваю опыта ради.
Поскольку рассматриваемые микросервисы деплоятся и запускаются одинаково, необходим одинаковый набор Helm-шаблонов. Чтобы избежать копирования каталога .helm между репозиториями, раньше мы выполняли клонирование репозитория, в котором хранились Helm-шаблоны и делали checkout на нужный тег.
А что мешало использовать git submodules? Gitlab этот функционал неплохо поддерживает.
А при таком раскладе backup из omnibus будет работать? Какой профит от переноса базы просто на другой сервер? И сколько у вас пользователей онлайн?
Вторая ссылка в гугле на запрос
python __slots__. Более чем понятно.Это когда лютый джун присылает тебе исправление бага на 100 строк, хотя должен был написать цикл в 4 строки? Не надо термины так переводить — на Хабре к куче переводов постоянно об этом пушут в комментариях.
А по самой статье — очень интересно. Вроде
__slots__уже давно использую, но никогда не применял strict-модули. Кто-нибудь замерял, влияет ли это на производительность в какую-нибудь сторону или только на безопасное программирование?Пока ничем — используем кубик для "визуального тестирования" приложения. В остальных случаях тыкнуть мышкой для клонирования шаблона не проблема.
Теперь точно посмотрим. Интересный проект. Раньше пользовались Ansible, потому что куча модулей для OpenStack, но в принципе ничего не мешает добавить слой terraform'а, который так же может вызывать Ansible на крайний случай (или наоборот)./
Спасибо за наводку.
Думаю всё же будущее за разумным подходом.
В ноутбуках 100% нужен SSD, чтобы меньше волноваться за механическое воздействие.
В PC и серверных решениях неплохо живут RAID'ы с writeback-кешем на SSD. В бюджетных решениях — lvmcache. Так получается производительность SSD, а предсказуемость HDD.
В различных "холодных" хранилищах могут даже ленточные накопители встречаться, но HDD сейчас там самое место.
Я надеюсь LVM доработают, чтобы можно было держать резервный SSD, чтобы при выходе из строя одного, данные писались на резервный. Тогда вообще идеально будет.
Во-первых, откуда вы её взяли? В статье поиском не нашёл.
Во-вторых, если всё же открыть документацию, то там очень понятно с примерами написано, что это ссылка на якорь. Это значит, что в это место подставится содержимое
staging-deploy-common(если прям по простому объяснить).Ну и вопросы лучше задавать на Тостер'е.
ZFS любит память… очень сильно. Меня просто замучила бы амфибиотропная асфиксия. Одна из причин, почему решил не заморачиваться. Ко всему, не проверял на ситуациях, когда резко пропадает питание на сервере — восстановится ли всё как надо?
Но самая главная причина была в том, что sas-провода только до контроллера дотягивались, а за новыми лень было ехать. Вот так вот решаются судьбы.
Но вообще есть в планах сервер развернуть на ZFS, чтобы "обкатать", так сказать.
А на someting.lan нельзя никак. А вот многие таким паттерном пользуются.
Зачем мне менять всю инфраструктуру ради HTTPS, который мне не нужен внутри сети?
Зачем мне lb, если сервисы могут работать и без него?
Вы понимаете, что значит децентрализированная модульная инфраструктура? Мне на каждый сервис лезть в балансировщик? И только затем, чтобы использовать SW?
Сейчас куча независимых сервисов работают и легко разворачиваются и убиваются. Умрёт какой-то сервис — другие работают. Вы же предлагаете кучу сервисов засунуть за один-N балансировщиков, которые нафиг не нужны, кроме как принудительно загонять трафик в https? Это же
ректальное удаление гланд автогеномкостыль!Итого:
танцы с бубном и тревогу в сердцеподсервиса для обновления сертификата и мониторинга ("дьявольская ромашка" или любит/не любит — отработает/сломается).А все потому, что SW работает только по HTTPS, хотя мог бы прекрасно работать и без него. Я может старомоден, но чем меньше узлов для поломки, тем лучше, но это ведёт к зоопарку зависимостей.
Проблема больше наверное даже не в самом https, а в том, как делать те или иные сертификаты доверенными или получить их от доверенного.
А прикручивать certbot на каждый сервис то ещё удовольствие. У нас Кубик внутренний и dns-челлендж там не самый простой процесс (во всяком случае пока не нашёл ничего внятного, что завелось бы).
Может быть в том, что, как я уже написал, этому сервису не нужен https, а всё чему он нужен использует LE. Или вы предлагаете купить сертификат? Или нужно ставить проксю с wildcard-сертификатом, что тоже не всегда удобно и хорошо.
В общем о том и говорю: нет проблем, кроме боли с сертификатами.
У Service Workers есть один фатальный недостаток: нормально работает только по HTTPS. С одной стороны безопасность это прекрасно, но когда ты не контролируешь эту опцию это порой приводит к боли и страданиям.
Пример кейса, когда SW при использовании приносит боль:
Во-первых, wrapper тоже не async, а значит "мне не нужен async call" — решаемая проблема.
Во-вторых, оберните только async: для чего оборачивать обычный метод?
В этом месте вообще не вижу смысла в том, чтобы каждый раз возвращать wrapper и ещё и создавать его. Почему бы сразу не возвращать метод объекта?
Более того, каждый раз когда вызывается
self., то Python ищет этот атрибут в словаре атрибутов. Если возвращать сразу метод, то это минус один сложный вызов (внутри wrapper'а).Либо, как предложил ADR, логику запихнуть во wrapper, но создавать по методу на каждую декорацию мне кажется расточительным по памяти и немного нагромождённым для одного метода.
Так если он при расширении кластера перегоняет данные в новый, то мог бы и переехать.
Действительно очень похоже на ноющих ёжиков жрущих кактус.
А разве AGPLv3 не помогла бы этого избежать?
Я не хочу прикапываться к словам, но это и в 2.7 работает. Не знаю как насчёт '!r', но остальная конструкция точно.
Я наверное коряво задал вопрос. Чем уступают? Точнее что конкретно вам мешало в подходе с подмодулями? Вы просто написали, что это было похоже на обходной путь, но без пояснений, поэтому и спрашиваю опыта ради.
А что мешало использовать git submodules? Gitlab этот функционал неплохо поддерживает.