무언가 한것들

[Terraform & Route 53] 클라우드 인프라 구축 - 3일 차 : 로그인 시스템 구현과 JWT 토큰 도입

hy0sk — Wed, 8 Jul 2026 22:56:45 +0900

이번에는 로그인 회원가입 기능과 JWT 토큰을 도입해서 수정과 삭제를 글을 쓴 사람만 할 수 있게 만들어 보겠습니다.

비밀번호를 평문으로 DB에 저장하면 해킹 당했을 때 곤란하기에 암호화 하기 위해 라이브러리를 추가해줍니다.

RDS에 users 테이블과 회원가입 API를 추가해주는 코드를 추가해줍니다.

깃허브에 업로드 하고 서버를 배포해줍니다.

이제 제 웹사이트로 들어가서 뒤에 docs를 붙여주니 signup이 보입니다.

아이디와 비번을 입력했는데 암호화되어서 저장되는 것을 확인할 수 있었습니다.

아이디는 중복되지 않게끔 해주었습니다.

잘 로그인이 되는 모습입니다.

이제 작성자가 익명인지 회원인지 확인할 수 있고 오른쪽 위에서 로그인/회원가입을 할 수 있습니다. 로그인 후에는 로그아웃도 가능합니다.

익명으로 글을 쓴다면 게시글의 비번을 통해서 글을 수정, 삭제 할 수 있습니다.

익명의 글은 비번 입력시 삭제 할 수 있고 회원의 글은 본인만 삭제할 수 있습니다.

게시글 삭제도 잘 되는 모습입니다.

게시글 작성 시에 비번을 입력하지 않고 글을 써도 게시되는 오류가 있어서 수정하고 메세지를 띄우도록 바꿨습니다.

그리고 제 계정에 관리자 권한을 주어서 비번을 알지 못하더라도 모든 글을 통제할 수 있게 바꾸었습니다.

오늘 활동을 통해서 유저 DB 구축, 비밀번호 암호화, JWT 출입증 발급, 프론트엔드 연동까지 해보았습니다. 이 모든걸 코드와 깃허브 연동으로 가능하다는 것이 아직도 신기합니다.

다음에는 S3를 이용해서 이미지와 영상 업로드를 연동해보고 다이어그램을 제작해볼까합니다.

[Terraform & Route 53] 클라우드 인프라 구축 - 2일 차 : RDS 연결과 웹사이트 꾸미기

hy0sk — Tue, 30 Jun 2026 03:23:39 +0900

사용자가 글을 쓰고 로그인 같은 데이터를 저장할 수 있게 데이터베이스를 연결해 주겠습니다. RDS를 테라폼으로 구축해보려고 합니다.

바깥 폴더에 새 파일을 만들어서 RDS 생성을 위한 코드를 넣어줍니다.

그리고 데이터 베이스 엔드포인트를 알 수 있게 output 파일에 코드를 추가해줍니다.

백엔드는 학교에서 그래도 다뤄봤던 파이썬으로 선택했습니다. requirements.txt는 파이썬이 실행될 때 필요한 패키지들의 목록입니다.

fastapi, uvicorn: 웹 서버를 띄우는 핵심 도구

sqlalchemy, pymysql: MySQL 데이터베이스와 통신하는 도구

main.py에는 데이터베이스에 접속하고 글을 쓰는 기능을 넣었습니다. 나중에 수정해갈 예정입니다.

Dockerfile는 파이썬 코드를 ECS에 올릴 수 있게 도커 이미지로 굽는 설명서 입니다.

저장 후 apply해주니 엔드포인트가 잘 나왔습니다.

엔드포인트를 ECS 코드에 붙여줍니다.

git add. / git commit -m / git push로 깃으로 푸시해줬습니다.

그리고 app-infra에 있는 코드도 apply해서 인프라를 만들어줍니다.

디스코드로 배포 알림이 왔습니다.

이제 제 웹사이트를 들어가보니 잘 접속이 되는데 화면이 좀 다르게 나옵니다. 기존의 프론트엔드 대신에 백엔드로 화면이 나오게 됐습니다. 성공적으로 적용이 된 것입니다.

주소 뒤에 docs를 치고 테스트 화면으로 들어옵니다. 여기서 POST에 들어갑니다.

그리고 Try it out을 누릅니다.

