[구름 k8s] TIL 2-4-1

Peppie·2022년 9월 26일
0

0. 현재까지 학습한 내용 정리

기본 기술

전통적인 방법 (직접 설치)으로 Application 실행 및 배포 가능한 Infrastructure 구성을 위한 요소 기술

Infrastructure 구성 요소

  • Server : 서비스 제공 컴퓨터
  • Storage : 프로그램이나 데이터 저장 공간
  • Network : Server나 Storage의 통신을 위한 환경 구성

★★★ Linux ★★★

  • 운영체제 사용법
  • Server 구축 방법

Public Cloud - AWS

  • Infrastructure 구축 방법
  • Cloud Service 활용 방법

IaC

  • AWS CloudFormation
  • Ansible
  • Infrastructure 관리 자동화

1. Docker 이해

Application

사용자가 원하는 기능/서비스 제공을 위해 동작하는 프로그램

Application 구성 요소

Application binary - 설치 대상

해당 Application 동작을 위한 필수 기능만 포함

Application을 사용하는 공유 라이브러리 - OS에 미리 설치 多

라이브러리 (Library) : 변수/함수/클래스 집합

Application 설치

Application 설치 프로그램 구성 요소

  • Application 설치 환경 확인 프로그램
  • Application binary
  • Application에서 사용하는 공유 라이브러리 파악 및 필요시 설치

Application이 설치되는 환경

Application 설치 프로그램에 의해 설치 과정을 수행하는데 있어 공유 라이브러리 유무에 따라 설치 과정이 쉽게 수행 or 설치 과정 복잡해질수도

Application 동작 환경

Traditional Deployment (전통적인 Application 배포 동작 방식)

  • 물리적인 서버에 Application이 동작가능한 환경 구축 -> Infrastructure 영역
  • 물리적인 서버에 Application 설치를 통한 서비스 제공

장점

  • Application이 물리적인 서버의 자원을 직접적으로 활용 가능 - 물리적 서버 리소스 사용 제약 X

단점

  • 개발 환경과 운영 환경의 차이 : Application 설치시 필요한 공유 라이브러리 X -> 설치 어려움
  • 특정 Application이 물리적인 서버의 리소스를 과다하게 사용하는 것에 대한 통제 쉽지 X

Virtualized Deployment (가상머신을 통한 배포 방식)

  • 가상머신을 구성하여 Application 배포
    • 가상머신 : Hypervisor 기반으로 SW적으로 구성된 컴퓨터 시스템,
      VirtualBox / VMWare 또는 Cloud 환경
  • 가상머신을 Application을 동작할 수 있는 최상의 환경으로 구성하여 배포
    -> 전통적인 배포 방식의 문제점 해결

장점

  • Application 간의 격리 (isolate) 가능
  • 배포시 가상머신 배포를 통해 Application 실행환경 구성의 어려움 극복

단점

  • 가상머신 환경은 결국 HW 환경을 SW적으로 구성하는 것
    -> 현재의 HW 환경을 나눠 사용하기 때문에 리소스 관리 측면에서 효과적 X
  • 각 가상머신에는 별도 OS 설치 및 공유 라이브러리도 각각 설치 필요
    -> 하나의 시스템 관점에서는 중복되게 설치되는 문제
  • 배포되는 크기가 크다

Container Deployment (Container를 통한 배포 방식)

Container도 하나의 가상 환경, VM과 유사한 방식으로 동작하는 구조
App + App이 동작하기 위해 필요한 실행 환경 (공유 라이브러리 등)만으로 구성

Container와 VM의 차이점

  • Container는 독립된 OS를 가지지 X
  • Container는 Host OS에서 관리하는 프로세스 형태로 동작
  • Container는 완전 격리된 형태의 프로세스로 동작; 다른 프로세스와 별개
    -> 기존 리눅스 프로세스와의 차이점
  • Container가 동작하는 프로세스는 독점적인 자원 사용 불가능하게끔 제어

장점

  • 기존 VM에 비해 작은 Container 크기
  • 기민한 App 배포
  • 지속적인 개발, 통합 및 배포
  • 개발과 운영의 관심사 분리
  • 개발, 테스팅 및 운영 환경에 걸친 일관성
  • 클라우드 및 OS 배포판 간 이식성
  • App 중심 관리
  • 리소스 격리
  • 자원 사용량 : 고효율, 고집적

Docker

Container 기술의 한 종류, Container 생성 관리 역할

VM처럼 완전 독립(격리)된 실행 환경 (container) 생성

하드웨어 레벨 가상화

가상머신을 이용한 가상화, Hypervisor 기반 가상화 - VirtualBox, VMWare

