전제 요구사항
단계 1: AWS Fargate 작업을 위한 컨테이너 이미지 준비
단계 2: 컨테이너 이미지를 레지스트리에 푸시
단계 3: GitLab Runner용 EC2 인스턴스 생성
단계 4: EC2 인스턴스에 GitLab 러너 설치 및 구성
단계 5: ECS Fargate 클러스터 생성
단계 6: ECS 작업 정의 생성
단계 7: 구성 테스트
정리
개인 AWS Fargate 작업 구성
문제 해결

AWS Fargate에서 GitLab CI 자동 스케일링

Tier: Free, Premium, Ultimate
Offering: GitLab.com, Self-Managed

custom executor인 GitLab은
AWS Fargate
드라이버를 사용하여 Amazon Elastic Container Service (ECS)에 컨테이너를 자동으로 시작하여
각 GitLab CI 작업을 실행합니다.

이 문서의 작업을 완료하면 실행기가 GitLab에서 시작된 작업을 실행할 수 있습니다.
GitLab에서 커밋이 이루어질 때마다 GitLab 인스턴스는 새 작업이 가능하다는
실행기에 알립니다. 그럼 실행기는 AWS ECS에 구성한 작업 정의를 기반으로
타겟 ECS 클러스터에서 새 작업을 시작합니다.
AWS ECS 작업 정의를 구성하여 Docker 이미지를 사용할 수 있으므로
AWS Fargate에서 실행할 수 있는 빌드 유형에 대해 완전한 유연성이 있습니다.

이 문서는 구현에 대한 초기 이해를 제공하기 위한 예제를 보여줍니다.
실제 운용을 위한 것이 아니며, AWS에서 추가 보안이 필요합니다.

예를 들어, 다음과 같은 두 개의 AWS 보안 그룹을 원할 수 있습니다:

GitLab Runner를 호스팅하는 EC2 인스턴스에서 사용되며,
특정 외부 IP 범위(관리용 액세스)로부터만 SSH 연결을 허용합니다.
Fargate Tasks에 적용되며,
EC2 인스턴스로부터 SSH 트래픽만 허용합니다.

또한, ECS 작업은 IAM 권한이 필요합니다(only for AWS ECR)
또는 작업용 개인 레지스트리 인증 필요
ECR 외의 개인 레지스트리에 대해서는.

AWS 인프라를 자동으로 프로비저닝 및 설정하는 데 CloudFormation 또는 Terraform을 사용할 수 있습니다.

CI/CD 작업은 .gitlab-ci.yml 파일의 image: 키워드 값이 아닌
ECS 작업에서 정의한 이미지를 사용합니다. 이 구성은 실행기 관리자의 여러 인스턴스가 생성되거나
대규모 빌드 컨테이너가 발생할 수 있습니다. AWS는 이 문제를 인식하고 GitLab은 이 문제의 해결을 추적하고 있습니다.
공식 AWS EKS 블루프린트를 따라 AWS EKS 클러스터를 생성하는 것을 고려해볼 수 있습니다.

Fargate는 컨테이너 호스트를 추상화하고,
컨테이너 호스트 속성의 설정 가능성을 제한합니다. 이로 인해 Fargate에서는 디스크 또는 네트워크에 대한 높은 IO가 필요한 실행기 작업에 영향을 미칩니다.
따라서 Fargate에서 GitLab Runner를 사용하기 전에, CPU, 메모리, 디스크 IO 또는 네트워크 IO에
높은 또는 극한의 계산 특성이 있는 실행기 작업이 Fargate에 적합한지 확인하세요.

전제 요구사항

시작하기 전에 다음이 필요합니다:

EC2, ECS 및 ECR 리소스를 만들고 구성할 수 있는 AWS IAM 사용자.
AWS VPC 및 서브넷.
하나 이상의 AWS 보안 그룹.

단계 1: AWS Fargate 작업을 위한 컨테이너 이미지 준비

컨테이너 이미지를 준비합니다. 이 이미지를 업로드하여 GitLab 작업이 실행될 때 사용할
레지스트리에 이미지를 배포합니다.

이미지에 CI 작업을 빌드하는 데 필요한 도구가 포함되어 있는지 확인합니다.
예를 들어 Java 프로젝트의 경우 Java JDK와 Maven 또는 Gradle과 같은 빌드 도구가 필요합니다.
Node.js 프로젝트의 경우 node와 npm이 필요합니다.
GitLab Runner가 포함되어 있는지 확인합니다. 실행기 문서의 Run 단계 섹션을 참조하세요.
컨테이너 이미지가 공개 키 인증을 통해 SSH 연결을 수락할 수 있는지 확인합니다.
실행기는 .gitlab-ci.yml 파일에 정의된 빌드 명령을 Fargate의 컨테이너로 보내기 위해
이 연결을 사용합니다. SSH 키는 Fargate 드라이버에서 자동으로 관리됩니다. 컨테이너는
SSH_PUBLIC_KEY 환경 변수에서 키를 수락할 수 있어야 합니다.

Debian 예제를 확인하세요(GitLab Runner 및 SSH 구성 포함). Node.js 예제를 확인하세요.

단계 2: 컨테이너 이미지를 레지스트리에 푸시

이미지를 만든 후, ECS 작업 정의에서 사용할 레지스트리에 이미지를 게시합니다.

ECR에 리포지터리를 만들고 이미지를 푸시하려면, Amazon ECR Repositories 문서를 따르세요.
AWS CLI를 사용하여 이미지를 ECR에 푸시하려면, AWS CLI를 사용한 Amazon ECR 시작 문서를 따르세요.
GitLab 컨테이너 레지스트리를 사용하려면,
Debian 또는 Node.js
예제를 사용할 수 있습니다. Debian 이미지는 registry.gitlab.com/tmaczukin-test-projects/fargate-driver-debian:latest에
NodeJS 예제 이미지는 registry.gitlab.com/aws-fargate-driver-demo/docker-nodejs-gitlab-ci-fargate:latest에 발행됩니다.

단계 3: GitLab Runner용 EC2 인스턴스 생성

이제 AWS EC2 인스턴스를 생성하세요. 다음 단계에서는 GitLab Runner를 설치합니다.

https://console.aws.amazon.com/ec2/v2/home#LaunchInstanceWizard로 이동합니다.
인스턴스에서 Ubuntu Server 18.04 LTS AMI를 선택합니다.
선택한 AWS 지역에 따라 이름이 다를 수 있습니다.
인스턴스 유형에서 t2.micro를 선택합니다. 다음: 인스턴스 세부정보 구성을 클릭합니다.
인스턴스 수는 기본값으로 남겨 둡니다.
네트워크에서 VPC를 선택합니다.
퍼블릭 IPv4 주소 자동 할당을 사용으로 설정합니다.
IAM 역할에서 새 IAM 역할 생성을 클릭합니다. 이 역할은 테스트 목적으로만 사용되며 안전하지 않습니다.
1. 역할 생성을 클릭합니다.
2. AWS 서비스를 선택하고 일반적인 사용 사례 아래에서 EC2를 클릭한 후 다음: 권한 부여를 클릭합니다.
3. AmazonECS_FullAccess 정책의 확인란을 선택합니다. 다음: 태그 추가를 클릭합니다.
4. 다음: 검토를 클릭합니다.
5. IAM 역할에 이름(예: fargate-test-instance)을 입력하고 역할 생성을 클릭합니다.
인스턴스를 생성 중인 브라우저 탭으로 돌아갑니다.
새 IAM 역할 생성의 좌측에 있는 새로고침 버튼을 클릭합니다. fargate-test-instance 역할을 선택합니다. 다음: 스토리지 추가를 클릭합니다.
다음: 태그 추가를 클릭합니다.
다음: 보안 그룹 구성을 클릭합니다.
새 보안 그룹 생성을 선택하고 fargate-test로 이름을 지정하고
SSH에 대한 규칙이 정의되어 있는지 확인합니다(유형: SSH, 프로토콜: TCP, 포트 범위: 22).
내부 및 외부 규칙을 위한 IP 범위를 지정해야 합니다.
검토 및 시작을 클릭합니다.
시작을 클릭합니다.
선택 사항. 새 키페어 생성을 선택하고 fargate-runner-manager로 이름을 지정한 다음 키페어 다운로드 버튼을 클릭합니다.
SSH용 개인 키가 컴퓨터에 다운로드됩니다(브라우저에서 구성한 디렉터리를 확인하세요).
인스턴스 시작을 클릭합니다.
인스턴스 보기를 클릭합니다.
인스턴스가 실행될 때까지 기다립니다. IPv4 퍼블릭 IP 주소를 확인하세요.

단계 4: EC2 인스턴스에 GitLab 러너 설치 및 구성

이제 Ubuntu 인스턴스에 GitLab 러너를 설치하세요.

GitLab 프로젝트의 설정 > CI/CD로 이동하고 러너 섹션을 확장합니다. 특정 러너 매뉴얼으로 설정 아래에서 등록 토큰을 메모하세요.
키 파일이 올바른 권한을 갖고 있는지 확인하고 다음 명령을 실행하여 권한을 변경하세요: chmod 400 path/to/downloaded/key/file.
다음 명령을 사용하여 생성한 EC2 인스턴스에 SSH로 연결하세요:
```
ssh ubuntu@[ip_address] -i path/to/downloaded/key/file
```

연결에 성공하면 다음 명령을 실행하세요:

sudo mkdir -p /opt/gitlab-runner/{metadata,builds,cache}
curl -s "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh" | sudo bash
sudo apt install gitlab-runner

아래 명령을 사용하여 단계 1에서 메모한 GitLab URL과 등록 토큰으로 명령을 실행하세요.

sudo gitlab-runner register --url "https://gitlab.com/" --registration-token TOKEN_HERE --name fargate-test-runner --run-untagged --executor custom -n

sudo vim /etc/gitlab-runner/config.toml을 실행하고 아래 내용을 추가하세요:

concurrent = 1
check_interval = 0
   
[session_server]
  session_timeout = 1800
   
[[runners]]
  name = "fargate-test"
  url = "https://gitlab.com/"
  token = "__REDACTED__"
  executor = "custom"
  builds_dir = "/opt/gitlab-runner/builds"
  cache_dir = "/opt/gitlab-runner/cache"
  [runners.custom]
    volumes = ["/cache", "/path/to-ca-cert-dir/ca.crt:/etc/gitlab-runner/certs/ca.crt:ro"]
    config_exec = "/opt/gitlab-runner/fargate"
    config_args = ["--config", "/etc/gitlab-runner/fargate.toml", "custom", "config"]
    prepare_exec = "/opt/gitlab-runner/fargate"
    prepare_args = ["--config", "/etc/gitlab-runner/fargate.toml", "custom", "prepare"]
    run_exec = "/opt/gitlab-runner/fargate"
    run_args = ["--config", "/etc/gitlab-runner/fargate.toml", "custom", "run"]
    cleanup_exec = "/opt/gitlab-runner/fargate"
    cleanup_args = ["--config", "/etc/gitlab-runner/fargate.toml", "custom", "cleanup"]

Self-Managed형 인스턴스 및 프라이빗 CA가 있는 경우 다음 라인을 추가하세요:

       volumes = ["/cache", "/path/to-ca-cert-dir/ca.crt:/etc/gitlab-runner/certs/ca.crt:ro"]

인증서 신뢰에 대한 자세한 내용을 확인하세요.

아래의 config.toml 파일 섹션은 등록 명령에 의해 생성되었습니다. 변경하지 마세요.

concurrent = 1
check_interval = 0
   
[session_server]
  session_timeout = 1800
   
name = "fargate-test"
url = "https://gitlab.com/"
token = "__REDACTED__"
executor = "custom"