안에 타이틀과 콘텐츠에 아무 단어나 넣어줬습니다.

그리고 GET에 들어가보니 제가 작성한 글이 데이터베이스에 저장된 것을 확인할 수 있습니다.

작동이 잘 되는 것을 확인했기 때문에 웹사이트의 디자인도 좀 바꿔줬습니다.

수정이랑 삭제 기능도 넣고,,,

좀 더 깔끔하게도 만들어봤습니다. 글쓰기를 누르고 뒤로 가기를 누르면 메인 화면으로 갈 수 있게끔 편의성도 챙겨줬습니다.

다음에는 로그인 기능이랑 S3를 이용해서 이미지 업로드도 구현해볼 생각입니다.

[Terraform & Route 53] 클라우드 인프라 구축 - 1일 차 : 내 도메인에 인증서 붙이기

hy0sk — Wed, 24 Jun 2026 14:29:08 +0900

이번에는 제 이름이 들어간 홈페이지 이름을 사고 그 홈페이지를 aws와 연동해서 https로 접속해보겠습니다.

1. 도메인 연동 및 인증서 발급

우선 인프라를 다시 세워줍니다.

그리고 git 푸시 명령으로 도커 이미지를 채워줍니다.

새롭게 domain.tf 파일을 만들어줍니다. 여기에는 Route53에 제 호스팅 영역을 생성하고 aws가 할당한 네임 서버 4개의 주소를 출력해주는 코드를 넣습니다.

실행해주니 주소 4개가 나왔습니다.

제 이름의 주소는 가비아에서 미리 사놨습니다. (무려 2700원,,,) 이 주소의 네임서버 설정에 들어갑니다.

처음에 3차까지 있는데 추가로 4개를 만들어준 후에 아까 나온 주소 4개를 순서대로 넣어줍니다.

이제 도메인에 인증서를 걸어서 https 접속과 로드밸런서와 제 주소를 연결해주는 코드를 넣어줍니다.

alb 코드에 443포트에서 오는 연결도 허용하도록 코드를 넣어줍니다.

에러가 떴는데 코드에 중복이 있는 것 같습니다. 그래서 코드 정리를 해야겠다는 생각이 들었습니다.

코드를 분야 별로 나눠서 정리를 해준 후에 destroy, apply 해줬습니다.

근데 인증해주는 게 19분이 걸려서 뭔가 이상하다싶었습니다. 근데 알고 보니 Route53을 지우고 다시 생성하면 네임 서버 4개를 다르게 지급해준다는 것을 알게됐습니다,,

그래서 ctrl + c로 강제 종료를 해주고 terraform output name_servers 명령으로 주소를 가져왔습니다. (강종해도 인프라는 만들어짐)

네임 서버 4개를 다시 연결하니 제 이름이 도메인인 홈페이지가 만들어졌습니다.!

전에 만들었던 디스코드 알림 봇도 작동했습니다 ㅎㅎ 이건 나중에 혼자 알림을 바꿔봐야겠습니다.

2. 코드 분리

근데 앞으로 인프라를 부수고 다시 만들고 반복할 텐데 그때마다 휴대폰 인증하고 네임서버 연결하는게 너무 귀찮을 거 같았습니다.

그래서 방법을 생각해봤는데 인프라를 만드는 (돈이 나오는) 폴더를 따로 만들어서 그 폴더만 부숴주면 되겠다는 생각을 했습니다.

제가 작업하던 폴더에 새 폴더를 만들어줍니다. 이름은 app-infra입니다. 그 안에 alb, ecs, iam 이렇게 돈이 나갈 위험이 있는 코드들을 넣어줍니다.

작업 폴더에서 받은 인증서 정보를 새 폴더가 가져갈 수 있게 코드를 넣어줍니다. 그리고 apply로 tfstate에 기록해둡니다.

새 폴더 안에 main.tf 파일을 새로 만들어줍니다. 작업 폴더의 tfstate를 통해 정보를 받아올 수 있게 됐습니다.

그리고 alb 파일에 인증서를 받아올 때 aws에서 받는 코드였는데 이것을 domain.tf에서 받아오고 그걸 사용하도록 바꿔줍니다.

