Puppet *

За последние лет пять я вижу очень много статей по «удачным» рецептам построения систем деплоймента и управления конфигурацией на базе Chef/Puppet/Vagrant/Ansible. Я потратил около 7 лет на решение задач автоматического деплоймента в компании, в которой я в то время работал, и теперь считаю, что имею достаточно опыта, чтобы покритиковать многие распространенные инструменты.

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

Всем привет, недавно мы начали цикл статей о тестировании в Chef, но сегодня я расскажу о более вводных и универсальных вещах: зачем тестировать инфраструктуру, какие инструменты для этого есть и как все это автоматизировать. Также затрону тему публикации инфраструктурного кода в open source. Статья будет интересна пользователям любой из популярных систем управления конфигурацией — Chef, Puppet, Ansible или SaltStack.

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

Вот весна и перевалила через свою середину, к концу подходит апрель. Этот месяц был богат на хорошие новости от JetBrains: обновление ReSharper Ultimate, выпуск ReSharper C++ и CLion 1.0. А сегодня мы надеемся порадовать и Ruby-разработчиков. В среду, 15 апреля, вышло обновление нашей интеллектуальной среды для разработки на Ruby и Rails — RubyMine 7.1. Прежде всего, в новой версии мы усовершенствовали поддержку Puppet, кроме того уделили много внимания JavaScript и CoffeeScript, постарались привнести еще больше удобства и эффективности в процесс написания кода.

В чужой монастырь со своим уставом не ходят. На очередном месте работы в мои задачи входит создание и последующая поддержка документооборота на платформе Alfresco, попутно ведение других систем. Заведение с предписанными правилам, устоявшимися обычаями и порядками. Многих привычных IT вещей в инфраструктуре нет, но всё работает надежно и всех устраивает. Как человек обладающий интеллектом и зачатками воспитания не буду пытаться нарушить чужие традиции и глобально что-либо менять. Учитывая over 500 рабочих мест, некоторые замечу не всегда рядом и критичность создаваемого сервиса для организации, некоторые вещи сделаю на свой лад. К ним относятся мониторинг и оркестрация.

Пока патентные войны остаются скрытой угрозой для экосистемы OpenStack, давайте поговорим о технологии, позволяющей разворачивать OpenStack практически в один клик. Название этого проекта многократно встречалось в постах нашего блога, но не было ни одного текста, посвященного именно Fuel. Между тем — именно этот проект существенно упростил процедуру развертывания OpenStack и сделал менее трудоемким процесс дальнейшего управления облаком. Безусловно, можно действовать по старинке. Использование Fuel не является обязательным для работы с OpenStack. Однако мы считаем, что если театр начинается с вешалки, то OpenStack начинается с Fuel. По крайней мере — Mirantis OpenStack (MOS).

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

1. «Sharding — patterns & antipatterns».
Доклад Алексея Рыбака (Badoo) и Константина kostja Осипова (Mail.ru).

Мы в JetBrains искренне считаем, что программирование отнюдь не сводится к простому написанию кода. Программировать — значит постоянно развиваться, приумножать свои знания, совершенствовать навыки, используя при этом самые лучшие инструменты. Если вам знакома притча о двух дровосеках, в которой более искусен оказывается тот, кто не забывает наточить свой топор, то вы поймете наше стремление оттачивать инструменты разработки с каждым следующим релизом. Не стал исключением и последний релиз RubyMine, нашей среды для разработки на Ruby и Rails, о котором мы и хотим рассказать подробнее в этом посте. Кстати, вчера стало доступно для скачивания и первое обновление — RubyMine 7.0.1.

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

Вы наверняка знаете или представляете, что управление большой инфраструктурой с помощью Puppet — непростая задача. Если для десяти серверов Паппет не нужен, для пятидесяти в самый раз и код можно писать как угодно, то когда речь идет о 500+ серверов, то в этом случае приходится уже серьезно думать об оптимизации своих усилий. Плохо, что Паппет изначально, видимо, не задумывался, как решение для больших инфраструктур, по крайней мере иерархия в него изначально заложена из рук вон плохо. Стандартные node definitions совершенно неприменимы в больших компаниях. Node inheritance (также как и class inheritance) Puppetlabs не рекомендуют больше использовать вообще, вместо этого лучше загружать данные о иерархии из внешних источников, таких как Hiera и External Node Classifier (ENC).

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

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

Имеется сервер с установленным Apache. Установка и настройка производится удобно и модно puppet-классом apache. Для простоты все будем хранить в основном манифесте site.pp. Все появляющиеся проблемы в ходе развития примера актуальны и в случае разнесения кусков логики по модулям.