sudo vim /etc/gitlab-runner/fargate.toml을 실행하고 아래 내용을 추가하세요:
```
LogLevel = "info"
LogFormat = "text"
   
[Fargate]
  Cluster = "test-cluster"
  Region = "us-east-2"
  Subnet = "subnet-xxxxxx"
  SecurityGroup = "sg-xxxxxxxxxxxxx"
  TaskDefinition = "test-task:1"
  EnablePublicIP = true
   
[TaskMetadata]
  Directory = "/opt/gitlab-runner/metadata"
   
[SSH]
  Username = "root"
  Port = 22
```
- Cluster의 값을 확인하고 TaskDefinition의 이름을 확인하세요. 이 예시에서는 test-task 및 :1이 리비전 번호로 표시되었습니다. 리비전 번호가 지정되지 않은 경우 가장 최근의 활성 리비전이 사용됩니다.
- 리전을 선택하세요. 러너 관리자 인스턴스에서 Subnet값을 가져오세요.
- 보안 그룹 ID를 찾으려면:
  1. AWS에서 인스턴스 디렉터리에서 생성한 EC2 인스턴스를 선택합니다. 세부 정보가 표시됩니다.
  2. 보안 그룹에서 생성한 그룹의 이름을 클릭하세요.
  3. 보안 그룹 ID를 복사하세요.
  프로덕션 설정에서는 AWS 지침에 따라 보안 그룹을 설정하고 사용하세요.
- EnablePublicIP가 true로 설정된 경우 작업 컨테이너의 공개 IP가 수집되어 SSH 연결을 수행합니다.
- EnablePublicIP가 false로 설정된 경우:
  - Fargate 드라이버는 작업 컨테이너의 프라이빗 IP를 사용합니다. false로 설정된 경우에 연결을 설정하려면 VPC의 보안 그룹은 SSH(포트 22)에 대한 인바운드 규칙이 있어야 합니다. 소스는 VPC CIDR입니다.
  - 외부 의존성을 가져오려면 프로비저닝된 AWS Fargate 컨테이너는 공개 인터넷에 대한 액세스 권한이 있어야 합니다. AWS Fargate 컨테이너에 공개 인터넷 액세스를 제공하려면 VPC에 NAT 게이트웨이를 사용할 수 있습니다.
- SSH 서버의 포트 번호은 선택 사항입니다. 생략된 경우 기본 SSH 포트(22)가 사용됩니다.
- 섹션 설정에 대한 자세한 정보는 Fargate 드라이버 문서를 참조하세요.

Fargate 드라이버를 설치하세요:

sudo curl -Lo /opt/gitlab-runner/fargate "https://gitlab-runner-custom-fargate-downloads.s3.amazonaws.com/latest/fargate-linux-amd64"
sudo chmod +x /opt/gitlab-runner/fargate

단계 5: ECS Fargate 클러스터 생성

Amazon ECS 클러스터는 ECS 컨테이너 인스턴스의 그룹화입니다.

https://console.aws.amazon.com/ecs/home#/clusters로 이동합니다.
클러스터 생성을 클릭합니다.
네트워킹 전용 유형을 선택합니다. 다음 단계를 클릭합니다.
test-cluster로 명명합니다(위에 있는 fargate.toml과 동일).
생성을 클릭합니다.
클러스터 보기를 클릭합니다. Cluster ARN 값에서 리전 및 계정 ID 부분을 기록하세요.
클러스터 업데이트 버튼을 클릭합니다.
기본 수용 공급자 전략 옆에 있는 다른 공급자 추가를 클릭하고 FARGATE를 선택합니다. 업데이트를 클릭합니다.

Amazon ECS Fargate 클러스터 설정 및 작업 방법에 대한 자세한 지침은 AWS 문서를 참조하세요.

단계 6: ECS 작업 정의 생성

이 단계에서는 CI 빌드에 사용할 컨테이너 이미지를 참조하는 유형이 Fargate인 작업 정의를 만듭니다.

