Docker в значительной мере изменил подход к настройке серверов, поддержке и доставке приложений. Разработчики начинают задумываться о том, можно ли архитектуру их приложений разделить на более мелкие компоненты, которые будут запускаться в изолированных контейнерах, что позволит достичь большего ускорения, параллелизации исполнения и надежности. Также Docker решает важную проблему снятия облачного vendor–lock и позволяет легко мигрировать настроенные приложения между собственными серверами и облаками. Все что требуется от сервера, чтобы запустить Docker – более-менее современная ОС Linux с ядром не ниже 3.8.

В этой статье мы расскажем о том, как просто использовать Docker и какие преимущества он даст сисадмину и разработчику. Забудьте про проблемы с зависимостями, запускайте на одном сервере софт, требующий разные дистрибутивы Linux, не бойтесь «загрязнить» систему неправильными действиями. И делитесь наработками с сообществом. Docker решает множество актуальных проблем и помогает сделать IaaS гораздо более похожими на PaaS, без vendor-lock.



На облачных VPS от Infobox мы сделали готовый образ Ubuntu 14.04 с Docker. Получите бесплатную пробную версию (кнопка «Тестировать 10 дней») и начните использовать Docker прямо сейчас! Не забудьте поставить галочку «Разрешить управление ядром ОС» при создании сервера, это требуется для работы Docker. В самое ближайшее время у нас появятся и другие ОС с Docker внутри.

Под катом вы узнаете, что же в Docker настолько воодушевило автора статьи, что за пару дней он перевел свои облачные сервера, автоматизирующие части процесса разработки, в контейнеры Docker.

В моем случае, в качестве frontend сервера, стоит nginx и формат access-лога имеет вид:

log_format main '$remote_addr — $remote_user [$time_local] "$host" "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for" -> $upstream_response_time';

Что на выходе дает что-то вроде такой строки:

188.142.8.61 — - [14/Sep/2014:22:51:03 +0400] «www.mysite.ru» «GET / HTTP/1.1» 200 519 «6wwro6rq35muk.ru» «Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.191602; .NET CLR 3.5.191602; .NET CLR 3.0.191602» "-" -> 0.003

1. tail -f /var/log/nginx/nginx.access.log | cut -d ' ' -f 1 | logtop

