GH GambleHub

GitLab CI/CD iGaming პროექტებისთვის

(განყოფილება: ტექნოლოგიები და ინფრასტრუქტურა)

მოკლე რეზიუმე

GitLab CI/CD არის „კონვეიერი“ iGaming პროგრამების, ანალიტიკისა და ML სერვისებისთვის. იგი აერთიანებს: საცავებს, პაემნებს, როგორც კოდს, გარემოსა და უსაფრთხოების მენეჯმენტს, კონტეინერების/პაკეტების საკუთარ რეესტრს, Kubernetes- სა და Terraform- თან ინტეგრაციას, აგრეთვე დაუცველობისა და ლიცენზიების სკანირებას. წარმატების გასაღებია იგივე paypline შაბლონები, efemer ranners, რომელსაც აქვს skale მანქანა, უფლებებისა და საიდუმლოებების მკაცრი მოდელი, GitOps პროცესები და ღირებულების კონტროლი.

1) არქიტექტურა და როლები

GitLab (SaaS ან Self-Managrovals): ჯგუფები/პროექტები, Protected branches/tags, Merge Request Approvals.
Runners: Docker/Kubernetes/Virtual Machine executors. K8s- ში ეფემერული მარაგი მინიმუმამდე ამცირებს გარემოს დრიფტს.
რეგისტრატორები: Container/Package/Dependence Proxy - ძირითადი სურათები და დამოკიდებულებები.
Observability: job logs, job artifacts, pipeline insights, მეტრის ექსპორტი მონიტორინგში.

როლები: დეველოპერები (MR), მეინტრეინერები (approve/release), SecOps (სკანირების პოლიტიკა), Platform/DevOps (რანერები, შაბლონები, GitOps).

2) საფუძვლები '.gitlab-ci. yml ': სტადიები, წესები, დამოკიდებულება

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" ]
პრაქტიკა:
  • 'rules' ფილიალებისთვის/MR/tegs; 'needs' DAG პარალელიზმისთვის; 'artifacts: reports' JUnit/coverage- ისთვის; 'workflow' - ისე, რომ არ დაიწყოს ზედმეტი რაციონი.

3) რანერები და სკეიტი

Kubernetes executor (რეკომენდებულია)

ეფემერული ქვესადგურები, კვოტები CPU/RAM, nodeSelector/taints, საიდუმლოების იზოლაცია.
კეში/არტეფაქტები: ობიექტის საცავი; dependency proxy для NPM/Maven/PyPI/Docker.

Docker executor

მარტივი დასაწყისი; გამოიყენეთ DinD ან Kaniko/BuildKit პრივილეგიების გარეშე შეკრებისთვის.

რჩევები:
  • რანერების ცალკეული აუზები დატვირთვის ტიპების მიხედვით (Build/Test/Security/ML); ჯგუფის/პროექტის შეზღუდვები; რანერების ტეგები ('k8s', 'gpu', 'უსაფრთხოება').

4) კეში, არტეფაქტები და მატრიცები

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

გამოიყენეთ გლობალური dependence proxy ტრეფიკისა და დროის დაზოგვის მიზნით, მატრიქსის split tests, artifacts: expire _ in ჰიგიენისთვის.

5) უსაფრთხოება და შესაბამისობა (Shift-Left)

ტიპიური „უსაფრთხოების ეტაპი“:
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" }

ასევე: DAST სტენდებისთვის, Dependence/License Compliance, სავალდებულო MR-approvals კრიტიკულ findings- ით, ცვლადის შენიღბვა.

6) გარემო, მიმოხილვა აპსი და გამოშვებები

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" ]

Release/Tag pipline: Helm გრაფიკის/არტეფაქტების გამოქვეყნება, გამოცემის ნოტების წარმოება, სურათების ხელმოწერა.

7) Progressive delivery: canary/blue-green

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" ]

დაამატეთ quality gates: SLO latency/error-rate მონიტორინგიდან - რეზოლუცია/გამოტოვება.

8) Parent/Child და მულტიპროექტული piplines

Parent/Child: აჩქარებს დიდ მონორეპოს (თითოეული კომპონენტი არის ბავშვი მილები).

yaml trigger_components:
stage: build trigger:
include: [ "ci/component-a. yml", "ci/component-b. yml" ]
strategy: depend

Multi-Project: „Release“ პროექტი CD- ს მანიფესტის რეპოში (GitOps).

9) GitOps и Terraform/IaC

GitOps MR- ის საშუალებით მანიფესტის საცავში

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) საიდუმლოებები და წვდომა

CI Variables: masked/protected; გაყოფილი წრე/ჯგუფებად.
Protected branches/tags: desplay in studios - მხოლოდ დაცული ფილიალებიდან და სახელმძღვანელო დადასტურებით.
გარე საიდუმლოებები: ინტეგრაცია საიდუმლო მენეჯერთან/HashiCorp Vault (JWT/OIDC), ადრენალებზე დამონტაჟება მხოლოდ დროის განმავლობაში.

