압축 파일이 분할 저장된 경우, 종류에 상관없이 모두 풀어버리는 유틸리티가 있습니다.

여기에서는 zip 파일을 예시로 들었지만 다른 압축 형태도 풀리므로 아래와 같이 사용해 보세요.

파일 리스트

- test.zip

- test.z01

- test.z02

패키지 설치

# apt -y install p7zip-full

압축 해제

# 7za x test.zip

GitLab은 Git 저장소 관리, CI/CD, 이슈 트래킹, 웹 IDE 등의 기능을 제공하는 자체 호스팅 가능한 플랫폼입니다. 이를 사용하여 소스 코드를 관리하고 프로젝트를 효율적으로 개발할 수 있습니다.

여기에서는 Ubuntu 22.04 서버에서 GitLab 을 설치하는 가이드를 제공합니다. 이 가이드는 기본적인 설치 방법을 제공하며, 실제 프로덕션 환경에서는 보안 및 성능을 위한 추가 구성이 필요할 수 있습니다.

- 공식 사이트 : https://about.gitlab.com/

1. GitLab 설치

환경을 최신으로 유지합니다.

# apt -y update

# apt -y upgrade

GitLab 에 필요한 패키지를 우선 설치합니다.

# apt -y install curl openssh-server ca-certificates tzdata perl

GitLab 패키지 리포지토리를 추가합니다.

여기에서 추가하는 버전은 CE (Community Edition) 입니다.

그리고 우분투 환경에서 테스트 하기때문에 파일명에 deb 문자가 포함된 스크립트로 추가합니다.
# curl -L "https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh" | sudo bash

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  6865  100  6865    0     0  18730      0 --:--:-- --:--:-- --:--:-- 18756
Detected operating system as Ubuntu/jammy.
Checking for curl...
Detected curl...
Checking for gpg...
Detected gpg...
Running apt-get update... done.
Installing apt-transport-https... done.
Installing /etc/apt/sources.list.d/gitlab_gitlab-ce.list...done.
Importing packagecloud gpg key... done.
Running apt-get update... done.

The repository is setup! You can now install packages.

GitLab CE (Community Edition) 를 설치합니다.

아래와 같이 사용할 도메인을 입력하여 명령을 실행합니다.

도메인은 DNS 에서 GitLab 서버 IP 로 연결해 놓아야 합니다.

# EXTERNAL_URL="http://git.sysdocu.kr" apt -y install gitlab-ce

웹 인터페이스에 접속하기 위해 패스워드를 확인합니다.

아래 패스워드는 24시간 유효합니다.

# cat /etc/gitlab/initial_root_password |grep Password:
Password: q2RIma952BAKFM0xJQKvBTD6009m8cwuiHyxtcjYAUE=

* 참고

패스워드 파일이 없거나 분실하여 재설정이 필요할때는 아래 명령을 사용합니다.

# gitlab-rake "gitlab:password:reset[root]"
Enter password: (신규 패스워드)
Confirm password: (신규 패스워드)
Password successfully updated for user with username root.

웹브라우저를 이용해 GitLab 웹 인터페이스에 접속합니다.

- http://git.sysdocu.kr
- ID : root

- PW : 위에 출력된 Password

* 웹페이지 접근이 되지 않을때

로컬에서 이미 포트를 사용하고 있어서 포트를 변경해야 하거나, 도메인이 아닌 IP 로 접근해야 할 수도 있습니다.

설정 파일에서 접속 URL 에 사용하지 않는 포트를 추가하여 재설정하고 접속하면 됩니다.

# vi /etc/gitlab/gitlab.rb

external_url 'http://git.sysdocu.kr:8090'    // 이렇게 사용하지 않는 포트 추가 후 아래 명령으로 재설정

# gitlab-ctl reconfigure

이제 웹페이지 접근이 될 것입니다.

처음 로그인시 상단에 아래와 같은 경고메세지가 출력됩니다.

"가입 제한을 확인합니다. 당신의 GitLab 인스턴스는 누구나 계정을 등록할 수 있도록 하는데, 이것은 공개적으로 직면한 GitLab 인스턴스의 보안 위험입니다. 공용 사용자가 계정에 등록하지 않을 것으로 예상되는 경우 신규 가입을 비활성화해야 합니다."

[ Deactivate ]  [ Acknowledge ]

여기에서 허용한 사용자만 이용할 수 있게 할 예정이므로, 'Deactivate' 버튼을 눌러줍니다.

그러면 화면이 'Sign-up restrictions' 항목으로 이동되는데 그 중에서 아래 내용만 변경하고 [Save changes] 버튼을 눌러 저장합니다.

- Sign-up enabled : 체크 해제

기본 설정된 패스워드가 길어 불편하므로 아래 메뉴를 찾아 root 패스워드를 변경하도록 합니다.

- 좌측 상단 '동그란 프로필 이미지' 클릭 > Preferences 클릭 > 좌측 메뉴에서 Password 클릭

변경 후에는 자동으로 로그아웃이 되며, 다시 로그인 하였을 경우 관리자 초기 페이지가 출력됩니다.

* 참고

1) 설정 파일 : /etc/gitlab/gitlab.rb

    수정 후 반영 : # gitlab-ctl reconfigure

2) GitLab 서비스 재시작 명령 : # gitlab-ctl restart

2. 프로젝트 생성

root 사용자로 로그인 한 경우 다음과 같은 메뉴를 이용할 수 있습니다.

- Create a project

- Create a group

- Add people

- Configure GitLab

이제 Repository 를 만들면 웹 상에서 소스 파일을 만들거나 업로드 할 수 있습니다.

본 매뉴얼에서는 공개 Repository 를 생성하고, CLI 를 통해 소스파일을 업로드, 증분 데이터 업로드 하는 순서로 진행해 보겠습니다.

'Create a project > Create blank project' 메뉴를 순서대로 선택하고 아래 필수 항목만 입력하여 프로젝트를 생성합니다.

나머지는 기본값으로 둡니다.

- Project name : sample

- Project URL & Project slug : http://git.sysdocu.kr/root/sample

- Visibility Level : Private

3. 파일 업로드

1) PC 에서 파일 업로드

로컬 PC 에서 git 명령어를 사용하여 Repository 에 파일을 추가 합니다.

git 명령이 없을 경우 Git 패키지를 설치해야 합니다.

(실습 PC : Ubuntu 22.04)

# apt -y install git

파일을 업로드 하기 위해 소스 파일이 있는 곳으로 이동합니다.

필자는 해당 디렉토리에 업로드 할 샘플 파일을 미리 만들어 두었습니다.

# cd php-sample

# ls -al
합계 1024032
drwxr-xr-x  2 root root      4096  1월 19 16:45 .
drwx------ 25 root root      4096  1월 19 16:45 ..
-rw-r--r--  1 root root 104857600  1월 19 16:44 file01.bin
-rw-r--r--  1 root root 104857600  1월 19 16:44 file02.bin
-rw-r--r--  1 root root 104857600  1월 19 16:44 file03.bin
-rw-r--r--  1 root root 104857600  1월 19 16:44 file04.bin
-rw-r--r--  1 root root 104857600  1월 19 16:44 file05.bin
-rw-r--r--  1 root root 104857600  1월 19 16:44 file06.bin
-rw-r--r--  1 root root 104857600  1월 19 16:44 file07.bin
-rw-r--r--  1 root root 104857600  1월 19 16:44 file08.bin
-rw-r--r--  1 root root 104857600  1월 19 16:44 file09.bin
-rw-r--r--  1 root root 104857600  1월 19 16:44 file10.bin
-rw-r--r--  1 root root        44  1월 19 16:45 index.php

로컬 main 저장소를 초기화 합니다.

# git init -b main

/root/php-sample/.git/ 안의 빈 깃 저장소를 다시 초기화했습니다

원격 저장소를 origin 이라는 이름으로 로컬 저장소에 추가 합니다.

# git remote add origin http://git.sysdocu.kr/root/sample.git

[참고] --------------------

다른 저장소로 연결하기 위해 현재 원격 저장소를 확인하고 해제하는 명령어 입니다.

- 연결 상태 확인 명령어 : git remote 또는 git remote -v

- 연결 해제 명령어 : git remote remove {해제하려는 원격 저장소 이름}

-----------------------------

현재 작업 디렉토리의 모든 변경 사항을 로컬 저장소의 스테이징 영역 (Staging Area) 에 추가합니다.

변경된 파일들을 Git 이 추적하도록 표시하고, 이후에 이 변경 사항들을 커밋에 포함시킬 수 있습니다.

아직 Git 서버로 전송된 것은 아니며, 커밋 이후에 git push 명령을 사용하여 원격 서버로 변경 사항을 전송할 수 있습니다.
. 은 현재 디렉토리의 모든 파일을 의미합니다.

# git add .

스테이징 영역에 추가된 변경 사항들을 실제로 저장소에 기록 (commit) 합니다.
-m 옵션을 이용하여 커밋에 대한 간략한 설명을 입력합니다.
커밋 메시지는 커밋의 의도를 알 수 있도록 명확하게 작성하는 것이 좋습니다.

# git commit -m "First commit"

[main (최상위-커밋) b3e50c2] First commit

 11 files changed, 4 insertions(+)
 create mode 100644 file01.bin
 create mode 100644 file02.bin
 create mode 100644 file03.bin
 create mode 100644 file04.bin
 create mode 100644 file05.bin
 create mode 100644 file06.bin
 create mode 100644 file07.bin
 create mode 100644 file08.bin
 create mode 100644 file09.bin
 create mode 100644 file10.bin
 create mode 100644 index.php

