Jenkins 추가 설정
- Jenkins에 접속하여 Jenkins관리에 들어가보니 아래와 같은 에러 메세지가 뜨는 것을 확인했다.
- 이것을 해결하기 위해 아래와같이 Jenkins 시스템 설정에 들어가 Jenkins Location부분에서 이 브라우저에 접속할때 입력한 주소를 등록하니 해결되었다.
- 이러한 간단한 에러를 잡는데 문득 역방향 프록시가 정확히 무엇일까 하는 궁금증이 들어서 찾아서 공부해보았다.
- 우리는 쿠버네티스에서 사용하는 서비스 리소스 (Cluster IP 타입, NodePort타입 , LoadBalancer 타입)가 프록시 역할을 하는 것을 이미 알고 있다.
- 즉, 아래의 설명처럼 외부에서 클라이언트가 서버에 요청(ex.파드)을 보낼때 다이렉트로 서버에 도달하는 것이 아니라 중간에 프록시 역할을 하는 서비스가 존재하는 것이다.
- 따라서 우리가 지금까지 쿠버네티스 리소스들을 외부에 노출시키기 위해서 사용했던 서비스들이 프록시 역할을 하기때문에 리버스 프록시의 구조를 사용하고 있었던 것이다.
- 예를들어 우리가 생성한 파드를 외부에 노출시키기 위해 로드밸런서 타입의 서비스 리소스를 사용했다고 하자. 클라이언트는 외부용 IP를 통해 요청을 보낸다. 이 요청에 대해서 바로 파드에 접근하는 것이 아니라, 포트포워딩을 통해 노드에 뚫린 NodePort에 들어온다. 이때 ClusterIP가 내부에서 서비스를 찾아준다. 바로 이 서비스가 프록시 역할을 하는 서비스이고, 자신과 느슨하게 연결된 파드들의 IP정보를 저장하고 있는 엔드포인트 정보를 보고 포트포워딩과 로드밸런싱을 통해 파드에 연결한다.
= 이러한 구조가 리버스 프록시 구조이다 - 또한 프록시 역할을 하는 서비스가 존재하는 리버스 프록시 구조이기 때문에 마지막에 파드에 대해 로드밸런싱이 가능한 것이다.
- 이러한 리버스 프록시 구조는 클라이언트가 서버에 다이렉트로 접근할 수 없기 때문에 보안에도 좋다.
- 예를들어 우리가 생성한 파드를 외부에 노출시키기 위해 로드밸런서 타입의 서비스 리소스를 사용했다고 하자. 클라이언트는 외부용 IP를 통해 요청을 보낸다. 이 요청에 대해서 바로 파드에 접근하는 것이 아니라, 포트포워딩을 통해 노드에 뚫린 NodePort에 들어온다. 이때 ClusterIP가 내부에서 서비스를 찾아준다. 바로 이 서비스가 프록시 역할을 하는 서비스이고, 자신과 느슨하게 연결된 파드들의 IP정보를 저장하고 있는 엔드포인트 정보를 보고 포트포워딩과 로드밸런싱을 통해 파드에 연결한다.
Jenkins 선택 이유
- 다음주부터 본격적인 파이프라이닝 작업에 앞서 왜 Jenkins를 선택했는지 간단하게 설명할 것이다.
- 대표적인 CI/CD 툴로는 Jenkins와 GitHub Action이 있다. 하지만 요즘 개발자들 사이에서 GitHub Action이 유행이다. 그렇다면 왜 GitHub Action이 유행할까?
GitHub Action
- Jenkins처럼 서버를 따로 설치할 필요가 없이 클라우드가 있으므로 GitHub과 통합되어 사용할 수 있다.
- 또한 Jenkins에 비해 CI과정에서 설정할 것이 적기 때문에 훨씬 간편하게 사용할 수 있다. 따라서 설정에 자신이 없어 Jenkins를 사용하기 꺼려지는 사람들에게 좋은 선택이다.
- Github에서 제공하는 완전 관리형 서비스이므로 실행하기 위한 인프라를 확장하고 운영하기 위한 방법을 알 필요가 없다.
- Jenkins에 비해 문서가 적다.
- 규모가 작은 프로젝트에 적합하다.
Jenkins
- 설정 프로세스가 GitHub Action보다 복잡하다.
- 호스팅을 하나부터 열까지 모두 관리해야하기 때문에 모든 문서를 관리하기 위한 비용이 든다.
- 따로 Jenkins용 서버를 배포해야 한다.
- 전세계에 많은 기업들이 사용하는 만큼 문서도 매우 많다.
- 다양한 IDE를 지원하고 다양한 커스터마이징이 가능하다.
- 규모가 큰 프로젝트에 적합하다
<Jenkins 선택 이유>
위의 차이점을 봤을때 뭔가 한눈에 보면 Jenkins가 더 안좋아 보인다. 또한 우리가 하는 프로젝트는 규모가 작은 프로젝트이기 때문에 GitHub Action이 더 적합하다. 하지만 그럼에도 선택한 이유는 아래와 같다.
1 . 쿠버네티스 전문가 양성과정에서 배운 CI/CD툴이 Jenkins이기 때문에 실무와 비슷한 프로젝트에서 배운것을 한번 써보고싶다.
2 . GitHub Action은 설정 프로세스가 간단하고 , 따로 서버를 배포할 일도 없으며, 인프라에 대한 개념이 없어도 배포를 할 수 있다. 그렇기에 개발자에게도 인기가 많은 것 같다. 하지만 Jenkins는 인프라에 대한 이해도가 있어야 하며, 설정이 복잡한 만큼 커스터마이징도 다양하다. 따라서 Jenkins는 개발자보다는 좀 더 인프라엔지니어, Devops엔지니어등...에게 특화된 툴이라고 생각한다. 즉 GitHub Action은 개발자 포함 누구나 다룰 수 있는 툴이지만, Jenkins는 인프라 관련 엔지니어에게 특화되어 있기에 나같은 인프라 엔지니어를 희망하는 사람들에게는 Jenkins를 다룰줄 아는 것은 차별점이라고 생각한다.
3 . 내가 하는 프로젝트는 작은 프로젝트이고 따라서 굳이 어려운 길인 Jenkins를 사용하지 않고, Github Action을 사용해도 되지만 이 프로젝트가 끝나고 추가로 진행하는 캡스톤디자인 프로젝트에서 GitHub Action을 사용할 예정이기 때문에 이번 프로젝트에서 Jenkins를 사용함으로써 더 많은 툴을 이용해 볼 수 있을 것이다.
인프라 구축 마무리 및 다음 계획
- 오늘부로 전반적인 인프라 구축을 완료하였다.
- 추후에 인프라에 대해서 변경사항이나 수정사항이 생길 수 있다.
- 다음주부터는 원래 나의 역할이였던 CI/CD 파이프라인 자동화 구축 작업을 시작할 예정이다. 일단 시작하기에 앞서 JAR파일을 빌드하는 것, 프론트 엔드 배포하는 것은 처음이기 때문에 자료조사와 정리가 필요할 것이다. 이 단계가 끝난 후 본격적으로 Jenkins를 이용해 CI/CD 파이프라인 자동화 구축 작업을 시작할 것이다.
인프라 구축 작업에서 느낀점
- 인프라 구축을 하면서 느낀점은 주로 AWS EKS, EC2, RDS 등을 적극 활용하여 클러스터를 배포하고 인프라를 구축하였다. 그러다보니 비용이 만만치않게 청구되는 것을 확인할 수 있었다. 불과 2주만에 200달러 이상이 찍히고, 1년 예상비용이 3만8천달러가 측정되어있었다. 심지어 대규모 프로젝트도 아닌 소규모 프로젝트인데 말이다. 이것이 기업같은 대규모 인프라라면 상상을 초월하는 금액일 것이다. 따라서 비용을 고려하지 않고 단지 고가용성을 위해 인프라를 구축한다면 아무리 장애대응이 신속해도, 효율적인 인프라가 아닐 것이다.
- 이번 프로젝트에서 비용이 생각보다 많이 든 이유는 서버가 실행되지 않는 시간에도 인스턴스와 클러스터가 실행되고 있었고, 그 외에도 같은 인스턴스인데도 비용이 저렴한 스팟인스턴스와 같은 AWS에서 제공하는 다양한 서비스를 적극 활용하지 못했다. 분명 인스턴스뿐 아니라 다양한 서비스에서 비용이 좀 더 저렴한 여러가지 타입이 존재할 것이다. 예를 들어 서버리스를 활용한 인프라 구축과 같이 말이다. 하지만 지금은 처음 AWS를 사용하여 프로젝트를 진행하다보니 AWS의 정석이자 대표적인 서비스들만 이용하여 인프라를 구축하였다.
- 따라서 다음 프로젝트 뿐 아니라 기업 내의 실무에서 프로젝트를 진행할때는 스케줄링을 통해 사용하지 않는 인스턴스는 중단시키거나, 스팟 인스턴스나 예약 인스턴스등의 인스턴스 타입을 활용하고 인스턴스 뿐 아니라 상황에 따라 AWS에서 제공하는 여러 서비스를 적극 활용하여 고가용성과 비용이라는 두마리 토끼를 잡아야 할 것이다.
