Deployment

Недавно я начал применять Terraform для создания облачной лабы для тестов, и это довольно круто. Буквально за несколько дней я поднялся с никогда не использовал AWS до я умею декларативно создавать изолированную инфраструктуру в облаке. Я поставил парочку серверов в выделенной сети в VPC с security group и отдельными ключами SSH, все это заняло у меня несколько сотен строк кода.

Все приятно и прельстиво, но после создания сервера из некоторого базового AMI мне надо его развернуть. Мой типовой инструмент для этого Ansible, но, к сожалению, у Terraform нет встроенного модуля для Ansible (есть обратный, начиная с Ansible 2.5, прим. переводчика), в отличие от Chef и Salt. Это не похоже на Packer, имеющий ansible (удаленный) и ansible-local, который я использовал для сборки образов Docker.

Так что я потратил немножко времени и нашел несколько способов подружить Terraform и Ansible, о чем расскажу в этой статье. Но сначала поговорим о развертывании.

Нужно ли развертывание в облаке?

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

Далее если делаете свои AMI, вам все равно нужно как-то запускать развертывание, так что опять появляются такие вещи, как Ansible. Ну и опять же, я рекомендую использовать Packer вместе с Ansible.

Получается, что в большинстве случаев развертывание нужно, потому что оно неизбежно.

Как использовать Ansible вместе с Terraform

Возвращаемся к задаче развертывания: я нашел три способа использовать Ansible совместно с Terraform после прочтения этого обсуждения. Читайте дальше, чтобы выбрать подходящий вам.

Встроенный inventory с IP сервера

Наиболее очевидное и хакерское решение запускать Ansible с помощью local-exec, например так:

provisioner "local-exec" {    command = "ansible-playbook -i '${self.public_ip},' --private-key ${var.ssh_key_private} provision.yml"}

Просто и приятно, но тут сразу же есть нюанс. local-exec запускается без ожидания запуска сервера, так что в большинстве случаев это не сработает, потому что на момент подключения еще некуда подключаться.

В качестве изящного обходного способа вы можете предварительно использовать remote-exec, который будет ожидать соединения с сервером, а затем запускать local-exec.

В результате у меня получилась следующая вещь, запускающая роль Ansible provisioner:

provisioner "remote-exec" {    inline = ["sudo dnf -y install python"]    connection {      type        = "ssh"      user        = "fedora"      private_key = "${file(var.ssh_key_private)}"    }  }  provisioner "local-exec" {    command = "ansible-playbook -u fedora -i '${self.public_ip},' --private-key ${var.ssh_key_private} provision.yml"  }

Чтобы ansible-playbook работал, вам надо иметь код для Ansible рядом с кодом для Terraform:

$ ll infradrwxrwxr-x. 3 avd avd 4.0K Mar  5 15:54 roles/-rw-rw-r--. 1 avd avd  367 Mar  5 15:19 ansible.cfg-rw-rw-r--. 1 avd avd 2.5K Mar  7 18:54 main.tf-rw-rw-r--. 1 avd avd  454 Mar  5 15:27 variables.tf-rw-rw-r--. 1 avd avd   38 Mar  5 15:54 provision.yml

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

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

Динамический inventory после работы Terraform

Еще одно простое решение для раскатки инфраструктуры, созданной Terraform не связывать вместе Terraform и Ansible. Создаем инфраструктуру с помощью Terraform, а затем используем Ansible с динамическим inventory без привязки к тому, как сервера были созданы.

Так что вы сначала создаете инфраструктуру с помощью terraform apply, затем запускаете ansible-playbook -i inventory site.yml, где inventory каталог, содержащий скрипты динамического inventory.

Это все будет шикарно работать, но есть небольшая ложка дегтя если вам надо увеличить число серверов, не забывайте запускать Ansible после Terraform.

А это то, что я использую в дополнение к предыдущему способу.

Inventory, создаваемая из состояния Terraform

Есть еще одна интересная штука, которая, возможно, будет у вас работать создание статического inventory из состояния Terraform.

Terraform при работе поддерживает состояние инфраструктуры, содержащее все, включая ваши сервера. При использовании local backend это состояние сохраняется в файле JSON, который можно потом легко разобрать и сконвертировать в inventory для Ansible.

Я нашел два проекта с примерами, так что вы можете их использовать, если будете работать с этим способом.

Первый

[all]52.51.215.84[all:vars][server]52.51.215.84[server.0]52.51.215.84[type_aws_instance]52.51.215.84[name_c10k server]52.51.215.84[%_1]52.51.215.84

Второй

$ ~/soft/terraform.py --root . --hostfile## begin hosts generated by terraform.py ##52.51.215.84        C10K Server## end hosts generated by terraform.py ##

Дополнение Ansible для Terraform, которое у меня не заработало

Наконец, есть несколько проектов, которые пытаются внедрить поддержку Ansible в Terraform, как это уже, например, сделано для Chef.

Первая попытка сделать дополнение, но, к сожалению, он уже не поддерживается автором и даже больше не поддерживается актуальной системой дополнений Terraform.

Вторая, более свежая и поддерживаемая, позволяет такой вариант развертывания:

...provisioner "ansible" {    plays {        playbook = "./provision.yml"        hosts = ["${self.public_ip}"]    }    become = "yes"    local = "yes"}...

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

Заключение

Terraform и Ansible мощная связка, которую я использую для развертывания облачной инфраструктуры. Для типовых облачных серверов я запускаю Ansible через local-exec, позднее я запускаю Ansible отдельно с динамическим inventory.

Примеры можно найти здесь.

Благодарю за внимание и до новых встреч!

HashiCorp показала новый проект Waypoint на HashiCorp Digital. Он использует файл на основе HCL для описания сборки, поставки и выпуска приложений для различных облачных платформ, начиная от Kubernetes и заканчивая AWS и Google Cloud Run. Можно представить, что Waypoint это сложенные вместе Terraform и Vagrant для описания процесса сборки, поставки и выпуска ваших приложений.

Не изменяя себе, HashiCorp выпустила Waypoint с открытым исходным кодом, также к нему прилагается множество примеров. Уровень оркестратора остается за вами, Waypoint поставляется в виде исполняемого файла, который вы можете запустить прямиком на вашем ноутбуке или из выбранного вами инструмента оркестрации CI/CD. Цель для развертывания приложений также выбирается вами, поскольку Waypoint поддерживает Kubernetes, Docker, Google Cloud Run, AWS ECS и другие.

Почитав улетную документацию и шикарнейшие примеры приложений, предоставленные HashiCorp, мы решили взглянуть поближе на оркестровку Waypoint с помощью GitLab CI/CD. Чтобы это сделать, мы возьмем простое приложение Node.js, запускаемое на AWS ECS, из репозитория примеров.

После клонирования репозитория посмотрим структуру приложения, отображающего одну страницу:

Как вы могли заметить, в этом проекте нет Dockerfile. Они не добавлены в примере, поскольку они в принципе и не нужны нам, ведь Waypoint позаботится о них за нас. Давайте рассмотрим детальнее файл waypoint.hcl, чтобы понять, что он будет делать:

project = "example-nodejs"app "example-nodejs" {  labels = {    "service" = "example-nodejs",    "env" = "dev"  }  build {    use "pack" {}    registry {    use "aws-ecr" {        region = "us-east-1"        repository = "waypoint-gitlab"        tag = "latest"    }    }  }  deploy {    use "aws-ecs" {    region = "us-east-1"    memory = "512"    }  }}

