[kubernetes] kubeadm, kubelet, kubectl 설치하기


Kubernetes는 컨테이너화된 애플리케이션을 자동으로 배포, 확장, 관리하는 오픈 소스 플랫폼이며, 다양한 환경에서 일관된 애플리케이션 실행을 가능하게 해주는 컨테이너 오케스트레이션 도구입니다.

 

Kubernetes를 사용하기 위해 kubeadm, kubelet, kubectl 패키지 등을 사용하여 클러스터를 구성하거나 Pod를 사용할 수 있습니다.


각 패키지에 대한 내용을 확인해보고 설치하는 방법을 알아보도록 하겠습니다.

 

 


패키지별 용도

 

kubeadm

kubeadm은 Kubernetes 클러스터를 설치하고 관리하는 데 필요한 기본 도구로, 클러스터의 부트스트랩 작업을 자동화하는 역할을 합니다. 또한 kubeadm은 클러스터 초기화, 노드 추가 및 업그레이드와 같은 작업을 쉽게 할 수 있도록 명령어를 제공합니다. 주로 마스터 노드(컨트롤 플레인)를 설정하고 클러스터를 시작하는 데 사용됩니다.

 

  • 주요 기능
    • 클러스터 초기화 (init)
      • kubeadm init 명령어를 사용하여 컨트롤 플레인을 초기화하고, 클러스터의 기본 구성 요소들을 설치합니다.
      • 인증서, 키, 구성 파일 등을 생성하고, 필수적인 컨트롤러 컴포넌트들을 설정할 수 있습니다.
    • 노드 추가 (join)
      • kubeadm join 명령어를 사용하여 워커 노드를 기존 클러스터에 추가합니다.
      • 이를 통해 워커 노드가 마스터 노드에 연결되어 작업을 처리할 수 있습니다.
    • 클러스터 업그레이드
      • Kubernetes의 새로운 버전이 릴리스될 때, kubeadm upgrade 명령어를 사용하여 클러스터를 업그레이드할 수 있습니다.

 

kubelet

kubelet은 Kubernetes 클러스터에서 각 노드에 상주하며 Pod와 컨테이너를 관리하는 에이전트입니다. 또한 kubelet은 마스터 노드의 API 서버에서 내려오는 명령을 받아서 해당 노드에서 컨테이너가 올바르게 실행되는지 지속적으로 모니터링하고 관리하는 역할을 합니다. Kubernetes의 기본 구성 요소 중 하나로, Pod의 상태를 보고하고 필요한 경우 컨테이너를 다시 시작하는 등 작업을 수행합니다.

 

  • 주요 기능
    • Pod 및 컨테이너 관리
      • kubelet은 Pod의 정의를 받아 해당 Pod를 생성하고, 올바르게 실행되고 있는지 확인합니다.
      • 컨테이너의 상태를 주기적으로 확인하며, 상태가 이상할 경우 컨테이너를 재시작하여 상태를 유지하도록 합니다.
    • 노드 상태 보고
      • kubelet은 마스터 노드의 API 서버에 노드의 상태와 자원 사용량(CPU, 메모리 등)을 주기적으로 보고합니다.
      • 이를 통해 클러스터 관리자가 노드의 상태를 모니터링할 수 있습니다.
    • 로깅 및 진단
      • kubelet은 로그 파일을 관리하고, 시스템의 진단 정보를 수집하여 클러스터의 상태를 확인하는 데 도움을 줍니다.

 

kubectl

kubectl은 Kubernetes 클러스터와 상호작용하기 위한 명령줄 도구로, 클러스터 내 리소스 관리, 배포, 디버깅 등을 수행할 수 있는 가장 중요한 도구 중 하나입니다. kubectl을 사용하면 Kubernetes API 서버와 통신하여 클러스터 상태를 조회하거나 관리할 수 있으며, Kubernetes 리소스를 생성, 조회, 수정, 삭제하는 다양한 작업을 수행할 수 있습니다.

 

  • 주요 기능
    • Kubernetes 리소스 관리
      • 클러스터 내에서 Pod, Service, Deployment, ConfigMap 등과 같은 리소스를 생성, 조회, 업데이트, 삭제할 수 있습니다.
    • 클러스터 상태 모니터링
      • 노드, 네임스페이스, 컨테이너 등의 상태를 확인하고, 로그를 조회하여 애플리케이션 상태를 진단할 수 있습니다.
    • 배포 관리
      • 애플리케이션 배포, 확장, 롤백 등의 작업을 쉽게 수행할 수 있습니다.

 

 

 


설치

kubeadm, kubelet, kubectl 패키지 설치 작업은 Rocky Linux 9.4 버전에서 테스트를 진행했습니다.
또한 각 패키지의 버전은 1.31 버전을 설치하도록 설정하였습니다.

 

Kubernetes는 Github으로 프로젝트가 관리되고 있습니다.
Kubernetes의 최신 릴리즈 노트 를 확인해보면 24년 9월 둘째 주에 릴리즈한 v1.31.1 버전이 최신 버전입니다.

 

각각의 kubeadm, kubelet, kubectl 패키지 들은 kubernetes GitHub 프로젝트의 리포지토리를 통해 확인할 수 있습니다.

https://github.com/orgs/kubernetes/repositories?type=all

 

 

본격적으로 설치를 진행해보도록 하겠습니다.
cat 명령어를 사용하여 Kubernetes repo를 추가합니다. repo 추가 시 최신 버전인 v1.31 버전을 지정하였습니다.

# cat <<EOF | sudo tee /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://pkgs.k8s.io/core:/stable:/v1.31/rpm/
enabled=1
gpgcheck=1
gpgkey=https://pkgs.k8s.io/core:/stable:/v1.31/rpm/repodata/repomd.xml.key
exclude=kubelet kubeadm kubectl cri-tools kubernetes-cni
EOF

 

 

 

yum list 명령어를 사용하여 yum repo 확인 시 1.31 버전의 kubeadm, kubelet, kubectl 패키지 리스트를 확인하실 수 있습니다.

# yum list kube*
Kubernetes                4.2 kB/s | 1.7 kB     00:00
Installed Packages
kubeadm.x86_64            1.31.0-150500.1.1     @kubernetes
kubectl.x86_64            1.31.0-150500.1.1     @kubernetes
kubelet.x86_64            1.31.0-150500.1.1     @kubernetes
kubernetes-cni.x86_64     1.5.1-150500.1.1

 

 

 

yum install 명령어를 사용하여 kubeadm, kubelet, kubectl 패키지를 설치합니다.

# yum install -y kubelet kubeadm kubectl --disableexcludes=kubernetes
Last metadata expiration check: 0:00:12 ago on Fri 20 Sep 2024 01:36:55 PM KST.
Package kubelet-1.31.0-150500.1.1.x86_64 is already installed.
Package kubeadm-1.31.0-150500.1.1.x86_64 is already installed.
Package kubectl-1.31.0-150500.1.1.x86_64 is already installed.
Dependencies resolved.
================================================================================
 Package        Architecture        Version             Repository        Size
================================================================================
Upgrading:
 kubeadm        x86_64              1.31.1-150500.1.1   kubernetes        11 M
 kubectl        x86_64              1.31.1-150500.1.1   kubernetes        11 M
 kubelet        x86_64              1.31.1-150500.1.1   kubernetes        15 M
Transaction Summary
================================================================================
Upgrade  3 Packages

##### 생략 #####

Upgraded:
  kubeadm-1.31.1-150500.1.1.x86_64       kubectl-1.31.1-150500.1.1.x86_64
  kubelet-1.31.1-150500.1.1.x86_64

Complete!

 

 

kubelet은 데몬 형태로 실행되므로 systemctl 명령어를 사용하여 시스템 부팅 시 자동으로 시작되도록 등록하고, 시작합니다.

# systemctl enable --now kubelet

 

 

*** 2024-10-17 추가

Kubernetes는 노드의 메모리 관리 방식을 중요하게 여기며, 스왑(Swap)이 활성화된 상태에서는 메모리 관련 문제가 발생할 수 있기 때문에 이를 비활성화해야 합니다.

 

스왑(Swap) 비활성화 후 kubelet을 재시작 합니다.

# swapoff -a
# sed -i '/ swap / s/^/#/' /etc/fstab

# systemctl restart kubelet

 

 

 

*** 2024-10-30 추가

Linux에서 기본적으로 구동 중인 firewalld 서비스를 종료합니다. API 서버 연결 및 노드 추가 등의 작업 시 방화벽으로 작업이 비정상적으로 동작할 수 있습니다. 해당 서비스를 종료할 수 없다면 허용이 필요한 모든 방화벽 정책 확인 후 방화벽 정책을 추가하여 사용 가능합니다.

 

firewalld 서비스를 종료 후 재시작 시에도 비활성화 하도록 설정합니다.

# systemctl stop firewalld
# systemctl disable firewalld
Removed "/etc/systemd/system/multi-user.target.wants/firewalld.service".
Removed "/etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service".

 


설치 확인

kubeadm

kubeadm version 명령어를 사용하여 kubeadm 패키지가 정상적으로 설치되었는지 확인합니다.

# kubeadm version
kubeadm version: &version.Info{Major:"1", Minor:"31", GitVersion:"v1.31.1", 
GitCommit:"948afe5ca072329a73c8e79ed5938717a5cb3d21", GitTreeState:"clean", 
BuildDate:"2024-09-11T21:26:49Z", GoVersion:"go1.22.6", Compiler:"gc", Platform:"linux/amd64"}

 

 

kubelet

kubelet --version 명령어를 사용하여 kubelet 패키지가 정상적으로 설치되었는지 확인합니다.

# kubelet --version
Kubernetes v1.31.1

 

 

systemctl 명령어를 사용하여 kubelet 데몬의 상태를 확인합니다.
클러스트가 구성되어 있지 않기 때문에 실행되고 있지만 상태는 실패로 확인될 것입니다.

# systemctl status kubelet
● kubelet.service - kubelet: The Kubernetes Node Agent
     Loaded: loaded (/usr/lib/systemd/system/kubelet.service; enabled; preset: disabled)
    Drop-In: /usr/lib/systemd/system/kubelet.service.d
             └─10-kubeadm.conf
     Active: activating (auto-restart) (Result: exit-code) since Fri 2024-09-20 16:20:57 KST; 3s ago
       Docs: https://kubernetes.io/docs/
    Process: 1465978 ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_CONFIG_ARGS $KUBELET_KUBEADM_ARGS $KUBELET_EXTRA_ARGS (code=exited, status=1/FAILURE)
   Main PID: 1465978 (code=exited, status=1/FAILURE)
        CPU: 136ms

 

 

kubectl

kubectl version 명령어를 사용하여 kubectl 패키지가 정상적으로 설치되었는지 확인합니다.
클러스트가 구성되어 있지 않기 때문에 API와 통신할 수 없어 API 서버 연결 오류가 발생할 것입니다.

# kubectl version
Client Version: v1.31.1
Kustomize Version: v5.4.2
The connection to the server localhost:8080 was refused - did you specify the right host or port?

 

 

 


 

Rocky Linux 9.4에서 kubeadm, kubelet, kubectl 패키지를 설치하는 방법을 알아봤습니다.

 

먼저, Kubernetes 관련 repo를 등록하고 yum install명령어를 사용하여 각 패키지를 설치합니다. 그 후, 각 패키지별 version 명령어를 사용하여 버전 정보를 확인할 수 있으며, kubelet 및 kubectl 에서는 클러스트가 구성되어 있지 않기 때문에 오류가 발생하는 것을 확인하실 수 있습니다.

 

지금까지 kubeadm, kubelet, kubectl 패키지를 설치하는 방법을 간단히 알아보는 시간을 가졌습니다....! 끝...!

 

 

유익하게 보셨다면 공감을 눌러주고, 댓글로 의견을 공유해 남겨주시면 감사하겠습니다!

 

 

 

[Reference]
https://github.com/kubernetes/kubernetes
https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/

 

 

 

[kubernetes] kubeadm init "found multiple CRI endpoints on the host" 오류

 

오류 내용

kubeadm init 명령을 실행할 때 발생하는 "found multiple CRI endpoints on the host" 오류는 시스템에 여러 개의 CRI(Container Runtime Interface) 엔드포인트가 존재할 때 발생하는 문제입니다.


Kubernetes에서 지원하는 컨테이너 런타임은 dockershim, containerd, CRI-O 등이 있으며, 여러 개의 컨테이너 런타임이 설정된 경우 Kubelet이 어떤 컨테이너 런타임을 사용할지 혼란스러워하는 상황이 발생합니다.

