Статья Develop VULN Workers SCAN

[supra]

бить боксеров, грабить банки, играть в бейсбол

Ведь мой папа, ведь мой папа - пиздабол)

сабж.
supra уже 3 поста, и 0 цитат темниковой... стареешь... скучно)

про композ абсолютно согласен. композ+докер акшон = авто деплой, без костылей с сшш и прочей мутотени.

в общем и целом, без грамнотного распределения, отработки ошибок, нормального управления машинами и единой целостной системы - это все так, лирика. оно и ежу понятно, что этот пок будет ворк. народ требует, хлеба, зрелищь! и прод версию!)

да и где конкурсная объективность, друзья? у новорегов до каждой "точки с запятой" доебываются, а сторожилы - "хуяк, хуяк и в прод" и все, сразу аплодисменты) не надо так)

а почему ты думаешь что это уже prod?)

 

[ГошаМарков]

а почему ты думаешь что это уже prod?)

дак вот о чем речь, что до прода тут копать да копать)

 

[supra]

дак вот о чем речь, что до прода тут копать да копать)

Откопал?

 

[ГошаМарков]

Откопал?

только пару скринов с дефолтной адмники джанги и кускок кода со стаковерфлоу

 

[barnaul]

только пару скринов с дефолтной адмники джанги и кускок кода со стаковерфлоу

Надо показать очвередной воркфлоу)

 

[Tr0jan_Horse]

Откопал?

Привет, отпиши в лс пожалуйста.

 

[Tr3kzzz]

Просто оставлю это тут ScanTron бери да прикручивай чего изволишь
Вот тебе прод
Если хочется не просто сканить то вот вроде прикольное Komo

 

[supra]

На сегодняшний день:
как полностью закончу выложу тут код и в целом статью

 

[moneytype]

Рекомендую обратить внимание на docker-compose + swarm. Добавить к вашему стеку очередь задач (Celery или redis-rq), для решения балансировки тасков по воркерам, и в целом для отказа от SSH-взаимодействия.
Все иснрументы для скана и функций воркеров вы заворачиваете в один простой контейнер на базе linux. Вам останется написать прокладку-воркер на python, для взаимодействия с очередью задач и функций-оберток для запуска/получения результатов от софтов.

Например, скрипт-воркер взял таск из очереди на запуск Naboo с параметрами, вызывает функцию naboo_run(*args, **kwargs), которая стартует сабпроцесс Naboo и через communicate парсит результат. После отправляет его либо в очередь, либо в админку по апи, либо напрямую в бд (не рекомендую).

Если захотите добавить в билд, например, масскан просто допишите его установку в контейнер воркера и добавьте функцию-оберку для работы с его подпроцессом.

С помощью docker-swarm вся эта сборка сама распределяет нагрузку по кластеру серваков. Paramiko вам будет нужен только для подключения новых серверов-воркером (ноды) к вашему сворму, зайти по SSH, установить докер и запустить "docker swarm join --token <master-token>". Причем на одном сервере-воркере может работать нескольк воркер-контейнеров и не мешать друг-другу.
При выходе из строя одного из северов, docker и очередь задач распределят нагрузку на другие ноды автоматически.
Плюс, эта задача довольно популярная, и под неё есть множество руководств и шаблонов с таким стеком. Вам останется только настроить саму админку и добавить питон скрипт для воркеров. Всё остальное решает докер.

Как бонус, есть дополнительные панельки для наблюдения за работой кластера и очееди задач, которые можно установить парой строк в docker-compose.yaml.

Спойлер: Картинки дэщбордов

Насчет защиты, это будет изолированная виртуальная сеть, так что и это плюс. Но дополнительно, конечно, можно и шифрование внутри добавить и много чего ещё из Opsec.
В общем одни плюсы от такого решения, и настроить такое не менее сложно, чем дурить голову с бегатнёй по ссш через парамико
Успехов вам!

Задачи разве сам swarm распределяет по воркерам? Нужен балансировщик отдельный.

 

[barnaul]

Задачи разве сам swarm распределяет по воркерам? Нужен балансировщик отдельный.

Добавить к вашему стеку очередь задач (Celery или redis-rq), для решения балансировки тасков по воркерам

Swarm балансирует контейнеры между серверами

 

[moneytype]