На этапе сборки Waypoint использует Cloud Native Buildpacks (CNB), чтобы определить язык программирования проекта и создать образ для Docker без использования Dockerfile. В принципе, это та же самая технология, которая используется GitLab в части Auto DevOps на шаге Auto Build. Приятно видеть, что CNB от CNCF получает все большее распространение у пользователей из отрасли.

Как только образ собран, Waypoint автоматически выгрузит его в нашу AWS ECR registry, чтобы он был готов к поставке. По окончанию сборки шаг поставки использует дополнение AWS ECS для развертывания нашего приложения в нашу учетную запись AWS.

С моего ноутбука все просто. Я ставлю Waypoint, который уже аутентифицирован в моей учетной записи AWS, и оно просто работает. Но что будет, если я захочу выйти за пределы моего ноутбука? Или вдруг я хочу автоматизировать это развертывание в виде части моего общего конвейера CI/CD, где запускаются мои текущие интеграционные тесты, тесты безопасности и прочие? Это та часть рассказа, где появляется GitLab CI/CD!

N.B. Если вы еще только планируете внедрение CI/CD или хотите начать применять лучшие практики построения пайплайнов, обратите внимание на новый курс Слёрма CI/CD на примере Gitlab CI. Сейчас он доступен по цене предзаказа.

Waypoint в GitLab CI/CD

Для оркестровки всего этого в GitLab CI/CD давайте посмотри, что нам понадобится в нашем файле .gitlab-ci.yml:

• В первую очередь, нужен базовый образ для запуска внутри него. Waypoint работает на любом дистрибутиве Linux, ему нужен только Docker, так что мы может запускаться с generic образа Docker.
• Далее надо установить Waypoint в этот образ. В будущем мы можем собрать образ meta build и контейнеризировать этот процесс для себя.
• Наконец мы запустим команды Waypoint

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

Для аутентификации GitLab CI\CD в AWS есть несколько вариантов. Первый вариант использование встроенного HashiCorp Vault. Он подойдет, если ваша команда уже пользуется Vault для управления учетными данными. Еще один способ, который подходит, если ваша команда управляет авторизацией с помощью AWS IAM проверьте, что задачи поставки запускаются через GitLab Runner, авторизованный для запуска развертывания через IAM. Но если вы просто хотите ознакомиться с Waypoint и хотите это сделать побыстрее, есть последний вариант добавить ваши ключи AWS API и Secret в переменные окружения GitLab CI/CD AWS_ACCESS_KEY_ID и AWS_SECRET_ACCESS_KEY.

Собираем все вместе

Как только мы разобрались с аутентификацией, можно начинать! Наш окончательный .gitlab-ci.yml выглядит так:

waypoint:  image: docker:latest  stage: build  services:    - docker:dind  # Define environment variables, e.g. `WAYPOINT_VERSION: '0.1.1'`  variables:    WAYPOINT_VERSION: ''    WAYPOINT_SERVER_ADDR: ''    WAYPOINT_SERVER_TOKEN: ''    WAYPOINT_SERVER_TLS: '1'    WAYPOINT_SERVER_TLS_SKIP_VERIFY: '1'  script:    - wget -q -O /tmp/waypoint.zip https://releases.hashicorp.com/waypoint/${WAYPOINT_VERSION}/waypoint_${WAYPOINT_VERSION}_linux_amd64.zip    - unzip -d /usr/local/bin /tmp/waypoint.zip    - rm -rf /tmp/waypoint*    - waypoint init    - waypoint build    - waypoint deploy    - waypoint release

Вы видите, что мы начинаем с образа docker:latest и устанавливаем несколько переменных окружения, требуемых для Waypoint. В разделе script мы скачиваем последнюю версию исполняемого файла Waypoint и ставим его в /usr/local/bin. Поскольку наш runner уже авторизован в AWS, далее мы просто запускаем waypoint init, build, deploy и release.

Вывод задачи по сборке покажет нам endpoint, куда мы раскатили приложение:

Waypoint одно из многочисленных решений HashiCorp, отлично работающих с GitLab. Например, в дополнение к поставке приложения мы можем оркестрировать нижележащую инфраструктуру с помощью Terraform в GitLab. Для стандартизации безопасности SDLC, мы можем также внедрить GitLab с Vault для управления секретами и токенами в конвейерах CI/CD, предоставляя целостное решение для разработчиков и администраторов, полагающихся на управление секретами при разработке, тестировании, а также промышленном использовании.

Совместные решения, разработанные HashiCorp и GitLab, помогают компаниям найти лучший способ разработки приложений, обеспечивая согласованное управление потоками поставки и инфраструктурой. Waypoint сделали еще один шаг в верном направлении, и мы с нетерпением ожидаем дальнейшего развития проекта. Вы можете узнать больше о Waypoint здесь, также стоит изучить документацию и план развития проекта. Мы добавили полученные нами знания в документацию GitLab CI\CD. Если вы хотите попробовать все в работе самостоятельно, можете взять полный работоспособный пример в этом репозитории.

Понять принципы CI/CD, освоить все тонкости работы с Gitlab CI и начать применять лучшие практики можно, пройдя видеокурс CI/CD на примере Gitlab CI. Присоединяйтесь!

Пару недель назад я посмотрела демонстрацию Waypoint нового инструмента, который представила 15 октября 2020 года компания Hashicorp. Инструмента, который предназначен для создания легкого, интуитивного и настраиваемого под пользователя рабочего процесса сборки, развертывания и релиза.

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

Чем Waypoint не является

Наверное, будет проще в начале пояснить, чем Waypoint не является.

Waypoint не:

• автоматическая система сборки программ (как make, npm, maven и т.д.)
• диспетчер пакетов (как helm, pip и т.д.)
• система непрерывной интеграции (как Jenkins, GitHub Actions и т.д.)
• registry артефактов (как Artifactory, Docker Registry и т.д.)
• среда выполнения (как OCI images, Docker containers, buildpacks, машинный код, архивы и т.д.)
• кластерный оркестратор или кластерная платформа (как Kubernetes, EC2, EKS и т.д.)

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

Что же такое Waypoint?

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

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

Waypoint был построен для простоты использования. Больше не надо писать Dockerfiles, YAML и т.д.У нас есть дополнения для автоматического определения вашего языка, построения образа и развертывания. Да, вам придется немного настроить его, но мы сейчас говорим примерно о пятнадцати сроках текста для одного инструмента в сравнении с сотнями строк в разных инструментах на разных языках программирования.

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

Довольно много слов, и изрядное их количество требует объяснения. Остаток статьи как раз будет посвящен расшифровке того, что все это значит.

Переосмысление схемы работы разработкатестированиеразвертываниевыпуск

Я использую термин схема работы от разработки до релиза, а не непрерывная интеграция и развертывание программного обеспечения (CI/CD), потому что не каждая организация научилась массово использовать CI/CD, даже если все компании действительно разрабатывают и выпускают программное обеспечение с разной периодичностью.
Непрерывно или нет, все схемы работы от разработки до релиза традиционно состоят из различный типовых компонентов:

Разработка: включает в себя сборку исполняемых файлов и библиотек, содержащих изменения кода. Большая часть языков программирования имеют собственный набор системы сборки кода. Большинство вычислительных рабочих окружений имеют собственные поддерживаемые форматы артефактов, как Docker/OCI images, ELF binaries, ZIP archives, платформенно-ориентированные артефакты (как AWS Lambda Layers), и это далеко не полный перечень. Любая схема работы с комплексом инструментальных средств, которая имеет целью обслуживать максимально обширное сообщество разработчиков, вынуждена приспосабливаться к сборке кода и предпочтительного формата артефакта, по возможности используя уже существующие ориентированные на конкретный язык встроенные инструментальные средства.

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

