Как стать DevOps инженером за полгода или даже быстрее. Часть 4. Пакетирование программ

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



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



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

Учебник по виртуализации


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

Представьте себе, что единственный способ обрести жилище — это построить совершенно новый дом. Вам ведь нужно где-то жить? Вот и ждите, пока его построят, сколько бы времени это ни заняло! Вроде бы круто, потому что каждый получает собственный дом, но обременительно, потому что его строительство занимает много времени. Следуя этой аналогии, физический сервер подобен дому.

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

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

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

Итак, дом или даже квартира обходится слишком дорого, так может попробовать просто временно снимать комнату? Причем я могу въезжать и выезжать из нее в любой момент! Вот что по сути представляет собой Docker по состоянию на декабрь 2018 года.



Рождение Docker


Docker – это новая технология, базирующаяся на очень старой идее. Операционная система FreeBSD содержала концепцию механизма виртуализации jail, которая восходит к 2000 году! Воистину, все новое — это хорошо забытое старое.

И тогда, и сейчас идея состояла в том, чтобы изолировать отдельные процессы внутри одной и той же операционной системы на основе operating system level virtualization, или «виртуализации на уровне системы». Учтите, это не то же самое, что full virtualization, или «полная виртуализация», которая запускает виртуальные машины бок о бок на одном физическом хосте.

На практике это означает, что рост популярности Docker точно отражает рост микросервисов — подхода к разработке программного обеспечения, при котором программное обеспечение разбивается на множество отдельных компонентов. И все эти компоненты нуждаются в своем доме. Развертывание их по отдельности, как автономных Java-приложений или двоичных исполняемых файлов — это огромная боль: то, как вы управляете Java-приложением, отличается от того, как вы управляете приложением C++, и это, в свою очередь, отличается от управления приложением Golang.

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

Преимущества Docker


1. Изоляция процессов


Докер позволяет каждой службе иметь полностью изолировать процесс. Служба А живет в своем собственном маленьком контейнере, со всеми своими зависимостями, служба B тоже живет в своем личном контейнере со всеми своими зависимостями, и эти две службы не конфликтуют.

Более того, если один контейнер выходит из строя, то пострадает только этот контейнер.

Остальные контейнеры будут и должны продолжать работать. Такой механизм идет на пользу безопасности. Если контейнер скомпрометирован, то будет очень трудно (но не невозможно!) выйти из него, чтобы взломать базовую ОС.

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

2. Развертывание


Подумайте о том, как различные приложения строятся на практике. Если это приложение Python, то у него будет множество различных пакетов Python. Некоторые из них будут установлены в виде модулей pip, другие — в виде пакетов rpm или deb, а третьи — в виде простых установок git-clone. Или, если это сделано с virtualenv, то это будет один zip-файл всех зависимостей в каталоге virtualenv.

С другой стороны, если это приложение Java, то у него будет сборка Gradle Built, со всеми ее зависимостями, вытянутыми и разбросанными в соответствующих местах.

Понимаете, в чем дело? Различные приложения, сборки с разными языками и разным временем выполнения создают проблему, когда речь заходит о развертывании этих приложений для prod. Кроме того, проблема усугубляется, если возникают конфликты. Что делать, если служба A зависит от библиотеки Python v1, а служба B — от библиотеки Python v2? Здесь возникает конфликт, поскольку v1 и v2 не могут сосуществовать на одной и той же машине.

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

3. Управление выполнением программ


Замечу, что то, как мы управляем разрозненными приложениями, зависит от самого приложения. Код Java прописывается в реестре по-другому, запускается по-другому и отслеживается по-другому, чем код Python. А Python отличается от Golang и т. д.

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

С декабря 2018 года вам больше не придется делать выбор между быстрым запуском Docker и безопасностью виртуальных машин. Проект легковесной платформы виртуализации Fireckracker, представленный Amazon, попытался объединить лучшее из обоих решений. Тем не менее, это новая технология, которая только приближается к этапу prod.



Примечание: Платформа Firecracker предоставляет средства для создания и управления изолированными окружениями и сервисами, построенными с использованием бессерверной модели разработки. Код проекта написан на языке Rust и распространяется под лицензией Apache 2.0.