Swarm балансирует контейнеры между серверами

Там Round Robin алгоритм. Нагрузку он никак не распределяет в контексте данной задачи.

 

[barnaul]

Там Round Robin алгоритм. Нагрузку он никак не распределяет в контексте данной задачи.

А какая, по-вашему, нагрузка в контексте этой задачи?

 

[diams]

That look ty bro

 

[moneytype]

А какая, по-вашему, нагрузка в контексте этой задачи?

CPU и канал.
Чтобы распределять нагрузгу, балансировщик должен знать значения этих параметров. А тупо по кругу раскидывать через Round Robin что это за балансировщик? Это пара строк кода без всяких докеров свагеров.

 

[ckat_soft]

CPU и канал.
Чтобы распределять нагрузгу, балансировщик должен знать параментры этих значений. А тупо по кругу раскидывать через Round Robin что это за балансировщик? Это пара строк кода без всяких докеров свагеров.

хе-хе, если просто по кругу крутить задания то можно получить интересный момент, воркер еще выполняет задачу, а балансировщик уже стучит с новой к нему, что мы получаем? либо потерю данных, либо перегрузку воркера в целом, либо жоский фриз,(ожидаем когда воркер освободится чтоб принять задание), думаю все таки автору надо смотреть в сторону распределённых задач celery/rabit-mq, да и думаю если воркер выпадет, то это тоже никто не мониторит, опять потеря куска данных

 

[barnaul]

CPU и канал.
Чтобы распределять нагрузгу, балансировщик должен знать параментры этих значений. А тупо по кругу раскидывать через Round Robin что это за балансировщик? Это пара строк кода без всяких докеров свагеров.

Канал и цпу по дефолту балансирует планировщик ядра хоста (контейнеры это процессы, если что). И да, лимиты на цпу и мемори ты можешь выставить в конфиге контейнера, если прям ограничен в ресурсах на нодах.

Большой трафик тут только на воркерах, и нагрузка только в исходящих запросах при работе того же масскана, например.
Но и в этом случае работает планировщик ядра. Например, если вы запустите два маскана на своём хосте, что произойдет? Канал может забить и один из них, но в случае двух, они его будут конкурентно делить через планировщик, как любые процессы. В сумме сделают ту же работу за плюс/минус такое же время, как если бы запускались по очереди.

Насчет round robin, в который вы так усердно тычите пальчиком - в контексте докера, это вообще не про таски и нагрузку как таковую (с оговорками). Это про реплики и балансировку контейнеров по нодам, балансировку запросов во внутренней сети (опять же по репликам) между сервисами (контейнерами). Если отвалится контейнер, он перенаправит всё на реплику, пока не поднимется оригинальный. Если упадёт нода с контейрами, он поднимет их на других нодах. Его суть в том, чтобы сохранять целостность системы и рабочее состояние. Поэтому я и обратил ваше внимание на контекст этой задачи, т.к. тут нет нагрузки на внутрянку или веб-сервер (как это бывает в нагруженных веб-приложениях).

хе-хе, если просто по кругу крутить задания то можно получить интересный момент, воркер еще выполняет задачу, а балансировщик уже стучит с новой к нему, что мы получаем? либо потерю данных, либо перегрузку воркера в целом, либо жоский фриз,(ожидаем когда воркер освободится чтоб принять задание), думаю все таки автору надо смотреть в сторону распределённых задач celery/rabit-mq, да и думаю если воркер выпадет, то это тоже никто не мониторит, опять потеря куска данных

Вы вообще к чему это написали тут? Мы ведем речь не про таски воркеров (по крайней мере я), но и этот вопрос был оговорен выше, и celery/anyMQ уже был предложен в контексте Swarm. Сам Swarm (и его RR) не крутит таски и к бизнес-логике работы сервисов не имеет отношение. Это просто внутренний механизм докера для работы с контейнерами в распределенной среде, это ниже уровнем. Как сравнивать tpc и http

 

[ckat_soft]

Канал и цпу по дефолту балансирует планировщик ядра хоста (контейнеры это процессы, если что). И да, лимиты на цпу и мемори ты можешь выставить в конфиге контейнера, если прям ограничен в ресурсах на нодах.