Развертывание: чтобы начать обслуживать новый трафик, новые артефакты должны внедряться в эксплуатационную (или тестовую) среду. Часто для этого артефакты устанавливаются на сервера, где запускаются соответствующие исполняемые файлы. В своей карьере я работала с инструментами развертывания, которые охватывали весь спектр: начиная от простых развертываний на основе git (Heroku), до лабиринтообразных скриптов оболочки, до безагентных инструментов удаленного выполнения на основе ssh, как Fabric/Capistrano/Ansible, до систем, запускающих агентов на узлах, которые следят за новыми развертываниями, до (после 2015) сервисов кластерных оркестраторов, как Nomad или Kubernetes. Новому инструменту нецелесообразно заново изобретать платформу/runtime/механизмы развертывания, уже имеющиеся у поставщика облачных услуг, поскольку поставщики облачных услуг уже предоставляют собственные безапелляционные API специальные инструменты и рабочие процессы для развертывания кода.

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

Hashicorp (я никак с ней не связана) с самого начала была компанией с особым сверхъестественным умением выпускать инфраструктурные проекты, соответствующие (за редким исключением) рынку. Это позволило компании процветать, не ввязываясь в схемы с повторным лицензированием, чем массово занимались другие компании, выпускающие инфраструктуры с открытым исходным кодом, а особенно с open-core.

Специалисты, идущие в ногу со временем и использующие продукты Hashicorp так же долго, как и я, возможно, заметят, что Waypoint не первый заход Hashicorp в сферу развертывания или рабочих процессов. Одной из предыдущих попыток был проект Otto, который должен был стать абстракцией высокого уровня для разработки и развертывания приложений. Atlas также был экспериментом для предоставления интегрированных инструментов и общего рабочего пространства как для разработчиков, так и для операторов; от внедрения кода приложения до создания артефакта развертывания, конфигурирования инфраструктуры и в конечном итоге управления жизненным циклом приложения в процессе его работы.

Теперь, по прошествии времени, становится понятно, почему ни один из инструментов не справился и оба были в итоге свернуты или стали частью других предложений. На мой взгляд, и Otto, и Atlas должны были одни махом решить слишком много разношерстных задач. Хотя такой подход мог сработать в случае Consul, который может использоваться в качестве распределенного хранилища данных типа ключ-значение, сервиса распределенных блокировок, сервисной сетки, системы обнаружения сервисов и многого другого (и я за годы работы действительно использовала Consul для многих из этих разнообразных целей), рабочий процесс разработчика или даже рабочий процесс развертывания, требующий использования полного набора инструментов Hashicorp, был не совсем подходящим продуктом для решения такой серьезной проблемы как рабочий процесс, и особенно не в то время (начиная с 2015 года), когда индустрия видела невообразимый всплеск в количестве специализированных инструментов инфраструктуры, систем, платформ, API, парадигм и экосистем. Когда у пользователей есть выбор из множества вариантов, продуктам, нацеленным на объединение разрозненных проблем, пожалуй, труднее найти соответствие продукта и рынка без интеграции с широким спектром доступных решений.

Здесь напрашивается вопрос, чем же третья попытка одолеть эту проблемную задачу отличается от предыдущих?
Начнем с того, что Waypoint намного более узко сфокусирован, чем были Otto и Atlas за все время своего существования. Waypoint призван унифицировать опыт разработчика, не давая предписаний или обязуя пользователей прибегать к другим продуктам Hashicorp, таким как Vagrant, Terraform или Packer.

Во-вторых, складывается ощущение, что Waypoint перенял кое-что у Terraform. Подобно тому как Terraform успешно абстрагировался от различных облачных провайдеров, облачных API, платформ, систем и инструментов с открытым кодом, предоставил пользователям язык (HCL) для определения, настройки, обновления, поддержки и развития исходных конфигураций инфраструктуры и для интеграции, Waypoint стремится предоставить пользователям ориентированную на HCL декларативную спецификацию и простой CLI-интерфейс для управления и развития рабочего процесса сборки и развертывания. Как и проводники в Terraform, так и плагины в Waypoint позволяют проводить интеграцию с внешними и API системами.

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

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

Заключение

В настоящее время развертывание кода является нетривиальной задачей не в связи с недостатком API или систем, особенно хорошо адресующих частные проблемы. Это связано, скорее, с тем, сколько усилий требуется на соединение всех компонентов вместе во что-то пригодное для работы.

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

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

Для меня Waypoint шаг в нужном направлении. Все еще рано загадывать, но я с радостью буду следить за развитием проекта в следующие 1218 месяцев.

От редакции: приглашаем на курс Слёрма CI/CD на примере Gitlab CI. Сейчас курс находится в разработке и его можно купить по цене предзаказа. Кроме того, вы сможете стать консультантом-тестером: получить ранний доступ к урокам, задать свои вопросы спикерам и повлиять на итоговую программу курса.

В этой статье мы с помощью bash, ssh, docker и nginx организуем бесшовную выкладку веб-приложения. Blue-green deployment это техника, позволяющая мгновенно обновлять приложение, не отклоняя ни одного запроса. Она является одной из стратегий zero downtime deployment и лучше всего подходит для приложений с одним инстансом, но возможностью загрузить рядом второй, готовый к работе инстанс.

Допустим, у Вас есть веб-приложение, с которым активно работает множество клиентов, и ему совершенно никак нельзя на пару секунд прилечь. А Вам очень нужно выкатить обновление библиотеки, фикс бага или новую крутую фичу. В обычной ситуации, потребуется остановить приложение, заменить его и снова запустить. В случае докера, можно сначала заменить, потом перезапустить, но всё равно будет период, в котором запросы к приложению не обработаются, ведь обычно приложению требуется некоторое время на первоначальную загрузку. А если оно запустится, но окажется неработоспособным? Вот такая задача, давайте её решать минимальными средствами и максимально элегантно.

DISCLAIMER: Большая часть статьи представлена в экспериментальном формате в виде записи консольной сессии. Надеюсь, это будет не очень сложно воспринимать, и этот код сам себя документирует в достаточном объёме. Для атмосферности, представьте, что это не просто кодсниппеты, а бумага из "железного" телетайпа.

Интересные техники, которые сложно нагуглить просто читая код описаны в начале каждого раздела. Если будет непонятно что-то ещё гуглите и проверяйте в explainshell (благо, он снова работает, в связи с разблокировкой телеграма). Что не гуглится спрашивайте в комментах. С удовольствием дополню соответствующий раздел "Интересные техники".

Приступим.

$ mkdir blue-green-deployment && cd $_

Сервис

Сделаем подопытный сервис и поместим его в контейнер.

Интересные техники

• cat << EOF > file-name (Here Document + I/O Redirection) способ создать многострочный файл одной командой.
• wget -qO- URL (explainshell) вывести полученный по HTTP документ в /dev/stdout (аналог curl URL).

Распечатка

Я специально разрываю сниппет, чтобы включить подсветку для Python. В конце будет ещё один такой кусок. Считайте, что в этих местах бумага порвалась и была склеена.

$ cat << EOF > uptimer.py

