구약성서의 구조

공동번역 성경의 구분과 용어로 설명해드리겠습니다.

1. 오경

• 창세기: 세상과 인류의 시작, 이스라엘 민족의 조상들
• 탈출기: 이집트 탈출과 십계명
• 레위기: 예배와 제사 규정
• 민수기: 광야 생활
• 신명기: 모세의 마지막 가르침

2. 역사서

• 여호수아기: 가나안 정복
• 심판기: 지도자들의 시대
• 룻기: 다윗의 가문 이야기
• 사무엘기 상하: 왕정 시대의 시작
• 열왕기 상하: 두 왕국의 역사
• 역대기 상하: 다윗 왕조 중심의 역사
• 에즈라기: 귀환과 성전 재건
• 느헤미야기: 예루살렘 성벽 재건
• 토빗기: 유배시대의 신앙 이야기
• 유딧기: 구원의 역사
• 에스테르기: 페르시아에서의 구원
• 마카베오기 상하: 독립 투쟁의 역사

3. 시서와 지혜서

• 욥기: 고난과 신앙
• 시편: 기도와 찬양의 노래
• 잠언: 삶의 지혜
• 코헬렛: 인생의 의미 탐구
• 아가: 사랑의 노래
• 지혜서: 하느님의 지혜
• 집회서: 실천적 지혜

4. 예언서
   대예언서:

• 이사야서: 메시아 예언과 희망
• 예레미야서: 유다의 멸망과 새 계약
• 애가: 예루살렘 멸망을 슬퍼하는 노래
• 바룩서: 유배자들에 대한 위로
• 에제키엘서: 새 성전과 회복
• 다니엘서: 하느님 나라의 승리

소예언서:

• 호세아서부터 말라키서까지 12권의 예언서
• 각 시대의 예언자들이 전한 하느님의 말씀

공동번역에는 제2경전(듀테로카노니카)이 포함되어 있어 개신교 성경보다 책의 수가 더 많습니다. 이 책들은 토빗기, 유딧기, 마카베오기 상하, 지혜서, 집회서, 바룩서 등입니다.

Ubuntu NFS server, mac client

Ubuntu NFS 서버 설정

1. NFS 서버 패키지 설치

sudo apt update
sudo apt install nfs-kernel-server

2. 공유 디렉토리 생성

sudo mkdir -p /data/shared
sudo chown nobody:nogroup /data/shared
sudo chmod 777 /data/shared

3. NFS 설정 파일 수정

/etc/exports 파일을 편집합니다:

sudo nano /etc/exports

다음 라인을 추가합니다 (클라이언트 IP에 맞게 수정):

/data/shared *(rw,sync,no_subtree_check,insecure)

4. NFS 서버 재시작

sudo exportfs -a
sudo systemctl restart nfs-kernel-server

5. 방화벽 설정 (필요한 경우)

sudo ufw allow from any to any port nfs
sudo ufw allow 2049

Mac 클라이언트 연결

1. 마운트 포인트 생성

sudo mkdir -p /Volumes/nfs_share

2. NFS 마운트

sudo mount -t nfs -o resvport,rw {ubuntu-ip-address}:/data/shared /Volumes/nfs_share
# 나의 경우는 
sudo mount -t nfs -o resvport,rw,User=shawn {ubuntu-ip-address}:/stuff/nfs-share /Users/shawn/mini12

3. 자동 마운트 설정 (선택사항)

/etc/fstab에 추가:

{ubuntu-ip-address}:/data/shared /Volumes/nfs_share nfs resvport,rw 0 0

연결 테스트

마운트된 디렉토리에서 파일 생성 테스트:

touch /Volumes/nfs_share/test.txt

문제 해결

• NFS 서버 상태 확인:

sudo systemctl status nfs-kernel-server

• 마운트 포인트 확인:

mount | grep nfs

• 공유 목록 확인:

showmount -e {ubuntu-ip-address}

helm install 설명

helm install 할 때, helm install harbor -f xx.yaml . 로 명령을 내릴 때, 명령어의 각 arguments와 flag를 설명해 보겠다.

helm install:

• 기본 helm 명령어로, 새로운 차트를 쿠버네티스 클러스터에 설치한다는 의미입니다

harbor:

