GitLab-Runner 설치

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

설치

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

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

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

Gitlab 에 등록하기

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

gitlab-runner 셋업 정보

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

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

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

등록된 gitlab-runner

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

Java 컴파일 환경 구축.

번외로 Java 컴파일 환경을 구축해 보겠다. 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 를 사용하기로 했다. 현 시점에서 최신판을 다운로드 한다.

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

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

maven 설치

maven 을 설치해준다.

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

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

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

.gitlab-ci.yml 파일

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

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 설치를 위한 저장소 추가

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

Gitlab 설치

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

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

Gitlab 설정

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

접속 URL 바꾸기

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

Grafana 비활성화

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

Prometheus 모니터링 비활성화

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

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

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

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

업로드 용량 변경

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

데이터 저장 디렉토리 변경

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

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

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

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

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

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

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

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

이 방법은 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 에는 wheel 라고 하는 특수한 그룹이 존재하는데, sudo 설정에는 이 그룹에 한해 sudo 사용 권한을 부여하고 있어 일반 계정 systemv 에 sudo 를 사용하게하고 싶다면 wheel 그룹에 포함시키면 된다.

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

br_netfilter 모듈 로딩

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

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

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

커널 네트워크 파라메터

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

/etc/hosts 파일 편집

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

swapoff 설정

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

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

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

CentOS 8.2 에서 설정

SELinux off

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

firewalld 비활성화

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

패키지 설치

Ubuntu 에서 설정

패키지 설치

Docker 설치 및 설정

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

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

Ubuntu 20.04

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

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

CentOS 8.2

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

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

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

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

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

CGroup Driver 설정

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

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

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

Kubernetes 설치

Ubuntu 20.04

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

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

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

CentOS 8.2

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

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

Master 설정

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

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

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

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

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

Calico 설치

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

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

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

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

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

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

Worker Node 추가.

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

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

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 설치는 스크립트로 제공한다.

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

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

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

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

Metric Server 설치

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

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

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

Downloads

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

TLS 수정

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

Deploy

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

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

확인

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

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

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

VSCode 폰트 변경하기

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

폰트(font) 알기 – fc-list

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

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

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

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

‘:’ 를 기준으로 필터를 줄 수 있다. 필터는 ‘:’ 를 기준으로 연달아 적어주면 되는데 위의 예제는 언어가 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)’ 선택해 자신만의 설정을 커스터마이징 할 수 있다. 폰트 변경은 다음과 같이 했다.

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

Oracle Linux 8 UEK 커널 설치

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

Yum Repository 확인

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

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

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

시스템 커널 유지 개수

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

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

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

설치

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

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

Oracle Linux 8.2 설치

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

다운로드

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

설치

다운받은 이미지를 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 를 요구 한다. 이는 다음과 같은 설정 때문이다.

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

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 에서 이루어진다.

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

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

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

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

로그인 화면

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

Eclipse 에서 제작되었다.

Mybatis에 DAO 와 Mapper

SpringFramework 을 이용하다보면 데이터베이스 액세스를 위해서 MyBatis 를 사용하곤 한다. SQL 매퍼라고 불리기도 하는 것인데, 이를 이용하면 손쉽게 자바 코드와 SQL 문을 분리해줄 수 있을뿐만 아니라 MyBatis 에서 제공하는 여러가지 추가적인 기능을 이용해 데이터베이스를 좀 더 유연하게 사용할 수 있다.

DAO

보통 MyBatis 를 이용할대는 DAO 를 구조를 사용하곤 했다. Data Access Object 라고 불리는 것으로 말 그대로 데이터 접근을 위한 객체로서 sqlSession 객체를 이용해 데이터베이스 조회만 전담하는 객체다.

이 구조는 인터페이스와 그것을 구현한 구현체 클래스가 있어야 한다. 이를 위해서 Spring의 컨텍스트 설정을 해줘야 하는데 대략 다음과 같다.

sqlSession 을 빈으로 등록해준다. 그리고 다음과 같이 DAO 를 작성해 준다.

UserDAOImpl 은 UserDAO 인터페이스의 구현체다. SqlSession 의 빈을 가지고 오기 위해서 와이어를 걸어서 가지고 왔고, SQL 매퍼를 찾기위한 네임스페이스와 파라메터 인자를 주고 selectOne 메소드를 호출하고 있다.

이제 이것을 Service 계층에서, 역시나, 와이어를 걸어서 가지와서 데이터베이스에 데이터를 값을 호출하고 있다.

많은 프로젝트에서 이와 유사한 구조를 자주 보게 된다.

Mapper

그런데, 신기하게도 Mapper 을 이용해서 DAO 를 사용할 수도 있다. 이 기능은 MyBatis 3.0 이상부터 지원하기 시작한 것으로 Mapper 인터페이스만 구현하고 Service 계층에서 바로 와이어를 걸어서 사용할 수 있도록 했다.

하지만 DAO 구조에서도 얼마든지 Mapper 를 사용할 수 있다. sqlSession 에 메소드의 파라메터를 Mapper 클래스로 넘기면 된다. 먼저 Mapper 인터페이스를 다음과 같이 만든다.

그리고 앞에 DAO 구현체에 메소드를 다음과 같이 바꾼다.

sqlSession 객체에는 getMapper 는 메소드가 존재하고 이는 MyBatis 가 지원하는 Mapper 인터페이스를 받게 되어 있다.

문제는 MyBatis 의 namespace 인데, Mapper 인터페이스의 경로를 적어주면 되며 id 가 Mapper 인터페이스의 메소드 이름과 매핑된다.

이렇게 함으로써 Mapper 를 이용하면서도 DAO 구조를 그대로 유지할 수 있다. 문제는 DAO 에서 Mapper 인터페이스 객체를 매번 생성해 줘야 한다는 것이다. sqlSession.getMapper 를 이용해서 매번 가지고 오게 되는데, 이렇게 하는 것보다는 Spring Context 에서 빈으로 등록해 와이어로 가지고 오게 되면 DAO 가 아닌 Service 계층에서 호출이 가능하다.

다음과 같이 빈으로 등록한다.

이제 Service 계층에서 다음과 같이 와이어로 가지고 오고 바로 사용할 수 있다.

하지만 이렇게 할 경우에 Mapper 인터페이스 객체 하나하나 전부 Spring Context 에서 빈으로 만들어 줘야 한다. 그래서 이렇게 하지말고 Mapper 인터페이스를 스캔하도록 할 수 있는데 이를 위해서 mybatis-spring 라이브러리 패키지와 xsd 설정을 해줘야 한다. xsd 과 설정은 Spring Context 파일에 다음과 같이 해준다.

Mapper 인터페이스 클래스 파일들을 전부 위 설정에 나온 패키지 경로로 모두 옮긴다. 그리고 각 Mapper 인터페이스에 @Mapper 어노테이션을 붙여준다. 또한 매퍼 XML 에 네임스페이스 경로도 모두 위 설정으로 바꿔 준다.

이렇게 하면 DAO 관련 파일들은 전부 삭제해도 잘 동작 한다.