Punch Operator¶

Previously we checked COTS from the vagrant user. We saw that the processes where launched in background by the punchdaemon user.

There is another user deployed which is described in the punchplatform_operator section of the punchplatform-deployment.settings.

{
  "punchplatform_operator": {
    "punchplatform_operator_environment_version": "punch-operator-6.4.5",
    "configuration_name_dir_from_home": "conf",
    "reporters": [
      "kafka-reporter"
    ],
    "operators_username": [
      "punchoperator"
    ],
    "storage": {
      "type": "kafka",
      "kafka_cluster": "common"
    },
    "servers": {
      "server1": {}
    }
  }
}

The punchoperator user will start punchlines and other Punch applications.

You can log in as the punchoperator using:

# on server1
sudo su - punchoperator

Operator configuration¶

The Punch Operator requires punchlines, configuration files, channels structures and parsers... to start Punch applications. Those files are already present in the conf directory in the Standalone. Here, it is described with configuration_name_dir_from_home parameter.

On a deployed version we need to prepare this folder :

Choose punchlines, configuration files, channels structures...

# vagrant@deployer
sudo yum install tree -y
tree punch-deployer-6.4.5/examples/platforms/getting_started_deployer/runtime/tenants

Install parsers.

# vagrant@deployer
bash punch-deployer-6.4.5/examples/platforms/getting_started_deployer/install-parsers.sh

Send configuration to operators.

# vagrant@deployer
export PUNCHPLATFORM_OPERATOR_CONF_DIR=~/punch-deployer-6.4.5/examples/platforms/getting_started_deployer/runtime/
punchplatform-deployer.sh --copy-configuration

Warning

The configuration tools used in this tutorial are not recommended for a production use. On a production platform, configuration must be managed carefully with a git for example.

Prepare platform¶

Right after deploying the platform and the configuration, the operator must push the Kibana resources and the Elasticsearch templates.

# punchoperator@server1
punchplatform-push-es-templates.sh -d conf/resources/elasticsearch/ -l http://server1:9200 -u admin -p admin
punchplatform-setup-kibana.sh --import -l http://server3:5601 -u admin:admin

You can check that Punch dashboards are available in Kibana.

Punchlinectl¶

Start¶

Operator can start punchline & applications in foreground.

Let's try to launch a punchline in foreground:

punchlinectl --tenant mytenant start --punchline ~/conf/tenants/mytenant/channels/stormshield_networksecurity/input.yaml

Your stream punchline is running and you can inject logs in another terminal:

punchplatform-log-injector.sh -c ~/conf/resources/injectors/mytenant/stormshield_networksecurity_injector.json

Resolve¶

In deployed platform, there is a resolv.yaml file. We added this file in the $PUNCHPLATFORM_CONF_DIR at the beginning of the tutorial. The resolver adds and replaces parameters in configuration files based on JSONPath rules.

Let's take the example of the first rule:

elasticsearch_nodes:
  selection:
    tenant: "*"
    channel: "*"
    runtime: "*"
    name: "*"
  match: "$.spec.dag[?(@.type=='elasticsearch_output' || @.type=='elastic_output')].settings"
  additional_values:
    http_hosts: 
      host: server2
      port: 9200

This rule will add http_hosts parameter to all elastisearch_output and elastic_output nodes. This makes it possible to reuse configurations (standalone ones for example) on different platforms.

Let's see how the resolver changes the configurations on the punchline we started !

Without resolver:

cat ~/conf/tenants/mytenant/channels/stormshield_networksecurity/input.yaml | yq e -j | jq .

With resolver:

punchlinectl --tenant mytenant resolve --file ~/conf/tenants/mytenant/channels/stormshield_networksecurity/input.yaml | jq .

You can see that many sections were augmented by this resolver.

Channelctl¶

Operator is the one submitting channels to the Punch orchestrator: Shiva.

You can start channels as you would do in Standalone.

Let's start monitoring channels that will be useful to understand Shiva in the next chapter.

channelctl -t mytenant start --channel monitoring
channelctl -t platform start --channel monitoring