git push 명령어로 로컬 저장소의 변경 사항을 원격 저장소로 전송합니다.
-u 는 원격 저장소의 브랜치 (분기) 에 로컬 브랜치를 연결하는 옵션입니다. 옵션 사용 이후에는 간단히 git push 만 사용하여 변경 사항을 전송할 수 있습니다.
아래는 로컬 main 브랜치의 변경 내용을 origin 이라는 원격 저장소에 업로드하는 명령입니다.

# git push -u origin main

Username for 'http://git.sysdocu.kr': root
Password for 'http://root@git.sysdocu.kr': (계정 비밀번호 입력)
오브젝트 나열하는 중: 5, 완료.
오브젝트 개수 세는 중: 100% (5/5), 완료.
Delta compression using up to 8 threads
오브젝트 압축하는 중: 100% (3/3), 완료.
오브젝트 쓰는 중: 100% (4/4), 99.93 KiB | 157.00 KiB/s, 완료.
Total 4 (delta 0), reused 0 (delta 0), pack-reused 0
To http://git.sysdocu.kr/root/sample.git
   91ee794..4c5d008  main -> main
'main' 브랜치가 리모트의 'main' 브랜치를 ('origin'에서) 따라가도록 설정되었습니다.

[에러 발생시] --------------------

error: 레퍼런스를 'http://git.sysdocu.kr/root/sample.git'에 푸시하는데 실패했습니다

이런 메세지가 출력된 경우는 원격지에는 있는 파일이, 로컬에는 없기 때문에 업데이트가 거부된 것입니다. 이 상황은 보통 처음 push 하거나 또 다른 저장소에서 같은 저장소로 push 할 때 발생합니다.

때문에 git pull 명령으로 원격지의 파일을 가져와서 로컬의 파일과 합치고, 다시 git push 하면 해결이 됩니다.

(pull 은 원격지 파일을 다운로드 하여 현재 디렉토리에 저장하므로 주의할 것)

명령어를 실행할 때 기본적으로 리베이스 (rebase) 전략을 사용하도록 설정합니다.

# git config pull.rebase true

그리고 다시 다운로드, 업로드 명령을 수행합니다.

# git pull origin main

# git push -u origin main

-------------------------------------

2) PC에서 증분 파일 업로드

파일을 한개 추가하고 업로드 할때, 모든 파일을 다시 업로드 하는것이 아니고 한개의 추가된 파일만 업로드 되는지 확인해 봅니다.

# cp -arp file10.bin file11.bin

현재 작업 디렉토리의 모든 변경 사항을 로컬 저장소의 스테이징 영역 (Staging Area) 에 추가합니다.

# git add .

최근 커밋을 수정하고 새로운 커밋을 생성합니다.

# git commit -m "Second commit"

[main 1cf3b17] Second commit
 1 file changed, 1 insertion(+)
 create mode 100644 file11.bin

다시 push 를 하게되면, 추가된 file11.bin 파일만 업로드 됩니다.

이 명령은 변경된 소스 또는 새로운 소스 파일만 업로드 하며, 로컬 디스크에 삭제된 파일이 있을 경우 원격지에서도 삭제하는 동기화 명령입니다.

-u 옵션은 위에서 한번 실행했으므로, 이번에는 생략해 보겠습니다.

# git push origin main
Username for 'http://git.sysdocu.kr': root
Password for 'http://root@git.sysdocu.kr': (계정 비밀번호 입력)
오브젝트 나열하는 중: 3, 완료.
오브젝트 개수 세는 중: 100% (3/3), 완료.
Delta compression using up to 8 threads
오브젝트 압축하는 중: 100% (2/2), 완료.
오브젝트 쓰는 중: 100% (2/2), 244 바이트 | 244.00 KiB/s, 완료.
Total 2 (delta 1), reused 0 (delta 0), pack-reused 0
To http://git.sysdocu.kr/root/sample.git
   3054f87..6943ce1  main -> main

GitLab 웹페이지에서 확인해보면 새로운 파일이 업로드 된것을 확인할 수 있습니다.

또한 올려진 파일리스트를 보면, 업로드 시간이 다른것으로 확인됩니다. 이로써 추가된 파일만 업로드 했음을 알 수 있습니다.

4. 커밋 변경

1) 로그 활용

실수로 로컬 파일을 삭제하거나 잘못 수정하였을때 이전 커밋 시점으로 돌리는 방법입니다.

테스트를 위해 다시 위 예제와 동일한 상태로 만들고 진행하였습니다.

복원이 잘 되는지 확인하기 위해 로컬의 file11.bin 파일을 삭제하였습니다.

# rm file11.bin

로컬의 변경사항을 되돌리기 위해 마지막으로 Git 원격 저장소에 업로드했던 해시를 확인합니다.

(최신 일시 순으로 정렬됩니다)
# git log
commit cfefa5fede689a7004f022f711d749fe8c79bfe1 (HEAD -> main, origin/main)
Author: SYSDOCU <root@sysdocu.kr>
Date:   Tue Jan 23 08:56:08 2024 +0900

    Second commit

commit 4c5d008cec251e152b5a197a6117b7d576611003
Author: SYSDOCU <root@sysdocu.kr>
Date:   Tue Jan 23 08:54:29 2024 +0900

    First commit

commit 91ee7943e944edb6f62a65d1036fb055fbf66753
Author: Administrator <admin@example.com>
Date:   Mon Jan 22 23:53:38 2024 +0000

    Initial commit

로컬의 현재 위치 (커밋) 를 file11.bin 파일이 존재했던 시점으로 변경하면 로컬에 삭제된 파일이 복원 됩니다.

작업량이 많은 경우 더 이전의 커밋 상태로 돌아갈 수도 있습니다.

# git reset --hard cfefa5fede689a7004f022f711d749fe8c79bfe1
HEAD의 현재 위치는 cfefa5f입니다 Second commit

# ls -al
합계 1024032
drwxr-xr-x  2 root root      4096  1월 19 16:45 .
drwx------ 25 root root      4096  1월 19 16:45 ..

drwxr-xr-x  8 root root      4096  1월 23 09:03 .git
-rw-r--r--  1 root root 104857600  1월 19 16:44 file01.bin
-rw-r--r--  1 root root 104857600  1월 19 16:44 file02.bin
-rw-r--r--  1 root root 104857600  1월 19 16:44 file03.bin
-rw-r--r--  1 root root 104857600  1월 19 16:44 file04.bin
-rw-r--r--  1 root root 104857600  1월 19 16:44 file05.bin
-rw-r--r--  1 root root 104857600  1월 19 16:44 file06.bin
-rw-r--r--  1 root root 104857600  1월 19 16:44 file07.bin
-rw-r--r--  1 root root 104857600  1월 19 16:44 file08.bin
-rw-r--r--  1 root root 104857600  1월 19 16:44 file09.bin
-rw-r--r--  1 root root 104857600  1월 19 16:44 file10.bin

-rw-r--r--  1 root root 104857600  1월 19 16:44 file11.bin
-rw-r--r--  1 root root        44  1월 19 16:45 index.php

2) 스테이시 활용

경우에 따라 git stash 명령을 사용해도 됩니다. 현재 작업 디렉토리의 변경사항을 일시적으로 저장하는 기능을 수행하는데, 이는 현재 브랜치에서 아직 커밋하지 않은 변경사항이 있을 때, 브랜치를 변경하거나 다른 브랜치로 이동할 때 유용합니다.
git stash 명령을 실행하면 현재 변경된 파일들을 스태시 스택에 저장하고, 작업 디렉토리는 이전 커밋의 상태로 돌아갑니다. 스태시는 나중에 필요할 때 다시 적용할 수 있습니다.

# git stash

명령 한 번이면 이전 커밋 상태로 돌아갑니다.

5. 전체 다운로드

공개된 Git 소스를 다운로드 받을 때 많이 사용하는 방법으로, 항상 전체 파일을 다운로드 합니다.

로컬에 같은 디렉토리가 있을 경우 다운로드가 되지 않습니다.

# git clone http://git.sysdocu.kr/root/sample.git

metrics-server 는 Kubernetes 클러스터 내에서 노드 및 Pod 의 리소스 사용량에 대한 메트릭 데이터를 수집하고 제공하는 서버입니다. 이러한 메트릭 데이터는 Kubernetes API 서버를 통해 조회할 수 있어, 사용자나 다른 Kubernetes 구성 요소들이 클러스터의 성능 및 리소스 사용에 대한 정보를 얻을 수 있습니다.

metrics-server 가 제공하는 주요 메트릭은 다음과 같습니다:
- CPU 사용량 (CPU Usage) : 클러스터 내의 각 노드 및 Pod 가 사용하는 CPU 의 양을 측정합니다.
- 메모리 사용량 (Memory Usage) : 클러스터 내의 각 노드 및 Pod 가 사용하는 메모리의 양을 측정합니다.
- 네트워크 입출력 (Network I/O) : 클러스터 내의 각 노드 및 Pod 가 수행하는 네트워크 입출력을 측정합니다.
- 파일 시스템 사용량 (Filesystem Usage) : 클러스터 내의 각 노드 및 Pod 가 사용하는 파일 시스템의 용량과 사용량을 측정합니다.

이러한 메트릭 데이터는 Kubernetes 의 Horizontal Pod Autoscaling (HPA) 및 기타 리소스 관리 및 모니터링 도구에서 사용됩니다. metrics-server 는 일반적으로 클러스터 내에서 자동으로 배포되며, Kubernetes 버전 1.8 이상에서는 기본적으로 활성화됩니다.

