WebLogic 12c: 노드 매니저(NodeManager) 설정하기

WebLogic 에서 노드매니저(NodeManger)는 웹로직을 운영할 머신(Machine) 에 설치되는 것으로 웹로직의 Admin 서버에 요청을 받아 처리해주는 역할을 한다. 노드매니저가 하는 일은 대략 다음과 같다.

  • 매니지드 서버 생성/삭제
  • 매니지드 서버 시작, 중지, 종료

웹로직을 설치하면 노드 매니저도 함께 설치가 된다. 기본적으로 터미널 상에서 노드매니저를 설정을 한 후에 Admin 콘솔에서 Admin 서버가 인식할 수 있도록 등록을 해줘야 한다.

여기서는 터미널 상에서 노드매니저 설정에 대해서 간단하게 다루어 본다.

노드매니저 설정

웹로직을 설치하고 난 후에 도메인(Domain) 을 생성하면 노드매니저 관련 내용도 함께 설치가 된다. 기본적으로 도메인 디렉토리에 nodemanager 디렉토리가 함께 존재하게 되고 여기에 파일들이 존재하게 되는데, 각 파일의 역할은 다음과 같다.

  • nodemanager/nodemanager.domains – 웹로직의 도메인. 파일 시스템상의 도메인의 풀 경로를 입력해준다.
  • nodemanager/nodemanager.properties – 노드 관리자 설정에 핵심 파일이다.
  • config/nodemanager/nm_password.properties – 노드매니저 사용자ID, 패스워드 정보를 담고 있는 파일. 암호화 되어 있지만 초기화가 가능하다.

핵심은 nodemanager.properties 인데 다음과 같은 3가지가 핵심적이 설정으로 보면 된다.

nodemanager.properties 주요 설정
INI
1
2
3
4
5
DomainsFile=/home/oracle/wls_domain/krcard_pay/nodemanager/nodemanager.domains
NodeManagerHome=/home/oracle/wls_domain/krcard_pay/nodemanager
ListenAddress=0.0.0.0
ListenPort=5556
SecureListener=false

여기서 중요한 설정으로 SecureListener 를 들수 있다. 만일 웹로직 자체를 TLS 설정을 했다면 true 로 놔야 하겠지만 대부분 TLS 설정을 하지 않는다. TLS 설정이 없는 상태에서 이 설정을 변경하지 않고, 왜 안되는지 헤메는 경우가 많다.

이렇게 한 후에 Admin 콘솔에서 노드매니저 등록을 해줘야 한다. 이것은 환경 > 시스템 에서 할 수 있다.

쿠버네티스 수동 설치

쿠버네티스 설치는 kubeadm 명령어를 이용하면 손쉽게 자동으로 이루어 진다. HA 를 위한 설치에서는 좀 더 손이 더 가겠지만 어쨌거나 그것도 kubeadm 을 이용한다. 쿠버네티스 설치에 많은 시간을 들이는 것이 그렇게 현명해 보이지는 않을 수 있지만 쿠버네티스의 기본적인 구조를 이해하는데 수동 설치만큼 유용한 것도 없다.

인터넷을 검색해보면 쿠버네티스 수동 설치는 보통 ‘Hard way’ 로 많이 나온다. ‘힘든 방법’ 등으로 번역할 수 있는데, 하나하나 수동으로 설치를 하게 된다. 이 글이 어렵다면 ‘Kubernetes Hard way’ 로 검색하면 많은 자료를 얻을 수 있다.

Requirements

쿠버네티스 수동 설치의 최종적인 모습은 다음과 같다.

위 그림은 ‘고가용성 토폴로지 선택‘ 문서에 나온 것이다. 컨트롤 플레인 노드는 적어도 3개, 워커 노드도 적어도 3개 그리고 중간에 로드 밸런서(Load balancer) 가 필요하다. 정리를 하면 다음과 같다.

  1. 컨트롤 플레인 노드(Control plane Node): 3개
  2. 워커 노드(Worker Node): 3개
  3. 로드 밸런서(Load balancer): 1개

이를 위해서 필자는 KVM 으로 VM 호스트를 6개를 만들었고 로드 밸런서는 KVM 호스트 컴퓨터에 HAProxy 를 구성하는 것으로 결정 했다.

툴 설치

쿠버네티스는 내부에 많은 프로그램들로 구성된다. 이들 프로그램들 간의 통신은 보안 통신을 기반으로 하는데, 이를 위해서는 TLS 인증서가 필요하다. 생성하는 방법은 다양하지만 CloudFlare 에서 만든 cfssl, cfssljson 명령어를 가장 많이 이용한다.

cfssl, cfssljson 명령어는 cfssl respository 에서 공식 배포 된다.

cfssl, cfssljson 설치
ZSH
1
2
3
4
5
6
]$ wget -q --show-progress --https-only --timestamping \
  https://pkg.cfssl.org/R1.2/cfssl_linux-amd64 \
  https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64
]$ chmod +x cfssl_linux-amd64 cfssljson_linux-amd64
]$ sudo mv cfssl_linux-amd64 /usr/local/bin/cfssl
]$ sudo mv cfssljson_linux-amd64 /usr/local/bin/cfssljson

kubectl 명령어도 다음과 같이 설치를 해준다. kubectl 명령어 설치는 Kubernetes 메뉴얼에 잘 나와 있다.

kubectl 설치
ZSH
1
2
3
]$ curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
]$ chmod +x kubectl
]$ sudo mv kubectl /usr/local/bin/

쿠버네티스 수동 설치를 위한 자원들

앞에서 쿠버네티스 컨트롤 플레인, 워커, 로드 밸런서에 대해서 언급을 했었는데 자세하게는 다음과 같다.

호스트 이름도메인아이피
kmaster1kmaster1.systemv.local192.168.96.46
kmaster2kmaster2.systemv.local192.168.96.47
kmaster3kmaster3.systemv.local192.168.96.48
haproxyhaproxy.systemv.local192.168.96.7
kworker1kworker1.systemv.local192.168.96.49
kworker2kworker2.systemv.local192.168.96.50
kworker3kworker3.systemv.local192.168.96.51

도메인은 내부 도메인네임서버를 운영하고 있어 이를 이용했다. 운영체제는 우분투(Ubuntu) 20.04 LTS 다. KVM 의 네트워크는 NAT 가 아니라 브릿지(Bridge) 네트워크로 구성해 KVM 게스트를 외부에서도 자유롭게 접속되도록 구성 했다. KVM의 게스트는 공유기 IP 대역에서 고정IP로 설정을 했다.

TLS 인증서 생성하기

CA(Certificate Authority) 작성하기

쿠버네티스에서 사용하는 인증서는 Self Sign 인증서다. 보통 인증서라고 하면 HTTPS 통신을 위한 인증서를 많이 들어봤을 것이다. 이 인증서를 발급받기 위해서는 여러 과정이 필요한데, 이 과정을 자세히 알고 있다면 이 과정이 이해하기 쉽다.

HTTPS 인증서를 발급 받기 위해서는 CSR 을 먼저 작성해야 한다. 하지만 그 전에 필요한 것이 CA 다. 보통은 CSR 을 작성해 CA 기관에 제출하는 형태로 진행이되지만 Self Sign 할때에는 CA 가 없다. 공인 CA에서 Self Sign 인증서를 발급해줄리도 만무하고… 그래서 CA 를 먼저 생성해 준다.

Root CA 의 역할은 제출받은 CSR 를 받아서 개인키를 돌려준다. 보통 HTTP 인증서를 발급받을때에 Root CA 는 기관에서 하기 때문에 돈을 주고 해달라고 요청을 하게 된다. 하지만 Self Sign 인증서를 작성할때에는 Root CA 기관의 CA 키가 있다고 가정하고 그 CA Key + CSR 를 돌려서 개인키를 발급받게 된다. 요약하자면 공인 Root CA 에서 사용하는 CA 키를 셀프로 만드는 것이다.

셀프 Root CA 는 모든 인증서의 기반이 된다.

Self Sign Root CA 인증성 생성
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
]$ cat > ca-config.json <<EOF
{
  "signing": {
    "default": {
      "expiry": "8760h"
    },
    "profiles": {
      "kubernetes": {
        "usages": ["signing", "key encipherment", "server auth", "client auth"],
        "expiry": "8760h"
      }
    }
  }
}
EOF
]$ cat > ca-csr.json <<EOF
{
  "CN": "Kubernetes",
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "names": [
    {
      "C": "US",
      "L": "Portland",
      "O": "Kubernetes",
      "OU": "CA",
      "ST": "Oregon"
    }
  ]
}
EOF
]$ cfssl gencert -initca ca-csr.json | cfssljson -bare ca
2021/04/16 10:39:10 [INFO] generating a new CA key and certificate from CSR
2021/04/16 10:39:10 [INFO] generate received request
2021/04/16 10:39:10 [INFO] received CSR # csr 받음
2021/04/16 10:39:10 [INFO] generating key: rsa-2048
2021/04/16 10:39:10 [INFO] encoded CSR # csr 인코딩
2021/04/16 10:39:10 [INFO] signed certificate with serial number 218079751927709843791408092001643512042320999306

출력 메시지를 자세히보면 new CA key 와 CSR 를 기반으로 new certificate 를 생성중이라고 시작하고 ‘CSR 받았다’ 그리고 ‘CSR 인코드’ 라고 나온다. 생성된 파일은 다음과 같다.

생성된 파일
ZSH
1
2
3
4
5
$ ls -lh
total 20K
-rw-r--r-- 1 systemv systemv 1005 Apr 16 10:39 ca.csr
-rw------- 1 systemv systemv 1.7K Apr 16 10:39 ca-key.pem
-rw-rw-r-- 1 systemv systemv 1.4K Apr 16 10:39 ca.pem

ca.pem 은 인증서이며 ca-key.pem 은 Root CA 에서 사용할 개인키(Private Key) 다. ca.csr 은 인증 요청서. Self Root CA 조차도 Key 를 요청하기는 것이기 때문에 CSR 이 필요하게 돼, ca.csr 이 만들어진다.

이 Self Root CA 는 Self Root CA 기관을 하나 만들었다고 생각하면 된다.

apiserver 클러스터 관리자 인증을 위한 클라이언트 인증서

마치 SSH 인증서를 사용한 인증 로그인이 가능하듯이 apiserver 클러스터 관리자 인증을 위해서 별도의 인증서가 필요한 모양이다. 이를 다음과 같이 생성해 준다.

apiserver 클러스터 관리자 인증을 위한 인증서 생성
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
$ cat > admin-csr.json <<EOF
{
  "CN": "admin",
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "names": [
    {
      "C": "US",
      "L": "Portland",
      "O": "system:masters",
      "OU": "Kubernetes The Hard Way",
      "ST": "Oregon"
    }
  ]
}
EOF
$ cfssl gencert \
  -ca=ca.pem \
  -ca-key=ca-key.pem \
  -config=ca-config.json \
  -profile=kubernetes \
  admin-csr.json | cfssljson -bare admin