Недавно я переосмыслил процедуру установки нового сервера Puppet с нуля на Ubuntu 12.04, включая все современные свистелки и перделки. В итоге у меня получился этот гайд.

Для начала нам потребуется чистая Ubuntu c работающей сетью и настроенным DNS.

В итоге мы должны получить:

• Установленый везде Puppet 3-й версии
• Конфиги в git репозитории с общим доступом
• Динамические окружения, управляемые r10k
• Поддержку PuppetDB
• Поддержку Hiera

Данное руководство довольно длинное, т.к. все настройки делаются вручную, чтобы впоследствии легко можно было пользоваться результатом и подстраивать его под себя. Единственным исключением является PuppetDB, который проще установливать через собственный модуль от Puppet Labs, а не вручную.

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

Автор: Евгения Шумахер

Евгения Шумахер – бизнес-аналитик компании Mirantis и автор предложения: How to Avoid Picking Problems that OpenStack Can’t Solve, докладчик по теме Will your Cloud be Compliant? на саммите OpenStack, который пройдет этой весной в Атланте.

Введение

Рано или поздно каждой серьезной компании приходится задумываться о легализации своей IT инфраструктуры. Возьмем среднюю по масштабам компанию N. Центральный офис, 30 небольших филиалов. Везде стоят рабочие станции под Windows, в основном XP. На более свежих машинах, ноутбуках, встречаются windows 7 и 8, на серверах 2k3, 2k8, ubuntu-server.
Расширяется компания не слишком большими темпами, и немногочисленный отдел IT успевает новые машины накатывать из заранее созданных образов Acronis'ом. Но в целях уменьшения затрат/легализации инфраструктуры/очистки совести принимается решение перейти на opensource. Тут уже другой масштаб трагедии, переустанавливать руками множество рабочих станций — процесс долгий и неблагодарный. Под катом — один из вариантов решения данной проблемы.

Сегодня я расскажу Вам о волшебстве. И это волшебство способно изменить жизнь системного администратора Windows раз и навсегда.

В наше время становится все меньше и меньше людей, которые хоть раз не устанавливали софт в среде Linux. Это невероятно просто: для установки midnight commander (mc), в среде RH (RedHat Enterprise, CentOS, Fedora, и т.д) нам всего лишь нужна пара «волшебных» команд:

# yum install mc

Менеджер пакетов yum позаботится о том, чтобы установилась самая свежая версия mc, а также о зависимостях пакета, если таковые имеются. Но что же делать, если в нашем распоряжении находится Windows, а мы хотим что-то подобное? Правильно, перейти на Linux или читать дальше!

Под моей «опекой» находится гетерогенная сеть из Windows и Linux машин (проще сказать — зоопарк), и вот уже около двух лет для установки софта под Win* я пользуюсь, где это возможно, Chocolatey. Chocolatey (chocolatey.org, github.com/chocolatey) — система управления пакетами, во многом схожая с apt-get или yum, но только для Windows.

На хабре уже касались темы Chocolatey в контексте разработчика, сегодня я хочу взглянуть на этот замечательный инструмент с точки зрения системного администратора. Chocolatey работает на основе технологии NuGet (активно используется разработчиками софта под Windows), и основная черта Chocolatey — пакеты чаще всего не содержат установочных файлов (setup.msi, setup.exe, и т.д...). Работает это следующим образом: в пакете находится скрипт-установщик на powershell, который скачивает и устанавливает нужную версию установочного файла из нужного места в интернете, а Вам остается только наслаждаться легкостью установки.

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

Задача

Необходимо развернуть сервер со следующими требованиями:

• Массив дисков RAID-10
• Full Performance in BIOS
• Windows Server 2012 с всеми обновлениями и патчами
• Это будущий сервер приложений со службами для которых необходим .net 4.5
• Мониторинг доступности сервера, а также CPU, Памяти и свободного места на диске
• Необходимо подключить сервер к системе выкатки релизов Octopus Deploy

Сложности

Основное требование здесь — все должно быть максимально автоматизировано, участие человека минимизировано до 1 минута «в начале» и 1 минута «в конце». Целью такой автоматизации является потенциальная необходимость «поднять» в дальнейшем несколько новых серверов достаточно быстро. Решение должно быть не сложным для восприятия младшими админами и разработчиками, в чьи обязанности развертывание серверов не входит.

В качестве предисловия

