Before upgrading to 8, you must be running at least version 7.17 … so I am first upgrading my ES7 to a new enough version that upgrading to ES8 is possible.
Environment
Not master eligible nodes:
a6b30865c82c.example.com
a6b30865c83c.example.com
Master eligible nodes:
a6b30865c81c.example.com
- Disable shard allocation
PUT _cluster/settings{ "persistent": { "cluster.routing.allocation.enable": "primaries" }}
- Stop non-essential indexing and flush
POST _flush/synced
- Upgrade the non-master eligible nodes first then the master-eligible nodes. One at a time, SSH to the host and upgrade ES
a. Stop ES
systemctl stop elasticsearch
b. Install the new RPM:
rpm --import https://artifacts.elastic.co/GPG-KEY-elasticsearch
wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-7.17.3-x86_64.rpm
wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-7.17.3-x86_64.rpm.sha512
shasum -a 512 -c elasticsearch-7.17.3-x86_64.rpm.sha512
rpm -U elasticsearch-7.17.3-x86_64.rpm
c. Update configuration for new version
vi /usr/lib/tmpfiles.d/elasticsearch.conf
vi /etc/elasticsearch/elasticsearch.yml # Add the action.auto_create_index as required -- * for all, or you can restrict auto-creation to certain indices
d. Update unit file and start services
systemctl daemon-reload
systemctl enable elasticsearch
systemctl start elasticsearch.service
- On the Kibana server, upgrade Kibana to a matching version:systemctl stop kibana
wget https://artifacts.elastic.co/downloads/kibana/kibana-7.17.3-x86_64.rpm
rpm -U kibana-7.17.3-x86_64.rpm
sytemctl daemon-reload
systemctl enable kibana
systemctl start kibana - Access the Kibana console and ensure the upgraded node is back online
- Re-enable shard allocation
PUT _cluster/settings{"persistent": {"cluster.routing.allocation.enable": null }}
Can you please share steps to upgrade Elasticsearch , Kibana installed with docker compose as a 3 node cluister from 7.10 to 7.17
Elastic Forums shares other methods but not containers installed/started with docker compose – swarm.
Few people suggested to just point the compose file to the new image. But how to get the new image?
Before you upgrade anything, make sure everything you care about exists outside of the containers. In some of my sandboxes, I don’t care about any data or configuration loss, so “upgrade” basically means “start over with a different version”. But, if you’ve got real data … make sure your config & data storage were mapped to some external data (volume, bind mount, etc) otherwise “upgrade” means “blow away everything you care about” and you get to test your DR plan.
Now, assuming you are certain your data isn’t all hiding within the container — the quick answer is that your new image will come from the same place you got the old image — hopefully you still have your docker-compose yaml file available! If so, it’s a quick edit. If not … you end up reconstructing the file based on what your running containers look like.
Finally, the quick edit to upgrade. Look for the ‘image’ section in your yaml — it will be something like this for your 7.10 implementation:
image: elasticsearch:7.10.1
You’d need to change that image to use something newer — maybe elasticsearch:7.17.6
That assumes you’re using an ES container. If you based your installation on, for example, CentOS and then installed ES components into the OS container … you’d need to make your own “new version of ES” container.
You can upgrade one node at a time by changing just the image for, say, your cold node.
Hi Lisa,
Can you please help answer below queries:
How to know if i should use RPM or debian to upgrade and any concerns using them rather than zip install?
https://www.elastic.co/guide/en/elasticsearch/reference/7.17/rpm.html
The link says: it has 30 day free trial. Afterwards, is it invoiced or any other concerns, if using the basic features.
current version is as below:
Virtualization: vmware
Operating System: Oracle Linux Server 7.8
CPE OS Name: cpe:/o:oracle:linux:7:8:server
Kernel: Linux 4.1.12-94.3.9.el7uek.x86_64
Architecture: x86-64
Oracle Linux is built from the RedHat source, so you’d follow the RedHat instructions for a package install. The *zip* install is for Windows, but there’s a tar.gz archive that can be used on Linux.
The difference between the package and archive installation– the end result is basically the same. The package has fixed locations into which files are placed, it executes some scripts that save a few steps like creating the elasticsearch user and group, and it includes a unit file for start/stop. For that reason, I’d go with the package installation if it’s a viable path. I bring up enough sandboxes that a few minutes here and there helps 🙂
There can be business cases that dictate one method or the other — I’ve worked places that only permit install from approved package repositories. I had to get the ES repo cleared through Security, include ES’s GPG key in the sealed corporate OS build, and *then* we could install ElasticSearch. Archive installations weren’t an option. Where I work now, the “application owners” are only given a /MyApp partition into which they are allowed to write data. The package installation has a pretty high level of effort to get all of the files in a place I’m allowed to write. So the archive installation is the way to go.
You *can* switch between the two installation types. It’s a bit of a pain since the file paths won’t match up — any config parameters that included fully qualified paths like /opt/elk/config/certs/host.cer needed to be updated to /package/install/path/config/certs/host.cer — but the ES node is fully functional after all of the path-related problems were sorted.