• docker가 기본적으로 설치되어있어야함
  • docker 설치는 다른 페이지에서 참고

1. 프로메테우스 적용 yaml 파일 → 모니터링할 목록 정의

# 프로메테우스 yaml파일을 관리한 디렉토리 생성
$ mkdir /etc/prometheus

# prometheus.yml 파일 내용 정의
$ vi /etc/prometheus/prometheus.yml
global:
  scrape_interval: 15s
  scrape_timeout: 10s
  evaluation_interval: 15s
  external_labels:
    monitor: legacy

scrape_configs:
  - job_name: 'prometheus'
    static_configs:
      - targets:
        - [서버 IP]:9090

2. 프로메테우스 인스턴스 시작

# 영구 볼륨(Persistent volumes)을 준비
$ mkdir -p /data/prometheus_data/

# 프로메테우스 인스턴스 배포
$ docker run -d --net=host --rm \
    -v /etc/prometheus:/etc/prometheus \
    -v /data/prometheus_data:/prometheus \
    -u root \
    --name prometheus\
    quay.io/prometheus/prometheus:v2.33.0 \
    --config.file=/etc/prometheus/prometheus.yml \
    --storage.tsdb.path=/prometheus \
    --storage.tsdb.retention=365d \
    --storage.tsdb.max-block-duration=1d \
    --storage.tsdb.min-block-duration=1d \
    --web.listen-address=:9090 \
    --web.enable-lifecycle \
    --web.enable-admin-api

3. 프로메테우스 배포 확인

  • docker 배포 확인
      $ docker ps
      CONTAINER ID                                 IMAGE                                   COMMAND                  CREATED             STATUS              PORTS               NAMES
      86205a98ec4d        quay.io/prometheus/prometheus:v2.33.0   "/bin/prometheus --c…"   14 seconds ago      Up 12 seconds                           prometheus

4. docker로 설치한 Prometheus의 관리 스크립트 내용

4.1. Prometheus.yml 파일 수정 후 Prometheus의 yaml 파일 내용 적용

```
$ source /etc/prometheus/cmd/Restart_Prometheus.sh

# 코드 내용
#! /bin/bash

container_id=`docker ps -a | grep -i prometheus | awk -F ' ' '{print $1}'`
docker restart $container_id
```

4.2. prometheus의 로그 삭제

```
$ source /etc/prometheus/cmd/Log_Clear.sh

# 코드 내용
#! /bin/bash

container_id=`docker ps -a | grep -i prometheus | awk -F ' ' '{print $1}'`
Log_file=$(docker inspect --format='{{.LogPath}}' "$container_id")

log_file_volume=`ls -al $Log_file | awk -F ' ' '{print $5}'`
if [[ $log_file_volume == 0 ]]; then
  echo "Log File is alrealy zero"
else
  truncate -s 0 $Log_file
  echo "Prometheus Log Clear"
fi
```

4.3. prometheus의 로그 보기

```
$ source /etc/prometheus/cmd/View_Log.sh

# 코드 내용
#! /bin/bash

container_id=`docker ps -a | grep -i prometheus | awk -F ' ' '{print $1}'`
docker logs -f $container_id
```

  • RedHat 계열의 CentOS 서버에서 Prometheus를 설치하고 systemd로 관리
  • Security Group, Firewall 등으로 9090번 포트에 대한 방화벽 해제가 필요

1. Prometheus 설치

  • 설치하고 싶은 Prometheus 버전의 경로를 잘 확인하여 다운받으면 됨

  • systemd를 사용하지 않고 /root/apps/prometheus-2.22.0.linux-amd64/pometheus를 실행해도 Prometheus 사용 가능

    $ pwd
    /root
    
    # 설치하는 컴포넌트들의 관리를 더 쉽게 하기 위해서 디렉토리 생성
    $ mkdir apps
    
    # 디렉토리 이동
    $ cd /root/apps
    
    # Prometheus 바이너리 파일이 들어 있는 압축 파일 설치
    $ wget https://github.com/prometheus/prometheus/releases/download/v2.22.0/prometheus-2.22.0.linux-amd64.tar.gz
    
    # 설치한 Prometheus 바이너리 파일 확인
    $ ls
    prometheus-2.22.0.linux-amd64.tar.gz
    
    # 압축 파일 해제
    $ tar zxvf prometheus-2.22.0.linux-amd64.tar.gz
    prometheus-2.22.0.linux-amd64/
    prometheus-2.22.0.linux-amd64/NOTICE
    prometheus-2.22.0.linux-amd64/prometheus
    prometheus-2.22.0.linux-amd64/consoles/
    prometheus-2.22.0.linux-amd64/consoles/node-cpu.html
    prometheus-2.22.0.linux-amd64/consoles/prometheus-overview.html
    prometheus-2.22.0.linux-amd64/consoles/node.html
    prometheus-2.22.0.linux-amd64/consoles/node-overview.html
    prometheus-2.22.0.linux-amd64/consoles/index.html.example
    prometheus-2.22.0.linux-amd64/consoles/prometheus.html
    prometheus-2.22.0.linux-amd64/consoles/node-disk.html
    prometheus-2.22.0.linux-amd64/console_libraries/
    prometheus-2.22.0.linux-amd64/console_libraries/prom.lib
    prometheus-2.22.0.linux-amd64/console_libraries/menu.lib
    prometheus-2.22.0.linux-amd64/promtool
    prometheus-2.22.0.linux-amd64/LICENSE
    prometheus-2.22.0.linux-amd64/prometheus.yml



2. Prometheus를 서비스로 생성하여 관리 → prometheus 실행을 systemd로 관리

  • Prometheus를 리눅스 systemd를 통해 서비스로 등록

    $ pwd
    /root/apps/prometheus-2.22.0.linux-amd64
    
    # 디렉토리 프로비저닝
    $ useradd --no-create-home --shell /bin/false prometheus
    
    # 생성한 prometheus 계쩡 확인
    $ cat /etc/passwd | grep prometheus
    prometheus:x:1001:1001::/home/prometheus:/bin/false
    
    # prometheus를 관리할 디렉토리 생성 및 명령어 복사
    $ mkdir /etc/prometheus
    $ mkdir /var/lib/prometheus
    $ cp ./prometheus /usr/local/bin/
    $ cp ./promtool /usr/local/bin/
    $ cp ./prometheus.yml /etc/prometheus/
    $ cp -r ./consoles /etc/prometheus
    $ cp -r ./console_libraries /etc/prometheus
    
    # 명령어 복사 확인
    $ ls /usr/local/bin/
    prometheus  promtool
    
    # prometheus 관련 내용 복사
    $ ls /etc/prometheus
    console_libraries  consoles
    
    # 유저:그룹 설정 -> prometheus 사용자 계정이 관리할 수 있도록 권한 변경
    $ chown prometheus:prometheus /etc/prometheus
    $ chown prometheus:prometheus /var/lib/prometheus
    $ chown prometheus:prometheus /usr/local/bin/prometheus
    $ chown prometheus:prometheus /usr/local/bin/promtool
    $ chown -R prometheus:prometheus /etc/prometheus/consoles
    $ chown -R prometheus:prometheus /etc/prometheus/console_libraries
    
    # 서비스 파일 등록
    $ cat << EOF | tee /etc/systemd/system/prometheus.service
    [Unit]
    Description=Prometheus Server
    Wants=network-online.target
    After=network-online.target
    
    [Service]
    User=prometheus
    Group=prometheus
    Type=simple
    ExecStart=/usr/local/bin/prometheus \
      --config.file /etc/prometheus/prometheus.yml \
      --storage.tsdb.path /var/lib/prometheus/ \
      --web.console.templates=/etc/prometheus/consoles \
      --web.console.libraries=/etc/prometheus/console_libraries
    
    [Install]
    WantedBy=multi-user.target
    EOF
  • 서비스 데몬 리로딩
    $ systemctl daemon-reload
  • prometheus 서비스 시작
    $ systemctl start prometheus
  • prometheus 서비스 상태 확인

    $ systemctl status prometheus
    ● prometheus.service - Prometheus Server
     Loaded: loaded (/etc/systemd/system/prometheus.service; disabled; vendor preset: disabled)
     Active: active (running) since Sat 2021-11-20 02:55:12 KST; 11h ago
    Main PID: 11780 (prometheus)
      Tasks: 14
     Memory: 48.4M
     CGroup: /system.slice/prometheus.service
             └─11780 /usr/local/bin/prometheus --config.file /etc/prometheus/prometheus.yml --storage.tsdb.path /var/lib/prometheus/ --web.console.templates=/etc/prometheus/consoles --web.console.libraries=/etc/prometheus/console_...
    
    Nov 20 12:00:03 [서버 IP] prometheus[11780]: level=info ts=2021-11-20T03:00:03.377Z caller=head.go:889 component=tsdb msg="WAL checkpoint complete" first=2 last=3 duration=29.052021ms
    Nov 20 12:00:03 [서버 IP] prometheus[11780]: level=info ts=2021-11-20T03:00:03.425Z caller=compact.go:440 component=tsdb msg="compact blocks" count=3 mint=1637344800000 maxt=1637366400000 ulid=01FMXMJQ5RJ914...ration=41.7039ms
    Nov 20 12:00:03 [서버 IP] prometheus[11780]: level=info ts=2021-11-20T03:00:03.431Z caller=db.go:1152 component=tsdb msg="Deleting obsolete block" block=01FMX6V8HX8WMN15F7H841AKH0
    Nov 20 12:00:03 [서버 IP] prometheus[11780]: level=info ts=2021-11-20T03:00:03.432Z caller=db.go:1152 component=tsdb msg="Deleting obsolete block" block=01FMXDPZSXA1G1VCYYE6JTVAQN
    Nov 20 12:00:03 [서버 IP] prometheus[11780]: level=info ts=2021-11-20T03:00:03.433Z caller=db.go:1152 component=tsdb msg="Deleting obsolete block" block=01FMWZZH9W1MH7PN1NZBT06CG9
    Nov 20 14:00:03 [서버 IP] prometheus[11780]: level=info ts=2021-11-20T05:00:03.321Z caller=compact.go:494 component=tsdb msg="write block" mint=1637373600000 maxt=1637380800000 ulid=01FMXVEE9X21CFW66VFRRZNAK...tion=59.826896ms
    Nov 20 14:00:03 [서버 IP] prometheus[11780]: level=info ts=2021-11-20T05:00:03.329Z caller=head.go:809 component=tsdb msg="Head GC completed" duration=2.347334ms
    Nov 20 14:00:03 [서버 IP] prometheus[11780]: level=info ts=2021-11-20T05:00:03.386Z caller=compact.go:440 component=tsdb msg="compact blocks" count=2 mint=1637344458250 maxt=1637366400000 ulid=01FMXVEEC8WEK8...tion=50.157896ms
    Nov 20 14:00:03 [서버 IP] prometheus[11780]: level=info ts=2021-11-20T05:00:03.393Z caller=db.go:1152 component=tsdb msg="Deleting obsolete block" block=01FMXMJQ5RJ914MKYP3J4QZ7WT
    Nov 20 14:00:03 [서버 IP] prometheus[11780]: level=info ts=2021-11-20T05:00:03.394Z caller=db.go:1152 component=tsdb msg="Deleting obsolete block" block=01FMWZNF1BR2H33QNDPE91K04T
    Hint: Some lines were ellipsized, use -l to show in full.



3. [서버 IP]:9090에 접속하여 prometheus의 UI 확인 가능

  • public IP:9090"에 접속하면 아래 UI를 확인 가능

  • Prometheus는 메트릭 수집, 시각화, 알림, 서비스 디스커버리 기능을 모두 제공하는 오픈 소스 모니터링 시스템
  • SoundCloud에서 Go언어로 개발하였으며, Apache 2.0 License를 따르고 있음
  • 2016년에 쿠버네티스에 이어 두 번째로 CNCF(Cloud Native Computing Foundation) 산하 프로젝트 멤버로 들어감
  • Grafana Labs에서 유지 보수를 메인으로 전담
  • Prometheus는 독립형 오픈소스 프로젝트이며 많은 회사들이 사용함
  • kubernetes에서 Prometheus를 사용하여 매트릭 수집 및 대시보드 구축하는 방식을 장려
  • Prometheus는 애초에 "스케일 아웃"을 고려하지 않고 설계
  • 데이터가 많으면 많을수록 Prometheus 클러스터링을 위한 Thanos, Cortex등 여러 오픈 소스가 개발되면서 클러스터링 구성 가능

Prometheus의 대표적인 기능

  1. 풀 방식의 메트릭 수집, 시계열 데이터 저장
  2. PromQL을 활용하여 저장된 시계열을 쿼리 및 집계
  3. 서비스 디스커버리
  4. 데이터 시각화

Prometheus 아키텍처

  • Prometheus의 아키텍쳐는 아래와 같이 구성

1. Prometheus

  • Prometheus는 시계열 데이터를 저장
  • Prometheus는 Exporter를 통해 다양한 서비스/시스템의 메트릭을 수집 → Node Exporter는 설치된 머신의 CPU, Memory 등의 메트릭 정보를 수집
  • Client Library는 애플리케이션 코드를 계측하기 위해 쓰인다.
  • Prometheus는 설정 파일(prometheus.yml)에 작성된 "Job"을 통해서 이들이 수집하는 메트릭을 가져와서 저장

2. Pushgateway

  • Pushgateway는 Polling방식이 아닌 프로메테우스에 메트릭을 매트릭을 푸시할 수 있도록 지원
  • Prometheus에서 제공하는 Pushgateway는 푸시된 매트릭을 프로메테우스에서 가져갈 수 있도록 중개자 역할을 수행
  • 즉, Pushgateway에 푸시된 매트릭을 Prometheus에서 가져갈 수 있음

3. Client Library

  • Client Library는 애플리케이션 코드를 계측하기 위해 사용됨
  • 서비스를 개발할 때 가장 좋은 방법은 프로메테우스 클라이언트 라이브러리를 사용해 메트릭을 코드 인라인 기반으로 직접 작성하고 계측함
  • 기본적으로 Go, Java(Scala), Python, Ruby 는 공식 라이브러리를 제공
  • 클라이언트 라이브러리 : https://prometheus.io/docs/instrumenting/clientlibs/

4. Exporter

  • Exporters는 실제로 매트릭을 수집하는 프로세스
  • Exporter가 매트릭을 수집하고 HTTP 통신을 통해 매트릭 데이터를 가져갈 수 있게 /metrics 라는 HTTP 엔드포인트를 제공
  • Prometheus가 Exporter의 엔드포인트로 HTTP GET 요청을 날려 매트릭 정보를 수집(Pull)함

5. Alertmanager

  • Alertmanager를 통해서 특정 메트릭이 임계치가 넘어가거나 경계에 잡혔을 때 이메일, 슬랙 등을 통해서 알림을 보내줄 수 가 있음
  • UI 기능이 있어 데이터를 시각화 가능 → 프로메테우스의 시각화 기능은 약한 편임
  • Prometheus의 Alertmanager 기능의 부족한 부분을 채우기 위해 Grafana 대시보드 툴로 Prometheus UI를 대체

6. Service Discovery

  • Service Discovery 기능을 제공
  • Service Discovery를 활용하면, 인스턴스는 다이나믹하게 스케일 인/아웃이 됨
  • Prometheus는 여러 Service Discovery와 통합 가능
  • 쿠버네티스 Service Discovery와 통합하여, 쿠버네티스 클러스터에 존재하는 모든 노드와 팟들의 메트릭을 수집 가능


Prometheus를 사용하기에 적합한 일, 적합하지 않은 일

  • Prometheus는 "메트릭"을 저장하기 위한 모니터링 시스템
  • 커널 스케줄링이나 데이터 수집 실패 같은 요소로 인해 약간의 부정확성과 레이스 컨디션을 피할 수 없는 운영 모니터링 환경을 위해 설계되었다.

1. Prometheus에 적합한 일

  1. 순수한 숫자 시계열을 기록하는 데 적합
  2. 메트릭 기반의 시계열 데이터 저장
  3. 동적인 혹은 마이크로 서비스의 인스턴스에 대한 메트릭을 수집

2. Prometheus에 적합하지 않은 일 → 다른 도구를 사용하여 Prometheus의 부족한 부분을 해결

  1. 이벤트 로그나 개별 이벤트를 저장하는 일
  2. 이메일 주소/사용자 이름과 같이 카디널리티가 높은 데이터를 저장하는 일
  3. 100%의 정확성이 요구되는 일

참고 URL : https://gurumee92.tistory.com/220
Pushgateway 참고 URL : https://kdevkr.github.io/using-pushgateway-to-monitor-private-network-instance/
Client Library 참고 URL : https://medium.com/nexclipper-io/prometheus-exporter-exporterhub-f29d63e0ae49


1. GitOps를 도입하기 전과 GitOps를 도입한 후의 kubernetes의 배포 방식 차이


2. GitOps란

2.1. 개발자의 코드가 실제 서비스로 반영되기까지 많은 과정을 거쳐야함

  1. Repository에 Push 후 CI를 통해 Docker Image로 빌드
  2. Container Registry(ex: DockerHub)로 업로드
  3. Kubernetes에 배포 방법 선택 후 kubernetes cluster에 배포

2.2. GitOps를 도입하기 전의 문제화 해결 과정

  1. 사람마다 선호하는 배포 방식이 제각각이고 여러 소스(원천)로부터 Manifest가 변경됨
  2. 이미지 태그를 1.1로 업데이트하여 배포했는데, 누군가가 1.0 버전의 Manifest 파일로 배포했다면 문제가 발생 가능
  3. 여러 사람이 배포하기에 배포한 담당자를 파악하기 힘들고, 다시 1.1 버전으로 배포진행해야함
  4. Manifest를 가져오는 소스를 Git Repository 한 곳으로 통일하는 방식으로 문제에 해결
  5. Git Repository에 존재하는 Manifest 파일과 Kubernetes cluster에 존재하는 리소스의 현재 상태를 계속 비교하며 Sync 작업을 수행
  6. 현재 Manifest에 정의한 리소스가 생성되지 않았으면, 생성하고, 일치하지 않는 경우 Spec에 맞도록 복구 작업을 수행
  7. 모든 과정을 자동으로 진행하기에 사람이 배포에 개입할 여지를 최소화 → 더 이상 배포를 Imperative 방식이 아닌 Declarative 방식으로 수행


3. 단일 진실의 원천(Single source of truth; SSOT)이란

  • 단일 진실의 원천은 "오직 진실(결과)이 오직 한가지의 원천(이유)에서 발생"하는 것을 의미
  • 단일 진실의 원천에 대한 예시로, 어떤 아이가 울고 있으면(결과) 그것은 오직 아이스크림을 땅바닥에 떨어뜨렸기 때문(이유)이라고 가정
    1. 넘어져서 우는 것도 아니고 혼나서 우는 것도 아니라 오직 아이스크림을 땅바닥에 떨어뜨렸기 때문에 우는 것
    2. 반대로 아이스크림을 제대로 들고 있으면 항상 웃고, 아이가 웃는다면 이유는 칭찬을 받아서도 아니고 과자를 먹어서도 아니고 오직 아이스크림을 떨어뜨리지 않았기 때문임



4. 소프트웨어 배포 관점에서 단일 진실의 원천

4.1. 단일한 방법으로의 소프트웨어 배포

  • 어떤 소프트웨어를 개발하여, 운영 환경에 반영할 때 다양한 방법을 통해서 배포 가능
  • 예를 들어, 자바 WAR 파일을 운영 환경의 Tomcat 서버에 배포를 한다고 했을 때, scp를 이용하여 파일을 배포할 수도 있고 S3에 파일을 올려놓고 운영 서버에서 그것을 다운 받을 수도 있음
  • 자동으로 배포를 하고 싶으면 ansible이나 chef 같은 툴을 이용하여 소프트웨어를 배포 가능
  • 소프트웨어를 배포 방법이 다양하면 문제가 발생할 소지가 많아짐 → 사람마다 배포하는 방법이 달라 human error가 증가하게 될 수 있고 다양한 배포 방법이 서로 충돌할 여지 발생 가능
  • 배포에서 충돌이 발생하는 human error 문제를 해결하기 위해서 GitOps는 소프트웨어 배포 과정을 체계적으로 관리하고 자동화하기 위해 모든 배포 정의를 한 곳에서 관리하고 한가지 방법으로 배포하는 것을 추구

4.2. 항상 원천(Git Repository)의 상태를 완벽히 반영하는 배포

  • 위 아이스크림과 아이의 예시에서 아이가 아이스크림의 상태를 완벽하게 반영한다고 할 수 있음 → 아이스크림을 들고 있으면 아이는 울지 않고 아이스크림을 떨어뜨리면 아이가 울기 때문.
  • 소프트웨어 배포 관점에서 보자면, 아이스크림은 배포 작업 정의서(어떻게 소프트웨어를 배포할지 기술한 문서)를 의미하고 아이는 실제 배포된 상태를 의미
  • GitOps에서는 배포상태의 모습을 항상 Git Repository과 동일하게 맞출려고 노력
  • “단일 진실의 원천(Single source of truth; SSOT)” 방법을 통해 얻을 수 있는 3가지 장점.
    1. 현재 배포환경의 상태를 쉽게 파악 가능 → 배포환경에 들어가서 상태를 파악할 필요 없이 Git Repository(배포 작업서)만 확인하면 쉽게 파악 가능
    2. 빠르게 배포 가능 → 단일한 방법으로 소프트웨어를 배포하여 표준화 시켰기 때문에 쉽게 배포 자동화 가능(빠르고 지속적인 배포를 가능)
    3. 안정적으로 운영 환경에 배포 가능 → 배포할 때 운영 환경에서 발생할 수 있는 human error를 최소화(배포를 관장하는 사람은 Git Repository의 내용만 잘 확인하면 문제 X)
  • GitOps는 Git 저장소를 단일 진실의 원천으로 사용
  • 쿠버네티스와 같이 선언형 (declarative description)명령은 Git 저장소(Git Repository)에 원하는 배포 형태를 선언하기만 하면 운영에 반영하기 쉬움


5. GitOps 방식의 이점

  1. Manifest가 위치한 Repository만 신경쓰면 됨 → Manifest Repository에 권한이 있는 인원만 배포 과정에 참여할 수 있으며, Manifest 파일 변경 이력이 Git에 그대로 남기 때문에 추적이 용이
  2. 배포 과정 단순화 가능 → 터미널에서 'kubectl' 명령어를 실행하거나, 스크립트를 수정하는 등의 작업이 없어지기 때문에 더욱 빠르고 자주 배포 가능
  3. 사람의 부주의로 발생할 수 있는 Human Error을 줄일 수 있음
  4. 서비스 업데이트는 해당 Manifest파일을 수정해서 Repository에 Push하는 것으로 실현하고, 새 버전에 문제가 있는 경우, 'git revert'를 해서 이전으로 쉽게 돌아갈 수 있음


6. GitOps에서 요구하는 원칙

  • GitOps는 특정 소프트웨어나 프로덕트가 아닌 철학 혹은 방법론에 더 가까움

6.1. 선언형 배포 작업 정의서

  • 배포 방법이 명령형 방식으로 정의된 것이 아니라 배포된 상태가 어떤 모양을 가져야 할지 선언되어 있는 방식으로 정의가 되어 있어야 함
  • 사용자가 배포의 원하는 상태 (desired state)를 선언적으로 정의
  • Git 저장소에 단일 진실의 원천 조건을 만족 가능
  • 배포 작업 정의서가 선언형으로 되어 있으면 더 쉽게 배포할 수 있으며 문제 발생시, 롤백하기도 쉬움
  • 장애 등으로 인해 손상된 배포 환경을 자가 치유하기 유리

6.2. Git을 이용한 배포 버전 관리

  • Git에 모든 배포에 관련된 정보가 정의되어 있어야 함
  • 각 버전이 Git 저장소에 기록이 되어야함
  • 사용자는 쉽게 예전 버전으로 롤백을 하거나 새로운 버전으로 업그레이드 가능

6.3. 변경 사항 운영 반영 자동화

  • 사용자는 Git 저장소에 선언형 정의서를 저장하게 되면 실제 배포가 일어나는 작업은 자동으로 이루어져야함
  • 책임지는 주체가 ArgoCD와 같은 배포 주체(deploy operator)가 됨
  • 자동으로 하는 경우 human error를 줄이고 지속적 빌드/배포를 가능하게 만듬

6.4. 자가 치유 및 이상 탐지

  • 사용자가 원하는 배포 상태 (desired state)를 작성하게 되면 실제 배포 환경이 그에 맞게 유지되고 있는지 책임지는 것 또한 배포 주체(deploy operator)가 됨
  • 배포를 관장하는 소프트웨어가 주체가 되어 현재 배포 상태를 확인하고 Git 저장소의 변경 사항 등이 없는지를 체크하여 운영 환경에 반영하는 역할을 함
  • 원칙들을 가지고 소프트웨어를 배포하는 모든 Agent를 우리는 GitOps의 구현체 (Deploy Operator)라 부름.
  • 현재 GitOps의 구현체로 ArgoCD 뿐만 아니라 Weaveworks flux, Codefresh, Jenkins X 등 다양한 소프트웨어들이 존재
  • 애플리케이션 개발 단계를 자동화하여 애플리케이션 개발을 보다 짧은 주기로 고객에게 제공하는 방법
  • 새로운 코드 통합으로 인해 개발 및 운영팀에서 발생하는 문제를 해결하는 솔루션
  • CI/CD는 애플리케이션 통합, 테스트, 제공, 배포에 이르는 라이프사이클 전체에 걸쳐서 지속적인 자동화와 모니터링을 제공
  • CI → 빌드/테스트 자동화
  • CD → 배포 자동화

1. CI (Continuous Integration)

  • Continuous Integration(지속적인 통합)의 약자
  • 개발자를 위한 자동화 프로세스를 의미
  • CI (Continuous Integration) 구축
    1. 애플리케이션 코드 변경사항이 정기적으로 빌드/테스트
    2. 공유 저장소에 병합되어 여러명의 개발자가 동시에 프로그램을 개발할 경우 서로 충돌할 수 있는 문제를 해결

2. CD (Continuous Delivery & Continuous Deployment)

  • Continuous Delivery(지속적인 서비스제공), Continuous Deployment(지속적인 배포)의 약자
  • 개발자들이 애플리케이션에 적용한 변경사항이 버그테스트를 거쳐 저장소에 자동 업로드 되는 것을 의미
  • Continuous Delivery 의미를 가진 CD 구축
    1. 운영팀은 애플리케이션을 이 저장소에서 실시간 운영 환경으로 배포 가능
    2. 개발팀과 운영팀의 가시성 및 커뮤니케이션 문제를 해결해 줄 수 있음
  • Continuous Deployment 의미를 가진 CD 구축
    1. 지속적인 배포로 개발자의 변경사항을 저장소에서 고객이 사용 가능한 운영환경까지 자동으로 릴리즈할 수 있음
    2. 애플리케이션 수동 배포 프로세스로 인한 프로세스 과부하 문제를 해결 가능

'IT 학습 용어' 카테고리의 다른 글

Little's law(리틀의 법칙) → 시스템 성능 테스트에 활용  (0) 2022.07.15
GitOps 설명  (0) 2022.07.08
file storage, block storage, object storage이란  (0) 2022.07.03
페이로드(payload)  (0) 2022.06.27
M3U8 파일  (0) 2022.06.27
  • 터미널이나 윈도우 cmd 에서 작업 가능
  • 백업 등 프로그램들을 할때 shell을 통하여 업로드하면 편함


1. MinIO 설치

$ wget -P /usr/bin https://dl.min.io/client/mc/release/linux-amd64/mc
$ chmod +x /usr/bin/mc

# 기본 버전 확인
$ mc --version
mc version RELEASE.2022-02-02T02-03-24Z



2. 기본 커맨드

  1. Minio가 의도한 대로 작동하는지 확인 → http://[MinIO IP]:9000/
  2. 자격 증명을 입력
    • Access Key (액세스 키) : minio
    • Secret Key (비밀 키) : melovethanos

2.1. access key와 secret key를 MinIO client 등록

  • mc 모든 구성 정보를 ~/.mc/config.json파일에 저장
  • 는 단순히 클라우드 스토리지 서비스의 짧은 이름
  • S3 엔드포인트, 액세스 및 비밀 키는 클라우드 스토리지 제공업체에서 제공
    # set access key / secret key
    # 형식 : mc alias set my-storage http://192.168.0.30:9001 ROOT_ACCESS_KEY_CHANGE_ME SECRET_ACCESS_KEY_CHANGE_ME
    $ mc alias set hippo http://[MinIO IP]:9000 minio melovethanos
    mc: Configuration written to `/root/.mc/config.json`. Please update your access credentials.
    mc: Successfully created `/root/.mc/share`.
    mc: Initialized share uploads `/root/.mc/share/uploads.json` file.
    mc: Initialized share downloads `/root/.mc/share/downloads.json` file.
    Added `hippo` successfully.

2.2. MinIO client로 bucket 생성

## bucket 생성
$ mc mb hippo/mctest
Bucket created successfully `hippo/mctest`.

2.3. MinIO client로 bucket 리스트 확인

## bucket 리스트 확인
$ mc ls hippo
[2022-02-03 01:22:49 KST]     0B hello/
[2022-02-04 02:55:46 KST]     0B mctest/
[2022-02-04 02:00:24 KST]     0B thanos/

2.4. MinIO client로 bucket에 파일 및 디렉토리 업로드

# upload
# 형식 : mc cp SOURCE ALIAS/PATH
# 파일 복사
$ mc cp ./Prometheus_Restart.sh hippo/hello/Prometheus_Restart.sh

..._Restart.sh:  115 B / 115 B ┃▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓┃ 12.78 KiB/s 0s

# 성공적으로 파일 upload 확인
$ mc ls hippo/hello
[2022-02-04 03:04:44 KST]   115B STANDARD Prometheus_Restart.sh

# 디렉토리 복사
$ mc cp --recursive ./test hippo/hello/

..._Restart.sh:  578 B / 578 B ┃▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓┃ 58.30 KiB/s 0s

# 성공적으로 디렉토리 upload 확인
$ mc ls hippo/hello/test
[2022-02-04 03:13:27 KST]   348B STANDARD Prometheus_Log_Clear.sh
[2022-02-04 03:13:27 KST]   115B STANDARD Prometheus_Log_View.sh
[2022-02-04 03:13:27 KST]   115B STANDARD Prometheus_Restart.sh

2.5. MinIO client로 bucket에 파일 및 디렉토리 삭제

# 디렉토리 내 리스트 확인
$ mc ls hippo/hello/test
[2022-02-04 03:13:27 KST]   348B STANDARD Prometheus_Log_Clear.sh
[2022-02-04 03:13:27 KST]   115B STANDARD Prometheus_Log_View.sh
[2022-02-04 03:13:27 KST]   115B STANDARD Prometheus_Restart.sh

# 형식 : mc rm ALIAS/PATH
# 파일 삭제
$ mc rm hippo/hello/test/Prometheus_Restart.sh
Removing `hippo/hello/test/Prometheus_Restart.sh`.

# 성공적으로 파일 삭제 확인
$ mc ls hippo/hello/test
[2022-02-04 03:13:27 KST]   348B STANDARD Prometheus_Log_Clear.sh
[2022-02-04 03:13:27 KST]   115B STANDARD Prometheus_Log_View.sh

# 형식 : mc rm --recursive --force ALIAS/PATH
# 디렉토리 삭제
$ mc rm --recursive --force hippo/hello/test
Removing `hippo/test/Prometheus_Log_Clear.sh`.
Removing `hippo/test/Prometheus_Log_View.sh`.

