hou27의 블로그

계기 release branch에서 master로 병합 전, 즉 실 배포 전에 배포하고 확인할 수 있는 서버가 필요하다고 느껴 테스트 서버를 구축하게 되었다. 기존 서버 구성도 기존의 서버 구성은 위와 같았다. docker-compose를 활용하여 api server, postgreSQL, Redis 총 3개의 컨테이너를 묶어서 EC2에 올려 관리하고 있었다. 초반엔 단순하게 인스턴스 하나를 늘려야겠다고 생각했지만, 서버 비용이 2배가 된다는 생각에 아찔해져 지금 올려둔 EC2에 테스트 서버를 함께 올리기로 결심했다. 시도 1 우선 docker compose로 묶어뒀던 구성에서 api server를 분리하고, ec2 보안 그룹에 test server를 위한 인바운드 규칙을 추가하고 Application ..

프로젝트를 진행하면서 aws ec2에 띄워둔 docker container에서 로그를 요일별로 정리하여 파일로 저장하고 있었다. 근데 로그에 표시할 시간은 적절한 조치를 통해 한국 시간으로 표시하고 있었지만, docker container 자체의 timezone이 UTC+0으로 설정되어 있었기 때문에 한국 시간을 기준으로 00시부터 새로운 로그파일이 생성되지 않는 문제가 있었다. 그래서 docker container의 timezone 자체를 Asia/Seoul로 설정하고자 한다. Dockerfile의 설정을 통해서도 timezone을 지정해줄 수 있지만 현재 필자의 프로젝트는 EC2에 docker-compose를 통해 API 서버 & PostgreSQL 서버 & Redis 서버 로 배포되고 있었기 때문에..

프로젝트를 진행하면서 CI / CD의 자동화 필요성을 절실하게 느끼게 되었다. 다른 것도 많았지만 기본적으로 github를 사용하고 있다보니 자연스레 github action을 사용해보자라고 생각했던 것 같다. 여기서 CI / CD 란 무엇일까? 필자가 자동화의 필요성을 절실하게 느낀 것처럼 매번 개발자가 코드를 수정하고 직접 빌드 및 테스트를 하고 배포까지 하게 된다면 그 시간 비용은 엄청날 것이다. 때문에 CI / CD의 개념을 알고 도입하는 것이 필요하다. CI : 빌드와 테스트를 자동화하는 것 지속적 통합(Continuous Integration) CD : 배포 과정을 자동화하는 것 지속적 서비스 제공(Continuous Delivery) or 지속적 배포(Continuous Deployment)..