2021/04/16 11:00:23 [INFO] generate received request
2021/04/16 11:00:23 [INFO] received CSR
2021/04/16 11:00:23 [INFO] generating key: rsa-2048
2021/04/16 11:00:23 [INFO] encoded CSR
2021/04/16 11:00:23 [INFO] signed certificate with serial number 115687386704811718443950929337723184713983594790
2021/04/16 11:00:23 [WARNING] This certificate lacks a "hosts" field. This makes it unsuitable for
websites. For more information see the Baseline Requirements for the Issuance and Management
of Publicly-Trusted Certificates, v.1.1.6, from the CA/Browser Forum (https://cabforum.org);
specifically, section 10.2.3 ("Information Requirements").

O, 그러니까 조직(Oganization) 이 “system:masters” 라는 사실에 주목해야 한다.

이렇게하면 admin-key.pem, admin.pem 이 생성된다.

Kubelet 클라이언트 인증서

Kubelet 은 쿠버네티스 클러스터에 각 노드에 설치되는 에이전트다. 이는 파드(Pod) 에 컨테이너가 실행되도록 해준다.

쿠버네티스는 노드 인증(Node Authorizer) 라 부르는, 특히 Kubelets 에 의한 API 요청 인증에 특별한 목적의 인증 모드를 사용한다. 노드 인증(Node Authorizer) 로 인증되기 위해, Kubelets 는 반드시 system:node:<nodename> 의 이름을 가진 system:nodes 그룹에 그들이 있는 것처럼 확인된 자격증명을 사용해야 한다.

따라서 nodename 이 반드시 있어야 한다. 만일 DNS 서버가 없다고 해도 괜찮다. 쿠버네티스 클러스터를 위한 서버들에 /etc/hosts 에 정적으로 도메인을 할당하면 되며, 호스트도 마찬가지로 정적으로 넣어줘도 된다.

앞에서 워커 노드의 경우에 worker1, worker2, worker3, 3개의 worker 노드가 있다. 이에 대해서 CSR 을 만들어 준다.

Kubelet 클라이언트 인증서를 위한 CSR 요청서
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
$ DOMAIN="systemv.local"
$ for instance in kworker1 kworker2 kworker3; do
cat > ${instance}-csr.json <<EOF
{
  "CN": "system:node:${instance}.${DOMAIN}",
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "names": [
    {
      "C": "US",
      "L": "Portland",
      "O": "system:nodes",
      "OU": "Kubernetes The Hard Way",
      "ST": "Oregon"
    }
  ]
}
EOF
done
$ cat kworker1-csr.json
{
  "CN": "system:node:kworker1",
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "names": [
    {
      "C": "US",
      "L": "Portland",
      "O": "system:nodes",
      "OU": "Kubernetes The Hard Way",
      "ST": "Oregon"
    }
  ]
}

CSR 은 인증서를 요청하기 위한 문서라고 보면 된다. 여기에는 요청에 필요한 각종정보를 적게 되어 있는데, O 의 경우에 조직(Oganization) 을 뜻하며 CN 은 Company Name 이다. 이것을 Kubelets 에서는 system:nodes 조직, system:nodes:worker1.systemv.local 회사등으로 인식한다고 보면 된다. CN 에 node 이름을 도메인명으로 했다는 것을 잘 봐둬야 한다.

이제 인증서를 만들어야 하는데, Self Root CA 와 CSR 를 조합해서 만든다. 단, 여기서 주의해야 하는 것은 호스트네임(hostname) 을 줘야 한다. 호스트네임은 콤마(,) 를 구분자로 여러개를 줄 수 있는데 여기서는 호스트네임, 아이피를 주고 생성한다. worker 서버 3개에 대해서 각각 만들어 준다.

Kubelet 클라이언트 인증서 생성
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
$ cfssl gencert \
  -ca=ca.pem \
  -ca-key=ca-key.pem \
  -config=ca-config.json \
  -hostname=kworker1.systemv.local,kworker1,192.168.96.49 \
  -profile=kubernetes \
  kworker1-csr.json | cfssljson -bare kworker1
2021/04/16 11:25:47 [INFO] generate received request
2021/04/16 11:25:47 [INFO] received CSR
2021/04/16 11:25:47 [INFO] generating key: rsa-2048
2021/04/16 11:25:48 [INFO] encoded CSR
2021/04/16 11:25:48 [INFO] signed certificate with serial number 538816406986381230934384726276464293616164354584
$ cfssl gencert \
  -ca=ca.pem \
  -ca-key=ca-key.pem \
  -config=ca-config.json \
  -hostname=kworker2.systemv.local,kworker2,192.168.96.50 \
  -profile=kubernetes \
  kworker2-csr.json | cfssljson -bare kworker2
2021/04/16 11:26:59 [INFO] generate received request
2021/04/16 11:26:59 [INFO] received CSR
2021/04/16 11:26:59 [INFO] generating key: rsa-2048
2021/04/16 11:27:00 [INFO] encoded CSR
2021/04/16 11:27:00 [INFO] signed certificate with serial number 597751742484889183781059204510460046544933863841
$ cfssl gencert \
  -ca=ca.pem \
  -ca-key=ca-key.pem \
  -config=ca-config.json \
  -hostname=kworker3.systemv.local,kworker3,192.168.96.51 \
  -profile=kubernetes \
  kworker3-csr.json | cfssljson -bare kworker3
2021/04/16 11:27:46 [INFO] generate received request
2021/04/16 11:27:46 [INFO] received CSR
2021/04/16 11:27:46 [INFO] generating key: rsa-2048
2021/04/16 11:27:47 [INFO] encoded CSR
2021/04/16 11:27:47 [INFO] signed certificate with serial number 9063887800656623067709796741742546672753221216

-hostname 에 콤마(,) 를 이용해 도메인, 호스트네임, IP 주소를 적고 있는데 이것은 SAN 확장을 위한 것이다. 멀티도메인 인증서에서 주로 많이 나오는 이야기인데, SAN 은 하나의 SSL 인증서에 여러개의 도메인을 사용할 수 있도록 해주는 X509 인증서의 확장이다.

이렇게 해서 생성한 인증서는 다음과 같다.

Kubelet 클라이언트 인증서
1
2
3
4
5
6
kworker1-key.pem
kworker1.pem
kworker2-key.pem
kworker2.pem
kworker3-key.pem
kworker3.pem

-hostname 으로 준 도메인,호스트네임,IP 주소가 인증서에 잘 있는지를 확인하는 방법은 다음과 같다.

kworker1.pem 인증서 확인
1
2
3
4
5
$ openssl x509 -in kworker1.pem -text -noout
...
            X509v3 Subject Alternative Name:
                DNS:kworker1.systemv.local, DNS:kworker1, IP Address:192.168.96.49
...

TLS 인증서는 CSR 과 RSA Public Key 조합으로 구성되며 이것을 Root CA 의 Private Key 를 이용해 암호화 된 상태다. 따라서 그냥 텍스트 에디터로 열어보면 암호화 스트링을 볼수 있는데, openssl 명령어를 이용하면 위와같이 텍스트로 확인이 가능하다. -hostname 으로 준 도메인,호스트네임,IP 주소는 DNS 와 IP Address 로 인식이 되었다.

kube-controller-manager 와 통신을 위한 인증서

kube-controller-manager 와 통신을 위한 인증서를 생성해 준다.

kube-controller-manager 와 통신을 위한 인증서
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
$ cat > kube-controller-manager-csr.json <<EOF
{
  "CN": "system:kube-controller-manager",
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "names": [
    {
      "C": "US",
      "L": "Portland",
      "O": "system:kube-controller-manager",
      "OU": "Kubernetes The Hard Way",
      "ST": "Oregon"
    }
  ]
}
EOF
$ cfssl gencert \
  -ca=ca.pem \
  -ca-key=ca-key.pem \
  -config=ca-config.json \
  -profile=kubernetes \
  kube-controller-manager-csr.json | cfssljson -bare kube-controller-manager
2021/04/16 11:53:51 [INFO] generate received request
2021/04/16 11:53:51 [INFO] received CSR
2021/04/16 11:53:51 [INFO] generating key: rsa-2048
2021/04/16 11:53:51 [INFO] encoded CSR
2021/04/16 11:53:51 [INFO] signed certificate with serial number 707492023587759406906035528054497220180910976164
2021/04/16 11:53:51 [WARNING] This certificate lacks a "hosts" field. This makes it unsuitable for
websites. For more information see the Baseline Requirements for the Issuance and Management
of Publicly-Trusted Certificates, v.1.1.6, from the CA/Browser Forum (https://cabforum.org);
specifically, section 10.2.3 ("Information Requirements").

“O”: “system:kube-controller-manager” 에 주목해야 한다.

kube-proxy 와 통신을 위한 인증서

kube-proxy 와 통신을 위한 인증서를 생성해 준다.

kube-proxy 와 통신을 위한 인증서
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
$ cat > kube-proxy-csr.json <<EOF
{
  "CN": "system:kube-proxy",
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "names": [
    {
      "C": "US",
      "L": "Portland",
      "O": "system:node-proxier",
      "OU": "Kubernetes The Hard Way",
      "ST": "Oregon"
    }
  ]
}
EOF
$ cfssl gencert \
  -ca=ca.pem \
  -ca-key=ca-key.pem \
  -config=ca-config.json \
  -profile=kubernetes \
  kube-proxy-csr.json | cfssljson -bare kube-proxy
2021/04/16 11:56:31 [INFO] generate received request
2021/04/16 11:56:31 [INFO] received CSR
2021/04/16 11:56:31 [INFO] generating key: rsa-2048
2021/04/16 11:56:31 [INFO] encoded CSR
2021/04/16 11:56:31 [INFO] signed certificate with serial number 663577426807755857235217640760583940251020445314
2021/04/16 11:56:31 [WARNING] This certificate lacks a "hosts" field. This makes it unsuitable for
websites. For more information see the Baseline Requirements for the Issuance and Management
of Publicly-Trusted Certificates, v.1.1.6, from the CA/Browser Forum (https://cabforum.org);
specifically, section 10.2.3 ("Information Requirements").

“O”: “system:node-proxier” 에 주목해야 한다.

kube-scheduler 와 통신을 위한 인증서

kube-scheduler 와 통신을 위한 인증서를 생성해 준다.

kube-scheduler 와 통신을 위한 인증서
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
$ cat > kube-scheduler-csr.json <<EOF
{
  "CN": "system:kube-scheduler",
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "names": [
    {
      "C": "US",
      "L": "Portland",
      "O": "system:kube-scheduler",
      "OU": "Kubernetes The Hard Way",
      "ST": "Oregon"
    }
  ]
}
EOF
$ cfssl gencert \
  -ca=ca.pem \
  -ca-key=ca-key.pem \
  -config=ca-config.json \
  -profile=kubernetes \
  kube-scheduler-csr.json | cfssljson -bare kube-scheduler
2021/04/16 11:59:13 [INFO] generate received request
2021/04/16 11:59:13 [INFO] received CSR
2021/04/16 11:59:13 [INFO] generating key: rsa-2048
2021/04/16 11:59:13 [INFO] encoded CSR
2021/04/16 11:59:13 [INFO] signed certificate with serial number 619651712283739066643157460188000366903756344982
2021/04/16 11:59:13 [WARNING] This certificate lacks a "hosts" field. This makes it unsuitable for
websites. For more information see the Baseline Requirements for the Issuance and Management
of Publicly-Trusted Certificates, v.1.1.6, from the CA/Browser Forum (https://cabforum.org);
specifically, section 10.2.3 ("Information Requirements").

노드간 API Server 통신을 위한 인증서

Kubernetes API Server 인증서라고 설명되어 있지만 앞에 다이어그램을 보면, API Server 는 쿠버네티스 컨트롤 플레인 노드에 있게 된다. 그리고 로드 밸런서를 통해서 워커 노드와 통신을 하게 된다. 이뿐만 아니라 API Server 는 외부에 클라이언트와 Kubectl 을 통해서 통신도 해야 한다.

이를 위해서 인증서에는 쿠버네티스 컨트롤 플레인 서버들과 로드밸런서에 대해 각각 인증이 가능해야 한다.

kube-api server 와 통신을 위한 인증서
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
$ DOMAIN=systemv.local
$ KUBERNETES_HOSTNAMES=kubernetes,kubernetes.default,kubernetes.default.svc,kubernetes.default.svc.cluster,kubernetes.svc.cluster.local
$ cat > kubernetes-csr.json <<EOF
{
  "CN": "kubernetes",
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "names": [
    {
      "C": "US",
      "L": "Portland",
      "O": "Kubernetes",
      "OU": "Kubernetes The Hard Way",
      "ST": "Oregon"
    }
  ]
}
EOF
$ cfssl gencert \
  -ca=ca.pem \
  -ca-key=ca-key.pem \
  -config=ca-config.json \
  -hostname=haproxy.${DOMAIN},192.168.96.7,192.168.96.46,192.168.96.47,192.168.96.48,127.0.0.1,10.32.0.1,${KUBERNETES_HOSTNAMES} \
  -profile=kubernetes \
  kubernetes-csr.json | cfssljson -bare kubernetes

-hostname 옵션에 보면 haproxy 의 도메인과 IP 주소를 연다라 입력해줬고, 그 이후에 kmaster1~3 까지 IP 주소를 입력해 줬다. 그리고 localhost 에 해당하는 127.0.0.1 을 입력해주고 10.32.0.1 을 입력해줬다. 이 주소는 후에 컨트롤 플레인을 만들때에 사용할 Cluster IP 주소 대역 10.32.0.0/16 에 첫번째 주소다.

쿠버네티스 API 서버는 내부 DNS 네임에 kubernetes 를 Cluster IP 대역의 첫번째 IP와 묶어서 저장해놓는다. 따라서 이 10.32.0.1 주소는 Cluster IP 대역과 연관이 돼 있다는 것을 알아야 한다.

Service Account Key Pair

Kubernetes Controller Manager는 managing service accounts 문서에 설명된대로 키 페어를 사용하여 서비스 계정 토큰을 생성하고 서명합니다.

service account key pair 위한 인증서
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
$ cat > service-account-csr.json <<EOF
{
  "CN": "service-accounts",
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "names": [
    {
      "C": "US",
      "L": "Portland",
      "O": "Kubernetes",
      "OU": "Kubernetes The Hard Way",
      "ST": "Oregon"
    }
  ]
}
EOF
$ cfssl gencert \
  -ca=ca.pem \
  -ca-key=ca-key.pem \
  -config=ca-config.json \
  -profile=kubernetes \
  service-account-csr.json | cfssljson -bare service-account
2021/04/16 12:26:10 [INFO] generate received request
2021/04/16 12:26:10 [INFO] received CSR
2021/04/16 12:26:10 [INFO] generating key: rsa-2048
2021/04/16 12:26:10 [INFO] encoded CSR
2021/04/16 12:26:10 [INFO] signed certificate with serial number 657346270815993169700676646594372924490206343750
2021/04/16 12:26:10 [WARNING] This certificate lacks a "hosts" field. This makes it unsuitable for
websites. For more information see the Baseline Requirements for the Issuance and Management
of Publicly-Trusted Certificates, v.1.1.6, from the CA/Browser Forum (https://cabforum.org);
specifically, section 10.2.3 ("Information Requirements").

이제 필요한 인증서는 다 작성되었다.

인증서 배포

워커 노드에는 ca, kubelet 클라이언트 인증서, kubelet 클라이언트 키를 노드에 복사해 준다.

워커 노드에 인증서 배포
ZSH
1
2
3
$ scp ca.pem kworker1.pem kworker1-key.pem kube-proxy.pem kube-proxy-key.pem kworker1.systemv.local:./
$ scp ca.pem kworker2.pem kworker2-key.pem kube-proxy.pem kube-proxy-key.pem kworker2.systemv.local:./
$ scp ca.pem kworker3.pem kworker3-key.pem kube-proxy.pem kube-proxy-key.pem kworker3.systemv.local:./

컨트롤 플레인 노드에는 ca, ca key, apiserver 인증서, apiserver key, service account key pair 를 노드에 복사해 준다.

컨트롤 플레인 노드에 인증서 배포
ZSH
1
2
3
$ scp ca.pem ca-key.pem kubernetes-key.pem kubernetes.pem service-account-key.pem service-account.pem kmaster1.systemv.local:./
$ scp ca.pem ca-key.pem kubernetes-key.pem kubernetes.pem service-account-key.pem service-account.pem kmaster2.systemv.local:./
$ scp ca.pem ca-key.pem kubernetes-key.pem kubernetes.pem service-account-key.pem service-account.pem kmaster3.systemv.local:./

클라이언트 인증 설정

controller manager, kubelet, kube-proxy, scheduler 클라이언트 그리고 admin 사용자를 위한 kubeconfig 파일을 생성해준다.

쿠버네티스 공인 IP 주소

kubeconfig 는 쿠버네티스 API Server 에 접속이 필요하다. 고가용성을 위해서 API Server 앞에 외부 로드 밸런서에 IP 주소를 할당해서 사용했다. 이것은 아키텍쳐 다이어그램에서 로드밸런서가 쿠버네티스의 공인 IP가 되며 여기는 HAProxy 의 IP 주소다.

Kubernetes 공인 IP
ZSH
1
$ KUBERNETES_PUBLIC_ADDRESS=192.168.96.7

kubelet 쿠버네티스 설정 파일

Kubelets 를 위한 kubeconfig 파일을 생성할때, Kubelet의 노드 이름과 일치하는 클라이언트 인증서를 사용해야 한다. 이것은 쿠버네티스 Node Authorizer 로 인증할 수 있도록 해준다.

kubelet 쿠버네티스 설정 파일
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
$ DOMAIN=systemv.local
$ for instance in kworker1 kworker2 kworker3; do
  kubectl config set-cluster kubernetes-the-hard-way \
    --certificate-authority=ca.pem \
    --embed-certs=true \
    --server=https://${KUBERNETES_PUBLIC_ADDRESS}:6443 \
    --kubeconfig=${instance}.kubeconfig
 
  kubectl config set-credentials system:node:${instance}.${DOMAIN} \
    --client-certificate=${instance}.pem \
    --client-key=${instance}-key.pem \
    --embed-certs=true \
    --kubeconfig=${instance}.kubeconfig
 
  kubectl config set-context default \
    --cluster=kubernetes-the-hard-way \
    --user=system:node:${instance}.${DOMAIN} \
    --kubeconfig=${instance}.kubeconfig
 
  kubectl config use-context default --kubeconfig=${instance}.kubeconfig
done
Cluster "kubernetes-the-hard-way" set.
User "system:node:kworker1" set.
Context "default" created.
Switched to context "default".
Cluster "kubernetes-the-hard-way" set.
User "system:node:kworker2" set.
Context "default" created.
Switched to context "default".
Cluster "kubernetes-the-hard-way" set.
User "system:node:kworker3" set.
Context "default" created.
Switched to context "default".

kube-proxy 쿠버네티스 설정 파일

kube-proxy 서비스를 위한 설정 파일을 생성해 준다.

kube-proxy 서비스를 위한 설정 파일 생성
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
$ kubectl config set-cluster kubernetes-the-hard-way \
    --certificate-authority=ca.pem \
    --embed-certs=true \
    --server=https://${KUBERNETES_PUBLIC_ADDRESS}:6443 \
    --kubeconfig=kube-proxy.kubeconfig
Cluster "kubernetes-the-hard-way" set.
$ kubectl config set-credentials system:kube-proxy \
    --client-certificate=kube-proxy.pem \
    --client-key=kube-proxy-key.pem \
    --embed-certs=true \
    --kubeconfig=kube-proxy.kubeconfig
User "system:kube-proxy" set.
$ kubectl config set-context default \
    --cluster=kubernetes-the-hard-way \
    --user=system:kube-proxy \
    --kubeconfig=kube-proxy.kubeconfig
Context "default" created.
$ kubectl config use-context default --kubeconfig=kube-proxy.kubeconfig
Switched to context "default".

kube-proxy.kubeconfig 파일이 생성된다.

kube-controller-manager 쿠버네티스 설정 파일

kube-controller-manager 서비스를 위한 kubeconfig 파일을 생성해 준다.

kube-controller-manager 서비스를 위한 설정 파일 생성
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
$ kubectl config set-cluster kubernetes-the-hard-way \
    --certificate-authority=ca.pem \
    --embed-certs=true \
    --server=https://127.0.0.1:6443 \
    --kubeconfig=kube-controller-manager.kubeconfig
Cluster "kubernetes-the-hard-way" set.
$ kubectl config set-credentials system:kube-controller-manager \
    --client-certificate=kube-controller-manager.pem \
    --client-key=kube-controller-manager-key.pem \
    --embed-certs=true \
    --kubeconfig=kube-controller-manager.kubeconfig
User "system:kube-controller-manager" set.
$ kubectl config set-context default \
    --cluster=kubernetes-the-hard-way \
    --user=system:kube-controller-manager \
    --kubeconfig=kube-controller-manager.kubeconfig
Context "default" created.
$ kubectl config use-context default --kubeconfig=kube-controller-manager.kubeconfig
Switched to context "default".

kube-controller-manager.kubeconfig 파일이 생성된다.

kube-scheduler 쿠버네티스 설정 파일

kube-scheduler 서비스를 위한 kubeconfig 파일을 생성해 준다.

kube-scheduler 서비스를 위한 설정 파일 생성
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
$ kubectl config set-cluster kubernetes-the-hard-way \
    --certificate-authority=ca.pem \
    --embed-certs=true \
    --server=https://127.0.0.1:6443 \
    --kubeconfig=kube-scheduler.kubeconfig
Cluster "kubernetes-the-hard-way" set.
$ kubectl config set-credentials system:kube-scheduler \
    --client-certificate=kube-scheduler.pem \
    --client-key=kube-scheduler-key.pem \
    --embed-certs=true \
    --kubeconfig=kube-scheduler.kubeconfig
User "system:kube-scheduler" set.
$ kubectl config set-context default \
    --cluster=kubernetes-the-hard-way \
    --user=system:kube-scheduler \
    --kubeconfig=kube-scheduler.kubeconfig
Context "default" created.
$ kubectl config use-context default --kubeconfig=kube-scheduler.kubeconfig
Switched to context "default".

kube-scheduler.kubeconfig 파일이 생성된다.

admin 사용자를 위한 kubeconfig 파일

admin 사용자를 위한 kubeconfig 파일을 생성해 준다.

admin 사용자를 위한 설정 파일 생성
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
$ kubectl config set-cluster kubernetes-the-hard-way \
    --certificate-authority=ca.pem \
    --embed-certs=true \
    --server=https://127.0.0.1:6443 \
    --kubeconfig=admin.kubeconfig
Cluster "kubernetes-the-hard-way" set.
$ kubectl config set-credentials admin \
    --client-certificate=admin.pem \
    --client-key=admin-key.pem \
    --embed-certs=true \
    --kubeconfig=admin.kubeconfig
User "admin" set.
$ kubectl config set-context default \
    --cluster=kubernetes-the-hard-way \
    --user=admin \
    --kubeconfig=admin.kubeconfig
Context "default" created.
$ kubectl config use-context default --kubeconfig=admin.kubeconfig
Switched to context "default".

admin.kubeconfig 파일이 생성된다.

생성된 파일을 배포

워커 노드에는 node.kubeconfig 와 kube-proxy.kubeconfig 파일을 복사해 준다.

워커 노드에 배포
ZSH
1
2
3
$ scp kworker1.kubeconfig kube-proxy.kubeconfig kworker1.systemv.local:./
$ scp kworker2.kubeconfig kube-proxy.kubeconfig kworker2.systemv.local:./
$ scp kworker3.kubeconfig kube-proxy.kubeconfig kworker3.systemv.local:./

컨트롤 플레인 노드에는 admin, kube-controller-manager, kube-scheduler 에 kubeconfig 파일을 배포해 준다.

워커 노드에 배포
ZSH
1
2
3
$ scp admin.kubeconfig kube-controller-manager.kubeconfig kube-scheduler.kubeconfig kmaster1.systemv.local:./
$ scp admin.kubeconfig kube-controller-manager.kubeconfig kube-scheduler.kubeconfig kmaster2.systemv.local:./
$ scp admin.kubeconfig kube-controller-manager.kubeconfig kube-scheduler.kubeconfig kmaster3.systemv.local:./

데이터 암호화 설정 및 키 생성

쿠버네티스트는 클러스터 상태, 애플리케이션 설정들, secret 등 다양한 데이터를 저장한다. 쿠버네티스는 클러스터 데이터를 암호화를 제공한다.

쿠버네티스 Secret 의 암호화를 위한 암호화 설정과 암호화 키 생성을 위한 설정을 작성해준다.

encryption-config.yaml 파일 작성
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
$ ENCRYPTION_KEY=$(head -c 32 /dev/urandom | base64)
$ cat > encryption-config.yaml <<EOF
kind: EncryptionConfig
apiVersion: v1
resources:
  - resources:
      - secrets
    providers:
      - aescbc:
          keys:
            - name: key1
              secret: ${ENCRYPTION_KEY}
      - identity: {}
EOF

이것을 컨트롤 플레인에 배포 해 준다.

HAProxy 서버 설치 및 설정

HAProxy 는 컨트롤 플레인을 로드 밸런싱을 해주는 역할을 한다. 다이어그램을 보면 워커와 컨트롤 플레인을 연결해주는 것으로 나오는데, 워커가 컨트롤 플레인을 하나의 도메인으로 연결하기 위한 것이기도 하다.

컨트롤 플레인은 외부에 통신을 6443 포트를 이용하게 된다. 도메인, IP 가 다른 컨트롤 플레인을 하나의 도메인 haproxy.systemv.local:6443 로 묶게 된다.

설치는 Ubuntu 20.04 서버에 APT 명령어로 패키지 설치 했다. 설정은 다음과 같이 간단하게 해줬다.

haproxy 설정
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
$ sudo vim /etc/haproxy/haproxy.cfg
listen stats
        bind *:9000
        stats enable
        stats realm Haproxy\ Statistics
        stats uri /haproxy_stats
        stats auth admin:password
        stats refresh 30
        mode http
 
frontend k8s
        bind *:6443
        default_backend k8s
        mode tcp
        option tcplog
 
backend k8s
        balance roundrobin
        #balance source
        mode tcp
        option tcplog
        option tcp-check
        server kmaster1.systemv.local 192.168.96.46:6443 check
        server kmaster2.systemv.local 192.168.96.47:6443 check
        server kmaster3.systemv.local 192.168.96.48:6443 check
$ sudo systemctl restart haproxy

etcd 클러스터 설치

etcd 는 key-value 로 데이터를 저장해주는 서버다. 쿠버네티스는 자체적인 데이터를 하나도 가지고 있지 않다. 전부다 외부에 데이터를 저장하는데 그것을 해주는 것이 etcd 다. 서버 한대만 가지고 데이터를 저장하는 것은 위험함으로 이것도 클러스터로 여러 서버를 하나로 묶는다.

다운로드 및 설치

etcd 서버 설치
ZSH
1
2
3
4
$ wget -q --timestamping "https://github.com/etcd-io/etcd/releases/download/v3.4.15/etcd-v3.4.15-linux-amd64.tar.gz"
$ tar xvzf etcd-v3.4.15-linux-amd64.tar.gz
$ chmod +x etcd-v3.4.15-linux-amd64/etcd*
$ sudo mv etcd-v3.4.15-linux-amd64/etcd* /usr/local/bin/

etcd 는 클러스터내에 서버들과 kmaster, kworker 서버들과 통신을 해야 한다. 하지만 쿠버네티스는 TLS 통신을 기반으로 하기 때문에 인증서를 함께 설치해 줘야 한다. 모든 서버와 통신을 위한 인증서로 Root CA 인증서와 kubernetes 인증서를 설치해 준다.

etcd 인증서 설치
ZSH
1
2
$ sudo mkdir -p /etc/etcd /var/lib/etcd
$ sudo cp -v ca.pem kubernetes-key.pem kubernetes.pem /etc/etcd/

ubuntu20.04, centos 7 서버의 경우에 systemd 가 핵심이다. etcd 를 서비스 등록을 위해서 systemd 를 이용한다. 이 서버는 kmaster1 서버에 실행해준다.

etcd systemd 등록하기
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
$ INTERNAL_IP=$(hostname --ip-address)
$ ETCD_NAME=$(hostname -s)
$ cat <<EOF | sudo tee /etc/systemd/system/etcd.service
[Unit]
Description=etcd
Documentation=https://github.com/coreos
 
[Service]
ExecStart=/usr/local/bin/etcd \\
  --name ${ETCD_NAME} \\
  --cert-file=/etc/etcd/kubernetes.pem \\
  --key-file=/etc/etcd/kubernetes-key.pem \\
  --peer-cert-file=/etc/etcd/kubernetes.pem \\
  --peer-key-file=/etc/etcd/kubernetes-key.pem \\
  --trusted-ca-file=/etc/etcd/ca.pem \\
  --peer-trusted-ca-file=/etc/etcd/ca.pem \\
  --peer-client-cert-auth \\
  --client-cert-auth \\
  --initial-advertise-peer-urls https://${INTERNAL_IP}:2380 \\
  --listen-peer-urls https://${INTERNAL_IP}:2380 \\
  --listen-client-urls https://${INTERNAL_IP}:2379,https://127.0.0.1:2379 \\
  --advertise-client-urls https://${INTERNAL_IP}:2379 \\
  --initial-cluster-token etcd-cluster-0 \\
  --initial-cluster kmaster1=https://${IP kmaster1}:2380,kmaster2=https://${IP master2}:2380,kmaster3=https://${IP master3}:2380 \\
  --initial-cluster-state new \\
  --data-dir=/var/lib/etcd
Restart=on-failure
RestartSec=5
 
[Install]
WantedBy=multi-user.target
EOF
$ sudo systemctl daemon-reload
$ sudo systemctl enable etcd.service --now

INTERNAL IP 는 kmaster1 서버의 IP, ETCD_NAME 은 kmaster1 이며 각각의 kmaster1, kmater2, kmaster3 에 IP를 적어주면 된다. 각각 kmaster 에서 INTERNAL IP 와 ETC_NAME 을 바꿔가면서 해주면 된다.

모두 정상적으로 설치가 되었다면 다음과 같이 확인할 수 있다.

etcd 확인하기
ZSH
1
2
3
4
5
6
7
8
$ sudo ETCDCTL_API=3 /usr/local/bin/etcdctl member list \
>   --endpoints=https://127.0.0.1:2379 \
>   --cacert=/etc/etcd/ca.pem \
>   --cert=/etc/etcd/kubernetes.pem \
>   --key=/etc/etcd/kubernetes-key.pem
5b11cfa779be5990, started, kmaster3, https://192.168.96.48:2380, https://192.168.96.48:2379, false
735f2a33dbd756c4, started, kmaster1, https://192.168.96.46:2380, https://192.168.96.46:2379, false
9066c1507a7e5374, started, kmaster2, https://192.168.96.47:2380, https://192.168.96.47:2379, false

ETCD 클러스터 설치와 설정으로 이것으로 끝이다.

Controll Plane(Master) 설치

컨트롤 플레인(Controll Plane) 혹은 마스터(Master) 노드는 쿠버네티스에 두뇌에 해당한다. 모든 명령과 연산은 모두 컨트롤 플레인에서 이루어진다. 클라이언트의 명령은 컨트롤 플레인의 api server 에서 받아서 워커 노드에 kubelet 이 실행하는 형태다. 데이터는 모두 etcd 에 저장된다.

컨트롤 플레인의 주요 구성요소는 다음과 같다.

  1. kube-apiserver
  2. kube-controller-manager
  3. kube-scheduler
  4. kubectl

다운로드 및 설치

바이너리 파일을 받아야 한다. github 에는 소스코드만 올라와 있어서 어디서 받을지 잠시 헷깔렸는데, dowloadkubernetes 에서 받을 수 있었다.

쿠버네티스(kubernetes) 다운로드 및 설치
ZSH
1
2
3
4
5
6
$ curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kube-apiserver"
$ curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kube-controller-manager"
$ curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kube-scheduler"
$ curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
$ chmod +x kube-apiserver kube-controller-manager kuber-scheduler kubectl
$ sudo mv -vv kube-apiserver kube-controller-manager kuber-scheduler kubectl /usr/local/bin/

쿠버네티스 API Server 설정

API Server 설정을 해보도록 하자. 쿠버네티스의 내부적인 데이터 이동은 암호화 통신을 기반으로 하기 때문에 인증서를 항상 달고 산다고 보면 된다.

인증서 복사
ZSH
1
2
3
4
$ sudo mkdir -p /var/lib/kubernetes/
$ sudo mv ca.pem ca-key.pem kubernetes-key.pem kubernetes.pem \
    service-account-key.pem service-account.pem \
    encryption-config.yaml /var/lib/kubernetes/

이제 systemd 유닛 등록을 위한 파일을 다음과 같이 작성해 준다.

kube-apiserver 를 위한 systemd 유닛 파일 작성
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
$ INTERNAL_IP=$(hostname --ip-address)
$ cat <<EOF | sudo tee /etc/systemd/system/kube-apiserver.service
[Unit]
Description=Kubernetes API Server
Documentation=https://github.com/kubernetes/kubernetes
 
[Service]
ExecStart=/usr/local/bin/kube-apiserver \\
  --advertise-address=${INTERNAL_IP} \\
  --allow-privileged=true \\
  --apiserver-count=3 \\
  --audit-log-maxage=30 \\
  --audit-log-maxbackup=3 \\
  --audit-log-maxsize=100 \\
  --audit-log-path=/var/log/audit.log \\
  --authorization-mode=Node,RBAC \\
  --bind-address=0.0.0.0 \\
  --client-ca-file=/var/lib/kubernetes/ca.pem \\
  --enable-admission-plugins=NamespaceLifecycle,NodeRestriction,LimitRanger,ServiceAccount,DefaultStorageClass,ResourceQuota \\
  --enable-swagger-ui=true \\
  --etcd-cafile=/var/lib/kubernetes/ca.pem \\
  --etcd-certfile=/var/lib/kubernetes/kubernetes.pem \\
  --etcd-keyfile=/var/lib/kubernetes/kubernetes-key.pem \\
  --etcd-servers=https://${IP kmaster1}:2379,https://${IP master2}:2379,https://${IP master3}:2379 \\
  --event-ttl=1h \\
  --experimental-encryption-provider-config=/var/lib/kubernetes/encryption-config.yaml \\
  --kubelet-certificate-authority=/var/lib/kubernetes/ca.pem \\
  --kubelet-client-certificate=/var/lib/kubernetes/kubernetes.pem \\
  --kubelet-client-key=/var/lib/kubernetes/kubernetes-key.pem \\
  --kubelet-https=true \\
  --runtime-config=api/all=true \\
  --service-account-signing-key-file=/var/lib/kubernetes/service-account-key.pem \\
  --service-account-issuer=api \\
  --service-account-api-audiences=api,vault \\
  --service-account-key-file=/var/lib/kubernetes/service-account.pem \\
  --service-cluster-ip-range=10.32.0.0/24 \\
  --service-node-port-range=30000-32767 \\
  --tls-cert-file=/var/lib/kubernetes/kubernetes.pem \\
  --tls-private-key-file=/var/lib/kubernetes/kubernetes-key.pem \\
  --v=2
Restart=on-failure
RestartSec=5
 
[Install]
WantedBy=multi-user.target
EOF
$ sudo systemctl daemon-reload
$ sudo systemctl enable kube-apiserver.service --now

여기서 –service-cluster-ip-range 를 잘 봐야 한다. 이것은 쿠버네티스 내부의 네트워크 주소 범위에 속한다. 앞에서 kubernetes 의 인증서를 작성할때에 이 주소 범위의 맨 앞의 주소인 10.32.0.1 을 넣어줬었다. 반드시 인증서에 포함되는 주소를 적어줘야 한다.

–service-account-signing-key-file, –service-account-issuer, –service-account-api-audiences 은 새롭게 추가된 기능으로 자세한 사항을 확인해 볼 필요가 있다.

쿠버네티스 Controller Manager 설정

앞에 api server 설치를 위해서 인증서를 모두 복사를 해뒀다. 컨틀로러 매니저를 위해서 kubeconfig 파일이 필요하다. 이를 복사해 준다.

kube-controller-manager.kubeconfig 파일 복사
ZSH
1
$ sudo mv -vv kube-controller-manager.kubeconfig /var/lib/kubernetes/

kube-controller-manager.service 파일을 다음과 같이 작성해 준다.

kube-controller-manager를 위한 systemd 유닛 등록
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
$ cat <<EOF | sudo tee /etc/systemd/system/kube-controller-manager.service
[Unit]
Description=Kubernetes Controller Manager
Documentation=https://github.com/kubernetes/kubernetes
 
[Service]
ExecStart=/usr/local/bin/kube-controller-manager \\
  --address=0.0.0.0 \\
  --allocate-node-cidrs=true \\
  --cluster-cidr=10.31.0.0/16 \\
  --cluster-name=kubernetes \\
  --cluster-signing-cert-file=/var/lib/kubernetes/ca.pem \\
  --cluster-signing-key-file=/var/lib/kubernetes/ca-key.pem \\
  --kubeconfig=/var/lib/kubernetes/kube-controller-manager.kubeconfig \\
  --leader-elect=true \\
  --root-ca-file=/var/lib/kubernetes/ca.pem \\
  --service-account-private-key-file=/var/lib/kubernetes/service-account-key.pem \\
  --service-cluster-ip-range=10.32.0.0/24 \\
  --use-service-account-credentials=true \\
  --v=2
Restart=on-failure
RestartSec=5
 
[Install]
WantedBy=multi-user.target
EOF
$ sudo systemctl daemon-reload
$ sudo systemctl enable kube-controller-manager.service --now

–cluster-cidr 은 kubeadm 을 이용해 설치할때에 –pod-network-cidr 에 해당한다.

쿠버네티스 Scheduler 설정

kubeconfig 를 복사 해준다.

kube-scheduler.kubeconfig 를 복사
ZSH
1
sudo mv kube-scheduler.kubeconfig /var/lib/kubernetes/

kube-scheduler 를 위한 설정파일을 다음과 같이 작성해 준다.

kube-scheduler.yaml 설정 파일 작성
ZSH
1
2
3
4
5
6
7
8
9
$ sudo mkdir -p /etc/kubernetes/config
$ cat <<EOF | sudo tee /etc/kubernetes/config/kube-scheduler.yaml
apiVersion: kubescheduler.config.k8s.io/v1beta1
kind: KubeSchedulerConfiguration
clientConnection:
  kubeconfig: "/var/lib/kubernetes/kube-scheduler.kubeconfig"
leaderElection:
  leaderElect: true
EOF

kube-scheduler.service 유닛 파일을 다음과 같이 작성해 준다.

kube-scheduler.service 유닛 파일 작성
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
$ sudo cat <<EOF | sudo tee /etc/systemd/system/kube-scheduler.service
[Unit]
Description=Kubernetes Scheduler
Documentation=https://github.com/kubernetes/kubernetes
 
[Service]
ExecStart=/usr/local/bin/kube-scheduler \\
  --config=/etc/kubernetes/config/kube-scheduler.yaml \\
  --v=2
Restart=on-failure
RestartSec=5
 
[Install]
WantedBy=multi-user.target
EOF
$ sudo systemctl daemon-reload
$ sudo systemctl enable kube-scheduler.service --now

Kubelet 인증을 위한 RBAC

쿠버네티스는 kubectl 을 이용해 명령을 받는다. 그러면 api server 에서 받고, 이것을 워커 서버에 kubelet 이 실행시키는 구조다. 문제는 api server 가 워커 노드에 kubelet 에 액세스를 할려면 RBAC 권한이 필요하다는 데 있다. RBAC(Role-Based Access Control) 는 사용자 역할 기반 접근 제어 방법이다.

system:kube-apiserver-to-kubelet ClusterRole 생성

system:kube-apiserver-to-kubelet 유닛 파일 작성
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
$ cat <<EOF | kubectl apply --kubeconfig admin.kubeconfig -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
  labels:
    kubernetes.io/bootstrapping: rbac-defaults
  name: system:kube-apiserver-to-kubelet
rules:
  - apiGroups:
      - ""
    resources:
      - nodes/proxy
      - nodes/stats
      - nodes/log
      - nodes/spec
      - nodes/metrics
    verbs:
      - "*"
EOF

쿠버네티스 API 서버는 –kubelet-client-certificate 플래그에 정의된 클라이언트 인증서를 사용해 kubernetes 사용자로 Kubelet 에 인증한다.

앞에서 생성한 ClusterRole 을 kubernetes 사용자에게 바인딩(binding) 해준다.

system:kube-apiserver-to-kubelet 룰 바인딩
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
$ cat <<EOF | kubectl apply --kubeconfig admin.kubeconfig -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: system:kube-apiserver
  namespace: ""
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:kube-apiserver-to-kubelet
subjects:
  - apiGroup: rbac.authorization.k8s.io
    kind: User
    name: kubernetes
EOF

확인

컨트롤 플레인이 잘 설정 되었는지 다음과 같이 확인할 수 있다.

쿠버네티스 컴포넌트 확인
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
$ kubectl get componentstatuses --kubeconfig admin.kubeconfig -o yaml | egrep "kind|name|message"
Warning: v1 ComponentStatus is deprecated in v1.19+
  - message: ok
  kind: ComponentStatus
    name: controller-manager
  - message: ok
  kind: ComponentStatus
    name: scheduler
  - message: '{"health":"true"}'
  kind: ComponentStatus
    name: etcd-0
  - message: '{"health":"true"}'
  kind: ComponentStatus
    name: etcd-2
  - message: '{"health":"true"}'
  kind: ComponentStatus
    name: etcd-1
kind: List

로드 밸런서에서 응답이 정상으로 나오는지도 확인할 수 있다.

haproxy 로드 밸런서 확인
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
$ curl --cacert /var/lib/kubernetes/ca.pem https://haproxy.systemv.local:6443/version
{
  "major": "1",
  "minor": "20",
  "gitVersion": "v1.20.6",
  "gitCommit": "8a62859e515889f07e3e3be6a1080413f17cf2c3",
  "gitTreeState": "clean",
  "buildDate": "2021-04-15T03:19:55Z",
  "goVersion": "go1.15.10",
  "compiler": "gc",
  "platform": "linux/amd64"
}

Worker 노드 설치

이제 워커 노드 작업을 진행 해야 한다. 여기서 한가지 결정해야 한다. 인터넷에 메뉴얼들을 보면 워커 노드의 컨테이너엔진을 RunC, Docker 등으로 나뉘어 있다. 여기서는 Docker 를 사용하는 것으로 진행 했다.

필수 패키지 및 Docker 설치

다음과 같이 필수 패키지를 설치해 준다. socat 은 kubectl port-forward 명령을 쓸때 사용한다고 한다.

필수 패키지 설치
ZSH
1
2
3
$ sudo apt clean all
$ sudo apt update
$ sudo apt install socat conntrack ipset

다음과 같이 Docker 를 설치 해준다. Docker 설치는 공식 메뉴얼 대로 해줬다.

Docker 설치
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
$ sudo apt install \
    apt-transport-https \
    ca-certificates \
    curl \
    gnupg \
    lsb-release
$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg
$ echo \
  "deb [arch=amd64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu \
  $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
$ sudo apt update
$ sudo apt install docker-ce docker-ce-cli containerd.io

일반 사용자도 Docker 를 이용할 수 있도록 해준다.

systemv 일반 사용자도 Docker 이용할 수 있도록 설정
ZSH
1
$ sudo usermod -aG docker systemv

시스템 설정을 해준다. 이 설정은 쿠버네티스 문서에 나와 있다.

시스템 모듈 및 파라메터 설정
ZSH
1
2
3
4
5
6
7
8
9
$ sudo cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
br_netfilter
EOF
 
$ sudo cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
EOF
$ sudo sysctl --system

kubectl, kubelet, kube-proxy 설치.

워커 노드 작동을 위한 바이너리 다운로드 및 설치해 준다.

kubectl, kubelet, kube-proxy 바이너리 다운로드 및 설치
ZSH
1
2
3
4
5
$ curl -LO https://dl.k8s.io/v1.20.6/bin/linux/amd64/kubectl
$ curl -LO https://dl.k8s.io/v1.20.6/bin/linux/amd64/kubelet
$ curl -LO https://dl.k8s.io/v1.20.6/bin/linux/amd64/kube-proxy
$ chmod +x kubectl kube-proxy kubelet
$ sudo mv kubectl kube-proxy kubelet /usr/local/bin

설치 디렉토리를 생성해 준다.

필요한 디렉토리 생성
ZSH
1
2
3
4
$ sudo mkdir -p /var/lib/kubelet \
   /var/lib/kube-proxy \
   /var/lib/kubernetes \
   /var/run/kubernetes

kubelet 설정

워크 노드 인증 키와 설정 파일 복사
ZSH
1
2
3
$ sudo mv -vv kworker1-key.pem kworker1.pem /var/lib/kubelet/
$ sudo mv -vv kworker1.kubeconfig /var/lib/kubelet/kubeconfig
$ sudo mv ca.pem /var/lib/kubernetes/

kubelet 설정 파일을 작성해 준다.

kubelet 설정 파일 생성
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
$ cat <<EOF | sudo tee /var/lib/kubelet/kubelet-config.yaml
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
authentication:
  anonymous:
    enabled: false
  webhook:
    enabled: true
  x509:
    clientCAFile: "/var/lib/kubernetes/ca.pem"
authorization:
  mode: Webhook
clusterDomain: "cluster.local"
clusterDNS:
  - "10.32.0.10"
runtimeRequestTimeout: "15m"
tlsCertFile: "/var/lib/kubelet/kworker1.pem"
tlsPrivateKeyFile: "/var/lib/kubelet/kworker1-key.pem"
EOF

kubelet를 위한 systemd 유닛 파일을 작성해 준다.

kubelet 을 위한 systemd 유닛 파일 작성
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
$ cat <<EOF | sudo tee /etc/systemd/system/kubelet.service
[Unit]
Description=Kubernetes Kubelet
Documentation=https://github.com/kubernetes/kubernetes
After=containerd.service
Requires=containerd.service
 
[Service]
ExecStart=/usr/local/bin/kubelet \\
  --config=/var/lib/kubelet/kubelet-config.yaml \\
  --container-runtime=docker \\
  --image-pull-progress-deadline=2m \\
  --kubeconfig=/var/lib/kubelet/kubeconfig \\
  --network-plugin=cni \\
  --register-node=true \\
  --v=2
Restart=on-failure
RestartSec=5
 
[Install]
WantedBy=multi-user.target
EOF

kube-proxy 설정

proxy 설정 파일을 복사해 준다.

kube-proxy 설정 파일 복사
ZSH
1
$ sudo mv kube-proxy.kubeconfig /var/lib/kube-proxy/kubeconfig

kube-proxy-config.yaml 설정 파일을 만들어 준다.

kube-proxy 설정 작성
ZSH
1
2
3
4
5
6
7
8
$ cat <<EOF | sudo tee /var/lib/kube-proxy/kube-proxy-config.yaml
apiVersion: kubeproxy.config.k8s.io/v1alpha1
kind: KubeProxyConfiguration
clientConnection:
  kubeconfig: "/var/lib/kube-proxy/kubeconfig"
mode: "iptables"
clusterCIDR: "10.31.0.0/16"
EOF

마지막으로 systemd 유닛 파일을 생성해 준다.

kube-proxy 을 위한 systemd 유닛 파일 작성
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
$ cat <<EOF | sudo tee /etc/systemd/system/kube-proxy.service
[Unit]
Description=Kubernetes Kube Proxy
Documentation=https://github.com/kubernetes/kubernetes
 
[Service]
ExecStart=/usr/local/bin/kube-proxy \\
  --config=/var/lib/kube-proxy/kube-proxy-config.yaml
Restart=on-failure
RestartSec=5
 
[Install]
WantedBy=multi-user.target
EOF

서비스를 기동해 준다.

서비스 기동
ZSH
1
2
$ sudo systemctl daemon-reload
$ sudo systemctl enable kubelet.service kube-proxy.serivce --now

이렇게 한 후에 kmaster1 서버에서 다음과 같이 노드를 확인해보자.

노드 확인
ZSH
1
2
3
4
5
$ kubectl get nodes --kubeconfig admin.kubeconfig
NAME                     STATUS   ROLES    AGE    VERSION
kworker1.systemv.local   NotReady    <none>   102m   v1.20.6
kworker2.systemv.local   NotReady    <none>   65m    v1.20.6
kworker3.systemv.local   NotReady    <none>   53m    v1.20.6

NotReady 로 나와야 한다. 그리고 kubelet 로그에는 cni network 가 없다는 메시지가 올라 온다.

CNI 네트워크 설치

CNI 네트워크까지 수동으로 설치할려면 머리가 아프다. 그래서 그냥 간단하게 이것을 pod 컨테이너로 구현하면 된다. 그것도 제공해주는 yaml 파일을 이용해서.

여기서는 Calico 를 이용했다. 50 node 이하에서 사용할 경우를 가정했다. 50 노드 이상이면 Typha 를 설치해줘야 한다.

Calico CNI 네트워크 설치
ZSH
1
2
$ curl https://docs.projectcalico.org/manifests/calico.yaml -O
$ kubectl apply -f calico.yaml

시간이 좀 지난후에 노드를 살펴보고 Ready 가 되어 있을 것이다.

원격 접속을 위한 kubectl 설정

지금까지 kubectl 명령어를 사용할려면 admin.kubeconfig 파일이 있어야 했다. 이 설정파일은 –server=https://127.0.0.1:6443 으로 로컬 호스트 api server 를 지칭하도록 만들어 졌다. 만일 kubectl 명령어를 외부에서 사용할려면 어떻게 해야할까?

admin 사용자를 위한 설정을 다시 해주면 된다.

원격 접속을 위한 설정
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
$ kubectl config set-cluster kubernetes-the-hard-way \
    --certificate-authority=ca.pem \
    --embed-certs=true \
    --server=https://haproxy.systemv.local:6443
Cluster "kubernetes-the-hard-way" set.
$ kubectl config set-credentials admin \
    --client-certificate=admin.pem \
    --client-key=admin-key.pem
User "admin" set.
$ kubectl config set-context kubernetes-the-hard-way \
    --cluster=kubernetes-the-hard-way \
    --user=admin
Context "kubernetes-the-hard-way" created.
$ kubectl config use-context kubernetes-the-hard-way
Switched to context "kubernetes-the-hard-way".
$ kubectl get nodes
NAME                     STATUS   ROLES    AGE   VERSION
kworker1.systemv.local   Ready    <none>   61m   v1.20.6
kworker2.systemv.local   Ready    <none>   24m   v1.20.6
kworker3.systemv.local   Ready    <none>   12m   v1.20.6

위 내용을 자세히 보면 kubeconfig 파일을 작성할때에 어느 파일에 저장할지에 대한 –kubeconfig=admin.kubeconfig 옵션이 존재하지 않는다. 이렇게 될 경우에 사용자의 홈디렉토리에 .kube/config 파일에 저장이 된다.

그리고 kubectl 명령어는 명시적으로 –kubeconfig admin.kubeconfig 를 주지 않는 이상 .kube/config 파일을 자동으로 읽어서 수행하게 된다.

Kube-dns 설치.

kube-dns 는 pods 에서 도메인 네임을 처리해 주는 서비스라고 보면 된다. pods 도메인을 할당라고 리절빙을 해준다.

kube-dns 설치
ZSH
1
2
3
4
5
6
7
$ curl -LO https://storage.googleapis.com/kubernetes-the-hard-way/kube-dns.yaml
$ vim kube-dns.yaml
....
apiVersion: apps/v1
kind: Deployment
....
$ kubectl apply -f kube-dns.yaml

중간에 apiVersion: extension/v1 이라고 되어 있는 것을 위와 같이 바꿔 준다.

kube-dns 설치 상태 확인
ZSH
1
2
3
$ kubectl get pods -l k8s-app=kube-dns -n kube-system
NAME                        READY   STATUS    RESTARTS   AGE
kube-dns-7854dfc8c7-d69g5   3/3     Running   0          7m37s

정상적으로 작동되는 것을 볼 수 있다.

이로써 모든 설치가 완료 됐다.

WebLogic 12c Silent 설치

WebLogic 12c 사일런트(Silent) 설치에 대해서 다룹니다. 현재 WebLogic 은 12.2.1.4 버전이다.

WebLogic 12.2.1.4

WebLogic 은 자바 엔터프라이즈 서버(Java Enterprise Server) 이다. 자바를 필요로 하는데, 특징은 Oracle 자바 jdk8 이 반드시 필요하다. JEE 7 스펙을 만족한다. 최근에 Oracle Linux 8.x 에서 인증이 되어서 설치할 수 있게 되었다.

시스템 계정 생성

WebLogic 을 운영하기 위한 시스템 계정을 생성 한다.

oracle 시스템 계정 생성
ZSH
1
2
3
4
5
6
7
8
]# groupadd -g 1000 oinstall
]# useradd -u 1100 -g oinstall oracle
]# passwd oracle
oracle 사용자의 비밀 번호 변경 중
새  암호:
잘못된 암호: 암호는 8 개의 문자 보다 짧습니다
새  암호 재입력:
passwd: 모든 인증 토큰이 성공적으로 업데이트 되었습니다.

디렉토리 생성

WebLogic 설치를 위한 디렉토리를 다음과 같이 생성해 준다.

WebLogic 설치를 위한 디렉토리 생성
ZSH
1
2
3
4
5
6
]# mkdir -p /u01/app/oracle/middleware
]# mkdir -p /u01/app/oracle/config/domains
]# mkdir -p /u01/app/oracle/config/applications
]# mkdir -p /u01/software
]# chown -R oracle:oinstall /u01
]# chmod -R 775 /u01/