# kubeadm init
found multiple CRI endpoints on the host. Please define which one do you wish to use by setting the 'criSocket' field in the kubeadm configuration file: unix:///var/run/containerd/containerd.sock, unix:///var/run/crio/crio.sock
To see the stack trace of this error execute with --v=5 or higher

 

 


해결 방법

1. 컨테이너 런타임 소켓을 확인합니다.

  • /var/run/dockershim.sock
  • /var/run/containerd/containerd.sock
  • /var/run/crio/crio.sock

 

 

2.1 kubeadm init 명령에 --cri-socket 옵션을 사용하여 특정 CRI 소켓을 지정합니다

# kubeadm init --cri-socket /var/run/containerd/containerd.sock

 

 

2.2 불필요한 런타임을 제거 및 종료 후 kubeadm init 명령어를 사용합니다.

 

# systemctl stop crio
# kubeadm init

 

 


 

kubeadm init 명령어 실행 시 하나의 컨테이너 런타임을 지정하거나 사용 중이어야 "found multiple CRI endpoints on the host" 오류가 발생하지 않습니다.


위 해결 방법을 통해 오류가 발생하여도 해결하여 Kubernetes를 설치하여 사용하시길 바랍니다.

 

지금까지 kubeadm init 명령어 시 간단히 오류를 해결해보는 시간을 가졌습니다....! 끝...!

 

 

유익하게 보셨다면 공감을 눌러주고, 댓글로 의견을 공유해 남겨주시면 감사하겠습니다!

 

 

 

[kubernetes] runc 설치하기

Kubernetes는 컨테이너화된 애플리케이션을 자동으로 배포, 확장, 관리하는 오픈 소스 플랫폼이며, 다양한 환경에서 일관된 애플리케이션 실행을 가능하게 해주는 컨테이너 오케스트레이션 도구입니다.

 

runc는 Kubernetes와 같은 컨테이너 오케스트레이션 시스템에서 컨테이너 런타임으로 사용되며, 컨테이너를 실제로 실행하는 핵심적인 역할을 담당합니다. Kubernetes에서는 runc가 containerd와 같은 상위 컨테이너 런타임과 함께 동작하며, 컨테이너의 생성, 실행, 종료 등의 작업을 수행합니다.

 

Kubernetes를 사용하기 전 runc를 설치하고 확인하는 것을 테스트 해보도록 하겠습니다.

 

 


설치

runc 설치 작업은 Rocky Linux 9.4 버전에서 테스트를 진행했습니다.

 

runc는 github으로 프로젝트가 관리되고 있습니다.
runc의 최신 릴리즈 노트 를 확인해보면 24년 9월 첫째주에 릴리즈한 v1.1.14 버전이 최신 버전입니다.
최신 버전인 v1.1.14버전을 설치해보겠습니다.

 

 

wget 명령어를 사용하여 runc 바이너리 파일을 다운로드 받습니다.
버전 및 CPU 아키텍처에 맞는 바이너리 파일을 지정합니다.

# wget https://github.com/opencontainers/runc/releases/download/v1.1.14/runc.amd64 -O /usr/local/sbin/runc
--2024-09-12 14:07:38--  https://github.com/opencontainers/runc/releases/download/v1.1.14/runc.amd64
Resolving github.com (github.com)... 20.200.245.247
Connecting to github.com (github.com)|20.200.245.247|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://objects.githubusercontent.com/github-production-release-asset-2e65be/36960321/e98c6b7d-c8ae-4c3d-9d00-abe634ca1fca?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=releaseassetproduction%2F20240912%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20240912T050741Z&X-Amz-Expires=300&X-Amz-Signature=864efce7938d2f7ade782e4c1736b3ae152e3d81aaf831d661917219517567dd&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=36960321&response-content-disposition=attachment%3B%20filename%3Drunc.amd64&response-content-type=application%2Foctet-stream [following]
--2024-09-12 14:07:39--  https://objects.githubusercontent.com/github-production-release-asset-2e65be/36960321/e98c6b7d-c8ae-4c3d-9d00-abe634ca1fca?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=releaseassetproduction%2F20240912%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20240912T050741Z&X-Amz-Expires=300&X-Amz-Signature=864efce7938d2f7ade782e4c1736b3ae152e3d81aaf831d661917219517567dd&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=36960321&response-content-disposition=attachment%3B%20filename%3Drunc.amd64&response-content-type=application%2Foctet-stream
Resolving objects.githubusercontent.com (objects.githubusercontent.com)... 185.199.111.133, 185.199.108.133, 185.199.109.133, ...
Connecting to objects.githubusercontent.com (objects.githubusercontent.com)|185.199.111.133|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 11089920 (11M) [application/octet-stream]
Saving to: ‘/usr/local/sbin/runc’

/usr/local/sbin/runc                            100%[=====================================================================================================>]  10.58M  7.93MB/s    in 1.3s

2024-09-12 14:07:41 (7.93 MB/s) - ‘/usr/local/sbin/runc’ saved [11089920/11089920]

 

 

권한을 할당하여 runc 명령어를 사용할 수 있도록 합니다.

# chmod 755 /usr/local/sbin/runc

# ls -al /usr/local/sbin/runc
-rw-r--r--. 1 root root 11089920 Sep  3 10:26 /usr/local/sbin/runc

 

 


설치 확인

runc --version 명령어를 사용하여 runc가 정상적으로 설치되었는지 확인합니다.

# runc --version
runc version 1.1.14
commit: v1.1.14-0-g2c9f5602
spec: 1.0.2-dev
go: go1.22.6
libseccomp: 2.5.5

 

 

추가적으로 runc 명령어를 사용하여 컨테이너를 직접적으로 실행할 수 있으며, 아래 링크를 통해 추가적으로 테스트를 진행해보시기 바랍니다.
https://github.com/opencontainers/runc?tab=readme-ov-file#using-runc

 

 


 

Rocky Linux 9.4에서 runc를 설치 및 확인하는 방법을 알아봤습니다.

 

먼저, GitHub에서 최신 버전의 runc 바이너리 파일을 다운로드하고, /usr/local/sbin 경로에 업로드 후 권한을 할당합니다.
그 후, runc --version 명령어를 통해 runc 버전 정보 및 실행을 확인할 수 있으며, 추가적으로 runc 명령어를 통해 직접적으로 컨테이너를 실행하거나 관리할 수 있습니다.

 

지금까지 runc를 설치 및 확인 방법을 간단히 알아보는 시간을 가졌습니다....! 끝...!

 

 

