Category: Linux

DNF 사용하기

CentOS 8 로 넘어오면서 기본 패키지 매니지먼트로 dnf 가 되었다. 여전히 yum 을 지원하지만 앞으로는 dnf 로 쭉 간다고 하니 이참에 배워보자고 생각하지만….

겁나 빡치는게, 이제 그만 바꿨으면 한다. 뭔 yum 정도로도 충분히 잘 쓰고 있고 괜찮다고 싶다. 무슨 겁나 가볍네, 더 빠르네 어케 좋네… 응 yum 도 그렇게 느리고 그렇게 무겁지도 않아! 도대체 뭘 할때마다 갈아 엎고 이걸 새로 배우라고 하니.. 뭐 어쩌것나.. 그렇게 하겠다는데, 닥치고 배워야지!

dnf

햐.. 쓰기도 귀찮다… “DNF is the next upcoming major version of YUM, a package manager for RPM-based Linux distributions” 이렇게 맨 페이지에 설명이 나온다.

사용법

사용법은 아주 간단하다. yum 의 기본 사용법은 대동소이하다고 하겠다.

이정도만 알아도 패키지를 다루는데는 문제가 없을 것이다.

Ubuntu, systemd-networkd 전환하기

Ubuntu 16.04 로 넘어오면서 SysV 의 Init 이 Systemd 로 변경되었다. 이런 변화에는 Network 관리에도 적용되고 있는데, 이에 대해서 알아보자.

기존의 Network 관련된, 정확하게는 Network Interface 와 관련된 일은 NetworkManager 가 담당했다. Network Interface 가 무엇인지, 아이피는 DHCP 혹은 Static 인지 등이 그것이다.

하지만 Ubuntu 16.04 로 넘어오면서 시스템에 관련된 일체가 systemd 로 통합되면서 네트워크 관련 작업도 systemd 로 통합되어지게 되는데, 이것이 systemd-networkd 이 이다.

하지만 Ubuntu 18.04 로 넘어온 시점에서도 NetworkManger 는 이전과 호환을 위해서 살려뒀고 살려둔김에 지금도 기본적인 네트워크 설정 프로그램으로 활약(?) 하고 있다.

Network Manager

Network Manager 의 동작은 다음의 명령어로 이루어진다.

관련 설정은 /etc/NetworkManger/NetworkManger.conf 파일이다. 위 프로그램을 실행하게 되면 기본적으로 이 파일을 읽게 되어 있다.

그리고 netplan 설정에서도 NetworkManager 를 기본으로 지정하도록 되어 있다.

Network Manager 비활성화

비활성화는 다음과 같이 하면 된다.

이렇게 하면 네트워크가 비활성화 됨으로 절대로 원격지 서버에서 하면 안된다.

systemd-networkd 활성화

netplan

systemd-networkd 를 활성화하면 이제 네트워크 작업은 netplan 명령어를 통해서 이루어진다. 이 netplan 명령어는 기본적으로 ‘/etc/netplan’ 디렉토리에 파일을 읽어서 네트워크 설정을 적용해 준다.

‘/etc/netplan’ 디렉토리에 설정파일은 기본적으로 yaml 파일형식을 가진다. 예를 들면 다음과 같다.

파일을 수정한 후에는 다음과 같이 명령어만 주면 적용이 된다.

‘–debug’ 는 제외해도 된다.

쿠버네티스(Kubernetes) 개념

쿠버네티스(Kubernetes) 처음 접하면 개념 잡기를 해야 한다. 쿠버네티스를 잘 사용하기 위한 사용법을 익히는것도 중요하지만 개념을 이해하고 나면 외워서 문제해결을 하는 것이 아닌 응용력이 생겨 예기치 않은 장애를 겪을때에 힘을 발휘한다.

개인적으로 쿠버네티스의 개념을 이해하는데 약간의 혼란이 있었다. 개념을 설명하는 용어와 실제 작업을 할때에 사용하는 단어, 명령어들이 다 틀리게 사용되고 있는데서 오는 것이였다.

Master/Worker

다들 알다시피 쿠버네티스는 Master Node와 Work Node 로 구성된다. 대부분 Work Node 가 Master Node 보다 훨씬 많고 대부분의 서비스들이 여기에 배포되어진다.

Node 라는 단어를 빼버리고 단순히 Master/Worker 라고도 하지만 그냥 Master/Node 라고 하기도 하는 모양이다. 하지만 정확하게는 Master Node, Worker Node 라고 불린다.

또, Master Node 를 Controller 라고도 한다. Master 의 역활이 Worker Node 를 모니터링, 감시를 하고 각종 명령어을 Master 가 받아서 처리한다. 이 Master Node 는 거대한 Controller 서버 역할이라고 보면 된다.