• 설치할 릴리스의 이름입니다
• 이 이름으로 helm과 쿠버네티스에서 해당 설치를 식별합니다
• 다른 이름(예: my-harbor)으로 변경할 수 있습니다

-f xx.yaml:

• -f 또는 --values 플래그는 차트의 기본값을 오버라이드할 설정 파일을 지정합니다
• xx.yaml에는 사용자가 정의한 커스텀 설정값들이 포함됩니다
• 여러 개의 설정 파일을 사용하려면 -f 플래그를 여러 번 사용할 수 있습니다 (예: -f values1.yaml -f values2.yaml)

. (마침표):

• 차트의 소스 위치를 지정합니다
• 현재 디렉토리를 의미하며, 이는 현재 디렉토리에 Chart.yaml 파일이 있어야 함을 의미합니다
• 대신 차트 저장소의 차트 이름(예: harbor/harbor)이나 압축된 차트 파일의 경로를 지정할 수도 있습니다

기타 자주 사용되는 옵션들:

• --namespace: 설치할 네임스페이스 지정
• --create-namespace: 지정한 네임스페이스가 없는 경우 생성
• --debug: 디버그 정보 출력
• --dry-run: 실제 설치 없이 결과만 미리 확인

nslookup, dig 명령어의 기본적인 사용법

 nslookup은 DNS 조회를 위한 매우 유용한 네트워크 도구입니다. 기본적인 사용법을 설명해드리겠습니다:

1. 가장 기본적인 사용법:

nslookup example.com

이렇게 하면 도메인의 IP 주소를 조회할 수 있습니다.

2. 특정 DNS 서버를 지정해서 조회하기:

nslookup example.com 8.8.8.8

(8.8.8.8은 Google의 DNS 서버입니다)

3. 역방향 DNS 조회 (IP로 도메인 찾기):

nslookup 192.0.2.1

4. 대화형 모드 사용:

nslookup
> server 8.8.8.8    // DNS 서버 지정
> example.com       // 도메인 조회

5. 레코드 타입 지정 조회:

nslookup -type=MX example.com     // 메일 서버 정보 조회
nslookup -type=NS example.com     // 네임서버 정보 조회
nslookup -type=A example.com      // IPv4 주소 조회
nslookup -type=AAAA example.com   // IPv6 주소 조회

조회 결과에는 보통 다음과 같은 정보가 포함됩니다:

• 사용된 DNS 서버의 정보
• 조회한 도메인의 정식 이름
• 해당하는 IP 주소들
• TTL(Time To Live) 값

dig(Domain Information Groper)는 nslookup과 비슷하지만 더 강력하고 유연한 DNS 조회 도구입니다. 많은 리눅스 관리자들이 dig를 선호하는데, 그 이유는:

1. 기본 사용법:

dig example.com

2. 간단한 출력만 보기 (+short 옵션):

dig +short example.com

3. 특정 DNS 서버 지정:

dig @8.8.8.8 example.com

4. 특정 레코드 타입 조회:

dig example.com MX    # 메일 서버 정보
dig example.com NS    # 네임서버 정보
dig example.com ANY   # 모든 레코드 정보

nslookup과 비교했을 때 dig의 장점:

• 더 자세한 타이밍 정보 제공
• 결과 포맷이 더 읽기 쉽고 스크립팅하기 좋음
• DNSSEC 관련 정보도 쉽게 확인 가능
• 더 많은 쿼리 옵션 제공

일반적으로 리눅스/유닉스 환경에서는 dig를 더 많이 사용하고, Windows 환경에서는 기본으로 제공되는 nslookup을 주로 사용합니다.

nfs-subdir-external-provisioner의 storageclass에서 pathPattern을 삭제하면 어떻게 되지?

StorageClass에서 pathPattern을 삭제하면 NFS 프로비저너는 기본 경로 패턴을 사용합니다.

nfs-subdir-external-provisioner의 기본 동작은 다음과 같습니다:

1. 기본 경로 패턴:

{.PVC.namespace}-{.PVC.name}

예를 들어:

• namespace: production
• PVC 이름: data-pvc 일 경우 → production-data-pvc 디렉토리가 NFS 서버의 base path 아래에 생성됩니다.

2. 실제 경로 구성:

