Docker و CI/CD و Git

#Containers و VMs: بتعزل إيه؟Containers and VMs: what is isolated?

مشكلة «شغال عندي» بتقل لما تشحن التطبيق مع runtime و dependencies في image معروفة. الـ container process معزول بيشارك kernel الـ host؛ الـ VM عندها guest OS و kernel خاص. Linux containers على Windows عادة بتشتغل جوه Linux VM، مش على Windows kernel مباشرة.

container مش sandbox كامل ضد كل تهديد، ومش backup ولا orchestrator. ماتستخدمش privileged mode لمجرد حل permission error؛ افهم الـ mount والـ user المطلوبين.

#Images و Layers و Volumes و NetworksImages, layers, volumes and networks

الـ image قالب immutable مكوّن من layers، والـ container بيضيف writable layer مؤقتة. الـ tag اسم ممكن يتغير؛ digest بيحدد المحتوى. layers بتتشارك وبتتخزن في build cache، لكن secret اتحذف في layer جديدة ممكن يفضل موجود في layer قديمة.

الأوامر دي لـ Bash مع Docker، بعد وجود image محلية اسمها store-api:study. التطبيق بيسمع على 8080.

docker network create store-backend                 # (1)
docker volume create store-data                     # (2)
docker run -d --name store-api --network store-backend \
  -p 127.0.0.1:8080:8080 store-api:study              # (3)
docker logs store-api
docker inspect store-api
docker stats --no-stream store-api

bind mount بيربط path من الجهاز، و volume Docker بيديرها. الاتنين مش بديل عن backup واختبار restore. logs تروح stdout و stderr، مش ملفات جوا writable layer.

#Dockerfile متعدد المراحل لـ ASP.NET Core 10A multi-stage ASP.NET Core 10 Dockerfile

الشحن بالـ SDK بيزود حجم وسطح هجوم من غير فايدة وقت التشغيل. المثال لـ API واحدة اسمها Store.Api.csproj في build context root، من غير project references أو central package files. لو عندك dependencies في projects تانية، انسخ ملفاتها وملفات restore configuration قبل restore. حط bin و obj و.git وملفات الأسرار في .dockerignore.

FROM mcr.microsoft.com/dotnet/sdk:10.0-noble AS build
WORKDIR /src
COPY Store.Api.csproj ./
RUN dotnet restore Store.Api.csproj                         # (1)
COPY . .
RUN dotnet publish Store.Api.csproj -c Release --no-restore \
    -o /out /p:UseAppHost=false                             # (2)

FROM mcr.microsoft.com/dotnet/aspnet:10.0-noble-chiseled-extra
WORKDIR /app
COPY --from=build /out/ ./
USER $APP_UID                                              # (3)
ENV ASPNETCORE_HTTP_PORTS=8080
EXPOSE 8080
ENTRYPOINT ["dotnet", "Store.Api.dll"]                      # (4)

chiseled مافيهاش shell أو package manager؛ نسخة extra فيها dependencies للـ globalization زي ICU و tzdata. ماتكتبش healthcheck بـ curl أو CMD-SHELL من غير binary موجود. استخدم probe خارجي. في releases حقيقية ثبّت base images بالـ digest وجدول تحديثها وفحصها؛ version tags هنا للتوضيح. توثيق chiseled.

#SDK container publishing من غير DockerfileSDK container publishing without a Dockerfile

لو صورة التطبيق محتاجة ناتج publish فوق base image بس، الـ SDK يقدر يبنيها من غير Dockerfile. المثال Bash لـ ASP.NET Core project من الكارت اللي فات، مع .NET 10 SDK و local Docker daemon.

dotnet publish Store.Api.csproj -c Release --os linux --arch x64 \
  /t:PublishContainer \
  -p:ContainerRepository=store-api \
  -p:ContainerImageTag=study \
  -p:ContainerBaseImage=mcr.microsoft.com/dotnet/aspnet:10.0-noble-chiseled-extra

PublishContainer بيعمل image، و ContainerRepository اسمها و ContainerImageTag الـ tag. الـ SDK publishing يقدر يطلع archive أو ينشر لregistry بإعداداته؛ daemon مش مطلوب لكل أشكال النشر. راجع port و user و architecture بدل افتراض تطابقهم مع Dockerfile.

