Құрастыруды оңтайландыру және кэштеу

(Бөлім: Технологиялар және Инфрақұрылым)

Қысқаша түйіндеме

iGaming-тегі CI/CD жылдамдығы релиздердің жиілігіне, минуттардың құнына және ең жоғары жүктемелер кезінде p99 тұрақтылығына тікелей әсер етеді. Кілт - дұрыс кэштер (тәуелділік, артефактілер, контейнерлердің қабаттары, құрастырудың аралық нәтижелері), инкрементальды құрастыру және детерминирлену. «Жақсы» құрастыру өзгеріссіз енгізілген кезде тез қайталанады, ал кэш-мүгедектікті болжауға және бақылауға болады.

1) Кэш картасы және біз қандай кэш жасаймыз

Тәуелділік: NPM/pnpm, pip wheels/Poetry, Maven/Gradle, сән Go, Cargo crates, NuGet.
Аралық құрастыру артефактілері: '~/.cache/pip', '~/.m2', '.gradle', '~/.cargo/registry/',' $GOMODCACHE ',' target/', 'build/',' node _ modules/.pnpm-store '.
Контейнерлік қабаттар: Docker layer cache (BuildKit/GHA cache), registry-based кэш, multi-stage.
Құралдар және SDK: toolchains/микрообраздар (JDK, Node, Python, Rustup targets).
Моно/полирепо-мета: тапсырмалар үшін Nx/Turborepo/Bazel remote-cache кэші (lint/test/build).
Тест-деректер және e2e фикстуралар: снепшоттар БД, жинақталған UI-бандлалар.
ML/деректер: дайындалған датасеттер, эмбеддингтер, құрастырылған қозғалтқыштар (TensorRT/ONNX).

2) Тез және болжамды құрастыру принциптері

1. Детерминация: нұсқаларды (lockfiles), pin негізгі бейнелерді, hermetic плагиндер → ойнатылатын шығарылым.
2. Теңсіздік: бір құрастыру → бірдей артефактілер мен хэштер.
3. Инкременталдығы: тек өзгерген (DAG/needs/matrix/affected).
4. Локальділігі және «жылуы»: раннерлермен/тізілімдегі кэштер, шыңдар алдында жылыту.
5. Айқын мүгедектік: lockfile/конфигурация файлдары және мазмұн хэштері бойынша кэш кілттері.
6. Гигиена: TTL/' expire _ in ', авто-тазарту, кэштер мен артефактілердің өлшемін бақылау.
7. Жеткізу тізбегінің қауіпсіздігі: құпияларға арналған кэш ≠ қоқыс салғыш; SBOM/артефактілердің қолы міндетті болып қалады.

3) Docker/OCI: қайта жинаусыз жылдам бейнелер

Үлгілер

Multi-stage (builder → runtime).
Минималды runtime (distroless/ubi-micro, тек қажетті so/ca-шарттар).
Қабаттардың реті: алдымен сирек өзгеретін (deps), содан кейін код.
'.dockerignore': '.git', тестер/фикстураларды, жергілікті кэштерді болдырмаңыз.
BuildKit: 'cache-from/to' → джобтар мен бұтақтар арасындағы ортақ кэш.

Dockerfile мысалы (Node + pnpm)

dockerfile syntax=docker/dockerfile:1.7
FROM node:20-bookworm AS deps
WORKDIR /app
COPY pnpm-lock.yaml./
RUN corepack enable && pnpm fetch

FROM node:20-bookworm AS builder
WORKDIR /app
COPY --from=deps /root/.cache/pnpm /root/.cache/pnpm
COPY package.json pnpm-lock.yaml./
RUN corepack enable && pnpm install --offline
COPY..
RUN pnpm build

FROM gcr.io/distroless/nodejs20 AS runtime
WORKDIR /app
COPY --from=builder /app/dist./dist
USER 10001
CMD ["dist/server.js"]

BuildKit в CI (GitHub Actions)

yaml
- uses: docker/setup-buildx-action@v3
- uses: actions/cache@v4 with:
path: /tmp/.buildx-cache key: buildx-${{ github.ref }}-${{ github.sha }}
restore-keys: buildx-${{ github.ref }}-
- uses: docker/build-push-action@v6 with:
push: true tags: ${{ env.IMAGE }}
cache-from: type=gha cache-to: type=gha,mode=max

4) Тілдік экожүйелер: не кэштеу және қалай

Java/Kotlin (Maven/Gradle)

Remote cache Gradle, параллелизм, сұралған конфигурация.
Кэш кілті: хэш 'build. gradle[.kts]` + lockfiles + `gradle-wrapper. properties`.
Нысан storage/HTTP-де build cache node жариялау.
Инкременталды жинақтау және пакеттер бойынша тест-split.

yaml
GitLab CI cache:
key: gradle-${CI_COMMIT_REF_SLUG}
paths: [.gradle/caches,.gradle/wrapper ]
script:
-./gradlew --build-cache --parallel build

Node. js (npm/pnpm/yarn)

Жергілікті store кэші ('~/.npm', '~/.cache/pnpm'), lockfile кілті.
Nx/Turborepo remote-cache (S3/Redis) тапсырмалар үшін (lint/test/build).
'turbo run build --cache-dir = .turbo' и «affected» - монорепо үшін режим.

Python (pip/Poetry)

wheels + virtualenv кэші; 'requirements. lock`/`poetry. lock`.
Жеке сатыдағы wheels құрастыру, матрицалар арасында қайта пайдалану.
C-кеңейтімдері үшін - 'pip wheel' + 'auditwheel' builder-бейнеде.

Go

Кэш `GOMODCACHE`, `GOCACHE`; 'GOTOOLCHAIN '/нұсқасын белгілеңіз.
Қадамдарды бөлісіңіз: 'go mod download' → код көшірмесі → 'go build'.
Үлкен монорептер үшін - Bazel/Bazelisk немесе қабат билдімен 'mage'.

Rust

