Jenkins Cluster
젠킨스는 주로 소프트웨어 통합 서비스를 위해 사용된다. 이외에도 주기적인 빌드, 배포가 필요한 Batch Job을 수행하는데 활용될 수 있다.
이 과정에서 하나의 Jenkins 인스턴스에 부하가 생길 수 있는데, Master와 Slave로 이루어진 Jenkins Cluster를 구성하여 부하를 분산시킬 수 있다.
Master Node 설정
사내에서 사용하고 있는 전체 빌드/배포를 위한 Jenkins 이외에도 각 팀별로 Batch Job을 돌리기 위해 Jenkins Cluster를 구성하고있다. Jenkins Node들은 모두 AWS EC2 인스턴스에 띄워져있다.
Master Node의 경우 Docker Compose 파일을 이용해 최신 Jenkins Docker Image를 불러와 직접적으로 Jenkins를 실행한다.
Master Node가 띄워진 IP에 접속할 경우 로컬에서 Jenkins를 띄웠을때와 같이 Jenkins GUI를 확인할 수 있다.
Master Node는 직접 Jenkins Job을 수행할 수 도 있지만 일반적으로 작업을 분배하는 역할을 하고 Job 수행은 Slave Node에서 수행한다.
Slave Node 구성
Slave Node의 경우 직접적으로 Job들을 수행한다. Slave Node를 Master Node와 연결하는 방법은 크게 어렵지않다.
Master Node와 같이 EC2 인스턴스를 통해 Slave Node가 될 서버를 생성한다. Master Node와 연결하는 방법은 여러가지인데
가 많이 사용되는 방법은 SSH를 이용하는 것과, JNLP(Jave Netwoork Launching Protocol)을 사용하는 것이다.
두 방법 모두 Jenkins GUI를 활용하여 어렵지 않게 세팅할 수 있다. SSH는 Master Node에서 생성한 공개키와 비밀키를 Slave Node와 Jenkins Credential에 등록하면 된다. 
JNLP의 경우 GUI를 통해 Slave Node를 등록하고 Jenkins가 제공하는 agent.jar 파일을 Slave Node에서 다운로드 받고
백라운드에서 실행하면 된다.
agjent.jar 파일의 코드를 잠깐 살펴보니 TCP 프로토콜을 맺는 TcpSlaveAgentProcol을 구현한 클래스로 되어 있었다. Master Node에서 TCP 커넥션을 맺기 위한 정보를 담은 채로 agent.jar 파일을 생성해주고 이를 실행하기만 하면 connection이 맺어지는 것 같다.
신기했던 점은 등록한 Slave Node의 agent.jar 파일을 꼭 해당 IP를 가지고 있는 인스턴스에서 실행하지 않아도 동작한다는 점이다. 즉, 내 로컬에서 agent.jar 파일을 실행시켜도 정상적으로 Slave Node로 인식된다. Slave Node의 IP가 agent에 대해 특별한 식별자 기능을 하지는 않는것 같다.
