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 프로토콜 주소만 리스닝한다.

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

참고: Configuring and Administering Oracle Net Listener

생성하기

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

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

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

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

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

위 내용을 생성한 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 를 사용한다.

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

Local Naming Prarameters in the tnsnames.ora 파일

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

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

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

listener.ora, tnsnames.ora 차이

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

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

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

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

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

오라클 기본 정보 확인

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

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

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

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

데이터베이스 이름 확인

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

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

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

컨테이너 확인

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

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 구조에서 현재 내가 어느 곳에 연결되어 있는지 아는 건 중요 하다. 다음의 명령어로 확인해 볼 수 있다.

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

컨테이너 타입 확인하기

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

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

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

CDB 와 연결된 PDB 상태 보기

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

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

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

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

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

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

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

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

PDBS 에 있는 사용자들 보기

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

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

각 PDB 의 데이터 파일 보기

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

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

CDB 에 임시 파일들 보기

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

컨트롤 파일 확인

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

Redo Log 파일 확인

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

PDB에 연결된 서비스 보기

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

PDB 의 히스토리 보기

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

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

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

SQLcl 활용

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

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

PDB 로 세션 변경

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

HR 스키마 설치

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

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

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

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

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

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

hr 계정 패스워드 설정 및 UNLOCK

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

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

호스트 네임 변경

Selinux 를 Permissive 로 변경

HugePages 비활성화.

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

PreInstallation RPM 설치

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

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

시스템 그룹 생성

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

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

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

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

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

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

커널 파라메터 수정.

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

Firewalld 설정

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

Oracle Universal Installer (OUI)

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

디렉토리 생성

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

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

.bashrc 파일 설정

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

설치

이제 설치를 진행 해준다.

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

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

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

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

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

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

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

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

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

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

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

시작/중지.

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

Docker, Kubernetes 네트워크

인터넷 검색을 하다보면 Docker, Kubernetes 네트워크에 관한 글이 많이 보인다. 기본적인 이론에서부터 응용까지 잘 설명된 글들이 꽤 많은데, 나는 눈에 보이는 상태를 한번 살펴보기로 했다.

Docker 네트워크

Docker 를 처음 설치하면 어떤 상태일까? 먼저 Docker 를 설치한 리눅스 시스템의 네트워크 상태는 다음과 같다.

docker0 라는 네트워크 인터페이스가 생성되면서 172.17.0.1/16 아이피가 할당되었다. 그리고 이 인터페이스는 Bridge 다.하지만 인터페이스는 DOWN 상태다. Docker 를 막 설치하고 난 후에 이런 모습이다.

Bridge 상태는 다음의 명령으로 확인이 가능하다.

nmcli 를 보면 TYPE 에 bridge 라고 나온다. 그리고 이 docker0 인터페이스는 docker 네트워크에서 Bridge 네트워크에 해당한다고 다음과 같이 확인해 볼수 있다.

“com.docker.network.bridge.name”: “docker0” 로 Docker Bridge 가 docker0 호스트 네트워크 인터페이스라는 걸 말해주고 있으며 여기에 붙은 Container 인 doc1 에 대한 정보를 보여주고 있다. doc1 컨테이너의 IP 는 172.17.0.2/16 이다.

bridge 명령어에서는 아무것도 안나온다. 이제 Docker 컨테이너를 하나 실행해 본다.

이렇게 Docker 컨테이너를 하나 생성하면 docker0 브릿지 인터페이스는 Down -> Up 상태로 변경되며 여기에 veth 가상의 인터페이스가 하나 붙는다.

“veth46d3de6@if8” 가 보인다. 이것은 필시 doc1 컨테이너가 실행되면서 생성되었을게 분명하다. 이것과 doc1 과는 무슨 상관일까?

doc1 컨테이너의 네트워크 인터페이스 eth0 는 8번이다. 그리고 if9 로 인터페이스 9번을 가리키고 있다고 명시하고 있다. 아래 호스트 네트워크 인터페이스를 보면 veth 라고 나오는데, if8 로 인터페이스 8번을 가리고 있다. 인터페이스 8번은 doc1 컨테이너의 네트워크 인터페이스를 말한다.

그러니까 네트워크 인터페이스에 번호로 서로 연관성을 보여주고 있다는 걸 알수 있다.

ip 명령어를 통해서 veth 인터페이스만 뽑아 볼 수 있다. veth 는 가상 이더넷(Virtual Ethernet) 인데, Docker 컨테이너가 생성될때마다 가상 이더넷 카드가 호스트에 하나 생성되고 이런 가상 이더넷은 Docker 컨테이너의 기본 네트워크 인터페이스 카드와 연결된다.

docker0 는 Docker 에 기본 Bridge 인터페이스이며 Docker 컨테이너가 하나도 없으면 DOWN 상태가 되며 단 하나의 컨테이너가 실행될 경우에 UP 상태로 변경되고 가상 이더넷을 생성하고 Bridge 에 붙이게 된다.

Kubernetes 네트워크

Kubernetes 를 설치하고 난후에 상태는 Docker 만 설치한 것과 동일하다. Kubernetes 는 CNI 를 설치를 해줘야 한다. CNI 는 Kubernetes 에 네트워크를 담당할 기능을 붙이기 위한 인터페이스로 다양한 네트워크 기능들을 제공하는 프로그램들이 있다.

Flannel, Weave, Calico 등등이 자주 쓰인다.

한가지 의문(?) 혹은 문제는 이 쿠버네티스 CNI 들은 구조가 모두 다르다. 테스트를 위해서 Flannel 을 사용했다.

정상적으로 설치되었다면 Flannel 이 Pod 로 올라온다. 더불어서 CoreDNS 도 정상으로 나온다.

한가지 쿠버네티스에 대해서 짚고 넘어가야 할게 있는데, 쿠버네티스는 마스터 노드라 불리는 Controller 와 워커 노드로 나뉜다. 적어도 2대의 호스트 서버가 필요하고 여기에 설치가 진행 된다.

Flannel 을 설치하고 nginx 파드(pod) 를 생성한 후에 워커 노드 상태다.

위 상태를 보면, cni0 네트워크 인터페이스가 보인다. 이는 Flannel 에서 생성한 것으로 Bridge 다.

위에 보면 Bridge 네트워크 인터페이스를 볼 수 있는데, Docker0 는 DOWN 이며 cni0 는 UP 상태다. 이 cni0 에 연결된 네트워크 인터페이스는 다음과 같이 확인할 수 있다.

이 인터페이스는 필히 nginx 파드에 것이다. master 브릿지로 cni0 를 사용하고 있다.

그러면, flannel.1 인터페이스는 대체 무엇일까? 다음의 명령어로 확인해 보자.

“vxlan id 1 local 192.168.96.39 dev enp0s3” 로컬 호스트의 enp0s3 에 연결된 vxlan 이라고 나온다.

Flannel 은 VXLAN 기반으로 호스트가 서로 다른 파드에 대한 연결을 만들어주게 되어 있다. 마스터 노드에서 다음의 명령어를 실행해 보자.

backend-type: vxlan 이라고 나오고 있으며 VTEP 도 보인다. 이 장치에 대한 Mac 주소도 나오는데, 이것은 flannel.1 에 있는것과 같다.

파드의 네트워크는 veth 장치를 통해서 패킷이 나가고 이것을 cni0 브릿지가 받는다. 그리고 flannel 이 이것을 flannel.1 장치로 보내게 된다.

이렇게 하는 이유가 있는데, Flannel 은 L2 Layer 스위치다. L2 Layer 스위치는 ARP 라우팅만 가능하다. 파드(Pod) 가 같은 호스트에 있는 경우에는 ARP 라우팅만으로 서로 통신이 가능하겠지만 호스트가 다를 경우, IP 대역이 변경될 경우에는 원격 호스트에 있는 파드를 ARP 라우팅만으로 찾을 수 없다.

