Nginx *

Давно ничего не писал, поэтому разбавим конец пятницы простыми, но не всегда очевидными изысканиями в Nginx.

В этом веб-сервере есть замечательная директива map, которая позволяет существенно упростить и сократить конфиги. Суть директивы в том, что она позволяет создать новую переменную, значение которой зависит от значений одной или нескольких исходных переменных. Ещё большую силу директива приобретает при использовании регулярных выражений, но при этом многие забывают, об одном важном моменте. Выдержка из мануала:

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

Распределённая трассировка (Distributed Tracing) - это метод, используемый для мониторинга приложений. Для микросервисов он просто незаменим.

В качестве примера мы будем использовать приложение Meow-Micro , специально созданное для этой статьи. Но вы можете развернуть собственные приложения, если захотите.

В digital-агентстве Convergent, где я работаю, в потоке множество проектов, и у каждого из них может быть собственная админка. Есть несколько окружений (дев, стейдж, лайв). А ещё есть разные внутрикорпоративные сервисы (как собственной разработки, так и сторонние вроде Redmine или Mattermost), которыми ежедневно пользуются сотрудники. 

Наша команда всегда была распределённой между несколькими офисами, но с учётом событий последнего года все сотрудники перешли на удалёнку. Так мы столкнулись с необходимостью организовать всё многообразие внутренних и клиентских сервисов в единой системе.

Так сложились обстоятельства, что мне удалось скоммуниздить старенький ПК, да и чтобы он просто не пылился, так как такое старье продавать за 5-7 тысяч (цена в моем регионе за подобную конфигурацию) мне стыдно, а получать за него 3 тысячи — ну такое. Я решил, сделаю дома небольшую библиотеку фильмов, музыки, да и у жены очень много фотографий, которые её очень дороги.

После того, как мы закончили разработку веб-приложения, оно должно быть размещено на хосте, чтобы общественность могла получить доступ к нему из любого места. Мы посмотрим, как развернуть и разместить приложение на экземпляре AWS EC2, используя Nginx в качестве веб-сервера и Gunicorn в качестве WSGI.

Липкие сессии (Sticky-session) — это особый вид балансировки нагрузки, при которой трафик поступает на один определенный сервер группы. Как правило, перед группой серверов находится балансировщик нагрузки (Nginx, HAProxy), который и устанавливает правила распределения трафика на доступные сервера.

В первой части цикла мы посмотрим как создавать липкие сессии с помощью Nginx. Во второй же части разберем создание подобной балансировки средствами Kubernetes.

Как известно настройка и обучение моделей машинного обучения это только одна из частей цикла разработки, не менее важной частью является развертывание модели для её дальнейшего использования. В этой статье я расскажу о том, как модель машинного обучения может быть развернута в виде Docker микросервиса, а также о том, как можно распараллелить работу микросервиса с помощью распределения нагрузки в несколько потоков через Load balancer. В последнее время Docker набрал большую популярность, однако здесь будет описан только один из видов стратегий развертывания моделей, и в каждом конкретном случае выбор лучшего варианта остаётся за разработчиком.

Ранее Cloud4Y рассказал про уязвимости веб-серверов Nginx, балансировщиков нагрузки и прокси-серверов. Что-то из этого вы могли знать, а что-то, надеемся, стало полезной информацией.

Но история не закончилась. Многочисленные программы bug bounties позволяют проводить широкомасштабные исследования, благодаря которым удаётся найти реально действующие уязвимости. Проект Gixy помог найти множество неправильных конфигураций промежуточного ПО, но далеко не все. Что ещё удалось обнаружить:

Долгое время я терпел ограничения РосКомНадзора и соответствующие действия провайдеров по различным ограничениям доступа к сайтам - но с определённого момента устал, и начал думать как бы сделать так, чтобы было и удобно, и быстро, и при этом с минимумом заморочек после настройки... Хочу оговориться, что цель анонимизации не ставилась.

Вообще, эта проблема имеет несколько решений... Но я решил бороться с провайдером их же методом.

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

Nginx — один из наиболее часто используемых веб-серверов в Интернете, поскольку он модульный, отзывчивый под нагрузкой и может масштабироваться на минимальном железе. Компания Detectify регулярно сканирует Nginx на предмет неправильных настроек и уязвимостей, из-за которых могут пострадать пользователи. Найденные уязвимости потом внедряются в качестве теста безопасности в сканер веб-приложений.

Мы проанализировали почти 50 000 уникальных файлов конфигурации Nginx, загруженных с GitHub с помощью Google BigQuery. С помощью собранных данных нам удалось выяснить,  какие ошибки в конфигурациях встречаются чаще всего.

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

Эта небольшая история — живое свидетельство того, как самые простые решения (иногда) могут оказаться очень эффективными. В одном из проектов руководство взяло курс на оптимизацию бюджета на инфраструктуру. В результате анализа всех статей расходов стало очевидным, что заметно выдаются счета за сетевой трафик из Amazon S3-бакета, где хранится публичная статика веб-приложения. Так появилась задача найти и реализовать максимально недорогой и решающий бизнес-задачу способ.

Привет, Хабр! Меня зовут Владимир. Я разработчик в Максилекте. Помимо технического образования у меня есть бэкграунд в практической психологии. В этой статье я разберу модель уточнения, которая может быть полезна для дополнения информации о проекте как при обсуждении внутри команды, так и в разговорах с бизнесом. Модель содержит вопросы, которые стоит задавать, чтобы быстрее получить нужные данные.

Текст написан по материалам внутреннего тренинга, который я проводил в нашей компании в начале февраля.

В этой статье я буду в общих чертах рассказывать про то, в каком направлении нужно двигаться, чтобы сделать полуавтоматический обменник криптовалюты с возможностью управлять сделками с любого устройства в любой точке планеты 24/7. Вы не найдете здесь полной реалиализации, т.к. этот материал предназначен скорее для получения базового набора знаний, необходимых для запуска такого стартапа.

Правильная работа с параметрами фронтенд-приложения помогает создавать надежные и удобные в эксплуатации системы. Достаточно отделить конфигурацию от приложения и перенести ее в среду выполнения, чтобы радикально улучшить комфорт членов команды и снизить количество потенциальных ошибок. Разбираемся как это сделать.

В общем задача звучала так: установить Redmine на сервер, где веб-сервер на nginx.

Так как Redmine написан на RoR, то необходимо иметь RoR среду, но проблема в том, что разные RoR приложения могут требовать разные версии окружения. В моем случае необходимо было предусмотреть возможность установки RoR приложений с разным окружением, а значит нужен менеджер версий, который будет разворачивать нужную среду в нужном месте.