Bulutli infratuzilmalar va Konteynerlashtirish(Cloud & Containerization)

Cloud & containerization ichiga quyidagilar kiradi: Docker for Java apps, multi-stage builds, Kubernetes basics, health probes, graceful shutdown, 12-factor app principles, cloud-native config, Spring Cloud Config.

1. Cloud & containerization nima?

Cloud & containerization — Java/Spring Boot ilovani serverga qo‘lda ko‘chirish emas, uni container qilib, cloud yoki Kubernetes muhitida barqaror ishlatish san’ati.

Oddiy qilib:

Java app yozildi
 ↓
Docker image qilindi
 ↓
Registry’ga push qilindi
 ↓
Kubernetes/Cloud’da deploy qilindi
 ↓
Monitoring, health check, scaling, config bilan boshqarildi

Senior Java developer faqat kod yozmaydi. U ilova production’da qanday ishlashini ham tushunadi:

• app qanday build bo‘ladi;

• image hajmi qancha;

• container ichida JVM qanday ishlaydi;

• memory limit qanday beriladi;

• shutdown paytida requestlar yo‘qolmaydimi;

• health check to‘g‘rimi;

• config qayerdan keladi;

• secretlar qayerda saqlanadi;

• app scale bo‘lganda muammo chiqmaydimi.

2. Docker nima?

Docker — ilovani barcha dependency’lari bilan birga paketlab, bir xil muhitda ishlatish imkonini beradigan container platforma.

Docker bo‘lmasa:

Developer laptopida ishlaydi
Serverda ishlamaydi

Docker bilan:

Image bir xil
Container bir xil
Muhit bir xil

Java app uchun Docker image ichida odatda:

JRE/JDK
application.jar
environment config
start command

bo‘ladi.

3. Image va container farqi

Docker image

Image — tayyor template.

Masalan:

my-app:1.0.0

Bu hali ishlamayapti. Faqat paket.

Docker container

Container — image’dan ishga tushgan real process.

docker run my-app:1.0.0

Bitta image’dan bir nechta container ishlatish mumkin:

my-app:1.0.0
 ├── container 1
 ├── container 2
 └── container 3

4. Java app uchun oddiy Dockerfile

Masalan Spring Boot app bor:

target/app.jar

Oddiy Dockerfile:

FROM eclipse-temurin:21-jre

WORKDIR /app

COPY target/app.jar app.jar

EXPOSE 8080

ENTRYPOINT ["java", "-jar", "app.jar"]

Bu ishlaydi, lekin senior darajada hali yetarli emas.

Kamchiliklari:

• image hajmi katta bo‘lishi mumkin;

• build va runtime ajratilmagan;

• non-root user yo‘q;

• JVM container memory sozlamalari yo‘q;

• layer cache optimal emas.

5. Multi-stage build

Multi-stage build — bitta Dockerfile ichida build qilish va runtime image’ni alohida qilish.

Maqsad:

Build uchun Maven/JDK kerak
Runtime uchun faqat JRE va jar yetarli

Maven bilan misol

FROM maven:3.9-eclipse-temurin-21 AS build

WORKDIR /build

COPY pom.xml .
COPY src ./src

RUN mvn clean package -DskipTests


FROM eclipse-temurin:21-jre

WORKDIR /app