그래서 Flannel 은 L3 Layer 계층의 가상의 스위칭 장비를 만들고, 이렇게 만들어진 각 호스트의 가상의 스위칭을 하나로 연결하는데 이것이 바로 VXLAN 이다. 가상의 스위칭 장비가 flannel.1 네트워크 인터페이스 이다. 이때, cni0 에서 올라온 데이터는 L2 Layer 에서 만든 프레임(Frame)으로 이것을 UDP 패킷형태로 IP 를 붙여 캡슐화 한다. 그리면 flannel.1 인터페이스는 다른 호스트와 연결된 또 다른 flannel.1 인터페이스로 브로드캐스팅을 한다.

다른 호스트로 받은 UDP 패킷은 flannel.1 장치에 의해서 까지고(디캡슐화) 자신의 네트워크 대역과 비교하는데, 맞으면 받은 프레임에 destination mac address 를 자신의 mac address 로 넣고 다시 UDP로 캡슐화해 돌려보낸다. 이렇게 함으로써 호스트가 다른 파드의 이더넷 주소(맥주소)를 얻게되어 연결이 이루어지는데, 이게 VXLAN 의 동작 방법이다.

VXLAN 는 L2 Layer 프레임을 UDP L3 Layer 로 캡슐화해 브로드캐스팅하고 목적지 맥주소를 얻는데 있다.

Flannel 은 이렇게 작동하지만 Calico 는 또 다르다. Calico 는 BGP 연결을 통해서 아예 L3 Layer 를 구현 한다. 완전한 Pure L3 Switch 기능을 제공하기 때문에 처음부터 IP 라우팅이 가능해진다. Calico 는 Tunnel.0 인터페이스를 통해서 서로 다른 호스트와 Peer to Peer 연결되어 있어서 IP 라우팅만으로 대상 호스트의 파드를 알아낼 수 있다. 그래서 동작 방법은 (Flannel 보다) 훨씬 간단하다.

메트릭 서버(Metric Server) 설치에 관한 오류들…

다양한 메트릭 서버 설치에 관한 오류들을 알아보자.

kubectl top node Error from server (ServiceUnavailable): the server is currently unable to handle the request (get nodes.metrics.k8s.io)

메트릭 서버(Metric Server) 의 파드(Pod)가 정상적으로 Running 상태라 하더라도 이와같은 오류 메시지를 만날 수 있다. 이 오류는 kube-apiserver 의 로그에 다음과 같이 관련 오류가 나온다.

뒤쪽에 삭제된 부분은 “net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)” 이다. 응답커넥션을 맺다가 안되서 timeout 으로 끝난 것이다.

이것은 kube-apiserver 다음의 커맨드 파라메터를 추가해줘야 한다.

  • –enable-aggregator-routing=true

메트릭 서버의 0.4.3 버전부터는 쿠버네티스의 Aggregator Layer 를 이용한다. API 서버가 실행중인 호스트에 kube-proxy 가 없을 경우에 위 파라메터를 추가해줘야 한다.

워커 노드 메트릭 수집 안됨

쿠버네티스의 Deployments.apps 리소스에 배포된 Metric Server 메니페스트를 다음과 같이 수정해 줘야 한다.

hostNetwork: true 를 추가해줘야 한다.

extension-apiserver 란?

쿠버네티스(Kubernetes)가 발전에 따라서 많은 변화를 겪었다. 최신의 버전에서 extension apiserver 라는 것을 필요로하는 경우가 많다. 이것은 쿠버네티스 문서에서는 aggregation layer 라고 설명하고 있다.

Configuring the aggregation layer allows the Kubernetes apiserver to be extended with additional APIs, which are not part of the core Kubernetes APIs

애그리게이션 레이어 설정은 쿠버네티스 API 코어의 일부가 아닌 추가적인 API를 가지고 확장될 수 있는 쿠버네티스 apiserver 를 가능하게 한다.

Configure the Aggregarion Layer

최근에 구축한 쿠버네티스 서버에 메트릭 서버(Metric Server) 를 설치했는데 제대로 작동되지 않아 왜 그런가 봤더니 바로 이 문제였다. 메트릭 서버 파드(Pod) 에 로그는 다음과 같다.

메시지를 보면 extension-apiserver-authentication 등의 메시지를 볼 수 있다. 문제는 이런 로그가 남는다고 해서 메트릭 서버 파드의 상태가 Running 으로 된다는 것이다. 파트 상태가 Running 이라고 해서 메트릭 서버가 정상으로 작동되는 것은 아닌게 문제의 핵심이다.

이 문제를 해결하기 위해서는 extension-apiserver 기능을 apiserver 가 가지도록 해야 한다. 이것은 kube-apiserver 에 커맨드 파라메터를 다음과 같이 추가 해주고 재시작 해줘야 한다.

요구사항을 보면 인증서가 필요하다는 것을 알게 된다. 인증서 제작은 Kubernetes Hard Way 문서에 잘 정리되어 있다. 필자는 쿠버네티스 하드 웨이 방법을 구축한 서버이기에 이 과정을 진행해 볼 수 있었다.

extension apiserver 를 위한 인증서 작성

인증서 작성은 다음과같이 CSR 파일을 작성함으로서 시작된다.

여기서 주의해야 할 것이 조직(O) 를 system:masters 로 해야 하며, CN 은 –requestheader-allowed-names 파라메터의 값과 동일해야 한다. 이제 다음과 같이 인증서를 제작한다.

이제 이것을 각 master 서버에 배포를 해준다.

kube-apiserver 커맨드 파라메터 수정

배포를 모두 했다면, 이제 kube-apiserver 에 커맨드 파라메터를 수정해 줘야 한다. systemd 에 kube-apiservere 를 등록했기 때문에 유닛 파일을 수정해주면 된다.

정상적으로 구동이 되었다면 이제 메트릭 서버를 재설치하면 정상적으로 작동 된다.

AWS CloudFormation 보안 모범 사례

이 문서는 다음의 내용을 번역한 것입니다.

AWS CloudFormation을 사용하면 개발자와 시스템 관리자가 AWS와 연관된 리소스 모음을 질서있고 예측 가능한 방식으로 프로비저닝하고 업데이트하여 쉽게 생성하고 관리 할 수 ​​있다. 우리의 많은 고객들은 그들의 AWS 환경에서 변경사항을 간단하게 캡쳐하고 버전 제어를 실행하고 인프라에서 다른 작업 중에서도 비용을 관리하는 등에 모든 리소스를 제어하기 위해 CloudFormation 을 사용한다.

고객들은 자주 어떻게 CloudFormation 스택에 허가권을 제어하는 우리에게 묻는다. 이 글에서, 우리는 CloudFormation 에 대한 AWS Identity 와 IAM 정책을 사용, CloudFormation 에 특화된 IAM 조건 그리고 CloudFormation 스택 정책들을 포함하는 몇가지 모범사례를 공유한다. 대부분의 CloudFormation 배포는 AWS CLI 나 SDK 를 통해서 이루어지기 때문에 우리는 모범 사례를 어떻게 구현하는지 보여주기 위해서 AWS CLI 와 SDK 사용에 포커스를 둘 것이다.

IAM 을 통한 CloudFormation 스택 접근 제한

IAM 을 통해서, 여러분은 정책이나 사용자 혹은 롤(role) 을 사용함으로써 AWS 서비스나 리소스 접근을 보안적으로 통제할 수 있다. CloudFormation 은 fine-grained(세분화된) 액세스 제어를 제공하기 위해서 IAM 을 지렛대로 사용한다.

모범사례를 통해서, 우리는 최소 권한 원칙을 적용된 IAM 정책들을 통해 AWS 서비스 및 자원 접근을 제한하기 권한다. 이것을 하는 가장 단순한 방법은 CloudFormation 에 특정 API 콜을 제한하는 것이다. 예를들어, 여러분은 특정 IAM 유저나 롤이 CloudFormation 스택을 삭제하거나 업데이트하길 원하지 않을 것이다. 다음의 단수한 정책들은 모든 CloudFormation API 접근을 허용하지만 여러분의 프로덕트 스택의 UpdateStackDeleteStack API 접근은 거부한다.

IAM 정책은 종종 특정 리소스를 생성할 수 있도록 허용해야 하지만 이러한 리소스를 CloudFormation의 일부로 생성하지 않을 수 있다. 이것이 CloudFormation 의 IAM 조건 지원이 제공된다.

CloudFormation 을 위한 IAM 조건

