Так будет, если сертификат самоподписан (при этом криво) и если залезть через браузер, и если сертификат не положили в хранилище доверенных (привет рутованым телефонам, плюс не забываем, что некоторые vpn могут законно потребовать положить сертификат), и если в пакете приложения не разрешено доверять пользовательским сертификатам. И много других если.
Говоря о простых пользователях, вы наблюдали на сколько всего они согласны, лишь бы зайти в любимое приложение с фоточками друзей?
Даже если вы в код запихнёте сертификат, само приложение это набор файлов. Есть много способов вытащить оттуда этот сертификат в умелых руках. Но как я уже сказал, это сильно повысит сложность взлома, чего иногда достаточно.
Скажем так, приведённый пример окружения ssl pining вполне может решить. Не решит это план Б исследователя: перепаковку приложения для проведения тщательного исследования.
Есть более интересный способ, когда ответ от сервера имеет какие-то определённые признаки в самом пакете, которые после перепаковки пропадают из ответа или запроса. Эта техника применяется вполне успешно, но требует некоторых навыков. Стандартные инструменты в данном случае бессильны либо требуют знания алгоритма этих случайных данных. Я не писал лично код, который подобную технику защиты от MitM реализует, но разбирался в коде, где видел её реализацию. Это довольно изящное решение, потому что подменить сертификат даже зашифрованный можно в пакете. А вот подменить алгоритм уже требует полной пересборки или нехилых навыков.
Это усложняет задачу, но не решает проблему. Тот же пакет apk это просто архив, который можно перебрать и переподписать. Поэтому клиентское приложение всегда должно рассматриваться как потенциально скомпроментированное.
Лучше разберитесь что эти параметры делают и когда они нужны. Есть хороший бесплатный курс, который можно посмотреть, скачать и попробовать от разработчиков Postgres, про оптимизацию вообще всего в PG. Хотя я советую вообще все курсы оттуда пройти, если планируете активно использовать pg в продакшене.
Тогда все рекомендации начнут обретать определённый смысл и начнёте разбираться как тонко настроить субд, чтобы выжать максимум из железа. Плюс научитесь менять эти параметры в зависимости от изменений в самой БД. Тогда вас будет жёстко триггерить от того, что люди не понимают значение effective_io_concurrency и как работает SATA и NVMe протоколы (да и вообще дисковая и файловая системы).
У меня нужды прям не было, потому что для своих нужд пока ssh достаточно. Для одного заказчика писал для их особенной самописной системы виртуализации на вебсокете - было весело. Самое классное, что для написания плагина каких-то особенных знаний прям не нужно.
А так и сам напишу, конечно.
Поделитесь потом с сообществом. Но сразу предупреждаю, что адекватно решить проблему become не получится, потому что нет необходимых инструментов в pve api.
Нет, хотя написать его не проблема. Могу выложить в gist, когда руки дойдут, и приложить к статье.
А в чём проблема теперь самостоятельно написать и выложить?) Самое сложно там учесть вызовы для windows машин (проблемы с кодировкой). А так, поднимаете http пул в _connect, закрываете в close, отправляете запросы в api. Файлы лучше кодировать сразу в base64.
Справедливости ради надо учесть ещё стоимость сервера 1С (15 пользователей это уже не файловый вариант), подписку ИТС для обновлений и возможно лицензии ОС и БД (очень сомневаюсь что интегратор воткнул linux+pg). Добавим туда стоимость поддержки всего этого или стоимость одного админа.
Самопис конечно не вариант, потому что поддержка там золотая будет. Я просто к тому, что экономия сомнительная. Поэтому автоматизация это не про экономию, а, как вы сказали, увеличение пропускной способности и уменьшение рисков человеческого фактора. Я бы добавил, что без этого сложно заниматься оптимизацией, потому что не видно узких мест.
Но посыл в статье и правда кривой, что мол мы начали экономить деньги, при этом ни слова про увеличение других статей расходов. По сути то на то и поменяли, просто процессы стали прозрачнее и качественнее.
Да и скажем честно - ну вот даже 9к фреймы взять дома особо не откуда, разве что если у Вас только нет выделенного SAN сегмента для какой-нибудь лабы.
Вы удивитесь как можно фоточками и домашними видосиками раскачать сетку, если дома поднять минисервер на TrueNAS/Openmediavault с zfs и кешами на ssd. Это вам не документооборот.
Оставлю свои 5 копеек. Rancher и Openshift продукты работающие на разных уровнях.
Насчёт OpenShift наверное и правда сомнительное сравнение. Но если смотреть как на удобную гуёвую консольку для управления нагрузками, то где-то рядом.
Из личного опыта Rancher с одной стороны удобный инструмент для отладки и поиска проблемы на продакшн кластерах, с другой, сама идея что в инфраструктуре есть узел из которого можно получить доступ ко всем кластерам, некоторых безопасников вводит в ужас.
Это безопасники которые в основном матчасть не изучают? В рамках одного облачного провайдера это одно и то же по уровню безопасности. Если говорить за локальное облако, то тут вообще претензия сомнительная с их стороны. Если все от админа ходят, то наверное это действительно проблема. В остальном это больше выдуманная проблема.
В UI Rancher из версии в версию что-то не работает, складывается ощущение сырого продукта, несмотря на количество лет на рынке.
У меня было такое ощущение, пока сидел на lates ветке. Потом перешёл на stable и как-то без проблем всё было. Может быть не сильно глубоко использовали, но Istio и прочее работало исправно. Был прикол только с производительностью ingress, при установке через helm приложений в кластер. Долго не могли понять в чём дело, пока не добавили пару аннотаций, которые добавляет Rancher. С тех пор проблем не знали.
Как вариант можно создать свою коллекцию в Plex. Правда нужно хранилище. Мне было довольно удобно пользоваться до переезда. Я туда и кино торрентами закидывал. Смотреть было удобнее чем на кинопоиске и амедиатеке (хотя была подписка).
Минусов было два. Во-первых, нужно было свое хранилище (пришлось на домашний сервер дисков докупить). Во-вторых, нужно заново коллекцию и плейлисты собирать. А так, всё очень даже удобно и антисанкционненько.
А можно сразу 4ую часть? Пока что больше вопросов чем ответов. Но ко всему, я бы прошёлся и прокомментировал всё что могло бы вызвать вопросы. Хотя если задачка разовая, то это уже на совести и усмотрении вашем.
Зачем было обновлять django пошагово? Есть changelog, в котором очень подробно пишется что дропнули и добавили + судя по всему есть тесты. В чём профит от этого геморроя?
Зачем обновляться на не-LTS джангу? Одна из причин, почему хочется часть 4 посмотреть.
Почему не использовали репозиторий с мёртвыми змеями? Питон 3.6 вполне себе там живой. Нее, контейнер тоже неплохо, но почему нет?
Не понял проблему с pip. Он не запускался? Можно же в любой момент установить его скриптом get-pip. Ни разу не подводил.
Почему не пользуетесь ~= наверное уже лишним будет, потому что poetry. Но какую проблему им решали? Чем pip не угодил?
Ага. Заодно искать его в списках участников хакатона, по компаниям пробивать по виду деятельности (а то вдруг медсестра после двух смен), на входе брать анализ крови (а то вдруг простывший, некоторые спят крепче в период болезни, или может бессонницей страдает и сел днём в такси) и много чего ещё.
Про внешний трафик. Он меня всегда печалит в облаках - стоит как самолет.
Если мы говорим не про AWS, то что же такое надо гонять через кластер, чтобы ощутить стоимость внешней сети? Я сейчас глянул тот же ЯОблако и там Исходящий трафик, свыше 100 ГБ в месяц 1,5300 ₽. Всё что меньше 100ГБ в месяц вообще бесплатно. Не представляю себе как раскачать на 4 CPU / 12 RAM занята на 14-30% и 5 Gb такой трафик эффективно. Если только от VPS в S3 заворачивать трафик и настроить отдачу HLS-трафика.
расскажите зачем нужна пачка админов для обычного проекта? Ну т.е. я реально не понимаю, что они там будут делать. Во многих статьях про k8s рассказывают про мифическое "администрирование кластера" и начинают сравнивать "стоимость облака vs ЗП админа k8s". Что они там делают сутками? Что там постоянно ломается?
С одним кластером не так много чего делают: обновляют (кластер обновить без downtime довольно интересная задача может быть), следят за актуальными версиями приложений и пакетов, мониторят CVE там всякие, соответствия всяким там PCI-DSS и прочим стандартам (тут важно понимать специфику кластера и его рабочих нагрузок) и многое другое по мелочи. В принципе, с одним кластером который загружен примерно в половину это максимум человеко-неделя в месяц. Если кластеров уже 10 в разных ДЦ, провайдерах и прочем, то тут всё будет кратно увеличиваться.
Но это не самая важная проблема. Ещё кучу рутинного времени занимает упаковка сервисов в CI/CD в кластере, да так чтоб с каким-нибудь ArgoCD да через Argo Workflows, да мгновенно и с согласованностью и с мягким переходом пользователей. В общем и целом работы и без того хватает, а тут ещё за кластером следить, да так чтоб без даунтаймов. Поэтому и считают, что на всю эту обслугу нужны будут люди кратно количеству кластеров.
Сколько машин нужно среднему интернет-магазину? Одна? Десять? Двадцать? Это все без проблем потянет средненький разработчик этого же магазина, ибо админить там особо нечего.
Давайте просто прикинем о какой вилке по зп для среднего разработчика магазина мы говорим? Теперь давайте просто откроем тот же hh и посмотрим как много там могут разработчики среднего уровня. Теперь посчитаем просто на калькуляторе. Я в принципе, считаю нужно подбирать инструмент под нагрузку. Если кластер поднимать только для одного интернет магазина, да ещё и монолита без особых изысков к скейлингу, то это вообще оверхед. Простой systemd внутри vps гораздо лучше справится, а выйдет гораздо дешевле. Если архитектура проекта это с десяток сервисов, каждый из которых можно равномерно скейлить и нужно горизонтальное масштабирование, то там лучше справится куб.
Помню как-то раз я по ошибке снес свой кластер. Ну вот подчистую. Ошибся немного :) Знаете сколько времени заняло восстановить десяток машин в рабочее состояние? Около часа.
Кубового админа обычно берут не ради одного часа на восстановление, а чтобы этого даунтайма в час никогда не случилось. Собственно большой кластер куба это про отсутствие даунтайма как такового.
Однако, хочу уточнить, что сама тема статьи как раз о том, что для небольших инсталляций, где downtime в час это прям ок и никто не умрёт, можно использовать очень удобно k3s, который как раз и рассчитан не небольшие статические кластеры для небольшого количества сервисов. В принципе, его можно адаптировать под high-volume/highload нагрузки, но с нюансами.
RKE, как и RKE2 не упомянут намерено. Во-первых, он чуточку жирнее (Control plane требует больше ресурсов для запуска, возможно потому что etcd и и куча ванильного k8s). Во-вторых, эта утилита требует сохранения стейта установки кластера. Если для k3s достаточно самого кластера, то rke привязывается к этому самому стейту. Это хорошо для gitops и так себе для админов стартующих один кластер на всю организацию. В-третьих, управление и обслуживание у них отличается.
Если так в лоб сравнить, то rke это утилита для деплоя почти (не возьмусь утверждать) ванильного кубера и нацелен больше на управление через облака (тут раскрывается вся их мощь node driver и cluster driver, когда можно дописать драйвер на любое облако с api), в то время как k3s это прям сразу облегчённый кубик, которому вообще пофиг где и как запуститься, работающий с sql-базой и живущий самостоятельной жизнью (без привязки к стейтам и прочему).
Плюс в том, что там всегда безлимит трафика. Это окупает все эти «сожмемся пока нет нагрузки».
Мы сейчас про внешний или внутренний трафик говорим? Внутренний вроде как почти везде, кроме AWS бесплатен. Насчёт VPS'ок это подходит как раз для небольших развёртываний без пиковых нагрузок. Т.е. для внутренних каких-то сервисов, маленьких интернет-магазинов и т.п. туда не придёт хабраэффект и не положит всё. И это реально дешевле если есть пачка админов (я считал местного известного vps хостера и местное облако - разница 30%).
Я, кстати, хотел в следующей статье про rke и rancher написать. Там нужно будет изрядно потрудиться, поэтому нужно время.
Судя по фото, производители подразумевают их сделать "рекламой для грабителей". В любом случае, это прям ну очень сомнительно выглядит (как и носить карту в прозрачном чехле телефона, имхо).
Так будет, если сертификат самоподписан (при этом криво) и если залезть через браузер, и если сертификат не положили в хранилище доверенных (привет рутованым телефонам, плюс не забываем, что некоторые vpn могут законно потребовать положить сертификат), и если в пакете приложения не разрешено доверять пользовательским сертификатам. И много других если.
Говоря о простых пользователях, вы наблюдали на сколько всего они согласны, лишь бы зайти в любимое приложение с фоточками друзей?
Даже если вы в код запихнёте сертификат, само приложение это набор файлов. Есть много способов вытащить оттуда этот сертификат в умелых руках. Но как я уже сказал, это сильно повысит сложность взлома, чего иногда достаточно.
Скажем так, приведённый пример окружения ssl pining вполне может решить. Не решит это план Б исследователя: перепаковку приложения для проведения тщательного исследования.
Есть более интересный способ, когда ответ от сервера имеет какие-то определённые признаки в самом пакете, которые после перепаковки пропадают из ответа или запроса. Эта техника применяется вполне успешно, но требует некоторых навыков. Стандартные инструменты в данном случае бессильны либо требуют знания алгоритма этих случайных данных. Я не писал лично код, который подобную технику защиты от MitM реализует, но разбирался в коде, где видел её реализацию. Это довольно изящное решение, потому что подменить сертификат даже зашифрованный можно в пакете. А вот подменить алгоритм уже требует полной пересборки или нехилых навыков.
Это усложняет задачу, но не решает проблему. Тот же пакет apk это просто архив, который можно перебрать и переподписать. Поэтому клиентское приложение всегда должно рассматриваться как потенциально скомпроментированное.
Наверное в коде прописано изучить историю браузера и предугадать ожидания.
Лучше разберитесь что эти параметры делают и когда они нужны. Есть хороший бесплатный курс, который можно посмотреть, скачать и попробовать от разработчиков Postgres, про оптимизацию вообще всего в PG. Хотя я советую вообще все курсы оттуда пройти, если планируете активно использовать pg в продакшене.
Тогда все рекомендации начнут обретать определённый смысл и начнёте разбираться как тонко настроить субд, чтобы выжать максимум из железа. Плюс научитесь менять эти параметры в зависимости от изменений в самой БД. Тогда вас будет жёстко триггерить от того, что люди не понимают значение
effective_io_concurrencyи как работает SATA и NVMe протоколы (да и вообще дисковая и файловая системы).Можете плагин на rust+maturin написать :)
У меня нужды прям не было, потому что для своих нужд пока ssh достаточно. Для одного заказчика писал для их особенной самописной системы виртуализации на вебсокете - было весело. Самое классное, что для написания плагина каких-то особенных знаний прям не нужно.
Поделитесь потом с сообществом. Но сразу предупреждаю, что адекватно решить проблему become не получится, потому что нет необходимых инструментов в pve api.
Нет, хотя написать его не проблема. Могу выложить в gist, когда руки дойдут, и приложить к статье.
А в чём проблема теперь самостоятельно написать и выложить?) Самое сложно там учесть вызовы для windows машин (проблемы с кодировкой). А так, поднимаете http пул в _connect, закрываете в close, отправляете запросы в api. Файлы лучше кодировать сразу в base64.
Главное чтоб никто не вклинился. А то не получится зарегистрироваться.
Справедливости ради надо учесть ещё стоимость сервера 1С (15 пользователей это уже не файловый вариант), подписку ИТС для обновлений и возможно лицензии ОС и БД (очень сомневаюсь что интегратор воткнул linux+pg). Добавим туда стоимость поддержки всего этого или стоимость одного админа.
Самопис конечно не вариант, потому что поддержка там золотая будет. Я просто к тому, что экономия сомнительная. Поэтому автоматизация это не про экономию, а, как вы сказали, увеличение пропускной способности и уменьшение рисков человеческого фактора. Я бы добавил, что без этого сложно заниматься оптимизацией, потому что не видно узких мест.
Но посыл в статье и правда кривой, что мол мы начали экономить деньги, при этом ни слова про увеличение других статей расходов. По сути то на то и поменяли, просто процессы стали прозрачнее и качественнее.
Вы удивитесь как можно фоточками и домашними видосиками раскачать сетку, если дома поднять минисервер на TrueNAS/Openmediavault с zfs и кешами на ssd. Это вам не документооборот.
Насчёт OpenShift наверное и правда сомнительное сравнение. Но если смотреть как на удобную гуёвую консольку для управления нагрузками, то где-то рядом.
Это безопасники которые в основном матчасть не изучают? В рамках одного облачного провайдера это одно и то же по уровню безопасности. Если говорить за локальное облако, то тут вообще претензия сомнительная с их стороны. Если все от админа ходят, то наверное это действительно проблема. В остальном это больше выдуманная проблема.
У меня было такое ощущение, пока сидел на lates ветке. Потом перешёл на stable и как-то без проблем всё было. Может быть не сильно глубоко использовали, но Istio и прочее работало исправно. Был прикол только с производительностью ingress, при установке через helm приложений в кластер. Долго не могли понять в чём дело, пока не добавили пару аннотаций, которые добавляет Rancher. С тех пор проблем не знали.
Как вариант можно создать свою коллекцию в Plex. Правда нужно хранилище. Мне было довольно удобно пользоваться до переезда. Я туда и кино торрентами закидывал. Смотреть было удобнее чем на кинопоиске и амедиатеке (хотя была подписка).
Минусов было два. Во-первых, нужно было свое хранилище (пришлось на домашний сервер дисков докупить). Во-вторых, нужно заново коллекцию и плейлисты собирать. А так, всё очень даже удобно и антисанкционненько.
А можно сразу 4ую часть? Пока что больше вопросов чем ответов. Но ко всему, я бы прошёлся и прокомментировал всё что могло бы вызвать вопросы. Хотя если задачка разовая, то это уже на совести и усмотрении вашем.
Зачем было обновлять django пошагово? Есть changelog, в котором очень подробно пишется что дропнули и добавили + судя по всему есть тесты. В чём профит от этого геморроя?
Зачем обновляться на не-LTS джангу? Одна из причин, почему хочется часть 4 посмотреть.
Почему не использовали репозиторий с мёртвыми змеями? Питон 3.6 вполне себе там живой. Нее, контейнер тоже неплохо, но почему нет?
Не понял проблему с pip. Он не запускался? Можно же в любой момент установить его скриптом get-pip. Ни разу не подводил.
Почему не пользуетесь ~= наверное уже лишним будет, потому что poetry. Но какую проблему им решали? Чем pip не угодил?
Ага. Заодно искать его в списках участников хакатона, по компаниям пробивать по виду деятельности (а то вдруг медсестра после двух смен), на входе брать анализ крови (а то вдруг простывший, некоторые спят крепче в период болезни, или может бессонницей страдает и сел днём в такси) и много чего ещё.
Если мы говорим не про AWS, то что же такое надо гонять через кластер, чтобы ощутить стоимость внешней сети? Я сейчас глянул тот же ЯОблако и там
Исходящий трафик, свыше 100 ГБ в месяц 1,5300 ₽. Всё что меньше 100ГБ в месяц вообще бесплатно. Не представляю себе как раскачать на4 CPU / 12 RAM занята на 14-30% и 5 Gbтакой трафик эффективно. Если только от VPS в S3 заворачивать трафик и настроить отдачу HLS-трафика.С одним кластером не так много чего делают: обновляют (кластер обновить без downtime довольно интересная задача может быть), следят за актуальными версиями приложений и пакетов, мониторят CVE там всякие, соответствия всяким там PCI-DSS и прочим стандартам (тут важно понимать специфику кластера и его рабочих нагрузок) и многое другое по мелочи. В принципе, с одним кластером который загружен примерно в половину это максимум человеко-неделя в месяц. Если кластеров уже 10 в разных ДЦ, провайдерах и прочем, то тут всё будет кратно увеличиваться.
Но это не самая важная проблема. Ещё кучу рутинного времени занимает упаковка сервисов в CI/CD в кластере, да так чтоб с каким-нибудь ArgoCD да через Argo Workflows, да мгновенно и с согласованностью и с мягким переходом пользователей. В общем и целом работы и без того хватает, а тут ещё за кластером следить, да так чтоб без даунтаймов. Поэтому и считают, что на всю эту обслугу нужны будут люди кратно количеству кластеров.
Давайте просто прикинем о какой вилке по зп для среднего разработчика магазина мы говорим? Теперь давайте просто откроем тот же hh и посмотрим как много там могут разработчики среднего уровня. Теперь посчитаем просто на калькуляторе. Я в принципе, считаю нужно подбирать инструмент под нагрузку. Если кластер поднимать только для одного интернет магазина, да ещё и монолита без особых изысков к скейлингу, то это вообще оверхед. Простой systemd внутри vps гораздо лучше справится, а выйдет гораздо дешевле. Если архитектура проекта это с десяток сервисов, каждый из которых можно равномерно скейлить и нужно горизонтальное масштабирование, то там лучше справится куб.
Кубового админа обычно берут не ради одного часа на восстановление, а чтобы этого даунтайма в час никогда не случилось. Собственно большой кластер куба это про отсутствие даунтайма как такового.
Однако, хочу уточнить, что сама тема статьи как раз о том, что для небольших инсталляций, где downtime в час это прям ок и никто не умрёт, можно использовать очень удобно k3s, который как раз и рассчитан не небольшие статические кластеры для небольшого количества сервисов. В принципе, его можно адаптировать под high-volume/highload нагрузки, но с нюансами.
RKE, как и RKE2 не упомянут намерено. Во-первых, он чуточку жирнее (Control plane требует больше ресурсов для запуска, возможно потому что etcd и и куча ванильного k8s). Во-вторых, эта утилита требует сохранения стейта установки кластера. Если для k3s достаточно самого кластера, то rke привязывается к этому самому стейту. Это хорошо для gitops и так себе для админов стартующих один кластер на всю организацию. В-третьих, управление и обслуживание у них отличается.
Если так в лоб сравнить, то rke это утилита для деплоя почти (не возьмусь утверждать) ванильного кубера и нацелен больше на управление через облака (тут раскрывается вся их мощь node driver и cluster driver, когда можно дописать драйвер на любое облако с api), в то время как k3s это прям сразу облегчённый кубик, которому вообще пофиг где и как запуститься, работающий с sql-базой и живущий самостоятельной жизнью (без привязки к стейтам и прочему).
Мы сейчас про внешний или внутренний трафик говорим? Внутренний вроде как почти везде, кроме AWS бесплатен. Насчёт VPS'ок это подходит как раз для небольших развёртываний без пиковых нагрузок. Т.е. для внутренних каких-то сервисов, маленьких интернет-магазинов и т.п. туда не придёт хабраэффект и не положит всё. И это реально дешевле если есть пачка админов (я считал местного известного vps хостера и местное облако - разница 30%).
Я, кстати, хотел в следующей статье про rke и rancher написать. Там нужно будет изрядно потрудиться, поэтому нужно время.
Судя по фото, производители подразумевают их сделать "рекламой для грабителей". В любом случае, это прям ну очень сомнительно выглядит (как и носить карту в прозрачном чехле телефона, имхо).
Этот стикер прям так и звучит:
Если NFC это опциональная, выключаемая и маломальски защищенная система, то сейчас объявят сезон краж телефонов или ещё хуже - чехлов.
Вариант.
Добавил небольшую заметку про балансировку в статью. Возможно будет полезно