Как основной участник проекта «Переводчик тепла», у меня была возможность немного узнать в течение прошлого года о TOSCA .
Когда мы начинали разработку Cloudify 3.0 (около полутора лет назад), мы знали, что нам нужен улучшенный синтаксис для описания облачных приложений и сервисов по сравнению с тем, что мы использовали в наших версиях 2x. Сначала мы думали изобрести новый язык, основанный на синтаксисе YAML для описания сервисов облачных приложений, но решили, что нам, вероятно, следует искать существующие стандарты — вместо этого изобретать колесо.
И тогда мы нашли TOSCA, которая, как мы думали, имела большой потенциал.
OpenStack Heat изначально был запущен как альтернатива AWS CloudFormation, то есть проекту с закрытым исходным кодом. OpenStack Heat , один из крупнейших проектов по принятию TOSCA в качестве одного из основных языков шаблонов, выбрал TOSCA, поскольку он обеспечил преимущество стандартизации шаблонов для проектов облачной оркестрации, и это, по сути, стало главной движущей силой, которая была принята TOSCA большие проекты.
Cloudify 3.1 с TOSCA из коробки. Дай вихрь ..
иди
TOSCA набирает обороты в результате необходимости создания альтернативного и независимого синтаксиса, который свободно доступен, который позволяет вам стандартизированным образом описывать более сложные сценарии функциональности, в частности, для сложных топологий и приложений.
Единственная выгода для нас с принятием TOSCA изначально заключалась в том, что она была написана на XML, что было слишком громоздким для того, что мы хотели сделать.
Помимо этого, мы обнаружили, что спецификация TOSCA очень тесно связана с тем, чего мы стремимся достичь, и решили приступить к ее преобразованию в YAML, поскольку наша команда согласилась, что это будет язык, который лучше всего поможет нам получить работа сделана Короче говоря, на саммите OpenStack в Гонконге в 2013 году мы встретились с теми, кто принимал активное участие в работе комитета TOSCA, и они рассказали нам о своих намерениях и первоначальной работе по преобразованию TOSCA в YAML. Казалось, что мы разделяли те же идеи и решили встретиться после саммита, и это было, когда мы присоединились к комитету TOSCA.
В то же время мы также начали вносить код для проекта тепловой трансляции OpenStack . Основная цель проекта Heat-Translator — взять шаблон TOSCA и преобразовать его в шаблон OpenStack Heat, который на ранних этапах очень соответствовал синтаксису CloudFormation. Однако, когда TOSCA был преобразован в YAML, он был быстро принят в этот проект. Тепло было в первую очередь ориентировано на инфраструктуру, однако, поскольку проект рос и развивался и начал подниматься по стеку, ему требовался синтаксис, который учитывал бы более сложные сценарии и топологии для облачных приложений.
Интересным фактом является то, что проект Heat согласился включить в него проект по переводу тепла, который де-факто определил TOSCA в качестве основного языка шаблонов. Как только он был интегрирован в официальный проект, это было свидетельством того, что Фонд OpenStack продвигался к стандартизации TOSCA для всего проекта.
Cloudify 3.1 поддерживает большую часть спецификации TOSCA , и мы намерены охватить больше областей спецификации в наших следующих версиях. Одна из самых крутых функций, представленных в Cloudify 3.1, — это возможность запускать шаблон TOSCA локально (на вашем собственном ноутбуке или ПК) без использования какого-либо облака. Это делает его очень простым для людей, которые хотят поиграть со спецификацией, узнать об этом, а также узнать об Cloudify.
Основная суть в том, что обычно приложение nodecellar устанавливает приложение NodeJS с бэкэндом Mongo. Однако этот пример обычно запускается, когда у вас установлен Cloudify Manager, и по большей части в облачной среде.
Эта возможность локально запускать спецификацию TOSCA позволяет вам тестировать свои чертежи и плагины локально для разработчиков среди вас и просто использовать Cloudify почти как инструмент управления конфигурацией. Мы также привыкли использовать эту функцию локальных рабочих процессов для начальной загрузки Cloudify Manager, поскольку она значительно упрощает все.
Вы можете проверить, как это будет выглядеть в действии ниже.
# Установить Cloudify
-
Используйте машину с Ubuntu.
-
Убедитесь, что у вас установлены gcc и python-dev.
-
Бег:
pip install cloudify
# Скачать пример
Загрузите пример NodeCellar от Cloudify:
https://github.com/cloudify-cosmo/cloudify-nodecellar-example/archive/3.1.zip
# Распаковать …
cd cloudify-nodecellar-example
# Initialize
`cfy local init -p local-blueprint.yaml`
Команда cfy local init инициализирует текущий рабочий каталог для работы с заданным планом.
После этого этапа вы можете запустить любой рабочий процесс, содержащийся в проекте.
# Установить NodeCellar
Чтобы установить NodeCellar, давайте выполним `install`рабочий процесс:
`cfy local execute -w install`
Эта команда установит все компоненты приложения на ваш локальный компьютер.
(не волнуйтесь, все это установлено в каталоге `tmp`)
Как только это будет сделано, вы сможете перейти к [http: // localhost: 8080] ( http: // localhost: 8080 ) и увидеть приложение NodeCellar.
Вывод будет выглядеть примерно так:
…
2014-12-18 10:02:41 CFY <local> [nodecellar_31177] Starting node 2014-12-18 10:02:41 CFY <local> [nodecellar_31177.start] Sending task 'script_runner.tasks.run' 2014-12-18 10:02:41 CFY <local> [nodecellar_31177.start] Task started 'script_runner.tasks.run' 2014-12-18 10:02:42 LOG <local> [nodecellar_31177.start] INFO: Executing: /tmp/tmp1hAdu3-start-nodecellar-app.sh 2014-12-18 10:02:43 LOG <local> [nodecellar_31177.start] INFO: MongoDB is located at localhost:27017 2014-12-18 10:02:43 LOG <local> [nodecellar_31177.start] INFO: Starting nodecellar application on port 8080 2014-12-18 10:02:43 LOG <local> [nodecellar_31177.start] INFO: /tmp/d5c3b8d3-bc14-43b1-8408-4a5f7216641b/nodejs/nodejs-binaries/bin/node /tmp/d5c3b8d3-bc14-43b1-8408-4a5f7216641b/nodecellar/nodecellar-source/server.js 2014-12-18 10:02:43 LOG <local> [nodecellar_31177.start] INFO: Running Nodecellar liveness detection on port 8080 2014-12-18 10:02:43 LOG <local> [nodecellar_31177.start] INFO: [GET] http://localhost:8080 000 2014-12-18 10:02:43 LOG <local> [nodecellar_31177.start] INFO: Nodecellar has not started. waiting... 2014-12-18 10:02:45 LOG <local> [nodecellar_31177.start] INFO: [GET] http://localhost:8080 200 2014-12-18 10:02:45 LOG <local> [nodecellar_31177.start] INFO: Sucessfully started Nodecellar (22584) 2014-12-18 10:02:45 LOG <local> [nodecellar_31177.start] INFO: Execution done (return_code=0): /tmp/tmp1hAdu3-start-nodecellar-app.sh 2014-12-18 10:02:45 CFY <local> [nodecellar_31177.start] Task succeeded 'script_runner.tasks.run' 2014-12-18 10:02:45 CFY <local> 'install' workflow execution succeeded ...
### Step 3: Uninstall
To uninstall the application we run the `uninstall` workflow:
`cfy local execute -w uninstall`
As of now 3.1 supports these leading aspects of the TOSCA spec — inputs, outputs, intrinsic functions, the relationships between nodes, versioning, workflows and more. In our next versions we’ll be adding support for requirements and capabilities, nested templates, and policies that include: placement (affinity and anti-affinity), stack governance, etc.
At the end of the day, this TOSCA engine partnered with Cloudify is what gives you free hand to decide with which cloud you want to work, since Cloudify actually makes the pluggability of any cloud possible. This ultimately enables you to run TOSCA templates on any cloud, and the same of course also goes for any configuration management or other tools you’re working with (which Cloudify also integrates with via plugins that are written in the same syntax). Although TOSCA doesn’t refer to CM tools very much, the integration with Cloudify is what makes this possible. If in the past you would need to script your own code, or use more tools that are more limited to the deployment aspects, rather than orchestration and such.