Автор:Михаил Шишло

В начале июня, а если быть точнее 3 июня, состоялась конференция DotNext в Санкт-Петербурге. Дружная команда разработчиков IT Band, а именно ее мужская составляющая, в полном составе посетила данное мероприятие и я готов от лица команды поделиться c вами впечатлениями.

День 1. Вылет

Так как конференция проходила в пятницу, решено было лететь в четверг на самолете. Только Сергей добирался ночью на поезде и прибыл прямо “с корабля на бал”. Кто летел самолетом, добрались без приключений, за исключением задержки вылета на час из-за пассажира, который передумал лететь в последний момент. Коле даже выпал счастливый билет, и он летел бизнес классом.

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

Ночь 1. Прогулка к Неве

Заселившись в квартиру, которую сняли до этого с помощью AirBnb, отправились гулять по городу. Погода на удивление порадовала, и знаменитой питерской сырости не ощущалось все три дня, что мы там провели. Стояла по-настоящему летняя погода. В это время ночи еще не “белые”, но уже довольно таки светло, поэтому гулять было в удовольствие. Добравшись домой глубоко за полночь, было решено первый keynote пропустить. Дружно одобрив эту идею, еще несколько часов предвкушали, сколько новых знаний мы завтра впитаем.

День 2. Конференция

Как и планировали, приехали к первому докладу. Сразу опишу организационную составляющую.

За организацию можно поставить твердую 5. Каких-либо изъянов я не нашел. Логистика была отличная, все компактно, заблудиться было сложно. Питание - тут вообще все замечательно. Обед без очередей и в течение дня постоянные закуски и напитки. Сувенирная продукция на уровне - майки от Касперского и Luxsoft (Сергей даже примерил, чтобы выбрать нужный размер) и еще куча разных штук. От организаторов в пакете была предоставлена банка сгущенки, которую мы отважно доставили домой.

А теперь подробнее остановлюсь на докладах.

Первым шел доклад на английском про новый asp net core. На самом деле, самый слабый доклад, что я послушал. Запомнился он только веселым моментом. После доклада вышел парень из зала, чтобы задать вопрос, который он начал словами: “Thank you for your ... эммм..доклад”

Далее был доклад Дино Эспозито. Ставлю его на первое место. И в первую очередь из-за докладчика. Эспозито со свойственной итальянцам экспрессией просто “уничтожил” Microsoft и его разработчиков. Основные тезисы его доклада:

1. Go to Azure -> more customers. Microsoft в последнее время делает огромную ставку на Azure. И именно привлечение новых клиентов на облачную инфраструктуру было одной из причин выпуска asp net core.
2. We know how to do things. Other do things better than us. Если раньше Microsoft шли своим путем в разработке, то теперь берут лучшие примеры из других технологий.
3. MS love Linux -> money  Резко полюбили Linux, хотя раньше евангелисты могли выступать и показывать demo только на win phones. Опять же все для привлечения новых клиентов.
4. No SignalR no F# В RTM нет поддержки данных технологий
5.    Bad education for developers. Don’t use repository on controllers Канонические гайдлайны от MS содержит bad practices для разработчиков.
6. Legacy code Тонны легаси кода, которые потребуют уйму часов и денег для переписывания.
7. All should be rewritten Напрочь отсутствует обратная совместимость. Некоторых библиотек и методов попросту нет, либо сигнатуры методов не совпадают.
8. RTM not RTM Даже после выхода RTM версии asp core ждут изменения несовместимые с RTM версией. Многострадальный project.json
9. Cost for training  Обучение новой технологии - это тоже огромные затраты
10. Start use core on 2017 H2 wait for .net core 2.0. Don’t use MS products until version 3. Совет, что не стоит начинать использовать core до версии 2.0
11. Start using core if you have problems with system.web and IIS. И вообще переходить на core, если у вас проблемы с IIS и system.web

Кратко об остальных докладах

Следующим был доклад про PerfView. Утилита для поиска performance and memory issues.

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

Затем был обед и после него доклад для улучшения performance на .net core. Приглушенный свет, сытный обед и убаюкивающий тембр докладчика практически погрузили в сон большую часть зала.

После - доклад про отладку wcf сервисов. Много специфической информации полезной для тех, кто работает с этой технологией.

И завершающий доклад про архитектуру микросервисов. Полностью перевернул у меня представление о данном подходе и заслуживает отдельной статьи в блоге.

