Статьи

Состав развертывания в Cloudify

Декабрь 19, 2017

[Эта статья была написана DeWayne Filppi .]

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

В этой модели развертывание базы данных (например) может быть создано независимо от других уровней. Другие уровни могут приходить и уходить независимо от базы данных. Cloudify не имеет встроенной возможности для выражения такой модели, но гибкая архитектура плагинов делает это довольно просто.

Быстрое прохождение

Узел DeploymentProxy позволяет настроить зависимость запуска между развертываниями. Узел DeploymentProxy вставляется в зависимый проект и конфигурируется для обращения к выводам независимого проекта или, точнее, независимого развертывания. Источник для плагина находится на GitHub , и включает в себя пример. В этом примере демонстрируется проект NodeJS, который зависит от проекта MongoDB . Детали зависимости несколько надуманы, но достаточно хороши для демонстрации.

В DeploymentProxy в качестве точки интеграции используется функция « выходные данные ». Таким образом, в этом примере первым шагом является создание значимых выходных данных в проекте MongoDB.

outputs:
  endpoint:
    description: MongoDB endpoint
    value:
      ip_address: { get_property: [ host, ip ] }
      port: { get_property: [mongod, port] }

Как только выходные данные установлены, вся работа перемещается в зависимый проект (NodeJS), который содержит узел DeploymentProxy. Для начала проект NodeJS включает определение плагина и определение узла TOSCA для DeploymentProxy.

imports:  
  - http://www.getcloudify.org/spec/cloudify/3.1/types.yaml
  - http://www.getcloudify.org/spec/diamond-plugin/1.1/plugin.yaml
  - types/nodecellar.yaml
# the yaml file for the proxy is local to the example, but ideally
# is located on a shared drive or web server
  - plugins/proxy/plugin.yaml

Затем добавляется сам узел DeploymentProxy. Узел DeploymentProxy представляет независимый проект (MongoDB) в проекте NodeJS. Его единственная функция должна использоваться во время встроенного рабочего процесса установки для ожидания (при необходимости) и предоставления информации об указанном проекте / развертывании.

  proxy:
    type: cloudify.nodes.DeploymentProxy
    properties:
      deployment_id: md
      wait_for: expr
      test: outputs['endpoint']['value']['port']>0

Этот конкретный узел демонстрирует логическое выражение python, используемое для определения того, когда прокси-сервер успешно вернется во время рабочего процесса установки. Другими словами, установка NodeJS будет ожидать выполнения этого условия или истечения времени ожидания. Выражение снабжается диктом «выходы» целевого развертывания. Другой тип условия «существует», который успешно возвращается, если указанное свойство существует в выходных данных.

Последний шаг — это соединение через приложение NodeCellar с базой данных MongoDB, представленной прокси. Помимо простого ожидания доступности MongoDB, пример также демонстрирует доступ к выходным данным для подключения к базе данных. Узел DeploymentProxy возвращает выходные данные своего целевого проекта в свойствах среды выполнения.

 nodecellar:
    type: nodecellar.nodes.NodecellarApplicationModule
    properties:
      port: 8080
    relationships:

      ################################
      # Setting the mongo connection
      ################################

      - type: node_connected_to_mongo
        target: mongod

В отношении «node_connected_to_mongo», слегка измененном по сравнению с исходной версией в стандартном проекте NodeCellar, метод жизненного цикла postconfigure получает хост и порт MongoDB. В исходной версии он получает значения от узлов MongoDB, которые находятся в текущем проекте. В этой версии, поскольку MongoDB имеет совершенно отдельный проект, он получает хост и порт от прокси-узла. Это показано в проекте NodeJS в реализации отношений по адресу /scripts/mongo/set-mongo-url.sh.

ctx source instance runtime_properties mongo_ip_address $(ctx target instance runtime_properties outputs.endpoint.value.ip_address)
ctx source instance runtime_properties mongo_port $(ctx target instance runtime_properties outputs.endpoint.value.port)

Немного глубже

Плагин имеет только одну функцию реализации «wait», которая ожидает условий на выходах целевого развертывания. Когда вызывается метод «start», «wait» получает следующие параметры:

  • deploy_id : развертывание, от которого зависит.
  • wait_for : либо «существует», либо «expr».

    • Если «существует», будет ожидать вывода, соответствующего значению свойства «тест».
    • Если «expr», он интерпретирует свойство «test» как булево выражение Python, в котором коллекция «output» представляет собой dict output (например, expr: output [port]> 0
  • test : либо имя вывода, либо логическое выражение (см. wait_for)
  • timeout : количество секунд ожидания. Когда время ожидания истекает, выдается «RecoverableError». По умолчанию = 30.

Функция «wait» вызывает API-интерфейс Cloudify REST для получения выходных данных с настроенного идентификатора развертывания. Он либо проверяет, существует ли конкретное выходное свойство, либо оценивает предоставленное логическое выражение python для проверки более сложных условий. Если выражение сконфигурировано, то «dict» «output», содержащий целевой «output» развертывания, находится в области действия при оценке выражения. Функция пытается выполнить условие в течение «тайм-аута» секунд, после чего возникает «RecoverableError». Это приводит к тому, что рабочий процесс установки Cloudify входит в свой цикл повторных попыток. Это продолжается до тех пор, пока рабочий процесс установки окончательно не сработает или выражение не оценивается как true. Когда DeploymentProxy завершает работу, он копирует выходные данные целевого развертывания в свои собственные свойства времени выполнения.Это позволяет другим узлам в содержащем чертеже легкий доступ к выходам, где, например, IP-адрес сервера и порт
может быть расположен.

Заключение и будущие направления

Узел cloudify.nodes.DeploymentProxy предоставляет базовый механизм зависимости между развертываниями. Он маскируется как локальный узел развертывания при доступе к другому развертыванию, ожидая состояния готовности, описанного его выходными данными. Это только верхушка айсберга для этой концепции, так как связь ограничена выходами и является однонаправленной. В принципе, нет никаких оснований для того, чтобы этот плагин нельзя было расширять, чтобы фактически запускать установку целевого развертывания, получать доступ и открывать свойства времени выполнения, а также постоянно обновлять выходные данные и другие свойства. Источник доступен на github , а также пример использования из пошагового руководства в этом посте.

38
Share: