Как стать DevOps инженером за полгода или даже быстрее. Часть 1. Введение
Как стать DevOps инженером за полгода или даже быстрее. Часть 2. Конфигурирование
Как стать DevOps инженером за полгода или даже быстрее. Часть 3. Версии
Рассмотрим, как упаковать ваш код для легкого развертывания и последующего выполнения. Напомню, что сейчас мы находимся здесь:
Независимо от того, разговариваете ли вы со своими нынешними или будущими работодателями, вы должны быть в состоянии четко сформулировать, что такое DevOps и почему это важно.
Изложите последовательную историю о том, как лучше всего быстро и эффективно доставить код с ноутбука разработчика до места развертывания конечного продукта с извлечением соответствующей прибыли. Мы изучаем не кучу разрозненных, модных инструментов DevOps, а набор навыков, руководствуясь потребностями бизнеса и опираясь на технические инструменты. Помните, что изучение каждого этапа DevOps занимает примерно месяц обучения, что в общей сложности займет у вас шесть месяцев.
Помните физические серверы? Те самые серверы, для которых вы неделями ждали одобрения заказа на поставку, согласования процесса отправки, одобрения дата-центром, подключения к сети, установки ОС и патчей? Такими серверы пришли в нашу жизнь.
Представьте себе, что единственный способ обрести жилище — это построить совершенно новый дом. Вам ведь нужно где-то жить? Вот и ждите, пока его построят, сколько бы времени это ни заняло! Вроде бы круто, потому что каждый получает собственный дом, но обременительно, потому что его строительство занимает много времени. Следуя этой аналогии, физический сервер подобен дому.
Со временем этот процесс стал раздражать, и действительно умные люди придумали идею виртуализации. Они решили запустить кучу воображаемых машин на одной физической машине и заставили каждую из них притворяться настоящей машиной. Гениально!
Поэтому, если вам действительно нужен дом, вы можете построить свой собственный и подождать шесть недель. Или же вы можете заселиться в многоквартирный дом и делиться ресурсами с другими жильцами. Может быть, не так круто, но достаточно хорошо! И самое главное, вам не нужно ничего ждать!
Так продолжалось некоторое время, и такие компании, как VMWare, наварили на этом серьезный капитал. Затем другие умные люди решили, что запихивать кучу виртуальных машин в физическую машину недостаточно: нужна более компактная упаковка большего количества процессов в меньшее количество ресурсов.
Итак, дом или даже квартира обходится слишком дорого, так может попробовать просто временно снимать комнату? Причем я могу въезжать и выезжать из нее в любой момент! Вот что по сути представляет собой Docker по состоянию на декабрь 2018 года.
Docker – это новая технология, базирующаяся на очень старой идее. Операционная система FreeBSD содержала концепцию механизма виртуализации jail, которая восходит к 2000 году! Воистину, все новое — это хорошо забытое старое.
И тогда, и сейчас идея состояла в том, чтобы изолировать отдельные процессы внутри одной и той же операционной системы на основе operating system level virtualization, или «виртуализации на уровне системы». Учтите, это не то же самое, что full virtualization, или «полная виртуализация», которая запускает виртуальные машины бок о бок на одном физическом хосте.
На практике это означает, что рост популярности Docker точно отражает рост микросервисов — подхода к разработке программного обеспечения, при котором программное обеспечение разбивается на множество отдельных компонентов. И все эти компоненты нуждаются в своем доме. Развертывание их по отдельности, как автономных Java-приложений или двоичных исполняемых файлов — это огромная боль: то, как вы управляете Java-приложением, отличается от того, как вы управляете приложением C++, и это, в свою очередь, отличается от управления приложением Golang.
Вместо этого Docker предоставляет единый интерфейс управления, который позволяет программистам упаковывать, последовательно развертывать и запускать различные приложения. Это огромная победа, но давайте поговорим о плюсах и минусах Docker.
Докер позволяет каждой службе иметь полностью изолировать процесс. Служба А живет в своем собственном маленьком контейнере, со всеми своими зависимостями, служба B тоже живет в своем личном контейнере со всеми своими зависимостями, и эти две службы не конфликтуют.
Более того, если один контейнер выходит из строя, то пострадает только этот контейнер.
Остальные контейнеры будут и должны продолжать работать. Такой механизм идет на пользу безопасности. Если контейнер скомпрометирован, то будет очень трудно (но не невозможно!) выйти из него, чтобы взломать базовую ОС.
Наконец, если контейнер ведет себя неправильно (потребляет слишком много ресурсов процессора или памяти), можно уменьшить «радиус взрыва» только для этого контейнера, не затрагивая остальную часть системы.
Подумайте о том, как различные приложения строятся на практике. Если это приложение Python, то у него будет множество различных пакетов Python. Некоторые из них будут установлены в виде модулей pip, другие — в виде пакетов rpm или deb, а третьи — в виде простых установок git-clone. Или, если это сделано с virtualenv, то это будет один zip-файл всех зависимостей в каталоге virtualenv.
С другой стороны, если это приложение Java, то у него будет сборка Gradle Built, со всеми ее зависимостями, вытянутыми и разбросанными в соответствующих местах.
Понимаете, в чем дело? Различные приложения, сборки с разными языками и разным временем выполнения создают проблему, когда речь заходит о развертывании этих приложений для prod. Кроме того, проблема усугубляется, если возникают конфликты. Что делать, если служба A зависит от библиотеки Python v1, а служба B — от библиотеки Python v2? Здесь возникает конфликт, поскольку v1 и v2 не могут сосуществовать на одной и той же машине.
И тут в игру вступает Docker. Он позволяет полностью изолировать не только процесс, но и зависимости. Вполне возможно иметь несколько контейнеров, работающих бок о бок, на одной и той же ОС, каждый из которых содержит свои собственные, не совместимые с другими, библиотеки и пакеты.
Замечу, что то, как мы управляем разрозненными приложениями, зависит от самого приложения. Код 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, у него есть и недостатки.
Во-первых, запущенный 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 евро за копейки?
Как стать 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 евро за копейки?