유익하게 보셨다면 공감을 눌러주고, 댓글로 의견을 공유해 남겨주시면 감사하겠습니다!

 

 

 

[Reference]
https://github.com/opencontainers/runc

 

 

 

[kubernetes] CRI-O 설치하기


Kubernetes는 컨테이너화된 애플리케이션을 자동으로 배포, 확장, 관리하는 오픈 소스 플랫폼이며, 다양한 환경에서 일관된 애플리케이션 실행을 가능하게 해주는 컨테이너 오케스트레이션 도구입니다.

 

Kubernetes에서의 CRI-O(Container Runtime Interface - Open Container Initiative)는 컨테이너 런타임으로서, Kubernetes의 kubelet과 통신하여 컨테이너의 생성, 실행, 관리 등을 수행합니다. CRI(Container Runtime Interface)를 통해 Kubernetes의 명령을 수신하고, 컨테이너 이미지를 풀링하거나 컨테이너를 시작, 정지, 삭제하는 작업을 수행합니다.

 

Kubernetes 를 사용하기 전 CRI-O를 설치하고 확인하는 것을 테스트 해보도록 하겠습니다.

 

 


설치

CRI-O 설치 작업은 Rocky Linux 9.4 버전에서 테스트를 진행했습니다.

 

CRI-O는 github으로 프로젝트가 관리되고 있습니다.
CRI-O의 최신 릴리즈 노트를 확인해보면 24년 9월 6일을 기준으로 3일 전에 릴리즈한 v1.30.5 버전이 최신 버전입니다.
최신 버전인 v1.30.5버전을 설치해보겠습니다.

 

 

CRI-O를 yum 명령어를 통해 설치하기 repo를 등록해줍니다.
repo에는 최신 버전인 CRI-O를 설치하기 위해 v1.30 버전 값을 입력하였습니다.

cat <<EOF | tee /etc/yum.repos.d/cri-o.repo
[cri-o]
name=CRI-O
baseurl=https://pkgs.k8s.io/addons:/cri-o:/stable:/v1.30/rpm/
enabled=1
gpgcheck=1
gpgkey=https://pkgs.k8s.io/addons:/cri-o:/stable:/v1.30/rpm/repodata/repomd.xml.key
EOF

 

 

 

 

yum 명령어를 사용하여 CRI-O를 설치합니다.

# yum install -y cri-o

=== 생략 ===
Running transaction
  Preparing        :                                    1/1
  Installing       : cri-o-1.30.5-150500.1.1.x86_64     1/1
  Running scriptlet: cri-o-1.30.5-150500.1.1.x86_64     1/1
  Verifying        : cri-o-1.30.5-150500.1.1.x86_64     1/1

Installed:
  cri-o-1.30.5-150500.1.1.x86_64

Complete!

 

 

 

systemctl 명령어를 사용하여 CRI-O 서비스를 시작하고 자동 재시작 리스트에 등록합니다.

# systemctl enable --now crio
Created symlink /etc/systemd/system/cri-o.service → /usr/lib/systemd/system/crio.service.
Created symlink /etc/systemd/system/multi-user.target.wants/crio.service → /usr/lib/systemd/system/crio.service.

 

 


설치 확인

여러 명령어를 사용하여 CRI-O가 정상적으로 설치되고 구동 중인지 확인합니다.

 

systemctl 명령어를 사용하여 CRI-O 서비스 데몬의 상태를 확인합니다.

# systemctl status crio
● crio.service - Container Runtime Interface for OCI (CRI-O)
     Loaded: loaded (/usr/lib/systemd/system/crio.service; enabled; preset: disabled)
     Active: active (running) since Fri 2024-09-06 08:25:38 KST; 4s ago
       Docs: https://github.com/cri-o/cri-o
   Main PID: 192282 (crio)
      Tasks: 11
     Memory: 20.3M
        CPU: 409ms
     CGroup: /system.slice/crio.service
             └─192282 /usr/bin/crio

Sep 06 08:25:38 K8S-CN-001 crio[192282]: time="2024-09-06 08:25:38.072731000+09:00" level=info msg="Restore irqbalance config: created backup file"
Sep 06 08:25:38 K8S-CN-001 crio[192282]: time="2024-09-06 08:25:38.078009800+09:00" level=warning msg="Error encountered when checking whether cri-o should wipe containers: open /var/run/cr>
Sep 06 08:25:38 K8S-CN-001 crio[192282]: time="2024-09-06 08:25:38.078581900+09:00" level=info msg="Registered SIGHUP reload watcher"
Sep 06 08:25:38 K8S-CN-001 crio[192282]: time="2024-09-06 08:25:38.078617000+09:00" level=info msg="Starting seccomp notifier watcher"
Sep 06 08:25:38 K8S-CN-001 crio[192282]: time="2024-09-06 08:25:38.078700400+09:00" level=info msg="Create NRI interface"
Sep 06 08:25:38 K8S-CN-001 crio[192282]: time="2024-09-06 08:25:38.078795100+09:00" level=info msg="runtime interface created"
Sep 06 08:25:38 K8S-CN-001 crio[192282]: time="2024-09-06 08:25:38.078820100+09:00" level=info msg="Registered domain \"k8s.io\" with NRI"
Sep 06 08:25:38 K8S-CN-001 crio[192282]: time="2024-09-06 08:25:38.078832100+09:00" level=info msg="runtime interface starting up..."
Sep 06 08:25:38 K8S-CN-001 crio[192282]: time="2024-09-06 08:25:38.078843100+09:00" level=info msg="starting plugins..."
Sep 06 08:25:38 K8S-CN-001 systemd[1]: Started Container Runtime Interface for OCI (CRI-O).

 

 

 

자체 crio 명령어를 사용하여 CRI-O 버전을 확인합니다.

# crio --version
crio version 1.30.5
Version:        1.30.5
GitCommit:      df27b8f8eb49a13c522aca56ee4ec27bc7482fad
GitCommitDate:  2024-09-02T07:15:35Z
GitTreeState:   clean
BuildDate:      1970-01-01T00:00:00Z
GoVersion:      go1.22.0
Compiler:       gc
Platform:       linux/amd64
Linkmode:       static
BuildTags:
  static
  netgo
  osusergo
  exclude_graphdriver_btrfs
  exclude_graphdriver_devicemapper
  seccomp
  apparmor
  selinux
LDFlags:          unknown
SeccompEnabled:   true
AppArmorEnabled:  false

 

 

 

