작은시작

1. 컨테이너란? 

운영체제에서 실행되는 프로세스를 격리하여 별도의 실행 환경을 제공해주며, 해당 프로세스는 운영체제상에서 실행되는 유일한 프로세스인 것처럼 작동한다. 즉, 운영체제에서 실행되는 여러 프로세스는 컨테이너라는 개념으로 격리되어 별도의 운영환경을 제공하는 기술이다.

컨테이너 환경을 제공하는 기술 

chroot

Docker

LCX

Solaris Containers(Zones)

FreeBSD Jail

WPARS(AIX)

rkt

2. 컨테이너 아키텍처

리눅스 시스템에서 컨테이너를 이용하여 격리 구조를 만드는 기법은, 격리를 담당하는 Linux Namespace와 리소스를 제어하는 Control Group(cgroup)을 사용하여 격리된 컨테이너 환경을 제공한다.

네임스페이스 종류

마운트 포인트

프로세스

네트워크 - IPC

UTS

사용자

제어 그룹은 프로세스 또는 컨테이너가 사용할 수 있는 리소스의 양을 제한 할 수 있다. (CPU, 메모리, 네트워크 대역폭, 디스크 입출력)

3. 도커 컨테이너

컨테이너 기술은 오래전부터 존재해왔던 기술이지만 Docker Inc가 만든 도커 플랫폼의 등장으로 컨테이너 플랫폼에 대해 널리 알려지고 쉽게 사용할 수 있게 되었다. 도커는 네임스페이스와 제어 그룹 기술을 사용하여 애플리케이션을 패키징, 배포 실행하는 플랫폼이다.

주요 개념 

이미지 : 실행할 애플리케이션과 라이브러리 및 환경을 하나의 패키지로 묶은 것

레지스트리 : 이미지를 저장하고 공유할 수 있는 스토리지

도커 허브 등과 같은 공용 레지스트리와 개인 및 특정 시스템만 사용할 수있는 사설 레지스트리를 직접 구축할 수 있다.

컨테이너 : 이미지를 실행할 컨테이너 

도커는 컨테이너를 주류 기술로 만든 최초의 컨테이너 플랫폼으로 , 쿠버네티스에서 기본적으로 애플리케이션을 구동하기 위한 구성요소 중 하나이다.

현재 쿠버네티스는 도커 이외에도 컨테이너 형식 및 컨테이너 런타임에 대한 개방된 표준을 만드는 OCI가 생겨, OCI표준의 컨테이너 대부분을 지원한다. (대표적으로 rkt)

컨테이너 vs 가상머신 

가상 머신은 애플리케이션을 동작시키기 위해서 애플리케이션이 사용하는 리소스만 사용하는 것뿐만 아니라 운영체제가 동작하기 위한 리소스가 추가로 필요하다. 그러나 컨테이너는 애플리케이션이 동작하기 위한 리소스만 사용하기 때문에 훨씬 더 빠르고 가볍게 동작한다.

쿠버네티스란?

쿠버네티스는 '조타수' '파일럿'을 뜻하는 그리스어에서 유래하였으며 K8s라고 부르는데 이는 국제화를 110n으로 표기하는 것과 같이 'ubernete' 글자 개수로 대체한 약어이다. 

구글은 전 세계 적으로 수십만 대의 서버를 운영하고 있으며, 소프트웨어와 인프라를 전 세계에 확장될 수 있는 훨씬 진보된 방법을 찾았고 Borg라는 내부 시스템을 개발하여 개발자와 관리자가 수천 개의 애플리케이션과 서비스를 관리하는데 도움을 주었다. 

이후 구글의 Borg 시스템은 쿠버네티스란 이름으로 오픈소스를 공개하고, 이를 Linux 재단 산하의 CNCF 재단에 기증하였다. CNCF는 컨테이너 기술 및 주위 기술에 대한 프로젝트를 담당한다.

쿠버네티스가 제공하는 기본 기능 요약

컨테이너 플랫폼

마이크로 서비스 플랫폼

이식성 있는 클라우드 플랫폼 

즉, 쿠버네티스는 컨테이너 기반의 분산 클러스터 환경을 제공하며 워크로드를 위해 컴퓨팅, 네트워킹 및 스토리지 인프라를 오케스트레이션 한다.

1. 모놀리식 아키텍처

모놀리식 아키텍처는 오늘날에도 널리 사용되고 있는 아키텍처다. 대부분 단일 프로세스에서 실행되거나 몇몇 시스템에서 몇 개의 프로세스로 실행되는 거대한 모놀리식 애플리케이션이었다.

장점

1. 간단한 개발

2. 간편한 배포

3. 단순한 확장성

모놀리식 아키텍처에서는 애플리케이션을 매번 릴리스 할 때 마다 개발자가 전체 애플리케이션을, Java의 경우 WAR파일을 패키징 하거나, Ruby, Node.js의 경우 단일 디렉터리 계층으로 묶어서 배포해야 했다.

단점 

1. 코드 품질이 낮아짐

2. 애플리케이션의 시작이 오래걸림

3. 확장이 어려움

