ybchoi

그라파나+로키를 이용하여 얼럿 설정하기

ybchoi — Thu, 4 Jan 2024 20:34:45 +0900

메트릭등을 카운트 하여 얼럿을 생성해도 되겠지만 간단하게 로그를 카운팅 하여 얼럿을 설정 할수도 있다

그라파나에서 loki 로그 카운터로 얼럿을 생성하는 방법 테스트

먼저 로그를 찍기 위해 pod를 한개 배포함

% k get pod --show-labels
NAME     READY   STATUS    RESTARTS   AGE     LABELS
worker   1/1     Running   0          6d18h   run=worker

해당 파드의 로그 테스트 (얼럿에 추가할 로그는 임의로 trigger_alert_xxxapi_error라고 정함) 앱에서 특정 로그를 찍으면 그것을 카운팅 하는 형태

파드에서 STD 출력을 통해 로깅 수행

[root@worker /]# echo "trigger_alert_xxxapi_error" >> /proc/1/fd/1
[root@worker /]# echo "trigger_alert_xxxapi_error" >> /proc/1/fd/1
[root@worker /]# echo "trigger_alert_xxxapi_error" >> /proc/1/fd/1
[root@worker /]# echo "trigger_alert_xxxapi_error" >> /proc/1/fd/1
[root@worker /]# echo "trigger_alert_xxxapi_error" >> /proc/1/fd/1

파드안에서 echo 로 std출력 시킴

loki에서 해당 로그 잘 찍혔는지 확인

정상적으로 로그가 찍힌다

이제 저 로그를 카운팅 할 대상으로 얼럿을 생성하여 테스트

쿼리문은 아래와 같음

count_over_time({pod="worker"}[5m] |= "trigger_alert_xxxapi_error") > 5

5분간 해당 로그의 카운트가 5개가 넘으면 얼럿

쿼리 테스트

이제 이것을 이용하여 얼럿을 생성한다

파드내 에러 생성(6개)

[root@worker /]# echo "trigger_alert_xxxapi_error" >> /proc/1/fd/1
[root@worker /]# echo "trigger_alert_xxxapi_error" >> /proc/1/fd/1
[root@worker /]# echo "trigger_alert_xxxapi_error" >> /proc/1/fd/1
[root@worker /]# echo "trigger_alert_xxxapi_error" >> /proc/1/fd/1
[root@worker /]# echo "trigger_alert_xxxapi_error" >> /proc/1/fd/1
[root@worker /]# echo "trigger_alert_xxxapi_error" >> /proc/1/fd/1

설정한대로(슬랙으로 보내기) 알람 정상 작동

쿠버네티스 이벤트로그 loki 로 수집

ybchoi — Thu, 4 Jan 2024 20:29:44 +0900

쿠버네티스 이벤트에는 클러스터 동작관련된 중요한 로그가 남는다

이 로그는 휘발성이며 1시간만 보유됨, 컨테이너 로깅이 아니기때문에 기본 로그수집기로는 수집 불가

https://artifacthub.io/packages/helm/deliveryhero/k8s-event-logger

위 툴은 컨테이너를 하나 띄워 주기적으로 k8s api에 event를 콜하고 STD출력함

STG출력은 기본 로그 수집기인 fluentd 가 수집하여 로키로 보냄

위와같이 쿼리하면 json형식으로 쿠버네티스 이벤트 로그를 수집하고 확인할수 있다

prettify json을 활성화하면 좀더 보기 좋게 나옴

1개의 ALB-Ingress로 여러개의 타켓 사용시 타켓별 설정 하는법

ybchoi — Thu, 4 Jan 2024 20:26:04 +0900

동일 도메인을 path별로 공유할때는 1개의 Ingress를 사용한다

이렇게 되면 여러가지 타겟을 한개의 ingress가 바라보는 형태인데

각각 타겟별로 속성이 다르다면(헬스체크,attributes 등) ingress 어노테이션이 아닌 서비스 어노테이션을 이용하면 된다

헬스체크 패스가 /가 아니라면 아래와 같이 ingress 어노테이션을 설정하는데

  annotations:
    alb.ingress.kubernetes.io/healthcheck-path: /api/health

이 어노테이션을 인그레스가 아닌 대상이 바라보는 서비스에 달면 각각의 타겟별로 설정을 다르게 가져갈수 있다

Cluster Autoscaler에서 0개짜리인 ASG를 스케일아웃 하는법

