Что будет под катом:

• Базовые настройки Nagios в связке с Telegram.
• Общая концепция нашего с коллегами мониторинга проектов.
• Разбор граблей, на которые мы успели наступить при работе с этой системой.

Наша статья будет полезна для тех, кто:

• Недоволен информативностью своего текущего мониторинга.
• Испытывает ежедневную боль ниже спины с оповещениями о проблемах.

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

Узнать больше и увидеть NGINX Amplify в действии можно записавшись на онлайн вебинар, который пройдет 13 июля в 20:00 по московскому времени.

Также, вы можете начать бесплатно использовать NGINX Amplify прямо сейчас, пройдя регистрацию.

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

Вкратце:

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

Вкратце:

1. cfnetwork — Puppet API для полной настройки сети и фильтра через ресурсы Puppet. Идеально дружит с Hiera и потенциально другими "data providers" в концепции Puppet.
2. cffirehol — "meta-provider" конкретной реализации настройки фильтра для cfnetwork на базе замечательного генератора FireHOL
3. Пока поддерживаются только Debian 8+ (Jessie и выше) и Ubuntu 14.04+ (Trusty и выше)

Сегодня многие говорят о DevOps как о методологии, которая помогает разрушить «железный занавес» между IT отделом, QA и программистами и создать некий общий механизм, помогающий делать продукты быстрее и качественнее. Основная задача, которая встает перед DevOps разработчиком — это добиться максимальной автоматизации развертывания development. testing, production сред и переходов между ними. Соответственно одна из основных проблем в данном случае — это соблюсти полную идентичность сред разработки, тестирования и эксплуатации. Под катом приведу пример практического решения данной задачи, которое я использовал в нескольких компаниях в ходе интеграции DevOps методологии.

Конференция закончилась всего несколько часов назад, поэтому в голове еще небольшой сумбур от количества и качества полученной информации. Надеюсь, написав этот пост у меня получиться разобраться в собственных мыслях. Сначала будут общие впечатления, затем кратко пробегусь по докладам и закончу мыслями на тему того, о чем говорили на конференции, благо таких мыслей накопилось по ходу прилично. Хотите узнать, о чем сейчас говорят в мире DevOps? Тогда вам под кат. И да, пост будет длинным, но в конце будет бонус-сюрприз).

От переводчика. Продолжая серию переводов про DevOps, в этот раз хочется поговорить о том, как делать НЕ надо. Мы сталкивались с этим, каждый раз, когда приходит что-то новое, например agile. Возникают культы карго, слышаться речи, что мы особенные и у нас все не так и так далее. Так давайте же попробуем избежать этого в случае DevOps.

Итак, вы хотите стать DevOps? Хорошо, но прежде чем начать, давайте взглянем на некоторые вещи, которые вы не должны делать.

В старые добрые времена, мы просто называли их «плохие идеи», но появилась дипломатия и политкорректность, ушел «мозговой штурм» и появился «idea shower», а вместе с ним и слово «анти-паттерны».

Если «паттерн» это правильный путь, то по своей сути «анти-паттерн» является неправильным — и поэтому, чтобы не дать вам пойти неверным путем, мы составили этот список (с небольшой помощью DevOps сообщества).

(Продолжение перевода, первая часть здесь)

8. Как Infosec и QA интегрируются в поток работ DevOps?

Высокие темпы развертывания обычно ассоциируемые с DevOps, часто оказывают огромное давление на QA и Infosec. Рассмотрим случай, когда разработчики делают десять развертываний в день, в то время как безопасники требуют четырехмесячного тестирования безопасности приложения. На первый взгляд, все это выглядит как тотальное несоответствие между темпами разработки и тестирования безопасности.

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

От переводчика

В 2009 года за рубежом возникло движение, которое назвало себя DevOps. На первый взгляд это разработчики с навыками сисадминов и сисадмины с навыками разработчиков. Но на самом деле это отнюдь не так. Данное подход имеет четкие цели, философию, инструменты и методы, которые только некоторые русскоязычные компании начинают использовать. Мне кажется, что данный подход у нас незаслуженно игнорируется и мне хотелось бы рассказать об 11 вещах, которые нужно знать о DevOps, в частности:

• что такое DevOps
• каковы его ценности
• как он внедряется
• кому он приносит пользу

Надеюсь, этот текст вам понравится.