사용자는 kubectl top 명령을 통해 metrics-server 에서 수집된 메트릭 데이터를 조회할 수 있습니다. 예를 들어, kubectl top pods, kubectl top nodes 등을 사용하여 Pod 및 노드의 리소스 사용량을 확인할 수 있습니다.

1. Metrics-server 설치

설치는 한번의 명령으로 끝이 납니다.

아래 URL 은 공식 배포 URL 로써 항상 최신버전의 metrics-server 가 설치 됩니다.

# kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml
serviceaccount/metrics-server created
clusterrole.rbac.authorization.k8s.io/system:aggregated-metrics-reader created
clusterrole.rbac.authorization.k8s.io/system:metrics-server created
rolebinding.rbac.authorization.k8s.io/metrics-server-auth-reader created
clusterrolebinding.rbac.authorization.k8s.io/metrics-server:system:auth-delegator created
clusterrolebinding.rbac.authorization.k8s.io/system:metrics-server created
service/metrics-server created
deployment.apps/metrics-server created
apiservice.apiregistration.k8s.io/v1beta1.metrics.k8s.io created

명령이 잘 실행되는지 확인합니다.

아래는 nodes 의 자원 사용률 확인 명령입니다.

# kubectl top nodes
error: Metrics API not available

이와 동일한 에러가 출력된 경우, metrics-server Pod 가 잘 생성되었는지 확인합니다.

# kubectl get pod -A |grep metrics
kube-system                                     metrics-server-5d875656f5-vmv66                                 0/1     Running     0          10s

설치가 되었으나 Running 중인 Pod 는 0개로 확인 됩니다.

Pod 의 상세 정보에서는 HTTP status code 500 에러가 확인되었습니다.

# kubectl describe pod metrics-server-5d875656f5-vmv66 -n kube-system

...

(생략)

...

Events:
  Type     Reason     Age               From               Message
  ----     ------     ----              ----               -------
  Normal   Scheduled  52s               default-scheduler  Successfully assigned kube-system/metrics-server-5d875656f5-vmv66 to kind-control-plane
  Normal   Pulled     51s               kubelet            Container image "registry.k8s.io/metrics-server/metrics-server:v0.6.4" already present on machine
  Normal   Created    51s               kubelet            Created container metrics-server
  Normal   Started    51s               kubelet            Started container metrics-server
  Warning  Unhealthy  1s (x4 over 31s)  kubelet            Readiness probe failed: HTTP probe failed with statuscode: 500

문제 해결을 위해 Deployment 를 수정합니다.

# kubectl edit deployment metrics-server -n kube-system

출력된 내용중에 metric-resolution 문자열을 검색해서 그 다음에 옵션을 하나 더 추가해 주어야 하는데, 문자열을 검색하면 두 군데 나옵니다. 그중에서 아래와 같이 옵션이 행으로 구분된 곳에 --kubelet-insecure-tls 옵션을 추가해 줍니다.

kubelet-insecure-tls 옵션은 공식적으로 발급받은 인증서인지 확인하지 않고 접근하겠다는 의미입니다.

...

(생략)

...

    spec:
      containers:
      - args:
        - --cert-dir=/tmp
        - --secure-port=4443
        - --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname
        - --kubelet-use-node-status-port
        - --metric-resolution=15s
        - --kubelet-insecure-tls
        image: registry.k8s.io/metrics-server/metrics-server:v0.6.4

...

(생략)

...

저장 후 시간이 조금 지나야 적용됩니다.

적용이 되면 아래와 같이 자원 사용량 확인이 가능합니다.

# kubectl top nodes
NAME                 CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%   
kind-control-plane   294m         3%     2753Mi          17%  

# kubectl top pods
NAME                                                    CPU(cores)   MEMORY(bytes)   
b07a7888-df03-451f-8475-13c6d9bac48d-cf--cb3e18e9fd-0   1m           4Mi             
nginx-665cb6f744-wf5g5                                  0m           6Mi      

네임스페이스에 일정 용량을 적용하여 그 안의 Pod 가 제한된 용량 안에서만 자원을 나누어 사용할 수 있도록 합니다.

본 매뉴얼은 아래 공식 문서를 참고하여 작성하였습니다.

https://kubernetes.io/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/

1. 네임스페이스 생성

테스트를 위한 네임스페이스를 생성합니다.

# kubectl create namespace sysdocu-ns

2. 할당량 생성 및 적용

네임스페이스에 적용할 할당량을 설정합니다.

# vi rq.yaml

작성한 할당량을 먼저 생성한 네임스페이스에 적용합니다.

# kubectl apply -f rq.yaml -n sysdocu-ns
resourcequota/mem-cpu-limits created

설정한 리소스 할당량과 사용량에 대한 정보를 볼 수 있습니다.

# kubectl get resourcequota mem-cpu-limits -n sysdocu-ns --output=yaml
apiVersion: v1
kind: ResourceQuota
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","kind":"ResourceQuota","metadata":{"annotations":{},"name":"mem-cpu-limits","namespace":"sysdocu-ns"},"spec":{"hard":{"limits.cpu":"2","limits.memory":"2Gi","requests.cpu":"1","requests.memory":"1Gi"}}}
  creationTimestamp: "2024-01-11T00:29:34Z"
  name: mem-cpu-limits
  namespace: sysdocu-ns
  resourceVersion: "12801859"
  uid: 98127c56-33bc-4ccc-a55c-1152b7f04128
spec:
  hard:
    limits.cpu: "2"
    limits.memory: 2Gi
    requests.cpu: "1"
    requests.memory: 1Gi
status:
  hard:
    limits.cpu: "2"
    limits.memory: 2Gi
    requests.cpu: "1"
    requests.memory: 1Gi
  used:
    limits.cpu: "0"
    limits.memory: "0"
    requests.cpu: "0"
    requests.memory: "0"

위 예시의 리소스 할당량 (ResourceQuota : mem-cpu-limits) 이 설정된 네임스페이스에 다음과 같은 제약 사항이 있습니다.
- 네임스페이스의 모든 Pod 에 대해 각 컨테이너에는 메모리 요청, 메모리 제한, CPU 요청 및 CPU 제한이 있어야 합니다.
- 해당 네임스페이스에 있는 모든 Pod 에 대한 메모리 요청 합계는 1 GiB 를 초과해서는 안 됩니다.
- 해당 네임스페이스에 있는 모든 Pod 의 메모리 제한 합계는 2 GiB 를 초과해서는 안 됩니다.
- 해당 네임스페이스에 있는 모든 포드에 대한 CPU 요청 합계는 1 CPU 를 초과해서는 안 됩니다.
- 해당 네임스페이스에 있는 모든 포드의 CPU 제한 합계는 2 CPU 를 초과해서는 안 됩니다.

3. 첫번째 Pod 생성

테스트를 위해 간단한 Pod 를 생성합니다.

# vi pod1.yaml

# kubectl apply -f pod1.yaml -n sysdocu-ns
pod/demo-pod1 created

Pod 가 정상 실행되고 있는지 확인합니다.

# kubectl get pod demo-pod1 -n sysdocu-ns
NAME        READY   STATUS    RESTARTS   AGE
demo-pod1   1/1     Running   0          80s

설정한 리소스 할당량과 사용량에 대한 정보를 다시 확인합니다.

아래와 같이 사용량이 변경된 것을 확인할 수 있습니다.

# kubectl get resourcequota mem-cpu-limits -n sysdocu-ns --output=yaml

apiVersion: v1
kind: ResourceQuota
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","kind":"ResourceQuota","metadata":{"annotations":{},"name":"mem-cpu-limits","namespace":"sysdocu-ns"},"spec":{"hard":{"limits.cpu":"2","limits.memory":"2Gi","requests.cpu":"1","requests.memory":"1Gi"}}}
  creationTimestamp: "2024-01-11T00:29:34Z"
  name: mem-cpu-limits
  namespace: sysdocu-ns
  resourceVersion: "12805135"
  uid: 98127c56-33bc-4ccc-a55c-1152b7f04128
spec:
  hard:
    limits.cpu: "2"
    limits.memory: 2Gi
    requests.cpu: "1"
    requests.memory: 1Gi
status:
  hard:
    limits.cpu: "2"
    limits.memory: 2Gi
    requests.cpu: "1"
    requests.memory: 1Gi
  used:
    limits.cpu: 800m
    limits.memory: 800Mi
    requests.cpu: 400m
    requests.memory: 600Mi

jq 명령어 사용이 가능한 시스템에서는 아래와 같이 필요한 항목만 출력시킬 수 있습니다.

# kubectl get resourcequota mem-cpu-limits -n sysdocu-ns -o jsonpath='{ .status.used }' | jq .
{
  "limits.cpu": "800m",
  "limits.memory": "800Mi",
  "requests.cpu": "400m",
  "requests.memory": "600Mi"
}

4. 두번째 Pod 생성

테스트를 위해 두번째 Pod 를 생성합니다.

# vi pod2.yaml

# kubectl apply -f pod2.yaml -n sysdocu-ns
Error from server (Forbidden): error when creating "pod2.yaml": pods "demo-pod2" is forbidden: exceeded quota: mem-cpu-limits, requested: requests.memory=700Mi, used: requests.memory=600Mi, limited: requests.memory=1Gi

