Do it, it will be better

[AWS]AWS Certified Solutions Architect - Associate 후기

용감한 개복치 — Wed, 30 Oct 2024 03:43:42 +0900

합격 후기 :

이틀 정도 덤프 문제 200개 가량 풀고 들어갔다.

평소 관련된 일을 하다가 시험을 치러가면 쓰던 서비스에 대해서는 대충 읽고 끼워 맞추기가 가능하다.

다만, 안써보던 서비스들의 경우 정말 모르니 덤프 문제집에서 내가 들어보지 못했다 + 덤프에서 반복적으로 등장한다 - 하는 서비스들 위주로 문제 + 4지 선다의 답변들 눈에 익히고 들어가는 방법이 가장 효율적이었다.

문제 은행식이어서 가능한 방법인 것 같다.

환율 낮을 때 신청하면 좀 더 싸다.

50% 할인 바우처 너무너무너무 중요하다. 이거 시험 너무 비싸ㅠ

이쪽 직군의 자격증들 다 너무 비싸다...CKA, AWS 등등..

[k8s]파드 스케일링(1)

용감한 개복치 — Wed, 30 Oct 2024 03:24:30 +0900

목표

https://cloud.google.com/blog/products/containers-kubernetes/kubernetes-best-practices-resource-requests-and-limits

안정적인 서비스

안정적인-의 기준 세우기

정밀한 스케일링을 위한 모니터링 + 실험 추가 필요

자원관리

resource

limits : pod가 실행될때 사용할수 있는 최대 cpu, memory
- Limit을 pod가 넘기면 cpu는 throttling이 걸리고, memory는 pod가 종료(oom)
  - oom이 자주 일어나는 서비스들의 노드 여분 리소스를 확인하면서 기존 설정된 memory limit에 대한 검토 필요
- 실제 노드의 여분 리소스와 상관없이 limit 값으로 결정되기 때문에 아이디어스의 데브옵스팀은 cpu limit을 해제하는 방식 채택하기도 함 → 단, 이 때는 노드 리소스가 넉넉하거나 유연해야 안정성 확보 가능
requests : pod가 실행되는데 최소한으로 필요한 cpu, memory
- 파드를 넣을 노드를 결정 할 때 기준. 단, 실제 실행 될 때 limit 값을 사용하기 때문에 노드의 할당가능한 리소스보다 리밋의 합이 클 때 overcommit 상태가 됨 → 장애!

namespace resource

limitrange :
- 네임스페이스에서 파드 하나의 리소스 limit, request 구성
resourcequota :
- 네임스페이스별 총 리소스 사용을 제한하는 제약 조건을 제공
- 유형별로 네임스페이스에서 만드는 오브젝트, 컴퓨팅 리소스양 제한

상태확인

kubectl describe node

allocatable : 데몬 같은거 제외하고 pod에 할당 할 수 있는 총 용량
각 파드 별로 리퀘스트, 리밋 기준 얼마나 사용하고 있는지 볼 수 있음.

kubectl top node
kubectl top pod

cpu, memory 만 알아보기

QoS

https://kubernetes.io/docs/concepts/workloads/pods/pod-qos/

Quality of Service

파드의 우선순위. 노드에 메모리 자원이 부족해지면 어떤걸 먼저 아웃시키는가 에 대한 클래스

Kubelet에 기본적으로 노드 가용 메모리가 100mi 이하일 때 memory pressure가 발생하도록 설정되어있음.

memory pressure 발생하면,

해당 노드에서 실행 중인 모든 파드에 대해 우선순위를 매겨 가장 낮은 순서부터 다른 노드로 쫓아냄.
해당 노드에선 새로운 파드를 할당 받지 않음.

종류

BestEffort : resources 항목을 아예 사용하지 않을 경우. limit, request 둘 다 x → 노드의 모든 자원 사용할 수도 있고, 전혀 사용하지 못할 수 도 있음
Burstable : Request의 지정된 만큼 리소스를 보장받고 상황에 따라서는 limit까지 사용 가능
Guaranteed : limit == request 일때. 자원 사용을 무조건 보장받음
우선순위 : Guaranteed > Burstable > BestEffort

스케일 인/아웃 테스트

kubectl 명령어 공식문서

https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#autoscale

적용하기

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: hpa-test-service
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: deploy-test-service
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

version : 2부터 다양한 메트릭 참조 가능, 1은 cpu만 가능

cpu utilization : request의 cpu 값이 기준

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: hpa-test-service
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: deploy-test-service
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Pods
      pods:
        metric:
          name: http_requests
        target:
          type: AverageValue
          averageValue: "100"

http_requests : 각 Pod의 평균 요청 수가 100이 될 때마다 스케일 인/아웃이 발생

단, 이를 위해서는 메트릭 서버가 http_requests 메트릭을 수집하고 있어야함.

수집 중인 메트릭

kubectl get --raw "/apis/metrics.k8s.io/v1beta1" | jq

{
  "kind": "APIResourceList",
  "apiVersion": "v1",
  "groupVersion": "metrics.k8s.io/v1beta1",
  "resources": [
    {
      "name": "nodes",
      "singularName": "",
      "namespaced": false,
      "kind": "NodeMetrics",
      "verbs": [
        "get",
        "list"
      ]
    },
    {
      "name": "pods",
      "singularName": "",
      "namespaced": true,
      "kind": "PodMetrics",
      "verbs": [
        "get",
        "list"
      ]
    }
  ]
}

요약 : 리소스 메트릭만 수집중, 어플리케이션 래벨의 커스텀 메트릭 x

NodeMetrics (nodes):
- 클러스터의 각 노드(node)에 대한 메트릭을 수집합니다.
- 메트릭 종류: 노드 수준의 메트릭 (CPU, 메모리 사용량 등)
- 메트릭 접근 방법: get, list
PodMetrics (pods):
- 각 네임스페이스(namespace) 내의 파드(pod)에 대한 메트릭을 수집합니다.
- 메트릭 종류: 파드 수준의 메트릭 (CPU, 메모리 사용량 등)
- 메트릭 접근 방법: get, list

cpu 부하주기

명령어 :

kubectl run -i --tty load-generator --rm --image=busybox:1.28 --restart=Never -- /bin/sh -c "while sleep 0.01; do wget -q -O- http://<deployment 서비스 이름>:<파드 포트>; done"

테스트값 :

cpu utilization 10

스케일 아웃 까지 시간 : 부하 들어가고 1분이내

스케일 인 까지 시간 : 부하 주는 것 멈추고 2분 이내

HPA 확인

kubectl get hpa -w

참고문서

https://kubernetes.io/ko/docs/tasks/run-application/horizontal-pod-autoscale/

https://no-easy-dev.tistory.com/entry/쿠버네티스-Pod-자원관리-QoS

https://velog.io/@hsshin0602/쿠버네티스-auto-scaling

[Network]4계층 TCP & UDP

용감한 개복치 — Wed, 30 Oct 2024 03:13:24 +0900

Transport 계층

OSI 7 계층 분류에서 엔드 투 엔드 유저들이 신뢰성 잇는 데이터를 주고 받을 수 있도록 함.
그위 세션, 프레젠테이션, 어플리케이션 레벨이 데이터 전달의 걱정을 안하게 해줌
- 어플리케이션 프로세스 사이의 논리적 통신 제공 -> 데이터를 어떻게 전송할까 결정
- host(라우터) 간의 논리적 통신을 제공한다? -> 네트워크 계층

TCP

OSI 7 계층 중 4층, 전송 계층
연결 지향적, 신뢰성, 데이터 전송 보장
- udp 보다 속도 느림
- point to point
웹, 이메일, 파일 전송 등에 사용
흐름 제어, 혼잡 제어
3-way handshaking 으로 연결, 4-way handshaking 으로 해제 -> tcp 헤더 필드 값 사용

3-way handshaking

TCP 의 접속 설정
네트워크 연결을 설정
양쪽의 준비를 보장하고 검증

과정

SYN: 클라이언트 → 서버
- 클라이언트가 syn segment 서버로 보냄
- 서버는 수신
SYN+ACK: 서버 → 클라이언트
- 서버가 클라이언트에게 ack segment, 동시에 syn segment 보냄
- 클라이언트가 ack segment 받으면 ESTAB 상태
ACK: 클라이언트 → 서버
- 클라이언트가 서버에게 ack segment 전송
- 서버도 ack segment 받으면 ESTAB 상태

