DevOps *

Пришло время описать архитектуру и особенности эксплуатации одного приложения. И для себя, чтоб не забыть, и для других — попробовать показать, как делать не нужно. Все совпадения случайны, все персонажи выдуманы. Реальны только используемые технологии и описаные, гхм, архитектурные решения. Поехали.

Приветствую, дорогой читатель. Я начинаю цикл статей о том, как мы искали решение для применения подхода Infrastructure-as-Code в нашем виртуальном окружении VMware VSphere.

В нашем блоге на Хабре мы много рассказываем о внедрении подходов DevOps и разработанных нами инструментах автоматизации разработки и тестирования. Сегодня речь пойдет о том, как мы решали проблему взаимодействия с VMware vSphere.

Индустрия хостинга существует в России более 20 лет. Казалось бы, достаточно времени, чтобы рынок стабилизировался, появились четкие лидеры и простые критерии выбора для заказчиков. Однако, при решении задачи выбора хостинга до сих пор приходится опираться на собственный опыт, рекомендации и «метод тыка».

В этой статье мы рассмотрим методичный подход к выбору провайдера хостинга с позиций качественной работы веб-проекта как с точки зрения скорости, так и надёжности. Уточню, что речь пойдёт только о выделенных серверах или VPS (или их облачных аналогах), полностью виртуальный (shared) хостинг оставляем за скобками как неприемлемый вариант.

Контейнеры Docker хороши тем, что они немутабельны (immutable). Docker поставляется с файловой системой типа copy-on-write, поэтому базовый образ может быть изменен только в том случае, если вы сами создали соответствующий коммит.

Эта особенность может пригодиться, например, при расследовании хакерских атак. Давая возможность легко проверить расхождение файловой системы контейнера с базовым образом, она позволит увидеть сделанные атакующей стороной изменения.

За последний год программное обеспечение для автоматизации развертывания в среде виртуализации на уровне операционной системы набирает большие обороты. Эта статья послужит новичкам в этой сфере примером, как нужно упаковывать свое приложение в Docker контейнеры.

В классическом виде, PHP приложение представляет из себя следующие составляющие:

1. Веб-сервер
2. СУБД
3. PHP приложение

В нашем примере мы будем использовать Nginx, PostgreSQL и PHP-FPM.

Мы продолжаем рассказывать о процессах организации разработки в Positive Technologies. Ранее мы коснулись тем создания дистрибутивов продуктов, организации процесса хранения и лицензирования софта и реализации собственной системы Continuous Integration.

Сегодня речь пойдет о том, как мы используем инструмент Team Foundation Server (TFS) для организации workflow разработки.

Мой коллега написал прекрасный блог о локальном тестировании ролей Ansible с использованием KitchenCI. Очень быстрый и простой инструмент, состоящий из ruby gem'ов, доступный на каждой ОС, который также работает с разными инструментами тестирования (например Serverspec и Pester). Коллега разрабатывал это решение под нужды своих проектов (provision и deploy исключительно под Windows), что на первый взгляд стало проблемой, потому что:

• Я тоже люблю Ansible
• Ansible мне нужен, чтобы управлять Linux
• Я не хочу создавать еще один репозиторий на GitHub для отдельного тестирования Linux-ролей, потому что не хочу плодить сущности (Бритва Оккама наше все)

Кому интересно, что было дальше, прошу под кат.

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

Предисловие

Мой опыт использования puppet. До написания настоящей статьи, я работал с Open Source Puppet версии 3 в stand alone конфигурации, и использовал его для управления несколькими сотнями хостов. Но пришло время расти: количество управляемых хостов вышло за тысячу, и грозит в ближайшем будущем перевалить за несколько тысяч. Было принято решение для распределения нагрузки и повышения отказоустойчивости развернуть Open Source Puppet версии 4 с несколькими серверами Puppet Master и отдельным сервером PuppetDB с postgresql. А также использовать для хранения окружений с конфигурациями конечных хостов git-репозиторий на git-сервере.