CRI-O 소켓이 정상적으로 생성되었는지 확인합니다.
kubernetes 에서는 해당 경로의 소켓을 설정하여 컨테이너 런타임을 설정할 수 있습니다.

# ls -al /var/run/crio/crio.sock
srw-rw----. 1 root root 0 Sep  6 08:25 /var/run/crio/crio.sock

 

위 명령어까지 모두 정상적으로 확인되었다면 CRI-O 설치는 정상적임을 확인하실 수 있습니다.

 


 

Rocky Linux 9.4 및 기타 OS에서 CRI-O를 설치하여 kubernetes에서 컨테이너 런타임으로 사용할 수 있습니다.

 

먼저, yum을 사용해 CRI-O 설치를 위해 필요한 repository를 설정하고 최신 버전인 v1.30.5를 설치합니다. 설치 후 systemctl 명령어로 CRI-O 서비스를 시작하고 자동으로 재시작되도록 설정합니다. 설치가 완료된 후, systemctl status crio 명령어로 서비스 상태를 확인하고, crio --version 명령어로 CRI-O 버전을 확인합니다.


마지막으로 /var/run/crio/crio.sock 경로에 소켓이 정상적으로 생성되었는지 확인하여 Kubernetes와 연동할 수 있는지 점검할 수 있습니다.

 

지금까지 CRI-O 설치 및 설치 방법을 간단히 알아보는 시간을 가졌습니다....! 끝...!

 

 

유익하게 보셨다면 공감을 눌러주고, 댓글로 의견을 공유해 남겨주시면 감사하겠습니다!

 

 

 

[Reference]
https://github.com/cri-o/packaging/blob/main/README.md#usage

 

 

 

[kubernetes] containerd 설치하기

Kubernetes는 컨테이너화된 애플리케이션을 자동으로 배포, 확장, 관리하는 오픈 소스 플랫폼이며, 다양한 환경에서 일관된 애플리케이션 실행을 가능하게 해주는 컨테이너 오케스트레이션 도구입니다.

 

Kubernetes에서의 containerd는 컨테이너를 실행하고 관리하는 역할을 하는 컨테이너 런타임으로, 컨테이너의 라이프사이클(생성, 실행, 종료)을 처리합니다. Kubernetes는 CRI(Container Runtime Interface)를 통해 containerd와 통신하여 파드 내 컨테이너를 조정하고 상태를 모니터링합니다.

 

Kubernetes 를 사용하기 전 containerd를 설치하고 확인하는 것을 테스트 해보도록 하겠습니다.

 

 


 

설치

containerd 설치 작업은 Rocky Linux 9.4 버전에서 테스트를 진행했습니다.

 

containerd는 github으로 프로젝트가 관리되고 있습니다.
containerd의 최신 릴리즈 노트를 확인 후 설치하고자 하는 버전 및 OS에 맞는 패키지를 wget 명령어로 다운로드 받습니다.

wget https://github.com/containerd/containerd/releases/download/v1.7.21/containerd-1.7.21-linux-amd64.tar.gz

# wget https://github.com/containerd/containerd/releases/download/v1.7.21/containerd-1.7.21-linux-amd64.tar.gz
--2024-09-05 08:22:56--  https://github.com/containerd/containerd/releases/download/v1.7.21/containerd-1.7.21-linux-amd64.tar.gz
Resolving github.com (github.com)... 20.200.245.247
Connecting to github.com (github.com)|20.200.245.247|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://objects.githubusercontent.com/github-production-release-asset-2e65be/46089560/4cdd822a-9a57-4fde-a891-e5bb5e3693a8?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=releaseassetproduction%2F20240904%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20240904T232257Z&X-Amz-Expires=300&X-Amz-Signature=66ac189261e5205e2013370f0428faf9020156f0beaf112e8f8ec82714b1bd4d&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=46089560&response-content-disposition=attachment%3B%20filename%3Dcontainerd-1.7.21-linux-amd64.tar.gz&response-content-type=application%2Foctet-stream [following]
--2024-09-05 08:22:57--  https://objects.githubusercontent.com/github-production-release-asset-2e65be/46089560/4cdd822a-9a57-4fde-a891-e5bb5e3693a8?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=releaseassetproduction%2F20240904%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20240904T232257Z&X-Amz-Expires=300&X-Amz-Signature=66ac189261e5205e2013370f0428faf9020156f0beaf112e8f8ec82714b1bd4d&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=46089560&response-content-disposition=attachment%3B%20filename%3Dcontainerd-1.7.21-linux-amd64.tar.gz&response-content-type=application%2Foctet-stream
Resolving objects.githubusercontent.com (objects.githubusercontent.com)... 185.199.109.133, 185.199.111.133, 185.199.110.133, ...
Connecting to objects.githubusercontent.com (objects.githubusercontent.com)|185.199.109.133|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 47904009 (46M) [application/octet-stream]
Saving to: ‘containerd-1.7.21-linux-amd64.tar.gz’

containerd-1.7.21-linux-amd64. 100%[===================================================>]  45.68M  10.6MB/s    in 4.3s

2024-09-05 08:23:02 (10.6 MB/s) - ‘containerd-1.7.21-linux-amd64.tar.gz’ saved [47904009/47904009]

 

 

 

패키지를 /usr/local 경로에 압축 해제합니다.

tar Cxzvf /usr/local containerd-1.7.21-linux-amd64.tar.gz

# tar Cxzvf /usr/local containerd-1.7.21-linux-amd64.tar.gz
bin/
bin/ctr
bin/containerd
bin/containerd-shim-runc-v2
bin/containerd-shim-runc-v1
bin/containerd-shim
bin/containerd-stress

 

 

 

systemd를 통해 containerd를 시작하기 위해 containerd.service 파일을 다운로드 후 systemd 서비스 유닛 파일을 저장하는 /usr/local/lib/systemd/system/ 경로에 추가합니다.

wget https://raw.githubusercontent.com/containerd/containerd/main/containerd.service -P /usr/local/lib/systemd/system/

# wget https://raw.githubusercontent.com/containerd/containerd/main/containerd.service -P /usr/local/lib/systemd/system/
--2024-09-05 08:25:40--  https://raw.githubusercontent.com/containerd/containerd/main/containerd.service
Resolving raw.githubusercontent.com (raw.githubusercontent.com)... 185.199.110.133, 185.199.108.133, 185.199.111.133, ...
Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|185.199.110.133|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1251 (1.2K) [text/plain]
Saving to: ‘/usr/local/lib/systemd/system/containerd.service’