Большой трафик тут только на воркерах, и нагрузка только в исходящих запросах при работе того же масскана, например.
Но и в этом случае работает планировщик ядра. Например, если вы запустите два маскана на своём хосте, что произойдет? Канал может забить и один из них, но в случае двух, они его будут конкурентно делить через планировщик, как любые процессы. В сумме сделают ту же работу за плюс/минус такое же время, как если бы запускались по очереди.

Насчет round robin, в который вы так усердно тычите пальчиком - в контексте докера, это вообще не про таски и нагрузку как таковую (с оговорками). Это про реплики и балансировку контейнеров по нодам, балансировку запросов во внутренней сети (опять же по репликам) между сервисами (контейнерами). Если отвалится контейнер, он перенаправит всё на реплику, пока не поднимется оригинальный. Если упадёт нода с контейрами, он поднимет их на других нодах. Его суть в том, чтобы сохранять целостность системы и рабочее состояние. Поэтому я и обратил ваше внимание на контекст этой задачи, т.к. тут нет нагрузки на внутрянку или веб-сервер (как это бывает в нагруженных веб-приложениях).

Вы вообще к чему это написали тут? Мы ведем речь не про таски воркеров (по крайней мере я), но и этот вопрос был оговорен выше, и celery/anyMQ уже был предложен в контексте Swarm. Сам Swarm (и его RR) не крутит таски и к бизнес-логике работы сервисов не имеет отношение. Это просто внутренний механизм докера для работы с контейнерами в распределенной среде, это ниже уровнем. Как сравнивать tpc и http

я знаю что такое docker-swarm, не утруждайтесь мисье

 

[barnaul]

я знаю что такое docker-swarm, не утруждайтесь мисье

Вы процитировали человека, который пишет про Round Robin, и "раскидывать по кругу" (я надеюсь он не имел ввиду задания, потому что это сразу клиника). Вы отвечаете, "хе-хе, если просто по кругу крутить задания...".
Ладно, я просто рукалицо и покину этот чат.
ТС, сори за флуд

 

[ckat_soft]

Вы процитировали человека, который пишет про Round Robin, и "раскидывать по кругу" (я надеюсь он не имел ввиду задания, потому что это сразу клиника). Вы отвечаете, "хе-хе, если просто по кругу крутить задания...".
Ладно, я просто рукалицо и покину этот чат.
ТС, сори за флуд

Ну вы надетесь что не имел ввиду, а я понял именно так)

 

[moneytype]

Канал и цпу по дефолту балансирует планировщик ядра хоста (контейнеры это процессы, если что). И да, лимиты на цпу и мемори ты можешь выставить в конфиге контейнера, если прям ограничен в ресурсах на нодах.

Большой трафик тут только на воркерах, и нагрузка только в исходящих запросах при работе того же масскана, например.
Но и в этом случае работает планировщик ядра. Например, если вы запустите два маскана на своём хосте, что произойдет? Канал может забить и один из них, но в случае двух, они его будут конкурентно делить через планировщик, как любые процессы. В сумме сделают ту же работу за плюс/минус такое же время, как если бы запускались по очереди.

Насчет round robin, в который вы так усердно тычите пальчиком - в контексте докера, это вообще не про таски и нагрузку как таковую (с оговорками). Это про реплики и балансировку контейнеров по нодам, балансировку запросов во внутренней сети (опять же по репликам) между сервисами (контейнерами). Если отвалится контейнер, он перенаправит всё на реплику, пока не поднимется оригинальный. Если упадёт нода с контейрами, он поднимет их на других нодах. Его суть в том, чтобы сохранять целостность системы и рабочее состояние. Поэтому я и обратил ваше внимание на контекст этой задачи, т.к. тут нет нагрузки на внутрянку или веб-сервер (как это бывает в нагруженных веб-приложениях).

Вы вообще к чему это написали тут? Мы ведем речь не про таски воркеров (по крайней мере я), но и этот вопрос был оговорен выше, и celery/anyMQ уже был предложен в контексте Swarm. Сам Swarm (и его RR) не крутит таски и к бизнес-логике работы сервисов не имеет отношение. Это просто внутренний механизм докера для работы с контейнерами в распределенной среде, это ниже уровнем. Как сравнивать tpc и http

Рукалицо это ставить докер, чтобы на одном серваке запустить два масскана в разных контейнерах.