На последнем вебинаре нас просили рассказать, как мы работаем с логами с помощью monit.d.
Хоть и с большой задержкой, все же отвечаем.

Это — статья-roadmap-cheatsheet для изучающих Ruby. Вместо того, чтобы рассказывать очередной how-to я постараюсь расписать все те вещи, которые, на мой взгляд, можно изложить кратко и емко, с упором на то, что программисту пришедшему с других языков и платформ может показаться не очевидным, антипоисковым и просто затратным по времени на изучение без подсказок — на остальное просто дам ссылки. Не смотря на то, что в природе существует множество туториалов/кастов/книг/чего угодно по чему угодно — именно такого формата мне самому всегда не хватает. И по сути, это те вещи, которые чаще всего рассказываю при вопросах «а как оно вообще?», «с чего начать?», «а как делается такая вот штука?», «а какой gem лучше?». Кстати, пока работал над этой статьей на Хабре появилась похожая про Python — видимо, идея витает в воздухе.

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



Сервис LinkedIn был запущен в 2003 году с целью создания и поддержания сети деловых контактов и расширения возможностей поиска работы. За первую неделю в сети зарегистрировалось 2 700 человек. Спустя несколько лет число продуктов, клиентская база и нагрузка на серверы заметно выросли.

Сегодня в LinkedIn насчитывается более 350 миллионов пользователей по всему миру. Мы проверяем десятки тысяч веб-страниц каждую секунду, каждый день. На мобильные устройства сейчас приходится более 50% нашего трафика по всему миру. Пользователи запрашивают данные из наших бэкенд-систем, которые, в свою очередь, обрабатывают по несколько миллионов запросов в секунду. Как же мы этого добились?

Capistrano — любимый многими rails-разработчиками инструмент, с помощью которого можно быстро и без заморочек автоматизировать развертывание вашего приложения. Capistrano — стандарт де-факто для системы развертывания RoR, must-know технология для любого уважающего себя рубиста, тот инструмент, которому в своё время завидовали разработчики на python и PHP.
Несмотря на комфорт, от которого не хочется отказываться, чем более сложные задачи мне приходилось решать, тем чаще Capistrano показывал себя к ним не приспособленным.

Я отметил следующие недостатки:

• Известные проблемы со скоростью. Вследствие своей универсальности, Capistrano деплоит медленно, выполняя лишние проверки и вызовы, которые вы не всегда можете контролировать.
• Последовательный деплой. Небыстрое время развертывания нужно умножить на количество целевых серверов (однако, можно настроить распараллеливание комманд явным образом).
• Сильная связанность с рельсами. Конфиги и зависимости Capistrano переплетаются с приложением, становясь его частью. Нельзя создать новое окружение-развертывания (например сервера для раннего выкатывания функционала) без создания нового rails-окружения. В сложных ситуациях Capistrano заставляет уходить от хорошей практики держать только development, test и production окружения.
• Плагины — палка о двух концах. Давая возможность быстро “прикрутить” развертывание той или иной зависимости приложения, плагины лишают вас контроля ситуации, заставляют действовать так, как действует разработчик плагина. О влиянии лишних “телодвижений” плагинов на скорость деплоя я написал выше.
• Сложный деплой гетерогенных приложений. Трендом последних лет в рельсах стало выделение самых тяжелых (бекграундных или сетевых) задач в отдельные сервисы, не обязательно написанные на ruby. В такой ситуации capistrano заставляет вас плодить зоопарк из разных систем развертывания для разных языков и технологий.

Многие ruby-разработчики перешли на Mina или решают свои проблемы с помощью ещё более сложных систем управления конфигурациями вроде Chef и Puppet. Все они имеют свои особенности и недостатки и в разной степени решают описанные выше проблемы. Мне же удалось их решить их с помощью Ansible, не растеряв преимуществ Capistrano, к которым я привык.

Ansible это инструмент для управления конфигурациями и в его задачи входит не только описанное в этой статье выполнение удаленных команд на серверах для развертывания и управления отдельным приложением, но и автоматизация серверного администрирования посредством хранимых серверных конфигураций (ролей на языке Ansible). А значит Ansible (как впрочем и Chef и Puppet) позволяет гораздо больше, чем Capistrano и в конечном счете они все не идут с ним ни в какое сравнение. Однако, задача этой статьи дать rails-разработчикам отправную точку для миграции и разъяснить на этом примере основы Ansible. В конце этой статьи, волшебная команда cap production deploy превратится в ansible-playbook deploy.yml -i inventory/production
Кому интересно как — прошу под кат.