kubectl – ResTful API

Master 가 거대한 Controller 서버라면 클라이언트를 이용해서 이 서버에 명령을 보내면 될 것이다. 이 클라이언트가 바로 kubectl 이라는 커맨드가 수행한다. 서버-클라이언트 구조상 서버는 1대지만 클라이언트는 여러대 일 수 있다. 실제로 kubectl 은 단일한 명령어로서 도커(Docker), 컨테이너(Container) 등도 필요없이 동작한다. 그래서 클라이언트는 어느 머신이든지 다 설치/사용이 가능하다.

kubectl 은 클라이언트, Master Node 는 Controller 서버다. 이 둘이 명령어를 주고 받는 방법이 바로 RESTFul API 통신 방법이다.

ResTful API 는 HTTP 를 이요해 URI 에 자원(Resources) 을 명시하고 메소드(Method) 를 이용해 CRUD 연산을 수행한다.

쿠버네티스(Kubernetes) 에서 중요한 것이 바로 자원이다. ResTful API 를 이용해 어떤 작업을 명령할때에 반드시 대상이 필요한데, 이것이 바로 자원이다.

Object, Resource, Kind

쿠버네티스(Kubernetes) 에서 개념을 설명할때에 오브젝트(Object) 라는 말을 쓴다. 오브젝트라고하면 쿠버네티스를 구성요소쯤으로 이해하면 된다. 예를들어 Pods, Service, Volume, Namespace 등은 쿠버네티스의 기본 오브젝트라고 불린다.

문제는 이러한 오브젝트들이 때로는 자원(Resource), 때로는 종류(Kind) 로 불린다.

자원 ResTful API 관점에서 실체적인 존재로서 호출하는 오브젝트들이다. 실제로 kubectl 커맨드를 사용할때에는 ‘오브젝트를 명시한다’ 하지 않고 ‘자원을 명시한다’라고 한다. ResTful API 개념을 차용했기 때문에 ‘자원을 명시한다’라고 해야 맞다.

위 결과를 보면 자원(Resource) 목록에서 오브젝트들도 볼 수 있다. 물론 오브젝트는 개념화된 추상적 그야말로 개념이고 자원을 실체적인 대상으로서 차이를 보이지만 이들에 명명된 말이 모두 같다. 맨 오른쪽에 KIND 도 보인다.

종류(Kind) 는 보통 Pods 를 생성하거나 업데이트를 하기위한 매니페스트(Manifest) 파일 작성시에 사용된다. 종류(Kind)는 쿠버네티스 자원 종류를 말한다. 매니페스트 파일은 JSON, YAML 포맷형태인데 예를들면 다음과 같다.

kind: Pod 라는 것이 보인다. 매니페스트 파일에서 자원이라고 하면 그야말로 컨테이너가 사용할 컴퓨터 하드웨어 자원을 말한다. 그래서 Resource:Pod 라고 한다면 문제가 되니까 Kind 라는 것으로 바꾼거 짐작이 된다.

이 kind 가 궁금하다면 ‘kubectl api-resources’ 명령어를 호출하면 자원에 붙여진 kind 를 볼 수 있다.

어느 방향으로 이해하느냐가 관건

쿠버네티스가 다루는 자원의 방향으로 접근해 이해하는 것도 괜찮다. 아니면 추상화 개념으로서 개념을 이해하고 가는것도 괜찮다.

다만, 완전히 추상적인 개념과 실제적인 대상을 구분하고 연결짓는 것이 머리속에 체계적으로 저장하는 방법이 될 수 있다.

kubectl 원격 접속 설정

kubectl 은 Kubernetes Client 이다. 이 명령어는 HTTP 통신을 기반으로 Kubernetes Controller 와 RestFul API 통신을 요청하고 결과를 받아 사용자에게 출력하게 하는 역할을 한다.

HTTP RESTFUL API 통신을 한다는 말을 듣는 순간 직감했겠지만 인터넷만 된다면 kubectl 은 어느 컴퓨터에서든 실행이 가능하다. 처음 Kubernetes 설치문서들을 보면 대부분 Master Node 에서 실행되도록 설정을 하는데, 여기서는 다른 컴퓨터에서 kubectl 만 설치해서 Kubernetes Controller 와 연결하는 방법에 대해서 살펴보도록 할 것이다.

설치환경

설치 환경은 Mint Linux 19.2 – XFCE4 환경에서 진행했다. kubectl 를 실행하는 환경는 다양하겠지만 제일 편한 것으로는 Unix 환경일 것이다. Mac OS X, Linux 가 가장 적합한데, 필자는 Mint Linux 19.2 – XFCE4 데스크탑을 사용하고 있음으로해서 이 환경에서 진행하게 됐다.

