Start Local Clusters, Use Kibana/OpenSearch Dashboards Dev Tools or curl, and Inspect Cluster/Node Health

Learning outcomes

This lesson creates the chapter’s observable baseline: two pinned search engines running side by side on local loopback ports with product identity, authentication/TLS state, cluster health, node/JVM evidence and deterministic AtlasMart data. curl is mandatory because it exposes the HTTP boundary directly; Kibana/OpenSearch Dashboards Dev Tools are optional interfaces over the same ideas.

1. Preconditions and resource budget

Install Docker Desktop on Windows/macOS or Docker Engine on Linux. Elastic’s current Docker guidance recommends at least 4 GB allocated to Docker Desktop for its development workflow; running Elasticsearch and OpenSearch simultaneously needs enough host memory for both JVMs plus Docker and the browser. This chapter intentionally uses one node per product and no Dashboards containers by default to reduce memory pressure.

Create one private Docker network and two named data volumes. Host ports bind to 127.0.0.1 so another machine cannot reach the lab through a normal external interface. The containers still communicate on the private Docker network.

docker network create atlasmart-searchdocker volume create atlasmart-es-datadocker volume create atlasmart-os-data

2. Start pinned Elasticsearch with its default security path

The official Elasticsearch Docker workflow starts a pinned image, generates security material, prints the initial elastic password/enrollment token, and allows the HTTP CA certificate to be copied from the container. We keep that secure default rather than disabling security for convenience.

docker pull docker.elastic.co/elasticsearch/elasticsearch:9.5.3docker run -d --name atlasmart-es --hostname atlasmart-es --network atlasmart-search -p 127.0.0.1:9200:9200 -m 1GB -v atlasmart-es-data:/usr/share/elasticsearch/data docker.elastic.co/elasticsearch/elasticsearch:9.5.3docker logs --tail 120 atlasmart-es

Wait for startup. If you did not preserve the initially printed password, reset it using the supported tool, then store the new value only in your local shell/session—not in a committed lesson file:

docker exec -it atlasmart-es /usr/share/elasticsearch/bin/elasticsearch-reset-password -u elasticdocker cp atlasmart-es:/usr/share/elasticsearch/config/certs/http_ca.crt ./atlasmart-es-http-ca.crt

Set ELASTIC_PASSWORD in your shell to the generated/reset value. In PowerShell use $env:ELASTIC_PASSWORD = "..."; in Bash use export ELASTIC_PASSWORD='...'. Do not commit it.

curl --cacert atlasmart-es-http-ca.crt -u "elastic:$ELASTIC_PASSWORD" https://localhost:9200/curl --cacert atlasmart-es-http-ca.crt -u "elastic:$ELASTIC_PASSWORD" "https://localhost:9200/_cluster/health?pretty"curl --cacert atlasmart-es-http-ca.crt -u "elastic:$ELASTIC_PASSWORD" "https://localhost:9200/_nodes?filter_path=cluster_name,nodes.*.name,nodes.*.version,nodes.*.roles,nodes.*.jvm.version"

Windows PowerShell users should call curl.exe when they want real curl semantics. A successful TLS request with --cacert proves the presented certificate chains to the copied course CA and the credentials were accepted for that request; it does not prove backups, high availability or production hardening.

3. Start pinned OpenSearch with demo security explicitly labeled

Current OpenSearch Docker distributions run the Security plugin demo configuration unless it is disabled. OpenSearch 2.12+ requires a custom initial admin password for that demo setup. The demo configuration uses self-signed/demo certificates and must not be reused as a production certificate/identity design.

# Bashexport OPENSEARCH_INITIAL_ADMIN_PASSWORD='replace-with-a-strong-local-lab-secret'# PowerShell equivalent:# $env:OPENSEARCH_INITIAL_ADMIN_PASSWORD = 'replace-with-a-strong-local-lab-secret' 

docker pull opensearchproject/opensearch:3.8.0docker run -d --name atlasmart-os --hostname atlasmart-os --network atlasmart-search -p 127.0.0.1:9201:9200 -p 127.0.0.1:9601:9600 -e discovery.type=single-node -e OPENSEARCH_INITIAL_ADMIN_PASSWORD -e "OPENSEARCH_JAVA_OPTS=-Xms512m -Xmx512m" -v atlasmart-os-data:/usr/share/opensearch/data opensearchproject/opensearch:3.8.0docker logs --tail 120 atlasmart-os

curl -k -u "admin:$OPENSEARCH_INITIAL_ADMIN_PASSWORD" https://localhost:9201/curl -k -u "admin:$OPENSEARCH_INITIAL_ADMIN_PASSWORD" "https://localhost:9201/_cluster/health?pretty"curl -k -u "admin:$OPENSEARCH_INITIAL_ADMIN_PASSWORD" "https://localhost:9201/_nodes?filter_path=cluster_name,nodes.*.name,nodes.*.version,nodes.*.roles,nodes.*.jvm.version"

4. Health is shard allocation, not “the process exists”

In both product families, green/yellow/red health is about shard allocation. A single-node cluster can be yellow when a primary is allocated but a configured replica has nowhere else to go. That is not equivalent to a red cluster, but it is evidence that the requested redundancy is not satisfied. For the Chapter 01 fixture we use zero replicas explicitly so the lab does not pretend one node is highly available.

PUT /atlasmart-products-v1{  "settings": {"number_of_shards": 1, "number_of_replicas": 0},  "mappings": {    "properties": {      "product_id": {"type":"keyword"},      "name": {"type":"text"},      "category": {"type":"keyword"},      "description": {"type":"text"}    }  }}

5. Diagnose failures by layer

If you prefer Dev Tools, start the version-matched Kibana/OpenSearch Dashboards using current official instructions and execute the same REST request bodies there. The UI is a convenience layer; curl remains the portable chapter baseline.

Production judgment

A process that returns HTTP 200 is only the first layer of readiness. Production acceptance also needs authenticated/authorized access, valid certificate verification, shard allocation, capacity headroom, snapshot/restore, monitoring, tested upgrades and application-level correctness. Next, turn this ad-hoc startup into a repeatable course lab with data, metrics and reset automation.

Summary and next step

You now have a safe identity and health evidence path for both products, with TLS/auth differences visible rather than hidden. Next, make the AtlasMart fixture persistent and repeatable, collect metrics, and define reset procedures that cannot accidentally target unrelated data.

Authoritative references

• Elastic: single-node Docker cluster — Current secure Docker workflow, CA copy, password and REST verification.
• Elasticsearch cluster health API — Official green/yellow/red shard-allocation semantics.
• Elasticsearch CAT health — Human-oriented CAT health guidance.
• OpenSearch Docker installation — Current Docker setup and admin-password requirement.
• OpenSearch security demo configuration — Demo certificates/security behavior and production warning.
• OpenSearch quickstart — Official local Docker verification examples.