jklein
227bcebeb6
Stage 2 of the Fleet migration for minecraft-server. Major bump: runtime behaviour changes (probes, hardening) and the values interface breaks (resource renames, strict schema). Two real bugs first: - The container declared port 35565 while the Service targeted 25565. It only worked because targetPort was numeric. Both are now server.port (25565) and the Service targets the named port. - The download-serverpack init container was guarded by the map .Values.curseforgeServerpack instead of .enabled, so it rendered for every release and silently no-opped on an empty wget URL. Conventions: - Resources renamed to <release>-<chart>-<kind>, templates to <app>.<kind>.yaml. The PVC deliberately keeps its historical name - renaming it would provision a new, empty volume and orphan the worlds. - Probes (liveness/readiness/startup) via the image's own mc-health, so Ready means the server answers a server-list ping. Startup budget 20 min. - Hardened, values-configurable security contexts: non-root uid 1000, read-only root filesystem with an emptyDir at /tmp, all caps dropped. - Resources from values with the limitFactor helper; an unset memory request is derived from the JVM heap so the two cannot drift apart. - Additive env block rendered through tpl, pinned init image, storage class as a value, RCON wiring only when actually enabled. - curseforge/ftb/curseforgeServerpack are now mutually exclusive. - minecraft.version is pinned to the Java line instead of LATEST. - The mc-router auto-discovery annotation is gone; the service type it implicitly switched is now the explicit value server.service.type. Schema pilot (#68): values.schema.json with additionalProperties false on every chart-owned level, rejecting all three known dead keys.
43 lines
2.0 KiB
YAML
43 lines
2.0 KiB
YAML
# Values for the minecraft-server install-test. Kept as close to the real
|
|
# deployments as possible; only what a CI runner cannot provide is overridden.
|
|
#
|
|
# minecraft.version is deliberately NOT set here any more. Since chart 1.0.0 the
|
|
# chart ships a pinned default that belongs to the Java line it publishes (the
|
|
# image tag comes from .Chart.AppVersion, and Java 8 runs Minecraft only up to
|
|
# 1.16.5, 1.18-1.20.4 need Java 17, 1.20.5+ need Java 21). Leaving it unset
|
|
# means the install-test exercises exactly the default a user would get, so a
|
|
# Java line published with a mismatched default version fails CI instead of
|
|
# passing on a CI-only override.
|
|
#
|
|
# server.service.type is not set either: the default is ClusterIP, which is what
|
|
# all three real deployments run (routing is done by the static mappings of the
|
|
# minecraft-router chart). That also keeps CI free of node-port allocation.
|
|
secrets:
|
|
minecraftServerRef: vaults/CI/items/minecraft-server
|
|
|
|
minecraft:
|
|
management:
|
|
# opPlayers deliberately stays at the default (null): the image resolves
|
|
# every name in OPS against the external Playerdb API and aborts the whole
|
|
# startup when a name does not resolve, so any placeholder name would break
|
|
# the install-test and a real name would make CI depend on a third-party
|
|
# lookup.
|
|
maxPlayers: 2
|
|
resources:
|
|
# The production 32Gi world volume is backed by a static hostPath PV in CI
|
|
# (see fixtures.yaml); 2Gi is plenty for a server that only has to boot.
|
|
storage: 2Gi
|
|
# JVM heap. 1G instead of 4G keeps the runner comfortable - and since chart
|
|
# 1.0.0 this also drives the container's memory request (1Gi) and, via
|
|
# limitFactor 3, its limit (3Gi), so the runner is not asked for the
|
|
# production-sized 4Gi/12Gi any more.
|
|
memory: "1"
|
|
|
|
server:
|
|
resources:
|
|
requests:
|
|
# The production default is 2 CPUs, which would not leave much room on a
|
|
# 4-vCPU GitHub runner alongside the k3d control plane. Since chart 1.0.0
|
|
# this is configurable instead of hardcoded in the template.
|
|
cpu: "500m"
|