StatefulSet 에서 로컬 디스크 사용

이 문서는 StatefulSet 에서 로컬 디스크 사용 에 대한 글이다. Kubernetes 에서 디스크 사용은 어려운감이 있다. PersistentVolume 과 PersistentVolumeClaim 이라는 것을 알아야하고 이를 알고나서도 여러가지 속성들때문에 헷깔리는 경우가 많다.

PersistentVolume 관련해서 문서를 보면 대부분 클라우드가 제공하는 스토리지를 이용하는 예제가 많다. 그것이 아니라면 nfs 를 이용하는 경우가 많아서 나처럼 집에 컴퓨터를 이용하는 경우에 실습해 보기가 쉽지 않은게 사실이다.

StatefulSet 의 경우가 바로 이런 경우였다. StatefulSet 을 연구하기 위해서 여러가지 예제를 찾아봤고 다음과 같은 파일을 찾아냈다.

StatefulSet 생성을 위한 yaml 파일 내용
YAML
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
---
apiVersion: v1
kind: Service
metadata:
  name: nginx
  namespace: perf-poc
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
  namespace: perf-poc
spec:
  selector:
    matchLabels:
      app: nginx
  serviceName: "nginx"
  replicas: 2
  template:
    metadata:
      labels:
        app: nginx
    spec:
      terminationGracePeriodSeconds: 10
      containers:
      - name: nginx
        image: k8s.gcr.io/nginx-slim:0.8
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
      nodeSelector:
        kubernetes.io/hostname: knode
  volumeClaimTemplates:
  - metadata:
      name: www
      namespace: perf-poc
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 1Gi

StatefulSet 은 비상태(stateless) 자원을 생성하는게 아니라 상태를 가지는 자원을 생성하게 해주는 Kubernetes 의 객체다. 대부분 Persistent Data 를 위한 것이기에 PersistentVolume 을 대부분 필요로 한다.

위 예제를 가지고 생성을 해보자.

Kuberentes 객체 생성
ZSH
1
2
3
]$ kubectl apply -f web.yaml
service/nginx created
statefulset.apps/web created

정상적으로 생성이 됐다고 나온다. 확인을 해보자.

Kuberentes 객체 생성 확인
ZSH
1
2
3
4
5
6
7
8
9
10
]$ kubectl get po,svc,sts
NAME        READY   STATUS    RESTARTS   AGE
pod/web-0   0/1     Pending   0          2m7s
 
NAME                 TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
service/kubernetes   ClusterIP   10.96.0.1    <none>        443/TCP   14d
service/nginx        ClusterIP   None         <none>        80/TCP    2m7s
 
NAME                   READY   AGE
statefulset.apps/web   0/2     2m7s

Pod 생성이 Pending 상태를 보이고 있다. 왜 이럴까? 앞에서 객체 생성을 정의한 yaml 파일을 자세히 보면 Persistent Volume 을 요청하고 있다. volumeClaimTemplates 이 바로 그것이다. 이것은 PersistentVolumeClaim 을 요청하는 것으로 나타난다. 확인해 보자.

PersistentVolumeClaim 확인
ZSH
1
2
3
]$ kubectl get po,pvc
NAME                              STATUS    VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE
persistentvolumeclaim/www-web-0   Pending                                                     5m29s

persistentvolumeclaim 이 Pending 상태이다. 결국에는 이것으로 인해서 Pod 생성도 Pending 이 된 것이다.

해결방안

PersistentVolumeClaim 은 PersistentVolume 이 있어야 한다. 그리고 이것을 묶어줘야하는데 이것을 Bound 라고 한다. 문제는 web.yaml 을 실행했을때에 생성되는 PersistentVolumeClaim 과 PersistentVolume 을 어떻게 연결할 것인가?

좀더 정확하게 말하면 StatefulSet 이 자동으로 생성하는 PersistentVolumeClaim 과 PersistentVolume 을 어떻게 연결할 것인가?

StatefulSet 의 특징은 생성하는 객체의 이름이 임의대로 정해지지 않는다. 정확하게 사람이 인식하기 쉬운 이름으로 결정된다. 앞에서보면 Pod 의 이름이 web-0 이다. 이는 Pod 이름에 Replicas 의 첫번째인 0 을 붙여서 만든다.

StatefulSet 에서 PersistentVolumeClaim 이름은 예측 가능한 패턴을 따른다. volumeclaimtemplates-name–statefulset-name–replica-index. 그래서 생성된 PersistentVolumeClaim 의 이름이 www-web-0 가 된 것이다.

PersistentVolumeClaim 은 PersistentVolume 을 필요로 한다. PersistentVolume 을 생성할때에 claimRef.name 을 PersistentVolumeClaim 이름으로 지정한다. 이렇게 하면 PersistentVolumeClaim 이 생성될때에 PersistentVolume 이 이름과 연결되어 자동으로 Bound 되어진다. 다음과 같이 PersistentVolume 을 만든다.

PersistentVolume 생성
YAML
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
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-statefulset-demo-0
  namespace: perf-poc
spec:
  storageClassName: "example-storageclass"
  capacity:
    storage: 2Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  claimRef:
    namespace: perf-poc
    name: www-web-0
  persistentVolumeReclaimPolicy: Delete
  hostPath:
    path: /tmp/k8s-pv-statefulset-demo
    type: DirectoryOrCreate
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: "kubernetes.io/hostname"
          operator: "In"
          values:
          - knode

이것은 Kubernetes Worker 호스트에 파일시스템에 특정 디렉토리를 PersistentVolume 으로 생성한다. 만일 디렉토리가 존재하지 않을 경우에는 생성하도록 한다. 그리고 PersistentVolumeClaim 이 삭제되면 이 볼륨도 함께 삭제되도록 했다.

여기서 중요한 것이 claimRef 필드이다. name 속성에 PersistentVolumeClaim 이름을 지정해준다.

또, nodeAffinity 필드를 이용해서 특정한 Worker 에서 생성되도록 했다.

StatefulSet 에서 replicas 를 2 로 했기 때문에 위 PersistentVolume 생성은 claimRef.name 이 www-web-0, www-web-1 로 두개가 필요하다.

두개의 PersistentVolume 을 생성하고 시간을 갖고 기다리면 다음과 같은 결과를 얻게 된다.

객체 확인
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
]$ kubectl get po,pv,pvc
NAME        READY   STATUS    RESTARTS   AGE
pod/web-0   1/1     Running   0          21m
pod/web-1   1/1     Running   0          33s
 
NAME                                     CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM               STORAGECLASS           REASON   AGE
persistentvolume/pv-statefulset-demo-0   2Gi        RWO            Delete           Bound    default/www-web-0   example-storageclass            57s
persistentvolume/pv-statefulset-demo-1   2Gi        RWO            Delete           Bound    default/www-web-1   example-storageclass            23s
 
NAME                              STATUS   VOLUME                  CAPACITY   ACCESS MODES   STORAGECLASS   AGE
persistentvolumeclaim/www-web-0   Bound    pv-statefulset-demo-0   2Gi        RWO                           21m
persistentvolumeclaim/www-web-1   Bound    pv-statefulset-demo-1   2Gi        RWO                           33s

Worker 호스트에 PersistentVolume 에서 생성한 디렉토리가 있는지 확인해 보자.

PersistentVolume 이 생성한 디렉토리 확인
ZSH
1
2
3
4
$ ls -lh /tmp/
total 0
drwxr-xr-x 2 root root  6 Aug  8 21:42 k8s-pv-statefulset-demo-0
drwxr-xr-x 2 root root  6 Aug  8 21:44 k8s-pv-statefulset-demo-1

이렇게 문제를 해결할 수 있다.

참고: StatefulSet 에서 기존 디스크 사용

GitLab-Runner 설치

이 문서는 GitLab-Runner 설치 에 대한 것이다. GitLab 은 CI/CD 를 위해 외부 프로그램을 사용하는데, 이것이 바로 GitLab-Runner 이다. 외부 프로그램을 사용하기 때문에 반드시 GitLab 과 함께 있어야 하는것도 아니고 독립적으로 다양한 플랫폼에 설치해도 된다.

설치

설치는 아주 간단하다. 각 배포판, 플랫폼마다 패키지를 제공한다. 나는 Ubuntu 20.04 에 그것도 GitLab 서버에 설치할 예정이다. 다른 서버에 설치를 해도 되지만 테스트 삼아 설치하는 것이여서 이렇게 진행했다.

GitLab-Runner 설치
ZSH
1
2
3
$ sudo apt install git # 의존성 설치
$ curl -LJO https://gitlab-runner-downloads.s3.amazonaws.com/latest/deb/gitlab-runner_amd64.deb
$ sudo dpkg -i gitlab-runner_amd64.deb

이렇게 설치를 하고 나면 /home/gitlab-runner 계정이 생성되며 systemd 에 gitlab-runner 서비스가 등록이되며 자동으로 실행이 된다.

GitLab-Runner 결과
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
$ ls /home/
gitlab-runner
$ systemctl status gitlab-runner
● gitlab-runner.service - GitLab Runner
     Loaded: loaded (/etc/systemd/system/gitlab-runner.service; enabled; vendor preset: enabled)
     Active: active (running) since Sat 2020-08-01 22:49:15 KST; 1min 2s ago
   Main PID: 9245 (gitlab-runner)
      Tasks: 12 (limit: 9487)
     Memory: 5.5M
     CGroup: /system.slice/gitlab-runner.service
             └─9245 /usr/lib/gitlab-runner/gitlab-runner run --working-directory /home/gitlab-runner --config /etc/gitlab-runner/config.toml --service gitlab-runner --syslo>
 
Aug 01 22:49:15 gitlab gitlab-runner[9245]: Running in system-mode.
Aug 01 22:49:15 gitlab gitlab-runner[9245]: Running in system-mode.
Aug 01 22:49:15 gitlab gitlab-runner[9245]:
Aug 01 22:49:15 gitlab gitlab-runner[9245]:
Aug 01 22:49:15 gitlab gitlab-runner[9245]: Configuration loaded                                builds=0
Aug 01 22:49:15 gitlab gitlab-runner[9245]: Configuration loaded                                builds=0
Aug 01 22:49:15 gitlab gitlab-runner[9245]: listen_address not defined, metrics & debug endpoints disabled  builds=0
Aug 01 22:49:15 gitlab gitlab-runner[9245]: listen_address not defined, metrics & debug endpoints disabled  builds=0
Aug 01 22:49:15 gitlab gitlab-runner[9245]: [session_server].listen_address not defined, session endpoints disabled  builds=0
Aug 01 22:49:15 gitlab gitlab-runner[9245]: [session_server].listen_address not defined, session endpoints disabled  builds=0
$ sudo systemctl stop gitlab-runner

우선 gitlab-runner 서비스를 중지를 해준다.

Gitlab 에 등록하기

GitLab-Runner 를 설치했다면 이제 이것을 GitLab 에 등록을 해줘야 한다. 이를 위해서 GitLab 에서 Runner 메뉴를 보고 URL 과 Token 값을 확인 한다.

gitlab-runner 셋업 정보

오른쪽에 보면 URL 과 token 값이 보인다. Gitlab-Runner 를 GitLab 서버에 등록을 해줘야 한다.

GitLab-Runner 등록
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
$ sudo gitlab-runner register
[sudo] password for sbhyun:
Runtime platform                                    arch=amd64 os=linux pid=10804 revision=a998cacd version=13.2.2
Running in system-mode.
 
Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/):
http://gitlab.systemv.local:8001/
Please enter the gitlab-ci token for this runner:
HHjQMREKED4vxoazrDBv
Please enter the gitlab-ci description for this runner:
[gitlab]: For compile java
Please enter the gitlab-ci tags for this runner (comma separated):
java,java runner
Registering runner... succeeded                     runner=HHjQMREK
Please enter the executor: docker, shell, ssh, docker-ssh+machine, docker+machine, kubernetes, custom, docker-ssh, parallels, virtualbox:
shell
Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!

등록할때에 URL, Token 값을 입력해 준다. 그리고 무엇보다 중요한 executor 를 선택해줘야 한다. 나의 경우에 Java 컴파일을 해줘야 하기 때문에 executor 를 shell 로 선택해줬다. 이렇게 설정된 내용은 /etc/gitlab-runner/config.toml 파일에 기록된다.

정상적으로 완료됐다면 서비스를 시작해 준다. 그리고 GitLab 에서 다음과 같이 runner 가 보인다.

등록된 gitlab-runner

여기서 중요한 것이, config.toml 파일을 수동으로 조작한다고 해서 GitLab 서버에 등록이 되지 않는다. 반드시 register 를 이용해야만 등록이 가능하다.

Java 컴파일 환경 구축.

번외로 Java 컴파일 환경을 구축해 보겠다. gitlab-runner 의 프로세스를 보면 다음과 같다.

GitLab-Runner 프로세스
ZSH
1
2
$ ps aux | grep gitlab-runner
root        9245  0.0  0.3 138144 24564 ?        Ssl  22:49   0:02 /usr/lib/gitlab-runner/gitlab-runner run --working-directory /home/gitlab-runner --config /etc/gitlab-runner/config.toml --service gitlab-runner --syslog --user gitlab-runner

위 내용을 보면 working-directory 가 /home/gitlab-runner 이고 사용자가 gitlab-runner 이다. 따라서 /home/gitlab-runner 홈 디렉토리를 기반으로 runner 가 작동된다.

Java 컴파일 환경을 위해 다음의 필요하다.

  • java 1.8 컴파일러
  • maven

이 두가지를 gitlab-runner 계정에 설정을 해줘야 한다.

java 1.8 설정

java 1.8 은 Oracle JDK 가 아닌 오픈 소스인 Zulu JDK 를 사용하기로 했다. 현 시점에서 최신판을 다운로드 한다.

Zulu JDK 1.8 설치
ZSH
1
2
3
$ curl -LJO https://cdn.azul.com/zulu/bin/zulu8.48.0.53-ca-jdk8.0.265-linux_musl_x64.tar.gz
$ tar xvzf zulu8.48.0.53-ca-jdk8.0.265-linux_musl_x64.tar.gz
$ ln -s zulu8.48.0.53-ca-jdk8.0.265-linux_musl_x64 java

gitlab-runner 를 executor 로 작동하도록 했기 때문에 gitlab-runner 의 기본 쉘인 bash 를 기반이다. gitlab-runner 계정에 .bashrc 파일에 java 1.8 환경 변수를 등록해준다. gitlab-runner 는 서비스에 등록되어 동작은 root 계정으로 동작한다. 하지만 gitlab-runner 가 실행될때에 su 명령어로 gitlab-runner 계정으로 전환된다.

문제는 이때에 .bashrc 를 읽어들이지 않는다. 대신에 .profile 을 읽어들이게 된다. 따라서 각종 환경 변수들은 .profile 에 작성해야 한다.

java 1.8 환경변수 등록
ZSH
1
2
3
4
5
6
7
8
9
10
$ vim .profile
export JAVA_HOME=$HOME/java
export JRE_HOME=$HOME/jre
export PATH=$PATH:$JAVA_HOME/bin:$JRE_HOME/bin
export CLASSPATH=.:$JRE_HOME/lib/ext:$JAVA_HOME/lib/tools.jar
$ source .profile
$ java -version
openjdk version "1.8.0_265"
OpenJDK Runtime Environment (Zulu 8.48.0.53-CA-linux-musl-x64) (build 1.8.0_265-b11)
OpenJDK 64-Bit Server VM (Zulu 8.48.0.53-CA-linux-musl-x64) (build 25.265-b11, mixed mode)

maven 설치

maven 을 설치해준다.

Maven 설치
ZSH
1
2
3
$ curl -LJO http://mirror.navercorp.com/apache/maven/maven-3/3.6.3/binaries/apache-maven-3.6.3-bin.tar.gz
$ tar xvzf apache-maven-3.6.3-bin.tar.gz
$ ln -s apache-maven-3.6.3 maven

이제 maven 을 위한 환경 변수를 등록해준다. 역시 .bashrc 파일에 해준다.

Maven 설정
ZSH
1
2
3
4
$ vim .profile
export MAVEN_HOME=$HOME/maven
export PATH=$PATH:$MAVEN_HOME/bin
$ source .profile

그리고 maven 에 setting.xml 파일을 수정해 의존성 패키지들의 저장소를 다음과 같이 바꿔 준다.

Maven 에 setting.xml 수정
ZSH
1
2
3
$ mkdir ~/maven/repository
$ vim setting.xml
<localrepository>${user.home}/maven/repository</localrepository>

이로써 java 컴파일을 위한 gitlab-runner 설정을 완료됐다.

.gitlab-ci.yml 파일

Spring5MVC 프로젝트를 maven 으로 작성했다. Eclipse 를 쓴다면 간단하게 Spring5MVC 를 Maven 프로젝트로 손쉽게 제작할 수 있다. 이런 경우에 .gitlab-ci.yml 파일을 다음과 같이 간단하게 작성할 수 있다.

.gitlab-ci.yml 파일
YAML
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
stages:
  - build
 
build:
  stage: build
  script:
    - mvn clean install
 
  after_script:
    - echo 'build success!'
 
  tags:
    - springmvc-runner
 
  only:
    - master

tags 는 gitlab-runner 에서 지정한 tag 를 말한다. gitlab-ci.yml 에서 gitlab-runner 를 구분하는 방법은 바로 tag 다. 이것은 GitLab 에서 gitlab-runner 를 수정하면서 함께 변경이 가능하다.

only 는 git 브랜치중에서 master 브랜치에 커밋이 발생했을때에 이를 실행하도록 한 것이다. git 는 전략적으로 브랜치를 자주 사용하는데, 전략에 따라서 특정 브랜치에 대해서만 작동하도록 할 수도 있다.

위 파일은 Deploy 는 없어서 단순하게 컴파일하는 것으로 끝난다. 나중에 Deploy 에 대해서 이야기 해보도록 하겠다.

GitLab 설치와 설정

GitLab 설치 하기. GitLab 은 무료로 사용가능한 git 저장소, ticket 시스템이다. github 의 오픈소스 버전으로 생각할 수 있지만 그것보다 많은 기능을 제공한다. 이 글에서는 gitlab 을 Ubuntu 20.04 LTS 에 설치와 설정에 대해서 알아보도록 하겠다.

준비

Gitlab 을 설치하기 전에 필요한 의존성 패키지들을 먼저 설치해 준다.

