아주조코

sudo 권한 부여

uuuhhh — Sat, 28 Jan 2023 18:31:06 +0900

sudo : 일반 사용자가 일시적으로 root 관리자 권한을 얻는 명령어

위 sudo 명령어를 일반 사용자가 사용하기 위한 방법
- /etc/sudoers 파일에 일반 사용자 / 그룹이 등록되어 있어야 한다.

/etc/sudoers 파일은 readonly 속성을 가지고 있어 편집하기 위한 두가지 방법
- sudoers 파일 관리 application 사용 → 추천 (문법 및 적합성 검사도 해줌 !)
  - visudo -f /etc/sudoers
- 편집 권한 변경 및 부여 → 추천 안함 (권한 회수를 깜빡할 수 도 있기 때문 !)
  - chmod u+x /etc/sudoers
  - chmod 640 /etc/sudoers

파일 안에서도 visudo를 권장(?)한다고 말하네여,,

sudoers 파일 하단에 sudo 권한을 부여할 설정을 작성한다.
sudo 명령어를 처음 사용할 시 비밀번호를 입력해줘야함
- 이를 생략할 수 있는 옵션(NOPASSWD) 설정가능

# 특정 사용자에게 sudo 사용 권한 부여
# username ALL=(ALL) ALL
daniel ALL=(ALL) ALL

# 그룹에 포함된 모든 사용자에게 sudo 사용 권한 부여
# %groupname ALL=(ALL) ALL
%student ALL=(ALL) ALL

# 패스워드 생략 설정
# username ALL=(ALL) NOPASSWD: ALL
tom ALL=(ALL) NOPASSWD: ALL
%adult ALL=(ALL) NOPASSWD: ALL

ref.

일반 사용자에게 sudo 권한 부여

ArgoCD Manage Secrets

uuuhhh — Thu, 15 Dec 2022 17:14:16 +0900

Epilogue

DB Pod 매니페스트 파일 정의 다하고..
MySQL 시크릿도 다 정의해주고..
namespace 안에 apply로 적용을 다 한 상태에서..
argoCD로 배포만 하면 되는데..
왜 Sync failed로 인해서 에러가 발생하는 것일까..

에러 로그 탐색 !

유효하지 않는 데이터 에러
- Deployment.spec.template.spec.containers[1]..
위 변수는 다음과 같은 secret을 참조하는 데이터다.

...
- name: MYSQL_USER
        valueFrom:
          secretKeyRef:
            name: mysql-secret
            key: username
...

여기서 시크릿에 대한 문제인 것을 확인하였다.
결론은 시크릿과 매니페스트 데이터 매칭을 제대로 설정하지 않아서 생긴 오류였다.

이슈 해결 후 secret 리소스만 따로 관리하는 것이 마음에 안 들기 시작했다..
github repo에 secret 파일을 같이 올려서 argoCD를 통해 배포 후 관리하면 편하지 않을까?

말도 안 되는 소리..❗️

github와 같은 public한 공간에는 절대 절대 절대로 secret 파일을 올리는 건 안된다.

왜냐하면..❓

공개가 되어선 매우 치명적인 데이터를 숨기고자 생성하고 사용하는 secret 파일을 모두가 볼 수 있는 공간에 업로드한다는 것은 secret의 의미가 퇴색되도록 만드는 것이기 때문이다.

그럼 무슨 방법이..❓

ArgoCD 자체에서 secret을 관리할 수 있는 방법은 없다.
외부 Tools을 사용하는 등.. 다른 솔루션으로 해결해야 한다.
ArgoCD 공식 Doc에서 소개하는 방법 중 제일 간편하고 따라 하기 쉬운 것을 소개하고자 한다.

▪︎ ArgoCD로 Secret 관리하기

그건 바로 바로..
Beatnami의 sealed-secrets 오픈소스를 사용해서 secret을 한 번 더 암호화하는 방법을 소개해본다.

GitHub - bitnami-labs/sealed-secrets: A Kubernetes controller and tool for one-way encrypted Secrets

A Kubernetes controller and tool for one-way encrypted Secrets - GitHub - bitnami-labs/sealed-secrets: A Kubernetes controller and tool for one-way encrypted Secrets

github.com

sealed-secrets은 두 가지 구조로 동작한다.
- cluster-side의 controller / operator
  - seal-secrets-controller
- client-side의 tool
  - kubeseal
동작 프로세스

출처 : https://coffeewhale.com/sealedsecret

client-side의 tool인 kubeseal은 public key를 보유 중이며 k8s secret을 암호화한다.
- 암호화 : Secret → SealedSecret
git repository에 업로드를 하더라도 그 누구도 복호화할 수 없다.
GitOps Operator(e.g. ArgoCD)로 인해 k8s 클러스터로 배포한다.
cluster-side의 controller / operator는 private key를 보유중이며 암호화한 k8s secret을 복호화한다.
- 복호화 : SealedSecret → Secret

▪︎ kubeseal 설치

$ brew install kubeseal

$ helm install sealed-secrets -n kube-system sealed-secrets/sealed-secrets
- namespace는 kube-system에 지정하여 설치해줘야 한다.

⚠️ 주의사항

헬름 차트는 기본적으로 컨트롤러 이름을 sealed-secrets로 설치한다.
kubeseal CLI는 기본적으로 sealed-secrets-controller의 이름을 가진 컨트롤러에 접근한다.

kubeseal에 controller 이름을 명시하지 않았을 경우
- 다음과 같은 에러 발생

kubeseal에서 --controller-name옵션을 통해 CLI에 명시적으로 컨트롤러의 이름을 전달할 수 있다.
- e.g.) $ kubeseal --controller-name sealed-secrets <args>
kubeseal에 controller 이름을 명시해줬을 경우
- 정상적으로 kubeseal 명령 수행

만약 CLI를 통해 kubeseal을 사용할 때 매번 위와 같은 옵션을 사용하지 않으려면?
helm chart를 설치할 때 fullnameOverride=**.. 옵션으로 controller의 이름을 명시하여 설치할 수 있다.
- e.g.) $ helm install sealed-secrets -n kube-system --set-string fullnameOverride=sealed-secrets-controller sealed-secrets/sealed-secrets

▪︎ kubeseal로 암호화

kubeseal을 사용해서 여러 가지 방법으로 암호화가 가능하다.
- 여러 파일 형식 지원 (json, yaml)
- echo를 통해 데이터 하나씩 암호화
- cat을 통해 Secret 오브젝트를 SealedSecret으로 변환
- 등..

‘1234’를 암호화 해보자 !
꼭 지정한 namespace에 해당 secret을 넣어주어야만 복호화가 가능하다.
- data : 1234
- namespace : test-namespace
- secret name : test-secret

$ echo -n 1234 | kubeseal --controller-name sealed-secrets --raw --namespace test-namespace --name test-secret

AgBa27gCAJDNYXYy+0PRHhmm8hBocVbq5tGiojJhehv/eHA....

‘db-secret.yaml’를 ‘db-sealed-secret.yaml’로 암호화 해보자 !
- object : Secret → SealedSecret
- data file : db-secret.yaml → db-sealed-secret.yaml
- namespace : cucumovie-main
- secret name : mysql-secret

$ cat db-secret.yaml | kubeseal --controller-name sealed-secrets --namespace cucumovie-main -oyaml > db-sealed-secret.yaml

$ cat db-sealed-secret.yaml

apiVersion: bitnami.com/v1alpha1
kind: SealedSecret
metadata:
  creationTimestamp: null
  name: mysql-secret
  namespace: cucumovie-main
spec:
  encryptedData:
    host: AgAOGqdmS5HUPkLD9+s6A...
    password: AgBpRqR6scdjQvAs4n...
    root-password: AgCmj/tE2nVK1...
    username: AgBZqHpSItYBRJwXjtM...
  template:
    metadata:
      creationTimestamp: null
      name: mysql-secret
      namespace: cucumovie-main
    type: Opaque

▪︎ SealedSecret Controller로 복호화

Github에 업로드 !

$ git add .
$ git commit -m "add sealed-secret"
$ git push

GitOps Operator(e.g. ArgoCD)로 배포 !
- controller로 sealedsecret을 복호화한 secret을 확인할 수 있다.

해당 파드도 정상적으로 controller로 복호화한 secret을 통해 환경변수를 설정하는 것 확인 !

ref.

Secret Management - Argo CD - Declarative GitOps CD for Kubernetes

How to Use Secrets with GitOps and ArgoCD | Dev House 2021 | Kostis Kapelonis

DB Pod 생성하기

uuuhhh — Thu, 15 Dec 2022 15:51:40 +0900

목표

Kubernetes Cluster에 DB Pod를 띄워보자 !
- MySQL을 사용하는..
- SpringBoot의 백엔드와 연결하기 위해..
먼저 준비물 !
- Deployment
- Secret
- Persistent Volume (PV)
- Persistent Volume Claim (PVC)
위 것들이 왜 필요한지는 직접 매니페스트 파일을 작성하면서 알아보자

▪︎ DB Deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: db-mysql
  labels:
    app: db-mysql
spec:
  replicas: 1
  selector:
    matchLabels:
      app: db-mysql
  template:
    metadata:
      labels:
        app: db-mysql
    spec:
      nodeName: cnp-node-w-1vmd
      containers:
      - name: db-mysql
        image: mysql:8.0.31
        env:
        - name: MYSQL_USER
          valueFrom:
            secretKeyRef:
              name: mysql-secret
              key: username
        - name: MYSQL_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql-secret
              key: password
        - name: MYSQL_ROOT_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql-secret
              key: root-password
        ports:
        - containerPort: 3306
      volumes:
        - name: volume
          persistentVolumeClaim:
            claimName: mysql-pvc

먼저 Deployment를 살펴보면 특별히 봐야 할 두 가지를 확인해 볼 수 있다.
1. spec.template.spec.containers.env
2. spec.template.spec.volumes

1. spec.template.spec.containers.env (secret)

spec.template.spec.containers.env에는 mysql의 비밀번호를 환경 변수로 넣어주는 부분이다.
그러나 이를 github의 public repo에 push를 하게 된다면 치명적인 보안 이슈가 생길 수 있다.

참조 : https://www.padok.fr/en/blog/kubernetes-secrets

이러한 이슈를 방지하기 위해 k8s에는 secret을 지원한다.
MYSQL_ROOT_PASSWORD에 대한 값을 mysql-password의 secret에서 password에 대한 key 값을 가져오며 보안을 향상한다.

2. spec.template.spec.volumes (PV / PVC)

생성한 pod내에 저장소를 사용하며 데이터를 저장할 수 있다.
그러나 언제든지 k8s내의 파드는 죽을 수 있다는 시스템 설계상 DB 파드가 종료된다면 관련 데이터는 모두 없어질 것이다.

참조 : 이미지 클릭

따라서 별개로 관리하는 PV 스토리지를 두며 파드에 직접 연결하지 않고 파드와 PV 사이에 PVC를 두어 요청을 중간에서 처리한다.

▪︎ DB Secret.yaml

apiVersion: v1
kind: Secret
metadata:
  name: mysql-secret
type: Opaque
data:
  username: *******
  password: *******
  root-password: *******
  host: *******

그럼 위에서 열심히 얘기했던 1번에 대한 시크릿을 생성해보자
여기서 중요하게 볼 것은 data.password !
- data 하위에 넣고 싶은 값을 key-value 쌍으로 넣어주면 된다 !
그냥 우리가 사용할 비밀번호를 와다다 적으면 될 것이라고 생각하지만 no no..
secret에는 value 값들을 base64로 인코딩한 값으로 넣어줘야 한다.
- 그럼 어떻게 base64로 인코딩해요?
$ echo -n password | base64의 명령어를 사용하면 된다.
- 예를 들면 password를 base64로 인코딩하면 아래와 같은 결과값을 가진다.

근데 잠깐.. -n 옵션은 뭐죠?
만약 -n 옵션을 주지 않고 인코딩을 하게 된다면..
$ echo password | base64

조금 다른데..?
echo 명령어를 수행하면 자동으로 trailing newline을 삽입한다.
위와 같은 이유로 -n 옵션을 사용해서 trailing newline을 없앤 후에 인코딩을 해야 secret에서 원하는 정상적인 인코딩된 문자열을 얻을 수 있다.

-n 옵션 없이 인코딩한 값으로 키 값을 부여하면 mysql: unknown option ‘–”‘ 오류가 발생한다.

그럼 secret 생성!
- $ kubectl apply -f db-secret.yaml -n cucumovie-main

▪︎ PV.yaml / PVC.yaml

apiVersion: v1
kind: PersistentVolume
metadata:
  name: mysql-pvc
spec:
  capacity:
    storage: 10Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: local-storage
  local:
    path: /volume/pv
  nodeAffinity:
    required:
      nodeSelectorTerms:
        - matchExpressions:
            - key: name
              operator: In
              values:
              - node

PV의 path를 노드의 /volume/pv로 지정한 후 PV 생성 !

PVC

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-pvc
spec:
  storageClassName: local-storage
  resources:
    requests:
      storage: 10Gi
  accessModes:
    - ReadWriteOnce

PVC 생성 !

이제 모든 준비를 다 마쳤으니..
Deployment 생성 !

생성된 DB Pod에 접속

접속한 Pod에서 mysql에 로그인하고 현재 계정이 접근 가능한 데이터베이스 목록 확인
정상적으로 DB Pod가 생성된 것을 확인할 수 있다 !

ref.

쿠버네티스 Web-DB pod 연결하기

Jenkins Front-End Dockerizing

uuuhhh — Thu, 15 Dec 2022 09:22:37 +0900

Epilogue

앞선 Jenkins로 React 빌드를 진행하였다.
빌드 산출물을 배포하기 위해선 Docker Image로 패키징 해야 한다.
Dockerfile을 작성하고 Jenkins로 Dockerizing을 진행해보자!

⚡ Leggo

▪ Nginx 설정 파일

/conf/conf.d/default.conf에 Nginx 설정 파일 필요

server {
    listen 80;

    location / {
        root   /usr/share/nginx/html;

        index  index.html index.htm;
        try_files $uri $uri/ /index.html;

    }

    error_page   500 502 503 504  /50x.html;

    location = /50x.html {
        root   /usr/share/nginx/html;
    }
}

▪ Multi Stage Build

예를 들어 빌드 환경 / 배포 환경을 나눠서 이미지 빌드
필요 없는 환경을 제거하고 최종적으로 필요한 환경만 남는다.
컨테이너 이미지 경량화 가능

FROM node:12.16.2 as builder

...

FROM nginx:latest

...

COPY --from=builder /usr/src/app/build /usr/share/nginx/html

▪ React Application 배포

nginx의 기본 설정을 삭제하고 Application 소스에서 설정한 파일을 복사
소스 코드에 /conf/conf.d 파일이 있어야 함
Jenkins에서 생성한 Application의 빌드 산출물을 nginx의 기본 Sample Application이 사용하던 폴더로 이동

Dockerfile

FROM nginx:latest

RUN rm -rf /etc/nginx/conf.d
COPY conf /etc/nginx

COPY build /usr/share/nginx/html
EXPOSE 80

CMD ["nginx", "-g", "daemon off;"]

Jenkinsfile

pipeline{
    agent {
        kubernetes{
            yamlFile 'KubernetesPod.yaml'
        }
    }

...
 
        stage('Docker Image Build'){
            steps{
                container('docker'){
                    dir('front'){
                        sh "docker build . -t ${dockerHubRegistry}:${currentBuild.number}"
                        sh "docker build . -t ${dockerHubRegistry}:latest"
                    }
                }
            }
            post{
                failure{
                    echo 'Docker image build failure!'
                }
                success{
                    echo 'Docker image build success!'
                }
            }
        }
...

▪ 부록

e.g.) --from=builder
- 앞에서 builder로 지정한 환경에서 파일을 가져와서 최종 이미지에 파일을 추가하는 의미

FROM node:12.16.2 as builder

...

FROM nginx:latest

...

COPY --from=builder /usr/src/app/build /usr/share/nginx/html

ref.

[Devops] React 프로젝트 Docker이미지 만들기(Dockerizing)

Jenkins Front-End React Build

uuuhhh — Thu, 15 Dec 2022 09:03:22 +0900

Epilogue

Jenkins로 React 빌드를 해보자 !

⚡ Leggo

▪ React Build

개발 모드로 프로그램 실행
- $ npm start

실제 배포 시 빌드 명령어
- $ npm run build
- 배포 환경에서 사용할 파일들 압축 형태로 제공
- index.html 최적화하여 배포

테스트용으로 serve라고 하는 간단한(한 번만 사용하는) 서버를 npm을 통해 설치하는 명령어

npm insatll -g serve
npx serve -s build // 한번만 실행

현재 개발 단계에서 [ Front-End → Back-End ] 요청 타겟팅 설정 파일 path check
- Movie-project/back/src/main/movie-project/src/setProxy.ts

webpack을 사용하지 않고 $ npm run build 빌드시 나오는 산출물
- ./build 디렉토리 안에 있는 빌드 산출물 사용

+ ls -al build  
total 20  
drwxr-xr-x 3 node node 4096 Nov 23 14:26 .  
drwxr-xr-x 7 node node 4096 Nov 23 14:26 ..  
-rw-r--r-- 1 node node  218 Nov 23 14:26 asset-manifest.json  
-rw-r--r-- 1 node node  315 Nov 23 14:26 index.html  
drwxr-xr-x 3 node node 4096 Nov 23 14:26 static

Build WorkFlow
- Jenkins → build → 빌드 산출물 → + Nginx → Dockerfile
Jenkins에서 빌드? ✅
- 빌드시 Jenkins의 빌드 서버의 리소스 사용이 적합하다고 판단
Dockerfile에서 빌드? ❌
- 서버에서 도커 이미지를 통해 매번 굳이 빌드를 행해야 할 필요가 있을까?
- 서버 리소스를 빌드시 사용하는 것이 낭비라고 판단

Jenkinsfile

...

stage('React Build'){
            steps{
                dir('front'){
                    sh '''
                        npm install
                        npm run build
                    '''
                }
            }
            post{
                failure{
                    echo 'React build failure!'
                }
                success{
                    echo 'React build success!'
                }
            }
        }
           
...

ref.

[초보자] React 설치부터 배포까지의 과정을 정리 | DevelopersIO

ArgoCD Application Create

uuuhhh — Wed, 14 Dec 2022 10:48:15 +0900

Epilogue

CI 파이프라인에서 Kubernetes Deployment Manifest 파일의 도커 이미지 태그 수정을 완료하였다.
이제는 수정된 버전의 도커 이미지를 가지고 새로 업그레이드나 배포를 해야할 차례..!

위 과정에서 GitOps의 Operation 툴인 ArgoCD를 사용하고자 하는데..
ArgoCD로 Kubernetes 클러스터 내의 리소스들을 관리하기 위해서는 사전에 Application을 만들어줘야한다.

콘솔로 세팅
YAML 파일로 세팅

두 가지 세팅 방법이 있는데
우리는 아무래도 선언적으로 설정하는게 편하다보니 ~~(맞죠?)~~ ..
YAML 파일 작성을 통해 Application을 만들어 보고자 한다 !

⚡ Leggo

Edit as YAML

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: test-back
spec:
  project: default
  destination:
    namespace: back-end
    server: <https://kubernetes.default.svc>
  source:
    repoURL: <https://github.com/Cucumber-web/Test-Kubernetes>
    path: .
    targetRevision: main
  syncPolicy:
    syncOptions:
      - CreateNamespace=true
    automated:
      selfHeal: true
      prune: true

Application Name
- 배포할 애플리케이션 이름
- 소문자, 숫자, . , -만 허용
Project
- ArgoCD 내 애플리케이션 그룹
SYNC POLICY
- Git 변동사항을 자동으로 반영 (Automatic)
- Git 변동사항을 수동으로 반영 (Manual)
Repository URL
- Git or Helm 저장소 URL
Revision
- Git의 어떤 Revision을 보고 있는지
- e.g.) Head, master, main ..
Path
- Repo 내 변경 사항을 관리할 매니페스트 파일이 위치한 경로
- root일 경우 . 로 표기
Cluster URL
- 배포 대상 Cluster 지정
- https://kubernetes.default.svc
Namespace
- Cluster 내 배포할 Namespace 지정
DIRECTORY RECURSE
- path 하위 경로의 매니페스트 파일 변동 사항 체크 여부

현재 application 정보 및 로그 상태 확인
- $ argocd app get [application-name]

[ Back-End ] 배포 Test

[ Back-End + Front-End ] 배포 Test
- 여기서 사전에 없는 namespace 지정시 잘 생성하는 것도 확인

현재 3분간 Sync가 이뤄지는 것으로 보임
- 최악의 경우 3분을 대기
- 이를 위해 ArgoCD도 webhook을 사용 → 나의 임무이로다..

Git Webhook Configuration - Argo CD - Declarative GitOps CD for Kubernetes

Git Webhook Configuration Overview Argo CD polls Git repositories every three minutes to detect changes to the manifests. To eliminate this delay from polling, the API server can be configured to receive webhook events. Argo CD supports Git webhook notific

argo-cd.readthedocs.io

매번 이렇게 Application Create는 매우 귀찮음
- 전에는 App of App 배포 전략이 존재
  - 대장 Application이 존재하여 하위 Application을 관리하는 전략
- 요즘은 ApplicationSet 지원을 통해 해결한다고 함

ref.

ArgoCD 선언적으로 이용해나가기 - Helm, App of App

Declarative Setup - Argo CD - Declarative GitOps CD for Kubernetes

Jenkins Kubernetes Manifest Deploy

uuuhhh — Wed, 14 Dec 2022 09:54:58 +0900

Epilogue

현재 프로젝트에 적용할 CD 파이프라인 소개

도커 이미지 빌드
도커 이미지 Docker Hub Registry에 Push
Kubernetes Deployment Manifest 파일에 도커 이미지 태그 수정

ArgoCD가 수정 사항을 감지하여 새로 Push 된 Docker Image를 가지고 배포를 진행한다.
이로써 GitOps 환경이 구축이 된다.

진짜 역대급으로 힘들었고 시간 많이 잡아먹었던 파이프라인 Stage
- 왜냐고 물으신다면 이 빌드 숫자를 보아하니..^^

⚡ Leggo

Jenkinsfile

environment{
        ...
        gitToken = credentials('github-repo-access-token')
    }

...

stage('Kubernetes Manifest Update'){
            steps{
                git branch: 'main',
                    url: '<https://github.com/Cucumber-web/Test-Kubernetes.git>',
                    credentialsId: 'github-repo-access-token'
                
                sh '''
                    git config --global user.email "uh9222959@gmail.com"
                    git config --global user.name "UhyeongJo"
                '''

                sh "sed -i 's/cucumber-back:.*\\$/cucumber-back:${currentBuild.number}/g' back_deployment.yaml"
                sh "git add back_deployment.yaml"
                sh "git commit -m '[Update] test-back ${currentBuild.number} image versioning'"
                
                sshagent(credentials: ['****************']){
                    sh 'git remote set-url origin '
                    sh "git push origin main"
                }

                /*
                sh '''
                    git config --global user.email "{e-mail-***}"
                    git config --global user.name "{username-***}"
                '''
                sh "sed -i 's/cucumber-back:.*\\$/cucumber-back:${currentBuild.number}/g' back_deployment.yaml"
                sh "git add back_deployment.yaml"
                sh "git commit -m '[Update] test-back ${currentBuild.number} image versioning'"
                sh "git remote set-url origin "
                sh "git push --set-upstream origin main"
                */
            }
        }

▪ 이건 또 하나의 삽질 경험기

젠킨스 컨테이너 접속
- 젠킨스 홈 디렉토리에 들어가서 공개-비밀키 쌍을 생성하고 Github의 Secret과 Jenkins의 Credentials로 등록을 해줘야 했다.
- $ kubectl exec -it [jenkins-pod-name] /bin/bash -n [jenkins-namespace]

젠킨스 홈 디렉토리에 공개-비밀키 쌍 생성 과정
- $ cd /var/jenkins-home
- $ mkdir .ssh
- $ cd .ssh
- $ ssh-keygen -t rsa -C [github e-mail]
- Enter + Enter + Enter ,,
- id_rsa (private key) → COPY → jenkins credential
- id_rsa.pub (public key) → COPY → github secret

ssh agent

위에서 등록한 Jenkins ssh private key를 가지고 사용 및 활용할 수 있는 agent