COPY --from=build /build/target/*.jar app.jar

EXPOSE 8080

ENTRYPOINT ["java", "-jar", "app.jar"]

Bu yerda:

1-stage: build
2-stage: runtime

Final image ichida Maven ham, source code ham bo‘lmaydi.

6. Productionga yaqin Dockerfile

Senior yondashuvda quyidagilar qo‘shiladi:

• non-root user;

• JVM options env orqali;

• health check tashqi platformaga qoldiriladi yoki minimal beriladi;

• image kichikroq bo‘ladi;

• predictable entrypoint bo‘ladi.

FROM eclipse-temurin:21-jre

WORKDIR /app

RUN addgroup --system app && adduser --system --ingroup app app

COPY target/app.jar app.jar

USER app

EXPOSE 8080

ENV JAVA_OPTS=""

ENTRYPOINT ["sh", "-c", "java $JAVA_OPTS -jar app.jar"]

Nega USER app kerak?

Container root bo‘lib ishlasa, xavfsizlik riski oshadi. Agar container ichida exploit bo‘lsa, root permission bilan ishlashi mumkin.

7. JVM va container memory

Java eski davrda container limitlarini har doim to‘g‘ri tushunmasdi. Hozirgi Java 17/21 container-aware, lekin baribir JVM memory’ni tushunish kerak.

Containerga limit beriladi:

resources:
  limits:
    memory: "512Mi"

Agar JVM noto‘g‘ri sozlansa:

Container memory limit: 512 MB
JVM heap: 512 MB
Metaspace/native/thread stack ham memory yeydi
Natija: OOMKilled

Shuning uchun heap container memory’dan kichikroq bo‘lishi kerak.

Misol:

JAVA_OPTS="-XX:MaxRAMPercentage=70"

Bu JVMga container memory’ning taxminan 70% qismini heap uchun ishlatishni aytadi.

Yana misol:

JAVA_OPTS="-Xms256m -Xmx512m"

Lekin Kubernetes’da dinamik muhitda MaxRAMPercentage ko‘pincha qulayroq.

8. Docker Compose

Localda bir nechta servisni ko‘tarish uchun Docker Compose ishlatiladi.

Masalan:

services:
  app:
    build: .
    ports:
      - "8080:8080"
    environment:
      DB_URL: jdbc:postgresql://postgres:5432/appdb
      DB_USERNAME: app
      DB_PASSWORD: secret
    depends_on:
      - postgres

  postgres:
    image: postgres:16
    environment:
      POSTGRES_DB: appdb
      POSTGRES_USER: app
      POSTGRES_PASSWORD: secret
    ports:
      - "5432:5432"

Bu local development uchun yaxshi:

Spring Boot app + PostgreSQL

Lekin production uchun depends_on yetarli emas. App database tayyor bo‘lishini retry bilan kutishi kerak.

9. Container ichida log

Container’da log file’ga yozishdan ko‘ra stdout/stderr ishlatish yaxshi.

Yaxshi:

app log → stdout → Docker/Kubernetes → log collector

Yomon:

/app/logs/app.log

Chunki container o‘chsa, log yo‘qolishi mumkin. Productionda loglar odatda:

• stdout;

• Fluent Bit;

• Logstash;

• Loki;

• Elasticsearch;

• Cloud logging;

orqali yig‘iladi.

10. Kubernetes nima?

Kubernetes — containerlarni deploy qilish, scale qilish, restart qilish va boshqarish platformasi.

Docker bitta container ishlatadi.

Kubernetes esa katta tizimni boshqaradi:

Deployment
Service
Pod
ConfigMap
Secret
Ingress
Volume
Horizontal Pod Autoscaler

11. Kubernetes asosiy tushunchalari

11.1. Pod

Pod — Kubernetes’dagi eng kichik deploy unit.

Odatda bitta Spring Boot app bitta pod ichida ishlaydi.

Pod
 └── container: spring-boot-app

Pod o‘chishi va qayta yaratilishi mumkin. Shuning uchun pod ichiga doimiy file saqlash noto‘g‘ri.

11.2. Deployment

Deployment — podlarni boshqaradi.

Masalan:

3 replica kerak

Agar bitta pod o‘lsa, Deployment yangisini yaratadi.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-service
spec:
  replicas: 3
  selector:
    matchLabels:
      app: order-service
  template:
    metadata:
      labels:
        app: order-service
    spec:
      containers:
        - name: order-service
          image: registry.example.com/order-service:1.0.0
          ports:
            - containerPort: 8080

11.3. Service

Podlar o‘zgaruvchan. Bugun IP bitta, ertaga boshqa.

Service podlarga stable network endpoint beradi.

apiVersion: v1
kind: Service
metadata:
  name: order-service
spec:
  selector:
    app: order-service
  ports:
    - port: 80
      targetPort: 8080

Endi boshqa servis shunday chaqiradi:

http://order-service

Pod IP bilishi shart emas.

11.4. Ingress

Ingress tashqi trafikni ichki service’larga yo‘naltiradi.

https://api.example.com/orders → order-service
https://api.example.com/users  → user-service

Ingress odatda NGINX Ingress, Traefik yoki cloud load balancer bilan ishlaydi.

12. ConfigMap

ConfigMap — maxfiy bo‘lmagan configuration qiymatlarini saqlash uchun.

Masalan:

apiVersion: v1
kind: ConfigMap
metadata:
  name: order-config
data:
  SPRING_PROFILES_ACTIVE: prod
  ORDER_PAGE_SIZE: "50"

Deployment’da ishlatish:

envFrom:
  - configMapRef:
      name: order-config

ConfigMap ichida quyidagilar bo‘lishi mumkin:

• profile;

• feature flag;

• external service URL;

• page size;

• timeout qiymatlari.

Lekin parol, token, private key ConfigMap’da saqlanmaydi.

13. Secret

Secret — maxfiy qiymatlar uchun.

apiVersion: v1
kind: Secret
metadata:
  name: order-secret
type: Opaque
stringData:
  DB_PASSWORD: super-secret-password
  JWT_SECRET: very-secret-key

Deployment:

envFrom:
  - secretRef:
      name: order-secret

Muhim:

Kubernetes Secret default holatda faqat Base64 encoded. Bu encryption degani emas. Productionda etcd encryption, RBAC, external secret manager kerak.

Yaxshiroq variantlar:

• HashiCorp Vault;

• AWS Secrets Manager;

• GCP Secret Manager;

• Azure Key Vault;

• External Secrets Operator;

• Sealed Secrets.

14. Health probes

Kubernetes app sog‘lommi yoki yo‘qligini probe orqali tekshiradi.

Spring Boot Actuator bilan odatda:

/actuator/health/liveness
/actuator/health/readiness

ishlatiladi.

14.1. Liveness probe

Liveness — app tirikmi?

Agar liveness fail bo‘lsa, Kubernetes podni restart qiladi.

livenessProbe:
  httpGet:
    path: /actuator/health/liveness
    port: 8080
  initialDelaySeconds: 30
  periodSeconds: 10

Liveness ichida DB tekshirish ko‘pincha xato. DB vaqtincha sekinlashsa, hamma podlar restart bo‘lib, muammo kattalashadi.

Liveness faqat app process osilib qolmaganini tekshirishi kerak.

14.2. Readiness probe

Readiness — app trafik qabul qilishga tayyormi?

Agar readiness fail bo‘lsa, Kubernetes podni service traffic’dan chiqaradi.

readinessProbe:
  httpGet:
    path: /actuator/health/readiness
    port: 8080
  initialDelaySeconds: 20
  periodSeconds: 5

Readiness ichida quyidagilar tekshirilishi mumkin:

• DB connection;

• required external dependency;

• migration tugaganmi;

• app warmed up bo‘lganmi.

14.3. Startup probe

Agar app sekin start bo‘lsa, startup probe ishlatiladi.

startupProbe:
  httpGet:
    path: /actuator/health/liveness
    port: 8080
  failureThreshold: 30
  periodSeconds: 10

Bu Spring Boot app katta bo‘lsa foydali.

15. Graceful shutdown

Graceful shutdown — pod o‘chirilayotganda app requestlarni to‘satdan uzib tashlamasligi.

Yomon holat:

Kubernetes podni o‘chiradi
 ↓
O‘rtadagi request uziladi
 ↓
User error oladi
 ↓
Transaction yarimta qolishi mumkin

Yaxshi holat:

Pod termination signal oladi
 ↓
Readiness false bo‘ladi
 ↓
Yangi request kelmaydi
 ↓
Eski requestlar tugaydi
 ↓
App toza yopiladi

Spring Boot config:

server:
  shutdown: graceful

spring:
  lifecycle:
    timeout-per-shutdown-phase: 30s

Kubernetes:

terminationGracePeriodSeconds: 40

Bu qiymat Spring’dagi shutdown timeoutdan kattaroq bo‘lishi kerak.

16. Resource requests va limits

Kubernetes’da har container uchun CPU/RAM beriladi.

resources:
  requests:
    cpu: "250m"
    memory: "512Mi"
  limits:
    cpu: "1000m"
    memory: "1Gi"

requests

Pod scheduler uchun minimal kerakli resurs.

Menga kamida 512Mi memory kerak

limits

Container ishlatishi mumkin bo‘lgan maksimal resurs.

1Gi’dan oshsa kill qilinadi

Java uchun memory limit juda muhim. Limit juda past bo‘lsa:

OOMKilled

bo‘ladi.

17. CPU limit va Java

Java app uchun CPU limit ham ehtiyotkorlik bilan qo‘yiladi.

Agar CPU limit juda qattiq bo‘lsa:

• GC sekinlashadi;

• latency oshadi;

• thread scheduling yomonlashadi;

• timeoutlar ko‘payadi.

Masalan:

limits:
  cpu: "500m"

Bu yarim CPU degani. Katta Spring Boot app uchun yetmasligi mumkin.

Senior yondashuv:

requests real usage asosida
limits ehtiyotkorlik bilan
monitoring orqali sozlash

18. Horizontal scaling

Agar traffic oshsa, podlar sonini ko‘paytirish mumkin.

kubectl scale deployment order-service --replicas=5

Yoki HPA:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: order-service-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: order-service
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

HPA CPU 70% dan oshsa replica sonini oshiradi.

Lekin hamma app oson scale bo‘lmaydi.

Scale qilish uchun app:

• stateless bo‘lishi;

• sessionni local memoryda saqlamasligi;

• file’ni pod ichida saqlamasligi;

• distributed lockga ehtiyot bo‘lishi;

• DB connection poolni nazorat qilishi kerak.

19. Stateless design

Cloud-native app imkon qadar stateless bo‘lishi kerak.

Yomon:

User session pod memorysida saqlanadi
Uploaded file pod diskiga yoziladi
Cache faqat local memoryda

Agar pod o‘chsa:

session/file/cache yo‘qoladi

Yaxshi:

Session → Redis yoki JWT
File → S3/MinIO
Cache → Redis/Caffeine + reload strategy
State → Database

Stateless app scale qilishga qulay.

20. 12-factor app principles

12-factor app — cloud-native app yozish bo‘yicha prinsiplar to‘plami.

Senior Java developer buni konsept sifatida bilishi kerak.

Eng muhimlari:

20.1. Codebase

Bitta codebase, ko‘p deploy.

same repo → dev/staging/prod

20.2. Dependencies

Dependency aniq e’lon qilinadi.

pom.xml / build.gradle

Serverda “oldindan o‘rnatilgan library”ga ishonilmaydi.

20.3. Config

Config code’dan ajratiladi.

Yomon:

String dbPassword = "secret";

Yaxshi:

spring:
  datasource:
    password: ${DB_PASSWORD}

20.4. Backing services

Database, Redis, Kafka kabi servislar attachable resource sifatida ko‘riladi.

DB URL o‘zgarsa, code o‘zgarmaydi

20.5. Logs

Log stdout/stderrga yoziladi.

20.6. Disposability

App tez start bo‘lishi va graceful shutdown qila olishi kerak.

21. Spring profiles

Spring’da turli muhit uchun profile ishlatiladi:

local
dev
staging
prod

application.yml:

spring:
  profiles:
    active: ${SPRING_PROFILES_ACTIVE:local}

application-prod.yml:

logging:
  level:
    root: INFO

spring:
  datasource:
    url: ${DB_URL}
    username: ${DB_USERNAME}
    password: ${DB_PASSWORD}

Muhim:

Profile configni ajratadi, lekin secretlarni Git’da saqlash uchun bahona emas.

22. Cloud-native config

Cloud-native muhitda config odatda environment’dan keladi:

DB_URL=jdbc:postgresql://postgres:5432/app
DB_USERNAME=app
DB_PASSWORD=secret

Spring Boot buni oson o‘qiydi:

spring:
  datasource:
    url: ${DB_URL}
    username: ${DB_USERNAME}
    password: ${DB_PASSWORD}

Afzallik:

Image bir xil
Config muhitga qarab o‘zgaradi

Ya’ni dev, staging, prod uchun alohida image build qilish shart emas.

Yomon amaliyot:

my-app-dev.jar
my-app-prod.jar

Yaxshi:

my-app:1.0.0
dev config bilan devda
prod config bilan prodda

23. Spring Cloud Config

Spring Cloud Config — configlarni markazlashgan holda boshqarish uchun ishlatiladi.

Architecture:

Config Server
  ↓
Git repository / Vault / backend storage
  ↓
Spring Boot clients

Misol:

order-service-prod.yml
payment-service-prod.yml
inventory-service-prod.yml

App start bo‘lganda Config Server’dan config oladi.

Qachon kerak?

Spring Cloud Config foydali bo‘lishi mumkin, agar:

• ko‘p microservice bor;

• config markazdan boshqarilishi kerak;

• runtime refresh kerak;

• environmentlar ko‘p;

• config audit qilish kerak.

Lekin kichik loyiha uchun Kubernetes ConfigMap/Secret yetarli bo‘lishi mumkin.

24. Container registry

Docker image build qilingandan keyin registry’ga yuboriladi.

Misollar:

Docker Hub
GitHub Container Registry
GitLab Container Registry
AWS ECR
Google Artifact Registry
Azure Container Registry
Harbor

Flow:

docker build -t registry.example.com/order-service:1.0.0 .
docker push registry.example.com/order-service:1.0.0

Kubernetes image’ni registry’dan tortadi:

image: registry.example.com/order-service:1.0.0

Productionda latest tag ishlatish yomon.

Yomon:

image: order-service:latest

Yaxshi:

image: order-service:1.4.7

Yoki commit SHA:

image: order-service:sha-8f3a91c

25. CI/CD pipeline

Cloud/containerization’da CI/CD juda muhim.

Typical flow:

Git push
 ↓
Tests
 ↓
Build jar
 ↓
Build Docker image
 ↓
Scan image
 ↓
Push registry
 ↓
Deploy staging
 ↓
Deploy prod

Minimal GitHub Actions misol:

name: build

on:
  push:
    branches: [ main ]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-java@v4
        with:
          distribution: temurin
          java-version: 21

      - name: Test
        run: mvn test

      - name: Package
        run: mvn package -DskipTests

      - name: Build Docker image
        run: docker build -t my-app:${{ github.sha }} .

Production pipeline’da yana:

• vulnerability scan;

• SBOM;

• image signing;

• deployment approval;

• rollback;

• smoke test;

bo‘lishi mumkin.

26. Image scanning

Container image ichida zaif dependency yoki OS package bo‘lishi mumkin.

Shuning uchun image scan qilinadi.

Ko‘p ishlatiladigan toollar:

Trivy
Grype
Snyk
Docker Scout
Anchore

Masalan:

trivy image my-app:1.0.0

Bu:

• CVE;

• vulnerable package;

• severity;

• fixed version;

ko‘rsatadi.

27. Java app image hajmini kamaytirish

Image juda katta bo‘lsa:

• pull sekinlashadi;

• deploy sekinlashadi;

• attack surface oshadi;

• registry storage ko‘payadi.

Yaxshi amaliyotlar:

JRE ishlatish, JDK emas
multi-stage build
.dockerignore yozish
keraksiz filelarni copy qilmaslik
minimal base image ishlatish
Spring Boot layered jar ishlatish

.dockerignore:

.git
target
.idea
*.iml
README.md

Agar targetni ignore qilsangiz, Docker ichida build qilayotgan multi-stage holatda moslab yozish kerak. Agar local jar copy qilayotgan bo‘lsangiz, target ignore qilinmasligi kerak.

28. Spring Boot layered jar

Spring Boot dependency va app layerlarni ajratishga yordam beradi.

Maqsad:

Dependency kam o‘zgaradi
App code tez-tez o‘zgaradi
Docker cache yaxshi ishlaydi

Dockerfile konseptual ko‘rinish:

FROM eclipse-temurin:21-jre

WORKDIR /app

COPY target/app.jar app.jar

RUN java -Djarmode=layertools -jar app.jar extract

ENTRYPOINT ["java", "org.springframework.boot.loader.launch.JarLauncher"]

Layerlar:

dependencies
spring-boot-loader
snapshot-dependencies
application

Bu katta loyihalarda build/deploy tezligini yaxshilaydi.

29. Deployment strategy

Production deployda yangi versionni chiqarish ham muhim.

29.1. Rolling update

Podlar navbat bilan yangilanadi.

old pod 1 → new pod 1
old pod 2 → new pod 2
old pod 3 → new pod 3

Afzalligi:

• oddiy;

• downtime kam.

Kamchiligi:

• eski va yangi version bir vaqtda ishlashi mumkin;

• backward compatibility kerak.

29.2. Blue-green deployment

Ikki environment:

blue = hozirgi prod
green = yangi version

Tekshiruvdan keyin traffic green’ga o‘tkaziladi.

Afzalligi:

• rollback oson;

• risk kamroq.

Kamchiligi:

• ikki barobar resource kerak bo‘lishi mumkin.

29.3. Canary deployment

Yangi versionga avval ozgina traffic beriladi.

5% traffic → new version
95% traffic → old version

Metrics yaxshi bo‘lsa, asta-sekin oshiriladi.

Bu katta production tizimlarda kuchli yondashuv.

30. Database migration cloud muhitda

Spring Boot app start bo‘lganda Flyway/Liquibase migration ishlatishi mumkin.

Lekin Kubernetes’da 5 ta pod bir vaqtda start bo‘lsa:

5 pod bir vaqtda migration qilishga urinish

Bu muammo berishi mumkin.

Yechimlar:

• migrationni CI/CD job sifatida alohida ishlatish;

• init job;

• Flyway lock mexanizmini to‘g‘ri tushunish;

• backward compatible migration qilish.

Muhim qoida:

Rolling deployda DB schema eski va yangi app version bilan bir muddat mos ishlashi kerak.

Masalan, fieldni darhol o‘chirish xavfli.

Yaxshi ketma-ketlik:

1. Yangi nullable column qo‘shish
2. App yangi columnni yozishni boshlaydi
3. Data backfill
4. App eski columnni ishlatmaydi
5. Eski column o‘chiriladi

31. Cloud providerlar

Java app quyidagi cloudlarda ishlashi mumkin:

AWS
Google Cloud
Azure
DigitalOcean
Hetzner
Yandex Cloud
Oracle Cloud

Platforma turlari:

VM

Oddiy server.

Ubuntu server + Docker + Nginx

Afzalligi:

• arzonroq;

• nazorat ko‘proq;

• kichik loyiha uchun yetarli.

Kamchiligi:

• maintenance sizda;

• scaling qo‘lda;

• monitoringni o‘zingiz qilasiz.

Managed Kubernetes

Masalan:

AWS EKS
GCP GKE
Azure AKS
DigitalOcean Kubernetes

Afzalligi:

• cluster boshqarish osonroq;

• scaling kuchli;

• production microservice uchun mos.

Kamchiligi:

• murakkabroq;

• qimmatroq;

• DevOps bilim kerak.

PaaS

Masalan:

Render
Railway
Fly.io
Heroku-type platforms

Afzalligi:

• tez deploy;

• kichik team uchun qulay.

Kamchiligi:

• cheklovlar bor;

• narx traffic oshganda qimmatlashishi mumkin;

• ichki nazorat kamroq.

32. Senior xatolari

Xato 1: latest image ishlatish

Productionda qaysi version ishlayotganini bilish qiyinlashadi.

Xato 2: Secretni image ichiga qo‘shish

Yomon:

ENV DB_PASSWORD=my-secret

Image registry’da qoladi. Secret tarqalishi mumkin.

Xato 3: Root user bilan container ishlatish

Security risk.

Xato 4: Health check noto‘g‘ri

Liveness DBga bog‘lansa, DB sekinlashganda podlar ommaviy restart bo‘ladi.

Xato 5: Graceful shutdown yo‘q

Deploy paytida requestlar uziladi.

Xato 6: Memory limit va JVM heap mos emas

Natija:

OOMKilled

Xato 7: Local diskga file saqlash

Pod restart bo‘lsa file yo‘qoladi.

Xato 8: Config image ichida

Har muhit uchun alohida image build qilishga olib keladi.

33. Senior checklist

Java app’ni container/cloudga chiqarishdan oldin tekshir:

Dockerfile multi-stage yoki optimalmi?
Image non-root user bilan ishlaydimi?
JVM memory container limitga mosmi?
Config env orqali keladimi?
Secret image/code ichida emasmi?
Logs stdout/stderrga chiqyaptimi?
Health probes to‘g‘ri ajratilganmi?
Graceful shutdown yoqilganmi?
Resource requests/limits bor-mi?
Readiness deploy paytida trafficni boshqaradimi?
DB migration strategiyasi bormi?
Image tag aniq versionmi?
CI/CD pipeline test va scan qiladimi?
Rollback yo‘li bormi?
Metrics/logging/tracing ulanadimi?

34. Amaliy topshiriqlar

Topshiriq 1: Spring Boot app’ni Docker qilish

Minimal app:

GET /health
GET /hello

Dockerfile yozing:

FROM eclipse-temurin:21-jre
WORKDIR /app
COPY target/app.jar app.jar
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar"]

Keyin:

docker build -t hello-app:1.0.0 .
docker run -p 8080:8080 hello-app:1.0.0

Topshiriq 2: Docker Compose

Spring Boot + PostgreSQL compose yozing.

Talab:

App DBga ulanadi
DB config env orqali keladi

Topshiriq 3: Kubernetes Deployment

Deployment, Service, ConfigMap, Secret yozing.

Talab:

2 replica
readinessProbe
livenessProbe
resource requests/limits

Topshiriq 4: Graceful shutdown test

Endpoint yozing:

GET /slow

30 sekund ishlasin.

Podni terminate qilib, request uziladimi yoki toza tugaydimi — tekshiring.

35. Qisqa xulosa

Cloud & containerization Senior Java developer uchun muhim production skill.

Asosiy fikrlar:

Docker image — app paketi
Container — image’dan ishga tushgan process
Multi-stage build image’ni tozalaydi
Kubernetes podlarni boshqaradi
Service stable endpoint beradi
ConfigMap config uchun
Secret maxfiy qiymatlar uchun
Liveness app tirikligini tekshiradi
Readiness traffic qabul qilishga tayyorligini tekshiradi
Graceful shutdown deploy paytida requestlarni asraydi
12-factor app cloud-native prinsip beradi
Config code’dan ajratiladi

Eng muhim qoida:

Senior Java developer uchun deploy “jarni serverga tashlash” emas. App container ichida, limitlar ostida, health check, config, secret, logging, graceful shutdown va monitoring bilan productionga tayyor bo‘lishi kerak.