Gitlab 설치를 위한 의존성 패키지 설치
ZSH
1
]$ sudo apt install -y ca-certificates curl

메일을 사용할 경우에는 메일 서버를 설치해줘야 하지만 여기서는 제외한다.

Gitlab 설치를 위한 저장소 추가

gitlab 홈페이지에서는 각 리눅스 배포판에 맞춰 스크립트를 제공한다. Ubuntu 20.04 를 위해 제공해주는 스크립트를 실행해 준다.

Gitlab 설치를 위한 저장소 추가
ZSH
1
]$ sudo curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash

Gitlab 설치

접속을 위한 도메인을 결정해야 한다. 그리고 gitlab 은 SSL 접속을 권장하지만, 꼭 필요한 것은 아니다. 설치를 할 시점에서 도메인을 정할 수 있다.

Gitlab 설치
ZSH
1
]$ sudo EXTERNAL_URL="http://gitlab.systemv.local" apt-get install gitlab-ce

별문제가 없다면 설치가 정상적으로 진행이 된다.

Gitlab 설정

Gitlab 설정은 ‘/etc/gitlab/gitlab.rb’ 파일을 이용 한다. 여기서 뭔가 변경을 하면 다음과 같이 재설정을 해야 한다.

Gitlab 재설정
ZSH
1
2
3
]$ sudo gitlab-ctl reconfigure
]$ sudo gitlab-rake gitlab:check
]$ sudo gitlab-ctl status

접속 URL 바꾸기

접속 URL 은 설치시에 지정해 줬지만 나중에 바꿀 수 있다. gitlab.rb 파일을 열어 다음의 내용을 확인하고 바꾸면 된다.

Gitlab 접속 URL 바꾸기
ZSH
1
2
]# vim /etc/gitlab/gitlab.rb
external_url 'http://gitlab.systemv.local:8001'

Grafana 비활성화

Gitlab 서버를 모니터링을 하기 위해서 Grafana 를 내장하고 있다. 이것을 비활성화를 하고 싶다면 다음과 같이 비활성화를 해준다.

Gitlab 에 Grafana 비활성화
ZSH
1
2
]# vim /etc/gitlab/gitlab.rb
grafana['enable'] = false

Prometheus 모니터링 비활성화

Prometheus 는 서비스에 대한 모니터링을 수집해주는 프로그램이며 Time Series 데이터베이스다. Grafana 는 이 데이터베이스를 읽어서 그래프를 그려주는 것이다.

Prometheus 뿐만 아니라 서비스의 각 메트릭을 수집해주는 Exporter 들이 있는데, Gitlab 에서는 prometheus_monitoring 을 비활성화하면 모든 Exporter 들도 비활성화가 된다.

Gitlab 에 Prometheus Monitoring 비활성화
ZSH
1
2
]# vim /etc/gitlab/gitlab.rb
prometheus_monitoring['enable'] = false

이렇게 한 후에 gitlab 을 reconfigure, restart 를 한 후에 gitlab 상태를 보면 다음과 같다.

Gitlab 에 상태
ZSH
1
2
3
4
5
6
7
8
9
]# gitlab-ctl status
run: gitaly: (pid 548) 21022s; run: log: (pid 542) 21022s
run: gitlab-workhorse: (pid 554) 21022s; run: log: (pid 544) 21022s
run: logrotate: (pid 9780) 3021s; run: log: (pid 546) 21022s
run: nginx: (pid 558) 21022s; run: log: (pid 551) 21022s
run: postgresql: (pid 559) 21022s; run: log: (pid 552) 21022s
run: puma: (pid 557) 21022s; run: log: (pid 553) 21022s
run: redis: (pid 550) 21022s; run: log: (pid 543) 21022s
run: sidekiq: (pid 556) 21022s; run: log: (pid 547) 21022s

모니터링을 위한 export, prometheus 등의 프로세스가 없다.

업로드 용량 변경

Gitlab 은 nginx 를 웹서버로 사용한다. nginx 에서는 client_max_body_size 값으로 파일 업로드 용량을 결정하는데, 이것을 설정에서 바꾸면 된다.

Gitlab 에 업로드 파일 용량 수정
ZSH
1
2
3
]# vim /etc/gitlab/gitlab.rb
nginx['enable'] = true
nginx['client_max_body_size'] = '1G' # 1G upload size

데이터 저장 디렉토리 변경

만일 데이터 저장 디렉토리를 변경하고 싶다면 다음의 설정을 바꾸면 된다.

Gitlab 에 데이터 저장 디렉토리 변경
ZSH
1
2
3
4
5
6
7
8
9
]# vim /etc/gitlab/gitlab.rb
### For setting up different data storing directory
###! Docs: https://docs.gitlab.com/omnibus/settings/configuration.html#storing-git-data-in-an-alternative-directory
###! **If you want to use a single non-default directory to store git data use a
###!   path that doesn't contain symlinks.**
git_data_dirs({
  "default" => { "path" => "/var/opt/gitlab/git-data" },
  "alternative" => { "path" => "/opt/gitlab-data" }
})

저장소를 “/opt/gitlab-data” 로 변경된다.

하지만, 만일 이미 저장소를 사용하고 있다면 다음과 같이 해줘야 한다.

Gitlab 에 데이터 저장 디렉토리 변경
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
mkdir /opt/gitlab-data
chown git:root /opt/gitlab-data
 
# Prevent users from writing to the repositories while you move them.
gitlab-ctl stop
 
# Note there is _no_ slash behind 'repositories', but there _is_ a
# slash behind 'git-data'.
sudo rsync -av /var/opt/gitlab/git-data/repositories /opt/gitlab-data
 
# Start the necessary processes and run reconfigure to fix permissions
# if necessary
sudo gitlab-ctl upgrade
 
# Double-check directory layout in /opt/gitlab-data. Expected output:
# repositories
sudo ls /opt/gitlab-data/
 
# Done! Start GitLab and verify that you can browse through the repositories in
# the web interface.
sudo gitlab-ctl start

자세한 것은 다음 링크를 참고한다.

virsh 를 통해 Ubuntu 20.04 에 console 로 접속하는 방법

KVM 가상화 시스템에서 virsh 를 통해 Ubuntu Guest OS에 Console 로 접속하는 방법은 다양한데 대부분 grub 부팅 옵션을 손보는 것이 였다. 하지만 Ubuntu 20.04 로 넘어오면서 이 방법이 훨씬 간단해 졌다.

먼저 Ubuntu 20.04 Guest 에 접속한 후에 다음과 같이 입력 하면 끝난다.

Ubuntu 20.04 Guest OS 에 접속하기 위한 서비스 시작
ZSH
1
2
$ sudo systemctl enable serial-getty@ttyS0.service
$ sudo systemctl start serial-getty@ttyS0.service

이렇게 한 후에 KVM 시스템에서 console 접속을 하면 접속이 잘된다.

KVM Guest OS Console 접속
ZSH
1
2
3
4
5
$ virsh console ubuntu20.04
Connected to domain ubuntu20.04
Escape character is ^]
 
systemv login:

이 방법은 18.04 에서도 가능하다.

Kubernetes 설치

Kubernetes 설치에 대해서 다룬다. 이번에는 Ubuntu 20.04 LTS, Centos 8.2 기반으로 진행했으며 이전에 설치에서 CNI 를 Calico 로 진행 했다. 더 나가 Helm, Metric Server 까지 진행 한다.

설치 환경은 다음과 같다.

  • Master
    • Distribution: Ubuntu 20.04
    • IP: 192.168.96.31
    • Hostname: kmaster
    • account: systemv
  • Worker Node
    • Distribution: CentOS 8.2
    • IP: 192.168.96.32
    • Hostname: knode
    • account: systemv
  • CNI: Calico
  • Helm 설치
  • Metric Server 설치

공통 설정 부분

Master, Node 두 서버 모두 Static IP 주소를 가지고 있어야 한다. 그리고 모두 일반 계정을 가지고 있어야 하며 이 일반 계정은 sudo 사용 권한을 가지고 있어야 한다.

sudo 권한 부여

CentOS 8.2 의 경우에 일반 계정을 생성한 후에 sudo 권한을 주고 싶다면 다음과 같이 하면 된다.

CentOS 8.2 에서 systemv 계정에 sudo 권한 부여하기
Shell
1
usermode -aG wheel systemv

CentOS 8.2 에는 wheel 라고 하는 특수한 그룹이 존재하는데, sudo 설정에는 이 그룹에 한해 sudo 사용 권한을 부여하고 있어 일반 계정 systemv 에 sudo 를 사용하게하고 싶다면 wheel 그룹에 포함시키면 된다.

Ubuntu 20.04 에서는 다음과 같이 일반계정에 sudo 권한을 부여할 수 있다.

Ubuntu 20.04 에서 systemv 계정에 sudo 권한 부여하기
Shell
1
usermode -aG sudo systemv

br_netfilter 모듈 로딩

br_netfilter 커널 모듈을 로딩해 줘야 한다. 기존에는 modprobe 설정으로 했지만 이제는 systemd 를 활용하면 되는데 ubuntu 20.04, CentOS 8.2 이 모두 이를 사용하고 있어서 적용 가능하다.

다음과 같이 모듈이름으로 conf 파일을 생성해 준다.

br_netfilter 커널 모듈 적재
ZSH
1
2
3
4
]$ sudo vim /etc/modules-load.d/br_netfilter.conf
# Load br_netfilter.ko at boot
br_netfilter
]$ sudo systemctl restart  systemd-modules-load.service

물론 이렇게 하면 시스템을 재부팅을 하더라도 자동으로 모듈이 로딩 된다.

커널 네트워크 파라메터

다음과 같이 커널 파라메터를 수정해 줘야 한다.

network 커널 파라메터 설정
ZSH
1
2
3
4
5
6
7
]# cat <<EOF > /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
net.bridge.bridge-nf-call-arptables = 1
net.ipv4.ip_forward = 1
EOF
]# sysctl --system

/etc/hosts 파일 편집

Master, Node 서버 양쪽 모두에 /etc/hosts 파일에 각 서버 정보를 다음과 같이 입력해준다.

hosts 파일 편집
ZSH
1
2
3
]# vim /etc/hosts
192.168.96.31  kmaster
192.168.96.32  knode

swapoff 설정

kubernetes 는 swap 파티션이 존재할 경우에 동작하지 않을 수 있다. 예를들어, kubeadm 명령어로 뭔가를 할려고 할경우에 swap 파티션이 존재할 경우에 오류를 내면서 작동되지 않는다.

Master, Worke 양쪽 모두에 swap 을 off 로 해준다.

swapoff 실행
ZSH
1
]# swapoff -a

이렇게 하면 swap 이 비활성화 된다. 그리고 반드시 /etc/fstab 에서 swap 관련 마운트 설정을 주석처리 해준다.

CentOS 8.2 에서 설정

SELinux off

CentOS 8.2 에서 설정은 SELinux 설정이다. 다음과 같이 해준다.

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

firewalld 비활성화

이것은 systemctl 로 다음과 같이 가능하다.

firewalld 비활성화
ZSH
1
2
]# systemctl stop firewalld
]# systemctl disable firewalld

패키지 설치

필수 패키지 설치
ZSH
1
2
3
]# dnf install -y yum-utils \
  device-mapper-persistent-data \
  lvm2

Ubuntu 에서 설정

패키지 설치

필수 패키지 설치
ZSH
1
2
3
4
5
6
]# apt install \
    apt-transport-https \
    ca-certificates \
    curl \
    gnupg-agent \
    software-properties-common

Docker 설치 및 설정

Kubernetes 는 Docker 를 기반으로하는 서비스다. 당연히 설치를 해줘야 하는데, 설치 관련 내용은 다음에 링크에서 각 배포판마다 잘 설명되어 있다.

한가지, Docker 설치를 위한 패키지 저장소는 명령어와 파일을 생성하는 방법 두가지가 있다.

Ubuntu 20.04

ubuntu 에서는 add-apt-repository 명령어로 저장소 URL 을 추가 가능하다. 예를 들면 다음과 같다.

저장소 주소 추가
ZSH
1
2
3
4
5
]# curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
]# add-apt-repository \
   "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
   $(lsb_release -cs) \
   stable"

저장소 추가가 되었다면 다음과 같이 Docker 를 설치해 준다.

Docker 설치
ZSH
1
2
]# apt update
]# apt install docker-ce docker-ce-cli containerd.io

CentOS 8.2

CentOS 8.2 에서는 yum-config-manager 명령어를 이용해서 추가할 수 있다. 이 명령어는 yum-utils 패키지에 포함되어 있어 설치하면 사용할 수 있다.

필수 유틸 프로그램 설치
ZSH
1
2
3
4
]# dnf install dnf-utils
]# yum-config-manager \
    --add-repo \
    https://download.docker.com/linux/centos/docker-ce.repo

저장소 추가가 되었다면 다음과 같이 Docker 를 설치해 준다.

CentOS 8.2 에서 Docker 설치
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
]# dnf install docker-ce docker-ce-cli containerd.io
Docker CE Stable - x86_64                                                                                                                                                275 kB/s |  25 kB     00:00    
오류:
문제: package docker-ce-3:19.03.12-3.el7.x86_64 requires containerd.io >= 1.2.2-3, but none of the providers can be installed
  - cannot install the best candidate for the job
  - package containerd.io-1.2.10-3.2.el7.x86_64 is filtered out by modular filtering
  - package containerd.io-1.2.13-3.1.el7.x86_64 is filtered out by modular filtering
  - package containerd.io-1.2.13-3.2.el7.x86_64 is filtered out by modular filtering
  - package containerd.io-1.2.2-3.3.el7.x86_64 is filtered out by modular filtering
  - package containerd.io-1.2.2-3.el7.x86_64 is filtered out by modular filtering
  - package containerd.io-1.2.4-3.1.el7.x86_64 is filtered out by modular filtering
  - package containerd.io-1.2.5-3.1.el7.x86_64 is filtered out by modular filtering
  - package containerd.io-1.2.6-3.3.el7.x86_64 is filtered out by modular filtering
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)

현시점에서 위와같은 오류가 발생한다. CentOS 8 에 대한 containerd 저장소가 존재하지 않기 때문에 필요한 정보만 출력하고 오류를 낸다. 수동으로 필요한 패키지를 다운받아서 해결한다.

containerd 패키지 수동 설치
ZSH
1
2
]# wget https://download.docker.com/linux/centos/7/x86_64/stable/Packages/containerd.io-1.2.13-3.2.el7.x86_64.rpm
]# dnf localinstall containerd.io-1.2.13-3.2.el7.x86_64.rpm

수동으로 설치는 정상적으로 진행된다. 그리고 다음과 같이 Docker 를 설치해 준다.

Docker 설치
ZSH
1
]# dnf install docker-ce docker-ce-cli iproute-tc

CentOS 8.2 에서 Docker 를 설치하면 필요한 서비스가 자동으로 시작되지 않는다. 이를 위해서 다음과 같이 systemd 를 설정해주고 시작해준다.

Docker 서비스 시작
ZSH
1
2
3
4
]# systemctl enable containerd
]# systemctl start containerd
]# systemctl enable docker
]# systemctl start docker

CGroup Driver 설정

Ubuntu, CentOS 모두 공통으로 Docker 를 설정해 주는 부분이 존재한다. 바로 Driver 를 systemd 로 바꿔줘야 한다.

Kubernetes 를 설치할때에 Cgroup driver 를 systemd 로 추천하고 있다. 그래서 Kubernetes 만 systemd 로 드라이버를 교체하면 docker 와 통신이 되지 않는다. 이것을 위해서 Docker 에서도 드라이버를 systemd 로 교체해 준다.

CGoup Driver 설정
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
]# cat > /etc/docker/daemon.json <<EOF
{
"exec-opts": ["native.cgroupdriver=systemd"],
"log-driver": "json-file",
"log-opts": {
"max-size": "100m"
},
"storage-driver": "overlay2",
"dns": ["8.8.8.8", "8.8.4.4"]
}
EOF
]# systemctl daemon-reload
]# systemctl restart docker

다음과 같이 확인이 가능하다.

CGroup Driver 확인
ZSH
1
2
3
4
]$ docker info
Logging Driver: json-file
Cgroup Driver: systemd
Plugins:

Kubernetes 설치

Ubuntu 20.04

Master 로 사용될 Ubuntu 20.04 에서 다음과 같이 Kubernetes 패키지 저장소를 추가 한다.

Kubernetes 설치를 위한 저장소 추가
ZSH
1
2
]# curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -
]# apt-add-repository "deb http://apt.kubernetes.io/ kubernetes-xenial main"

xenial 은 Ubuntu 16.04 를 말하는데 Ubuntu 20.04 에 설치하는데 아무런 문제가 없다.

다음과 같이 kubeadm, kubelet, kubectl 을 설치해 준다.

Kubernetes 컴포넌트 설치
ZSH
1
]# apt install -y kubelet kubeadm kubectl

CentOS 8.2

CentOS 8.2 에서는 다음과 같이 Kubernetes 패키지 저장소를 추가 한다.

CentOS 8 에서 Kubernetes 를 설치를 위한 저장소 추가
ZSH
1
2
3
4
5
6
7
8
9
]# cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF

그리고 다음과 같이 Kubernetes 를 설치해 준다.

CentOS 8 에서 Kubernetes 를 설치를 위한 저장소 추가
ZSH
1
2
3
]# dnf install -y kubeadm --disableexcludes=kubernetes
]# systemctl enable kubelet
]# systemctl start kubelet

Master 설정

Master 를 다른 말로 Control Plaine 이라고도 한다. 이것을 만드는 것은 kubeadm 을 이용한다. 일반 계정으로 실행 한다.

kubeadm 명령어를 통한 Master 생성
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
64
65
66
67
68
69
70
71
72
]$ sudo kubeadm init --apiserver-advertise-address=192.168.96.31 --pod-network-cidr=10.31.0.0/16
[sudo] password for systemv:
W0725 07:13:28.938671    1458 configset.go:202] WARNING: kubeadm cannot validate component configs for API groups [kubelet.config.k8s.io kubeproxy.config.k8s.io]
[init] Using Kubernetes version: v1.18.6
[preflight] Running pre-flight checks
[preflight] Pulling images required for setting up a Kubernetes cluster
[preflight] This might take a minute or two, depending on the speed of your internet connection
[preflight] You can also perform this action in beforehand using 'kubeadm config images pull'
[kubelet-start] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet-start] Starting the kubelet
[certs] Using certificateDir folder "/etc/kubernetes/pki"
[certs] Generating "ca" certificate and key
[certs] Generating "apiserver" certificate and key
[certs] apiserver serving cert is signed for DNS names [kmaster kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 192.168.96.31]
[certs] Generating "apiserver-kubelet-client" certificate and key
[certs] Generating "front-proxy-ca" certificate and key
[certs] Generating "front-proxy-client" certificate and key
[certs] Generating "etcd/ca" certificate and key
[certs] Generating "etcd/server" certificate and key
[certs] etcd/server serving cert is signed for DNS names [kmaster localhost] and IPs [192.168.96.31 127.0.0.1 ::1]
[certs] Generating "etcd/peer" certificate and key
[certs] etcd/peer serving cert is signed for DNS names [kmaster localhost] and IPs [192.168.96.31 127.0.0.1 ::1]
[certs] Generating "etcd/healthcheck-client" certificate and key
[certs] Generating "apiserver-etcd-client" certificate and key
[certs] Generating "sa" key and public key
[kubeconfig] Using kubeconfig folder "/etc/kubernetes"
[kubeconfig] Writing "admin.conf" kubeconfig file
[kubeconfig] Writing "kubelet.conf" kubeconfig file
[kubeconfig] Writing "controller-manager.conf" kubeconfig file
[kubeconfig] Writing "scheduler.conf" kubeconfig file
[control-plane] Using manifest folder "/etc/kubernetes/manifests"
[control-plane] Creating static Pod manifest for "kube-apiserver"
[control-plane] Creating static Pod manifest for "kube-controller-manager"
W0725 07:14:17.257414    1458 manifests.go:225] the default kube-apiserver authorization-mode is "Node,RBAC"; using "Node,RBAC"
[control-plane] Creating static Pod manifest for "kube-scheduler"
W0725 07:14:17.259815    1458 manifests.go:225] the default kube-apiserver authorization-mode is "Node,RBAC"; using "Node,RBAC"
[etcd] Creating static Pod manifest for local etcd in "/etc/kubernetes/manifests"
[wait-control-plane] Waiting for the kubelet to boot up the control plane as static Pods from directory "/etc/kubernetes/manifests". This can take up to 4m0s
[apiclient] All control plane components are healthy after 28.510647 seconds
[upload-config] Storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
[kubelet] Creating a ConfigMap "kubelet-config-1.18" in namespace kube-system with the configuration for the kubelets in the cluster
[upload-certs] Skipping phase. Please see --upload-certs
[mark-control-plane] Marking the node kmaster as control-plane by adding the label "node-role.kubernetes.io/master=''"
[mark-control-plane] Marking the node kmaster as control-plane by adding the taints [node-role.kubernetes.io/master:NoSchedule]
[bootstrap-token] Using token: 5azn6k.npyqsyongk3rsmqq
[bootstrap-token] Configuring bootstrap tokens, cluster-info ConfigMap, RBAC Roles
[bootstrap-token] configured RBAC rules to allow Node Bootstrap tokens to get nodes
[bootstrap-token] configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials
[bootstrap-token] configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token
[bootstrap-token] configured RBAC rules to allow certificate rotation for all node client certificates in the cluster
[bootstrap-token] Creating the "cluster-info" ConfigMap in the "kube-public" namespace
[kubelet-finalize] Updating "/etc/kubernetes/kubelet.conf" to point to a rotatable kubelet client certificate and key
[addons] Applied essential addon: CoreDNS
[addons] Applied essential addon: kube-proxy
 
Your Kubernetes control-plane has initialized successfully!
 
To start using your cluster, you need to run the following as a regular user:
 
  mkdir -p $HOME/.kube
  sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
  sudo chown $(id -u):$(id -g) $HOME/.kube/config
 
You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
  https://kubernetes.io/docs/concepts/cluster-administration/addons/
 
Then you can join any number of worker nodes by running the following on each as root:
 
kubeadm join 192.168.96.31:6443 --token 5azn6k.npyqsyongk3rsmqq \
    --discovery-token-ca-cert-hash sha256:743df4adaa7bace459250fa858ed07f587f6f40c4f5cd0898e3407c5ae6505a4

Kubernetes Master 명령은 전부 일반계정으로 하도록 되어 있어 있다. 일반계정이 kube api 통신을 위한 설정을 위 출력에 나온데로 실행해주면 된다.

kube api 통신을 위한 환경 설정
ZSH
1
2
3
]$ mkdir -p $HOME/.kube
]$ sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
]$ sudo chown $(id -u):$(id -g) $HOME/.kube/config

하지만 문제가 있다. 다음을 보자.

master 상태
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
systemv@kmaster:~$ kubectl get nodes
NAME      STATUS     ROLES    AGE     VERSION
kmaster   NotReady   master   6m49s   v1.18.6
systemv@kmaster:~$ kubectl get pods -o wide --all-namespaces
NAMESPACE     NAME                              READY   STATUS    RESTARTS   AGE     IP              NODE      NOMINATED NODE   READINESS GATES
kube-system   coredns-66bff467f8-7c8hr          0/1     Pending   0          6m57s   <none>          <none>    <none>           <none>
kube-system   coredns-66bff467f8-7t9z4          0/1     Pending   0          6m57s   <none>          <none>    <none>           <none>
kube-system   etcd-kmaster                      1/1     Running   0          7m6s    192.168.96.31   kmaster   <none>           <none>
kube-system   kube-apiserver-kmaster            1/1     Running   0          7m6s    192.168.96.31   kmaster   <none>           <none>
kube-system   kube-controller-manager-kmaster   1/1     Running   0          7m6s    192.168.96.31   kmaster   <none>           <none>
kube-system   kube-proxy-x76xr                  1/1     Running   0          6m57s   192.168.96.31   kmaster   <none>           <none>
kube-system   kube-scheduler-kmaster            1/1     Running   0          7m6s    192.168.96.31   kmaster   <none>           <none>

kmaster 가 ‘NotReady’ 나오고 coredns 상태가 ‘Pending’ 이다. kubelet 로그를 보자.

kubectl 로그
ZSH
1
2
3
Aug 30 00:29:03 kmaster kubelet[9751]: W0830 00:29:03.096595    9751 cni.go:213] Unable to update cni config: No networks found in /etc/cni/net.d
Aug 30 00:29:05 kmaster kubelet[9751]: E0830 00:29:05.155336    9751 kubelet.go:2169] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not read
Aug 30 00:29:08 kmaster kubelet[9751]: W0830 00:29:08.096862    9751 cni.go:213] Unable to update cni config: No networks found in /etc/cni/net.d

NetworkPlugin 이 없어 오류가 나오는 것으로 이는 CNI(Container Network Interface) 를 필요로 한다.

Calico 설치

Calico 는 Flannel 처럼 Kubernetes Cluster 에 네트워킹을 가능하도록 해준다. CNI 를 위한 컴포넌트중에 하나라고 보면 되는데, 한가지 주의해야 할 것은 반드시 메뉴얼을 읽어보고 해야 한다는 것이다.

Calico 는 Kubernetes 가 운영되는 환경에 따라 설치과정에 차이가 있으며 심지여 같은 운영환경이라고 할지라도 node 의 수에 따라서 설치해줘야하는 것도 다르다.

이 메뉴얼은 OnPremise 환경이며, 50 node 이하를 가지고 있음으로 아주 간단하게 다음과 같이 yaml 파일 하나만 다운로드 받아서 적용해주면 된다.

calico 설치를 위한 정의서 다운로드
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
$ curl https://docs.projectcalico.org/manifests/calico.yaml -O
$ kubectl apply -f calico.yaml
configmap/calico-config created
customresourcedefinition.apiextensions.k8s.io/bgpconfigurations.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/bgppeers.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/blockaffinities.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/clusterinformations.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/felixconfigurations.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/globalnetworkpolicies.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/globalnetworksets.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/hostendpoints.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/ipamblocks.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/ipamconfigs.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/ipamhandles.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/ippools.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/kubecontrollersconfigurations.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/networkpolicies.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/networksets.crd.projectcalico.org created
clusterrole.rbac.authorization.k8s.io/calico-kube-controllers created
clusterrolebinding.rbac.authorization.k8s.io/calico-kube-controllers created
clusterrole.rbac.authorization.k8s.io/calico-node created
clusterrolebinding.rbac.authorization.k8s.io/calico-node created
daemonset.apps/calico-node created
serviceaccount/calico-node created
deployment.apps/calico-kube-controllers created
serviceaccount/calico-kube-controllers created

이제 시간을 조금 기달려서 모든 pods 가 정상으로 Running 인지를 확인해 본다.

kubernetes 운영을 위한 pods 확인
ZSH
1
2
3
4
5
6
7
8
9
10
11
$ kubectl get pods -o wide --all-namespaces
NAMESPACE     NAME                                       READY   STATUS    RESTARTS   AGE   IP              NODE      NOMINATED NODE   READINESS GATES
kube-system   calico-kube-controllers-578894d4cd-892sz   1/1     Running   0          91s   10.31.189.3     kmaster   <none>           <none>
kube-system   calico-node-8btl4                          1/1     Running   0          91s   192.168.96.31   kmaster   <none>           <none>
kube-system   coredns-66bff467f8-7c8hr                   1/1     Running   0          8h    10.31.189.2     kmaster   <none>           <none>
kube-system   coredns-66bff467f8-7t9z4                   1/1     Running   0          8h    10.31.189.1     kmaster   <none>           <none>
kube-system   etcd-kmaster                               1/1     Running   0          8h    192.168.96.31   kmaster   <none>           <none>
kube-system   kube-apiserver-kmaster                     1/1     Running   0          8h    192.168.96.31   kmaster   <none>           <none>
kube-system   kube-controller-manager-kmaster            1/1     Running   0          8h    192.168.96.31   kmaster   <none>           <none>
kube-system   kube-proxy-x76xr                           1/1     Running   0          8h    192.168.96.31   kmaster   <none>           <none>
kube-system   kube-scheduler-kmaster                     1/1     Running   0          8h    192.168.96.31   kmaster   <none>           <none>

그리고 nodes 의 상태를 확인해 본다.

kubernetes 의 nodes 확인
ZSH
1
2
3
$ kubectl get nodes
NAME      STATUS   ROLES    AGE   VERSION
kmaster   Ready    master   8h    v1.18.6

“Ready” 상태가 되었음으로 이제 Worker Node 를 추가해 보자.

Worker Node 추가.

Worker Node 는 knode 서버에서 다음과 같이 Kubernetes Cluster 에 join 하겠다는 것으로 실현된다. join 을 위한 파라메터는 kmaster 에서 kubeadm 으로 cluster 를 생성할때 보여준 값을 입력하면 된다.

Worker Node 추가
ZSH
1
2
$ sudo kubeadm join 192.168.96.31:6443 --token 5azn6k.npyqsyongk3rsmqq \
>     --discovery-token-ca-cert-hash sha256:743df4adaa7bace459250fa858ed07f587f6f40c4f5cd0898e3407c5ae6505a4

이렇게 한 다음에 kmaster 서버에서 다음과 같이 knode 가 추가되고 상태가 Ready 된다면 Worker Node 추가가 완료된 것이다.

kubernetes 의 nodes 확인
ZSH
1
2
3
4
$ kubectl get nodes
NAME      STATUS   ROLES    AGE     VERSION
kmaster   Ready    master   9h      v1.18.6
knode     Ready    <none>   5m49s   v1.18.6

Helm 3 설치하기

Helm 은 Kubernetes 에서 작동하는 많은 Application 들을 손쉽게 설치하도록 도와주는 프로그램이다. 마치 Ubuntu 의 APT 나 CentOS 의 Yum 이 프로그램 설치를 손쉽게 해주는것과 같다.

한가지 변화가 있다. Helm 2 와 Helm 3 은 완전히 다르다고 생각해야 한다. Helm 2 는 Tiller 라고 해서 Helm 서버가 필요했지만 Helm 3 에서는 이것이 없어졌다.

Helm 3 는 설치 스크립트를 제공함으로 이것을 이용하면 손쉽게 설치할 수 있다. 설치 Node는 kubectl 을 사용할 수 있는 곳이라면 어디선든 사용이 가능하다.

Helm 3 설치

Helm 3 설치는 스크립트로 제공한다.

Helm 3 설치
ZSH
1
2
3
$ curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3
$ chmod 700 get_helm.sh
$ ./get_helm.sh

설치는 그냥 바이너리를 다운로드 받아서 /usr/bin 에 helm 바이너리를 설치하는 것으로 끝난다.

정상적으로 설치됐는지 확인은 다음과 같이 한다.

Helm 3 설치 확인
ZSH
1
2
$ helm version
version.BuildInfo{Version:"v3.2.4", GitCommit:"0ad800ef43d3b826f31a5ad8dfbb4fe05d143688", GitTreeState:"clean", GoVersion:"go1.13.12"}

한가지 문제는 기본 repository 주소가 없어서 뭐든 설치할려면 설치가 안된다. 이를 위해서 다음과 같이 저장소를 추가해 준다.

Helm 3 저장소 추가
ZSH
1
2
3
4
5
6
7
8
$ helm search repo
Error: no repositories configured
$ helm repo add stable https://kubernetes-charts.storage.googleapis.com/
"stable" has been added to your repositories
$ helm repo update
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "stable" chart repository
Update Complete. ⎈ Happy Helming!⎈

Helm 3 은 이것으로 끝이다. 이전 Helm 2 버전에 비해 해줘야 하는 것이 없다.

Metric Server 설치

Kubernetes 를 설치하게 되면 자원에 대한 모니터링이 필요하다. 과거에는 Heapster 를 이용했지만 이것은 이제 더 이상 개발이 되지 않고 있으며 이를 대체하는 것이 Metric Server 이다.

Kubernetes 에서 뭔가를 설치하는 것은 대부분 Pods 를 설치하는 것이며 이것에 대한 Rules, Datastore 등도 한꺼번에 설정을 해준다.

Metric Server 를 설치하게 되면 Kubernetes 의 컴포넌트들에 대한 자원 모니터링이 가능해지며 이것을 이용해 Autoscaling 에도 사용이 가능해진다.

Downloads

Metric Server 를 다음과 같이 다운로드를 한다.

Metric Server 설치 파일 다운로드
ZSH
1
]$ wget https://github.com/kubernetes-sigs/metrics-server/releases/download/v0.3.7/components.yaml

TLS 수정

Metric Server 를 설치할때에 주의해야 할 것은 Kube API 서버와의 통신에서 사용할 TLS 를 수정하는 것이다. Metric Server 는 Public TLS 를 기본으로 하지만 Kube API 는 Kube 자체의 TLS 를 사용하기 때문에 그냥 설치하면 문제가 된다.

Metric Server 설치 파일 TLS 수정
ZSH
1
2
3
4
5
6
7
8
]$ vim components.yaml
....
        args:
          - --cert-dir=/tmp
          - --secure-port=4443
          - --kubelet-insecure-tls
          - --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname
....

Deploy

이제 이것을 Deploy 해준다. Kubernetes 에서는 설치라는게 없다. 모두 다 pods 로 다 올라가기 때문에 Deploy 라고 한다.

Metric Server 배포
ZSH
1
2
3
4
5
6
7
8
9
10
$ kubectl apply -f components.yaml
clusterrole.rbac.authorization.k8s.io/system:aggregated-metrics-reader created
clusterrolebinding.rbac.authorization.k8s.io/metrics-server:system:auth-delegator created
rolebinding.rbac.authorization.k8s.io/metrics-server-auth-reader created
apiservice.apiregistration.k8s.io/v1beta1.metrics.k8s.io created
serviceaccount/metrics-server created
deployment.apps/metrics-server created
service/metrics-server created
clusterrole.rbac.authorization.k8s.io/system:metrics-server created
clusterrolebinding.rbac.authorization.k8s.io/system:metrics-server created

위와같이 관련된 설정과 pods, deploy, service 등이 생성이 된다.

확인

Metric Server 의 확인은 pods, deploy 가 제대로 되었는지를 살펴보면 된다.

Metric Server 배포 확인
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
]$ kubectl get pods -n kube-system
NAME                                       READY   STATUS    RESTARTS   AGE
calico-kube-controllers-578894d4cd-892sz   1/1     Running   0          67m
calico-node-8btl4                          1/1     Running   0          67m
calico-node-kp5gm                          1/1     Running   0          58m
coredns-66bff467f8-7c8hr                   1/1     Running   0          9h
coredns-66bff467f8-7t9z4                   1/1     Running   0          9h
etcd-kmaster                               1/1     Running   0          9h
kube-apiserver-kmaster                     1/1     Running   0          9h
kube-controller-manager-kmaster            1/1     Running   0          9h
kube-proxy-2nklp                           1/1     Running   0          58m
kube-proxy-x76xr                           1/1     Running   0          9h
kube-scheduler-kmaster                     1/1     Running   0          9h
metrics-server-5f4ffd464c-s98nr            1/1     Running   0          77s
]$ kubectl get deploy -n kube-system
NAME                      READY   UP-TO-DATE   AVAILABLE   AGE
calico-kube-controllers   1/1     1            1           68m
coredns                   2/2     2            2           9h
metrics-server            1/1     1            1           92s

그리고 1~2분을 기다리면 후에 다음과 같이 자원이 출력이 되는지를 보면 된다.

Metric Server 작동 확인
ZSH
1
2
3
4
5
6
7
8
9
10
11
12
13
NAME                                       CPU(cores)   MEMORY(bytes)  
calico-kube-controllers-578894d4cd-892sz   1m           6Mi            
calico-node-8btl4                          24m          26Mi            
calico-node-kp5gm                          21m          45Mi            
coredns-66bff467f8-7c8hr                   4m           6Mi            
coredns-66bff467f8-7t9z4                   3m           6Mi            
etcd-kmaster                               20m          28Mi            
kube-apiserver-kmaster                     39m          325Mi          
kube-controller-manager-kmaster            14m          41Mi            
kube-proxy-2nklp                           1m           12Mi            
kube-proxy-x76xr                           1m           9Mi            
kube-scheduler-kmaster                     4m           12Mi            
metrics-server-5f4ffd464c-s98nr            1m           13Mi

CPU, Memory 등과 같은 자원 현황이 출력이 되면 정상적으로 작동하는 것이다.

VSCode 폰트 변경하기

VSCode 폰트(font) 변경하기에 대해서 알아본다. 환경도 윈도우즈가 아닌 리눅스(Linux) 에서 VSCode 폰트 변경이다. 리눅스 환경에서 폰트변경은 뭐든 쉬운 일이 아니다.

폰트(font) 알기 – fc-list

리눅스에서 폰트는 fc-list 명령어를 통해서 알 수 있다.

List installed font
Shell
1
2
3
4
5
6
7
8
$ fc-list
/usr/share/fonts/truetype/tlwg/TlwgTypo-Bold.ttf: Tlwg Typo:style=Bold
/usr/share/fonts/truetype/dejavu/DejaVuSerif-Bold.ttf: DejaVu Serif:style=Bold
/usr/share/fonts/truetype/noto/NotoSansThai-Regular.ttf: Noto Sans Thai:style=Regular
/usr/share/fonts/truetype/noto/NotoSansModi-Regular.ttf: Noto Sans Modi:style=Regular
/usr/share/fonts/opentype/urw-base35/URWBookman-LightItalic.otf: URW Bookman:style=Light Italic
/usr/share/fonts/truetype/fonts-kalapi/Kalapi.ttf: Kalapi:style=Regular
/usr/share/fonts/truetype/fonts-gujr-extra/Rekha.ttf: Rekha:style=Medium

결과를 보면 다음과 같은 정보를 보여준다.

  1. 설치된 폰트 파일(전체 경로 포함)
  2. 폰트 이름.
  3. 스타일. 스타일은 Regular, Bold, Italic 등이다.

옵션없이 실행하자 설치된 모든 폰트들을 보여준다. 이 명령어에는 필터 기능을 제공한다.

List installed font for ko
Shell
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
$ fc-list : lang=ko
/usr/share/fonts/truetype/nanum/NanumSquareRoundB.ttf: 나눔스퀘어라운드,NanumSquareRound,NanumSquareRound Bold,나눔스퀘어라운드 Bold:style=Bold,Regular
/usr/share/fonts/opentype/noto/NotoSerifCJK-Bold.ttc: Noto Serif CJK SC:style=Bold
/usr/share/fonts/opentype/noto/NotoSerifCJK-Bold.ttc: Noto Serif CJK TC:style=Bold
/usr/share/fonts/opentype/noto/NotoSansCJK-Black.ttc: Noto Sans CJK HK,Noto Sans CJK HK Black:style=Black,Regular
/usr/share/fonts/opentype/noto/NotoSerifCJK-Bold.ttc: Noto Serif CJK JP:style=Bold
/usr/share/fonts/opentype/noto/NotoSerifCJK-Bold.ttc: Noto Serif CJK KR:style=Bold
/usr/share/fonts/truetype/nanum/NanumSquareRoundR.ttf: 나눔스퀘어라운드,NanumSquareRound,NanumSquareRound Regular,나눔스퀘어라운드 Regular:style=Regular
/usr/share/fonts/truetype/nanum/NanumSquareB.ttf: 나눔스퀘어,NanumSquare,NanumSquare Bold,나눔스퀘어 Bold:style=Bold
/usr/share/fonts/opentype/noto/NotoSansCJK-Regular.ttc: Noto Sans CJK JP:style=Regular
/usr/share/fonts/opentype/noto/NotoSansCJK-Regular.ttc: Noto Sans CJK HK:style=Regular
/usr/share/fonts/opentype/noto/NotoSansCJK-Regular.ttc: Noto Sans CJK KR:style=Regular
/usr/share/fonts/opentype/noto/NotoSansCJK-Black.ttc: Noto Sans CJK TC,Noto Sans CJK TC Black:style=Black,Regular
/usr/share/fonts/opentype/noto/NotoSerifCJK-Medium.ttc: Noto Serif CJK KR,Noto Serif CJK KR Medium:style=Medium,Regular
/usr/share/fonts/opentype/noto/NotoSansCJK-Black.ttc: Noto Sans CJK KR,Noto Sans CJK KR Black:style=Black,Regular
/usr/share/fonts/truetype/wqy/wqy-microhei.ttc: WenQuanYi Micro Hei,文泉驛微米黑,文泉驿微米黑:style=Regular
/usr/share/fonts/opentype/noto/NotoSansCJK-Regular.ttc: Noto Sans CJK SC:style=Regular

‘:’ 를 기준으로 필터를 줄 수 있다. 필터는 ‘:’ 를 기준으로 연달아 적어주면 되는데 위의 예제는 언어가 ko 인 것만을 보여주도록 옵션을 줬다. 하지만 결과를 보면 중국어, 홍콩, 일본등도 함께 출련된다. 이것은 CJK 폰트의 특성이다. CJK 는 중국어,일본어,한국어만을 따로 모아 놓은 폰트를 말한다.

다음과 같은 필터를 사용할 수 있다.

  1. fc-list : family
  2. fc-list : lang=ko family
  3. fc-list : family style
  4. fc-list –format=”%{family[0]}\n” | sort | uniq

위 보기에서 2번째 명령어를 통해서 한글을 지원하는 폰트를 알아낸다. 나는 “Noto Sans Mono CJK KR” 를 선택했다.

VSCode 폰트 변경

리눅스용 VSCode 는 설정을 열기위한 단축키를 제공하는데, Shift + Ctl + P 를 누르면 된다. 여기서 ‘설정열기(JSON)’ 선택해 자신만의 설정을 커스터마이징 할 수 있다. 폰트 변경은 다음과 같이 했다.

Change font for vscode
1
2
3
4
{
    "editor.fontFamily": "'Noto Sans Mono CJK KR', 'monospace', monospace, 'Droid Sans Fallback'",
    "editor.fontSize": 16,
}

폰트 이름에 공백(Space) 가 들어간 경우에 홑따옴표(‘) 로 감싸준다. 새로운 폰트 이름을 적자마자 바로 적용된다.

Oracle Linux 8 UEK 커널 설치

Oracle Linux 는 UEK(Unbreakable Enterprise Kernel) 라고 해서 커널을 제공 한다. Oracle 은 이를통해 최신의 커널을 제공하고 자신들만의 퍼포먼스 패치를 더해서 고성능을 낼수 있도록 했다. Oracle Linux 8 에서 UEK 커널을 설치해 보자.

Yum Repository 확인

Oracle Linux 8 에는 uek 를 위한 yum repository 가 추가되어 있다. 다음과 같이 확인이 가능하다.

Check yum's repository for UEK
Shell
1
2
3
4
5
6
yum repolist
Failed to set locale, defaulting to C.UTF-8
repo id                                                                      repo name
ol8_UEKR6                                                                    Latest Unbreakable Enterprise Kernel Release 6 for Oracle Linux 8 (x86_64)
ol8_appstream                                                                Oracle Linux 8 Application Stream (x86_64)
ol8_baseos_latest                                                            Oracle Linux 8 BaseOS Latest (x86_64)

‘ol8_UEKR6’ 가 uek 를 위한 저장소(repository) 이다. 이제 다음과 같이 어떤 버전의 uek 커널이 있는지 다음과 같이 체크해보자.

Check version of UEK
Shell
1
2
3
4
5
yum list kernel-uek
Last metadata expiration check: 0:19:13 ago on Thu Jul 23 19:37:48 2020.
Available Packages
kernel-uek.x86_64                                                                            5.4.17-2011.3.2.1.el8uek                                                                             ol8_UEKR6
kernel-uek.src                                                                               5.4.17-2011.4.4.el8uek                                                                               ol8_baseos_latest

현재 시점에서 5.4 버전의 uek 커널이 있음을 알 수 있다.

시스템 커널 유지 개수

yum 은 자동으로 패키지를 설치해주고 더 이상 필요없는 패키지는 삭제해주며, 의존성도 함께 해결해준다. 커널의 경우에는 버전마다 설치가 되는데 이렇게 되면 아주 많은 커널이 설치가되어서 부팅시 많은 커널들이 보이게 된다.

이런문제를 해소하기 위해서 yum 은 같은 패키지의 경우에 다양한 버전에 한해서 몇개까지 유지할지 개수를 제한하는데 이것이 ‘installonly_limit’ 이다. 이는 다음과 같이 /etc/yum.conf 파일에 저장된다.

Check 'installonly_limit' variable in yum.conf
Shell
1
2
3
4
5
6
[main]
gpgcheck=1
installonly_limit=3
clean_requirements_on_remove=True
best=True
skip_if_unavailable=False

초기값은 3 인데, uek 를 설치하게되면 기본 커널도 삭제될 가능성도 있기 때문에 이것을 5로 교체해준다.

설치

설치는 yum 명령어를 이용해 간단히 다음과 같이 설치 할 수 있다.

Install uek kernel by yum
Shell
1
yum install kernel-uek -y

자동으로 uek 의 최신 버전을 다운로드 받아 설치해 준다. 재부팅을하면 uek 커널로 올라올 것이다.

Install uek kernel by yum
Shell
1
2
uname -a
Linux localhost.localdomain 5.4.17-2011.3.2.1.el8uek.x86_64 #2 SMP Sun May 24 13:36:59 PDT 2020 x86_64 x86_64 x86_64 GNU/Linux

Oracle Linux 8.2 설치

Oracle 에서 만들어서 배포하는 Oracle Linux 8.2 를 설치해 본다. 현 시점(2020.07) 에서 최신버전은 Oracle Linux 8.2 이다.

