mirrors/ClickHouse
0
0 Fork 0
mirror of https://github.com/ClickHouse/ClickHouse.git synced 2026-10-28 16:18:23 +08:00
Code Activity
Files
master
ClickHouse/docs/clickstack/deployment/docker-compose.mdx
T
Alexey Milovidov e8e1e12ba0 Add a style check for the spelling of ClickHouse 
The product name is written `ClickHouse` - one word, with a capital `C`
and a capital `H`. Two case variants are accepted, because a mixed case
is unusable there: `clickhouse` for identifiers, package, binary and host
names, and `CLICKHOUSE` for macros and environment variables. Everything
else - `Clickhouse`, `clickHouse`, `click_house`, `CLICK_HOUSE`,
`click-house`, `Click House` - is a misspelling, and the new
`clickhouse_spelling` check of the style job reports it, in code as well
as in comments, messages, documentation and file names.

The check searches every file tracked by git, and the file names
themselves. It skips:
* `contrib` - third-party sources;
* the generated locale directories of the documentation - a machine
  translation of the English pages, which are checked instead;
* release notes - a record of what was published;
* `docs/_specs` - API specifications pinned from their generator;
* regions between `AUTOGENERATED_START` and `AUTOGENERATED_END` markers -
  their source of truth (a `FunctionDocumentation` string, for instance)
  is checked instead;
* URLs - a link whose path spells the name differently is not a mistake
  we can fix, and rewriting it would only break the link;
* the exceptions listed in `clickhouse_spelling_ignore.txt` - text that
  is not ours to spell: names defined by other projects (the
  `ClickhouseClientOptions` of our Azure SDK fork, the `clickHouse*`
  parameters of Google's Dataflow templates), verbatim quotations (Stack
  Overflow post titles shown as query output), and the misspellings that
  tests feed to the server on purpose (`LIKE` / `ILIKE` case variants, an
  unknown URI scheme).

The rest of the change fixes the 191 misspellings this found. Most are
prose and comments; the renamed identifiers are `isClickhouseApp`,
`getClickhouseAttemptNumber` / `setClickhouseAttemptNumber`,
`getClickhouseTableSchemaById` / `hasClickhouseTableSchemaById`, the
`Clickhouse*` classes of `clickhouse-diagnostics`, the `tabClickhouse` /
`btnQueryClickhouse` element ids of the `utils` web tools, and
`clickHousePartsInserter.js`. Three of them are visible to tests: the
`X-Clickhouse-Format` HTTP header, the `SOURCE(Clickhouse(...))`
dictionary source and a directory named `Clickhouse`; the first two are
matched case-insensitively by the server (Poco header collections are
case-insensitive, and the parser lowercases the source name), which I
confirmed against a running server.

The rule is also written down in the style guide.
2026-08-15 02:44:49 +00:00

150 lines
6.5 KiB
Plaintext
Raw Permalink Blame History