from http.server import BaseHTTPRequestHandler, HTTPServerfrom time import monotonicapp_version = 1app_name = f'Uptimer v{app_version}.0'loading_seconds = 15 - app_version * 5class Handler(BaseHTTPRequestHandler):    def do_GET(self):        if self.path == '/':            try:                t = monotonic() - server_start                if t < loading_seconds:                    self.send_error(503)                else:                    self.send_response(200)                    self.send_header('Content-Type', 'text/html')                    self.end_headers()                    response = f'<h2>{app_name} is running for {t:3.1f} seconds.</h2>\n'                    self.wfile.write(response.encode('utf-8'))            except Exception:                self.send_error(500)        else:            self.send_error(404)httpd = HTTPServer(('', 8080), Handler)server_start = monotonic()print(f'{app_name} (loads in {loading_seconds} sec.) started.')httpd.serve_forever()

EOF$ cat << EOF > DockerfileFROM python:alpineEXPOSE 8080COPY uptimer.py app.pyCMD [ "python", "-u", "./app.py" ]EOF$ docker build --tag uptimer .Sending build context to Docker daemon  39.42kBStep 1/4 : FROM python:alpine ---> 8ecf5a48c789Step 2/4 : EXPOSE 8080 ---> Using cache ---> cf92d174c9d3Step 3/4 : COPY uptimer.py app.py ---> a7fbb33d6b7eStep 4/4 : CMD [ "python", "-u", "./app.py" ] ---> Running in 1906b4bd9fdfRemoving intermediate container 1906b4bd9fdf ---> c1655b996fe8Successfully built c1655b996fe8Successfully tagged uptimer:latest$ docker run --rm --detach --name uptimer --publish 8080:8080 uptimer8f88c944b8bf78974a5727070a94c76aa0b9bb2b3ecf6324b784e782614b2fbf$ docker psCONTAINER ID        IMAGE               COMMAND                CREATED             STATUS              PORTS                    NAMES8f88c944b8bf        uptimer             "python -u ./app.py"   3 seconds ago       Up 5 seconds        0.0.0.0:8080->8080/tcp   uptimer$ docker logs uptimerUptimer v1.0 (loads in 10 sec.) started.$ wget -qSO- http://localhost:8080  HTTP/1.0 503 Service Unavailable  Server: BaseHTTP/0.6 Python/3.8.3  Date: Sat, 22 Aug 2020 19:52:40 GMT  Connection: close  Content-Type: text/html;charset=utf-8  Content-Length: 484$ wget -qSO- http://localhost:8080  HTTP/1.0 200 OK  Server: BaseHTTP/0.6 Python/3.8.3  Date: Sat, 22 Aug 2020 19:52:45 GMT  Content-Type: text/html<h2>Uptimer v1.0 is running for 15.4 seconds.</h2>$ docker rm --force uptimeruptimer

Реверс-прокси

Чтобы наше приложение имело возможность незаметно поменяться, необходимо, чтобы перед ним была ещё какая-то сущность, которая скроет его подмену. Это может быть веб-сервер nginx в режиме реверс-прокси. Реверс-прокси устанавливается между клиентом и приложением. Он принимает запросы от клиентов и перенаправляет их в приложение а ответы приложения направляет клиентам.

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

Если реверс-прокси будет жить на другом хосте, придётся отказаться от docker network и связать приложение с реверс-прокси через сеть хоста, пробросив порт приложения параметром --publish, как при первом запуске и как у реверс-прокси.

Реверс-прокси будем запускать на порту 80, ибо это именно та сущность, которой следует слушать внешку. Если 80-й порт у Вас на тестовом хосте занят, поменяйте параметр --publish 80:80 на --publish ANY_FREE_PORT:80.

Интересные техники

• "В docker-сетях, созданных пользователем, с контейнерами можно связываться не только по IP адресу. Имя контейнера также резолвится в его айпишник" (статья "Networking with standalone containers", часть "Use user-defined bridge networks", пункт 5 докер-кодекса).

Распечатка

$ docker network create web-gateway5dba128fb3b255b02ac012ded1906b7b4970b728fb7db3dbbeccc9a77a5dd7bd$ docker run --detach --rm --name uptimer --network web-gateway uptimera1105f1b583dead9415e99864718cc807cc1db1c763870f40ea38bc026e2d67f$ docker run --rm --network web-gateway alpine wget -qO- http://uptimer:8080<h2>Uptimer v1.0 is running for 11.5 seconds.</h2>$ docker run --detach --publish 80:80 --network web-gateway --name reverse-proxy nginx:alpine80695a822c19051260c66bf60605dcb4ea66802c754037704968bc42527bf120$ docker psCONTAINER ID        IMAGE               COMMAND                  CREATED              STATUS              PORTS                NAMES80695a822c19        nginx:alpine        "/docker-entrypoint."   27 seconds ago       Up 25 seconds       0.0.0.0:80->80/tcp   reverse-proxya1105f1b583d        uptimer             "python -u ./app.py"     About a minute ago   Up About a minute   8080/tcp             uptimer$ cat << EOF > uptimer.confserver {    listen 80;    location / {        proxy_pass http://uptimer:8080;    }}EOF$ docker cp ./uptimer.conf reverse-proxy:/etc/nginx/conf.d/default.conf$ docker exec reverse-proxy nginx -s reload2020/06/23 20:51:03 [notice] 31#31: signal process started$ wget -qSO- http://localhost  HTTP/1.1 200 OK  Server: nginx/1.19.0  Date: Sat, 22 Aug 2020 19:56:24 GMT  Content-Type: text/html  Transfer-Encoding: chunked  Connection: keep-alive<h2>Uptimer v1.0 is running for 104.1 seconds.</h2>

Бесшовный деплоймент

Выкатим новую версию приложения (с двухкратным бустом startup performance) и попробуем бесшовно её задеплоить.

Интересные техники

• echo 'my text' | docker exec -i my-container sh -c 'cat > /my-file.txt' Записать текст my text в файл /my-file.txt внутри контейнера my-container.
• cat > /my-file.txt Записать в файл содержимое стандартного входа /dev/stdin.

Распечатка

$ sed -i "s/app_version = 1/app_version = 2/" uptimer.py$ docker build --tag uptimer .Sending build context to Docker daemon  39.94kBStep 1/4 : FROM python:alpine ---> 8ecf5a48c789Step 2/4 : EXPOSE 8080 ---> Using cache ---> cf92d174c9d3Step 3/4 : COPY uptimer.py app.py ---> 3eca6a51cb2dStep 4/4 : CMD [ "python", "-u", "./app.py" ] ---> Running in 8f13c6d3d9e7Removing intermediate container 8f13c6d3d9e7 ---> 1d56897841ecSuccessfully built 1d56897841ecSuccessfully tagged uptimer:latest$ docker run --detach --rm --name uptimer_BLUE --network web-gateway uptimer96932d4ca97a25b1b42d1b5f0ede993b43f95fac3c064262c5c527e16c119e02$ docker logs uptimer_BLUEUptimer v2.0 (loads in 5 sec.) started.$ docker run --rm --network web-gateway alpine wget -qO- http://uptimer_BLUE:8080<h2>Uptimer v2.0 is running for 23.9 seconds.</h2>$ sed s/uptimer/uptimer_BLUE/ uptimer.conf | docker exec --interactive reverse-proxy sh -c 'cat > /etc/nginx/conf.d/default.conf'$ docker exec reverse-proxy cat /etc/nginx/conf.d/default.confserver {    listen 80;    location / {        proxy_pass http://uptimer_BLUE:8080;    }}$ docker exec reverse-proxy nginx -s reload2020/06/25 21:22:23 [notice] 68#68: signal process started$ wget -qO- http://localhost<h2>Uptimer v2.0 is running for 63.4 seconds.</h2>$ docker rm -f uptimeruptimer$ wget -qO- http://localhost<h2>Uptimer v2.0 is running for 84.8 seconds.</h2>$ docker psCONTAINER ID        IMAGE               COMMAND                  CREATED              STATUS              PORTS                NAMES96932d4ca97a        uptimer             "python -u ./app.py"     About a minute ago   Up About a minute   8080/tcp             uptimer_BLUE80695a822c19        nginx:alpine        "/docker-entrypoint."   8 minutes ago        Up 8 minutes        0.0.0.0:80->80/tcp   reverse-proxy

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

