모도리는 공부중

[AWS] Elastic Beanstalk으로 Node.js 앱 배포 트러블 슈팅 좌충우돌기 본문

내 지식 정리/날것 그 자체

[AWS] Elastic Beanstalk으로 Node.js 앱 배포 트러블 슈팅 좌충우돌기

공부하는 모도리 2023. 9. 9. 19:50
728x90
반응형

[ 목차 ]

     

     

    아래 과정은 IAM 유저도 만들지 않고 그냥 무작정 진행한 사람의 좌충우돌기를 담고 있습니다.


    정식 배포용으로는 도커 컨테이너를 이용하려고 하지만 개발 테스트 배포용으로는 조금 더 편리한 Elastic Beanstalk을 활용해보고 싶은 마음에 여러가지 글을 읽어보며 실습해보게 됐다. 아래 진행 순서는 Elastic Beanstalk으로 어플리케이션과 환경 생성부터 진행한 다음 파이프라인을 만들어 연결하는 방식으로 진행될 것이다.

     

    1. Elastic Beanstalk 어플리케이션 생성 및 환경 구성

    애플리케이션과 환경 구성

    환경 구성만 먼저 진행해보자.

    플랫폼을 선택해주자. 현재 전 세계적으로 npm과 GLIBC 버전 호환 등의 문제가 있어 node version 18이 안정화(LTS) 버전이라고는 하나 16을 쓸 수 밖에 없는 추세인 것 같다. 나 또한 이런 문제를 겪었으므로 16을 선택하려고 열었더니,

    예? 16과 14가 Deprecated라구요? 18만 지원하는 겁니까? 예???

    거치대 이슈는 핸드폰 거치대에 노트북 올려놨더니 무게를 못 버텨서..

    샘플 애플리케이션을 선택한 다음, 나는 프리티어 계정을 그대로 사용할 것이므로 다음으로 넘어간다.

    서비스 액세스 구성부터 진행되는 내용은 다음에 구성 가능하지 않을까? 검토 단계로 건너뛰기라는 버튼이 아래에 보여서 건너뛰어 보았다. 아래는 자동으로 설정된 내용들이다. (이게 앞으로 발생할 모든 문제의 화근이다)

    이렇게 생성해주고 나면 생성하는 시간이 좀 걸린다.

    시간이 너무 오래 걸리길래 아래로 스크롤해보니 에러가 나 있었다.

    The instance profile aws-elasticbeanstalk-ec2-role associated with the environment does not exist.

    그대로 구글링해본 결과, IAM 유저를 만들지 않은 게 화근인가 보다. IAM을 검색했더니 대시보드가 먼저 보인다. 역할 클릭.

    IAM 역할 aws-elasticbeanstalk-ec2-role 생성 후 Elastic Beanstalk 환경 구성

    서비스 사용 사례 1. EC2

    이미 뭔가 역할들이 4개나 생성되어 있지만, ec2-role에 대한 문제를 재기하고 있으니 역할 만들기를 진행했다.

    서비스 또는 사용 사례를 선택해야 다음으로 넘어갈 수 있는데, 일반적으로 사용되는 서비스 또는 사례에서 EC2를 선택하고 다음으로 넘어갔다. 그리고 내가 참고한 글에서 말하는 정책을 모두 추가하기 위해 ElasticBeanstalk을 검색해서 아래와 같이 추가를 진행해주었다.

    AWSElasticBeanstalkEnhancedHealth
    AWSElasticBeanstalkManagedUpdatesCustomerRolePolicy
    AWSElasticBeanstalkMulticontainerDocker
    AWSElasticBeanstalkWebTier
    AWSElasticBeanstalkWorkerTier

    다음으로 넘어가면 이름을 지정하고 신뢰할 수 있는 엔터티 선택에서 json 포맷이 나오는데,

    편집 버튼을 누르면 맨 처음 단계로 넘어가니 이대로 생성을 진행했다. 그리고 에러가 또 나온다.

    방금 만든 역할을 클릭해서 정책 추가를 수정해봐야겠다.

    인라인 정책 생성을 클릭하면 권한 지정 화면이 나오며, 아까와는 다르게 정책 json을 편집할 수 있는 것 같아 보인다. JSON을 선택해서 아래와 같이 수정 진행

    ... 안된다. 뭐가 또 에러가 나온다.

    서비스 사용 사례 2. Elastic Beanstalk

    역할 자체를 삭제하고 처음부터 다시. 이번엔 사용 사례를 EC2가 아닌 Elastic Beanstalk으로 바꿔서 역할을 생성해보자.

    Elastic Beanstalk - Customizable을 선택하여 나오는 정책 2개를 그대로 다음, 다음 버튼을 눌러서 생성했다.

    이번엔 IAM 역할 생성에서 에러가 발생하지 않았다. 다시 Elastic Beanstalk으로 돌아가서 어플리케이션만 생성되고 환경은 생성되지 못하였으므로 환경 생성을 이어서 진행해보자.

    죽일듯이 따라 붙는 무서운 에러들...

    마지막 검토 단계로 가서 제출 버튼을 누르니 이번엔 새로운 에러가 나를 반긴다.

    Configuration validation exception: Invalid option specification (Namespace: 'aws:elasticbeanstalk:managedactions', OptionName: 'ManagedActionsEnabled'): You can't enable managed platform updates when your environment uses the service-linked role 'AWSServiceRoleForElasticBeanstalk'. Select a service role that has the 'AWSElasticBeanstalkManagedUpdatesCustomerRolePolicy' managed policy.

    IAM 역할로 다시 돌아가서 아까 만들어준 'aws-elasticbeanstalk-ec2-role'을 클릭하여 '권한 추가 - 정책 연결'을 통해 위에서 말하는 부분(AWSElasticBeanstalkManagedUpdatesCustomerRolePolicy)을 추가해주자.

    그리고 다시 Elastic Beanstalk으로 돌아와서 이번엔 서비스 액세스 구성부를 건너뛰지 않고 그 부분으로 돌아가봤다. 

    기본 값이 '기존 서비스 역할 사용'이고 공백으로 비어 있었다. 아, 이래서 문제였던 걸까?

    보시다시피 기존 서비스 역할과 EC2 키 페어, EC2 인스턴스 프로파일이 비어 있다. (나중에 이슈 다 해결하고 보니 이 부분이 중요했더라.)

    '새 서비스 역할 생성 및 사용'을 누르면 지금까지 내가 한 것들을 거치지 않고 될 것 같다는 유혹이 밀려온다.

    저게 더 좋을 것 같은데... 열어서 세부 정보를 확인해보자.

    역할 이름: aws-elasticbeanstalk-service-role
    신뢰할 수 있는 엔티티: elasticbeanstalk.amazonaws.com
    권한:
    - AWSElasticBeanstalkEnhancedHealth
    - AWSElasticBeanstalkManagedUpdatesCustomerRolePolicy

    내가 IAM에서 만든 역할도 다시 확인하며 비교해보자.

    역할 이름: aws-elasticbeanstalk-ec2-role
    신뢰할 수 있는 엔티티: elasticbeanstalk.amazonaws.com
    권한:
    - AWSElasticBeanstalkEnhancedHealth
    - AWSElasticBeanstalkManagedUpdatesCustomerRolePolicy
    - AWSElasticBeanstalkService

    역시 뜯어서 비교해보길 잘했다. 어차피 비슷하니 내가 만든 것(aws-elasticbeanstalk-ec2-role)을 선택해주기로 한다. 그리고 다시 검토 단계로 건너뛰기. 제출. 부디 이번엔 에러 없이 되길 간절히 소망한다.

    응. 안돼. 돌아가.

    이번엔 개발자 안내서 - IAM - 서비스 역할을 참고해본다. '기본 서비스 역할에 권한 추가'에서 말하는대로 AmazonAPIGatewayAdministrator를 추가.

    위에서 말한대로 모두 진행해보았고... 계속 안되고, 안되고, 안된다.

     

    대체, 만들어준 역할인 aws-elasticbeanstalk-ec2-role 인스턴스 프로파일이 왜 없다고 하는걸까?

    실패한 환경들을 구성 탭에 들어가서 서비스 생성부를 열어봤는데, 분명 연결해준 역할을 찾을 수 없다고 뜬다. 하지만 목록을 눌러보면 해당 역할이 잘만 보인다. 그래서 다시 선택해주면 이미 환경이 제대로 배포되지 못해서 환경은 지워진 뒤라 환경을 찾을 수 없다는 멘트가 빨간 에러로 뜬다.

     

    다시 어플리케이션을 클릭하고 환경 생성을 진행하고, 이 과정을 여러 번 반복했지만 계속 도로묵.

     

    2. IAM 역할 재생성 및 Elastic Beanstalk 어플리케이션과 환경 재생성

    기존 생성한 IAM 역할 삭제 후 재생성

    과정 해결을 위해 여러 구글링을 진행하면서 얻게 된 정보는, 옛날에는 Elastic Beanstalk을 생성할 때 미리 생성된 IAM 역할이 없다면 자동으로 인스턴스 프로파일 맞춤 생성을 해주었지만 AWS 보안 지침이 변경되어 이제는 IAM 인스턴스 프로파일부터 먼저 생성을 해주어야 한다고 한다.

    이래저래 Elastic Beanstalk과 IAM 역할이 꼬인 김에, 전부 처음부터 생성해서 연결해주기로 한다. 위에서 말한 보안 지침 변경된 부분이 분명 개발자 안내서에도 나와 있을 것이다. 해당 부분을 찾아서 읽어보자.

    관리형 정책에서 말하는 아래 3가지를 '개발자 안내서'에서 말하는 '인스턴스 프로파일 생성' 방법을 참고하여 연결한다.

    - AWSElasticBeanstalkWebTier
    - AWSElasticBeanstalkWebTier
    - AWSElasticBeanstalkMulticontainerDocker

    이렇게 생성을 마치고 나면 아래처럼 IAM 인스턴스 프로파일(역할)이 정상적으로 생성된 것을 확인할 수 있다.

    Elastic Beanstalk 애플리케이션과 환경 재생성

    지금까지 플랫폼 브랜치를 이미 Deprecated된 node 16을 시도해서 그런가 하고 'Node.js 18 running on 64bit Amazon Linux 2023'으로 바꿔서 진행해보았고 거짓말처럼 만들어지는 것을 확인했다. 그래서 설마 노드 버전이 문제인 애플리케이션에 환경을 연결하려고 해서 그런 문제였다고?라는 생각이 들어 플랫폼 브랜치를 'Node.js 16 running on 64bit Amazon Linux 2/5.8.5'로 바꿔서 환경과 애플리케이션 재생성을 시도했고, 이 역시 문제 없이 발행되는 것을 보고 느꼈다.

     

    아, 애플리케이션이 도커에서 컨테이너 같은 것인가 보구나. 그리고 이미 IAM 인스턴스 프로파일이 생성되지 않은 상태의 IAM 상태를 복사해서 애플리케이션을 생성했나 보구나. 비정상적으로 만들어진 애플리케이션인게 문제인가 보다. 애플리케이션에 종속되어 만들어지는 환경은 애플리케이션 생성 당시 없었던 IAM 인스턴스 프로파일이 아무리 동일한 이름으로 새로 만들어져도 해당 역할이 없다고 판단하여 계속 'The instance profile aws-elasticbeanstalk-ec2-role associated with the environment does not exist.'를 띄운 거였나 보다.

     

    아래는 아무리 시도해도 공백으로 뜨던 '서비스 역할 - 기존 서비스 역할 사용 - 기존 서비스 역할'과 'EC2 인스턴스 프로파일'을 제대로 불러오는 것을 확인할 수 있는 이미지다.

    환경 구성 시 없다고 목 놓아 울부 짖던 EC2 인스턴스 프로파일이 이 단계에서 제대로 뜨는지 확인은 앞으로 필수다. 서비스 액세스 구성부에서 확인하지 않고 검토 단계로 건너뛰기를 해버리는 순간 아무리 환경을 재생성해도 도르마무를 겪게 되므로 필히 확인하도록 하자.

    사용되지 않는 Elastic Beanstalk 애플리케이션과 환경 삭제하기

    추후 업데이트 예정

     

    파이프라인 설정

    내가 참고했던 글에서는 고급설정을 열어보지 않고 다음으로 진행했기에 고급설정이 새삼 궁금해져 열어봤더니 기본 위치로 계정에 S3 버킷을 생성하도록 설정되어 있었다. 안 그래도 Elastic Beanstalk을 하기 위해 S3 버킷을 만들어야겠다고 생각했는데 내가 먼저 만들지 않고 파이프라인부터 생성하면 S3 버킷을 자동 생성해주나 보다. 굉장히 편리한 시스템이로군.

    여기에서 GitHub(버전 2)를 선택하면 아래와 같이 펼쳐지는데, 최초 설정일 경우 연결 탭에 아무것도 활성화되지 않으므로 GitHub에 연결을 클릭하여 원하는 유저명을 선택한다. 나의 경우 내 리포지토리가 아닌 사이드 프로젝트를 위해 결성된 조직에 리포지토리를 만들었으므로 조직명을 입력해주었다.

    연결 설정 후 리포지토리 이름과 브랜치 명을 입력한다. 유저명(조직명)이 잘 연결되었다면 해당 유저가 가지고 있는 리포지토리와 브랜치가 자동으로 선택만 가능하게 뜰 것이다.

    변경 감지 옵션은 체크된 상태 그대로 둘 것이고, 출력 아티팩트 형식에 대해 궁금한데.. 우선은 선택된 기본값대로 두고 넘어간다.

    빌드 스테이지에서는 환경 변수를 추가할 수 있는데 선택사항이다. 현재 프로젝트 시작에 앞서 배포 라인부터 구성하는 중이므로 우선은 넘어간다.

     

     


    참고 글

     

     

     

     

     

    728x90
    반응형
    Comments