개시하다

제목과 같이 "AWS Batch가 만든 EC2 인스턴스는 ECS 클러스터에 들어가지 않습니다!"이런 미혹 방법은 마침내 해결되었다.
앞으로 같은 상황의 사람들을 도와서 해결할 수 있었으면 좋겠어요.

TL;DR

선택한 EC2 조사 및 자신의 영역에 대응하는 EC2

선택

Batch 실행 환경에 할당된 서브넷이 무엇인지 확인

인터넷 GW에 대한 루트맵이 있고'공용 IPv4 주소의 자동 분배'는'예'

이다

라우팅 테이블에 인터넷 GW에 대한 NAT 게이트웨이

첫 번째 푹 빠진 곳 → 원인: AWS Batch가 선택한 EC2 실례 유형이 도쿄 지역을 지원하지 않습니다

현상.

AWS Batch에서 Computeenvironments, Job queue, Job definitions를 제작하고 Job을 실행한 뒤'RUNNABLE'상태를 유지하고 있다.
이 경우 EC2 인스턴스는 구현되지 않습니다.AutoScalling Group의 설정을 보면 다음과 같은 정보가 표시됩니다.

오류 메시지 텍스트
a user request created an AutoScalingGroup changing the desired capacity from 0 to 1.
an instance was started in response to a difference between desired and actual capacity, increasing the capacity from 0 to 1

원인과 해결

AWS Batch가 선택한 EC2 인스턴스 유형(a1 시스템)이 도쿄 지역을 지원하지 않기 때문이다.
AWS Batch의ompute environments를 다시 설정하여 참조[EC2] 도쿄 지역에 구축할 수 있는 실례 유형의abilitian 분류 일람표의 글에 대응하는 실례 유형을 선택하여 오류를 해결했고 다음에 실행할 때 EC2 실례를 만들었습니다.

두 번째 미치광이 → 원인: Computeenvironments에서 선택한 서브넷이 외부 네트워크에 연결될 수 없습니다

현상.

첫 번째 문제를 해결하고 EC2 실례가 생겼지만 그 EC2 실례는AWS Batch가 관리하는 ECS 집단에 들어가지 않았고 Batch의 작업은 RUNNAMBLE의 상태가 되었다.

원인과 해결

조사하다.

나는 공식AWS Batch의 작업이 왜 RUNNABLE 상태에서 중지됩니까?의 문장을 확인했지만, 나는 이 문장의 항목에 문제가 없다는 것을 안다
인스턴스가 여전히 Amazon ECS 클러스터에 참여하지 않으면 인스턴스에 연결됩니다.다음은 Docker 데몬 및 Amazon ECS 컨테이너 에이전트의 상태를 확인합니다.
이 절차를 실시하였다.
AWS Batch가 제작한 EC2 인스턴스는 자체 가동아마존 ECS 컨테이너 에이전트된 Docker 용기를 알게 됐는데, 이 이동은 ECS 클러스터 이동을 의미한다.
AWS Batch에 킥보드 서버를 통해 시작한 EC2 인스턴스를 SSH로 진행해 Docker 컨테이너의 상태를 확인했다.

$ docker ps

이걸 확인하면 Docker 컨테이너가 제작되어 분실되었음을 알 수 있습니다.
거기서 일어났을 때 컨테이너 안의 일지를 확인했는데 다음과 같은 오류가 발견됐다.

$ docker logs -f ecs-agent
level=info time=2020-06-22T13:06:09Z msg="Loading configuration" module=agent.go
level=info time=2020-06-22T13:06:09Z msg="Image excluded from cleanup: amazon/amazon-ecs-agent:latest" module=parse.go
level=info time=2020-06-22T13:06:09Z msg="Image excluded from cleanup: amazon/amazon-ecs-pause:0.1.0" module=parse.go
level=info time=2020-06-22T13:06:09Z msg="Amazon ECS agent Version: 1.36.2, Commit: 0e4174f6" module=agent.go
level=info time=2020-06-22T13:06:09Z msg="Creating root ecs cgroup: /ecs" module=init_linux.go
level=info time=2020-06-22T13:06:09Z msg="Creating cgroup /ecs" module=cgroup_controller_linux.go
level=info time=2020-06-22T13:06:09Z msg="Event stream ContainerChange start listening..." module=eventstream.go
level=info time=2020-06-22T13:06:09Z msg="Loading state!" module=state_manager.go
level=info time=2020-06-22T13:06:10Z msg="Registering Instance with ECS" module=agent.go
level=info time=2020-06-22T13:06:10Z msg="Remaining mem: 3725" module=client.go
level=error time=2020-06-22T13:06:31Z msg="Unable to register as a container instance with ECS: RequestError: send request failed\ncaused by: Post https://ecs.ap-northeast-1.amazonaws.com/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)" module=client.go
level=error time=2020-06-22T13:06:31Z msg="Error registering: RequestError: send request failed\ncaused by: Post https://ecs.ap-northeast-1.amazonaws.com/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)" module=agent.go

분명히 인터넷 문제의 문구다.sudo yum update가 실행되면 실행되지 않습니다.네트워크 문제가 확실합니다.
ECS 인스턴스가 클러스터에 등록되어 있지 않습니다.의 글을 만났는데 네트워크의 상황을 보면 루트표의 위치가 좋지 않은 것을 발견했다. 왜냐하면 AWS Batch의Computeenvironments가 가지고 있는 서브넷이 외부 네트워크에 연결되지 못하기 때문이다.

해결책

그 1

공용 IPv4 주소를 자동으로 할당하는 서브넷을 만들고 ComputeEnvironment를 서브넷에 할당합니다.

두 번째

공식공용 서브넷 및 개인 서브넷이 있는 VPC(NAT)의 글을 참고하여 NAT 게이트웨이는 Target의 루트 테이블로 만듭니다.그 루트 테이블이 있는 서브넷을 만들어서 그 서브넷을AWS Batch의 Computeenvironments와 연결시키면 Job은 안전하게 운행할 수 있습니다.
주의점은 우리가 NAT 스위치를 저장하고 없으면 그 부분의 비용이 첫 번째 것보다 비싸다는 것이다.

참고 자료

https://qiita.com/aikan-umetsubo/items/e4cf1c6a092d82503c63

https://docs.aws.amazon.com/batch/latest/userguide/troubleshooting.html#job_stuck_in_runnable

https://aws.amazon.com/jp/premiumsupport/knowledge-center/batch-job-stuck-runnable-status/