Devops 어떻게 쓰고 계신가요?
Azure Devops, 2가지의 빌드 환경
Azure Devops는 빌드되는 환경을 크게 2가지로 나누어 제공하고 있다.
- Microsoft Hosted Agent
- Self Hosted Agent
이 두가지의 차이는 파이프라인이 돌아가는 환경이 어디냐? 라는 차이점이다. Microsoft에서 제공하는 Host에서 나의 코드가 빌드되어 배포되어진다면 Microsoft Hosted Agent이다.
위와는 다르게 나의 코드가 내가 가지고 있는 Virtual Machine에서 실행되어 진다면 Self Hosted Agent이다.
일반적인 jenkins 환경과 비교 하자면?
일반적인 jenkins 환경은 아래와 같이 정리해볼 수 있다.
- 사설망 위에 Virtual Machine 또는 container 형태로 jenkins를 사용한다.
- 사설망 위에 있기에 inbound 트래픽과 outbound 트래픽 모두 컨트롤이 가능하다.
- 생성된 아티팩트 내 사설망 안에서 이동할 수 있다.
Microsoft Hosted Agent
- Microsoft에서 호스팅하는 어느 container 또는 VM에서 실행된다.
- 따지자면 public 망이기에 내 코드가 빌드되는 환경의 inbound 트래픽이나 outbound 트래픽의 컨트롤이 불가능하다. (정책상 사설망 내에서 빌드되어야 한다는 부분들이 있는 회사나 업종은 사용하기 힘들다.)
- 파이프라인이 내 네트워크에서 실행되지 않기에 public 망을 통해서 아티팩트를 내 사설망 안으로 가져와야 한다. 즉, 내 사설망중 어떤 서비스는 아티팩트를 받는 inbound rule을 열어 놓아야 한다.
Self Hosted Agent
- 사설망 위에 Virtual Machine 또는 container 형태 안에 Agent를 설치하여 사용한다.
- 사설망 위에 있기에 inbound 트래픽과 outbound 트래픽 모두 컨트롤이 가능하다.
- 생성된 아티팩트 내 사설망 안에서 이동할 수 있다.
정리 해보면 jenkins와 보안적으로 조금 폐쇄적인 환경에서 쓰고 싶다고 한다면 Self Hosted Agnet를 사용하고, 빌드 환경과 아티팩트가 public을 통해서 전달되도 상관없다면 Microsoft Hosted Agent를 사용하면 된다.
Self Hosted Agent를 어떻게 쓰면 될까?
설치에 관련된 Microsoft Docs는 이 링크를 참고하자.
inbound
Microsoft Hosted Agent의 경우 사용하기 가장 쉽지 않은 이유중 하나가 이 주소에 명시된 Azure Devops에 대한 ip range를 열기가 까다롭기 때문이다. 특정 주기로 변경될 수도 있기에, 매번 바뀌는 source ip를 매번 firewall에서 변경해주는게 쉽지 않다. AzureDevops라는 Service Tag 또한 있으나, Microsoft Hosted Agent에는 적용되지 않는다.
반면, Self Hosted Agent는 아래와 같은 경우가 아닌 경우, inbound 트래픽에 대한 nsg를 따로 열어줄 필요가 없다. 나는 inbound를 일절 닫고 사용하고 있다.
아래의 그림을 보자.
Azure Pipelines과 Agent간의 통신은 항상 Agent가 먼저 시작을 한다. 따라서 inbound에 대한 nsg를 신경 쓸 필요는 없으나, outbound에 대한 부분은 따로 열어줘야한다.
inbound를 열어주는 경우는 아래와 같은 상황이 있을때 고려를 해본다.
위와 같은 상황에 놓인 경우, 아래와 같이 Docs에 명시된 IP list를 열어주거나 AzureDevops라는 Service Tag를 nsg에서 allow 하면된다. (3/11/24 기준)
outbound
위 inbound에서 설명하였듯 outbound는 firewall에서 아래와 같이 열려 있어야한다.
어떻게 사용하고 있을까?
현재 내가 참여하고 있는 프로젝트에서는 inbound를 deny all 로 하고 사용하고 있으며, outbound는 필요한 수준으로 열어서 사용하고 있다고 말할 수 있다.
Azure Repos와 Azure Pipelines을 사용하며 빌드와 아티팩트에 대한 전달을 내 머신에서 할 수 있다는 장점과 그 머신이 코드를 받아오는 과정 자체를 inbound nsg에서 deny all을 해놓고 사용할 수 있다는 장점이 있다.
기존에 jenkins를 고집하는 부분이 일부 필드에서는 빌드가 무조건 사설망에서 이루어져야 한다는 포인트와 빡센 보안정책 때문에 inbound 트래픽에 대한 제약이 있는 곳들이 많은데 요구사항들을 잘 지키며 jenkins라는 또 하나의 3rd party playform을 관리하지 않아도 된다는 점을 장점이라 말할 수 있다.
마치며
Self Hosted Agent 꽤 쓸만하다. 꼭 사용해보자!! 언제까지 빌드 결과물을 받기 위해 나의 소중한 사설망을 열어줘야 하는가!?
아래의 그림과 같이 나의 target들도 안전하게 배포받을 권리가 있다!!
참고 & 출처