Ночь 2. Думская

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

День 3. Дорога к морю

День третий ознаменовался поисками выхода к морю, которые не увенчались успехом. Лишь удалось вдохнуть бриз на мосту к Васильевскому острову. Вот такими насыщенными и полезными получились эти три дня.

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

А вообще чаще ходите, ездите, летайте на конференции - это не только новые знания, но и отличный тим билдинг.

Автор: Рита Лютикова

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

Все знают карты гугла и яндекса. На своём проекте мы используем оpen-source аналог, а именно карты OpenStreetMap. Они не такие детальные как карты от гугла, но никаких ограничений на лицензию работы с ними нету, и они бесплатны в использовании.

Один из наших проектов - Street View Service для Нигерии, проект MoRiWo. Повторюсь, в качестве основной карты используется OpenStreetMap, в качестве панорамных изображений – уникальные снимки города Лагоса. Добавив более 80 тысяч панорамных изображений и наложив их на карту OpenStreetMap, мы столкнулись с проблемой, что некоторых совсем маленьких улиц на карте просто не существует.

Например, в реальности к улице Raymond Njoku Rd прилегает несколько переулков.

Панорамы для данных улиц уже загружены в систему, но ссылаются на пустое место на карте. Поэтому перед нами встал вопрос: - «Удалить панорамы из системы?...» - «Пожалуйста, дорисуйте улицы на OSM-карте. Ведь на Google Maps они есть» - попросил клиент...

Просьба оказалась не такой невыполнимой, как показалось на первый взгляд. На помощь к нам пришел онлайн редактор OpenStreetMap под названием iD. Данный сервис доступен с 2013 года. С помощью него на карту можно добавлять и редактировать точки, линии (улицы), полигоны (здания), отношения и их теги. Изменения, сделанные на карте, будут доступны в общем доступе уже через несколько минут .

Таким образом, добавить недостающие улицы на карту не составляет большого труда: 1. Заходим на openstreetmap.org. Чтобы стать «Правщиком» - необходимо зарегистрироваться. Ведь мир должен знать своих героев ☺ 2. Чтобы начать править карту - нужно выбрать “Правка”-> “Править с помощью iD” в главном меню сайта

3. Откроется карта в режиме редактирования с видом со спутника. Здесь мы и поняли, почему улиц до сих пор нет. Со спутника их совсем не видно.

4. С помощью функции «Настройка слоев», мы нашли более четкие снимки данной области и убедились, что эти улицы действительно есть.

5. Чтобы нарисовать улицу необходимо выбрать «Линия» и поместить ее в нужное место.

6. Далее вводим название улицы, добавляем теги

7. Жмем на «Сохранить» и оставляем комментарий к правке. Вопреки ожиданию долгой модерации, улица “Benson Close” появилась на основной карте в течение нескольких минут.

Так мы познакомились с полезным сервисом правки карт - OpenStreetMap iD, нашли решение проблемы на своем проекте и внесли небольшой вклад в мировую карту.

PS. Спасибо требовательному клиенту и Юре Щеголеву за быструю реакцию на проблему.

Автор: Ксения Попова

23 января часть нашей команды решила провести выходной вместе (не хватает нам времени насладиться друг другом в будние дни) и сходить на Agile.by Gathering. Буду называть это meet up, т.к. слово «конференция» для сего мероприятия звучит достаточно громко. Как понятно из названия, посвящались все доклады Agile и тому, как круто использовать эту методологию.

Говоря в общем, однозначно было полезно послушать опыт и практики других компаний, понять в очередной раз, что в целом-то и общем процессы на здравом смысле – самые правильные процессы. Не все, конечно, подходит для нашей команды, т.к. agile лучше ложится на продуктовые компании. А при работе с заказчиками появляются те самые «неблагоприятные условия», про которые рассказывал Андрей Дворецкий из Support.by.

Как нам показалось, команды, использующие agile, достаточно категорично отзываются о том же waterfall как о пережитке прошлого. Если грамотно построить процесс, то и тот же waterfall может стать гибким и удобным для работы. Но об этом мы можем рассказать, если сами в следующий раз выступим на Agile.by Gathering :)

Из всех прослушанных докладов, как ни удивительно, больше всех понравился кейноут мероприятия Тимофей Евграшин, который рассказывал нам о том, в какой момент лучше всего принимать решения. Было приятно осознать, что все тем же здравым смыслом мы дошли до того, что называют умными словами LRM или JIT. Да и вообще было приятно послушать грамотно составленный и презентуемый доклад.

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