...
[ssh-agent] Using credentials ***-key
[ssh-agent] Looking for ssh-agent implementation...
[ssh-agent] Exec ssh-agent (binary ssh-agent on a remote machine)
$ ssh-agent
...

credentials에 username이 아니라 ID를 입력해야 함

SSH Agent

This plugin allows you to provide SSH credentials to builds via a ssh-agent in Jenkins.

plugins.jenkins.io

Environment Credential Secure
- sh "git remote set-url origin <https://${gitToken}@github.com/Cucumber-web/Test-Kubernetes.git>"
- 현재 Jenkins에서 연결되어 있는 원격 Repository의 주소를 변경하기 위한 명령인데 자꾸 자격 증명 에러가 발생..
  - fatal: could not read Username for '<https://github.com>': No such device or address
  - Host key verification failed.
  - … 아주 다양..
- Github Token을 통하여 이를 해결하였다.
- 그러나 보안 상 Github Token이 환경 변수로 사용하지만 명령어로 유출될 가능성이 있다는 경고 발생

Warning: A secret was passed to "sh" using Groovy String interpolation, which is insecure.
		 Affected argument(s) used the following variable(s): [gitToken, gitToken_PSW]

해결법은 간단하다.
큰따옴표 → 작은따옴표
“sh ~~~ “ → ‘sh ~~~ ‘

Using a Jenkinsfile

For more advanced usage with Scripted Pipeline, the example above node is a crucial first step as it allocates an executor and workspace for the Pipeline. In essence, without node, a Pipeline cannot do any work! From within node, the first order of busines

www.jenkins.io

성공 ~

빌드 성공 !

로그에서도 반가운 SUCCESS !

새로운 도커 이미지 Push !

Kubernetes Deployment Manifest 파일의 새로운 도커 이미지 태그 수정 확인 !

Jenkins Docker Image Push

uuuhhh — Wed, 14 Dec 2022 09:12:02 +0900

Epilogue

험난한 과정을 거친 후 도커 이미지 빌드 파이프라인을 성공하였다 !
이제는 빌드한 이미지를 가지고 도커 허브 레지스트리에 Push를 해보자 ~

⚡ Leggo

Jenkinsfile

...

stage('Docker Image Push'){
            steps{
                container('docker'){
                    withDockerRegistry([credentialsId: 'docker-access-key', url: "" ]){
                        sh "docker push ${dockerHubRegistry}:${currentBuild.number}"
                        sh "docker push ${dockerHubRegistry}:latest"
                        
                        /* Wait Uploading */
                        sleep 10

                        sh "docker rmi ${dockerHubRegistry}:${currentBuild.number}"
                        sh "docker rmi ${dockerHubRegistry}:latest"
                    }
                }
            }
            post{
                failure{
                    echo 'Docker Image Push failure!'
                }
                success{
                    echo 'Docker Image Push Success!'
                }
            }
        }

...

credentialsId: 'docker-access-key'
- 도커 허브 레지스트리 계정 정보는 젠킨스 시크릿 인증 키로 설정하였다.

currentBuild.number
- 현재 빌드 넘버를 표기해주는 변수
- Jenkins에서 제공
- 배포 자동화 → 매우 매우 중요한 요소

성공 ! ⭐️

허브에도 정상 push !✨

Jenkins Back-End Dockerizing

uuuhhh — Tue, 13 Dec 2022 10:29:11 +0900

Epilogue

역시나 험난한 트러블 슈팅기

도커가 없다고 하는 거 같아요..

⚡ Leggo

플러그인 설치
- Docker
- Docker Pipeline
실패..

uname -a 를 통해 OS 정보 확인

+ uname -a

Linux default-hp930 5.4.0-99-generic #112-Ubuntu SMP Thu Feb 3 13:50:55 UTC 2022 x86_64 GNU/Linux

도커 설치 스크립트 추가

sudo apt-get update
sudo apt-get install docker.io
sudo ln -sf /usr/bin/docker.io /usr/local/bin/docker

agent pod에서 sudo: not found 문제로 실패

해결책

apt-get update && apt-get -y install sudo

이지만 매번 agent pod가 띄워질 때마다 패키지를 업데이트하고 설치하는 것이 빌드 파이프라인에 시간이 많이 소비될 것이 우려됨

다른 해결책을 찾다가 저번 Gradle Build에서 Custom Agent를 실패했던 것이 떠올랐다.

현재 Agent pod에 도커가 없으니
‘Docker Container를 Custom해서 Agent에 넣어주면 Image Build가 되지 않을까’
라고 생각하게 되었다.

Agent Docker Container

spec:
  containers:
  - name: docker
    image: docker:latest
    command:
    - cat
    tty: true
    volumeMounts:
    - mountPath: /var/run/docker.sock
      name: docker-sock
  volumes:
  - name: docker-sock
    hostPath:
      path: /var/run/docker.sock

Dockerfile

FROM openjdk:11