oracle 계정의 Bash 환경변수 세팅

oracle 계정으로 운영할 WebLogic 을 위해서 환경변수를 다음과 같이 세팅해 준다.

oracle 계정의 WebLogic 환경변수 세팅
ZSH
1
2
3
4
5
6
7
8
]# vi .bash_profile
export MW_HOME=/u01/app/oracle/middleware
export WLS_HOME=$MW_HOME/wlserver
export WL_HOME=$WLS_HOME
 
# Set to the appropriate JAVA_HOME.
export JAVA_HOME=/u01/app/oracle/jdk1.8.0_291
export PATH=$JAVA_HOME/bin:$PATH

Oracle Java 설치

oracle 계정으로 다음과 같이 Oracle 자바를 설치해 준다. Oracle 자바 1.8 버전을 다운받아서 설치 했다.

Oracle 자바 1.8 설치
ZSH
1
2
]$ tar xvzf jdk-8u291-linux-x64.tar.gz -C /u01/app/oracle
]$

WebLogic Response File 작성

WebLogic 사일런스 설치를 하기 위해서 Response File 가 필요한데, 다음과 같이 작성해 준다.

WebLogic Response File 작성
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
]$ vi /u01/software/wls.rsp
[ENGINE]
Response File Version=1.0.0.0.0
[GENERIC]
ORACLE_HOME=/u01/app/oracle/middleware
INSTALL_TYPE=WebLogic Server
MYORACLESUPPORT_USERNAME=
MYORACLESUPPORT_PASSWORD=<secure value="">
DECLINE_SECURITY_UPDATES=true
SECURITY_UPDATES_VIA_MYORACLESUPPORT=false
PROXY_HOST=
PROXY_PORT=
PROXY_USER=
PROXY_PWD=<secure value="">
COLLECTOR_SUPPORTHUB_URL=

Inventory 파일 작성

인벤토리를 위한 파일을 작성해 준다.

WebLogic Inventory File 작성
ZSH
1
2
3
]$ vi /u01/software/oraInst.loc
inventory_loc=/u01/app/oraInventory
inst_group=oinstall

다운로드 WebLogic

다운로드를 할때에 주의해야할게 있다. WebLogic 이 발전하면서 Fusion Middleware Infrastructure 패키지화가 되었다. 다운로드 홈페이지에 가보면 두가지 타입으로 제공하고 있는데, “Generic Installer for Oracle WebLogic Server and Oracle Coherence:” 이것을 다운받아야 한다.

WebLogic 사일런트 설치
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
]$ $JAVA_HOME/bin/java -Xmx1024m -jar /u01/software/fmw_12.2.1.4.0_wls_lite_generic.jar -silent -responseFile /u01/software/wls.rsp -invPtrLoc /u01/software/oraInst.loc
시작 프로그램 로그 파일은 /tmp/OraInstall2021-05-17_01-01-27AM/launcher2021-05-17_01-01-27AM.log입니다.
설치 프로그램을 추출하는 중... . 완료
CPU 속도가 300MHz 이상인지 확인 중.   실제 3618.202MHz    성공함
교체 공간 확인 중: 512MB 이상이어야 합니다..   실제 5118MB    성공함
이 플랫폼에 64비트 JVM이 필요한지 확인하는 중.   실제 64    성공함(64비트 필요 없음)
임시 공간 확인 중: 300MB 이상이어야 합니다..   실제 21170MB    성공함
/tmp/OraInstall2021-05-17_01-01-27AM에서 Oracle Universal Installer 시작을 준비하는 중
로그: /tmp/OraInstall2021-05-17_01-01-27AM/install2021-05-17_01-01-27AM.log
Copyright (c) 1996, 2019, Oracle and/or its affiliates. All rights reserved.
응답 파일을 읽는 중...
소프트웨어 업데이트를 건너뛰는 중
검사 시작: CertifiedVersions
예상 결과: oracle-6, oracle-7, redhat-7, redhat-6, SuSE-11, SuSE-12, SuSE-15 중 하나
실제 결과: oracle-8.3
검사가 완료되었습니다. 이 검사에 대한 전반적인 결과: 성공함
CertifiedVersions 검사: 성공했습니다.
 
 
검사 시작: CheckJDKVersion
예상 결과: 1.8.0_191
실제 결과: 1.8.0_291
검사가 완료되었습니다. 이 검사에 대한 전반적인 결과: 성공함
CheckJDKVersion 검사: 성공했습니다.
 
 
이 세션에 대한 검증이 사용으로 설정되어 있습니다.
데이터를 확인하는 중
파일 복사 중
완료율: 10
완료율: 20
완료율: 30
완료율: 40
완료율: 50
완료율: 60
완료율: 70
완료율: 80
완료율: 90
완료율: 100
 
설치/Oracle Fusion Middleware 12c WebLogic Server 및 Coherence 12.2.1.4.0이(가) 성공적으로 완료되었습니다.
/u01/app/oraInventory/logs에 로그를 성공적으로 복사했습니다.

설치 확인

설치가 성공적으로 되었는지 다음과 같이 확인할 수 있다.

WebLogic 사일런트 설치
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
]$ . $WLS_HOME/server/bin/setWLSEnv.sh
CLASSPATH=/u01/app/oracle/jdk1.8.0_291/lib/tools.jar:/u01/app/oracle/middleware/wlserver/modules/features/wlst.wls.classpath.jar:.:/u01/app/oracle/jdk1.8.0_291/jre/lib
 
PATH=/u01/app/oracle/middleware/wlserver/server/bin:/u01/app/oracle/middleware/wlserver/../oracle_common/modules/thirdparty/org.apache.ant/1.10.5.0.0/apache-ant-1.10.5/bin:/u01/app/oracle/jdk1.8.0_291/jre/bin:/u01/app/oracle/jdk1.8.0_291/bin:/u01/app/oracle/jdk1.8.0_291/bin:/u01/app/oracle/jdk1.8.0_77/bin:/home/oracle/.local/bin:/home/oracle/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/u01/app/oracle/middleware/wlserver/../oracle_common/modules/org.apache.maven_3.2.5/bin
 
Your environment has been set.
]$ java weblogic.version
 
WebLogic Server 12.2.1.4.0 Thu Sep 12 04:04:29 GMT 2019 1974621
 
Use 'weblogic.version -verbose' to get subsystem information
 
Use 'weblogic.utils.Versions' to get version information for all modules

도메인 생성하기

WebLogic 은 도메인이라는 개념이 존재한다. 도메인은 하나의 WebLogic 서버처럼 여겨지는데, Admin 과 Managed 도메인 두가지 타입으로 나뉜다.

먼저 Admin 도메인 서버는 Managed 도메인 서버를 총괄한다. Managed 도메인 서버가 자바 애플리케이션을 실행하는 실제 서버라고 보면 되며 이 Managed 도메인 서버는 Admin 도메인 서버에 등록되어야만 동작할 수 있다.

도메인 생성에는 python 스크립트를 이용한다. 정확하게는 WebLogic 의 스크립트를 이용한다고 보면 된다. 이것은 스크립트뿐만 아니라 WLS 쉘을 이용해서도 할 수 있다.

다음과 같이 스크립트를 작성해 준다.

Admin 도메인 서버 생성을 위한 스크립트
Python
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
#Read Template
selectTemplate('Basic WebLogic Server Domain','12.2.1.3.0')
loadTemplates()
 
# Enter Admin Server
cd('/Servers/AdminServer')
cmo.setListenAddress('')
setOption('ServerStartMode','prod')
set('ListenPort', 7001)
create('AdminServer', 'SSL')
cd('SSL/AdminServer')
set('Enabled', 'True')
set('ListenPort', 7002)
cd('/')
cd('Security/base_domain/User/weblogic')
set('Name', 'weblogic')
cmo.setPassword('weblogic1')
setOption('ServerStartMode','prod')
setOption('OverwriteDomain','True')
writeDomain('/home/oracle/wls_domain/krbank_pay')
closeTemplate()
exit()

‘krbank_pay’ 가 도메인이 된다. selectTemplate 에 버전을 표시하고 있는데, 이는 $MW_HOME/wlserver/common/templates/wls/wls.jar 파일을 압축 해제하고 나온 파일중에 template-info.xml 을 보면 버전 정보가 나온다.

ServerStartMode 를 prod 로 하고 있으며, 아이디와 패스워드를 입력해주고 있다. writeDomain 으로 Admin 도메인을 어디에 생성할 것인지 디렉토리 정보를 넘겨주고 있다. 이렇게 작성을 다 했다면 다음의 명령어로 실행해 준다.

Admin 도메인 생성 스크립트 실행.
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
]$ cd $MW_HOME/wlserver/common/bin
]$ wlst.sh /u01/software/create_admin_domain.py
WARNING: This is a deprecated script. Please invoke the wlst.sh script under oracle_common/common/bin.
 
Initializing WebLogic Scripting Tool (WLST) ...
 
Welcome to WebLogic Server Administration Scripting Shell
 
Type help() for help on available commands
 
Exiting WebLogic Scripting Tool.
]$

정상적으로 실행이 되었다면 /home/oracle/wls_domain/admin 디렉토리에 관련 파일들이 존재하게 된다. 디렉토리를 잘 보면 startWebLogic.sh 파일이 존하고 이것을 실행하면 Admin 도메인 서버가 실행 되게 되는데, 중간에 Username 과 password 를 입력받도록 되어 있다.

매번 서버를 시작할때마다 입력해주면 불편하니까, 이것을 다음과 같이 파일을 작성해 준다.

boot.properties 파일 작성
ZSH
1
2
3
4
]$ mkdir -p wls_domain/krbank_pay/servers/AdminServer/security
]$ vi wls_domain/krbank_pay/servers/AdminServer/security/boot.properties
username=weblogic
password=weblogic1

Admin 도메인 서버를 실행하면 입력한 내용은 암호화 된다. startWebLogic.sh 를 실행하고 브라우져에서 http://weblogic 서버 IP:7001/console 을 입력하면 관리자 화면이 나오게 된다.

Redmine 컴파일 설치

Redmine 컴파일 설치에 대해서 다룬다. 최신의 OS 를 가지고 하면 좋겠지만, CentOS 7 에서 설치를 진행 했다.

Mariadb 설치

MySQL 도 가능하지만, MariaDB 를 선택했다. 컴파일 설치가 가능하지만 패키지 설치로 설치한다.

MariaDB 설치
ZSH
1
]# yum install mariadb-server mariadb-devel -y

각종 의존성이 함께 설치가 된다. CentOS 7 에서 MariaDB 버전은 5.5 이다. 현재 최선 버전은 10.4 이며 이것을 설치하고자 한다면 MariaDB 홈페이지에 공식 리파지토리를 설정하고 yum 명령어로 간단하게 설치할 수 있다.

my.cnf 파일을 다음과 같이 설정해 준다.

MariaDB 설정
INI
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
]# vim /etc/my.cnf
 
[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0
# Settings user and group are ignored when systemd is used.
# If you need to run mysqld under a different user or group,
# customize your systemd unit file for mariadb according to the
# instructions in http://fedoraproject.org/wiki/Systemd
 
character-set-server = utf8
collation-server = utf8_general_ci
 
port = 3306
skip-name-resolve
 
[mysqld_safe]
log-error=/var/log/mariadb/mariadb.log
pid-file=/var/run/mariadb/mariadb.pid
 
#
# include all files from the config directory
#
!includedir /etc/my.cnf.d
 
[mysql]
default-character-set = utf8
no-auto-rehash
show-warnings
prompt=\u@\h:\d\_\R:\m:\\s>
pager="less -n -i -F -X -E"

캐릭터 셋을(character-set) 설정하는 부분과 함께 mysql 콘솔에 대한 설정이 전부다. 이제 서버를 시작해주고 보안 설정을 해준다.

MariaDB 실행
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
]# systemctl start mariadb.service
]# systemctl enable mariadb.service
]# mysql_secure_installation
 
NOTE: RUNNING ALL PARTS OF THIS SCRIPT IS RECOMMENDED FOR ALL MariaDB
      SERVERS IN PRODUCTION USE!  PLEASE READ EACH STEP CAREFULLY!
 
In order to log into MariaDB to secure it, we'll need the current
password for the root user.  If you've just installed MariaDB, and
you haven't set the root password yet, the password will be blank,
so you should just press enter here.
 
Enter current password for root (enter for none): <- 그냥 엔터
OK, successfully used password, moving on...
 
Setting the root password ensures that nobody can log into the MariaDB
root user without the proper authorisation.
 
Set root password? [Y/n] Y
New password:
Re-enter new password:
Password updated successfully!
Reloading privilege tables..
... Success!
 
By default, a MariaDB installation has an anonymous user, allowing anyone
to log into MariaDB without having to have a user account created for
them.  This is intended only for testing, and to make the installation
go a bit smoother.  You should remove them before moving into a
production environment.
 
Remove anonymous users? [Y/n] Y
... Success!
 
Normally, root should only be allowed to connect from 'localhost'.  This
ensures that someone cannot guess at the root password from the network.
 
Disallow root login remotely? [Y/n] Y
... Success!
 
By default, MariaDB comes with a database named 'test' that anyone can
access.  This is also intended only for testing, and should be removed
before moving into a production environment.
 
Remove test database and access to it? [Y/n] Y
- Dropping test database...
... Success!
- Removing privileges on test database...
... Success!
 
Reloading the privilege tables will ensure that all changes made so far
will take effect immediately.
 
Reload privilege tables now? [Y/n] Y
... Success!
 
Cleaning up...
 
All done!  If you've completed all of the above steps, your MariaDB
installation should now be secure.
 
Thanks for using MariaDB!
]#

mysql_secure_installation 명령어를 이용하면 root 관리자 비밀번호와 간단한 보안설정도 함께 할 수 있다. 이제 redmine 을위한 데이터베이스를 생성하고 접속 계정을 만들어 준다.

Redmine 을 위한 Mariadb 계정 설정
PgSQL
1
2
3
4
5
6
7
8
9
10
11
12
13
14
> use mysql;
Database changed
> CREATE DATABASE redmine CHARACTER SET utf8 COLLATE utf8_general_ci;
Query OK, 1 row affected (0.00 sec)
> CREATE USER 'redmine'@'localhost' IDENTIFIED BY 'HS79aB';
Query OK, 0 rows affected (0.00 sec)
> CREATE USER 'redmine'@'127.0.0.1' IDENTIFIED BY 'HS79aB';
Query OK, 0 rows affected (0.00 sec)
> GRANT ALL PRIVILEGES ON redmine.* TO 'redmine'@'localhost';
Query OK, 0 rows affected (0.00 sec)
> GRANT ALL PRIVILEGES ON redmine.* TO 'redmine'@'127.0.0.1';
Query OK, 0 rows affected (0.00 sec)
> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)

로컬에서만 접속되도록 하였다. 이로서 redmine 설치를 위한 Mariadb 설치 설정은 모두 끝났다.

Ruby 2.7 컴파일 설치

Redmine 4.2 를 사용하기 위해서는 Ruby 2.7 이 필요로 한다. 컴파일 설치를 해야 하는데, 먼저 다음과 같이 컴파일 환경을 만들어 준다.

컴파일 패키지 설치
ZSH
1
]# yum -y install gcc g++ cpp gcc-c++ openssl-devel readline-devel zlib-devel curl-devel libyaml-devel libxslt-devel libyaml-devel libxml2-devel pcre-devel git make bzip2 libffi-devel autoconf bison jemalloc-devel automake patch glibc-devel gpg libtool gdbm-devel ImageMagick ImageMagick-devel

한가지, Ruby 는 jemalloc 를 사용하도록 할 것이다. CentOS 7 공식 패키지 저장소에는 이를 제공하지 않는다. EPEL 서드파티 레드햇 저장소를 활요하면 설치가 가능하다.

EPEL 저장소를 이용한 jemalloc 설정
ZSH
1
2
3
]# yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
]# yum install jemalloc-devel
]# yum-config-manager --disable epel

설치를 다하고나면 epel 저장소를 비활성화 해준다.

이제 Ruby 2.7 버전을 다운로드하고 다음과 같이 컴파일 설치 해준다.

Ruby 컴파일 설치
ZSH
1
2
3
4
5
6
]# curl -LO https://cache.ruby-lang.org/pub/ruby/2.7/ruby-2.7.3.tar.gz
]# tar xvzf ruby-2.7.3.tar.gz
]# cd ruby-2.7.3
]# configure --prefix=/opt/ruby-2.7.3 --with-jemalloc
]# make
]# make install

