→ Развертывание OpenSource Puppet 4 с несколькими Puppet masters. Часть I. Подготовительная
→ Развертывание OpenSource Puppet 4 с несколькими Puppet masters. Часть II. Настройка Puppet Masters

Настройка puppet-db с помощью Puppet

Зададим настройки для ноды puppet-db в репозитории puppet-environments.git.

В случае стандартного размещения datadir для postgresql

В репозитории puppet-environments.git в файл manifests/nodes.pp добавим настройки puppet-db:

node default {

}
node puppet-db {
  class { 'puppetdb':
    listen_addresses => '0.0.0.0',
  }
}

→ Развертывание OpenSource Puppet 4 с несколькими Puppet masters. Часть I. Подготовительная
→ Развертывание OpenSource Puppet 4 с несколькими Puppet masters. Часть III. Настройка puppet-db с помощью Puppet

Настройка серверов puppet

Общие настройки серверов. На серверах puppet-master01, puppet-master02 и на puppet-db добавим репозитории puppetlabs:

wget https://apt.puppetlabs.com/puppetlabs-release-pc1-xenial.deb
sudo dpkg -i puppetlabs-release-pc1-xenial.deb
sudo apt update

На серверах puppet-master01, puppet-master02 установим puppet-сервер:

sudo apt install puppetserver

Проверим адрес, порт и требование авторизации в файле /etc/puppetlabs/puppetserver/conf.d/webserver.conf, по умолчанию должно быть:

client-auth: want
ssl-host: 0.0.0.0
ssl-port: 8140

На сервере puppet-db достаточно puppet-агента:

sudo apt install puppet-agent

Остальное на puppet-db установим с помощью Puppet.

Вкратце:

1. cfdb — модуль развёртывания и автонастройки узлов и кластеров баз данных и доступа к ним с высокой доступностью и защитой от сбоев.
2. Как proof-of-concept поддерживаются MySQL и PostgreSQL на базе Percona Server/XtraDB Cluster и официальных сборок PostgreSQL+repmgr.
3. Изоляция ресурсов на базе cgroups, интеграция с настройками сетевого фильтра через модуль cfnetwork и строгий контроль доступа средствами СУБД.
4. Запись на один узел для минимизации конфликтов и распределение нагрузки для read-only доступа.
5. Автоматическая проверка здоровья кластера и фактической осуществимости доступа.
6. Ручное и автоматическое локальное резервное копирование, автоматизированное восстановление данных.
7. Поддержка автоматической миграции уже существующих баз данных

Авторы: Евгения Шумахер, Илья Стечкин

Всем привет. Да, если вы любите деньги, то оно вам надо. Дальше мы расскажем, что такое “валидация плагинов” и почему это полезно для бизнеса. Если у вас нет бизнес-интересов, а программирование — способ самовыражения, то дальше можете не читать.

We Need To Go Deeper.
Inception.

Здесь я хочу описать примеры/приёмы программирования. Причина всё та же: в интернете должно быть больше доков. В моей прошлой статье было рассказано про установку и нaстройку Puppet версии 3.8 на примере Centos 6.5. Там же бы простейший пример, чтобы проверить работоспособность связки клиент-сервер. Теперь посмотрим как это можно усложнить и для чего это надо.

Вкратце:

1. cftotalcontrol — модуль создания среды специальной учётной записи с SSH доступом к другим узлам инфраструктуры и выполнения массовых рутинных задач параллельно.
2. Отвлечённая от реализации теория организации безопасного и контролируемого доступа к инфраструктуре.
3. Описывается практическое применение конкретного решения

Вкратце:

1. cfpuppetserver — модуль автоматической настройки Puppet Server + PuppetDB + PostgreSQL + r10k + librarian-puppet
2. Краткое введение в Puppet
3. Описывается изначальное развёртывание с нуля

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

К вашему сведению! В этой статье мы рассматриваем само явление docker-контейнеров, а не составляем список микросервисов, которые гнездятся внутри. Этим мы займемся в следующей серии, во имя справедливости!

UPDATE: пришлось заменить «докер» на «docker», иначе статья не ищется. Заранее прошу прощения за все «docker'ы» в тексте. Селяви.

Что мы имеем сегодня

• Зоопарк дубовых VPS-хостингов.
• Дорогие IaaS и PaaS с гарантированным vendor lock in.
• Уникальные сервера-снежинки.
• Ворох устаревших зависимостей на неподдерживаемой операционке.
• Скрытые связи частей приложения.
• Незаменимый админ полубог на скейтборде.
• Радуга окружений: development, testing, integration, staging, production.
• Генерация конфигов для системы управления конфигами.
• Feature flagging.
  

Вариант развёртывания Linux систем на базе Puppet 4. Часть II: доступ и стандартное окружение (cfauth + cfsystem)

Вкратце:

1. cfauth — настраивает сервис SSH, админскую учётную запись, sudo, пароль суперпользователя
2. cfsystem — настройка: APT, временной зоны, отправки системных писем, синхронизация времени, расширенный список стандартных пакетов
3. Все модули интегрированы с модулем сетевого фильтра cfnetwork и не требуют дополнительных настроек

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

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

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

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

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

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

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

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

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

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

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

Пролог

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

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

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

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

В этой статье будет рассмотрена установка и настройка связки 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:

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



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

За последние лет пять я вижу очень много статей по «удачным» рецептам построения систем деплоймента и управления конфигурацией на базе 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 рабочих мест, некоторые замечу не всегда рядом и критичность создаваемого сервиса для организации, некоторые вещи сделаю на свой лад. К ним относятся мониторинг и оркестрация.