[NFS base path]/[namespace]-[pvc-name]-[pvc-uid]

예시:

• NFS base path: /exports
• namespace: production
• PVC 이름: data-pvc
• PVC UID: abc123 → 최종 경로: /exports/production-data-pvc-abc123

이는 다음과 같은 특징이 있습니다:

• 각 PVC마다 고유한 디렉토리가 생성됨
• namespace와 PVC 이름을 조합하여 구분이 용이함
• UID를 포함하여 이름 충돌 방지

만약 특별한 디렉토리 구조가 필요하지 않다면, pathPattern을 삭제하고 기본 패턴을 사용하는 것이 안전합니다.

pvc의 accessmode

 PVC(PersistentVolumeClaim)의 accessModes는 볼륨의 접근 방식을 정의합니다. Kubernetes에서는 3가지 접근 모드를 제공합니다:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteOnce     # 단일 노드에서 읽기/쓰기
    # 또는
    - ReadOnlyMany      # 다중 노드에서 읽기 전용
    # 또는
    - ReadWriteMany     # 다중 노드에서 읽기/쓰기

1. ReadWriteOnce (RWO)

• 단일 노드에서만 읽기/쓰기가 가능
• 하나의 노드에서만 마운트 가능
• 해당 노드의 여러 파드에서는 동시에 사용 가능
• 적합한 사용 사례:
  • 데이터베이스 볼륨
  • 단일 인스턴스 애플리케이션의 로컬 스토리지

2. ReadOnlyMany (ROX)

• 여러 노드에서 읽기 전용으로 마운트 가능
• 모든 노드가 동시에 볼륨을 읽을 수 있음
• 적합한 사용 사례:
  • 설정 파일
  • 정적 컨텐츠
  • 공유 라이브러리

3. ReadWriteMany (RWX)

• 여러 노드에서 동시에 읽기/쓰기가 가능
• 클러스터의 모든 노드가 동시에 접근 가능
• 적합한 사용 사례:
  • 공유 파일 시스템
  • CI/CD 빌드 디렉토리
  • 여러 파드가 공유하는 데이터
  • NFS와 같은 네트워크 스토리지

스토리지 유형별 지원하는 접근 모드:

1. NFS

• RWO, ROX, RWX 모두 지원
• 가장 유연한 접근 모드 지원

2. Local 볼륨

• RWO만 지원
• 노드에 물리적으로 연결된 스토리지

3. AWS EBS, Azure Disk

• 기본적으로 RWO만 지원
• 클라우드 블록 스토리지의 특성상 단일 노드 접근만 가능

예시 - NFS PVC:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfs-pvc
spec:
  accessModes:
    - ReadWriteMany    # NFS는 RWX 지원
  storageClassName: nfs-storage
  resources:
    requests:
      storage: 10Gi

주의사항:

• 스토리지 솔루션이 지원하지 않는 접근 모드를 요청하면 PVC 생성이 실패할 수 있음
• 일부 스토리지는 특정 접근 모드에서 성능 저하가 있을 수 있음
• 보안 요구사항에 따라 적절한 접근 모드 선택 필요

containers/volumeMounts 설정 필드

 volumeMounts 필드의 각 속성들에 대해 상세히 설명해드리겠습니다:

containers:
  volumeMounts:
  - name: app-storage           # volume의 이름
    mountPath: /app/data        # 컨테이너 내부 마운트 경로
    subPath: data              # 볼륨 내부의 하위 경로
    readOnly: false            # 읽기 전용 여부
    mountPropagation: None     # 마운트 전파 정책

1. name

• 필수 필드입니다
• Pod의 volumes 섹션에서 정의된 볼륨의 이름과 일치해야 합니다
• 이를 통해 어떤 볼륨을 마운트할지 지정합니다

2. mountPath

• 필수 필드입니다
• 볼륨을 마운트할 컨테이너 내부의 절대 경로를 지정합니다
• 예: /var/log, /app/config, /data 등
• 다른 volumeMount와 중첩되지 않아야 합니다

3. subPath