Ну а в остальном… с интересом ждем, что же представит нам секретный старт-ап Juno, спасибо Игорю Хрол из Toptal за доклад по тестированию, натолкнул на несколько полезных идей.

Сэндвичи были очень вкусные – это надо отметить отдельно, особенно с лососем. Виски – не знаю, была за рулем :)

Автор: Михаил Шишло 

В один прекрасный день, примерно в обед, ко мне подошел тех. лид, и сказал: «Вот тебе, Миша, доступ по ssh на линуксовую машину, нужно развернуть сайт на wordpress к концу дня». Как бы так сказать... Настройка серверов – это не совсем мой конек, а до этого момента с wordpress я вообще только как читатель блогов сталкивался, поэтому я отнесся с некоторой долей скептицизма к поставленным к задаче срокам.

Однако в моей памяти на долю секунду всплыло слово docker. О данном инструменте я услышал впервые на одном из докладов митапа 4front. В нем речь велась о том, что с помощью докера можно создать рабочее окружение буквально за несколько минут. То, что нужно. И это еще раз подтверждает тот факт, что посещение митапов и конференций – это не всегда пустая трата времени.

Итак, с чего начать. Конечно, с установки докера. Стоит отметить, что установка идёт на чистую, только установленную версию ubuntu server v14. И тут нас ждет первый сюрприз. Для установки последней версии докера на ubuntu одного apt-get не достаточно. Следует выполнить следующую магию:

sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 
36A1D7869245C8950F966E92D8576A8BA88D21E9
sudo sh -c "echo deb https://get.docker.io/ubuntu docker main > /etc/apt/sources.list.d/docker.list"
sudo apt-get update
sudo apt-get install lxc-docker

Отлично, docker установлен, можно качать образы. Для wordpress, как пить дать, нужна база. Для нашего сайта достаточно mysql. Поэтому качаем два образа один для mysql и второй для wordpress – это следующие 2 команды:

sudo docker pull mysql
sudo docker pull wordpress

Супер, теперь осталось запустить контейнера для mysql и для wordpress – для этого предназначены такие команды:

sudo docker run --name wp-db -e MYSQL_ROOT_PASSWORD=mysecretpassword -d mysql

 //запускает контейнер для mysql

sudo docker run --name web --link wp-db:mysql -p 80:80 -d wordpress

// запускает контейнер для wordpress

Заходим по 80 порту и нас там ждет скрин создания wordpress сайта.

Вот так вот. Т.е если пренебречь танцами с бубном для установки докера на ubuntu, то, чтобы создать рабочее окружение, потребовалось выполнить всего 5 команд. Пять, Карл!!!

apt-get install docker.io
docker pull mysql
docker pull wordpress
docker run --name wp-db -e MYSQL_ROOT_PASSWORD=mysecretpassword -d mysql
docker run --name web --link wp-db:mysql -p 80:80 -d wordpress

Такс, нам надо закачать исходники на контейнер с установленным wordpress. Установливать git в контейнер желания нету, поэтому решаю сделать shared папку с хостовой машиной. И тут ждет сюрприз номер 2: менять параметры в уже созданных контейнерах не получится. Поэтому приходится удалять контейнеры и заново их создавать, добавляя следующую опцию для shared папки:

docker run --name wp-db -e MYSQL_ROOT_PASSWORD=mysecretpassword -v 
/home/ubuntu/src:/external/src

А стартует ли докер автоматом после перезагрузки? Нет, конечно. Ну, удалять и создавать контейнеры мы уже умеем… Добавляем еще одну опцию для автоматического рестарта:

docker run --name wp-db -e MYSQL_ROOT_PASSWORD=mysecretpassword --restart=always

Итак, окончательный вид команд для контейнеров такой:

docker run --name wp-db -e MYSQL_ROOT_PASSWORD=mysecretpassword 
--restart=always -v /home/ubuntu/src:/external/src -d mysql

docker run --name web --link wp-db:mysql -p 80:80 --restart=always -v 
/home/ubuntu/src:/external/src -d wordpress

Наступает еще один не менее прекрасный день. В обед подходит снова тех. лид и говорит: «Нужно нам тестовое окружение для проекта на wordpress». Я ему отвечаю: «Ты не успеешь дойти до своего стола, как уже будет готово!» – всего-то 2 команды выполнить.

И, действительно, 2 команды выполнены и еще 2 докер контейнера запущены на машине. И тут ждет сюрприз номер 3, самый неприятный, и я б сказал просто отвратительный.

4 запущенных докер контейнера просто отъели всю оперативную память (768 Mb) так, что по ssh попасть на сервер не представлялось возможным. А так как для тестовых контейнейров так же была установлена опция автоматического запуска, попасть на машину так и не удалось даже после перезрузки. Пришлось заново создавать сервер, благо на amazon это занимает не так много времени.

Чтобы обойти это проблему, было решено запустить один контейнер c mysql и там уже создать 2 базы – одну для продакшн сайта, а вторую для тестового. А также был выставлен memory limit для тестовогого сайта в 256Mb. Для этого есть опция:

docker run --name test-web --link wp-test-db:mysql -p 80:80 --restart=always -v 
/home/ubuntu/src:/external/src -d wordpress -m 256M

Что можно сказать в качестве вывода?

1. Если Вам нужно развернуть промышленную среду, а у Вас мало времени или Вы не умеете этого делать, то используйте докер.
2. Если Вам нужно одинаковую тестовую или девелопмент среду раздать всем членам команды, то используйете докер.
3. Если Вы хотите создать образ своего окружения, чтобы потом была возможность перенести на другой физичиский сервер, то используйте докер.
4. Если у Вас на сервере развернуто несколько независимых друг от друга систем, у которых входы и выходы должны быть под контролем для того, чтобы обеспечить их безопасность, используйте докер.

Автор: Сергей Кулага

Один из наших проектов построен на NodeJS c использованием фреймворка Sails.js, базы данных MongoDB, системы обмена сообщений RabbitMQ, и поискового движка ElasticSearch, используются юнит тесты на основе Mocha. Приступили к разработке, вроде и работает, и можно собрать приложение на тестовый сервер и запустить тесты, но все это надо делать вручную и очень утомительно.

Было решено использовать для автоматизации TeamCity. Был использован сервер на Ubuntu, установка компонентов ничем не примечательна, можно только упомянуть, что NodeJS запускается через Forever. Forever нужен для того, чтобы запускать приложение в виде демона, forever проверяет его доступность и перезапускает в случае остановки приложения.

Подготовка на сервере

У нас приложение состоит из двух больших частей: WebSite и WorkHorse, последний используется для выполнения задач по расписанию и обработки задач из очереди (например отсылка писем, индексация, и другое). Эти две части могут масштабироваться независимо друг от друга. Для простоты мы предположим, что у нас только WebSite и один WorkHorse.

Предположим, что приложение работает из-под директории /home/user/node/app/dev.

Для начала создадим два скрипта для запуска и остановки приложения через Forever

start.sh (запуск приложения)

export NODE_ENV=vm-node-dev now=$(date +"%Y_%m_%d--%H-%M-%S") if [ $(forever list | grep dev-website | grep -v grep | wc -l) -eq 0 ] then cd /home/user/node/app/dev/WebSite forever start --uid "dev-website" -l "logs/dev-website-$now.log" app.js fi if [ $(forever list | grep dev-workhorse | grep -v grep | wc -l) -eq 0 ] then cd /home/user/node/app/dev/WorkHorse forever start --uid "dev-workhorse" -l "logs/dev-workhorse-$now.log" app.js fi

Поясение по скрипту запуска

export NODE_ENV=vm-node-dev - задание имя конфигурации, этот параметр используется концигураций как sails.js так и билиотекой config.js if [ $(forever list | grep dev-website | grep -v grep | wc -l) -eq 0 ] проверка запущено ли приложение, forever start --uid "dev-website" -l "logs/dev-website-$now.log" app.js запуск app.js с именем “dev-website” и логгирование в определенную панку (по умолчанию запись консольного вывода из nodejs происходит в файл с автогенерируемым именем, например, 6n71.log, что не очень удобно, поэтому запись логов перенаправлена в dev-website-$now.log). Логи содержат всю информацию, которую приложение выводит на консоль.

stop.sh (Остановка)

if [ $(forever list | grep dev-website | grep -v grep | wc -l) -ne 0 ] then forever stop dev-website fi if [ $(forever list | grep dev-workhorse | grep -v grep | wc -l) -ne 0 ] then forever stop dev-workhorse fi

Установим права для запуска

chmod 700 dev-start.sh chmod 700 dev-stop.sh