containerd.service             100%[===================================================>]   1.22K  --.-KB/s    in 0s

2024-09-05 08:25:40 (34.1 MB/s) - ‘/usr/local/lib/systemd/system/containerd.service’ saved [1251/1251]

 

 

 

 

systemctl 명령어를 사용하여 데몬 리로드 및 containerd를 시작합니다.

# systemctl daemon-reload
# systemctl enable --now containerd
Created symlink /etc/systemd/system/multi-user.target.wants/containerd.service → /usr/local/lib/systemd/system/containerd.service.

 

 

*** 2024-10-21 추가

Kubernetes 노드가 systemd 기반으로 관리되지만 containerd가 cgroupfs를 사용하면, 두 가지 cgroup 관리자가 충돌할 수 있습니다. 이로 인해 성능 저하, 리소스 관리 실패, 컨테이너의 불안정한 상태 등이 발생할 수 있으므로 systemd 기반의 cgroup 드라이버를 사용하도록 설정을 변경합니다.

 

우선 runc를 사용하여 systemd 기반의 cgroup-을 사용할 수 있도록 runc를 설치합니다.

[kubernetes] runc 설치하기

 

[kubernetes] runc 설치하기

[kubernetes] runc 설치하기Kubernetes는 컨테이너화된 애플리케이션을 자동으로 배포, 확장, 관리하는 오픈 소스 플랫폼이며, 다양한 환경에서 일관된 애플리케이션 실행을 가능하게 해주는 컨테이너

every-up.tistory.com

 

 

containerd 설정 파일을 만든 후 SystemdCgroup 옵션을 true로 변경합니다.

containerd를 재시작 후 적용합니다.

# containerd config default | tee /etc/containers/config.toml
# sed -i 's/SystemdCgroup = false/SystemdCgroup = true/' /etc/containers/config.toml

# systemctl restart containerd

 

 

해당 설정 적용 이후에 kubernetes 설치 시 충돌 관련 오류가 발생하지 않습니다.

 


설치 확인

여러 명령어를 사용하여 containerd가 정상적으로 설치되고 구동 중인지 확인합니다.

 

systemctl 명령어를 사용하여 containerd 서비스 데몬의 상태를 확인합니다.

# systemctl status containerd
● containerd.service - containerd container runtime
     Loaded: loaded (/usr/local/lib/systemd/system/containerd.service; enabled; preset: disabled)
     Active: active (running) since Thu 2024-09-05 08:26:51 KST; 9s ago
       Docs: https://containerd.io
    Process: 96710 ExecStartPre=/sbin/modprobe overlay (code=exited, status=0/SUCCESS)
   Main PID: 96711 (containerd)
      Tasks: 13
     Memory: 23.4M
        CPU: 191ms
     CGroup: /system.slice/containerd.service
             └─96711 /usr/local/bin/containerd

Sep 05 08:26:51 K8S-CN-001 containerd[96711]: time="2024-09-05T08:26:51.084327200+09:00" level=info msg="Start subscribing>
Sep 05 08:26:51 K8S-CN-001 containerd[96711]: time="2024-09-05T08:26:51.084492500+09:00" level=info msg="Start recovering >
Sep 05 08:26:51 K8S-CN-001 containerd[96711]: time="2024-09-05T08:26:51.084697700+09:00" level=info msg="Start event monit>
Sep 05 08:26:51 K8S-CN-001 containerd[96711]: time="2024-09-05T08:26:51.084760100+09:00" level=info msg="Start snapshots s>
Sep 05 08:26:51 K8S-CN-001 containerd[96711]: time="2024-09-05T08:26:51.084804600+09:00" level=info msg="Start cni network>
Sep 05 08:26:51 K8S-CN-001 containerd[96711]: time="2024-09-05T08:26:51.084843100+09:00" level=info msg="Start streaming s>
Sep 05 08:26:51 K8S-CN-001 containerd[96711]: time="2024-09-05T08:26:51.085571800+09:00" level=info msg=serving... address>
Sep 05 08:26:51 K8S-CN-001 containerd[96711]: time="2024-09-05T08:26:51.085782700+09:00" level=info msg=serving... address>
Sep 05 08:26:51 K8S-CN-001 containerd[96711]: time="2024-09-05T08:26:51.086589400+09:00" level=info msg="containerd succes>
Sep 05 08:26:51 K8S-CN-001 systemd[1]: Started containerd container runtime.

 

 

 

containerd 명령어를 사용하여 containerd 버전을 확인합니다.

containerd --version

# containerd --version
containerd github.com/containerd/containerd v1.7.21 472731909fa34bd7bc9c087e4c27943f9835f111

 

 

 

containerd 소켓이 정상적으로 생성되었는지 확인합니다.
kubernetes 에서는 해당 경로의 소켓을 설정하여 컨테이너 런타임을 설정할 수 있습니다.

# ls -al /run/containerd/containerd.sock
srw-rw----. 1 root root 0 Sep 5 08:26 /run/containerd/containerd.sock

 

 

 


 

Rocky Linux 9.4 및 기타 OS에서 containerd를 설치하여 kubernetes에서 컨테이너 런타임으로 사용할 수 있습니다.

 

먼저, GitHub에서 최신 버전의 containerd 패키지를 다운로드하고, /usr/local 경로에 압축을 풀어 설치를 진행합니다.
그 후, containerd.service 파일을 /usr/local/lib/systemd/system/ 경로에 추가하고, systemctl을 사용해 데몬 리로드 후 containerd를 활성화합니다.
설치 후, systemctl status 및 containerd --version 명령어를 통해 containerd가 정상적으로 구동 중인지 확인할 수 있습니다.

 

지금까지 containerd 설치 및 설치 방법을 간단히 알아보는 시간을 가졌습니다....! 끝...!

 

 

유익하게 보셨다면 공감을 눌러주고, 댓글로 의견을 공유해 남겨주시면 감사하겠습니다!

 

 

 

[Reference]
https://kubernetes.io/ko/docs/setup/production-environment/container-runtimes/#containerd
https://github.com/containerd/containerd/blob/main/docs/getting-started.md

 

 

 

[Jenkins] Email 알림 받기


