ტექნოლოგიები და ინფრასტრუქტურა Docker Compose და Dev გარემოცვა

Docker Compose და Dev გარემო

1) რატომ არის კომპოზიცია

• პარიტეტი გაყიდვით (სურათები, ცვლადები, ქსელები) ნაკლებად „მუშაობს ჩემთან“.
• სწრაფი დასაწყისი დამწყებთათვის არის 'make up' და ბრძოლა.
• დეველოპერის/ფილიალის იზოლირებული სტენდები - პარალელური მუშაობა კონფლიქტების გარეშე.
• ინტეგრაციის ტესტები რეალურ დამოკიდებულებაზე.

2) საცავის ძირითადი სტრუქტურა

project/
docker/
app/      # Dockerfile, скрипты web/      # Nginx/Traefik конфиги seed/      # сидеры/фикстуры compose.yaml       # общий базовый стек compose.override.yaml   # локальные оверрайды (в.gitignore)
compose.ci.yaml      # для CI
.env.example       # шаблон окружения
Makefile         # удобные цели devcontainer.json     # VS Code Dev Containers (опционально)

• compose. yaml - აღწერს „ჩონჩხი“ (სერვისები, ქსელები, ტომი) იგივეა, რაც dev/CI.
• override - მხოლოდ ადგილობრივი რედაქტირება: დირექტორიების მაპინგები, პორტები, debug დროშები.
• .env. example - დეველოპერი ასლებს '.env- ში და ცვლის მნიშვნელობებს.

3) ჩარჩო. yaml (მაგალითი)

yaml name: project services:
gateway:
image: traefik:v3 command:
- "--providers.docker=true"
- "--entrypoints.web.address=:80"
- "--entrypoints.websecure.address=:443"
- "--certificatesresolvers.dev.acme.tlschallenge=true"
ports: ["80:80", "443:443"]
volumes:
- /var/run/docker.sock:/var/run/docker.sock:ro networks: [edge, core]

api:
build:
context:.
dockerfile: docker/app/Dockerfile target: dev env_file: [.env]
command:./scripts/dev-start.sh volumes:
-./:/app:cached depends_on: [db, redis, kafka]
labels:
- "traefik.http.routers.api.rule=Host(`${API_HOST}`)"
- "traefik.http.services.api.loadbalancer.server.port=8080"
networks: [core]

db:
image: postgres:16 environment:
POSTGRES_USER: ${DB_USER}
POSTGRES_PASSWORD: ${DB_PASS}
POSTGRES_DB: ${DB_NAME}
volumes:
- pgdata:/var/lib/postgresql/data healthcheck: {test: ["CMD-SHELL","pg_isready -U $$POSTGRES_USER"], interval: 5s, timeout: 3s, retries: 20}
networks: [core]

redis:
image: redis:7 command: ["redis-server","--appendonly","yes"]
volumes: [ "redisdata:/data" ]
networks: [core]

kafka:
image: bitnami/kafka:3 environment:
KAFKA_ENABLE_KRAFT: "yes"
KAFKA_CFG_PROCESS_ROLES: "controller,broker"
KAFKA_CFG_NODE_ID: 1
KAFKA_CFG_LISTENERS: PLAINTEXT://:9092
KAFKA_CFG_ADVERTISED_LISTENERS: PLAINTEXT://kafka:9092 networks: [core]

mailhog:
image: mailhog/mailhog ports: ["8025:8025"]
networks: [core]

mock-psp:
image: wiremock/wiremock:3 command: ["--verbose","--global-response-templating"]
volumes: ["./docker/mocks/psp:/home/wiremock"]
labels:
- "traefik.http.routers.mockpsp.rule=Host(`${PSP_HOST}`)"
networks: [core]

volumes:
pgdata: {}
redisdata: {}

networks:
edge: {}
core: {}

• Traefik/NGINX, როგორც gateway: უახლოვდება Routing სქემას გაყიდვასთან.
• Healthcheck და depends _ on 'condition: service _ healthy' (v3-ში waiting სკრიპტების საშუალებით) არის შეკვეთილი დასაწყისი.
• Volumes persistence (BD/ქეში) და bind-mount კოდი (ცხელი-reload).

4) პროფილები და რამდენიმე ფაილი

Profiles ('profiles: [dev, ci, extras]') მოიცავს/გამორიცხავს სერვისებს ('docker compose -profile extras up-d').