# 성공적으로 디렉토리 삭제 확인 -> hippo/hello/test 디렉토리 없음을 확인
$ mc ls hippo/hello
[2022-02-04 03:04:44 KST]   115B STANDARD Prometheus_Restart.sh

2.6. minio client로 bucket에 파일 다운로드 → 업로드와 위치만 변경

# download
# 형식 : mc cp my-storage/test.zip ~/test.zip
#위 cp 예제에서 source/target을 위치를 바꿈.
$ mc cp hippo/hello/Prometheus_Restart.sh /Prometheus_Restart.sh

..._Restart.sh:  115 B / 115 B ┃▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓┃ 14.64 KiB/s 0s

# / 디렉토리 아래에 Prometheus_Restart.sh 파일 존재 확인
$ ls /Prometheus_Restart.sh
Prometheus_Restart.sh



3. 공유 파일 → 특정 파일을 특정일만 공유

  • 공유기간을 설정후 카피 버튼을 클릭해서 복사후 공유
  • 파일을 공유하기 위해 카피 버튼 클릭
  • Copy Link를 통해 접근 URL을 획득



4. 일반 웹서버처럼 공유 → 공유 기간을 무한정으로 설정

4.1. 버킷 자체를 public으로 설정

# 형식 : mc policy set public my-storage/test_bucket
$ mc policy set public hippo/hello
Access permission for `hippo/hello` is set to `public`

4.2. 버킷의 policy를 확인

$ mc policy get hippo/hello
Access permission for `hippo/hello` is `public`

4.3. 다운로드 테스트 → minio에서의 웹사이트 주소에는 minio client의 alias인 hippo는 제외

# minio 서버에 bucket 디렉토리가 바로 뒤로 붙음
$ wget http://[MinIO IP]:9000/hello/Prometheus_Restart.sh
--2022-02-04 03:33:43--  http://[MinIO IP]:9000/hello/Prometheus_Restart.sh
Connecting to [MinIO IP]:9000... connected.
HTTP request sent, awaiting response... 200 OK
Length: 115 [application/x-sh]
Saving to: ‘Prometheus_Restart.sh’

    100%[===============================================>] 115         --.-K/s   in 0s

2022-02-04 03:33:43 (7.72 MB/s) - ‘Prometheus_Restart.sh’ saved [115/115]

1. 쿠버네티스를 통해 MinIO 설치

$ vi minio_install.yml
apiVersion: v1
kind: Namespace
metadata:
  name: minio
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: minio-local-persistent-volume
  namespace: minio
spec:
  capacity:
    storage: 6.9T
  accessModes:
  - ReadWriteMany
  volumeMode: Filesystem
  storageClassName: "minio-local-storage"
  local:
    path: /data
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - "Minio설치IP"

  claimRef:
    namespace: minio
    name: minio-local-persistent-volume-claim
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: minio-local-persistent-volume-claim
  namespace: minio
spec:
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 6.9T
  storageClassName: minio-local-storage
  volumeMode: Filesystem
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: minio-deployment
  namespace: minio
spec:
  selector:
    matchLabels:
      app: minio
  strategy:
    type: Recreate
  replicas: 1
  template:
    metadata:
      labels:
        app: minio
    spec:
      volumes:
      - name: data
        persistentVolumeClaim:
          claimName: minio-local-persistent-volume-claim
      containers:
      - name: minio
        image: minio/minio:latest
        args:
        - "server"
        - "--address=:9000"
        - "--console-address=:9001"
        - "/data"
        env:
        - name: MINIO_ACCESS_KEY
          value: "minio"
        - name: MINIO_SECRET_KEY
          value: "melovethanos"
        ports:
        - name: service
          containerPort: 9000
        - name: console
          containerPort: 9001
        volumeMounts:
        - name: data
          mountPath: /data
---
apiVersion: v1
kind: Service
metadata:
  name: minio-service-headless
  namespace: minio
spec:
  selector:
    app: minio
  ports:
  - name: service
    port: 9000
    targetPort: 9000
    protocol: TCP
  - name: console
    port: 9001
    targetPort: 9001
    protocol: TCP
  type: ClusterIP
  clusterIP: None
---
apiVersion: v1
kind: Service
metadata:
  name: minio-loadbalancer-service
  namespace: minio
spec:
  selector:
    app: minio
  ports:
  - name: service
    port: 9000
    targetPort: 9000
    protocol: TCP
  - name: console
    port: 9001
    targetPort: 9001
    protocol: TCP
  type: LoadBalancer



2. MinIO 생성 및 MinIO 생성 확인

# MinIO생성
$ kubectl apply -f minio_install.yml
namespace/minio created
persistentvolume/minio-local-persistent-volume created
persistentvolumeclaim/minio-local-persistent-volume-claim created
deployment.apps/minio-deployment created
service/minio-service-headless created
service/minio-loadbalancer-service created

# 생성 확인 → 내용이 많아 생략함
$ kubectl get -n minio all -o wide

# PV 생성 확인
$ kubectl get -n minio persistentvolume
NAME                                       CAPACITY  ACCESS MODES       RECLAIM POLICY   STATUS CLAIM            STORAGECLASS                                     REASON                       AGE
minio-local-persistent-volume     6900G          RWX                        Retain                  Bound    minio/minio-local-persistent-volume-claim       minio-local-storage              92s