4. 다양한 기술 적용의 어려움

모놀리식 애플리케이션은 모든 것이 서로 강하게 결합하여 구성되어 단일 OS의 단일 프로세스로 실행되기 때문에 모든 것을 하나의 애플리케이션으로 개발 배치 관리되어야 한다. 즉, 조그마한 추가 및 변경에서 전체를 재배포해야 한다.

2. 마이크로 서비스 아키텍처

모놀리식 아키텍처가 크기가 커짐에 따라 발생하는 문제점을 극복하기 위해 기능적으로 세분화되고 독립적으로 구성

세분화되고, 독립적으로 작동하는 마이크로 서비스 기반의 애플리케이션은 API를 통해 서로 다른 마이크로 서비스와 통신하게 된다. 여러 마이크로 서비스 사이에는 일반적으로 동기방식인 HTTP/RESTful API 또는 비동기 방식인 AMQP프로토콜을 이용하여 통신한다. 

장점 

1. 크고 복잡한 애플리케이션을 지속적으로 배포 - 유지보수성, 테스트 용이성, 배포 효율성, 독립 개발, 배포 확장 가능

2. 개발에 대한 생산성 증가 배포 속도 향상

3. 향상된 장애 격리

4. 다양한 기술 적용 가능

단점 

1. 분산 설계 시스템에 따른 복잡성 - 서비스 간 통신 메커니즘을 따로 구현해야 함

2. 배포 및 관리 운영상의 복잡성

3. 증가된 리소스 소비 

3. DevOps

예전에는 개발팀에서 애플리케이션을 개발해 QA에 넘겨주면 테스트 후, 다시 운영팀에게 넘겨주면 애플리케이션을 배포, 관리 및 실행하는 흐름을 가진다. 그러나 최근에는 테스트뿐만 아니라 배포 이상의 작업에 개발자가 관여하고, 애플리케이션의 전체 라이프 사이클을 함께 관리하는 것이 효율적이라는 것을 알게 되었다. 

즉, 이런 소프트웨어 개발, 품질, 운영 팀의 소통 협업 및 통합을 강조하는 개발환경 및 문화를 DevOps라고 한다.

로그 관리 데몬

systemd시스템에서 로그는 rsyslogd 와 systemd-journald두데몬에 의해 관리됩니다.

시스템에서 이벤트가 발생하면 모두 systemd-journald 로 전달됩니다. 이는 부팅 시작부터 로그를 수집하며 이후에 rsyslogd로 syslog를 전달하여 각 파일 별로 로그를 저장합니다.

rsyslogd에 의해 수집되는 로그의 파일 위치

/var/log/messages : 대부분의 로그 기록 (인증,메일,cron,부팅,디버깅과 관련된 로그를 제외)

/var/log/secure : 인증과 관련된 로그를 기록

/var/log/maillog : 메일고 관련된 로그를 기록

/var/log/cron : 주기적인 작업과 관련된 로그를 기록

/var/log/boot.log : 부팅과정에 발생된 로그를 기록

systemd-journald 에 의해 처리되는 저널 데이터 파일의 위치

systemd-journald 에 의해 수집되는 로그는 저널(journal) 데이터라고 부르며, /run/log/journal 디렉토리에 바이너리 파일 형태로 저장됩니다.

저널 데이터 파일이 저장되는 /run 디렉토리는 메모리 기반 파일시스템인 tmpfs로 마운트 되어 있으므로 시스템이 재부팅 되면 저널 데이터 파일은 삭제됩니다.

저장 경로 ->/run/log/journal

[root@localhost ~]# ls -lR /run/log/journal
/run/log/journal:
total 0
drwxr-s---+ 2 root systemd-journal 60 May 17 09:43 9ba7072b23acb44487a132be7e2230ee

/run/log/journal/9ba7072b23acb44487a132be7e2230ee:
total 8192
-rwxr-x---+ 1 root systemd-journal 8388608 May 17 10:16 system.journal

/etc/rsyslog.conf

/etc/rsyslog.conf 파일의 룰(rule)부분에는 rsyslogd 에 의해 전달되는 로그의 규칙들이 저장되어있습니다.

규칙을 정의할 때 공백을 기준으로 앞부분을 필터(Filter)라 하고 뒷부분을 행동(Action) 이라 합니다.

필터(Filter)

필터는 로그 메시지를 분류하기위한 기준입니다. 필터 조건에 따라 로그 메시지가 처리되는 방식을 결정할 수 있습니다.

1. 기능 및 우선 순위 기반 필터

2. 속성 기반 필터 

3. 표현 기반 필터

세가지 형식으로 분류됩니다.

1. 기능 및 우선 순위 기반 필터는 로그의 정류와 로그의 우선순위 를 기준으로 분류하는 방식이며 속성 기반 필터는 로그 메시지에 포함된 호스트 이름,메시지,태그 등의 속성을 기준으로 로그를 분류하는 방식입니다.

기능의 종류

우선 순위 종류