• `docker compose -f compose. yaml -f compose. dev. yaml up '- კონფიგურაციის შერწყმა.

• `compose. yaml '- ბაზა.
• `compose. dev. yaml '- bind-mounty, debag, icheflagi.
• `compose. extras. yaml '- ინსტრუმენტული (Grafana, pgAdmin, Kafdrop).
• `compose. ci. yaml '- „თავი გრაფიკის გარეშე“, bind-mounts- ის გარეშე.

5) ცვლადი, საიდუმლოებები და პარამეტრები

.env - ცვლადის ზოგადი წყარო: მასპინძლები, ტესტის მონაცემთა ბაზის კრედიტები, დროშები.

• ადგილობრივი dummy საიდუმლოებები (დანამატის გასაღებები),
• ინტეგრაცია skinny-Vault/SOPS- ით განსაკუთრებით მგრძნობიარე.
• პრინციპი: მინიმალური საჭირო მონაცემები. PAN/PII - ნიშნები/ფიქსაცია.

6) შეკრება და სიჩქარე

6. 1 Multi-stage + BuildKit

Dockerfile სამიზნეებით 'base', 'dev', 'medel'; საერთო cache-layer დამოკიდებულებისთვის.
ჩართეთ BuildKit: 'DOCKER _ BUILDKIT = 1' (ან კონფისკაციაში).
ქეშირება: '-mount = ტიპი = cache, target =/root/.cache/...' pip/npm/maven.

6. 2 სწრაფი ციკლი

Bind-mount кода + hot-reload (nodemon, uvicorn --reload, Spring Devtools).
ცალკეული target dev შეკრება მხოლოდ საჭირო.
Makefile цели: `make up`, `make down`, `make logs`, `make rebuild`, `make seed`.

make
ENV?= dev up:
docker compose --profile $(ENV) up -d down:
docker compose down -v logs:
docker compose logs -f --tail=200 rebuild:
DOCKER_BUILDKIT=1 docker compose build --pull --no-cache api seed:
docker compose run --rm api./scripts/seed.sh migrate:
docker compose run --rm api./scripts/migrate.sh test:
docker compose -f compose.yaml -f compose.ci.yaml run --rm api./scripts/test.sh

7) BD, მიგრაცია, სეირნობა

მიგრაცია (Flyway/Liquibase/Alembic/Prisma) იწყება 'db' - ის დაწყების შემდეგ (healthcheck- ის მოლოდინი).
სიდინგი: ცალკეული კონტეინერი 'თესლი' ფიქსირებით; განმეორებითი და idempotent.
მონაცემთა ჭურვები: ტომი 'pgdata' შეგიძლიათ ჩამოაგდოთ/აღადგინოთ 'reset-db სკრიპტით. sh`.

8) ბროკერები, ქეში, CDC

Kafka/Rabbit/Redpanda - როგორც გაყიდვაში (მინიმალური კონფიგურაცია).
Redis ერთად AOF შედის რეალისტიკისთვის.
CDC კონექტორები (სურვილისამებრ): Debezium ცალკეულ სერვისში ანალიტიკოსების ინტეგრაციის ტესტებისთვის.

9) გარე მომწოდებლების Mokes

WireMock/Prism for REST, MockServer რთული სცენარებისთვის.
Mailhog/SMTP4Dev წერილებისთვის.
Localstack/MinIO ღრუბლოვანი სვეტებისა და S3 თავსებადობისთვის.
პოლიტიკა: ყველა გარე PSP/KYC/KMS - პერკუსიის მეშვეობით კონტრაქტებით (OpenAPI) და არა „ინტერნეტით“.

10) საპირისპირო მარიონეტული და TLS

• `api. local. test`, `mockpsp. local. test`.
• TLS: mkcert, ადგილობრივი სანდო სერტიფიკატის გასაცემად, HSTS/Secure-cookies- ის შესამოწმებლად.
• Sticky სესიები მოიცავს მხოლოდ იმ შემთხვევებს, სადაც ეს მართალია.

11) დეველოპერის პროფილები: Node/Python/Java

Node: mount 'node _ modules' როგორც ქეში (volume) ინსტალაციის დაჩქარების მიზნით; 'CHOKIDAR _ USEPOLING = 1' Windows/WSL.
Python: `pip cache` как volume, `watchfiles`/`uvicorn --reload`.
Java: JRebel/Devtools, 'mvn -T 1C-o' + დამოკიდებულების ფენა.

12) ტესტები და ხარისხი

ჩვენ ვატარებთ ინტეგრაციის ტესტებს Compose ქსელის შიგნით: 'docker compose run test'.
Testcontainers (JVM/Node/Python/.NET) არის კარგი ვარიანტი unit ინტეგრაციისთვის სრული დასტის გარეშე.
კონტრაქტის ტესტები მაკა-კით - კარიბჭე CI- ში.
Linters/Pre commit: გაშვება კონტეინერში განმეორებით.