ybchoi — Thu, 4 Jan 2024 20:15:04 +0900

min 이 0 인 ASG를 CA가 scaling 하지 못하는 문제 발생

https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md#auto-discovery-setup

문서 확인결과 아래 태그가 ASG에 필요함

k8s.io/cluster-autoscaler/node-template/label/value

k8s.io/cluster-autoscaler/node-template/taint/value

테라폼에서 여러개의 태그를 지정하기 위해 아래 방법 시도

locals {
  eks_asg_tag_list_gpu_pv = {
    "k8s.io/cluster-autoscaler/node-template/label/role" : "gpu-pv"
    "k8s.io/cluster-autoscaler/node-template/label/team" : "devops"
    "k8s.io/cluster-autoscaler/node-template/taint/spot" : "true:NoSchedule"
    "k8s.io/cluster-autoscaler/node-template/taint/team" : "data:NoSchedule"
  }
  
  
  resource "aws_autoscaling_group_tag" "gpu_pv" {
  for_each               = local.eks_asg_tag_list_gpu_pv
  autoscaling_group_name = aws_eks_node_group.gpu_pv.resources.0.autoscaling_groups.0.name

  tag {
    key                 = each.key
    value               = each.value
    propagate_at_launch = true
  }
}

위와같이 적용하고 from 0에서 스케일링 정상작동 하는것 확인

cronjob의 타임존 설정

ybchoi — Thu, 4 Jan 2024 20:08:53 +0900

쿠버네티스 타임존은 기본적으로 UTC로 동작하며 이를 변경할수 없음

파드 내부의 타임존은 timezone파일을 마운트 하여 맞출수 있지만 크론탭의 경우 불가능함

일반적인 사용에는 -9해서 만들면 되니까 큰 문제가 없는데

만약 매달 1일 05시에 도는 잡이라면 문제가 발생

30 8 1 * * /usr/bin/bash test3
0 5 1 * * /usr/bin/bash  test1
0 6 1 * * /usr/bin/bash  test

이게 왜 문제냐면 위 시간은 UTC라 KST로 조정하면 1일이 아니고 매달 말일임

매달 말일의 경우 크론탭으로는 설정이 불가능(28일,30일,31일 등 여러가지 조건이 있으므로)

해서 일반적으로 크론탭에서는 아래와 같은 방법을 쓰는데

30 23 28-31 * * [ $(date +\%d -d tomorrow) = 02 ] && /usr/bin/bash test

위와같이 설정하면 매달 28~31일날(UTC기준) 실행되는데 다음날이 2일(KST기준)인 경우에만 실행 한다(원래는 1일이나 파드내부는 KST 크론잡 타임은 UTC이므로 위와같이 설정해야함) 외 내부 타임존이 다르기때문에 계산하는것도 두번해야하고 관리도 번거로움

이렇게 적용을 하려다가 크론잡 doc을 보니 1.25부터 크론잡 타임존이 베타로 승격됨

타임 존

크론잡에 타임 존이 명시되어 있지 않으면, kube-controller-manager는 로컬 타임 존을 기준으로 스케줄을 해석한다.

기능 상태: Kubernetes v1.25 [beta]

CronJobTimeZone 기능 게이트를 활성화하면, 크론잡에 대해 타임 존을 명시할 수 있다(기능 게이트를 활성화하지 않거나, 타임 존에 대한 실험적 지원을 제공하지 않는 쿠버네티스 버전을 사용 중인 경우, 클러스터의 모든 크론잡은 타임 존이 명시되지 않은 것으로 동작한다).

이 기능을 활성화하면, spec.timeZone을 유효한 타임 존으로 지정할 수 있다. 예를 들어, spec.timeZone: "Etc/UTC"와 같이 설정하면 쿠버네티스는 협정 세계시를 기준으로 스케줄을 해석한다.

Go 표준 라이브러리의 타임 존 데이터베이스가 바이너리로 인클루드되며, 시스템에서 외부 데이터베이스를 사용할 수 없을 때 폴백(fallback)으로 사용된다

아래와 같이 설정

spec:
  schedule: "30 8 1 * *"
  successfulJobsHistoryLimit: 1
  timeZone: 'Asia/Seoul'

굳이 -9 계산안해도 편하게 타임존 설정가능

쿠버네티스 기본 기조자체가 UTC를 써라 tz관련된 그 어떤 피쳐도 없다 였는데

크론잡의 경우 위같은 문제가 워낙 많아 최근에 생긴듯

위와같이 모든 잡에 적용 했으며 매일 6~9시 사이 도는 잡이 있으니 익일 KST기준으로 잘 도는지 체크

기존잡에 timezone만 추가해서 그런지 정상적으로 적용이 되지 않았음(09시 도는 잡이 18시에 돔)

전체 잡을 삭제하고 다시 적용했고

    State:          Terminated
      Reason:       Completed
      Exit Code:    0
      Started:      Wed, 26 Jul 2023 09:05:01 +0900
      Finished:     Wed, 26 Jul 2023 09:05:01 +0900

정상적으로 KST 09시에 돔

무중단 배포를 위해 필요한 기술들

ybchoi — Thu, 4 Jan 2024 20:04:27 +0900

쿠버네티스 롤링 업데이트를 하다보면 업데이트 간 간헐적으로 50x 코드가 발생하는데 이러한일이 왜 발생되며 예방하려면 어떠한 기술을 사용해야 하는지에 대한 정리

구조상 무조건 발생되는 문제이며 대부분 모르거나 새로고침하면 해결되므로 그냥 두는경우가 있는데 충분히 예방하고 방지할수 있는 부분임

쿠버네티스만의 문제는 아니고 복합적인 원인과 문제로 인해 발생되는 일

먼저 에러가 왜 발생되는지에 대한 부분

테스트를 위해 구동하는데 10초가 걸리는 웹서버를 생성

package main

import (
	"fmt"
	"net/http"
	"time"
)

func main() {
	// 루트 경로 핸들러 등록
	http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
		fmt.Fprint(w, "Hello, World!")
	})

	// 시작전 딜레이 10초
	time.Sleep(10 * time.Second)
	// 서버 시작
	fmt.Println("서버 시작...")
	err := http.ListenAndServe(":8080", nil)
	if err != nil {
		fmt.Println(err)
	}
}

이를 쿠버네티스에 배포함(프로브 설정없음)

apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: websvr
  name: websvr
spec:
  replicas: 3
  selector:
    matchLabels:
      app: websvr
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: websvr
    spec:
      containers:
      - image: devops-demo:10001
        name: websvr
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: websvr-service
spec:
  selector:
    app: websvr-server
  ports:
    - protocol: TCP
      port: 8080
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/group.name: private-group
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS":443}]'
    alb.ingress.kubernetes.io/manage-backend-security-group-rules: "true"
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/security-groups: sg-05ac5cd61c45454
    alb.ingress.kubernetes.io/ssl-redirect: "443"
    alb.ingress.kubernetes.io/target-type: ip
  name: websvr-ing
spec:
  ingressClassName: alb
  rules:
  - host: testapp.devops.test.gg
    http:
      paths:
      - backend:
          service:
            name: websvr-service
            port:
              number: 8080

도메인을 연결하고 파드는 3개로 구성

배포후 curl을 통해 확인

% curl https://testapp.devops.test.gg
Hello, World!%

장애 상황을 감지할수 있도록 간단한 쉘작성

while true; do
  STATUS_CODE=$(curl --output /dev/null --silent --max-time 5 --write-out "%{http_code}" "https://testapp.devops.test.gg")
  sleep 0.5
  if [ $STATUS_CODE -ne 200 ] ;
  then
   echo $STATUS_CODE "$(date +"%T")"
  fi
done

0.5초마다 curl을 하고 200외에는 시간과 코드를 출력함, timeout은 5초 설정

rollout을 해도 되겠으나 실제 롤링 업데이트를 가정하기 위해 10001 10002 이미지 2개를 번갈아가며 교체하고 테스트

위 상태에서 롤링 업데이트 결과

% bash curl.sh
000 13:57:05
000 13:57:11
000 13:57:16
502 13:57:17
502 13:57:17
502 13:57:18
502 13:57:18
....
502 13:57:31

처음 000 코드는 설정된 5초의 타임아웃때문에 발생

그 후 502는 웹서버가 올라오는 약 10초동안 502가 발생함

실제 컨테이너내 앱은 10초후에 준비가 되지만 쿠버네티스 기본값으로는 PID 1만 구동이면 성공으로 간주하므로 트래픽을 보내기 시작하며 위와같은 일이 벌어짐

이러한 근본적인 원인을 해결하려면 프로브를 설정해야함

현재는 파드구동 → 컨테이너구동(PID) ->성공(트래픽보내기시작) → 다음파드 롤링

이라면 파드구동 → 컨테이너구동(PID) → 프로브작동(httpget) → 프로브성공(트래픽 보내기 시작) → 다음파드 롤링

형태로 바꾸어야 한다

위 앱의 경우 웹서버이므로 간단하게 / 를 체크하는 프로브를 설정한다

        livenessProbe:
          httpGet:
            path: /
            port: 8080
          initialDelaySeconds: 10
          periodSeconds: 5
        readinessProbe:
          httpGet:
            path: /
            port: 8080
          initialDelaySeconds: 10
          periodSeconds: 5

적용

지금까지는 프로브가 없어서 시작하자마자 모든 파드가 내려가고 올라감

지금부터는 이과정에 프로브가 추가된다

websvr-66cfd8bf4d-44x5c   1/1     Running   0          7m
websvr-66cfd8bf4d-6p95c   1/1     Running   0          6m59s
websvr-66cfd8bf4d-7bmhr   1/1     Running   0          7m1s
websvr-6df6fd758d-d6kp6   0/1     Running   0          12s

위와같이 파드를 생성하고 준비가 될때까지(프로브성공) 성공으로 간주하지 않고 기다림

프로브 설정 이후에는 위와같은 이유로 전체 롤링 업데이트 시간이 크게 증가됨

프로브 설정 이후 curl 체크

000 14:11:17
000 14:11:23
000 14:11:30
000 14:13:13
000 14:13:20
000 14:13:47
502 14:13:50
000 14:13:55
000 14:14:23
000 14:14:31

보면 502는 거의 사라지고 타임아웃이 많이 나는걸 확인 할수 있다

502가 나는 원인중 한개는 준비되기전 파드에 트래픽이 흐르기 시작해서이고 해결이 되었다

타임아웃이 나는 원인은 인입된 트래픽의 처리 이전 파드가 종료되서 이다

쿠버네티스가 파드를 종료할때는 sigterm을 내리고 컨테이너는 신호를 받아 pid1번을 종료한다

잘 개발된 앱이라면 sigterm을 받고 현재 연결된 세션이나 이미 받은 요청에 대한 처리를 하도록 구성이 되어있겠지만 그렇지 못한 경우가 많고 웹서버의 경우에는 거의 이렇게 구성하지 않는다

이를 대비하기 위한 기능이 쿠버네티스에도 있는데 Lifecyclehook 이다

파드가 종료될때(롤링으로인해)는 아래의 순서에 따른다

종료 성공이 기본값으로 30초간(기본값 늘릴수 있음) 되지 않으면 sigkill을 보내 강제 종료함

종료신호(Sigterm) → 종료 확인 → 종료 성공

종료시작-(EP에서 해당 파드제거)-이미종료

파드가 종료되기전에 EP에서 해당 파드가 제거되어 트래픽이 가지 않아야 하는데 sigterm(종료시작)을 받자마자 파드가 죽어버려서 EP에서 빠지기전 트래픽이 도달하고 해당 트래픽처리를 하지 못하고 파드가 죽어버린다 그래서 에러 발생

이와같은 앱에 라이프사이클 훅(sleep 10) 을 삽입하면 아래와 같이 종료된다

종료신호(Sigterm)-> 훅 작동(sleep ………………..10)→ 종료 확인 → 종료 성공

종료시작(EP에서 해당 파드제거)----여기충분한트래픽처리시간이존재------종료

라이프사이클은 아래와 같이 설정한다

    lifecycle:
      preStop:
        exec:
          command: ["sleep", "10"]

설정후 롤링 업데이트 수행

라이프사이클 훅이 삽입됬으므로 각 파드 종료간 10초의 딜레이가 생겨 전체적인 롤링 업데이트시간은 더욱 늘어남

여기부터는 상황 설명을 위해 curl을 내부망에서도 수행

외부망 curl

pv -N 000 14:46:38
pv -N 000 14:47:47

전체 과정에서 타임아웃 2번 발생

내부망 curl

아무런 에러없음

위 2가지 설정만으로 쿠버네티스에서는 파드 롤링 업데이트간 트래픽 제어와 처리를 효과적으로 할수 있다

그러나 아직도 외부망에서는 에러가 발생되고 있음

이러한 이유는 ALB때문이다

쿠버네티스 서비스의 ep와는 다르게 ALB가 바라보고 있는 타겟그룹의 추가시간이나 제거시간에 딜레이가 있기때문임

쿠버네티스는 체크(성공시) → ep에 넣기 → 트래픽가기 가 순식간에 일어남

ALB의 경우 체크(성공시) → 타겟그룹에 넣기(한참걸림) → 실제로 트래픽 감

타겟그룹의 타겟 add,delete타임이 쿠버네티스 엔드포인트 제어보다 느리므로 전체 과정에서 타겟그룹에 정상적인 타겟이 없는 경우가 간혹 생기는데 그에 따른 에러다

이를 해소하기위해서는 readinessgate를 이용하면되는데

readinessgate를 설정하면 아래의 단계로 업데이트가 수행된다

파드구동 → 컨테이너구동(PID) → 프로브작동(httpget) → 프로브성공(트래픽 보내기 시작) → ALB 타겟그룹에 대상추가가 끝나길기다림 → 다음파드 롤링

readinessgate는 네임스페이스에 레이블링 하여 설정한다

kubectl label namespace default elbv2.k8s.aws/pod-readiness-gate-inject=enabled

설정이후부터는 pod -o wide옵션으로 보면 게이트가 보이며

gate까지 성공해야 파드 구동 성공으로 간주함

위 설명한 모든 기술들을 적용하고 롤링 업데이트 결과

내부/외부 모두 단 한번의 에러없이 수행됨

NPD(Node Problem Detector) 활용

ybchoi — Thu, 4 Jan 2024 19:52:02 +0900

k8s에서 노드 모니터링 하는건 단순히 4가지인데 이는 아래와 같다

노드 컨디션

설명

Ready	노드가 상태 양호하며 파드를 수용할 준비가 되어 있는 경우 True, 노드의 상태가 불량하여 파드를 수용하지 못할 경우 False, 그리고 노드 컨트롤러가 마지막 node-monitor-grace-period (기본값 40 기간 동안 노드로부터 응답을 받지 못한 경우) Unknown
DiskPressure	디스크 사이즈 상에 압박이 있는 경우, 즉 디스크 용량이 넉넉치 않은 경우 True, 반대의 경우 False
MemoryPressure	노드 메모리 상에 압박이 있는 경우, 즉 노드 메모리가 넉넉치 않은 경우 True, 반대의 경우 False
PIDPressure	프로세스 상에 압박이 있는 경우, 즉 노드 상에 많은 프로세스들이 존재하는 경우 True, 반대의 경우 False
NetworkUnavailable	노드에 대해 네트워크가 올바르게 구성되지 않은 경우 True, 반대의 경우 False

위처럼 아주 제한적인 상황에서만 노드의 장애여부를 판단하고 스케쥴을 disable하며 이외의 경우는 아무것도 감지하지 못하고 파드를 스케쥴링 한다

NPD는 노드의 문제감지케이스를 크게 확장 시켜주는데 이는 아래와 같다

Problem Daemon Types

NodeCondition

Description

Configs

Disabling Build Tag

Problem Daemon Types

NodeCondition

Description

Configs

Disabling Build Tag

SystemLogMonitor	KernelDeadlock ReadonlyFilesystem FrequentKubeletRestart FrequentDockerRestart FrequentContainerdRestart	A system log monitor monitors system log and reports problems and metrics according to predefined rules.	filelog, kmsg, kernel abrt systemd	disable_system_log_monitor
SystemStatsMonitor	None(Could be added in the future)	A system stats monitor for node-problem-detector to collect various health-related system stats as metrics. See the proposal here.		disable_system_stats_monitor
CustomPluginMonitor	On-demand(According to users configuration), existing example: NTPProblem	A custom plugin monitor for node-problem-detector to invoke and check various node problems with user-defined check scripts. See the proposal here.	example	disable_custom_plugin_monitor
HealthChecker	KubeletUnhealthy ContainerRuntimeUnhealthy	A health checker for node-problem-detector to check kubelet and container runtime health.	kubelet docker

커널의 deadlock감지, filesystem read-only감지(full check) 중요 프로세스의 리스타트 횟수등을 감지하여 노드의 장애 여부 판단할수 있는 케이스종류를 크게 늘려 준다

장애 상황이 많아지는대신 시스템은 안정되겠으나 관리의 포인트는 늘어날듯

주의사항으로는 node cordon이후 uncordon은 자동으로 되지 않음 한번 cordon되면 운영자가 확인하고 제거나 uncordon 수행해야함

terraform backend s3+dynamodb 사용하기

ybchoi — Thu, 27 Oct 2022 11:32:07 +0900

혼자서 terraform사용할때는 사실 크게 필요없음(백업용도 외)

그냥 로컬코드 레포에 테라폼의 상태를 저장하는 tfstate를 두면 된다

그러나 여러사람이 동시에 작업할경우에는 일일히 tfstate를 동기화하여야 하고 동기화를 하지 않았을때 apply를 해버리면 인프라가 날라가는 경우가 생김

또한 tfstate를 동기화 했더라도 동시에 작업을 해버리면 일관성을 해칠수 있다

해서 terraform backend로 s3(tfstate저장) 와 dynamedb(tfstate Lock관리) 를 사용하는 방법 정리

현재 bc-labs 클러스터 내 mainnet,testnet 배포에 적용되어 있음

크게 어렵진 않다 아래와 같이 프로바이더tf에 설정해주면 됨

terraform {
  required_version = ">= 0.12"
    backend s3 {
    bucket         = "testnet" # S3 버킷 이름
    key            = "terraform/testnet/terraform.tfstate" # tfstate 저장 경로
    region         = "ap-northeast-2"
    dynamodb_table = "terraform-testnet-tfstate-lock" # dynamodb table 이름
    profile        = "testnet"
  }
}

profile의 경우 아래와 같이 provider에 설정이 되어있는데

provider "aws" {
        profile = "testnet"
  region = var.aws_region
}

위 설정을 참조하지 않아서 계속 에러가 발생됨

해서 backend 부분에 profile을 별도로 명시 해줌

lock용 dynamodb table은 아래와 같이 배포

resource "aws_dynamodb_table" "terraform-testnet-tfstate-lock" {
  name           = "terraform-testnet-tfstate-lock"
  hash_key       = "LockID"
  billing_mode   = "PAY_PER_REQUEST"

  attribute {
    name = "LockID"
    type = "S"
  }
}

dynamodb 및 s3는 프로비저닝 이전에 배포되야 하므로 console에서 생성하려면 아래와 같이 생성

새롭게 프로비저닝 하는것이라면 terraform init을 바로 하면 되고

기존에 이미 로컬로 관리하고 있었다면 .terraform 폴더를 삭제해야함(s3 backend의 경우 설치 되는게 다름)

삭제 후 terrafom init 재수행

terraform init

Initializing the backend...

Successfully configured the backend "s3"! Terraform will automatically
use this backend unless the backend configuration changes.

Initializing provider plugins...
- Finding latest version of hashicorp/aws...
- Finding latest version of hashicorp/http...
- Installing hashicorp/http v3.1.0...
- Installed hashicorp/http v3.1.0 (signed by HashiCorp)
- Installing hashicorp/aws v4.36.1...
- Installed hashicorp/aws v4.36.1 (signed by HashiCorp)

Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

s3 backend 설정 완료

이후 테라폼 작업시에는 tfstate가 로컬이 아닌 s3로 저장되어지며 dynamodb로 인해 lock관리도 되므로 여러명이서 작업해도 문제 없음

GitOps를 위한 Jenkins Pipeline 작성

ybchoi — Thu, 14 Jul 2022 14:33:28 +0900

파이프라인 문법은 2가지가 있는데 Declarative 방식을 사용 하였습니다

젠킨스 설치법,인증생성 방법등 기초적인 내용은 생략 합니다

AWS ECR 인증과 github인증은 젠킨스내에 이미 있어야 합니다(credential)

슬랙 알람을 사용하려면 슬랙 설정을 해야 합니다

아래 파이프라인중 {{}} 안에 내용은 사용자의 맞게 수정하여야 합니다

레포는 빌드할 이미지가 있는 소스레포, ArgoCD에서 사용하는 배포용 manifest레포 2가지가 있다고 가정 합니다