다음은 여러분의 IAM 정책에 추가할 수 있는 세가지 CloudFormation 특화된 IAM 조건들이다.

  • cloudformation:TemplateURL
  • cloudformation:ResourceTypes
  • cloudformation:StackPolicyURL

이러한 세가지 조건을 통해서, 여러분은 특정리소스 생성, 업데이트, 특정 템프릿 사용등과 같은 스택 작업을 API 로 가능해지거나 스택 업데이트 중에 의도하지 않게 업데이트나 삭제가 될수 있는 스택 리소스를 방지하는 스택 정책을 사용해 특정 리소스를 제한할 수 있다.

Condition: TemplateURL

첫째 조건, Condition: TemplateURL, 생성, 업데이트, reside 등과 같은 스택 작업에 대해 CloudFormation 템플릿을 지정하도록 하고 그것만 사용하도록 강제한다. IAM 정책에서, 다음과 같다.

첫번째 구분은 지정된 템플릿에 한해서 모든 CreateStack 과 UpdateStack API 콜을 활성화 한다. 두번째 구분에서 모든 CreateStack 이나 UpdateStack API 콜들은 TemplateURL 파라메터를 반드시 포함하도록 한다. CLI 에서 여러분의 호출들은 –template-url 파라메터를 포함해야 한다.

Condition: ResourceTypes

CloudFormation 은 IAM 정책을 통해서 템플릿 생성, 업데이트에 리소스 타입을 제어할 수 있도록 해준다. CloudFormation API는 ResourceTypes 파라메터를 받는다. API 호출에서, 생성이나 업데이트할 수 있는 리소스 유형을 지정할 수 있다. 하지만, 새로운 ResourceTypes 파라메터를 사용하기 위해서는 다음과 같이 컨디션 조건을 추가함으로서 특정한 파라메터 사용이 가능하도록 IAM 정책을 수정할 필요가 있다.

CLI 에서, 여러분의 호출은 –resource-types 파라메터 포함할 필요가 있다. 여러분의 스택을 업데이트하기 위한 호출은 다음과 같다.

쉘(Shell)에 따라서 명령어는 쌍따옴표를 사용해야할 수도 있다. 그렇지 않으면 “No JSON object could be decoded” 에러를 보게 될 것이다.

ResourceTypes 조건은 CLI 나 API 호출을 통해서 CloudFormation 이 올바른 리소스 타입과 템플릿을 생성, 업데이트 하도록 합니다. 첫번째 예제에서, 우리의 IAM 정책은 AWS::IAM 리소스를 포함한 예제였기 때문에 API 호출을 차단했을 것이다. 만약 우리의 템플릿이 오직 AWS::EC2::Instance 자원만 포함한다면, CLI 명령어는 다음과 같을 것이며 성공할 것입니다.

세번째 조건은 StackPolicyURL 조건이다. 어떻게 동작하는지 설명하기 전에, 우리는 스택 정책에 대해 몇가지 추가적인 컨텍스트를 제공할 필요가 있다.

Stack Policies

가끔, 최악의 운영 중단은 의도되지 않은 리소스에 변경으로 발생 된다. 이 리스크를 완화하는데 도움이 되기 위해, CloudFormation 은 스택 정책들을 제공는데 이것은 스택 업데이트 중에 의도치않은 업데이트나 삭제로부터 스택 리소스들을 보호해준다. IAM 과 함께 사용할 경우, 스택 정책들은 스택 리소스에 대해 악의적이고 의도치않은 변경 모두에 대해 두번째 방어 계층을 제공 한다.

CloudFormation 스택 정책은 스택 업데이트 작업의 일부로 업데이트할 수 있는 항목을 정의하는 JSON 문서다. 정책을 지정하거나 업데이트하기 위해서, 여러분의 IAM 사용자 혹은 롤(Role)은 반드시 우선적으로 Cloudformation::SetStackPolicy 액션을 호출 할 수 있어야 한다.

여러분 스택에 직접 스택 정책을 적용한다. 주의해야할 것은 이것은 IAM 정책이 아니다. 기본적으로, 스택 정책 설정은 명시적으로 Allow 지정하지 않는 한 업데이트를 거부하기 위해 Deny 를 사용해 모든 스택 리소스들을 보호한다. 이것은 만약 오직 몇가지 리소스들만 제한 하길 원한다면, 리소스 “*” 를 사용해 Allow 를 포함으로써 모든 업데이트를 반드시 명시적으로 허용해야 하며 특정 리소스를 Deny 해야 한다.

예를들면, 스택 정책은 라이브로 진행되는 데이터를 포함하고 있기 때문에 프로덕션 데이터베이스를 보호하는 데 종종 사용된다. 변경중인 필드에 따라 업데이트중에 전체 데이터베이스를 교체할 수 있는 경우가 있다. 다음의 예제는, 스택 정책은 명시적으로 프로덕션 데이터베이스 업데이트 시도를 거부한다.

여러분은 모든 RDS DB 인스턴스나 주어진 ResourceType 을 포함하도록 여러분의 스택 정책을 일반화 할 수 있다. 이것을 얻기 위해서는 컨디션 사용한다. 그러나, 우리의 예제는 와일드카드를 사용했기 때문에, condition 은 반드시 “StringEquals” 이 아닌 “StringLike” condition 을 사용해야 한다.

스택 정책에 대한 보다 많은 정보는  Prevent Updates to Stack Resources 참고하라.

마지막으로, 여러분의 모든 스택에 알맞은 미리 정의된 스택 정책을 가지고 있는지를 확인해라. 이것을 해결할려면 IAM 정책을 봐야 한다.

Condition:StackPolicyURL

여러분의 IAM 정책 내에서, 여러분은 모든 CloudFormation 스택이 StackPolicyURL 조건을 가지고 생성된 것과 연결된 스택 정책을 가지는지를 확인할 수 있다.

이 정책은 SetStackPolicy 가 호출될때마다 반드시 스택 정책 URL 이 지정되어 있는지 확인한다. 이 경우에, URL 은 https://s3.amazonaws.com/samplebucket/sampleallowpolicy.json 다. 유사하게, 모든 생성과 업데이트 스택 연산에서, 이 정책은 StackPolicyURL 은 S3 에 sampledenypolicy.json 문서로 지정되었고, StackPolicyURL 은 항상 지정된다. CLI 에서 create-stack 명령어는 다음과 같다.

주의해야 할 것은 만약 스택 업데이트에 새로운 스택 정책을 지정한다면, CloudFormation 은 이미 있는 스택 정책을 사용한다. 새로운 정책은 오직 이후 업데이트에만 새 정책을 사용한다. 예를들어, 현재 정책이 모든 업데이트를 거부하도록 지정되어 있다면, 딱 한개 업데이트를 허용하기 위해서 스택정책을 변경할려면 반드시 SetStackPolicy 명령어를 실행해야 한다. 그리고 여러분은 스택에 대해서 업데이트 명령어를 실행할 수 있다. 이미 생성된 스택 업데이트를 위해서 다음과 같이 실행 할 수 있다.

그리고 업데이트를 실행할 수 있다.

우리가 사용하는 IAM 정책은 스택이 생성 혹은 업데이트 될때마다 스택에 적용되어질 특정한 스택 정책을 보장한다.

Conclusion

CloudFormation 은 연관된 AWS 리소스를 생성, 관리하는 반복적인 방법을 제공한다. IAM 정책, 사용자, 롤, CloudFormation-specific IAM condition, 스택 정책을 조합해 사용함으로써, 여러분은 CloudFormation 스택을 의도한데로 사용하고 잘못된 업데이트, 삭제를 최소할 수 있다.

You can learn more about this topic and other CloudFormation best practices in the recording of our re:Invent 2015 session, (DVO304) AWS CloudFormation Best Practices, and in our documentation.

AWS EKS 클러스터 셋업

How to setup

AWS 의 EKS Cluster 를 셋업할 수 있는 방법에는 다음과 같다.

  • AWS Management Console
  • eksctl utility provided by AWS
  • IaC (Terrform, Ansible)

여기서는 AWS Management Console 를 이용한 방법을 사용할 것이다.

Prerequirement