실행했을 때 작동이 잘 되는 것을 확인해줬습니다. 작업 폴더에서 새폴더로 이동한 인프라들도 나옵니다. 올린 내용 외에도 따로 코드만 옮긴 것도 있고 시간을 좀 썼습니다. 하하

다음에는 로그인 기능이랑 게시물 작성 기능도 넣어볼까 합니다.

[GitHub Actions & ECS] CI/CD 배포 자동화 - 4일 차 (완) : 오토 스케일링과 트래픽 집중 시 알림 구현

hy0sk — Tue, 9 Jun 2026 21:37:08 +0900

이번에는 오토스케일링을 추가해서 서버에 트래픽을 몰아넣었을 때 자동으로 서버를 늘리고 알림까지 보내는 기능을 만들어 보겠습니다.

1. 오토 스케일링 환경 구성

인프라도 다시 만들어줍니다.

ecs.tf 파일 아래에 오토스케일링 코드를 넣어줍니다. CPU 사용률이 70% 이상일 때 컨테이너를 3개까지 늘려주고 한 번 만든 후에 60초는 상황을 지켜보는 코드입니다.

이제 알림 보내주는 기능을 구현해주기 위해 EventBridge의 연결에 들어간 후 연결 생성을 해줍니다.

이름을 정해주고 권한 유형은 API 키를 선택해줍니다. 키 이름과 값은 Authorization, dummy로 넣어줍니다. 인증 정보를 보관하는 느낌입니다.

웹후크 URL과 인증 정보를 묶어주기 위해 API 대상에 들어가서 API 대상 생성을 해줍니다.

이름을 입력해주고 API 대상 엔드포인트에 디스코드 웹후크 URL을 넣어줍니다. HTTP 메서드는 POST로 하고 아까 만든 연결이랑 이어주면 됩니다.

이제 오토스케일링 전용 규칙을 만들어 줄 건데 규칙에서 규칙 생성을 해줍니다.

이름을 지어주고 다 기본값으로 두고 스크롤을 내립니다.

이벤트 패턴에서 AWS 서비스는 Application Auto Scaling을 선택합니다. 유형은 스케일링 활동 상태 변경을 고릅니다.

다음으로 넘어가서 대상 유형에 아까 만든 API 대상을 연결해줍니다.

스크롤을 내리면 있는 추가 설정에서 메세지 알림을 이쁘게 만들어주기 위해 입력 변환기를 선택해줍니다. 입력 변환기 구성을 누르면 팝업이 뜹니다.

입력 경로의 코드는 복잡한 로그 중에 필요한 변수만 가져와줍니다.

템플릿은 디코 메세지에 뿌려질 템플릿 양식입니다. 다음으로 넘어가다가 규칙 생성을 해주면 됩니다.

규칙을 생성했습니다.

2. 트래픽 폭격

환경은 다 만들었으니 이제 트래픽을 몰리게 해보겠습니다. 도커를 열어주고 터미널로 docker run --rm williamyeh/hey -n 20000 -c 200 http://로드밸런서주소 명령으로 200명이 20000번 새로고침 하는 효과를 줬습니다.

근데 503이 떠서 너무 트래픽이 많이 쏠려서 그런건가 해서 횟수 대신에 시간을 적용하기로 해봤습니다.

50명이 3분동안 접속을 시도하게 명령을 바꿔봤습니다. 이번에도 503이 떠버려서 의문을 해결하기 위해 콘솔에서 상태를 확인하기로 했습니다.

일단 오토스케일링은 잘 적용되어 있었습니다.

이벤트 탭에서 로그를 확인해봤는데 오랜만에 하느라 창고안을 채우는 것을 잊어버렸습니다....그래서 서버가 켜지지 않았던 것 같습니다. 처음에도 트래픽이 너무 몰려서 그런 게 아닌 거 같습니다.

푸시 명령 3가지를 입력해준 후에 다시 시도해봤습니다.

이번에는 200이 떴는데 여전히 알림은 안 온 상태였습니다. 아무래도 트래픽 적정량을 모르겠어서 CPU 사용률이 10%를 넘어갈 때 서버가 늘어나게 코드를 수정해줬습니다.

그리고 트래픽을 넣어줬습니다.

드디어 알림봇에서 알림이 왔습니다.!!!

CloudWatch로 CPU 사용률을 봤는데 트래픽 때문에 서서히 증가하는 것을 확인할 수 있었습니다.

