# 2022-07-28 매트의 아고라 - 잠실편
# 아고라
아고라
고대 그리스의 도시국가(폴리스)에서 자유 시민들이 자유롭게 토론을 벌이던 장소. 아고라라는 단어 자체의 의미는 '집결지'(Gathering Place)이다.
우리는 다양한 미션을 진행하며 많은 의문과 고민에 직면하게 된다. 미션을 진행하며 단순히 정답을 찾는 것이 아닌 자신만의 근거와 사례를 만들어가는 과정이라고 생각한다. 우리 아고라 에서는 구체적인 예시를 기반으로 다양한 상황을 제시한다. 참여자는 그에 대한 실제 적용 사례를 이야기 하거나 자신만의 근거를 이야기 하며 건전한 토론을 진행한다.
# 목적
미션을 진행하며 직면하는 다양한 의문들에 대한 자신만의 근거를 만들기 위한 의식적인 연습과 자신의 생각을 의도에 맞게 적절히 전달할 수 있는 말하기 연습이 가장 큰 목적이다.
# 각 팀들의 CI/CD 방식 공유
우리는 CI를 통해 여러 명이 하나의 코드에 대한 수정을 진행해도 지속적으로 통합하여 관리해주며 CD를 통해 항상 신뢰 가능한 수준에서 배포할 수 있도록 관리한다.
CI/CD의 도움을 받아 개발을 진행하면 자동으로 반복적인 빌드 및 테스트와 배포 작업을 처리해주기 때문에 코드의 변경에 원할하게 대처할 수 있다.
이번 팀 프로젝트에서는 대부분의 팀들이 CI/CD에 대해 많은 고민을 진행하며 도입하고 있다. 아고라를 통해 다른 팀들은 어떻게 CI/CD를 구축 했는지, 혹은 어떠한 이유로 해당 도구를 선택했는지 의견을 나눠보려 한다.
WARNING
해당 내용은 토론을 진행할 때 주최자가 기록한 것을 기반으로 각색한 것입니다! 모든 내용을 기록하지 못했기 때문에 잘못된 부분이나 틀린 부분이 존재할 수 있습니다. 만약 잘못된 부분이나 추가하고 싶은 내용이 있다면 아래 코멘트에 남겨주세요!
# 아고라 - 잠실편
각 팀들의 배포 방식을 공유해보자.
github actions를 통한 CI와 젠킨스를 통해 CD를 진행하고 있다. github actions를 통해 CI를 나눈 이유는 develop 브랜치에 merge되기 이전에 빌드 과정을 거치기 때문에 빌드 및 테스트가 통과 되어야만 merge를 진행할 수 있도록 의도하였다.
운영 서버는 github actions와 젠킨스를 활용 했지만 개발 서버는 리눅스의 크론탭을 사용했다. github에 변경 주기를 확인한 뒤 변경이 되었다고 판단되면 pull을 받은 뒤 빌드 및 배포를 진행한다. 주기는 대략 10분정도로 설정해두었다. 가장 큰 장점은 매우 간편하며 추가적인 도구의 도움 없이 사용할 수 있다는 것이다.
사용하지 않고 있다고 다른 팀의 좋은 사례를 보고 도입하게 되었다. 젠킨스에도 비슷한 기능이 있지만 설정이 복잡하고, github actions를 활용할 경우 간단히 적용이 가능하기 때문에 선택하게 되었다.
스프링에 빌드 및 배포를 위한 추가 컨트롤러를 통해 운영 서버 내부에 스크립트를 실행하도록 작성한 경험이 있다. 자기 자신이 특정 신호를 받아 빌드 배포를 진행한 뒤 서버를 재시작 하도록 한다.
우리 팀은 조금 특별하다. 서버 측에서 소켓 프로그래밍으로 열려 있는 포트를 통해 http 요청을 보내 미리 작성한 배포 쉘 스크립트를 실행하도록 만들었다. 이러한 선택의 이유는 젠킨스는 학습 비용이 크다고 판단했기 때문이다. 또한 이미 github actions를 사용하고 있기 때문에 다른 도구를 사용하기 보다 gitgub actions를 더 활용해보고 싶었다.
위 방식을 사용했을 때 큰 문제는 없었나?
지금까지 운영하며 파이썬 서버가 딱 한 번 죽었던 적이 있다. 이것은 추후 반복적으로 서버의 생존 유무를 판단하여 다시 시작될 수 있도록 조치를 취하였다.
아무래도 배포를 위한 요청 uri가 고정이기 때문에 보안적인 문제가 생길 수 있다고 판단한다. 때문에 추가적인 암호화가 필요하다. 또한 현재는 단순히 요청 uri를 보내면 단순히 배포 스크립트를 실행할 뿐이기 때문에 배포 버전에 대한 롤백을 진행할 수 없다. 추후에 이러한 기능을 보완할 예정이다.
대부분의 팀들이 젠킨스를 활용하고 있다. 왜 젠킨스를 선택하게 되었을까?
가장 유명해서(?)
사실 선택에 여지가 없었다. github actions를 사용하고 싶었는데 보안 정책이나 다른 CI/CD 도구의 유료 정책으로 인해 젠킨스를 선택하게 되었다. 걱정이 많았지만 파이프라인이 생각보다 어렵지 않았고, 현재도 만족하며 사용하고 있다.
우리가 사용하고 있는 AWS에 보안 정책도 우려된다. 현재 ssh 프로토콜이 허용된 public IP에서만 접근이 가능하다. 즉 github actions를 통해 ssh 접근이 불가능하다. 관련해서 인스턴스 내부에 22 포트를 8080 포트로 변경하는 방법도 고민해보았다. 하지만 보안적인 측면에서 매우 위험할 것이라 판단한다.
젠킨스는 Java로 만들어졌다. GUI를 통해 java 빌드 설정을 진행하는 등 java에 친화적으로 다양한 설정을 간편하게 할 수 있다.
젠킨스를 설치하기 위한 방법은 다양하다. 각 팀은 어떤식으로 젠킨스를 설치한 뒤 운영하고 있는가?
젠킨스에 대한 학습을 진행하며 자연스럽게 ec2 위에서 환경을 구성하였다. 도커에 대해서는 크게 고려하지 않았다.
도커 없이 설치를 했는데 문제가 발생하여 도커를 활용하여 재설치를 진행했다. 이점으로는 환경 구성이 간편하다는 것과 문제가 생길 때 마다 이미지 활용하여 다시 컨테이너를 띄우면 된다. 하지만 메모리 추적 등 불편함을 느끼기도 했다.
도커의 가장 큰 장점은 설정이 간편하다는 것이다. 젠킨스 설치를 위해서는 젠킨스 및 jdk 설치 등 신경써야 할 부분이 많다. 도커는 최소 운영이 가능한 상태로 컨테이너를 생성할 수 있기 때문에 간편하다. 하지만 앞서 언급한 것 처럼 메모리에 대한 관리와 예상하지 못한 부분에서 트러블이 생긴 경험이 있다.
도커를 사용했지만 추후 도커를 활용하지 않고 설치 하도록 변경을 염두하고 있다. 우리는 여러 환경에서 젠킨스를 설치할 일이 없기 때문에 도커의 장점이 조금 옅어진다.
젠킨스를 활용한 팀들이 현재 가장 크게 겪는 문제는 메모리 부족 현상이다. 무엇이 문제일까?
현재 운영 서버는 수동 빌드 및 배포를 진행하기 때문에 아직 경험하지 못했다.
워크 스페이스와 빌드 기록 및 캐싱으로 메모리 부족 현상이 일어나는 것 같다. 빌드가 완료되면 빌드를 삭제하는 방향으로 개선했다. 하지만 아직 근본적인 원인은 찾지 못했다.
빌드 과정 중에 생긴 파일 중 가장 큰 비중을 차지하는 것은 바로 .node_modules 디렉토리였다. 파이프라인에 해당 디렉토리를 삭제하는 로직을 추가했지만 이것이 근본적인 원인은 아니기 때문에 다른 해결책이 없는지 계속 고민 중이다.
파이프 라인 마지막 단계에 젠킨스 아래 .cache를 제거했다. 생각보다 많은 용량이 확보되었다.
다양한 환경에 서버를 실행하기 위해 서버의 설정 정보를 분리해야 한다. 각 팀들은 어떤 방식으로 설정 정보를 관리하고 있는가?
환경 변수를 활용했다. 각 환경에 맞춰 미리 환경 변수를 세팅한 뒤 유연하게 적용할 수 있다. 단점으로는 개발 중 환경 변수가 추가되면 그에 맞춰 다른 환경에도 환경 변수를 수정해야 한다.
조금 특별하게 서브 모듈을 활용했다. 편하기도 하고 외부에서 보이지 않고 등록해두면 private repository를 함께 pull 한다. 다만 파이프 라인 작성 때 코드가 추가된다. 이유는 서브 모듈을 가져올 때 접근 권한 등을 명시해야 하기 때문이다.
추가로 Spring pofile 설정으로 각 환경에 맞춰 간편하게 적용이 가능하다.