How to Use Kubernetes as a Config Center and Auto‑Generate Dockerfiles

Comparison of Config Center Approaches

Learning cost : Independent config center requires ops to learn setup/maintenance and developers to learn the tool; k8s only needs YAML/JSON knowledge and developers just read environment variables.

Adaptation effort : Independent center needs code changes and library management; k8s services can directly parse environment variables via ConfigMap or Secret.

Cluster maintenance cost : Independent center adds extra overhead; k8s only requires a stable etcd.

Service discovery : Supported by both.

Cloud resource cost : Independent adds cost; k8s adds none.

Environment Variable Strategy

To avoid cumbersome definitions, the service first checks if an environment variable provides a value; if not, it falls back to the default defined in code. This override mechanism can be driven by environment variables or an optional override file, allowing seamless switching between local development and container runtime.

Automatic Dockerfile Generation

The workflow separates build and runtime images. A makefile handles compilation, while a templated Dockerfile is generated automatically. Build images contain the compiler (e.g., golang:1.20-buster), and runtime images use minimal bases such as distroless/static-debian11 to keep size small (~20 MB).

package global

import (
    "github.com/kunlun-qilian/conflogger"
    "github.com/kunlun-qilian/confserver"
    "github.com/kunlun-qilian/confx"
)

func init() {
    confx.SetConfX("demo-docker", "..")
    confx.ConfP(&Config)
}

var Config = struct {
    Logger  *conflogger.Log
    Server  *confserver.Server
    TestEnv string `env:""`
}{
    Server: &confserver.Server{Port: 80, Mode: "debug"},
    TestEnv: "123",
}

The confx library injects environment variables and generates a default config/default.yml file. Variables follow the SERVICE__VAR_NAME convention (e.g., DEMO_DOCKER__TestEnv).

Local overrides are placed in config/local.yml (git‑ignored). Runtime overrides can also be supplied via exported environment variables, e.g.:

export DEMO_DOCKER__TestEnv=terminal_789 && go run main.go

The automatically generated Dockerfile looks like:

FROM dockerproxy.com/library/golang:1.20-buster AS build-env
FROM build-env AS builder
WORKDIR /go/src
COPY ./ ./
RUN make build WORKSPACE=demo-docker
FROM gcr.dockerproxy.com/distroless/static-debian11
COPY --from=builder /go/src/cmd/demo-docker/demo-docker /go/bin/demo-docker
EXPOSE 80
ARG PROJECT_NAME
ARG PROJECT_VERSION
ENV PROJECT_NAME=${PROJECT_NAME} PROJECT_VERSION=${PROJECT_VERSION}
WORKDIR /go/bin
ENTRYPOINT ["/go/bin/demo-docker"]

When multiple ports are needed, adding a field with the env:"opt,expose" tag causes the generator to emit additional EXPOSE statements.