운영체제 레벨 가상화

container engine을 통한 프로세스 단위 가상화, docker

  • 프로세스 : OS kernel에 의해서 관리되는 대상, 하나의 프로그램 실행 시 생성되는 단위

운영체제를 설치하는 것과 유사한 효과 but 실제 운영체제 설치 X -> 적은 설치 용량 + 빠른 실행 속도

Docker Container는 일종의 SW 실행에 필요한 모든 것을 포함한, 완전한 파일 시스템 안에 감싼 상자와 같은 모양
-> 런타임 코드, 시스템 도구, 시스템 라이브러리 등 서버에 설치되는 모든 것,
실행중인 환경 (OS)에 관계없이 동일 실행 보증

Docker 구성 요소

Docker Engine (Docker run-time) + Docker Container

Docker Engine (docker daemon) - daemon process

Container runtime, Container 생성 / 관리 역할 수행

Docker Engine이 사용하는 기술적 요소

리눅스 컨테이너 (LinuX Container, LXC) 기술 기반

  • chroot (change root) : 특정 디렉토리를 최상위 디렉토리 root로 인식하게끔 설정하는 리눅스 명령
  • namespace : 프로세스 자원 관리 기능 + mnt/pid/net/ipc/user 등의 자원 그룹화 후 할당 기능
  • cgroup (control group) : CPU/memory/disk/IO/network 등의 자원 사용량 제어를 통해 특정 App의 과도한 자원 사용 제한
  • UnionFS (Union File System) : 여러 파일 시스템을 하나의 파일 시스템으로 마운트시키는 가상 파일 시스템

Docker Container - application process

격리(isolate)된 응용 프로그램 실행 환경 (가상 환경)

container 기술 장점

  • Hypervisor와 게스트 OS의 부재로 가벼움
    -> 경량이기에 만들어진 이미지 복제/이관/배포 쉬움
  • 게스트 OS 부팅 X -> 빠른 어플리케이션 시작 시간
  • 가상머신보다 경량 -> 더 많은 어플리케이션 실행 가능

Docker에서 적용하는 LXC (LinuX Container) 기반 기술

chroot (Change root)

root 변경
root 계정 (관리자 계정)을 변경하는 것이 아닌 Linux 시스템의 /(root) 디렉토리 위치 변경

chroot <변경할 root 폴더 경로> <명령 shell>

  • root 권한으로 실행
  • 먼저 변경할 root 디렉토리 생성
  • 변경할 root 디렉토리로 이동 후 chroot 명령 수행
  • 변경한 root 디렉토리에서 사용할 shell 지정

ldd <실행 파일 이름>

  • 실행 파일이 사용하는 공유 라이브러리 목록 출력

실습

  • root user로 사용자 전환 : su - 또는 sudo su
  • / 위치로 디렉토리 이동 : cd /
  • chroot 명령으로 / 디렉토리로 설정한 디렉토리 생성 : mkdir tomato
  • 생성한 디렉토리로 이동 : cd tomato
  • chroot 명령으로 현재 디렉토리를 / 디렉토리로 변경 : chroot /tomato /bin/bash
  • chroot 명령을 실행할 설정한 사용 shell에 대한 바이너리가 /로 설정한 디렉토리에는 존재 X
    -> /로 설정할 디렉토리에 사용 shell 바이너리와 공유 라이브러리 복사
    • /bin/bash를 현재 /로 만드려는 디렉토리에 복사 : cp /bin/bash /tomato/bin
    • /bin/bash의 공유 라이브러리 확인 : ldd /bin/bash
      linux-vdso.so.1 (0x00007ffe83d69000) // 가상 라이브러리, 목사 필요 X
            libtinfo.so.6  // bash가 동작할 때 필요한 라이브러리
            libc.so.6  // Linux 공통 라이브러리
            /lib64/ld-linux-x86-64.so.2 (0x00007f05a2f07000) // 동적 로더 (loader), 공유 라이브러리를 메모리에 로드하는 역할
    • 공유 라이브러리가 복사될 디렉토리 생성
      mkdir -p /tomato/lib/x86_64-linux-gnu
      mkdir -p /tomato/lib64
    • 공유 라이브러리 복사
      cp /lib/x86_64-linux-gnu/libtinfo.so.6 /tomato/lib/x86_64-linux-gnu/
      cp /lib/x86_64-linux-gnu/libc.so.6 /tomato/lib/x86_64-linux-gnu/
      cp /lib64/ld-linux-x86-64.so.2 /tomato/lib64
    • 다시 chroot 명령으로 / 디렉토리 변경

0개의 댓글