Основной задачей моей работы является поддержка парка железных и vm хостов — уже под 200 (а приходил было менше 100, эх, время бежит...) Поддерживаю все железо, а также сеть. Также на мне весь мониторинг (используем Opsview — сделан на ядре nagios), аггрегация логов (я внедрил Logstash, обалденное opensource решение за место ну ооочень дорогого Splunk), configuration management (puppet), бекапы, поддержка баз данных и прочих систем тоже на мне (MongoDB, MySQL, Redis, ElasticSearch, etc). В общем — все самое интересное). Стоит отметить что у нас достаточно тонкая грань между поддержкой и разработкой, и разработчики часто говорят что они хотят, а я уже занимаюсь внедрением. Хочется рассказать обо всем что происходит интересного и какие технологии удается использовать. Какие прижились, а какие по каким-то причинам нет.

Задача

Мы используем Opsview для мониторинга и Puppet для управления конфигурациями. В Opsview есть шаблоны (Host Templates), которые позволяют определить определенный список проверок (Service Checks) для определенного типа хостов. Например для хоста с шаблоном IIS будут проверяться всевозможные параметры IIS данного хоста, к примеру количество текущих подключений или например средняя скорость подключения.

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

Сложности

Основная сложность здесь, как обычно, в том что этого никто не сделал этого для меня. Не существует модуля «Мониторинг IIS в один клик» для моей инфраструктуры. Практически сложность заключается в том, как сообщить модулю который управляет конфигурацией Opsview что в другом модуле создали сайт, передать параметры URI которые нужно мониторить, а также имена шаблонов хоста (в данном случае это будет как минимум шаблон IIS). Мои попытки и пробы включали следующее:

История

Внедрение Linux в ПриватБанке началось в 2007 году. За это время был пройден большой путь и хотелось бы поделиться с сообществом своим опытом внедрения. На данный момент мы достигли следующих показателей: более 36500 рабочих мест с ОС Linux в 4000 отделений, расположенных в 5 странах.
В 2007 году за основу был взят ASPLinux 11.2. Со временем для альтернативы были выбраны другие дистрибутивы — Fedora, openSUSE, Ubuntu. Позже стала очевидной необходимость создания собственного дистрибутива и системы управления рабочими станциями. Разработка началась в январе 2012 года. Для основы был выбран Ubuntu 12.04 LTS с рабочим окружением Gnome Classic (no effect). Основные аргументы: Ubuntu — самый распространённый десктопный дистрибутив последних лет; обширное комьюнити, где проще найти решение возникающих проблем; именно его в качестве основы внедрения выбрал Google, много примеров внедрения в государственных и муниципальных учреждениях Германии, Франции. Выбор системы управления остановился на Puppet.
В июне 2012 года стартовал переход и к январю 2013 на корпоративную ОС были переведены уже около 95% ПК. Такая скорость перехода обусловлена тем, что сотрудники уже имели опыт работы в Linux.

Основные задачи, которые удалось решить благодаря текущему внедрению:

• cущественная экономия ресурсов при поддержке ОС на рабочих местах сотрудников;
• поддержание программного обеспечения в актуальном состоянии;
• возможность оперативного применения критических обновлений (до 1 часа на всех ПК);
• cбор и анализ статистической информации о парке ПК и периферии;
• создание системы проактивной реакции на сбои (Event Manager).

Дальше более детальное описание компонентов нашей реализации.

Большинство статей в наш блог пишут разработчики. Мы решили исправить эту несправедливость и добавить немного DevOps. Сегодня поговорим о важном ― о бэкапах.
Так как Badoo активно развивается и количество сотрудников постоянно увеличивается, мы пришли к выводу, что централизованное резервное копирование гораздо удобнее, чем частичное копирование и хранение информации в различных местах.
В статье мы рассмотрим, как различными способами «забэкапить» довольно большое количество рабочих станций с помощью одного хранилища, не прибегая к серьёзным вложениям и избегая громоздкой реализации.
Заранее оговоримся, что бэкап не охватывает 100% сотрудников, так как не все хранят свои данные на локальных машинах, поэтому у нас не было цели сделать бэкап обязательно-принудительным.
Одной из основных сложностей централизованного бэкапа стало то, что сотрудники используют разные операционные системы.

Как же мы смогли собрать всех на одном сервере?

Автор: Олег Гельбух

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

— Бесперебойность (HA) сервиса и резервирование
— Масштабируемость кластера
— Автоматизация технологических операций

Компания Mirantis разработала подход, который позволяет удовлетворять всем этим трем требованиям. Эта статья – первая в ряде статей, которые описывают наш подход. В статье содержится обзор используемых методов и инструментов.

Бесперебойность (HA) и резервирование

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

API-сервисы
Первая группа включает API-серверы, а именно: