728x90
반응형

도커 네트워크

  • 도커 네트워크는 일종의 내부망 이다.
    • 각 컨테이너들은 독립적인 네트워크 망을 가진다.
    • 정확히는 분리된 네트워크를 가진다 -> IP를 나눈다는 의미
    • 때문에 각 컨테이너별로 호스트와는 다른 가상의 IP 주소를 가진다.
  • 도커 네트워크는 컨테이너가 끼리의 통신을 할 수 있는 범위라 말할 수 있을 것 같다.
  • 기본적으로 컨테이너가 구동되게 되면 해당 컨테이너에 대한 default_network가 생성된다.
    • 이렇게 되면 다른 네트워크의 컨테이너와 소통할 수 없기 때문에 도커 외부로 우회하여 소통해야한다.
    • 컨테이너끼리 소통하기 위해 외부로 나갔다 들어와야 하기 때문에 성능적으로 저하가 발생하고, 보안적으로도 문제가 생길 수 있다.
  • 그러나 동일한 네트워크에 속한 컨테이너들 끼리는, 컨테이너의 이름과 포트만으로 서로 통신이 가능하다.

컨테이너 구동 시 도커 네트워크 구성에 대해

  • 컨테이너 구동 시, 순차적으로 도커 내부 IP 부여
    • 일반적으로 172.~~ 으로 시작하더라
    • 순차적으로 IP를 부여하기 때문에, 컨테이너를 내렸다 다시 올리면 컨테이너 IP가 변동 될 수 있음
  • 도커 네트워크는 내부망이기에, 외부와 연결시켜야 함
    • 컨테이너 구동 시, 자동적으로 컨테이너 마다 호스트에 veth(Virtual Ethernet)라는 가상 네트워크 인터페이스를 생성함
    • 네트워크 관련 설정을 하지 않는다면 default0 브릿지를 사용함

Docker Bridge

  • 도커 브릿지는 호스트와 컨테이너를 잇는 라우팅 경로
    • 즉 쉽게 말하면, 각 컨테이너에 가상의 IP를 부여하는 공유기 역할

도커 네트워크 전체 조회

  • 현재 사용중인 도커 네트워크 리스트 조회
docker network ls
  • 도커 네트워크 세부사항 조회
docker network inspect 

도커 네트워크 설정

  • 도커 네트워크 설정
  • docker network create <네트워크 이름>

컨테이너 네트워크 설정

  • 같은 도커 네트워크에 해당하는 모든 컨테이너들은 서로 내부 통신이 가능함
    • 이미 db_mariadb 라는 컨테이너가 proxy라는 도커 네트워크 안에 구동되어 있다면
    • 지금 올리는 어플리케이션 컨테이너를 proxy라는 네트워크에 포함시킴으로 인해서, db_mariadb:3306 을 url로 잡으면 통신이 가능해짐
    • 같은 네트워크가 아니라면, 'HostIP:컨테이너 포트' 를 통해 접근할 수 있음
      • 문제는 컨테이너가 호스트에 포트를 열어둔게 아닌, 컨테이너 포트만 노출 시킨 상태라면 접근할 수 있는 방법이 없어짐
  • 컨테이너 네트워크 설정 - docker compose
    • external: 컨테이너 구동 시 새로운 네트워크를 사용할지에 대한 여부를 설정하는 것
      • true: 기존 도커 네트워크를 할당함
      • false: 새로운 도커 네트워크를 생성함
    services:
        app:
            // 컨테이너 설정
            networks:
                - proxy
    
    networks:
        proxy:
          # proxy라는 새로운 네트워크를 생성하는게 아닌, 기존의 proxy라는 네트워크를 사용한다는 의미
            external: true
  • 컨테이너 네트워크 설정 - Dockerfile
    docker run app_name --net proxy
728x90
반응형
728x90
반응형

프로메테우스란?

  • 프로메테우스는 사운드 클라우드에서 처음 제작한 모니터링 & 알람에 초점이 맞춰진 모니터링 오픈소스 툴이다.
  • 요청 발생 수, DB 연결 수 등의 숫자로 치환될 수 있는 시계열 데이터를 메트릭스(Metrics) 라 하는데, 이를 시계열 데이터로 저장 및 수집하는 툴이다.

특징

  • 다차원 시계열 데이터를 메트릭스 명과 key-value 쌍으로 관리한다.
  • PromQL 이라는 쿼리 언어로 차원들을 관리한다.
  • 다른 저장소에 종속되지 않는다.

데이터 수집 방법

  • 엔드포인트에 HTTP 요청을 통해 데이터를 스크레이핑 한다.
  • exporter를 배포해 해당 exporter의 엔드포인트를 통해 데이터를 스크레이핑한다.

시스템 메트릭 수집

  • 프로메테우스가 서버의 시스템 메트릭스(Load Average, CPU Usage 등)을 수집하는 방법은 node-exporter를 사용하는 것이다.
    • node-exporter는 시스템 정보를 수집하는 툴이라고 생각하면 편하다.