AWS 를 사용하기 위해서는 권한이 있어야 한다. 다음과 같은 권한이 일단 필요하다.

  • AWS Account with Admin Privileges
  • AWS Cli Access to use Kubectl utility
  • Instance (To manage cluster by using Kubectl)

AWS 계정은 될수 있는한 관리자 권한이 필요하다.

Create IAM role for EKS Cluster

EKS Cluster 를 위한 IAM를 생성해야 한다. 이것은 IAM 서비스에서 역할(Role) 을 이용해서 생성한다.

각각의 허가권(Permission) 을 설정할 필요 없이 사용사례선택에서 EKS – Cluster 를 선택하고 Role 이름을 설정하면 끝나게 된다.

다음으로 일반 사용자가 이 Role 을 위임받을 수 있도록 신뢰관계를 맺어준다.

systemv 사용자에 대해서 신뢰관계를 만들어 줬다.

Create Dedicated VPC for the EKS Cluster

VPC 를 생성해야 하는데, 하나하나 생성할 수도 있다. 하지만, EKS 를 위해서 AWS 는 CloudFormation 템플릿을 제공하고 있다. 이 정보는 다음의 링크를 통해서 확인할 수 있다.

위 내용을 보면 S3 에 CloudFormation 용 템플릿을 제공한다. 이를 이용하면 손쉽게 VPC 를 생성할 수 있는데 생성되는 리소스는 대략 다음과 같다.

  • 퍼블릭 서브넷 2개, 모든 서브넷에는 로드밸런서 할당을 위해 태그가 지정된다.
  • 엘라스틱 IP 할당.
  • 프라이빗 서브넷 2개, 모든 서브넷에는 내부 로드밸러서 할당을 위해 태그가 지정된다.
  • NAT 게이트웨이 1개
  • 모든 인바운드 트래픽을 차단하고 아웃바운드 트래픽을 허용하는 보안그룹.

AWS EKS 는 Master Node, Worker Node 로 구성되는데, Master Node 는 Managed 서비스이며 이것은 퍼블릭 서브넷이 필요하게 된다. Worker Node 는 EC2 인스턴스에 Docker 가 설치되며 EKS 에 의해서 제어된다. 이것은 프라이빗 서브넷이 필요하게 된다.

모든 인바운드 트래픽은 차단되고 아웃바운드 트래픽을 허용하기 위해서 NAT 게이트웨이가 설치가 된다.

CloudFormation 을 이용해 이런 제반사항들을 손쉽게 만들 수 있다.

AWS EKS 생성을 위한 CloudFormation 스택 이름 변수 정하기
AWS EKS 생성을 위한 CloudFormation 스택 이름 변수 정하기

스택이름만 쓰고 나머지는 그냥 기본적으로 제공하는 값을 사용해도 된다. 다음화면에서 태그나 기타 필요 옵션등을 선택할 수 있는데, 아무것도 안하고 넘어가도 된다.

CloudFormation 을 이용한 AWS EKS VPC 생성완료
CloudFormation 을 이용한 AWS EKS VPC 생성완료

생성된 자원들을 보면 어떤 것을 생성했고 어떻게 연결을 했는지도 눈에 보인다. SecurityGroup 은 ControllPlane 에 접근을 위해서 만들어졌다.

Login AWS Account for creating Cluster

앞에 CloudFormation 작업은 AWS Root 계정으로 진행 된다. 어짜피 네트워크 작업이며 이를 제어하기 위한 퍼미션만 사용자가 가지고 있어도 되기 때문이다. 하지만 서비스는 다르다. 서비스는 Role 기반으로 작동되는 경우가 많아 반드시 일반 계정으로 생성을 해야 한다.

만일 AWS Root 계정으로 EKS Cluster 를 생성할 경웨 피고한 경우가 생길 수 있다. 따라서 반드시 일반 계정으로 로그인을 해준다. 그 계정에 다음과 같은 정책을 생성해 준다.

EKS Cluster 를 위한 권한이 대부분 다 들어 있다.

Create EKS Cluster

이제 네트워크 환경이 모두 구성됐으니 EKS Cluster 를 만들어야 한다. AWS 콘솔에서 EKS 를 검색해 서비스로 이동하면 된다.