pipeline {
 environment {
 registry = "{{ECR주소}}/{{레포이름(이미지)}}"
 registryCredential = '{{erc인증용credential}}'
 dockerImage = ''
}
  
  agent any
  stages {
    stage('Cloning Git') {
      steps {
        slackSend (channel: '#{{슬랙채널}}', color: '#00FF00', message: "${env.JOB_NAME}앱의 CI 과정이 시작되었습니다 \n Job '${env.JOB_NAME} [${env.BUILD_NUMBER}]' (${env.BUILD_URL})")
        git([url: '{{소스레포지토리의주소}}', branch: '{{브랜치이름}}', credentialsId: '{{깃접속에필요한credential}}'])
          }
            }
    stage('Building Image') {
      steps{
        script {
          dockerImage = docker.build registry + ":$BUILD_NUMBER"
    }
        }
            }
    stage('Testing') {
        steps{
         script {
            dockerImage.inside {
            sh 'node --version'
            }
            }
        }
    }
stage('Push Image') {
    steps{
        script {
        docker.withRegistry( '{{ECR주소}}', registryCredential ) {
        dockerImage.push()
    }
        }
            }
                }
stage('Cleaning Up') {
steps{
sh "docker rmi $registry:$BUILD_NUMBER"
                }
            }
    stage('Deploy') {
    steps{
                    sh 'set +x'
                    sh 'export GIT_SSH_COMMAND="ssh -oStrictHostKeyChecking=no"'
                    sh '{{아르고CD배포용레포주소}} || true'
                    sh "sed -i 's/{{레포이름(이미지)}}:.*\$/{{레포이름(이미지)}}:${env.BUILD_NUMBER}/g' {{deployment의경로}}/deployment.yaml"
                    dir ("{{레포경로}}") {
                        sh 'git add {{레포이름(이미지)}}/deployment.yaml'
                        sh "git commit -m 'updated the image tag to ${env.BUILD_NUMBER}'"
                        sh 'git push'
                        deleteDir()
                }
            }
        }
            
  }   
            
    post {
        success {
            slackSend (channel: '#{{슬랙채널}}', color: '#00FF00', message: "빌드 완료 \n ${env.JOB_NAME}앱의 CI 과정이 성공적으로 끝났습니다 \n Job '${env.JOB_NAME} [${env.BUILD_NUMBER}]' (${env.BUILD_URL})")
        }
        failure {
            slackSend (channel: '#{{슬랙채널}}', color: '#00FF00', message: "빌드가 실패하였습니다 \n ${env.JOB_NAME}앱의 젠킨스 콘솔을 확인해주세요 \n Job '${env.JOB_NAME} [${env.BUILD_NUMBER}]' (${env.BUILD_URL})")
        }
    }
}

아래는 상세 설명입니다

먼저 파이프라인의 시작 env 입니다

