По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Что это и зачем?
Сегодня сложно представить мир без компьютерных сетей. Технический прогресс позволяет пользователю всего за несколько минут совершить покупки в интернет-магазине с доставкой, заказать такси, забронировать билет на самолет и отель, приобрести билеты в театр и многое другое. Всё это стало возможным благодаря широкому применению компьютерных сетей, их взаимодействию и интегрированию в общую глобальную сеть.
Мало кто задумывается, как всё это работает. Средний пользователь, который является конечным потребителем услуг, взаимодействует с сетью через интерфейс пользователя, и просто делает в сети то, что ему нужно. Между тем десятки и сотни тысяч системных инженеров ежеминутно поддерживают инфраструктуру сети на плаву, чтобы всё функционировало без поломок и сбоев. В этом им помогают различные автоматизированные программные решения, которые позволяют одному администратору поддерживать работу сети из сотен устройств. Сегодня мы разбираем одно из таких приложений, призванных сэкономить время системного инженера решение Chef от одноименной группы разработчиков.
Непосредственно о Chef
Chef это система управления конфигурацией сети. По функциональному назначению она схожа с Puppet или Ansible, однако имеет от них ряд отличий, благодаря которому и пользуется популярностью у некоторых системных инженеров. Разберем, что же в этом решении такого.
Сама программа реализована на Ruby, поэтому пользователь должен обладать хотя бы базовыми знаниями по этому языку программирования, а на центральном сервере должно быть установлена соответствующая программная среда. Базовыми понятиями, которые используются в этой программе являются:
Ноды (Nodes): Эта любая серверная единица, физическая или виртуальная, которая будет входить в систему обслуживания Chef.
Шеф-сервер (Chef-server): Центральный сервер, на котором будет установлена основная управляющая часть программы.
Рецепт (Receipt): Собственно, сам файл с конфигурацией, применяемой для настройки поведения сети на различных сетевых узлах.
Поваренная книга (Cookbook): Хранилище рецептов то есть всех файлов конфигурации сети.
Хранилище поваренных книг (Bookshelf): Директория-хранилище поваренных книг.
Рабочая станция администратора (Workstation): Физический ПК, на котором будет развернута система управления Chef.
Нож (Knife): Основной инструмент управления программой Chef и ее составляющими из консоли.
Помимо этого, программа содержит много компонентов таких как веб-сервер Nginx, сетевой интерфейс сервера Web-UI, хранилище данных PostgreSQL, и другие компоненты. Кроме того, каждая поваренная книга содержит, помимо рецептов, также атрибуты (параметры поведения сети, описанные через рецепты или роли), шаблоны (заготовки файлов конфигурации) и файлы (любые файлы, которые будут распространяться на ноды с помощью рецептов).
То есть, структура программы выглядит так: администратор разворачивает серверную часть программы на рабочей станции, то есть создаёт на ней шеф-сервер. Далее пишет рецепты для определения будущего поведения всех нод, объединяет их в поваренную книгу (вместе с нужными атрибутами, файлами программного обеспечения и шаблонами будущих параметров конфигурации), затем помещает книгу в хранилище. Причем, рецептов в поваренной книге может быть несколько на случай различных версий операционных систем и ПО на узлах сети, да и самих поваренных книг также может быть более одной для различных сценариев поведения сети. Ноды через клиентскую часть запрашивают актуальные рецепты у сервера, принимают команды и переконфигурируют параметры узла так, что он исполняет свое назначение в сети наиболее эффективно. Таким образом, система является достаточно гибкой для быстрой перенастройки сети под исполнение тех или иных задач что и является ее основным плюсом.
Таким образом, вы получаете ультимативную платформу для управления и автоматизации в вашей сети. Конечно, придется немного поучиться и набраться опыта, зато потом вы сможете экономить кучу вашего времени и избавиться от досадных ошибок.
Как и множество других инструментов для управления и автоматизации на рынке программного обеспечения, Ansible был изначально open – source проектом (с открытым исходным кодом), который предназначался для автоматизации настройки и деплоймента (развертывания) ПО в сетевых контурах компаний. Чего скрывать, продукт «стрельнул» - когда компания AnsibleWorks это поняла, начала активную монетизацию через коммерческую поддержку продукта для корпоративных заказчиков.
/p>
В настоящее время их продуктовая линейка состоит из двух направлений - Ansible и Ansible Tower, причем последний обладает полноценным интерфейсом управления (UI) и возможностью реализации дашбордов.
Ansible - новые ребята в DevOps направлении, по сравнению, например, с Chef или Puppet, но успели круто зарекомендовать себя в сообществе профессионалов за простоту и скоуп возможностей. Его playbooks понятны и легко читаемы, даже без особых знаний.
Так к чему это все? В «правильных руках», где присутствует полное понимание плюсов и минусов продукта Ansible может работать еще круче :) Поэтому, хотим рассказать про 5 лучших и 5 худших свойств Ansible.
Playbooks в Ansible это файл в формате YAML, который содержит последовательность состояния ресурсов системы, задач, которые позволяет запустить то или состояние сервера.
Что такое DevOps, что нужно знать и сколько получают DevOps - специалисты?
5 лучших качеств Ansible
Легкость в изучении
По правде говоря, это одно из самых крутых качеств Ansible – изучить его можно за один вечер и уже запускать веб – сервер из YAML, например. Ansible задачи запускаются последовательно, что сильно облегчает траблшутинг конфигураций. Например, можно сделать Playbook для Ansible, который позволит получить минимальный веб сервер примерно так:
Создаем файл формата .yml и наполняем командами;
Установить через yum apache;
Запустить apache как сервис в операционной системе;
Скопировать в корень веб – сервера html страничку с заглушкой («Мы готовим информацию по сайту, скоро здесь все будет, бла бла бла..»);
Скорректировать iptables, открыв порты и сохранить конфигурацию;
Не сложно, не правда ли?
Написан на Python
Я, как автор статьи, подметил следующее: если мы возьмем 10 программистов, вероятность, что кто-то из них знает Python гораздо выше, чем то, что кто – то из них знает Ruby. Именно это делает Ansible крутым – он написан на питоне в отличие от Ruby – based конкурентов. Так же отмечу, что Python библиотека, обычно, по умолчанию присутствует в любом Linux дистрибутиве, чего не сказать о Ruby.
Продолжая экскурсию – Ansible поддерживает написание модулей на любом языке программирования. Единственное требование – формат ответа. Это должен быть JSON.
Не нужно ставить клиента (агента) на машину
Для управления узлами, Ansible обрабатывает все коммуникации между мастер – узлами и узлами – агентами по стандартному SSH, или через модуль Paramiko, который является частью Python SSH второй версии.
Не нужно ставить агентское ПО на удаленные машины – только SSH подключение. Как следствие, упрощение обслуживания и траблшутинга.
YAML плейбуки
Как мы писали ранее, плейбуки в Ансибл невероятно просты и читаемы. Все DevOps инженеры, с которыми мы обсуждали его, освоили их за один вечер. Они даже проще чем JSON :)
Портал Ansible Galaxy
Портал, на котором вы наверняка найдете решение для своей задачи. Это объединение Ansible сообщества, где люди делятся наработками и решениями той или иной задачи. Знаете, это как ответ на мэйл.ру - чтобы вам не пришло реализовать на Ансибл, то как правило, кто – то эту задачу уже решил :). Тонны плейбуков, фреймворков, дистрибутивов и сопутствующего ПО.
5 худших качеств Ansible
Настало время хорошенько пройтись по Ansible и выделить минусы продукта. Пожестим.
Проблемы с интерфейсом (UI)
Изначально Ansible разработан для работы с командной строкой. Первые наметки в сторону визуализации конфигурации Ансибл начались через AWX – графический интерфейс пользователя, который являлся первой попыткой упрощения конфигураций через интерфейсную составляющую. В последствии, AWX превратился в Anbile Tower, который дает возможность через GUI управлять Ansible, рисовать workflow и так далее.
Несмотря на улучшение Tower перед AWX, он все равно позволяет делать только 85% рабочего функционала Ansible, который можно делать через командную строку. В добавок, конфигурации внесенный через интерфейс зачастую не синхронизируются с CLI – конфигами.
Ansible Tower находится на стадии разработки и пока весьма сыроват.
Нет работы с состоянием машин/процессов
Если сравнивать с тем же Puppet, Ansible не имеет понятия «состояние» и, соответственно, не отслеживает его. Ансибл не смотрит на зависимости, а просто выполняет последовательный ряд задач/процессов. Для кого – то это нормально и удовлетворяет поставленным задачам, но есть и другие пользователи, у которых от такой работы, мягко говоря, «подгорает» :)
Слабая поддержка совместимости с Windows
С версии 1.7 Ansible умеет работать с Unix и Windows узлами, но надо признаться, работа с первыми реализована гораздо лучше. Взаимодействие с Windows машинами происходит через PowerShell, и, что важно, вам все равно потребуется Linux хост (управляющая тачка) для такой коммуникации.
Ждем, когда Ansible разрабы разгребут бэклог по работе продукта с Windows.
Поддержка крупного бизнеса
Ansible Enterprise Tower и Premiun Tower имеют 8х5х4 и 24х7х2 SLA соответственно, но имеют меньше опыта поддержки крупняков, в сравнении, например, с Chef и Puppet.
Новизна продукта
Ansible находится на рынке меньше своих конкурентов и, само собой, баги будут всплывать. К тому же, комьюнити Ансибл только растет и развивается, в отличие от более крупных игроков, упомянутых в этой статье.
Итоги
Подведем черту: Ansible это просто, гибкий и мощный инструмент, для управления конфигами и автоматизацией. Ansible Tower имеет графический веб – интерфейс, REST API, с помощью которого вы можете интегрировать свой сторонние приложения и поддержку, которая только учится и осваивает азы сопровождения крупного энтерпрайза.
Ansible – новинка, которая имеет своих ранних последователей, противников, сторонников. Сочетая в себе большое количество плюсов, он, конечно, имеет ряд недостатков или так сказать «ранних болезней», через которые уже прошли более крупные конкуренты.
Но кто знает, что покажет нам Ansible завтра?
Салют! Изо дня в день администраторы IP – АТС Asterisk выполняют рутинные действия связанные с обслуживанием: добавить внутренний номер, настроить новый транк и соответствующие маршруты, посмотреть статус пиров и другие итерации. Для облегчения этих действия существует графическая оболочка FreePBX 13. Сегодня хотим рассказать про очень полезную «кастомизацию» этой самой графической оболочки – настройку вкладок и пунктов меню так, как это будет удобно именно Вам :)
Как это работает?
Кастомизацию интерфейса FreePBX можно осуществлять с помощью файла freepbx_menu.conf, который должен быть расположен в директории /etc/asterisk. При загрузке интерфейса, FreePBX проверяет существование этого файла, парсит настройки и отображает их администратору.
Pre-work
Перед началом работы, давайте проверим наличие файла кастомизации в директории /etc/asterisk. Для этого, выполните последовательность следующих команд:
[root@asterisk ~]# cd /etc/asterisk/
[root@asterisk asterisk]# ls -l | grep freepbx_menu.conf
В случае, если файл находится в указанной директории, он будет отображен в выводе последней команды. В противном случае, просто создадим его вручную командой:
[root@asterisk ~]# touch /etc/asterisk/freepbx_menu.conf
Теперь открываем интерфейс FreePBX, и переходим во вкладку Settings → Advanced Settings. Находим параметр Use freepbx_menu.conf Configuration и выставляем его в значение Yes.
Важно! Убедитесь, что в данном пункте меню, параметры Display Readonly Settings
и Override Readonly Settings выставлены в значение Yes.
Процесс настройки
Допустим, мы хотим создать дополнительную вкладку под названием «Основное», куда вынесем пункты настройки внутренних номеров, транков, входящих и исходящих маршрутов и статус Asterisk. Переходим к конфигурации файла. Открываем его для редактирования:
[root@asterisk ~]# vim /etc/asterisk/freepbx_menu.conf
Для редактирования нажимаем «O» на клавиатуре и добавляем следующую конфигурацию:
[extensions]
category=Основные
name=Внутренние номера
[trunks]
category=Основные
name=Линии к провайдеру
[did]
category=Основные
name=Входящие маршруты
[routing]
category=Основные
name=Исходящие маршруты
[asteriskinfo]
category=Основные
name=Статус Asterisk
Синтаксис следующий:
[extensions] - наименование модуля;
category - категория (наименование вкладки, в которой будет отображаться данный модуль;
name - видимое имя для модуля (параметр для удобства);
Дополнительные параметры:
sort - порядок расположения модуля сверху вниз во вкладке;
remove - удалить модуль из рабочей области интерфейса;
Важно! Параметр remove не удаляет модуль с сервера. Он просто не будет отображаться среди доступных для конфигурации модулей в FreePBX.
Готово. Давайте посмотрим, что у нас получилось в FreePBX: