GitLab CI/CD dla projektów iGaming
(Sekcja: Technologia i infrastruktura)
Krótkie podsumowanie
GitLab CI/CD to rurociąg dostawy dla aplikacji iGaming, analityki i usług ML. Łączy w sobie: repozytorium, rurociągi jako kod, zarządzanie środowiskiem i bezpieczeństwem, własny rejestr kontenerów/pakietów, integracje z Kubernetes i Terraform, a także wrażliwość i skanowanie licencji. Kluczem do sukcesu są te same szablony rurociągów, efemeryczne biegacze z autoskalą, ścisły model praw i tajemnic, procesy GitOps i kontrola kosztów.
1) Architektura i role
GitLab (SaaS lub Self-Managed): grupy/projekty, Protected branches/tags, Merge Request Approvals.
Biegacze: Docker/Kubernetes/Wirtualna maszyna wykonawców. Efemeryczne słuchy w K8s minimalizują średnie dryfowanie.
Rejestry: Container/Package/Dependency Proxy - cache base images and dependencies.
Obserwowalność: dzienniki pracy, artefakty pracy, wgląd w rurociągi, wskaźniki eksportu do monitoringu.
Role: deweloperzy (MR), opiekunowie (approve/release), SecOps (polityka skanowania), Platforma/DevOp (runners, templates, GitOps).
2) Podstawy ".gitlab-ci. yml': fazy, zasady, ograniczenia
yaml stages: [lint, test, build, security, package, deploy]
variables:
DOCKER_DRIVER: overlay2
IMAGE: "$CI_REGISTRY_IMAGE/app:$CI_COMMIT_SHA"
workflow:
rules:
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
.default:
image: alpine:3. 20 before_script: [ 'apk add --no-cache bash curl jq' ]
lint:
stage: lint script: [ "make lint" ]
rules: [ { if: '$CI_PIPELINE_SOURCE == "merge_request_event"' } ]
unit:
stage: test script: [ "make test" ]
artifacts:
when: always reports: { junit: "reports/junit. xml" }
needs: [ "lint" ]
build_image:
stage: build image: docker:27 services: [ 'docker:27-dind' ]
variables: { DOCKER_TLS_CERTDIR: "" }
script:
- docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
- docker build -t $IMAGE.
- docker push $IMAGE cache:
key: "docker-${CI_COMMIT_REF_SLUG}"
paths: [ "/var/lib/docker" ]
policy: pull-push needs: [ "unit" ]
Praktyki:
- „rule” dla oddziałów/MR/tags; „needs” dla równoległości DAG; „artefakty: sprawozdania” dla JUnit/coverage; „przepływ robót” - aby nie prowadzić zbędnych rurociągów.
3) Biegacze i automatyczna skala
Wykonawca Kubernetes (zalecany)
Efemeryczne strąki, kontyngenty CPU/RAM, nodeSelector/tains, tajna izolacja.
Pamięć podręczna/artefakty: przechowywanie obiektów; proxy zależność дла NPM/Maven/PyPI/Docker.
Wykonawca Docker
Prosty start; używać DinD lub Kaniko/Kit do budowania bez uprawnień.
Wskazówki:- Oddzielne baseny z podziałem na typy obciążeń (Build/Test/Security/ML); limity współistnienia na grupę/projekt; tagi runner ('k8s',' gpu ',' security ').
4) Pamięć podręczna, artefakty i matryce
yaml cache:
key: "pip-${CI_COMMIT_REF_SLUG}"
paths: [ "venv/", ".cache/pip/" ]
policy: pull-push
test:py:
stage: test parallel:
matrix:
- PY: ["3. 10", "3. 12"]
image: python:${PY}
script:
- python -m venv venv &&. venv/bin/activate
- pip install -r requirements. txt
- pytest -q
Użyj globalnego serwera proxy zależności, aby zaoszczędzić ruch i czas, podzielić testy według matrycy, artifacts:expire_in dla higieny.
5) Bezpieczeństwo i zgodność (Shift-Left)
Typowy „etap bezpieczeństwa”:yaml sast:
stage: security image: registry. gitlab. com/security-products/sast:latest script: [ "analyzer run" ]
artifacts: { reports: { sast: "gl-sast-report. json" } }
rules: [ { if: '$CI_PIPELINE_SOURCE == "merge_request_event"' } ]
secret_detection:
stage: security image: registry. gitlab. com/security-products/secret-detection:latest script: [ "analyzer run" ]
artifacts: { reports: { secret_detection: "gl-secret-report. json" } }
sbom:
stage: security image: alpine:3. 20 script:
- apk add syft cosign
- syft $IMAGE -o cyclonedx-json > sbom. json
- cosign sign --key $COSIGN_KEY $IMAGE artifacts:
reports: { cyclonedx: "sbom. json" }
Również: DAST dla stoisk, zależność/zgodność licencji, obowiązkowe aprobaty MR dla krytycznych ustaleń, zmienne maskujące.
6) Środowiska, przeglądy aplikacji i wersji
yaml review:
stage: deploy image: bitnami/kubectl environment:
name: review/$CI_COMMIT_REF_SLUG url: https://$CI_COMMIT_REF_SLUG. apps. example. com on_stop: stop_review script:
-./deploy. sh --env=review --image=$IMAGE rules: [ { if: '$CI_PIPELINE_SOURCE == "merge_request_event"' } ]
stop_review:
stage: deploy when: manual environment:
name: review/$CI_COMMIT_REF_SLUG action: stop script: [ "./deploy. sh --env=review --delete" ]
Rurociąg Release/Tag: publikowanie map Helm/artefaktów, generowanie notatek, podpisywanie obrazów.
7) Stopniowa dostawa: kanaryjski/niebiesko-zielony
yaml deploy_canary:
stage: deploy script: [ "./helm_upgrade. sh --set canary. weight=10 --image=$IMAGE" ]
environment: { name: production }
rules: [ { if: '$CI_COMMIT_TAG' } ]
promote_100:
stage: deploy when: manual script: [ "./helm_upgrade. sh --set canary. weight=100" ]
needs: [ "deploy_canary" ]
Dodaj bramy jakości: opóźnienie SLO/wskaźnik błędów z monitoringu → rozdzielczość/rolka.
8) Rurociągi rodzicielskie/dziecięce i wielofunkcyjne
Rodzic/dziecko: przyspieszyć duże monorepos (każdy składnik jest rurociągiem dla dzieci).
yaml trigger_components:
stage: build trigger:
include: [ "ci/component-a. yml", "ci/component-b. yml" ]
strategy: depend
Multi-Project: Projekt „Release” uruchamia płytę CD do manifestowania repo (GitOps).
9) GitOps, Terraform/IaC
GitOps za pośrednictwem MR do manifestowania repozytorium
yaml gitops_bump:
stage: deploy image: alpine/git script:
- git clone $MANIFESTS_REPO manifests
- yq -i '.image = env(IMAGE)' manifests/apps/app/values. yaml
- cd manifests && git commit -am "bump $CI_COMMIT_SHA" && git push origin HEAD:$TARGET_BRANCH
Terraform ма CI
yaml terraform:
stage: deploy image: hashicorp/terraform:1. 9 script:
- terraform init -backend-config="bucket=$TF_BUCKET"
- terraform plan -out tfplan
- terraform apply -auto-approve tfplan rules: [ { if: '$CI_COMMIT_BRANCH == "infra"'} ]
10) Tajemnice i dostęp
CI Zmienne: maskowane/chronione; oddzielnie według środowiska/grupy.
Chronione gałęzie/tagi: zwolnienie w prod - tylko z gałęzi chronionych i z ręcznym potwierdzeniem.
Tajemnice zewnętrzne: integracja z Secrets Manager/HashiCorp Vault (JWT/OIDC), montaż na biegaczach tylko na czas trwania zadania.
11) Obserwowalność rurociągu i SLO
Rurociąg DORA/KPI: czas realizacji, częstotliwość wdrażania, szybkość zmiany awarii, MTTR.
Narzędzia: przekaźniki/timeouts, „allow _ failure” dla zadań niezablokowanych, raport pokrycia kodu.
Metryka eksportu: czas trwania etapów, kolejka biegaczy, stosunek sukcesu; wpisy w ChatOps.
12) FinOps: koszt i wydajność
Zależność Proxy + Zależność Dockera i pamięć podręczna warstwy.
Split runner pools (prod/security/ML) z ograniczeniami współistnienia.
Automatyczne wstrzymywanie przeglądania aplikacji i nieaktywnych środowisk; „artefakty: wygasają _ w”.
Duże zespoły - na miejscu/prefabrykowane baseny; wstępne ogrzewanie obrazów podstawowych.
13) Szablony dla przypadków iGaming
Usługa Backend/API
yaml include: [ "ci/includes/security. yml", "ci/includes/docker. yml" ]
deploy_prod:
stage: deploy environment: { name: production, url: https://api. example. com }
script: [ "./helm_upgrade. sh --env=prod --image=$IMAGE" ]
rules: [ { if: '$CI_COMMIT_TAG' } ]
Model ETL/DBT
yaml dbt_run:
stage: build image: ghcr. io/dbt-labs/dbt-snowflake:latest script: [ "dbt deps", "dbt run --profiles-dir. ", "dbt test" ]
artifacts: { paths: [ "target/" ], expire_in: 3 days }
Artefakt <> ML/LLM
yaml ml_pack:
stage: package image: nvidia/cuda:12. 1. 0-runtime-ubuntu22. 04 tags: [ "gpu" ]
script:
- python export_onnx. py
- trtexec --onnx=model. onnx --saveEngine=model. plan artifacts: { paths: [ "model. plan", "model. onnx" ] }
14) Lista kontrolna wdrażania
1. Zdefiniuj rurociągi i udostępnij Zawiera wzory dla poleceń (lint/test/build/security/deploy).
2. Uruchamianie efemerycznych uruchomionych K8s, włączanie proxy zależności, przechowywanie obiektów dla artefaktów/pamięci podręcznej.
3. Wprowadź zasady/potrzeby/DAG, matryce i współistnienie.
4. Konfiguracja SAST/DAST/Secret/SBOM/Licencja i aprobaty MR według zasad.
5. Organizuj środowiska/Przeglądaj aplikacje, automatycznie zamknij i schludne adresy URL.
6. Zawiera GitOps: samodzielny manifest repo, MR-bump wygląda/wykresy.
7. Zapewnij tajne zarządzanie (maskowane/chronione, skarbiec/OIDC), chronione gałęzie/tagi.
8. Podłącz Terraform/IaC i „monitor jako kod”.
9. Wprowadź praktyki FinOps: limity biegacza, pamięć podręczną/serwer proxy, artefakty wygasające, stoiska automatycznej przerwy.
10. Regularne dni gry: runner drop, cache fill, rejestr niedostępność.
15) Antypattery
Jeden „uniwersalny” biegacz bez izolacji i kwot.
Rurociągi bez „reguł” (uruchom „zawsze”), bez „potrzeb” (powoli).
Uprzywilejowany DinD buduje w nieograniczonych operatorów produkcji.
Przechowywanie tajemnic w repozytorium/dziennikach zadań.
Brak etapu bezpieczeństwa i zatwierdzenia przez pana posła.
Nieskończone aplikacje przeglądające bez 'on _ stop' i 'expire _ in'.
Ręczne wydania w prod bez chronionych znaczników.
Podsumowanie
GitLab CI/CD daje zespołom iGaming szybkie i przewidywalne wydania: jednolite szablony, auto-skale runners, wysokiej jakości bramy bezpieczeństwa, środowiska i progresywne wdrożeń, GitOps i integracja Terraform. Dodaj obserwowalność i FinOps - a Twoje aplikacje, usługi ETL i ML będą regularnie, bezpiecznie i po kontrolowanych kosztach.