[CloudClub] 90DaysOfDevOps 4

11. Create CI/CD Pipelines

Day 70

📌 CI/CD 파이프라인

1. 파이프라인

✔️ 애플리케이션의 빌드, 테스트 및 배포를 자동화하여 개발과 운영 간의 격차 해소

2. CI/CD (지속적 통합/지속적 배포)

✔️ CI(지속적 통합): 점진적인 코드 변경을 더 자주, 안정적으로 수행하는 보다 현대적인 소프트웨어 개발 관행. 지속적 통합에 의해 리포지토리에 병합되는 코드 변경사항을 신뢰할 수 있도록 보장

✔️ CD(지속적 배포): CI에 의해 변경된 코드(애플리케이션)를 신속하고 원활하게 제공

3. CI/CD의 중요성

✔️ 소프트웨어를 빠르고 효율적으로 배포

✔️ 애플리케이션을 최대한 빠르게 시장에 출시하기 위한 효과적인 프로세스

✔️ 버전 릴리스를 기다릴 필요없이 버그 수정 및 기능 추가가 지속적으로 제공

4. 소프트웨어 개발 수명 주기 (SDLC)

⚡️ 개발자가 코드를 작성하면 빌드되거나 모두 컴파일되고, 버그가 있는지 테스트되고, 최종 사용자나 고객이 사용하는 프로덕션에 배포되고(운영), 모니터링 및 피드백을 수집하고, 마지막으로 해당 피드백을 중심으로 개선 사항을 계획하고 반복하는 것

📌 CI

개발자가 하루에 여러 번 공유 리포지토리에 코드를 통합해야 하는 개발 관행

✔️ 순서

1. 코드가 작성되어 레포지토리(Github 또는 GitLab)에 push

2. 자동화된 빌드를 통해 코드가 검증되므로 문제 확인 가능

3. 코드 분석 및 자동화된 테스트 수행

• 단위 테스트는 소스 코드의 개별 단위를 테스트

• 유효성 검사 테스트는 소프트웨어가 의도된 용도를 충족하거나 적합한지 확인

• 형식 테스트는 구문 및 기타 형식 지정 오류 확인

ㄴ workflow로 생성된 마스터 브랜치로 push할 때마다 실행되기에 자동화된 workflow를 구축하는 것이 효율적

4. 컴파일하여 레포지토리로 전송

• 레포지토리는 파이프라인의 CD 측면에 활용되는 모든 곳 가능

• ex. DockerHub

🔥 요약하면, CI 프로세스는 애플리케이션을 만들고, 버그 확인하고, 수정 이후 다음 소스 제어를 업데이트하고, 테스트하면서 버전 관리 수행

📌 CD

테스트된 버전의 코드 배포

➕ 오라클이나 Microsoft와 같은 공급업체로부터 소프트웨어를 받는 경우, DockerHub 유형 레포지토리에서 소비한 후 CD 파이프라인을 통해 배포

1. 올바른 코드 베이스를 올바른 환경에서 가져오고 있는지 확인

2. DockerHub에서 소프트웨어의 최신 릴리스를 가져온 후 환경에 릴리스하는 동시에 Git 레포지토리에 구성 가져와 환경에 push

• 구성이 올바른지 확인하기 위해 Staging 환경으로 이동하여 이 구성을 실행한 후 테스트를 위한 수동 단계 or 코드를 프로덕션에 배포하기 전에 다시 자동화 가능

➕ 애플리케이션의 v2가 나오면 해당 단계를 반복하여 애플리케이션과 구성이 Staging에 배포되어 모든 것이 정상인지 확인 후 프로덕션에 배포

📌 CI/CD를 사용하는 이유

🔥 자동화를 통해 작은 문제도 놓치지 않음

🔥 메인 코드 레포지토리는 시간이 지남에 따라 지속적으로 구축되기에 몇 년 후 더 많은 비용이 드는 기술 부채 방지

📌 도구

✔️ Jenkins

✔️ ArgoCD

✔️ GitHub Actions

Day 71

📌 Jenkins

1. Jenkins

✔️ 새로 만든 코드를 지속적으로 개발, 테스트 및 배포할 수 있는 지속적 통합 도구

2. 지속적 개발을 위한 방법

✔️ 개발자가 하루종일 작업 후 하루가 끝나면 변경 사항을 소스 코드 저장소에 push > 밤에 단위 테스트 실행 및 소프트웨어 빌드되는 방식

✔️ 개발자가 소스 코드에 변경사항을 커밋하고 해당 코드 커밋이 완료되면 빌드 프로세스가 지속적으로 시작되는 방식

=> 전세계의 분산된 개발자의 경우 매일 코드 변경을 중단해야하는 시간이 정해져있지 않음. 따라서 CI 서버 역할을 수행하여 테스트를 제어하고 프로세스를 구축하는 것이 Jenkins

3. Jenkins 이외의 오픈 소스 도구

✔️ TravisCI

✔️ Bamboo

✔️ Buildbot

✔️ Apache Gump

📌 Jenkins 특징

✔️ 간편한 설치

• Windows, macOS 및 Linux 운영 체제용 패키지와 함께 실행할 준비가 된 독립형 자바 기반 프로그램

✔️ 간편한 구성

• 오류 확인 및 기본 제공 도움말이 포함된 웹 인터페이스를 통해 쉽게 설정 및 구성할 수 있음

✔️ 플러그인

• 업데이트 센터에서 다양한 플러그인을 사용할 수 있으며 CI/CD 툴체인의 여러 도구와 통합됨

✔️ 확장 가능

• 사용 가능한 플러그인 외에도 플러그인 아키텍처를 통해 Jenkins를 확장할 수 있어 거의 무한한 용도로 사용 가능한 옵션 제공

✔️ 분산

• 여러 머신에 작업을 쉽게 분산하여 여러 플랫폼에서 빌드, 테스트 및 배포 속도를 높일 수 있도록 지원

📌 Jenkins 파이프라인

• Jenkins에 코드를 커밋하면 모든 자동화된 테스트를 통해 애플리케이션을 빌드한 다음 각 단계가 완료되면 해당 코드를 릴리스 및 배포

=> 해당 프로세스를 자동화한 것이 Jenkins

📌 Jenkins 아키텍처

✔️ Minikube 클러스터 내에 Jenkins를 설치하여 Kubernetes에 배포하는 과정 시뮬레이션

0. Jenkins 설치

• Windows, macOs, Linux 등 다양한 운영체제에 설치할 수 있으며 Docker 컨테이너로 배포하거나 Kubernetes 내에서 배포할 수 있는 기능 존재

https://www.jenkins.io/doc/book/installing/

1. 개발자가 소스 코드 레포지토리에 변경 사항 커밋

2. Jenkins가 정기적으로 레포지토리를 확인하여 새 코드 가져옴

3. 빌드 서버가 코드를 실행 파일로 빌드하며, 본 예시에서는 빌드 서버로 maven 사용

4. 빌드에 실패하면 개발자에게 피드백 전달

5. 빌드 성공한 경우, Jenkins는 빌드된 앱을 테스트 서버에 배포. 본 예시에서는 테스트 서버로 selenium 사용

6. 테스트가 실패하면 개발자에게 피드백 전달

7. 테스트가 성공하면 프로덕션에 릴리스 가능

🔥 위의 주기는 연속적이기에 애플리케이션을 몇 분마다 업데이트 가능

Day 72

📌 파이프라인

✔️ 아래 프로세스 또는 단계를 자동화하여 최종적으로 배포된 애플리케이션을 최종 사용자에게 제공하는 결과물을 얻음

✔️ 자동화된 프로세스를 통해 사용자에 대한 버전 관리를 수행할 수 있으며 코드가 정상인지 확인

✔️ Jenkins 파이프라인은 Jenkins 파일이라는 텍스트 파일로 작성되며 해당 파일은 소스 제어 레포지토리에 커밋되어야 함 => 코드형 파이프라인

📌 Jenkins 배포

✔️ Minikube 사용

✔️ 실습에 필요한 모든 파일은 해당 폴더에서 확인 가능

https://github.com/MichaelCade/90DaysOfDevOps/tree/main/2022/Days/CICD/Jenkins

1. Minikube 클러스터 시작하고 실행

minikube start

2. 위의 폴더에서 클러스터 생성 > jenkins 네임스페이스 생성

kubectl create -f jenkins-namespace.yml

kubectl get ns : namespace 조회

3. Jenkins 배포를 위해 Helm 사용

helm repo add jenkinsci https://charts.jenkins.io : Jenkins 레포지토리 추가

helm repo update : chart (k8s cluster에서 애플리케이션이 기동되기 위해 필요한 모든 리소스들이 포함) 업데이트

Helm : Kubernetes 패키지 관리 (Node.js의 pmp, Python의 pip과 같은 역할)

4. 지속성을 위해 volume 생성

kubectl apply -f jenkins-volume.yml

5. 서비스 계정 생성

kubectl apply -f jenkins-sa.yml

6. Helm chart 사용해 배포

chart=jenkinsci/jenkins : chart 정의

helm install jenkins -n jenkins -f jenkins-values.yml $chart : volume과 서비스가 포함된 jenkins-values.yml 배포

❗️ kubectl get pods -n jenkins : pod가 이미지를 가져와야 하지만 Jenkins 설치를 시작할 수 없다는 오류 발생

⭐️ 문제 해결을 위해 액세스 권한 제공

minikube ssh : 실행 중인 Minikube Docker 컨테이너에 접속

sudo chown -R 1000:1000 /data/jenkins-volume : 데이터 volume에 대한 권한 확인

• 위의 방법으로 pod가 수정되어야 하지만 그렇지 않은 경우 kubectl delete pod jenkins-0 -n jenkins로 pod 강제 새로 고침

