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

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

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

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

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

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

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

1. «Панель: Тренды разработки в высоконагруженных интернет-проектах».
Алексей fisher Рыбак (Badoo) собрал вместе лучших экспертов из Яндекса, Mail.ru, 2ГИС и Communico и обсудил с ними современные тенденции в разработке и поддержке больших высоконагруженных проектов. Плюс эксперты рассказали об интересных решениях и поделились личным опытом.

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

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

Сегодня я расскажу Вам о волшебстве. И это волшебство способно изменить жизнь системного администратора 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, который скачивает и устанавливает нужную версию установочного файла из нужного места в интернете, а Вам остается только наслаждаться легкостью установки.

Не так давно облачная платформа Microsoft Windows Azure была переименована в Microsoft Azure. Эта небольшое по сути, но очень важное по факту событие, которое отражает стремление Microsoft предложить Azure как открытую публичную облачную платформу для всех пользователей.



Это переименование давно напрашивалось, ведь платформа является открытой для всех технологий, предлагая строить решения на любых инструментах от Windows, SQL и .NET и до Python, Ruby, Node.js, Java, Hadoop, Linux и Oracle. В этой статье мы посмотрим какие возможности предлагает Azure для пользователей Linux, разных языков и opensource-инструментов:

• поддержка Linux в качестве ОС в виртуальных машинах
  
  • 1000+ готовых образов VM
  • использование любимого дистрибутива Linux
  • opensource-партнеры Azure
• поддержка Oracle и Java
  
  • поддержка OpenJDK, разработки Java и Eclipse
• поддержка Java, PHP, Python, Node.JS, Ruby в качестве PaaS
  
  • Visual Studio, Azure и Python, Node.js
  • WebMatrix, Azure и PHP
  • интеграция с Git, Mercurial, GitHub и другими системами
• поддержка Android, iOS, Xamarin, HTML5/JS, PhoneGap единым мобильным бэкендом
• Hadoop как сервис в облаке Azure
• администрирование Azure
  
  • работа с Azure из командной строки в Linux, OSX, Windows
  • интеграция с Puppet и Chef
• MongoDB, Redis и MySQL по запросу из Azure Store

В чужой монастырь со своим уставом не ходят. На очередном месте работы в мои задачи входит создание и последующая поддержка документооборота на платформе 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).

В этой статье будет рассмотрена установка и настройка связки Puppet + Foreman для централизованного управления конфигурациями.

Для сервера, на котором будет установлена связка Puppet + Foreman, будет использоваться виртуальная машина (1 CPU, 2 Gb RAM, 20Gb HDD), в качестве клиентов будут физические ПК на которых установлена Ubuntu. Конфигурация моего виртуального сервера с указанными выше характеристиками позволяет без проблем обслуживать 500 клиентов (можно и больше).

Установка Puppet довольно простая (все последующие команды выполняются от root):


Этими командами мы скачиваем deb пакет с сайта разработчиков puppet и устанавливаем его. Данный пакет puppetlabs-release-trusty.deb при установке создает файл /etc/apt/sources.list.d/puppetlabs.list в котором прописаны репозитории puppet, а также импортируется gpg ключ которым подписан репозиторий puppet. Сам puppetmaster мы не устанавливаем, он будет установлен автоматически при установке Foreman.

На этом установка Puppet закончена, приступим к установке веб-интерфейса Foreman:

Это вторая часть из серии статей о связке Puppet + Foreman, в ней будет рассмотрено следующее:

* Создание групп хостов
* Добавление хоста в группу
* Применение манифестов на группу хостов
* Автоподпись сертификатов
* Автоматическое распределение хостов по группам

Действующие лица и исполнители:

Александр Кислицкий — автор кода,
Евгения Шумахер, Ирина Поволоцкая — полезные замечания и ссылки,
Вячеслав Струк — ревью,
Илья Стечкин — рассказчик

Важная оговорка: мир плагинов очень быстро развивается. То, что описано ниже, актуально для плагинов, созданных под MOS 6.0. Напомним, что MOS — это Mirantis OpenStack, наш дистрибутив, открытый, как и все, что мы делаем. Однако на прошлой неделе было официально объявлено об официальном выпуске MOS 7.0, а это совсем другая история, которую мы тоже постараемся рассказать. Но в другой раз. Для ленивых копипастеров сразу предлагаем ссылку на GitHub и напоминаем, что лень — двигатель прогресса.

В этом посте я расскажу про не очень известные особенности языка YAML.

Пролог

Системное администрирование за последние несколько лет несколько изменилось. Вместо маленьких скриптиков на bash у нас теперь огромные проекты системы конфигурации. Puppet с миллионом модулей готов «отконфигурять» для нас любую машинку, все поставить и все настроить. И конечно же, венчает это торжество автоматизации Hiera — система управления системой управления.

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