`~/.cargo/registry`, `~/.cargo/git`, `target/`; sccache (қашықтағы/жергілікті).
'Cargo' тармақтары арасында кэшті ортақ пайдалану. lock`.

C/C++

ccache/sccache + жиынтық жалаулары мен SDK нұсқалары бойынша кілт.
Жеке негізгі бейнеге toolchain шығару.

5) Bazel/Nx/Turborepo: тапсырмалар кэши және баған

Bazel remote cache (HTTP/Cloud) - жіберілетін контент; қатаң саңылаусыздық, құмсалғыш.
Nx/Turborepo - тапсырмалар шығыстарының кэші және монорепода «only-affected» орындау.
Мүгедектік: қадамның кіруіне байланысты (файлдар/жалаулар/ауыспалы).

6) Кэшті мүгедектендіру стратегиялары

Кілт = кіріс хэштері: lockfiles, компиляторлар конфигалары, манифесттер.
Жеңіл мүгедектік: 'restore-keys' (GHA )/префикстер (GLCI).
Қатаң мүгедектік: rotate namespace/критикалық өзгерістер кезінде кілт.
Қабаттарды бөлу: deps vs sources - ауыр тәуелділіктерге тиіспей кодты өзгертіңіз.

7) Инкременталды бильдтер мен матрицалар

DAG/needs: тәуелді джобтарды қатар іске қосыңыз, бірізділікті күтпеңіз.
Paths-filter: триггер тек қозғалған компоненттер үшін.
Tests Shard :/seed каталогтары бойынша ұзақтығын теңестіріңіз.
Warm-pool раннерлері: шыңдар алдындағы алдын ала жылытылған бейнелер/кэштер (турнирлер/науқандар).

8) Артефакттар vs кэш: айырмашылығы қандай

Кэш: қайта пайдаланылатын кіру/аралық нәтижелер, «лас» аумақ, TTL қысқа/орташа.
Артефакттар: соңғы жиналыстар (бейнелер, бинарниктер, charts), өзгермейтін, қол қойылған, SBOM.
Ережелер: кэш агрессивті тазартылады, артефактілер релиздер саясаты бойынша сақталады.

9) Бақылау, KPI және FinOps

Метрика (пайплайн/репо бойынша):

Hit-rate кэш (%), Warm-start vs Cold-start time, орташа/медиана кезеңдерінің ұзақтығы.
Cost per pipeline/job, кэш/артефакт өлшемі, өткізу (jobs/hour).
Монореподағы «affected-runs» үлесі өзгеріссіз қайта жинау (waste).

Алерталар:

hit-rate табалдырықтан төмен түсуі, «build image» уақытының өсуі, артефакттарды үрлеу, SLO бойынша қателіктер.

10) Кэш қауіпсіздігі және supply chain

Кэш/артефактілерде ешқандай құпия жоқ; mask vars, құпия сканерлері.
Pin SHA сыртқы actions/plugins, тек сенімді runners.
Контейнерлердің/бинарлардың (cosign), SBOM (CycloneDX/SPDX) қолы және CD-де тексеру.
Оқшаулау: 'dev/stage/prod' үшін бөлек кэш namespace, foreign branches үшін «тек оқу» құқықтары.

11) Практикалық үлгілер

GitHub Actions - тіл + контейнер

yaml name: ci on: [push, pull_request]
concurrency: { group: ${{ github.ref }}, cancel-in-progress: true }
jobs:
build:
runs-on: ubuntu-latest steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4 with: { node-version: '20' }
- uses: actions/cache@v4 with:
path: ~/.cache/pnpm key: pnpm-${{ hashFiles('pnpm-lock.yaml') }}
- run: corepack enable && pnpm i --frozen-lockfile
- run: pnpm build
- uses: docker/build-push-action@v6 with:
tags: ${{ env.IMAGE }}
cache-from: type=gha cache-to: type=gha,mode=max

GitLab CI — Gradle remote cache

yaml variables:
GRADLE_USER_HOME: ".gradle"
cache:
key: gradle-${CI_COMMIT_REF_SLUG}
paths: [.gradle/wrapper,.gradle/caches ]
build:
stage: build script:
-./gradlew --build-cache --no-daemon build artifacts:
paths: [ "build/libs/.jar" ]
expire_in: 3 days

Jenkins — ccache/sccache

groovy pipeline {
agent { label 'cpp' }
environment { CCACHE_DIR = '/cache/ccache' }
stages {
stage('Build') {
steps {
sh 'ccache -M 10G'
sh 'cmake -B build -S. && cmake --build build -j$(nproc)'
}
}
}
post { always { sh 'ccache -s' } }
}

12) ML/деректер: ауыр құрастыруды жылдамдату

Жергілікті NVMe раннерлердегі модельдер/эмбеддингтер/датасеттер кэші; хэш бойынша нұсқалау.
TensorRT/ONNX қозғалтқыштарын релиздік артефактілер ретінде алдын ала жинау; инференсте қайта пайдалану.
Үлкен модельдерге арналған Chunked-артефакттар (splits); TTL және кейінге қалдырылған тазалау.

13) Енгізу чек-парағы

1. lockfiles және негізгі бейнелерді бекітіңіз; BuildKit бағдарламасын қосыңыз.
2. Docker қабаттарын бөліңіз: deps → код; '.dockerignore' дегенді қосыңыз.
3. remote cache (Gradle/Bazel/Nx/Turbo) көтеріңіз; dependency proxy орнатыңыз.
4. lockfile бойынша CI тәуелділік кэшін теңшеңіз; 'paths-filter' деген матрицаларды қосыңыз.
5. Монорепоға инкременталды билдерді және «affected only» енгізіңіз.
6. hit-rate, warm/cold time өлшеңіз, құны; алерттерді қойыңыз.
7. SBOM/қолтаңбасын қосып, кэштегі құпияларды тыйым салыңыз.
8. Ең жоғары релиздер алдында кэштерді жылытыңыз; TTL/retention бағдарламасын реттеңіз.
9. Кэштің және runbooks-тың «кэш сынған» дегенді құжаттаңыз.
10. «Мәңгілік» кэштерді үнемі тазалап, ауыр артефактілерді мұрағаттаңыз.

14) Антипаттерндер

deps орнатқанға дейін жиі өзгеретін қадамдары бар үлкен Dockerfile.
Кілтсіз жалпы «мәңгілік» кэш/TTL → флейка және қоқыс.
Артефактілер мен кэшті араластыру; қолтаңба/SBOM жоқ.
Кэш бар, бірақ қайталанбайды.
Әрбір PR кезінде «барлығына» матрицалары; concurrency жоқ. cancel`.
Жылы кэшсіз және dependency proxy жоқ бірыңғай runner.

Қорытынды

Құрастыруды оңтайландыру - бұл кэштермен, инкрементальдылықпен және детерминділікпен жүйелі жұмыс. Dockerfile дұрыс құрылымы, билдтер үшін remote-cache, dependency proxy және мүгедектік тәртібі жылдам, арзан және қайта шығарылатын конвейерлерді береді. Бақылау мен қауіпсіздік ережелерін қосыңыз - релиздеріңіз жиі, тұрақты және үнемді болады.