Implementation guide: branch deploys for EKS using Cased

This guide walks you through setting up branch deploys for your Amazon EKS (Elastic Kubernetes Service) application using Cased. This setup enables a robust CI/CD pipeline for Kubernetes deployments.

Prerequisites

• An AWS account with EKS cluster set up
• A GitHub repository for your application
• A Cased account
• kubectl configured for your EKS cluster
• Helm (if using Helm charts)

Step 1: Connect Cased to Your Services

1. Connect Cased to GitHub:

   • Navigate to the Cased connections page and select GitHub
   • Click “Install GitHub App” and follow prompts to give Cased repository access

2. Connect Cased to AWS:

   • Create a new IAM role in AWS Console named “CasedEKSRole” with the following permissions:
     • eks:DescribeCluster
     • eks:ListClusters
     • eks:UpdateClusterConfig
     • eks:UpdateClusterVersion
     • eks:UpdateNodegroupConfig
   • Copy the Role ARN
   • In Cased, navigate to AWS Connections and enter the Role ARN and AWS region

Step 2: Set Up Your Project in Cased

1. Go to the Deploys section in Cased
2. Click “Create new project”
3. Select your GitHub repository
4. Click “Create Project”

Step 3: Create Deployment Targets

1. In your project page, click “Create new target”
2. Create two targets:
   • Staging target:
     • Name: “staging”
     • Select GitHub Actions workflow
     • Set appropriate environment variables
   • Production target:
     • Name: “production”
     • Select GitHub Actions workflow
     • Check the “production” box
     • Set stricter approval requirements

Step 4: Create GitHub Actions Workflow

Create .github/workflows/cased-eks-deploy.yml:

name: Cased EKS Deploy
on:
  workflow_dispatch:
    inputs:
      branch:
        required: true
      target_name:
        required: true

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3
        with:
          ref: ${{ github.event.inputs.branch }}

      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: your-aws-region

      - name: Login to Amazon ECR
        id: login-ecr
        uses: aws-actions/amazon-ecr-login@v1

      - name: Build, tag, and push image to Amazon ECR
        env:
          ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}
          ECR_REPOSITORY: your-ecr-repo-name
          IMAGE_TAG: ${{ github.sha }}
        run: |
          docker build -t $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG .
          docker push $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG

      - name: Update kubeconfig
        run: |
          aws eks update-kubeconfig --name your-cluster-name --region your-aws-region

      - name: Deploy to EKS
        env:
          IMAGE_TAG: ${{ github.sha }}
        run: |
          # Update image in deployment
          kubectl set image deployment/your-deployment-name container-name=$ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG
          
          # Wait for rollout
          kubectl rollout status deployment/your-deployment-name

      - name: Notify Cased of deployment
        uses: cased/cased-deploy-action@v2
        with:
          branch_name: ${{ github.event.inputs.branch }}
          target: ${{ github.event.inputs.target_name }}
          cased_token: ${{ secrets.CASED_TOKEN }}

Step 5: Kubernetes Manifests

Create a base Kubernetes deployment manifest (k8s/deployment.yaml):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: your-deployment-name
  namespace: your-namespace
spec:
  replicas: 3
  selector:
    matchLabels:
      app: your-app
  template:
    metadata:
      labels:
        app: your-app
    spec:
      containers:
      - name: container-name
        image: your-ecr-repo-name:latest
        ports:
        - containerPort: 80
        resources:
          requests:
            memory: "64Mi"
            cpu: "250m"
          limits:
            memory: "128Mi"
            cpu: "500m"

Step 6: Set Up Secrets

In GitHub repository settings, add these secrets:

• AWS_ACCESS_KEY_ID
• AWS_SECRET_ACCESS_KEY
• CASED_TOKEN

In EKS, create necessary secrets:

kubectl create secret generic app-secrets \
  --from-literal=DB_PASSWORD=your-db-password \
  --from-literal=API_KEY=your-api-key

Step 7: Deploy a Branch

1. Navigate to your project’s deploy page in Cased
2. Select target (staging/production)
3. Choose branch to deploy
4. Click “Deploy”

The workflow will:

1. Build and push Docker image to ECR
2. Update Kubernetes deployment with new image
3. Monitor rollout status
4. Notify Cased of deployment status

Step 8: Advanced Configuration

Rolling Updates

Add to your deployment manifest for safer updates:

spec:
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
    type: RollingUpdate

Health Checks

Add readiness/liveness probes:

spec:
  containers:
  - name: container-name
    livenessProbe:
      httpGet:
        path: /health
        port: 80
      initialDelaySeconds: 30
      periodSeconds: 10
    readinessProbe:
      httpGet:
        path: /ready
        port: 80
      initialDelaySeconds: 5
      periodSeconds: 5

Step 9: Monitor and Analyze

After deployment:

• Check deployment status in Cased
• Monitor Kubernetes metrics:

  kubectl get pods
  kubectl describe deployment your-deployment-name
  kubectl logs -f deployment/your-deployment-name
  

• Use Cased’s log analysis for troubleshooting
• Monitor EKS CloudWatch metrics

Best Practices

1. Resource Management:

   • Set appropriate resource requests/limits
   • Use horizontal pod autoscaling
   • Monitor cluster capacity

2. Security:

   • Use namespace isolation
   • Implement network policies
   • Regular security scanning
   • Rotate credentials

3. Rollback Strategy:

   • Keep deployment history
   • Test rollback procedures
   • Document recovery steps

Conclusion

This setup provides a robust branch deployment system for EKS using Cased. It enables:

• Safe deployment of feature branches
• Controlled production releases
• Easy rollbacks
• Deployment monitoring
• Security compliance

Remember to customize the configuration based on your specific requirements, such as adding custom validation steps, automated testing, or approval workflows for production deployments.