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

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

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

GitLab의 커스텀 실행기 드라이버는
AWS Fargate에서
각각의 GitLab CI 작업을 실행하기 위해 Amazon Elastic Container Service(ECS)에서
컨테이너를 자동으로 시작합니다.

이 문서의 작업을 완료하면, 실행기는 GitLab에서 시작된 작업을 실행할 수 있습니다.

GitLab에서 커밋이 이루어질 때마다 GitLab 인스턴스는 새로운 작업이
가능하다는 것을 러너에 알립니다.

그런 다음, 러너는 AWS ECS에서 구성한 작업 정의에 따라
대상 ECS 클러스터에서 새로운 작업을 시작합니다.

AWS ECS 작업 정의를 사용하여 모든 Docker 이미지를 사용할 수 있으므로,
AWS Fargate에서 실행할 수 있는 빌드 유형에 완전한 유연성이 있습니다.

이 문서는 구현에 대한 초기 이해를 제공하기 위한 예시를 보여줍니다.

생산 사용을 위한 것이 아니며, AWS에서 추가 보안이 필요합니다.

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

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

또한, 비공식 컨테이너 레지스트리의 경우 ECS 작업은
AWS ECR 전용 IAM 권한이 필요하거나
비공식 레지스트리의 작업에 대한 개인 레지스트리 인증이 필요합니다.

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

CI/CD 작업은 .gitlab-ci.yml 파일의 image: 키워드 값이 아니라
ECS 작업에 정의된 이미지를 사용합니다.

이 구성은 러너 관리자의 여러 인스턴스 또는 대형 빌드 컨테이너를 초래할 수 있습니다.

AWS는 이 문제를 인식하고 있으며 GitLab은 해결 상황을 추적하고 있습니다.

공식 AWS EKS Blueprints를 따라 EKS 클러스터를 생성하는 것을 고려할 수 있습니다.

Fargate는 컨테이너 호스트를 추상화하여 컨테이너 호스트 속성의 구성 가능성을 제한합니다.

이것은 디스크 또는 네트워크에 대한 높은 IO가 필요한 러너 작업에 영향을 미치며,
이러한 속성은 Fargate에서 제한되거나 구성할 수 없습니다.

GitLab Runner를 Fargate에서 사용하기 전에 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 파일에 정의된 빌드 명령을
AWS Fargate의 컨테이너로 전송합니다. SSH 키는 Fargate 드라이버에 의해 자동으로 관리됩니다.
컨테이너는 SSH_PUBLIC_KEY 환경 변수로부터 키를 수락할 수 있어야 합니다.

GitLab Runner와 SSH 구성의 Debian 예제를
확인하십시오. Node.js의 예제도 확인할 수 있습니다.

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

이미지를 생성한 후, ECS 작업 정의에 사용하기 위해 이미지를 컨테이너 레지스트리에 게시합니다.

ECR에 리포지토리를 생성하고 이미지를 푸시하려면, Amazon ECR 리포지토리 문서를 참조하세요.
AWS CLI를 사용하여 이미지를 ECR에 푸시하려면, AWS CLI를 사용하여 Amazon ECR 시작하기 문서를 참조하세요.
GitLab Container Registry를 사용하려면, Debian 또는 NodeJS 예제를 사용할 수 있습니다. 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 리전(Region)에 따라 다를 수 있습니다.
인스턴스 유형으로 t2.micro를 선택합니다. 다음: 인스턴스 세부 정보 구성을 클릭합니다.
인스턴스 수에 대해 기본값을 그대로 둡니다.
네트워크에서 자신의 VPC를 선택합니다.
공용 IP 자동 할당을 사용으로 설정합니다.
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 Runner 설치 및 구성

이제 Ubuntu 인스턴스에 GitLab Runner를 설치합니다.

GitLab 프로젝트의 Settings > CI/CD로 가서 Runners 섹션을 확장합니다.
Set up a specific Runner manually 아래에 있는 등록 토큰을 기록해 둡니다.
키 파일에 올바른 권한이 있는지 확인하려면 다음을 실행합니다.
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"]

개인 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. Security groups에서 생성한 그룹의 이름을 클릭합니다.
  3. Security group ID를 복사합니다.
  프로덕션 설정에서는
  AWS 가이드라인을 따라 보안 그룹을 설정하고 사용합니다.