네임스페이스 내에서 사용 가능한 요청 메모리가 1Gi 인데, Pod1 의 메모리 600MiB 에 Pod2 의 메모리 700MiB 를 추가하려니까 에러가 발생했습니다.

600MiB + 700MiB > 1 GiB.

이렇게 ResourceQuota 을 이용해 네임스페이스에 리소스 할당량을 사용하여 제한하는 방법을 알아보았습니다.

ab는 Apache HTTP server의 성능을 측정하기 위한 ApacheBench 도구로, 웹 서버에 대한 부하 테스트를 수행하는 데 사용됩니다. 다수의 요청을 동시에 보내고 서버의 응답 시간, 처리량 등을 측정하여 성능을 평가할 수 있습니다.

ab 명령어는 httpd 또는 apache2 를 설치하면 사용이 가능합니다.

Ubuntu 를 사용하는 경우 유틸리티 패키지만 설치하여 사용이 가능합니다.

# apt -y install apache2-utils

이제 사용 가능한 ab 명령으로 아래 예시처럼 실행합니다.

# ab -n 1000 -c 50 http://www.sysdocu.kr/

-n 1000 : 전체 요청 횟수는 1000번 입니다.
-c 50 : 동시에 처리되는 연결 수는 50개 입니다.
http://www.sysdocu.kr/ : 요청을 보낼 웹사이트의 주소입니다. 도메인 뒤에 슬래시 ('/') 가 꼭 있어야 합니다.

결과를 다시 살펴 보겠습니다.

# ab -n 1000 -c 50 http://www.sysdocu.kr/
This is ApacheBench, Version 2.3 <$Revision: 1879490 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking http://www.sysdocu.kr(be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests


Server Software:        Apache/2.4.57
Server Hostname:        http://www.sysdocu.kr 
Server Port:            80

Document Path:          /
Document Length:        211 bytes

Concurrency Level:      50
Time taken for tests:   0.264 seconds
Complete requests:      1000
Failed requests:        0
Non-2xx responses:      1000
Total transferred:      682000 bytes
HTML transferred:       211000 bytes
Requests per second:    3791.34 [#/sec] (mean)
Time per request:       13.188 [ms] (mean)
Time per request:       0.264 [ms] (mean, across all concurrent requests)
Transfer rate:          2525.09 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        1    4   1.5      5       7
Processing:     4    9   2.4      8      25
Waiting:        2    8   2.3      8      23
Total:          5   13   2.1     13      28

Percentage of the requests served within a certain time (ms)
  50%     13
  66%     13
  75%     13
  80%     14
  90%     14
  95%     16
  98%     19
  99%     21
 100%     28 (longest request)

이중에서 Time taken for tests:   0.264 seconds 부분을 살펴보면 됩니다.

페이지를 모두 요청하여 응답받기까지 총 0.264초 소요되었습니다.

Autoscaler 종류는 총 세가지 입니다.

1) HPA (Horizontal Pod Autoscaler) : 애플리케이션의 복제본 수를 조정합니다. HPA 는 CPU 활용도를 기반으로 복제 컨트롤러, 배포, 복제본 집합 또는 상태 저장 집합의 포드 수를 조정합니다. HPA 는 또한 사용자 지정 또는 외부 메트릭을 기반으로 스케일링 결정을 내리도록 구성될 수 있습니다.

2) CA (Cluster Autoscaler) : 클러스터의 노드 수를 조정합니다. 클러스터 오토스케일러는 노드가 포드를 실행할 수 있는 자원이 부족하거나 (노드를 추가), 노드의 활용도가 낮은 상태로 있을 때 (노드를 제거), 포드가 다른 노드에 할당될 수 있을 때 (노드를 제거), 클러스터에서 노드를 자동으로 추가하거나 제거합니다.

3) VPA (Vertical Pod Autoscaler) : 클러스터 내 컨테이너의 리소스 요청 및 제한을 조정합니다. 본 매뉴얼에서 다룰 내용입니다.

- 공식 Document : https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler

1. VPA (Vertical Pod Autoscaler) 배포

VPA 사용을 위해 필요한 파일을 다운로드 받고 클러스터에 배포합니다.
# git clone https://github.com/kubernetes/autoscaler.git
# cd autoscaler/vertical-pod-autoscaler
# ./hack/vpa-up.sh

배포가 잘 되었는지 확인합니다.

# kubectl get pods -n kube-system |grep vpa
NAME                                         READY   STATUS    RESTARTS   AGE
vpa-admission-controller-754ccfdf99-pkxnl    1/1     Running   0          45s
vpa-recommender-667f9769fb-84rl5             1/1     Running   0          46s
vpa-updater-696b8787f9-6665j                 1/1     Running   0          46s

- VPA Admission-Controller : VPA 업데이터가 Pod 를 제거하고 다시 시작할 때마다 새 Pod 가 시작되기 전에 Webhook 를 사용하여 CPU 및 메모리 설정을 변경합니다.

- VPA Recommender : Metric Server 의 정보를 참조하여 적합한 리소스 크기를 추천합니다.

- VPA Updater : 1분에 1회씩 변경 사항을 확인하고 업데이트 합니다.

VPA 사용자 지정 리소스 정의가 생성되었는지 확인합니다.
# kubectl get customresourcedefinition | grep verticalpodautoscalers

verticalpodautoscalers.autoscaling.k8s.io             2023-12-29T07:32:30Z

2. Pod 생성

Deployment 로 생성한 Pod 에 적용이 잘 되는지 확인해보겠습니다.

아래와 같이 Deployment 구성 파일을 작성합니다.

# vi deployment.yaml

작성한 yaml 파일을 적용합니다.

# kubectl apply -f deployment.yaml

deployment.apps/nginx created

생성된 Pod 이름을 확인합니다.

# kubectl get pod

NAME                                                     READY   STATUS      RESTARTS   AGE
nginx-7f856c878-gbk77                                    1/1     Running     0          7m43s

Pod 에 적용된 자원 요청 및 제한값을 확인합니다.

# kubectl describe pod nginx-7f856c878-gbk77 |grep -E 'cpu|memory'
      cpu:     100m
      memory:  256Mi
      cpu:        50m
      memory:     128Mi

변경을 위해 Vertical Pod Autoscaler 구성 파일을 작성합니다.

# vi vpa.yaml

작성한 yaml 파일을 적용합니다.

# kubectl apply -f vpa.yaml

verticalpodautoscaler.autoscaling.k8s.io/nginx-vpa created

생성한 VPA 를 확인합니다.

VPA Updater 가 1분 간격으로 변경 사항을 확인하고 업데이트 하기 때문에 조금 기다려야 정확한 내용 확인이 가능합니다.

# kubectl get vpa
NAME        MODE   CPU    MEM     PROVIDED   AGE
nginx-vpa   Auto   100m   256Mi   True       8m28s

자세한 VPA 정보를 확인합니다.

# kubectl describe vpa nginx-vpa

...

Status:
  Conditions:
    Last Transition Time:  2024-01-02T05:17:45Z
    Status:                True
    Type:                  RecommendationProvided
  Recommendation:
    Container Recommendations:
      Container Name:  nginx
      Lower Bound:
        Cpu:     100m
        Memory:  256Mi
      Target:
        Cpu:     100m
        Memory:  256Mi
      Uncapped Target:
        Cpu:     25m
        Memory:  262144k
      Upper Bound:
        Cpu:     100m
        Memory:  256Mi

...

이미 생성되어 있는 Pod 에는 적용되지 않으므로 Pod 를 삭제하여 재생성 되도록 합니다.

# kubectl delete pod nginx-7f856c878-gbk77

pod "nginx-7f856c878-gbk77" deleted

재생성된 Pod 이름을 확인합니다.

# kubectl get pod
NAME                                                     READY   STATUS      RESTARTS   AGE
nginx-75954b4f8d-6g54j                                   1/1     Running     0          62s

새로 적용된 자원 요청 및 제한값을 확인합니다.

Deployment 의 설정값보다 VPA 설정값이 우선시 되는것을 확인하였습니다.

# kubectl describe pod nginx-75954b4f8d-6g54j |grep -E 'cpu|memory'

                  vpaUpdates: Pod resources updated by nginx-vpa: container 0: cpu request, memory request, cpu limit, memory limit
      cpu:     200m
      memory:  512Mi
      cpu:        100m
      memory:     256Mi

참고로, VPA 에서 Deployment 가 인식되는 시간 (최대 1분) 이 필요한데, VPA 를 먼저 정의한 다음에 Deployment (Pod 자동 생성) 를 생성한다 하더라도 VPA 가 Deployment 를 인식하기 전에 Pod 가 먼저 생성되는 경우가 많으므로 Pod 삭제 작업은 꼭 필요합니다.

삭제 작업 없이 Pod 를 생성하는대로 적용하고 싶으면, Deployment 생성시 replicas: 0 으로 먼저 적용하고, VPA 에서 인식이 되면 replicas: 1 등으로 수정, 적용하세요. Deployment 인식 이후에 생성된 Pod 이므로 VPA 요청 및 제한값에 맞추어 생성됩니다.

Cloud Foundry 환경에서는 보통 BOSH 로 Service 를 구현합니다. 하지만 BOSH 를 사용할 수 없는 경우에는 Helm 또는 Kubectl 명령을 이용해 서비스 구성이 가능합니다. 본 매뉴얼에서는 Helm 또는 Kubectl 을 이용해 Cloud Foundry Service (MySQL) 를 구성하는 방법에 대해 설명합니다.

- 목적 : CF 서비스나 Helm, Kubectl 모두 결과적으로 MySQL Pod 를 생성하고 네트워크 연결이 가능하면 되는 것