Mint Linux 19.2 는 Ubuntu 기반이기 때문에 Ubuntu 에서 설치, 설정 모두 동일하다고 생각하면 된다.

kubectl 설치하기

Mint Linux 19/2 에서 설치하는 방법은 Ubuntu 에서 설치하기와 동일하다. 단, 여기서는 kubectl 패키지만 설치하면 된다. root 계정으로 다음과 같이 한다.

설치는 별다른 이상이 없는한 문제 없이 진행된다.

kubectl 설정하기

kubectl 명령은 일반계정으로 사용하길 권고 하기 있다. kubectl 은 일반 계정에서 .kube/config 파일을 참조한다. 파일의 내용을 볼수도 있지만 다음과 같이 명령어로도 같단히 확인할 수 있다.

config 설정을 kubectl config 명령어를 통해서 가능하지만 복잡해 보인다. 손쉬운 방법을 찾게 되는데, 그 방법은 바로 Master Node 를 초기화 할때에 나오는 것을 참고하면 된다.

Master Node 초기화 때 나오는 출력에 설정관련 내용이 나온다. Master Node 에서 Mint Linux 19.2 에 일반계정으로 config 를 복사해보자.

이렇게 한 후에 다음과 같이 샘플 명령어를 쳤을때에 나오면 정상이다.

Kubernetes 설치

Kubernetes 설치에 대해서 다룬다. 설치를 위한 환경은 다음과 같다.

  • Master
    • Distribution: Ubuntu 18.04
    • IP: 192.168.96.14
    • hostname: kmaster
    • account: systemv
  • Worker Node
    • Distribution: CentOS 7
    • IP: 192.168.96.15
    • hostname: knode
    • account: systemv
  • CNI: Flannel

공통 설정 부분

sudo 권한 추가

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

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

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

Ubuntu 18.04 에서는 다음과 같이 일반계정을 sudo 권한을 줄 수 있다.

br_netfilter 모듈 로딩

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

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

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

커널 네트워크 파라메터

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

/etc/hosts 파일 편집

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

swap off 설정

양쪽 모두 swap 을 off 해준다.

그리고 반드시 /etc/fstab 에서 swap 관련 마운트 설정을 주석처리 해준다.

CentOS 7 에서 설정

SELinux off

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

firewalld 비활성화

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

패키지 설치

Ubuntu 에서 설정

패키지 설치

Docker 설치 및 설정

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

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

ubuntu 18.04

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

하지만 파일을 추가하는 방법으로 가능하다.

CentOS 7

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

다음과 같이 파일을 추가하는 방법도 있다.

Cgroup driver 설정

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

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

Kubernetes 설치

Ubuntu 18.04

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

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

CentOS 7

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

Master 설정

Master 를 만드는 것은 kubeadm 을 이용한다. 일반 계정으로 실행 한다.

Kubernetes Master 명령은 전부 일반계정으로 하도록 되어 있는데, 위 출력에 나온대로 설정을 해준다.

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

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

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

Flannel 설치

CNI 중에 Flannel 을 이용하려고 한다. 다음과 같이 설치를 해준다.

설치를 하고 기다리면 다음과 같이 오류가 발생한다.

잠깐 시간을 주고 기달리면 모두 Running 상태가 된다. 만일 오랜 시간이 지나도 Running 이 아니라면 kubelet 을 재시작 해준다.

Kubelet cgroup driver 교체

혹시나 kubelet 의 cgroup driver 를 교체 해줘야 한다면 다음의 파일을 열어서 드라이버를 교체 해주면 된다.

Ubuntu 18.04, Static IP 할당하기

Ubuntu 18.04 의 경우 네트워크 인터페이스 관련 작업은 netplan 으로 바뀌었다. 만일 Static IP 를 할당하고 싶다면 netplan 의 설정 파일을 수정하고 적용하면 된다.