- EnablePublicIP가 true로 설정되면, 작업 컨테이너의 공용 IP가 수집되어 SSH 연결을 수행합니다.
- EnablePublicIP가 false로 설정되면:
  - Fargate 드라이버는 작업 컨테이너의 개인 IP를 사용합니다. false로 설정된 경우 연결을 설정하려면 VPC의 보안 그룹에 Port 22(SSH)에 대한 수신 규칙이 필요하며, 출처는 VPC CIDR이어야 합니다.
  - 외부 종속성을 가져오기 위해 프로비저닝된 AWS Fargate 컨테이너는 공용 인터넷에 접근할 수 있어야 합니다. AWS Fargate 컨테이너에 대한 공용 인터넷 액세스를 제공하려면 VPC에서 NAT Gateway를 사용할 수 있습니다.
- 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로 이동합니다.
Create Cluster를 클릭합니다.
Networking only 유형을 선택합니다. Next step을 클릭합니다.
test-cluster라고 이름을 지정합니다 (fargate.toml의 이름과 동일).
Create를 클릭합니다.
View cluster를 클릭합니다. Cluster ARN 값에서 지역 및 계정 ID 부분을 기록해 둡니다.
Update Cluster 버튼을 클릭합니다.
Default capacity provider strategy 옆에서 Add another provider를 클릭하고 FARGATE를 선택합니다. Update를 클릭합니다.

AWS 문서를 참조하여 ECS Fargate에서 클러스터를 설정하고 작업하는 방법에 대한 자세한 지침을 확인하세요.

6단계: ECS 작업 정의 만들기

이 단계에서는 CI 빌드에 사용할 컨테이너 이미지에 대한 참조가 포함된 Fargate 유형의 작업 정의를 생성합니다.

https://console.aws.amazon.com/ecs/home#/taskDefinitions로 이동합니다.
Create new Task Definition을 클릭합니다.
FARGATE를 선택한 다음 Next step을 클릭합니다.
test-task라고 이름을 지정합니다. (참고: 이름은 fargate.toml 파일에 정의된 값과 동일하지만 :1은 제외합니다.)
Task memory (GB) 및 Task CPU (vCPU)의 값을 선택합니다.
Add container를 클릭합니다. 그런 다음:
1. ci-coordinator라고 이름을 지정하여 Fargate 드라이버가 SSH_PUBLIC_KEY 환경 변수를 주입할 수 있도록 합니다.
2. 이미지를 정의합니다 (예: registry.gitlab.com/tmaczukin-test-projects/fargate-driver-debian:latest).
3. 22/TCP의 포트 매핑을 정의합니다.
4. Add를 클릭합니다.
Create를 클릭합니다.
View task definition을 클릭합니다.

경고:

단일 Fargate 작업은 하나 이상의 컨테이너를 시작할 수 있습니다.

Fargate 드라이버는 ci-coordinator 이름이 있는 컨테이너에만 SSH_PUBLIC_KEY 환경 변수를 주입합니다. Fargate 드라이버에서 사용하는 모든 작업 정의에 이 이름의 컨테이너가 있어야 합니다. 이 이름의 컨테이너는 위에서 설명한 대로 SSH 서버와 모든 GitLab Runner 요구 사항이 설치된 컨테이너여야 합니다.

AWS 문서를 참조하여 작업 정의를 설정하고 작업하는 방법에 대한 자세한 지침을 확인하세요.

AWS 문서 Amazon ECS 태스크 실행 IAM 역할을 참조하여 AWS ECR에서 이미지를 시작하는 데 필요한 ECS 서비스 권한에 대한 정보를 확인하세요.

AWS 문서 작업을 위한 개인 레지스트리 인증을 참조하여 ECS가 GitLab 인스턴스에 호스팅되는 개인 레지스트리에 대해 인증하는 방법에 대한 정보를 확인하세요.

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

7단계: 구성 테스트

이제 구성이 사용 준비가 완료되었습니다.

GitLab 프로젝트에서 간단한 .gitlab-ci.yml 파일을 생성합니다:

test:
  script:
    - echo "작동합니다!"
    - for i in $(seq 1 30); do echo "."; sleep 1; done

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

참고: .gitlab-ci.yml 파일의 image 및 service 키워드는 무시됩니다.

러너는 작업 정의에 지정된 값만 사용합니다.

