Deploying ElasticSearch via Minionless Salt
• Mark Eschbach
I have been trying to avoid it for a while. ElasticSearch that is. I have always looked at as far exceeding my needs. Originally there was hope for a hand rolled solution. The honest truth though, is I would rather spend my time on other problems. So I’m just going to roll it out for now.
So on to the repeatable builds! I have been using Salt in my professional engagement recently. Specifically to configure the VMs and VM images. It is a fairly cool system which extends the declarative approach to inside the system. A coworker recently mentioned using it for his personal devices. This is my attempt to do the same.
Packer’s Masterless Provisioner is fairly painless to use. Pretty much point to a local directory, then like magic, it’s transported and applied. I believe Ubuntu has a package. Or least according to their documentation. Works just like the label says! Or at least so far…
To figure out where the salt configuration lives! With the provisioner they lived at
/srv/salt however that does not
seem to be the case at all. Turns out the first change should be in
/etc/salt/minion, setting the variable
local. Next up is to define
base: '*': - elasticsearch
elasticsearch: group.present: - system: True user.present: - fullname: ElasticSearch - shell: /bin/false - home: /srv/elastic/elasticsearch - system: True - gid: elasticsearch /srv/elastic: file.directory: - user: root - group: root /srv/elastic/elasticsearch: archive.extracted: - source: https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-7.1.1-linux-x86_64.tar.gz - source_hash: https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-7.1.1-linux-x86_64.tar.gz.sha512 - options: "-v --strip-components=1 -C /srv/elastic/elasticsearch" - enforce_toplevel: False file.directory: - user: elasticsearch - group: elasticsearch - recurse: - user - group /etc/systemd/system/elasticsearch.service: file.managed: - source: salt://elasticsearch.service - user: root - group: root - mode: 0444 service.running: - name: elasticsearch - enable: True - reload: True
When I issued
OSError: Failed to initialize OpenSSL library (OPENSSL_init_crypto failed) I received an error. Turns
out this might be a stale OpenSSL binding for Python. I figured it
would be safer to upgrade Salt too, since I had a fairly outdated version:
user@host:> pip3 show salt Name: salt Version: 2017.7.4 Summary: Portable, distributed, remote execution and configuration management system Home-page: http://saltstack.org Author: Thomas S Hatch Author-email: firstname.lastname@example.org License: Apache Software License 2.0 Location: /usr/lib/python3/dist-packages Requires:
pip3 install -U salt and…it explodes with an error in my file plus a
msgpack warning. Well, progress I
suppose. Because I had a legitimate error in my file. Ten points to Hufflepuff! I thought the command going dark
while running was an artifact of the Packer interactions. Turns out it just does not tell you anything. Probably
better to run it with
-l debug from now on.
And that worked! Awesome.