내 의식의 흐름이 궁금하다면... 참고해도 괜찮음. 하지만 실패함.

대체 뭐가 문제일지... 이제는 다시 codeDeploy도 안 되는 절망적인 상황에서 피같은 돈으로 구매한 도메인만 남기고 전부 리셋하기로 결정했다.

어차피 뭘 해도 이렇게 나오니까...

이젠 보내주기로 한다. 내 건강하지 못했던 인스턴스들아... 안녕...
너희들의 실패를 밑거름 삼아 건강한 인스턴스를 배양해야 할텐데...

아마 성공의 기록이라기보다는 내가 왜 실패했는지 누군가는 알게 될지도 모를 그럴 글이다. '어어 이거 이렇게 하는거 아닌데...' 하는 훈수가 있다면 흔쾌히 받아들이도록 하겠습니다. (사실 제발요)

S3 버킷 생성

버킷 이름을 만들어주고

퍼블릭 액세스 차단을 모두 비활성화 시켜준다.

버킷 버전과 버킷 키에 관한 것들을 모두 비활성화 시켜주어야 한다.

이 과정을 완료하고 나면 이렇게 last-flow라는 이름의 버킷이 생성된다.

EC2와 IAM 설정

EC2에서 S3와 CodeDeploy를 이용할 수 있는 권한을 만들어주기 위해서 필요한 과정이다.
수많은 실패 끝에 조금 와닿는 건... 우리는 ec2라는 인스턴스를 대여해서 그 위에서 프로그램을 배포하고 실행하게 해준다는 것...? 배포는 제대로 배운 적이 없어서 정말 너무 어려운 것 같다.

IAM 설정

먼저 권한을 만들어준다. IAM을 검색하고 즐거찾기 해두시는 것이 좋다.

역할이 엄청 많아져있다. 내 실패의 증거다. 보기가 싫다.

IAM 사용자 만들기

왼쪽 액세스 관리 배너에서 사용자를 누르면 오른쪽 위에 사용자 생성이 뜬다.

아주 당당하게 이름을 적어줬다. 내가 바로 flow deploy를 하실 몸이다 이거야.

권한은 직접 연결을 선택한다. 아래 검색창에 검색을 해서 하나하나 넣어주면 되는데...

내가 예전에 회사에서 배포를 야매로 해봤을 때는

• AmazonEC2RoleforAWSCodeDeploy
• AmazonS3FullAccess
• AmazonS3ReadOnlyAccess
• AWSCodeDeployFullAccess
• AWSCodeDeployRole

이만큼 권한 설정을 해줬었다.

하지만 블로그를 찾아서 들어가보면

AWSCodeDeployFullAccess
AmazonS3FullAccess

이 두 가지 정도의 권한만을 부여한다.

회사의 경험을 믿을 것이냐, 블로그를 믿을 것이냐 고민 끝에... 일단 권한을 다 줘보기로 했다. 하지만 뭔가 AmazonS3ReadOnlyAccess 얘는 좀 이름이... 제한을 두는 것 같아서 빼보기로 한다. 이것이 패착이라면... 죽을게...

검토 한 번 슥 해주고 권한을 생성해준다.

그리고 해당 사용자 설정의 엑세스 키를 발급받아야 한다.

CLI 선택 후

모든 것이 다 헷갈리기 때문에 이름을 냅다 박아준다.

분실하면 안되므로 .csv 파일 저장 후 좋은 곳에 보관해두기.

Github 레파지토리에 secret 변수 추가

아.. 내가 두 번째로 배포 시도했을 때 이걸 까먹어서 문제였다 222...

.csv 파일이 왜 생성되는 건가 했는데 ...

맞다 새벽에 레파지토리 시크릿에 넣어줬었지? ^^...

이걸 하는 이유는 workflow 파일을 AWS와 연동하기 위함이다. 그러니까 우리가 생성한 사용자를 이 레파지토리에 넣어줘서 인식하고 대신 뭔갈 요리조리 할 수 있게 해주는 것 같다! 아직도 이해가 잘 되진 않지만... 오키... 허탈하다. 조금만 더 빨리 알아차렸다면 시간 내에 배포할 수 있었을까...