Перекачка образов

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

$ ssh production-server docker image lsREPOSITORY          TAG                 IMAGE ID            CREATED             SIZE$ docker image save uptimer | ssh production-server 'docker image load'Loaded image: uptimer:latest$ ssh production-server docker image lsREPOSITORY          TAG                 IMAGE ID            CREATED             SIZEuptimer             latest              1d56897841ec        5 minutes ago       78.9MB

Команда docker save сохраняет данные образа в .tar архив, то есть он весит примерно в 1.5 раза больше, чем мог бы весить в сжатом виде. Так пожмём же его во имя экономии времени и трафика:

$ docker image save uptimer | gzip | ssh production-server 'zcat | docker image load'Loaded image: uptimer:latest

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

$ docker image save uptimer | gzip | pv | ssh production-server 'zcat | docker image load'25,7MiB 0:01:01 [ 425KiB/s] [                   <=>    ]Loaded image: uptimer:latest

Совет: Если Вам для соединения с сервером по SSH требуется куча параметров, возможно вы не используете файл ~/.ssh/config.

Передача образа через docker image save/load это наиболее минималистичный метод, но не единственный. Есть и другие:

1. Container Registry (стандарт отрасли).
2. Подключиться к docker daemon сервера с другого хоста:
   
   1. Переменная среды DOCKER_HOST.
   2. Параметр командной строки -H или --host инструмента docker-compose.
   3. docker context

Второй способ (с тремя вариантами его реализации) хорошо описан в статье How to deploy on remote Docker hosts with docker-compose.

deploy.sh

Теперь соберём всё, что мы делали вручную в один скрипт. Начнём с top-level функции, а потом посмотрим на остальные, используемые в ней.

Интересные техники

• ${parameter?err_msg} одно из заклинаний bash-магии (aka parameter substitution). Если parameter не задан, вывести err_msg и выйти с кодом 1.
• docker --log-driver journald по-умолчанию, драйвером логирования докера является текстовый файл без какой-либо ротации. С таким подходом логи быстро забивают весь диск, поэтому для production-окружения необходимо менять драйвер на более умный.

Скрипт деплоймента