이벤트 로그도 살펴봤는데 CPU 사용률이 높다고 하며 서버를 늘렸다고 18:12 로그에 나와있습니다. 이렇게 무사히 서버를 늘리고 방어해낸 것을 알 수 있었습니다.

이번 실습을 해보면서 스스로 만들어보고 싶었던 알림 시스템이 잘 작동하면서 오토스케일링이 돌아가니 너무 기분이 좋았습니다.

자동화를 시켜서 편리하게 코드만으로 인프라를 관리하니 간편하면서도 뭔가 시스템을 익숙하게 다루는 느낌이 나서 뿌듯했습니다 ㅎㅎ 아쉬운 점이 있다면 알림을 좀 더 세분화해서 만들면 좋았을 것 같긴하지만 그래도 잘 마무리한 것 같습니다.

[GitHub Actions & ECS] CI/CD 배포 자동화 - 3일 차 : 디스코드 배포 알림 봇 설정

hy0sk — Thu, 4 Jun 2026 13:13:04 +0900

이번에는 새로 배포가 완료되면 디스코드의 알림 봇을 통해 배포가 완료된 것을 알 수 있는 시스템을 만들어보겠습니다.

시작하기 전에 제거했던 인프라를 다시 만들어줍니다.

디스코드의 새로운 서버를 만들고 채팅 채널 하나를 알림창으로 만들어줍니다.

만든 서버의 설정에서 웹후크 만들기를 눌러줍니다.

새 웹후크를 하나 만들어줬습니다. 이름은 git배포.

웹후크와 깃을 연결해주겠습니다. AWS 키 연동했을 때처럼 새 보안 저장소 생성을 해줍니다.

이름은 DISCORD_WEBHOOK을 넣고 Secret에는 생성한 웹후크를 클릭하면 주소 복사 탭이 있는데 그걸 넣어줍니다.

AWS 키까지 해서 총 3개가 만들어져있습니다.

이제 서로 연동이 되었으니 yml 파일에 디스코드에 알림을 보내줄 코드를 넣어줍니다.

푸시 명령 3가지를 입력해주니 배포가 완료되었습니다. (git add . / git commit -m / git push origin)

디스코드에서 배포가 성공했다고 알림이 성공적으로 왔습니다.

다음에는 오토 스케일링을 통해서 서버가 늘어나고 줄어드는 상태를 알림으로 실시간으로 받아볼 수 있도록 만들어보겠습니다.

[GitHub Actions & ECS] CI/CD 배포 자동화 - 2일 차 : 자동 배포 명령서 작성 및 확인

hy0sk — Tue, 2 Jun 2026 17:58:51 +0900

이번에는 자동 배포 명령서 작성을 통해 편리하게 웹사이트 배포를 해보겠습니다.

1. 자동 배포 명령

저번에 만든 ECS와 ECR같은 인프라를 다시 terraform apply로 만들어줍니다.

명령서를 깃허브가 찾기 편하게 코드가 있는 파일내에 새 폴더를 만들고 .github라고 이름 지어줍니다. .github안에 또 폴더를 만들어주고 workflows라고 지어줍니다. 이번에는 workflows안에 deploy.yml라고 파일을 만들어줍니다.

파일에 자동 배포 명령 코드를 작성해주고 저장합니다.

git add. / git commit -m / git push origin 이렇게 3가지 푸시 국룰 명령을 입력해줍니다.

깃허브의 Actions를 보면 방금 푸시한 게 잘 도착한 것을 알 수 있습니다.

눌러서 들어와보면 상세정보를 볼 수 있습니다.

초록색 Bulid & deploy를 눌러보면 무슨 작업을 완료했는지 볼 수 있습니다. 최신코드 가져오기, AWS 키로 로그인, ECR 로그인, 도커 이미지 푸시, 서버 무중단 배포까지 명령서에 작성한 5가지 명령을 모두 완료한 것을 알 수 있습니다.

진짜 작업이 잘 돌아가고 있는 지 확인하기 위해 ECS의 클러스터에 들어가줍니다.

클러스터 아래에 서비스에 들어가주면 컨테이너가 Running 중인 것을 확인 할 수 있습니다.

이벤트의 로그도 확인해보면 코드 수정부터 서버 교체까지의 과정을 볼 수 있습니다.

