Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add ELK stack to docker-compose files #80

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open

Conversation

Killpit
Copy link

@Killpit Killpit commented Sep 24, 2024

Changes

-Added ELK stack for people who wants to work with ELK stack with OpenTelemetry
-Combined the additions with both Elastic stack documentation, Docker Hub and the docker-compose and .env file structures on implementing changes.

Copy link

cla-checker-service bot commented Sep 24, 2024

💚 CLA has been signed

Copy link

@rogercoll rogercoll left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for creating this PR @Killpit.

I see that most of the changes are in the docker-compose.yml file, which we try not to change/diverge from the upstream fork. The upstream repository is heavily forked and to improve the maintainability (we have nightly auto-syncs) the forked versions rely mostly on environment variables, specifically the .env.override file. Elastic's fork changes should be done using environment variables or by adding new files to avoid upstream conflicts.

In addition, what would happen for cloud deployments? With these changes, users using Elasticsearch cloud would be deploying a local instance too. What do you think if we provide a separate docker-compose file (e.g. docker-compose.elk.yaml) or we update the README to point to some public documentation for local deployments?

@Killpit
Copy link
Author

Killpit commented Oct 7, 2024

Thanks for creating this PR @Killpit.

I see that most of the changes are in the docker-compose.yml file, which we try not to change/diverge from the upstream fork. The upstream repository is heavily forked and to improve the maintainability (we have nightly auto-syncs) the forked versions rely mostly on environment variables, specifically the .env.override file. Elastic's fork changes should be done using environment variables or by adding new files to avoid upstream conflicts.

In addition, what would happen for cloud deployments? With these changes, users using Elasticsearch cloud would be deploying a local instance too. What do you think if we provide a separate docker-compose file (e.g. docker-compose.elk.yaml) or we update the README to point to some public documentation for local deployments?

I can create a separate Docker Compose file as a solution, I think it would work and then we can update the public documentation alongside with it. What is your opinion on that @rogercoll

@Killpit
Copy link
Author

Killpit commented Oct 14, 2024

Thanks for creating this PR @Killpit.

I see that most of the changes are in the docker-compose.yml file, which we try not to change/diverge from the upstream fork. The upstream repository is heavily forked and to improve the maintainability (we have nightly auto-syncs) the forked versions rely mostly on environment variables, specifically the .env.override file. Elastic's fork changes should be done using environment variables or by adding new files to avoid upstream conflicts.

In addition, what would happen for cloud deployments? With these changes, users using Elasticsearch cloud would be deploying a local instance too. What do you think if we provide a separate docker-compose file (e.g. docker-compose.elk.yaml) or we update the README to point to some public documentation for local deployments?

I'll create a new docker-compose file and can make the same pull request here, or change it @rogercoll

@rogercoll
Copy link

@Killpit I have discussed this PR with the team and we think that to ease the maintenance we could just reference existing tools that actively maintain ELK docker compose files. For example, this is a very new repository that creates a custom ELK docker compose file from a bash script: https://github.com/elastic/start-local

What do you think if we add a new section in the README.md referencing the start-local repository for local ELK deployments?

@Killpit
Copy link
Author

Killpit commented Oct 14, 2024

@Killpit I have discussed this PR with the team and we think that to ease the maintenance we could just reference existing tools that actively maintain ELK docker compose files. For example, this is a very new repository that creates a custom ELK docker compose file from a bash script: https://github.com/elastic/start-local

What do you think if we add a new section in the README.md referencing the start-local repository for local ELK deployments?

Sounds good to me if I get the credit

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants