Add rules YAML directive

[operatorequals]

This commit adds the rules YAML directive in the Helm Chart.
It is used similarly to stable/elastalert [ 1 ]

Specifically, the rules directive expects a map of <name, rule yaml>
and copies the rules as files to a Kubernetes ConfigMap with the
yaml file extension.

Finally, it uses the already there volume-mount-hack initContainer
to copy the rule files to the /opt/elastalert/rules directory
of the Pod (under data volumeMount) and grants RW permissions to
elasticsearch-server.

Related Issue [ 2 ]

[1] :https://github.com/helm/charts/tree/master/stable/elastalert
[2] :daichi703n/praeco-helm#4

[daichi703n]

@operatorequals I confirmed it works basically. Thanks.
Please tell me the expected behavior about delete and rename.
After deploying static, I renamed static to static2 by editing vars.yml. After re-deploying (upgrade), static remains. I think static should be removed. What do you think?
In addition, there are static and static.yaml file. Is this expected?

/opt/elastalert-server $ ls -la /opt/elastalert/rules/
total 36
drwxrwxrwx    2 root     root          4096 Sep 15 17:13 .
drwxr-xr-x    1 node     node          4096 Aug 27  2019 ..
-rw-r--r--    1 root     root           246 Sep 15 17:12 BaseRule.config
-rwxrwxrwx    1 root     root           678 Sep 15 16:51 static
-rwxrwxrwx    1 root     root           678 Sep 15 16:59 static.yaml
-rwxrwxrwx    1 root     root           678 Sep 15 17:13 static2
-rwxrwxrwx    1 root     root           678 Sep 15 17:13 static2.yaml
-rwxrwxrwx    1 node     node           611 Sep 15 16:14 test.yaml

[operatorequals]

This is very good and expected!

What I am doing is populate a ConfigMap with the rules in yaml files. Then, copy them to the /opt/elastalert/rules, which is a PersistentVolume (mounted as data).
When you re-deploy with recreate-pods, the Pods get recreated but not the PersistentVolume, so it stays under /opt/elastalert/rules. So all rules of the previous deployment still exist (did not get deleted along with the Pods). All rules with the same name get overwriten. All new rules get copied in the VolumeClaim.

Deleting a rule with rm ... or through the Praeco GUI will work, as the node user has write access to all rule files.

[daichi703n]

@operatorequals Sorry for late reply.

In addition, there are static and static.yaml file. Is this expected?

Is this occured on your environment? After I removed static.yaml from Praeco GUI, static remains and connot remove from GUI (404). I can remove it by ssh into container, but this is not a standard operation.

I think this issue occurs when initial creation of ConfigMap. But now I don't know how it generated...

[operatorequals]

No. Looks like this is a leftover of your previous deployments.
Searching the "Files Changed" tab for static does not bring any results.

The Rules ConfigMap does not have any static field.

For me it does not exist:

$ k exec -ti praeco-elastalert-5cfb7889fd-6krw8  -- ls /opt/elastalert/rules | grep -i static
$

[daichi703n]

static is my test naming. When I deploy your rule,

elastalert:
[...]
  rules:
    openvpn: |
      __praeco_query_builder: '{"query":{"logicalOperator":"all","children":[]}}'
      alert:
        - slack
      alert_subject: OpenVPN connection

openvpn_sec_connection and openvpn_sec_connection.taml are generated.

/opt/elastalert-server $ ls -la /opt/elastalert/rules/
total 60
drwxrwxrwx    2 root     root          4096 Sep 22 13:51 .
drwxr-xr-x    1 node     node          4096 Aug 27  2019 ..
-rw-r--r--    1 root     root           246 Sep 22 13:51 BaseRule.config
-rwxrwxrwx    1 root     root           799 Sep 22 13:51 openvpn_sec_connection
-rwxrwxrwx    1 root     root           799 Sep 22 13:51 openvpn_sec_connection.yaml
-rwxrwxrwx    1 root     root           678 Sep 22 11:41 static
-rwxrwxrwx    1 root     root           678 Sep 22 12:59 static.yaml

[operatorequals]

I don't know why this happens to your deployment.
I cannot reproduce it in mine.

[daichi703n]

Sorry for late reply. Thanks for your testing. It seems to be issue on my deployment...