20240721 TIL

✅ 오늘 배운 것

github actions, workflow를 이용해서 CI/CD를 구축할 때는 무작정 AWS EC2 서버에 접속해서 도커를 띄우는 것이 아니다. 

대신 AWS의 ECS(Elastic Container Service), ECR(Elastic Container Registry) 서비스를 사용한다. 즉 순서는 다음과 같다. 

1. github actions에서 도커 이미지를 만든 다음에 ECR에 올린다. 

2. ECR의 signal을 사용해서 ECS에게 ECR에 도커 이미지가 업로드되었다고 알림을 보내거나, github actions에서 직접 ECS에게 알림을 보낸다. 

3. 배포 완료

 

그리고 도메인을 처음으로 돈 주고 사 보았고, 그것을 Route53이라는 AWS의 서비스를 통해서 AWS와 연결시켜 보았다. 구체적인 스텝이 정확히는 기억이 안 나서 겨우겨우 약간이나마 복기해 보았다. 

1. 여러 사이트를 통해서 도메인 사기

2. Route53을 이용해서 도메인 연결하기

3. 서브넷 설정하기. 그래야 하나의 서버가 실행되다가 죽어도 다른 서브넷의 서버로 연결할 수 있다고 하셨던 것 같다. 

4. 로드 밸런서 설정하기. 각 지역(aws region)에 따라서 request가 들어오면 그에 맞는 region의 subnet으로 보내주는 역할이라고 이해했다. 

 

또한 우리가 있는 ap-northeast-2 aws region은 서브넷이 크게 4개(2a, 2b, 2c, 2d)이기 때문에, 총 서브넷은 기본으로 생성되어 있는 private 서브넷 4개와, 우리가 직접 생성한 public 서브넷 4개로 총 8개면 된다고 하셨다. 

 

그리고 CloudWatch로 로그도 저장해야 한다고 하셨다. 백엔드의 경우는 CloudWatch, 프론트의 경우는 잘 모르지만 알아보아야겠다. 

 

또한 배포용 DB라면 RDS를 사용하는 것이 제일 깔끔하다고 말씀해 주셨다. 

또한 LexoRank 라이브러리도, 원래는 프론트 단에서만 정렬을 하려고 했는데 그럴 수가 없다고 하셨다. 왜냐하면 프론트 단에서 정렬 관련 정보를 보내면 백엔드에서 이를 아예 validation하지 않고 저장하는 것은 거의 사실상 불가능하기 때문이다. 

 

✅ 더 궁금한 것

도커 대신 ECR, ECS를 사용하는 것이 권장되는 이유가 궁금하다. 

github workflow도 내부 소스코드를 보면 github actions를 통해 구현된 것이라고 한다. 이 원리가 궁금하다.