조급하면 모래성이 될뿐

Why? 프로젝트를 하며 배포 과정에서 아래와 같이 이미 존재하는 포트를 띄우는 상황이 종종 발생했고, 그때마다 서버가 죽어버렸다. 서버가 죽게 되면 프런트팀에서 슬랙을 통해 요청했고, 그때마다 서버에 접속해서 다시 애플리케이션을 구동시켰다. 이런 경우를 최소화하고자 무중단 배포를 적용했다. How? AWS CodeDeploy를 사용했기 때문에 블루 그린 무중단 배포를 적용하는 방식 이 경우는 ec2를 여러 개 생성해서 사용한다고 이해했다. 현재 프로젝트에서는 조금 오버스럽다고 느껴서 다른 방식을 선택했다. Nginx를 통한 무중단 배포 - 이걸로 적용함 2개의 애플리케이션을 실행한 후(8080, 8081), Nginx를 통해 포워딩한다. 포워딩 규칙은 현재 Nginx가 8080 포트를 바라보고 있다면,..

Why? 배포 환경을 구축하다 보니 환경 구성도 분리해야 했다. 그 과정에서 dev환경(aws)의 접속 정보 또한 github에 올려야 했다. 사실 로컬에 대한 접속 정보도 올릴 때마다 찝찝했다.. 그리고 이번에 직접 RDS에 구성한 DB에 접속하기 위한 정보를 push를 해야 하는데.. 이건 아니다 싶었다. How? 이것도 여러 가지 방법이 있었다. 암호화, 서브모듈 운영체제 환경변수 암호화는 복호화 과정에서 필요한 key를 계속 관리해야 한다는 게.. 마음에 들지 않았다. 또 OS환경변수는 뭔가 너무 간단(?)했다. 그래서 서브모듈을 써봤다. 서브모듈을 통해 application-dev.yml 파일을 관리했다. 서브모듈? 쉽게 private repository를 만들고 거기에 중요한 파일을 올린다. ..

Why? 팀 프로젝트를 하면서 애플리케이션 코드에 문서화를 위한 코드를 추가하는 것이 마음에 들지 않아 RestDocs를 선택했다. 하지만 RestDocs는 별로이쁘지 않았고, Swagger처럼 바로 호출할 수 없다는 단점이 있었다. Need? plugins { // api-spec 플러그인 추가 id 'com.epages.restdocs-api-spec' version '0.16.0' } dependencies { // api-spec 의존성 추가 testImplementation 'com.epages:restdocs-api-spec-mockmvc:0.16.0' } // openapi3 task 추가, 문서화 할 때 아래 정보를 참조해서 만들어진다. openapi3 { server = 'http://3..