/etc/netplan/*.yml

여기서 파일을 수정하면 된다. 대략 다음과 같은 포맷을 갖는다.

dhcp4: yes 로 되어 있는 경우에는 DHCP 로 아이피를 받아온다. 하지만 이것을 no 바꾸면 Static IP 를 할당할 수 있다.

netplan 적용

수정을 다 했다면 다음과 같이 적용해 준다.

Ubuntu 18.04 ethernet 이름 변경하기

Ubuntu 18.04 를 설치하면 ethernet 인터페이스 이름이 과거 eth0 가 아닌 ens3 과 같이 나온다. 하지만 아직도 많은 프로그램들이 기본적으로 eth0 를 기본으로 찾기도 한다. eth0 변경하는 방법에 대해 다룬다.

GRUB 파라메터 수정

다음과 같이 Grub 에 파라메터를 추가 한다. Grub 에 파라메터는 /etc/default/grub 파일에서 다음과 같이 추가할 수 있다.

수정된 사항이 Grub 에 반영하기 위해서 업데이트를 수행한다.

여기서 중요한 것이 바로 재부팅을 하면 안된다. 특히나 DHCP 환경에서는 다음의 단계를 수행한 후에 재부팅을 해야 한다.

netplan 수정

netplan 은 Ubuntu 17.04 에서 소개된 기능으로 네트워크 인터페이스 관련 작업을 해준다. 이 프로그램은 /etc/netplan/*.yml 파일을 참조하는데, Ubuntu 18.04 의 경우에 /etc/netplan/01-netcfg.yaml 파일을 참조 한다.

eth0 부분이 수정한 것이다. 이렇게 수정을 다 했으면 다음과 같이 명령어를 수행해 준다.

이렇게 한 후에 재부팅을 하면 DHCP 환경에서 문제 없이 eth0 인터페이스 이름으로 네트워크가 정상 동작한다.

Trac 에서 Ticket 삭제하기

Trac 을 사용하다보면 Ticket 을 삭제하고 싶을때가 있다. Ticket 삭제 플러그인이 존재하지만 Ticket 이란게 자주 삭제를 하는 것이 아니여서 굳이 이것을 설치해서 사용해야할 만큼은 아닌듯 한데, 그런데도 잘못된 Ticket 을 삭제해야한다면 다음과 같이 하면 된다.

trac-admin 을 활용하면 된다.

출처: Deleting trac tickets created since a certain date until today

두번째 방법으로 ‘ticket.deleter’ 를 활성화하면 된다. 이는 Trac 에서 공식지원하는 것으로 Ticket 웹화면에서 Reply 버튼 옆에 Delete 버튼이 나타난다. 이를 위해서는 trac.ini 설정파일에 다음과 같이 설정해준다.

Grub2 에 기본 커널 지정하기

Grub2 은 리눅스 시스템의 부팅 메니져이다. 리눅스는 커널을 여러개를 설치하고 부팅시에 선택해서 원하는 커널로 부팅을 할 수 있도록 해준다. 비상 복구가 필요할 경우에도 부팅 메니져인 Grub2 에서 비상복구 모드를 선택하면 된다.

문제는 어떻게 기본 커널을 지정할 수 있을까?

먼저, 기본 부팅 커널은 다음과 같이 확인할 수 있다.

만일 부팅 상황이라면 위에 설정한 커널을 기본으로 부팅을 진행하게 된다. 만일 이 기본 커널을 변경하고자 할 경우에는 어떻게 할까?

우선, 현재 Grub2 에 등록된 커널 목록들을 알아야하는데 다음과 같이 하면 알 수 있다.

커널 목록을 확인할 수 있는데, 맨 위쪽부터 0 을 시작으로 번호를 붙일 수 있다. 이러한 번호는 기본 부팅 커널을 바꾸는데 유용하게 사용된다. 이제 기본 부팅 커널을 다음과 같이 바꿀 수 있다.

확인을 한번 해보면 다음과 같다.

이렇게 한 후에 다시 Grub 을 설치해줘야 한다.

정상적으로 되었다면 기본 부팅 커널이 바꾼 것이다.

systemctl tomcat no bind 8005 port

Tomcat 을 설치하고 난후에 systemd 에 유닛으로 등록하고 나고 서비스를 시작하고 shutdown 을 하려고 할때에 다음과 같은 오류를 만날 수 있다.

8005 포트로 접속을 할 수 없어서 셧다운시에 오류를 발생시키는 것이다. 왜 이런문제가 발생할까? systemd tomcat 유닛의 내용은 다음과 같다.

그리고 이 상태로 다음과 같이 tomcat 을 서비스로 시작 한다.

이렇게 하고 난후에 netstat 명령어로 포트 리스닝 상태를 살펴보면 8005 포트가 보이지 않는다. 더 큰 문제는 shutdown 포트가 올라오지 않으면 Tomcat 이 작동하지 않는데 있다.

해결 방법은 의외로 간단하다. 다음과 같이 systemd tomcat 유닛 파일에 WorkingDirectory 를 CATALINA_BASE 로 해주면 된다.

이렇게 하게되면 tomcat 이 shutdown 포트까지 올라오면서 정상적으로 다 구동되게 된다.

ps, 이걸 몰라 3시간을 해멧다.