pipeline {
 environment {
 registry = "{{ECR주소}}/{{레포이름(이미지)}}"
 registryCredential = '{{erc인증용credential}}'
 dockerImage = ''
}

파이프라인에서 사용할 변수를 지정하여 줍니다

registry의 경우 ecr이면 {{계정}}.dkr.ecr.ap-northeast-2.amazonaws.com 이며

이미지는 test-app 식입니다

위 예제라면 registry에는 {{계정}}.dkr.ecr.ap-northeast-2.amazonaws.com/test-app 이라고 적어주시면 됩니다

registryCredential 부분은 ecr인증용 credential 이름을 적어주면 되고 젠킨스 메뉴 credential에서 ecr권한이 있는 계정의 AWS KEY를 이용한 credential을 생성하여 해당 credential이름을 적어주심 됩니다

스테이지 시작입니다

    stage('Cloning Git') {
      steps {
        slackSend (channel: '#{{슬랙채널}}', color: '#00FF00', message: "${env.JOB_NAME}앱의 CI 과정이 시작되었습니다 \n Job '${env.JOB_NAME} [${env.BUILD_NUMBER}]' (${env.BUILD_URL})")
        git([url: '{{소스레포지토리의주소}}', branch: '{{브랜치이름}}', credentialsId: '{{깃접속에필요한credential}}'])
          }
            }

소스 레포지토리의 git clone을 제일 먼저 수행합니다. 수행하면서 slack채널에 CI과정이 시작되었다고 알립니다

slackSend기능을 이용하기 위해서는 젠킨스에 플러그인과 적절한 slack설정이 필요 합니다

슬랙 알람 이후에 소스레포를 내려 받습니다 url에 레포주소를, branch는 사용할브랜치(ex, master,develop 등) 을 적어주시고

credentialsId에는 github접속시 사용할 credential이름을 적어줍니다 이 cred역시 마찬가지로 사전에 젠킨스에서 생성하여야 합니다

빌드와 테스트 PUSH과정

    stage('Building Image') {
      steps{
        script {
          dockerImage = docker.build registry + ":$BUILD_NUMBER"
    }
        }
            }
    stage('Testing') {
        steps{
         script {
            dockerImage.inside {
            sh 'node --version'
            }
            }
        }
    }
    stage('Push Image') {
    steps{
        script {
        docker.withRegistry( '{{ECR주소}}', registryCredential ) {
        dockerImage.push()
    }

내려받은 레포지토리안에 있는 Dockerfile로 docker build를 수행합니다 처음 설정한 registry 이름과 :빌드 넘버로 이미지가 빌드 되어집니다

테스팅 부분은 임의로 넣은것이니 필요하면 수정하여 사용하세요

테스트까지 마쳤으면 ECR로 빌드된 이미지를 PUSH 합니다

Clean UP과 배포용 Repo의 이미지 태그 변경 작업

이제 새로운 버전을 가진 앱이 ECR에 업데이트 되었으므로 배포용 repo에 해당앱의 deployment파일에 이미지 넘버를 수정하는 작업을 수행 합니다

stage('Cleaning Up') {
steps{
sh "docker rmi $registry:$BUILD_NUMBER"
                }
            }
    stage('Deploy') {
    steps{
                    sh 'set +x'
                    sh 'export GIT_SSH_COMMAND="ssh -oStrictHostKeyChecking=no"'
                    sh '{{아르고CD배포용레포주소}} || true'
                    sh "sed -i 's/{{레포이름(이미지)}}:.*\$/{{레포이름(이미지)}}:${env.BUILD_NUMBER}/g' {{deployment의경로}}/deployment.yaml"
                    dir ("{{레포경로}}") {
                        sh 'git add {{레포이름(이미지)}}/deployment.yaml'
                        sh "git commit -m 'updated the image tag to ${env.BUILD_NUMBER}'"
                        sh 'git push'
                        deleteDir()
                }
            }
        }
            
  }

Cleanup 스테이지는 방금 생성된 이미지를 로컬에서 삭제 합니다

deploy과정에서는 소스레포가 아닌 배포용 레포를 내려받고

배포용 레포의 해당앱 deployment.yaml 내 이미지 버전 이름을 빌드넘버로 sed를 이용하여 수정, 이후 git push로 커밋합니다

커밋이후에는 ArgoCD를 통해 deploy됩니다

마지막으로 post(알람) 입니다

    post {
        success {
            slackSend (channel: '#{{슬랙채널}}', color: '#00FF00', message: "빌드 완료 \n ${env.JOB_NAME}앱의 CI 과정이 성공적으로 끝났습니다 \n Job '${env.JOB_NAME} [${env.BUILD_NUMBER}]' (${env.BUILD_URL})")
        }
        failure {
            slackSend (channel: '#{{슬랙채널}}', color: '#00FF00', message: "빌드가 실패하였습니다 \n ${env.JOB_NAME}앱의 젠킨스 콘솔을 확인해주세요 \n Job '${env.JOB_NAME} [${env.BUILD_NUMBER}]' (${env.BUILD_URL})")
        }
    }
}

파이프라인 성공시 빌드완료 메시지를, 실패시 실패 메시지를 슬랙에 남깁니다

Linkerd 배포시 인증서 지정

ybchoi — Thu, 14 Jul 2022 14:14:03 +0900

linkerd install 명령어로 링커드 설치시 링커드 인증서는 k8s와 마찬가지로 기본 1년으로 자동으로 생성되어 배포 됨

만료되면 교체해야 하므로 아래의 방법으로 10년짜리 유효기간을 가진 trust anchor 를 발행하여 해당 인증서를 이용해 설치를 진행한다

인증서 생성

$ step certificate create root.linkerd.cluster.local ca.crt ca.key \
--profile root-ca --no-password --insecure


$ step certificate create identity.linkerd.cluster.local issuer.crt issuer.key \
--profile intermediate-ca --not-after 87600h --no-password --insecure \
--ca ca.crt --ca-key ca.key

생성된 인증서를 이용하여 linkerd 설치(ha모드 원하지 않으면 --ha제외)

$ linkerd install \
  --set proxyInit.runAsRoot=true \
  --ha \
  --identity-trust-anchors-file ca.crt \
  --identity-issuer-certificate-file issuer.crt \
  --identity-issuer-key-file issuer.key \
  | kubectl apply -f -