Ruby 설치가 정상적으로 되었다면 이제 계정에서 Ruby 를 사용할 수 있도록 쉘 설정을 해준다.

Ruby 컴파일 설치
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
]# vim $HOME/.bash_profile
# Ruby
RUBY_ROOT=/opt/ruby-2.7.3
RUBY_BIN=$RUBY_ROOT/bin
RUBY_INC=$RUBY_ROOT/include
RUBY_LIB=$RUBY_ROOT/lib
 
export LD_LIBRARY_PATH=$RUBY_LIB:/usr/local/lib:$LD_LIBRARY_PATH
export CPATH=$RUBY_INC:$CPATH
 
PATH=$RUBY_BIN:$PATH:$HOME/bin
 
export PATH
]# source $HOME/.bash_profile
]# ruby -v
ruby 2.7.3p183 (2021-04-05 revision 6847ee089d) [x86_64-linux]

이렇게 root 계정에서 ruby 가 인식이 된다.

Redmine 설치

Redmine 을 설치하기 위해서는 먼저 gem 을 설치해줘야 한다. gem 은 Ruby 에서 사용하는 플랫폼을 작성해주는 프로그램이다. 그런데, 여기서 또 생각해봐야 하는것이 이것을 이제 일반계정으로 만들것인지 아니면 전역적인 시스템에 설치할 것인지하는 것을 고려해야 한다.

나는 이것을 redmine 이라는 일반 계정을 생성해서 설치하기로 했다. ruby 는 전역적으로 설치했지만 redmine 은 계정을 생성해 시스템과 분리되도록 하였다.

gem 설치

이제 gem 을 설치해 준다. gem 은 Ruby 설치 디렉토리에 함께 설치 됨으로 root 계정으로 실행을 해준다.

gem 설치하기
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
]# curl -LO https://rubygems.org/rubygems/rubygems-3.2.17.tgz
]# tar xvzf rubygems-3.2.17.tgz
]# cd rubygems-3.2.17
]# ruby setup.rb
RubyGems installed the following executables:
        /opt/ruby-2.7.3/bin/gem
        /opt/ruby-2.7.3/bin/bundle
        /opt/ruby-2.7.3/bin/bundler
 
Ruby Interactive (ri) documentation was installed. ri is kind of like man
pages for Ruby libraries. You may access it like this:
  ri Classname
  ri Classname.class_method
  ri Classname#instance_method
If you do not wish to install this documentation in the future, use the
--no-document flag, or set it as the default in your ~/.gemrc file. See
'gem help env' for details.

gem 을 이용해서 다음과 같이 bundler, chef ruby-shadow 설치를 진행해 준다.

gem 설치하기
ZSH
1
]# gem install bundler chef ruby-shadow

또, mysql2 확장을 설치해준다. 일종의 드라이버라고 보면 된다.

mysql2 네이티브 확장
ZSH
1
2
3
4
5
6
7
]# gem install mysql2
Building native extensions. This could take a while...
Successfully installed mysql2-0.5.3
Parsing documentation for mysql2-0.5.3
Installing ri documentation for mysql2-0.5.3
Done installing documentation for mysql2 after 0 seconds
1 gem installed

계정 생성

다음과 같이 redmine 계정을 생성해 준다.

redmine 시스템 계정 생성
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
]# useradd -m -U -r -d /opt/redmine redmine
]# su - redmine
]$ vim $HOME/.bash_profile
# Ruby
RUBY_ROOT=/opt/ruby-2.7.3
RUBY_BIN=$RUBY_ROOT/bin
RUBY_INC=$RUBY_ROOT/include
RUBY_LIB=$RUBY_ROOT/lib
 
export LD_LIBRARY_PATH=$RUBY_LIB:/usr/local/lib:$LD_LIBRARY_PATH
export CPATH=$RUBY_INC:$CPATH
 
PATH=$RUBY_BIN:$PATH:$HOME/bin
 
export PATH
]$ source $HOME/.bash_profile

redmine 계정도 ruby 를 인식 시켜준다.

redmine 설치

이제 redmine 계정에 redmine 4.2 를 다운로드하고 설치해 준다.

redmine 다운로드 및 설치
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
]$ curl -LO https://www.redmine.org/releases/redmine-4.2.1.tar.gz
]$ tar xvzf redmine-4.2.1.tar.gz
]$ cd redmine-4.2.1
]$ cp config/configuration.yml.example config/configuration.yml
]$ cp config/database.yml.example config/database.yml
]$ vim config/database.yml
production:
  adapter: mysql2
  database: redmine
  host: localhost
  username: redmine
  password: "HS79aB"
  # Use "utf8" instead of "utfmb4" for MySQL prior to 5.7.7
  encoding: utf8

이제 구동에 필요한 패키지들을 설치해 준다.

redmine 에 필요한 패키지 설치
ZSH
1
]$ bundle install --without development test postgresql sqlite

쿠키 암호화를 위한 시크릿 토큰을 생성해 준다.

쿠키 암호화를 위한 시크릿 토큰 생성
ZSH
1
]$ bundle exec rake generate_secret_token

데이터베이스를 생성해 준다.

redmine 데이터베이스 생성
ZSH
1
]$ RAILS_ENV=production bundle exec rake db:migrate

기본 언어를 한국어로 설정해 준다.

redmine 언어 설정
ZSH
1
2
3
4
5
]$ RAILS_ENV=production bundle exec rake redmine:load_default_data
 
Select language: ar, az, bg, bs, ca, cs, da, de, el, en, en-GB, es, es-PA, et, eu, fa, fi, fr, gl, he, hr, hu, id, it, ja, ko, lt, lv, mk, mn, nl, no, pl, pt, pt-BR, ro, ru, sk, sl, sq, sr, sr-YU, sv, th, tr, uk, vi, zh, zh-TW [en] ko
====================================
Default configuration data loaded.

이제 모든게 완료 됐다. Redmine 을 다음과 같이 구동할 수 있다.

redmine 언어 설정
ZSH
1
2
3
4
5
6
]$ bundle exec rails server webrick -e production -b 0.0.0.0 &
=> Rails 5.2.5 application starting in production on http://0.0.0.0:3000
=> Run `rails server -h` for more startup options
[2021-05-16 18:18:18] INFO  WEBrick 1.6.1
[2021-05-16 18:18:18] INFO  ruby 2.7.3 (2021-04-05) [x86_64-linux]
[2021-05-16 18:18:18] INFO  WEBrick::HTTPServer#start: pid=32410 port=3000

이제 브라우져에서 3000 포트로 접속을 시도해 본다. 만일 안된다면 CentOS 7 의 firewalld 서비스를 중지 시키고 다시해본다.

nginx 연동

redmine 의 자체 웹서버를 이용하는게 아니라 nginx 를 이용하는 방법이 있다. 이를 위해서 passenger 라는 프로그램이 필요한데, 이를 먼저 설치해 준다.

먼저 root 계정으로 gem 를 이용해서 passenger 를 설치해 준다.

passenger 설치
ZSH
1
]# gem install passenger

이제 passenger 프로그램을 이용해서 passenger-nginx 모듈을 설치해주는데, 이게 passenger 가 알아서 nginx 를 다운로드 받아서 컴파일 설치까지 해준다.

nginx 설치
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
]# passenger-install-nginx-module
Please specify a prefix directory [/opt/nginx]:
The Nginx configuration file (/opt/nginx/conf/nginx.conf)
must contain the correct configuration options in order for Phusion Passenger
to function correctly.
 
This installer has already modified the configuration file for you! The
following configuration snippet was inserted:
 
  http {
      ...
      passenger_root /opt/ruby-2.7.3/lib/ruby/gems/2.7.0/gems/passenger-6.0.8;
      passenger_ruby /opt/ruby-2.7.3/bin/ruby;
      ...
  }
 
After you start Nginx, you are ready to deploy any number of Ruby on Rails
applications on Nginx.
 
Press ENTER to continue.

명령어를 실행하면 이것저것 물어보는데, 설치 모듈에는 python 을 빼고 ruby 만 되도록 했고 설치는 커스텀이 아닌 그냥 1번으로 설치를 진행 했다. 디렉토리는 /opt/nginx 기본값을 사용했다.

컴파일이 모두 정상적으로 진행이 되면 위와같이 설정 안내가 간단하게 나온다.

nginx.conf 파일 설정

기본적인 설정만 되어 있어서 redmine 을 위한 설정을 다음과 같이 해준다.

nginx 설정
INI
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
]# mkdir -p /opt/nginx/run/passenger-instreg
]# vim /opt/nginx/conf/nginx.conf
# redmine 계정을 이용함으로 프로세스가 redmine 으로 동작하도록 한다.
user  redmine;
worker_processes  auto;
 
error_log  logs/error.log;
 
pid        run/nginx.pid;
 
events {
    use epoll;
    worker_connections  1024;
    multi_accept on;
}
 
http {
    passenger_root /opt/ruby-2.7.3/lib/ruby/gems/2.7.0/gems/passenger-6.0.8;
    passenger_ruby /opt/ruby-2.7.3/bin/ruby;
    passenger_instance_registry_dir /opt/nginx/run/passenger-instreg;
 
    include       mime.types;
    default_type  application/octet-stream;
 
    sendfile        on;
    tcp_nopush        on;
    tcp_nodelay        on;
    keepalive_timeout  65;
 
    server {
        listen       80;
        server_name  192.168.96.11;
 
        # 파일 전송 사이즈
        client_max_body_size 64M;
 
        #body와 header의 버퍼 크기 설정
        client_body_buffer_size 10K;
        client_header_buffer_size 1k;
        large_client_header_buffers 2 1k;
 
        # 페이지 로딩이 일정시간 넘어가면 서버와의 연결을 끊도록 설정
        client_body_timeout 12;
        client_header_timeout 12;
        send_timeout 10;
 
        # 정적 파일 압축 기능 사용 설정
        gzip on;
        # 압축율(1~9)
        gzip_comp_level 6;
        # 압축 대상 최소 크기
        gzip_min_length 1024;
        # 압축 대상 컨텐츠. MIME 타입으로 설정
        gzip_types text/plain text/css application/x-javascript application/json text/javascript text/xml application/xml image/png image/jpeg image/jpg image/gif;
        # 클라이언트 캐쉬 설정.
        location ~* .(jpg|jpeg|png|gif|ico|css|js)$ {
                expires 7d;
                access_log off;
        }
 
        access_log  logs/redmine.access.log;
        error_log  logs/redmine.error.log;
        # redmine 홈 디렉토리
        root /opt/redmine/redmine-4.2.1/public;
        # passenger 기능 활성화
        passenger_enabled on;
    }
 
}
# vim: syntax=nginx ts=4 sw=4 sts=4 sr noet
]# /opt/nginx/sbin/nginx -t
nginx: the configuration file /opt/nginx/conf/nginx.conf syntax is ok
nginx: configuration file /opt/nginx/conf/nginx.conf test is successful
]# /opt/nginx/sbin/nginx

systemd 등록

nginx 를 systemd 에 등록 해보자. 다음과 같이 파일을 작성 한다.

nginx 설정
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
]# vim /etc/systemd/system/nginx.service
# Stop dance for nginx
# =======================
#
# ExecStop sends SIGSTOP (graceful stop) to the nginx process.
# If, after 5s (--retry QUIT/5) nginx is still running, systemd takes control
# and sends SIGTERM (fast shutdown) to the main process.
# After another 5s (TimeoutStopSec=5), and if nginx is alive, systemd sends
# SIGKILL to all the remaining processes in the process group (KillMode=mixed).
#
# nginx signals reference doc:
# http://nginx.org/en/docs/control.html
#
[Unit]
Description=A high performance web server and a reverse proxy server
After=network.target
 
[Service]
Type=forking
PIDFile=/opt/nginx/run/nginx.pid
ExecStartPre=/opt/nginx/sbin/nginx -t -q -g 'daemon on; master_process on;'
ExecStart=/opt/nginx/sbin/nginx -g 'daemon on; master_process on;'
ExecReload=/opt/nginx/sbin/nginx -g 'daemon on; master_process on;' -s reload
ExecStop=/opt/nginx/sbin/nginx -g 'daemon on; master_process on;' -s stop
TimeoutStopSec=5
KillMode=mixed
 
[Install]
WantedBy=multi-user.target

이제 systemd 유닛을 활성화 해주고 시작해준다.

systemd 유닛 활성화 및 시작
ZSH
1
2
]# systemctl enable nginx.service
]# systemctl start nginx.service

Redmine 설치하기

Redmine 은 오픈소스 프로젝트 매니지먼트 프로그램이다. Ruby 로 제작되었기 때문에 설치 과정에서 Ruby 가 있어야 한다. 웹을 통해서 서비스를 하기 때문에 보통 웹서버와 연동을 하는 편이다.

환경

  • OS: CentOS 7
  • Arch: x86_64
  • Minimal Installation 상태

MariaDB 설치

MySQL 도 가능하지만, MariaDB 를 선택했다. 컴파일 설치가 가능하지만 패키지 설치로 설치한다.

MariaDB 설치
ZSH
1
]# yum install mariadb-server -y

각종 의존성이 함께 설치가 된다.

my.cnf 파일을 다음과 같이 설정해 준다.

MariaDB 설정
MySQL
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
]# vim /etc/my.cnf
 
[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
# Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0
# Settings user and group are ignored when systemd is used.
# If you need to run mysqld under a different user or group,
# customize your systemd unit file for mariadb according to the
# instructions in http://fedoraproject.org/wiki/Systemd
 
character-set-server = utf8
collation-server = utf8_general_ci
 
port = 3306
skip-name-resolve
 
[mysqld_safe]
log-error=/var/log/mariadb/mariadb.log
pid-file=/var/run/mariadb/mariadb.pid
 
#
# include all files from the config directory
#
!includedir /etc/my.cnf.d
 
[mysql]
default-character-set = utf8
no-auto-rehash
show-warnings
prompt=\u@\h:\d\_\R:\m:\\s>
pager="less -n -i -F -X -E"

다음과 같이 서버를 실행해 준다.

MariaDB 실행
ZSH
1
2
]# systemctl start mariadb.service
]# systemctl enable mariadb.service

이제 기본적인 설정을 위해 mysql_secure_installation 을 실행해 준다.

MariaDB 기초 설정
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
]# mysql_secure_installation
 
NOTE: RUNNING ALL PARTS OF THIS SCRIPT IS RECOMMENDED FOR ALL MariaDB
      SERVERS IN PRODUCTION USE!  PLEASE READ EACH STEP CAREFULLY!
 
In order to log into MariaDB to secure it, we'll need the current
password for the root user.  If you've just installed MariaDB, and
you haven't set the root password yet, the password will be blank,
so you should just press enter here.
 
Enter current password for root (enter for none): <- 그냥 엔터
OK, successfully used password, moving on...
 
Setting the root password ensures that nobody can log into the MariaDB
root user without the proper authorisation.
 
Set root password? [Y/n] Y
New password:
Re-enter new password:
Password updated successfully!
Reloading privilege tables..
... Success!
 
By default, a MariaDB installation has an anonymous user, allowing anyone
to log into MariaDB without having to have a user account created for
them.  This is intended only for testing, and to make the installation
go a bit smoother.  You should remove them before moving into a
production environment.
 
Remove anonymous users? [Y/n] Y
... Success!
 
Normally, root should only be allowed to connect from 'localhost'.  This
ensures that someone cannot guess at the root password from the network.
 
Disallow root login remotely? [Y/n] Y
... Success!
 
By default, MariaDB comes with a database named 'test' that anyone can
access.  This is also intended only for testing, and should be removed
before moving into a production environment.
 
Remove test database and access to it? [Y/n] Y
- Dropping test database...
... Success!
- Removing privileges on test database...
... Success!
 
Reloading the privilege tables will ensure that all changes made so far
will take effect immediately.
 
Reload privilege tables now? [Y/n] Y
... Success!
 
Cleaning up...
 
All done!  If you've completed all of the above steps, your MariaDB
installation should now be secure.
 
Thanks for using MariaDB!
]#

root 패스워드를 설정하기 때문에 패스워드을 잃어서는 안된다.

이제 redmine 에서 사용할 계정을 생성해 준다.

Redmine 을 위한 Mariadb 계정 설정
PgSQL
1
2
3
4
5
6
7
8
9
10
> use mysql;
Database changed
> CREATE DATABASE redmine CHARACTER SET utf8 COLLATE utf8_general_ci;
Query OK, 1 row affected (0.00 sec)
> CREATE USER 'redmine'@'%' IDENTIFIED BY 'HS79aB';
Query OK, 0 rows affected (0.00 sec)
> GRANT ALL PRIVILEGES ON redmine.* TO 'redmine'@'%';
Query OK, 0 rows affected (0.00 sec)
> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)

이로서 redmine 설치를 위한 Mariadb 설치 설정은 모두 끝났다.

Redmine 설치

Redmine 4.2 버전을 설치하기 위해서는 다음과 같은 의존성이 필요하다.

  • Ruby – 4.2
  • Rails – 5.2

CentOS 7 에 Ruby 2.0 만을 패키지로 지원한다. 컴파일 설치를 해야한다.

컴파일을 위한 환경 구축

컴파일러와 라이브러리들을 함께 설치해 준다.

컴파일러와 라이브러리 설치
ZSH
1
2
]# yum -y install libxslt-devel libyaml-devel libxml2-devel gdbm-devel libffi-devel zlib-devel openssl-devel libyaml-devel readline-devel curl-devel openssl-devel pcre-devel git memcached-devel valgrind-devel mysql-devel ImageMagick-devel ImageMagick
]# yum install curl gpg gcc gcc-c++ make patch autoconf automake bison libffi-devel libtool bzip2 iconv-devel glibc-headers glibc-devel

Passenger 와 Nginx 설치

Passenger 는 가벼운 웹 애플리케이션 서버로 Ruby 를 지원한다. 이것을 Nginx 와 통합시켜줄 것이다. 다음과 같이 epel 저장소를 활성화 해준다.

Passenger 와 Nginx 설치를 위한 epel 저장소 추가
ZSH
1
2
3
]# yum install -y epel-release yum-utils
]# yum-config-manager --enable epel
]# yum clean all && sudo yum update -y

이제 Passenger 설치를 위한 저장소를 추가 준다.

Passenger 와 Nginx 설치를 위한 저장소 주소 추가 및 설치
ZSH
1
2
3
4
]# yum install -y pygpgme curl
]# curl --fail -sSLo /etc/yum.repos.d/passenger.repo https://oss-binaries.phusionpassenger.com/yum/definitions/el-passenger.repo
]# yum install -y nginx passenger nginx-mod-http-passenger
]#

redmine 시스템 계정 생성

다음과 같이 redmine 을 위한 시스템 계정을 생성해 준다.

컴파일러와 라이브러리 설치
ZSH
1
2
3
]# useradd -m -U -r -d /opt/redmine redmine\
]# usermod -a -G redmine nginx
]# chmod 750 /opt/redmine

RVM 을 이용한 Ruby 설치를 할 것이기 때문에 GPG 키를 먼저 임포트 해준다.