https://console.aws.amazon.com/ecs/home#/taskDefinitions로 이동합니다.
새 작업 정의 생성을 클릭합니다.
FARGATE을 선택하고 다음 단계를 클릭합니다.
test-task로 명명합니다. (참고: 이름은 fargate.toml 파일에 정의된 값과 동일하지만 :1은 없는 값입니다).
작업 메모리(GB) 및 작업 CPU(vCPU) 값 선택하세요.
컨테이너 추가를 클릭하고 다음을 수행하세요:
1. ci-coordinator로 명명하여 Fargate 드라이버가 SSH_PUBLIC_KEY 환경 변수를 주입할 수 있게 합니다.
2. 이미지 정의(예: registry.gitlab.com/tmaczukin-test-projects/fargate-driver-debian:latest)를 지정하세요.
3. 22/TCP의 포트 매핑을 정의하세요.
4. 추가를 클릭하세요.
생성을 클릭합니다.
작업 정의 보기를 클릭합니다.

단일 Fargate 작업은 하나 이상의 컨테이너를 시작할 수 있습니다. Fargate 드라이버는 ci-coordinator 이름을 가진 컨테이너에만 SSH_PUBLIC_KEY 환경 변수를 주입합니다. Fargate 드라이버에서 사용하는 모든 작업 정의에 이 이름을 가진 컨테이너가 있어야 합니다. 이 이름을 가진 컨테이너는 SSH 서버와 GitLab 러너 요구 사항이 설치된 컨테이너여야 합니다.

작업 정의 설정과 작업 방법에 대한 자세한 지침은 AWS 문서를 참조하세요.

AWS Amazon ECS 작업 실행 IAM 역할 및 작업용 개인 레지스트리 인증 문서를 참조하여 AWS ECR에서 이미지를 시작하는 데 필요한 ECS 서비스 권한 및 ECS가 GitLab 인스턴스에 호스팅된 개인 레지스트리를 인증하는 방법에 대해 자세히 알아보세요.

이제 러너 관리자와 Fargate 드라이버가 구성되어 AWS Fargate에서 작업을 실행할 준비가 되었습니다.

단계 7: 구성 테스트

이제 구성이 사용할 준비가되어야합니다.

GitLab 프로젝트에서 간단한 .gitlab-ci.yml 파일을 만듭니다.

test:
  script:
    - echo "It works!"
    - for i in $(seq 1 30); do echo "."; sleep 1; done

프로젝트의 CI/CD > 파이프라인으로 이동합니다.
파이프라인 실행을 클릭합니다.
브랜치를 업데이트하고 필요한 변수를 설정한 다음 파이프라인 실행을 클릭합니다.

.gitlab-ci.yml 파일의 image 및 service 키워드는 무시됩니다. 러너(runner)는 작업 정의에 지정된 값만 사용합니다.

정리

AWS Fargate와 사용자 지정 엑스큐터를 테스트 한 후 정리하려면 다음 객체들을 제거하십시오:

단계 3에서 작성한 EC2 인스턴스, 키페어, IAM 역할 및 보안 그룹.
단계 5에서 작성한 ECS Fargate 클러스터.
단계 6에서 작성한 ECS 작업 정의.

개인 AWS Fargate 작업 구성

높은 수준의 보안을 보장하기 위해 개인 AWS Fargate 작업을 구성합니다. 이 구성에서 엑스큐터는 내부 AWS IP 주소만 사용하며 AWS에서만 아웃바운드 트래픽을 허용하여 CI 작업이 개인 AWS Fargate 인스턴스에서 실행됩니다.

개인 AWS Fargate 작업을 구성하려면 다음 단계를 완료하여 AWS를 구성하고 개인 서브넷에서 AWS Fargate 작업을 실행합니다.

기존의 공용 서브넷이 VPC 주소 범위에서 모든 IP 주소를 예약하지 않았는지 확인하십시오. VPC 및 서브넷의 CIRD 주소 범위를 검사하십시오. 서브넷 CIRD 주소 범위가 VPC의 CIRD 주소 범위의 하위 집합인 경우 단계 2 및 4를 건너뜁니다. 그렇지 않으면 VPC에 무료 주소 범위가 없습니다. 따라서 VPC와 공용 서브넷을 삭제하고 다시 만들어야합니다:
1. 기존 서브넷 및 VPC를 삭제합니다.
2. 삭제 한 VPC와 동일한 구성으로 VPC를 만듭니다 예를 들어 10.0.0.0/23와 같은 CIRD 주소를 업데이트합니다.
3. 삭제 한 서브넷과 동일한 구성으로 공용 서브넷을 만듭니다. VPC의 주소 범위의 하위 집합 인 CIRD 주소를 사용합니다. 예를 들어 10.0.0.0/24입니다.
공용 서브넷과 동일한 구성으로 개인 서브넷을 만듭니다. 공용 서브넷 범위와 중첩되지 않는 CIRD 주소 범위를 사용하십시오. 예를 들어 10.0.1.0/24입니다.
NAT 게이트웨이를 생성하고 공용 서브넷에 배치합니다.
개인 서브넷의 라우팅 테이블을 수정하여 대상 0.0.0.0/0이 NAT 게이트웨이를 가리키도록합니다.