[ Helm 을 이용한 방법 ]

Helm 은 Kubernetes 애플리케이션을 관리하기 위한 오픈 소스 패키지 관리 도구입니다. Helm 은 애플리케이션을 쉽게 배포하고 업데이트하며, Kubernetes 클러스터에서 애플리케이션의 버전 관리를 지원합니다. OS 에서 자주 사용되는 yum 이나 apt 명령과 같이 Kubernetes 운영이 쉽도록 도와주는 도구라고 생각하면 이해가 쉽습니다.

1. 네임스페이스 확인

MySQL 서비스를 배포할 네임스페이스 이름을 확인합니다.

# kubectl get ns
NAME                                            STATUS   AGE
cert-manager                                    Active   19d
cf                                              Active   19d
cf-org-32cdb0e1-4d3e-40f5-878d-898aacb136ee     Active   19d
cf-space-5fd2f012-5436-4fbd-82b5-e25b701437d3   Active   19d
default                                         Active   19d
korifi-system                                   Active   19d
kpack                                           Active   19d
kube-node-lease                                 Active   19d
kube-public                                     Active   19d
kube-system                                     Active   19d
local-path-storage                              Active   19d
metallb-system                                  Active   19d
projectcontour                                  Active   19d

* 참고

작업 편의를 위해 컨텍스트 (네임스페이스) 를 변경해도 됩니다. 그러면 이후의 명령이나 설정에서 네임스페이스를 입력해야 하는 수고를 덜 수 있습니다. 여기에서는 방법을 알려드리지만, 이후의 명령이나 설정에서는 네임스페이스를 추가하도록 하겠습니다.

# kubectl config set-context --current --namespace=cf-space-5fd2f012-5436-4fbd-82b5-e25b701437d3

2. Helm Repository 추가

Helm 명령으로 MySQL 을 설치하기 위해 Repository 를 추가합니다.

# helm repo add bitnami https://charts.bitnami.com/bitnami

추가한 Repository 를 확인합니다.

# helm repo list
NAME    URL                               
bitnami https://charts.bitnami.com/bitnami

설치 가능한 서비스 목록을 확인합니다.

# helm search repo bitnami

(결과 생략)

3. MySQL 설치

확인된 네임스페이스에 아래와 같이 MySQL 을 설치 합니다.

root 패스워드는 추후 설치 가능하지만 여기에서는 설치할때 같이 적용하였습니다.

패스워드는 숫자만 입력하는 것을 허용하지 않으므로 문자를 반드시 포함해야 합니다.

# helm install my-mysql --namespace cf-space-5fd2f012-5436-4fbd-82b5-e25b701437d3 --set auth.rootPassword="pw12345678" bitnami/mysql

참고로 MySQL 을 다시 삭제하려면 helm uninstall my-mysql -n cf-space-5fd2f012-5436-4fbd-82b5-e25b701437d3 명령을 사용하면 됩니다.

설치된 Helm 릴리즈 목록을 확인합니다.

# helm ls -n cf-space-5fd2f012-5436-4fbd-82b5-e25b701437d3
NAME     NAMESPACE                                     REVISION UPDATED                                 STATUS   CHART        APP VERSION
my-mysql cf-space-5fd2f012-5436-4fbd-82b5-e25b701437d3 1        2023-12-28 15:30:21.487507655 +0900 KST deployed mysql-9.15.0 8.0.35

생성된 MySQL Pod 의 IP 를 확인합니다.

# kubectl get pod -n cf-space-5fd2f012-5436-4fbd-82b5-e25b701437d3 -o wide

NAME                                                     READY   STATUS      RESTARTS   AGE    IP             NODE                 NOMINATED NODE   READINESS GATES
my-mysql-0                                               1/1     Running     0          104s   10.244.0.205   kind-control-plane   <none>           <none>

4. 배포된 소스와 연결 확인

cf push 명령으로 배포된 PHP 소스에서 MySQL 연결이 잘 되는지 확인해보겠습니다.

PHP 빌드팩이 준비되지 않으신 분은 아래 URL 을 참고해 주세요.

https://sysdocu.tistory.com/1863

아래와 같은 소스를 준비하고 cf push 명령으로 배포합니다.

* 주의

- Cloud Foundry 조직과 공간이 설치한 MySQL 의 공간과 동일해야 합니다.

- 소스에 위에서 확인했던 MySQL IP 를 넣어주세요.

# mkdir php-sample

# cd php-sample

# vi index.php

필요한 PHP 모듈을 추가합니다.

# mkdir .php.ini.d
# vi .php.ini.d/extentions.ini

소스를 배포합니다.

# cf push php1

(결과 생략)

출력된 URL 로 접근하여 PHP 소스와 MySQL 연결이 잘 되었는지 확인합니다.

# curl --insecure https://php1.apps.az1.sysdocu.kr 

MySQL 연결 성공. 서버 버전 : 8.0.35

[ Kubectl 을 이용한 방법 ]

Kubernetes 에서 기본으로 제공하는 Kubectl 명령으로도 MySQL 배포가 가능한데, Helm 과는 다르게 리소스 제한이 가능합니다. 특정 Pod 의 CPU, 메모리 등의 자원을 제한하기 위해서는 Kubernetes 의 리소스 제한 설정을 사용해야 합니다. 아래는 MySQL 을 실행하는 Pod 에 리소스 제한을 설정하는 예제입니다. 이 예제에서는 CPU 와 메모리, 용량에 각각 제한을 두었습니다.

1. MySQL Deployment 작성 및 적용

아래와 같이 Manifest 파일을 작성합니다.

# vi mysql.yaml

작성한 yaml 파일을 적용합니다.

# kubectl appy -f mysql.yaml

deployment.apps/new-mysql created

생성된 MySQL Pod 의 IP 를 확인합니다.

# kubectl get pod -n cf-space-5fd2f012-5436-4fbd-82b5-e25b701437d3 -o wide

NAME                                                     READY   STATUS      RESTARTS   AGE     IP             NODE                 NOMINATED NODE   READINESS GATES

new-mysql-9b45cb976-wx8zf                                1/1     Running     0          106s    10.244.0.193   kind-control-plane   <none>           <none>

2. 배포된 소스와 연결 확인

cf push 명령으로 배포된 PHP 소스에서 MySQL 연결이 잘 되는지 확인해보겠습니다.

PHP 빌드팩이 준비되지 않으신 분은 아래 URL 을 참고해 주세요.

https://sysdocu.tistory.com/1863

아래와 같은 소스를 준비하고 cf push 명령으로 배포합니다.

* 주의

- Cloud Foundry 조직과 공간이 설치한 MySQL 의 공간과 동일해야 합니다.

- 소스에 위에서 확인했던 MySQL IP 를 넣어주세요.

# mkdir php-sample

# cd php-sample

# vi index.php

필요한 PHP 모듈을 추가합니다.

# mkdir .php.ini.d
# vi .php.ini.d/extentions.ini

소스를 배포합니다.

# cf push php2

(결과 생략)

출력된 URL 로 접근하여 PHP 소스와 MySQL 연결이 잘 되었는지 확인합니다.

# curl --insecure https://php2.apps.az1.sysdocu.kr

MySQL 연결 성공. 서버 버전 : 8.2.0

AWS Elastic Beanstalk 는 소스 파일을 업로드하기만 하면 Elastic Beanstalk 가 용량 프로비저닝부터 로드 밸런싱, 자동 크기 조정, 웹 애플리케이션 상태 모니터링에 이르기까지 배포를 자동으로 처리하며, 지속적인 완전관리형 패치 및 보안 업데이트를 제공합니다.

본 매뉴얼은 AWS Elastic Beanstalk 에서 제공하는 많은 기능들을 담은게 아닌 기초적인  소스 배포 방법만 다루었습니다. AWS 에 무료 가입 이후 콘솔에서 아래 절차를 따라 서비스를 이용하면 됩니다.

* 사전 작업 : AWS 회원가입 및 Elastic Beanstalk 콘솔 페이지 (https://console.aws.amazon.com/elasticbeanstalk) 이동 

[ 콘솔에서 배포 ]

1. 애플리케이션 생성

우측 상단에 잘 보이는 '애플리케이션 생성' 버튼을 클릭하고 아래 절차대로 진행합니다.

테스트 목적이므로 가장 간단한 내용으로 구성했으며 경우에 따라 설정값을 약간씩 조정 가능합니다.

1) 환경 구성
- 환경 티어 : 웹 서버 환경

2) 애플리케이션 정보
- 애플리케이션 이름 : sysdocu test

3) 환경 정보
- 환경 이름 : Sysdocutest-env
- 도메인 : sysdocutest (sysdocutest.eu-north-1.elasticbeanstalk.com 완성 도메인)
- 환경 설명 : test

4) 플랫폼
- 플랫폼 유형 : 관리형 플랫폼
- 플랫폼 : PHP
- 플랫폼 브랜치 : PHP 8.1 running on 64bit Amazon Linux 2023
- 플랫폼 버전 : 4.0.4 (Recommended)

5) 애플리케이션 코드
- 코드 업로드 (선택)      // 컴퓨터에서 소스를 업로드 하거나 Amazon S3 에서 복사할 수 있음
- 버전 레이블 : 0.0.1    // 코드에 대한 버전 입력
- 로컬 파일 (선택), 애플리케이션 업로드 (파일 선택)
* 여기에서 업로드 할 파일 (index.zip) 은 아래 내용으로 index.php 파일을 만든 후 zip 으로 압축하였습니다.
<?php
echo "Elastic Beanstalk !!<br>";
phpinfo();
?>