---
slug: /use-cases/observability/clickstack/deployment/docker-compose
title: 'Docker Compose'
description: 'Deploying ClickStack Open Source with Docker Compose - The ClickHouse Observability Stack'
doc_type: 'guide'
keywords: ['ClickStack Docker Compose', 'Docker Compose ClickHouse', 'HyperDX Docker deployment', 'ClickStack deployment guide', 'OpenTelemetry Docker Compose']
---
import { Image } from "/snippets/components/Image.jsx";
import JSONSupport from '/snippets/_json_support.mdx';
All ClickStack Open Source components are distributed separately as individual Docker images:
* **ClickHouse**
* **HyperDX**
* **OpenTelemetry (OTel) collector**
* **MongoDB**
These images can be combined and deployed locally using Docker Compose.
Docker Compose exposes additional ports for observability and ingestion based on the default `otel-collector` setup:
- `13133`: Health check endpoint for the `health_check` extension
- `24225`: Fluentd receiver for log ingestion
- `4317`: OTLP gRPC receiver (standard for traces, logs, and metrics)
- `4318`: OTLP HTTP receiver (alternative to gRPC)
- `8888`: Prometheus metrics endpoint for monitoring the collector itself
These ports enable integrations with a variety of telemetry sources and make the OpenTelemetry collector production-ready for diverse ingestion needs.
### Suitable for {#suitable-for}
* Local testing
* Proof of concepts
* Production deployments where fault tolerance isn't required and a single server is sufficient to host all ClickHouse data
* When deploying ClickStack but hosting ClickHouse separately e.g. using ClickHouse Cloud.
## Deployment steps {#deployment-steps}
<br/>
<Steps>
<Step title="Clone the repo" id="clone-the-repo">
To deploy with Docker Compose clone the ClickStack repo, change into the directory and run `docker-compose up`:
```shell
git clone https://github.com/ClickHouse/ClickStack.git
docker compose up
```
</Step>
<Step title="Navigate to the HyperDX UI" id="navigate-to-hyperdx-ui">
Visit [http://localhost:8080](http://localhost:8080) to access the HyperDX UI.
Create a user, providing a username and password which meets the requirements.
On clicking `Create` data sources will be created for the ClickHouse instance deployed with Docker Compose.
<Info>
**Overriding default connection**
You can override the default connection to the integrated ClickHouse instance. For details, see ["Using ClickHouse Cloud"](#using-clickhouse-cloud).
</Info>
<Image img="/images/use-cases/observability/hyperdx-login.webp" alt="HyperDX UI" size="lg"/>
For an example of using an alternative ClickHouse instance, see ["Using ClickHouse Cloud"](#using-clickhouse-cloud).
</Step>
<Step title="Complete connection details" id="complete-connection-details">
To connect to the deployed ClickHouse instance, simply click **Create** and accept the default settings.
If you prefer to connect to your own **external ClickHouse cluster** e.g. ClickHouse Cloud, you can manually enter your connection credentials.
If prompted to create a source, retain all default values and complete the `Table` field with the value `otel_logs`. All other settings should be auto-detected, allowing you to click `Save New Source`.
<Image img="/images/use-cases/observability/hyperdx-logs.webp" alt="Create logs source" size="md"/>
</Step>
</Steps>
## Modifying compose settings {#modifying-settings}
You can modify settings for the stack, such as the version used, through the environment variable file:
```shell
user@example-host clickstack % cat .env
# Used by docker-compose.yml
IMAGE_NAME_DOCKERHUB=clickhouse/clickstack-all-in-one
LOCAL_IMAGE_NAME_DOCKERHUB=clickhouse/clickstack-local
ALL_IN_ONE_IMAGE_NAME_DOCKERHUB=clickhouse/clickstack-all-in-one
OTEL_COLLECTOR_IMAGE_NAME_DOCKERHUB=clickhouse/clickstack-otel-collector
CODE_VERSION=2.8.0
IMAGE_VERSION_SUB_TAG=.8.0
IMAGE_VERSION=2
IMAGE_NIGHTLY_TAG=2-nightly
IMAGE_LATEST_TAG=latest
# Set up domain URLs
HYPERDX_API_PORT=8000 #optional (should not be taken by other services)
HYPERDX_APP_PORT=8080
HYPERDX_APP_URL=http://localhost
HYPERDX_LOG_LEVEL=debug
HYPERDX_OPAMP_PORT=4320
# Otel/ClickHouse config
HYPERDX_OTEL_EXPORTER_CLICKHOUSE_DATABASE=default
```
### Configuring the OpenTelemetry collector {#configuring-collector}
The OTel collector configuration can be modified if required - see ["Modifying configuration"](/clickstack/ingesting-data/collector#modifying-otel-collector-configuration).
## Using ClickHouse Cloud {#using-clickhouse-cloud}
This distribution can be used with ClickHouse Cloud, but it differs from [Managed ClickStack](/clickstack/deployment/managed). In this setup, you manage the ClickStack UI yourself while using ClickHouse Cloud only for compute and storage. Unless you have a specific reason to operate the UI independently, we recommend using Managed ClickStack, which includes integrated authentication and additional enterprise features, and removes the need to manage the ClickStack UI yourself.
You should:
- Remove the ClickHouse service from the `docker-compose.yml` file. This is optional if testing, as the deployed ClickHouse instance will simply be ignored - although waste local resources. If removing the service, ensure any references to the service such as `depends_on` are removed.
- Modify the OTel collector to use a ClickHouse Cloud instance by setting the environment variables `CLICKHOUSE_ENDPOINT`, `CLICKHOUSE_USER` and `CLICKHOUSE_PASSWORD` in the compose file. Specifically, add the environment variables to the OTel collector service:
```shell
otel-collector:
image: ${OTEL_COLLECTOR_IMAGE_NAME_DOCKERHUB}:${IMAGE_VERSION}
environment:
CLICKHOUSE_ENDPOINT: '<CLICKHOUSE_ENDPOINT>' # https endpoint here
CLICKHOUSE_USER: '<CLICKHOUSE_USER>'
CLICKHOUSE_PASSWORD: '<CLICKHOUSE_PASSWORD>'
HYPERDX_OTEL_EXPORTER_CLICKHOUSE_DATABASE: ${HYPERDX_OTEL_EXPORTER_CLICKHOUSE_DATABASE}
HYPERDX_LOG_LEVEL: ${HYPERDX_LOG_LEVEL}
OPAMP_SERVER_URL: 'http://app:${HYPERDX_OPAMP_PORT}'
ports:
- '13133:13133' # health_check extension
- '24225:24225' # fluentd receiver
- '4317:4317' # OTLP gRPC receiver
- '4318:4318' # OTLP http receiver
- '8888:8888' # metrics extension
restart: always
networks:
- internal
```
The `CLICKHOUSE_ENDPOINT` should be the ClickHouse Cloud HTTPS endpoint, including the port `8443` e.g. `https://mxl4k3ul6a.us-east-2.aws.clickhouse.com:8443`
- On connecting to the HyperDX UI and creating a connection to ClickHouse, use your Cloud credentials.
<JSONSupport/>
View Git Blame Copy Permalink