farget.toml 구성을 업데이트하십시오.

Subnet = "개인-서브넷-id"
EnablePublicIP = false
UsePublicIP = false

fargate 작업에 연결된 IAM 역할에 다음 인라인 정책을 추가합니다(일반적으로 fargate 작업에 연결된 IAM 역할의 이름은 ecsTaskExecutionRole이며 이미 존재해야합니다).

{
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "secretsmanager:GetSecretValue",
                "kms:Decrypt",
                "ssm:GetParameters"
            ],
            "Resource": [
                "arn:aws:secretsmanager:*:<account-id>:secret:*",
                "arn:aws:kms:*:<account-id>:key/*"
            ]
        }
    ]
}

AWS 구성 대화 상자에서 보안 그룹의 “인바운드 규칙”을 해당 보안 그룹 자체를 참조하도록 변경하십시오.
- 유형을 ssh로 설정합니다.
- 소스를 사용자 정의로 설정합니다.
- 보안 그룹을 선택합니다.
- 모든 호스트에서 SSH 액세스를 허용하는 기존 인바운드 규칙을 제거합니다.

기존의 인바운드 규칙을 제거하면 Amazon Elastic Compute Cloud 인스턴스에 SSH로 연결할 수 없습니다.

더 많은 정보는 다음 AWS 문서를 참조하십시오:

문제 해결

구성 테스트 시 `클러스터에 컨테이너 인스턴스가 없음` 오류

error="starting new Fargate task: running new task on Fargate: error starting AWS Fargate Task: InvalidParameterException: No Container Instances were found in your cluster."

AWS Fargate 드라이버는 기본 수용 공급자 전략이 ECS 클러스터와 연결되어야합니다.

추가 읽기 자료:

각 Amazon ECS 클러스터에는 기본 수용 공급자 전략이 연결됩니다. 다른 수용 공급자 전략이나 실행 유형이 지정되지 않으면 클러스터는 작업 실행 또는 서비스 생성 시에이 전략을 사용합니다.
capacityProviderStrategy가 지정된 경우 launchType 매개변수는 생략해야합니다. capacityProviderStrategy 또는 launchType이 지정되지 않은 경우 클러스터의 defaultCapacityProviderStrategy가 사용됩니다.

작업 실행 중 메타데이터 `파일이 존재하지 않음` 오류

Application execution failed PID=xxxxx error="obtaining information about the running task: trying to access file \"/opt/gitlab-runner/metadata/<runner_token>-xxxxx.json\": file does not exist" cleanup_std=err job=xxxxx project=xx runner=<runner_token>

IAM 역할 정책이 올바르게 구성되어있고 /opt/gitlab-runner/metadata/에 메타데이터 JSON 파일을 작성할 수 있도록 권한이 있는지 확인하십시오. 비 프로덕션 환경에서 테스트하려면 AmazonECS_FullAccess 정책을 사용하십시오. 조직의 보안 요구 사항에 따라 IAM 역할 정책을 검토하십시오.

작업 실행 중 `연결 시간 초과` 오류

Application execution failed PID=xxxx error="executing the script on the remote host: executing script on container with IP \"172.x.x.x\": connecting to server: connecting to server \"172.x.x.x:22\" as user \"root\": dial tcp 172.x.x.x:22: connect: connection timed out"