Краткий обзор статей на habrahabr по развертыванию Puppet

Вначале хотел бы предложить краткий обзор уже имеющийся статей на habrahabr.

Настройка современного Puppet сервера с нуля
Перевод статьи «Setup of modern Puppet of the server from scratch» выполненный grundic, оригинал которой мне удалось найти только в кэше гугла. Эта статья была взята мной за основу при подготовке публикации. Детали, описанные в оригинале статьи «Setup of modern Puppet of the server from scratch», как и дополнения переводчика в ее переводе, уже успели немного устареть. Это, а также желание поделиться описанием дополнительных тонкостей, побудило меня к написанию собственной статьи.

Продолжаем цикл статей о контейнеризации. Сегодня мы поговорим о runC — инструменте для запуска контейнеров, разрабатываемом в рамках проекта Open Containers. Цель этого проекта заключается в разработке единого стандарта в области контейнерных технологий. Проект поддерживают такие компании, как Facebook, Google, Microsoft, Oracle, EMC, Docker. Летом 2015 года был опубликован черновой вариант спецификации под названием Open Container Initiative (OCI).

Говорят, что нельзя полностью понять систему, пока не поймёшь её сбои. Ещё будучи студентом я ради забавы написал реализацию TCP, а потом несколько лет проработал в IT, но до сих пор продолжаю глубже и глубже изучать работу TCP — и его ошибки. Самое удивительное, что некоторые из этих ошибок проявляются в базовых вещах. И они неочевидны. В этой статье я преподнесу их как головоломки, в стиле Car Talk или старых головоломок Java. Как и любые другие хорошие головоломки, их очень просто воспроизвести, но решения обычно удивляют. И вместо того, чтобы фокусировать наше внимание на загадочных подробностях, эти головоломки помогают изучить некоторые глубинные принципы работы TCP.

Каждый год появляется столько новых технологий (таких как Kubernetes или Habitat), что легко забыть о тех инструментах, которые тихо и незаметно поддерживают наши системы в промышленной эксплуатации. Одним из таких инструментов, который мы используем в Stripe на протяжении нескольких лет, является Consul. Consul помогает в обнаружении сервисов (то есть помогает находить тысячи работающих у нас серверов с запущенными на них тысячами различных сервисов и сообщать, какие из них доступны для использования). Это эффективное и практичное архитектурное решение не было чем-то совсем новым и особенно заметным, но оно верой и правдой служит делу предоставления надежных сервисов нашим пользователям по всему миру.

В этой статье мы собираемся поговорить о следующем:

• Что такое обнаружение сервисов и Consul.
• Как мы управляли рисками, возникавшими при внедрении критически важного программного продукта.
• Вызовы, с которыми мы столкнулись, и наши ответы на эти вызовы.

В предыдущем материале я рассказывал о проекте для автоматизации деплоя Docker контейнеров, разработка которого стартовала в начале этого года. Прошло несколько месяцев, Fabricio был значительно улучшен и доработан, и сегодня я хочу рассказать об одном из последних нововведений — об автоматическом деплое master-slave конфигураций для PostgreSQL.

Запуск PostgreSQL в контейнерах — не самая популярная идея, и тому есть разумное объяснение: ни к чему добавлять дополнительные сетевые задержки к и без того довольно загруженному сервису. Но существует ряд случаев когда такое решение все же можно применить. Например, когда вы полностью доверяете Docker БД не испытывает серьезных нагрузок, но при этом важна возможность дублирования/реплицирования хранимых данных на несколько серверов. Либо просто для тестирования и отладки настроек перед применением их на боевых серверах.

Чтобы не утомлять читателя (и пользователя) большим количеством текстовой информации, я решил, что неплохо было бы уже привести «живые» примеры использования Fabricio на реально работающих контейнерах — согласитесь — лучше один раз увидеть.