13) მოწყობილობები და „IDE კოდი“

`devcontainer. json 'აფიქსირებს ნაგვის გამოსახულებას (CLI, SDK, ლინტერები), ამონტაჟებს პროექტს, ახდენს' postCreateCommand '- ს.
მოგება: იგივე ინსტრუმენტები, მასპინძლის „დაბინძურება“, ახალი მანქანა - მზად არის წუთში.

14) უსაფრთხოება dev- ში

ოთახის გარეშე განაცხადის სურათებში; 'readOnlyRootFilesystem', როდესაც შესაძლებელია.
არ არსებობს საბრძოლო გასაღებები/საიდუმლოებები, თუნდაც დროებით.
ლოგოები - PII/PAN გარეშე; შენიღბვა ფორმატის დონეზე.
პორტებისა და ქსელების გაჯანსაღება: გარე დაშვება მხოლოდ gateway- ით.

15) FinOps/შესრულება ლოკალში

შეზღუდეთ რესურსები: 'deploy. resources. limits '(კომპოზიცია ნაწილობრივ კითხულობს, მაგრამ ეხმარება დისციპლინას).
შეამცირეთ გულშემატკივარი (ნაკლები ნაგულისხმევი მომსახურება; extras - პროფილები).
Kash BuildKit და volume ქეში პაკეტების მენეჯერებისთვის.

16) CI с Compose

გამოიყენეთ იგივე 'კომპოზიცია. yaml` + `compose. ci. yaml 'bind-mounts- ის გარეშე.
დამოკიდებულების ქეში ჰგავს attachable volumes ჯობებს/ფენებს შორის.
პარალელური ჯობი: 'name:' კომპოზიციაში განსხვავებულია (ან ფილიალის პრეფიქსი) ისე, რომ სტენდები არ კონფლიქტდება.

17) ტრაბლშუტინგი

'docker compose ps '/' logs -f '/' exec' - ძირითადი დიაგნოზი.
შეამოწმეთ DNS კომპონენტის ქსელში (მომსახურება სახელით).
თუ bind-mount „ანელებს“ macOS/Windows - ': cached '/': delegated' ან Mutagen/virtiofs.
Healthcheck არის „მწვანე“, მაგრამ მომსახურება „მკვდარია“: შეამოწმეთ თქვენი მადა და მიგრაციის რიგი.

18) განხორციელების შემოწმების სია

1. ძირითადი დასტის (gateway, app, db, cache, queue) კომპოზიციაში. yaml.
2. ადგილობრივი რედაქტირება - override (v.gitignore).
3..env. example არის სრული და შესაბამისი; 'make bootstrap' ასლის '.env'.
4. Healthchecks და BD/მიგრაციის მოლოდინის სკრიპტი.
5. WireMock/Localstack/MinIO გარე პროვაიდერებისთვის.
6. სიდინგი და მიგრაცია, როგორც ბრძანებები 'make seed/migrate'.
7. BuildKit + multi სცენა, დამოკიდებულების ქეში.
8. Devcontainers/Makefile სწრაფი დაწყებისთვის.
9. პროფილები 'extras' ინსტრუმენტებისთვის (Grafana/pgAdmin/Kafdrop).
10. CI იყენებს იგივე კომპოზიციას (+ ci-override).

19) ანტი შაბლონები

„მონსტრი“ 40 სერვისზე, ყოველთვის დაწყებულია: ჩართეთ პროფილები.
მკაცრად დაფარული პორტები, რომლებიც ეწინააღმდეგებიან დეველოპერებს.
საიდუმლოებები/გასაღებები Git ან '.env. example`.
დამოკიდებულია ტესტების „ინტერნეტზე“ (რეალური PSP/KYC).
Healthcheck/მოლოდინების არარსებობა არის მიგრაციისა და დაწყების რბოლა.
სიდინგის არარსებობა - მფრინავი ინტეგრაციის ტესტები.

20) შედეგი

კომპოზიცია არის განვითარების სიჩქარის ძრავა: ერთი ფაილი აღწერს თქვენს მომსახურების სამყაროს, ხოლო პროფილები/overraids იძლევა მოქნილობას. შეინარჩუნეთ პარიტეტი გაყიდვით, ავტომატურად მოაწყეთ სავარძელი და მიგრაცია, შეინარჩუნეთ ხიდები და TLS „როგორც ბრძოლაში“, დააჩქარეთ BuildKit- ის შეკრება - და მიიღებთ ადგილობრივ გარემოს, რომელშიც მოსახერხებელია მუშაობა, მარტივად ტესტირება და უსაფრთხოდ რეპროდუცირება iGaming/fintech გაყიდვების სცენარები.