• kubectl get pods -n jenkins : 실행 중인 pod가 2/2이고 이름이 jenkins-0 이어야 함

7. 관리자 비밀번호 필요

kubectl exec --namespace jenkins -it svc/jenkins -c jenkins -- /bin/cat /run/secrets/chart-admin-password && echo : 비밀번호 입력

8. 새 터미널 열어 워크스테이션에 접근

새 터미널에 kubectl --namespace jenkins port-forward svc/jenkins 8080:8080 : 워크스테이션에 접근

9. 브라우저 열기

http://localhost:8080 : 위 브라우저에 username:admin과 지정한 password로 로그인

✔️ 인증 완료된 페이지 : Jenkins 배포 완료

✔️ Manage Jenkins > Manage Plugins > 플러그인 모두 선택 후 Download now and install after restart

📌 Jenkinsfile

✔️ Jenkinsfile: 파이프라인의 단계를 정의하는 곳. " 빌드 > 테스트 > 배포 "

✔️ 해당 섹션에서는 단순히 echo 기능만 존재하는 Jenkinsfile 배포

1. Jenkins 대시보드에서 New Item 선택 후 이름 지정 + Pipeline 선택 : 이름을 echo1으로 지정

• 확인을 누르면 파이프라인에만 관심 있는 간단한 테스트를 위한 탭 표시. 파이프라인에 스크립트를 추가할 수 있으며 스크립트 복사하여 상자에 붙여 넣을 수 있음

• Jenkinsfile 저장 => 특정 단계 호출을 위해 echo 명령 사용

Jenkinsfile (Declarative Pipeline)

pipeline {
    agent any

    stages {
        stage('Build') {
            steps {
                echo 'Building..'
            }
        }
        stage('Test') {
            steps {
                echo 'Testing..'
            }
        }
        stage('Deploy') {
            steps {
                echo 'Deploying....'
            }
        }
    }
}

2. Build now를 사용해 빌드 실행

3. 터미널 열고 어떤 일이 발생하는지 확인

kubectl get pods -n jenkins

Day 73

📌 Jenkins 데모 파이프라인 구축

✔️ 이전 섹션에서는 Minikube 클러스터에 Jenkins를 배포하고 기본적인(echo기능만 존재) Jenkins 파이프라인 설정

✔️ 아래 그림에서 보이는 Declarative (Kubernetes) 데모 스크립트 사용

• Declarative 데모 스크립트

// Uses Declarative syntax to run commands inside a container.
pipeline {
    agent {
        kubernetes {
            // Rather than inline YAML, in a multibranch Pipeline you could use: yamlFile 'jenkins-pod.yaml'
            // Or, to avoid YAML:
            // containerTemplate {
            //     name 'shell'
            //     image 'ubuntu'
            //     command 'sleep'
            //     args 'infinity'
            // }
            yaml '''
apiVersion: v1
kind: Pod
spec:
  containers:
  - name: shell
    image: ubuntu
    command:
    - sleep
    args:
    - infinity
'''
            // Can also wrap individual steps:
            // container('shell') {
            //     sh 'hostname'
            // }
            defaultContainer 'shell'
        }
    }
    stages {
        stage('Main') {
            steps {
                sh 'hostname'
            }
        }
    }
}

• 결과

📌 Job 만들기

✔️ 목표

1. 간단한 앱을 만들어 GitHub 공용 레포지토리에 저장

https://github.com/scriptcamp/kubernetes-kaniko

2. Jenkins를 사용하여 Docker 컨테이너 이미지를 빌드하고 DockerHub에 push (비공개 레포지토리 사용)

➕ Minikube에서 실행 중이거나 Minikube를 사용하는 Kubernetes 클러스터에서 해당 작업을 수행하려면 Kaniko 라는 것을 사용해야하지만, 실제 Kubernetes 클러스터에서 Jenkins를 사용하거나 서버에서 실행하는 경우 에이전트를 지정하여 Docker 빌드 명령을 수행하고 이를 DockerHub에 업로드하는 기능을 제공하는 것이 일반적

✔️ GitHub credentials로 Kubernetes에 시크릿 배포

kubectl create secret docker-registry dockercred \
    --docker-server=https://index.docker.io/v1/ \
    --docker-username=<dockerhub-username> \
    --docker-password=<dockerhub-password>\
    --docker-email=<dockerhub-email>

📌 Jenkins에 credentials 추가

✔️ 생성 시 결정한 ID를 사용하여 파이프라인에서 credentials 참조 가능 + DockerHub 및 GitHub에 대한 사용자 항목 생성

1. Manage Jenkins > Manage Credentials 생성

2. 범위가 Jenkins로 설정된 Stores 표시되면 Jenkins 클릭

3. Global Credentials (unrestricted) 선택

4. Add Credentials

• 계정에 대한 세부 정보 입력 : 참조할 ID 기억

• 비밀번호 대신 특정 토큰 액세스를 사용하는 것 권장. GitHub의 경우 Personal Access Token 사용

📌 파이프라인 구축

✔️ Kubernetes 클러스터에 secret으로 배포된 DockerHub credentials를 가지고 있으며, 이 credentials를 파이프라인의 DockerHub 단계에 배포하기 위해 호출

1. Jenkins 대시보드에서 New item 선택

2. 이름 지정 후 Pipeline 선택

3. Pipeline 탭의 script에 아래 코드 복붙

podTemplate(yaml: '''
    apiVersion: v1
    kind: Pod
    spec:
      containers:
      - name: maven
        image: maven
        command:
        - sleep
        args:
        - 99d
      - name: kaniko
        image: gcr.io/kaniko-project/executor:debug
        command:
        - sleep
        args:
        - 9999999
        volumeMounts:
        - name: kaniko-secret
          mountPath: /kaniko/.docker
      restartPolicy: Never
      volumes:
      - name: kaniko-secret
        secret:
            secretName: dockercred
            items:
            - key: .dockerconfigjson
              path: config.json
''') {
  node(POD_LABEL) {
    stage('Get the project') {
      git url: 'https://github.com/scriptcamp/kubernetes-kaniko.git', branch: 'main'
      container('maven') {
        stage('Test the project') {
          sh '''
          echo pwd
          '''
        }
      }
    }

    stage('Build & Test the Docker Image') {
      container('kaniko') {
        stage('Deploy to DockerHub') {
          sh '''
            /kaniko/executor --context `pwd` --destination me1e/helloword
          '''
        }
      }
    }

  }
}

4. Build now

5. DockerHub로 이동해 새 빌드가 있는지 확인

• DockerHub 레포지토리는 비공개 레포지토리

Day 74

📌 Hello World - Jenkinsfile 앱 파이프라인

✔️ 이전 섹션에서는 공개 GitHub 레포지토리에 있는 dockerfile에서 비공개 Dockerhub 레포지토리로 docker 이미지를 push하는 Jenkins 파이프라인 구축

✔️ 본 섹션에서는 간단한 애플리케이션을 통해 Jenkinsfile 파이프라인 구축

✔️ 목표

• Dockerfile(Hello World) / Jenkinsfile / GitHub 레포지토리가 업데이트될 때 트리거할 Jenkins 파이프라인 / GitHub 레포지토리를 소스로 사용 / Run - 레포지토리 복제, 가져오기, 빌드, 테스트, 배포 / 점진적인 버전 번호로 DockerHub에 배포 / Kubernetes 클러스터에 배포하는 Stretch Goal

1. GitHub 레포지토리에 파이프라인 소스로 사용하던 Jenkins 파이프라인 스크립트 추가

2. Jenkins 대시보드로 돌아가서 새 파이프라인 생성

• 이때 스크립트를 붙여 넣는 대신 "Pipeline script from SCM" 옵션 사용

• 저장을 누르면 수동으로 파이프라인을 실행하여 DockerHub 레포지토리에 업로드된 새 Docker 이미지 빌드 가능

• 레포지토리 또는 소스 코드가 변경될 때마다 빌드되도록 하고 싶은 경우 webhooks를 사용하거나 예약 pull 사용 가능

• 값비싼 클라우드 리소스를 사용하고 있고 코드 변경사항이 많은 경우 비용이 많이 들기에, 데모 환경이라는 것을 인식하고 "poll scm" 옵션 사용 <- minikube를 사용하면 webhooks 기능 부족

3. 이미지를 공개 저장소(DockerHub)에 업로드하고 싶음

• 이전 섹션에서 생성한 컨테이너 이미지 모두 삭제

4. Jenkins로 돌아가서 pipeline 생성 후 구성 추가 + Build now 클릭

5. DockerHub 레포지토리에 2개의 새 Docker 이미지 존재

6. 깃허브 레포지토리에서 index.html 파일 업데이트

7. Jenkins에서 Build now 이후 DockerHub에서 확인

• 버전 2와 최신 태그 존재 확인

⭐️ Kubernetes 클러스터에 액세스 및 인증을 통해 DockerHub로 도커 빌드를 push하는 시크릿 추가 => 내 레포지토리 및 계정과 연결된 Jenkins 파일 변경 필요

Day 75

📌 GitHub Actions

✔️ GitHub Actions는 파이프라인의 다른 작업들 사이에서 빌드, 테스트 및 배포할 수 있는 CI/CD 플랫폼. GitHub 레포지토리를 대상으로 빌드하고 테스트하는 Wolkflow 개념 존재 => GitHub Actions를 사용하여 리포지토리 내에서 발생하는 Event를 기반으로 다른 Wolkflow 구동 가능

1. Wolkflow

✔️ 전반적으로 GitHub Actions에서 작업을 부르는 이름

• 구성 가능한 자동화된 프로세스

• YAML 파일로 정의

• 하나 이상의 Job을 포함하고 실행

• 레포지토리의 Event에 의해 트리거될 때 실행되거나 수동으로 실행 가능

• 레포지토리 당 여러 wolkflow 사용 가능

• Wolkflow에는 Job과 해당 Job을 달성하기 위한 Step 포함

• Wolkflow 내에는 Wolkflow가 실행되는 Runner 존재

✔️ ex. PR을 빌드하고 테스트하는 Wolkflow, 릴리스가 만들어질 때마다 애플리케이션을 배포하는 Wolkflow, 누군가 새 issue를 열 때마다 레이블을 추가하는 Wolkflow 등

2. Event

✔️ Wolkflow를 실행하도록 트리거하는 레포지토리의 특정 이벤트

3. Job

✔️ Runner에서 실행되는 Wolkflow의 Step 집합

4. Step

✔️ Job 내의 각 step은 실행되는 shell 스크립트 또는 Action이 될 수 있고 순서대로 실행되며 서로 종속적

5. Action

✔️ 자주 반복되는 작업에는 반복 가능한 사용자 지정 애플리케이션이 사용됨

6. Runner

✔️ Wolkflow를 실행하는 서버로, 각 Runner는 한 번에 하나의 작업 실행

✔️ GitHub Actions는 Ubuntu Linux, Microsoft Windows 및 macOS Runner를 실행할 수 있으며 특정 OS 또는 하드웨어에서 직접 호스팅 가능

✔️ Wolkflow 트리거하는 Event > Wolkflow가 두 개의 Job으로 구성 > Job 내의 Step과 Action

7. YAML

✔️ 위의 이미지를 YAML 파일로 변환

#Workflow
name: 90DaysOfDevOps
#Event
on: [push]
#Jobs
jobs:
  check-bats-version:
    #Runner
    runs-on: ubuntu-latest
    #Steps
    steps:
        #Actions
      - uses: actions/checkout@v2
      - uses: actions/setup-node@v2
        with:
          node-version: '14'
      - run: npm install -g bats
      - run: bats -v

📌 GitHub Actions 실습 : 코드 lint에 GitHub Actions 사용

✔️ GitHub/super-linter 사용해 코드 확인

name: Super-Linter

on: push

jobs:
  super-lint:
    name: Lint code base
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2

      - name: Run Super-Linter
        uses: github/super-linter@v3
        env:
          DEFAULT_BRANCH: main
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

⭐️ Wolkflow에서 환경 변수 GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} 전달. GitHub Secret은 GitHub에서 자동으로 설정하므로 설정할 필요가 없으며, Action으로 전달하기만 하면 됨

1. 테스트할 레포지토리는 Jenkins 데모에서 사용한 레포지토리

2. 레포지토리에 새 파일 생성

➕ Actions를 사용하려면 Actions 탭을 사용하여 마켓플레이스에서 선택하거나 위의 super-linter 코드를 사용하여 파일 생성해야 함

.github/workflows/super-linter.yml 이름의 파일에 바로 위의 코드 복붙 후 커밋

3. 커밋 후 Actions 탭으로 이동

• super-linter Wolkflow 표시

• 코드에서 레포지토리에 무언가를 push할 때 Wolkflow가 실행되도록 정의했기에 Wolkflow가 트리거 되지만 오류 발생

=> super-linter의 버전을 3에서 4로 변경 후 다시 실행

• 성공

Day 76

📌 ArgoCD

Argo CD는 Kubernetes를 위한 선언적 GitOps 지속적 배포 도구입니다

✔️ minikube kubernetes 클러스터를 다시 로컬로 사용해 ArgoCD 배포

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

✔️ kubectl get pods -n argocd로 ArgoCD pod가 실행되고 있는지 확인

✔️ kubectl get all -n argocd로 네임스페이스에 배포한 모든 것 확인

✔️ 위의 내용이 정상적으로 보이면 포트 포워드를 통해 접근

• 새 터미널에 kubectl port-forward svc/argocd-server -n argocd 8080:443 명령 사용 후 웹브라우저에 https://localhost:8080 입력

✔️ 로그인을 위해 사용자 이름과 비밀번호 사용

• kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d && echo

✔️ 로그인 완료 페이지

12. Monitoring, Log Management, and Data Visualization

Day 77

📌 모니터링

1. 모니터링

✔️ 전체 인프라를 면밀히 주시하는 프로세스

2. 필요성

✔️ 서버의 모든 서비스, 애플리케이션, 리소스가 정상적으로 실행되고 있는지 확인할 책임이 있음

3. 모니터링 방법

✔️ 모든 서버에 수동으로 로그인하여 서비스 프로세스 및 리소스에 대한 모든 데이터 확인

✔️ 우리를 대신하여 서버에 로그인하고 데이터를 확인하는 스크립트 작성

✔️ 시중에 나와있는 모니터링 솔루션 사용 ex. Nagios, Zabbix

📌 Nagios

✔️ Nagios는 인프라 모니터링 도구로, 서버를 모니터링하고 서버와 서비스, 인프라가 충분히 활용되고 있는지 또는 해결해야 할 장애 작업이 있는지 확인 가능

✔️ 디스크 또는 서버가 위험한 상태에 있을 때 경고하여 서비스 중단을 피하기 위한 적절한 조치를 취할 수 있도록 알려줌

📌 지속적인 모니터링

✔️ 모니터링과 관련한 주요 영역: 인프라 모니터링, 애플리케이션 모니터링, 네트워크 모니터링

Day 78

✔️ Prometheus 사용해 모니터링

📌 Prometheus

1. Prometheus

✔️ 컨테이너와 마이크로서비스 기반 시스템뿐만 아니라 물리적, 가상 및 기타 서비스를 모니터링하는 데 도움이 되는 오픈소스

✔️ 여러 프로그래밍 언어 지원

2. pull 접근 방식

✔️ 수천 개의 마이크로서비스 또는 시스템 및 서비스와 대화하는 경우 push 방식은 일반적으로 서비스가 모니터링 시스템으로 push하는데, 네트워크 과부하, 높은 CPU 사용량, 단일 장애 지점 등의 문제 발생

✔️ pull 방식은 모든 서비스의 메트릭 엔드포인트에서 Prometheus가 끌어옴

3. Prometheus의 구성을 위한 YAML

✔️ Kubernetes에 배포되었을 때 작업/exporter로부터 메트릭을 가져오는 PushGateway

✔️ 알림을 push하는 AlertManager => 외부 서비스(이메일,슬랙 등)와 통합

✔️ PushGateway에서 pull 메트릭의 검색을 관리하고 push 알림을 AlertManager로 전송하는 Prometheus Server => 로컬 디스크에 데이터 저장

✔️ 메트릭과 상호 작용하는데 사용되는 PromQL

📌 Prometheus 배포 방법

✔️ 구성 YAML 파일 생성

✔️ 오퍼레이터 사용 (모든 Prometheus 구성 요소의 관리자)

✔️ Helm 차트를 사용하여 오퍼레이터 배포

📌 Kubernetes에 배포

✔️ 로컬에서 minikube 클러스터 사용 + Helm 사용해 Prometheus Helm 차트 배포

1. Prometheus Helm 차트 배포

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts

helm repo update : Helm 레포지토리 업데이트

helm repo list

2. minikube 환경에 Prometheus 배포

helm install stable prometheus-community/prometheus

kubectl get pods : (일정 시간 후) pod 생성 확인

kubectl get all : 모든 pod 실행되면 Prometheus의 배포된 측면 조회 가능

3. Prometheus Server UI에 액세스하기 위해 포트 포워딩

export POD_NAME=$(kubectl get pods --namespace default -l "app=prometheus,component=server" -o jsonpath="{.items[0].metadata.name}") kubectl --namespace default port-forward $POD_NAME 9090

4. 브라우저 열기

http://localhost:9090

• container_cpu_usage_seconds_total을 통해 PromQL을 사용하여 메트릭 캡처 확인

Day 79

📌 로그 관리 및 집계

✔️ 로그 집계란 다양한 서비스에서 애플리케이션 로그를 수집하고 태그를 지정하여 쉽게 검색할 수 있는 단일 대시보드에 저장하는 방법

✔️ 애플리케이션 성능 관리 시스템에서 가장 먼저 구축해야하는 시스템 중 하나

📌 예제 앱

✔️ 웹 앱으로, 일반적인 프론트엔드와 백엔드가 중요한 데이터를 MongoDB 데이터베이스에 저장

✔️ 사용자가 페이지가 모두 하얗게 변하고 오류 메세지가 인쇄되었다고 말하면 현재 스택의 문제를 진단하기 위해 사용자가 수동으로 오류를 보내야하고 다른 세 가지 서비스의 관련 로그와 일치시켜야 함

📌 Elk

✔️ 세 가지 구성 요소인 Elasticsearch, Logstash, Kibana의 이름을 딴 오픈 소스 로그 집계 스택

1. 구성 요소

✔️ 모든 서비스가 Logstash로 로그를 전송하고, Logstash는 애플리케이션이 방출하는 텍스트인 로그를 가져옴

✔️ Logstash는 로그 메세지에서 사용자가 언제 무엇을 했는지 추출하고 이를 태그로 포함시켜 텍스트 쿼리 DB인 Elasticsearch에 저장

✔️ Elasticsearch는 Kibana로 결과를 노출하고 Kibana는 Elasticsearch에 연결하는 웹 서버로 개발자나 관리자를 허용

✔️ 관리자는 Kibana에 연결하고, Kibana는 사용자가 원하는 것과 일치하는 로그를 찾기 위해 Elasticsearch를 쿼리

2. Elk를 사용해 프로덕션 문제 진단 방법