Node Exporter 실행

  • 컨테이너로 이를 시행시킬 수 있다.
  • 아래처럼 설정한다. 이렇게 했을 때, exporter의 엔드포인트로 접근해 데이터를 수집할 수 있다.
services:
    exporter:
        image: prom/node-exporter:v1.8.2
        container_name: exporter
        expose: 9100
        command:
          - '--path.procfs=/host/proc'
          - '--path.rootfs=/rootfs'
          - '--path.sysfs=/host/sys'
          - '--collector.filesystem.mount-points-exclude=^/(sys|proc|dev|host|etc)($$|/)'
        volumes:
            - /proc:/host/proc:ro
            - /sys:/host/sys:ro
            - /:/rootfs:ro
        networks:
            - proxy
  • path.roofts 설정
    • 호스트 전체 모니터링을 위한 설정
    • 루트 디렉토리에 대해 바인딩 시켜, Exporter가 호스트 FileSystem에 접근하게 해 주는 옵션
    • 이후 루트 디렉토리를 볼륨으로 넣음
    • 일반 디렉토리면 그냥 넣어주면 된다.

프로메테우스 실행

설정

  • 프로메테우스 설정
    • prometheus.yml 파일로 해야 인식한다. 물론 볼륨으로 넣을 때, 명칭을 바꿔주는 것도 가능하다.
    • 수집할 대상의 엔드포인트를 정의한다.
    • 이는 scrape_configs 에 그 타겟 대상과 라벨링이 가능하다.
global:
    scrape_interval: 15s
    evaluation_interval: 15s

# Set the scrape interval to every 15 seconds. Default is every 1 minute.

rule_files:
    - alert.rules.yml
      alerting:
        alertmanagers:
            - static_configs:
            - targets: ["host.docker.internal:9093"]

scrape_configs:
    - job_name: 'System Server'
      static_configs:
        - targets: ['node:9100']

    - job_name: 'cAdvisor'
      static_configs:
        - targets: ['cadvisor:8080']
  • 설정 옵션 관련 내용
    • global: 전체적인 데이터 수집에 대한 전역 설정
    • scrape_configs: 수집 작업에 대한 정의
    • remote_write: 수집된 메트릭을 원격 엔드포인트로 전달하기 위한 설정

컨테이너 설정

  • prometheus.yml 파일 이외에도 alert.rules (장애 알람 규칙) 등 다른 설정들도 먹일 수 있다.
  • 해당 설정들은 /etc/prometheus 경로에 넣어주면 된다.
services:
    prometheus:
        image: prometheus:v2.54.1
        volumes:
            - ./prom-config/prometheus.yml:/etc/prometheus/prometheus.yml
            - ./prom-config/alert.rules.yml:/etc/prometheus/alert.rules.ym
            - prometheus_data:/prometheus
        command:
            - '--config.file=/etc/prometheus/prometheus.yml'
            - '--storage.tsdb.path=/prometheus'
            - '--web.console.libraries=/etc/prometheus/console_libraries'
            - '--web.console.templates=/etc/prometheus/consoles'
            - '--web.enable-lifecycle'
        networks:
            - proxy
        restart: unless-stopped
        ports:
            - 9090:9090

GUI

  • 이제 http://localhost:9090으로 접근해 보면 아래와 같이 확인할 수 있다.
  • 아래 랜딩페이지 화면에서 PromQL을 통해 데이터를 쿼리해 볼 수 있다.

'

  • 또한 현재 데이터를 수집하고 있는 대상을 확인하는 방법은 Status - Target으로 확인할 수 있다.
    • 여기서 현재 정상적으로 데이터가 수집되고 있는지도 확인할 수 있다.

728x90
반응형

'데브옵스 devOps > Monitoring' 카테고리의 다른 글

[CNCF] OpenTelemetry(OTel)란?  (0) 2024.11.22
728x90
반응형

WORM

  • 감염 방식 중 하나로, 여러 단말기에 분산되어 해당 단말기들에 연결된 네트워크 전체를 감염
  • 트로이 목마의 위장 기능과 바이러스의 증식 기능을 탑재

Trojan horse

  • 정상적인 프로그램으로 위장한 악성코드
  • 시작부터 끝까지 메모리에 상주하여, 시스템 내부 정보를 공격자의 컴퓨터로 빼돌리는 프로그램
  • 직접적 전파능력은 없음

Root Kit

  • 공격자의 존재를 숨기면서 시스템에 대한 무제한 접근 권한 부여
  • 펌웨어, 가상화 계층 등의 시스템 영역에서 작동
  • 운영체제 시스템콜을 해킹하여 안티바이러스 탐지 우회 가능

Ransomware

  • 피해자의 데이터나 디바이스를 점유해 데이터를 암호화 한 후, 암호키를 대가로 금품을 요구하는 악성 코드
728x90
반응형

'백엔드 Backend' 카테고리의 다른 글

[테스팅] 어플리케이션 테스팅  (2) 2024.11.01
[결합도/응집도] 결합도와 응집도란  (0) 2024.10.24
SOLID 원칙  (0) 2024.10.08
비동기 Asynchronous 란?  (0) 2024.10.04
[백엔드] REST API 란?  (0) 2024.09.27

+ Recent posts