728x90

도커(Docker)를 사용하여 애플리케이션을 컨테이너화할 때, 컨테이너 내부에서 환경변수를 설정하는 것은 매우 중요함

환경변수를 통해 애플리케이션의 설정값을 동적으로 관리할 수 있으며, 이는 배포 및 운영 환경에서 매우 유용함

도커 컨테이너 내부에서 환경변수를 설정하는 여러 가지 방법이 있음

 

도커 컨테이너 실행 시점에 환경변수 설정하는 방법

1. docker run 명령어에 -e 옵션 사용

docker run -e MY_VAR=some_value my_image

 

2. docker run 명령어에 --env-file 옵션 사용

# .env 파일 예시
MY_VAR1=some_value1
MY_VAR2=some_value2
docker run --env-file .env my_image

 

도커 이미지 생성 시 환경변수 설정하는 방법

1. 도커파일에 ENV 지시어 사용

# Dockerfile 예시
FROM python:3.8-slim

ENV MY_VAR=some_value

 

2. 도커컴포즈 파일에서 환경변수 설정

# 환경변수 직접 설정
version: '3.8'
services:
  my_service:
    image: my_image
    environment:
      - MY_VAR=some_value
# .env 파일 사용
version: '3.8'
services:
  my_service:
    image: my_image
    env_file:
      - .env

 

3. 컨테이너 내부에서 스크립트를 사용하여 설정

# start.sh 예시
#!/bin/bash
export MY_VAR=some_value
exec "$@"
# Dockerfile 예시
FROM python:3.8-slim

COPY start.sh /start.sh
RUN chmod +x /start.sh
ENTRYPOINT ["/start.sh"]
CMD ["python", "app.py"]

exec "$@"에서 "$@"는 스크립트에 전달된 모든 인수를 의미함

위의 도커이미지로 도커컨테이너 실행 시 "docker run my_image python app.py" 라는 명령어를 수행했다면, 

exec "$@"exec python app.py 로 대체되어 동작함

 

4. 자주 변경되는 환경변수 도커파일 변경 없이 설정하는 방법

--build-arg를 활용하면 빌드 시점에 변수로 값을 주입할 수 있음

하지만 이는 빌드 과정에서만 사용되고 도커이미지 내에 환경변수로는 등록되지 않기 때문에, ENV 지시어를 사용해 도커이미지 환경변수로 등록해줘야 함

# Dockerfile 예시
FROM python:3.8-slim

# 빌드 시점 변수 받기
ARG MY_VAR

# 런타임 환경 변수로 등록
ENV MY_VAR=${MY_VAR}

RUN echo "MY_VAR is $MY_VAR"
docker build --build-arg MY_VAR=some_value -t my_image .

 

728x90
728x90

prometheus_client 라이브러리는 Prometheus와 함께 사용할 수 있는 클라이언트 라이브러리로, 애플리케이션의 메트릭을 수집하고 노출하는 데 사용됨

이 라이브러리를 통해 다양한 유형의 메트릭을 생성하고 관리할 수 있음

이 라이브러리에서 메트릭 수집을 위하여 주로 사용되는 Counter, Gauge, Histogram 클래스에 대해 알아봄

Counter

Counter는 단조 증가하는 메트릭을 나타냄

주로 이벤트의 발생 횟수를 측정하는 데 사용됨

한 번 증가하면 줄어들지 않음

from prometheus_client import Counter

# Counter 메트릭 생성
requests_total = Counter('requests_total', 'Total number of requests')

# 메트릭 증가
requests_total.inc()  # 1 증가
requests_total.inc(5)  # 5 증가

Gauge

Gauge는 값이 증가하거나 감소할 수 있는 메트릭을 나타냄

현재 온도, 메모리 사용량 등과 같이 상태를 나타내는 데 사용됨

from prometheus_client import Gauge

# Gauge 메트릭 생성
temperature = Gauge('temperature', 'Current temperature')

# 메트릭 설정 및 변경
temperature.set(25.3)  # 값 설정
temperature.inc()      # 1 증가
temperature.dec(2.3)   # 2.3 감소