Сначала все было просто. Молодость, задор. Проект пилили несколько программистов. Все кодили, по мере готовности копировали код на общую виртуалку, изредка попинывали админа на предмет доставить какой-нибудь пакет или поправить конфиг. Как только понимали, что все, шли делать релиз. Сначала backup, потом старшой собирал всю свою крутизну в кулак, копировал проект на production сервер и, при содействии админа, добивался, чтобы оно там заработало. Команда выжидала два дня, убеждалась, что очереди из благодарных пользователей с топориками не образовалось, и, с чувством гордости за выполненную работу, шла пить пиво.

Потом все чуть-чуть повзрослели. Появились и начали как-то использоваться redmine/jira/etc, git/svn, jenkins, spinx-docs/rubydoc/doxygen/etc, wiki, unit тесты. Появились подпроекты, стенд подрос. Production сервачков стало несколько. Админ поднял salt/puppet/etc, мониторинг, сидит в своем логове как паук, правит конфиги на salt-master и дергает оттуда state.highstate.

Puppet, Chef, Ansible — это так называемые системы управления конфигурациями, которые можно часто встретить в зарубежных IT вакансиях типа Server/DevOps Admin. Фактически же это мощные инструменты которые могут полностью настроить нулёвый сервер или же достаточно быстро массово перенастроить набор из 1-100+ серверов. Работа с пакетами, с командной строкой, файлами настроек, доступно всё.

Общий обзор можно прочитать в публикации «Как стать кукловодом».

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

Причина использования ветки 3.8, вместо 4.3 заключается в использовании именно этой версии на «моих» серверах из-за наличия именно этих пакетов в репо. Платный вариант Enterprise также не рассматривается, т. к. я с ним не работал. Причина использования Centos – он достаточно широко распространён, включая доработанные версии от Amazon.

Для локальных тестов можно использовать две виртуалки на VirtualBox под CentOS-6.5-x86_64.

— Эй, птичка, летим со мной, там столько вкусного!!!
— Столько? [разводя руки]
— у-у [мотая головой и соединяя руки]

Одна из основных проблем, которая встаёт перед провайдерами shared-хостинга, ‒ это изолирование пользователей. Было бы, конечно, проще и надёжнее создавать для каждого пользователя контейнер, но это съедает лишние ресурсы и здорово уменьшает плотность упаковки сайтов на одну машину (я исхожу из комфортной для клиента упаковки, а не вариант “селёдки в бочке”, который всё ещё встречается на ультрадешёвых хостингах, когда открытие даже статичной страницы сайта клиента заметно тормозит из-за нагрузки на веб-бокс). Скажу больше, нередки ситуации, когда один клиент, случайно или намеренно, занимает слишком много ресурсов, в ущерб всем остальным.

Решить эти задачи, не тратя ресурсы серверов впустую, мы и намеревались при помощи CloudLinux. CloudLinux уже упоминался на Хабре. Это RHEL-совместимый дистрибутив, базирующийся на ядре OpenVZ. При помощи хитрых компонентов (CageFS и LVE) и модифицированного ядра позволяет ограничивать пользователей в ресурсах (процессор память диск) без создания контейнеров.

“Я же сказал — полетели, а не побежали!”
“Давай, страус, пошел! Работаем, работаем!”



PHP сейчас один из самых популярных языков программирования, используемых для создания сайтов. На shared linux веб хостинге в России с выбором версии PHP не совсем гладко, хотя встречаются исключения из этого правила.
Почему выбор версии необходим? Интересно? Добро пожаловать под кат!

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

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

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

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

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

Можно настраивать компьютеры по одному, но иногда их становится слишком много...



Так уж вышло, что я устроился преподавателем на один бесплатный курс для школьников по разработке под Android, спонсируемый одной крупной корпорацией, и, естественно, мне потребовалось осваивать соответствующую технику в количестве 25 ноутбуков, 25 планшетов, 2 стационарных компьютеров и сенсорной панели. До недавнего времени ноутбуки использовались с ОС Windows 8.1, но мало кого устраивала производительность и стабильность работы этой ОС при разработке в Eclipse и Android Studio. После одного года под Windows, наше руководство решило все ноутбуки перевести на Xubuntu 14.04, чтобы разрешить эти сложности. Был подготовлен образ, настроенный под конкретную модель ноутбуков, что у нас использовалась, и со всеми необходимыми программами. Накатил и работай. Одна беда — не было предусмотрено никакого решения для централизованного управления конфигурацией. На мой логичный вопрос по этому поводу был дан ответ, что внедрение подобной системы усложняет процедуру установки Linux на ноутбуки и, поскольку в образе уже все сделано как надо, никаких изменений после его установки вносить не понадобится. (ох уж эти оптимисты!)