Под капотом сервиса d2c.io мы активно используем Ansible – от создания виртуальных машин в облаках провайдеров и установки необходимого программного обеспечения, до управления Docker-контейнерами с приложениями клиентов.
В первой части мы рассмотрели типы плагинов, которые поддерживает Ansible и сделали несколько своих плагинов: test, filter, action и callback. В этой статье попробуем более сложные модификации.
У себя в D2C мы активно используем Ansible. С его помощью мы создаем виртуальные машины у облачных провайдеров, устанавливаем программное обеспечение, а также управляем Docker-контейнерами с приложениями клиентов. В прошлой статье я рассказывал о том, как заставить Ansible работать быстрее, теперь расскажу о том, как расширить его функциональность.
Под капотом d2c.io мы используем Ansible. С его помощью мы создаем виртуальные машины у облачных провайдеров, устанавливаем программное обеспечение, а также управляем Docker-контейнерами с приложениями клиентов.
Ansible – удобный инструмент, который готов к работе почти без настройки. Это возможно благодаря отсутствию агентов (agentless system), поэтому не нужно ничего предустанавливать на обслуживаемые хосты.
Для подключения к хостам в большинстве случаев используется ssh. Однако оборотной стороной этой медали является определенная медлительность, так как вся логика находится на управляющем сервере и каждую задачу (task) Ansible формирует локально и отправляет на исполнение через SSH-подключение. Затем он принимает результат, анализирует его и переходит к следующему шагу. В статье мы рассмотрим, как можно ускорить работу Ansible.
Часто бывает, когда что-то не работает. И никто не хочет, чтобы что-то не работало по его вине. В контексте больших инфраструктур и распределенных приложений ошибка конфигурации может быть фатальной.
В статье я покажу как правильно тестировать окружение для приложения, какие инструменты использовать, приведу примеры удачного и целесообразного тестирования.
Статья будет интересна командам, которые практикуют DevOps или SRE, ответственным Dev, и прочим хорошим людям.
Читать полностью »
Делимся новым контентом по DevOps: курсы Microsoft Virtual Academy на русском языке, видео-уроки по DevOps-практикам на Channel 9 и подборка полезных материалов.
У меня есть pet project, которым я занимаюсь в свободное время. Этот проект полностью посвящён инфраструктурным экспериментам. Для управления конфигурацией я использую SaltStack. SaltStack — это централизованная система управления инфраструктурой. Это значит, есть мастер-сервер, который настраивает подчинённые серверы.
За время жизни проекта я наступил на небольшой набор граблей, но в итоге пришёл к очень удобному подходу работы с ним. В общем про это и статья — как оно все начиналось и к чему пришло.
Всем привет! Очередной выпуск статьи из цикла «Как мы внедряли DevOps» от команды Vorlon.JS. Vorlon.JS — это основанный на node.js инструмент, который позволяет веб-разработчикам удобный способ удаленно тестировать, контролировать и отлаживать веб-приложение, особенно на мобильных и embedded системах. В своем блоге на MSDN, команда описывала поэтапное внедрение DevOps практик в организацию работы над Vorlon.JS и выбор инструментов для решения ежедневных задач. Vorlon.JS является проектом с открытым исходным кодом.
Microsoft предлагает большое количество инструментов, которые могут быть использованы для реализации DevOps практик, и про часть из них мы рассказываем в этом цикле.
Содержание цикла:
Что такое «Инфраструктура-как-код»?
Инфраструктура-как-код — это возможность усовершенствовать методы создания и управления средами развертывания приложения на всех этапах его жизненного цикла, от среды разработки до рабочей среды. Она позволяет описать (декларировать) конечное желаемое состояние среды.
Допустим, вы развертываете приложение, которое должно выполняться на веб-ферме из 4 серверов.
Читать полностью »
Привет! Сегодня мы начинаем серию технических статей о Devops, Chef, infrastructure as code и всем таком. Эта статья – первая из трех о тестировании в Chef. Цикл статей будет полезен тем, кто уже знаком с Chef и хочет научиться тестировать свой код.
Концепция infrastructure as code позволяет нам применять к инфраструктуре решения из мира разработки. Отдельные компоненты инфраструктуры в проектах часто повторяются. При интеграции таких компонентов наиболее удобный вариант – общие кукбуки. Код кукбуков постоянно меняется, фиксятся баги, появляется новый функционал. С помощью тестирования мы отслеживаем регрессии, контролируем обратную совместимость и внедряем новые фичи быстрее.
В этой статье мы познакомимся с инструментами для тестирования, напишем простой кукбук и тест к нему.