Histogram

Histogram은 값의 분포를 관찰하는 데 사용됨

요청 시간, 응답 크기 등의 분포를 측정하는 데 유용함

from prometheus_client import Histogram

# Histogram 메트릭 생성
request_latency = Histogram('request_latency_seconds', 'Request latency')

# 메트릭 관찰
request_latency.observe(0.5)  # 0.5초의 지연 시간 관찰
request_latency.observe(1.2)  # 1.2초의 지연 시간 관찰

종합 예제

Counter, Gauge, Histogram을 사용하여 간단한 웹 애플리케이션에서 메트릭을 수집하고 노출하는 예제

 
from prometheus_client import Counter, Gauge, Histogram, start_http_server
import time
import random

# 메트릭 정의
REQUESTS = Counter('requests_total', 'Total number of requests')
TEMPERATURE = Gauge('temperature', 'Current temperature')
LATENCY = Histogram('request_latency_seconds', 'Request latency')

# 메트릭 수집 및 노출 시작
start_http_server(8000)

while True:
    # Counter 증가
    REQUESTS.inc()

    # Gauge 설정
    TEMPERATURE.set(random.uniform(20.0, 30.0))

    # Histogram 관찰
    latency = random.uniform(0.1, 1.0)
    LATENCY.observe(latency)

    # 대기 시간
    time.sleep(1)

결론

  • Counter: 단조 증가 메트릭
  • Gauge: 값이 증가하거나 감소할 수 있는 메트릭
  • Histogram: 값의 분포를 관찰하는 메트릭

이러한 구성 요소를 사용하여 애플리케이션의 다양한 성능 지표를 수집하고 Prometheus 서버에 노출할 수 있음

728x90
728x90

oh my zsh 설치

sh -c "$(curl -fsSL https://raw.github.com/robbyrussell/oh-my-zsh/master/tools/install.sh)"

 

테마 변경

ohmyzsh에서 제공하는 테마는 여기에서 확인 가능 

테마 변경 한 후에 터미널을 재시작하면 테마가 적용됨

vi ~/.zshrc
```
ZSH_THEME="robbyrussell" # 기본 테마
```

 

728x90
728x90

zsh 업그레이드

Mac은 기본적으로 zsh가 설치되어있음

zsh 버전을 확인하고, 필요한 경우 업그레이드 진행

업그레이드 하고 나면 터미널을 재시작해야 신규 버전이 로드됨

zsh --version
brew update
brew upgrade zsh

 

기본 shell 변경

# 현재 shell 확인
echo $SHELL

# 현재 zsh 경로 확인
which zsh

# 사용가능한 shell 경로 관리하는 파일 맨 아래에 현재 zsh 경로 추가
vi /etc/shells

# 기본 쉘 현재 zsh로 변경
chsh -s `which zsh`

 

728x90
728x90

테마를 설정하려면 먼저 vscode settings 들어가야 함

  • macOS : ⌘ + ,
  • Windows : Ctrl + ,
  • Linux : Ctrl + ,

1. 검색란에 "color theme"를 검색

2. 적용 범위 선택

  • User : 모든 창에 적용
  • Remode : 원격 접속 창에 적용
  • Workspace : 현재 창에만 적용

3. 테마 선택

728x90

'etc > vscode' 카테고리의 다른 글

vscode 언어 별로 설정 다르게 하기  (0) 2024.04.25
vscode PYTHONPATH 설정 (feat launch.json)  (0) 2024.03.31
728x90

멀티-컨테이너 팟(Multi-container pod)은 쿠버네티스(Kubernetes)에서 여러 컨테이너가 함께 배치되어 서로 긴밀하게 협력하며 실행되는 구조를 말함

이러한 팟은 단일 컨테이너로 구성된 팟과는 달리, 여러 컨테이너가 동일한 네트워크 공간을 공유하고 저장소 리소스에도 접근할 수 있음

