Как стать DevOps инженером за полгода или даже быстрее. Часть 6. Запуск приложения

Автор оригинала: Игорь Кантор (Igor Kantor)
  • Перевод
Как стать DevOps инженером за полгода или даже быстрее. Часть 1. Введение
Как стать DevOps инженером за полгода или даже быстрее. Часть 2. Конфигурирование
Как стать DevOps инженером за полгода или даже быстрее. Часть 3. Версии
Как стать DevOps инженером за полгода или даже быстрее. Часть 4. Пакетирование программ
Как стать DevOps инженером за полгода или даже быстрее. Часть 5. Развертывание



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



Готовы к запуску?


Итак, у нас есть наш код, написанный, упакованный и где-нибудь развернутый. Я решил проигнорировать развертывание кода как неизменяемых артефактов машины (например, EC2) и сосредоточиться на контейнерах. Почему?

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

На тот случай, если контейнеры невозможны, так как вы решили написать, упаковать и развернуть свое программное обеспечение как монолитное приложение, то рассмотрите неизменяемый шаблон AMI. Сделайте так и в случае, если вы должны запускать собственные необлачные приложения или коммерческое программное обеспечение, поставляемое по типу «as-is» (как есть). Однако не это является главной темой данной статьи.

Если же у нас есть аккуратно запакованные контейнеры, как же мы их запускаем?

Действительно работающие контейнеры


Самое простое, что вы можете сделать, это просто запустить команду docker run myImage и покончить с этим. Но это не очень хорошая идея, потому что подобное решение не работает, если:

  • этот контейнер внезапно «умрет»;
  • вам нужно иметь больше одного контейнера, чтобы справиться с нагрузкой
  • вам нужно реализовать развертывание с нулевым временем простоя;
  • вы хотите полностью контролировать ваши микросервисы;
  • вы хотите воспользоваться конвейером CI/CD, чтобы быстро доставить продукт клиентам
    и т.д.…

Другими словами, что происходит, когда вам нужно создать настоящее распределенное приложение корпоративного уровня? Очевидно, что это настолько сложный процесс, что примитивная команда docker run с ним просто не справится.

Замечу, что технология команд docker-compose страдает от очень похожего набора проблем. Docker-compose, позволяющая с помощью одной команды запускать множество сервисов, не предназначена для производственных развертываний. Ее цель — локальное прототипирование, быстрое функциональное тестирование или очень мелкомасштабные (например, персональные домашние) развертывания. Короче, это инструмент для рабочих нагрузок пользователя, не приносящих коммерческого дохода.

Итак, оркестровка контейнеров спешит на помощь!

Обзор способов оркестровки контейнеров


Как и во всем остальном в жизни, существует не один способ решить проблему. Первый и самый очевидный – это Kubernetes. Рожденный из внутреннего проекта Google, Kubernetes де-факто является стандартом оркестровки контейнеров.



Кроме того, это единственный вариант, если вы запускаете свое приложение в:

  • частном дата-центре;
  • Google Cloud;
  • Microsoft Azure;
  • любом другом публичном облаке.

Однако если вы работаете в AWS, у вас есть еще один вариант — ECS. Хотя, строго говоря, это не совсем так: у вас есть Nomad от Hashicorp (это те же люди, которые дали вам Terraform) и у вас есть Docker Swarm от Docker. Проблема в том, что существует очень много нишевых платформ с минимальным внедрением, поэтому в целях быстрого карьерного роста мы их игнорируем.
Так или иначе, вернемся к AWS Elastic Container Services (ECS). Это полностью управляемый сервис оркестровки контейнеров, довольно простой для начала работы, который тесно интегрирован с остальной частью экосистемы AWS. Он делает всего несколько вещей, но зато делает их хорошо. Короче говоря, это в значительной степени противоположность Kubernetes, и если ECS был достаточно хорош для компании McDonald's, то, вероятно, он достаточно хорош и для вас.

Однако, чисто с точки зрения немедленного карьерного роста, нет никаких сомнений в том, что Kubernetes является лучшим выбором. Хотя я готов поспорить, что 99% предприятий, работающих в AWS, прекрасно удовлетворит и ECS.

Итак, теперь вы можете сделать выбор. Если вы полный нуб в этой области, то сможете закалить себя с помощью Kubernetes, ведь вне команды единомышленников — инженеров DevOps, которые могут поддержать вас в вашем путешествии, это нелегкая задача! На картинке ниже показано, как будущий инженер DevOps изучает систему доступа на основе ролей Kubernetes.



Однако это определенно возможно, особенно с предложениями бесплатного использования Google и AWS, учебниками YouTube / Udemy и спотовыми ценами AWS. Если вы выбрали этот маршрут, я рекомендую вам начать с бесплатного уровня Google Cloud Platform Free Tier или kops, запускающих спотовые экземпляры AWS. Kubernetes (EKS) под управлением Amazon стоит денег и, хотя подходит для рабочих prod-нагрузок, не является хорошим способом для начала изучения правильного запуска приложений. И я не достаточно знаю об Azure, чтобы его рекомендовать.
Однако если вы не новичок в этой области и действительно работаете в рамках экосистемы AWS, мой совет заключается в следующем. Сделайте ваши микросервисы контейнерными и разверните их в ECS, чтобы спокойно спать ночью и параллельно работать над созданием платформы Kubernetes мирового класса. Дело в том, что погружение с головой в Kubernetes подобно «бритью яков», которого вы даже не можете себе вообразить, и неизбежно отвлечет вас от вашей истинной миссии — быстро и эффективно доставлять продукты клиентам.