4-way handshaking

TCP 의 접속 해제

과정

FIN: 클라이언트 → 서버
- 클라이언트가 서버에게 fin segment 보냄
ACK: 서버 → 클라이언트
- 서버는 fin 받고, 확인 ack 를 클라이언트에게 보냄
- 데이터를 모두 전송 후 통신 끝날때 까지 대기
FIN: 서버 → 클라이언트
- 서버가 데이터 모두 보내고 연결 종료에 합의하는 fin 패킷 클라이언트에게 전송
ACK: 클라이언트 → 서버
- fin 을 받은 클라이언트가 응답으로 서버에게 ack 전송
- time_wait 상태로 의도치 않은 에러로 연결이 데드락 빠지는 것을방지
- 이후 종료

차이

fin, 서버가 보낼 데이터가 남았는가를 검증하는 단계
단, fin 이후에 유실 및 지연된 데이터가 도착 할 수 있으므로 time_wait 단계가 추가됨

L4 스위치 ( 근데 이제, NLB 이해를 곁들인... )

얘가 가상화 된게 AWS NLB
로드밸런싱을 처리하는 장비 -> 외부에서 들어오는 모든 요청은 바로 서버로 가지않고 여기서 로드밸런싱함
TCP/UDP 프로토콜의 헤더를 분석 -> 3-way handshaking과 4-way handshaking를 실시
IP, port, 세션 정보 필요
L4 스위치를 기준으로 내외부 망이 나뉨
- 내부 망의 서버가 각자 가지고 있던 공인 IP 사라지고 모든 요청을 L4스위치로 가져가기 때문에 얘만 공인 IP를 가지게 됨 -> NLB가 고정 IP 를 갖는 과정
- 외부에서 내부 서버로 직접 접속할 방도 X -> 장비 자체를 대상으로 공격이 수행되거나 중간 방화벽 리소스 소비하는 방식으로 서비스 중단 일으킴

UDP

OSI 7 계층 중 4층, 전송 계층
비연결형, 신뢰성 낮음
- tcp 보다 빠름
- 데이터 그램 방식으로 패킷 교환
- 전송 순서, 수신여부 확인 x
헤더에 checksum 필드로 최소한의 오류 검출
1:n 의 스트리밍 서비스에 사용

[OS] 개념: 프로세스, 스레드, 데드락

용감한 개복치 — Wed, 30 Oct 2024 01:03:19 +0900

참고자료

https://wikidocs.net/232213

07-5 교착상태의 탐지와 회복

[TOC] 교착상태 탐지와 회복은 교착상태를 관리하는 또 다른 중요한 접근 방식입니다. 이 방법은 교착상태를 미리 예방하거나 회피하는 대신, 교착상태가 발생하였을 때 이를 탐지…

wikidocs.net

프로세스

독립된 실행 단위 -> 최소 1개의 스레드 가짐
독립된 메모리 공간 -> 코드 데이터 스택 힙
자원 소유 및 관리 -> 서로 다른 프로세스의 자원에 접근 x, 하고싶으면 IPC 사용

멀티프로세스

장점

안정성 높음
프로세스 간 영향 없음

단점

자원 소모가 큼
컨텍스트 스위칭 비용 높음 -> 캐시 메모리 초기화 등 무거운 작업 발생

스레드

출처 : https://hongcoding.tistory.com/138#:~:text=%EC%8A%A4%EB%A0%88%EB%93%9C%EB%9E%80%2C%20%ED%94%84%EB%A1%9C%EC%84%B8%EC%8A%A4%20%EB%82%B4%EC%97%90%EC%84%9C,%EC%9D%B4%EC%9A%A9%ED%95%98%EB%8A%94%20%EC%8B%A4%ED%96%89%EC%9D%98%20%EB%8B%A8%EC%9C%84%20%EC%9D%B4%EB%8B%A4.&text=%EC%8A%A4%EB%A0%88%EB%93%9C%EB%8A%94%20%ED%94%84%EB%A1%9C%EC%84%B8%EC%8A%A4%EC%9D%98%20%EA%B3%B5%EC%9C%A0,%EC%84%9C%EB%A1%9C%20%EB%A9%94%EB%AA%A8%EB%A6%AC%EB%A5%BC%20%EA%B3%B5%EC%9C%A0%ED%95%9C%EB%8B%A4.

프로세스 내 실행 단위
프로세스가 할당받은 자원 공유
독립된 스택만 할당 -> 그림에서 처럼 스택만 각각 할당 받고 나머지는 공유중

멀티스레드

장점

자원 공유로 효율적 -> 프로세스 생성 X, 시스템 콜 감소
컨텍스트 스위칭 비용, 통신 속도 낮음

단점

동기화 이슈 -> 데드락
하나의 스레드 문제가 전체에 영향

데드락(Deadlock)

두 개 이상의 프로세스가 서로의 자원을 기다리며 무한 대기하는 상태

발생 조건

상호배제: 자원은 한 번에 하나의 프로세스만 사용 -> 하나의 프로세스가 자원을 독점 사용중
점유와 대기: 자원을 보유한 상태에서 다른 자원 대기
비선점: os는 자원을 강제로 빼앗을 수 없음
순환대기: 프로세스간 순환형태의 자원 대기

예방 방법

상호배제 -> 자원의 공유
점유와 대기 ->
- 프로세스 시작 시 필요한 자원을한 번에 할당 받기
- 자원이 필요한 경우 보유한 자원 모두 놓고 재요청
비선점: 자원을 강제로 빼앗을 수 없음 -> cpu, memory는 일시적으로 빼앗을 수 있음
순환대기: 프로세스간 순환형태의 자원 대기 -> 프로세스의 priority를 기준으로 낮은 쪽이 자원 우선 놓기

==> Starvation 발생 가능

대응 알고리즘

Deadlock Avoidance

데드락 발생할 것 같으면 아예 자원을 할당하지 않는 방식

프로세스들이 필요로 하는 각 자원별 최대 사용량을 미리 선언하는 것

자원 할당 그래프 알고리즘
- 각 자원 유형이 하나의 인스턴스만 가지고 있는 경우
- 프로세스가 자원을 요청하는 것은 점선, 프로세스에 자원 할당하는 것은 실선으로 나타낸 그래프에서 사이클이 존재하지 않을 때 자원 할당
- 출처 : https://rebro.kr/177
은행원 알고리즘
- 인스턴스가 여럿 존재할 때는 위의 방식 사용 x
- 요청 자원을 모두 할당받았을 땐 일정 시간안에 모두 반납한다는 전제하에 저용
- 요청 자원수가 남은 자원의 수보다 적은 프로세스만 선택하여 할당

Deadlock Detection & Recovery

자원 선점시에 어떤 프로세스를 종료할 지 정해서 데드락 발생 이전 상태로 롤백
프로세스 재시작
롤백 회수를 지정함으로써 계속해서 동일한 프로세스가 종료되어 starvation 발생하는 것을 막음

Deadlock Ignorance

데드락은 어차피 드물게 일어나니 대처하면서 더 큰 오버헤드가 발생하는 경우를 제거
unix, window 대부분이 채택

[Grafana]데이터 소스 연결

용감한 개복치 — Thu, 11 Jul 2024 18:24:19 +0900

상황

쿠버네티스 프로메테우스 서버가 환경별로 존재

그라파나 대시보드는 운영환경만 설정

내가 볼 개발환경 대시보드가 필요해짐

방법

보통 프로메테우스를 설치했다면 네임스페이스 모니터링에 모아두었으므로 확인

kubectl get svc -n monitoring

그라파나 > connection > data source > connection 에 프로메테우스 서버 파드 주소 입력

그라파나는 단순 대시보드

프로메테우스가 풀링 방식으로 이런저런 파드상황을 들고오는거고

그걸 그라파나가 받아서 시각화 하는 것

[Terraform] 테라폼 기초 설명 & init 코드 구성 요소

용감한 개복치 — Thu, 25 Apr 2024 06:19:26 +0900

Terraform 이란?

- 하시코프사에서 공개한 IaC 도구

- 블록에서 작성된 타겟 리소스에 대한 api 를 테라폼 프로바이더가 호출

- 실행(apply) 하면 생성되는 tfstate 파일을 기준으로 상태를 비교하여 선언된 형태에 맞춤

출처 : 스터디 자료

HCL 이란?

- HashiCorp configuration language

- 하시코프사에서 IaC와 구성 정보를 명시하기 위해 개발된 오픈 소스 도구

- 테라폼에서 HCL이 코드의 영역을 담당

- 인프라가 코드로 표현되고, 이 코드는 곧 인프라이기 때문에 선언적 특성을 갖게 되고 튜링 완전한 Turing-complete 언어적 특성을 가짐

- 일반적인 프로그래밍 언어의 조건문 처리 같은 동작 가능

- 자동화와 더불어, 쉽게 버저닝해 히스토리를 관리하고 함께 작업 할 수 있는 기반을 제공

- syntax docs

https://developer.hashicorp.com/terraform/language/syntax/configuration

Syntax - Configuration Language | Terraform | HashiCorp Developer

Key constructs of the native Terraform language syntax, including identifiers, arguments, blocks, and comments.

developer.hashicorp.com

IaC 란?

- 수동 프로세스가 아닌 코드를 통해 인프라를 관리하고 프로비저닝 하는 것

- 프로비저닝 도구로써는 hcl로 작성되는 테라폼 외의 yaml, json 으로 작성되는 cloudformation 도 있음

- iac 에 속하지만 구성관리 도구로 분류되는 것에는 레드햇에서 제공하는 절차지향적인 ansible이 대표적

출처 : https://medium.com/cloudnativeinfra/when-to-use-which-infrastructure-as-code-tool-665af289fbde

terraform init : init을 위해 필요한 provider.tf 예시와 블럭 설명

provider

출처 : https://malwareanalysis.tistory.com/619

리소스 유형을 구현하는 플러그인
사용자를 대신하여 일반적으로 퍼블릭 클라우드 공급자의 서비스를 인증하고 연결하는 데 필요한 모든 코드가 포함
사용 중인 클라우드 플랫폼 및 서비스에 대한 공급자를 찾아 구성에 추가한 다음 해당 리소스를 사용하여 인프라를 프로비저닝
aws, azure 등 퍼블릭 클라우드 서비스부터 SaaS 서비스 까지 다양하게 제공되고 있음
특수한 경우 리소스마다 다른 프로바이더 사용하도록 설정 가능
동일 프로바이더를 가지고 다른 조건을 사용할 수 있음

terraform

tfstate 파일을 저장 관리하는 곳을 정의
- cloud : terraform cloud를 사용하여 remote로 관리
- backend : local / s3 / consul 등을 사용 가능. default 는 local
해당 블럭이 있는 곳을 수정했다면 terraform init 을 다시 해 줘야 반영됨

version

시맨틱 버전 관리 방식 따름
~> : 지정된 버전에서 가장 자리수가 낮은 구성요소만 증가하는 것을 허용
>= : 지정된 버전 이상의 모든 버전 허용

provider "aws" {
  profile = "사용하는 aws profile"
  region  = "옵션"

  default_tags {
    tags = {
      "service"      = "example"
    }
  }
}

# alias 를 사용하여 단일 프로바이더의 다중 설정 가능
# resource block 에서 provider = aws.seoul 을 추가하는 방식으로 사용 가능
provider "aws" {
  alias = "seoul"
  region = "ap-northeast-2"
}

terraform {
  required_providers {
    aws = {
      # 4.39.0 버전을 포함해서 4.39.x 다른 것만 허용
      version = "~> 4.39.0"
    }
  }

  cloud {
    organization = "terraform cloud를 사용하는 경우 작성"
    workspaces {
      name = "terraform cloud 사용 시 작업하는 workspace를 명시"
    }
  }
  
  backend "local" { # state를 보관하는 위치를 지정
    path = "relative/path/to/terraform.tfstate"
  }
}

다른 프로바이더 사용해보기

- 아래 공식 문서 링크에 따라가면 나오는 예제를 그대로 복붙하면 됨

https://registry.terraform.io/providers/hashicorp/aws/latest

Terraform Registry

registry.terraform.io

https://registry.terraform.io/providers/hashicorp/http/latest/docs/data-sources/http

Terraform Registry

registry.terraform.io

Terraform Registry

registry.terraform.io

terraform {
  required_providers {
    architech-http = {
      source = "architect-team/http"
      version = "~> 3.0"
    }
    http = {
      source = "hashicorp/http"
    }
    aws-http = {
      source = "terraform-aws-modules/http"
    }
  }
}

data "http" "example" {
  provider = aws-http
  url = "https://checkpoint-api.hashicorp.com/v1/check/terraform"

  request_headers = {
    Accept = "application/json"
  }
}

[Terraform] EKS IaC

용감한 개복치 — Wed, 24 Apr 2024 23:10:44 +0900

Amazon EKS Workshop Study 2기

8주차

EKS IaC ( Terraform )

eks 환경을 테라폼으로 구성해보기

실습환경 구성

윈도우에서 구성하려면 mac 환경에서보다 이것저것 해 줘야할 게 많다. ~~brew 짱짱맨..~~

wsl2 설치 > 실행 > 테라폼 설치

wget -O- https://apt.releases.hashicorp.com/gpg | sudo gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/hashicorp.list
sudo apt update && sudo apt install terraform

# 테라폼 버전 정보 확인
terraform version

https://www.how2shout.com/linux/how-to-install-eksctl-cli-tool-on-ubuntu-linux/

How to Install eksctl CLI tool on Ubuntu Linux

Using eksctl, users can easily deploy and scale containerized applications on AWS. Here we learn how to install eksctl on an Ubuntu system.

www.how2shout.com

시스템 업데이트

sudo apt update

AWSCLIL 설치

sudo apt install awscli

#자격증명
aws configure

EKSCTL 설치(amd64기)

curl --silent --location "https://github.com/weaveworks/eksctl/releases/latest/download/eksctl_$(uname -s)_amd64.tar.gz" | tar xz -C /tmp

바이너리 파일 위치 이동

sudo mv /tmp/eksctl /usr/local/bin

설치 확인

eksctl version
eksctl --help

KUBECTL 설치

curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/1.29.3/2024-04-19/bin/linux/amd64/kubectl
chmod +x ./kubectl
mkdir -p $HOME/bin && cp ./kubectl $HOME/bin/kubectl && export PATH=$HOME/bin:$PATH

#확인
kubectl version --client

HELM 설치

기존의 바이너리 파일 설치부터하는 방법도 있는데, 공식 인스톨러 스크립트가 있다니 그것을 사용

https://helm.sh/docs/intro/install/

Installing Helm

Learn how to install and get running with Helm.

helm.sh

curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3
chmod 700 get_helm.sh
./get_helm.sh

+) third party 를 사용한 방법(apt)

curl https://baltocdn.com/helm/signing.asc | gpg --dearmor | sudo tee /usr/share/keyrings/helm.gpg > /dev/null
sudo apt-get install apt-transport-https --yes
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/helm.gpg] https://baltocdn.com/helm/stable/debian/ all main" | sudo tee /etc/apt/sources.list.d/helm-stable-debian.list
sudo apt-get update
sudo apt-get install helm

테라폼 실습을 위한 디렉토리

mkdir learn-terraform
cd learn-terraform
touch main.tf

Amazon Linux 2 최신 ami id 찾기

#aws ec2 describe-images --owners self amazon
aws ec2 describe-images --owners amazon --filters "Name=name,Values=amzn2-ami-hvm-2.0.*-x86_64-gp2" "Name=state,Values=available" --query 'Images|sort_by(@, &CreationDate)[-1].[ImageId, Name]' --output text
ami-0217b147346e48e84   amzn2-ami-hvm-2.0.20240412.0-x86_64-gp2

aws ec2 describe-images --owners amazon --filters "Name=name,Values=amzn2-ami-hvm-2.0.*-x86_64-gp2" "Name=state,Values=available" --query 'Images|sort_by(@, &CreationDate)[-1].[ImageId]' --output text
ami-0217b147346e48e84

AL2ID=`aws ec2 describe-images --owners amazon --filters "Name=name,Values=amzn2-ami-hvm-2.0.*-x86_64-gp2" "Name=state,Values=available" --query 'Images|sort_by(@, &CreationDate)[-1].[ImageId]' --output text`
echo $AL2ID

ec2 생성 모니터링

# [터미널1] EC2 생성 모니터링
export AWS_PAGER=""
while true; do aws ec2 describe-instances --query "Reservations[*].Instances[*].{PublicIPAdd:PublicIpAddress,InstanceName:Tags[?Key=='Name']|[0].Value,Status:State.Name}" --filters Name=instance-state-name,Values=running --output text ; echo "------------------------------" ; sleep 1; done

Terraform 기본 사용법 -> 별도 포스팅

https://bravesunfish.tistory.com/80

[Terraform] 테라폼 기초 설명 & init 코드 구성 요소

Terraform 이란?- 하시코프사에서 공개한 IaC 도구- 블록에서 작성된 타겟 리소스에 대한 api 를 테라폼 프로바이더가 호출- 실행(apply) 하면 생성되는 tfstate 파일을 기준으로 상태를 비교하여 선언된

bravesunfish.tistory.com

Terraform 으로 EKS 배포

테라폼 배포 실행

> 테라폼은 디렉토리 기준으로 파일을 읽기 때문에 실행하고자하는 tf 가 있는 곳에서 실행

# 초기화
terraform init
ls -al
tree .terraform

# plan 확인
terraform plan

# apply 실행
terraform apply
 Enter a value: yes 입력

# ec2 생성 확인 : aws 웹 관리 콘솔에서도 확인 - 서울 리전 선택
export AWS_PAGER=""
aws ec2 describe-instances --output table

# 테라폼 정보 확인
terraform state list
terraform show
terraform show aws_instance.example

코드 파일 수정 > 반영 확인 : 태그 수정

plan 으로 변경 예정 값 확인 & apply 로 적용

첫 번째 EKS 클러스터 배포

# 코드 가져오기
git clone https://github.com/gasida/aews-cicd.git
cd aews-cicd/4

# terraform 환경 변수 저장
export TF_VAR_KeyName='peach'
echo $TF_VAR_KeyName

# 
terraform init
terraform plan

# 10분 후 배포 완료
terraform apply -auto-approve

만들어 져야할 것 : VPC, Subnet, IGW, NATGW, Routing Table, EKS, EKS SG

state 파일 생성 완

확인

#
kubectl get node -v=6

# EKS 클러스터 인증 정보 업데이트
CLUSTER_NAME=myeks
aws eks update-kubeconfig --region ap-northeast-2 --name $CLUSTER_NAME
kubectl config rename-context "arn:aws:eks:ap-northeast-2:$(aws sts get-caller-identity --query 'Account' --output text):cluster/$CLUSTER_NAME" "Aews-Labs"

#
kubectl cluster-info
kubectl get node --label-columns=node.kubernetes.io/instance-type,eks.amazonaws.com/capacityType,topology.kubernetes.io/zone
kubectl get pod -A

두 번째 배포 > 코드 재사용 검증

첫 번째 코드를 그대로 복사해서 myeks2 로 변수만 바꿔서 새로 apply 했으니 그대로 생성되는가 확인

#
cd ..
mkdir 5
cd 5
cp ../4/*.tf .
ls

#
terraform init
terraform apply -auto-approve -var=ClusterBaseName=myeks2 -var=KubernetesVersion="1.28"

# EKS 클러스터 인증 정보 가져오기
CLUSTER_NAME2=myeks2
aws eks update-kubeconfig --region ap-northeast-2 --name $CLUSTER_NAME2 --kubeconfig ./myeks2config

# EKS 클러스터 정보 확인
kubectl --kubeconfig ./myeks2config get node 
kubectl --kubeconfig ./myeks2config get pod -A

[ArgoCD] ArgoCD 설치 및 실습

용감한 개복치 — Sat, 20 Apr 2024 20:35:31 +0900

Argo

개념

ArgoCD란?

- gitops를 구현하기 위해 쿠버네티스 어플리케이션 자동배포를 위한 오픈소스

- ci/cd 중 cd 를 담당

- 선언적 어플리케이션 관리를 사용 : 명시적으로 원하는 상태를 선언, argoCD가 클러스터 상태와 비교하여 선언된 상태로 유지

- 활용 ci/cd 아키텍처

출처 : 스터디 자료

api 서버 : Web UI, CLI 및 CI/CD 시스템에서 사용되는 API를 노출하는 gRPC/REST 서버
- 애플리케이션 관리 및 상태 보고
- 애플리케이션 작업 호출 (예: 동기화, 롤백, 사용자 정의 작업)
- 리포지토리 및 클러스터 자격 증명 관리 (K8s 시크릿으로 저장)
- 외부 식별 공급자로의 인증 및 인증 위임
- RBAC 시행
- Git 웹훅 이벤트를 수신 및 전달하는 리스너/포워더
Repository Server : Git 연결 및 배포할 yaml 생성
- 애플리케이션 매니페스트를 보관하는 Git 저장소의 로컬 캐시를 유지하는 내부 서비스
- 다음 입력이 제공될 때 Kubernetes 매니페스트를 생성하고 반환
Application Controller : k8s 리소스 모니터링, Git과 비교
- 지속적으로 실행 중인 애플리케이션을 모니터링하고 현재 라이브 상태를 저장소에 지정된 목표 상태와 비교하는 Kubernetes 컨트롤러
- OutOfSync 애플리케이션 상태를 감지하고 선택적으로 보정 조치
- 라이프사이클 이벤트 (PreSync, Sync, PostSync)에 대한 사용자 정의 후크를 호출

- 동작방식

Git에 push, k8s 배포 방식인 helm / kustomize 사용
argoCD 가 git 저장소의 상태 변경 감지
변경 내용을 k8s에 배포, 반영

실습 : gui

helm을 이용한 설치

# helm 설치
cat <<EOT > argocd-values.yaml
global:
  domain: argocd.$MyDomain

configs:
  params:
    server.insecure: true

controller:
  metrics:
    enabled: true
    serviceMonitor:
      enabled: true

server:
  ingress:
    enabled: true
    controller: aws
    ingressClassName: alb
    hostname: "argocd.$MyDomain"
    annotations:
      alb.ingress.kubernetes.io/scheme: internet-facing
      alb.ingress.kubernetes.io/target-type: ip
      alb.ingress.kubernetes.io/backend-protocol: HTTP
      alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":80}, {"HTTPS":443}]'
      alb.ingress.kubernetes.io/certificate-arn: $CERT_ARN
      alb.ingress.kubernetes.io/ssl-redirect: '443'
    aws:
      serviceType: ClusterIP
      backendProtocolVersion: GRPC
  metrics:
    enabled: true
    serviceMonitor:
      enabled: true

repoServer:
  metrics:
    enabled: true
    serviceMonitor:
      enabled: true

applicationSet:
  metrics:
    enabled: true
    serviceMonitor:
      enabled: true

notifications:
  metrics:
    enabled: true
    serviceMonitor:
      enabled: true
EOT

kubectl create ns argocd
helm repo add argo https://argoproj.github.io/argo-helm
helm install argocd argo/argo-cd --version 6.7.11 -f argocd-values.yaml --namespace argocd

# 확인
kubectl get ingress,pod,svc -n argocd
kubectl get crd | grep argo

# 최초 접속 암호 확인
kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d ;echo
#Zhl8OmU3sRGl9eEk

최초 접속

https://argocd.peachengineer.click/

Argo CD

argocd.peachengineer.click

admin / 위에 나온 비밀번호는 user info > UPDATE PASSWORD 변경

위 화면에서 + 로 app create

sync > synchronize 로 배포

모니터링 : 새로운 파드 생성 확인

watch -d kubectl get deploy -n first --show-labels

gui 에서 확인

리소스 클릭 후 확인 : 각각 LIVE MANIFEST(쿠버네티스 정보)

라벨에 추가됨

k8s에서 직접 수정 → argocd 싱크(반영) 확인

# 아래 추가
kubectl edit deploy -n first myweb
...
  labels:
    add: label-test
    add2: k8s-test
...

but, diff 에서는 확인 x

Git 레포에서 값 변경 > commit > diff 확인

현재 상태는, Git을 기준으로 보자면 LIVE MANIFEST(K8S)형상이 뒤떨어진것으로 볼 수 있다 → OutOfSync 상태니 Sync

실습 : cli

Argo CD cli 설치

#
curl -sSL -o argocd-linux-amd64 https://github.com/argoproj/argo-cd/releases/latest/download/argocd-linux-amd64
sudo install -m 555 argocd-linux-amd64 /usr/local/bin/argocd
rm -f argocd-linux-amd64

#
argocd version

#
argocd login argocd.$MyDomain
Username: admin
Password: ###
'admin:login' logged in successfully

#
kubectl config get-contexts -o name
argocd cluster add peach@myeks.ap-northeast-2.eksctl.io
y 입력

#
argocd app list

Application 생성 with CLi

#
kubectl config set-context --current --namespace=argocd
argocd app create guestbook --repo https://github.com/argoproj/argocd-example-apps.git --path guestbook --dest-server https://kubernetes.default.svc --dest-namespace default

#
argocd app list

sync 어플리케이션

#
argocd app get guestbook

# 모니터링
watch -d kubectl get pod,svc,ep

#
argocd app sync guestbook

삭제

argocd app delete guestbook
Are you sure you want to delete 'guestbook' and all its resources? [y/n] y

# ns default 로 변경
kubectl ns default

개념

Argo Rollouts 란?

- Kubernetes 위에 구축된 애플리케이션 배포를 관리하는 오픈 소스 롤링 업데이트 및 릴리스 관리 도구

- 기능

롤링 업데이트 및 롤백 관리: Argo Rollouts는 애플리케이션의 새로운 버전을 롤아웃하고 이전 버전으로 롤백하는 것과 같은 롤링 업데이트 및 롤백을 관리합니다. 이를 통해 애플리케이션의 신뢰성과 안정성을 유지하면서 업데이트를 수행할 수 있습니다.
블루-그린 배포: 블루-그린 배포는 새로운 버전의 애플리케이션을 기존 버전과 완전히 분리된 환경에서 테스트할 수 있는 기능을 제공합니다. Argo Rollouts는 블루-그린 배포를 지원하여 안정성을 향상시키고 사용자들에게 무중단 서비스를 제공합니다.
카나리아 배포: 카나리아 배포는 새로운 버전의 애플리케이션을 일부 사용자 또는 특정 환경에 먼저 릴리스하여 문제를 사전에 발견하고 안정성을 확보하는 방법입니다. Argo Rollouts는 카나리아 배포를 쉽게 설정하고 관리할 수 있습니다.
프로모션 전략: Argo Rollouts는 배포 전략을 정의하여 특정 조건에 따라 배포를 자동으로 진행하거나 일시 중단하는 등의 작업을 수행할 수 있습니다. 이를 통해 유연한 배포 전략을 구성할 수 있습니다.
프로모션 상태 모니터링: 롤링 업데이트 또는 롤백 중에도 Argo Rollouts는 애플리케이션의 상태를 모니터링하고 프로모션의 진행 상황을 실시간으로 추적할 수 있습니다. 이를 통해 배포 프로세스의 투명성을 확보할 수 있습니다.

- 동작방식

- 배포 전략

Blue-Green
Canary
- 출처 : 스터디 자료

- 특징

세밀한 가중치 기반 트래픽 이동
자동 롤백 및 프로모션
수동 판단
사용자 정의 메트릭 쿼리 및 비즈니스 KPI 분석
인그레스 컨트롤러 통합: NGINX, ALB, Apache APISIX
서비스 메시 통합: Istio, Linkerd, SMI
여러 공급자 동시 사용: SMI + NGINX, Istio + ALB 등
메트릭 제공자 통합: Prometheus, Wavefront, Kayenta, Web, Kubernetes Jobs, Datadog, New Relic, Graphite, InfluxDB

실습

설치

#
cat <<EOT > argorollouts-values.yaml
dashboard:
  enabled: true
  ingress:
    enabled: true
    ingressClassName: alb
    hosts:
      - argorollouts.$MyDomain
    annotations:
      alb.ingress.kubernetes.io/scheme: internet-facing
      alb.ingress.kubernetes.io/target-type: ip
      alb.ingress.kubernetes.io/backend-protocol: HTTP
      alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":80}, {"HTTPS":443}]'
      alb.ingress.kubernetes.io/certificate-arn: $CERT_ARN
      alb.ingress.kubernetes.io/ssl-redirect: '443'
EOT

kubectl create ns argo-rollouts
helm install argo-rollouts argo/argo-rollouts --version 2.35.1 -f argorollouts-values.yaml --namespace argo-rollouts

# 확인
kubectl get all -n argo-rollouts
kubectl get crd | grep argo

rollout cli 설치

#
curl -LO https://github.com/argoproj/argo-rollouts/releases/download/v1.6.4/kubectl-argo-rollouts-linux-amd64
chmod +x ./kubectl-argo-rollouts-linux-amd64
mv ./kubectl-argo-rollouts-linux-amd64 /usr/local/bin/kubectl-argo-rollouts

# 설치 확인
kubectl argo rollouts version

deploy rollout : canary

spec:
  replicas: 5
  strategy:
    canary:
      steps:
      - setWeight: 20
      - pause: {}
      - setWeight: 40
      - pause: {duration: 10}
      - setWeight: 60
      - pause: {duration: 10}
      - setWeight: 80
      - pause: {duration: 10}

신규 20% > pause > 신규 40% > pause 10s > 신규 60% > pause 10 > 신규 80% > pause 10s

# Run the following command to deploy the initial Rollout and Service:
kubectl apply -f https://raw.githubusercontent.com/argoproj/argo-rollouts/master/docs/getting-started/basic/rollout.yaml
kubectl apply -f https://raw.githubusercontent.com/argoproj/argo-rollouts/master/docs/getting-started/basic/service.yaml

확인

kubectl argo rollouts get rollout rollouts-demo
kubectl argo rollouts get rollout rollouts-demo --watch

새 이미지로 디플로이 한 번 더해보기

# Run the following command to update the rollouts-demo Rollout with the "yellow" version of the container:
kubectl argo rollouts set image rollouts-demo rollouts-demo=argoproj/rollouts-demo:yellow

promoting a rollout

# 아래 입력 혹은 UI에서 Promote Yes 클릭
kubectl argo rollouts promote rollouts-demo

#
kubectl argo rollouts get rollout rollouts-demo --watch

Aborting a Rollout

# 
kubectl argo rollouts set image rollouts-demo rollouts-demo=argoproj/rollouts-demo:red

#
kubectl argo rollouts abort rollouts-demo

#
kubectl argo rollouts set image rollouts-demo rollouts-demo=argoproj/rollouts-demo:yellow

[Jenkins]Jenkins 설치 및 실습

용감한 개복치 — Fri, 19 Apr 2024 03:44:04 +0900

Jenkins

개념

- 지속적 통합 & 배포를 위한 워크플로우 제어에 사용되는 툴

- 자바 기반의 오픈소스 -> 자바와 친화성이 높음

- 아파치 톰캣처럼 서블릿 컨테이너 내부에서 실행되는 서버 시스템

- 파이프라인이라고 부르는 스크립트 작성 -> 각 빌드 단계마다 세부적으로 젠킨스의 태스크 정의 가능

- 다양한 플러그인 연동 제공

Build Plugins : Maven, Ant, Gradle …
VCS Plugins : Git, SVN …
Languages Plugins : Java, Python, Node.js …

- github action 과 함께 CI/CD 툴로 많이 거론 됨

- 간단한 비교 요약

출처 : https://wookiist.dev/155

- 워크플로우 예시

최신 코드 가져오기 : 개발을 위해 중앙 코드 리포지터리에서 로컬 시스템으로 애플리케이션의 최신 코드를 가져옴
단위 테스트 구현과 실행 : 코드 작성 전 단위 테스트 케이스를 먼저 작성
코드 개발 : 실패한 테스트 케이스를 성공으로 바꾸면서 코드 개발
단위 테스트 케이스 재실행 : 단위 테스트 케이스 실행 시 통과(성공!)
코드 푸시와 병합 : 개발 소스 코드를 중앙 리포지터리로 푸시하고, 코드 병합
코드 병합 후 컴파일 : 변경 함수 코드가 병함되면 전체 애플리케이션이 컴파일된다
병합된 코드에서 테스트 실행 : 개별 테스트뿐만 아니라 전체 통합 테스트를 실행하여 문제 없는지 확인
아티팩트 배포 : 애플리케이션을 빌드하고, 애플리케이션 서버의 프로덕션 환경에 배포
배포 애플리케이션의 E-E 테스트 실행 : 셀레늄 Selenium과 같은 User Interface 자동화 도구를 통해 애플리케이션의 전체 워크플로가 정상 동작하는지 확인하는 종단간 End-to-End 테스트를 실행.

실습

설치 및 설정

자바 설치 및 환경 변수 설정

# 실습 편리를 위해서 root 계정 전환
sudo su -

# Add required dependencies for the jenkins package
# https://docs.aws.amazon.com/corretto/latest/corretto-17-ug/amazon-linux-install.html
sudo yum install fontconfig java-17-amazon-corretto -y
java -version
alternatives --display java
JAVA_HOME=/usr/lib/jvm/java-17-amazon-corretto.x86_64
echo $JAVA_HOME

젠킨스 설치

# 젠킨스 설치
sudo wget -O /etc/yum.repos.d/jenkins.repo https://pkg.jenkins.io/redhat-stable/jenkins.repo
sudo rpm --import https://pkg.jenkins.io/redhat-stable/jenkins.io-2023.key
sudo yum upgrade
sudo yum install jenkins -y
sudo systemctl daemon-reload
sudo systemctl enable jenkins && sudo systemctl start jenkins   # 다소 시간 걸림
sudo systemctl status jenkins

# 초기 암호 확인
sudo systemctl status jenkins
cat /var/lib/jenkins/secrets/initialAdminPassword

# 접속 주소 확인 
curl -s ipinfo.io/ip | awk '{ print "Jenkins = http://"$1":8080" }'

설치 완료 되면 초창기 로그인 화면이 뜸

아까 cat 이하로 확인했던 암호로 입장

install

유저설정

주소 같은지 확인

대시보드 설명

구성에 대해 간략히 설명

item

- 작업 최소단위, job

- 종류

프로젝트 : 가장 기본적인 job 세팅
파이프라인 : 스크립트로 미리 정의된 템플릿 프로세스들로 job 실행

사람

- 계정 관련한 설정

젠킨스 관리

- 전역적인 설정

- tool 등을 설정 할 수 있음

실습

tool 설정 : 자바 JDK 를 사용하도록 path 지정 > save

item 생성 > 프로젝트

빌드 설정

빌드

확인

빌드에 변경 사항 추가하기 > 지금 빌드

변경 된 부분 확인

젠킨스 설치된 ec2 에서 프로젝트 위치 확인

#
find / -name First-Project

# 프로젝트(job, item) 별 작업 공간 확인
tree /var/lib/jenkins/workspace/First-Project

Jenkins with Docker

젠킨스에서 도커를 사용하는 방법

사전 준비

젠킨스 유저로 도커 사용하도록 설정 > 젠킨스 유저 전

# jenkins 유저로 docker 사용 가능하게 설정
grep -i jenkins /etc/passwd
usermod -s /bin/bash jenkins
grep -i jenkins /etc/passwd

# jenkins 유저 전환
su - jenkins
whoami
pwd
docker info
exit

su - jenkins 로 jenkins 사용자 로그인 후 기본적인 명렁어 확인했으나 docker 정보의 경우 권한 에러 발생

-> 권한 줘야함(666은 모든 사용자에게 읽기쓰기 오픈함 주의)

chmod 666 /var/run/docker.sock
usermod -aG docker jenkins

# Jeknins 유저로 확인
su - jenkins
docker info

# Dockerhub로 로그인 하기
docker login
Username: <자신의 계정명>
Password: <자신의 암호>

# myweb:v2.0.0 컨테이너 이미지 생성을 위한 Dockerfile 준비
# 실습을 위한 디렉터리 생성 및 이동
mkdir -p ~/myweb2 && cd ~/myweb2

# Dockerfile 파일 생성
vi Dockerfile
FROM ubuntu:20.04
ENV TZ=Asia/Seoul VERSION=2.0.0 NICK=peachdo
RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone && \
    sed -i 's/archive.ubuntu.com/mirror.kakao.com/g' /etc/apt/sources.list && \
    sed -i 's/security.ubuntu.com/mirror.kakao.com/g' /etc/apt/sources.list && \
    apt-get update && apt-get install -y apache2 figlet && \
    echo "$NICK Web Server $VERSION<br>" > /var/www/html/index.html && \
    echo "<pre>" >> /var/www/html/index.html && \
    figlet AEWS Study >> /var/www/html/index.html && \
    echo "</pre>" >> /var/www/html/index.html
EXPOSE 80
CMD ["usr/sbin/apache2ctl", "-DFOREGROUND"]

# 모니터링
watch -d 'docker images; echo; docker ps'

-----------
# (참고) 이미지 빌드
docker build -t myweb:v2.0.0 -f /var/lib/jenkins/myweb2/Dockerfile

# (참고) 컨테이너 실행
docker run -d -p 80:80 --rm --name myweb myweb:v2.0.0

젠킨스에서 Docker-Project 생성 & 빌드 스텝 설정

# build step
cd /var/lib/jenkins/myweb2
docker build -t myweb:v2.0.0 .

# add build step
docker run -d -p 80:80 --rm --name myweb myweb:v2.0.0

빌드 > 콘솔 출력

터미널에서 도커 이미지 빌드 할 때 봤던 로그들 확인

터미널에서 docker images 확인 & 이미지가 실행되는지 확인

Github 저장소 연결

실습용 레포지토리 포크

https://github.com/gasida/aews-cicd

GitHub - gasida/aews-cicd: cloudneta aws workshop study

cloudneta aws workshop study. Contribute to gasida/aews-cicd development by creating an account on GitHub.

github.com

프로젝트 생성

파라미터 string 추가 > VERSION & NICK

소스코드 관리(Source Code Management) 설정

additional behaviours 에서 sparse checkout path 를 1로 설정

build trigger 에서 poll scm 에 schedule '*****' 추가

+) poll scm

- 웹훅을 사용하지 않아도 빌드를 유발 시키기 위한 옵션

- 형상관리 서버를 주기적으로 감시하여 변경된 사항이 존재할때 빌드를 수행하는 설정

build step 설정

cd /var/lib/jenkins/myweb2
rm -rf Dockerfile
wget https://raw.githubusercontent.com/$NICK/aews-cicd/main/1/Dockerfile

docker build -t myweb:$VERSION .
docker run -d -p 80:80 --rm --name myweb myweb:$VERSION

Github 레포에서 1/Dockerfile 수정 후 커밋 > 트리거 발동

젠킨스에서 확인

노란 부분에서 어떤 커밋을 반영해서 돌아갔는지 보임

실패한 부분

Dockerfile 경로를 못찾음 -> 동일하게 Execute shell 수정

파이프라인

이론

위에 실습이 프로젝트에 관한 것이었다면, 지금 항목은 파이프라인에 관한 것

출처 : 스터디 자료

- 파이프라인 장점

코드 : 애플리케이션 CI/CD 프로세스를 코드 형식으로 작성할 수 있고, 해당 코드를 중앙 리포지터리에 저장하여 팀원과 공유 및 작업 가능
내구성 : 젠킨스 서비스가 의도적으로 또는 우발적으로 재시작되더라도 문제없이 유지됨
일시 중지 가능 : 파이프라인을 실행하는 도중 사람의 승인이나 입력을 기다리기 위해 중단하거나 기다리는 것이 가능
다양성 : 분기나 반복, 병렬 처리와 같은 다양한 CI/CD 요구 사항을 지원

- 파이프라인 용어

파이프라인 : 전체 빌드 프로세스를 정의하는 코드.
node : 파이프라인을 실행하는 시스템.
stage : 특정 단계에서 수행되는 작업들의 정의.
step : 파이프라인의 특정 단계에서 수행되는 단일 작업을 의미

- 파이프라인 3가지 구성 형태

Pipeline script : 일반적인 방식으로 Jenkins 파이프라인을 생성하여 Shell Script를 직접 생성하여 빌드하는 방식
Pipeline script from SCM : 사전 작성한 JenkinsFile을 형상관리 저장소에 보관하고, 빌드 시작 시 파이프라인 프로젝트에서 호출 실행하는 방식
Blue Ocean : 젠킨스 ui 로 관리하면 자동으로 jenkinsfile이 생성, 실행

- 구문 형태

선언형 : 쉽게 작성 가능, 최근 문법이고 젠킨스에서 권장하는 방법, step 필수!

예제)

pipeline {
    agent any     # Execute this Pipeline or any of its stages, on any available agent.
    stages {
        stage('Build') {   # Defines the "Build" stage.
            steps {
                //         # Perform some steps related to the "Build" stage.
            }
        }
        stage('Test') { 
            steps {
                // 
            }
        }
        stage('Deploy') { 
            steps {
                // 
            }
        }
    }
}

스크립트형 : 커스텀 작업에 용이, 복잡하여 난이도가 높음, step은 필수 아님

예제 )

node {          # 	Execute this Pipeline or any of its stages, on any available agent.
    stage('Build') {    # Defines the "Build" stage. stage blocks are optional in Scripted Pipeline syntax. However, implementing stage blocks in a Scripted Pipeline provides clearer visualization of each stage's subset of tasks/steps in the Jenkins UI.
        //              # Perform some steps related to the "Build" stage.
    }
    stage('Test') { 
        // 
    }
    stage('Deploy') { 
        // 
    }
}

실습 : 파이프라인 w. script

파이프라인 아이템 생성

스크립트로 정의

pipeline {
    agent any

    stages {
        stage('정보 확인') {
            steps {
                echo 'Hello World'
                sh 'java -version'
            }
        }
        stage('가라 배포') {
            steps {
                echo "Deployed successfully!";
            }
        }
    }
}

스크립트 자리에 내용 바꿔보기 > echo 동작 확인

pipeline {
    agent any
    environment { 
        STUDYNAME = 'AEWS'
    }
    stages {
        stage('연습') {
            environment { 
                mykey = 'abcd'
            }
            steps {
                echo "${STUDYNAME}";
                sh 'echo ${mykey}'
            }
        }
    }
}

maven 수정 테스트

pipeline {
    agent any
    tools {
        maven 'maven_3.8.7' 
    }
    stages {
        stage('Example') {
            steps {
                sh 'mvn --version'
            }
        }
    }
}

ui 상에선 아래 부분 수정하는 것

step 항목에 넣을 수 있도록 도와주는 문법 변환기

실습 : 파이프라인 SCM

파이프라인 아이템 생성

scm 으로 설정

실습 : secret text

관리 → Credentials → + Add Credentials → Secret text : Usename(root), Password(qwe123), ID(vmsshpw)

실습 : secret files

kube config 파일을 자신의 PC에 복사 → Jenkins Web에 Secret files 등록

scp root@<작업용EC2_공인IP>:/root/.kube/config .

# 아래 확인을 위해 모니터링
watch -d kubectl get pod

pipeline {
    agent any
    environment {
        MY_KUBECONFIG = credentials('k8sconfig')
    }

    stages {
        stage('remote k8s api') {
            steps {
                sh("kubectl --kubeconfig $MY_KUBECONFIG get pods -A")
                sh("kubectl --kubeconfig $MY_KUBECONFIG run nginx --image nginx --port=80")
            }
        }
    }
}

Jenkins → Credentials → Add → Secret file : File(업로드), ID(k8sconfig)

Jenkins with k8s

사전 준비 : 젠킨스에서 k8s 를 사용 할 수 있도록 설정

# jenkins 사용자에서 아래 작업 진행
whoami
mkdir ~/.kube

# root 계정에서 아래 복사 실행
cp ~/.kube/config /var/lib/jenkins/.kube/config
chown jenkins:jenkins /var/lib/jenkins/.kube/config

# jenkins 사용자에서 aws eks 사용(sts 호출 등)을 위한 자격증명 설정
aws configure
AWS Access Key ID [None]: ###
AWS Secret Access Key [None]: ###
Default region name [None]: ap-northeast-2

# jenkins 사용자에서 kubectl 명령어 사용 확인
kubectl get pods -A

파이프라인으로 디플로이먼트/서비스 배포

yaml 파일 수정 : 도커 이미지 수정 작업

k8s-1 아이템 생성

파이프라인 스크립트

pipeline {
    agent any

    tools {
        jdk 'jdk-17'
    }

    environment {
        DOCKERHUB_USERNAME = 'gasida'
        GITHUB_URL = 'https://github.com/<본인 깃헙id>/aews-cicd.git'
        // deployment-svc.yaml -> image: <도커 허브id>/myweb:v1.0.0        
        DIR_NUM = '3'
    }

    stages {
        stage('Container Build') {
            steps {	
                // 릴리즈파일 체크아웃
                checkout scmGit(branches: [[name: '*/main']], 
                    extensions: [[$class: 'SparseCheckoutPaths', 
                    sparseCheckoutPaths: [[path: "/${DIR_NUM}"]]]], 
                    userRemoteConfigs: [[url: "${GITHUB_URL}"]])

                // 컨테이너 빌드 및 업로드
                sh "docker build -t ${DOCKERHUB_USERNAME}/myweb:v1.0.0 ./${DIR_NUM}"
                sh "docker push ${DOCKERHUB_USERNAME}/myweb:v1.0.0"
            }
        }

        stage('K8S Deploy') {
            steps {
                sh "kubectl apply -f ./${DIR_NUM}/deploy/deployment-svc.yaml"
            }
        }
    }
}