gpg 키 임포트
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
]$ gpg --keyserver hkp://pool.sks-keyservers.net --recv-keys 409B6B1796C275462A1703113804BB82D39DC0E3 7D2BAF1CF37B13E2069D6956105BD0E739499BDB
gpg: directory `/opt/redmine/.gnupg' created
gpg: new configuration file `/opt/redmine/.gnupg/gpg.conf' created
gpg: WARNING: options in `/opt/redmine/.gnupg/gpg.conf' are not yet active during this run
gpg: keyring `/opt/redmine/.gnupg/secring.gpg' created
gpg: keyring `/opt/redmine/.gnupg/pubring.gpg' created
gpg: requesting key D39DC0E3 from hkp server pool.sks-keyservers.net
gpg: requesting key 39499BDB from hkp server pool.sks-keyservers.net
gpg: /opt/redmine/.gnupg/trustdb.gpg: trustdb created
gpg: key D39DC0E3: public key "Michal Papis (RVM signing) <mpapis@gmail.com>" imported
gpg: key 39499BDB: public key "Piotr Kuczynski <piotr.kuczynski@gmail.com>" imported
gpg: no ultimately trusted keys found
gpg: Total number processed: 2
gpg:               imported: 2  (RSA: 2)
</piotr.kuczynski@gmail.com></mpapis@gmail.com>

다음과 같이 RVM 을 설치 해준다.

RVM 설치
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
]$ curl -sSL https://get.rvm.io | bash -s stable
Downloading https://github.com/rvm/rvm/archive/1.29.12.tar.gz
Downloading https://github.com/rvm/rvm/releases/download/1.29.12/1.29.12.tar.gz.asc
gpg: Signature made 2021년 01월 16일 (토)  using RSA key ID 39499BDB
gpg: Good signature from "Piotr Kuczynski <piotr.kuczynski@gmail.com>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 7D2B AF1C F37B 13E2 069D  6956 105B D0E7 3949 9BDB
GPG verified '/opt/redmine/.rvm/archives/rvm-1.29.12.tgz'
Installing RVM to /opt/redmine/.rvm/
    Adding rvm PATH line to /opt/redmine/.profile /opt/redmine/.mkshrc /opt/redmine/.bashrc /opt/redmine/.zshrc.
    Adding rvm loading line to /opt/redmine/.profile /opt/redmine/.bash_profile /opt/redmine/.zlogin.
Installation of RVM in /opt/redmine/.rvm/ is almost complete:
 
  * To start using RVM you need to run `source /opt/redmine/.rvm/scripts/rvm`
    in all your open shell windows, in rare cases you need to reopen all shell windows.
Thanks for installing RVM 🙏
Please consider donating to our open collective to help us maintain RVM.
 
👉  Donate: https://opencollective.com/rvm/donate
]$ source /opt/redmine/.rvm/scripts/rvm

마지막에 source 부분을 반드시 해준다. Ruby 2.7 을 설치해 준다.

ruby 설치
ZSH
1
2
]$ rvm install 2.7
]$ rvm --default use 2.7

mysql2 extension 을 다음과 같이 설치해 준다.

mysql2 extension 설치
ZSH
1
2
3
4
5
6
7
8
/opt/redmine/.rvm/rubies/ruby-2.7.2/bin/gem install mysql2
Fetching mysql2-0.5.3.gem
Building native extensions. This could take a while...
Successfully installed mysql2-0.5.3
Parsing documentation for mysql2-0.5.3
Installing ri documentation for mysql2-0.5.3
Done installing documentation for mysql2 after 0 seconds
1 gem installed

이제 Redmine 을 설치해 준다.

Redmine 설치
ZSH
1
2
]$ curl -LO https://www.redmine.org/releases/redmine-4.2.1.tar.gz
]$ tar xvzf redmine-4.2.1.tar.gz

다음과 같이 데이베이스 접속 정보를 수정해 준다.

Redmine 데이터베이스 설정
ZSH
1
2
3
4
5
6
7
8
9
10
]$ cp /opt/redmine/redmine-4.2.1/config/database.yml.example /opt/redmine/redmine-4.2.1/config/database.yml
]$ vi /opt/redmine/redmine-4.2.1/config/database.yml
production:
  adapter: mysql2
  database: redmine
  host: localhost
  username: redmine
  password: ""
  # Use "utf8" instead of "utfmb4" for MySQL prior to 5.7.7
  encoding: utf8

Redmine 의존성을 설치해 준다.

Redmine 의존성 설치
ZSH
1
2
]$ /opt/redmine/.rvm/rubies/ruby-2.7.2/bin/gem install bundler
]$ bundle install --without development test postgresql sqlite

키를 생성하고 데이터베이스를 생성해 준다.

키를 생성하고 데이터베이스를 생성
ZSH
1
2
3
4
5
6
7
8
$ bundle exec rake generate_secret_token
$ RAILS_ENV=production bundle exec rake db:migrate
$ RAILS_ENV=production bundle exec rake redmine:load_default_data
 
Select language: ar, az, bg, bs, ca, cs, da, de, el, en, en-GB, es, es-PA, et, eu, fa, fi, fr, gl, he, hr, hu, id, it, ja, ko, lt, lv, mk, mn, nl, no, pl, pt, pt-BR, ro, ru, sk, sl, sq, sr, sr-YU, sv, th, tr, uk, vi, zh, zh-TW [en] Unknown language!
Select language: ar, az, bg, bs, ca, cs, da, de, el, en, en-GB, es, es-PA, et, eu, fa, fi, fr, gl, he, hr, hu, id, it, ja, ko, lt, lv, mk, mn, nl, no, pl, pt, pt-BR, ro, ru, sk, sl, sq, sr, sr-YU, sv, th, tr, uk, vi, zh, zh-TW [en] ko
====================================
Default configuration data loaded.

Nginx 설정

Nginx 설정
Apache
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
passenger_root /usr/share/ruby/vendor_ruby/phusion_passenger/locations.ini;
passenger_ruby /opt/redmine/.rvm/gems/default/wrappers/ruby;
passenger_instance_registry_dir /var/run/passenger-instreg;
 
server {
listen 80;
server_name 192.168.96.8;
 
root /opt/redmine/redmine-4.2.1/public;
 
# log files
access_log /var/log/nginx/example.com.access.log;
error_log /var/log/nginx/example.com.error.log;
 
passenger_enabled on;
passenger_min_instances 1;
 
client_max_body_size 10m;
}

listener.ora, tnsnames.ora 생성하기

오라클 데이터베이스 19c 를 Silent 설치를 하고 나면 listener.ora, tnsnames.ora 가 생성되지 않는다. 어떻게 수동으로 이것을 생성하는지에 대해서 알아보고 차이에 대해서 간단히 설명한다.

신기하게도 오라클 데이터베이스 19c를 Silent 설치하고 난 후에 이것을 생성하지 않는다고 하더라도 원격 클라이언트 접속에는 아무런 문제가 되지 않는다. 하지만 접속 서비스를 할당하고 접속을 쪼개고 싶다면 tnsnames.ora 파일이 반드시 있어야 한다.

Oracle Net Listener

Listener 는 정확하게는 ‘Oracle Net Listener’ 라고 한다. 리스너는 하나 혹은 그 이상의 지원하는 서비스에 대한 정보, 프로토콜 주소들을 리스닝하도록 설정된다. 리스너의 설정 정보는 listener.ora 파일에 저장된다. 모든 설정 파라메터는 디폴트 값을 가지기 때문에 별도의 설정을 하지 않더라도 시작하는데 문제가 없다. 디폴트 리스너는 LISTENER 라는 이름을 가지고 시작시 아무런 서비스를 지원하지 않으며 다음과 같은 TCP/IP 프로토콜 주소만 리스닝한다.

디폴트 리스너의 TCP/IP 프로토콜 주소 리스닝
1
(ADDRESS=(PROTOCOL=tcp)(HOST=host_name)(PORT=1521))

리스너는 클라이언트 요청을 지원하는 서비스로 포워드 한다. 이러한 서비스들은 listener.ora 파일에 정적으로 설정되어지거나 리스너로 동적으로 등록되어질 수 있다. 이러한 등록 기능을 서비스 등록(service registration) 이라고 부른다. 등록은 PMON process 에 의해서 실행된다.

참고: Configuring and Administering Oracle Net Listener

생성하기

오라클 데이터베이스 19c 를 Silent 설치하게되면 리스너 설정 파일이 생성되지 않는다. 생성하기 위해서 netca 명령어를 이용할 텐데, 역시나 Silent 모드로 실행을 해준다. 그러기 위해서는 response 파일이 있어야 하는데, 다음과 같은 경로에 있다.

netca 를 위한 response 파일
ZSH
1
2
$ ls $ORACLE_HOME/assistants/netca/netca.rsp
/u01/app/oracle/product/19.3.0/dbhome_1/assistants/netca/netca.rsp

파일을 열어보면 좀 복잡해 보이는데, 주석 등을 제거하면 설정된 값은 다음과 같다.

netca.rsp 설정
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
$ cat $ORACLE_HOME/assistants/netca/netca.rsp | grep -v ^$| grep -v ^#
[GENERAL]
RESPONSEFILE_VERSION="19.0"
CREATE_TYPE="CUSTOM"
[oracle.net.ca]
INSTALLED_COMPONENTS={"server","net8","javavm"}
INSTALL_TYPE=""typical""
LISTENER_NUMBER=1
LISTENER_NAMES={"LISTENER"}
LISTENER_PROTOCOLS={"TCP;1521"}
LISTENER_START=""LISTENER""
NAMING_METHODS={"TNSNAMES","ONAMES","HOSTNAME"}
NSN_NUMBER=1
NSN_NAMES={"EXTPROC_CONNECTION_DATA"}
NSN_SERVICE={"PLSExtProc"}
NSN_PROTOCOLS={"TCP;HOSTNAME;1521"}

내용들은 그냥 디폴트 값을 가지고 있다. 오라클 데이터베이스가 listener.ora 파일이 없이 잘 작동하는 이유가 위 파일의 값을 가지고 작동하기 때문인 것인데, 그렇다면 이것을 가지고 설정 파일을 만들어도 문제가 없다는 것과 같은 의미가 된다.

listener.ora 파일 생성
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
]$ netca -silent -responsefile $ORACLE_HOME/assistants/netca/netca.rsp
Parsing command line arguments:
    Parameter "silent" = true
    Parameter "responsefile" = /u01/app/oracle/product/19.3.0/dbhome_1/assistants/netca/netca.rsp
Done parsing command line arguments.
Oracle Net Services Configuration:
Profile configuration complete.
Oracle Net Listener Startup:
    Running Listener Control:
      /u01/app/oracle/product/19.3.0/dbhome_1/bin/lsnrctl start LISTENER
    Listener Control complete.
    Listener started successfully.
Listener configuration complete.
Oracle Net Services configuration successful. The exit code is 0

실행을 하게되면 listener.ora 파일이 생성되면서 리스너가 시작된다.

여기서 멀티테넌트 데이터베이스 구조일 경우에 PDB 에 따른 별도의 클라이언트 접속 요청을 처리해줄 필요가 있게된다. 리스너가 클라이언트 요청 파라메터에 PDB 의 SID 나 SERVICE 가 포함될 경우에 이를 받아서 처리해줘야 하는데, 그러기 위해서는 SID_LIST_LISTENER 엔트리를 사용해야 한다.

listener.ora 에 SID_LIST_LISTENER
ZSH
1
2
3
4
5
6
7
8
9
10
11
SID_LIST_LISTENER =
  (SID_LIST =
    (SID_DESC =
      (GLOBAL_DBNAME = O19C)
      (SID_NAME = o19c)
    )
    (SID_DESC =
      (GLOBAL_DBNAME = PDB1)
      (SID_NAME = pdb1)
    )
  )

위 내용을 생성한 listener.ora 에 추가해 준다.

주요한 설정 내용은 다음과 같다.

  • SID_NAME – oracle System IDentifier 초기 설정 파라메터 파일에 INSTANCE_NAME 으로부터 SID 값을 얻을 수 있다.
  • GLOBAL_DBNAME – 데이터베이스 서비스다. 클라이언트 접속 요청을 처리하는 동안, 리스너는 클라이언트 접속 디스크립터에 SERVICE_NAME 파라메터 값과 이 파라메터의 값을 매치시킬려고 한다. 만약 클라이언트 접속 디스크립터가 SID 파라메터를 사용한다면 리스너는 더 이상 매칭 시도를 하지 않는다. 이 파라메터는 전용 서버에서 다이나믹 설정을 지원하지 않는 Oracle8 데이터베이스 설정을 위한 것이였다. 이 파라메터는 Oracle8i 나 그 이후에 데이터베이스 서비스 사용을 위해 필요할 수도 있다. 이 파라메터 값은 기본적으로 초기화 파라메터 파일에 DB_NAME 과 DB_DOMAIN 파라메터의 조합으로부터 (DB_NAME.DB_DOMAIN) 얻을 수 있다.
  • ORACLE_HOME – 오라클 인스턴스의 위치. 세팅하지 않으면 오라클 홈 디렉토리으로 가정한다. 리눅스와 유닉스에서 세팅은 옵션이지만 MS Windows 에서는 세팅을 무시하면 레지스트리 값 HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\HOMEID 를 사용한다.

오라클 데이터베이스의 컨테이너별 서비스를 알기위해서는 다음의 쿼리를 실행하면 된다.

오라클 데이터베이스 서비스들
PgSQL
1
2
3
4
5
6
7
8
9
10
SQL> SELECT name, pdb
    FROM   v$services
    ORDER BY name;
 
NAME             PDB        
SYS$BACKGROUND   CDB$ROOT  
SYS$USERS        CDB$ROOT  
o19c             CDB$ROOT  
o19cXDB          CDB$ROOT  
pdb1             PDB1

Local Naming Prarameters in the tnsnames.ora 파일

tnsnames.ora 파일은 네트워크 서비스 이름을 접속 디스크립트로 매핑하거나, Net 서비스 이름을 리스너 프로토콜 주소로 맵핑을 포함한 설정 파일이다. Net 서비스 이름은 접속 디스크립터를 포함하는 데이터베이스 네트워크 주소와 연결된 별명(Alias) 이다. 접속 드스크립터는 프로토콜 주소를 통한 리스너의 위치와 연결을 위한 데이터베이스 서비스의 이름을 포함한다. 클라이언트와 서버는 애플리케이션에서 연결할대에 Net 서비스 이름을 사용한다.

오라클 멀티테넌트 데이터베이스에서 CDB, PDB 별로 접속을 하기 위해서는 tnsnames.ora 파일을 다음과 같이 생성해 준다.

tnsnames.ora 파일 내용
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
O19C =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = oradb1.systemv.local)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = o19c)
    )
  )
 
PDB1 =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = oradb1.systemv.local)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = pdb1)
    )
  )

참고: Local Naming Parameters in the tnsnames.ora File

listener.ora, tnsnames.ora 차이

접속하는 방법에 차이를 둔다. 원칙적으로 접속하는 방법은 다음과 같다.

Direct 접속방법
ZSH
1
]$ sqlplus hr/HrPassword1@oradb1.systemv.local:1521/pdb1

@ 를 기준으로 뒤에 있는 호스트네임:포트/서비스 이다. 이것은 Direct 연결 방법이라고 하는데, 이 연결은 listener.ora 에 정의된 리스너 설정파일에 의해서 접속이 이루어진다.

이것을 짧게 별명만으로 지정할 수 있는데, 그것을 가능하게 하는 것이 tnsnames.ora 이다. pdb1 컨테이너에 접속하기 위해서는 PDB1 별명을 사용하기 때문에 다음과 같이 해도 된다.

Alias 를 이용한 접속방법
ZSH
1
]$ sqlplus hr/HrPassword1@PDB1

PDB1 은 tnsnames.ora 파일에서 별명을 찾아서 접속 디스크립트에 값을 가져다 쓴다. 그리고 연결을 시도하고 이것을 오라클 리스너가 받아서 listener.ora 파일에 파라메터와 매핑해 접속이 이루어지게 된다.

멀티테넌트 데이터베이스 구조에서는 listener.ora 파일에서 SID_LIST_LISTENER 설정을 해줘야지만 PDB 에 접속이 가능해진다.

오라클 기본 정보 확인

오라클을 설치하고 나면 정보를 확인해야 한다. 오라클은 많은 테이블, 뷰, 동적쿼리등을 지원하는데 워낙 많다보니까 다 알수는 없다. 필요한 정보를 위한 간단한 쿼리들을 소개 한다.

데이터베이스 컴포넌트들의 상태 확인

오라클 데이터베이스는 다양한 컴포넌트들로 구성되는데, 이에 대한 상태를 확인할 수 있다.

데이터베이스 컴포넌트들의 상태 확인
PgSQL
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
SQL> col comp_name for a40
SQL> col version for a15
SQL> col status for a10
SQL> SELECT name, comp_name, version, status FROM v$database, dba_registry;
NAME   COMP_NAME                            VERSION      STATUS      
O19C   Oracle Database Catalog Views        19.0.0.0.0   VALID        
O19C   Oracle Database Packages and Types   19.0.0.0.0   VALID        
O19C   Oracle Real Application Clusters     19.0.0.0.0   OPTION OFF  
O19C   JServer JAVA Virtual Machine         19.0.0.0.0   VALID        
O19C   Oracle XDK                           19.0.0.0.0   VALID        
O19C   Oracle Database Java Packages        19.0.0.0.0   VALID        
O19C   OLAP Analytic Workspace              19.0.0.0.0   VALID        
O19C   Oracle XML Database                  19.0.0.0.0   VALID        
O19C   Oracle Workspace Manager             19.0.0.0.0   VALID        
O19C   Oracle Text                          19.0.0.0.0   VALID        
O19C   Oracle Multimedia                    19.0.0.0.0   VALID        
O19C   Spatial                              19.0.0.0.0   VALID        
O19C   Oracle OLAP API                      19.0.0.0.0   VALID        
O19C   Oracle Label Security                19.0.0.0.0   VALID        
 
NAME   COMP_NAME               VERSION      STATUS  
O19C   Oracle Database Vault   19.0.0.0.0   VALID    
 
 
15 rows selected.

만일 INVALID 컴포넌트가 있다면 다음과 같이 해준다.

데이터베이스 컴포넌트 재컴파일
PgSQL
1
SQL> @?/rdbms/admin/utlrp.sql

데이터베이스 이름 확인

데이터베이스 이름이 뭔지를 확인할 수 있다.

데이터베이스 이름 확인
PgSQL
1
2
3
SQL> SELECT dbid, name, db_unique_name, created, log_mode, open_mode, cdb, con_id FROM v$database;
        DBID NAME   DB_UNIQUE_NAME   CREATED     LOG_MODE       OPEN_MODE    CDB     CON_ID
  2857479539 O19C   o19c             30-APR-21   NOARCHIVELOG   READ WRITE   YES          0            

CDB 가 YES 면 데이터베이스가 CDB 로 생성되었다는 것을 말한다. NO 라면 non-CDB 데이터베이스다.

DB_UNIQUE_NAME 은 쉘 환경변수에도 사용되고 있어 확인해 둘 필요가 있다. 데이터베이스 상태는 READ WRITE 상태여야 정상상태로 본다.

컨테이너 확인

오라클 12c 부터 도입된 개념이 멀티테넌트 컨테이너 데이터베이스다. 어떤 컨테이너들이 있는지 확인해 볼 필요가 있다.

컨테이터 목록 확인
PgSQL
1
2
3
4
5
SQL> select con_id, name, open_mode, dbid, con_uid, guid from v$containers;
  CON_ID NAME       OPEN_MODE            DBID      CON_UID GUID                              
       1 CDB$ROOT   READ WRITE     2857479539            1 86B637B62FDF7A65E053F706E80A27CA  
       2 PDB$SEED   READ ONLY      3121618961   3121618961 C1202C7545A136AAE0531D60A8C0E59E  
       3 PDB1       READ WRITE     2824454508   2824454508 C120605562113BC8E0531D60A8C0D56F

v$containers 뷰는 CDB 안에 root 와 모든 PDB 를 포함한 모든 컨테이너에 대한 정보를 제공한다. 이것으로 PDB 이름을 확인해 볼 수 있다.

모든 CDB 는 다음의 컨테이너를 포함 한다.

  • 정확하기 한개의 root – root 는 오라클이 제공하는 메타데이터와 일반 유저들을 저장한다. 메타데이터는 오라클이 제공하는 PL/SQL 패키지드르이 소스코드 같은 것이다. 일반 유저는 모든 컨테이너가 알아야 하는 데이터베이스 사용자다. root 컨테이너의 이름은 CDB$ROOT 다.
  • 정확히 하나의 시드(seed) PDB – 시드 PDB 는 CDB 가 새로운 PDB를 생성하는데 사용할 수 있도록 하는 시스템이 제공하는 템플릿이다. 시드 PDB 이름은 PDB$SEED 다. PDB$SEED 를 추가하거나 수정할 수 없다.
  • 없거나 하나 이상의 사용자 생성 PDB – PDB는 사용자가 생성한 엔터티로 코드와 데이터를 포함한다. 예를들어, PDB는 인적자원(Human Resources) 나 판매 애플리케이션(Sales application) 과 같은 특정한 애플리케이션을 지원할 수있다. CDB 생성 시점시 PDB는 존재하지 않는다. PDB는 비지니스 요청에 따라 추가 된다.
Multitenant Container Database

위 그림은 멀티테넌트 컨테이너 데이터베이스 구조 이다. CDB 안에 PDB 가 존재하는 구조다. PDB 는 Pluggable Database 다.

root 컨테이너와 함께 오라클 데이터베이스는 자동으로 seed PDB(PDB$SEED) 를 생성 한다. 다음 그래프는 새로운 CDB 생성을 보여준다.

새로운 CDB 생성. seed PDB 도 함께 생성된다.

연결 상태 보기

CDB, PDB 구조에서 현재 내가 어느 곳에 연결되어 있는지 아는 건 중요 하다. 다음의 명령어로 확인해 볼 수 있다.

연결 정보 확인
PgSQL
1
2
3
4
5
6
7
8
SQL> show con_id;
CON_ID
------------------------------
1
SQL> show con_name;
CON_NAME
------------------------------
CDB$ROOT

혹은 다음과 같은 쿼리문으로 확인 가능하다.

연결 정보 확인
PgSQL
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
SQL> select sys_context('USERENV','CON_NAME') CON_NAME,
                sys_context('USERENV','CON_ID') CON_ID,
                sys_context('USERENV','DB_NAME') DB_NAME from DUAL;
 
CON_NAME   CON_ID   DB_NAME  
CDB$ROOT   1        o19c      
 
 
SQL> alter session set container=pdb1;
 
Session altered.
 
SQL> select sys_context('USERENV','CON_NAME') CON_NAME,
                sys_context('USERENV','CON_ID') CON_ID,
                sys_context('USERENV','DB_NAME') DB_NAME from DUAL;
 
CON_NAME   CON_ID   DB_NAME  
PDB1       3        PDB1

컨테이너 타입 확인하기

내가 접속한 컨테이너가 CDB 인지, PDB 인지 타입을 확인할 수 있다.

컨테이너 타입 확인
PgSQL
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
SQL> select decode(sys_context('USERENV', 'CON_NAME'),'CDB$ROOT',sys_context('USERENV', 'DB_NAME'),sys_context('USERENV', 'CON_NAME')) DB_NAME,
                decode(sys_context('USERENV','CON_ID'),1,'CDB','PDB') TYPE
           from DUAL;
 
DB_NAME   TYPE  
o19c      CDB    
 
 
SQL> alter session set container=pdb1;
 
Session altered.
 
SQL> select decode(sys_context('USERENV', 'CON_NAME'),'CDB$ROOT',sys_context('USERENV', 'DB_NAME'),sys_context('USERENV', 'CON_NAME')) DB_NAME,
                decode(sys_context('USERENV','CON_ID'),1,'CDB','PDB') TYPE
           from DUAL;
 
DB_NAME   TYPE  
PDB1      PDB

컨테이너 연결 세션 변경하기

일반 사용자(common user) 는 CDB, PDB 모두에 걸친 사용자임으로 연결 세션 변경을 통해서 PDB, CDB 를 교체할 수 있다.

컨테니어 연결 세션 변경
PgSQL
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
SQL> alter session set container=pdb1;
 
Session altered.
 
SQL> show con_id;
CON_ID
------------------------------
3
SQL> show con_name;
CON_NAME
------------------------------
PDB1
 
SQL> alter session set container=cdb$root;
 
Session altered.
 
SQL> show con_id;
CON_ID
------------------------------
1
SQL> show con_name;
CON_NAME
------------------------------
CDB$ROOT

CDB 와 연결된 PDB 상태 보기

CDB 와 연결된 PDB 상태는 다음과 같이 조회할 수 있다.

PDB 상태 정보 보기
PgSQL
1
2
3
4
5
SQL> COLUMN PDB_NAME FORMAT A15
SQL> SELECT PDB_ID, PDB_NAME, STATUS FROM CDB_PDBS ORDER BY PDB_ID;
  PDB_ID PDB_NAME   STATUS  
       2 PDB$SEED   NORMAL  
       3 PDB1       NORMAL

STATUS 값을 확인해 상태를 점검할 수 있다.

PDB 의 오픈 모드(Open Mode) 보기

이 쿼리를 통해서 마지막 오픈시간을 확인해 볼 수 있다. root 컨테이너에서는 모든 PDB 에 대한 정보를 보여주며, PDB 에 있다면 오직 하나의 PDB에 대한 정보만 보여준다.

PDB 오픈 상태 보기
PgSQL
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
SQL> COLUMN NAME FORMAT A15
SQL> COLUMN RESTRICTED FORMAT A10
SQL> COLUMN OPEN_TIME FORMAT A30
SQL>  
SQL> SELECT NAME, OPEN_MODE, RESTRICTED, OPEN_TIME FROM V$PDBS;
NAME       OPEN_MODE    RESTRICTED   OPEN_TIME                                
PDB$SEED   READ ONLY    NO           01-MAY-21 04.52.38.929000000 PM +09:00  
PDB1       READ WRITE   NO           01-MAY-21 04.52.39.609000000 PM +09:00  
 
SQL> alter session set container = pdb1;
 
Session altered.
 
SQL> SELECT NAME, OPEN_MODE, RESTRICTED, OPEN_TIME FROM V$PDBS;
NAME   OPEN_MODE    RESTRICTED   OPEN_TIME                                
PDB1   READ WRITE   NO           01-MAY-21 04.52.39.609000000 PM +09:00

컨테이터 데이터 오브젝트 확인

root 에서(root CDB), 컨테이터 데이터 오브젝트는 root 나 PDB에 포함된 데이터베이스 오브젝트에(테이블 이나 사용자) 대한 정보를 볼 수 있다.

CDB_ 뷰는 컨테이너 데이터 오브젝트들인데, 여기에는 CON_ID 컬럼이 있다. 이 컬럼은 각 PDB 의 컨테이터 ID 를 나타내는 것이며 DBA_PDBS 뷰에 쿼리하면 각 컨테이너 ID 에 대한 PDB 이름을 알 수 있다. 이 두개의 뷰를 조인해서 다음과 같이 데이터 오브젝트 확인이 가능하다.

컨테이터 데이터 오브젝트 확인
PgSQL
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
SQL> COLUMN PDB_NAME FORMAT A15
SQL> COLUMN OWNER FORMAT A15
SQL> COLUMN TABLE_NAME FORMAT A30
SQL> SELECT p.PDB_ID, p.PDB_NAME, t.OWNER, t.TABLE_NAME
  FROM DBA_PDBS p, CDB_TABLES t
  WHERE p.PDB_ID > 2 AND
        t.OWNER IN('HR','OE') AND
        p.PDB_ID = t.CON_ID
  ORDER BY p.PDB_ID;
 
  PDB_ID PDB_NAME   OWNER   TABLE_NAME    
       3 PDB1       HR      REGIONS      
       3 PDB1       HR      LOCATIONS    
       3 PDB1       HR      DEPARTMENTS  
       3 PDB1       HR      JOBS          
       3 PDB1       HR      EMPLOYEES    
       3 PDB1       HR      JOB_HISTORY  
       3 PDB1       HR      COUNTRIES    
 
 
7 rows selected.

p.PDB_ID > 2 조건을 준 이유는 root 와 seed 컨테이너를 제외하기 위함이다.

PDBS 에 있는 사용자들 보기

DBA_PDBS 와 CDB_USERS 를 조합하면 각 PDB에 사용자들을 확인해 볼 수 있다.

PDB에 있는 사용자
PgSQL
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
SQL> COLUMN PDB_NAME FORMAT A15
SQL> COLUMN USERNAME FORMAT A30
SQL> SELECT p.PDB_ID, p.PDB_NAME, u.USERNAME
  FROM DBA_PDBS p, CDB_USERS u
  WHERE p.PDB_ID > 2 AND
        p.PDB_ID = u.CON_ID
  ORDER BY p.PDB_ID;
 
  PDB_ID PDB_NAME   USERNAME            
       3 PDB1       SYS                
       3 PDB1       SYSTEM              
       3 PDB1       XS$NULL            
       3 PDB1       LBACSYS            
       3 PDB1       OUTLN              
       3 PDB1       DBSNMP              
       3 PDB1       APPQOSSYS          
       3 PDB1       DBSFWUSER          
       3 PDB1       GGSYS              
       3 PDB1       ANONYMOUS          
       3 PDB1       CTXSYS              
       3 PDB1       DVSYS              
       3 PDB1       DVF                
       3 PDB1       GSMADMIN_INTERNAL  
 
  PDB_ID PDB_NAME   USERNAME                
       3 PDB1       MDSYS                    
       3 PDB1       OLAPSYS                  
       3 PDB1       XDB                      
       3 PDB1       WMSYS                    
       3 PDB1       GSMCATUSER              
       3 PDB1       MDDATA                  
       3 PDB1       SYSBACKUP                
       3 PDB1       REMOTE_SCHEDULER_AGENT  
       3 PDB1       PDBADMIN                
       3 PDB1       GSMUSER                  
       3 PDB1       SYSRAC                  
       3 PDB1       HR                      
       3 PDB1       OJVMSYS                  
       3 PDB1       SI_INFORMTN_SCHEMA      
 
  PDB_ID PDB_NAME   USERNAME    
       3 PDB1       AUDSYS      
       3 PDB1       DIP          
       3 PDB1       ORDPLUGINS  
       3 PDB1       SYSKM        
       3 PDB1       ORDDATA      
       3 PDB1       ORACLE_OCM  
       3 PDB1       SYS$UMF      
       3 PDB1       SYSDG        
       3 PDB1       ORDSYS      
 
 
37 rows selected.

p.PDB_ID > 2 조건을 준 이유는 root 와 seed 컨테이너를 제외하기 위함이다.

각 PDB 의 데이터 파일 보기

DBA_PDBS 와 CDB_DATA_FILES 뷰를 조합하면 데이터 파일들을 확인할 수 있다.

PDB 의 데이터 파일 보기
PgSQL
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
SQL> COLUMN PDB_ID FORMAT 999
SQL> COLUMN PDB_NAME FORMAT A8
SQL> COLUMN FILE_ID FORMAT 9999
SQL> COLUMN TABLESPACE_NAME FORMAT A10
SQL> COLUMN FILE_NAME FORMAT A45
SQL>
SQL> SELECT p.PDB_ID, p.PDB_NAME, d.FILE_ID, d.TABLESPACE_NAME, d.FILE_NAME
      FROM DBA_PDBS p, CDB_DATA_FILES d
     WHERE p.PDB_ID = d.CON_ID
     ORDER BY p.PDB_ID;
 
  PDB_ID PDB_NAME     FILE_ID TABLESPACE_NAME   FILE_NAME                              
       3 PDB1               9 SYSTEM            /u02/oradata/O19C/pdb1/system01.dbf    
       3 PDB1              10 SYSAUX            /u02/oradata/O19C/pdb1/sysaux01.dbf    
       3 PDB1              11 UNDOTBS1          /u02/oradata/O19C/pdb1/undotbs01.dbf  
       3 PDB1              12 USERS             /u02/oradata/O19C/pdb1/users01.dbf

혹은 다음과 같이 확인해 볼 수 있다.

컨테이너 데이터 파일 보기
PgSQL
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
SQL> SELECT c.name DB_NAME, a.name TABLESPACE_NAME, b.name DATA_FILE_NAME, b.bytes/1024/1024 SIZE_MB, b.status
     -- c.name DB_NAME, a.con_id, a.ts#, a.name TABLESPACE_NAME, b.name DATA_FILE_NAME, b.file#, b.blocks, b.bytes/1024/1024 SIZE_MB, b.status, b.enabled, b.creation_time
     FROM v$tablespace a, v$datafile b, v$containers c
     WHERE a.con_id = b.con_id
     AND a.con_id = c.con_id
     AND a.ts# = b.ts#
     ORDER BY a.con_id, a.TS#;
 
DB_NAME    TABLESPACE_NAME   DATA_FILE_NAME                              SIZE_MB STATUS  
CDB$ROOT   SYSTEM            /u02/oradata/O19C/system01.dbf                  910 SYSTEM  
CDB$ROOT   SYSAUX            /u02/oradata/O19C/sysaux01.dbf                  580 ONLINE  
CDB$ROOT   UNDOTBS1          /u02/oradata/O19C/undotbs01.dbf                 330 ONLINE  
CDB$ROOT   USERS             /u02/oradata/O19C/users01.dbf                     5 ONLINE  
PDB$SEED   SYSTEM            /u02/oradata/O19C/pdbseed/system01.dbf          270 SYSTEM  
PDB$SEED   SYSAUX            /u02/oradata/O19C/pdbseed/sysaux01.dbf          330 ONLINE  
PDB$SEED   UNDOTBS1          /u02/oradata/O19C/pdbseed/undotbs01.dbf         100 ONLINE  
PDB1       SYSTEM            /u02/oradata/O19C/pdb1/system01.dbf             280 SYSTEM  
PDB1       SYSAUX            /u02/oradata/O19C/pdb1/sysaux01.dbf             350 ONLINE  
PDB1       UNDOTBS1          /u02/oradata/O19C/pdb1/undotbs01.dbf            100 ONLINE  
PDB1       USERS             /u02/oradata/O19C/pdb1/users01.dbf                5 ONLINE  
 
 
11 rows selected.

CDB 에 임시 파일들 보기

CDB_TEMP_FILES 뷰를 활용하면 CDB 에 각 임시 파일 이름과 위치를 확인할 수 있다.

CDB 에 임시 파일들 보기
PgSQL
1
2
3
4
5
6
7
8
9
10
11
SQL> COLUMN CON_ID FORMAT 999
SQL> COLUMN FILE_ID FORMAT 9999
SQL> COLUMN TABLESPACE_NAME FORMAT A15
SQL> COLUMN FILE_NAME FORMAT A45
SQL>
SQL> SELECT CON_ID, FILE_ID, TABLESPACE_NAME, FILE_NAME
      FROM CDB_TEMP_FILES
      ORDER BY CON_ID;
 
  CON_ID   FILE_ID TABLESPACE_NAME   FILE_NAME                          
       3         3 TEMP              /u02/oradata/O19C/pdb1/temp01.dbf

컨트롤 파일 확인

다음과 같이 컨트롤 파일들을 확인할 수 있다.

컨트롤 파일 확인
PgSQL
1
2
3
4
SQL> show parameter control_files;
NAME          TYPE   VALUE                                                            
------------- ------ ----------------------------------------------------------------
control_files string /u02/oradata/O19C/control01.ctl, /u02/oradata/O19C/control02.ctl

Redo Log 파일 확인

다음과 같이 RedoLog 파일을 확인할 수 있다.

Redo Log 파일 확인
PgSQL
1
2
3
4
5
6
7
8
SQL> col member for a50;
SQL> SELECT a.group#, a.members, a.bytes/1024/1024 SIZE_MB, a.status, b.member
  2   FROM v$log a, v$logfile b
  3   WHERE a.group# = b.group#;
  GROUP#   MEMBERS   SIZE_MB STATUS     MEMBER                        
       3         1        50 CURRENT    /u02/oradata/O19C/redo03.log  
       2         1        50 INACTIVE   /u02/oradata/O19C/redo02.log  
       1         1        50 INACTIVE   /u02/oradata/O19C/redo01.log

PDB에 연결된 서비스 보기

CDB_SERVICES 뷰를 통해서 PDB 이름, 네트워크 이름, 컨테이너 ID 등을 확인해 볼 수 있다.

PDB에 연결된 서비스 보기
PgSQL
1
2
3
4
5
6
7
8
9
10
11
SQL> COLUMN NETWORK_NAME FORMAT A30
SQL> COLUMN PDB FORMAT A15
SQL> COLUMN CON_ID FORMAT 999
SQL>
SQL> SELECT PDB, NETWORK_NAME, CON_ID FROM CDB_SERVICES
      WHERE PDB IS NOT NULL AND
            CON_ID > 2
      ORDER BY PDB;
 
PDB    NETWORK_NAME     CON_ID
PDB1   PDB1                  3

PDB 의 히스토리 보기

CDB_PDB_HISTORY 뷰는 PDB의 생성된 시간과 여러 히스토리 정보들을 보여준다.

PDB 의 히스토리 보기
PgSQL
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
SQL> COLUMN DB_NAME FORMAT A10
SQL> COLUMN CON_ID FORMAT 999
SQL> COLUMN PDB_NAME FORMAT A15
SQL> COLUMN OPERATION FORMAT A16
SQL> COLUMN OP_TIMESTAMP FORMAT A10
SQL> COLUMN CLONED_FROM_PDB_NAME FORMAT A15
SQL>  
SQL> SELECT DB_NAME, CON_ID, PDB_NAME, OPERATION, OP_TIMESTAMP, CLONED_FROM_PDB_NAME
      FROM CDB_PDB_HISTORY
      WHERE CON_ID > 2
      ORDER BY CON_ID;
 
DB_NAME      CON_ID PDB_NAME   OPERATION   OP_TIMESTAMP   CLONED_FROM_PDB_NAME  
SEEDDATA          3 PDB$SEED   UNPLUG      17-APR-19                            
O19C              3 PDB$SEED   PLUG        30-APR-21      PDB$SEED              
O19C              3 PDB1       CREATE      30-APR-21      PDB$SEED

오라클 데이터베이스 19c 샘플 스키마 생성

오라클 데이터베이스 19c 를 Silent 설치를 할 경우에 대부분 데이터베이스를 생성하고 끝나게 된다. 하지만 오라클은 샘플 스키마를 제공하고 있는데, HR 관련 된 내용의 샘플 스키마를 제공 한다. 이것을 설치해보자.

SQLcl 활용

SQL Plus 에 기능을 더한 SQLcl 를 활용할 것이다. SQLcl 은 $ORACLE_HOME/sqldeveloper/sqldeveloper/bin 디렉토리가 있다. 여기에 sql 스크립트가 존재하는데 이것이 SQLcl 이다.

SQLcl 사용하기
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
]$ cd $ORACLE_HOME
]$ cd sqldeveloper/sqldeveloper/bin
]$ chmod +x sql
]$ ./sql
 
SQLcl: Release 19.1 Production on Fri Apr 30 23:23:46 2021
 
Copyright (c) 1982, 2021, Oracle.  All rights reserved.
 
Username? (''?) sys as sysdba
Password? (**********?) ************
Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.3.0.0.0
 
SQL> set sqlformat ansiconsole;
SQL>

“set sqlformat ansiconsole” 를 할 경우에 결과를 보다 보기 좋게 해준다.

PDB 로 세션 변경

오라클 데이터베이스 19c 의 경우에 CDB, PDB 개념이 존재한다. 실제 사용자 데이터베이스는 PDB 에 생성된다. 세션을 PDB 로 변경해준다.

PDB 이름 확인
PgSQL
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
SQL> select name, open_mode, restricted from v$pdbs;
NAME       OPEN_MODE    RESTRICTED  
PDB$SEED   READ ONLY    NO          
PDB1       READ WRITE   NO
 
SQL> alter session set container = pdb1;
 
Session altered.
 
SQL> select dbid, con_id, name from v$pdbs;
        DBID   CON_ID NAME  
  2824454508        3 PDB1
 
SQL> show pdbs;
  CON_ID CON_NAME   OPEN MODE    RESTRICTED  
       3 PDB1       READ WRITE   NO

HR 스키마 설치

HR 스키마는 오라클 데이터베이스에 있다. 경로는 다음과 같다.

HR 스키마 경로
ZSH
1
2
]$ ls $ORACLE_HOME/demo/schema/human_resources
hr_analz.sql  hr_code.sql  hr_comnt.sql  hr_cre.sql  hr_drop_new.sql  hr_drop.sql  hr_idx.sql  hr_main_new.sql  hr_main.sql  hr_popul.sql

hr_main.sql 를 실행하면 설치가 진행되는데, 사용자들로부터 다음과 같은 값을 입력 받는다.

  • HR 스키마 사용자의 패스워드
  • HR 스키마에 기본 테이블스페이스
  • HR 를 위한 임시 테이블스페이스
  • 로그 경로

기본 테이블스페이스, 임시 테이블스페이스를 만들어도 되지만 pdb1 에 있는 것을 가져다 써도 된다. 테이블스페이스 이름을 알아야 한다.

pdb1 의 테이블스페이스 이름
ZSH
1
2
3
4
5
6
7
SQL> select tablespace_name from user_tablespaces;
TABLESPACE_NAME  
SYSTEM            
SYSAUX            
UNDOTBS1          
TEMP              
USERS

USERS 는 기본 테이블스페이스, TEMP 를 임시 테이블스페이스로 사용하면 될 듯 하다. 이제 설치를 해보자.

HR 스키마 설치
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
SQL> @/u01/app/oracle/product/19.3.0/dbhome_1/demo/schema/human_resources/hr_main.sql
 
specify password for HR as parameter 1:
Enter value for 1: HrPassword1
 
specify default tablespeace for HR as parameter 2:
Enter value for 2: USERS
 
specify temporary tablespace for HR as parameter 3:
Enter value for 3: TEMP
 
specify log path as parameter 4:
Enter value for 4: /u01/app/oracle/product/19.3.0/dbhome_1/demo/schema/log

log 경로는 demo/schema 디렉토리에 log 디렉토리를 활용했다.

hr 계정 패스워드 설정 및 UNLOCK

계정을 생성하면 기본적으로 계정은 LOCKED 상태가 되어서 사용할 수 없다. UNLOCK 을 해줘야 한다.

HR 계정 UNLOCK
PgSQL
1
2
SQL> ALTER USER hr ACCOUNT UNLOCK;
SQL> ALTER USER hr IDENTIFIED BY HrPassword1;

Oracle Database 19c 설치

오라클 데이터베이스 19c (Oracle Database 19c) 설치에 대한 문서다. 설치는 Slient Mode 로 설치되었으면 PDB 를 기반으로 하였다. PDB, CDB 에 대한 설명은 오라클 문서를 참고.

환경

  • Oracle Linux 8.3
  • Kernel: 5.4.17-2102.200.13.el8uek.x86_64
  • Memory: 7.7Gib
  • Swap: 12Gi
  • Root Partition: 32GB

호스트 네임 변경

호스트 네임 변경
ZSH
1
2
3
]# hostnamectl set-hostname oradb1.systemv.local
]# vim /etc/hosts
192.168.96.29   oradb1.systemv.local    oradb1

Selinux 를 Permissive 로 변경

Selinux 비활성화
ZSH
1
2
]# setenforce Permissive
]# sed -i 's/^SELINUX=enforcing$/SELINUX=Permissive/' /etc/selinux/config

HugePages 비활성화.

오라클은 HugePages 를 비활성화할 것을 권장하고 있다.

Selinux 비활성화
ZSH
1
2
3
4
5
6
]# cat /sys/kernel/mm/transparent_hugepage/enabled
[always] madvise never
]# vim /etc/default/grub
- GRUB_CMDLINE_LINUX="crashkernel=auto resume=UUID=e17bf72e-de7f-49a6-9d37-4c61864a4ba3"
+ GRUB_CMDLINE_LINUX="crashkernel=auto resume=UUID=e17bf72e-de7f-49a6-9d37-4c61864a4ba3 transparent_hugepage=never"
]# systemctl reboot

PreInstallation RPM 설치

오라클은 시스템 계정, 설치 디렉토리, 시스템 리소스 설정등을 필요로 하는데 PreInstallation RPM 은 이것을 자동으로 해준다.

PreInstallation RPM 설치
ZSH
1
]# dnf install oracle-database-preinstall-19c

이것은 자동으로 필요로하는 시스템 설정을 해준다. 이것을 하고 난후에 변경된 시스템 설정들은 다음과 같다.

시스템 그룹 생성

다음과 같은 시스템 그룹이 생성되었다.

오라클 데이터베이스 19c 를 위한 시스템 그룹 생성
ZSH
1
2
3
4
5
6
7
]# groupadd -g 54321 oinstall
]# groupadd -g 54322 dba
]# groupadd -g 54323 oper
]# groupadd -g 54324 backupdba
]# groupadd -g 54325 dgdba
]# groupadd -g 54326 kmdba
]# groupadd -g 54330 racdba

oracle 계정 생성 및 소속 그룹 변경

oracle 계정이 생성되는데 기본 소속 그룹은 oinstall 이며 dba,oper,backupdba,dgdba,kmdba,racdba 그룹에도 속해야 한다.

오라클 데이터베이스 19c 를 위한 시스템 계정 생성
ZSH
1
2
3
4
]# useradd -u 54321 -g oinstall -G dba,oper,backupdba,dgdba,kmdba,racdba oracle
]# echo "oracle" | passwd oracle --stdin
Changing password for user oracle.
passwd: all authentication tokens updated successfully.

oracle 시스템 계정에 대한 시스템 자원 제한 설정.

파일, 메모리, 프로세스 등에 대한 자원 사용에 대해서 oracle 계정에 제한을 둔다. 이것은 /etc/security/limits.d 디렉토리에 파일을 생성해 설정한다.

오라클 데이터베이스 19c 에 oracle 시스템 계정 자원 제한 설정
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
]# vim /etc/security/limits.d/oracle-database-19c.conf
# oracle database 19c setting for nofile soft limit is 1024
oracle   soft   nofile    1024
 
# oracle database 19c setting for nofile hard limit is 65536
oracle   hard   nofile    65536
 
# oracle database 19c setting for nproc soft limit is 16384
# refer orabug15971421 for more info.
oracle   soft   nproc    16384
 
# oracle database 19c setting for nproc hard limit is 16384
oracle   hard   nproc    16384
 
# oracle database 19c setting for stack soft limit is 10240KB
oracle   soft   stack    10240
 
# oracle database 19c setting for stack hard limit is 32768KB
oracle   hard   stack    32768
 
# oracle database 19c setting for memlock hard limit is maximum of 128GB on x86_64 or 3GB on x86 OR 90 % of RAM
oracle   hard   memlock    134217728
 
# oracle database 19c setting for memlock soft limit is maximum of 128GB on x86_64 or 3GB on x86 OR 90% of RAM
oracle   soft   memlock    134217728
 
# oracle database 19c setting for data soft limit is 'unlimited'
oracle   soft   data    unlimited
 
# oracle database 19c setting for data hard limit is 'unlimited'
oracle   hard   data    unlimited

memlock 부분을 조정해 줄 필요가 있다. 전체 물리 메모리가 128GB 이하라면 약 90%를 할당을 권장하고 있다.

커널 파라메터 수정.

커널 파라메터는 sysctl 명령어로 조정이 되는데, 이것은 /etc/sysctl.d 디렉토리에 파일을 생성해 적용해 준다.

오라클 데이터베이스 19c 에 커널 파라메터 수정
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
]# vim /etc/systctl.d/97-oracle-database-19c.conf
# sysctl settings are defined through files in
# /usr/lib/sysctl.d/, /run/sysctl.d/, and /etc/sysctl.d/.
#
# Vendors settings live in /usr/lib/sysctl.d/.
# To override a whole file, create a new file with the same in
# /etc/sysctl.d/ and put new settings there. To override
# only specific settings, add a file with a lexically later
# name in /etc/sysctl.d/ and put new settings there.
#
# For more information, see sysctl.conf(5) and sysctl.d(5).
 
# oracle database 19c setting for fs.file-max is 6815744
fs.file-max = 6815744
 
# oracle database 19c setting for kernel.sem is '250 32000 100 128'
kernel.sem = 250 32000 100 128
 
# oracle database 19c setting for kernel.shmmni is 4096
kernel.shmmni = 4096
 
# oracle database 19c setting for kernel.shmall is 1073741824 on x86_64
kernel.shmall = 1073741824
 
# oracle database 19c setting for kernel.shmmax is 4398046511104 on x86_64
kernel.shmmax = 4398046511104
 
# oracle database 19c setting for kernel.panic_on_oops is 1 per Orabug 19212317
kernel.panic_on_oops = 1
 
# oracle database 19c setting for net.core.rmem_default is 262144
net.core.rmem_default = 262144
 
# oracle database 19c setting for net.core.rmem_max is 4194304
net.core.rmem_max = 4194304
 
# oracle database 19c setting for net.core.wmem_default is 262144
net.core.wmem_default = 262144
 
# oracle database 19c setting for net.core.wmem_max is 1048576
net.core.wmem_max = 1048576
 
# oracle database 19c setting for net.ipv4.conf.all.rp_filter is 2
net.ipv4.conf.all.rp_filter = 2
 
# oracle database 19c setting for net.ipv4.conf.default.rp_filter is 2
net.ipv4.conf.default.rp_filter = 2
 
# oracle database 19c setting for fs.aio-max-nr is 1048576
fs.aio-max-nr = 1048576
 
# oracle database 19c setting for net.ipv4.ip_local_port_range is 9000 65500
net.ipv4.ip_local_port_range = 9000 6550
]# sysctl --system

Firewalld 설정

Oracle SQL* NET Listener 포트인 1521/tcp 를 열어준다.

Oracle SQL* NET Listener 를 위한 firewalld 설정
ZSH
1
2
3
4
]# firewall-cmd --permanent --add-port=1521/tcp
success
]# firewall-cmd --reload
success

Oracle Universal Installer (OUI)

OUI 설치는 터미널에 명령행으로 설치를 진행할 수 있도록 해준다. 이를 위해서 필요한 작업이 있다.

디렉토리 생성

다음과 같이 디렉토리를 생성해 준다.

설치를 위한 디렉토리 생성
ZSH
1
2
3
4
5
6
7
8
]# mkdir -p /u01/app/oracle/product/19.3.0/dbhome_1
]# mkdir -p /u01/app/oraInventory
]# mkdir -p /u02/oradata
]#
]# mkdir -p /u01/software
]#
]# chown -R oracle:oinstall /u01 /u02
]# chmod -R 775 /u01 /u02

/u01/software 는 Oracle database 19c 설치파일들을 압축해제해 넣을 디렉토리다.

.bashrc 파일 설정

설치를 하기 위해서 환경변수를 설정해 준다. 이것은 oracle 계정에 .bashrc 파일에 해주면 된다.

oracle 계정에 .bashrc 파일
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# Oracle Settings
export TMP=/tmp
export TMPDIR=$TMP
 
export ORACLE_HOSTNAME=oradb1.systemv.local
export ORACLE_UNQNAME=o19c
export ORACLE_BASE=/u01/app/oracle
export ORACLE_HOME=$ORACLE_BASE/product/19.3.0/dbhome_1
export ORA_INVENTORY=/u01/app/oraInventory
export ORACLE_SID=o19c
export PDB_NAME=pdb1
export DATA_DIR=/u02/oradata
 
export PATH=$ORACLE_HOME/bin:$PATH
 
export LD_LIBRARY_PATH=$ORACLE_HOME/lib:/lib:/usr/lib
export CLASSPATH=$ORACLE_HOME/jlib:$ORACLE_HOME/rdbms/jlib

설치

이제 설치를 진행 해준다.

먼저, 오라클 데이터베이스 19c 에 설치 프로그램을 압축 해제해 준다.

oracle 계정으로 설치 프로그램 압축해제
ZSH
1
2
3
4
5
6
]$ export SOFTWARE_DIR=/u01/software
]$ export DB_SOFTWARE=LINUX.X64_193000_db_home.zip
]$ # Unzip the media
]$ mkdir -p ${ORACLE_HOME}
]$ cd ${ORACLE_HOME}
]$ unzip -oq ${SOFTWARE_DIR}/${DB_SOFTWARE}

이제 Silent 설치를 위한 쉘 스크립트 파일을 작성해 준다.

oracle 설치를 위한 쉘 스크립트 작성
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
]# vim ora_19c_install.sh
#!/bin/bash
  
source $HOME/.bashrc
 
export CV_ASSUME_DISTID=RHEL8.0
 
${ORACLE_HOME}/runInstaller \
-ignorePrereq -waitforcompletion -showProgress -silent \
-responseFile ${ORACLE_HOME}/install/response/db_install.rsp \
oracle.install.option=INSTALL_DB_SWONLY \
UNIX_GROUP_NAME=oinstall \
ORACLE_HOSTNAME=${ORACLE_HOSTNAME} \
UNIX_GROUP_NAME=oinstall \
INVENTORY_LOCATION=${ORA_INVENTORY} \
SELECTED_LANGUAGES=en \
ORACLE_HOME=${ORACLE_HOME} \
ORACLE_BASE=${ORACLE_BASE} \
oracle.install.db.InstallEdition=EE \
oracle.install.db.OSDBA_GROUP=dba \
oracle.install.db.OSBACKUPDBA_GROUP=dba \
oracle.install.db.OSDGDBA_GROUP=dba \
oracle.install.db.OSKMDBA_GROUP=dba \
oracle.install.db.OSRACDBA_GROUP=dba \
SECURITY_UPDATES_VIA_MYORACLESUPPORT=false \
DECLINE_SECURITY_UPDATES=true
]# chmod +x ora_19c_install.sh

“export CV_ASSUME_DISTID=RHEL8.0” 는 설치 오류를 피하기 위한 것이다. 이제 실행해준다.

oracle 설치 쉘 스크립트 실행
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
]# ./ora_19c_install.sh
Launching Oracle Database Setup Wizard...
 
The response file for this session can be found at:
/u01/app/oracle/product/19.3.0/dbhome_1/install/response/db_2021-04-30_00-53-34AM.rsp
 
You can find the log of this install session at:
/tmp/InstallActions2021-04-30_00-53-34AM/installActions2021-04-30_00-53-34AM.log
 
 
As a root user, execute the following script(s):
        1. /u01/app/oraInventory/orainstRoot.sh
        2. /u01/app/oracle/product/19.3.0/dbhome_1/root.sh
 
Execute /u01/app/oraInventory/orainstRoot.sh on the following nodes:
[oradb1]
Execute /u01/app/oracle/product/19.3.0/dbhome_1/root.sh on the following nodes:
[oradb1]
 
 
Successfully Setup Software.
Moved the install session logs to:
/u01/app/oraInventory/logs/InstallActions2021-04-30_00-53-34AM

출력 결과 안내대로 실행해 준다.

oracle 설치 후 쉘 스크립트 실행
ZSH
1
2
3
4
5
6
7
8
9
]# /u01/app/oraInventory/orainstRoot.sh
Changing permissions of /u01/app/oraInventory.
Adding read,write permissions for group.
Removing read,write,execute permissions for world.
 
Changing groupname of /u01/app/oraInventory to oinstall.
The execution of the script is complete.
]# /u01/app/oracle/product/19.3.0/dbhome_1/root.sh
Check /u01/app/oracle/product/19.3.0/dbhome_1/install/root_oradb1.systemv.local_2021-04-30_00-59-09-117429191.log for the output of root script

멀티테넌트 데이터베이스 생성하기

오라클 12c 로 넘어오면서 CDB, PDB 라는 개념을 도입했는데 이것이 멀티테넌트 데이터베이스 개념이라 간략히 말할 수 있다. 먼저 데이터베이스를 설치하기 위해서는 오라클 리스너(Oracle Listener) 를 실행 시켜준다.

오라클 리스너 시작
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
$ lsnrctl start
LSNRCTL for Linux: Version 19.0.0.0.0 - Production on 30-APR-2021 01:25:23
 
Copyright (c) 1991, 2019, Oracle.  All rights reserved.
 
Starting /u01/app/oracle/product/19.3.0/dbhome_1/bin/tnslsnr: please wait...
 
TNSLSNR for Linux: Version 19.0.0.0.0 - Production
Log messages written to /u01/app/oracle/diag/tnslsnr/oradb1/listener/alert/log.xml
Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=oradb1.systemv.local)(PORT=1521)))
 
Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521))
STATUS of the LISTENER
------------------------
Alias                     LISTENER
Version                   TNSLSNR for Linux: Version 19.0.0.0.0 - Production
Start Date                30-APR-2021 01:25:27
Uptime                    0 days 0 hr. 0 min. 4 sec
Trace Level               off
Security                  ON: Local OS Authentication
SNMP                      OFF
Listener Log File         /u01/app/oracle/diag/tnslsnr/oradb1/listener/alert/log.xml
Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=oradb1.systemv.local)(PORT=1521)))
The listener supports no services
The command completed successfully

이제 멀티테넌트 데이터베이스를 생성해 준다.

멀티테넌트 데이터베이스 생성
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
$ dbca -silent -createDatabase \
> -templateName General_Purpose.dbc \
> -gdbname ${ORACLE_SID} -sid  ${ORACLE_SID} \
> -responseFile NO_VALUE \
> -characterSet AL32UTF8 \
> -sysPassword SysPassword1 \
> -systemPassword SysPassword1 \
> -createAsContainerDatabase true \
> -numberOfPDBs 1 \
> -pdbName ${PDB_NAME} \
> -pdbAdminPassword PdbPassword1 \
> -databaseType MULTIPURPOSE \
> -automaticMemoryManagement false \
> -totalMemory 4000 \
> -storageType FS \
> -datafileDestination "${DATA_DIR}" \
> -redoLogFileSize 50 \
> -emConfiguration NONE \
> -ignorePreReqs
Prepare for db operation
8% complete
Copying database files
31% complete
Creating and starting Oracle instance
32% complete
36% complete
40% complete
43% complete
46% complete
Completing Database Creation
51% complete
53% complete
54% complete
Creating Pluggable Databases
58% complete
77% complete
Executing Post Configuration Actions
100% complete
Database creation complete. For details check the logfiles at:
/u01/app/oracle/cfgtoollogs/dbca/o19c.
Database Information:
Global Database Name:o19c
System Identifier(SID):o19c
Look at the log file "/u01/app/oracle/cfgtoollogs/dbca/o19c/o19c.log" for further details.

이렇게하면 하나의 CDB, PDB 가 생성된다. CDB 의 이름은 O19C, PDB 의 이름은 pdb1 이다.

멀티테넌트 데이터베이스 디렉토리
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
]$ pwd
/u02/oradata/O19C
[oracle@oradb1 O19C]$ ls -lh
total 1.9G
-rw-r-----. 1 oracle oinstall  18M Apr 30 02:01 control01.ctl
-rw-r-----. 1 oracle oinstall  18M Apr 30 02:01 control02.ctl
drwxr-x---. 2 oracle oinstall  104 Apr 30 01:56 pdb1
drwxr-x---. 2 oracle oinstall  111 Apr 30 01:41 pdbseed
-rw-r-----. 1 oracle oinstall  51M Apr 30 02:01 redo01.log
-rw-r-----. 1 oracle oinstall  51M Apr 30 01:56 redo02.log
-rw-r-----. 1 oracle oinstall  51M Apr 30 01:56 redo03.log
-rw-r-----. 1 oracle oinstall 511M Apr 30 02:01 sysaux01.dbf
-rw-r-----. 1 oracle oinstall 901M Apr 30 02:01 system01.dbf
-rw-r-----. 1 oracle oinstall  33M Apr 30 01:45 temp01.dbf
-rw-r-----. 1 oracle oinstall 331M Apr 30 02:01 undotbs01.dbf
-rw-r-----. 1 oracle oinstall 5.1M Apr 30 01:56 users01.dbf

필요한 데이터 파일들이 CDB 디렉토리 아래에 모두 자동으로 생성 되었다. 수동으로 생성할 수도 있는데, 이것은 추후 논의 한다.

루트(root) 사용자로 oratab 설정을 변경해 준다. 이것은 오라클 데이터베이스를 자동 시작을 활성화 해준다.

오라클 데이터베이스 자동 시작 활성화
ZSH
1
]# sed -i 's/:N$/:Y/g' /etc/oratab

이제 SQL Shell 을 실행하고 Oracle Managed File 를 활성화, CDB 시작시 PDB도 자동시작 활성화를 해준다.

SQL Shell 실행 후 명령어 실행
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
]$ sqlplus / as sysdba
 
SQL*Plus: Release 19.0.0.0.0 - Production on Fri Apr 30 02:08:18 2021
Version 19.3.0.0.0
 
Copyright (c) 1982, 2019, Oracle.  All rights reserved.
 
 
Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.3.0.0.0
 
SQL> ALTER SYSTEM SET DB_CREATE_FILE_DEST='/u02/oradata' SCOPE=BOTH;
 
System altered.
 
SQL> ALTER PLUGGABLE DATABASE pdb1 SAVE STATE;
 
Pluggable database altered.
 
SQL>

시작/중지.

오라클 데이터베이스 시작/중지는 다음과 같다.

오라클 데이터베이스 systemd 유닛 등록
ZSH
1
2
]$ /u01/app/oracle/product/19.3.0/dbhome_1/bin/dbstart /u01/app/oracle/product/19.3.0/dbhome_1 # 시작
]$ /u01/app/oracle/product/19.3.0/dbhome_1/bin/dbshut /u01/app/oracle/product/19.3.0/dbhome_1 # 중지