DEV Community: Thibault CORDIER ☁

Retour d'expérience : Quand ECS s'impose comme une alternative pertinente à Kubernetes

Thibault CORDIER ☁ — Tue, 19 Nov 2024 20:30:14 +0000

Ces derniers mois, j'ai accompagné un client dans sa transition d'une infrastructure traditionnelle AWS (EC2 + Auto Scaling Groups, orchestrée via CodePipeline et CodeDeploy) vers AWS ECS.

Cette migration, que nous appréhendions initialement, s'est révélée étonnamment fluide. Avec peu d'effort, nous avons réussi à mettre en place une infrastructure conteneurisée robuste et efficace, tout en conservant les avantages de l'intégration continue déjà en place.

Cette expérience m'a ouvert les yeux : ECS ne serait-il pas trop souvent négligé au profit de Kubernetes, particulièrement pour les structures de taille moyenne qui cherchent à moderniser leur infrastructure sans complexité excessive ?

La tendance Kubernetes

Ces dernières années, nous avons assisté à une adoption massive de Kubernetes dans le paysage du cloud computing. Ses promesses d'orchestration puissante, de scalabilité et de portabilité en ont fait un standard de facto. Cependant, cette adoption s'accompagne souvent d'une complexité non négligeable en termes de maintenance, de mises à jour et de gestion quotidienne.

Le défi des petites structures

Pour une entreprise disposant d'une équipe DevOps dédiée, la complexité de Kubernetes fait partie du quotidien. Les problèmes techniques trouvent rapidement leur solution grâce à l'expertise interne.
Mais qu'en est-il des structures plus modestes ? En l'absence d'équipe interne, le recours à une ESN ou à des freelances devient nécessaire, engendrant des coûts significatifs et une dépendance externe.

Au fil de mes missions freelance auprès de startups et PME, une question revient systématiquement : ont-elles réellement besoin de toute la puissance (et la complexité) de Kubernetes ?

ECS : L'alternative pragmatique

C'est dans ce contexte que j'ai récemment guidé un client vers AWS ECS plutôt que vers EKS (la version managée de Kubernetes par AWS). Bien que moins médiatisé que Kubernetes, ECS offre un ensemble de fonctionnalités particulièrement adaptées aux équipes réduites :

Simplicité opérationnelle

Aucune gestion de version du cluster requise
Déploiement familier, proche de docker-compose
Debug simplifié via l'accès console aux tâches

Intégration native AWS

Connexion transparente avec AWS Secret Manager et SSM Parameter Store
Configuration simple des Load Balancers et security groups
Gestion des droits intuitive via IAM et les rôles de tâches

Flexibilité et coût-efficacité

Support de Fargate et Fargate Spot (non disponible sur EKS)
Gestion flexible des volumes
Scaling automatique efficient

Déploiement continu

Intégration native avec CodePipeline
Support du rolling release et blue-green deployment
Transition douce depuis une infrastructure EC2 classique

Le cas concret de notre migration

Dans le cas de notre client, la transition depuis une architecture EC2 traditionnelle vers ECS s'est faite progressivement, en conservant les pipelines existants et en adaptant simplement la phase de déploiement. Les développeurs ont rapidement pris en main le nouveau système, notamment grâce à la similarité avec docker-compose qu'ils utilisaient déjà en développement.
L'équipe technique réduite a particulièrement apprécié l'absence de maintenance du cluster et la simplification des processus de déploiement, leur permettant de se concentrer sur le développement de fonctionnalités plutôt que sur l'infrastructure.
Un choix pragmatique

Si Kubernetes reste incontournable pour certains cas d'usage complexes, ECS s'impose comme une alternative crédible pour les équipes qui cherchent à moderniser leur infrastructure sans démultiplier la complexité opérationnelle. Il offre un excellent compromis entre fonctionnalités modernes et simplicité d'utilisation, particulièrement dans l'écosystème AWS.

Github ARC Runners sur EKS - Assume roles

Thibault CORDIER ☁ — Thu, 25 Apr 2024 08:45:46 +0000

Récemment, nous avons migré nos runners Github en "self-hosted" sur Kubernetes (EKS) via l'opérateur ARC.

L'installation est assez aisée (même si la doc est un peu succincte).

Une fois avoir installé l'opérateur ARC, on installe des CRD AutoScalingRunnerSet avec Helm dont voici un exemple fichier de values.

githubConfigUrl: "https://github.com/<myorganisation>"
githubConfigSecret: "pre-defined-secret"
maxRunners: 100
runnerScaleSetName: "arc-runner-set-arm"

template:
  metadata:
    annotations:
      karpenter.sh/do-not-disrupt: "true"
  spec:
    nodeSelector:
      kubernetes.io/arch: "arm64"
    serviceAccountName: arc-runner-base-role
    tolerations:
    - key: github/arm
      value: "true"
      effect: NoSchedule
    initContainers:
    - name: init-dind-externals
      image: ghcr.io/actions/actions-runner:latest
      command: ["cp", "-r", "-v", "/home/runner/externals/.", "/home/runner/tmpDir/"]
      volumeMounts:
        - name: dind-externals
          mountPath: /home/runner/tmpDir
    containers:
    - name: runner
      image: ghcr.io/actions/actions-runner:latest
      command: ["/home/runner/run.sh"]
      env:
        - name: DOCKER_HOST
          value: unix:///run/docker/docker.sock
      resources:
        requests:
          cpu: 1
      volumeMounts:
        - name: work
          mountPath: /home/runner/_work
        - name: dind-sock
          mountPath: /run/docker
          readOnly: true

    - name: dind
      image: public.ecr.aws/docker/library/docker:dind
      args:
        - dockerd
        - --host=unix:///run/docker/docker.sock
        - --group=$(DOCKER_GROUP_GID)
      env:
        - name: DOCKER_GROUP_GID
          value: "123"
      securityContext:
        privileged: true
      volumeMounts:
        - name: work
          mountPath: /home/runner/_work
        - name: dind-sock
          mountPath: /run/docker
        - name: dind-externals
          mountPath: /home/runner/externals
    volumes:
    - name: work
      emptyDir: {}
    - name: dind-sock
      emptyDir: {}
    - name: dind-externals
      emptyDir: {}

controllerServiceAccount:
  name: arc-gha-rs-controller
  namespace: arc-systems

La partie importante pour les droits va être de renseigner un spec.serviceAccountName qui sera utilisé par tous les runners qui vont être créés.

Avec AWS CDK, j'ai auparavant créé un serviceAccount et un rôle associé

        const arcBaseRole = kubernetesCluster.addServiceAccount('arc-base-role', {
            name: 'arc-runner-base-role',
            namespace: 'arc-systems',
        });
        // Allow to assumeRole in the account starting with arc-runner-*
        arcBaseRole.role.attachInlinePolicy(
            new Policy(this, 'arc-base-role-policy', {
                statements: [
                    new PolicyStatement({
                        actions: ['sts:AssumeRole', 'sts:TagSession'],
                        resources: ['arn:aws:iam::'+ this.account + ':role/arc-runner-*'],
                    }),
                ],
            })
        );

Ainsi qu'un rôle à assumer pour ce runner (ici la possibilité de push sur le dépôt ECR.)

const pusherRole = new Role(this, 'arc-ecr-image-pusher-role', {
    assumedBy: new AccountPrincipal(this.account),
    roleName: 'arc-runner-ecr-image-pusher-role',
});

pusherRoleI.attachInlinePolicy(
    new Policy(this, 'arc-ecr-image-pusher-policy-base', {
        statements: [
            new PolicyStatement({
                actions: [
                    'ecr:GetAuthorizationToken',
                    'ecr:BatchCheckLayerAvailability',
                    'ecr:GetDownloadUrlForLayer',
                    'ecr:BatchGetImage',
                    'ecr:InitiateLayerUpload',
                    'ecr:UploadLayerPart',
                    'ecr:CompleteLayerUpload',
                    'ecr:PutImage',
                ],
                resources: ['*'],
            })
        ]
        })
);

Ensuite dans mon job github, plus qu'à préciser le rôle à assumer et voila !

- uses: aws-actions/configure-aws-credentials@v4
  with:
    aws-region: eu-central-1
    role-to-assume: arn:aws:iam::${{ secrets.ECR_AWS_ACCOUNT_ID }}:role/arc-runner-ecr-image-pusher-role
    role-session-name: ${{ github.workflow }}_${{ github.run_number }}_${{ github.job }}
    role-skip-session-tagging: true

Pourquoi j'en ai fait un post ?
Parce que ça n'a pas marché tout de suite, notamment à cause du paramètre : role-skip-session-tagging: true qu'il faut rajouter sous peine de voir le runner répéter le même message en boucle :)