Firecracker предлагает легковесные виртуальные машины, именуемые microVM. Для их полноценной изоляции применяются технологии аппаратной виртуализации, но при этом обеспечивается производительность и гибкость на уровне обычных контейнеров. Основу платформы составляет монитор виртуальных машин (VMM), использующий встроенный в ядро Linux гипервизор KVM. VMM основан на наработках написанного на языке Rust проекта crosvm, который компания Google развивает с целью запуска Linux в ChromеOS. По состоянию на конец 2018 года кодовые базы crosvm и Firecracker разделились, но Amazon планирует передавать в upstream исправления, вносимые в заимствованные компоненты.

Однако, как бы ни был хорош Docker, у него есть и недостатки.

Введение в Lambda


Во-первых, запущенный Docker все еще продолжает работать на серверах, которые должны быть подготовлены, пропатчены и т.д. Во-вторых, Docker не является 100% безопасным. По крайней мере, он не настолько безопасен, как виртуальная машина. Существует причина, по которой огромные компании, работающие с размещенными контейнерами, делают это внутри виртуальных машин, а не на «голом железе». Им нужны быстрые сроки запуска контейнеров и безопасность виртуальных машин!



В-третьих, никто на самом деле не управляет «Докером» как таковым. Вместо этого он почти всегда развертывается как часть сложной структуры оркестровки контейнеров, такой как Kubernetes, ECS, docker-swarm или Nomad. Это довольно сложные платформы, которые требуют специального персонала для работы (подробнее об этих решениях я расскажу позже).

Однако, если я всего лишь разработчик, то просто хочу написать код и попросить кого-то запустить его для меня. Docker, Kubernetes и прочий джаз — неужели я обязан все это изучить? Скажу так: все зависит от обстоятельств. Для людей, которые просто хотят, чтобы кто-то другой запускал их код, облачное хранилище данных AWS Lambda и подобные ему штуки отличный вариант.

AWS Lambda позволяет запускать код без подготовки и управления серверами. Вы платите только за потребляемое вами вычислительное время, и когда ваш код не работает, плата не взимается.
Если вы слышали о бессерверном хранилище, то это оно и есть. Больше никаких серверов для запуска или контейнеров для управления! Просто напишите свой код, упакуйте его в zip-файл, загрузите на Amazon, и пусть они разбираются с вашей головной болью! Кроме того, поскольку «лямбды» недолговечны, взламывать их нечего — «лямбды» довольно безопасны по своей конструкции. Правда, здорово?

Но есть и негативные моменты. Во-первых, «лямбды» могут работать только в течение максимум 15 минут (по состоянию на ноябрь 2018 года). Это означает, что длительно работающие процессы, такие как Kafka или приложения для взлома чисел, не могут работать в Lambda.

Во-вторых, «лямбды» представляют собой Functions-as-a-Service (функции как услуга). Это означает, что ваше приложение должно быть полностью разложено на микросервисы и синхронизировано с другими сложными сервисами PaaS, такими как AWS Step Functions. Однако не каждое предприятие находится на таком уровне архитектуры микросервисов.

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

Замечу, что на конец 2018 года существуют также бессерверные облачные контейнерные решения, такие как AWS Fargate. Его механика во многом схожа с Lambda. Если вы только начинаете изучать эти сервисы, настоятельно рекомендую попробовать Fargate, это невероятно простой способ заставить контейнеры работать «правильно». К тому же 13.01.2019 облачные сервисы AWS объявили о значительном снижении цены на Fargate, делает его очень привлекательным выбором для запуска бессерверных контейнеров.



Резюме


Docker и Lambda — два наиболее популярных современных облачных подхода к упаковке, запуску и управлению приложениями. Они часто являются бесплатными, причем оба подходит для различных случаев использования и приложений.