멀티-컨테이너 팟을 사용하면 각 컨테이너는 자신의 역할에 집중할 수 있고, 유지보수가 쉬워지며, 시스템의 전체적인 안정성과 확장성을 향상할 수 있음

 

아래에는 멀티-컨테이너 팟을 구성하기 위한 대표적인 세 가지 패턴을 정리함

각 패턴은 특정 상황에 맞추어 설계되었으며, 쿠버네티스 환경에서 효율적인 컨테이너 관리와 운영을 가능하게 함

 

사이드카(Sidecar) 패턴

Sidecar 패턴은 주요 애플리케이션 컨테이너에 추가적인 기능을 제공하기 위해 별도의 사이드카 컨테이너를 추가하는 패턴

주요 애플리케이션은 자체적으로 동작하며, 사이드카 컨테이너는 이를 보조하거나 보완하는 역할을 수행함

예를 들어, 로그 수집, 파일 동기화, 구성 업데이트 등의 기능을 처리할 수 있음

이렇게 별도의 사이드카 컨테이너를 두어 메인 컨테이너의 기능을 분리하면, 각 컨테이너를 독립적으로 업데이트하고 재사용할 수 있음

 

앰배서더(Ambassader) 패턴

앰배서더 패턴은 외부 시스템과의 통신을 관리하기 위해 사용함

이 패턴에서 앰배서더 컨테이너는 프록시 서버처럼 작동하여 메인 컨테이너가 외부 서비스와 통신할 때 중계 역할을 함

예를 들어, 데이터베이스나 외부 API에 대한 접근을 캡슐화하여 메인 컨테이너의 코드 변경 없이도 외부 연결을 쉽게 수정하거나 업그레이드할 수 있음

 

어댑터(Adapter) 패턴

어댑터 패턴은 외부 라이브러리나 도구를 사용하기 쉽게 만들어주는 패턴

어댑터 패턴에서는 어댑터 컨테이너가 메인 컨테이너로부터 출력되는 데이터를 수정하거나 변환하는 역할을 함

예를 들어, 메인 컨테이너에서 생성된 로그 데이터를 특정 형식으로 변환하여 로그 관리 시스템에 전달할 수 있음

728x90
728x90

쿠버네티스(Kubernetes) 환경에서 작업을 효율적으로 관리하기 위해 여러 클러스터와 네임스페이스를 다뤄야 하는 경우가 있음

kubeconfig 파일이란?

kubeconfig 파일이란 쿠버네티스 클라이언트인 kubectl이 클러스터와 통신하기 위해 사용하는 설정 파일

이 파일에는 클러스터의 접속 정보, 사용자 인증 정보, 사용 중인 컨텍스트 등이 저장됨

여러 개의 클러스터와 사용자, 네임스페이스를 갖고 있는 경우 각각을 별도의 파일로 관리하는 대신 한 파일에 모두 통합할 수도 있음

kubeconfig파일 경로는 일반적으로 ~/.kube/config에 위치함

환경변수에 kubeconfig파일 경로 여러 개 등록하기

export KUBECONFIG=~/.kube/config:~/.kube/config-dev

환경변수에 파일 경로를 여러 개 등록해줄 수 있음

k9s에서 context 리소스를 검색해보면 환경변수로 등록한 컨텍스트들을 확인할 수 있음

파일 병합하기

환경변수에 파일 여러 개를 등록할 수 있지만, 파일 하나로 관리하고 싶으면 아래와 같이 파일을 병합할 수 있음

여러 kubeconfig 파일을 하나로 통합하는 가장 간단한 방법은 kubectl config view --flatten 명령어를 사용하는 것

이 명령어는 현재 KUBECONFIG 환경변수에 설정된 모든 파일을 병합하여 출력함

# 여러 config파일 병합하기
kubectl config view --flatten > merged-kubeconfig.yaml

# 병합한 파일 KUBECONFIG 환경변수로 등록
export KUBECONFIG=~/merged-kubeconfig.yaml

컨텍스트 선택하기

여러 컨텍스트 중 사용할 컨텍스트를 선택하려면 다음과 같이 하면 됨

kubectl config use-context my-context-name

 

728x90

'Kubernetes' 카테고리의 다른 글

쿠버네티스 네트워크 - 1. CNI  (0) 2024.07.07
Multi-container pod 패턴  (0) 2024.05.07
쿠버네티스의 마스터노드와 워커 노드  (0) 2024.04.28
CNI란?  (0) 2024.04.28
쿠버네티스 소개  (0) 2024.04.28
728x90

쿠버네티스 아키텍처는 크게 마스터 노드(master node)와 워커 노드(worker node)로 구분됨

마스터노드

마스터 노드는 쿠버네티스 클러스터의 컨트롤플레인(control plane)을 구성

주요 구성요소는 다음과 같음

  1. API 서버 (kube-apiserver)
    • 클러스터의 중심 통신 허브로, 모든 관리 명령이 API 서버를 통해 수행됨
    • 쿠버네티스 API를 통해 클러스터와 통신함
  2. 클러스터 저장소 (etcd)
    • 모든 클러스터 데이터를 저장하는 분산 키-값 저장소
    • 클러스터의 상태를 유지하며, 고가용성을 보장하기 위해 사용됨
  3. 컨트롤러 매니저 (kube-controller-manager)
    • 다양한 컨트롤러를 실행하여 클러스터 상태를 원하는 상태로 유지함
    • 예를 들어, 노드가 실패하면 해당 노드의 작업을 다른 노드로 이전
  4. 스케줄러 (kube-scheduler)
    • 새로 생성된 파드를 적절한 워커 노드에 할당하는 역할을 함
    • 리소스 요구 사항과 기타 제약 조건을 고려하여 배치 결정을 내림

워커 노드

워커 노드는 실제 컨테이너화된 애플리케이션을 실행하는 서버

주요 구성요소는 다음과 같음

  1. kubelet
    • 각 노드에서 실행되며, 마스터 노드의 지시에 따라 컨테이너를 시작하고 관리함
    • 파드의 건강 상태를 모니터링하고 보고함
  2. 컨테이너 런타임
    • 컨테이너를 실행하는 역할을 함
    • Docker, containerd, CRI-O 등이 있음
  3. 쿠브 프록시 (kube-proxy)
    • 노드의 네트워크 프록시 및 로드 밸런서 역할을 하며, 파드 간 네트워크 통신을 가능하게 함

동작 순서

쿠버네티스 클러스터는 다음과 같은 방식으로 동작함

  • 사용자 또는 자동화 도구가 API 서버에 명령을 제출
  • API 서버는 이 명령을 etcd에 저장하고, 상태를 갱신함
  • 컨트롤러 매니저가 변경 사항을 감지하고, 필요한 조치를 취함 (예: 파드 재배치)
  • 스케줄러가 새 파드를 적절한 워커 노드에 할당함
  • 워커 노드의 kubelet이 API 서버로부터 파드 생성 명령을 받고, 컨테이너 런타임을 통해 컨테이너를 시작함
728x90

'Kubernetes' 카테고리의 다른 글

Multi-container pod 패턴  (0) 2024.05.07
쿠버네티스 Config 파일 여러 개 관리  (0) 2024.04.30
CNI란?  (0) 2024.04.28
쿠버네티스 소개  (0) 2024.04.28
쿠버네티스와 마이크로서비스 아키텍처  (0) 2024.04.07
728x90

CNI란?

CNI는 컨테이너에 네트워크 인터페이스를 할당하고, 컨테이너를 네트워크에 연결하는 데 필요한 기본적인 작업을 수행하는 플러그인의 집합

쿠버네티스, Mesos, OpenShift와 같은 컨테이너 오케스트레이션 시스템에서 사용됨

CNI는 각 컨테이너가 시작될 때 네트워크 플러그인을 호출하여 네트워크 설정을 자동화하고, 컨테이너가 삭제될 때 이 설정을 정리함

 

CNI는 컨테이너화된 환경에서 네트워킹을 간편하게 만들어 주며,

