Информационный портал по безопасности

Привет!

Это первый пост от лица нашей компании на Хабре и в нём мы хотим вам немного рассказать об архитектуре нашего облачного сервиса мониторинга серверов и веб сайтов CloudStats.me, с которым мы в данный момент проходим акселерацию во ФРИИ в Москве. Мы также хотим поделиться с вами нашей текущей статистикой и рассказать о планах на ближайшее будущее, но обо всём по порядку.

1. Архитектура системы

Наша платформа нацелена на системных администраторов, которым не хочется долго возиться с настройкой Nagios или Zabbix, а просто нужно отслеживать основные параметры серверов, не тратя много времени и ресурсов на мониторинг. Мы стараемся не перегружать интерфейс системы количеством настроек, поэтому всё построено по принципу KISS (keep it simple stupid).

Почти вся система написана на Ruby on Rails (за исключением python агента, которого мы скоро также заменим на агента на Ruby), с использованием RactiveJS. Front-end работает на Tomcat, нагрузка на которые распределяется с помощью Haproxy. В качестве CDN мы используем CloudFlare, через которую проходят только статичные файлы JS, CSS, PNG и т.д. Тем не менее, даже для такого достаточно простого и пока что не очень большого сервиса, нам уже приходится применять балансировку нагрузки на всех частях платформы для избежания перегрузок.

Архитектура сервиса на конец июня:



(большая картинка)

Как видно на картинке, задачи создаются отдельным нодом Scheduler и обрабатываются несколькими Worker нодами, которые в свою очередь связываются по API с серверами проверок Ping/Port/URL, расположенными в 3х зонах — France, UK, USA. Если один из серверов проверок вернул «Ping Failed» статус для какого-либо IP, то осуществляются дополнительные проверки в двух других зонах, чтобы исключить false positives. В будущем мы планируем вывести всё это во front-end чтобы вы смогли видеть, из каких локаций ваш IP недоступен (допустим, в ситуации с DDoS или routing issues).

Я должен признаться, что написать эту статью я решил очень спонтанно, прочитав статью «XMPP отстой» и почувствовав некоторую близость к чувствам автора, так как также использую ХМРР в одном из наших продуктов. Тем не менее, сжав эмоции в кулак, я всё-таки решил просто изложить, почему я испытываю смешанные чувства к данному протоколу и разложить по полкам плюсы и минусы. Также расскажу, что мы выбрали для сервера и клиента. Это все, чтобы тебе, дорогой читатель, сделать правильный выбор и вырвать меньше волос в твоих будущих проектах.

Как это начиналось

Я всю жизнь занимался разработкой под Windows. Сначала на С++, затем на C#. В промежутках мелькали VB, Java Script и другая нечисть. Однако некоторое время назад всё изменилось и я впервые столкнулся с миром Linux, Java и Scala. У нас с Денисом, моим другом и соратником по многочисленным идеям, уже был свой проект – набор утилит для Windows, который пользовался широким спросом в узких кругах. В какой-то момент мы оба потеряли интерес к этому проекту и встал вопрос – что же делать дальше. Денис стал инициатором идеи нового проекта – сервис по обмену clipboard между разными устройствами. Этот проект существенно отличался от предыдущего помимо технологий ещё и целевой аудиторией. Этот сервис должен был стать полезен всем. Скопируйте данные в буфер обмена и вставьте из него на любом другом устройстве. Звучит проще некуда, пока не задумаешься над тем сколько сейчас разных устройств, а также как это все будет работать при большом количестве пользователей.
Первый прототип появился через несколько месяцев. Сервер был написан на ASP.NET и хостился на MS IIS. Было написано 2 клиента: на С++ под Windows и на Java под Android.



Тестирование показало, что прототип держит около 500 соединений. Что же делать, если их будет больше, мы ведь расчитываем на сотни тысяч пользователей ;) Как написать сервер, который может работать с большим количеством соединений, который не надо будет выключать во время апгрейда железа или софта и который будет легко масштабироваться (то есть расширяться в случае увелечения количества пользователей).

Цель

Разделить взаимодействия пользовательского интерфейса между веб-клиентом и веб-приложением на три чётко определённые роли.

Предпосылки

Термин MVC испытывает некоторое семантическое размытие своего первоначального значения, особенно в контексте веба (см. видео Стефана Прибша для более подробного рассмотрения вопроса). В качестве средства устранения этого размытия предлагаю вашему вниманию описание паттерна Action-Domain-Responder, являющегося доработкой концепции MVC под нужды решения специфичных для веба задач.

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

Еще одной вскрывшейся проблемой является тот факт, что часто мы рассматриваем Представление (View) как шаблон (template), хотя в контексте веба, вероятно, более уместно было бы говорить о том, что Представлением является HTTP-ответ. Исходя из вышесказанного, я считаю, что ADR способен предоставить лучшее, чем MVC, разделение концепций для веб-приложений.

Привет, Хабр!

4 месяца назад мы писали о запуске бета-версии нового Хекслета — образовательной платформы для программистов с настоящей практикой в браузере. В ближайшие месяцы Хекслет выходит из беты, а сегодня я хочу рассказать о нескольких новых курсах. Но вначале вкратце об обновлениях сервиса:

• Мы открыли публичный чат сообщества Хекслет в Слаке! Там можно общаться с другими юзерами и с преподавателями. Есть специальные каналы по отдельным курсам и темам, есть даже канал для изучения английского языка.


• Оповещения о выходе новых уроков в ваших курсах теперь приходят на почту и появляются в уведомлениях на сайте.


• На сайте теперь появляются запланированные курсы, которые находятся сейчас в разработке (подробнее о них ниже). На эти курсы можно подписаться заранее.


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


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

А теперь — новые курсы:

Основы Ansible

Системы управления конфигурацией и оркестрации – важные инструменты в арсенале современного разработчика и системного администратора. Цель этого курса – научиться работать с Ansible, популярным инструментом управления конфигурацией. Как мы писали ранее, Ansible активно используется при разработке и деплое Хекслета.

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

Постановка задачи

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

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

В ходе обработки ордер меняет свое состояние от нового до выполненного, при этом создаются несколько сервисов (в зависимости от данных) и они должны быть запущенны и работать к концу обработки заказа. Простой пример — вы оформляете себе симку для сотового. К этой симке «подключаются» сервисы голосовой связи, СМС-ок и ММС-ок, мобильного интернета (у которого свои тарифы), автоответчик, определитель номера и т.д. К окончанию обработки вашего договора (заказа) все эти сервисы должны быть запущены и работать. Далее вы можете заключить доп. договор и переключиться на др. тариф мобильного интернета и т.д. Это просто пример логики, на который я буду ссылаться для наглядности.

Абсолютное большинство программистов начнет делать такое приложение на колбэках или тригерах. Создан новый ордер — ставим ему состояние new — и вешаем колбэк который начинает создавать сервисы и т.д. Далее я постараюсь объяснить, почему это абсолютное зло.

В данный момент на просторах интернета, к сожалению, не так и много статей и отчетов о CTF-соревнованиях (да и о соревнованиях и олимпиадах в целом), написанных от лица самих организаторов. Чтобы хоть немного исправить это недоразумение, мы (PeterPen, команда по информационной безопасности из СПбГУ) хотели бы описать свой опыт проведения индивидуального CTF-соревнования StepCTF 2015, прошедшего 11 и 12 мая 2015 года. В программе: как готовились, как проводили соревнование; также расскажем о полученных уроках, дабы предостеречь и/или облегчить жизнь потенциальным организаторам.

Давно хотел прикрутить к своей домашней Raspberry Pi удобный интерфейс «общения», который бы удовлетворял главному требованию — простота и лёгкость, с доступом из любой точки мира и с помощью любого оборудования (но в первую очередь — со смартфона).

В связи с отсутствием дома выделенного IP и наличием сурового и неподкупного NAT варианты с SSH клиентами и web-интерфейсами отпали сразу. Для небольших потребностей решение тоже должно быть простое, быстрое и, в качестве бонуса, надежное. Так что идея использования протокола одного из распространенных мессенджеров показалась мне весьма привлекательной. Под прицел попали Jabber, Telegram и WhatsApp.

Против Jabber сыграло нежелание устанавливать лишний клиент. Ну а так как Telegram — это, IMHO, тот же WhatsApp, только лучше и удобнее (и даже чуточку безопаснее), то именно на нём я и решил остановить свой выбор. К тому же появившаяся недавно в Telegram возможность создавать своих рабов ботов и взаимодействовать с ними с помощью очень простого API позволяет избавиться от необходимости регистрировать новый аккаунт, а так же дает некоторые очень полезные и удобные возможности.

На самом деле всё действительно настолько просто, что опытным человекам хватит и 30 минут, чтобы разобраться, поднять и настроить своего бота. Остальным же: Добро Пожаловать!

Написание данного поста навеяно недавней поистине шикарной работой, Nikole Merlin. Во многом его методика верстки схожа с моей и мне радостно от того, что это направление развивается теперь и на западе. Чем же этот способ так хорош? Все очень просто. Не нужно объяснять как важно адаптировать под мобильные платформы сверстанные письма для того, чтобы они были прочтены. Читать простыни на телефоне мало кто будет. Что же все это время делал западный разработчик? Он верстал табличной версткой с элементами блочности, затем причесывал этот код медиазапросами для поддержки мобильников. Чем этот подход ущербен? А тем, что ни на андроиде, ни на яблоке медиазапросы не поддерживаются следующими почтовыми клиентами: Gmail, Yandex, Mail.ru. По большому счету западные коллеги могли бы и наплевать на яндекс с мейлом, но вот Gmail как ни крути первый среди почтовиков.



Для Nikole Merlin это стало очевидно и он разработал свою методику, которая основывается на резиновой верстке с минимальным использованием медиазапросов(progressive enhancement) и это работает! Но немного не так как хотелось бы нам в России. Вся резиновость автора держится на inline-block элементах и оперированием max-width. Но вот беда-то, наши ребята из яндекса и мейла max-width не поддерживают. Сначала я расскажу об отличиях моего подхода от приемов Nikole, а затем плавно перейду к своим мыслям и примерам кода, которые стоит использовать при подготовке писем.