2. 자동 배포 확인

우선 저번에 만들어놓은 웹페이지가 잘 뜨는지 ALB의 DNS주소로 들어가서 확인해줍니다.

기존 웹페이지 코드를 수정해서 저장해준 후에 푸시 명령 3가지를 쳐서 업로드해줍니다.

업로드 한 후에 이벤트 로그를 확인하여 교체작업이 원활하게 이루어진 것을 확인했습니다.

그리고 페이지를 새로고침해보니 수정한 웹페이지가 잘 나오는 것을 확인했습니다. (중간에 새로고침하니 기존 페이지와 번갈아가며 뜨다가 완전히 바뀜)

이제 예전처럼 코드 수정 후에 수동으로 업로드하고 로그인하고 명령 치고 할 필요없이 수정 후에 푸시 명령 3가지만 치면 알아서 서버 교체까지 자동으로 해주는 것이 너무 편해졌다는 것을 느꼈습니다.

[GitHub Actions & ECS] CI/CD 배포 자동화 - 1일 차 : GitHub 원격 저장소 및 보안 키 연동

hy0sk — Sun, 31 May 2026 14:47:35 +0900

이번 실습으로는 저번에 만든 ECS를 깃허브와 연동해서 자동으로 돌아가는 작업을 해보겠습니다.

그중에서도 오늘은 깃허브 저장소를 만들고 VSCODE로 푸시해주기, 보안 키 연동을 할 겁니다.

1. 깃허브 연동 및 푸시

우선 저는 깃허브 계정이 없어서 만들고 로그인 해준 후의 화면입니다. 여기서 초록색 새 저장소 생성을 누릅니다.

원하는 이름으로 만들어주고 퍼블릭으로 설정해준 후에 생성해줬습니다.

.gitignore 파일을 하나 만들어줄건데 여기에 넣은 애들을 빼고 저장소에 올라갑니다. 중요한 것이나 불필요한 것을 빼고 올리기 위해서 만드는 것입니다.

깃을 실행하는 명령인 git init을 쳤는데 에러가 떴습니다. 깃허브에 저장소는 만들었는데 이걸 올려줄 프로그램인 git은 별개라는 것을 알았습니다.

그래서 깃을 깔아주고 다시 실행해봤습니다.

잘 실행된 모습입니다.

이후 차례로 아까 제외코드 빼고 추가해주는 git add . / 상태를 기록하는(주석느낌) git commit -m 명령을 쳐줬습니다.

git branch -m main 명령으로 브랜치 이름을 main으로 설정합니다.

사진은 없지만 만든 저장소의 주소를 가져와서 git remote add origin https://github.com/hy0sk/aws-ecs.git 명령을 쳐줬습니다.

컴퓨터랑 깃허브를 연결해줍니다.

git push -u origin main 명령으로 최종 푸시를 해줬습니다. 근데 에러가 뜨는 걸 보니 앞에서 뭔가 누락된 게 있는 것 같아서 확인해봤습니다.

차례로 다시 실행하다보니 커밋을 붙일 때 제가 누군지 확인이 필요했던 것 같습니다.

제 가입 이메일과 이름을 적어주니 아까와 다르게 슈루룩 넘어가며 진행이 됐습니다.

코드를 치고 진행하니 자동으로 깃이 뜨면서 서로 연결하는 작업 같은 걸 했습니다. 자격 인증이 된 것 같습니다.

나머지 명령을 차례로 쳐주니 다 잘 푸시된 것 같았습니다.

직접 저장소에 들어와서 확인해보니 모두 잘 올라와 있었습니다. 다음 보안 키 연동을 위해 설정에 들어가줍니다.

2. 보안 키 연동

이제 보안 키를 업로드 하겠습니다. Secrets and Variables의 Actions에 들어온 후 새 보안 저장소를 누릅니다.

이름은 AWS_ACCESS_KEY_ID로 해줘야합니다. AWS에서 받았던 키의 기본 이름이 이것이기 때문에 바꾸면 깃에서 못 찾을 수 있습니다. 아래 Secret에는 AWS의 AWS_ACCESS_KEY_ID 보안 키를 실제 입력해줍니다.

