refactor: Consolidate and optimize Docker image architecture (#233)
## Overview
This PR consolidates and optimizes the Docker build system, reducing
redundancy and improving CI/CD performance. The changes eliminate
duplicate Dockerfiles, introduce a flexible build template, and optimize
release builds to reuse CI artifacts.
## Changes Summary
### 🐳 Docker Images Restructured
**Before:** 5 Dockerfiles with significant overlap
**After:** 4 focused images + 1 utility
#### Final Structure:
1. **`operator/Dockerfile`** ✨ Updated
- **Standard operator image** for CI and release builds
- Minimal node image (accepts pre-built binaries)
- GHCR: `ghcr.io/datahaven-xyz/datahaven/datahaven` (CI)
- DockerHub: `datahavenxyz/datahaven` (releases)
2. **`docker/datahaven-build.Dockerfile`** (moved from
`operator/Dockerfile`)
- Full source-to-binary build for manual releases
- DockerHub: `datahavenxyz/datahaven:{label}`
- Supports custom RUSTFLAGS and fast-runtime feature
- Only used for manual workflow_dispatch builds
3. **`docker/datahaven-production.Dockerfile`** (kept)
- Binary builder for CPU-specific releases
- Used by build-prod-binary workflow template
- Supports custom target-cpu flags
4. **`docker/datahaven-dev.Dockerfile`** ✨ NEW (local dev only)
- **FOR LOCAL DEVELOPMENT/TROUBLESHOOTING ONLY**
- Includes debug tools: gdb, strace, vim, sudo
- Extra dependencies: librocksdb-dev, curl
- RUST_BACKTRACE enabled by default
- **DO NOT USE for CI or production builds**
5. **`test/docker/crossbuild-mac-libpq.dockerfile`** (kept)
- Utility for macOS → Linux cross-compilation
#### Removed (Redundant):
- ❌ `docker/datahaven.Dockerfile` → replaced by operator/Dockerfile
- ❌ `test/docker/datahaven-node-local.dockerfile` → replaced by
datahaven-dev.Dockerfile
---
### 🔄 Workflow Improvements
#### Enhanced `publish-docker` Template
- Supports both GHCR and DockerHub registries
- Flexible inputs: dockerfile, context, build-args, cache scope
- Auto-generates OCI-compliant labels
- Reduces code duplication (~70 lines → ~15 per workflow)
#### Refactored CI Pipeline
- **`docker-build-ci`**: Builds `operator/Dockerfile` → GHCR for CI/E2E
testing
- **`docker-build-release`**: Builds `operator/Dockerfile` → DockerHub
(main branch only)
- Both CI and release workflows now use the same minimal operator image
- Release builds **reuse CI binaries** instead of rebuilding from source
#### Optimized Release Workflow
The `task-docker-release` workflow now has dual modes:
**Mode 1: `workflow_call` (CI - main pushes)**
- ✅ Reuses binary from CI's build-operator task
- ✅ Uses lightweight `operator/Dockerfile`
- ✅ Tags: `latest`, `sha-{short}`
- ⚡ **Fast**: ~5 minutes (vs ~30 min previously)
**Mode 2: `workflow_dispatch` (Manual)**
- ✅ Full source build with `datahaven-build.Dockerfile`
- ✅ Custom branch and label selection
- ✅ Optional fast-runtime feature
- ✅ Tags: `PROD-{label}` or user-defined
---
### 🔧 Additional Optimizations
- Copy libpq5 from builder stage instead of reinstalling (smaller,
faster)
- Remove redundant protobuf-compiler package (use protoc v21.12
directly)
- Standardize user UID to 1000 across all runtime images
- Consistent OCI labeling and metadata
---------
Co-authored-by: Claude <noreply@anthropic.com>
2025-10-14 23:33:20 +00:00
|
|
|
# --- Setup Build Environment ---
|
2025-10-22 11:36:30 +00:00
|
|
|
FROM rust:latest AS base
|
refactor: Consolidate and optimize Docker image architecture (#233)
## Overview
This PR consolidates and optimizes the Docker build system, reducing
redundancy and improving CI/CD performance. The changes eliminate
duplicate Dockerfiles, introduce a flexible build template, and optimize
release builds to reuse CI artifacts.
## Changes Summary
### 🐳 Docker Images Restructured
**Before:** 5 Dockerfiles with significant overlap
**After:** 4 focused images + 1 utility
#### Final Structure:
1. **`operator/Dockerfile`** ✨ Updated
- **Standard operator image** for CI and release builds
- Minimal node image (accepts pre-built binaries)
- GHCR: `ghcr.io/datahaven-xyz/datahaven/datahaven` (CI)
- DockerHub: `datahavenxyz/datahaven` (releases)
2. **`docker/datahaven-build.Dockerfile`** (moved from
`operator/Dockerfile`)
- Full source-to-binary build for manual releases
- DockerHub: `datahavenxyz/datahaven:{label}`
- Supports custom RUSTFLAGS and fast-runtime feature
- Only used for manual workflow_dispatch builds
3. **`docker/datahaven-production.Dockerfile`** (kept)
- Binary builder for CPU-specific releases
- Used by build-prod-binary workflow template
- Supports custom target-cpu flags
4. **`docker/datahaven-dev.Dockerfile`** ✨ NEW (local dev only)
- **FOR LOCAL DEVELOPMENT/TROUBLESHOOTING ONLY**
- Includes debug tools: gdb, strace, vim, sudo
- Extra dependencies: librocksdb-dev, curl
- RUST_BACKTRACE enabled by default
- **DO NOT USE for CI or production builds**
5. **`test/docker/crossbuild-mac-libpq.dockerfile`** (kept)
- Utility for macOS → Linux cross-compilation
#### Removed (Redundant):
- ❌ `docker/datahaven.Dockerfile` → replaced by operator/Dockerfile
- ❌ `test/docker/datahaven-node-local.dockerfile` → replaced by
datahaven-dev.Dockerfile
---
### 🔄 Workflow Improvements
#### Enhanced `publish-docker` Template
- Supports both GHCR and DockerHub registries
- Flexible inputs: dockerfile, context, build-args, cache scope
- Auto-generates OCI-compliant labels
- Reduces code duplication (~70 lines → ~15 per workflow)
#### Refactored CI Pipeline
- **`docker-build-ci`**: Builds `operator/Dockerfile` → GHCR for CI/E2E
testing
- **`docker-build-release`**: Builds `operator/Dockerfile` → DockerHub
(main branch only)
- Both CI and release workflows now use the same minimal operator image
- Release builds **reuse CI binaries** instead of rebuilding from source
#### Optimized Release Workflow
The `task-docker-release` workflow now has dual modes:
**Mode 1: `workflow_call` (CI - main pushes)**
- ✅ Reuses binary from CI's build-operator task
- ✅ Uses lightweight `operator/Dockerfile`
- ✅ Tags: `latest`, `sha-{short}`
- ⚡ **Fast**: ~5 minutes (vs ~30 min previously)
**Mode 2: `workflow_dispatch` (Manual)**
- ✅ Full source build with `datahaven-build.Dockerfile`
- ✅ Custom branch and label selection
- ✅ Optional fast-runtime feature
- ✅ Tags: `PROD-{label}` or user-defined
---
### 🔧 Additional Optimizations
- Copy libpq5 from builder stage instead of reinstalling (smaller,
faster)
- Remove redundant protobuf-compiler package (use protoc v21.12
directly)
- Standardize user UID to 1000 across all runtime images
- Consistent OCI labeling and metadata
---------
Co-authored-by: Claude <noreply@anthropic.com>
2025-10-14 23:33:20 +00:00
|
|
|
|
|
|
|
|
ARG MOLD_VERSION=2.40.4
|
|
|
|
|
ARG PROTOC_VER=21.12
|
|
|
|
|
ARG SCCACHE_VERSION=0.10.0
|
|
|
|
|
ARG FAST_RUNTIME=FALSE
|
|
|
|
|
RUN apt-get update && apt-get install -y --no-install-recommends \
|
|
|
|
|
curl \
|
|
|
|
|
xz-utils \
|
|
|
|
|
clang \
|
|
|
|
|
libpq-dev \
|
|
|
|
|
&& apt-get clean \
|
|
|
|
|
&& rm -rf /var/lib/apt/lists/* \
|
|
|
|
|
&& echo "Installing protoc v${PROTOC_VER}..." \
|
|
|
|
|
&& curl -Lo protoc.zip "https://github.com/protocolbuffers/protobuf/releases/download/v${PROTOC_VER}/protoc-${PROTOC_VER}-linux-x86_64.zip" \
|
|
|
|
|
&& unzip -q protoc.zip -d /usr/local/ \
|
2025-10-22 11:36:30 +00:00
|
|
|
&& rm protoc.zip
|
refactor: Consolidate and optimize Docker image architecture (#233)
## Overview
This PR consolidates and optimizes the Docker build system, reducing
redundancy and improving CI/CD performance. The changes eliminate
duplicate Dockerfiles, introduce a flexible build template, and optimize
release builds to reuse CI artifacts.
## Changes Summary
### 🐳 Docker Images Restructured
**Before:** 5 Dockerfiles with significant overlap
**After:** 4 focused images + 1 utility
#### Final Structure:
1. **`operator/Dockerfile`** ✨ Updated
- **Standard operator image** for CI and release builds
- Minimal node image (accepts pre-built binaries)
- GHCR: `ghcr.io/datahaven-xyz/datahaven/datahaven` (CI)
- DockerHub: `datahavenxyz/datahaven` (releases)
2. **`docker/datahaven-build.Dockerfile`** (moved from
`operator/Dockerfile`)
- Full source-to-binary build for manual releases
- DockerHub: `datahavenxyz/datahaven:{label}`
- Supports custom RUSTFLAGS and fast-runtime feature
- Only used for manual workflow_dispatch builds
3. **`docker/datahaven-production.Dockerfile`** (kept)
- Binary builder for CPU-specific releases
- Used by build-prod-binary workflow template
- Supports custom target-cpu flags
4. **`docker/datahaven-dev.Dockerfile`** ✨ NEW (local dev only)
- **FOR LOCAL DEVELOPMENT/TROUBLESHOOTING ONLY**
- Includes debug tools: gdb, strace, vim, sudo
- Extra dependencies: librocksdb-dev, curl
- RUST_BACKTRACE enabled by default
- **DO NOT USE for CI or production builds**
5. **`test/docker/crossbuild-mac-libpq.dockerfile`** (kept)
- Utility for macOS → Linux cross-compilation
#### Removed (Redundant):
- ❌ `docker/datahaven.Dockerfile` → replaced by operator/Dockerfile
- ❌ `test/docker/datahaven-node-local.dockerfile` → replaced by
datahaven-dev.Dockerfile
---
### 🔄 Workflow Improvements
#### Enhanced `publish-docker` Template
- Supports both GHCR and DockerHub registries
- Flexible inputs: dockerfile, context, build-args, cache scope
- Auto-generates OCI-compliant labels
- Reduces code duplication (~70 lines → ~15 per workflow)
#### Refactored CI Pipeline
- **`docker-build-ci`**: Builds `operator/Dockerfile` → GHCR for CI/E2E
testing
- **`docker-build-release`**: Builds `operator/Dockerfile` → DockerHub
(main branch only)
- Both CI and release workflows now use the same minimal operator image
- Release builds **reuse CI binaries** instead of rebuilding from source
#### Optimized Release Workflow
The `task-docker-release` workflow now has dual modes:
**Mode 1: `workflow_call` (CI - main pushes)**
- ✅ Reuses binary from CI's build-operator task
- ✅ Uses lightweight `operator/Dockerfile`
- ✅ Tags: `latest`, `sha-{short}`
- ⚡ **Fast**: ~5 minutes (vs ~30 min previously)
**Mode 2: `workflow_dispatch` (Manual)**
- ✅ Full source build with `datahaven-build.Dockerfile`
- ✅ Custom branch and label selection
- ✅ Optional fast-runtime feature
- ✅ Tags: `PROD-{label}` or user-defined
---
### 🔧 Additional Optimizations
- Copy libpq5 from builder stage instead of reinstalling (smaller,
faster)
- Remove redundant protobuf-compiler package (use protoc v21.12
directly)
- Standardize user UID to 1000 across all runtime images
- Consistent OCI labeling and metadata
---------
Co-authored-by: Claude <noreply@anthropic.com>
2025-10-14 23:33:20 +00:00
|
|
|
|
|
|
|
|
# --- Build dependencies using cargo-chef ---
|
|
|
|
|
FROM base AS builder
|
|
|
|
|
WORKDIR /datahaven
|
2025-10-22 11:36:30 +00:00
|
|
|
|
|
|
|
|
COPY . /datahaven
|
refactor: Consolidate and optimize Docker image architecture (#233)
## Overview
This PR consolidates and optimizes the Docker build system, reducing
redundancy and improving CI/CD performance. The changes eliminate
duplicate Dockerfiles, introduce a flexible build template, and optimize
release builds to reuse CI artifacts.
## Changes Summary
### 🐳 Docker Images Restructured
**Before:** 5 Dockerfiles with significant overlap
**After:** 4 focused images + 1 utility
#### Final Structure:
1. **`operator/Dockerfile`** ✨ Updated
- **Standard operator image** for CI and release builds
- Minimal node image (accepts pre-built binaries)
- GHCR: `ghcr.io/datahaven-xyz/datahaven/datahaven` (CI)
- DockerHub: `datahavenxyz/datahaven` (releases)
2. **`docker/datahaven-build.Dockerfile`** (moved from
`operator/Dockerfile`)
- Full source-to-binary build for manual releases
- DockerHub: `datahavenxyz/datahaven:{label}`
- Supports custom RUSTFLAGS and fast-runtime feature
- Only used for manual workflow_dispatch builds
3. **`docker/datahaven-production.Dockerfile`** (kept)
- Binary builder for CPU-specific releases
- Used by build-prod-binary workflow template
- Supports custom target-cpu flags
4. **`docker/datahaven-dev.Dockerfile`** ✨ NEW (local dev only)
- **FOR LOCAL DEVELOPMENT/TROUBLESHOOTING ONLY**
- Includes debug tools: gdb, strace, vim, sudo
- Extra dependencies: librocksdb-dev, curl
- RUST_BACKTRACE enabled by default
- **DO NOT USE for CI or production builds**
5. **`test/docker/crossbuild-mac-libpq.dockerfile`** (kept)
- Utility for macOS → Linux cross-compilation
#### Removed (Redundant):
- ❌ `docker/datahaven.Dockerfile` → replaced by operator/Dockerfile
- ❌ `test/docker/datahaven-node-local.dockerfile` → replaced by
datahaven-dev.Dockerfile
---
### 🔄 Workflow Improvements
#### Enhanced `publish-docker` Template
- Supports both GHCR and DockerHub registries
- Flexible inputs: dockerfile, context, build-args, cache scope
- Auto-generates OCI-compliant labels
- Reduces code duplication (~70 lines → ~15 per workflow)
#### Refactored CI Pipeline
- **`docker-build-ci`**: Builds `operator/Dockerfile` → GHCR for CI/E2E
testing
- **`docker-build-release`**: Builds `operator/Dockerfile` → DockerHub
(main branch only)
- Both CI and release workflows now use the same minimal operator image
- Release builds **reuse CI binaries** instead of rebuilding from source
#### Optimized Release Workflow
The `task-docker-release` workflow now has dual modes:
**Mode 1: `workflow_call` (CI - main pushes)**
- ✅ Reuses binary from CI's build-operator task
- ✅ Uses lightweight `operator/Dockerfile`
- ✅ Tags: `latest`, `sha-{short}`
- ⚡ **Fast**: ~5 minutes (vs ~30 min previously)
**Mode 2: `workflow_dispatch` (Manual)**
- ✅ Full source build with `datahaven-build.Dockerfile`
- ✅ Custom branch and label selection
- ✅ Optional fast-runtime feature
- ✅ Tags: `PROD-{label}` or user-defined
---
### 🔧 Additional Optimizations
- Copy libpq5 from builder stage instead of reinstalling (smaller,
faster)
- Remove redundant protobuf-compiler package (use protoc v21.12
directly)
- Standardize user UID to 1000 across all runtime images
- Consistent OCI labeling and metadata
---------
Co-authored-by: Claude <noreply@anthropic.com>
2025-10-14 23:33:20 +00:00
|
|
|
RUN --mount=type=cache,target=/usr/local/cargo/registry \
|
|
|
|
|
--mount=type=cache,target=/usr/local/cargo/git \
|
|
|
|
|
if [ "$FAST_RUNTIME" = "TRUE" ]; then \
|
|
|
|
|
cargo build --locked --release --features fast-runtime; \
|
|
|
|
|
else \
|
|
|
|
|
cargo build --locked --release; \
|
|
|
|
|
fi
|
|
|
|
|
|
|
|
|
|
# --- Create final lightweight runtime image ---
|
2025-10-22 11:36:30 +00:00
|
|
|
FROM debian:trixie-slim
|
refactor: Consolidate and optimize Docker image architecture (#233)
## Overview
This PR consolidates and optimizes the Docker build system, reducing
redundancy and improving CI/CD performance. The changes eliminate
duplicate Dockerfiles, introduce a flexible build template, and optimize
release builds to reuse CI artifacts.
## Changes Summary
### 🐳 Docker Images Restructured
**Before:** 5 Dockerfiles with significant overlap
**After:** 4 focused images + 1 utility
#### Final Structure:
1. **`operator/Dockerfile`** ✨ Updated
- **Standard operator image** for CI and release builds
- Minimal node image (accepts pre-built binaries)
- GHCR: `ghcr.io/datahaven-xyz/datahaven/datahaven` (CI)
- DockerHub: `datahavenxyz/datahaven` (releases)
2. **`docker/datahaven-build.Dockerfile`** (moved from
`operator/Dockerfile`)
- Full source-to-binary build for manual releases
- DockerHub: `datahavenxyz/datahaven:{label}`
- Supports custom RUSTFLAGS and fast-runtime feature
- Only used for manual workflow_dispatch builds
3. **`docker/datahaven-production.Dockerfile`** (kept)
- Binary builder for CPU-specific releases
- Used by build-prod-binary workflow template
- Supports custom target-cpu flags
4. **`docker/datahaven-dev.Dockerfile`** ✨ NEW (local dev only)
- **FOR LOCAL DEVELOPMENT/TROUBLESHOOTING ONLY**
- Includes debug tools: gdb, strace, vim, sudo
- Extra dependencies: librocksdb-dev, curl
- RUST_BACKTRACE enabled by default
- **DO NOT USE for CI or production builds**
5. **`test/docker/crossbuild-mac-libpq.dockerfile`** (kept)
- Utility for macOS → Linux cross-compilation
#### Removed (Redundant):
- ❌ `docker/datahaven.Dockerfile` → replaced by operator/Dockerfile
- ❌ `test/docker/datahaven-node-local.dockerfile` → replaced by
datahaven-dev.Dockerfile
---
### 🔄 Workflow Improvements
#### Enhanced `publish-docker` Template
- Supports both GHCR and DockerHub registries
- Flexible inputs: dockerfile, context, build-args, cache scope
- Auto-generates OCI-compliant labels
- Reduces code duplication (~70 lines → ~15 per workflow)
#### Refactored CI Pipeline
- **`docker-build-ci`**: Builds `operator/Dockerfile` → GHCR for CI/E2E
testing
- **`docker-build-release`**: Builds `operator/Dockerfile` → DockerHub
(main branch only)
- Both CI and release workflows now use the same minimal operator image
- Release builds **reuse CI binaries** instead of rebuilding from source
#### Optimized Release Workflow
The `task-docker-release` workflow now has dual modes:
**Mode 1: `workflow_call` (CI - main pushes)**
- ✅ Reuses binary from CI's build-operator task
- ✅ Uses lightweight `operator/Dockerfile`
- ✅ Tags: `latest`, `sha-{short}`
- ⚡ **Fast**: ~5 minutes (vs ~30 min previously)
**Mode 2: `workflow_dispatch` (Manual)**
- ✅ Full source build with `datahaven-build.Dockerfile`
- ✅ Custom branch and label selection
- ✅ Optional fast-runtime feature
- ✅ Tags: `PROD-{label}` or user-defined
---
### 🔧 Additional Optimizations
- Copy libpq5 from builder stage instead of reinstalling (smaller,
faster)
- Remove redundant protobuf-compiler package (use protoc v21.12
directly)
- Standardize user UID to 1000 across all runtime images
- Consistent OCI labeling and metadata
---------
Co-authored-by: Claude <noreply@anthropic.com>
2025-10-14 23:33:20 +00:00
|
|
|
COPY --from=builder /datahaven/target/release/datahaven-node /usr/local/bin
|
|
|
|
|
|
|
|
|
|
USER root
|
2025-10-22 11:36:30 +00:00
|
|
|
RUN apt-get update && apt-get install -y gcc libc6-dev libpq-dev && rm -rf /var/lib/apt/lists/*
|
refactor: Consolidate and optimize Docker image architecture (#233)
## Overview
This PR consolidates and optimizes the Docker build system, reducing
redundancy and improving CI/CD performance. The changes eliminate
duplicate Dockerfiles, introduce a flexible build template, and optimize
release builds to reuse CI artifacts.
## Changes Summary
### 🐳 Docker Images Restructured
**Before:** 5 Dockerfiles with significant overlap
**After:** 4 focused images + 1 utility
#### Final Structure:
1. **`operator/Dockerfile`** ✨ Updated
- **Standard operator image** for CI and release builds
- Minimal node image (accepts pre-built binaries)
- GHCR: `ghcr.io/datahaven-xyz/datahaven/datahaven` (CI)
- DockerHub: `datahavenxyz/datahaven` (releases)
2. **`docker/datahaven-build.Dockerfile`** (moved from
`operator/Dockerfile`)
- Full source-to-binary build for manual releases
- DockerHub: `datahavenxyz/datahaven:{label}`
- Supports custom RUSTFLAGS and fast-runtime feature
- Only used for manual workflow_dispatch builds
3. **`docker/datahaven-production.Dockerfile`** (kept)
- Binary builder for CPU-specific releases
- Used by build-prod-binary workflow template
- Supports custom target-cpu flags
4. **`docker/datahaven-dev.Dockerfile`** ✨ NEW (local dev only)
- **FOR LOCAL DEVELOPMENT/TROUBLESHOOTING ONLY**
- Includes debug tools: gdb, strace, vim, sudo
- Extra dependencies: librocksdb-dev, curl
- RUST_BACKTRACE enabled by default
- **DO NOT USE for CI or production builds**
5. **`test/docker/crossbuild-mac-libpq.dockerfile`** (kept)
- Utility for macOS → Linux cross-compilation
#### Removed (Redundant):
- ❌ `docker/datahaven.Dockerfile` → replaced by operator/Dockerfile
- ❌ `test/docker/datahaven-node-local.dockerfile` → replaced by
datahaven-dev.Dockerfile
---
### 🔄 Workflow Improvements
#### Enhanced `publish-docker` Template
- Supports both GHCR and DockerHub registries
- Flexible inputs: dockerfile, context, build-args, cache scope
- Auto-generates OCI-compliant labels
- Reduces code duplication (~70 lines → ~15 per workflow)
#### Refactored CI Pipeline
- **`docker-build-ci`**: Builds `operator/Dockerfile` → GHCR for CI/E2E
testing
- **`docker-build-release`**: Builds `operator/Dockerfile` → DockerHub
(main branch only)
- Both CI and release workflows now use the same minimal operator image
- Release builds **reuse CI binaries** instead of rebuilding from source
#### Optimized Release Workflow
The `task-docker-release` workflow now has dual modes:
**Mode 1: `workflow_call` (CI - main pushes)**
- ✅ Reuses binary from CI's build-operator task
- ✅ Uses lightweight `operator/Dockerfile`
- ✅ Tags: `latest`, `sha-{short}`
- ⚡ **Fast**: ~5 minutes (vs ~30 min previously)
**Mode 2: `workflow_dispatch` (Manual)**
- ✅ Full source build with `datahaven-build.Dockerfile`
- ✅ Custom branch and label selection
- ✅ Optional fast-runtime feature
- ✅ Tags: `PROD-{label}` or user-defined
---
### 🔧 Additional Optimizations
- Copy libpq5 from builder stage instead of reinstalling (smaller,
faster)
- Remove redundant protobuf-compiler package (use protoc v21.12
directly)
- Standardize user UID to 1000 across all runtime images
- Consistent OCI labeling and metadata
---------
Co-authored-by: Claude <noreply@anthropic.com>
2025-10-14 23:33:20 +00:00
|
|
|
RUN useradd -m -u 1001 -U -s /bin/sh -d /datahaven datahaven && \
|
|
|
|
|
mkdir -p /data /datahaven/.local/share && \
|
|
|
|
|
chown -R datahaven:datahaven /data && \
|
|
|
|
|
ln -s /data /datahaven/.local/share/datahaven && \
|
|
|
|
|
/usr/local/bin/datahaven-node --version
|
|
|
|
|
|
|
|
|
|
USER datahaven
|
|
|
|
|
|
2025-10-15 12:46:07 +00:00
|
|
|
EXPOSE 30333 9944 9615
|
refactor: Consolidate and optimize Docker image architecture (#233)
## Overview
This PR consolidates and optimizes the Docker build system, reducing
redundancy and improving CI/CD performance. The changes eliminate
duplicate Dockerfiles, introduce a flexible build template, and optimize
release builds to reuse CI artifacts.
## Changes Summary
### 🐳 Docker Images Restructured
**Before:** 5 Dockerfiles with significant overlap
**After:** 4 focused images + 1 utility
#### Final Structure:
1. **`operator/Dockerfile`** ✨ Updated
- **Standard operator image** for CI and release builds
- Minimal node image (accepts pre-built binaries)
- GHCR: `ghcr.io/datahaven-xyz/datahaven/datahaven` (CI)
- DockerHub: `datahavenxyz/datahaven` (releases)
2. **`docker/datahaven-build.Dockerfile`** (moved from
`operator/Dockerfile`)
- Full source-to-binary build for manual releases
- DockerHub: `datahavenxyz/datahaven:{label}`
- Supports custom RUSTFLAGS and fast-runtime feature
- Only used for manual workflow_dispatch builds
3. **`docker/datahaven-production.Dockerfile`** (kept)
- Binary builder for CPU-specific releases
- Used by build-prod-binary workflow template
- Supports custom target-cpu flags
4. **`docker/datahaven-dev.Dockerfile`** ✨ NEW (local dev only)
- **FOR LOCAL DEVELOPMENT/TROUBLESHOOTING ONLY**
- Includes debug tools: gdb, strace, vim, sudo
- Extra dependencies: librocksdb-dev, curl
- RUST_BACKTRACE enabled by default
- **DO NOT USE for CI or production builds**
5. **`test/docker/crossbuild-mac-libpq.dockerfile`** (kept)
- Utility for macOS → Linux cross-compilation
#### Removed (Redundant):
- ❌ `docker/datahaven.Dockerfile` → replaced by operator/Dockerfile
- ❌ `test/docker/datahaven-node-local.dockerfile` → replaced by
datahaven-dev.Dockerfile
---
### 🔄 Workflow Improvements
#### Enhanced `publish-docker` Template
- Supports both GHCR and DockerHub registries
- Flexible inputs: dockerfile, context, build-args, cache scope
- Auto-generates OCI-compliant labels
- Reduces code duplication (~70 lines → ~15 per workflow)
#### Refactored CI Pipeline
- **`docker-build-ci`**: Builds `operator/Dockerfile` → GHCR for CI/E2E
testing
- **`docker-build-release`**: Builds `operator/Dockerfile` → DockerHub
(main branch only)
- Both CI and release workflows now use the same minimal operator image
- Release builds **reuse CI binaries** instead of rebuilding from source
#### Optimized Release Workflow
The `task-docker-release` workflow now has dual modes:
**Mode 1: `workflow_call` (CI - main pushes)**
- ✅ Reuses binary from CI's build-operator task
- ✅ Uses lightweight `operator/Dockerfile`
- ✅ Tags: `latest`, `sha-{short}`
- ⚡ **Fast**: ~5 minutes (vs ~30 min previously)
**Mode 2: `workflow_dispatch` (Manual)**
- ✅ Full source build with `datahaven-build.Dockerfile`
- ✅ Custom branch and label selection
- ✅ Optional fast-runtime feature
- ✅ Tags: `PROD-{label}` or user-defined
---
### 🔧 Additional Optimizations
- Copy libpq5 from builder stage instead of reinstalling (smaller,
faster)
- Remove redundant protobuf-compiler package (use protoc v21.12
directly)
- Standardize user UID to 1000 across all runtime images
- Consistent OCI labeling and metadata
---------
Co-authored-by: Claude <noreply@anthropic.com>
2025-10-14 23:33:20 +00:00
|
|
|
VOLUME ["/data"]
|
|
|
|
|
|
|
|
|
|
ENTRYPOINT ["/usr/local/bin/datahaven-node"]
|