다운로드

Oracle Linux 를 설치를 위해 준비된 이미지는 두가지로 전체 패키지를 담은 DVD 이미지와 Boot 이미지를 제공한다. Boot 이미지는 또 일반 커널과 UEK 커널을 가지는 버전으로 제공한다. 어느걸 하던 상관은 없다.

Download Oracle Linux 8.2 image
Shell
1
2
3
4
5
6
7
8
9
10
11
]# wget https://yum.oracle.com/ISOS/OracleLinux/OL8/u2/x86_64/x86_64-boot-uek.iso
--2020-07-23 16:53:15--  https://yum.oracle.com/ISOS/OracleLinux/OL8/u2/x86_64/x86_64-boot-uek.iso
Resolving yum.oracle.com (yum.oracle.com)... 104.75.8.194
접속 yum.oracle.com (yum.oracle.com)|104.75.8.194|:443... 접속됨.
HTTP request sent, awaiting response... 200 OK
Length: 682622976 (651M) [application/octet-stream]
Saving to: ‘x86_64-boot-uek.iso’
 
x86_64-boot-uek.iso                100%[===============================================================>] 651.00M  11.7MB/s    in 57s    
 
2020-07-23 16:54:13 (11.3 MB/s) - ‘x86_64-boot-uek.iso’ saved [682622976/682622976]

설치

다운받은 이미지를 USB 나 CD 로 구워서 부팅을 한다.

부팅을 하면 위와 같은 화면이 나온다. 여기서 “Install Oracle Linux 8.2.0” 를 선택해서 설치를 진행한다.

설치는 CentOS 설치 화면과 동일하다. 부팅을 uek boot 이미지를 이용해서 부팅을 했기 때문에 설치를 위한 패키지가 존재하지 않는다. 따라서 반드시 인터넷이 되어야 한다. 그래서 설치할때에 반드시 Network 설정을 먼저해 줘야 한다.

Network 설정

나는 iptime 공유기를 이용하고 있기 때문에 DHCP 만으로 설치하는 Oracle Linux 서버의 ip 설정을 끝냈다. 물론 고정IP 를 설정해도 된다. 일단 인터넷이 되어야 한다.

패키지 저장소 지정.

uek boot 이미지로 부팅을 했기 때문에 패키지를 인터넷을 통해서 다운받아야 한다. 다운받을 주소를 지정해준다. 이 주소는 다음의 링크에서 확인이 가능하다.

위 링크에서 “Installation Media Packages” 에서 BaseOS 8.2 에 x86_64 링크를 클릭해서 나오는 화면에 오른쪽에 Direct Yum Repository URL 주소를 입력해주면 된다.

나머지는 모두 CentOS 설치와 완전히 동일하다. 개인적으로 여기에 Oracle DB 를 설치하고자 파티션을 다음과 같이 나눴다.

  1. / – 40GB
  2. swap – 12GB

Spring5 Security 기초 템플릿 – Session

이 글은 Spring5 에 Spring-Security 에 대한 기초 템플릿이다. Session 유지를 위해서 Redis 를 필요로 한다. 또, ElasticSearch 의 RestHighLevelClient 로 ElasticSearch를 연결 한다. 데이터베이스는 JNDI 설정으로 연결 된다.

다음과 같은 내용을 담았다.

  1. JDK 11
  2. Tomcat 서버 9 를 이용.
  3. spring-session.xml 을 작성해 Redis 를 세션으로 사용하도록 했다.
  4. JNDI 를 이용해 MySQL 에 연결된다.

Redis 설정한 이유는 Spring Security 에 인증을 InMemory 를 요구 한다. 이는 다음과 같은 설정 때문이다.

spring-security.xml 에 bcrypt 패스워드 설정
XHTML
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
<authentication-manager>
<authentication-provider>
<user-service>
<!-- This is required a InMemory DB. So I setup Redis and config to a spring-session.xml for connecting the redis
if you set spring-session.xml, you should config also web.xml for springSessionRepositoryFilter
-->
     <user name="jimi" password="{bcrypt}$2a$10$ddEWZUl8aU0GdZPPpy7wbu82dvEw/pBpbRvDQRqA41y6mK1CoH00m"
            authorities="ROLE_USER, ROLE_ADMIN" />
    <user name="bob" password="{bcrypt}$2a$10$/elFpMBnAYYig6KRR5bvOOYeZr1ie1hSogJryg9qDlhza4oCw1Qka"
            authorities="ROLE_USER" />
    <!-- Password is prefixed with {noop} to indicate to DelegatingPasswordEncoder that
     NoOpPasswordEncoder should be used. This is not safe for production, but makes reading
     in samples easier. Normally passwords should be hashed using BCrypt -->
     <!-- <user name="jimi" password="{noop}jimispassword" authorities="ROLE_USER, ROLE_ADMIN" /> -->
<!-- <user name="bob" password="{noop}bobspassword" authorities="ROLE_USER" /> -->
</user-service>
</authentication-provider>
</authentication-manager>

인증을 위한 패스워드가 {bcrypt} 로 되어 있다. 이 설정은 InMemory 세션을 요구한다. 이를 위해서 spring-session.xml 을 작성해 web.xml 에서 다음과 같이 인식을 시켜 준다.

web.xml 에 Session 설정
XHTML
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>
classpath:spring/root-context.xml
classpath:spring/spring-security.xml
classpath:spring/spring-session.xml
</param-value>
</context-param>
 
<!-- Spring Session. This setting is related to spring-session.xml -->
<filter>
<filter-name>springSessionRepositoryFilter</filter-name>
<filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
</filter>
<filter-mapping>
<filter-name>springSessionRepositoryFilter</filter-name>
<url-pattern>/*</url-pattern>
<dispatcher>REQUEST</dispatcher>
<dispatcher>ERROR</dispatcher>
</filter-mapping>
BasicSpring5SecurityThemplateRedisSession다운로드

Spring5 Security 기초 템플릿

이 문서는 Spring5 Security 기초 템플릿에 대한 것이다. Spring5 에 Spring-Security 를 이용해 기초적인 로그인을 구현 했다. Session 은 InMemory 가 아닌 WAS 서버에 세션을 저장한다. 로그인 정보는 spring-security.xml 에 정의된 것을 그대로 사용했다. 그야말로 기초적인 내용만 담았다.

이 템플릿이 동작하기 위한 조건은 다음과 같다.

  1. Java 1.8 기반.
  2. 데이터베이스가 연결되어 있어야 한다. 데이터베이스는 MySQL 이다.
  3. WAS 서버에 JNDI 를 연결된다.
  4. users 테이블이 필요한데, user.sql 파일에 내용이 있다.
  5. spring security 의 Role 기반 권한 접근 제어.
  6. context root 는 malluser 이다.

작동방식

Login 화면

권한을 체크하기 때문에 로그인 화면이 먼저 나온다. 권한 체크는 다음과 같이 Controller 에서 이루어진다.

HomeController.java 에 PreAuthorize 를 이용해 Role 설정
Java
1
2
3
4
5
6
7
8
9
10
11
// HomeController.java
@Slf4j
@Controller
@PreAuthorize("hasRole('ROLE_USER')")
public class HomeController {
@Autowired
private UsersService userService;
@RequestMapping(value = "/", method = RequestMethod.GET)
public String home(Locale locale, Model model) {

ROLE_USER 권한을 가지고 있다면 초기화면에 접근이 가능하며 그렇지 않다면 로그인 화면으로 돌아가게 된다.

spring-security.xml 에 URL 접근 Role 설정
XHTML
1
2
3
4
5
6
7
<http>
<intercept-url pattern="/**" access="hasRole('USER')" />
<form-login />
<logout />
<csrf />
</http>

인증을 위한 정보는 다음과 같이 구현 됐다.

spring-security.xml 에 인증 설정
XHTML
1
2
3
4
5
6
7
8
9
10
11
<authentication-manager>
<authentication-provider>
<user-service>
<!-- Password is prefixed with {noop} to indicate to DelegatingPasswordEncoder that
     NoOpPasswordEncoder should be used. This is not safe for production, but makes reading
     in samples easier. Normally passwords should be hashed using BCrypt -->
     <user name="jimi" password="{noop}jimispassword" authorities="ROLE_USER, ROLE_ADMIN" />
<user name="bob" password="{noop}bobspassword" authorities="ROLE_USER" />
</user-service>
</authentication-provider>
</authentication-manager>

{noop} 은 암화화 되지 않는 text 기반의 암호을 말하는 것이며 위 설정은 외부 정보 저장소를 이용하지 않는 것이다.

로그인을 하면 다음과 같은 화면이 나온다.

로그인 화면

LOGOUT 버튼은 다음과 JSP 에서 Security tags 를 이용해 구현 했다.

jsp 에 tag 를 이용한 인증
XHTML
1
2
3
4
5
6
7
8
<%@ taglib prefix="sec" uri="http://www.springframework.org/security/tags" %>
 
<sec:authorize access="isAuthenticated()">
    <form action="<c:url value="/logout"/>" method="POST">
        <sec:csrfInput />
        <button type="submit">LOGOUT</button>
    </form>
</sec:authorize>
BasicSpring5SecurityThemplate다운로드

Eclipse 에서 제작되었다.