Установим автозапуск через crontab

Для установки автозапуска можно добавить start.sh в crontab, например так @reboot /home/user/node/app/start.sh

Резюмируя этот раздел, мы добавили в автозагрузку запуск node.js веб-систем и их автоматический перезапуск в случае падения.

Настройка TeamCity

TeamCity - это билд контроллер, который крутится на отдельном сервере. В нашем случае на корпоративном Windows сервере. Напомню, что сама веб-система находится на другом Linux сервере.

Для копирования данных на Ubuntu сервер и запуска команд по SSH из TeamCity необходимо установить Deployer plugin.

Каждый билд всегда полностью берет версию из source control. Для этого был установлен флаг Clean build на вкладке Version Control Settings. Затем уже скачиваются пакеты nmp и bower. Таким образом, мы всегда имеем чистую последнюю версию. Получение последней версии и скачивание занимает 20-30 секунд, благо, интернет не медленный и размер проекта пока не большой. При желании можно не очищать что, но хотелось иметь всегда чистую версию.

Для тестов используется фреймворк mocha. Для того чтобы TeamCity отображал результаты тестов, используется пакет mocha-teamcity-reporter.

Итак, мы создали два билда:

1. Сборка и запуск автоматических тестов

Этот билд автоматически запускается после каждого checkin-а и прогоняет все тесты. Собирается быстро и используется в основном для контроля прогона тестов.

Список шагов в билде после того как с гита скачана последняя версия сорс кода:

2. Разветывание на тестовом окружении

Список шагов в втором билде:

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

Выводы:

1. Внедрять Continuous Integration следует на самых ранних этапах разработки, можно сразу после создания структуры проекта. Это позволит существенно сократить время на развертывание билдов для тестового и в дальнейшем проще перенести для продакшен окружения.
2. Для проекта на Node.js написание тестов как юнит, так и интеграционных - это “must have” практика, так как нет компиляции проекта и сложно выявлять опечатки.
3. В зависимости от задач можно использовать и другие подходы и инструменты, главное, чтобы все работало без ручного труда, было просто и устраивало команду.
4. Хотя TeamCity на моей практике больше применяется с проектами на .NET или JAVA, мы с успехом используем уже знакомый инструмент и для других языков.

Денис Колошко, технический директор:

Недавно участвовал в роли консультанта в расследовании инцидента взлома сервера, на котором крутится бизнес-система клиента.Как взломать бизнес-систему, если сама по себе она хорошо написана. Одним из вариантов — попытаться взломать её через другие системы, стоящие на этом же сервере.А на этом же сервере стоял ещё сайт-визитка клиента на базе WordPress-а. Во время исследования мы обнаружили бэкдор в WordPress сайте, установленном через инфицированный плагин. По логам видно время его установки и использования.

Что собой бэкдор представляет. Это один PHP файл, который позволяет анонимному пользователю возможность чтения записи всей файловой системы, возможности туда записи, автоматический сбор информации со всех «интересных» файлов, выполнение shell команд, запуск perl скрипт с отсылкой данных на определённый адрес и много чего интересного. Т.е. в купе с плохо настроенными правами на файловую систему для пользователя, под которым Вордпресс сайт работает, мы получаем полный контроль над системой. Добраться до бизнес-системы, если ты уже имеешь доступ на сервер, проблем не составляет.

Бэкдор взят отсюда http://www.exploit-db.com, и, кстати, имеет удобный UI интерфейс.

Долго думал выложить ли код этого бэкдора, а потом решил, что это может быть хороший инструмент для администратора, для проверки безопаности развёрнутой системы. Плюс если у вас есть PHP сайт, проверьте его на наличие похожего кода.
Код бэкдора: bwc.php.txt

Выученные уроки

  1. Нужно 100 раз подумать, прежде чем рядом с бизнес системой ставить системы со слабой безопаностью, типа вордпресса, джумлы, разных cms-ок

  2. Принцип минимальных привилегий. Пользователь, под которым сайт работает, в идеале должен иметь доступ только на папку сайта на чтение, и только в определённые подпапки на запись

  3. Безопасный деплоймент тоже нужно планировать заранее

  4. Для защищённых систем стоит планировать настройку файервола не только на входящий трафик на сервере, но и на исходящий, дабы предотвратить утечки данных непосредственно с сервера

- See more at: http://it-band.by/php-backdoor/#sthash.nk3OzGdg.dpuf