확인

접속 테스트를 위한 파드 생성

# 배포
cat <<EOF | kubectl create -f -
apiVersion: v1
kind: Pod
metadata:
  name: netpod
  labels:
    app: pod
spec:
  containers:
  - name: netshoot-pod
    image: nicolaka/netshoot
    command: ["tail"]
    args: ["-f", "/dev/null"]
  terminationGracePeriodSeconds: 0
EOF

배포 및 확인

#
kubectl exec -it netpod -- curl myweb:8080
kubectl exec -it netpod -- curl myweb:8080 | grep Web
while true; do kubectl exec -it netpod -- curl myweb:8080 | grep Web; echo; done

# 작업공간 확인
tree /var/lib/jenkins/workspace/k8s-1
cat /var/lib/jenkins/workspace/k8s-1/Dockerfile

참고 자료

https://wookiist.dev/155

[DevOps/번역글] Github Actions냐 Jenkins냐! 올바른 선택을 해봅시다

시작하기에 앞서, 본 포스트는 "Github Actions or Jenkins? Making the Right Choice for You" 를 읽고 한국어로 정리하기 위해 쓴 번역 글입니다. 오역이 있거나 미숙한 번역이 있을 수 있습니다. 많은 지적질 부

wookiist.dev

https://velog.io/@mirrorkyh/11%EC%9B%94-4%EC%A3%BC%EC%B0%A8-jenkins-Poll-scm-%EA%B8%B0%EB%8A%A5-%EC%84%A4%EC%A0%95