6) 사전 설정
- 구성 사전 설정 : 단일 인스턴스(프리 티어 사용 가능)

모든 값을 입력했으면, [다음] 버튼을 누릅니다.

2. 서비스 액세스

- 서비스 역할 : 새 서비스 역할 생성 및 사용
- 서비스 역할 이름 : aws-elasticbeanstalk-service-role
- EC2 키 페어 : https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/create-key-pairs.html 안내를 따라 Key Pair 파일을 생성하고 선택합니다.
- EC2 인스턴스 프로파일 : https://docs.aws.amazon.com/ko_kr/codedeploy/latest/userguide/getting-started-create-iam-instance-profile.html#getting-started-create-iam-instance-profile-console 안내를 따라 IAM 인스턴스 프로파일을 생성하고 선택합니다.

3. 네트워킹, 데이터베이스 및 태그 설정

아래 항목만 설정해 줍니다.

1) Virtual Private Cloud(VPC)

- VPC : 풀다운 메뉴를 누르면 사설대역이 하나 나오는데 이것을 선택합니다.

2) 인스턴스 설정

- 퍼블릭 IP 주소 : 활성화됨 (체크), 인스턴스 서브넷에 나온 가용 영역중 한개를 선택합니다. (여기에서는 172.31.0.0/20 을 선택 했습니다)

[다음] 버튼을 누릅니다.

4. 인스턴스 트래픽 및 조정 구성

아래 항목만 설정해 줍니다.

1) 인스턴스 유형 : t2.nano 또는 t3.nano   // 제일 저렴한 상품

[다음] 버튼을 누릅니다.

5. 업데이트, 모니터링 및 로깅 구성

아무것도 하지 않고 넘어가겠습니다.
[다음] 버튼을 누릅니다.

6. 검토

지금까지 선택한 사항이 출력되므로, 한번 훑어보고 잘못된 선택이 포함된경우 [편집] 을 눌러 수정하고, 이상이 없을 경우 [제출] 버튼을 누릅니다.
제출 버튼을 누른 경우 [콘솔] 페이지로 돌아오게 되며, Elastic Beanstalk 가 환경을 시작하기 까지 몇 분정도 소요됩니다.
기다려 봅니다.

상단 알림바에서 '환경이 성공적으로 시작되었습니다.' 라는 메세지가 출력되면 정보란에 출력된 도메인을 선택하여 소스코드가 잘 보여지는지 확인합니다.

* 참고 : Laravel 소스 배포

Laravel 소스를 배포할때는 초기 index 페이지가 /public 디렉토리에 존재하므로 위 절차대로 진행시 403 에러가 출력됩니다.

해결 방법으로는, 어플리케이션 '환경' 을 수정하면 되는데 위 '5. 업데이트, 모니터링 및 로깅 구성' 범주에 있는 문서 루트값을 입력해주면 됩니다.

- 문서 루트 : /public

* 참고 : 데이터베이스 사용

데이터베이스를 사용하고자 할 경우 '3. 네트워킹, 데이터베이스 및 태그 설정' 범주의 데이터베이스 부분을 활성화 시키고 아래 내용을 설정합니다. 아래 예시는 임의대로 입력하였으며, 테스트 또는 서비스에 사용에 적합한 값으로 변경, 적용하여 사용하시기 바랍니다.

'인스턴스 클래스' 에서 선택한 상품의 요금이 추가 청구 됩니다.

1) 데이터베이스 설정

- 엔진 : mysql

- 엔진 버전 : 8.0.35

- 인스턴스 클래스 : db.t3.micro

- 스토리지 : 5

- 사용자 이름 : sysdocu

- 암호 : 12345678

- 가용성 : 낮음(AZ 1개)

- 데이터베이스 삭제 정책 : 삭제

[ CLI 에서 배포 ]

1. CLI 명령어 설치

eb 명령어 설치를 간편하게 하기 위해 스크립트를 제공합니다. 아래와 같이 스크립트를 이용해 설치를 진행합니다.

# git clone https://github.com/aws/aws-elastic-beanstalk-cli-setup.git

# python ./aws-elastic-beanstalk-cli-setup/scripts/ebcli_installer.py

* eb 명령어는 python 라는 명령어를 사용하므로, python3 이 설치된 시스템일 경우 아래와 같이 링크파일을 생성해주면 됩니다.

# ln -s /usr/bin/python3 /usr/bin/python

설치된 eb 명령어 버전을 확인합니다.

# eb --version
EB CLI 3.20.10 (Python 3.10.12 (main, Nov 20 2023, 15:14:05) [GCC 11.4.0])

2. 애플리케이션 환경 설정

php 파일이 준비된 디렉토리에서 실행해야 합니다.

아래는 간단히 php 파일을 생성한 예제 이므로, 개인적인 소스 코드를 가지고 있을 경우 해당 디렉토리로 이동합니다.

# mkdir php-sample

# cd php-sample

# vi index.php

애플리케이션 배포를 위한 환경 설정을 먼저 진행합니다.

# eb init

Select a default region
1) us-east-1 : US East (N. Virginia)
2) us-west-1 : US West (N. California)
3) us-west-2 : US West (Oregon)
4) eu-west-1 : EU (Ireland)
5) eu-central-1 : EU (Frankfurt)
6) ap-south-1 : Asia Pacific (Mumbai)
7) ap-southeast-1 : Asia Pacific (Singapore)
8) ap-southeast-2 : Asia Pacific (Sydney)
9) ap-northeast-1 : Asia Pacific (Tokyo)
10) ap-northeast-2 : Asia Pacific (Seoul)
11) sa-east-1 : South America (Sao Paulo)
12) cn-north-1 : China (Beijing)
13) cn-northwest-1 : China (Ningxia)
14) us-east-2 : US East (Ohio)
15) ca-central-1 : Canada (Central)
16) eu-west-2 : EU (London)
17) eu-west-3 : EU (Paris)
18) eu-north-1 : EU (Stockholm)
19) eu-south-1 : EU (Milano)
20) ap-east-1 : Asia Pacific (Hong Kong)
21) me-south-1 : Middle East (Bahrain)
22) il-central-1 : Middle East (Israel)
23) af-south-1 : Africa (Cape Town)
24) ap-southeast-3 : Asia Pacific (Jakarta)
25) ap-northeast-3 : Asia Pacific (Osaka)
(default is 3): 10

명령 실행하면 리전 선택 화면이 나옵니다.

Seoul 을 선택하고 진행합니다.

You have not yet set up your credentials or your credentials are incorrect 
You must provide your credentials.
(aws-access-id): AKIATULSZDRUVAVPUM4H
(aws-secret-key): w7L9tc6vtTy5TENKE8YWARz9SqADnuLG1gs02WzL

액세스 키는 AWS Identity and Access Management 콘솔에서 생성됩니다. 키가 없는 경우 아래 URL 을 참고하여 생성합니다.

https://docs.aws.amazon.com/ko_kr/elasticbeanstalk/latest/dg/eb-cli3-configuration.html

Enter Application Name
(default is "root"): sysdocu-eb
Application sysdocu-eb has been created.

생성할 애플리케이션 이름을 입력하고 아래 단계에서 개발언어를 선택합니다.

여기에서는 PHP 소스를 배포하기 위해 7번을 선택하였습니다.

It appears you are using Node.js. Is this correct?
(Y/n): n
Select a platform.
1) .NET Core on Linux
2) .NET on Windows Server
3) Docker
4) Go
5) Java
6) Node.js
7) PHP
8) Packer
9) Python
10) Ruby
11) Tomcat
(make a selection): 7

플랫폼 버전을 선택합니다.

Select a platform branch.
1) PHP 8.2 running on 64bit Amazon Linux 2023
2) PHP 8.1 running on 64bit Amazon Linux 2023
3) PHP 8.1 running on 64bit Amazon Linux 2
4) PHP 8.0 running on 64bit Amazon Linux 2 (Deprecated)
(default is 1): 1

인스턴스에 SSH 접속이 필요한 경우 Y 를 입력합니다.

Cannot setup CodeCommit because there is no Source Control setup, continuing with initialization
Do you want to set up SSH for your instances?
(Y/n): y

Key Pair 가 없는 경우 아래와 같이 생성합니다.

Type a keypair name.
(Default is aws-eb): sysdocu_keypair

Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase): (엔터)
Enter same passphrase again: (엔터)
Your identification has been saved in /root/.ssh/sysdocu_keypair
Your public key has been saved in /root/.ssh/sysdocu_keypair.pub
The key fingerprint is:
SHA256:Yp/23Lnk4spaDXQWxgH16tsf8Peo0t3Sclx5DWLwfhs sysdocu_keypair
The key's randomart image is:
+---[RSA 3072]----+
|        .+=.     |
|         .oo     |
|        . oo.    |
|       . o .+ .  |
|      o S .o.. .o|
|     . o =  .oE.+|
|        = o..oo*+|
|       + oo*..=+*|
|      ..oo=oB+o+.|
+----[SHA256]-----+
WARNING: Uploaded SSH public key for "sysdocu_keypair" into EC2 for region ap-northeast-2.

여기까지 진행하면 현재 디렉토리에 .elasticbeanstalk 디렉토리와 .gitignore 파일이 생성됩니다.

참고로 파일이 생성된 상태에서 위 설정을 다시 선택하고 싶을 경우에는 eb init --interactive 명령을 사용합니다.

