Джин Ким - Руководство по DevOps

Здесь есть возможность читать онлайн «Джин Ким - Руководство по DevOps» весь текст электронной книги совершенно бесплатно (целиком полную версию без сокращений). В некоторых случаях можно слушать аудио, скачать через торрент в формате fb2 и присутствует краткое содержание. Город: Москва, Год выпуска: 2018, ISBN: 2018, Издательство: Манн, Иванов и Фербер, Жанр: Интернет, Базы данных, Прочая околокомпьтерная литература, на русском языке. Описание произведения, (предисловие) а так же отзывы посетителей доступны на портале библиотеки ЛибКат.

Руководство по DevOps: краткое содержание, описание и аннотация

Предлагаем к чтению аннотацию, описание, краткое содержание или предисловие (зависит от того, что написал сам автор книги «Руководство по DevOps»). Если вы не нашли необходимую информацию о книге — напишите в комментариях, мы постараемся отыскать её.

Профессиональное движение DevOps зародилось в 2009 году. Его цель — настроить тесные рабочие отношения между разработчиками программного обеспечения и отделами IT-эксплуатации. Внедрение практик DevOps в повседневную жизнь организации позволяет значительно ускорить выполнение запланированных работ, увеличить частоту релизов, одновременно повышая безопасность, надежность и устойчивость производственной среды. Эта книга представляет собой наиболее полное и исчерпывающее руководство по DevOps, написанное ведущими мировыми специалистами.

Руководство по DevOps — читать онлайн бесплатно полную книгу (весь текст) целиком

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

Тёмная тема
Сбросить

Интервал:

Закладка:

Сделать

Кэмпбел-Претти отмечала: «Неожиданно мы поняли, почему каждый раз при развертывании нашего кода в новых средах сталкивались с таким количеством дефектов. В каждой среде мы продвигались вперед с исправлением ошибок, но сделанные изменения не попадали в хранилище контроля версий».

Команда тщательно выполнила реверсивное проектирование всех изменений, внесенных в различные среды, и зафиксировала их в хранилище контроля версий. Она также автоматизировала процесс создания сред, с тем чтобы можно было создавать их повторно и правильно.

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

История, рассказанная Кэмпбел-Претти, демонстрирует разнообразие проблем в системе, где использовались несовместимые среды и систематически не вносились изменения в хранилище контроля версий.

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

Обеспечить создание сред по требованию для разработчиков, тестировщиков и эксплуатации

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

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

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

Вместо того чтобы просто описывать характеристики производственной среды в документе или на странице wiki, мы создаем механизм, создающий все наши среды, в том числе для разработки, тестирования и производства. При этом любой член команды может получить среду, близкую к производственной, через несколько минут без необходимости создавать задачу на выполнение работы, не говоря уже о необходимости ждать неделями [63].

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

Вместо того чтобы отдел эксплуатации вручную создавал и настраивал среду, мы можем использовать автоматизацию для следующих способов создания среды:

• копирование виртуализированной среды (например, образа VMware, запуск сценария Vagrant, загрузка файла Amazon Machine Image в EC2);

• создание процесса автоматизированного формирования среды, который начинает работу с нуля (например, PXE — установка из базовых образов);

• с помощью инструментов управления конфигурациями «инфраструктура как код» (например, Puppet, Chef, Ansible, Salt, CFEngine и так далее);

• с помощью автоматизированных инструментов конфигурации операционной системы (например, Solaris Jumpstart, Red Hat Kickstart, Debian preseed);

Читать дальше
Тёмная тема
Сбросить

Интервал:

Закладка:

Сделать

Похожие книги на «Руководство по DevOps»

Представляем Вашему вниманию похожие книги на «Руководство по DevOps» списком для выбора. Мы отобрали схожую по названию и смыслу литературу в надежде предоставить читателям больше вариантов отыскать новые, интересные, ещё непрочитанные произведения.


Николь Форсгрен - Ускоряйся! Наука DevOps
Николь Форсгрен
Отзывы о книге «Руководство по DevOps»

Обсуждение, отзывы о книге «Руководство по DevOps» и просто собственные мнения читателей. Оставьте ваши комментарии, напишите, что Вы думаете о произведении, его смысле или главных героях. Укажите что конкретно понравилось, а что нет, и почему Вы так считаете.

x