[Day 106] Cloud : 배포 자동화

학습 주제

 

배포 자동화
AWS Pipeline
AWS Parameter Store

 

---

 

새롭게 배운 내용

 

2022.10.06 - [Back-End/Cloud] - 배포 자동화, 파이프라인

2022.10.06 - [Back-End/Cloud] - AWS Pipeline을 통한 배포 자동화

 

 

보강할 내용

 

• DevOps
• CI / CD
• 배포 과정의 흐름을 세부적으로 정리하기
• 추가된 코드 분석

 

 

회고

 

  오늘은 AWS Pipeline을 통해 배포 자동화를 하는 실습을 했다. 사실 요즈음 가장 회의감이 들었던 날이기도 했다. Section 3까지는 Spring Boot 영역 안에서 애플리케이션을 구성해 나가는 것이 익숙했기에 하루하루 배워 나가는 것에 대한 성취감이 컸다. 그런데 Section 4에 들어와서 Spring Security를 처음 접하고, 로그인 인증 프로세스를 100% 소화하지 못했는데 충분한 복습을 할 여유도 없이 Cloud 유닛에 들어와서 AWS를 다루게 됐으니 어쩌면 자연스러운 일이다. 매일 '오늘 하루에 주어진 것에 최선을 다하자.' 다짐하면서도 그 이상의 것들이 요구되니 스스로 충족감이 낮아졌다. 이 스케줄 속에서 많은 것들을 하려고 하는 욕심이 있기에 당연하다 생각하고 어떻게 효율을 찾을 수 있을지 고민해 봐야겠다.

AWS의 CodePipeline을 통해 배포 자동화의 각 단계(Source 👉 Build 👉 Deploy)를 연결하는 파이프라인을 구축했다. Source 단계에서는 소스 코드가 저장된 GitHub Repository를 연결했다. Build 단계에서는 CodeBuild 서비스를 이용해서 EC2 인스턴스로 빌드된 파일을 전달하도록 한다. Deploy 단계에서는 CodeDeploy 서비스로 EC2 인스턴스의 변경 사항을 실시간으로 반영하도록 한다. 애플리케이션 코드를 수정한 후에 GitHub로 Commit, push 하면 파이프라인이 동작하여 자동으로 배포가 되는 것이 아주 신기했다.

이 과정까지 성공적으로 이루어져서 S3 버킷 웹 사이트 엔드포인트 주소에 접속하여 서버가 잘 동작하는지 확인했는데 로그인이 잘되지 않았다. 문제는 배포 자동화 과정이 대략 머릿속에서 그려지지만 각 세부 과정들이 어떻게 연결되는지 파악하지 못했다는 것이다. 핵심 주제에만 집중하다 보니 각 코드 한 줄 한 줄이 무엇을 의미하는지 깊게 분석해 보지 못했다.

다행히 문제점을 찾아서 해결은 했다. 정적 웹 페이지를 빌드하기 전에 클라이언트의 환경 변수에 서버의 주소를 담는데 이때 특정 포트에서 작동하는 경우 포트 번호까지 기재한다. 여기서는 8080으로 설정해 뒀었는데, 오늘 application.properties 파일의 server port는 80으로 설정되어 있었기 때문이다. 8080으로 수정했더니 잘 동작했다. 각 동작을 세부적으로 파악해 뒀다면 쉽게 해결할 수 있는 문제였을 것이다. 머릿속에 엉킨 배포 과정을 정리하고 코드를 분석하는 걸 중점으로 복습해야겠다.

 

 

★☆☆☆☆