✔️ 오류 코드를 검색 창에 입력하면 해당 로그가 표시되고, 그 로그를 생성한 서비스가 로그를 생성한 백엔드이고, 해당 로그가 생성된 시간의 백엔드 메세지 확인하여 원인 찾을 수 있음

3. 보안 및 로그 액세스

✔️ 로그는 관리자에게만 표시되도록 해야함

📌 로그 관리 도구의 예

• Elasticsearch

• Logstash

• Kibana

• Fluentd

• Datadog

• LogDNA

• Splunk

Day 80

📌 ELK 스택

1. Elasticsearch

✔️ 모든 유형의 데이터를 위한 분산형 무료 개방형 검색 및 분석 엔진

2. Logstash

✔️ 다양한 소스에서 데이터를 수집하고 변환한 다음 원하는 저장소(stash)로 전송하는 무료 개방형 서버측 데이터 처리 파이프라인

3. Kibana

✔️ 무료 개방형 사용자 인터페이스로, Elasticsearch 데이터를 시각화하고 Elastic Stack을 탐색할 수 있게 해줌

✔️ 쿼리 로드 추적과 앱에서 요청이 흐르는 방식 이해 가능

📌 ELK 스택 과정

1. Log : 분석해야 하는 서버 로그 식별

2. Logstash : 로그와 이벤트 데이터 수집. 데이터 구문 분석 및 변환 가능

3. ElasticSearch : Logstash에서 변환된 데이터는 저장, 검색 및 색인 가능

4. Kibana : Elasticsearch DB를 사용해 탐색, 시각화, 공유

Day 81

📌 Fluentd & FluentBit

✔️ Fluentd : 데이터 수집기. 깨끗하고 안정적인 로깅 파이프라인을 구축하는 데 적합한 4가지 주요 기능 존재

• JSON을 사용한 통합 로깅 : 가능한 데이터를 JSON으로 구조화하려 노력. 액세스할 수 있는 충분한 구조를 가지고 있기에 JSON 사용하면 다운스트림 데이터 처리가 쉬워짐

• 플러그 가능한 아키텍처 : 기능을 확장할 수 있는 유연한 플러그인 시스템을 갖춰 로그를 효과적으로 활용 가능

• 최소한의 리소스 필요 : 데이터 수집기는 바쁜 컴퓨터에서도 편안하게 실행되어야 하므로 가벼워야함

• 내장된 안정성 : 데이터 손실은 절대 일어나지 않아야 함

📌 앱이 데이터를 기록하는 법

✔️ 파일에 기록 .log 파일

✔️ 데이터베이스에 직접 기록

✔️ 타사 애플리케이션 (NodeJS, NGINX, PostgreSQL)

⚡️ FluentD는 위의 3가지 로깅 데이터 유형을 허용하고 수집, 처리하여 대상(Elastic, MongoDB, Kafka DB)으로 로그를 전송하는 기능 제공

⚡️ Fluentd와 FluentBit는 입력 플러그인을 사용하여 데이터를 FluentBit 형식으로 변환한 다음, 출력 플러그인을 사용하여 ElasticSearch와 같은 출력 대상이 무엇이든 출력 가능

📌 Kubernetes의 FluentBit

✔️ Kubernetes의 FluentBit는 데몬셋으로 배포되며, 이는 클러스터의 각 노드에서 실행됨을 의미 => 각 노드의 FluentBit pod는 해당 노드의 컨테이너를 읽고 모든 로그 수집

1. Fluent Helm 레포지토리에 배포

helm repo add fluent https://fluent.github.io/helm-charts

helm install fluent-bit fluent/fluent-bit : 설치

2. fluent-bit pod가 실행 중인지 확인

kubectl get all | grep fluent : 실행 중인 pod, 서비스 및 데몬셋 확인

3. FluentBit이 로그를 어디에서 가져올지 알 수 있는 구성 파일이 있으며, 이와 유사한 것이 configmap

kubectl get configmap : configmap 확인

4. pod를 포트 포워딩해 연결성 확보

kubectl get pods | grep fluent으로 pod 이름 가져와서 kubectl port-forward [pod이름] 2020:2020

5. http://localhost:2020/로 웹브라우저 열기

Day 82

📌 EFK 스택 소프트웨어

✔️ 이전 섹션에서는 로그 수집기로 Logstash를 사용하는 ELK 스택이었고, 이번 섹션에는 FluentD 또는 FluentBit를 사용하는 EFK 스택

1. Elasticsearch

• NoSQL 데이터베이스는 데이터를 저장하는데 사용되며 검색 및 로그 쿼리를 위한 인터페이스 제공

2. Fluentd

• 통합 로깅 계층을 위한 오픈 소스 데이터 수집기로, 데이터 수집과 소비를 통합하여 데이터를 더 잘 사용하고 이해할 수 있음

3. Kibana

• 로그 관리 및 통계를 위한 인터페이스로 elasticsearch에서 정보를 읽는 역할

📌 minikube에 EFK 배포

✔️ minikube 클러스터를 사용해 EFK 배포