Positive Technologies — продуктовая компания. Это значит, что мы разрабатываем большое количество продуктов, и важно понимать, что все они «коробочные». Соответственно, нам нужно каким-то образом доставлять разработанные нами решения до инфраструктуры конечного заказчика. При этом, зачастую наш софт обладает сложной конфигурацией — в нем много различных компонентов, которые должны устанавливаться на различные целевые машины, а эти компьютеры обладают разными ролями и т.п.

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

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

Я искал self-hosted мониторинговое решение с открытым кодом, которое может предоставить хранилище метрик, визуализацию и оповещение для физических серверов, виртуальных машин, контейнеров и сервисов, действующих внутри контейнеров. Опробовав Elastic Beats, Graphite и Prometheus, я остановился на Prometheus. В первую очередь меня привлекли поддержка многомерных метрик и несложный в овладении язык запросов. Возможность использования одного и того же языка для графических изображений и уведомления сильно упрощает задачу мониторинга. Prometheus осуществляет тестирование по методу как черного, так и белого ящика, это означает, что вы можете тестировать инфраструктуру, а также контролировать внутреннее состояние своих приложений.

Делимся новым контентом по DevOps: курсы Microsoft Virtual Academy на русском языке, видео-уроки по DevOps-практикам на Channel 9 и подборка полезных материалов.

Мы в Positive Technologies не только проводим исследования безопасности различных ИТ-систем, но и разрабатываем продукты, которые помогают обнаруживать и предотвращать угрозы, а также минимизировать ущерб от возможных атак.

За последние несколько лет линейка наших продуктов серьезно расширилась — к известной многим на рынке системе MaxPatrol добавился целый ряд новых инструментов от межсетевых экранов уровня приложений до инструментов управления инцидентами. Такое развитие поставило нас перед необходимостью адаптации процессов разработки в компании — поэтому мы активно внедряем в свою работу практики DevOps и связанные с этим технологии.

Сегодня мы хотим рассказать вам о модели созданной нами системы Continuous Integration.

Здравствуйте! О разработке chef кукбуков и связанной с ней инфраструктурой написано немало, да и инструментов в этой области существует уже предостаточно. Среди них можно перечислить такие решения как vagrant, test kitchen, food critic, chef spec, minitest-chef-handler, serverspec, inspec. Все они, в той или иной степени упрощают и ускоряют промышленную разработку и тестирование chef кукбуков и настраиваемой ими инфраструктуры.

Если данная область близка для вас и вы так же имеет некоторое отношение к языку Perl ( точнее к Perl6 ) — то добро пожаловать в топик.

Итак, сегодня я расскажу как я использую Sparrowdo при разработке и тестировании chef кукбуков.

Антон Турецкий (Badoo)

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



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

Для себя мы на эти вопросы ответили, без проблем у нас не было бы никакого внедрения. Какую-то часть проблем мы решаем. Я выделил основные из них, я расскажу вам о них и о том, как мы с ними справились. В конце я порекламирую нас, какие мы замечательные, как мы любим всякие-разные новые велосипеды, как мы их делаем, смотрим, изобретаем. Я вам их покажу, про них расскажу, вы составите какое-то свое мнение. Итак, поехали!

“Не трудности “ломают” вас, а то, как вы их переносите” —  Lou Holtz

В соавторстве с Emmet O’Grady (основателем NimbleCI и Docker Ninja)

В книге Франца Кафки “Превращение” (“Метаморфозы”) человек просыпается однажды утром и обнаруживает, что он превратился в гигантское насекомоподобное существо. Как у инженеров DevOps, у нас есть такие же сюрреалистические моменты в жизни. Мы находим экзотические ошибки “под ковриком” (скрытые в самых труднодоступных местах) или бываем атакованы червями либо другими опасными сущностями. Если вы занимаетесь этим достаточно долго, у вас рано или поздно появится ужасная история, или даже две (поделитесь ими с нами!). В такой момент мы не можем сидеть и ждать, когда наступит кризис, мы должны действовать быстро. Торопясь исправить это как можно раньше, мы должны развернуть (deploy) новую сущность и выпустить новую версию нашего сервиса, устраняя проблему.