SAS Risk Cirrus 계열 솔루션(ALM 등)은 단독으로 배포되지 않는다. 모든 Risk Cirrus 솔루션이 공유하는 Risk Cirrus Core 위에 얹히므로, 솔루션 하나를 올리려면 Core 를 함께 배포해야 한다. Viya 4 의 kustomize 배포 흐름에 맞춰 사전 작업을 끝내 두지 않으면 배포 Job 이 중간에 멈추거나 조용히 일부 단계를 건너뛴다.
디렉터리 이름이 헷갈리기 쉽다. 설정 디렉터리는 sas-risk-cirrus-rcc, ConfigMap 이름은 sas-risk-cirrus-core-parameters, PVC 컴포넌트 이름은 sas-risk-cirrus-core 다. 셋이 다르다.
$deploy/sas-bases/examples/sas-risk-cirrus-objects/resources/README.md. 여기에 sas_risk_cirrus_objects_transform.yaml 에 해야 할 변경이 적혀 있다.kustomization.yaml 에 Risk Cirrus Core 용 PVC 를 지정한다.configuration.env)을 만든다.외부 PostgreSQL 인스턴스를 쓴다면 두 가지를 반드시 맞춘다. 나중에 고치기 어렵다.
LTREE 확장이 있어야 한다.
SELECT * FROM pg_available_extensions WHERE name = 'ltree';
데이터베이스 로케일이 C 또는 POSIX 여야 한다. 생성할 때 --locale=C 로 만든다. 이미 만든 데이터베이스의 collation 은 바꿀 수 없으므로, 틀렸다면 다시 만들어야 한다.
SHOW LC_COLLATE;
SELECT datname, datcollate, datctype FROM pg_database;
psql -l
Risk Data Service 는 플랫폼용 PostgreSQL(SAS Infrastructure Data Server)과 별개의 PostgreSQL 클러스터를 요구한다. 이것이 SAS Common Data Store(CDS PostgreSQL)다.
두 클러스터의 형태가 같아야 한다. Infrastructure Data Server 가 외부 PostgreSQL 이면 CDS 도 외부여야 하고, 내부(Crunchy)면 CDS 도 내부여야 한다. 섞을 수 없다.
설정 방법은 $deploy/sas-bases/examples/postgres/README.md 에 있다.
프로그래밍 런타임 파드들이 공유해야 하는 코드가 있으므로 ReadWriteMany PVC 가 필요하다. kustomization.yaml 의 annotationSelector 목록에 sas-risk-cirrus-core 를 추가한다. 빠뜨리면 배포가 그냥 진행되지 않는다.
patches:
- path: site-config/storageclass.yaml
target:
kind: PersistentVolumeClaim
annotationSelector: sas.com/component-name in (sas-backup-job,sas-data-quality-services,
sas-commonfiles,sas-cas-operator,sas-pyconfig,sas-risk-cirrus-core)
2025.02 이전 카덴스에서 올라온 환경이라면 $deploy/site-config/sas-risk-cirrus-core 디렉터리와 그 안의 core_transform.yaml 이 남아 있다. 지금 방식과 충돌하므로 디렉터리를 지우고, kustomization.yaml 의 transformers 에서 해당 줄도 제거한다.
- site-config/sas-risk-cirrus-core/resources/core_transform.yaml
솔루션 쪽도 마찬가지다. site-config/sas-risk-cirrus-alm/resources/alm_transform.yaml 같은 예전 파일이 있으면 값만 메모해 두고 지운다.
mkdir -p "$deploy/site-config/sas-risk-cirrus-rcc"
cp "$deploy/sas-bases/examples/sas-risk-cirrus-rcc/configuration.env" \
"$deploy/site-config/sas-risk-cirrus-rcc/"
kustomization.yaml 의 configMapGenerator 에 등록한다.
configMapGenerator:
- name: sas-risk-cirrus-core-parameters
behavior: merge
envs:
- site-config/sas-risk-cirrus-rcc/configuration.env
| 변수 | 의미 |
|---|---|
SAS_LOG_LEVEL_RISKCIRRUSDEPLOYER |
배포 Job 의 로그 수준. 문제 추적 시 DEBUG 로 올린다 |
SAS_RISK_CIRRUS_DEPLOYER_SKIP_SPECIFIC_INSTALL_STEPS |
건너뛸 설치 단계 ID 목록. 기본은 빈 값이며, 보통 빈 값으로 둔다 |
SAS_RISK_CIRRUS_DEPLOYER_RUN_SPECIFIC_INSTALL_STEPS |
특정 단계만 실행. 기본은 빈 값(전부 실행) |
SAS_RISK_CIRRUS_SET_WORKFLOW_SERVICE_ACCOUNT_FLG |
Y 면 아래 계정을 SAS Workflow Manager 기본 서비스 계정으로 설정한다. N 이면 설정하지 않는다 |
SAS_RISK_CIRRUS_WORKFLOW_DEFAULT_SERVICE_ACCOUNT |
워크플로 서비스 태스크가 사용할 계정 |
SAS_RISK_CIRRUS_WORKFLOW_DEFAULT_SERVICE_ACCOUNT 은 Viya 에 로그인할 수 있는 일반 사용자 계정이다. 워크플로가 서비스 태스크를 수행할 때 이 계정의 권한으로 동작한다. SAS 관리자 계정을 쓰지 않는다 — 워크플로 클라이언트가 필요 이상의 파일 접근 권한을 갖게 된다. 전용 계정을 하나 만들어 쓴다.
SAS_LOG_LEVEL_RISKCIRRUSDEPLOYER=INFO
SAS_RISK_CIRRUS_SET_WORKFLOW_SERVICE_ACCOUNT_FLG=Y
SAS_RISK_CIRRUS_WORKFLOW_DEFAULT_SERVICE_ACCOUNT=${WORKFLOW_ACCOUNT}
배포 시점에 어떤 계정을 쓸지 정하지 못했다면 N 으로 두고, 배포 후 SAS Environment Manager 에서 지정해도 된다.
ConfigMap 에 값이 실제로 들어갔는지 본다. configMapGenerator 는 이름 뒤에 해시를 붙이므로 정확한 이름은 목록에서 확인한다.
kubectl -n <namespace> get cm | grep sas-risk-cirrus-core-parameters
kubectl -n <namespace> describe cm sas-risk-cirrus-core-parameters-<hash>
배포 Job 의 진행은 로그로 본다.
kubectl -n <namespace> logs -f deploy/sas-risk-cirrus-core
값이 ConfigMap 에는 제대로 들어갔는데 동작이 다르다면, 파드가 예전 ConfigMap 을 물고 있는 것일 수 있다. 해시가 바뀌면 파드가 재생성돼야 정상이므로, 재생성 여부를 확인한다.
솔루션(예: SAS Asset and Liability Management)마다 $deploy/sas-bases/examples/sas-risk-cirrus-<solution>/ 아래에 자체 configuration.env 가 있다. Core 와 같은 방식으로 site-config 로 복사해 고치고 configMapGenerator 에 등록한다.
주의할 점은 목적지 디렉터리가 이미 있을 때다. 예전 카덴스의 <solution>_transform.yaml 이 남아 있으면 지금 기대하는 configuration.env 가 아니므로, 파일 구성을 확인하고 정리한다.
SKIP_SPECIFIC_INSTALL_STEPS 에 넣는 값)은 릴리스와 솔루션에 따라 다르다. 배포 Job 로그를 DEBUG 로 올려 실제 단계 이름을 확인해야 한다. (확인 필요)