Почему контейнеры важны?

Завершено

В этом уроке вы будете следовать команде Tailspin, как они обсуждают некоторые необходимые улучшения в процессе DevOps. В этом сценарии команда использует Docker для контейнеризации своего веб-приложения. Затем команда обновляет свой конвейер CI/CD, чтобы поддерживать его.

Это были несколько тяжёлых недель.

Последние несколько недель были сложным временем в Tailspin. Команды не успевают уложиться в сроки по ряду причин, и есть беспокойство о производительности по всей компании. Энди призвал некоторых ключевых заинтересованных лиц из команды веб-сайта Space Game вместе собрать отзывы о предстоящей презентации для управления.

Энди: Спасибо за остановку. Я знаю, что последние несколько недель были тяжёлыми для всех, но у меня есть несколько хороших новостей. Руководство проводит выездное совещание завтра, чтобы услышать предложения, какие изменения мы можем внести для улучшения производительности. Они пригласили меня представить примеры наших успехов DevOps и сказали, что они также открыты для любых других идей, которые мы могли бы иметь. Я надеялся, что мы могли бы использовать эту встречу в качестве возможности для мозгового штурма. Кто хочет пойти первым?

Все смотрят на Амиту. Она была особенно разочарована в последнее время.

Амита: я пойду сначала. Как вы знаете, я тестируем для нескольких команд, и это может быть сложно, потому что каждая команда использует свой собственный стек технологий. Даже если они используют те же базовые платформы, например .NET или Java, они часто предназначены для разных версий. Я чувствую, что иногда трачу половину своего дня, просто приводя тестовые среды в состояние, когда они могут запускать код, который мне нужно проверить. Если что-то не работает, трудно определить, есть ли ошибка в коде или если я случайно настроили версию 4.2.3 вместо 4.3.2.

Энди пишет "Сложности версионирования зависимостей для QA" на доске.

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

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

Мара: у меня есть кое-что по части разработки. Несколько недель назад я работал над одноранговой системой обновлений, и она отлично работала на моем компьютере. Но когда я передал его для развертывания, он не работал в рабочей среде. Я забыл, что мне нужно было открыть порт 315 в рамках службы. У нас ушло больше дня на устранение неполадок, чтобы разобраться, что происходит. Когда мы открыли это в производственной среде, все работало должным образом.

Энди записывает "Несоответствия конфигурации между этапами развертывания" на доске.

Энди: Я думаю, что этот разговор — это хороший старт. Позвольте мне исследовать эти вопросы и посмотреть, что я могу придумать. Вот опасения, которые я слышал:

  • Проблемы версионирования зависимостей для QA
  • Издержки из-за решения изоляции приложений с помощью виртуальных машин
  • Несоответствия конфигурации между этапами развертывания

Объединение всех элементов (в одном контейнере)

На следующее утро Энди вызывает собрание, чтобы представить новую идею команде.

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

Амита: Что такое контейнер? Это как файл .zip?

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

Тим: Как она справляется с безопасностью и изоляцией?

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

Амита: Это отлично подходит для рабочей среды, но решает ли она проблемы, с которыми мы сталкиваемся ранее в конвейере?

Энди: Абсолютно! Вместо доставки исходного кода или набора двоичных файлов весь контейнер становится артефактом. Это означает, что при разработке Мара её сеансы отладки выполняются локально в контейнере, размещенном на её компьютере. Когда Амита проводит тестирование, она тестирует в сравнении с копией того же контейнера, которая уже включает все необходимые версии зависимостей. Когда Тим управляет нашей рабочей средой, контейнеры, которые он отслеживает, являются автономными копиями одних и того же контейнера, разработанных Марой и протестированными Амита.

Мара: Насколько сложно разрабатывать приложение контейнера? Нужно ли вносить значительные изменения в существующий код?

Энди: Контейнеры скорее технология упаковки и развертывания. Они не влияют на базовое программное обеспечение, которое мы пишем. Мы можем просто указать нашим средствам создать контейнер Docker в конце сборки. Затем при отладке приложение выходит из этого локального контейнера вместо локального веб-сервера. На самом деле, такие инструменты, как Visual Studio, даже позволяют переключаться между средами отладки, такими как Docker и IIS Express, чтобы дать нам необходимую гибкость. Я на самом деле скопировал наш проект веб-сайта вчера вечером и собрал его в Docker-контейнер, чтобы протестировать процесс. Мне нужно только добавить базовую конфигурацию контейнера; Мне не нужно изменять существующий код.

Мара: Это здорово знать! Бьюсь об заклад, что мы можем даже обновить конвейер выпуска в Azure Pipelines из вашего форка, чтобы создать и развернуть версию Docker.

Энди: Вы читали мое мнение.

Что такое Docker?

Docker — это технология автоматизации упаковки и развертывания переносимых самодостаточного контейнеров. Контейнеры Docker могут работать в любом месте, где находится узел Docker, будь то на компьютере разработки, отделальном сервере, корпоративном центре обработки данных или в облаке. Azure предоставляет несколько способов запуска приложений на основе контейнеров, включая службу приложений или в составе кластеров, управляемых с помощью технологий оркестрации, таких как Kubernetes.

Команда Tailspin выбрала контейнеры Docker для этого сценария, так как она соответствовала всем своим потребностям:

  • проблемы управления версиями зависимостей для QA: приложения упаковываются в виде контейнеров, которые предоставляют правильные версии их зависимостей.

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

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

Внедрение контейнеров Docker может быть ключевым шагом к архитектуре микрослужб. Далее мы обсудим это.

Проверка знаний

1.

Какой из следующих параметров не является хорошей причиной для использования Docker?

2.

Как похожи контейнеры и виртуальные машины?

3.

Сколько накладных расходов требуется перенос существующего приложения .NET Core для использования контейнера Docker?