다양한 요구 사항에 맞춰 네트워크를 구성하고 관리할 수 있는 유연성을 제공하기 때문에 

많은 개발자와 시스템 관리자가 CNI를 선호함

CNI의 주요 기능

  1. 네트워크 인터페이스 생성 및 관리
    • 컨테이너에 필요한 네트워크 인터페이스를 생성하고, 컨테이너를 네트워크에 연결하는 기능을 제공
  2. 네트워크 리소스 할당
    • IP 주소, 라우팅 규칙 등의 네트워크 리소스를 컨테이너에 할당
  3. 플러그인 기반 구조
    • 다양한 네트워킹 요구사항을 충족시키기 위해 여러 종류의 CNI 플러그인을 지원
    • 이는 사용자가 필요에 따라 플러그인을 선택하거나 교체할 수 있게 해줌

CNI 사용의 이점

  • 표준화 및 호환성: CNI는 컨테이너 네트워킹을 위한 산업 표준을 제공하여 다양한 오케스트레이션 플랫폼에서 호환되는 방식으로 네트워킹을 구현할 수 있도록 함
  • 유연성: 다양한 CNI 플러그인을 통해, 네트워크의 성능, 보안, 격리 등을 사용자의 요구에 맞춰 조정할 수 있음
  • 간소화된 관리: CNI는 네트워크 설정을 자동화하고, 컨테이너의 생명주기와 밀접하게 연동되므로 네트워크 관리를 간소화함

CNI 플러그인 예시

  • Calico: 보안과 성능을 강화한 네트워킹 및 네트워크 정책을 제공
  • Flannel: 간단하면서도 확장성 있는 네트워킹 솔루션을 제공
  • Weave Net: 네트워크 분할을 견딜 수 있는 견고한 네트워크 연결을 제공

 

728x90
728x90

쿠버네티스란?

쿠버네티스는 컨테이너화된 애플리케이션의 배포, 확장 및 운영을 자동화하기 위해 설계된 시스템

컨테이너는 독립적으로 실행되며, 다양한 컴퓨팅 환경에서 일관된 작동을 보장함

쿠버네티스는 이러한 컨테이너들을 효율적으로 관리하며, 사용자가 수많은 컨테이너를 쉽게 다룰 수 있도록 도움

 

쿠버네티스는 복잡한 컨테이너 관리를 단순화하며, 대규모 시스템의 민첩성과 효율성을 높임

또한 다양한 클라우드 환경(온프레미스 포함)에서의 이식성과 호환성을 제공함

이로 인해 개발자와 시스템 관리자는 더욱 집중적으로 애플리케이션 개발과 운영에 집중할 수 있게 됨

쿠버네티스의 주요 기능

  1. 자동화된 롤아웃과 롤백
    • 쿠버네티스를 사용하면 애플리케이션을 점진적으로 업데이트하거나 이전 버전으로 롤백 가능
    • 서비스 중단 없이 변경사항을 적용할 수 있음
  2. 부하 분산
    • 애플리케이션의 트래픽을 분석하여, 필요에 따라 트래픽을 여러 인스턴스에 분산시키는 로드 밸런싱을 제공
  3. 자동화된 빈 패킹(Automatic bin packing)
    • 쿠버네티스는 애플리케이션의 요구 사항과 사용 가능한 인프라 자원을 고려하여, 컨테이너를 자동으로 스케줄링하고 최적화된 방식으로 배치
  4. 자동 복구(Self-healing)
    • 실패한 컨테이너는 자동으로 재시작되고, 비정상적인 컨테이너는 교체되며, 정의된 사용자 정책에 따라 다운된 노드에서 컨테이너를 다시 배치
  5. 비밀과 구성 관리
    • 쿠버네티스는 암호, OAuth 토큰, SSH 키와 같은 중요 정보를 보안적으로 관리하고, 애플리케이션 구성을 쉽게 업데이트하고 관리할 수 있음

쿠버네티스 커뮤니티

728x90

+ Recent posts