Jenkins를 통해 작업 상태에 대한 Email 알림을 받을 수 있습니다.
Jenkins 플러그인에서 Email 기능을 제공하는 Email Extension 플러그인을 사용하며 Email 알림에 대한 여러 설정을 할 수 있으며, 간단하게 Email 알림을 받을 수 있도록 설정해보겠습니다.

 

 


Email Extension 플러그인 설치

Jenkins 관리 -> Plugins -> Available plugins 메뉴에서 Email Extension 검색 후 플러그인을 설치합니다.


플러그인 설치 후 System Configuration 설정을 통해 Email 알림에 대힌 기본적인 설정을 할 수 있습니다.

 

 


Email System Configuration 설정

Jenkins 관리 -> System Configuration -> System 메뉴를 선택합니다.

 

 

Extended E-mail Notification 설정에서 Email 관련 설정을 진행합니다.
SMTP server 및 SMTP Port는 설정하고자 하는 Email 서버의 정보를 입력합니다.

Credentials는 Email 알림을 발송하는 계정의 정보를 입력합니다.


Gmail인 경우 Gmail 앱 비밀번호를 통해 Gmail API를 사용할 수 있으며 계정명과 Gmail 앱 비밀번호를 Username, Password 값에 각각 입력 후 저장 및 적용합니다.

 

Gmail 앱 비밀번호 발급 방법은 아래 링크를 참고하시기 바랍니다.
https://every-up.tistory.com/81

 

[기타] Gmail 앱 비밀번호 생성하기

[기타] Gmail 앱 비밀번호 생성하기Gmail 앱 비밀번호는 2단계 인증이 설정된 Google 계정에서 앱이나 기기가 Gmail API에 접근할 수 있도록 생성된 전용 비밀번호입니다. 보안 설정을 통해 Gmail 앱 비밀

every-up.tistory.com

 

 


Jenkins 코드

Email Extension 플러그인 설치를 통해 emailext 기능을 Jenkins에서 사용할 수 있게 되었습니다.
emailext은 기본적인 Email 제목, Email 내용, Email 수신자 등의 정보를 정의할 수 있으며 Email을 보낼 수 있습니다.

pipeline {
    agent any

    stages {
        stage('Mail-Test') {
            steps {
                emailext (
                    subject: "TEST Subject",
                    body: "Test Message",
                    to: "test@test.com"     
                )
            }
        }
    }

}
  • subject : Email 제목
  • body : Email 내용
  • to : Email 수신자 (optional)

해당 코드를 추가하여 Email 알림 테스트를 진행해보도록 하겠습니다.

 

 


Email 테스트

pipeline 실행이 완료되면 수신자(to) 주소로 Email이 발송됩니다.


설정한 emailext 기능의 내용으로 Email 제목 및 내용이 수신되었습니다.
해당 기능을 통해 다양한 메일 제목 및 내용과 수신자들에게 Email을 보낼 수 있습니다.

 

 


응용

 

환경 변수 사용

Email 제목 및 내용에 환경 변수 값을 추가하여 작업에 대한 구분을 Email 제목 및 내용을 통해 확인할 수 있습니다.

subject: "[{env.JOB_NAME}] [${env.TAG_NAME}] [${env.BUILD_ID}]"

 

mimType 변경

text/html 등의 타입으로 변경하여 Email 내용을 html 및 기타 형식으로 변경 후 Email을 보낼 수 있습니다.

mimeType: 'text/html'

 

Email 수신자 설정

수신자, 참조, 숨은 참조 설정을 할 수 있습니다.

to : 'test1@test.com, cc:test2@test.com, bcc:test3@test.com'

 

기타

  • 성공 실패 여부에 따른 이메일 전송
  • 첨부 파일 전송
  • 수신자 목록 관리

 


 

Jenkins에서 Email Extension 플러그인을 설치하고, System Configuration 설정을 통해 이메일 알림을 구성할 수 있습니다.


emailext 기능을 사용하여 이메일 제목, 내용, 수신자 등을 설정하고 Pipeline 코드에 추가하여 작업 상태에 대한 이메일 알림을 받을 수 있습니다. 환경 변수를 사용하여 작업에 대한 정보를 이메일 제목 및 내용에 포함시킬 수 있으며, 이메일의 mimType을 변경하여 HTML 형식의 이메일을 보낼 수도 있습니다. 또한, 수신자, 참조, 숨은 참조 설정을 통해 다양한 이메일 수신자를 지정할 수 있습니다.


이 외에도 성공, 실패 여부에 따른 이메일 전송, 첨부 파일 전송, 수신자 목록 관리 등의 기능을 활용할 수 있습니다.

 

지금까지 Jenkins에서 Email Extension 플러그인을 사용하여 이메일 알림을 설정하는 방법에 대해 알아보는 시간을 가졌습니다...! 끝...!

 

 

유익하게 보셨다면 공감을 눌러주고, 댓글로 의견을 공유해 남겨주시면 감사하겠습니다!

 

 

 

[Reference]
https://www.jenkins.io/doc/pipeline/steps/email-ext/

 

 

 

[기타] Gmail 앱 비밀번호 생성하기

Gmail 앱 비밀번호는 2단계 인증이 설정된 Google 계정에서 앱이나 기기가 Gmail API에 접근할 수 있도록 생성된 전용 비밀번호입니다. 보안 설정을 통해 Gmail 앱 비밀번호를 생성할 수 있으며 생성하는 방법을 알아보도록 하겠습니다.

 

 


Gamil 앱 비밀번호 생성

Gmail 로그인 후 계정의 보안 설정에서 2단계 인증 설정에 들어갑니다.

 

 

2단계 인증이 이미 설정되어 있는 경우 2단계 인증 완료 후 페이지가 넘어갑니다.

2단계 인증 설정에서 아래 항목을 확인해보면 앱 비밀번호 메뉴를 확인할 수 있으며 해당 메뉴를 선택합니다.

 

 

기존에 생성되어 있는 앱 비밀번호를 확인할 수 있으며, 신규로 생성할 경우에는 앱 비밀번호 이름 입력 후 만들기 버튼으로 생성 가능합니다.

 

 

만들기를 통해 신규 생성된 앱 비밀번호는 총 16자리로 구성되어 있습니다.

 

 

이제 생성 완료된 앱 비밀번호를 사용하여 Gmail API를 사용할 수 있습니다.

 


 

Gamil 앱 비밀번호를 사용하여 자동화된 스크립트나 백엔드 서버 등에서 이메일을 전송할 수 있으며,
모바일 애플리케이션에서도 이메일 기능을 제공할 수 있습니다.

