OpenSearch represents a pivotal evolution in the landscape of open-source search, analytics, and observability. Derived from Elasticsearch 7.10.2 and Kibana 7.10.2, it is distributed under the Apache 2.0 license, ensuring that the software remains 100% open-source. This architectural foundation provides a scalable, flexible, and extensible suite that enables organizations to manage massive datasets for real-time search and complex analytics. The ecosystem is primarily composed of two core components: the OpenSearch search engine daemon, which handles the indexing and querying of data, and OpenSearch Dashboards, the centralized user interface utilized for data administration and the creation of visual representations of that data.
The utilization of Docker for deploying OpenSearch transforms the installation process by abstracting the underlying operating system requirements. By leveraging containerization, users can move away from traditional installation methods such as RPM packages or manual Tarball extractions, both of which necessitate extensive manual configuration and environment tuning after the initial download. Docker provides a portable environment that ensures the application runs consistently across Linux, MacOS, and Windows, provided the host supports the Docker engine. This portability is critical for DevOps pipelines, where consistency between development, staging, and production environments is paramount to avoid "it works on my machine" syndrome.
Technical Specifications and Image Infrastructure
The OpenSearch project maintains a rigorous image lifecycle to ensure stability and security. The official images are hosted on Docker Hub and the Amazon Elastic Container Registry (Amazon ECR), allowing users to choose the registry that best fits their network latency and security requirements.
The base operating system for these images has evolved to improve security and performance. For versions 1.x and 2.x up until version 2.9.0, Amazon Linux 2 served as the base image. Starting with version 2.10.0, the project transitioned to Amazon Linux 2023, incorporating the latest security patches and kernel optimizations provided by the Amazon Linux ecosystem.
The image sizes vary significantly based on the architecture (AMD64 vs ARM64) and the specific version tag.
| Version Tag | Architecture | Image Size | Push Date (Approx) |
|---|---|---|---|
| latest | linux/amd64 | 1.03 GB | 7 days ago |
| latest | linux/arm64 | 794.43 MB | 7 days ago |
| 3.6.0 | linux/amd64 | Not Specified | Current |
| 2.19.5 | linux/amd64 | 994.28 MB | Current |
| 2.19.5 | linux/arm64 | 755.1 MB | Current |
| 3.5.0 | linux/amd64 | 1.11 GB | 1 month ago |
| 3.5.0 | linux/arm64 | 871.01 MB | 1 month ago |
| 2.19.4 | linux/amd64 | 993.11 MB | 2 months ago |
| 2.19.4 | linux/arm64 | 753.91 MB | 2 months ago |
| 3.4.0 | linux/amd64 | 1.08 GB | 3 months ago |
| 3.4.0 | linux/arm64 | 849.45 MB | 3 months ago |
| 3.3.2 | linux/amd64 | 999.75 MB | 4 months ago |
| 3.3.2 | linux/arm64 | 761.06 MB | 4 months ago |
| 3.3.1 | linux/amd64 | 979.94 MB | 6 months ago |
| 3.3.1 | linux/arm64 | 741.25 MB | 6 months ago |
Local Development and Single-Node Deployment
For developers and users performing local testing, OpenSearch provides a streamlined path to launch a single-node cluster. This mode bypasses the complexities of cluster discovery and coordination that are typically required in production environments.
A critical hardware requirement for those utilizing Docker Desktop is the allocation of system memory. It is strongly recommended to configure Docker to use a minimum of 4 GB of system memory to prevent the OpenSearch JVM from crashing due to Out-of-Memory (OOM) errors, as search engines are resource-intensive by nature.
To pull the latest image from Docker Hub, use the following command:
docker pull opensearchproject/opensearch:latest
For a basic single-node setup for local development, the following command is utilized:
docker run -it -p 9200:9200 -p 9600:9600 -e "discovery.type=single-node" --name opensearch-node -d opensearchproject/opensearch:latest
In this command, port 9200 is mapped for the REST API and port 9600 is mapped for performance analyzer capabilities. The environment variable discovery.type=single-node instructs OpenSearch to skip the bootstrap checks and cluster formation process, allowing the node to start in isolation.
Starting with OpenSearch version 2.12, the security requirements have been tightened. A custom password for the admin user is now mandatory to initialize the demo configuration. The command is expanded as follows:
docker run -it -p 9200:9200 -p 9600:9600 -e OPENSEARCH_INITIAL_ADMIN_PASSWORD=<strong-password> -e "discovery.type=single-node" --name opensearch-node opensearchproject/opensearch:latest
Upon deployment, users can verify the operational status of the node by sending requests to the OpenSearch REST API. It is important to note that by default, OpenSearch utilizes self-signed TLS certificates for secure communication, which may require the use of the -k or --insecure flag when using tools like curl.
Advanced Cluster Management with Docker Compose
While docker run is sufficient for single nodes, Docker Compose is the preferred method for managing full clusters and integrated stacks. This approach allows the entire infrastructure—including network settings, volume mounts, and environment variables—to be defined in a single YAML file.
The OpenSearch project provides sample docker-compose.yml files to reduce friction. To initialize the cluster in the background, the following command is used:
docker compose up -d
To stop the cluster, the following command is executed:
docker compose down
If the goal is to completely wipe the environment, including the persistent data stored in Docker volumes, the -v flag must be added:
docker compose down -v
In the context of Docker Compose V2 and later, certain fields in the YAML file have become optional. The version of OpenSearch deployed is primarily controlled by the image tag, often represented as a variable such as opensearchproject/opensearch:${OS_VER}. Furthermore, there is a specific precedence for password configuration: if a password for the admin user is provided in a .env file, it will be overridden by any password specified in the internal_users.yml file.
Integrating OpenSearch Dashboards
OpenSearch Dashboards serves as the visualization layer. To ensure the Dashboards container can communicate with the OpenSearch engine, they must reside on the same Docker network.
First, create a dedicated network:
docker network create os-net
Next, start the OpenSearch node on that network:
docker run -d --name opensearch-node -p 9200:9200 -p 9600:9600 --network os-net -e "discovery.type=single-node" -e "OPENSEARCH_INITIAL_ADMIN_PASSWORD=<admin_password>" opensearchproject/opensearch:latest
To configure the Dashboards instance, a configuration file named opensearch_dashboards.yml must be created with the following settings:
yaml
server.name: opensearch_dashboards
server.host: "0.0.0.0"
server.customResponseHeaders : { "Access-Control-Allow-Credentials" : "true" }
server.ssl.enabled: false
opensearch.hosts: ["https://opensearch-node:9200"]
opensearch.ssl.verificationMode: none
opensearch.username: kibanaserver
opensearch.password: kibanaserver
opensearch.requestHeadersWhitelist: ["securitytenant","Authorization"]
opensearch_security.multitenancy.enabled: true
opensearch_security.multitenancy.tenants.preferred: ["Private", "Global"]
opensearch_security.readonly_mode.roles: ["kibana_read_only"]
The technical configuration above disables HTTPS on the Dashboards side (server.ssl.enabled: false) and connects to the OpenSearch node using the container name opensearch-node via the internal Docker network.
Finally, launch the Dashboards container by mounting the configuration file as a volume:
docker run -d --name osd \ --network os-net \ -p 5601:5601 \ -v ./opensearch_dashboards.yml:/usr/share/opensearch-dashboards/config/opensearch_dashboards.yml
Custom Plugin Management and Image Building
For specialized use cases, users may need to extend the functionality of OpenSearch by installing plugins. This requires the creation of a custom Docker image using a Dockerfile.
To implement a custom plugin, a Dockerfile should be structured as follows:
dockerfile
FROM opensearchproject/opensearch:latest
RUN /usr/share/opensearch/bin/opensearch-plugin install --batch <pluginId>
The process to build and run this custom image involves two primary steps. First, build the image:
docker build --tag=opensearch-custom-plugin .
Second, start the container using the newly created image, ensuring data persistence via volume mapping:
docker run -p 9200:9200 -p 9600:9600 -v /usr/share/opensearch/data opensearch-custom-plugin
Enterprise Distribution and Sourcing
While Docker Hub is the primary source for many, the project also provides images via the Amazon Elastic Container Registry (ECR). This is particularly beneficial for users already operating within the AWS ecosystem, as it can reduce data transfer costs and improve pull speeds.
To pull the image from ECR, use:
docker pull public.ecr.aws/opensearchproject/opensearch:latest
For those who wish to build images from the source, the project maintains a repository of Dockerfiles. Although the original docker-images repository is being archived in favor of the opensearch-build repository, the build logic remains consistent. To build a specific major version from the source, the following sequence is used:
cd {2.x} && docker build -t opensearch:{major_version} -f Dockerfile .
Analysis of Governance and Contribution
The OpenSearch project is governed by the Apache License, Version 2.0. This licensing choice is a strategic move to ensure that the software remains open and accessible, removing the barriers often associated with proprietary licenses or restrictive contributor license agreements (CLAs). By eliminating the need for a lengthy CLA, the project encourages a broader range of community contributions, focusing on code quality and innovation rather than legal bureaucracy.
The project also adheres to the Amazon Open Source Code of Conduct to maintain a professional and inclusive environment. Security is handled with a high degree of caution; users are instructed to report potential vulnerabilities through the AWS/Amazon Security vulnerability reporting page rather than opening public GitHub issues, which prevents the premature exposure of security flaws to malicious actors.
Conclusion
The deployment of OpenSearch via Docker represents a significant optimization in the lifecycle of search and analytics infrastructure. By moving from manual installations to containerized environments, the project provides a streamlined, portable, and scalable solution that caters to both local developers and enterprise architects. The transition to Amazon Linux 2023 for newer versions reflects a commitment to security and modernization. Through the use of Docker Compose and customized Dockerfiles, users can orchestrate complex environments including OpenSearch Dashboards and third-party plugins, all while maintaining the flexibility granted by the Apache 2.0 license. The strategic availability of images on both Docker Hub and Amazon ECR ensures that the global community has low-latency access to the tools required for modern observability.