AWS EKS Cluster 기본정보 입력
AWS EKS Cluster 기본정보 입력

Kubernetes 버전은 최신버전으로 했지만, 실제 서비스 운영은 기본값을 사용하길 권장한다. 클러스터 서비스 역할에는 맨처음에 만들었던 역할을 지정해 주면 된다.

AWS EKS Cluster 네트워킹 지정
AWS EKS Cluster 네트워킹 지정

네트워킹은 CloudFormation 으로 생성한 네트워크를 지정해 줘야 한다.

AWS EKS Cluster 클러스터 엔드포인트 액세스
AWS EKS Cluster 클러스터 엔드포인트 액세스

클러스터 엔드포이트 액세스는 퍼블릭 및 프라이빗으로 선택한다. 그리고 Amazon VPC CNI 는 최신버전으로 선택.

AWS EKS Cluster 클러스터 로깅
AWS EKS Cluster 클러스터 로깅

CloudWatch Logs 는 비활성화해서 넘어간다. 단, 실제 서비스를 운영할때는 활성화를 해준다. 적어도 Authenticator 정도는 해준다.

Install & Setup IAM Authenticator and Kubectl Utility

설치 aws-iam-authenticator 문서를 보고 authenticator 를 설치해 준다.

AWS EKS 를 위한 kubectl 명령어를 다운로드 받는다.

설치된 Client 버전과 AWS EKS 에서 버전이 같은지 확인한다.

이제 kubectl 명령어가 사용되는지를 확인해 본다.

접속을 위한 아무런 정보가 없기 에 localhost 에 접속을 시도했다.

접속을 위한 정보를 받아서 $HOME 에 .kube/config 에 저장이 된다. 이제 잘되는지 다음과 같이 확인해 보자.

위와같이 나오면 정상이다. 만일 위와같이 나오지 않는다면 Role 를 지정해줄 수도 있다.

이렇게 했는데도 안된다면 다음의 링크가 도움이 될지 모른다.

정상적으로 작동한다면 다음과 같이 Node 는 아무것도 안나올 것이고 Namespace 는 나올 것이다.

Create IAM Role for EKS Worker Nodes

EKS Cluster 는 Kubernetes 에서는 Master 작업이 끝난것이라고 보면 된다. 아직은 Work Node 가 없다. Work Node 는 NodeGroup 으로 묶여서 생성되고 Work Node 를 위한 Role 이 필요하다.

AWS Role for EKS WorkNodes
AWS Role for EKS WorkNodes

이와 더블어서 ssm.amazonaws.com, eks.amazonaws.com 을 신뢰관계에 추가 해준다.

많은게 필요가 없다. 이제 worknode 를 위한 group 를 생성해 보자.

AWS EKS WorkGroup 생성하기 - 기본정보 입력
AWS EKS WorkGroup 생성하기 – 기본정보 입력

이름과 역할을 지정해준다. 역할은 앞에서 생성한 역할이 자동으로 나올 것이다.

AWS EKS Workgroups 생성하기 - 컴퓨터 자원 생성
AWS EKS Workgroups 생성하기 – 컴퓨터 자원 생성

서비스 운영을 위한 시스템 자원을 선택해 준다. 이 시스템 작원은 물리적인 하드웨어를 선택하는 것이다. 이 자원 위에서 Docker 를 기반으로 Micro Service 가 돌아가게 된다.

AWS EKS Workgroups 설치하기 - 네트워크 설정
AWS EKS Workgroups 설치하기 – 네트워크 설정

서브넷은 AWS EKS 를 위한 서브넷을 선택되어 있어야 한다. 노드에 대한 액세스가 필요할 경우에 해주면 되고 보안 그룹은 기본보안 그룹(22 port 만 열려 있다)을 선택해 줬다. 서비스를 운영할때에는 적절하게 바꿔준다.

생성이 완료되면 다음과 같이 Node 가 나오게 된다.

이것이 Kubernetes 에서 Master, Work node 작업이 완료된것과 같은 AWS EKS Cluster 가 세팅이 완료가 된 것이다.


이 글은 초기버전이다. 큰 틀에서 대충 이렇게 한다는 것을 보여주는 것 외에는 깊이가 없다.