ARG JAR_FILE_PATH=./*.jar
COPY ${JAR_FILE_PATH} ./app.jar

EXPOSE 8080
ENTRYPOINT ["java","-jar","app.jar"]

Jenkinsfile

pipeline{
    agent {
        kubernetes{
            yamlFile 'KubernetesPod.yaml'
        }
    }

...

stage('Docker Image Build'){
            steps{
                container('docker'){
                    sh "cp demo/build/libs/demo-0.0.1-SNAPSHOT.jar ./"
                    sh "cp demo/Dockerfile ./"
                    sh "docker build . -t ${dockerHubRegistry}:${currentBuild.number}"
                    sh "docker build . -t ${dockerHubRegistry}:latest"
                }
            }

...

빌드 시작 !
- 성공 !!!!!!!!!

+ cp demo/build/libs/demo-0.0.1-SNAPSHOT.jar ./
[Pipeline] sh
+ cp demo/Dockerfile ./
[Pipeline] sh
+ docker build . -t uh2959/cucumber-back:51
Sending build context to Docker daemon  35.92MB

Step 1/5 : FROM openjdk:11
11: Pulling from library/openjdk
001c52e26ad5: Pulling fs layer
...
66223a710990: Pulling fs layer
db38d58ec8ab: Pulling fs layer
d85151f15b66: Waiting
...
9daef329d350: Waiting
d9d4b9b6e964: Verifying Checksum
d9d4b9b6e964: Download complete
2068746827ec: Verifying Checksum
...
db38d58ec8ab: Verifying Checksum
db38d58ec8ab: Download complete
001c52e26ad5: Pull complete
...
db38d58ec8ab: Pull complete
Digest: sha256:99bac5bf83633e3c7399aed725c8415e7b569b54e03e4599e580fc9cdb7c21ab
Status: Downloaded newer image for openjdk:11
 ---> 47a932d998b7
Step 2/5 : ARG JAR_FILE_PATH=./*.jar
 ---> Running in 208235ed04bf
...
Successfully built d9934a7196a4
Successfully tagged uh2959/cucumber-back:latest
[Pipeline] }
[Pipeline] // container
Post stage
[Pipeline] echo
Docker image build success!
[Pipeline] }
...
[Pipeline] End of Pipeline
Finished: SUCCESS

ref.

How to Use Kubernetes Pods As Jenkins Agents

Docker in Docker with Jenkins Pod on Kubernetes

Jenkins Back-End Gradle Build

uuuhhh — Tue, 13 Dec 2022 09:54:43 +0900

Epilogue

백엔드 Gradle 빌드 시 매우 많은 트러블 이슈 발생
- Gradle 빌드 명령어 이슈..
  - Test 제외 빌드 명령어
  - ./gradlew build --exclude-task -test

Java Build 과정 -> 여기서 Test 과정을 제외

Gradle 빌드 세팅 파일 찾지 못하는 이슈..
Gradle 권한 오류..
etc..
그중에서 제일 애를 먹었던 이슈를 해결했던 과정을 소개하고자 한다.

⚡ Leggo

Jenkinsfile

...

stage('Gradle Jar Build'){
            steps{
                dir('back'){
                    sh '''
                        chmod +x gradlew
                        ./gradlew build --exclude-task test
                    '''
                }
            }
            post{
                failure{
                    echo 'Gradle jar build failure!'
                }
                success{
                    echo 'Gradle jar build success!'
                }
            }
        }
        
...

'Gradle build daemon disappeard unexpectedly (it may have been killed or may have crashed)' 에러 문구 발생

PyeongHo Factory

즐거운 공장

pyeongho.github.io

위 블로그 글처럼 Gradle 옵션에 no-daemon 추가하여도 똑같은 에러 발생으로 Agent Pod의 스펙이 부족한가 의심됨

현재 Agent pod의 스펙은 다음과 같이 로그에 나타난다.

빌드 로그에서 빌드 데몬이 메모리가 494.9 MiB를 사용한다는 것(?)으로 유추할 수 있는 로그를 확인하였다.
- 이를 통해 Agent Pod의 스펙이 부족함으로 나타나는 에러 발생으로 생각이 굳혀져 갔다.

현재 젠킨스를 Helm으로 Kubernetes에 구축한 환경이라 Jenkins 내 시스템 설정에서 Agent 파드를 설정하는 파트가 존재하지 않았다..
방법을 강구하던 도중 Jenkins Helm Chart Value 파일을 살펴보았다.

[agent.resources] 필드가 존재하였다 !
- 바로 메모리 두 배 스펙업 고고링
- helm upgrade jenkins jenkins/jenkins -f jenkins-values.yaml -n jenkins

agent:
  enabled: true
  defaultsProviderTemplate: ""
  # URL for connecting to the Jenkins contoller
  jenkinsUrl:
  # connect to the specified host and port, instead of connecting directly to the Jenkins controller
  jenkinsTunnel:
  kubernetesConnectTimeout: 5
  kubernetesReadTimeout: 15
  maxRequestsPerHostStr: "32"
  namespace:
  image: "jenkins/inbound-agent"
  tag: "4.11.2-4"
  workingDir: "/home/jenkins/agent"
  nodeUsageMode: "NORMAL"
  customJenkinsLabels: []
  # name of the secret to be used for image pulling
  imagePullSecretName:
  componentName: "jenkins-agent"
  websocket: false
  privileged: false
  runAsUser:
  runAsGroup:
  hostNetworking: false
  resources:
    requests:
      cpu: "512m"
      memory: "1024Mi"
    limits:
      cpu: "512m"
      memory: "1024Mi"

정의한 스펙이 적용된 것을 확인

아시죠 ?
- 뭔가 감이 오잖아요
- 될 것 같은 이 기분..
- 에러 로그랑 그냥 시작부터 다르다는 것을..
- 성공 !!!!!!!

참고
Back-End JAR file PATH
- /home/jenkins/agent/workspace/test-backend/demo/build/libs/demo-0.0.1-SNAPSHOT.jar
- java -jar demo-0.0.1-SNAPSHOT.jar

Jenkins Webhook 연동

uuuhhh — Mon, 12 Dec 2022 09:41:16 +0900

목표

Github의 Webhook을 구성하고 Jenkins와 연동 후에 Push Event 발생 시 자동으로 빌드가 진행되도록 해보자 !

▪ Github Webhook 구성

Github Access Token 생성

Github Repository - Setting - Webhooks - Add Webhook

Payload URL
- 젠킨스 URL + /github-webhook/
- 외부에서 접근 가능한 도메인으로만 동작 가능 → ngrok 서비스 이용
- e.g.) http://jenkins.com/github-webhook/
Content Type
- application/json

▪ Jenkins Credential 등록 및 관리

Jenkins - Manage Credentials

Credential 등록

Username
- Github Username 입력
Password
- Github Access Token 입력

생성 완료 !

▪ Jenkins Pipeline 프로젝트 구성

Pipeline 프로젝트 생성

Push Event를 감지할 깃허브 레포 정보 입력
- Github project 체크
- GitHub hook trigger for GITScm polling 체크

Declarative 방식으로 파이프라인 작성
- agent
  - pipeline 최상단에 위치하며 특정 job들을 수행할 agent
  - 대표적으로 node, docker, kubernetes를 parameter로 포함
- stages
  - 해당 pipeline이 동작할 때, 실행되는 단계를 의미
  - 하나 이상의 stage를 정의
  - stage 내부적으로 steps를 정의
- environment
  - pipeline 내부에서 key-value 형태로 사용할 수 있는 환경 변수
- parameters
  - pipeline 내부에서 특정 노드, 컨테이너를 실행시킬 때 변수를 제공해야 할 경우 사용

pipeline {
    agent ansy
    stages {
        stage('Checkout') {
            steps {
                git branch: 'main',
                    credentialsId: 'github-repo-access-token',
                    url: '<https://github.com/Cucumber-web/Test-Webhook.git>'
            }
        }
    }
}

Webhook 트리거를 통해 빌드 작업을 자동화하기 위해서는 최초 빌드를 실행시켜줘야 한다.

최초 빌드 성공 !

▪ Github Webhook Trigger 발생 후 빌드 자동화 작업

앞서 설정한 레포에 간단하게 push event를 발생시켜보자

자동으로 빌드가 시작된다 !!!!

파드 로그를 살펴보면 Github Repo에서 PushEvent를 받아온 후
- 빌드 agent 파드를 생성 !
- 빌드 작업을 마치고 !
- 빌드 agent 파드를 종료하고 삭제 !

ref.

젠킨스(Jenkins) GitHub Webhooks 연동

Pipeline Syntax

ArgoCD Helm 설치 & 테스트

uuuhhh — Sat, 10 Dec 2022 15:40:49 +0900

▪︎ ArgoCD 설치

helm repo 받기

$ k create namespace argocd

$ helm repo add argo <https://argoproj.github.io/argo-helm>

argocd 설정 파일 받기

$ helm show values argo/argo-cd > argocd-values.yaml

helm으로 argocd 설치

$ helm install argocd argo/argo-cd -n argocd

그런데 만들고 보니깐 service도 로드밸런서 타입으로 만들고 싶고.. 리소스도 조정하고 싶은데..
다시 갈아 엎어보자..!
그리고 계속 argo-server pod이 CrashLoopBack 에러로 다운되는 것을 확인

$ helm uninstall argocd -n argocd
These resources were kept due to the resource policy:
[CustomResourceDefinition] applications.argoproj.io
[CustomResourceDefinition] applicationsets.argoproj.io
[CustomResourceDefinition] appprojects.argoproj.io

release "argocd" uninstalled

$ helm install argocd argo/argo-cd -n argocd \\
> --set server.service.type=LoadBalancer

NAME: argocd
LAST DEPLOYED: Sat Nov  5 15:52:55 2022
NAMESPACE: argocd
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
In order to access the server UI you have the following options:

1. kubectl port-forward service/argocd-server -n argocd 8080:443

    and then open the browser on  and accept the certificate

2. enable ingress in the values file `server.ingress.enabled` and either
      - Add the annotation for ssl passthrough: <https://argo-cd.readthedocs.io/en/stable/operator-manual/ingress/#option-1-ssl-passthrough>
      - Set the `configs.params."server.insecure"` in the values file and terminate SSL at your ingress: <https://argo-cd.readthedocs.io/en/stable/operator-manual/ingress/#option-2-multiple-ingress-objects-and-hosts>

After reaching the UI the first time you can login with username: admin and the random password generated during the installation. You can find the password by running:

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

(You should delete the initial secret afterwards as suggested by the Getting Started Guide: <https://argo-cd.readthedocs.io/en/stable/getting_started/#4-login-using-the-cli>)

설치 완료 !

근데 보이시나요 ? 불편해 보이는 것이..
- argocd-repo-server-*** → CrashLoopBackOff

트러블 슈팅

argo-repo-server issue: gpg ... --gen-key failed exit status 2 · Issue #9809 · argoproj/argo-cd

Checklist: I've searched in the docs and FAQ for my answer: https://bit.ly/argocd-faq. I've included steps to reproduce the bug. I've pasted the output of argocd version. Describe the b...

github.com

argocd-repo-server fails to start · Issue #1471 · argoproj/argo-helm

Describe the bug argocd-repo-server-c784cd67c-qkv5x 0/1 CrashLoopBackOff $ kubectl logs -n argocd argocd-repo-server-c784cd67c-qkv5x time="2022-09-21T07:44:34Z" level=info msg="Gener...

github.com

GnuPG verification - Argo CD - Declarative GitOps CD for Kubernetes

GnuPG signature verification Overview As of v1.7 it is possible to configure ArgoCD to only sync against commits that are signed in Git using GnuPG. Signature verification is configured on project level. If a project is configured to enforce signature veri

argo-cd.readthedocs.io

특정 버전에 나타나는 비슷한 이슈가 있었다.
configs.gpgKeys를 통해 잘못된 사용자 지정 GPG 키를 키링으로 가져오는 것에 대한 이슈라고 나온다.
- 솔직히 정확하게 관련 이슈를 분석하진 못했지만 해결법을 참고하는 데는 도움이 되었다.

argocd-repo-server Deployment 매니페스트 수정 및 적용
- spec.template.spec.seccomProfile.type 부분을 삭제하였다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: argocd-repo-server
spec:
  template:
    spec:
      securityContext:
      ############삭제##########
        seccompProfile:
          type: RuntimeDefault
      #########################

정상 동작 확인 !

▪︎ ArgoCD 실행

check admin passwd

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

console login

성공 !

argocd cli 설치

$ brew install argocd

$ argocd version

argocd: v2.5.1+504da42.dirty
  BuildDate: 2022-11-01T23:23:38Z
  GitCommit: 504da424c2c9bb91d7fb2ebf3ae72162e7a5a5be
  GitTreeState: dirty
  GoVersion: go1.19.3
  Compiler: gc
  Platform: darwin/arm64
FATA[0000] Argo CD server address unspecified

argocd login
- login을 안 하고 argocd CLI 명령어 입력 시 다음과 같은 에러 발생
- FATA[0000] rpc error: code = Unauthenticated desc = invalid session: Token is expired

$ argocd login argocd-argocd-server-81f92-13865802-c00c18872b20.kr.lb.naverncp.com

WARNING: server certificate had error: x509: “Argo CD” certificate is not trusted. Proceed insecurely (y/n)? y
Username: admin
Password:
'admin:login' logged in successfully
Context 'argocd-argocd-server-81f92-13865802-c00c18872b20.kr.lb.naverncp.com' updated

$ argocd version

argocd: v2.5.1+504da42.dirty
  BuildDate: 2022-11-01T23:23:38Z
  GitCommit: 504da424c2c9bb91d7fb2ebf3ae72162e7a5a5be
  GitTreeState: dirty
  GoVersion: go1.19.3
  Compiler: gc
  Platform: darwin/arm64
argocd-server: v2.5.1+504da42
  BuildDate: 2022-11-01T21:14:30Z
  GitCommit: 504da424c2c9bb91d7fb2ebf3ae72162e7a5a5be
  GitTreeState: clean
  GoVersion: go1.18.8
  Compiler: gc
  Platform: linux/amd64
  Kustomize Version: v4.5.7 2022-08-02T16:35:54Z
  Helm Version: v3.10.1+g9f88ccb
  Kubectl Version: v0.24.2
  Jsonnet Version: v0.18.0

password 바꾸기

$ argocd account update-password

*** Enter password of currently logged in user (admin):
*** Enter new password for user admin:
*** Confirm new password for user admin:
Password updated
Context 'argocd-argocd-server-81f92-13865802-c00c18872b20.kr.lb.naverncp.com' updated

▪︎ Sample Application으로 ArgoCD 동작 확인

Helm으로 Sample Application 생성

$ argocd app create helm-guestbook --repo <https://github.com/UhyeongJo/argocd-example-apps.git> --path helm-guestbook --dest-server <https://kubernetes.default.svc> --dest-namespace argocd

application 'helm-guestbook' created

아직 Github에서 애플리케이션의 helm 차트를 검색하고 생성하였지만 Kubernetes 리소스랑 동기화를 하지 않았으므로 OutOfSync 상태 !

Argocd CLI를 사용해서 동기화하는 법도 있지만 콘솔 창을 활용해서 동기화를 시도해보겠다.
- $ argocd app sync helm-guestbook
Synchronize !

동기화 성공 !

포트 포워딩을 통해 guestbook 서비스에 접속 !
- 8080은 젠킨스가 쓰고 있어서..ㅎㅎ

$ kubectl port-forward svc/helm-guestbook 9090:80

다른 버전의 이미지를 선언하여 GitOps를 활용한 Application 업데이트를 해보자
- 현재 지원하는 이미지 버전은 해당 GCR에서 확인 가능하다.

이미지 버전 태그 변경 후 Push

동기화를 해야겠죠 ?

→ Sync in progress…

→ Sync Done !

잘 적용이 되었는지 확인해야겠죠?
- 빤딱 빤딱 빛나는 로고로 바뀐 버전이 잘 적용된 것을 확인 !

ref.

How to Deploy to Kubernetes using Argo CD and GitOps | DigitalOcean

Jenkins 환경 설정 및 빌드 테스트

uuuhhh — Fri, 9 Dec 2022 09:35:26 +0900

목표

젠킨스를 설치했으니 필요한 환경설정 구성 및 빌드 테스트를 진행해보고자 한다 !

⚡ Leggo

필요한 플러그인 설치 및 확인
- Kubernetes, GitLab, Webhook..

웬만한 사전 설정은 Helm 파일을 통해 미리 구성이 된 상태인 것 같아 딱히 만질 것은 보이지 않았다.
일단 하나는 기억하면 좋을 것이 있어 가져와 보았다.
- # of executors
- 동시에 배포 가능한 스레드 수를 의미하며 ‘0’은 동시에 여러 배포가 진행되지 않도록 하는 설정이다.

테스트 빌드 스크립트를 작성하여 빌드 잡을 만들어보자

Pipeline을 선택해준다.
- FreeStyle : Jenkins 자체 GUI를 활용해서 Flow 정의
  - 장점 : 쉽게 접근 가능
  - 단점 : 제한적인 커스터마이징
- Pipeline : 코드를 통해 연속적인 이벤트 혹은 Job의 그룹 정의
  - 장점 : 폭이 넓은 커스터마이징 / 병렬적인 처리 가능
  - 단점 : 어려움

빌드 테스트 스크립트

podTemplate(label: 'builder',
            containers: [
                containerTemplate(name: 'gradle', image: 'gradle:5.6-jdk8', command: 'cat', ttyEnabled: true),
            ]) {
    node('builder') {
        stage('Build') {
            container('gradle') {
                sh "echo pipeline test"
            }
        }
    }
}

빌드 스크립트 작성 및 설정

빌드 시작

빌드 잡 성공 !

콘솔을 통해 성공 확인

K8s Pod 이벤트 로그를 확인해보니 정상적으로 빌드 Agent 파드가 생성되었다가 종료되는 것을 확인 !

ref.

[Kubernetes - CI/CD] Customized Jenkins 제작과 활용 - 1/2

쿠버네티스 시작하기(7) - CI/CD 파이프라인 만들기(1/3) - 쿠버네티스 클러스터에 jenkins 설치 및 설정

Jenkins Helm 설치

uuuhhh — Fri, 9 Dec 2022 09:25:50 +0900

목표

Helm을 사용해서 Jenkins를 Kubernetes 클러스터 환경에 구축해보자 !

⚡ Leggo

Helm 설치 for Mac OS

$ brew install helm

helm repo 추가하기

$ helm repo add jenkins <https://charts.jenkins.io>
$ helm repo update

jenkins 설정 파일인 values.yaml 받기

$ helm show values jenkins/jenkins > jenkins-values.yaml

jenkins namespace 생성 후 jenkins chart 설치

# Helm 3
$ helm install [RELEASE_NAME] jenkins/jenkins [flags]

$ kubectl create namespace jenkins
$ helm install jenkins jenkins/jenkins -f jenkins-values.yaml -n jenkins

비밀 번호 확인

$ helm status jenkins -n jenkins

...

$ kubectl exec --namespace jenkins -it svc/jenkins -c jenkins -- /bin/cat /run/secrets/additional/chart-admin-password && echo

...

외부에서 jenkins dashboard에 접근하기 위해 kubenetes service에 포트 포워딩을 사용한다.

$ k port-forward svc/jenkins 8080:8080 -n jenkins

Forwarding from 127.0.0.1:8080 -> 8080
Forwarding from [::1]:8080 -> 8080
Handling connection for 8080
Handling connection for 8080
...

접속
- 127.0.0.1:8080

Account
- id : admin
- pwd : ******** → 변경 완료
로그인 성공

지금은 클러스터가 private 환경이어서 로컬에서만 접속 가능하다.
외부에서 jenkins에 접근을 위해 service 타입을 모두 loadbalancer로 변경해주었다 !

먼저 values.yaml 파일 변경 !
serviceType: ClusterIP → LoadBalancer

변경 사항 적용 !

$ helm upgrade jenkins jenkins/jenkins -f jenkins-values.yaml -n jenkins

성공 !
- REVISION = Release 횟수

EXTERNAL-IP 발급 성공 !

접속도 좋구만요 !

ref.

https://github.com/jenkinsci/helm-charts/tree/main/charts/jenkins

Vi vs. Vim

uuuhhh — Thu, 1 Dec 2022 11:13:51 +0900

▪ Vi ?

Vi (Visual Editor) : 유닉스(UNIX) 계열 운영체제의 오픈소스 문서 편집기

한 줄씩 편집하는 줄 단위 편집기(line editor)가 아닌 한 화면을 편집하는 비주얼 에디터(visual editor)

모드
- 일반 모드
  - 위, 아래, 왼쪽, 오른쪽 → K, J, H, L
- 입력 모드
  - i (현재 커서 위치)
  - a (현재 커서 한 칸 뒤)
  - o (한 줄 추가 후)
  - 위, 아래, 왼쪽, 오른쪽 → Alt + ( K, J, H, L )
- 명령 모드
  - :w (파일 저장)
  - :q (vi 종료 / :q! 강제 종료)
  - :wq (저장 후 종료)

▪ Vi vs. Vim

Vim (vi imitation) → Vim (vi improved)

vi와 높은 호환성을 가지며 다양한 기능 + 플러그인 지원

다양한 기능
- 파일의 완성, 비교, 병합(vimdiff), 통합된 도움말 시스템, 확장된 정규 표현식, 플러그인 지원을 포함한 스크립트 언어, 그래픽 사용자 인터페이스(gvim), 마우스 상호작용(GUI와 함께/GUI 없이), 세션 상태 보존, 맞춤법 검사, 수직/수평 탭 창, 유니코드 및 기타 다언어 지원, 문법 강조, 세션 경유 명령, 검색 및 커서 위치 History, 시각 모드 ~~~~~ …
- 암튼 엄청 많이 확장됨
- 출처 - 위키피디아

▪ Why Vi ?

커서 이동을 비롯하여 대부분의 편집 명령어가 키보드 중심에 몰려있음
- 마우스를 이용하지 않겠다는 포부

타 편집기에 비해 손동작이나 타수가 크게 줄어든다.
- 여러 매크로 키 조합으로 다양한 작업 수행

서버 관리 작업을 수행할 경우 따로 에디터 사용보다는 터미널 상에서 작업이 용이

초기 모드가 편집 모드로 '편집' 하면서 시작하는 것을 전제하고 만들어져 있는 강력한 편집기의 기능 수행
- 장점이자 단점..

ref.

https://namu.wiki/w/vi

리눅스 패키지 시스템

uuuhhh — Thu, 1 Dec 2022 11:03:51 +0900

▪︎ 리눅스 패키지

리눅스 패키지 (Linux Package) : 소프트웨어를 실행하는데 필요한 파일들이 담겨 있는 설치 파일

소스 패키지 (Source Package)
- . tgz (source code archives)
- 소스 코드가 들어있는 패키지
- 컴파일을 통해 바이너리 파일로 만들어야 실행 가능
- 장점
  - 소스 코드 수정을 통해 소프트웨어 커스텀 가능
- 단점
  - 컴파일 작업으로 인한 설치 소요 시간 증가 / 컴파일 과정에서 에러 발생 가능성 존재

바이너리 패키지 (Binary Package)
- *. deb (Debian) / *. rpm (Red Hat)
- 이미 성공적으로 컴파일이 끝나 응용 프로그램, 라이브러리 등이 들어있는 바이너리 파일 패키지
- 장점
  - 이미 컴파일된 패키지이므로 설치 소요 시간 단축 / 에러 발생 가능성 감소
- 단점
  - 컴파일 된 환경과 설치를 진행할 로컬 컴퓨터상 환경이 다름으로써 이슈 발생 가능성 존재

▪︎ deb vs. rpm

deb
- Debian 계열에서 사용하는 패키지 도구
rpm
- Red Hat 계열에서 사용하는 패키지 도구

▪︎ rpm vs. yum

저수준 패키지 도구
- 패키지 파일을 설치하거나 제거할 때 사용하는 도구
- Red Hat 계열 → rpm
고수준 패키지 도구
- 패키지 파일을 설치하고 제거하며 다운 가능한 패키지를 검색하고 패키지 의존성을 해결하는 도구
- Red Hat 계열 → yum

ref.

리눅스 패키지(Linux Package)에 대한 이해

Package Manager

리눅스 배포판

uuuhhh — Thu, 1 Dec 2022 10:53:41 +0900

▪ Linux ?

‘Linux is an operating system.’
리눅스는 운영체제다.

‘In a GNU/Linux system, Linux is the kernel component.’
GNU/Linux 시스템에서 리눅스는 커널 구성 요소이다.

GNU : 자유 소프트웨어 재단에서 진행하며 유지 중인 OS 프로젝트

리눅스가 무엇인지 찾아보면 다음과 같이 다르게 표현된 정의를 볼 수 있다.
여기서 무엇이 맞는 말일까?

솔직히 둘 다 맞는 말이다.
리눅스는 리눅스 커널을 의미하기도 하고 리눅스 커널을 사용하는 운영체제를 의미하기도 하기 때문이다.
리눅스가 두 가지의 의미를 가지게 된 계기는 리눅스가 탄생한 흥미진진한 역사를 보면 잘 이해가 되지만 이번 포스팅은 리눅스의 역사가 중점이 아니라서.. 링크만 첨부 !

여담으로..

GNU 쪽 사람들은 리눅스는 커널일 뿐이고,
이 커널을 가져다가 GNU 프로그램들을 올려 만든 운영체제는 GNU/Linux라고 얘기한다.
-namu wiki 출처-

▪ 리눅스의 배포판과 탄생

먼저 다음과 같은 운영체제의 이름과 아이콘을 많이 보았을 것이다.
우분투 (Ubuntu)

센트 OS (CentOS)

등..
보통 이것을 리눅스 계열로 알고는 있는데.. 뭐가 다른 거지?

우리가 주로 말하는 리눅스(커널)로만은 원하는 목적의 기능과 편의성을 제공해주지 못한다.
그래서 리눅스 커널과 함께 해당 목적에 맞는 여러 기능들을 포함하여 패키징 해서 제공하는 운영체제가 탄생하였다.
이를 리눅스 배포판이라고 말한다.

따라서 배포판에 따라 서버 운영, IoT, 모바일, 일반 사용자 등.. 다양한 목적으로 나눠져 다른 기능과 프로그램을 제공한다는 걸 알 수 있다.

출처 : 위키피디아 (https://ko.wikipedia.org/wiki/리눅스_배포판)

현재 조사해보니 어마 무시하게 많은 리눅스 배포판이 존재하는 것을 확인할 수 있었다.
- 소리 소문 없이 생겼다가 사라진 것도..
- 좀 더 자세하게 알고 싶으면 사이트 링크 참고 !

ref.

1.2. What is GNU/Linux?

리눅스 배포판이란?

init vs. systemd

uuuhhh — Thu, 1 Dec 2022 10:45:43 +0900

▪ PID가 1인 프로세스

init Process : PID가 1인 프로세스

리눅스 부팅 과정
1. 시스템 전원 공급
2. BIOS (Basic Input / Output System)
3. Boot Loader
4. Kernel
5. init

커널 부팅이 완료된 후 첫 번째로 생성한 프로세스
커널이 직접 실행하는 유일한 프로세스
부모 프로세스가 없음
- PPID → 0

모든 프로세스는 init(PID : 1)을 부모 프로세스(PPID)로 가진다.
- 모든 프로세스의 조상님
모든 스레드는 kthreadd(PID : 2)를 부모 프로세스(PPID)로 가진다
- 모든 스레드의 조상님

▪ systemd 란?

init 프로세스의 한 종류

init 프로세스의 변천사
- SysV init → systemd

SysV init
- 직렬 처리 방식의 부팅
  - 순서대로 프로세스 실행 → 느림

↔ 호환 가능

systemd
- 병렬 처리 방식의 부팅
  - 빠름
- 다양해진 Unit
  - sshd.service
  - sshd.socket
- cgroup 제어
- 시스템 상태 저장 후 사용 snapshot 기능 지원
- journald 이벤트 로깅 데몬과 같은 여러 다양한 API 지원
- 등..

▪ systemd 기능

systemd 상태 모니터링

systemctl status
- 실행 중인 유닛의 상태 정보를 출력
- 유닛들을 cgroup으로 묶어서 출력

systemctl --failed
- 오작동 유닛 확인
- 흠.. 현재는 모두 멀쩡한가 봅니다..

systemctl (= systemctl list-units)
- 로딩된 유닛들 출력
- 유닛 파일 이름 / 활성화 상태 / 상세 설명 제공

systemctl list-unit-files
- 설치된 파일 출력
- 로딩되지 않았더라도 유닛 파일(.service, .device, ..)의 모든 서비스 출력

systemd 유닛 / 서비스 컨트롤 명령어

	영구히 적용 (재부팅 시 유지)	일회성 적용
시작 / 등록	enable	start	restart
종료 / 해제	disable	stop

유틸리티 제공
- 프로그램
  - journalctl → 시스템의 서비스와 커널 로그 확인
  - networkctl → 네트워크 상태 정보 확인

journalctl 명령어

networkctl 명렁어

프로세스와 스레드

uuuhhh — Thu, 1 Dec 2022 10:29:10 +0900

▪ 프로세스 (Process)

프로세스 (Process) : 운영체제(OS)에서 할당 받은 시스템 자원을 사용한 독립적인 작업

시스템 자원
- CPU 시간
- 주소 공간
- Code, Data, Stack, Heap 구조의 메모리 영역
각 프로세스는 다른 프로세스의 자원에 간섭이 불가능하다.
- 단, IPC(Inter Proceses Communication)를 통하여 서로 간에 통신 및 접근이 가능하다.

IPC(Inter Proceses Communication) : 프로세스 간 통신 → e.g.) 파이프, 소켓, 파일 ..

▪ 스레드 (Thread)

스레드 (Thread) : 프로세스 내부에서 프로세스 상의 공용의 자원을 사용하는 작업의 흐름

프로세스 자원
- Code, Data, Heap - 공용 사용
- Stack - 각각 따로 할당하여 사용
프로세스 내 스레드들은 주소 공간과 자원 공유(Code, Data, Heap)가 가능하다.
- 단, 서로 다른 프로세스 간 스레드들은 간섭 및 접근 불가능하다.

▪ 멀티 프로세스 (Multi Process)

장점
- 독립적이라 서로에게 영향을 미치지 않는다.
단점
- 문맥 교환 (Context Switching)으로 인한 오버헤드가 발생한다.
- 복잡한 IPC 구현을 통해야만 자원 공유 및 접근이 가능하다.
- 프로세스를 여러 개 생성 시 새로 시스템 자원 할당이 오버헤드..

문맥 교환 (Context Switching) :
하나의 프로세스가 CPU를 사용 중일 때 다른 프로세스가 CPU를 사용하기 위해
이전 프로세스의 상태를 보관하고 새로운 프로세스의 상태를 올리는 작업

Context ?
- 프로세스 정보
- 다음 실행할 명령어
- PID
- 레지스트리
- 등..

▪ 멀티 스레드 (Multi Thread)

장점
- 프로세스를 생성할 때 발생하는 시스템 콜이 줄어들어 자원의 효율성 상승
- 자원을 공유하는 간단한 통신 방법으로 프로그램 응답 시간 감소
- Stack 영역만 처리하는 스레드의 Context Switching으로 전환 속도 빠름
단점
- 자원을 동기화 함으로써 발생하는 관리 복잡성
- 단일 실패 지점에 대한 위험 발생

ref.

[OS] 프로세스와 스레드의 차이 - Heee's Development Blog

문맥 교환 - 위키백과, 우리 모두의 백과사전

리눅스 권한 체계

uuuhhh — Tue, 29 Nov 2022 01:34:51 +0900

▪ 리눅스 권한

특정한 사용자에게 파일이나 디렉토리에 대하여 읽기 / 쓰기 / 실행을 수행할 수 있는 자격을 부여해주는 것

리눅스 권한 : 허가권 + 소유권

▪ 허가권

-	파일을 의미	r (read)	[4]	파일을 읽을 수 있는 권한
d	디렉토리를 의미	w (write)	[2]	파일을 읽을 수 있는 권한
		x (execute)	[1]	파일을 읽을 수 있는 권한

▪︎ 문자로 권한 변경하기

u	사용자	+	권한 추가
g	그룹	-	권한 제거
o	다른 사용자

chmod u+x file
- 사용자에게 실행 권한 추가
chmod g-r file
- 그룹에게 읽기 권한 제거
chmod a+rwx file
- 모두에게 읽기, 쓰기, 실행 권한 추가
chmod ug-rx file
- 사용자와 그룹에게 읽기, 실행 권한 제거

▪︎ 숫자로 권한 변경하기

-rwxrwxrwx
- (4+2+1) x 100 + (4+2+1) x 10 + (4+2+1) x 1 = 777
- chmod 777 file
  - 사용자, 그룹, 다른 사용자에게 모든 권한을 추가
-rw-r--r--
- (4+2+0) x 100 + (4+0+0) x 10 + (4+0+0) x 1 = 644
- chmod 644 abc.txt
  - 사용자에게는 읽기와 쓰기, 그룹에게는 읽기, 다른 사용자에게는 읽기 권한 추가
drwxr-xr-x
- (4+2+1) x 100 + (4+0+1) x 10 + (4+0+1) x 1 = 755
- chmod 755 helloworld
  - 사용자에게는 모든 권한, 그룹에게는 읽기와 실행, 다른 사용자에게는 읽기와 실행 권한 추가

▪ 소유권

chown [OPTIONS] USER[:GROUP] FILE(s)

abc.txt 파일 소유자를 tom으로 변경
- chown tom abc.txt

abc.txt 파일 소유 그룹을 student로 변경
- chown :student abc.txt

abc.txt 파일 소유자를 andy로 소유 그룹을 adult로 변경
- chown andy:adult abc.txt

helloworld 디렉토리와 해당 폴더 모든 하위 파일들의 소유자 및 그룹 변경
- chown -R andy:adult helloworld

위와 같이 문자열인 유저 이름 대신 숫자형인 유저 ID 입력 가능
- chown 1500:1503 abc.txt

id / getent group을 통해 유저 이름과 ID 확인 가능

리눅스 Shell

uuuhhh — Tue, 29 Nov 2022 00:09:54 +0900

▪ 쉘 (Shell)

쉘(Shell) : 사용자와 OS의 내부 커널 사이의 인터페이스를 감싸는 층

출처 : https://wogh8732.tistory.com/75

명령어 처리기 (Command Processor)
사용자와 OS간 다리 역할을 수행
사용자의 명령을 받아 해석해서 전달 후 실행

▪ Bash vs. Zsh

Bash (Bash shell)
- 현 시대에 가장 많이 쓰이는 리눅스의 표준 Shell
- GNU 프로젝트를 위해 개발된 Shell
- /bin/bash

GNU 프로젝트 : 자유로운 소프트웨어를 희망하는 프로젝트

Zsh (Z shell)
- 높은 호환성
  - 지금까지 대부분 Shell의 기능을 포함한 확장형 Shell
- 플러그인 생태계
  - 다양한 플러그인 지원 (Oh My Zsh)
- 자동 완성 기능
  - /u/l/b + tab → /usr/local/bin
- /bin/zsh

리눅스 Pipe

uuuhhh — Mon, 28 Nov 2022 02:28:07 +0900

▪︎ 파이프 (Pipe)

파이프 (Pipe) : |

리눅스의 여러 명령어들을 조합하여 강력한 활용도를 보여줄 수 있는 기능
like a 조미료 (후추 팍팍! 소금 팍팍! 설탕 팍팍! → 짜자잔 맛있는 음식 ~)

명령어_1 | 명령어_2
- 여기서 명령어_1와 명령어_2는 다음의 과정을 거친다.
- 입력(stdin) → 수행 → 결과(stdout / stderr)
- 명령어_1의 결과는 | 파이프를 통해 명령어_2의 입력으로 전달되어 들어간다.
- 위 과정을 거치면 명령어_1의 결과가 입력된 명령어_2의 결과가 수행된다.

명령어_1은 부모 프로세스로써 fork()를 통해 명령어_2의 자식 프로세스를 생성한다.

▪︎ e.g.

특정 문자열의 파일명을 가진 파일을 검색하고 싶은 경우
- project를 포함한 파일명을 가진 파일 검색
  - ls -al | grep “project”

젠킨스 파드 스펙의 cpu 리소스를 수정(helm upgrade) 하고자 value 파일을 확인하는데..
- 너무 많아 ㅜ

cpu 부분만 보여줘 !
- cat jenkins-value.yaml | grep cpu

주석 부분은 필요 없어 !
- cat jenkins-values.yaml | grep cpu | grep -v “#”

ref.

[리눅스] 명령 실행 원리 2 : 파이프

NAT Gateway : NAT의 기본 개념과 AWS NGW 동작방식과 아키텍처 예시

uuuhhh — Sun, 13 Nov 2022 03:15:11 +0900

▪︎ NAT (Network Address Translation)

네트워크 주소 변환
정의

IP 주소를 다른 IP 주소로 변환해 라우팅을 원활히 해주는 기술

예시
- 사설 IP → 공인 IP
- 공인 IP → 사설 IP
- 사설 IP → 사설 IP
- 공인 IP → 공인 IP
- IPv4 → IPv6 / IPv6 → IPv4 (AFT : Address Family Traslation)

▪︎ Why?

IPv4 주소 고갈 문제 솔루션
- 단기 전략 - Subnetting (서브네팅)
- 중기 전략 - NAT & 사설 IP 체계
- 장기 전략 - IPv6 전환
보안 강화
- 내부 → 외부 통신할 때 IP 변환으로 내부 네트워크 보안 강화
IP 주소 체계가 같은 두 개의 네트워크 간 통신 가능
- 더블 NAT로 구현
불필요한 설정 변경 감소
- 공인 IP를 빌려쓰는 경우
- 회선과 IDC(Internet Data Center) 사업자 이전 해야하는 경우

실습 환경
- VM IP : 10.0.2.15
- Host IP : 210.115.xxx.xxx
- External Server IP : 210.115.225.11 (naver)
결론
- VM 내에서는 사설 IP를 달고 나가지만 외부 네트워크로 나갈 때는 Host를 통해 Host IP로 바꿔 나가는 것을 확인할 수 있어 Host의 NAT 기능을 확인.
- Host가 외부 네트워크랑 통신할때는 Host 내부 VM에서는 패킷이 잡히지 않는 것으로 보아 내부 네트워크랑 연관이 없음

▪︎ PAT(Port Address Translation)

NAT 기기는 PAT로 동작
Host → Server (Request O / Reply O)

Server → Host (Request X)

▪︎ AWS NGW

‘외부 네트워크에서는 Private Subnet에 접근 불가’를 원할 경우
‘Private Subnet을 외부 네트워크 or 기타 AWS 서비스에 연결’을 원할 경우

기본 원리 아키텍쳐 예시

조오금 더 응용

ref.

10-4 NAT Overloading aka Port Address Translation (PAT)

아키텍쳐 참고!

AWS VPC를 디자인해보자(3) - NAT Gateway 와 Bastion host

AWS NGW

⚠️ 2022/11/08 - 11/13 블로그 이관 작업 완료

uuuhhh — Sun, 13 Nov 2022 02:27:06 +0900

Plan : ~~2022/11/08 - 11/13~~
Done !

From Notion
To Tistory ❗️

[NKS] Ingress 생성

uuuhhh — Sun, 13 Nov 2022 02:25:54 +0900

⚠️ NKS(Naver Kubernetes Service) 환경에서 진행하였습니다. ⚠️

▪︎ Ingress

Service vs. Ingress
- Service는 트래픽을 Pod에 여러 타입으로 전달 (L4)
  - ClusterIP, NodePort, LoadBalancer
- Ingress는 외부의 HTTP/HTTPS 트래픽 요청을 규칙에 따라 Service에 전달 (L7)
Kubernetes에서 Ingress 생성 시 ALB Ingress Controller을 통해 LoadBalancer 인스턴스 생성 후 연동
Ingress Rule에서 설정한 Service의 NodePort를 포트 값으로 Target 그룹을 생성하고 LoadBalancer 인스턴스에 등록한다.

▪︎ ALB Ingress Controller

현재 NCP의 NKS를 사용하고 있는 관계로 NCP ALB Ingress Controller 매니페스트 파일로 설치를 진행한다.

$ k apply -f <https://raw.githubusercontent.com/NaverCloudPlatform/nks-alb-ingress-controller/main/docs/install/pub/install.yaml>

serviceaccount/alb-ingress-controller created
clusterrole.rbac.authorization.k8s.io/alb-ingress-controller created
clusterrolebinding.rbac.authorization.k8s.io/alb-ingress-controller created
ingressclass.networking.k8s.io/alb created
deployment.apps/alb-ingress-controller created

ALB Ingress Controller가 생성된 것을 확인 !
- 위 컨트롤러가 생성되는데 필요한 IngressClass나 ServiceAccount, ClusterRole, ClusterRoleBinding.. 등이 생성된 것도 확인 !

Ingress Controller의 기본 설정값
- Service Type
  - NodePort
- Default Rule
  - 매칭 되는 Rule이 없을 경우
  - spec.defaultBackend에 설정
  - 80 포트로 설정된 기본 Target Group이 생성
- Rule Priority
  - Ingress에서 정의한 Rule 순서에 따라 우선순위 결정
  - 가장 위부터 Rule 우선 순위 1로 설정

▪︎ Ingress 생성

Ingress와 Service에 어노테이션(Annotation)을 사용하여 ALB Ingress Controller의 설정을 변경할 수 있다.
ALB Ingress Controller의 어노테이션은 alb.ingress.kubernetes.io/ 로 시작 !
여러 가지 종류의 어노테이션들이 있으니 관련 공식 문서 참고 !

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cn-ingress
  labels:
    name: cn-ingress
  annotations:
    kubernetes.io/ingres.class: alb
spec:
  rules:
  - host: cc-cnproject.com
    http:
      paths:
      - pathType: Prefix
        path: "/"
        backend:
          service:
            name: cn-app-svc-n
            port: 
              number: 8080

Host Domain : cc-cnproject.com
cn-app-svc-n의 이름의 NodePort Type의 서비스로 트래픽 라우팅

위의 매니페스트 파일로 ingress를 생성해보자

Ingress Class도 alb로 설정된 것을 확인 !
Host Domain도 cc-cnproject.com으로 설정 확인 !
로드밸런서의 주소도 할당된 것을 확인 !

그럼 이제 남은 건 접속을 해봐야죠 :)
현재 위에서 설정한 호스트 도메인은 실제로 존재하지 않는 도메인이므로 위 도메인을 사용하여 요청을 보내기 위해서는 curl 명령에
-H host 옵션과 함께 사용해야 한다.

정상적으로 요청에 대한 응답 확인 !

▪︎ ⭐️

ALB Ingress Controller 외에 Nginx Ingress Controller 등 여러 종류가 존재한다.
Ingress는 로드밸런서의 확장된 버전이라고 생각하면 된다.
LoadBalancer Service vs. Ingress
- 로드밸런서 서비스는 해당 서비스의 Public IP 주소를 가진 로드밸런서가 필요하지만
- 인그레스는 하나의 IP 주소로 여러 개의 서비스를 라우팅하며 접근이 가능하도록 지원해준다 !

ref.

[AWS/EKS] 콘솔로 생성하는 EKS - ④ ingress로 서비스 외부 노출 시키기 (AWS LoadBalancer Controller 설치)

ALB Ingress Controller 설정

ALB Ingress Controller 활용 예제

Ingress 활용 예제

[NKS] NodePort / LoadBalancer 서비스 생성

uuuhhh — Sun, 13 Nov 2022 01:47:27 +0900

⚠️ NKS(Naver Kubernetes Service) 환경에서 진행하였습니다. ⚠️

▪︎ NodePort 타입으로 서비스 생성 및 접속

NodePort 타입으로 서비스를 생성해보자 !

apiVersion: v1
kind: Service
metadata:
  name: cn-app-svc-n
spec:
  selector:
    app: cn-app
  ports:
    - port: 8080
      targetPort: 8080
  type: NodePort

서비스 생성 확인 후 할당된 NodePort(31374) 확인 !

노드의 IP 확인

음.. Node IP + NodePort로 접속을 시도했는데.. 과묵하구먼..

트러블 슈팅

1. 포트 지정 문제 ?

처음에는 ‘파드에 포트를 잘못 지정해주고 타겟 포트랑 일치가 안돼서 그런가..’ 라는 의문점으로 시작하게 되었다.
하지만 파드 매니페스트 작성 시 포트와 타겟 포트를 동일하게 지정해도 똑같이 NodePort 서비스에 접속이 되지 않았다.
트래픽 → 노드 포트 → 파드 포트 → 타겟 포트 → 컨테이너
여기서 포트 지정과는 현재 이슈와 아무런 관계가 없다고 판단하였다.

2. Private Cluster or Public Cluster 문제 ?

많이 헤매고 여러 레퍼런스를 찾던 도중에 관련 문서에서 힌트를 찾을 수 있게 되었다 !

Amazon EKS 클러스터에서 실행되는 Kubernetes 서비스 공개

Amazon EKS 클러스터에서 실행 중인 Kubernetes 서비스를 공개하려면 어떻게 해야 합니까? 최종 업데이트 날짜: 2022년 09월 16일 Amazon Elastic Kubernetes Service(Amazon EKS) 클러스터에서 실행 중인 Kubernetes 서비

aws.amazon.com

‘노드가 프라이빗 서브넷에 있고 VPC 내부 또는 VPC를 통해서만 연결할 수 있는 경우 노드의 프라이빗 IP 주소를 확인합니다.’

현재 사용하고 있는 클러스터는 Private Subnet에서 생성한 Private Cluster이다.
여기서 반짝✨ 빛이 났다.
- 외부에서 Node IP:NodePort로 접속 시도
- 현재 Private Subnet에 있는 노드에 외부에서 Inbound로 들어갈 수 있는 문이 없음
- 들어갈 수도 없고 알 수 없는 목적지를 향한 트래픽은 헤매다가 Time Out..!

그럼 여기서 두 가지 방법을 생각하였다.
1. Public Subnet에 Public Type으로 Kubernetes Cluster 새로 생성하기
2. 같은 VPC 내 Public Subnet에 Bastion Host Server를 생성하고 Private Type 클러스터에 생성된 NodePort 서비스 접속하기

3. 보안 그룹 문제 ?

외부 트래픽을 수신할 수 있도록 워커 노드의 보안 그룹(ACG : Access control Group)을 설정해보고 서비스에 접속해보기

2-1. Public Subnet에 Public Type Kubernetes Cluster 새로 생성 후 서비스 접속

public 타입으로 cluster를 구축해 보았다.

생성 완료 !
- 여기서 워커 노드들에 public IP가 할당되어 있는 모습을 볼 수 있다.

NodePort Type 서비스를 생성해보고 서비스에 접속을 시도해 보았다.

또 과묵하구먼..

실패..
였지만.. 원인 분석 후 3번에서 해결 !

2-2. Bastion Host Server 생성하고 Private Type 클러스터 서비스 접속하기

Node 풀이 속해있는 VPC내의 Public Subnet에 Bastion Server를 생성

접속 !

NodePort Service에 접속 성공 !

3. 특정 NodePort에 관한 보안 그룹(ACG : Access control Group) 설정

2-1의 실패 원인을 분석해 보았다.
- NodePort는 해당 서비스를 외부에 워커 노드에 대한 특정 포트를 공개하는 것이다.
- 그렇다면 외부에서 특정 포트를 통해 노드에 접근하기 위해서는 외부 트래픽을 수신할 수 있도록 워커 노드의 보안 그룹(ACG : Access Controll Group)을 설정해줘야 하지 않을까 ?

해당 특정 NodePort에 대한 Inbound 규칙 추가 및 노드에 적용

서비스에 접속 !

성공 ㅎㅎㅎㅎ

▪︎ LoadBalancer 타입으로 서비스 생성 및 접속

LoadBalancer 타입으로 서비스를 생성 !

apiVersion: v1
kind: Service
metadata:
  name: cn-app-svc-l
spec:
  selector:
    app: cn-app
  ports:
  - port: 8080
    targetPort: 8080
  type: LoadBalancer

서비스 생성
- and pending…

loadbalancer 주소 할당 !

위 주소로 서비스에 접근 !

성공❗️❗️

[NKS] Deployment 생성

uuuhhh — Sun, 13 Nov 2022 01:43:48 +0900

⚠️ NKS(Naver Kubernetes Service) 환경에서 진행하였습니다. ⚠️

▪︎ Deployment 생성

나에게 할당된 네임스페이스가 잘 있는지 확인한다.

네임스페이스에 deployment 생성 !

apiVersion: apps/v1
kind: Deployment
metadata:
  name: cn-app-dpy
  labels:
    app: cn-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: cn-app
  template:
    metadata:
      labels:
        app: cn-app
    spec:
      containers:
      - name: cn-app
        image: uh2959/cn-action
        resources:
          limits:
            memory: "512Mi"
            cpu: "500m"

어라.. 왜 하나가 계속 pending이죠 ?

생성 과정 이벤트 로그를 확인해보자
0/2 nodes are availabe: 2 Insufficient cpu.
- 2개의 불충분한 cpu ??

▪︎ 트러블 슈팅

빨간불 키고 트러블 슈팅 들어갑시다 !
- 에러 메시지 그대로 cpu 자원이 부족하여 kubelet이 파드를 스케줄링을 하지 못해 FailedScheduling 에러가 발생한 듯하다.
  1. 누가 자원을 많이 먹고 있는지 확인할 수 있을까?
  2. 적절한 자원 요청을 어떻게 해줄 수 있을까?
  3. 특정한 리소스가 자원을 다 가져갈 수 없게 제한을 둘 수 있을까?
- 위와 같은 궁금한 것들이 생겨났고 일단 현재 이슈를 해결해보도록 하자
  1. 현재 리소스가 사용 중인 자원의 상황을 확인해보기
  2. 현재 사용 가능한 자원의 양을 확인해보기
  3. 과도한 자원을 사용 중인 리소스를 확인하여 자원 할당량 조정

현재 노드풀은 다음과 같다.

노드에서 사용 가능한 자원을 확인해보자
- kubectl describe nodes
- cnp-node-pool-w-1rbt 노드에 관한 테이블이다.

노드 총 자원량 + 할당 가능한 자원 테이블

할당된 자원 테이블

노드에 배포된 파드/서비스/데몬셋.. 자원 사용량 테이블

나머지 노드도 위 노드의 상태 테이블과 거의 일치하여 생략하였다.
위 node의 현재 상태의 정보를 살펴보면
- 노드의 cpu 초기 용량은 2이며 할당 가능한 cpu 자원은 1930m의 양인 것을 확인할 수 있다.
- 그리고 현재 노드의 모든 리소스에 할당된 자원의 양의 합은 요청(Requests) 초기 값이 1890m인 97%, 제한(Limits) 값은 2600m인 134%을 확인하였다.
- 여기까지 보아 지금 노드안에서 할당할 수 있는 자원은 없는 것을 알 수 있고 그 Limits 자원 요청마저도 overcommited(과도한 할당)라는 것을 확인할 수 있다.
도대체 노드안에서 누가 범인인가 싶어서 확인해 보았더니 빨간 박스 안의 리소스가 으마으마한 cpu와 memory 자원을 할당 받은 것을 확인할 수 있다.
- 무려.. 51%.. 25%..

그럼 이제 위 문제의 리소스들이 정말 할당을 요청한 자원을 충분히 사용중인지 확인해보자 !

일단 노드의 자원 사용량은
- cpu 73m → 3%.. 벌써 감이 오기 시작한다

mir 네임스페이스의 파드 자원 사용량을 확인하였다.
- 2m + 3m = 5m..

uhyeong 네임스페이스의 파드 자원 사용량을 확인해보았다.
- 2m + 2m = 4m…

여기서 중간 결론을 얘기해보자면 현재 디플로이먼트로 배포한 파드에서 컨테이너는 배포시 요청 자원보다 터무니없이 적은 자원을 사용하고 있는 것을 확인할 수 있었다.
- 이는 파드 배포시 과도한 자원 요청으로 엄청난 자원 낭비를 보여주고 있는 중이라 말할 수 있다.
- 이제 해결해봅시다 !
  - 배포시 사용한 매니페스트 파일 수정 후 적용

kubectl edit deployment -n <namespace>로 deployment의 resources.cpu 내용 수정하였다.

근데 또 뭔가 이상하다..

rollout이 고착 상태..

스케일 업으로 수정된 버전인 새로운 파드 생성을 하다가 할당할 cpu 자원이 부족해서 고착되었다,,,
- 웃프다..

그럼 디플로이먼트의 매니페스트 수정으로 롤링 업데이트를 할 수 없다면 자원을 지웠다가 다시 배포하는 수 밖에 없는건가?
1. 일단 임시방편으로 리소스 스펙을 완전 최소한의 자원으로 설정한 후 롤링 업데이트하는 방법
  - 충분히 가능성 있는 방안이지만 너무 임시방편 느낌이 강하다고 생각한다.
2. .spec.strategy.type==Recreate 에 대한 전략 적용으로 업데이트하는 방법
  - RollingUpdate 외에 새로운 타입의 방안인 Recreate에 대해 알아보고 적용해보자 !

⭐️ 디플로이먼트 재생성 (type : Recreate)
- 기존의 모든 파드는 새 파드가 생성되기 전에 죽는다.
- 업그레이드 전에 파드 종료를 보장할 수 있다.
- 업그레이드 시 이전 버전의 모든 파드는 즉시 종료되며 신규 버전의 파드가 생성되기 전에 성공적으로 제거가 완료되기를 대기한다.

두구두구,, 수정을 해보자 !

!!!! 뭔가 바뀐 것 같다 !!!!

흥분해서 여러 로그들을 다 확인해봤다ㅎㅎ
Limits 자원 할당도 제대로 업데이트 확인
이전 버전 디플로이먼트의 Scale down 후 업데이트된 새로운 버전의 디플로이먼트 Scale up 확인

이전 버전의 파드 삭제 및 Scale down 후 Scale up에 대한 이벤트 로그도 확인

노드의 자원이 어느 정도 여유가 생긴것을 확인할 수 있다.

그럼 mir 네임스페이스의 자원은 일반적인 RollingUpdate type으로 업데이트를 진행해보자

mir 네임스페이스의 디플로이먼트 매니페스트 파일 수정 후 롤링 업데이트 성공 !

이벤트 로그에서도 순차적으로 Scale Up 후 Scale Down에 대해 번갈아가면서 진행되는 것을 볼 수 있다.

노드 정보 확인
- 편안 ,,

⭐️ 결론

파드를 배포할 때 무자비하게 자원을 요청한 후 배포하면 나타날 수 있는 좋은 예시를 몸소 받았다..
하나 하나 고려해야할 점이 참 많구나.. 공부해야할 것이 늘었다는 이야기..

리소스의 메모리와 CPU 자원 관리

Epilogue NCP의 NKS에서 프로젝트를 진행 중에 각자 팀원들에게 namespace를 할당해주었다. 어느 날 간단한 파드에 대한 스펙을 정해주고 생성을 시도하였더니 스케줄링 에러가 발생 원인을 확인해

code1212-uh.tistory.com

Pod 안전하게 생성/배포 및 QoS 정책 설정

Epilogue 간단한 JAR 애플리케이션을 가지고 쿠버네티스 파드 배포를 시도하였다 ! 그런데 파드 상태가.. 엄청난 메모리 부족.. OOM Killed.. CrashLoopBackOff 상태 반복.. 파드 스펙 늘리고 다시 배포하

code1212-uh.tistory.com

ref.

디플로이먼트

RBAC 설정

uuuhhh — Sun, 13 Nov 2022 01:25:44 +0900

▪︎ RBAC ?

RBAC : 역할 기반 액세스 제어 (Role Based Access Control)

누가(주체), 무엇을(동사), 어디에(네임스페이스)를 실행할 수 있는지 결정하는 액세스 관리 형식
사용자 이름으로 액세스 권한을 부여하던 기존 ABAC에서 발전한 형태

ABAC : 속성 기반 액세스 제어 (Attribute Based Access Control)

K8s Service 클러스터 생성 시 클러스터를 생성한 Sub Account와 Root 계정은 클러스터 RBAC system:masters 그룹에 자동으로 설정된다.
클러스터 사용 권한을 IAM 유저에게 부여하려면 kube-system 네임스페이스에 ncp-auth ConfigMap을 등록해야 한다.

⭐️ 목적

각 Sub Account 마다 namespace를 할당하고 자신의 namespace에서만 리소스 접근 권한 부여하기 ❗️

▪ API objects

Role
- 특정 namespace 안에서 수행할 수 있는 권한
ClusterRole
- non-namespace 리소스이며 클러스터 전체에서 수행할 수 있는 권한
RoleBinding
- 특정 namespace 안에서 사용자나 사용자들 집합에게 Role안에서 정의한 권한을 부여
- ClusterRole을 참조할 수 있으며 RoleBinding의 namespace에 결합(bind) 가능
ClusterRoleBinding
- 클러스터에서 모든 namespace에 ClusterRole을 결합시키기 위한 설정

현 목적에 맞게 RBAC 인증을 사용하기 위해 필요한 권한과 API object를 생각해보자 !
- 개인의 namespace 안의 리소스만 접근 및 수정 가능
- Group으로 관리
  - node와 namespace를 볼 수 있는 ClusterRole + ClusterRoleBinding
  - 특정 namespace 내의 리소스를 관리할 수 있는 Role + RoleBinding

먼저 NCP 가이드에 나와있는 configmap 작성법을 참고하여 작성하였다.

▪︎ ConfigMap 작성 및 생성

ncp-auth-configmap.yaml
- subAccountIdNo
  - SubAccount 콘솔에서의 확인 가능한 SubAccount ID
- username
  - K8s 내부에서 IAM 유저에게 맵핑할 사용자의 이름
- group
  - K8s 내부에서 IAM 사용자에게 맵핑할 그룹 목록

apiVersion: v1
kind: ConfigMap
metadata:
  name: ncp-auth
  namespace: kube-system
data:
  mapSubAccounts: |
    - subAccountIdNo: b4e398d0-******
      username: snowcat471
      groups:
        - restricted-access-group-h
    - subAccountIdNo: 3318e510-******
      username: jungmir
      groups:
        - restricted-access-group-m
    - subAccountIdNo: d7dbe520-******
      username: fails9503
      groups:
        - restricted-access-group-j

configmap 생성 및 확인

트러블 이슈 때려 잡기 !

error: You must be logged in to the server (Unauthorized)
인증이 안되었다는 에러 메시지이므로 role에 대한 오류보다는 configmap에 IAM 계정이 제대로 안 들어갔다고 판단하였음
- namespace: kube-system
  - namespace를 kube-system에 넣어주지 않고 default에 넣어준 ~~바보 같은 나..~~
- subAccountIdNo : ****-****
  - sub account ID number을 명시해줘야 하는데 진짜 user ID를 넣어버린 ~~바보 같은 나~~..

▪︎ ClusterRole 작성 및 생성

ncp-auth-clusterrole.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: restricted-access-clusterrole
rules:
- apiGroups: [""]
  resources: ["nodes", "namespaces"]
  verbs: ["get", "list"]

클러스터 전체에 대해 수행할 cluster role 적용

▪︎ ClusterRoleBinding 작성 및 그룹 맵핑

ncp-auth-clusterrolebinding.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
	name: restricted-access-clusterrole-binding
subjects:
- kind: Group
	name: restricted-access-group
	apiGroup: rbac.authorization.k8s.io
roleRef:
	kind: ClusterRole
	name: restricted-access-clusterrole
	apiGroup: rbac.authorization.k8s.io

클러스터 전체에 대한 cluster role을 restricted-access-group 그룹에 맵핑

▪︎ Role 작성 및 생성

ncp-auth-role.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
	namespace: <specific-namespace>
	name: restricted-access-role
rules:
- apiGroups: [""]
	resources: ["pods"]
	verbs: ["get", "list"]
- apiGroups: ["apps"]
	resources: ["deployments", "daemonsets", "statefulsets", "replicasets"]
	verbs: ["get", "list"]
- apiGroups: ["batch"]
	resources: ["jobs"]
	verbs: ["get", "list"]

각 사용자의 namespace에 맞춘 role 생성
- 한꺼번에 적용시키면 편하지만 처음이라 하나하나 해보고 싶었던..ㅎ

트러블 이슈 때려 잡기 !

kubectl get pods -n mir에 대한 명령어 에러 발생
- Error from server (Forbidden): pods is forbidden: User “jungmir” cannot list resource “pods” in API group “” at the cluster scope
‘클러스터 범위 내 API 그룹 [“”] 안의 pods 리스트를 IAM 유저에게 보여줄 수 없다’
- 권한 에러
- rule에 대한 것이 IAM 유저에게 제대로 맵핑이 안되었나?
- rule이 제대로 정의가 안되었나?

apiGroups: ["apps"]
- 아무리 생각해도 잘못 설정한 곳이 없다고 생각했었던 ~~바보 같은 나..~~
- resources: ["deployments", … ] → 저 리소스들에 관한 rule 정할 건데..
- verbs: ["get", "list"] → 눈 3번 비벼도 이상하게 적은 곳 없는데..
- apiGroups: [””] → 확실하지 않은 건 이건데..?
- 앗.. 여기서 api 관련된 것을 어디서 볼 수 있었더라? pod의 apiVersiondeployment의 apiVersion

pod의 apiVersion

deployment의 apiVersion

위 그림 참고..
- 결국 pod에 대한 apiGroups는 [“”] 이었으며 deployment, daemonsets 등.. 에 관한 apiGroups는 [”apps”] 였다.
- 결론
  1. 리소스에 대한 apiVersion 잘못 작성함
  2. but, 여러 오브젝트 및 서비스에 관한 apiVersion을 확인하고 apiGroup에 넣는 법을 배웠다 !

▪︎ RoleBinding 작성 및 그룹 맵핑

ncp-auth-rolebinding.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: restricted-access-role-binding
  namespace: <specific-namespace>
subjects:
- kind: Group
  name: restricted-access-group
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: restricted-access-role
  apiGroup: rbac.authorization.k8s.io

각 사용자의 namespace에 맞춘 role에 대해 restricted-access-group에 맵핑

⭐️ 보나쓰

ClusterRole/Role verbs에서 “get”과 “list”의 차이는 뭘까?
- 둘 간의 차이 확인을 위해 RBAC의 role을 정의할 때 “list”에 대한 verbs를 제거하였다.

- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get"]

kubectl get pods
- Forbidden 에러 발생 !
kubectl get pods <specific-pod-name>
- 정상 출력 !
Why?
- 우리가 일반적으로 kubectl get pods 해서 나오는 pod 정보 리스트는 디폴트로 “list”에 대한 옵션이 들어갔다고 생각한다.
- 그렇기 때문에 “list”에 대한 권한이 없는 경우 전체 pod에 대한 리스트를 확인 불가능하며 특정 pod에 대한 이름 정보를 옵션으로 넣어주어야 그 특정 pod에 대한 정보만 “get”으로써 확인 가능한 것이다.
- 왜 “get”과 “list” 권한을 분리시켜놓았는지에 대한 목적을 생각해보았다.
  - 만약 특정 사용자나 개발자에게 모든 정보를 오픈하는 것보다 특정 정보만 오픈하길 원할 경우
    - 최소한의 권한 부여 → 보안 향상

ref.

IAM 인증 사용자 관리

Using RBAC Authorization

5 Kubernetes RBAC Mistakes You Must Avoid

K8s Service 인증

uuuhhh — Sun, 13 Nov 2022 01:02:31 +0900

NCP K8s Service는 ncp-iam-authenticator를 통해서 IAM 인증을 제공한다.
IAM 인증을 통해서 kubectl을 사용하기 위해
1. ncp-iam-authenticator를 설치하고
2. kubectl 설정 파일을 수정하여
이를 인증에 사용하도록 한다.

▪︎ ncp-iam-authenticator 설치 (for macOS)

1. Object Storage에서 ncp-iam-authenticator 바이너리를 다운로드

$ curl -o ncp-iam-authenticator <https://kr.object.ncloudstorage.com/nks-download/ncp-iam-authenticator/v1.0.5/darwin/amd64/ncp-iam-authenticator>

2. 바이너리에 실행 권한 추가

$ chmod +x ./ncp-iam-authenticator

3. $HOME/bin/ncp-iam-authenticator를 생성하고 $PATH에 추가

$ mkdir -p $HOME/bin && cp ./ncp-iam-authenticator $HOME/bin/ncp-iam-authenticator && export PATH=$PATH:$HOME/bin

4. Shell Profile에 PATH를 추가

나는 zsh 를 쓰고 있으므로 ~

$ echo 'export PATH=$PATH:$HOME/bin' >> ~/.zshrc

5. ncp-iam-authenticator 바이너리가 정상 동작하는지 테스트

$ ncp-iam-authenticator help

▪︎ IAM 인증 kubeconfig 생성

먼저 ncp-iam-authenticator를 사용하기 위해 API 인증키 값을 설정하는 두 가지 방법
1. OS 환경변수 설정
2. configure 파일 설정
- OS 환경변수가 configure 파일보다 우선시 된다 !

1️⃣ OS 환경변수 확인

API 인증키 값 확인한다.
- 마이페이지 → 계정 관리 → 인증키 관리

확인한 API 인증키 값을 OS 환경변수로 설정한다.

$ export NCLOUD_ACCESS_KEY=[ACCESS_KEY_ID]
$ export NCLOUD_SECRET_KEY=[SECRET_ACCESS_KEY]
$ export NCLOUD_API_GW=https://ncloud.apigw.ntruss.com

전체 환경변수 보기

$ printenv

특정 환경변수 보기

$ echo $[value_name]

환경변수 삭제

$ unset [value_name]

2️⃣ configure 파일 설정

사용자 로컬 홈 디렉토리의 .ncloud 폴더에 configure 파일 생성 및 설정
- 없으면 만든다 !

$ cat ~/.ncloud/configure
[DEFAULT]
ncloud_access_key_id = [ACCESS_KEY_ID]
ncloud_secret_access_key = [SECRET_ACCESS_KEY]
ncloud_api_url = <https://ncloud.apigw.ntruss.com>

➡️ kubeconfig 생성

ncp-iam-authenticator create-kubeconfig 으로 클러스터의 kubeconfig 생성한다.

$ ncp-iam-authenticator create-kubeconfig --region <region-code> --clusterUuid <cluster-uuid> --output kubeconfig.yaml

# 예시
$ ncp-iam-authenticator create-kubeconfig --region KR --clusterUuid 1234567890 --output kubeconfig.yaml

region-code
- 클러스터의 리전 코드
- e.g) KR, SGN
cluster-uuid
- 클러스터의 UUID
--output
- kubeconfig 파일이 저장될 path
- 입력 안할 시 ./kubeconfig-<cluster-uuid>.yaml path로 파일 저장
kubeconfig.yaml 파일로 kubectl 명령 테스트 성공 !

⏸ kubectl 명령어 단축

현재 kubectl 명령어를 사용하기 위해선 kubeconfig 환경 설정 파일까지 입력해야함
너무 길어서 불편,,

위에서 열심히 만들었던 kubeconfig.yaml 파일을 .kube/config 로 이름을 바꿔 이동하거나 복사한다.

잘 동작하는 것을 확인할 수 있다 !

NKS Cluster 생성

uuuhhh — Sun, 13 Nov 2022 00:53:57 +0900

▪︎ 신청 및 생성

Service - Kubernetes Service - Clusters

생성하기

요금 잘 계산한 후에 원하는 목적에 맞는 서버 스펙으로 노드풀 설정

인증키 생성 및 다운로드

클러스터 생성 스펙 리뷰

생성중 〰️

생성하는 동안 사용자 로컬에서 클러스터 제어를 위한 kubectl 설치

# Homebrew 패키지 매니저를 사용하고 있는 macOS인 케이스

# kubectl 설치
$ brew install kubectl

# 설치 버전 확인
$ kubectl version --client

생성 성공 !