Автоматизация документооборота PT II — Docker Orchestration and Management

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

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

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

Допустим, у нас есть приложение, такое как приложение Nodecellar, которое состоит из приложения NodeJS и серверной части MongoDB. (И не только потому, что это пример из нашей документации, он действительно хорошо демонстрирует это. Действительно.)

Требования здесь:

• Два виртуальных хоста.

• На каждом виртуальном хосте должен быть установлен и запущен Docker-сервер.

• На одном из наших виртуальных хостов должен быть запущен контейнер MongoDB.

• Другой должен иметь контейнер приложения NodeJS / Nodecellar.

• Контейнер Nodecellar / NodeJS должен быть создан после контейнера MongoDB. (В противном случае при запуске приложения NodeJS оно не сможет подключиться к базе данных.)

В этом сценарии есть четыре узла и три отношения.

Узлы:

1. Виртуальный хост 1

2. Виртуальный хост 2

3. Node JS / Nodecellar приложение контейнер

4. Контейнер MongoDB

Отношения:

1. Контейнер MongoDB в виртуальном хосте

2. NodeJS / Nodecellar containeraged_in Virtual Host 1

3. Nodecellar контейнер connected_to MongoDB контейнер

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

The MongoDB container must be created before the NodeJS/Nodecellar container, and it must be started before the NodeJS/Nodecellar container is started.

The complicated part is the installation and starting of the Docker server.

Docker needs to run as root. However, the Cloudify host agent does not run as root, but the host agent needs to install the Cloudify Docker plugin and run the related plugin operations.

This poses a problem, because cloud images with Docker installed by default are uncommon in public clouds. Furthermore, it is necessary to add the user agent on your Cloudify agent VM to the Docker group on your system.

Having Cloudify install Docker for you is problematic for two reasons:

• The Docker installation is a bit time-consuming, especially for a production environment.

• Once the Cloudify Agent is installed on the target host, it’s permissions cannot be reloaded.

(There is currently no way to log the Cloudify host agent out, or reload its permissions through plugin operations.)

Therefore, in general the user needs to make sure to bring an image with Docker pre-installed and the correct group membership already established.

There is another approach that involves using userdata in the Cloudify Nodecellar Docker Example repo.

Let’s consider this excerpt from the Nodecellar container definition in the Docker example blueprint:

nodecellar_container:

  nodecellar_container:
    type: cloudify.docker.Container
   relationships:
      - type: cloudify.relationships.contained_in
        target: host
      - type: cloudify.relationships.depends_on
        target: mongod_container

See the Cloudify Nodecellar Docker Example Simple Blueprint.

Notice that the relationship type that defines the relationship between the nodecellar_container and the mongod_container is depends_on.

This satisfies the requirement that the MongoDB container is running before the NodeJS Container is started.

During the workflow, runtime properties of the nodes will be assigned.

In order to access such properties in a blueprint, you need to use get_attribute. This is an intrinsic function of the Cloudify TOSCA DSL.

Hint: Remember that you can only use this function in an input to an operation, or in a blueprint output.

When a blueprint requires Docker containers running on separate hosts, we require runtime properties of some of the nodes.

Specifically, the IP of the Mongo Host, so that we can tell the Nodecellar container where to look for MongoDB.

  nodecellar_container:
   interfaces:
      cloudify.interfaces.lifecycle:
       start:
          implementation: docker.docker_plugin.tasks.start
          inputs:
            params:
             extra_hosts:
                mongod: { get_attribute: [ mongo_vm, ip ] }

See: Cloudify Nodecellar Docker Example Openstack Blueprint.

Here we are not only dependent on the fact that the container is running, but also that the IP runtime property of its virtual host has been set.

— Is this too abrupt?

When creating blueprints and working with workflows, it’s important to consider the implications of using particular elements in certain places.

You can find the differences between the different node types and relationship types in our documentation, and where and when to use each.

The different operations that are available in the install workflow ensure that you are able to gracefully and flexibly design your orchestration blueprint.

In the final post of this series I will demonstrate how to take these flexible workflows and scale them across large-scale deployments.