النهجين لسه محتاجين scanning و secrets خارج الصورة و artifact identity ثابت. توثيق SDK container publishing.

#Compose: الجاهزية مش مجرد بدء processCompose: readiness is more than process startup

بدء database container مش معناه إنها جاهزة للاتصال. المثال local development، مع Dockerfile السابق و package Npgsql EF provider في التطبيق. عرّف DB_PASSWORD في البيئة قبل التشغيل، وماتحطش قيمتها في Git.

services:
  api:
    build: .
    ports: ["127.0.0.1:8080:8080"]
    environment:
      ConnectionStrings__Default: >-
        Host=db;Database=store;Username=store;Password=${DB_PASSWORD:?Set DB_PASSWORD}
    depends_on:
      db:
        condition: service_healthy # (1)
  db:
    image: postgres:17
    environment:
      POSTGRES_DB: store
      POSTGRES_USER: store
      POSTGRES_PASSWORD: ${DB_PASSWORD:?Set DB_PASSWORD}
    volumes: ["pgdata:/var/lib/postgresql/data"] # (2)
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U store -d store"] # (3)
      interval: 5s
      timeout: 3s
      retries: 10
      start_period: 10s
volumes:
  pgdata:

شغّل docker compose up --build -d وافحص logs. الـ API محتاجة readiness endpoint يفحص dependencies المطلوبة، و retry محدود للـ transient errors. متغيرات البيئة مناسبة للمثال المحلي؛ production secrets تتحقن من secret store. ترتيب التشغيل في Compose.

#CI/CD: ابني مرة وروّج نفس الناتجCI/CD: build once and promote the same artifact

CI بتدمج تغييرات صغيرة مع build و tests تلقائي. Continuous delivery بتخلي النسخة جاهزة للنشر بموافقة، و continuous deployment بينشر كل تغيير ناجح تلقائياً. المثال GitHub Actions لـ repo فيه solution و tests و Dockerfile في root؛ test projects مضبوطة لتشتغل بـ dotnet test. tags بتاعة actions للتوضيح؛ ثبّتها على full commit SHA متراجع في pipeline حقيقية.

جزء CD بيفترض Container Apps موجودة للـ staging وproduction، وكل واحدة single-revision mode ومضبوطة تسحب الصورة من GHCR؛ لو package خاصة، اضبط registry credentials منفصلة. عرّف في كل GitHub environment متغيرات AZURE_CLIENT_ID وAZURE_TENANT_ID وAZURE_SUBSCRIPTION_ID وRESOURCE_GROUP وAPP_NAME وHEALTH_URL. اضبط OIDC federation لكل environment وصلاحية deployment محدودة، وrequired reviewers للـ production. المثال مش بينشئ infrastructure ولا يشغل migrations؛ طبق التغييرات المتوافقة بخطوة منفصلة قبل rollout.

name: ci-cd
on:
  pull_request:
  push:
    branches: [main]
permissions:
  contents: read
concurrency:
  group: release-${{ github.ref }}
  cancel-in-progress: false
