من GitHub Actions إلى ECS: بناء خط نشر بدون توقف لخدمات Go

عمليات النشر اليدوية هي المكان الذي تتسلل منه الأخطاء، ويفقد فيه الفريق الثقة في عملية الإصدار. كل خطوة يدوية فرصة للخطأ البشري: اختبار متخطى، متغير بيئة خاطئ، نشر للمجموعة الخاطئة. لفرق SaaS في لبنان والشرق الأوسط تشغل خدمات خلفية على AWS ECS، خط CI/CD مبني بشكل صحيح ليس رفاهية، بل متطلب أساسي للشحن بثقة.

ما الذي يحتاج الخط القيام به؟

خط كامل لخدمة Go على ECS يغطي هذه المراحل:

1. بناء واختبار خدمة Go
2. بناء صورة Docker صغيرة
3. دفع الصورة إلى Amazon ECR
4. تحديث تعريف مهمة ECS بالصورة الجديدة
5. تشغيل نشر دوار على خدمة ECS
6. مراقبة صحة النشر والتراجع تلقائياً عند الفشل

المرحلة السادسة هي ما تتخطاه معظم برامج التعليمية الأساسية، وهي الأكثر أهمية في عمليات SaaS الإنتاجية.

Dockerfile: بناء صورة Go صغيرة

الصور الصغيرة تُبنى أسرع وتُدفع أسرع وتُسحب أسرع على نسخ ECS:

FROM golang:1.23-alpine AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -ldflags='-w -s' -o server ./cmd/server

FROM gcr.io/distroless/static-debian12
COPY --from=builder /app/server /server
USER nonroot:nonroot
ENTRYPOINT ["/server"]

صورة الأساس distroless/static-debian12 تحتوي فقط على الملف الثنائي لـ Go وشهادات TLS. لا قشرة، لا مدير حزم، لا مكتبات إضافية. الصورة الناتجة عادةً 10 إلى 20 ميغابايت مقارنةً بـ 100 إلى 200 ميغابايت للصورة المبنية على Ubuntu.

سير عمل النشر

name: Deploy
on:
  push:
    branches: [main]

permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::ACCOUNT_ID:role/github-deploy
          aws-region: eu-west-1

      - name: Build and push image
        run: |
          docker build -t ECR_REPO:${{ github.sha }} .
          docker push ECR_REPO:${{ github.sha }}

      - name: Deploy to ECS
        uses: aws-actions/amazon-ecs-deploy-task-definition@v2
        with:
          task-definition: task-definition.json
          service: api-service
          cluster: production
          wait-for-service-stability: true
          wait-for-minutes: 10

المصادقة عبر OIDC بدلاً من مفاتيح طويلة الأمد

الإعداد أعلاه يستخدم role-to-assume بدلاً من AWS_ACCESS_KEY_ID وAWS_SECRET_ACCESS_KEY. هذا نهج OIDC حيث تفترض GitHub Actions دور IAM مباشرةً دون تخزين بيانات اعتماد طويلة الأمد.

الفائدة كبيرة: لا مفاتيح طويلة الأمد للتدوير، لا خطر تسرب مفتاح من المستودع، والدور المفترض يوجد فقط لمدة تشغيل سير العمل.

النشر الدوار بدون توقف

Nشر ECS الدوار يستبدل المهام واحدة في كل مرة مع الحفاظ على توافر الخدمة. النشر يتوقف ويتراجع تلقائياً إذا فشلت المهام الجديدة في فحوص الصحة.

متطلبات النشر بدون توقف:

• فحص صحة مُعدّ بشكل صحيح: ECS ينتظر نجاح فحص الصحة قبل إنهاء المهام القديمة
• الحد الأدنى للنسبة الصحية فوق الصفر: اضبط minimumHealthyPercent على الأقل 50
• مهلة نشر كافية: wait-for-minutes: 10 يتطابق مع مهلة ECS

التراجع التلقائي عند الفشل

      - name: Rollback on failure
        if: failure()
        run: |
          PREV=$(aws ecs describe-services \
            --cluster production --services api-service \
            --query 'services[0].taskDefinition' --output text)
          aws ecs update-service \
            --cluster production --service api-service \
            --task-definition $PREV

هذه الخطوة تعمل فقط عند فشل خطوة سابقة، وتعيد الخدمة إلى آخر تعريف مهمة مستقر.

الإعداد الخاص بالبيئة

متغيرات البيئة للخدمة يجب أن تأتي من AWS Systems Manager Parameter Store أو Secrets Manager، وليس من ملف task-definition المُدمج في المستودع. في قالب task definition:

{
  "secrets": [
    {
      "name": "DATABASE_URL",
      "valueFrom": "arn:aws:ssm:eu-west-1:123:parameter/prod/database_url"
    }
  ]
}

ECS يسحب قيمة السر من SSM عند إطلاق المهمة. تدوير كلمة مرور قاعدة البيانات يتطلب تحديث معامل SSM وإعادة تشغيل المهام فقط.

الدروس من الإنتاج

OIDC للمصادقة على AWS يحل مشكلة إدارة بيانات الاعتماد طويلة الأمد بشكل دائم. الإعداد يستغرق 20 دقيقة والفائدة التشغيلية كبيرة.

تشغيل الاختبارات في سير عمل النشر، وليس فقط في سير عمل PR، يلتقط الحالات التي تغير فيها اعتماد في الفرع الرئيسي بين مراجعة PR ودمجه.

صور Distroless تستحق منحنى التعلم. الفرق في وقت البناء على صور Ubuntu مهم بالتردد الذي تنشر فيه الفرق.

خطوة التراجع يجب أن تكون في كل سير عمل نشر. بدونها، يترك النشر الفاشل الخدمة في حالة متدهورة تتطلب تدخلاً يدوياً.