Примечание: «Yak shaving» — это термин программирования, означающий ряд задач, которые необходимо выполнить, прежде чем проект сможет продвинуться к своей следующей вехе. Он был придуман Карлин Вьери, вдохновленной эпизодом «The Ren & Stimpy Show». Название термина намекает на кажущуюся бесполезность выполняемых задач, даже если они могут быть необходимы для решения более крупной проблемы.

Действительно ли вам нужен Kubernetis? Нет. А если вы очень хотите с ним работать? Тогда «да». Понятно? Рынок говорит: «либо Kubernetes, либо go home». Поэтому давайте быстро взглянем, на что вы подписываетесь, связавшись с этой штукой.

Во-первых, несмотря на впечатление ультрасовременной технологии, идея Kubernetes относительно стара. Когда Google снял обертки с Borg (предшественника Kubernetes) в 2015 году, это уже тогда это была довольно старая идея.

Прочитайте это: «Мы представляем краткое описание архитектуры и особенностей системы Borg, важные проектные решения, количественный анализ некоторых ее политических решений и качественный анализ уроков, извлеченных из десятилетнего опыта работы с ней». Прочитайте это еще раз! В 2015 году (!), Google делился подробностями запуска системы, подобной Kubernetes, которой на тот момент исполнилось более десяти лет.



Однако сами они этого не стесняются. Вот первое предложение на домашней странице Kubernetes: «Kubernetes (K8s) — это система с открытым исходным кодом для автоматизации развертывания, масштабирования и управления контейнерными приложениями. Она группирует контейнеры, составляющие приложение, в логические блоки для удобства управления и обнаружения. Kubernetes опирается на 15-летний опыт работы с производственными рабочими нагрузками в Google в сочетании с лучшими идеями и практиками сообщества».

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

Наконец, один из оригинальных разработчиков Kubernetes и его самый активный сторонник, Келси Хайтауэр, также подчеркивает этот момент: «Kubernetes предназначен для людей, создающих целые платформы. Если вы разработчик, создающий свою собственную платформу (AppEngine, Cloud Foundry или клон Heroku), Kubernetes это то, что вам нужно».

Таким образом, если вы работаете в планетарных масштабах, или запускаете миллиарды контейнеров в неделю, или создаете облако для других пользователей, Kubernetes — правильный выбор. А если нет, то это еще не конец истории. И меня не волнует, что твоя бабушка прочитала кучу твитов Келси во время обеденного перерыва, а затем преобразовала свой сайт цветочного магазина в Kubernetes за неделю с помощью CI / CD и Automated Canary Analysis. Для вас это неподходящий инструмент, если только характер вашего продукта не требует использовать именно его.

Но разве это имеет какое-то значение? Kubernetes = $$$. Так что повышайте уровень, наслаждайтесь путешествием в мир DevOps и делитесь со мной своими впечатлениями.
Примечание переводчика: статья #7 о мониторинге приложений на основе ELK Stack до сих пор не опубликована.

Продолжение будет совсем скоро…

Немного рекламы :)


Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас, оформив заказ или порекомендовав знакомым, облачные VPS для разработчиков от $4.99, уникальный аналог entry-level серверов, который был придуман нами для Вас: Вся правда о VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps от $19 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).

Dell R730xd в 2 раза дешевле в дата-центре Equinix Tier IV в Амстердаме? Только у нас 2 х Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ТВ от $199 в Нидерландах! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — от $99! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки?
ua-hosting.company
Хостинг-провайдер: серверы в NL до 300 Гбит/с

Комментарии 4

    0
    ИМХО, не очень корректный посыл, что если Kubernetes сделан для ultra-high-load, то его не стоит применять для чего-то ещё. В настоящий момент ценность Kubernetes в том, что это фактический стандарт, что позволяет в 90% случаев вместо 100500 узко специализированных решений (которые каждое в своей области справилось бы лучше) знать 1, пусть и сложное.
      0

      Сложно согласиться. Мне кажется, надо знать о различных решениях и применять то, которое лучше всего подходит. Пихать все в k8s и пихать k8s всюду — признак как раз узкого кругозора. А для DevOps технический кругозор обязателен.

        0
        С другой стороны, можно знать одно решение хорошо или много решений как получится (на то, чтобы знать все времени не хватит).
          0

          Если вы хотите стать админом этого одного решения (того же к8с-а, например), то вполне можно изучить один инструмент. А вот инженеру нужно иметь кругозор, потому что если он будет всюду пихать один и тот же инструмент, то его решения будут малоэффективны.

    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

    Самое читаемое