그리고 보안 키를 하나 더 만들어주는데 이번에는 AWS_SECRET_ACCESS_KEY로 만듭니다. 그리고 AWS의 AWS_SECRET_ACCESS_KEY 보안 키를 입력해줍니다.

보안 키 두 개가 모두 업로드 되었습니다.

다음에는 자동으로 실행할 작업 지시서를 만들겁니다.

[Docker & ECS] 컨테이너 배포 해보기 - 4일 차 (완) : 무중단 배포 테스트하기

hy0sk — Wed, 20 May 2026 17:40:30 +0900

이번에는 배포한 컨테이너가 실제로 업데이트를 하여 버전을 바꾸더라도 멈추거나 오류를 내지않고 바로 바뀌는지 테스트 해보겠습니다.

우선 처음에 만든 웹페이지를 바뀐 것을 알아차리기 쉽게 업데이트합니다.

그리고 잊지않고 그동안 쓴 코드들을 모두 apply해주고 푸시명령까지 넣어서 창고를 채워줍니다.

이제 새로 넣은 업데이트버전으로 바로 교체할 수 있게 배포를 강제 적용해 줄 것입니다. ECS의 클러스터로 들어갑니다.

클러스터에 들어가서 만들었던 서비스에 들어가줍니다.

주황색의 서비스 업데이트를 눌러줍니다.

새 배포 강제 적용을 체크표시해주고 업데이트 해주면 됩니다.

ALB의 DNS 주소를 치고 들어오면 바로 이렇게 바뀐 버전의 웹페이지가 보입니다.

원래는 이전버전이 보이다가 새로고침 후에 바뀌는 것을 기대했는데 바로 바뀌어서,,,이벤트 탭으로 들어가서 자세한 과정을 보겠습니다.

이벤트 로그를 보면 처음에 ecb인 구버전이 일을 하다가 새롭게 68d 버전이 업데이트 되었고 아직 트래픽을 받지 않습니다. 그리고 헬스 체크를 마친 후 타겟 그룹에 들어가니 트래픽을 보내기 시작합니다. 구버전은 타겟 그룹에서 지워지고 처리중인 트래픽이 끝맺을 때까지 대기하다가 모든 것이 끝나면 꺼지게됩니다. 이렇게 로그를 통해서 교체과정을 명확히 확인할 수 있었습니다.

모든 작업이 끝난 후 destroy로 모두 삭제해줬습니다.

이번 4일동안 도커를 활용해봤는데 오류들을 통해 인프라가 어떻게 구성되고 트래픽이 흐르는지 이해할 수 있는 소중한 시간이었습니다. 그리고 이미지를 바뀔 때마다 푸시해주고 업데이트하다보니 자동화를 해보고 싶다는 생각도 해봤습니다. 다음에는 뭘 할지 모르지만 CI/CD 파이프라인 자동화도 가능하다면 해보고 싶다는 마음입니다.

[Docker & ECS] 컨테이너 배포 해보기 - 3일 차 : ECS와 ALB 붙이기

hy0sk — Tue, 19 May 2026 16:48:02 +0900

이번엔 직접 ip를 치고 들어오지않고 ALB를 거쳐서 들어오도록 만들어주겠습니다.

ALB 전용 보안 그룹을 먼저 만들어줍니다. 이게 방화벽으로써 트래픽을 걸러줄겁니다.

apply를 통해서 보안 그룹이 잘 만들어진 것을 확인했습니다.

이제 진짜 ALB와 로드밸런서가 트래픽을 보내줄 목적지 명단인 타겟 그룹을 만들어줍니다.

에러내용을 보니 vpc가 서로 다른 두개의 가용영역에 있어야 한다고 합니다.

저번에 만든 vpc는 하나였기에 새로 하나를 더 만들어주려합니다. 미리 가용영역을 봐주고 다른 곳으로 만들어줍니다.

다른 가용영역으로 vpc를 하나 더 만들었습니다.

그 다음 진행하니 잘 추가된 모습입니다.

어제 만들었던 ECS 부분 코드에서 타겟 그룹과 서로 연결해주는 코드를 추가해줍니다. (Fargate로 여는 코드)

성공적으로 변경됐습니다.

이제 콘솔로 들어가서 실제로 다 만들어졌는지 확인해줍니다. 보안 그룹은 잘 만들어졌습니다.

로드 밸런서도 잘 만들어졌습니다.