이번에는 eb create 명령을 실행합니다.

3. 애플리케이션 배포

# eb create
Enter Environment Name
(default is sysdocu-eb-dev): (엔터)
Enter DNS CNAME prefix
(default is sysdocu-eb-dev): (엔터)

Select a load balancer type
1) classic
2) application
3) network
(default is 2): (엔터)


Would you like to enable Spot Fleet requests for this environment? (y/N): n
Creating application version archive "app-231227_105647010648".
Uploading php-sample/app-231227_105647010648.zip to S3. This may take a while.
Upload Complete.
Environment details for: php-sample-dev
  Application name: php-sample
  Region: ap-northeast-2
  Deployed Version: app-231227_105647010648
  Environment ID: e-ukt3apx7xv
  Platform: arn:aws:elasticbeanstalk:ap-northeast-2::platform/PHP 8.2 running on 64bit Amazon Linux 2023/4.0.4
  Tier: WebServer-Standard-1.0
  CNAME: php-sample-dev.ap-northeast-2.elasticbeanstalk.com
  Updated: 2023-12-27 01:56:49.739000+00:00
Printing Status:
2023-12-27 01:56:48    INFO    createEnvironment is starting.
2023-12-27 01:56:49    INFO    Using elasticbeanstalk-ap-northeast-2-249900375145 as Amazon S3 storage bucket for environment data.
2023-12-27 01:57:15    INFO    Created security group named: sg-03917a84777b4c349
2023-12-27 01:57:31    INFO    Created security group named: awseb-e-ukt3apx7xv-stack-AWSEBSecurityGroup-119R1T01HLB5M
2023-12-27 01:57:31    INFO    Created Auto Scaling launch configuration named: awseb-e-ukt3apx7xv-stack-AWSEBAutoScalingLaunchConfiguration-vyMuxcBrdNwa
2023-12-27 01:57:31    INFO    Created target group named: arn:aws:elasticloadbalancing:ap-northeast-2:249900375145:targetgroup/awseb-AWSEB-S3ZQNDBFXRE4/07a7ad3c4fe8bb6a
2023-12-27 01:57:46    INFO    Created Auto Scaling group named: awseb-e-ukt3apx7xv-stack-AWSEBAutoScalingGroup-FCDZ3L234LAU
2023-12-27 01:57:47    INFO    Waiting for EC2 instances to launch. This may take a few minutes.
2023-12-27 01:57:47    INFO    Created Auto Scaling group policy named: arn:aws:autoscaling:ap-northeast-2:249900375145:scalingPolicy:5b8a67d5-b413-4224-ade6-2e85c25b1417:autoScalingGroupName/awseb-e-ukt3apx7xv-stack-AWSEBAutoScalingGroup-FCDZ3L234LAU:policyName/awseb-e-ukt3apx7xv-stack-AWSEBAutoScalingScaleDownPolicy-nAUVg0sg5nRn
2023-12-27 01:57:47    INFO    Created Auto Scaling group policy named: arn:aws:autoscaling:ap-northeast-2:249900375145:scalingPolicy:d9978a08-e318-484c-a4b3-8368b0276185:autoScalingGroupName/awseb-e-ukt3apx7xv-stack-AWSEBAutoScalingGroup-FCDZ3L234LAU:policyName/awseb-e-ukt3apx7xv-stack-AWSEBAutoScalingScaleUpPolicy-Neqs0FM41Apy
2023-12-27 01:58:02    INFO    Created CloudWatch alarm named: awseb-e-ukt3apx7xv-stack-AWSEBCloudwatchAlarmLow-FJ5YorP1s1Bh
2023-12-27 01:58:02    INFO    Created CloudWatch alarm named: awseb-e-ukt3apx7xv-stack-AWSEBCloudwatchAlarmHigh-uPMubhxbNaq8
2023-12-27 01:59:53    INFO    Created load balancer named: arn:aws:elasticloadbalancing:ap-northeast-2:249900375145:loadbalancer/app/awseb--AWSEB-aeBAFiqHxWdL/92ce8b40aa34ddaa
2023-12-27 01:59:54    INFO    Created Load Balancer listener named: arn:aws:elasticloadbalancing:ap-northeast-2:249900375145:listener/app/awseb--AWSEB-aeBAFiqHxWdL/92ce8b40aa34ddaa/25ced3633c1d40d2
2023-12-27 01:59:58    INFO    Instance deployment: You didn't include a 'composer.json' file in your source bundle. The deployment didn't install Composer dependencies.
2023-12-27 02:00:03    INFO    Instance deployment completed successfully.
2023-12-27 02:01:08    INFO    Successfully launched environment: php-sample-dev

맨 마지막 Successfully launched 로그 확인 후, 웹브라우저에서 조금 위에 출력된 CNAME 항목의 도메인으로 접근하면 개발한 소스코드 내용이 출력됩니다.

4. 애플리케이션 삭제

사용하지 않는 AWS 리소스에 대한 요금이 발생하지 않도록 실행 중인 환경을 종료합니다.

그런데 왜인지 CLI 에서 생성한 Elastic Beanstalk 애플리케이션은 콘솔에서 보이지 않습니다.

삭제도 CLI 에서 진행해야 하는데, 배포했던 소스 디렉토리 내에서 아래와 같이 삭제 명령을 실행합니다.

관련 옵션은 Document 를 참고하세요.

https://docs.aws.amazon.com/ko_kr/elasticbeanstalk/latest/dg/eb3-terminate.html

# eb terminate
The environment "php-sample-dev" and all associated instances will be terminated.
To confirm, type the environment name: php-sample-dev
2023-12-27 02:23:35    INFO    terminateEnvironment is starting.
2023-12-27 02:23:36    INFO    Validating environment's EC2 instances have termination protection disabled before performing termination.
2023-12-27 02:23:36    INFO    Finished validating environment's EC2 instances for termination protection.
2023-12-27 02:23:54    INFO    Deleted CloudWatch alarm named: awseb-e-ukt3apx7xv-stack-AWSEBCloudwatchAlarmLow-FJ5YorP1s1Bh 
2023-12-27 02:23:54    INFO    Deleted Load Balancer listener named: arn:aws:elasticloadbalancing:ap-northeast-2:249900375145:listener/app/awseb--AWSEB-aeBAFiqHxWdL/92ce8b40aa34ddaa/25ced3633c1d40d2
2023-12-27 02:23:54    INFO    Deleted CloudWatch alarm named: awseb-e-ukt3apx7xv-stack-AWSEBCloudwatchAlarmHigh-uPMubhxbNaq8 
2023-12-27 02:23:54    INFO    Deleted Auto Scaling group policy named: arn:aws:autoscaling:ap-northeast-2:249900375145:scalingPolicy:5b8a67d5-b413-4224-ade6-2e85c25b1417:autoScalingGroupName/awseb-e-ukt3apx7xv-stack-AWSEBAutoScalingGroup-FCDZ3L234LAU:policyName/awseb-e-ukt3apx7xv-stack-AWSEBAutoScalingScaleDownPolicy-nAUVg0sg5nRn
2023-12-27 02:23:54    INFO    Deleted Auto Scaling group policy named: arn:aws:autoscaling:ap-northeast-2:249900375145:scalingPolicy:d9978a08-e318-484c-a4b3-8368b0276185:autoScalingGroupName/awseb-e-ukt3apx7xv-stack-AWSEBAutoScalingGroup-FCDZ3L234LAU:policyName/awseb-e-ukt3apx7xv-stack-AWSEBAutoScalingScaleUpPolicy-Neqs0FM41Apy
2023-12-27 02:23:54    INFO    Waiting for EC2 instances to terminate. This may take a few minutes.
2023-12-27 02:24:55    INFO    Deleted load balancer named: arn:aws:elasticloadbalancing:ap-northeast-2:249900375145:loadbalancer/app/awseb--AWSEB-aeBAFiqHxWdL/92ce8b40aa34ddaa
2023-12-27 02:25:25    INFO    Deleted Auto Scaling group named: awseb-e-ukt3apx7xv-stack-AWSEBAutoScalingGroup-FCDZ3L234LAU
2023-12-27 02:25:26    INFO    Deleted target group named: arn:aws:elasticloadbalancing:ap-northeast-2:249900375145:targetgroup/awseb-AWSEB-S3ZQNDBFXRE4/07a7ad3c4fe8bb6a
2023-12-27 02:25:26    INFO    Deleted Auto Scaling launch configuration named: awseb-e-ukt3apx7xv-stack-AWSEBAutoScalingLaunchConfiguration-vyMuxcBrdNwa
2023-12-27 02:25:26    INFO    Deleted security group named: awseb-e-ukt3apx7xv-stack-AWSEBSecurityGroup-119R1T01HLB5M
2023-12-27 02:25:26    INFO    Deleted security group named: sg-03917a84777b4c349
2023-12-27 02:25:29    INFO    Deleting SNS topic for environment php-sample-dev.
2023-12-27 02:25:30    INFO    terminateEnvironment completed successfully.

Document 에서는 모든 구성 요소 삭제를 위해 아래와 같은 옵션을 제공합니다.

삭제할 요소가 있는지 한 번 더 확인합니다.

# eb terminate --all
The application "php-sample" and all its resources will be deleted.
This application currently has the following:
Running environments: 0
Configuration templates: 0
Application versions: 1