1. minikube start를 사용해 클러스터 시작 => WSL2가 활성화된 Windows OS 사용

2. EFK 스택을 클러스터에 배포하는 데 필요한 yml 파일(아래 링크) 생성

https://github.com/MichaelCade/90DaysOfDevOps/blob/main/2022/Days/Monitoring/EFK%20Stack/efk-stack.yaml

• 이후 kubectl create -f efk-stack.yaml으로 배포

3. kubectl get pods -n kube-logging -w을 통해 진행 상황 확인

4. kubectl get pods -n kube-logging을 통해 모든 pod가 실행 중인지 확인

• ElasticSearch와 연결된 3개의 pod / Fluentd와 연결된 pod 1개 / Kibana와 연결된 pod 1개 확인

5. kubectl get all -n kube-logging을 사용해 네임스페이스 표시

• fluentd는 데몬셋으로 배포되고, kibana는 deployment로, elasticsearch는 statefulset으로 배포

6. 새 터미널에 kubectl port-forward kibana-84cf7f59c-v2l8v 5601:5601 -n kube-logging 명령어 실행하여 포트 포워딩 및 kibana 대시보드 액세스

7. 브라우저에서 http://localhost:5601 이동

• 왼쪽 메뉴의 discover 탭 누르고 Index pattern에 * 추가 > next step

• Time Filter field name에서 @timestamp 옵션 선택 > create index pattern

• discover 탭으로 들어가면 데이터가 들어오는 것 확인 가능

Day 83

📌 데이터 시각화 - Grafana

1. Kibana

✔️ Kibana의 핵심 기능은 데이터 쿼리 및 분석으로, 사용자는 데이터 내의 특정 이벤트나 문자열에 대해 Elasticsearch에서 색인된 데이터를 검색할 수 있음

✔️ 쿼리를 기반으로 다양한 방식으로 데이터 시각화

2. Grafana

✔️ 일반적으로 Prometheus와 Grafana를 함께 사용하는 것을 볼 수 있지만, Elasticsearch 및 Graphite와 함께 사용하는 경우도 존재

⭐️ Kibana는 Elasticsearch 위에서 실행되며 주로 로그 메세지 분석에 사용되고, Grafana는 시스템 CPU, 메모리, 디스크 및 I/O 사용률과 같은 메트릭을 분석하고 시각화에 적합

⭐️ Kibana와 Grafana 모두 배포가 쉽고 배포 위치를 선택할 수 있으며, Linux, Mac, Windows, Docker에 설치하거나 소스에서 빌드하는 것을 지원

📌 Prometheus Operator + Grafana Deployment

✔️ Grafana가 Prometheus 데이터베이스에 수집 및 저장된 메트릭의 대화형 시각화 제공 => 사용자 정의 차트, 그래프 및 알림을 만들 수 있음

✔️ minikube 클러스터 사용

1. 로컬 시스템에 복제

git clone https://github.com/prometheus-operator/kube-prometheus.git

cd kube-prometheus

2. minikube 클러스터 내에 네임스페이스 생성

kubectl create -f manifests/setup

3. 데모에 필요한 모든 것 배포

kubectl create -f manifests/

4. pod가 실행될 때까지 대기 및 감시

kubectl get pods -n monitoring -w

5. 모두 실행 중이면 모든 pod가 정상 상태인지 확인

kubectl get pods -n monitoring

6. 서비스 배포 확인

kubectl get svc -n monitoring

7. 배포된 모든 리소스 확인

kubectl get all -n monitoring

8. 새 터미널에 kubectl --namespace monitoring port-forward svc/grafana 3000로 포트포워딩

9. 브라우저 http://localhost:3000로 이동

• 기본 사용자 이름과 비밀번호

Username: admin
Password: admin

10. kubectl --namespace monitoring port-forward svc/prometheus-k8s 9090로 prometheus 포팅 > Add your first data source 클릭 후 Prometheus 선택

• http://localhost:9090로 주소 변경 > save&test 클릭

11. 홈페이지에서 create your first dashboard > Add a new panel 선택 > Data source에 Prometheus-1 선택 > metric으로 cluster:node_cpu:ratio{} 입력(클러스터 노드에 대한 세부 정보 제공하고 통합이 작동하고 있음을 증명)

📌 알림

✔️ 배포한 알림 관리자를 활용하여 슬랙이나 다른 통합으로 알림 전송 가능

=> kubectl --namespace monitoring port-forward svc/alertmanager-main 9093 http://localhost:9093로 포트 포워딩

week4 TMI

Pull 접근 방식과 Push 접근 방식

1. Push 방식

✔️ 각 서버에 클라이언트를 설치하고 이 클라이언트가 메트릭 데이터를 수집해서 서버로 보내면 서버가 모니터링 상태를 보여주는 방식

2. Pull 방식

✔️ 서버에 클라이언트가 떠있으면 서버가 주기적으로 클라이언트에 접속해서 데이터를 가져오는 방식