Как часть моего открытия Cloudify — я столкнулся с другой темой, которая, по моему мнению, требует небольшого отката назад и более подробного ознакомления с тем, чтобы глубже погрузиться в документацию. Так что в этой серии постов я собираюсь погрузиться в то, что такое рабочий процесс ?! А затем, как их установить, и, в конечном итоге, как их масштабировать
Итак, я собираюсь начать с самого начала, и вы можете начать читать, где бы вы ни были в истории.
Cloudify использует чертежи для описания оркестровки облачных архитектур, где каждый компонент в чертеже является либо узлом, либо отношением .
Cloudify рабочие процессы из коробки — в любом масштабе.
Идти
Так, например, узел, может быть виртуальным хостом, группой безопасности, приложением, вы поняли идею.
Два узла могут быть связаны через отношения, такие как виртуальный хост, который содержится в группе безопасности, или IP-адрес, который связан с интерфейсом.
В то время как это описание делает архитектуру выглядящей статичной, оркестровка подразумевает динамизм — и именно здесь рабочие процессы входят в смесь. Рабочие процессы Cloudify позволяют статическим узлам и отношениям иметь программируемое поведение.
В одном из предыдущих постов в блоге я упомянул о встроенных рабочих процессах Cloudify, которые обеспечивают основу для того, как сделать инфраструктуру гибкой, изменчивой, « управляемой ».
Возьмем, к примеру, процесс начальной загрузки Cloudify Manager .
В этом сценарии у нас много узлов — групп безопасности, пар ключей, виртуальных хостов и т. Д.
Но центральным компонентом, raison d’être (причудливая формулировка для основной предпосылки) — всего этого является Cloudify Manager, который является центром всех наших усилий по оркестровке.
Это приложение менеджера является узлом, и оно содержится в явном виде или через наследование для различных других узлов.
Рабочие процессы выполняют подключение и определяют, когда выполняется каждая операция.
Когда мы загружаем менеджер, рабочий процесс установки гарантирует, что менеджер установлен на нужном сервере и что это происходит в нужное время.
Этот рабочий процесс содержит определенный порядок операций. Вот некоторые из них:
-
Создание операций для каждого из узлов в проекте
-
Предварительно сконфигурируйте операции для каждого из отношений в проекте
-
Настройте операции для каждого из узлов
-
Операции после настройки для каждого из отношений
-
Начать операцию для каждого из узлов
When you are writing a blueprint, you need to decide when you want certain operations to execute. Truthfully, this can be an intellectual exercise if you want it to be. You might consider combining certain tasks. You might have dependency loops. And so on.
Here are some basic rules:
First, make a list of the broad steps that you would need to set up your infrastructure.
For example, when we bootstrap a manager, we need to:
-
Create the manager security groups and key pair,
-
Create the virtual host,
-
Install the manager software on the virtual host,
-
And, finally, attach the IP address.
For now, let’s assume we have the security groups and key pairs.
When we bootstrap the manager, we need to make sure that two things happen in a particular order:
-
The virtual host must be up and running.
-
The manager must be installed on the virtual host.
The contained_in relationship illustrates the correct relationships of this scenario.
Notice the manager definition in the manager bootstrap blueprint, which I’ve abridged (for conciseness):
manager:
relationships:
- type: cloudify.relationships.contained_in
target: manager_host
See: Simple Manager Blueprint in the Cloudify Manager Blueprint repository.
The contained_in relationship will make sure the manager_host node is up and running before anything else happens.
The contained_in relationship, and the start operation illustrate the power of the workflows.
Remember earlier we discussed the order of operations in the install workflow. The create happens on the node before the pre-configure on the relationship.
Если операция начальной загрузки была сопоставлена с операцией создания или конфигурирования, рабочий процесс установки будет выполнять операции, связанные с отношением contains_in, после начальной загрузки менеджера.
Другими словами, отношения не будут готовы, менеджер не будет знать, где установить, и наш рабочий процесс закончится ошибкой. Вот почему операция начальной загрузки отображается на операцию запуска.
Это простая иллюстрация использования рабочих процессов.
Поэтому, прежде чем это станет перегрузкой — я остановлюсь здесь и позволю вам обработать, как работают операции, и порядок зависимостей в этом примере.
В следующем посте я расскажу о более сложном сценарии и продемонстрирую, как установить Docker на несколько узлов, а в последнем посте серии я расскажу о том, как масштабировать как простой, так и более сложный рабочий процесс.