둘 다 같은 서버의 같은 기능을 부른다. oozie CLI 자체가 내부적으로 REST 를 호출한다. 그래서 고르는 기준은 기능이 아니라 누가 부르느냐다.
| 상황 | 권하는 쪽 |
|---|---|
| 클러스터 노드의 운영 스크립트, 수동 조작 | CLI. kinit 티켓을 그대로 쓰고 명령이 짧다 |
| Airflow · NiFi · 사내 포털 등 외부 시스템 연동 | REST. 클라이언트 설치가 필요 없고 상태 코드로 판정이 명확하다 |
| 대량 자동화, 재시도·관측이 필요한 경우 | REST. HTTP 상태와 JSON 응답을 그대로 쓸 수 있다 |
REST 를 쓰면 호출하는 쪽에 Oozie 클라이언트와 하둡 설정 파일을 깔지 않아도 된다. 이것이 외부 연동에서 가장 큰 차이다.
kinit user@EXAMPLE.COM
oozie job -oozie http://oozie.example.com:11000/oozie \
-config job.properties -run
-run 은 제출과 시작을 한 번에 한다. 나눠야 한다면 -submit 으로 잡 ID 를 받고 -start 로 띄운다.
oozie job -oozie $OOZIE_URL -config job.properties -submit
oozie job -oozie $OOZIE_URL -start 0000000-250101000000000-oozie-oozi-W
oozie job -oozie $OOZIE_URL -info 0000000-250101000000000-oozie-oozi-W
oozie job -oozie $OOZIE_URL -log 0000000-250101000000000-oozie-oozi-W
oozie job -oozie $OOZIE_URL -kill 0000000-250101000000000-oozie-oozi-W
OOZIE_URL 환경변수를 잡아 두면 -oozie 를 매번 적지 않아도 된다.
엔드포인트는 /oozie/v2 를 쓴다. v1 도 살아 있지만 새로 만드는 것은 v2 로 간다.
OOZIE=http://oozie.example.com:11000/oozie
curl -H 'Content-Type: application/xml' \
-X POST "$OOZIE/v2/jobs?jobtype=workflow" \
-d '<configuration>
<property><name>user.name</name><value>hadoop</value></property>
<property><name>oozie.wf.application.path</name>
<value>hdfs:///user/hadoop/oozie/workflows/myflow</value></property>
</configuration>'
응답으로 잡 ID 가 온다.
{"id":"0000000-250101000000000-oozie-oozi-W"}
JOB=0000000-250101000000000-oozie-oozi-W
curl -X PUT "$OOZIE/v2/job/$JOB?action=start"
action=start 를 제출 요청에 함께 주면 한 번에 끝난다.
curl -H 'Content-Type: application/xml' \
-X POST "$OOZIE/v2/jobs?action=start&jobtype=workflow" \
-d @job-config.xml
본문은 job.properties 가 아니라 XML <configuration> 형식이다. 프로퍼티 파일을 그대로 보내면 400 이 난다. oozie.wf.application.path 는 필수이고, 코디네이터를 띄울 때는 jobtype=coordinator 와 oozie.coord.application.path 를 쓴다.
curl "$OOZIE/v2/job/$JOB?show=info" # 액션별 상태까지
curl "$OOZIE/v2/job/$JOB?show=status" # 상태 한 줄
curl "$OOZIE/v2/job/$JOB?show=definition" # 워크플로 XML
curl "$OOZIE/v2/job/$JOB?show=log" # 로그
curl -X PUT "$OOZIE/v2/job/$JOB?action=suspend"
curl -X PUT "$OOZIE/v2/job/$JOB?action=resume"
curl -X PUT "$OOZIE/v2/job/$JOB?action=kill"
실패한 노드부터 다시 돌린다.
curl -H 'Content-Type: application/xml' \
-X PUT "$OOZIE/v2/job/$JOB?action=rerun" \
-d '<configuration>
<property><name>oozie.wf.rerun.failnodes</name><value>true</value></property>
</configuration>'
curl "$OOZIE/v2/jobs?jobtype=workflow&filter=status%3DRUNNING&len=50"
filter 값의 = 는 URL 인코딩(%3D)해야 한다. 그대로 넣으면 질의 문자열 파싱이 어긋난다.
보안이 켜진 클러스터에서는 SPNEGO 로 인증한다. kinit 으로 티켓을 먼저 얻고, curl 에 --negotiate -u : 를 붙인다.
kinit hadoop@EXAMPLE.COM
OOZIE=http://oozie.example.com:11000/oozie
AUTH='--negotiate -u : -b /tmp/.ooziecookie -c /tmp/.ooziecookie'
curl $AUTH "$OOZIE/v2/job/$JOB?show=status"
| 옵션 | 뜻 |
|---|---|
--negotiate |
SPNEGO 협상을 켠다 |
-u : |
사용자 이름을 비워 둔다. 실제 신원은 Kerberos 티켓에서 온다 |
-b · -c |
쿠키 파일. 첫 요청에서 받은 인증 쿠키를 재사용해 매 호출마다 협상하지 않는다 |
쿠키 파일을 안 쓰면 요청마다 SPNEGO 협상이 일어나 느려지고, Oozie 서버 로그에 인증 기록이 잔뜩 쌓인다.
curl 이 GSS-API 를 지원하도록 빌드돼 있어야 한다. curl -V 출력의 Features 에 GSS-API 또는 SPNEGO 가 있는지 확인한다. 없으면 --negotiate 가 조용히 무시되고 401 이 돌아온다.
무인 배치라면 keytab 으로 티켓을 갱신한다.
kinit -kt /etc/security/keytabs/batch.keytab batch@EXAMPLE.COM
HTTPS 를 쓰는 환경이면 포트와 스킴이 다르다. 사설 CA 라면 --cacert 로 CA 인증서를 지정한다. -k 로 검증을 끄지 않는다.
Oozie 는 user.name 프로퍼티로 잡 소유자를 정한다. 인증된 주체와 다른 사용자로 제출하려면 Oozie 서버에 proxyuser 설정이 있어야 한다.
<property>
<name>oozie.service.ProxyUserService.proxyuser.batch.hosts</name>
<value>*</value>
</property>
<property>
<name>oozie.service.ProxyUserService.proxyuser.batch.groups</name>
<value>analysts</value>
</property>
설정이 없으면 E0902: Exception occured: [User: batch is not allowed to impersonate ...] 가 난다.
job.properties 와 workflow.xml 작성.