Gmail 서비스 및 기능을 다양한 곳에서 활용할 수 있도록 Gamil 앱 비밀번호를 생성하여 사용하기 바랍니다

 

 

 

지금까지 Gmail 앱 비밀번호를 생성하는 방법에 대해 알아보는 시간을 가졌습니다....! 끝...!

 

 

유익하게 보셨다면 공감을 눌러주고, 댓글로 의견을 공유해 남겨주시면 감사하겠습니다!

 

 

 

[Jenkins] Azure Storage 업로드


Azure Blob Storage는 대규모 비정형 데이터를 저장하고 관리하는 확장 가능하고 고가용성의 객체 스토리지 서비스입니다.

 

Jenkins에서 Azure Storage를 사용하여 빌드 아티팩트를 안전하게 저장하고 관리할 수 있으며, Azure Blob Storage를 통해 대규모 데이터 처리를 지원할 수 있습니다. 이를 통해 CI/CD 파이프라인의 효율성을 높이고, 데이터 백업 및 복구를 간소화할 수 있습니다. Jenkins를 통해 빌드 완료된 파일 또는 업로드가 필요한 파일을 Azure Storage에 업로드 해보는 작업을 진행해보겠습니다.

 

Azure Blob Storage의 생성 및 기초 사용법은 아래 글을 참고해주세요.
https://every-up.tistory.com/78

 

[Azure] Blob Storage 생성 및 기초 사용법

[Azure] Blob Storage 생성 및 기초 사용법Azure Blob Storage는 대규모 비정형 데이터(이미지, 동영상, 로그 등)를 저장하고 관리할 수 있는 Microsoft Azure의 객체 스토리지 서비스입니다. 세 가지 저장소 유

every-up.tistory.com

 

 


Azure Storage 플러그인 설치

Jenkins 관리 -> Plugins -> Available plugins 메뉴에서 Azure Storage plugin 검색 후 플러그인을 설치합니다.

해당 플러그인을 통해 Azure Storage에 접근할 수 있는 Storage Account Key를 저장하여 사용할 수 있습니다.

 

 


Azure Storage 접근 Credentials 설정

Jenkins 관리 -> Credentials 메뉴에서 global Domain 선택 후 Add credentials 을 선택합니다.

 

 

Kind를 Azure Storage를 선택 후 Storage Account Name, Storage Account Key, Blob EndPoint URL, ID 값을 모두 입력합니다.


Blob EndPoint URL 값은 스토리지 계정이 포함된 URL 정보 "https://{스토리지 계정}.blob.core.windows.net/"를 입력해주시면 됩니다.

 

 


Jenkins 코드

Jenkins에서는 withCredentials 기능을 통해 사전에 설정한 Credentials 값을 불러와 Azure Storage에 접근할 수 있습니다.
Azure CLI 로그인 작업을 통해서도 Azure Storage를 관리할 수 있지만 로그인 작업이 필요하며 명령어가 더 복잡하므로 Storage Account Key를 Credentials 설정을 통해 불러와 사용하였습니다.

 

Environment 정의

Azure Storage에 접근 후 파일을 업로드하기 위해 환경 변수를 정의합니다.

environment {
  AZURE_STORAGE_NAME = "스토리지 계정 이름"
  AZURE_CONTAINER_NAME = "스토리지 계정내 컨테이너 이름"
}

스토리지 계정 및 컨테이너 이름을 사전에 환경 변수로 정의 후 az 명령어로 파일 업로드 시 사용합니다.

 

 

업로드 명령어 정의 및 실행

withCredentials 기능을 사용하여 AZURE_STORAGE ID의 Credentials 사용하도록 정의 하였습니다.
Credentials에 저장된 Storage Account Key 값은 STORAGE_KEY 이름으로 사용할 수 있습니다.

 

az storage blob upload 명령어를 통해 STORAGE_KEY Storage Account Key 값을 사용하여 Azure Storage에 접근할 수 있으며, 업로드하고자 하는 UPLOAD_FILE 파일을 지정하여 TEST_DIR/ 경로에 업로드 되도록 설정하였습니다.

 

withCredentials([azureStorage(credentialsId: "AZURE_STORAGE",
                          storageAccountNameVariable : "STORAGE_NAME",
                          storageAccountKeyVariable : "STORAGE_KEY"
)]) {
  script {
    def COMMAND_AZURE_STORAGE_UPLOAD = """
    az storage blob upload --overwrite \
      --account-name ${AZURE_STORAGE_NAME} \
      --account-key ${STORAGE_KEY} \
      --container-name ${AZURE_CONTAINER_NAME} \
      --file ${UPLOAD_FILE} \
      --name TEST_DIR/${UPLOAD_FILE} 
    """.stripIndent().trim().replaceAll("\n", " ")
    bat script: COMMAND_AZURE_STORAGE_UPLOAD
  }
}

 

bat 스크립트로 명령어를 실행하면 정의된 명령어가 실행되어 파일을 Azure Storage에 업로드 합니다.

 

단순히 파일을 업로드하는 작업만 진행하였지만, Storage Account Key 값을 사용하여 Azure Storage의 다양한 기능들을 제어할 수 있습니다.

 


업로드 확인

Azure 콘솔을 통해 Azure Storage에 업로드된 파일을 확인합니다.

az storage blob upload 명령어의 옵션 중 --name 옵션에 따라 디렉토리 및 파일 이름 정보로 파일이 업로드 됩니다.

 

 


 

Jenkins에서 Azure Storage 플러그인을 설치하고, Credentials 설정을 통해 Azure Storage에 접근하여 파일을 업로드할 수 있습니다. withCredentials 기능을 사용해 Storage Account Key를 불러와 az storage blob upload 명령어로 파일을 업로드하며 업로드 후 Azure 콘솔에서 파일을 확인할 수 있습니다.

 

Jenkins CI/CD 자동화 코드를 통해 Azure Storage에 파일을 업로드만 하였지만 다양한 Storage 기능을 활용하여 사용하시기 바랍니다.

 

지금까지 Jenkins에서 Azure Storage를 사용하는 방법에 대해 알아보는 시간을 가졌습니다....! 끝...!

 

 

유익하게 보셨다면 공감을 눌러주고, 댓글로 의견을 공유해 남겨주시면 감사하겠습니다!

 

 

 

[Reference]
https://plugins.jenkins.io/windows-azure-storage

 

 

 

+ Recent posts