До недавнего времени в Одноклассниках в качестве основного Linux-дистрибутива использовался частично обновлённый OpenSuSE 10.2. Однако, поддерживать его становилось всё труднее, поэтому с прошлого года мы перешли к активной миграции на CentOS 7. На подготовительном этапе перехода для CentOS были отработаны все внутренние процедуры, подготовлены конфиги и политики настройки (мы используем CFEngine). Поэтому сейчас во многих случаях миграция с одного дистрибутива на другой заключается в установке ОС через kickstart и развёртывании приложения с помощью системы деплоя нашей разработки — всё остальное осуществляется без участия человека. Так происходит во многих случаях, хотя и не во всех.

Но с самыми большими проблемами мы столкнулись при миграции серверов раздачи видео. На их решение у нас ушло полгода.

Предыстория

На создание этой статьи меня толкнула недавняя публикация о деплое. В приведённой статье описан способ разворачивания проекта на основе rbenv, я же опишу ситуацию с rvm и настройкой upstart.

Задачи и требования

Итак, дано: простейшее RubyOnRails-приложение. В случае разворачивания своего проекта я ставил перед собой следующие задачи:

• ОС Ubuntu LTS 14.04;
• Веб-сервер Nginx;
• Сервер приложения Puma;
• Использование RVM для установки ruby требуемой версии;
• Автоматический запуск приложения при запуске VPS-сервера, возможность управлять приложением как службой;
• Автоматизация процесса деплоя с помощью mina;

Почему Ubuntu?
Просто я к ней привык (точнее к её производной — Linux Mint).

Почему puma, а не unicorn или passenger?
О пуме я слышал неплохие отзывы, а у unicron страшненький сайт. Passenger, на мой взгляд, нарушает принцип единственной обязанности — я хочу иметь веб-сервер и приложение-сервер.

Почему RVM?
Я к нему привык — у меня он установлен на локальной машине, хочу его видеть и на production.

Почему mina?
Она действительно проще чем capistrano и при этом быстрее. Скорость достигается за счёт того, что для каждой задачи capistrano создаёт отдельное ssh-соединение. Mina же формирует shell-скрипт и выполняет его в рамках одного соединения.

В данном случае задача легко разбивается на 3 этапа:

1. Убедиться, что приложение корректно запускается (пока без автоматизации);
2. Настроить сервер так, чтобы наше rails-приложение работало как полноценная служба;
3. На основе этого настроить автоматизированное разворачивание с помощью mina.

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

За последний год в Docker Hub стало доступно уже более 100 000 образов, а загружались образы с Docker Hub уже более 300 миллионов раз. Из них более 20 миллионов загрузок пришлись на 70 официальных образов разработчиков Docker, таких как Oracle, CentOS и NGINX.

NGINX используется на более 40% самых больших сайтов в мире, не только как веб-сервер, но и как реверс-прокси сервер, балансировщик нагрузки и HTTP кэш. Официальный образ NGINX был загружен 3.4 миллиона раз.



В этой статье вы узнаете:

• как развернуть и использовать Docker-образ с NGINX.
• как быстро развернуть реверс-прокси на NGINX и несколько сайтов в Docker
• как развернуть геораспределенную инсталляцию, состоящую из нескольких сайтов и реверс-прокси в каждом из 3х регионов InfoboxCloud.

Если раньше вы не использовали Docker, рекомендуется к прочтению:
Используем Docker и не волнуемся о vendor-lock
Погружаемся в Docker: Dockerfile и коммуникация между контейнерами
Обзор новшеств Docker Engine с 1.0 до 1.8. Введение в Docker Compose

В конце статьи мы раздаем пробные версии InfoboxCloud бесплатно.

Docker — технология, вокруг которой нынче огромное количество хайпа. «Shitstorm» — именно таким словом окрестил в твиттере докеровые войны один из моих немецких знакомых. Ну и конечно, вместе с «Microservices» и «Reactive», слово «Docker» прочно вошло в тройку ведущих айтишных баззвордов последних двух лет.

Неделю назад на московской встрече CodeFreeze Александр aatarasoff Тарасов из Альфа-Лаборатории (подразделение Альфа-банка) рассказал от том, как они внедряли у себя Docker, какой получили профит, какую боль и т.п. Интрига в том, что, с одной стороны, Альфа-банк — это банк, то есть, «кровавый энтерпрайз». С другой стороны… внедрили же.



Под катом — короткое описание того, о чем рассказал нам Александр и видеозапись его выступления.

