딸기말차

[MSA] 13. alias, cordon, drain, AWS 활용 본문

Bootcamp/MSA

[MSA] 13. alias, cordon, drain, AWS 활용

딸기말차 2023. 10. 26. 10:44

엔코아 플레이데이터(Encore Playdata) Backend 2기 백엔드 개발 부트캠프 (playdata.io)

 

백엔드 개발 부트캠프

백엔드 기초부터 배포까지! 매력있는 백엔드 개발자 포트폴리오를 완성하여 취업하세요.

playdata.io


1. 가상머신 실행 자동화를 위한 batch파일 작성

"C:\Program Files\Oracle\VirtualBox\VBoxManage.exe" startvm "cent-m" --type headless
"C:\Program Files\Oracle\VirtualBox\VBoxManage.exe" startvm "cent-w1" --type headless
"C:\Program Files\Oracle\VirtualBox\VBoxManage.exe" startvm "cent-w2" --type headless

해당 내용을 메모장 등 텍스트 에디터에 작성해 batch 파일로 생성한 후 실행하면, 매번 일일이 centOS를 실행할 필요가 사라진다.

 

vm_auto_start.bat


2. sed 명령어를 통한 문자열 변경 및 process id 확인

# 디렉토리 명 변경
mv [기존 디렉토리명] [바꿀 디렉토리명]
mv k8s workspace

디렉토리명 변경

# 작성된 내용 확인
cat ./echo-hname.yaml

cat을 통한 내용확인

# replicas: 3 로 되어있는 문자열 패턴을 replicas: 6 로 변경
sed -i 's/replicas: 3/replicas: 6/' ./echo-hname.yaml

문자열 내용 변경, 변경사항 확인

해당 명령어를 실행 후 내용을 보면 replicas: 3 으로 되어있던 yaml 파일이 replicas: 6으로 변경된 것을 확인할 수 있다.

# nginx-pod 컨테이너 접속
kubectl exec -it nginx-pod bash

컨테이너 내부 접속

# nginx process id 확인
cat /run/nginx.pid

pid 확인

# 파일의 생성시간 확인
ls -l /run/nginx.pid

파일 생성시간 확인

# 서버의 시간 확인
date

서버 시간확인

작업 도중 시간동기화가 필요한 경우, 해당 키워드를 통해 해당 서버의 시간을 우선 확인해보고 진행하면된다.


3. Alias 활용

# sh 파일 생성
vim test.sh

#!/bin/bash
i=1; while true; do sleep 1; echo $((i++)) `curl --silent 172.16.103.133 | grep title` ; done

sh 파일 작성

# sh 파일 실행
sh ./test.sh

sh 파일 실행

# nginx-pod 삭제
kubectl delete pods nginx-pod

# 삭제한 pod 확인
kubectl get pods

pod 삭제

# 명령어를 간추려쓰기위해 환경파일 변경
vim ~/.bashrc

# kubectl -> k
alias k='kubectl'
alias info='kubectl get pods -o wide'

alias 등록

# 변경한 환경설정 파일 적용
source ~/.bashrc

변경사항 적용

명령어를 변경한 후 정상적으로 동작하는지 확인해보았다.

등록한 alias 확인

# alias 를 사용해 pod 생성
k apply -f ./echo-hname.yaml

파드 생성

# scale 기능을 통해 생성한 파드의 복제품 생성
k scale deployment echo-hname --replicas=8

복제 생성

# .bashrc 접근
vim ~/.bashrc

# kubectl get pods -o wide 의 결과 중 필요한 것만 가져와 alias 등록
alias info2='kubectl get pods -o=custom-columns=NAME:.metadata.name,IP:.status.podIP,STATUS:.spec.nodeName'

# 변경사항 적용
source ~/.bashrc

등록한 alias 확인

# replica 개수 변경
k scale deployment echo-hname --replicas=3

# 8개였던 replica 개수가 3개로 변경된 것 확인
info2

replica의 개수가 3으로 줄어든 것 확인


4. cordon, drain

# 연결 된 노드들 확인
kubectl get nodes

# cordon 
# 해당 노드를 pod가 할당되지 않게 스케줄되지 않은 상태로 표시 
kubectl cordon w2-k8s

스케줄 할당을 막은 상태

# 스케줄 되지 않게 변경한 노드 되돌리기
kubectl uncordon w2-k8s

다시 스케줄 가능하게 변경

 

# drain 명령어를 통해 해당 노드에 pod가 없는 상태로 만들기
# 해당 기능은 pod가 동작중이면 에러가 나기 때문에 동작중인 pod에 실행하기 위해선 ignore 옵션을 붙여야한다.
kubectl drain w2-k8s --ignore-daemonsets

w2-k8s 노드에 pod가 없는 상태로 만들었기 때문에, 기존에 실행중이던 pod들이 다 w1-k8s로 할당 된 것을 확인할 수 있다.


5. AWS 고정 IP 할당

1. 탄력적 IP 할당

탄력적 IP 할당

 

2. EC2 인스턴스와 탄력적 IP 연결

인스턴스와 IP 연결

인스턴스 선택에서 연결할 인스턴스를 선택하면 된다.


6. EC2 내에서 Docker 설치

# 도커 설치 및 설정
sudo yum install docker -y 
sudo systemctl enable --now docker

# 정상적으로 설치됐는지 확인
sudo systemctl status docker 

# 도커 그룹에 자기자신 집어넣기
sudo usermod -aG docker $USER

이후, exit를 통해 재실행하면 docker 명령어 실행 시 sudo를 붙이지 않아도 된다.

도커 설치 및 유저 등록

# 개인 저장소 설정 
docker pull registry:latest

개인 저장소 설정

