Files
Myasnikov Daniil ed0297eb87 refactor(build): standardize image tagging to fix concurrent PR push conflicts
Every package Makefile tagged images via `settag` which, on a non-release
commit, collapsed to `:latest`. Concurrent PR builds therefore raced on every
image's `:latest` manifest in the OCIR registry. Two outliers (metallb,
redis-operator) used hardcoded version tags and collided across PRs even when
`settag` would not have.

Replace `settag` and the `TAG=latest` fallback with an `image-tags` macro
driven by three env vars:
  - IMAGE_TAG          — build-unique tag, always pushed
  - PUBLISH_VERSIONED  — also push :<component-version>
  - PUBLISH_FLOATING   — also push :latest

PR CI sets IMAGE_TAG=pr-<N>-<sha> with both PUBLISH_* off, so every push is
unique across runs. Release CI sets IMAGE_TAG=<git-tag> with both PUBLISH_*
on, preserving the previous release output and adding a uniform :<git-tag>
tag across every image. Local builds default to IMAGE_TAG=dev with PUSH=0
already off.

Image consumers reference digests pinned into values.yaml by each Makefile,
so the tag is decorative for cluster-side pulls; the build-unique tag is
sufficient for E2E.

Drops the redundant `:<component-version>-<git-tag>` form (cilium, linstor,
matchbox, ubuntu-container-disk, kubevirt-*, cluster-autoscaler) — nothing
in the repo or downstream values.yaml consumed it. The same information is
preserved via the new uniform `:<git-tag>` plus the existing
`:<component-version>` on release.

ubuntu-container-disk builds a separate image per Kubernetes version in a
loop. Switched its primary tag to `:<k8s-ver>-<IMAGE_TAG>` so loop
iterations within a single build do not push to the same tag.

Assisted-By: Claude <noreply@anthropic.com>
Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
2026-05-21 15:23:18 +05:00
..
2026-04-16 08:50:30 +00:00
2024-08-12 14:47:11 +02:00
2024-07-16 17:31:52 +02:00
2025-09-24 12:32:37 +02:00

Managed Nginx-based HTTP Cache Service

The Nginx-based HTTP caching service is designed to optimize web traffic and enhance web application performance. This service combines custom-built Nginx instances with HAProxy for efficient caching and load balancing.

Deployment information

The Nginx instances include the following modules and features:

  • VTS module for statistics
  • Integration with ip2location
  • Integration with ip2proxy
  • Support for 51Degrees
  • Cache purge functionality

HAproxy plays a vital role in this setup by directing incoming traffic to specific Nginx instances based on a consistent hash calculated from the URL. Each Nginx instance includes a Persistent Volume Claim (PVC) for storing cached content, ensuring fast and reliable access to frequently used resources.

Deployment Details

The deployment architecture is illustrated in the diagram below:


          ┌─────────┐
          │ metallb │ arp announce
          └────┬────┘
               │
               │
       ┌───────▼───────────────────────────┐
       │  kubernetes service               │  node
       │ (externalTrafficPolicy: Local)    │  level
       └──────────┬────────────────────────┘
                  │
                  │
             ┌────▼────┐  ┌─────────┐
             │ haproxy │  │ haproxy │   loadbalancer
             │ (active)│  │ (backup)│      layer
             └────┬────┘  └─────────┘
                  │
                  │ balance uri whole
                  │ hash-type consistent
           ┌──────┴──────┬──────────────┐
       ┌───▼───┐     ┌───▼───┐      ┌───▼───┐ caching
       │ nginx │     │ nginx │      │ nginx │  layer
       └───┬───┘     └───┬───┘      └───┬───┘
           │             │              │
      ┌────┴───────┬─────┴────┬─────────┴──┐
      │            │          │            │
  ┌───▼────┐  ┌────▼───┐  ┌───▼────┐  ┌────▼───┐
  │ origin │  │ origin │  │ origin │  │ origin │
  └────────┘  └────────┘  └────────┘  └────────┘

Known issues

Parameters

Common parameters

Name Description Type Value
size Persistent Volume Claim size available for application data. quantity 10Gi
storageClass StorageClass used to store the data. string ""
external Enable external access from outside the cluster. bool false

Application-specific parameters

Name Description Type Value
endpoints Endpoints configuration, as a list of ip:port. []string []

HAProxy parameters

Name Description Type Value
haproxy HAProxy configuration. object {}
haproxy.replicas Number of HAProxy replicas. int 2
haproxy.resources Explicit CPU and memory configuration. When omitted, the preset defined in resourcesPreset is applied. object {}
haproxy.resources.cpu CPU available to each replica. quantity ""
haproxy.resources.memory Memory (RAM) available to each replica. quantity ""
haproxy.resourcesPreset Default sizing preset used when resources is omitted. string t1.nano

Nginx parameters

Name Description Type Value
nginx Nginx configuration. object {}
nginx.replicas Number of Nginx replicas. int 2
nginx.resources Explicit CPU and memory configuration. When omitted, the preset defined in resourcesPreset is applied. object {}
nginx.resources.cpu CPU available to each replica. quantity ""
nginx.resources.memory Memory (RAM) available to each replica. quantity ""
nginx.resourcesPreset Default sizing preset used when resources is omitted. string t1.nano

Parameter examples and reference

resources and resourcesPreset

resources sets explicit CPU and memory configurations for each replica. When left empty, the preset defined in resourcesPreset is applied.

resources:
  cpu: 4000m
  memory: 4Gi

resourcesPreset sets named CPU and memory configurations for each replica. This setting is ignored if the corresponding resources value is set.

Preset name CPU memory
nano 250m 128Mi
micro 500m 256Mi
small 1 512Mi
medium 1 1Gi
large 2 2Gi
xlarge 4 4Gi
2xlarge 8 8Gi

endpoints

endpoints is a flat list of IP addresses:

endpoints:
  - 10.100.3.1:80
  - 10.100.3.11:80
  - 10.100.3.2:80
  - 10.100.3.12:80
  - 10.100.3.3:80
  - 10.100.3.13:80