Столкнулись с задачей: полностью пустой сервер, настраивать полностью через ansible, «так что бы даже обезьяна» справилась", — дословная цитата клиента.
Исходные данные: есть сервер, с ОС СentOS 7, внешним IP и паролем root.
Задача: установить на него все обновления, ПО по списку и ни разу к нему не подключиться консолью. Весь процесс описывать нет смысла, но есть два интересных момента о которых я и расскажу. А именно, как с помощью ansible настроить ansible и как перезагрузить сервер, а потом продолжить выполнять palybook.

Ранее публиковал первую часть, в которой описывались общие сведения о RAID контроллерах (азы читать здесь), были вопросы и интерес, выкладываю уже «мясной» кусок. Здесь всё очень конкретно – подробная классификация контроллеров Adaptec, функции каждой серии контроллеров, таблицы, картинки и т.д.

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

В этой статье я опишу установку и настройку Active/Active кластера на основе Pacemaker, Corosync 2.x и CLVM с использованием разделяемого хранилища. Покажу, как приспособить этот кластер для работы с контейнерами LXC и Docker. Опишу команды для работы с кластером. И припомню те грабли, в которые вляпался, что, надеюсь, облегчит судьбу следующим проходимцам.

В качестве серверных дистрибутивов буду использовать CentOS 7 + epel и актуальные версии пакетов в них. Основной инструмент для работы с Pacemaker-ом будет PCS (pacemaker/corosync configuration system).

В прошлых статьях мы уже рассматривали что такое Docker и как использовать Dockerfile и осуществлять коммуникацию между контейнерами.



Эти статьи были написаны по Docker 1.1.2. С тех пор в Docker появилось много полезного, о чем мы расскажем в этой статье. Также мы рассмотрим подробнее Docker Compose, утилиту, позволяющую определять мультиконтейнерное приложение со всеми зависимостями в одном файле и запускать это приложение в одну команду. Примеры будут продемонстрированы на облачном сервере в InfoboxCloud.

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

Первое, что я заметил — множество советов как все настроить под большую нагрузку. Читайте их внимательно, обычно в тексте найдете, что речь про «высокую нагрузку» в 15-20 тысяч клиентов в сутки. У нас клиентов примерно миллион, активных, ежедневных.

У нас нет денег и мы все делаем за свой счет, поэтому экономим. Итог — весь миллион клиентов обслуживается на одном сервере, вот на таком — EX-60 на hetzner.

Здравствуйте. Хочу поделиться с хабровчанами своим опытом развертывания кластера Postgres-xl в виде мини-инструкции для «чайников». Статей и мануалов на тему развертывания кластера postgres-xl не то чтобы много, но достаточно. И в них всех есть пару существенных недостатков на взгляд такого человека как я, который никогда прежде не занимался кластеризацией и тем более никогда прежде не работал в линукс-подобных осях. Все статьи подобного рода написаны для людей уже более-менее знакомых с линуксом и развертыванием postgresql/postgres-xl на таком окружении.

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

Так как много статей «для опытных» уже написано, и на хабре тоже, я опущу описание самого Postgres-xl, его компонентов и их типов (ролей).

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

Краткое описание гема и дополнительные ссылки ожидают вас под катом.

Привет Хабр! Последние 1.5 года я работал над своим проектом, которому был необходим надежный облачный хостинг. До этого момента я больше 10 лет занимался веб-программированием и когда я решил построить свой хостинг у меня были относительно поверхностные знания в этой области, я и сейчас не являюсь системным администратором. Все что я буду рассказывать может выполнить обычный программист в течение 5 минут, просто запустив набор сценариев для Ansible, которые я подготовил специально для вас и выложил на GitHub.

Добрый день.

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

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

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

Почему? Maxifier представляет собой SaaS-продукт с клиентами в США, Бразилии, в нескольких странах Европы и в Японии, так что у нас около сотни серверов, раскиданных по всему миру. Для оперативной работы нам необходимо иметь удобный доступ к логам наших приложений и быстрый поиск ошибок в них в случае проблем на сторонних сервисах/api, появления некорректных данных т.д. Кстати, похожей системой сборки логов пользуются The Guardian (одни из наших клиентов).

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

Bareos (Backup Archiving Recovery Open Sourced) является централизованной, клиент-серверной и кроссплатформерной системой для резервного копирования, архивирования и восстановления данных.



Является форком Bacula и активно развивается. Имеет клиенты под Linux и Windows. Полный список поддерживаемых фич на Github.