# etc 폴더로 이동
cd /etc/docker

etc 에서 작업하기 위해서는 sudo를 붙여야한다.

설정을 추가하기 etc 폴더로 이동

# json 파일 생성
sudo vim daemon.json

도커는 기본적으로 https로 동작하는데, https가 아니라도 통과시켜달라는 설정을 추가한다.

http 접근도 허용하기 위한 설정

# 변경한 설정적용을 위한 docker restart
sudo systemctl restart docker

# 재시작 후 도커 상태 확인
sudo systemctl status docker

설정 적용을 위해 재시작, 상태 확인

# 이미지를 pull하며 컨테이너 생성
docker run --name personal-registry -d -p 5000:5000 registry

이미지 생성 및 확인

# 이미지 실행을 위한 Dockerfile 작성
cd ~
vim Dockerfile

Dockerfile 생성을 위해 경로 이동
Dockerfile 작성

# 도커 이미지 build
docker build -t encore/hello_docker .

테스트용 이미지 빌드

# 가지고있는 image 확인
docker images

# 새로 생성한 이미지를 registry에 밀어넣기
docker tag encore/hello_docker localhost:5000/hello_docker
docker push localhost:5000/hello_docker

# 확인을 위한 curl 날려보기
curl -X GET http://localhost:5000/v2/_catalog

push가 잘됐는지 확인

# 외부에서 접속하기 위한 AWS 방화벽 설정 (보안그룹 추가)

보안그룹 추가


7. EC2에 업로드한 Docker Image 가져오기

# master node에서 EC2 docker로 접근하기 위한 ip 등록
sudo vim /etc/hosts

etc의 hosts 접근
ec2의 public ip 등록

# master node에서도 http로도 접근 가능하게 설정
cd /etc/docker
vim daemon.json
{ "insecure-registries": ["docker-registry:5000"] }

# 적용을 위한 재시작
sudo systemctl restart docker

http로 접근가능하게 설정

# ec2에 업로드해둔 이미지를 가져오기
docker pull docker-registry:5000/hello_docker:latest

image pull


8. Service Gateway

보안과 로깅, 여러 서비스 호출에 걸친 사용자 추적 처럼 어느 서비스던 필요한 공통 된 요구사항이 있다고 가정한다면,

이 기능을 구현하려고 모든 개발팀이 독자적인 솔루션을 구축하는 것보단 하나의 마이크로서비스를 구축하여 모든 서비스에 일관되게 적용하면 될 것이다.

 

공통 라이브러리나 프레임워크를 사용해 기능을 각 서비스에 직접 구축할 수도 있지만, 해당 방법은 다음과 같은 문제가 생길 수 있다.

1. 서비스에 일관되게 구현하기 어렵다.
2. 보안과 로깅 같은 구현 책임을 개별 팀에게 전가하면 잘못 구현하거나 누락될 수 있따.
3. 모든 서비스에 걸쳐 강한 의존성을 만들 수 있다.

이러한 문제를 해결하기 위해 MSA 호출에 대한 필터와 라우터 역할을 할 수 있는 서비스를 추상화하여 만든 것이 Gateway 이다.

 

1. 서비스 게이트웨이 구현

정적 라우팅 (Static Routing)

서비스 게이트웨이는 URL과 API 경로로 서비스를 호출하는데, 모든 서비스에 대해 하나의 서비스 엔드포인트만 알면 되므로 개발이 편리해진다.

 

2. 동적 라우팅 (Dynamic routing)

서비스 게이트웨이는 모든 서비스 요청을 검사하고 요청 데이터를 기반으로 서비스를 호출한 클라이언트를 위한 지능적 라우팅을 수행할 수 있다.

예를들어, 같은 프로그램의 다른 버전이 존재할 때 어떤 유저 층엔 1번 버전을, 어떤 유저 층에는 2번 버전의 서비스 클러스터로 라우팅되게 할 수 있다.

 

3. 인증 (Authentication) 과 인가 (Authoriztion)

모든 서비스 호출이 서비스 게이트웨이로 라우팅 되기 때문에 서비스 게이트웨이는 클라이언트가 자신의 인증 여부를 확인할 수 있는 적합한 장소가 필요하다.

 

4. 지표 수집 (metirc collection) 과 로깅 (logging)

서비스 호출이 게이트웨이를 통과하기 때문에 서비스 게이트웨이를 지표와 로그를 수집하는데 사용할 수 있다.

또한, 사용자 요청에 대한 중요한 정보가 있는지 확인해 균일한 로깅을 보장할 수 있다.

서비스 게이트웨이를 사용하면 서비스 호출 회수 및 응답 시간처럼 많은 기본 지표를 한 곳에서 잘 수집할 수 있다.


9. 60일차 후기

반복 된 작업을 좀더 편하게 할 수 있도록, CentOS 실행을 자동화하고 쿠버네티스의 명령어를 단순화 하는 설정을 해보았다. 물론 내가 작업하는 환경에서만 적용되는 내용이지만, 해당 기능을 활용하면 추후 일을 할 때 유용할 것 같다는 생각이 들었다.

 

또한 AWS의 EC2를 띄워, 하나의 허브로 활용해보는 실습을 진행해보았다. 

물론 도커 허브라는 유용한 사이트가 있긴하지만, 해당 사이트는 유료버전을 사용하지 않으면 이미지 pull에 제한이 걸릴 수 있다. 

때문에 EC2 내에 도커를 설치하여 이미지를 저장하고, 해당 이미지를 public ip로 접근할 수 있는 컨테이너에 집어넣어 외부 서버 (환경) 에서 해당 이미지를 pull해서 받아 사용할 수 있게 구성해보았다.