jobs:
  verify:
    runs-on: ubuntu-24.04
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-dotnet@v4
        with:
          dotnet-version: '10.0.x'
      - run: dotnet restore
      - run: dotnet build -c Release --no-restore -warnaserror
      - run: dotnet test -c Release --no-build # (1)
  image:
    needs: verify
    if: github.event_name == 'push'
    runs-on: ubuntu-24.04
    outputs:
      image: ${{ steps.publish.outputs.image }}
    permissions:
      contents: read
      packages: write
    env:
      GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      GH_USER: ${{ github.actor }}
      REPOSITORY: ${{ github.repository }}
      REVISION: ${{ github.sha }}
    steps:
      - uses: actions/checkout@v4
      - name: Build and push
        id: publish
        shell: bash
        run: |
          image="ghcr.io/${REPOSITORY,,}:$REVISION" # (2)
          printf '%s' "$GH_TOKEN" | docker login ghcr.io \
            -u "$GH_USER" --password-stdin
          docker build --pull -t "$image" .
          docker push "$image" # (3)
          digest=$(docker inspect --format='{{index .RepoDigests 0}}' "$image")
          echo "image=$digest" >> "$GITHUB_OUTPUT"
  deploy-staging:
    needs: image
    runs-on: ubuntu-24.04
    environment: staging # (4)
    concurrency: deploy-staging
    permissions:
      contents: read
      id-token: write
    env:
      IMAGE: ${{ needs.image.outputs.image }}
      GROUP: ${{ vars.RESOURCE_GROUP }}
      APP: ${{ vars.APP_NAME }}
      HEALTH_URL: ${{ vars.HEALTH_URL }}
    steps:
      - uses: azure/login@v2
        with:
          client-id: ${{ vars.AZURE_CLIENT_ID }}
          tenant-id: ${{ vars.AZURE_TENANT_ID }}
          subscription-id: ${{ vars.AZURE_SUBSCRIPTION_ID }}
      - run: az extension add --name containerapp --upgrade
      - run: az containerapp update -g "$GROUP" -n "$APP" --image "$IMAGE"
      - run: curl --fail --retry 5 --retry-connrefused "$HEALTH_URL" # (5)
  deploy-production:
    needs: [image, deploy-staging]
    runs-on: ubuntu-24.04
    environment: production # (6)
    concurrency: deploy-production
    permissions:
      contents: read
      id-token: write
    env:
      IMAGE: ${{ needs.image.outputs.image }}
      GROUP: ${{ vars.RESOURCE_GROUP }}
      APP: ${{ vars.APP_NAME }}
      HEALTH_URL: ${{ vars.HEALTH_URL }}
    steps:
      - uses: azure/login@v2
        with:
          client-id: ${{ vars.AZURE_CLIENT_ID }}
          tenant-id: ${{ vars.AZURE_TENANT_ID }}
          subscription-id: ${{ vars.AZURE_SUBSCRIPTION_ID }}
      - run: az extension add --name containerapp --upgrade
      - run: az containerapp update -g "$GROUP" -n "$APP" --image "$IMAGE"
      - run: curl --fail --retry 5 --retry-connrefused "$HEALTH_URL"

الـ workflow بتسلسل releases لنفس ref علشان rollout قديم وجديد مايشتغلوش في نفس الوقت. زوّد image scanning وفحص dependencies حسب policy الفريق، وحدّث actions وbase images بانتظام. vulnerability report لوحده مش gate إلا لو policy بتفشل الـ job. أمان GitHub Actions.

#Promotion و Deployment strategiesPromotion and deployment strategies

إعادة build لكل environment معناها إن production بتاخد حاجة مختلفة عن اللي اتاختبرت. خزن config والأسرار برّه artifact، وروّج نفس image digest، مع release record يحدد version و config و migration status.

1. نسخة جديدة تبدأ وتعدّي readiness، مش مجرد process running.
2. وجّه traffic تدريجياً وراقب error rate و tail latency ومعيار business.
3. وقت الإيقاف، اسحب instance من routing واديها وقت تخلص الطلبات.
4. لو المقاييس اتدهورت، وقف rollout أو ارجع للنسخة المتوافقة.

rollback للصورة مش بيرجع database ولا refund للدفع. عرّف خطة recovery للداتا والعمليات الخارجية قبل النشر.

#Database migrations من غير قطع الخدمةDatabase migrations without service interruption

أثناء rolling deployment فيه كود قديم وجديد بيستخدموا نفس الـ schema. حذف column أو rename مباشر ممكن يكسر القديم فوراً. استخدم expand و migrate و contract بدل التغيير المدمر مرة واحدة.

1. Expand: ضيف column جديد nullable أو بقيمة افتراضية مناسبة؛ راجع locking وتكلفة DDL على engine الحقيقي.
2. انشر كود متوافق مع القديم والجديد. لو فيه dual-write، خلي التحديثات متسقة وخطط للفشل الجزئي.
3. Backfill دفعات صغيرة قابلة للاستكمال، وراقب latency و locks.
4. حوّل القراءة للجديد بعد التحقق من اكتمال الداتا، واستنى انتهاء rollback window وكل old instances.
5. Contract: احذف القديم في release لاحقة، مع backup وخطة restore مجربة.