Как бы то ни было, современный инженер DevOps должен хорошо разбираться и в том, и в другом. Поэтому обучение Docker и Lambda — это хорошие краткосрочные и среднесрочные цели.
Замечу, что до сих пор мы имели дело с темами, которые должны знать инженеры DevOps младшего и среднего уровня. В последующих разделах мы начнем обсуждать методы, которые больше подходят для инженеров среднего и старшего уровня DevOps. Как всегда, для обретения знаний не существует легких путей!

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

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


Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас, оформив заказ или порекомендовав знакомым, облачные 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 Гбит/с

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

    0
    Почему вы не упомянули про жесткий vendor lock-in Лямбды и практически отсутствие такового у Докера? Или хотя бы упомянули бы, что в других публичных облаках тоже есть свои аналоги Лямбды.

    Мое понимание такое, что Лямбда хорошо подходит для каких-то простых вещей, например быть прокладкой между сервисами AWS либо служить в качестве простого REST API. Строить сложную логику вокруг Лямбды — это в разы сложнее, чем реализовать то же самое на Докере/Кубере.

    Плюс Докер вы можете спокойно запустить на лэптопе. Сделать то же самое с Лямбдой вы просто не сможете.
        0

        Есть множество способов, позволяющий отлаживать лямбду с окружением (база и api gateway, например) локально. И в чем vendor lock, если лямбда — это просто приложение на одном из распространённых языков? Тот же dotnet запросто вам один и тот же код завернет и как архив для лямбды, и как docker image.
        У лямбды ограничение на доступные ресурсы. Если ваша сложная логика помещается в эти ограничения, то лямбда отличный выбор. Если нет — то еще и не факт, что вам Docker поможет, контейнеры по террабайту и жрущие десятки ядер и гигабайт памяти — не то чтоб ОК.

          0
          Сложная логика — это не про ресурсы, это, например, API Gateway с парой сотен роутов. Сделать такое на Лямбде — это значит быть самому себе врагом. Поддерживать такое решение, то есть поддерживать тестовые окружения, плюс локальные для разработчиков, плюс отлавливать баги, будет очень сложно. С Докером девелопер сможет разрабатывать у себя на ноуте в оффлайне.

          Vendor lock-in — это когда у вас все прекрасно работает, а потом вам вдруг говорит директор, что Амазон — стало слишком дорого, и надо валить на on-premise. И тогда вы с острой болью понимаете, что такое vendor lock-in. С Кубернетес это было бы в сотню раз легче.
            0

            Если вы закатываете раутинг внутрь приложения, то и для лямбды у вас будет просто proxy-API GW, а раутинг будет внутри вашего кода, так же как и в докере. Это очень просто поддерживается.
            Если же у вас раутинг снаружи, то конфигурировать раутинг внутри отдельного докер-контейнера на мой взгляд не проще, чем у API GW.
            И это же касается vendor-lock. Если вы все делаете с оглядкой на мультикауд, то вашему коду будет все равно, на какой платформе крутиться. Если же нет, то переезд с хоста в докер будет для вас такой же проблемой. Это вопрос оптимизации и оценки рисков.

          0
          Плюс Докер вы можете спокойно запустить на лэптопе.

          Угу, конечно. Особенно под Windows Home.

            0
            VirtualBox в помощь, но вообще Windows Home для разработки — это несерьезно.
              0
              VirtualBox в помощь

              Это уже не "спокойно запустить", извините.


              Windows Home для разработки — это несерьезно

              Другие вам скажут что использовать какой бы то ни было Windows для разработки — это несерьёзно. И будут субъективны, как и вы. По факту: IDE работают, компиляторы/интерпретаторы языков работают, всевозможные системы контроля версий работают. В чём заключается несерьёзность?

                0
                Главным образом из-за отсутствия нормальной виртуализации и Докера, ну и плюс невозможность войти в домен. Если вы не используете ни виртуализацию, ни Докер, ни Линукс, а ваша машина исключительно домашняя, то какие вопросы — для вас Windows Home идеально подходит.

                Но мое субъективное мнение, что в большинстве случаев эти вещи все же либо необходимы, либо являются большим плюсом для разработки.
          0
          AWS Fargate действительно хорошее решение для быстрого старта и обслуживания. Но контейнеры на базе EC2 — это все еще более гибкое решение, как в плане цены так и возможных конфигураций. Все зависит от бизнес-требований.
            0
            Когда ждать 5 часть?
              0
              В течении этой или следующей недели.

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

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