정리

AWS Fargate로 사용자 지정 실행기를 테스트한 후 정리를 수행하려면, 다음 객체를 제거하세요:

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

개인 AWS Fargate 작업 구성

높은 수준의 보안을 보장하기 위해 개인 AWS Fargate 작업을 구성합니다.

이 구성에서는 실행기가 내부 AWS IP 주소만 사용하며, CI 작업이 개인 AWS Fargate 인스턴스에서 실행되도록 AWS에서만 아웃바운드 트래픽을 허용합니다.

개인 AWS Fargate 작업을 구성하려면, 다음 단계를 수행하여 AWS를 구성하고 개인 서브넷에서 AWS Fargate 작업을 실행하세요:

기존의 공용 서브넷이 VPC 주소 범위 내 모든 IP 주소를 예약하지 않았는지 확인합니다. VPC 및 서브넷의 CIRD 주소 범위를 검사합니다. 서브넷 CIRD 주소 범위가 VPC의 CIRD 주소 범위의 하위 집합인 경우, 2단계 및 4단계를 건너뜁니다. 그렇지 않으면 VPC에 사용할 수 있는 주소 범위가 없으므로 VPC와 공용 서브넷을 삭제하고 다시 생성해야 합니다:
1. 기존 서브넷과 VPC를 삭제합니다.
2. VPC 생성하여 삭제한 VPC와 동일한 구성으로 만들고 CIRD 주소를 업데이트합니다, 예를 들어 10.0.0.0/23.
3. 공용 서브넷 생성하여 삭제한 서브넷과 동일한 구성으로 만듭니다. VPC 주소 범위의 하위 집합인 CIRD 주소를 사용합니다, 예를 들어 10.0.0.0/24.
사설 서브넷 생성하여 공용 서브넷과 동일한 구성으로 만듭니다. 공용 서브넷 범위와 겹치지 않는 CIRD 주소 범위를 사용합니다, 예를 들어 10.0.1.0/24.
NAT 게이트웨이 생성하고 이를 공용 서브넷 내에 배치합니다.
приват 서브넷 라우팅 테이블을 수정하여 목적지 0.0.0.0/0가 NAT 게이트웨이를 가리키도록 합니다.

farget.toml 구성을 업데이트합니다:

Subnet = "private-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 문서를 참조하세요:

문제 해결

구성 테스트 시 `No Container Instances were found in your cluster` 오류

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가 사용됩니다.

작업 실행 시 `metadata file does not exist` 오류

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 역할 정책을 검토하십시오.

작업 실행 시 `connection timed out` 오류

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 Runner 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가 노출되어 있고, Step 6: Create an ECS task definition 지침에 따라 포트 매핑이 구성되어 있는지 확인하십시오. 포트가 노출되어 있고 컨테이너가 구성된 경우:

Amazon ECS > Clusters > Choose your task definition > Tasks에서 컨테이너에 대한 오류가 있는지 확인하십시오.
상태가 Stopped인 태스크를 보려면, 실패한 최신 태스크를 확인하십시오. logs 탭에서 컨테이너 실패에 대한 더 많은 세부 정보가 제공됩니다.

또는, 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 Runner 설치 및 구성

5단계: ECS Fargate 클러스터 만들기

6단계: ECS 작업 정의 만들기

7단계: 구성 테스트

정리

개인 AWS Fargate 작업 구성

문제 해결

구성 테스트 시 `No Container Instances were found in your cluster` 오류

작업 실행 시 `metadata file does not exist` 오류

작업 실행 시 `connection timed out` 오류

작업 실행 시 `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 Runner 설치 및 구성

5단계: ECS Fargate 클러스터 만들기

6단계: ECS 작업 정의 만들기

7단계: 구성 테스트

정리

개인 AWS Fargate 작업 구성

문제 해결

구성 테스트 시 No Container Instances were found in your cluster 오류

작업 실행 시 metadata file does not exist 오류

작업 실행 시 connection timed out 오류

작업 실행 시 connection refused 오류

ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain 작업 실행 시 발생

도움말

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

도움받기

구성 테스트 시 `No Container Instances were found in your cluster` 오류

작업 실행 시 `metadata file does not exist` 오류

작업 실행 시 `connection timed out` 오류

작업 실행 시 `connection refused` 오류

`ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain` 작업 실행 시 발생