To confirm, type the application name: php-sample
Removing application versions from s3.
2023-12-27 02:34:31    INFO    deleteApplication is starting.
2023-12-27 02:34:31    INFO    Validating environment before performing delete
2023-12-27 02:34:31    INFO    Invoking Environment Termination workflows.
2023-12-27 02:34:32    INFO    The environment termination step is done.
2023-12-27 02:34:32    INFO    The application has been deleted successfully.

NLnet Labs 에서 제작한 NSD (Name Server Daemon) 은 BSD 라이센스를 가지고 있는 오픈소스 DNS 로써 속도, 신뢰성, 안정성 및 높은 보안성이 특징입니다. NSD 는 타 DNS 에 비해 월등히 빠른 속도를 보입니다. 몇 십만개 또는 몇 백만개의 쿼리를 요청하는 경우에도 쉽게 처리가 가능한 성능을 발휘하기 때문에 최상위 루트 네임서버중 몇 대는 NSD 로 사용되고 있다고 알려져 있습니다.

여기에서는 간단히 NSD 를 소스로 설치하고 sysdocu.kr 도메인을 등록해 질의 테스트하는 부분까지 안내합니다.

* 참고 : 패키지 설치 방법

# apt -y update

# apt -y install nsd

1. 설치

NSD 소스 파일을 다운로드 합니다.

공식 홈페이지에서는 현재 4.8.0 버전을 배포하고 있습니다.

- 공식 홈페이지 : https://nlnetlabs.nl/projects/nsd/about/
# wget https://nlnetlabs.nl/downloads/nsd/nsd-4.8.0.tar.gz

압축을 해제하고 설치 디렉토리로 이동합니다.

# tar xvzf nsd-4.8.0.tar.gz

# cd nsd-4.8.0

NSD 설치에 필요한 패키지를 사전 설치합니다.
# apt -y update
# apt -y install build-essential libssl-dev libevent-dev bison flex

NSD 설치를 계속 진행합니다.
# ./configure
# make
# make install

설치가 완료되었으면 명령어를 통해 설치 버전을 확인합니다.

# nsd -v
NSD version 4.8.0
Written by NLnet Labs.

Configure line:
Event loop: libevent 2.1.12-stable (uses epoll)
Linked with OpenSSL 3.0.2 15 Mar 2022

Copyright (C) 2001-2020 NLnet Labs.  This is free software.
There is NO warranty; not even for MERCHANTABILITY or FITNESS
FOR A PARTICULAR PURPOSE.

2. 설정

기본 설정 파일을 생성합니다.

# cp -arp /etc/nsd/nsd.conf.sample /etc/nsd/nsd.conf

기본 파일에 옵션이 많이 있는것을 확인할 수 있습니다.

하지만 모든 옵션에 대한 설명을 다루지 않을 예정이므로 아래와 같이 몇가지 옵션만으로 구성해 보겠습니다.

아래 내용에 없는 옵션을 사용하고자 할 경우 공식 Ducoment 를 참고하시기 바랍니다.

https://nsd.docs.nlnetlabs.nl/en/latest/manpages/nsd.conf.html

설정파일에 사용할 key 파일과 pem 파일은 생성 명령이 준비되어 있으므로, 우선 테스트를 위해 아래 도메인 부분만 보유한 도메인으로 변경하고, 나머지는 같은 내용으로 작성합니다.

# vi /etc/nsd/nsd.conf

도메인을 여러개 등록하려는 경우 nsd.conf 파일 하단 3줄 (zone 부분) 을 복사하여 아래로 붙여넣고 도메인과 zone 파일명을 적절히 수정하면 됩니다.

설정이 제대로 되었는지 명령을 통해 확인합니다.

출력되는 내용은 고쳐야 하는 내용이며, 아무런 결과가 나오지 않으면 정상입니다.

# nsd-checkconf /etc/nsd/nsd.conf

설정파일에 사용했던 key 파일과 pem 파일을 생성합니다.

# nsd-control-setup
setup in directory /etc/nsd
Certificate request self-signature ok
subject=CN = nsd-control
removing artifacts
Setup success. Certificates created. Enable in nsd.conf file to use

생성된 key 파일과 pem 파일을 확인합니다.

# ll /etc/nsd
total 52
drwxr-xr-x   2 root root  4096 12월 21 10:56 ./
drwxr-xr-x 108 root root  4096 12월 20 22:38 ../
-rw-r--r--   1 root root   666 12월 21 10:56 nsd.conf
-rw-r--r--   1 root root 16685 12월 20 21:50 nsd.conf.sample
-rw-------   1 root root  2484 12월 21 10:56 nsd_control.key
-rw-r-----   1 root root  1484 12월 21 10:56 nsd_control.pem
-rw-------   1 root root  2484 12월 21 10:56 nsd_server.key
-rw-r-----   1 root root  1529 12월 21 10:56 nsd_server.pem

zone 파일을 생성합니다.

# vi /etc/nsd/sysdocu.kr.zone

마찬가지로 zone 파일의 설정이 제대로 되었는지 체크해봅니다.

형식) nsd-checkzone {zone이름} {zone파일}

# nsd-checkzone sysdocu.kr /etc/nsd/sysdocu.kr.zone
zone sysdocu.kr is ok

NSD 사용자를 생성합니다.

# useradd -r nsd

* 참고

이제 데몬을 구동해야 하는데, 이전에 53번 포트를 systemd-resolved  데몬이 사용하고 있을 경우 nsd 가 시작되지 않으므로 해당 데몬을 중지하고, 서버에서 외부 DNS 를 사용하기 위해서 /etc/resolv.conf 파일 최상단에 nameserver 8.8.8.8 를 추가해 줍니다.

방법은 netstat -nltp 로 확인이 가능합니다.

예) systemctl stop systemd-resolved

nsd 데몬을 구동하고 상태를 확인합니다.

# nsd-control start

# nsd-control status

version: 4.8.0
verbosity: 0

3. 테스트

외부에서 도메인 질의를 합니다.

# nslookup sysdocu.kr 115.68.249.135
Server: 115.68.249.135
Address: 115.68.249.135#53

Name: sysdocu.kr
Address: 115.68.249.232

# nslookup -type=mx sysdocu.kr 115.68.249.135
Server: 115.68.249.135
Address: 115.68.249.135#53

sysdocu.kr mail exchanger = 10 mail.sysdocu.kr.

Ubuntu 22.04 에서 MaraDNS 설치하는 방법입니다.

apt 와 같은 패키지 관리 툴로 손쉽게 설치가 가능한 부분이 있지만,

# apt -y update

# apt -y install maradns

여기에서는 소스로 설치하고 관리하는 방법을 알려드립니다.

우선 MaraDNS 의 특징은 용량이 작고, 가볍고 (메모리 점유율이 낮음), 빠른 (Performance) 장점이 있습니다.

PowerDNS 는 DB 와 연동을하여 레코드로 zone 파일 내용을 관리하지만, MaraDNS 는 Bind 와 같이 파일로 레코드를 관리합니다.

1. 설치

소스를 설치하기 위해 gcc 컴파일러를 우선 설치 합니다.

# apt -y install gcc

그리고 현재 기준 MaraDNS 3.5.0036 버전을 다운로드하고 압축을 풀어 설치합니다.

- Download : https://maradns.samiam.org/download.html

# wget https://maradns.samiam.org/download/3.5/3.5.0036/maradns-3.5.0036.tar.xz

# tar xvf maradns-3.5.0036.tar.xz

# cd maradns-3.5.0036

# CC=cc

# export CC

# make

# make install

설치가 모두 마무리되면 출력된 내용과 같이 데몬을 실행해줍니다.

# systemctl start maradns
# systemctl start deadwood    // 필수 구동은 아니므로, 아래 설명 확인 후 구동 여부를 선택해주세요.

netstat 명령으로 포트가 확인되면 좋은데, MaraDNS 는 UDP 통신을 하므로, netstat 명령으로 포트가 확인되지 않아 프로세스 상태로 체크해봐야 합니다.

# systemctl status maradns

2. 설정

MaraDNS 는 역할에 따라 설정 파일이 두개로 나뉩니다.

1) /etc/mararc (관련 데몬 : maradns)

이 파일은 DNS 서버를 실행하는 데 사용되며, DNS 질의 및 응답 동작을 제어하는 다양한 설정을 포함합니다. 주요한 설정 사항은 zone 파일의 경로, Listen 주소, 캐싱 및 안전성 관련 설정 등이 있습니다.

2) /etc/dwood3rc (관련 데몬 : deadwood)

이 파일은 특정 환경에서의 DNS 서버 동작을 제어하는데 사용됩니다. DNS 캐시 설정, 불필요한 DNS 쿼리에 대한 차단, 차단된 도메인 목록 관리 등과 같은 설정을 포함할 수 있습니다. DNS 의 보안과 효율성을 향상시키는데 사용됩니다.

여기에서는 기본 설정만 다루겠습니다.

# vi /etc/mararc

* 외부 질의를 허용하려면 Binding 주소를 공인 IP 로 변경해야 합니다.

  VM 의 경우 ifconfig 명령으로 공인 IP 가 보이지 않는 경우에는 (공인과 연결된) 사설 IP 로 입력해 보시기 바랍니다.

도메인 zone 파일을 생성합니다.

# vi /etc/maradns/db.sysdocu.kr

적용을 위해 데몬을 재시작 합니다.

# systemctl restart maradns

3. 테스트

로컬 또는 외부에서 질의 테스트를 해봅니다.

# nslookup sysdocu.kr 115.68.249.135
Server: 115.68.249.135
Address: 115.68.249.135#53

Name: sysdocu.kr
Address: 115.68.249.232