다 잘 만들어져있어서 ALB DNS주소로 들어왔는데 503 오류가 떴습니다.

타겟 그룹으로 가서 대상을 확인해봤는데 아무것도 없었습니다. 이건 컨테이너를 정상적으로 생성하지 못했다는 뜻이니 ECS에서 따로 확인해봅니다.

클러스터 서비스의 이벤트 탭을 보면 not found가 써있는데 저번처럼 빈 창고만 만들고 안을 안 채웠습니다. 그래서 저번처럼 푸시 명령을 다 적용시켜준 후 다시 살펴봤습니다.(몸이 아파서,,)

조금 기다리니 실행중인 태스크가 생기고 타겟 그룹에도 잘 들어갔다고 뜹니다.

새로 고침 해주니 페이지도 정상적으로 잘 떠줬습니다. 이렇게 3일차 실습이 성공적으로 끝났습니다.

다음에는 진짜 중단없이 배포되는지 테스트를 해보겠습니다.

[Docker & ECS] 컨테이너 배포 해보기 - 2일 차 : 24시간 돌아가는 서버 환경 구축

hy0sk — Thu, 14 May 2026 13:35:11 +0900

이번엔 창고에 있는 도커 이미지를 ECS Fargate로 가져와보겠습니다.

우선 ECR에서 이미지를 빼오기 위해 필요한 권한을 iam역할을 통해 부여해주는 코드를 넣어줍니다.

다음으로 컨테이너들이 모이는 구역인 클러스터, 도커 컨테이너의 스펙을 적어두는 설계도인 작업 정의서를 만들어주는 코드를 넣어줍니다.

에러가 떠서 내용을 확인해보니 컨테이너 이미지 주소에 유효하지 않은 문자가 들어있다고 해서 수정해서 다시 입력했습니다. ( [ ] 가 문제였습니다)

수정해주니 잘 만들어졌습니다.

이제 실제로 보안그룹과 ECS 서비스를 만들어줍니다. Fargate타입으로 띄워줬습니다.

만드는 과정에서 또 오류가 나서 봤는데 서브넷이 비어있다는 오류였습니다. 전에 요금 나갈까봐 모든 vpc를 지웠는데 그때 기본값으로 있는 vpc도 지웠습니다.

그래서 서브넷 하나를 새롭게 직접 만들었습니다.

코드를 다시 돌려주니 제대로 작동했습니다.

도커 컨테이너가 Fargate에서 진짜 돌고있는지 확인하기 위해 직접 콘솔에 들어왔습니다. ECS의 왼쪽탭에 클러스터를 누르고 들어옵니다. 그리고 아래에 있는 서비스를 누릅니다.

현재 배포 상태가 실패한 작업으로 뜨는데 원인을 찾기 위해 태스크 탭으로 들어가줍니다.

태스크 중에 중지된 것에 들어와서 원인을 확인해보니 ECS가 ECR에 들어가서 확인했는데 도커 이미지가 없어서 에러가 난 것이었습니다.

어제 만든 모든 것을 지워놓고 오늘 빈 창고를 만들고 안에 이미지를 안 채운 것을 알아차렸습니다. 그래서 어제처럼 푸시 명령에서 1번에서 4번까지 cmd에 다시 쳐서 push해주고 다시 진행했습니다.

마냥 다시 실행되기까지 기다릴 수 없기에 주황색 서비스 업데이트를 눌러준 후 새 배포 강제 적용을 체크하여 바로 업데이트 해줬습니다.

안을 채워주니 바로 프로비저닝중인 태스크가 생겼습니다.

조금 기다리니 실행중으로 바뀌며 초록색이 되었습니다.

실행 중인 둘 중 하나의 태스크에 들어가서 퍼블릭 ip를 쳐주니 만들어둔 페이지가 잘 떠주는 모습을 확인했습니다.

이렇게 로컬의 HTML 파일을 도커 이미지로 굽고 AWS 클라우드에 올린 뒤 24시간 서버에 올라가는 과정을 실습해봤습니다. 지금처럼 단순한 정적파일은 S3를 이용하면 되지만 나중에 연산이 필요한 프로그램을 올릴 때 ECS를 쓸 것을 미리 체험해 보는 것에 의의를 뒀습니다.

다음에는 ALB에 연결해보겠습니다.