[11월 4주차] jenkins Poll scm 기능 설정

• 사용 이유• 유사기능 Build periodically• 크론 작업 형식• Poll SCM사용 이유빌드 트리거를 주로 웹훅을 사용하지만특정 상황에는 웹훅을 사용하지 못하는 경우가 발생할 수 있기 때문에웹훅을

velog.io

[EKS] CI/CD

용감한 개복치 — Fri, 19 Apr 2024 03:36:06 +0900

Amazon EKS Workshop Study 2기

7주차

CI/CD

eks 환경에서 젠킨스와 argoCD 를 활용한 CI/CD 파이프라인 구축

실습환경 구성

curl -O https://s3.ap-northeast-2.amazonaws.com/cloudformation.cloudneta.net/K8S/eks-oneclick6.yaml

# default 네임스페이스 적용
kubectl ns default

# 노드 정보 확인 : t3.medium
kubectl get node --label-columns=node.kubernetes.io/instance-type,eks.amazonaws.com/capacityType,topology.kubernetes.io/zone

# ExternalDNS
MyDomain=<자신의 도메인>
echo "export MyDomain=<자신의 도메인>" >> /etc/profile

MyDomain=peachengineer.click
echo "export MyDomain=peachengineer.click" >> /etc/profile
MyDnzHostedZoneId=$(aws route53 list-hosted-zones-by-name --dns-name "${MyDomain}." --query "HostedZones[0].Id" --output text)
echo $MyDomain, $MyDnzHostedZoneId
curl -s -O https://raw.githubusercontent.com/gasida/PKOS/main/aews/externaldns.yaml
MyDomain=$MyDomain MyDnzHostedZoneId=$MyDnzHostedZoneId envsubst < externaldns.yaml | kubectl apply -f -