# PVC 생성 확인
$ kubectl get -n minio persistentvolumeclaims
NAME                                              STATUS                   VOLUME                 CAPACITY   ACCESS MODES          STORAGECLASS              AGE
minio-local-persistent-volume-claim   Bound    minio-local-persistent-volume   6900G            RWX                  minio-local-storage          117s



3. headless 서비스 nslookup 확인

$ nslookup minio-service-headless.minio.svc.cluster.local
Server:         210.220.163.82
Address:        210.220.163.82#53

Non-authoritative answer:
Name:   minio-service-headless.minio.svc.cluster.local
Address: 218.38.137.27



4. MinIO 서비스의 Service IP를 통해 생성 확인 → Access Denied로 접근 불가

  • minio에 curl로 접근하면 Access Denied됨으로 다른 방법으로 접근

    # clusterIP 서비스를 통해 접근 가능
    $ curl 20.10.118.211:9000
    <?xml version="1.0" encoding="UTF-8"?>
    <Error><Code>AccessDenied</Code><Message>Access Denied.</Message><Resource>/</Resource><RequestId>16E0270B55D8E06A</RequestId><HostId>c2659a6e-1046-4fd9-8793-e756fbc033a2</HostId></Error>
    
    # LoadBalancer 할당 IP 서비스를 통해 접근 가능
    $ curl [LoadBalancer IP]:9000
    <?xml version="1.0" encoding="UTF-8"?>
    <Error><Code>AccessDenied</Code><Message>Access Denied.</Message><Resource>/</Resource><RequestId>16E026EBFCC13E44</RequestId><HostId>c2659a6e-1046-4fd9-8793-e756fbc033a2</HostId></Error>



5. MinIO 서비스에 Python으로 접근하여 확인

  • curl로 접근할 수 없기에 MinIO Client로 접근

    # minio 테스트에 사용할 파이썬3과 minio 패키지 설치
    $ yum install -y python3
    $ pip3 install minio
    
    # minio 접속 가능 테스트
    $ vi minio_api.py
    #!/bin/python3
    from minio import Minio
    
    if __name__ == '__main__':
       minioIP = "20.10.180.199:9000"     # serviceIP
       minioAccessKey = "minio"
       minioSecretKey = "melovethanos"
       client = Minio(minioIP, minioAccessKey, minioSecretKey, secure=False)
       print(client)
    
    # minio 접속 가능 테스트 실행 -> Minio Object 출력 시 이상 없음
    $ python3 minio_api.py
    <minio.api.Minio object at 0x7f2740e873c8>

  • 서버에 MinIO 설치
  • 로컬 디스크에 데이터를 유지하는 간단한 S3 호환 Minio 엔진을 시작

 

1. MinIO docker 설치

$ mkdir -p /data/minio
$ mkdir -p /var/log/minio/
$ touch /var/log/minio/minio.log

$ docker run -d --rm --name minio \
    -v /data/minio:/data \
    -v /var/log/minio/minio.log:/log/minio.log \
    -p 9000:9000 \
    -e "MINIO_ACCESS_KEY=minio" \
    -e "MINIO_SECRET_KEY=melovethanos" \
    -e "MINIO_HTTP_TRACE=/log/minio.log" \
    minio/minio:RELEASE.2019-01-31T00-31-19Z \
    server --anonymous --json /data

 

2. minio logrotate 작성

  1. 매주 생성
  2. gz으로 압축
  3. 압축파일에 날짜를 명시
  4. 수행 완료 후 minio 컨테이너 재실행
    $ vi /etc/logrotate.d/minio
    /var/log/minio/*.log {
    weekly
    rotate 5
    create 0644 root root
    missingok
    notifempty
    compress
    sharedscripts
    postrotate
       /bin/docker restart `docker ps | grep -i minio | awk -F ' ' '{print$1}'` > /dev/null 2>/dev/null || true
    endscript
    }

3. minio logrotate를 실행할 /etc/crontab 설정 및 logroate 적용

# logrotate 디버그
$ /usr/sbin/logrotate -d /etc/logrotate.d/minio
Allocating hash table for state file, size 15360 B

Handling 1 logs

rotating pattern: /var/log/minio/*.log  weekly (5 rotations)
empty log files are not rotated, old logs are removed
considering log /var/log/minio/minio.log
  log does not need rotating (log has been already rotated)not running postrotate script, since no logs were rotated

# logrotate 적용
$ /usr/sbin/logrotate -f /etc/logrotate.d/minio

# 압축 파일 생성 확인
$ ls /var/log/minio/
minio.log  minio.log.1.gz

# /etc/crontab 적용
# 매주 일요일 자정 logrotate 실행
$ vi /etc/crontab
00 00 * * 7 /usr/sbin/logrotate -f /etc/logrotate.d/minio

# log 확인
$ cat /var/lib/logrotate/logrotate.status  | grep minio
"/var/log/minio/minio.log" 2022-2-6-0:9:7  

 

4. thanos bucket(타노스 버킷) 생성

  • 향후 minio 오브젝트 스토리지에 thano 실행하기 위한 디렉토리 생성
    $ mkdir /data/minio/thanos

5. Minio 배포 확인

  1. Minio가 의도한 대로 작동하는지 확인 → http://[설치 서버IP]:9000
  2. 자격 증명을 입력
    • Access Key (액세스 키) : minio
    • Secret Key (비밀 키) : melovethanos

 

 

+ Recent posts