Viya 4 에서 R 을 붙이는 구조는 Python 과 같다. SAS Configurator for Open Source(sas-pyconfig)가 배포 과정에서 R 을 빌드해 PVC 에 올리고, transformer 가 CAS · Compute · Launcher 파드에 그 PVC 를 마운트하면서 실행 경로를 알려 준다. 폐쇄망에서는 소스 tarball 과 CRAN 패키지를 미리 반입해 두거나, 아예 밖에서 만든 R 트리를 PVC 에 올리는 방식으로 간다.
Python 구성을 이미 마쳤다면 겹치는 부분이 많고, 겹치는 그 지점이 가장 자주 사고가 나는 자리다.
GLIBC_x.xx not found 로 죽는다..so 파일까지 트리 안에 들어 있어야 한다. 빌드한 서버에서는 잘 돌던 R 이 파드 안에서만 실패하는 사고의 대부분이 여기서 나온다. ldd $R_HOME/bin/exec/R 로 의존 목록을 뽑아, 파드 이미지에 없는 것들을 <R_HOME>/lib/R/lib 아래로 복사한다.--prefix 를 /nfs/r-mount 로 잡았다면 파드에서도 /nfs/r-mount 로 마운트해야 한다.mkdir -p "$deploy/site-config/sas-open-source-config/r"
cp -R "$deploy/sas-bases/examples/sas-open-source-config/r/"* \
"$deploy/site-config/sas-open-source-config/r/"
복사된 파일 이름은 릴리스마다 조금씩 다르다. 실제로 복사된 목록을 보고 kustomization.yaml 의 resources · transformers 에 넣는다.
공식 문서가 경고하는 제약이 이것이다. python-transformer.yaml 과 r-transformer.yaml 둘 다 같은 mountPath 에 볼륨을 붙이려 하면 같은 경로에 두 번 마운트하는 정의가 되어 충돌한다.
둘 중 한 파일에서만 마운트를 정의하고, 다른 쪽은 Add mount path ... 블록 전체를 주석 처리한다. Python 을 먼저 붙인 환경이라면 Python 쪽을 남기는 것이 자연스럽다.
# r-transformer.yaml — 마운트 블록만 주석 처리한다
# - op: add
# path: /spec/template/spec/containers/0/volumeMounts/-
# value:
# name: r-volume
# mountPath: /opt/sas/viya/home/sas-pyconfig
주석 처리하는 것은 마운트 블록뿐이다. 실행 경로를 알려 주는 환경변수·설정 패치는 그대로 둔다. 예를 들어 SAS_JAVA_POLICY_ALLOW_DM_RHOME 같은 항목은 R 이 어디 있는지 플랫폼에 알려 주는 값이므로 지우면 연동이 되지 않는다.
- op: add
path: /data/SAS_JAVA_POLICY_ALLOW_DM_RHOME
value: /opt/sas/viya/home/sas-pyconfig/default_r/lib64/R/bin/Rscript
결과적으로 R 과 Python 이 같은 볼륨 아래 다른 하위 디렉터리에 놓인다. 볼륨 안의 배치는 sas-pyconfig 의 설정에서 정하므로, 두 언어의 트리 이름이 겹치지 않는지 확인한다.
sas-pyconfig 의 ConfigMap 을 패치해 tarball 위치와 빌드 옵션을 지정한다. 폐쇄망에서는 CRAN URL 대신 내부에 반입해 둔 경로나 내부 미러를 가리킨다.
- op: replace
path: /data/default_r.r_tarball
value: https://<internal-mirror>/R/R-4.6.1.tar.gz
- op: replace
path: /data/default_r.configure_opts
value: "--enable-memory-profiling --enable-R-shlib --with-blas --with-lapack --with-readline=no --with-x=no"
--enable-R-shlib 는 빼면 안 된다. Viya 가 libR.so 를 통해 R 을 호출하므로 없으면 연동 자체가 성립하지 않는다.
--with-readline=no 와 --with-x=no 는 파드 안에서 대화형 콘솔과 X11 을 쓰지 않으므로 의존성을 줄이려는 선택이다. 대신 그림을 파일로 뽑으려면 cairo 계열이 살아 있어야 하므로, 빌드 이미지에 cairo-devel 이 들어 있는지 확인한다.
R 패키지는 별도로 반입해 PVC 안의 라이브러리 경로에 넣는다. 수집 방법은 별도 문서에 있다.
kustomize build -o site.yaml
kubectl apply -f site.yaml
마운트가 실제로 붙었는지 본다.
kubectl -n <namespace> describe pod sas-cas-server-default-controller | grep -A3 Mounts
파드 안에서 R 이 실행되는지 본다. 여기까지 통과해야 의존성 문제가 없다고 말할 수 있다.
kubectl -n <namespace> exec -it sas-cas-server-default-controller -- \
/opt/sas/viya/home/sas-pyconfig/default_r/lib64/R/bin/R --version
kubectl -n <namespace> exec -it sas-cas-server-default-controller -- \
/opt/sas/viya/home/sas-pyconfig/default_r/lib64/R/bin/Rscript -e '.libPaths(); sessionInfo()'
런타임을 붙였다고 사용자가 바로 R 코드를 돌릴 수 있는 것은 아니다. 외부 언어 실행은 별도 권한으로 통제된다. Environment Manager 에서 해당 사용자·그룹에 외부 언어 실행 권한을 주어야 한다. Python 연동 때 이미 그룹을 만들어 두었다면 그 그룹을 그대로 쓴다.
| 증상 | 확인할 것 |
|---|---|
파드에서 R 실행 시 GLIBC_... not found |
UBI 계열이 아닌 곳에서 빌드했다 |
파드에서만 error while loading shared libraries |
의존 .so 가 PVC 안에 없다. ldd 로 확인 |
.libPaths() 가 비어 있다 |
R_LIBS_SITE 가 PVC 경로를 가리키지 않는다 |
| CAS 에서는 되는데 Compute 에서 안 된다 | transformer 가 CAS 에만 적용됐다 |
| 볼륨이 두 번 마운트된다는 오류 | python / r transformer 가 같은 mountPath 를 각자 정의했다 |
| 빌드 Job 이 tarball 을 못 받는다 | r_tarball 이 아직 외부 URL 을 가리킨다 |
sas-open-source-config/r 아래 예제 파일 이름과 ConfigMap 키 이름이 바뀐다. 위에 적은 default_r.r_tarball · default_r.configure_opts 도 릴리스에 따라 다를 수 있으므로, 실제 복사된 예제의 README.md 를 기준으로 삼는다. (확인 필요)rpy2 를 SAS 모델 저장소 서비스에서 쓰려면 transformer 를 추가로 넣어야 한다는 안내가 예제 README 에 있다. 적용 여부는 모델 저장소를 쓰는지에 달려 있다. (확인 필요)