AWS Kubernetes에 Bahmni 설치
관리자 사용자 만들기
루트 액세스 권한이 있는 새 AWS 계정으로 시작할 때는 관리자 사용자를 만든 후 루트 키 사용을 제한하는 것이 좋습니다. 첫 IAM 관리자 사용자와 사용자 그룹을 만들려면 이 문서를 따르십시오.
최소 권한으로 IAM 사용자 만들기
관리자 권한(IAM 관리자 사용자)으로 Bahmni 인프라를 프로비저닝할 수 있습니다. CI/CD(GitHub Actions)를 통해 인프라 프로비저닝을 자동화하거나 DevOps 팀에 인프라 관리를 위임하려면 추가 IAM 사용자를 만들어야 합니다. 권한을 위임할 때는 역할을 사용하고 최소 권한만 부여하는 것이 좋습니다.
참고: CLI를 사용하는 경우 로컬 환경에 aws를 설치하고 구성했는지 확인하십시오. 또한 bahmni-infra GitHub 저장소를 체크아웃했는지 확인하십시오.
aws/policies 폴더에는 AWS 계정에 적용되는 모든 사용자 지정 정책이 있습니다. 아래 CLI에서는 로컬 aws 프로필 이름이 bahmni-aws라고 가정합니다. export AWS_PROFILE=your-profile을 사용해 aws 프로필을 전역으로 내보내면 각 CLI 명령에 --profile을 지정하지 않아도 됩니다.
⚠️ 참고: CLI와 정책 문서에서 {YourAccountNumber}를 실제 계정 번호로 바꿔야 합니다. 계정 번호를 공개 GitHub 저장소에 커밋하지 마십시오.
1️⃣ 최소 권한으로 Bahmni Infra Admin Policy 만들기
첫 단계는 Bahmni 인프라 프로비저닝에 필요한 최소 권한만 포함하는 Policy를 만드는 것입니다.
aws iam create-policy \
--policy-name BahmniInfraAdmin \
--policy-document file://aws/policies/BahmniInfraAdmin.json \
--profile bahmni-awsAWS Console에서도 같은 절차로 정책을 만들거나 업데이트할 수 있습니다.
생성 후 BahmniInfraAdmin 정책을 변경하려면 다음 절차를 따릅니다.
a) 정책 ARN을 조회합니다.
aws iam list-policies \
--scope Local \
--profile bahmni-awsb) (조건부) 정책 버전을 나열합니다. 이미 5개 개정판이 있다면 가장 오래된 버전을 삭제해야 합니다. "IsDefaultVersion": false인 가장 오래된 버전을 찾으십시오.
c) (조건부) 해당 정책 버전을 삭제합니다.
d) 정책 변경 사항을 적용해 새 개정판을 만듭니다.
2. 신뢰 정책이 있는 역할 만들기
적절한 권한이 있는 IAM 주체가 맡을 수 있도록 신뢰 정책을 설정한 BahmniInfraAdminRoleForIAMUsers 역할을 만듭니다.
역할을 만든 뒤 BahmniInfraAdmin 정책을 BahmniInfraAdminRoleForIAMUsers에 연결합니다.
AWS Console에서도 역할을 만들고 정책을 연결할 수 있습니다.
3. IAM 사용자용 역할 수임 정책 만들기
IAM 사용자/그룹이 BahmniInfraAdminRoleForIAMUsers 역할을 맡아 BahmniInfraAdmin 정책 권한으로 인프라를 프로비저닝할 수 있게 하는 정책을 만듭니다.
BahmniInfraAdminAssumeRolePolicy.json
BahmniInfraAdminAssumeRolePolicy 정책을 만듭니다.
4. IAM 사용자 그룹과 사용자 만들기
정책을 IAM 사용자에게 직접 연결하지 말고 IAM 사용자 그룹을 만드는 것을 권장합니다.
bahmni_infra_admins 그룹을 만듭니다(AWS Console 절차는 관련 문서 참고).
BahmniInfraAdminRoleForIAMUsers 역할을 맡을 수 있도록 BahmniInfraAdminAssumeRolePolicy 권한을 연결합니다.
IAM 그룹을 만든 뒤 IAM 사용자를 생성하여 bahmni_infra_admins 그룹에 추가합니다.
주의: bahmni_infra_admins 그룹에 속하거나 BahmniInfraAdminAssumeRolePolicy 역할을 맡을 수 있는 IAM 사용자는 Bahmni AWS 인프라에서 광범위한 관리자 작업을 수행할 수 있습니다. 제한된 DevOps 사용자나 CI/CD 파이프라인에만 신중하게 부여하십시오.
인프라 프로비저닝
Bahmni는 Terraform으로 AWS 인프라를 프로비저닝합니다. 로컬에 Terraform CLI를 설치·구성하십시오. S3와 DynamoDB를 사용하는 Terraform 백엔드로 인프라 상태를 유지합니다.
Terraform과 AWS CLI 외에 kubectl도 설치해야 합니다.
1. S3 버킷 만들기(Terraform 상태 파일 저장)
aws s3api create-bucket \
--bucket <bucket-name> \
--create-bucket-configuration LocationConstraint=<yourRegion>S3 버킷 버전 관리를 활성화할 수도 있습니다.
aws s3api put-bucket-versioning \
--bucket <bucket-name> \
--versioning-configuration Status=Enabled2. DynamoDB 테이블 만들기
aws dynamodb create-table \
--table-name <lock-table-name> \
--attribute-definitions AttributeName=LockID,AttributeType=S \
--key-schema AttributeName=LockID,KeyType=HASH \
--provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5 \
--region <yourRegion><bucket-name>, <lock-table-name>, <yourRegion>에 적절한 값을 사용하십시오. S3 버킷과 DynamoDB 테이블을 만든 뒤 config.s3.tfbackend 파일에 값을 설정합니다.
3. 리소스 만들기
여기까지는 새 AWS 계정마다 한 번만 수행합니다. 이제 로컬 Terraform CLI 또는 GitHub Actions로 리소스를 프로비저닝할 수 있습니다.
Bahmni Appointments 모듈의 이메일 전송용 Amazon SES Terraform 모듈이 포함됩니다. AWS Route53에 등록된 도메인이 필요하며 인프라 프로비저닝 전 domain_name과 hosted_zone_id를 제공해야 합니다. nonprod.tfvars 같은 파일이나 환경 변수로 지정할 수 있습니다. 선택 모듈이며 enable_ses 변수로 활성화/비활성화합니다.
GitHub Actions 사용
bahmni-infra 저장소를 포크하고 GitHub Actions 워크플로를 실행해 인프라를 프로비저닝할 수 있습니다.
1. GitHub Actions Secrets에 AWS 보안 정보 추가
워크플로가 AWS에 인증하도록 AWS 보안 정보를 GitHub Actions Secrets에 추가합니다.
BAHMNI_AWS_ID → 프로비저닝한 사용자의 Access Key ID
BAHMNI_AWS_SECRET → 사용자의 Secret Access Key
BAHMNI_INFRA_ADMIN_ROLE → BahmniInfraAdminRoleForIAMUsers의 Role ARN
2. 원격 상태 구성 업데이트
포크의 config.s3.tfbackend에서 bucket과 DynamoDB 테이블 값을 앞 단계에서 만든 이름으로 변경합니다.
3. 파이프라인 실행
파이프라인은 두 개입니다.
a) Deploy: EKS, RDS 등의 공유 리소스를 프로비저닝합니다. Slack 연동을 사용하지 않으면 slack-workflow-status 작업을 주석 처리하십시오. 연동한다면 Slack Webhook을 설정하고 URL을 GitHub Secret SLACK_WEBHOOK_URL로 정의합니다.
b) node-group: Deploy 후 자동 실행되어 노드 그룹과 노드를 만듭니다. 필요하면 수동 실행해 더 만들 수 있습니다. 기본 노드 그룹 이름은 nonprod이며 포크에서 원하는 상태로 변경하십시오.
cluster_name = "bahmni-cluster-nonprod"
node_role_name = "BahmniEKSNodeRole-nonprod"
node_group_name = "nonprod"
desired_num_of_nodes = 2
min_num_of_nodes = 1
max_num_of_nodes = 2
node_instance_type = "m5.xlarge"CLI
아래 명령 전에 nonprod.tfvars를 확인하고 필요한 구성 값을 조정하십시오.
공유 인프라
위 명령은 리소스 이름 끝에 non-prod를 붙여 인프라를 프로비저닝합니다.
노드 그룹과 노드
4. (선택) 여러 환경 프로비저닝
- 환경별 tfvars 파일 만들기
nonprod.tfvars를 복제해 만들 환경 이름으로 바꾸고 필요한 구성을 수정합니다.
- 환경 값 업데이트
새 tfvars 파일에서 environment와 vpc_suffix 값을 반드시 변경합니다.
- 환경 프로비저닝
다음 명령의 {environment_name}을 실제 환경 이름으로 바꿉니다.
terraform init -backend-config=config.s3.tfbackend -backend-config='key={environment_name}/terraform.tfstate'
terraform apply -var-file={environment_name}.tfvars5. AWS EFS로 영속성 구성
EFS는 ReadWriteMany 접근 모드로 동일한 영구 볼륨을 여러 Pod에 동시에 마운트할 수 있으며, 같은 리전의 모든 가용 영역에서 데이터에 접근할 수 있습니다.
클러스터 영속성에 EFS를 사용하며 설정 절차는 다음과 같습니다.
- Amazon EKS 클러스터에 연결
aws eks update-kubeconfig --name <cluster-name>- Amazon EFS 드라이버 설치
Manifest를 사용해 Amazon EFS CSI 드라이버를 설치합니다.
kubectl kustomize \
"github.com/kubernetes-sigs/aws-efs-csi-driver/deploy/kubernetes/overlays/stable/?ref=release-1.4" > public-ecr-driver.yamlManifest를 적용합니다.
- Amazon EFS용 StorageClass Manifest 적용
파일을 편집해 fileSystemId 값을 실제 파일 시스템 ID로 바꿉니다. 다음 명령으로 SSM에서 fileSystemId를 조회할 수 있습니다.
StorageClass를 배포합니다.
StorageClass를 확인합니다.
PVC에서 이 StorageClass 이름을 참조하면 PV가 동적으로 프로비저닝됩니다. EFS 정적 프로비저닝에는 다음 PV 템플릿을 사용하십시오.
apiVersion: v1
kind: PersistentVolume
metadata:
name: <name-for-your-pv>
spec:
capacity:
storage: 8Gi
volumeMode: Filesystem
accessModes:
- ReadWriteMany
mountOptions:
- tls
persistentVolumeReclaimPolicy: Retain
claimRef:
namespace: <namespace>
name: <name-of-your-pvc>
storageClassName: <name-of-storage-class-created-in-above-step>
csi:
driver: efs.csi.aws.com
volumeHandle: <file-system-id>할당된 AWS 리소스 전체 삭제
클러스터를 삭제하기 전에 AWS EKS 클러스터의 리소스를 먼저 제거하는 것이 좋습니다.
하위 문서
Bahmni Wiki · CC BY-SA 4.0