deploy() {    local usage_msg="Usage: ${FUNCNAME[0]} image_name"    local image_name=${1?$usage_msg}    ensure-reverse-proxy || return 2    if get-active-slot $image_name    then        local OLD=${image_name}_BLUE        local new_slot=GREEN    else        local OLD=${image_name}_GREEN        local new_slot=BLUE    fi    local NEW=${image_name}_${new_slot}    echo "Deploying '$NEW' in place of '$OLD'..."    docker run \        --detach \        --restart always \        --log-driver journald \        --name $NEW \        --network web-gateway \        $image_name || return 3    echo "Container started. Checking health..."    for i in {1..20}    do        sleep 1        if get-service-status $image_name $new_slot        then            echo "New '$NEW' service seems OK. Switching heads..."            sleep 2  # Ensure service is ready            set-active-slot $image_name $new_slot || return 4            echo "'$NEW' service is live!"            sleep 2  # Ensure all requests were processed            echo "Killing '$OLD'..."            docker rm -f $OLD            docker image prune -f            echo "Deployment successful!"            return 0        fi        echo "New '$NEW' service is not ready yet. Waiting ($i)..."    done    echo "New '$NEW' service did not raise, killing it. Failed to deploy T_T"    docker rm -f $NEW    return 5}

Использованные функции:

• ensure-reverse-proxy Убеждается, что реверс-прокси работает (полезно для первого деплоя)
• get-active-slot service_name Определяет какой сейчас слот активен для заданного сервиса (BLUE или GREEN)
• get-service-status service_name deployment_slot Определяет готов ли сервис к обработке входящих запросов
• set-active-slot service_name deployment_slot Меняет конфиг nginx в контейнере реверс-прокси

По порядку:

ensure-reverse-proxy() {    is-container-up reverse-proxy && return 0    echo "Deploying reverse-proxy..."    docker network create web-gateway    docker run \        --detach \        --restart always \        --log-driver journald \        --name reverse-proxy \        --network web-gateway \        --publish 80:80 \        nginx:alpine || return 1    docker exec --interactive reverse-proxy sh -c "> /etc/nginx/conf.d/default.conf"    docker exec reverse-proxy nginx -s reload}is-container-up() {    local container=${1?"Usage: ${FUNCNAME[0]} container_name"}    [ -n "$(docker ps -f name=${container} -q)" ]    return $?}get-active-slot() {    local service=${1?"Usage: ${FUNCNAME[0]} service_name"}    if is-container-up ${service}_BLUE && is-container-up ${service}_GREEN; then        echo "Collision detected! Stopping ${service}_GREEN..."        docker rm -f ${service}_GREEN        return 0  # BLUE    fi    if is-container-up ${service}_BLUE && ! is-container-up ${service}_GREEN; then        return 0  # BLUE    fi    if ! is-container-up ${service}_BLUE; then        return 1  # GREEN    fi}get-service-status() {    local usage_msg="Usage: ${FUNCNAME[0]} service_name deployment_slot"    local service=${1?usage_msg}    local slot=${2?$usage_msg}    case $service in        # Add specific healthcheck paths for your services here        *) local health_check_port_path=":8080/" ;;    esac    local health_check_address="http://personeltest.ru/away/${service}_${slot}${health_check_port_path}"    echo "Requesting '$health_check_address' within the 'web-gateway' docker network:"    docker run --rm --network web-gateway alpine \        wget --timeout=1 --quiet --server-response $health_check_address    return $?}set-active-slot() {    local usage_msg="Usage: ${FUNCNAME[0]} service_name deployment_slot"    local service=${1?$usage_msg}    local slot=${2?$usage_msg}    [ "$slot" == BLUE ] || [ "$slot" == GREEN ] || return 1    get-nginx-config $service $slot | docker exec --interactive reverse-proxy sh -c "cat > /etc/nginx/conf.d/$service.conf"    docker exec reverse-proxy nginx -t || return 2    docker exec reverse-proxy nginx -s reload}

Функция get-active-slot требует небольших пояснений:

Почему она возвращает число, а не выводит строку?

Всё равно в вызывающей функции мы проверяем результат её работы, а проверять exit code средствами bash намного проще, чем строку. К тому же, получить из неё строку очень просто:
get-active-slot service && echo BLUE || echo GREEN.

А трёх условий точно хватает, чтобы различить все состояния?

Даже двух хватит, последнее тут просто для полноты, чтобы не писать else.

Осталась неопределённой только функция, возвращающая конфиги nginx: get-nginx-config service_name deployment_slot. По аналогии с хелсчеком, тут можно задать любой конфиг для любого сервиса. Из интересного только cat <<- EOF, что позволяет убрать все табы в начале. Правда, цена благовидного форматирования смешанные табы с пробелами, что сегодня считается очень дурным тоном. Но bash форсит табы, а в конфиге nginx тоже было бы неплохо иметь нормальное форматирование. Короче, тут смешение табов с пробелами кажется действительно лучшим решением из худших. Однако, в сниппете ниже Вы этого не увидите, так как хабр "делает хорошо", меняя все табы на 4 пробела и делая невалидным EOF. А вот тут заметно.

Чтоб два раза не вставать, сразу расскажу про cat << 'EOF', который ещё встретится далее. Если писать просто cat << EOF, то внутри heredoc производится интерполяция строки (раскрываются переменные ($foo), вызовы команд ($(bar)) и т.д.), а если заключить признак конца документа в одинарные ковычки, то интерполяция отключается и символ $ выводится как есть. То что надо для вставки скрипта внутрь другого скрипта.

get-nginx-config() {    local usage_msg="Usage: ${FUNCNAME[0]} service_name deployment_slot"    local service=${1?$usage_msg}    local slot=${2?$usage_msg}    [ "$slot" == BLUE ] || [ "$slot" == GREEN ] || return 1    local container_name=${service}_${slot}    case $service in        # Add specific nginx configs for your services here        *) nginx-config-simple-service $container_name:8080 ;;    esac}nginx-config-simple-service() {    local usage_msg="Usage: ${FUNCNAME[0]} proxy_pass"    local proxy_pass=${1?$usage_msg}cat << EOFserver {    listen 80;    location / {        proxy_pass http://$proxy_pass;    }}EOF}

Это и есть весь скрипт. И вот гист с этим скриптом для скачки через wget или curl.

Выполнение параметризированных скриптов на удалённом сервере

Пришло время стучаться на целевой сервер. В этот раз localhost вполне подойдёт:

$ ssh-copy-id localhost/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keyshimura@localhost's password: Number of key(s) added: 1Now try logging into the machine, with:   "ssh 'localhost'"and check to make sure that only the key(s) you wanted were added.

Мы написали скрипт деплоймента, который перекачивает предварительно собранный образ на целевой сервер и бесшовно подменяет контейнер сервиса, но как его выполнить на удалённой машине? У скрипта есть аргументы, так как он универсален и может деплоить сразу несколько сервисов под один реверс-прокси (конфигами nginx можно разрулить по какому url какой будет сервис). Скрипт нельзя хранить на сервере, так как в этом случае мы не сможем его автоматически обновлять (с целью багфиксов и добавления новых сервисоы), да и вообще, стэйт = зло.

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

Минусы:

• Два действия вместо одного
• Места куда вы копируете может не быть, или не быть к нему доступа, или скрипт может выполняться в момент подмены.
• Желательно убрать за собой (удалить скрипт).
• Уже три действия.

Решение 2:

• В скрипте держать только определения функций и вообще ничего запускать
• С помощью sed дописывать в конец вызов функции
• Отправлять всё это прямо в shh через pipe (|)

Плюсы:

• Truely stateless
• No boilerplate entities
• Feeling cool

Вот давайте только без Ansible. Да, всё уже придумано. Да, велосипед. Смотрите, какой простой, элегантный и минималистичный велосипед:

$ cat << 'EOF' > deploy.sh

#!/bin/bashusage_msg="Usage: ${FUNCNAME[0]} ssh_address image_name"ssh_address=${1?$usage_msg}image_name=${2?$usage_msg}echo "Connecting to '$ssh_address' via ssh to seamlessly deploy '$image_name'..."( sed "\$a deploy $image_name" | ssh -T $ssh_address ) << 'END_OF_SCRIPT'deploy() {    echo "Yay! The '${FUNCNAME[0]}' function is executing on '$(hostname)' with argument '$1'"}END_OF_SCRIPT

EOF$ chmod +x deploy.sh$ ./deploy.sh localhost magic-porridge-potConnecting to localhost...Yay! The 'deploy' function is executing on 'hut' with argument 'magic-porridge-pot'

Однако, мы не можем быть уверены, что на удалённом хосте есть адекватный bash, так что добавим в начало небольшую проверочку (это вместо shellbang):

if [ "$SHELL" != "/bin/bash" ]then    echo "The '$SHELL' shell is not supported by 'deploy.sh'. Set a '/bin/bash' shell for '$USER@$HOSTNAME'."    exit 1fi

А теперь всё по-настоящему:

$ docker exec reverse-proxy rm /etc/nginx/conf.d/default.conf$ wget -qO deploy.sh https://git.io/JUJq1$ chmod +x deploy.sh$ ./deploy.sh localhost uptimerSending gzipped image 'uptimer' to 'localhost' via ssh...Loaded image: uptimer:latestConnecting to 'localhost' via ssh to seamlessly deploy 'uptimer'...Deploying 'uptimer_GREEN' in place of 'uptimer_BLUE'...06f5bc70e9c4f930e7b1f826ae2ca2f536023cc01e82c2b97b2c84d68048b18aContainer started. Checking health...Requesting 'http://uptimer_GREEN:8080/' within the 'web-gateway' docker network:  HTTP/1.0 503 Service Unavailablewget: server returned error: HTTP/1.0 503 Service UnavailableNew 'uptimer_GREEN' service is not ready yet. Waiting (1)...Requesting 'http://uptimer_GREEN:8080/' within the 'web-gateway' docker network:  HTTP/1.0 503 Service Unavailablewget: server returned error: HTTP/1.0 503 Service UnavailableNew 'uptimer_GREEN' service is not ready yet. Waiting (2)...Requesting 'http://uptimer_GREEN:8080/' within the 'web-gateway' docker network:  HTTP/1.0 200 OK  Server: BaseHTTP/0.6 Python/3.8.3  Date: Sat, 22 Aug 2020 20:15:50 GMT  Content-Type: text/htmlNew 'uptimer_GREEN' service seems OK. Switching heads...nginx: the configuration file /etc/nginx/nginx.conf syntax is oknginx: configuration file /etc/nginx/nginx.conf test is successful2020/08/22 20:15:54 [notice] 97#97: signal process started'uptimer_GREEN' service is live!Killing 'uptimer_BLUE'...uptimer_BLUETotal reclaimed space: 0BDeployment successful!

Теперь можно открыть http://localhost/ в браузере, запустить деплоймент ещё раз и убедиться, что он проходит бесшовно путём обновления страницы по КД во время выкладки.

Не забываем убираться после работы :3

$ docker rm -f uptimer_GREEN reverse-proxy uptimer_GREENreverse-proxy$ docker network rm web-gateway web-gateway$ cd ..$ rm -r blue-green-deployment

Перевод статьи подготовлен в преддверии старта базового и продвинутого курсов по машинному обучению.

Расширяем возможности для наших студентов. Теперь в OTUS есть целых два курса по Machine Learning: базовый и продвинутый. Оба курса стартуют в августе, в связи с чем мы приглашаем всех желающих на день открытых дверей в онлайн-формате, в рамках которого наш эксперт Дмитрий Сергеев (Senior Data Scientist в Oura) подробно расскажет о курсах, а также ответит на интересующие вопросы.

---

Наша основная задача как специалистов по Data Science это обработка данных, а также разработка и совершенствование моделей машинного обучения. Бытует мнение, что обработка данных самый трудоемкий этап во всем проекте, а точность модели определяет успех информационного продукта. Однако отрасль сейчас находится на переходном этапе от эпохи открытий к эпохе внедрения (Сверхдержавы в области искусственного интеллекта: Китая, Силиконовая Долина, а новый мировой порядок в этой сфере диктует Ли Кайфу). Сейчас картина становится шире, и фокус смещается с построения модели на предоставление модели пользователям в качестве сервиса и с производительности модели к ее бизнес-ценности. Самый известный пример здесь Netflix, который никогда не использовал модели победителей их соревнования на 1$ млн, несмотря на обещанное значительное повышение производительности, обеспечиваемое этими движками (Netflix Never Used Its $1 Million Algorithm Due To Engineering Costs WIRED).


От понимания к реальности (слайды с конференции Strata Data Kubeflow explained: Portable machine learning on Kubernetes)

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

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

С сайта Docker

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

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

Вопрос первый Почему Docker?

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

Когда я только начинал свою работу в банке, мне поручили проект, который был связан с обработкой данных, и первый MVP (минимальный жизнеспособный продукт) нужно было доставить за месяц. Звучит напряжно, но мы в команде используем методологию Agile в процессе разработки всех основных продуктов, и основной целью этого MVP было проверить гипотезу о практичности и эффективности продукта (более подробную информацию про методологию Agile вы найдете в книге Эрика Риса Lean Startup). Мой менеджер хотел, чтобы я развернул свою модель на его ноутбуке, то есть запустил ее и использовал для прогнозирования.

Если вы представили себе все шаги, которые мне нужно было сделать, чтобы подготовить ноутбук менеджера к запуску моего проекта, то у вас могло возникнуть много вопросов, таких как:

• На какой операционной системе нужно будет запускать модель, ведь он пользуется Macbook и ThinkPad? Я мог бы, конечно, спросить его об этом, но предположим, что в тот момент жизни мой босс был очень противным, и не хотел, чтобы я знал эту информацию. (Эта мысль здесь для того, чтобы вы осознали проблему зависимости от операционной системы, а так мой босс правда хороший человек.)
• Второй вопрос: Установлен ли у него Python?. Если да, то какая версия, 2 или 3? Какая именно: 2.6, 2.7 или 3.7?
• А как насчет необходимых пакетов, таких как scikit-learn, pandas и numpy? Установлены ли у него те же версии, что и у меня на машине?

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

1. Установить Python.
2. Установить все пакеты.
3. Настроить переменные среды.
4. Перенести код на машину.
5. Запустить код с необходимыми параметрами.

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

Итак, если у вас уже установлен и запущен Docker, вы можете открыть терминал и выполнить следующую команду:

docker run --rm -p 5000:5000 datascienceexplorer/classifier

Через пару минут вы должны увидеть нечто похожее в своем терминале:

* Serving Flask app "main" (lazy loading)* Environment: production   WARNING: Do not use the development server in a production environment.   Use a production WSGI server instead.* Debug mode: off* Running on http://0.0.0.0:5000/ (Press CTRL+C to quit)

Теперь откройте свой любимый браузер и перейдите по этому адресу:

http://localhost:5000/apidocs/

Нажмите на строчку predict из API, а затем на кнопку try-out справа, интерфейс будет выглядеть следующим образом:


Страница Swagger для API на бэкенде

Помните стандартный набор данных Цветы Ириса, с которым вы игрались? Это небольшое приложение поможет вам спрогнозировать вид цветка на основе информации о некоторых измерениях на основе классификационной модели. На самом деле вы уже используете мою модель машинного обучения как сервис, и все, что вы установили это лишь Docker, и мне не понадобилось ставить Python или какие-то пакеты на вашу машину.

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

DevOps Data Science

Теперь, надеюсь, я вас достаточно замотивировал, чтобы продолжать чтение, и если вы просто захотите пропустить эти части и перейти сразу к коду, то все в порядке, поскольку это значит, что вы хотите контейнеризировать свою модель машинного обучения с Docker и предоставлять ее как сервис. Однако сейчас нам придется немного остановиться и отложить все материалы про машинное обучение и Docker в сторону, чтобы подумать о DevOps в Data Science и о том, зачем он там вообще нужен.

Что же такое DevOps?

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

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

Но с Jupyter notebook я счастлив!!!

У специалистов по Data Science история аналогичная, поскольку опять же вы не можете просто взять и отдать свой ноутбук с запущенным Jupyter Notebook, чтобы клиент просто пользовался им. Нам нужен способ использовать модель так, чтобы она могла обслуживать большое количество пользователей в любое время в любом месте и подниматься с минимальным временем простоя (удобство использования, надежность, масштабируемость).

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

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

Хранение обученной модели

Еще в университете мы узнали, что проект Data Science состоит из шести этапов, как показано на картинке ниже. Если автоматизация и развертывание модели на продакшене является нашей конечной целью, то как же отправить модель на стадию развертывания?


Шесть этапов Data Science-проекта

Самый простой способ, который только можно придумать это скопировать все из нашего notebook, вставить в файл с расширение .py и запустить его. Однако каждый раз, когда нам нужно будет сделать прогноз, мы будем запускать этот файл и заново на тех же данных обучать модель. Если такой подход хоть как-то применим для простых моделей с небольшим обучающим набором данных, он не будет эффективен для сложных моделей с большим количеством обучающих данных (подумайте о том, сколько времени вам понадобится для обучения модели ANN или CNN). Здесь имеется в виду, что, когда пользователь отправляет запрос модели на прогнозирование, ему придется ждать от нескольких минут до нескольких часов, чтобы получить результат, поскольку много времени уйдет на выполнения этапа обучения модели.

Как хранить модель сразу после того, как она обучится?

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

В Jupyter notebook вы можете с легкостью сохранить объект модели (в моем случае knn) в файл pkl, который располагается в том же каталоге, что и код:

import picklewith open('./model.pkl', 'wb') as model_pkl:  pickle.dump(knn, model_pkl)

Сохранение модели в текущую директорию

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

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

---

Узнать подробнее о:

• Machine Learning. Продвинутый курс
• Machine Learning. Базовый курс

---

Читать ещё

• Как сделать тематическое моделирование форума быстро или что беспокоит людей с целиакией
• Энтропия: как Деревья Решений принимают решения
• Создать мощный курс Machine Learning: миссия выполнена

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

В первой части этого руководства мы успешно сохранили вашу классификационную модель в локальном каталоге и завершили все работы по разработке модели, связанные с Jupyter Notebook. С этого момента основное внимание будет уделяться развертыванию нашей модели. Чтобы повторно использовать модель для прогнозирования, вы можете просто загрузить ее и вызвать метод predict(), как вы обычно это делаете в Jupyter Notebook.

Для того чтобы протестировать модель, в той же папке, где находится файл model.pkl, создайте файл main.py с этим кодом:

import pickle# Импортируем все пакеты, которые необходимы для вашей моделиimport numpy as npfrom sklearn.neighbors import KNeighborsClassifier# Загружаем модель в памятьwith open('./model.pkl', 'rb') as model_pkl:   knn = pickle.load(model_pkl)# Неизвестные данные (создаем новое наблюдение для тестирования)unseen = np.array([[3.2, 1.1, 1.5, 2.1]])result = knn.predict(unseen)# Выводим результаты на консольprint('Predicted result for observation ' + str(unseen) + ' is: ' + str(result))

Повторное использование модели для прогнозирования.

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

Traceback (most recent call last): File "main.py", line 4, in <module>   from sklearn.neighbors import KNeighborsClassifierImportError: No module named sklearn.neighbors

Это связано с тем, что используемый нами пакет недоступен в среде, в которой вы запускаете файл. Это значит, что среда, используемая для разработки модели (conda), не идентична среде выполнения (среда python за пределами conda), и это можно рассматривать как потенциальную проблему при запуске нашего кода в других средах. Я специально хотел, чтобы вы увидели эту ошибку, чтобы помочь вам узнать о проблеме, и еще раз подчеркнуть важность использования контейнеров для развертывания нашего кода, чтобы избежать подобных проблем. На данный момент вы можете просто вручную установить все необходимые пакеты с помощью команды pip install. Мы вернемся сюда позже, чтобы сделать это автоматически.

После установки всех пакетов и успешного запуска файла модель должна быстро вернуть следующее сообщение:

Predicted result for observation [[3.2 1.1 1.5 2.1]] is: [1]

Как вы можете здесь увидеть, для тестирования модели мы используем захардкоженные неизвестные данные. Эти числа представляют собой длину чашелистика, его ширину, длину лепестка и его ширину соответственно. Однако, поскольку мы хотим предоставлять нашу модель как сервис, она должна быть представлена как функция, принимающая запросы, содержащие эти четыре параметра, и возвращающая результат прогноза. Затем эту функцию можно использовать для сервер API (бекенда) или развернуть в бессерверной среде выполнения, такой как Google Cloud Functions. В этом руководстве мы попытаемся вместе создать сервер API и поместить его в контейнер Docker.

---

Как работает API?

Давайте поговорим о том, как сегодня устроены веб-приложения. В большинстве веб-приложений есть два основных компонента, которые покрывают почти все функции, необходимые приложению: фронтенд и бекенд. Фронтенд ориентирован на обслуживание интерфейса (веб-страницы) для пользователя, а фронтенд сервер часто хранит HTML, CSS, JS и другие статические файлы, такие как изображения и звуки. С другой стороны, бекенд сервер будет обрабатывать всю бизнес-логику, которая отвечает на любые запросы, отправленные из фронтенда.


Иллюстрация структуры веб-приложений.

Вот что произойдет, когда вы откроете Medium в своем браузере.

1. Ваш браузер отправляет HTTP-запрос на адрес medium.com. Потребуется ряд операций на DNS-сервере, маршрутизаторах, межсетевых экранах и т. д., но для простоты этой статьи мы их проигнорируем.
2. Фронтенд сервер отправляет обратно * .html, * .css, * .js и все другие файлы, необходимые для рендеринга веб-страницы в вашем браузере.
3. Теперь в браузере вы должны увидеть страницу Medium и начать с ней взаимодействовать. Допустим, вы только что нажали кнопку clap (похлопать) на статье.
4. Скрипты (javascript) в вашем браузере отправят HTTP-запрос на бекенд сервер с id истории. URL-адрес запроса сообщит бекенду, какое действие следует выполнить. В этом примере он скажет бекенду обновить количество хлопков в истории с id XXXXXXX.
5. Бекенд программа (которая, может быть написана на любом языке) получит текущее количество хлопков в базе данных и увеличит его на единицу.
6. Затем бекенд программа отправляет актуальное количество хлопков обратно в базу данных.
7. Бекенд отправляет новое количество хлопков в браузер, чтобы его можно было отразить в интерфейсе.

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

Теперь я хочу, чтобы вы сосредоточили внимание на синих стрелках на рисунке выше. Это HTTP-запросы (отправленные из браузера) и HTTP-ответы (полученные браузером или отправленные в браузер). Компоненты, обрабатывающие запросы от браузера и возвращающие ответы на бекенд сервере, называются API.

Ниже приведено определение API:

Из Вебопедии

Интерфейс прикладного программирования (API application program interface) это набор процедур, протоколов и инструментов для создания программных приложений. По сути, API определяет, как должны взаимодействовать программные компоненты.

Создаем наш собственный API!

Существует множество фреймворков, которые помогают нам создавать API с помощью Python, включая Flask, Django, Pyramid, Falcon и Tornado. Преимущества и недостатки, а также сравнение этих структур, перечислены здесь. В этом уроке я буду использовать Flask, но техника и рабочий процесс остаются такими же, как и для других, и в качестве альтернативы вы вполне можете использовать на этом этапе свой любимый фреймворк.

Последнюю версию Flask можно установить через pip с помощью этой команды:

pip install Flask

Все, что вам нужно сделать сейчас это превратить код из предыдущего шага в функцию и зарегистрировать для нее эндпоинт API после инициализации приложения Flask. По умолчанию приложение Flask запускается на локалхосте (127.0.0.1) и будет прослушивать запросы на порту 5000.

import pickle# Импортируем все пакеты, которые необходимы для вашей моделиimport numpy as npimport sysfrom sklearn.neighbors import KNeighborsClassifier# Импортируем Flask для создания APIfrom flask import Flask, request# Загружаем обученную модель из текущего каталогаwith open('./model.pkl', 'rb') as model_pkl:   knn = pickle.load(model_pkl)# Инициализируем приложение Flaskapp = Flask(__name__)# Создайте конечную точку API@app.route('/predict')def predict_iris():   # Считываем все необходимые параметры запроса   sl = request.args.get('sl')   sw = request.args.get('sw')   pl = request.args.get('pl')   pw = request.args.get('pw')# Используем метод модели predict для# получения прогноза для неизвестных данных   unseen = np.array([[sl, sw, pl, pw]])   result = knn.predict(unseen)  # возвращаем результат    return 'Predicted result for observation ' + str(unseen) + ' is: ' + str(result)if __name__ == '__main__':   app.run()

Представление вашей модели как API

На терминале вы должны увидеть следующее:

* Serving Flask app "main" (lazy loading)* Environment: production  WARNING: This is a development server. Do not use it in a production deployment.  Use a production WSGI server instead.* Debug mode: off* Running on http://127.0.0.1:5000/ (Press CTRL+C to quit)

Откройте браузер и введите в адресной строке следующий запрос:

http://localhost:5000/predict?sl=3.2&sw=1.1&pl=1.5&pw=2.1

Если в вашем браузере появляется что-то подобное, поздравляем! Теперь вы предоставляете свою модель машинного обучения в качестве службы с эндпоинтом API.

Predicted result for observation [['3.2' '1.1' '1.5' '2.1']] is: [1]

Тестирование API с помощью Postman

Недавно мы использовали наш браузер для быстрого тестирования API, но это не очень эффективный способ. Например, мы могли бы не использовать метод GET, а вместо этого использовать метод POST с токеном аутентификации в заголовке, а сделать так, чтобы браузер отправлял такой запрос, непросто. При разработке программного обеспечения Postman широко используется для тестирования API-интерфейсов и совершенно бесплатен для базового использования.


Пользовательский интерфейс Postman (со страницы загрузки Postman)
После загрузки и установки Postman откройте инструмент и следуйте инструкциям ниже, чтобы отправить запрос.


Отправка GET запроса с помощью Postman

1. Убедитесь, что вы выбрали GET запрос, поскольку мы настраиваем API только для получения GET запроса. Это может не сработать, если вы случайно выберете POST запрос.
2. Вставьте сюда URL вашего запроса.
3. В этой таблице необходимо обновить параметры запроса. Не стесняйтесь поиграть с этими параметрами и посмотреть, что вы получите в результате.
4. Нажмите кнопку Отправить, чтобы отправить запрос на наш сервер API.
5. Здесь будет отображаться ответ нашего сервера.
6. Вы также можете проверить дополнительную информацию об этом HTTP-ответе. Это может быть очень полезно для отладки.

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

Читать первую часть.