IAM 역할 생성

EC2와 CodeDeploy에 접근하는 역할: iam-role

IAM 사용자를 만들었으니 그 다음은 IAM 역할을 생성하는 것 같다.

권한은 이 두 가지만 넣어주었다.

참고로 난 너무 많은 역할을 만들어버렸다...

CodeDeploy에 관한 역할: iam-codedeploy

이 역할은 이것만 선택해주면 된다.

하도 이름을 많이 만들어놔서 통일성을 위해 이렇게 만들어뒀다.

EC2 인스턴스 시작

인스턴스 시작을 누른 후 인스턴스 이름을 적고 ubuntu로 퀵 스타트를 선택.

그리고 나면

이게 뭐죠? 😠 진짜 이틀 내내 쉼없이 이거로 난리부르스를 떨었는데 아직도 모르겠다.

키 페어 (flow-key-pair)

fair인지 pair인지는 몰라도 일단 생성해준다.

네트워크 설정은 전부 허용해주도록 한다. 나머지는 더 건드릴 필요 없이 인스턴스를 시작해주면 된다.

사실 인스턴스 생성을 먼저 해줘도 무방할 것 같다.

사용할 EC2에서 보안설정을 추가 및 수정해준다.

너무 헷갈리지만 이거겠죠?

CodeDeploy 애플리케이션 생성

과거의 잔해는 잊고 다시 시작하기로! CodeDeploy의 애플리케이션에 들어가서 애플리케이션 생성을 눌러준다.

아 이제 그냥 직관적으로 가자고 ㅋㅋ EC2/온프레미스를 눌러준 후 애플리케이션을 생성해준다.

이제 배포를 진행하기 위해서는 배포 그룹을 설정해줘야 한다.

이름은 그냥 직관적으로 가고, 아! 이게 아까 내가 설정해둔 권한을 주는 건가보다!

환경 구성은 이렇게 해주시면 되고요, 네임에는 배포할 ec2 인스턴스 이름을 넣어준다.

직접 할거라 안 함 선택한다.

로드 밸런싱을 비활성화 해준 후 생성하면 된다.

codeDeploy-agent 설치

이젠 우리가 ec2 인스턴스에 codeDeploy-agent를 설치해야 한다고 함.

우리는 putty를 통해서 쉽고 빠르게 인스턴스에 접근할 것이다. 아까 만들어둔 pem키를 puttygen을 통해서 ppk 파일로 바꿔준다. 시간이 없으니 이것까진 적지 못한다.

접속하는 방법은 기억이 잘 안나서 이 블로그를 참고했다. 시간이 없다.
https://vanillacreamdonut.tistory.com/323#2.%20EC2%20IAM%20%EC%84%A4%EC%A0%95-1
https://developerjjh.tistory.com/205
여기서 설치 주문을... 좔좔 외워줌

코드

코드에 관한 건 다음에.. 왜냐면 제출 2시간 전이 되었다.
깃허브 코드 들어가면 ci.yml, appspec.yml, start_server.sh 보면 있음

다시금 대차게 실패 중이다.

이건 ci 파일에 버킷 이름이 달라서 생긴 에러

또 같은 에러라서 bucket 달려갔더니

혹시 배포 그룹 이름을 안 써줘서...? 하지만 여전히...

안 올라옴...

정책 문제인가...? 버킷 정책을 다시 설정해줬다.

아니 근데 이게 버킷 이름인가...? 다시 설정...

네 그렇습니다 ^^..flowbucket 뭐였지.. 내가 캡쳐하고도.. (멍청)

하지만 여전히 문제가 있어 보인다.

s3 업로드 경로를 실수로 잘 못 바꿨나 보다. 정해진게 있었나보구나... 미안 건드려서...

일단 여기까지 오니까... 과제 제출 기한이 30분 남았기 때문에 지금꺼라도 일단 올려야 한다.

언젠간 배포와의 싸움을 끝낼 수 있길 바라며... 너무 슬픈 하루... 마무리...
그래도 이전보단 조금 더 배포를 알게된 것 같다.
언젠간 혼자 척척 배포할 날도 오겠지...