0에 가까울수록 시스템에 영향이 높은 로그 메시지로, 하드웨어 이상에 따른 즉각적인 시스템 중단 경고가 해당되고, 코드값이 7에 가까운 로그 메시지는 일반적으로 사용자에게 표시되어야할 필요는 없지만, 경우에 따라 문제 해결에 유용하게 사용될 수 있는정보입니다.

행동(Action)

행동은 필터에 의해서 선택된 로그들이 처리되는 방법을 정의하는 부분입니다. 주로 파일에 메시지를 저장하거나, 시스템에 로그인된 사용자에게 메시지를 전달합니다.

systemd-journald

systemd-journald는 시스템이 부팅이 시작할 때 부터 발생하는 모든 이벤트를 수집해서 구조화된 바이너리 형태의 저널데이터로 저장합니다. 이 저널 데이터는 구조화 되어있기 때문에 인덱싱을 통해 사용자가 원하는 내용을 쉽고 자세하게 찾을수있습니다.

journalctl

journalctl 명령을 사용하여 저널 데이터를 조회할수 있습니다.

journalctl [option] [argument]

옵션이나 인자없이 사용한다면 현재 저장된 저널 데이터를 순차적으로 출력합니다. 출력은 시간순이다.

-p 옵션을 추가하면 특정 우선순위를 지정하여 로그를 출력할 수 있습니다.

-r : 최근에 발생한 저널 데이터 출력

-f : 실시간 저널 데이터 모니터링

--since ' YYYY-MM-DD hh :mm :ss' 형식을 통해 지정 시점부터의 저널데이터를 조회 할수있습니다.

--since ' ~ ' --until : 특정기간의 저널 데이터 출력

-o : 저널데이터의 출력 설정

저널 데이터의 영구적 저장

저널 데이터가 저장되는 파일은 /run/log/journal 디렉토리에 존재하기 때문에 시스템이 재부팅되면 삭제됩니다. 이를 영구적으로 저장하려면 기존의 저널 데이터가 저장되던 경로인 /run/log/journal 디렉토리와 동일하게 설정하여야합니다.

이를 위해선

1. 기존 디렉터리 설정값 확인 ( ls -ld /run/log/journal/)

2. 저널 데이터 저장 디렉토리 생성 및 설정 변경 (일반적으로 로그 파일들이 저장 되는 /var/log 디렉토리에 저널데이터를 저장할 새로운 디렉토리를 생성하고 설정을 변경합니다 mkdir /var/log/journal)

3. 저널 데이터를 영구적으로 저장하도록 설정한 뒤 systemd-journald 를 재시작하면 즉시 /varlog/journal 디렉토리에 저널 데이터가 저장되고 시스템이 재부팅되어도 유지됩니다. ( journalctl --list-boots )

1. MBR 파티션 (Master Boot Record)

MBR 파티션 방식은 1980년대 초반 IBM PC 호환 컴퓨터의 보급에 의해 널리 사용되게 된 방식입니다. 최근 까지도 대부분의 시스템이 MBR 파티션 방식을 사용하여 디스크 파티션을 구성하고 있습니다.

MBR 파티션의 기능

1. 디스크 전체의 파티션 레이아웃을 파티션 테이블에 저장합니다.

2. 전체 파티션 중 운영체제 데이터를 가지고 있어 부팅 할 수 있는 파티션에 대한 정보를 가지고 있습니다.

3. 운영체제 부팅에 필요한 Boot code를 가지고 있습니다.

MBR 파티션 방식의 경우 첫번째 파티션에서 64byte 만큼을 전체 파티션 테이블 용도로 사용합니다.

그 64byte는 다시 16byte씩 4개의 각 파티션 테이블로 나뉩니다.

MBR파티션의 경우 테이블 구조에 따라 최대4개 까지 파티션을지원합니다. 하지만 4개이상ㅇ의 파티션이 필요할경우 확장파티션 기능을 사용하여 4개이상의 파티션을 사용할수있습니다.

또한, 섹터의 주소를 4byte로 저장하기 때문에 디스크 최대 크기의 제한이 발생합니다. -> 이를 해결하기 위해서는 GPT 파티션 방식을 사용합니다.

2. GPT 파티션 (GUID Partition Table)

GPT 파티션 테이블은 확장 펌웨어 인터페이스(Extensible Firmware Interface,EFI) 의 일부에 포함된 디스크 파티션 테이블 레이아웃 표준이빈다. 1990 년대 후반에 개발되어 기존의 MBR의 제약을 극복할 수 있게 설계되었습니다.

기존 MBR방식과의 차이는

1. 파티션 테이블 개수가 128개로 늘어났고 각 테이블당 128byte 씩 사용하게됩니다.

2. 섹터 주소를 64bit 로 저장하여 최대 8ZB 디스크를 사용할 수 있습니다.

3. GPT 중요 데이터를 디스크 마지막 부분에 백업합니다. (장애복구)

다만 부팅용 디스크를 GPT 파티션으롤 사용하기 위해서는 BIOS 대신 EFI/UEFI 방식의 펌웨어를 지원해야합니다.

BIOS는 부팅시 MBR방식 파티션만 인식합니다 !

각 방식에 따른 디스크 구조는 다음과 같습니다.