안녕하세요~ 오늘은 Jenkins에서 제공하는 API를 이용하여 Job을 생성하고, 원하는 설정을 주입해 보도록 하겠습니다.
업무를 하다 보면 Job을 한꺼번에 생성하거나, 아니면 특정 조건 발동 시 Job을 생성하도록 할 일이 있는데요.
그런 경우에 사용하는 방법입니다.
준비물: (준비물의 준비 과정은 아래에 설명되어 있습니다)
- 원하는 Jenkins Job 설정을 담은 config.xml
- Jenkins Job creation 및 Job Configuration 권한이 있는 계정
- Job creation 권한을 가진 계정의 API Token
우선 주입할 설정을 config.xml 형태로 로컬이든 어디든 준비합니다.
config.xml은 Jenkins Job마다 가지고 있는 설정 파일로, Jenkins Home의 Jobs에서 보시면 각 잡별로 config.xml이
생성되어 있는 걸 보실 수 있습니다. 굳이 서버 안 들어가셔도 Job url 뒤에 config.xml 붙여도 액세스 가능합니다.
그렇다면 여기서 알 수 있는 것은...?
config.xml은 직접 작성하실 필요 없이 그냥 원하는 형태로 ui에서 설정해 주시고 해당 잡의 config.xml로 접근해서 얻을 수 있습니다.
첫 번째 준비물이 완료되었으니 다음으로 넘어갑시다.
두 번째 준비물은 권한이 있는 계정입니다. 이 글을 읽으시는 분들은 대부분 admin 권한을 가지고 있는 분들이라 별 의미가 없겠네요.
넘어가시죠...권한이 없으시면 관리자에게 권한을 요청하시면 되겠습니다.
마지막 준비물은 API 토큰입니다. 앞서 준비한 계정의 유저 설정에 들어가 API Token에서 토큰명을 입력 후 Generate 합니다.
토큰 생성이 완료되면 토큰값이 나타나는데, 한 번만 보여지므로 꼭 잘 저장해 두고 사용하시면 됩니다.
보안상의 이유로 admin 계정과 연동하지 마시고 (혹은 global admin 권한이 있는 계정과 연동하지 마시고)
Job 생성 권한이 있는 별도의 계정에 토큰 발급을 권장 드립니다.
이제 모든 준비가 완료되었습니다. 저는 Pipeline 코드 수행 중 실행할 것이라 scriptpath에서 찾도록 했지만 로컬에서 하실 거라면
로컬 현재 위치(.) 에 config.xml을 갖다 두고 사용하셔도 되겠습니다.
한 가지 더 말씀드리면, Pipeline 에서 수행한다면 레파지토리에 토큰 아이디와 토큰값을 평문으로 노출할 것은 아니기 때문에
withCredentials를 이용하여 id = 계정, pw = 토큰값 이런 식으로 미리 매핑해 두었습니다.
1
2
3
4
5
6
7
8
9
10
11
12
13
|
...(선략)
withCredentials([ usernamePassword( // Jenkins에 저장된 credential의 유형입니다.
credentialsId : "아이디와 토큰을 저장한 credential의 ID",
usernameVariable: "token_user",
passwordVariable: "token"
)
]) {
sh """
curl -s -XPOST 'https://젠킨스 도메인/job/폴더명/createItem?name=Job이름' \
--data-binary '@config.xml' -H 'Content-Type:text/xml' --user ${token_user}:${token}
"""
}
... (후략) |
cs |
이런 식으로 호출하시면 잘 작동이 되고요, 나는 저게 무슨 말인지 모르겠고 로컬에서 돌리고싶다 하시면
1
2
|
curl -s -XPOST 'https://젠킨스 도메인/job/폴더명/createItem?name=Job이름' \
--data-binary "@config.xml" -H "Content-Type:application/xml" --user 토큰이 있는 계정명:토큰값
|
cs |
이런 식으로 사용하시면 되겠습니다.
이쯤 되면 이런 의문이 드실 수도 있습니다.
얘는 왜 멀쩡한 아이디 패스워드를 두고 토큰을 발급해서 아이디 패스워드처럼 쓰지?
그냥 아이디랑 패스워드를 써...!
토큰을 발급받아서 사용하는 이유는 제가 더 번거로운 길을 선호하기 때문입니다.
농담이고 아이디랑 패스워드 방식을 사용하면 breadCrumb이 없다는 에러가 뜨실 건데요, (혹은 권한이 없다는 에러)
아이디, 패스워드 방식으로 인증 시 breadCrumb이라는 일회용 인증키같은 것과 같이 사용해야 해서
login API를 호출해서 breadCrumb을 받고, 그 breadCrumb을 이용해서 다시 Job creation API를 호출해야 합니다.
Access Token을 이용하면 breadCrumb을 필요로 하지 않아 Token 방식이 여러모로 편리합니다. 파싱하기 귀찮잖아요..?
아무튼 요런 식으로 하시면 원하시는 설정이 주입된 Job이 기다리고 있을 겁니다~짜잔~~!
저는 config.xml의 템플릿만 미리 갖다두고 설정 디테일은 동적으로 변경되도록 하여
서비스 성격에 맞는 Job이 생성되도록 하는 데 요걸 사용하고 있는데요. 다른 분들도 유용하게 사용하셨으면 해서 공유합니다~
'DevOps' 카테고리의 다른 글
[Kubernetes] Application Gateway의 기본 기능, Connection Draining에 대해 알아보자! (0) | 2021.11.10 |
---|---|
[Kubernetes] Node selector vs. Node affinity, 어떤 것을 사용할까? (1) | 2021.11.07 |
DNS 레코드 삭제 후 재생성 시 도메인 질의가 되지 않는 문제 해결하기 (3) | 2021.09.21 |
ARP Protocol은 어떻게 맥 어드레스를 쿼리하고 수신할까? (1) | 2021.08.16 |
traceroute로 목적지까지 거치는 경로 확인하기 (0) | 2021.08.14 |