Позволяет получить общую картину: распределение уникальных IP, с которых идут запросы, кол-во запросов с одного IP и т.д.
Самое ценное — что все это работает в режиме реального времени и можно мониторить ситуацию, внося какие-либо изменения в конфигурацию (например просто забанить ТОП 20 самых активных IP через iptables или временно ограничить географию запросов в nginx через GeoIP http://nginx.org/ru/docs/http/ngx_http_geoip_module.html).

Образы Docker могуть быть очень большими. Многие превышают 1 Гб в размере. Как они становятся такими? Должны ли они быть такими? Можем ли мы сделать их меньше, не жертвуя функциональностью?

В CenturyLink Lab мы много работали над сборкой различных docker-образов в последнее время. Когда мы начали экспериментировать с их созданием, мы обнаружили, что наши сборки очень быстро раздуваются в объеме (обычным делом было собрать образ, который весит 1 Гб или больше). Размер, конечно, не столь важен, если мы говорим про образы по два гига, лежащие на локальной машине. Но это становится проблемой, когда вы начинаете постоянно скачивать/отправлять эти образы через интернет.

Я решил, что стоит копнуть поглубже и разобраться с тем, как работает процесс создания docker-образов, чтобы понять, что можно сделать для уменьшения размера наших сборок.

В жизни каждого умного дома возникает закономерный вопрос – как маленький нежный микроконтроллер своими пятью вольтами сможет коммутировать 220 вольт переменного тока?

Самый простой вариант – реле. Тут вам и гальваническая развязка, и замыкаешь что хочешь, хоть постоянный, хоть переменный, мало, много. Но и минусы у реле очень неприятные.

Первый – щелкает. Раздражает. Да, человек – штука такая, ко всему приспособится, и можно привыкнуть, но зачем привыкать к плохому?

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

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

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

Лучше поздно, чем никогда. Я наконец понял свою ошибку, и теперь начну с того, с чего обычно начинаются все книги — с оглавления.
Структурное представление умного дома:

Назрела необходимость замены медленного rdiff-backup на более шустрое решение для инкрементальных бекапов на удаленый сервер. Сперва рассматривался Rsnapshot, но причине того, что он не умеет без костылей делать бекапы именно на удаленные серверы от него отказались. Прочие аналоги нам также не подошли по тем или иным причинам. Искать что-то готовое на просторах github и допиливать под себя мы не захотели, поэтому было решено написать новый скрипт с нуля своими силами. Главная цель сделать решение для инкрементального бекапа на удаленный сервер схожее с rdiff, но с использованием жестких ссылок rsync.

     Доброго времени суток, уважаемые читатели. В этом посте я хотел бы описать несколько примеров развертки mongoDB, отличия между ними, принципы их работы. Однако больше всего хотелось бы поделиться с вами практическом опытом шардирования mongoDB. Если бы этот пост имел план, он бы выглядел скорее всего так:

1. Вступление. Кратко о масштабировании
2. Некоторые примеры развертки mongoDB и их описание
3. Шардинг mongoDB

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

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

Для мониторинга наших подопечных мы используем Zabbix.
Так почему бы не приспособить сей дивный инструмент и для этой задачи.
Ведь было бы очень удобно ткнуть в карте Zabbix на нужную стойку, перейти на её подкарту и, выбрав железку,
запустить локальный ssh/telnet/vnc клиент на своем компьютере.

Озадачившись идеей, я начал мучать поисковые машины в надежде отыскать варианты реализации.
Был найден данный тред на форуме Zabbix, но мне хотелось запускать именно локальные программы на моей машине кликом по ссылке в карте.
Еще некоторое время поплутав по закоулкам всемирной паутины и помучав знакомых программистов глупыми вопросами я вспомнил о… Python.
Да, Python, не раз пришедший на помощь в трудную минуту.
Питаю очень нежные чувства к этому языку за его простоту и приятный теплый синтаксис.

И так, вектор атаки изменился и поисковики замерли в ожидании нового вброса мыслеобразов…
Спустя некоторое время я уже четко представлял как буду решать задачу — напишу клиент-серверное приложение!
На моем компьютере будет ждать команд серверная часть, а на сервере мониторинга, при клике по ссылке, будет запускаться клиент и передавать нужную команду.

Результатом изысканий стало кроссплатформенное приложение, работает как на Linux, так и на Windows.
Эпопея проб и ошибок на пути к заветной цели ждет вас под хабракатом.

Данная заметка является переводом статьи из блога компании Scout. В статье дается простое и наглядное объяснение такого понятия, как load average. Статья ориентирована на начинающих Linux-администраторов, но, возможно, будет полезна и более опытным админам. Заинтересовавшимся добро пожаловать под кат.

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

1. Заходим в chrome://flags.
2. Находим пункт «Enable Instant Extended API» / «Включить расширенный API Живого поиска» и выбираем Disable/Отключено.
3. Нажимаем кнопку Restart/Перезапустить в полоске, появившейся внизу окна.
4. Profit!

Вот и настал тот день, когда пришлось отложить в сторону кукбуки, рецепты, нож шеф-повара и немного позаниматься кукловодством.
Для начала постановка задачи довольно тривиальная — организовать для девелоперов возможность быстро и просто разворачивать окружение. Обязательное требование — для автоконфигурации использовать Puppet Enterprise

Некоторое время назад, в силу определенных причин, мне пришла в голову мысль о том, чтобы начать изучать какой-нибудь новый язык программирования. В качестве альтернатив для этого начинания я определил два языка: Java и Python. После продолжительного метания между ними и сопутствующих нытья и долбежки головой о стену (у меня с новыми языками всегда так — сомнения, раздумья, проблема выбора и т.д.), я все-таки остановился на Python. Окей, выбор сделан. Что дальше? А дальше я стал искать материал для изучения…

В данной статье будет по шагам разобран процесс создания небольшого кластера Hadoop для опытов.

Несмотря на то, что в интернете на иностранных ресурсах есть полно материала про настройку/развертывание Hadoop, большинство из них либо описывают настройку ранних версий (0.X.X и 1.X.X), либо описывают только настройку в режиме single mode/pseudo distributed mode и лишь частично fully distributed mode. На русском языке материала практически нет вовсе.

Когда мне самому понадобился Hadoop, то я далеко не с первого раза смог все настроить. Материал был неактуален, часто попадались конфиги, которые используют deprecated параметры, поэтому использовать их нежелательно. А даже когда все настроил, то задавался многими вопросами, на которые искал ответы. Также встречались похожие вопросы у других людей.

Всем кому интересно, прошу пожаловать по кат.

Wireshark — это достаточно известный инструмент для захвата и анализа сетевого трафика, фактически стандарт как для образования, так и для траблшутинга.
Wireshark работает с подавляющим большинством известных протоколов, имеет понятный и логичный графический интерфейс на основе GTK+ и мощнейшую систему фильтров.
Кроссплатформенный, работает в таких ОС как Linux, Solaris, FreeBSD, NetBSD, OpenBSD, Mac OS X, и, естественно, Windows. Распространяется под лицензией GNU GPL v2. Доступен бесплатно на сайте wireshark.org.
Установка в системе Windows тривиальна — next, next, next.
Самая свежая на момент написания статьи версия – 1.10.3, она и будет участвовать в обзоре.

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

Начинаем плаванье

Для начала захвата достаточно выбрать свой сетевой интерфейс и нажать Start.

Добрый день уважаемые читатели. В сегодняшней посте я продолжу свой цикл статей посвященный анализу данных на python c помощью модуля Pandas и расскажу один из вариантов использования данного модуля в связке с модулем для машинного обучения scikit-learn. Работа данной связки будет показана на примере задачи про спасенных с "Титаника". Данное задание имеет большую популярность среди людей, только начинающих заниматься анализом данных и машинным обучением.

Посмотрев недавно статью, был сильно удивлен, что кто-то еще задается вопросом автоматического прописывания ДНС доменов на вторичном сервере. Хочу поделится своим вариантом «Automate slave DNS support», которым пользуюсь уже много лет. Возможно он подойдет не всем, но он довольно прост.

Давно хотел написать этот пост с подборкой полезных ссылок, так как очень часто спрашивают подобное (думаю, у многих, кто в этой (да и в других) сфере). Ссылки разбиты на категории.

Этом цикле статей «Идеальный www кластер», я хочу передать базовые основы построения высокодоступного и высокопроизводительного www решения для нагруженных web проектов для неподготовленного администратора.
Статья будет содержать пошаговую инструкцию и подойдет любому человеку кто освоил силу copy-paste
Ошибки найденые вами, помогут в работе и мне и тем кто будет читать эту статью позже! Так что любые улучшение и правки приветствуются!

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

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

На frontend мы будем использоваться связку из двух службы:

keepalived — реализации протокола VRRP (Virtual Router Redundancy Protocol) для Linux. Демон keepalived следит за работоспособностью машин и в случае обнаружения сбоя — исключает сбойный сервер из списка активных серверов, делегируя его адреса другому серверу.

Другими словами, у нас 2 сервера на которых прописано по одному публичному адресу. Если любой из этих серверов падает, то адрес упавшего подхватывается вторым.
Демоны keepalived общаются по протоколу VRRP, посылая друг другу сообщения на адрес 224.0.0.18.
Если сосед не прислал свое сообщение, то по истечению периода он считается умершим и оба адреса обслуживает оставшаяся нода. Как только упавший сервер начинает слать свои сообщения в сеть, все возвращается на свои места

nginx [engine x] — это HTTP-сервер и обратный прокси-сервер, а также почтовый прокси-сервер, написанный Игорем Сысоевым. Уже длительное время он обслуживает серверы многих высоконагруженных российских сайтов, таких как Яндекс, Mail.Ru, ВКонтакте и Рамблер. Согласно статистике Netcraft nginx обслуживал или проксировал 15.08% самых нагруженных сайтов в октябре 2013 года.

Основная функциональность HTTP-сервера

• Обслуживание статических запросов, индексных файлов, автоматическое создание списка файлов, кэш дескрипторов открытых файлов;
• Акселерированное обратное проксирование с кэшированием, простое распределение нагрузки и отказоустойчивость;
• Акселерированная поддержка FastCGI, uwsgi, SCGI и memcached серверов с кэшированием, простое распределение нагрузки и отказоустойчивость;
• Модульность, фильтры, в том числе сжатие (gzip), byte-ranges (докачка), chunked ответы, XSLT-фильтр, SSI-фильтр, преобразование изображений; несколько подзапросов на одной странице, обрабатываемые в SSI-фильтре через прокси или FastCGI, выполняются параллельно;
• Поддержка SSL и расширения TLS SNI.

Другие возможности HTTP-сервера

• Виртуальные серверы, определяемые по IP-адресу и имени;
• Поддержка keep-alive и pipelined соединений;
• Гибкость конфигурации;
• Изменение настроек и обновление исполняемого файла без перерыва в обслуживании клиентов;
• Настройка форматов логов, буферизованная запись в лог, быстрая ротация логов;
• Специальные страницы для ошибок 3xx-5xx;
• rewrite-модуль: изменение URI с помощью регулярных выражений;
• Выполнение разных функций в зависимости от адреса клиента;
• Ограничение доступа в зависимости от адреса клиента, по паролю (HTTP Basic аутентификация) и по результату подзапроса;
• Проверка HTTP referer;
• Методы PUT, DELETE, MKCOL, COPY и MOVE;
• FLV и MP4 стриминг;
• Ограничение скорости отдачи ответов;
• Ограничение числа одновременных соединений и запросов с одного адреса;
• Встроенный Perl.

Непрерывный рост данных и увеличение скорости их генерации порождают проблему их обработки и хранения. Неудивительно, что тема «больших данных» (Big Data) является одной из самых обсуждаемых в современном ИТ-сообществе.

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

Одним из самых известных и обсуждаемых проектов в области распределенных вычислений является Hadoop — разрабатываемый фондом Apache Software Foundation свободно распространяемый набор из утилит, библиотек и фреймворк для разработки и выполнения программ распределенных вычислений.

Мы уже давно используем Hadoop для решения собственных практических задач. Результаты нашей работы в этой области стоят того, чтобы рассказать о них широкой публике. Эта статья — первая в цикле о Hadoop. Сегодня мы расскажем об истории и структуре проекта Hadoop, а также покажем на примере дистрибутива Hadoop Cloudera, как осуществляется развертывание и настройка кластера.

Осторожно, под катом много трафика.

Сегодня речь пойдет о пакете Pandas. Данный пакет делает Python мощным инструментом для анализа данных. Пакет дает возможность строить сводные таблицы, выполнять группировки, предоставляет удобный доступ к табличным данным, а при наличии пакета matplotlib дает возможность рисовать графики на полученных наборах данных. Далее будут показаны основы работы с пакетом, такие как загрузка данных, обращение к полям, фильтрация и построение сводных.