شغّل migrations من job واحدة بصلاحية مخصصة، مش من كل replica عند startup. idempotent script مش ضمان إنه سريع أو من غير locks. اختبر migration على حجم قريب من الحقيقي، وما تفترضش إن Down migration آمنة أو بترجع الداتا المحذوفة.

#Kubernetes: desired state و Health probesKubernetes: desired state and health probes

Kubernetes بيدير desired state على cluster؛ مش بيصلح business bugs. Pod وحدة scheduling فيها container أو أكتر بيشاركوا network namespace؛ Deployment بيدير replicas و rollouts؛ Service عنوان discovery ثابت وتوجيه للـ endpoints الجاهزة؛ Ingress قواعد HTTP محتاجة controller. ConfigMap للإعدادات، و Secret للداتا الحساسة، لكن base64 مش تشفير.

المثال fragment جوه Pod template في Deployment؛ image لازم تتبدل بإصدارك الحقيقي، والـ API لازم تعرض endpoints المذكورة.

containers:
  - name: api
    image: registry.example.com/store-api:release-1
    ports:
      - containerPort: 8080
    resources:
      requests: { cpu: "250m", memory: "256Mi" } # (1)
      limits: { cpu: "1", memory: "512Mi" }
    startupProbe:
      httpGet: { path: /health/live, port: 8080 }
      failureThreshold: 30
      periodSeconds: 2
    readinessProbe:
      httpGet: { path: /health/ready, port: 8080 } # (2)
    livenessProbe:
      httpGet: { path: /health/live, port: 8080 } # (3)

ماتربطش liveness بكل external dependency فتعمل restart storm وقت عطل database. HPA بيغير replicas بناء على metrics، ومش بيزوّد قدرة database تلقائياً. Kubernetes مفيد لما التشغيل محتاج قدراته؛ managed container platform ممكن تكون أبسط.

#Git: تاريخ مفهوم وقرارات قابلة للرجوعGit: understandable history and reversible decisions

Git بيسجل snapshots و relationships بين commits. merge بيجمع histories، وممكن يكون fast-forward من غير merge commit؛ rebase بيعيد إنشاء commits فوق base جديد، فهوياتها بتتغير. تجنب إعادة كتابة shared history إلا بتنسيق صريح.

الأوامر Bash داخل repository تجريبية؛ غيّر أسماء الـ refs حسب الحالة. reset بيغير branch pointer وقد يغيّر index و working tree حسب الـ mode؛ ماتستخدموش لإلغاء commit منشور على main.

git switch -c feature/order-limits
git rebase main                  # (1) replay this private branch
git revert HEAD                  # (2) create a new inverse commit
git bisect start
git bisect bad
git bisect good v1.0.0            # (3) known-good tag must exist
# Test each selected revision; mark it with git bisect good or bad.
git bisect reset

Conventional commits زي feat(orders): add booking limit و fix(payments): reject duplicate capture بتوضح النية وتساعد automation. جودة الرسالة والـ PR أهم من prefix لوحده؛ main تحتاج review و CI وحماية branches.

#IIS و Linux مع NginxIIS and Linux with Nginx

الـ hosting chain لازم تبقى مفهومة علشان تشخص 502 و redirect loops. على Windows ثبّت ASP.NET Core Hosting Bundle المناسب بعد IIS، واستخدم app pool بإعداد No Managed Code لتطبيق ASP.NET Core. الـ ASP.NET Core Module بيستضيف in-process جوه w3wp أو يمرر لـ Kestrel في out-of-process؛ صلاحيات identity و web.config المنشور مهمة.

على Linux شغّل dotnet كـ service تحت systemd أو container orchestrator، وخلي Nginx قدام Kestrel للـ TLS و routing. المثال fragment داخل Nginx server block للـ HTTP المحلي؛ TLS configuration مطلوبة للنشر العام.

location / {
    proxy_pass http://127.0.0.1:5000; # (1)
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme; # (2)
}

لو Nginx و Kestrel في containers مختلفة، loopback مش هيوصل بينهم؛ استخدم service DNS و network خاصة. WebSockets محتاجة upgrade configuration إضافية. Data Protection keys لازم تستمر وتتشارك بأمان لما فيه replicas أو deploys بتحافظ على login cookies. دليل Nginx الرسمي.