• 선택적 필드입니다
• 볼륨 내의 특정 하위 디렉토리를 마운트하고 싶을 때 사용합니다
• 전체 볼륨이 아닌 특정 하위 경로만 마운트하므로 다른 마운트와 볼륨을 공유할 수 있습니다
• 예시:

  volumeMounts:
  - name: shared-data
    mountPath: /app1/data
    subPath: app1
  - name: shared-data
    mountPath: /app2/data
    subPath: app2
  

4. readOnly

• 선택적 필드입니다 (기본값: false)
• true: 읽기 전용으로 마운트
• false: 읽기/쓰기 모두 가능

5. mountPropagation

• 선택적 필드입니다
• 호스트-컨테이너 간 마운트 전파 방식을 결정합니다
• 가능한 값:
  • None: 호스트의 후속 마운트가 컨테이너에 표시되지 않음 (기본값)
  • HostToContainer: 호스트의 후속 마운트가 컨테이너에도 표시됨
  • Bidirectional: 호스트와 컨테이너 양방향으로 마운트가 전파됨

사용 예시:

containers:
- name: app
  image: nginx
  volumeMounts:
  # 기본적인 볼륨 마운트
  - name: config-volume
    mountPath: /etc/nginx/conf.d
    
  # 읽기 전용 설정 파일
  - name: ssl-certs
    mountPath: /etc/ssl/certs
    readOnly: true
    
  # 공유 볼륨의 특정 하위 디렉토리 사용
  - name: shared-data
    mountPath: /app/my-data
    subPath: app1/data
    
  # 로그 디렉토리를 호스트와 양방향 공유
  - name: log-volume
    mountPath: /var/log
    mountPropagation: Bidirectional

이러한 설정들을 통해 컨테이너와 볼륨 간의 세밀한 마운트 제어가 가능합니다.

deployment에서 pvc를 이용하여 볼륨을 이용하는 방법과 상세 경로 설정을 지정하는 법

Kubernetes 클러스터에서 NetApp NFS 스토리지를 사용하기 위한 구성을 설명해드리겠습니다.

1. 먼저 NFS 프로비저너를 설치해야 합니다:

helm repo add nfs-subdir-external-provisioner https://kubernetes-sigs.github.io/nfs-subdir-external-provisioner/
helm install nfs-provisioner nfs-subdir-external-provisioner/nfs-subdir-external-provisioner \
    --set nfs.server=<NetApp_NFS_IP> \
    --set nfs.path=/your/exported/path

2. StorageClass 생성:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: netapp-nfs
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
provisioner: k8s-sigs.io/nfs-subdir-external-provisioner
parameters:
  archiveOnDelete: "false"
  pathPattern: "${.PVC.namespace}/${.PVC.name}"  # 이는 NFS 내의 경로 패턴을 정의합니다

3. PVC(PersistentVolumeClaim) 생성:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: app-data
  namespace: your-namespace
spec:
  accessModes:
    - ReadWriteMany  # NFS는 여러 파드에서 동시 접근 가능
  storageClassName: netapp-nfs
  resources:
    requests:
      storage: 10Gi

4. Deployment에서 PVC 사용:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: your-app
  namespace: your-namespace
spec:
  replicas: 3
  selector:
    matchLabels:
      app: your-app
  template:
    metadata:
      labels:
        app: your-app
    spec:
      containers:
      - name: app
        image: your-image:tag
        volumeMounts:
        - name: app-storage
          mountPath: /app/data  # 컨테이너 내부의 마운트 경로
          subPath: data  # PV 내의 하위 경로 (선택사항)
      volumes:
      - name: app-storage
        persistentVolumeClaim:
          claimName: app-data

특정 경로 설정을 위한 팁:

• subPath: PV 내의 특정 하위 디렉토리를 마운트할 때 사용
• mountPath: 컨테이너 내부의 마운트 위치 지정
• StorageClass의 pathPattern을 사용하여 NFS 서버 내의 디렉토리 구조 정의 가능

주의사항:

1. NetApp NFS 서버의 export 설정이 올바르게 되어 있어야 합니다
2. 모든 Kubernetes 노드에 NFS 클라이언트가 설치되어 있어야 합니다
3. 네트워크 방화벽이 NFS 포트(일반적으로 2049)를 허용해야 합니다

이런 설정을 통해 파드들은 NetApp 스토리지에 영구적으로 데이터를 저장하고 접근할 수 있게 됩니다.