# kube-ops-view
helm repo add geek-cookbook https://geek-cookbook.github.io/charts/
helm install kube-ops-view geek-cookbook/kube-ops-view --version 1.2.2 --set env.TZ="Asia/Seoul" --namespace kube-system
kubectl patch svc -n kube-system kube-ops-view -p '{"spec":{"type":"LoadBalancer"}}'
kubectl annotate service kube-ops-view -n kube-system "external-dns.alpha.kubernetes.io/hostname=kubeopsview.$MyDomain"
echo -e "Kube Ops View URL = http://kubeopsview.$MyDomain:8080/#scale=1.5"

# AWS LB Controller
helm repo add eks https://aws.github.io/eks-charts
helm repo update
helm install aws-load-balancer-controller eks/aws-load-balancer-controller -n kube-system --set clusterName=$CLUSTER_NAME \
  --set serviceAccount.create=false --set serviceAccount.name=aws-load-balancer-controller

# gp3 스토리지 클래스 생성
kubectl apply -f https://raw.githubusercontent.com/gasida/PKOS/main/aews/gp3-sc.yaml

프로메테우스 & 그라파나 설정

# 사용 리전의 인증서 ARN 확인
CERT_ARN=`aws acm list-certificates --query 'CertificateSummaryList[].CertificateArn[]' --output text`
echo $CERT_ARN

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

# 파라미터 파일 생성 : PV/PVC(AWS EBS) 삭제에 불편하니, 4주차 실습과 다르게 PV/PVC 미사용
cat <<EOT > monitor-values.yaml
prometheus:
  prometheusSpec:
    podMonitorSelectorNilUsesHelmValues: false
    serviceMonitorSelectorNilUsesHelmValues: false
    retention: 5d
    retentionSize: "10GiB"

  ingress:
    enabled: true
    ingressClassName: alb
    hosts: 
      - prometheus.$MyDomain
    paths: 
      - /*
    annotations:
      alb.ingress.kubernetes.io/scheme: internet-facing
      alb.ingress.kubernetes.io/target-type: ip
      alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":443}, {"HTTP":80}]'
      alb.ingress.kubernetes.io/certificate-arn: $CERT_ARN
      alb.ingress.kubernetes.io/success-codes: 200-399
      alb.ingress.kubernetes.io/load-balancer-name: myeks-ingress-alb
      alb.ingress.kubernetes.io/group.name: study
      alb.ingress.kubernetes.io/ssl-redirect: '443'

grafana:
  defaultDashboardsTimezone: Asia/Seoul
  adminPassword: prom-operator
  defaultDashboardsEnabled: false

  ingress:
    enabled: true
    ingressClassName: alb
    hosts: 
      - grafana.$MyDomain
    paths: 
      - /*
    annotations:
      alb.ingress.kubernetes.io/scheme: internet-facing
      alb.ingress.kubernetes.io/target-type: ip
      alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":443}, {"HTTP":80}]'
      alb.ingress.kubernetes.io/certificate-arn: $CERT_ARN
      alb.ingress.kubernetes.io/success-codes: 200-399
      alb.ingress.kubernetes.io/load-balancer-name: myeks-ingress-alb
      alb.ingress.kubernetes.io/group.name: study
      alb.ingress.kubernetes.io/ssl-redirect: '443'

alertmanager:
  enabled: false
EOT
cat monitor-values.yaml | yh

# 배포
kubectl create ns monitoring
helm install kube-prometheus-stack prometheus-community/kube-prometheus-stack --version 57.2.0 \
--set prometheus.prometheusSpec.scrapeInterval='15s' --set prometheus.prometheusSpec.evaluationInterval='15s' \
-f monitor-values.yaml --namespace monitoring

# Metrics-server 배포
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

# 프로메테우스 ingress 도메인으로 웹 접속
echo -e "Prometheus Web URL = https://prometheus.$MyDomain"

# 그라파나 웹 접속 : 기본 계정 - admin / prom-operator
echo -e "Grafana Web URL = https://grafana.$MyDomain"

도커

본인 계정 생성 or 확인

https://hub.docker.com/

Docker Hub Container Image Library | App Containerization

Increase your reach and adoption on Docker Hub With a Docker Verified Publisher subscription, you'll increase trust, boost discoverability, get exclusive data insights, and much more.

hub.docker.com

자신만의 웹 서버 도커 이미지 생성 후 도커 컨테이너 실행

# ubuntu 이미지 다운로드
docker pull ubuntu:20.04
docker images

# 실습을 위한 디렉터리 생성 및 이동
mkdir -p /root/myweb && cd /root/myweb

# Dockerfile 파일 생성
vi Dockerfile
FROM ubuntu:20.04
ENV TZ=Asia/Seoul VERSION=1.0.0 NICK=<자신의 닉네임>
RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone && \
    sed -i 's/archive.ubuntu.com/mirror.kakao.com/g' /etc/apt/sources.list && \
    sed -i 's/security.ubuntu.com/mirror.kakao.com/g' /etc/apt/sources.list && \
    apt-get update && apt-get install -y apache2 figlet && \
    echo "$NICK Web Server $VERSION<br>" > /var/www/html/index.html && \
    echo "<pre>" >> /var/www/html/index.html && \
    figlet AEWS Study >> /var/www/html/index.html && \
    echo "</pre>" >> /var/www/html/index.html
EXPOSE 80
CMD ["usr/sbin/apache2ctl", "-DFOREGROUND"]

# 이미지 빌드
cat Dockerfile
docker build -t myweb:v1.0.0 .
docker images
docker image history myweb:v1.0.0
docker image inspect myweb:v1.0.0 | jq

컨테이너 동작 확인

# 컨테이너 실행
docker run -d -p 80:80 --rm --name myweb myweb:v1.0.0
docker ps
curl localhost

# 웹 접속 확인
curl -s ipinfo.io/ip | awk '{ print "myweb = http://"$1"" }'

이렇게 이미지가 만들어졌고, 동작을 확인 했다면,

해당 이미지를 도커 허브에 업로드

#
DHUB=<도커 허브 계정>
DHUB=peachdo
docker tag myweb:v1.0.0 $DHUB/myweb:v1.0.0
docker images

# 도커 허브 로그인
docker login
Username: <자신의 ID>
Password: <암호>
## 로그인 정보는 /[계정명]/.docker/config.json 에 저장됨. docker logout 시 삭제됨
## cat /root/.docker/config.json | jq

# push 로 이미지를 저장소에 업로드
docker push $DHUB/myweb:v1.0.0

허브에 이미지 있으니까 필요하면 저기서 꺼내쓰고,

로컬에서는 삭제

# 컨테이너 종료
docker rm -f myweb
docker ps

# 로컬 이미지 삭제
docker rmi $DHUB/myweb:v1.0.0
docker images

도커 허브에서 해당 이미지 사용 시 동작여부 확인

# 
docker run -d -p 80:80 --rm --name myweb $DHUB/myweb:v1.0.0
docker iamges

# 확인
docker ps
curl localhost
curl -s ipinfo.io/ip | awk '{ print "myweb = http://"$1"" }'

# 삭제
docker rm -f myweb

젠킨스(w. k8s) -> 별도 페이지 링크

https://bravesunfish.tistory.com/77

[Jenkins]Jenkins 설치 및 실습

Jenkins 개념 - 지속적 통합 & 배포를 위한 워크플로우 제어에 사용되는 툴 - 자바 기반의 오픈소스 -> 자바와 친화성이 높음 - 아파치 톰캣처럼 서블릿 컨테이너 내부에서 실행되는 서버 시스템 -

bravesunfish.tistory.com

아르고 -> 별도 페이지 링크

https://bravesunfish.tistory.com/78

[ArgoCD] ArgoCD 설치 및 실습

Argo 개념 ArgoCD란? - gitops를 구현하기 위해 쿠버네티스 어플리케이션 자동배포를 위한 오픈소스 - ci/cd 중 cd 를 담당 - 선언적 어플리케이션 관리를 사용 : 명시적으로 원하는 상태를 선언, argoCD가

bravesunfish.tistory.com