11) payplines და SLO დაკვირვება

Pipeline DORA/KPI: lead time, deployment frequency, change fail rate, MTTR.
ინსტრუმენტები: retray/taimauts, 'allow _ failure' არაკონტროლირებადი დავალებებისთვის, კოდის დაფარვის ანგარიში.
მეტრიკის ექსპორტი: სტადიების ხანგრძლივობა, რანერების ჯერი, success ratio; ალერტები ChatOps- ში.

12) FinOps: ღირებულება და შესრულება

Dependency Proxy + Docker დამოკიდებულებისა და ფენების ქეში.
Ranners ტყვიების გამიჯვნა (ML/Security/ML) concurrency limites.
Review Apps- ის ავტომატური პაუზა და არააქტიური მედია; 'artifacts: expire _ in'.
დიდი შეკრებები - spot/freemptable ტყვიებზე; ძირითადი სურათების წინასწარი დათბობა.

13) შაბლონები iGaming შემთხვევებისთვის

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' } ]

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 }

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) განხორციელების სია

1. შეამოწმეთ paypline შაბლონები და Shared Includes ბრძანებებისთვის (lint/test/build/უსაფრთხოება/deploy).
2. განათავსეთ efemer K8s ranners, ჩართეთ dependence proxy, ობიექტის სცენა არტეფაქტებისთვის/ქეში.
3. შეიყვანეთ rules/needs/DAG, მატრიცები და პარალელიზმი.
4. SAST/DAST/Secret/SBOM/License და MR-approvals პარამეტრები პოლიტიკოსებისთვის.
5. მოაწყეთ Environments/Review Apps, ავტო დახურვა და სისუფთავე URL.
6. ჩართეთ GitOps: ცალკეული მანიფესტი-რეპო, MR ბამპის სურათები/ჩარტები.
7. უზრუნველყეთ საიდუმლოების კონტროლი (masked/procected, Vault/OIDC), დაცული branches/tags.
8. დააკავშირეთ Terraform/IaC და „მონიტორინგი, როგორც კოდი“.
9. შეიყვანეთ FinOps პრაქტიკა: რანერების შეზღუდვები, ქეში/მარიონეტული, ექსპირაციული არტეფაქტები, ავტოპაუზა.
10. რეგულარული თამაშის დღე: ჭრილობის ვარდნა, ქეში შევსება, რეესტრის მიუწვდომლობა.

15) ანტიპატერები

ერთი „უნივერსალური“ რანერი იზოლაციისა და კვოტების გარეშე.
Payplines 'rules' გარეშე (ამოქმედებულია „ყოველთვის“), 'needs' (ნელა) გარეშე.
პრივილეგირებული DinD შეკრებები Prod Ranners- ში შეზღუდვების გარეშე.
საიდუმლოებების შენახვა საცავებში/job ლოგოებში.
უსაფრთხოების ეტაპის არარსებობა და MR-approvals.
გაუთავებელი მიმოხილვა Apps 'on _ stop' და 'expire _ in'.
ხელნაკეთი გამოშვებები sublited გარეშე tags.

შედეგები

GitLab CI/CD აძლევს iGaming გუნდებს სწრაფ და პროგნოზირებად გამოშვებებს: ერთჯერადი შაბლონები, რანერების ავტომობილი, მაღალი ხარისხის უსაფრთხოების კარიბჭეები, გარემო და პროგრესული დეპოზიტები, GitOps და Terraform ინტეგრაცია. დაამატეთ დაკვირვება და FinOps - და თქვენი პროგრამები, ETL და ML სერვისები გაიცემა რეგულარულად, უსაფრთხოდ და კონტროლირებადი ღირებულებით.

Contact

დაგვიკავშირდით

დაგვიკავშირდით ნებისმიერი კითხვის ან მხარდაჭერისთვის.ჩვენ ყოველთვის მზად ვართ დაგეხმაროთ!

ინტეგრაციის დაწყება

Email — სავალდებულოა. Telegram ან WhatsApp — სურვილისამებრ.

თქვენი სახელი არასავალდებულო
Email არასავალდებულო
თემა არასავალდებულო
შეტყობინება არასავალდებულო
Telegram არასავალდებულო
@
თუ მიუთითებთ Telegram-ს — ვუპასუხებთ იქაც, დამატებით Email-ზე.
WhatsApp არასავალდებულო
ფორმატი: ქვეყნის კოდი და ნომერი (მაგალითად, +995XXXXXXXXX).

ღილაკზე დაჭერით თქვენ ეთანხმებით თქვენი მონაცემების დამუშავებას.