Хорошее замечание. Учту, пока ещё новичок в написании подобных статей: это вторая моя статья на Хабре. Вы мне очень помогли этим советом. Будем исправляться
Я указал в хабах данную технологию. Так как имеется и Postgres, ELK, Nginx, iptables, ufw в этом обзоре. Подумал, что не вместится весь перечень инструментария)
С подобным аргументом не спорю, всё так и надо: закрывать по возможности всё, открывать только для потребителя внешнего нужное. Для примера просто взят один порт для закрытия из множества.
Очень круто, спасибо за развернутый ответ! А можете, пожалуйста, поделиться ссылкой на подобные руководства для чайников? Я думаю, что читателям было бы полезно.
Про модифицированные версии согласен, очень много предустановленного ПО и нет возможности во многих бюджетных хостингах просто взять и поставить свой диструбутив - это боль. Изначально хотел писать статью про пользу развертывания со своей машины безопасного сервера, но не у всех есть белый IP-адрес, а ngrok я бы рекомендовал использовать людям на страх и риск :)
Да, как раз таки хочется не додумывать за автором комментария, а в чистой дискуссии обсудить выбор диструбутива.
А по поводу чистого ядра и системы - с Вами согласен. В принципе, ничего нет безопаснее того, что ты контролируешь сам, начиная от ОС, заканчивая железкой. Материал образовательный и для новичков как в плане хостинга серверов, так и в в принципе в карьере IT: подавал примеры на распространенные случаи, частые ошибки.
Многие поставщики услуг vps\vds и сейчас добавляют ключи, насколько знаю, для поддержки. И много где закрыта возможность через VMware и без этих ключей взять и настроить (на очень бюджетных хостингах и датацентрах)
Да, это вообще best-practies. Цель открытых и закрытых портов средствами iptables показан как раз для того, чтобы новички имели представление, как это работает. Соглашусь, что лучше закрыть всё, кроме избранного.
Пример на скриншоте сделан ради примера. Сервер не реальный, а поднято в виртуальной среде. Как раз-таки для того, чтобы в образовательных целях показать, что есть определенные порты и необходимые нужно закрыть.
Вы закрываете фаерволом ненужные порты (тот же 9090), а надо делать наоборот - закрыть все по умолчанию и открывать только нужные (22, 80, 443 и ничего больше).
Вы точно читали текст после скриншота и точно ли понимаете грань между for example и реальными боевыми действиями?
Решение проблемы со слишком большим объёмом данных из комментаторов предложена очень корректно: ограничение по чанкам, ограничение по content lenght. Также я планирую доработать мидлварь для бан-листа для формирования бинарников(если content length - binary), также ограничивать определенные endpoints.
И кстати, такой проблемы нет?
user = { name: "alex" } logger("my name", { user, }; ->> ушло в очередь user.name = "ahmed"
Что уйдет в лог?
уйдет в лог “alex”, потому что мы сразу ставим record объект в очередь логгера, а его результат записи стрима уже будет работать в asyncio. То есть CPU bound задача с форматированием сработает синхронно, а вывод стрима (I/O) - отработает асинхронно. В этом вся прелесть предложенного мной подхода. И да, Мистер “ahmed” останется ждать своего часа побывать в логгере.
1) JSON для кастомно-настроенного логстэша. Какие никакие, а поля (я убрал из примеров, но были поля еще трассировки OpenTelemetry, посчитал, что для статьи это неважно)
2) тело и заголовки в строке, потому что эксплуатация хочет это в таком виде читать, копировать, использовать для своих нужд, а также оптимизация для разработчиков на других языках программирования: тут формат вышел из попытки подстроиться под текущие и устоявшиеся стандарты скорее, чем какое-то ноу хау. Поэтому я заложил возможность менять форматы как угодно и где угодно, чтобы это не было головной болью для разработчиков.
Формат специфичный и дело уже разработчика подстраивать формат: я это описал в части, где инициализировал pydantic структуру. Вот, по сути этой структурой можно сделать что угодно в части формата. Тело ответа и заголовки строкой в связи со спецификациями проектов в компании, требования архитекторов и девопсов для однообразия. Решения придумывались совместно над типом данных некоторых полей, они также изменяемы, как видно в коде примеров. Суть статьи была показать, как заставить все механизмы вместе: нативное логирование, асинхронность, форматирование в удобный кастомный формат, который нужен только автору, а можно еще и под ECS это подбить, также показать это дело со стороны веба(аналогичное можно на http-клиентах сделать, могу показать, как это было реализовано на примере httpx библиотеки).
Никак нет. Как я уже пометил в этом комментарии https://habr.com/ru/post/575454/#comment_23431790 - асинхронная библиотека логирования реализована на принципе очереди Queue стандартного logging в питоне. То есть, есть шанс, что можно набить этот буфер очень быстро, но при 860 rps полет был нормальный. Да, есть эффект того, что код отрабатывает быстрее, а логи уже потом за ним поспевают, это нормально для асинхронного мира в других языках программирования, например в Котлине такой же эффект с корутинами.
Да, Вы верно подметили этот недочет. На самом деле, тут оставляется выбор за разработчиком уже достраивать новые ограничения на контент, на формат данных с помощью pydantic, на то, как будет мидлварь сплитить и декомпозировать отдельные части запроса и ответа. Совет с content-type - очень крутой, возьму на заметку. Спасибо за Ваш комментарий!
Очень годный совет! Спасибо! Да, доработки будут вестись, также попробую сделать упоминания комментаторов, чтобы было как-то по-справедливости.
Хорошее замечание. Учту, пока ещё новичок в написании подобных статей: это вторая моя статья на Хабре. Вы мне очень помогли этим советом. Будем исправляться
Я указал в хабах данную технологию. Так как имеется и Postgres, ELK, Nginx, iptables, ufw в этом обзоре. Подумал, что не вместится весь перечень инструментария)
Очень рад, что понравилось!)
С подобным аргументом не спорю, всё так и надо: закрывать по возможности всё, открывать только для потребителя внешнего нужное. Для примера просто взят один порт для закрытия из множества.
про ssh-тунель - очень годная мысль в целом
Очень круто, спасибо за развернутый ответ! А можете, пожалуйста, поделиться ссылкой на подобные руководства для чайников? Я думаю, что читателям было бы полезно.
Про модифицированные версии согласен, очень много предустановленного ПО и нет возможности во многих бюджетных хостингах просто взять и поставить свой диструбутив - это боль. Изначально хотел писать статью про пользу развертывания со своей машины безопасного сервера, но не у всех есть белый IP-адрес, а ngrok я бы рекомендовал использовать людям на страх и риск :)
Да, как раз таки хочется не додумывать за автором комментария, а в чистой дискуссии обсудить выбор диструбутива.
А по поводу чистого ядра и системы - с Вами согласен. В принципе, ничего нет безопаснее того, что ты контролируешь сам, начиная от ОС, заканчивая железкой. Материал образовательный и для новичков как в плане хостинга серверов, так и в в принципе в карьере IT: подавал примеры на распространенные случаи, частые ошибки.
Многие поставщики услуг vps\vds и сейчас добавляют ключи, насколько знаю, для поддержки. И много где закрыта возможность через VMware и без этих ключей взять и настроить (на очень бюджетных хостингах и датацентрах)
Порты и ситуации с ними указаны в качестве примера. На тот случай "Если вдруг возникла необходимость...и тут учимся работать с iptables"
Спасибо большое!
Это детали настройки NGINX, у меня на моем сервере так и настроено как указано у вас:
спасибо за замечание!
Да, это вообще best-practies. Цель открытых и закрытых портов средствами iptables показан как раз для того, чтобы новички имели представление, как это работает. Соглашусь, что лучше закрыть всё, кроме избранного.
Токсичный комментарий, не раскрывающий ничего
Пример на скриншоте сделан ради примера. Сервер не реальный, а поднято в виртуальной среде. Как раз-таки для того, чтобы в образовательных целях показать, что есть определенные порты и необходимые нужно закрыть.
Вы точно читали текст после скриншота и точно ли понимаете грань между for example и реальными боевыми действиями?
Не используются потоки. Используется обычный класс, который наследуется от QueueHandler, если внимательно попрыгать по исходникам этой либы.
Решение проблемы со слишком большим объёмом данных из комментаторов предложена очень корректно: ограничение по чанкам, ограничение по content lenght. Также я планирую доработать мидлварь для бан-листа для формирования бинарников(если content length - binary), также ограничивать определенные endpoints.
уйдет в лог “alex”, потому что мы сразу ставим record объект в очередь логгера, а его результат записи стрима уже будет работать в asyncio. То есть CPU bound задача с форматированием сработает синхронно, а вывод стрима (I/O) - отработает асинхронно. В этом вся прелесть предложенного мной подхода. И да, Мистер “ahmed” останется ждать своего часа побывать в логгере.
1) JSON для кастомно-настроенного логстэша. Какие никакие, а поля (я убрал из примеров, но были поля еще трассировки OpenTelemetry, посчитал, что для статьи это неважно)
2) тело и заголовки в строке, потому что эксплуатация хочет это в таком виде читать, копировать, использовать для своих нужд, а также оптимизация для разработчиков на других языках программирования: тут формат вышел из попытки подстроиться под текущие и устоявшиеся стандарты скорее, чем какое-то ноу хау. Поэтому я заложил возможность менять форматы как угодно и где угодно, чтобы это не было головной болью для разработчиков.
Формат специфичный и дело уже разработчика подстраивать формат: я это описал в части, где инициализировал pydantic структуру. Вот, по сути этой структурой можно сделать что угодно в части формата. Тело ответа и заголовки строкой в связи со спецификациями проектов в компании, требования архитекторов и девопсов для однообразия. Решения придумывались совместно над типом данных некоторых полей, они также изменяемы, как видно в коде примеров. Суть статьи была показать, как заставить все механизмы вместе: нативное логирование, асинхронность, форматирование в удобный кастомный формат, который нужен только автору, а можно еще и под ECS это подбить, также показать это дело со стороны веба(аналогичное можно на http-клиентах сделать, могу показать, как это было реализовано на примере httpx библиотеки).
Никак нет. Как я уже пометил в этом комментарии https://habr.com/ru/post/575454/#comment_23431790 - асинхронная библиотека логирования реализована на принципе очереди Queue стандартного logging в питоне. То есть, есть шанс, что можно набить этот буфер очень быстро, но при 860 rps полет был нормальный. Да, есть эффект того, что код отрабатывает быстрее, а логи уже потом за ним поспевают, это нормально для асинхронного мира в других языках программирования, например в Котлине такой же эффект с корутинами.
Да, Вы верно подметили этот недочет. На самом деле, тут оставляется выбор за разработчиком уже достраивать новые ограничения на контент, на формат данных с помощью pydantic, на то, как будет мидлварь сплитить и декомпозировать отдельные части запроса и ответа. Совет с content-type - очень крутой, возьму на заметку. Спасибо за Ваш комментарий!