EnablePublicIP가 false로 구성된 경우 VPC 보안 그룹이 SSH 연결을 허용하는 인바운드 규칙을 가져야합니다. AWS Fargate 작업 컨테이너는 GitLab 러너 EC2 인스턴스에서 SSH 트래픽을 수락해야합니다.

작업 실행 시 `connection refused` 오류

Application execution failed PID=xxxx error="executing the script on the remote host: executing script on container with IP \"10.x.x.x\": connecting to server: connecting to server \"10.x.x.x:22\" as user \"root\": dial tcp 10.x.x.x:22: connect: connection refused"

작업 컨테이너가 포트 22를 노출하고 포트 맵핑이 단계 6: ECS 작업 정의 생성의 지침에 따라 구성되어 있는지 확인하세요. 포트가 노출되어 있고 컨테이너가 구성되어 있을 경우 다음을 수행하세요:

Amazon ECS > 클러스터 > 작업에서 컨테이너에 대한 오류를 확인하세요.
Stopped 상태의 작업을 확인하고 최신 실패 항목을 확인하세요. 로그 탭에 컨테이너 실패에 대한 자세한 정보가 있습니다.

또는 Docker 컨테이너를 로컬에서 실행할 수 있는지 확인하세요.

`ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain` 오류 발생 시

오래된 버전의 AWS Fargate 드라이버로 인해 지원되지 않는 키 유형이 사용되는 경우 다음 오류가 발생합니다.

Application execution failed PID=xxxx error="executing the script on the remote host: executing script on container with IP \"172.x.x.x\": connecting to server: connecting to server \"172.x.x.x:22\" as user \"root\": ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain"

이 문제를 해결하려면 GitLab Runner EC2 인스턴스에 최신 AWS Fargate 드라이버를 설치하십시오:

sudo curl -Lo /opt/gitlab-runner/fargate "https://gitlab-runner-custom-fargate-downloads.s3.amazonaws.com/latest/fargate-linux-amd64"
sudo chmod +x /opt/gitlab-runner/fargate

AWS Fargate에서 GitLab CI 자동 스케일링

전제 요구사항

단계 1: AWS Fargate 작업을 위한 컨테이너 이미지 준비

단계 2: 컨테이너 이미지를 레지스트리에 푸시

단계 3: GitLab Runner용 EC2 인스턴스 생성

단계 4: EC2 인스턴스에 GitLab 러너 설치 및 구성

단계 5: ECS Fargate 클러스터 생성

단계 6: ECS 작업 정의 생성

단계 7: 구성 테스트

정리

개인 AWS Fargate 작업 구성

문제 해결

구성 테스트 시 `클러스터에 컨테이너 인스턴스가 없음` 오류

작업 실행 중 메타데이터 `파일이 존재하지 않음` 오류

작업 실행 중 `연결 시간 초과` 오류

작업 실행 시 `connection refused` 오류

`ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain` 오류 발생 시

도움말

기능 사용 가능성과 제품 평가판

도움받기

AWS Fargate에서 GitLab CI 자동 스케일링

전제 요구사항

단계 1: AWS Fargate 작업을 위한 컨테이너 이미지 준비

단계 2: 컨테이너 이미지를 레지스트리에 푸시

단계 3: GitLab Runner용 EC2 인스턴스 생성

단계 4: EC2 인스턴스에 GitLab 러너 설치 및 구성

단계 5: ECS Fargate 클러스터 생성

단계 6: ECS 작업 정의 생성

단계 7: 구성 테스트

정리

개인 AWS Fargate 작업 구성

문제 해결

구성 테스트 시 클러스터에 컨테이너 인스턴스가 없음 오류

작업 실행 중 메타데이터 파일이 존재하지 않음 오류

작업 실행 중 연결 시간 초과 오류

작업 실행 시 connection refused 오류

ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain 오류 발생 시

도움말

기능 사용 가능성과 제품 평가판

도움받기

구성 테스트 시 `클러스터에 컨테이너 인스턴스가 없음` 오류

작업 실행 중 메타데이터 `파일이 존재하지 않음` 오류

작업 실행 중 `연결 시간 초과` 오류

작업 실행 시 `connection refused` 오류

`ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain` 오류 발생 시