심루트의 연구노트

[PKOS] 쿠버네티스 스터디 1주차 - AWS kOps 설치 및 기본사용, Helm

심루트 — Tue, 10 Jan 2023 16:07:27 +0900

안녕하세요. Solutions Architect(AWS) 제니입니다

오랜만에 글을 적어봅니다. 글 제목 분류인 [PKOS]는 Production Kubernetes Online Study의 약어입니다. 우연한 기회로 외부 스터디를 알게 되어서 앞으로 약 7주간 매주 일요일 저녁 8~10시에 쿠버네티스 스터디를 하고 학습 과제까지 완료한 뒤 내용 정리를 포스팅해볼 예정입니다. 매주 실습 결과를 제출해야 하고 과제도 있는데, 1주 차라도 과제를 완료하지 못하면 자동 탈락처리 된다고 하여.. 정말 빡세게 해 볼 계획입니다. 취업 후 바빠서 업로드하지 못했던 블로그도 다시 살릴 겸, 새해 버프를 받아서 달려봐요!

1주차 : AWS kOps 설치 및 기본 사용

기초 지식 : AWS 기초(VPC, ELB, EBS/EFS/S3, IAM)
옵션/심화 : 컨테이너 격리 & 도커 네트워크, 쿠버네티스 특징 & 기초
스터디 교재 : 24단계 실습으로 정복하는 쿠버네티스

1주 차부터 많은 내용을 진행했는데, 스터디 모임장인 가시다님이 준비해주신 핸즈온을 통해 놓친 부분들을 쉽게 따라갈 수 있었습니다.

[쿠버네티스 기초]

여기서 제일 중요하게 느껴졌던 포인트는 '멱등성(Reconciler)'입니다.

여러 번 실행하더라도 같은 결과가 나오는 것을 멱등성이라고 합니다. 많은 내용이 담겨있는 스크립트 파일이 중간에 멈췄다가 다시 재실행된다면? 이미 실행된 부분에 대해서 또다시 시작하게 되고 소스가 꼬일 수 있습니다. 이런 부분을 방지해줄 수 있는 특징을 멱등성이라고 할 수 있습니다. 오늘 실습할 내용인 AWS kOps 배포를 하며 확인해보도록 하겠습니다.

[kOps 소개]

kOps 공식 홈페이지에 가서 보면 kOps를 다음과 같이 소개하고 있습니다.

kOps - Kubernetes Operations
The easiest way to get a production grade Kubernetes cluster up and running.

Kubernetes 클러스터를 시작하고 실행하는 가장 쉬운 방법.

한마디로 쿠버네티스 생성 및 관리를 쉽게 하도록 도와주는 오픈소스 툴이라고 합니다. 저도 이번에 공부하면서 처음 알게 되었는데요. 처음에 [케이 옵스]로 읽었다가 [콥스] 라고 하셔서 발음하는 방법도 새롭게 알아갔습니다. 낯설지만 실습을 통해 어떤 개념인지 대략적으로 잡아갈 수 있었습니다.

[아키텍처 및 kOps 배포]

AWS, Azure, GCP 등을 지원하는데 실습에서 AWS 서비스를 다룹니다.

AWS kOps Architecture

위 아키텍처를 배포하기 위해서 제 도메인인 jennysim.shop을 사용하고, AWS CloudFormation에 이미 작성되어 있는 yaml파일을 이용해서 기본 인프라 환경을 배포하였습니다. 이후 자동으로 kOps 클러스터 인프라를 배포하여 쉽게 설치환경을 구성하였습니다. 실습 중 중간에 배포내용을 삭제하지 않고 CloudFormation delete를 했다가 인스턴스가 종료되지 않는 상황이 있었는데요. EC2 Auto Scaling 그룹을 삭제함으로써 해결하였습니다. 처음에는 인스턴스 내부에 replica구성을 제거해야 하는 건가 싶어서 새로 생성된 인스턴스로 접근은 안되고 혼자서 삽질을 조금 했는데, EC2에 Auto Scaling구성으로 구현이 된다는 것을 알게 되었습니다.

설치 중간에 실패 시 삭제 방법
1. EC2 Auto Scaling 그룹 : 3개 삭제
2. EC2 시작 템플릿 : 3개 삭제
3. S3 버킷 비우기
4. Route53에 추가된 A 레코드 3개 삭제
5. CloudFormation 삭제

이후 kops-ec2 인스턴스 서버에 ssh 접속해서 테스트를 진행하였습니다. 사용 중인 노트북이 Windows라서 MobaXterm을 사용했는데, 까만 배경에 하얀 글자가 눈에 띄지 않아서 나중에 하이라이트 기능을 추가해야겠네요.

kOps 구성이 완료되어 현재 접속한 서버에서 클러스터와 인스턴스의 현재 정보를 다음과 같이 확인할 수 있었습니다.

이번 스터디의 과제 1번!

# kops get cluster

# kops get instances

Control plane과 node에도 각각 SSH로 접속해서 메타데이터들을 확인할 수 있습니다. 그리고 AWS Route53 도메인 정보도 간단하게 확인해 봤는데요. 저는 제 도메인인 jennysim.shop 도메인으로 테스트를 마쳤습니다.

[기타 : 관리 편의성]

Alias

작업 중에 kubectl 명령어를 k 입력만으로 완성할 수 있도록 alias를 사용할 수 있습니다.

# 자동 완성 및 alias 축약 설정
source <(kubectl completion bash)
echo 'source <(kubectl completion bash)' >> ~/.bashrc
echo 'alias k=kubectl' >> ~/.bashrc
echo 'complete -F __start_kubectl k' >> ~/.bashrc

kubectl 플러그인 : krew

kubectl의 cli 플러그인 매니저인 쿠버네티스 크루(krew)를 통해 부가적인 기능들을 제공합니다.

kubectl 플러그인 배포
다른 사람이 사용할 수 있는 플러그인을 개발한 경우, 이를 패키징하고, 배포하고 사용자에게 업데이트를 제공하는 방법을 고려해야 한다.

Krew
Krew는 플러그인을 패키징하고 배포하는 크로스-플랫폼 방식을 제공한다. 이렇게 하면, 모든 대상 플랫폼(리눅스, 윈도우, macOS 등)에 단일 패키징 형식을 사용하고 사용자에게 업데이트를 제공한다. Krew는 또한 다른 사람들이 여러분의 플러그인을 검색하고 설치할 수 있도록 플러그인 인덱스를 유지 관리한다.

출처 : https://kubernetes.io/ko/docs/tasks/extend-kubectl/kubectl-plugins/

플러그인으로 kubectl 확장

kubectl 플러그인을 작성하고 설치해서 kubectl을 확장한다.

kubernetes.io

What does Krew do?

Krew is a tool that makes it easy to use kubectl plugins. Krew helps you discover plugins, install and manage them on your machine. It is similar to tools like apt, dnf or brew. Today, over 200 kubectl plugins are available on Krew.

- For kubectl users: Krew helps you find, install and manage kubectl plugins in a consistent way.
- For plugin developers: Krew helps you package and distribute your plugins on multiple platforms and makes them discoverable.

출처 : https://github.com/kubernetes-sigs/krew/

GitHub - kubernetes-sigs/krew: Find and install kubectl plugins

Find and install kubectl plugins. Contribute to kubernetes-sigs/krew development by creating an account on GitHub.

github.com

정리하면 Krew는 kubectl 플러그인을 쉽게 사용할 수 있는 도구입니다. 설치해서 쓸 수 있으며 apt, dnf, brew와 같은 도구와 유사합니다. 현재까지 Krew에서 200개 이상의 kubectl 플러그인을 사용할 수 있습니다.

# 설치
curl -fsSLO https://github.com/kubernetes-sigs/krew/releases/download/v0.4.3/krew-linux_amd64.tar.gz
tar zxvf krew-linux_amd64.tar.gz
./krew-linux_amd64 install krew
tree -L 3 /root/.krew/bin

# PATH 추가
export PATH="${PATH}:/root/.krew/bin"
echo 'export PATH="${PATH}:/root/.krew/bin"' >>~/.bashrc

# krew 확인
kubectl krew
kubectl krew update
kubectl krew search
kubectl krew list
kubectl krew

실습에서는 krew로 df-pv, get-all, ktop, neat, oomd, view-secret을 사용해 봤습니다. krew 하나에도 정말 많은 플러그인이 있어서 나중에 잘 활용하면 편리할 것 같네요.

[svc,pod 배포 테스트 - Mario 게임 with CLB]

가시다님의 슈퍼마리오 디플로이먼트 배포 yaml파일을 받아서 정말 쉽고 간단하게 svc, pod를 배포해볼 수 있습니다.

# 수퍼마리오 디플로이먼트 배포
curl -O https://raw.githubusercontent.com/gasida/PKOS/main/1/mario.yaml
kubectl apply -f mario.yaml
cat mario.yaml | yh

# 배포 확인 : CLB 배포 확인 >> 5분 이상 소요
kubectl get deploy,svc,ep mario
watch kubectl get svc mario

# 마리오 게임 접속 : CLB 주소로 웹 접속
kubectl get svc mario -o jsonpath={.status.loadBalancer.ingress[0].hostname} | awk '{ print "Maria URL = http://"$1 }'

# 삭제
kubectl delete deploy,svc mario

다음 마리오 게임을 배포한 뒤 웹 주소로 접근하니 추억의 마리오 게임이 실행됩니다. 여기서는 AWS CLB를 사용합니다. 2022년 12월을 끝으로 AWS에서 CLB 서비스를 종료하려고 하기 때문에(아직 실행은 됩니다.) 실제 활용하는 곳에서는 NLB나 ALB를 사용하고 있다고 합니다.

추억의 슈퍼마리오 게임

[트러블 슈팅]

언제나 발생하는 에러 상황에 대처하는 기본 조치 프로세스입니다.

get 확인 → describe 확인 → 애플리케이션 로그(log) 확인 → 클러스터 에러 이벤트(event) 확인

이전에 k8s 공부할 때 Vagrant를 활용해서 배포 테스트를 해봤는데요. 그때도 마찬가지로 이슈가 발생했고, describe로 히스토리를 확인해서 해결했던 경험이 있습니다. 이번 스터디를 통해 애플리케이션 로그 확인이나 클러스터 에러 이벤트 확인하는 것까지 더 자세하게 들여다볼 수 있었습니다.

여기서 잘못된 이미지 정보의 pod를 배포해서 디버깅해보는 테스트를 진행했습니다.

# 잘못된 이미지 정보의 파드 배포
kubectl apply -f https://raw.githubusercontent.com/junghoon2/kube-books/main/ch05/nginx-error-pod.yml

디버깅 프로세스 : Apply → Get → Describe → Log → Event

프로세스에 따라 확인해서 문제의 원인은 nginx-19 이미지가 업데이트되지 않았기 때문이었습니다.

Q. 여기서 patch와 update의 차이는 무엇? patch: 일부, update: 전부

kubectl patch pod nginx-19 --type='json' -p='[{"op": "replace", "path": "/spec/containers/0/image", "value":"nginx:1.19"}]'

다음과 같이 해결할 수 있었습니다.

[헬름(Helm)]

쿠버네티스를 하면서 정말 많이 들어본 헬름! 헬름이다 헬름차트다 많이 들어봤었는데요.

헬름이 무엇인지, 왜 써야 하는지 등을 아래 유튜브 강의를 통해서 개념을 잡아갈 수 있었습니다.

출처 : https://helm.sh/

What is Helm?

Helm helps you manage Kubernetes applications — Helm Charts help you define, install, and upgrade even the most complex Kubernetes application.

* 요약 : Helm은 k8s 애플리케이션을 관리하는데 도움이 됩니다.

한 마디로 헬름은 쿠버네티스의 패키지 관리자입니다. 패키지를 차트(Chart)라고도 표현합니다. 그래서 헬름 차트라는 말을 많이 들어본 것 같네요. 오픈소스로 공개되어 있어서 public hub의 경우 ArtifactHUB 같은 곳에서 여러 헬름 저장소를 통합해서 검색해볼 수 있습니다.

자세한 내용은 유튜브에!

YouTube : [인프런] 대세는 쿠버네티스 Helm편

[Helm으로 워드프레스 배포]

두 번째 과제는 'Helm으로 워드프레스를 배포해서 글 남기기'입니다.

먼저 helm은 ArtifactHUB에서 GUI, CLI 모두 검색이 가능합니다.

* CLI

# 아티팩트 허브에서 검색
helm search hub wordpress

* GUI

오픈소스 소프트웨어들을 쉽게 설치할 수 있도록 도와주는 설치 패키지 인 bitnami를 추가해 주고, wordpress 네임스페이스를 따로 생성해준 뒤에 준비된 wordpress를 배포합니다. 미리 준비된 명령들을 활용해서 손쉽게 워드프레스를 배포했고, 접속 URL을 따라 다음과 같이 두 번째 과제를 완료했습니다.

관리자 페이지 > 새 글 작성 완료

wordpress 메인 페이지

게시글 1개 포스팅 완료

[AWS kOps를 활용하여 워커 노드 증가(ASG = Auto Scaling Group 활용)]

세 번째 과제로 기본 node 수를 증가시키는 작업을 진행했습니다. 인스턴스 그룹 정보에 보면 각각 MIN, MAX값이 1로 설정되어 있는데요. 이 부분을 편집해서 maxSize는 3으로, minSize는 2로 수정하였습니다.

# 편집
kops edit ig nodes-ap-northeast-2a

이후 kops update를 완료해준 뒤 kubectl get node를 입력해주면 수분 이후에 node수가 증가한 것을 확인할 수 있습니다.

Updating kOps
You may want to run below commands to include fixes/features after updating kOps

kops update cluster $NAME --yes
kops rolling-update cluster $NAME --yes

출처 : https://kops.sigs.k8s.io/operations/updates_and_upgrades/

Updates & Upgrades - kOps - Kubernetes Operations

Updates and Upgrades Updating kOps MacOS From Homebrew: brew update && brew upgrade kops From Github: sudo rm -rf /usr/local/bin/kops wget -O kops https://github.com/kubernetes/kops/releases/download/$(curl -s https://api.github.com/repos/kubernetes/kops/r

kops.sigs.k8s.io

* 결과 화면

클러스터 업데이트

rolling-update

# 워커노드 증가 확인
kubectl get node

node 수 확인

[실습 환경 삭제]

추가 리소스 발생을 막기 위해서 실습 환경을 삭제합니다. 먼저 kOps 클러스터 삭제를 해야 오토스케일링 그룹이 제거가 되기 때문에 먼저 삭제 후, AWS CloudFormation 스택을 제거해야 합니다.

# kOps 클러스터 삭제
kops delete cluster --yes

# 클러스터 삭제 완료 확인 후 AWS CloudFormation 스택 삭제
aws cloudformation delete-stack --stack-name mykops

글을 마치며

이 스터디를 입사한 지 얼마 안 되었을 때 했다면 AWS 기초 지식부터 이해해야 해서 많은 어려움이 있었을 것 같다는 생각을 해봤습니다. 물론 이 스터디의 요건이 실무자를 위한 스터디지만, 현재 1년 차 SA로서 기초적인 AWS 서비스는 사용해봤기 때문에 따라갈 만했습니다. 물론 쿠버네티스는 별개라서 학습할 내용이 참 많지만요. 핸즈온이 잘 되어있어서 너무 좋았습니다.

쿠버네티스 같은 경우 전부터 계속 관심이 있었지만 다른 프로젝트에 계속 조인되다 보니 프로젝트를 접할 기회가 없어서 우선순위에 많이 밀려 있었던 것 같아요. 만 1년을 다 채우고 난 뒤부터 Devops라는 직무가 매력적으로 다가왔습니다. 이번 기회에 스터디를 통해 쿠버네티스를 많이 접해놓으면 추후 관련된 일이 있을 때 큰 도움이 될 거라고 생각합니다.

쿠버네티스 하면 떠오르는 것이 오픈소스가 아닐까 싶습니다. 정말 넓고 깊은 오픈소스의 세계를 평생 가도록 다 해보긴 어렵겠지만, 쿠버네티스와 떼려야 뗄 수 없는 관계라고 생각합니다. 필요한 것들 위주로 점점 범주를 넓혀갈 수밖에 없을 것 같아요. 이번 스터디를 하면서 오픈소스가 정말 다양하게 쓰이는 것을 보았습니다.

1시간 동안 알차게 1주 차 내용을 차근차근 설명해주신 가시다님 강의와, 중간에는 스터디 교재 '24단계 실습으로 정복하는 쿠버네티스'의 저자 이정훈(Jerry)님의 책 후기, 경험담을 듣는 재미도 쏠쏠했습니다. 저도 언젠가는 이런 역할을 하는 시니어가 되고 싶습니다.

[CCCR 아카데미 회고] 7개월간의 클라우드 교육을 마치며 | 혁신성장 후기

심루트 — Thu, 30 Dec 2021 14:04:01 +0900

클라우드에 관심은 많은데 기초부터 끝까지 어떻게 방향을 잡아가야 할 지 정말 정보가 많이 부족했다. 특히 AWS같은 경우에는 혼자서 해보고싶어도 과금의 두려움이 막연히 있었는데, 과연 어디서부터 시작해야할지 1~2년 고민을 했었던 것 같다. 그렇게 고민하던 중 CCCR 아카데미를 만나게 되었다.

컴퓨터공학을 전공하고 IT업계에 계속 있었지만 20대 후반이고 그러다보니 직무를 바꾸는 데 신중했다. 회사를 한참 다니다가 반년이라는 시간을 학업에만 투자하기에는 큰 결정이 필요했다. 마침 교육 공지가 떴고 다니던 회사에서도 연말이 지나 프로젝트를 마무리짓고 다음년도 계획을 하는 단계였기에 본격적으로 다음년도 프로젝트가 시작되기 전에 과감하게 회사를 그만두고 클라우드 교육을 선택했다. 역시 모든건 타이밍이 중요하다는 것을 올 해 참 많이 느꼈던 것 같다.

결론은 선택하기를 아주 잘했다.

약 7개월간의 교육을 진행하며 정말 많은 것들을 배웠다. 현재 원하던 곳에 취업해서 다니게 된 지도 1달이 조금 넘었다. 최종발표에서도 우리 팀이 1등을 해서 유종의 미를 거두었다. 인생에서 열심을 다했던 순간들 중 하나에 들었던 이 기간들을 돌아보며 기록으로 남겨본다

2021년 혁신성장 청년인재 집중양성

과학기술정통부에서 주관하는 혁신성장교육의 4기로 들어가게 되었는데 정식 과정명은 "차세대 클라우드컴퓨팅 구축 및 오케스트레이션 개발 실무과정"이다. 9시 반 ~ 18시 반까지 전일 과정으로 듣게 되었다.

2021.04.15~16 Orientation

처음 이틀간의 OT가 기억에 남는다. 처음 코엑스에 들어갔을 때부터 설레는 그 느낌! 2일간의 OT를 통해서 교육 소개와 클라우드에 관련된 특강을 들었다.

클라우드 아카데미 4기 오리엔테이션

2021.04.19~07.16 정규 수업

그리고 정규 수업을 구로 교육장에서 시작했다. 네트워크 수업부터 시작해서 리눅스, 도커, 쿠버네티스, IaC, 개발까지 클라우드 엔지니어가 되기 위한 기본적인 이론 과정들을 거쳤다.

첫 수업 & 내가 만든 랜선

USB로 베어메탈 환경에서 OS 설치하는 것 부터 기본적인 네트워크 개념과 패킷 트레이서 프로그램을 통해 어떻게 패킷이 흘러가는지, 그리고 랜선만들기도 해보며 알차게 시간을 보냈다. 하루에 풀데이로 전념하다보니 정말 많은 지식들이 쌓였다.

코로나 때문에 대면수업을 하다가 온라인으로 전환된 부분이 있었지만 그래도 초반에는 나와서 들을 수 있어서 대면/비대면 수업의 장단점이 있어 좋았다. 아무래도 면접기간에는 비대면 수업이 시간적인 활용이 더 좋았던 것 같다. 이론수업 때 비대면이면 질문하기가 많이 불편했을 텐데 그런 기간이 적어서 괜찮았다. 그리고 구로 교육장은 생긴지 얼마 안 돼서 쾌적했는데, 2인 좌석에 한명씩 앉아서 수업을 들었기 때문에 넓게 쓸 수 있었던 점도 좋았다. 나는 거의 맨 앞자리에서 엄청 집중하며 들었다.

돌아보면서 정리 해보니 그동안 받은 책만 해도 약 15권 이상은 되는 것 같다. 이전에 전공수업때 보던 컴퓨터 네트워킹도 이번에 다시 꺼내보게 되었고, 지원해준 책과 강의가 참 알차고 의미있는 시간들이었다. 사실 이론수업 들으면서 복습하고 실습해보고 자기가 얼마나 남아서 하냐가 정말 중요했는데, 그 날 배운부분들은 꼭 그날 이해하고 정리하고 들어가려고 했었기 때문에 끝까지 이 열정을 유지하는 것이 아무래도 많이 힘들었다. 이 교육을 시작하기 전부터 절대 지각, 결석하지 말아야지 하고 다짐했어서 나와의 약속도 지키고, 또 수업때도 흐름을 놓치지 않으려고 꾸준히 노력하는 그 포인트가 당시에는 빠듯했더라도 지금 돌아보니 정말 뿌듯한 경험으로 남아있다.

힐링

공부만 하다보니 열도 식힐 겸 수업 때 알게 된 친구와 노들섬에서 야경도 보고 힐링타임도 가졌다.

그리고 수업을 들으면서 CCCR측에서 여러모로 학습할 수 있을 환경을 만들어주려고 노력해주신 점이 정말 이 교육을 잘 선택했다는 마음이 들게했다. 중간중간 음료수도 챙겨주시고 굿즈나 책들도 잘 챙겨주시고, 나는 크게 상담을 받진 않았지만 진로문제로 고민하고 있는 분들도 따로 챙겨주시는 것 같았다. 수강생도 물론 열정이 있어야겠지만 서포트 해주는 운영진들도 끝까지 관심을 가지고 참여할 수 있다는게 참 쉽지 않았을텐데 정말 감사했다. 취업 시즌에는 면접준비에도 많은 도움을 받았다.

2021.07.29~ 멘토링 프로젝트 시작

이 교육을 선택하게 된 큰 이유중 하나도 현업에 계신 실무진들과 함께 그룹으로 프로젝트를 진행할 수 있다는 점에 끌렸다.

이론수업이 끝나갈 때쯤 멘토링 첫 kick off 이후 프로젝트 준비도 함께 병행했고, 이론수업이 끝난 뒤에는 멘토링 프로젝트에 전일적으로 집중해서 진행했다. 이번 교육에서 참 운이 좋다고 느꼈던 점은, 원래 프로젝트 집중 기간에는 오후부터 저녁 일정이었지만 비대면으로 전환된 후로 기존대로 9~6시까지 정기적으로 진행할 수 있었다는 점이 좋았다. 저녁시간을 활용할 수 있어서 좋았다!

팀을 구성하는것도 블라인드로 진행이 되었는데, 팀을 정말 잘 만난 것도 좋았다. 현업에 계신 실무자 멘토님이 정말 많은 것들을 챙겨주셨고, 퍼블릭 클라우드 수업같은 경우 1주일정도만 진행해서 많이 아쉬웠는데 프로젝트를 하면서 AWS를 다루고 깊이있게 학습할 수 있어서 좋았고 진행했던 주제가 정말 좋았다.

발표일이 가까워질수록 점점 시간이 더 필요하지 않나 이런 생각들은 들었지만 직전에는 후회하지 않을만큼 다들 열심을 다했던 것 같다.

2021.11.05 프로젝트 발표회, 수료식

대망의 프로젝트 발표회 & 수료식도 처음과 같이 코엑스에서 진행했다. 코로나 바이러스가 한참일 때라 반별로 진행해서 다른 반 분들의 내용을 듣지 못했던 것은 아쉬웠지만, 괜찮았다.

별마당 도서관 그리고 프로젝트 발표회!

(계속 생각이 든건데 CCCR은 굿즈 맛집이다)

우리 팀은 'Cloud Native 데이터 분석 및 플랫폼 구축'이라는 주제로 발표를 했었는데 최우수상을 받게 되었다. 기사에서도 우리 프로젝트 주제가 뜨니까 너무 신기하기도 하고.. 그동안 정말 열심히 했구나 하면서 뿌듯했던 하루였다. 유종의 미를 거두어서 너무 기쁘고 프로젝트 발표회 전에 취업 결과가 있어서 목표했던 바를 이루는 한 해가 되어 정말 뿌듯했다.

유종의 미(뿌듯)

글을 마치며

정말 고민도 걱정도 많았던 한 해였고, 많은 걸 배웠다. 뜻깊은 성과를 이루었다. 클라우드 엔지니어가 되고 싶어 시작했던 이 교육을 통해 AWS Solutions Architect라는 직무로 커리어를 다시 시작하게 되었다. 그동안 Slaes, Marketing 업무와 개발쪽에 일을 하다가 클라우드로 전향을 하게 되었는데 살면서 그동안 동종업계에서 일을 하며 굴렀던 것들이 이번 직무에서 조금이나마 도움이 되기도 하다는 생각이 든다. 무엇이든 경험해놓으면 나중에 쓸데가 있다라는 것을 느끼고 있는 중이다.

20대 후반인데 직무를 바꾸는 것이 정말 늦지 않았을까? 하는 생각들로 고민했던 1년이라는 시간이 아까울 정도로 너무 만족하며 이 일을 하고있다. 그래서 아직 20대인데 하고싶은 일을 고민하고 있는 사람들이 있다면 나는 무조건 적극적으로 내가 하고싶은걸 찾으라고 말하고싶다.

앞으로 주니어로 성장하고 그 안에서도 더 다양한 진로가 있겠지만, 나에게 맞는 것이 무엇인지 경험해보며 찾아나갈 예정이다. 앞으로 많은 역량들을 쌓아나가면서 전문성을 확보하고 싶고, 삽질하고 배운 것들을 꾸준히 글을 통해 업로드 하며 기록해볼 예정이다.

Good bye~

참고자료

https://www.cccr-edu.or.kr/board/read.jsp?id=106699&&code=pds1

CCCR 아카데미

문의사항이 있으시면 친절히 안내해드리겠습니다. 전문인력(재직자 교육): 02-2052-1162 혁신성장(미취업자 교육): 02-2052-1163 혁신성장 : 02-2052-1267 --> 평일 09:00~18:00 / 점심 12:00~13:00 주말 및 공휴일

www.cccr-edu.or.kr

참고기사

https://www.sedaily.com/NewsView/22U0YOB63W

CCCR, '클라우드 엔지니어 양성과정' 프로젝트 발표회 및 수료식 개최

한국클라우드컴퓨팅연구조합(CCCR, 이사장 홍승균)이 지난 9일 과학기술정보통신부와 정보통신기획평가원이 시행하는 혁신성장 청년인재 집중양성사업의 '클라우드 엔지니어 양성과정' 프로젝

www.sedaily.com

[AWS EMR] Spark로 CSV 파일을 read 후 Parquet로 write하는 방법

심루트 — Tue, 28 Sep 2021 19:57:19 +0900

현재 진행중인 프로젝트에서 웹 상에서 가져온 크롤링 데이터를 CSV로 받아왔다. 해당 파일을 다루기 쉬운 Parquet로 변환하는 방법으로 AWS서비스의 EMR(Elastic Map Reduce)를 이용하여 Spark로 코드화하였다.(Python 사용)

How to Convert CSV to Parquet Files?

1. Create AWS S3 bucket

AWS상의 버킷을 하나 만들어주고, 그 안에 폴더를 구분하였다.

- input : 크롤링 데이터인 CSV 샘플파일을 저장

- script : spark script 코드를 저장

- output : EMR 클러스터를 돌렸을 때 결과물이 저장되는 위치

폴더 이름은 본인이 편한걸로 설정해주면 된다. sample.csv 파일을 input 폴더에 업로드 하였으며, pysaprk 코드는 script 폴더에 업로드하였다.

2. EMR 클러스터 생성

AWS 서비스 탭을 클릭하여 Amazon EMR을 찾거나 검색창에 EMR을 검색하여 들어와 클러스터를 생성한다. 내가 지정한 Region 안에서 진행한다.

"고급 옵션으로 이동" 한다.

Spark에 체크표시한 뒤 나머지는 기본 설정으로 남겨두고 클러스터를 생성한다.

참고로 보안옵션의 키페어 없음으로 설정해두어도 실습은 가능하며, 생성한 뒤 약 15분정도가 경과하면 클러스터가 test 가능 상태가 된다.

Before

초기 화면은 시작으로 표시되고, 영어버전으로 변경하면 Starting이라는 초록색 글씨를 확인할 수 있다. 대시보드상에서 생성 후 경과시간도 확인할 수 있으니 잠시 10분간 다른 일 하면서 기다려본다.

EMR 대시보드 우측 하단

대시보드에서 마스터, 코어 부분이 현재 어디까지 구성중인지 중간 현황도 확인할 수 있다. 아직 프로비저닝 중으로 확인된다. 8-9분이 경과하니 아래와 같이 대기상태로 변경된다.

After

마찬가지로 대시보드 우측 하단의 네트워크 및 하드웨어에 보면 Running or 실행 이라는 초록색 글씨가 나오면 작업 환경이 준비가 된다.

AWS EMR Dashboard

3. 단계(Step) 탭에서 단계 추가

단계(Step) 탭을 클릭하면 단계추가 버튼이 보인다. 여기서 사용자 지정 JAR의 위치, 인수를 지정하여 추가해 줄 것이다. 참고로 클러스터를 생성할 때부터 이 단계추가가 가능하지만, 클러스터 생성부터 오류가 날 수 있으니 코드가 확실하다면 생성할 때 옵션들을 이용해 만들고 테스트 단계라면 단계 탭을 이용하는 것이 편하다.

- JAR위치 : command-runner.jar

- 인수 : spark-submit s3://<bucket name>/script/<pyspark filename> s3://<bucket name>/input/<csv filename> s3://<bucket name>/output/

JAR 위치는 command-runner.jar로 입력해준다.

인수 입력할 때 spark-submit 이라는 명령어는 spark-submit [script위치] [input위치] [output위치] 를 의미하며 띄어쓰기로 구분한다. <>안에 들어있는 내용은 각각 환경에 맞게 지정해주면 된다.

추가 후 기다리면 실패/성공 여부를 확인할 수 있고, 정상적으로 작동 되었다면 지정해놓은 S3 bucket의 output 폴더에 아래와 같이 SUCCESS를 볼 수 있다.

Parquet 형태로 변경 완료

* CODE

참고로 여기서 pyspark 코드를 작성하는 데 아래 코드를 사용하였다.

import sys
import os
from datetime import datetime
from pyspark.sql import SparkSession
from pyspark.sql.functions import *

input_path = "s3://jhsim-emr-bucket/input/sample.csv"
output_path = "s3://jhsim-emr-bucket/output/"

spark = SparkSession \
    .builder \
    .appName("How to read CSV file to Parquet") \
    .getOrCreate()

# read csv
SampleData = spark.read.option("inferSchema", "true").option("header", "true").csv(input_path)
SampleData.show()

# write parquet
SampleData.write.format("parquet").mode("overwrite").save(output_path)

먼저 필요한 모듈들과 SparkSession을 import한 뒤, input, output 경로는 가독성이 좋게 따로 지정해두었다. 이후 SparkSession을 지정하였다. 그리고 CSV파일을 read하는 코드, Parquet 형식으로 write하는 옵션을 지정해주면 성공적으로 작동한다.

Spark read CSV를 하는데 있어서 아래 설명을 참고하였다.

글을 마치며

해당 테스트를 해보기 전에 AWS workshops에 올라와있는 EMR workshop을 한 번 돌려봤다. 그 후 진행하니 개념에 대한 이해가 되고 적용점을 찾을 수 있었다. Jupyter notebook으로 기본 테스트를 해봤지만 프로젝트를 위해 Python 언어로 pyspark 스크립트화 해서 EMR에 돌리니 파일 변형하는 부분에 있어서 쉽게 자동화를 시킬 수 있어 편리했다.

CSV 파일마다 필드값이 달라질 수도 있고 같은 필드값을 가진 파일도 있을 것이다. 이번 프로젝트에서는 크롤링을 할 것이기 때문에 별도로 추가되는 필드값은 없다. 그래서 스키마를 필드별로 지정해서 사용하는 것이 더 안정적인 코드가 될 것 같다. 지금은 header값을 true로 지정하여 기본적인 코드로 작성했지만, 더 나아가서 각 필드값별로 스키마를 지정해 주는 것이 더 안정적일 것이다. 이번 코드 외에도 StructField 값을 지정하는 코드까지 2가지 방법을 테스트해봐야겠다.

<참고자료>

* AWS workshops

EMR Workshop

EMR Steps EMR Steps can be configured while creating the cluster or submitted after the cluster is created. We will be following the latter. You can add steps to a cluster using the AWS Management Console, the AWS CLI, or the Amazon EMR API. The maximum nu

emr-etl.workshop.aws

* Apache Spark Tutorial— How to Read and Write Data With PySpark

Spark Essentials — How to Read and Write Data With PySpark

More than a cheat sheet

towardsdatascience.com

* 필드별 StructField 지정 참고

[pyspark] CSV파일로 데이터프레임 생성

pyspark에서 스파크세션을 이용하여 CSV파일을 읽어서 데이터프레임을 생성하는 예제를 알아보겠습니다. ;

118k.tistory.com

[DATABASE] 운용 데이터 저장소(Operational Data Store, ODS)란?

심루트 — Thu, 12 Aug 2021 17:56:09 +0900

운용 데이터 저장소(Operational Data Store, ODS)

운용 데이터 저장소는 데이터 웨어하우스(DW)의 데이터를 저장, 유지, 관리하는 잠정 영역에 속하는 데이터베이스 형태를 말한다. 이전 포스팅에 자세하게 적었던 ‘데이터 웨어하우스’는 정보(data)와 창고(warehouse)의 합성어로, 데이터를 공통 형식으로 변환하여 관리하며 대량의 데이터를 수반하는 복잡한 질의 형태를 갖는다.

이와 달리 운용 데이터 저장소(ODS)는 단기 사용 메모리처럼 소량의 데이터를 수반하는 질의를 수행하고, 비즈니스 운용 과정에서 데이터를 현행화한다. 앞선 데이터 웨어하우스나 데이터마트와는 상호 작용 관계이다. 초기 운용 데이터 저장소는 일일 판매 및 주문 등 보고용 도구로 개발되어 비즈니스 거래 보고에 사용되었으나, 현재는 고객 관계 관리(CRM)로 개발되어 동기화를 통해 고객에게 지속적이고 조직적인 정보를 제공하는 데 사용된다.

DW등 용어에 대해 궁금하다면 여기를 클릭하여 이전 포스팅을 참고해주세요!

<참고자료>

Operational data store - Wikipedia

An operational data store (or "ODS") is used for operational reporting and as a source of data for the enterprise data warehouse. It is a complementary element to an EDW in a decision support landscape, and is used for operational reporting, controls and d

en.wikipedia.org

운용 데이터 저장소(Operational Data Store, ODS) | 과학문화포털 사이언스올

과학의 모든 것, 사이언스올! 과학학습, 과학체험, 과학문화 콘텐츠 제공

www.scienceall.com

[DATABASE] CDC(Change Data Capture)란?

심루트 — Thu, 12 Aug 2021 17:25:15 +0900

데이터베이스에서 CDC(Change Data Capture)는 변경된 데이터를 확인하고 추적하여, 그 변경된 데이터를 사용하여 작업을 수행할 때 사용되는 소프트웨어 설계 패턴의 집합이다. 데이터 소스의 변경 사항을 식별, 캡처 및 전달하는 것을 기반으로 하는 데이터 통합 접근 방식이다. CDC는 데이터 웨어하우스(DW)의 핵심 기능 중 하나이기 때문에 데이터 웨어하우스 환경에서 자주 발생하지만, CDC는 모든 데이터베이스 또는 데이터 저장소 시스템에서 활용할 수 있다.

CDC 매커니즘에는 아래와 같은 다양한 방법론이 있다.

- Timestamps on rows
- Version numbers on rows
- Status indicators on rows
- Time/Version/Status on rows
- Triggers on tables
- Event programming
- Log scanners

또한 여러가지 교란 요인들이 있는데, 자세한 내용은 참고자료를 활용해보자.

<참고자료>

Change data capture - Wikipedia

From Wikipedia, the free encyclopedia Jump to navigation Jump to search In databases, change data capture (CDC) is a set of software design patterns used to determine and track the data that has changed so that action can be taken using the changed data. C

en.wikipedia.org

[DATABASE] 데이터 웨어하우스란? DW, EDW, RDW, ADW, DM, ETL 용어정리

심루트 — Wed, 11 Aug 2021 17:40:14 +0900

"AWS based EDW 구축"이라는 주제로 프로젝트를 진행하기에 앞서, 기본적으로 등장하는 DW, EDW, RDW, ADW, 그리고 DM, ETL이라는 개념을 용어부터 정리해보려고 한다.

DW(Data Warehouse) - 데이터 웨어하우스

데이터 웨어하우스(data warehouse)란 사용자의 의사 결정에 도움을 주기 위하여 데이터베이스에 축적된 데이터를 공통의 형식으로 변환해서 관리하는 데이터베이스를 말한다.(비즈니스 사용자들의 의사결정 지원에 전적으로 이용된다) 줄여서 DW로도 불린다. DW는 하나 이상의 서로 다른 소스에서 통합된 데이터의 중앙 리포지토리이다. DW, DWH 라고도 표현한다.

정보(data)와 창고(warehouse)가 합쳐져서 만들어진 어휘이다. 따라서 데이터 웨어하우스는 방대한 조직 내에서 분산 운영되는 각각의 데이터 베이스 관리 시스템들을 효율적으로 통합하여 조정ㆍ관리한다. 그렇기 때문에 효율적인 의사 결정 시스템을 위한 기초를 제공하는 실무적인 활용 방법론이 제공되고 있다.

data warehouse 기본 아키텍처 / 출처 : 위키피디아

EDW(Enterprise Data Warehouse) - 엔터프라이즈 데이터 웨어하우스

엔터프라이즈 데이터 웨어하우스(enterprise data warehouse)는 여러 애플리케이션의 비즈니스 정보를 중앙 집중화하고 조직 전체에서 분석 및 사용할 수 있도록 하는 데이터베이스 또는 데이터베이스 모음이다. EDW는 사내 서버 또는 클라우드에 보관할 수 있다.

이러한 유형의 디지털 웨어하우스에 저장된 데이터는 비즈니스, 직원, 고객 등에 대해 알려진 정보의 대부분을 나타내므로 비즈니스의 가장 귀중한 자산 중 하나가 될 수 있다.

오늘날 기업이 비즈니스 전략을 계획하기 위해서는 데이터 기반 의사 결정에 의존하기 때문에 EDW가 필요하다. 분석을 성공적으로 수행하려면 모든 데이터 소스의 데이터를 분석에 적합한 형식으로 데이터 웨어하우스에 로드해야 한다. 그런 다음 선택한 비즈니스 인텔리전스 도구를 이 데이터 웨어하우스에 연결하여 필요한 분석을 수행할 수 있다.

* EDW(엔터프라이즈 데이터 웨어하우스) 사용의 이점

EDW를 사용하면 다음과 같은 이점이 있다.

- 데이터 표준화 : 모든 기업의 운영 데이터는 다양한 OLTP(온라인 트랜잭션 처리) 시스템 및 데이터베이스에 저장된다. 각 시스템 또는 데이터베이스는 데이터를 다른 형식으로 저장한다. 유용한 분석을 수행하려면 먼저 모든 데이터가 동일한 형식이 되도록 데이터를 표준화해야 한다. 이러한 데이터베이스의 데이터는 ETL(Extract, Transform, Load / 추출, 변환, 로드) 파이프라인을 사용하여 데이터 웨어하우스로 로드된다. 이 파이프라인을 사용하여 데이터를 표준 형식으로 변환하고 데이터 웨어하우스에 저장할 수 있다. 이렇게 하면 데이터를 더 쉽게 분석하고 데이터 웨어하우스의 데이터에 대한 이해를 높일 수 있다.

- 유연성 : 기업이 성장함에 따라 저장하는 데이터의 양이 급격히 증가하게 된다. 볼륨의 증가와 함께 기록해야 하는 다양한 기타 속성을 수용하기 위해 데이터 모델을 업데이트해야 하는 상황이 있을 수 있다. EDW는 유연성으로 유명하며 시스템을 완전히 정비하지 않고도 저장되는 데이터의 양이나 데이터 모델의 변경과 같은 요구 사항의 변경 사항을 쉽게 수용할 수 있다.

- 비즈니스 인텔리전스 도구에 대한 연결성 : 대부분의 최신 엔터프라이즈 데이터 웨어하우스(EDW)를 사용하면 선택한 비즈니스 인텔리전스 도구에 쉽게 연결할 수 있다. 이러한 원활한 연결을 통해 기업은 비즈니스가 주요 목표를 얼마나 잘 달성하고 있는지 측정하는 데 사용할 수 있는 다양한 KPI(핵심 성과 지표)를 쉽게 설정하고 추적할 수 있다.

RDW(Real-time Data Warehouse) - 실시간 데이터 웨어하우스

사용자는 데이터 웨어하우스에 점점 더 많은 것을 요구하고 있다. 이는 기술이 제공하는 것의 발전과 가능한 기술의 변화로 이어진다. 점점 더 많은 고객이 요구하는 기능인 라이브 데이터, 최근 데이터, 과거 데이터에 대한 분석 기능들을 다루는 실시간 데이터 웨어하우스(real-time data warehouse)라는 개념이 등장하게 된 것이다.

* RDW의 이점
- 빠른 결정
- 이상적인 데이터 로드
- 빠른 복구
- 최적화

ADW(analytical data warehouse) - 분석 데이터 웨어하우스

ADW의 A가 analytical이라 함은 분석이라는 의미이다.

다른 뜻으로는 오라클 데이터웨어하우스 클라우드(ADW: Autonomous Data Warehouse cloud)라는 인공지능 기술 등을 도입해 클라우드 기반 실시간처리를 도와주는 솔루션이 있다. 여기서 말하는 것은 전자에 말한 분석 DW를 말한다. ADW는 과거의 DW개념이라고 생각할 수 있으며 RDW로 점점 발전해가고 있다.

DM(Data Mart)

데이터 마트는 금융이나 마케팅같은 제한된 수의 데이터를 하나의 주제에 초점을 맞춘 데이터웨어 하우스의 간단한 형태이다. 규모가 더 작고 집중적이다.

ETL(Extract, Transform, Load)

ETL 시스템은 소스 데이터 시스템과 데이터 웨어하우스 간의 데이터 이동과 데이터 웨어하우스에서 데이터 마트로의 이동을 관리한다. 먼저 소스에서 데이터를 추출한 다음 다음 스토리지 계층의 표준에 따라 변환해야 하며 마지막으로 형식이 지정된 데이터를 이 다음 계층에 올바르게 로드해야 한다.

쉽게 말해서 원본으로부터 데이터를 내려받아 가공해서 로딩하는 것을 ETL이라고 한다. 금융권에서 많이 등장하는데 예를들어서 은행 거래를 할 때 새벽에 잠시 작업이 안 되고 로딩하는 과정이 ETL 작업중인 것이다.

출처 : Snowflake

Database 아키텍처의 과거와 현재에 대하여

정형, 비정형, 반정형을 object storage에 모아서 AI를 위한 데이터셋을 만들수도 있고 기존의 DW를 구성할 수도 있다. 예전에는 DB 안에 들어있던 정형 데이터만 썼다면 지금은 정형, 비정형, 반정형을 이용해 구성할 수 있다.

OLTP의 특징 : 동시접속자가 엄청 많다. 커넥션이 몇백~몇천개까지 열린다. 동시접속자들을 받아서 최대한 많이 처리하는 것이 관건이며 대표적으로 MySQL, Oracle, DB2, MSSQL같이 우리가 알고있는 대부분의 SQL.을 말한다.

OLAP – 동시 접속자 수는 작음. 심할 경우에는 커넥션이 5개인 경우도 있음. 동시에 들어오는 쿼리가 적다. 대용량 데이터를 처리를 잘 한다는 컨셉으로 갔었음. 대표적으로 Informix, Sybase / Teradata 같은것들이 있고 전통적으로 고가의 장비였다.

그런데 DW시장이 생기기 전 1999~2000년 정도에는 어떤식으로 처리를 했을까?

기업엔 굉장히 많은 DB가 있다. 하나의 업무단위가 많이 있었는데 이제 이 업무에대한 보고를 해야하는 것. 결국 최고 결정권자들이 결정할 수 있도록 보고하는 자료를 만들어야 한다. 간략하게 하나의 레코드를 만들어서 (축약, 요약, 데이터 단편화)정보 만들기하는 것을 기존에는 reporting system이라고 불렀다. (ex. 재무, 환율정보등)

전체적인 흐름을 살펴볼 수 있도록 아래의 그림으로 정리해두었다.

과거의 database의 흐름 기본 아키텍처

원통형의 그림은 각각의 데이터를 의미한다. 재무, 환율정보 등과 같은 것이다.

현재의 database의 흐름 기본 아키텍처

엑사데이터와 같은 대용량의 데이터를 관리해주기도 하며 실시간 동기화를 사용하는 방향으로 나아가고있다. 여기서 CDC라는 개념과 위에 설명한 EDW, RDW, ADW가 등장한다. 결국 관리가 되는 데이터로 바꾸려면 정형 데이터로 바꿔야 한다. 그 때 쓰이는 게 EMR, Spark와 같은 솔루션이 있다.

아직까지는 기본적으로 실시간으로 동기화 시켜주는 기술이 없다. 그래서 자꾸 케네시스라던지 카프카, 등으로 꽂아넣는 Microservice Architecture로 가이드가 되고 있다. 전통적인 기업들의 앱을 바꾸기란 쉽지가 않다. 아직까지는 위와 같은 흐름으로 정형, 비정형, 반정형 같은 것들을 처리하고 계속해서 새로운 것들이 등장하고 있는 상황이다.

현재 프로젝트를 진행하고 있는데, 앞으로 두달간 해야 할 과제들이 생겼다. 이런것들에 대해 이벤트와 데이터 파이프라인이 발생하면 어떻게하면 심플하게 가져가고, 유기적으로 만들 것인가 흐름을 고민하는 것이 필요하다. 또한 모니터링을 하고 있다가 임계점이 넘으면 자동으로 scale out을 하고 테라폼을 돌려서 서버를 증설할 수 있는지. 그리고 이것을 돌렸을 때 네트워크 구성이 잘 되도록 구조화 하는 작업이 필요하다.

이러한 컨셉을 가지고 아마존에서 사용하는 기능들을 돞아보고 생각해보는 시간을 프로젝트 기간동안 가져 볼 예정이다.

<참고자료>

DW(Data warehouse) - wikipedia

데이터 웨어하우스 - 위키백과, 우리 모두의 백과사전

데이터 웨어하우스(data warehouse)란 사용자의 의사 결정에 도움을 주기 위하여 기간시스템의 데이터베이스에 축적된 데이터를 공통의 형식으로 변환해서 관리하는 데이터베이스를 말한다. 줄여

ko.wikipedia.org

Data warehouse - Wikipedia

The basic architecture of a data warehouse In computing, a data warehouse (DW or DWH), also known as an enterprise data warehouse (EDW), is a system used for reporting and data analysis and is considered a core component of business intelligence.[1] DWs ar

en.wikipedia.org

EDW(Enterprise Data warehouse)

Enterprise Data Warehouse (EDW)

See our definition of EDW, or Enterprise Data Warehouse. Understand what a data warehouse is and why its important

www.precisely.com

Understanding EDW (Enterprise Data Warehouse) Simplified

This article will provide you with an understanding of Enterprise Data Warehouses (EDW) along with its types allowing you to set it up for your business.

hevodata.com

RDW(Real-Time Data Warehouse)

An Overview of Real Time Data Warehousing on Cloudera - Cloudera Blog

Users today are asking ever more from their data warehouse. This is resulting in advancements of what is provided by the technology, and a resulting shift in the art of the possible. As an example of this, in this post we look at Real Time Data Warehousing

blog.cloudera.com

Why have a real-time Data Warehouse?

Going from an infrequently updated data warehouse or data mart environment to a near real-time data warehouse has a number of benefits. Here are just five.|Going from an infrequently updated data warehouse or data mart environment to a near real-time data

www.hvr-software.com

[DATABASE] OLTP와 OLAP의 개념과 차이

심루트 — Sat, 7 Aug 2021 20:04:37 +0900

Database가 있으면 크게 두가지의 처리 방법이 있다. OLTP와 OLAP인데, 이 두가지의 대략적인 개념과 실 사용하는 예시를 알아보자. 먼저 이 두가지는 시스템의 개념으로 생각해볼 수 있다.

* OLTP : 온라인 트랜잭션 처리(Online transaction processing)

#실시간 #트랜잭션처리 #소규모데이터처리

트랜잭션 지향 애플리케이션을 손쉽게 관리할 수 있도록 도와주는 정보 시스템의 한 계열이다. OLTP는 시스템이 사용자의 요청에 즉각 반응하는 처리를 가리키는 용어이며 은행 ATM기기의 트랜잭션 처리를 예로 들 수 있다. 보통 이 방법을 금융권, 전산상에서 많이 사용한다. 은행이나 증권거래같은 경우 즉각적인 반응이 매우 중요하기 때문이다.

이 시스템은 AWS의 RDS에 저장된다. 그러면 아마존의 RDW 어디쪽에 저장이 될까? RDS는 MySQL, postgreSQL, MariaDB에 저장된다. 참고로 RDS는 Amazon Relational Database Service를 말한다.

* OLAP : 온라인 분석 처리(Online Analytical Processing)

#대화식정보분석 #데이터분석 #정보변환 #대용량데이터처리

사용자가 동일한 데이터를 가지고 여러 기준으로, 다차원 데이터 분석을 할 수 있도록 도와준다. 의사결정 지원 시스템 중 대표적인 예라 할 수 있다. DW(Data Warehouse)같은 시스템과 연관되어서 데이터를 분석하며 적극적인 데이터의 활용을 통한 의사결정을 할 수 있게 한다. OLAP의 특성은 다음과 같다.

- 다차원 정보 제공
다차원정보에 직접적으로 대화 형태로 분석하는 것이 OLAP의 특징이다. 보통 데이터베이스는 2차원인데, 현업에서 요구하는 것은 다차원이다. 그래서 다차원 데이터베이스를 만들고 전문화된 데이터베이스 엔진으로 정보를 추출하는 것이 OLAP이다.

- 중간 매개자 없이 사용자가 직접 데이터 접근
OLAP는 중간 매개자가 없이 사용자가 온라인으로 접근한다. 홈뱅킹, VOD,또는 TV쇼핑 등에 사용할 수 있다.

- 대화형태 정보분석
OLAP는 대화 형태로 정보가 분석된다. 대화로 진행되기 때문에 사용자는 명령을 하고 오래 기다리지 않는다. 따라서 신속성이 중요하다. 사용자가 질의했을 때 신속하게 처리해야 한다.

- 의사 결정지원
질의, 목표탐색, 원인-결과 분석
보통 데이터베이스는 2차원인데, 현업에서 요구하는 것은 다차원이다. 그래서 다차원 데이터베이스를 만들고 전문화된 데이터베이스 엔진으로 정보를 추출하는 것이 OLAP이다.

OLAP는 AWS의 Redshift을 사용한다. 이번에 새로운 프로젝트를 준비하면서 Redshift에 대해서도 스터디하고 정리한 내용을 업로드 해볼 예정이다. 아직까지는 프로젝트의 큰 틀과 흐름을 잡고있는데 "AWS based EDW 구축"이라는 주제를 한번 고민해봐야겠다.

OLTP와 OLAP의 차이

<참고자료>

OLTP : 위키백과

온라인 트랜잭션 처리 - 위키백과, 우리 모두의 백과사전

ko.wikipedia.org

OLAP : 위키백과

온라인 분석 처리 - 위키백과, 우리 모두의 백과사전

온라인 분석 처리(Online Analytical Processing, OLAP)는 의사결정 지원 시스템 가운데 대표적인 예로, 사용자가 동일한 데이터를 여러 기준을 이용하는 다양한 방식으로 바라보면서 다차원 데이터 분석

ko.wikipedia.org

OLTP, OLAP 차이

Difference between OLAP and OLTP

Difference between OLAP and OLTP OLAP stands for On-Line Analytical Processing. It is used for analysis of database information from multiple database systems at one time such as sales analysis and forecasting, market research, budgeting and etc. Data Wa

www.tutorialspoint.com

Anaconda navigator를 이용한 Python 실습환경 만들기 - JupyterLab

심루트 — Mon, 28 Jun 2021 17:38:16 +0900

여태까지는 python을 하기위한 도구로 MS의 vscode나 Jetbrains의 Pycharm 또는 쉘에서 프로그래밍을 해봤는데, 파이썬을 기초부터 다시 시작하고자 Anaconda navigator를 이용해서 실습환경을 만드려고 한다.

아나콘다는 파이썬으로 프로그램을 개발할 때 여러가지 종속성이 있는데 해당 종속성들이 다른 프로그램에 영향을 주지 않도록 격리된 환경을 만들기 위해 사용한다.

보통 프로그래밍을 할 때는 가상머신 비슷하게 가상환경을 만들어놓고 작업한다. 그리고 문제가 되면 가상환경만 없애주면 된다. 또는 다른 환경을 만들어 똑같은 코드로 실행할 수 있다. 아나콘다 네비게이터는 웹 UI로 작업할 수 있어 Ctrl+C,V도 쉽게할 수 있다. 그리고 찐 파이썬은 아니니까 실제로 동작하는 프로그램은 안되지만, 실습정도는 해볼 수 있기 때문에 프로그램을 처음 접하기에 좋다.

먼저 구글링해서 anaconda 홈페이지에서 설치 파일을 다운로드한다.

Anaconda | The World's Most Popular Data Science Platform

Anaconda is the birthplace of Python data science. We are a movement of data scientists, data-driven enterprises, and open source communities.

www.anaconda.com

홈페이지상의 get started 클릭 -> Download Anaconda installers 클릭 -> 기기에 맞는 다운로드 클릭하여 다운받음.

Download Anaconda installers

Anaconda Installers

참고로 나는 호스트를 Linux를 사용하고 있기 때문에 리눅스 맨 첫번째 64bit installer버전을 다운로드 받았다. 받는데 시간이 좀 걸리는데, 다운로드가 완료된 후 다운로드폴더에 저장이 되면 해당 폴더로 이동해준 뒤 파일의 실행권한을 준다.

user@test:~/Downloads$ sudo chmod +x Anaconda3-2021.05-Linux-x86_64.sh

실행권한이 생겼으면 파일을 실행해준다.

user@test:~/Downloads$ ./Anaconda3-2021.05-Linux-x86_64.sh

처음에 실행을 해주면 영어로 길~게 글이 적혀있다. 엔터를 쳐서 넘겨준다. 그러고 나면 yes/no 확인 프롬프트가 뜨는데 yes를 입력해준다. 조금 시간이 더 지나면 init 어쩌고 하면서 yes/no 가 표시되는데, 이 init은 yes로 설정해주도록 하자.

설치가 완료된 후 아래와 같이 입력하면 화면이 뜬다.

user@test:~/Downloads$ bash
// bash를 입력하면 아래와 같이 표기된다.

(base) user@test:~$ anaconda-navigator

이후 초록색 원 모양의 아이콘이 뜨면서 아나콘다 네비게이터가 실행된다.

anaconda navigator 대시보드

이제 쉘 창은 숨겨두고, Environments 메뉴를 클릭하면 왼쪽 하단에 Create를 눌러준다.

* 요약 : environments → create → 원하는 이름으로 지정(3.8버전) – 생성

Environments Create

파이썬 버전과 함께 이름을 내가 원하는대로 지정해준다. 나는 기본값인 파이썬 3.8 버전으로 만들어 준 후 다시 Home으로 와서 JupyterLab을 Install해줬다. Install이 완료되면 Lanch라는 이름으로 바뀌는데, 그걸 클릭해주면 주피터랩이 웹 브라우저로 실행된다. JupyterLab은 JupyterNotebook에서 제공하는 기능도 들어있어서 이 것으로 설치해주었다.

Notebook - Python3 클릭

웹 서버가 하나 띄워진 것이라고 생각할 수 있다. 그 밑에는 파이썬 커널이 동작하고 있고 웹 서버를 띄워 연동되어져 있는 상태다.

Notebook의 Python3를 눌러 그 안에서 실습을 진행할 수 있다. 만들게되면 확장자가 ipynb으로 만들어지는데 파이썬 확장자가 아니기 때문에 이 화면에서만 작업을 할 수 있다. 그래도 노션처럼 편리하게 작성할 수 있고 실습해볼 수 있다. 폴더를 통해 경로도 만들어놓을 수 있고 이름도 지정해서 자유롭게 실습해보면 된다. 실제 동작을 위한 프로그래밍은 vscode나 pycharm으로 하는게 더 좋지만, 프로그램을 처음 접하기에는 이 환경도 괜찮다. 그리고 옛날에는 아나콘다 네비게이터에서 pycharm이 안 됐는데 이제는 지원이 된다.

Desktop/week1/ 폴더경로에서 python3 생성. day1으로 rename해줌.

보이는 네모칸에 프로그래밍을 해볼 수 있다. 우측상단에 Code라고 되어있으면 코드를 작성할 수 있으며 m을 누르면 마크다운으로 바뀌면서 주석도 쓸 수 있다. 이러한 마크다운을 쓰는 방법은 아래 깃허브 링크를 통해 상세하게 확인해볼 수 있다.

마크다운(Markdown) 사용법

마크다운(Markdown) 사용법. GitHub Gist: instantly share code, notes, and snippets.

gist.github.com

간단한 동작 방법은 다음과 같다. 참고로 하나의 네모칸(입력하는곳)을 셀이라고 한다.

- 컨트롤 엔터 : 셀이 동작하고 나면 숫자로 바뀐다.

- 쉬프트 엔터 : 실행이 되면서 밑에라인이 추가된다.

- 셀 지우기 : dd

- 셀 위로 추가 : a (above)

-> 그럼 이제 이 환경으로 프로그래밍을 시작해보자!

hello world!

<서적 추천>

점프 투 파이썬

파이썬 for Beginner

처음 시작하는 파이썬 : 단점은 딱딱하고 어렵다.

파이썬을 이용한 컴퓨터 과학 입문 : 체계적으로 배우고싶다면 이 책을 추천. 작년에 나왔는데 내용이 어려움.

파이썬3 바이블 : 2013년도에 나온 책. 욕은 많이 먹고있지만 깊이가 깊음.

쿠버네티스 클러스터의 구성요소는? 쿠버네티스 아키텍처에 대하여

심루트 — Mon, 28 Jun 2021 14:40:26 +0900

쿠버네티스 클러스터의 구성 요소는 크게 세가지가 있다.

- 컨트롤 플레인(Control Plane)

- 노드(Node)

- 애드온(Addons)

다음 쿠버네티스 컨트롤러 매니저 이미지를 보며 항목별로 알아보도록 하자.

쿠버네티스 컨트롤러 매니저

1) Control Plane(컨트롤 플레인)

왼쪽 박스는 컨트롤플레인으로, 클러스터의 전체를 제어한다. 클러스터에 대한 전반적인 결정을 수행하고 클러스터 이벤트를 감지하고 대응하는 일을 한다. ex. 스케줄링 등

개발환경에서는 3개 이상의 멀티 컨트롤플레인 환경을 구성한다. 컨트롤플레인의 구성에 대해 알아보도록 한다.

(1) API 서버(kube-apiserver)

쿠버네티스 클러스터의 모든 구성요소들과 메세지를 주고받기 위해서는 항상 컨트롤 플레인의 api서버를 지나가야 한다. 컨트롤플레인에 대한 프론트엔드를 담당한다.

(2) 키-값 저장소(etcd) [엣씨디]

쿠버네티스 클러스터의 모든 정보데이터들을 저장하는 일관성과 고가용성을 지원하는 키-값 저장소이다. k8s의 모든 정보를 가지고 있기 때문에 DB라고 보면 된다. 그리고 발음이 특이해서 옆에 따로 적어봤다.

(3) 쿠버네티스 스케줄러(kube-scheduler)

운영체제의 핵심은 스케줄러다. 쿠버네티스 스케줄러는 새로 생성되는 파드를 감지하고 적절한 노드에 배정하는 일을 한다.

(4) 쿠버네티스 컨트롤러 관리자(kube-controller-manager)

그림의 c-m에 해당한다. 컨트롤러는 API서버를 통해 클러스터의 상태를 감시하고 필요한 상태로 이행하는 기능을 가진다. 컨트롤 관리자의 종류는 다음과 같다

- 노드 컨트롤러(Node controller) : 노드를 관리하며 노드가 다운 되었을 때 알림과 대응을 한다.

- 레플리케이션(Replication) 컨트롤러 : 복제 컨트롤러를 사용하는 모든 오브젝트를 관리하며 알맞은 수의 파드를 유지하는 기능을 한다.

- 엔드포인트(Endpoint) 컨트롤러 : 서비스와 파드를 연결한다.

- 서비스 어카운트(Service Account) 및 토큰 컨트롤러(Token Controller) : 쿠버네티스의 네임스페이스, 계정, 토큰을 담당한다.

(5) 클라우드 컨트롤러 관리자(cloud-controller-manager)

그림의 c-c-m에 해당한다. 클라우드를 제공하는 업체의 기능과 클라우드에서 동작하는 쿠버네티스 구성 요소와 상호작용할 수 있도록 하는 컨트롤러 관리자이다. 쿠버네티스 1.6버전에서 도입된 알파 기능이다. 초반에는 이게 없어서 api와 cloud provider api가 직접 통신했다. 클라우드와 상호작용하는것이라고 생각할 수 있다. 종류는 다음과 같다.

- 노드 컨트롤러 : 노드가 응답이 없을 때 클라우드상에서 노드가 삭제되었는지 확인을 담당한다.

- 라우트 컨트롤러 : 클라우드 인프라의 네트워크 경로 구성을 담당한다.

- 서비스 컨트롤러 : 클라우드 로드밸런서 관리를 담당한다.

클라우드 컨트롤러 관리자는 클라우드 공급자(AWS, Azure, GCP, OCI 등)의 의존성을 갖는다.

2) Node(노드)

노드는 쿠버네티스의 컨테이너 런타임 환경을 제공하며 동작중인 파드를 유지하는 기능을 한다. 예전에 불리던 이름으로는 미니언(Minion), 워커(Worker)노드라고 불렸다.

(1) kubelet

각 노드에서 실행되는 에이전트로 컨트롤플레인으로부터 제공받은 파드의 구성 정보를 받아서 컨테이너가 확실하게 동작하는 것을 관리하고 보장한다.

(2) 쿠버네티스 프록시(kube-proxy)

호스트 레벨의 네트워크 규칙을 구성하고 외부 연결 포워딩을 담당한다. 쿠버네티스의 서비스 추상화가 가능하도록 한다. 쉽게말해서 pod(컨테이너)에게 네트워크를 제공해주는 것이다.

(3) 컨테이너 런타임

컨테이너의 동작을 책임지는 구성요소이다. 지원하는 컨테이너 런타임은 다음과 같다.

- Docker -> 1.20버전부터는 더이상 지원하지 않는다.

- containerd -> 도커는 이것을 사용하여 컨테이너를 만든다.(위의 지원중단과 헷갈리지 말기)

- CRI-O

- Kubernetes CRI(Container Runtime Interface)를 구현한 모든 런타임

3) Addon(애드온)

쿠버네티스 클러스터에 추가할 수 있는 확장기능을 제공해준다. 주요 애드온 구성요소로는 다음과 같다.

- 클러스터 DNS : 쿠버네티스 클러스터 내에 여러 오브젝트(파드,컨테이너,서비스 등)에 대한 DNS 레코드 제공

- 대시보드 : k8s 클러스터를 위한 웹 기반 인터페이스 제공

- 컨테이너 리소스 모니터링 : 컨테이너들에 대한 리소스 사용량에 대한 인터페이스 제공

- 클러스터 로깅 : 컨테이너 로그를 중앙 로그 저장소에 저장하고 관리하는 기능 담당

4) 쿠버네티스 API

(1) API 버전 규칙

A. 알파 버전 API

이 버전은 버그가 있을 수도 있으며 언제든 공지 없이 중단될 수 있다. 버전 이름에 alpha가 포함되어있다.

B. 베타 버전 API

코드가 잘 테스트되어있어서 이 기능을 활성화해도 안전하다. 전반적인 기능에 대한 기술지원이 중단되지 않는다. 버전 이름에 beta가 포함되어 있다.

C. 안정화 버전 API

버전 이름이 v?? 이거나 ??(정수) 이다.

(2) API 그룹

- 코어 그룹

- 코어 이외 그룹

<참고자료>

쿠버네티스 컴포넌트

쿠버네티스 클러스터는 컴퓨터 집합인 노드 컴포넌트와 컨트롤 플레인 컴포넌트로 구성된다.

kubernetes.io

Vagrant를 이용하여 쿠버네티스 클러스터 구성에서 노드 제거 및 추가하기

심루트 — Sat, 19 Jun 2021 16:05:39 +0900

쿠버네티스 클러스터를 구성하다가 node가 많아지면 복잡하고 골치아파진다. 지난번에 테스트 한 환경을 배경으로 클러스터의 노드를 제거 및 추가하는 방법을 적어본다. 사전에 준비해야 할 환경은 master, node1, node2가 이루어져 있는 환경이 필요하다. 아래 글 외에도 kubernetes 카테고리의 글들을 참고하면 된다.

<지난 글 바로가기>

[쿠버네티스] Vagrant를 이용한 kubeadm 클러스터 업그레이드(Version에 대하여)

이번에는 Vagrant를 이용한 kubeadm 클러스터 버전을 업그레이드를 해볼 예정이다. 쿠버네티스 공식 홈페이지에 보면 관련 명령어를 다 확인해볼 수 있다. 오늘 새벽에 최신 버전이 나와서 쿠버네티

simroot.tistory.com

노드 제거

kubernetes - Clean up

공식 홈페이지에서 제거하기 위한 절차가 잘 작성되어있다. 명령어를 기준으로 작성해나가려고 하는데, 이전에 갖춰져있어야 할 환경과 진행 순서는 다음과 같다.

kvagrant@kube-control1:~$ kubectl get nodes
NAME            STATUS   ROLES    AGE    VERSION 
kube-control1   Ready    master   151m   v1.19.11 
kube-node1      Ready    <none>   113m   v1.19.11 
kube-node2      Ready    <none>   122m   v1.19.11

1. kubeadm reset부터 시작(작업내용 초기화) -> 이 때 여기에 있던 kubelet들이 다 없어진다.

2. 노드 1개를 제거한다.

1. 초기화

kube-node2를 제거해보도록 하자. ssh 원격으로 접속한다.

vagrant@kube-control1:~$ ssh vagrant@kube-node2

노드를 제거하기 전에 kubeadm이 설치한 상태를 reset한다. reset은 다시 작업했던 것들을 초기화하는 것이다. 그리고 iptables를 재설정하려면 다음 명령어도 진행해야하는데, 사용자 계정이라 permission 에러가 떠서 root 권한으로 명령을 실행한다.

vagrant@kube-node2:~$ sudo kubeadm reset

vagrant@kube-node2:~$ sudo -i
root@kube-node2:~$ iptables -F && iptables -t nat -F && iptables -t mangle -F && iptables -X 
root@kube-node2:~# ipvsadm -C

root@kube-node2:~# exit

이제 master node인 kube-control1에서 확인해보면 Not Ready가 표시된다. 이 상태에서 kube-node2를 제거한다.

vagrant@kube-control1:~$ kubectl get nodes
NAME STATUS ROLES AGE VERSION 
kube-control1 Ready master 3h35m v1.19.11 
kube-node1 Ready <none> 178m v1.19.11 
kube-node2 NotReady <none> 3h7m v1.19.11

2. 제거

kubectl delete 명령을 이용해 노드를 제거하고 exit 해서 호스트로 이동한다. 호스트에서 vagrant status를 확인해봐도 된다.

vagrant@kube-control1:~$ kubectl delete node kube-node2 
node "kube-node2" deleted 

vagrant@kube-control1:~$ exit

이후 다시 Vagrant를 이용해서 클러스터 추가를 하기 위해서는 vagrant reload를 해야한다.

노드 추가

이 작업에서는 다시 join을 해줘야하기 때문에 토큰값과 해시값이 필요하다. 먼저 호스트에서 vagrant를 reload해준다.

user@test:~/vagrant/kubernetes$ vagrant reload kube-node2

이후 원격접속

user@test:~/vagrant/kubernetes$ vagrant ssh kube-control1
vagrant@kube-control1:~$ ssh vagrant@kube-node2

master node인 kube-control1에서 토큰과 해쉬값을 확인하여 따로 메모해둔다.

vagrant@kube-control1:~$ kubeadm token list
// token 확인 명령어

지난시간 포스팅했듯 토큰값은 24시간이 지나면 사라지기 때문에 list를 해도 조회가 되지 않는다면 kubeadm token create를 해서 생성해주면 된다.

vagrant@kube-control1:~$ openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outform der 2>/dev/null | openssl dgst -sha256 -hex | sed 's/^.* //' 
// hash값 확인 명령어

토큰값과 해시값이 확인되었으면 token과 hash부분에 값을 넣고 node2로 들어가 연결해준다(join)

sudo kubeadm join <--control-plane-endpoint>:6443 --token <token> --discovery-token-ca-cert-hash <hash>

vagrant@kube-control1:~$ ssh vagrant@kube-node2

vagrant@kube-node2:~$ sudo kubeadm join 192.168.100.11:6443 --token 3quz9~~~~nfyc6exg \ 
--discovery-token-ca-cert-hash sha256:5078ade3213814~~~~~4fe31d8~~~~~~~fa857203278a0ce8405

이후 다시 master node에서 확인해보면 클러스터 구성에 추가됨을 확인할 수 있다.

vagrant@kube-control1:~$ kubectl get nodes
NAME STATUS ROLES AGE VERSION 
kube-control1 Ready master 50m v1.19.11 
kube-node1 Ready <none> 29m v1.19.11 
kube-node2 Ready <none> 105s v1.19.11

참고로 쉘에서 TAB 자동완성이 잘 되지 않으면 아래 명령어를 사용하여 구성한다.

source <(kubectl completion bash)
echo "source <(kubectl completion bash)" >> ~/.bashrc

* 출처 및 참고

Creating a cluster with kubeadm

Using kubeadm, you can create a minimum viable Kubernetes cluster that conforms to best practices. In fact, you can use kubeadm to set up a cluster that will pass the Kubernetes Conformance tests. kubeadm also supports other cluster lifecycle functions, su

kubernetes.io

[쿠버네티스] Vagrant를 이용한 kubeadm 클러스터 업그레이드(Version에 대하여)

심루트 — Fri, 18 Jun 2021 18:18:56 +0900

이번에는 Vagrant를 이용한 kubeadm 클러스터 버전을 업그레이드를 해볼 예정이다. 쿠버네티스 공식 홈페이지에 보면 관련 명령어를 다 확인해볼 수 있다. 오늘 새벽에 최신 버전이 나와서 쿠버네티스의 최신 버전은 현재 기준으로 v1.21.2-00가 최신 버전이다.

아래에 보면 노드 드레이닝(draining)에 대한 내용이 등장한다. drain은 '배수'라는 뜻으로, 싱크대를 비우는 것을 생각해볼 수 있다. kubeadm 클러스터를 업그레이드 하기 전에는 비워놓고 해야한다.

쿠버네티스 홈페이지

아래 명령어를 실행해보면 현재 지원중인 버전의 리스트를 뽑아준다.

vagrant@kube-control1:~$ apt-cache madison kubeadm

Version Skew Policy

먼저 버전에 대한 내용을 이해하기 위하여 Version Skew Policy(갭차이)를 살펴보면,

kubernetes version skew policy

Kubernetes versions are expressed as x.y.z, where x is the major version, y is the minor version, and z is the patch version, following Semantic Versioning terminology. For more information, see Kubernetes Release Versioning.

* 요약 : x는 메이저 버전, y는 마이너 버전, z는 패치 버전

버전은 x.y.z형태로 이루어져 있다.

메이저버전은 메인 버전이고 마이너는 소소한 내용이 변경된 것, 패치는 버그나 보완대응 하기위한 버전이다. 메이저버전은 변경된 적 없고 마이너 버전은 3개월에 한 번씩 바뀐다. 1년에 총 4번의 버전이 나온다. 정확하게는 1년에 총 3번의 버전이 나온다.

하나의 버전은 1년이 지나게 되면 지원이 종료된다. 지금은 2.21.x 버전이 나왔으니 1.18~ 이용이 가능하다.

참고로 AWS의 EKS(Elastic Kubernetes Service)의 경우,

아직까지도 쿠버네티스 버전이 1.20까지만 지원되며, 기본값은 1.19이다. 최신버전은 안정성이 떨어지기 때문에 위험하긴 한 부분이 있어 기본값을 이렇게 셋팅해 놓은 것 같다.

Supported component upgrade order

버전 업그레이드를 하게될 때 순서가 매우 중요하다. 실제 현업에서 중요한 개념인데, 외울 필요는 없지만 알고는 있도록 하자.

kubernetes supported component upgrade order

해당 내용을 읽다보면 순서가 나타나는데,

kube-apiserver -> kube-controllermamager -> kubelet 순서대로 업그레이드를 해야한다.

업그레이드를 하든 업데이트를 하든 그 동안에는 사용을 하지 못한다. 그것을 다운타임이라고 한다. 실제 기업에서는 사용율이 제일 적은 때 서비스를 닫아놓고 다 업데이트한다. ex. 금융권은 추석때 정기점검(그동안 사용 못함)

보통 24/7(24시간 일주일 내내)서비스로 돌아가야 하는 경우 365일동안 장애가 발생하지 않는 한 계속해서 서비스 되어야 하는 것인데, 업데이트를 어떻게 할까?

결론은 부분 부분 해야한다. 모두 다 한꺼번에 다 업데이트를 할 수가 없기 때문이다. 한번에 하면 앞서 말했듯 다운타임이 발생한다.

ex. Naver, Daum은 수십억의 매출 손실이 나기 때문에 순차적으로 부분 부분 업그레이드를 해야 전체 서비스가 중단되지 않는다.

그렇기 때문에 버전 설치 순서에 대한 내용을 알고 있어야 하는 것이다.

업그레이드 테스트를 해볼텐데, 먼저 z에 해당하는 패치 업그레이드 -> y에 해당하는 마이너 업그레이드 순서로 진행 할 것이다.

패치 업그레이드

[v1.18.18-00 -> v1.18.19-00 패치 업그레이드]

* 사전 준비해야 할 환경 : v1.18.18-00로 설치된 master node, node1, node2 환경

준비사항은 이전 포스팅 참고 : Ubuntu 18.04 LTS, Vagrant를 이용한 쿠버네티스 아키텍처 설치

Ubuntu 18.04 LTS, Vagrant를 이용한 쿠버네티스 아키텍처 설치

쿠버네티스의 기본 중에서 쿠버네티스 아키텍처에 대한 간단한 설명과 함께 다양한 테스트를 해보려고 한다. 쿠버네티스 클러스터의 구성 요소는 큼직하게 컨트롤 플레인(Control Plane), 노드(Node)

simroot.tistory.com

패치 업그레이드 순서는 다음과 같다.

1. control-plane
- kubeadm
- kubectl, kubelet
2. kube-node1/node2
- kubeadm
- kubectl, kubelet

1. control-plane

- kubeadm 업그레이드

vagrant@kube-control1:~$ sudo apt-get install -y --allow-change-held-packages kubeadm=1.18.19-00
// kubeadm 업그레이드
vagrant@kube-control1:~$ sudo kubeadm upgrade plan

vagrant@kube-control1:~$ sudo kubeadm upgrade apply v1.18.19
// 조금 오래걸림. 명령이 완료되면 SUCCESS! 가 뜬다.
vagrant@kube-control1:~$ kubectl get nodes
// 아직 변동안되어있음

- kubelet, kubectl 업그레이드

vagrant@kube-control1:~$ sudo  apt-get install -y --allow-change-held-packages kubelet=1.18.19-00 kubectl=1.18.19-00
// kubelet, kubectl 업그레이드

vagrant@kube-control1:~$ sudo systemctl daemon-reload
vagrant@kube-control1:~$ sudo systemctl restart kubelet

vagrant@kube-control1:~$ kubectl get nodes
NAME            STATUS   ROLES    AGE    VERSION
kube-control1   Ready    master   135m   v1.18.19
kube-node1      Ready    <none>   97m    v1.18.18
kube-node2      Ready    <none>   106m   v1.18.18

kubelet, kubectl을 업그레이드 해줄 때에는 daemon을 reload해줘야 하고 kubelet을 restart시켜주는 과정이 필요하다. 이후 노드를 확인해보면 kube-control1만 v1.18.19로 업그레이드 된 것을 확인할 수 있다.

2. kube-node1/node2 각각 업그레이드

- kubeadm 업그레이드

vagrant@kube-node1:~$ sudo apt-get install -y --allow-change-held-packages kubeadm=1.18.19-00
vagrant@kube-node1:~$ sudo kubeadm upgrade node

- kubelet, kubectl 업그레이드

vagrant@kube-node1:~$ sudo apt-get install -y --allow-change-held-packages kubelet=1.18.19-00 kubectl=1.18.19-00
vagrant@kube-node1:~$ sudo systemctl daemon-reload
vagrant@kube-node1:~$ sudo systemctl restart kubelet

* 클러스터 상태 확인

vagrant@kube-control1:~$ kubectl get nodes
NAME            STATUS   ROLES    AGE    VERSION
kube-control1   Ready    master   135m   v1.18.19
kube-node1      Ready    <none>   97m    v1.18.19
kube-node2      Ready    <none>   106m   v1.18.19

-> 나머지 2개의 노드 모두 1.18.19 버전으로 업그레이드 완료

마이너 업그레이드

[v1.18.19에서 1.19의 최신버전(v1.19.11-00)으로 업그레이드하기]

업그레이드 순서는 동일하다.

1. control plane

- kubeadm

- kubelet, kubectl

2. worker node

- kubeadm

- kubelet, kubectl

* 여기서 드는 의문) 만약 작업이 수백대라면? 엄청 오래 걸릴 것. 이 부분도 해결하는 방법이 있을 것 같은데 더 공부해봐야 할 문제인 것 같다.

1.19버전의 최신버전은 무엇일까?

vagrant@kube-control1:~$ apt-cache madison kubeadm | grep 1.19

위 명령어를 이용해 현재 지원되는 1.19버전의 목록을 찾아보았더니 1.19.11-00버전이 최신버전으로 확인된다. 1.18에서 1.19로 두번째 부분인 y 부분이 바뀌는 것이니 마이너 업그레이드라고 할 수 있다.

1. control plane

- kubeadm

vagrant@kube-control1:~$ sudo apt-get install -y --allow-change-held-packages kubeadm=1.19.11-00
vagrant@kube-control1:~$ sudo kubeadm upgrade plan

vagrant@kube-control1:~$ sudo kubeadm upgrade apply v1.19.11

- kubelet, kubectl

vagrant@kube-control1:~$ sudo  apt-get install -y --allow-change-held-packages kubelet=1.19.11-00 kubectl=1.19.11-00

vagrant@kube-control1:~$ sudo systemctl daemon-reload
vagrant@kube-control1:~$ sudo systemctl restart kubelet.service

- 상태 확인

vagrant@kube-control1:~$ kubectl get nodes

2. worker node(kube-node1/node2 각각 업그레이드)

- kubeadm

vagrant@kube-node1:~$ sudo apt-get install -y --allow-change-held-packages kubeadm=1.19.11-00
vagrant@kube-node1:~$ kubeadm version
vagrant@kube-node1:~$ sudo kubeadm upgrade node

- kubelet, kubectl

vagrant@kube-node1:~$ sudo apt-get install -y --allow-change-held-packages kubelet=1.19.11-00 kubectl=1.19.11-00
vagrant@kube-node1:~$ sudo systemctl daemon-reload
vagrant@kube-node1:~$ sudo systemctl restart kubelet

* 클러스터 상태 확인(최종)

kvagrant@kube-control1:~$ kubectl get nodes
NAME            STATUS   ROLES    AGE    VERSION
kube-control1   Ready    master   151m   v1.19.11
kube-node1      Ready    <none>   113m   v1.19.11
kube-node2      Ready    <none>   122m   v1.19.11

글을 마치며..

이번 글을 쓰면서 버전에 대한 개념에 대해 제대로 정립할 수 있었다. 파이썬이나 다른 서비스들을 다운로드 받을 때 최신버전은 안정성이 떨어진다고 하는 동료들의 이야기를 듣고 사실 큰 신경을 쓰지 않았었다. 그런데 쿠버네티스를 공부하면서 모든 서비스들이 서로 유기적으로 연결되어있다보니, 버전은 현업에서 중요하게 작용하는 부분임을 확실하게 느낄 수 있었다.

나중에 이 글을 보더라도 이해할 수 있도록 신경써서 정리를 해봤는데, 중요한 개념들을 종종 적어나가면서 스킬업 해나가야겠다. 다음번 포스팅에서는 Clean up에 대해 다룰건데, 마스터와 노드들을 셋팅하는것도 중요하지만 제거하는 것도 중요하다. 그래서 노드를 제거하는것과 다시 추가해보는 테스트도 진행해볼 것이다.

위에 글에서 정리했던 내용들은 쿠버네티스 공식 홈페이지에 잘 정리되어있고, 이 문서들은 다 영어로 작성되어있어서 가독성이 너무 떨어진다는 점이 있지만 짬내서 번역하며 읽어보는 것도 중요할 것 같다. 아래 링크도 참고해보시길..

* 출처

kubeadm 클러스터 업그레이드

이 페이지는 kubeadm으로 생성된 쿠버네티스 클러스터를 1.20.x 버전에서 1.21.x 버전으로, 1.21.x 버전에서 1.21.y(여기서 y > x) 버전으로 업그레이드하는 방법을 설명한다. 업그레이드가 지원되지 않는

kubernetes.io

Version Skew Policy

The maximum version skew supported between various Kubernetes components.

kubernetes.io

Ubuntu 18.04 LTS, Vagrant를 이용한 쿠버네티스 아키텍처 설치

심루트 — Fri, 18 Jun 2021 13:51:38 +0900

쿠버네티스의 기본 중에서 쿠버네티스 아키텍처에 대한 간단한 설명과 함께 다양한 테스트를 해보려고 한다. 쿠버네티스 클러스터의 구성 요소는 큼직하게 컨트롤 플레인(Control Plane), 노드(Node), 애드온(Addons)이 있다.

컨트롤 플레인은 클러스터의 전체를 제어하고, 노드는 쿠버네티스의 컨테이너 런타임 환경을 제공하며 동작중인 파드를 유지하는 기능을 담당한다. 애드온은 쿠버네티스에 추가할 수 있는 확장 기능을 제공한다. 그래서 Ubuntu 18.04 LTS버전이 설치되어 있는 호스트에서 Vagrant를 이용하여 쿠버네티스 아키텍처를 설치하고, 패치/마이너 업그레이드와 노드 제거 및 추가까지 해볼 예정이다.

* 사전 준비사항 : Vagrant에 VM 3개 생성(kube-control1, kube-node1, kube-node2) 후 도커 설치되어 있는 환경

해당 준비내용은 이전 포스팅을 참고하면 된다.

Ubuntu 18.04 Vagrant 설치 및 기본 사용법, 명령어

VMware나 VirtualBox처럼 가상머신에 가상 컴퓨터가 많이 올라가있으면 부팅이 안 되는 현상이 발생할 수 있다. 그렇기 때문에 안 쓰는 가상 컴퓨터는 싹 정리해주는 과정이 사전에 필요하다. Kubernete

simroot.tistory.com

설치하기 전에..

쿠버네티스를 설치하기 전에 kubeadm을 설치해야한다. 그 이후 kubelet과 kubectl을 설치한다. 이 세가지는 쿠버네티스를 시작하기 위해 중요한 설정이다.

* kubeadm : 클러스터를 부트스트랩(bootstrap)하는 명령어. 설치를 하는 명령어.

bootstrap은 여성의 부츠에 있는 고리. 이 의미는 it의 많은 곳에서 사용된다. bootstrap이라 하는 것은 부츠의 끈을 손으로 들어 올려서 들어 올릴 수 있도록 만드는 것. 자기가 자기 발을 들어 올린다는 말인데, 모든 운영체제는 자기 혼자서 작동하지 못한다.

컴퓨터에 전원을 넣게 되면 boot loader가 실행이 된다. 이 bootstrap이라고 하는 프로그램이 운영체제를 띄운다. 자기가 자기 자신을 잡아당겨서 스스로 구출해낸다는 어원이 있다고 하는데, 그 특성에 맞게 자기 자신이 운영체제를 끌어올린다 해서 bootstrap이라 한다.

-> 쿠버네티스를 끌어올린다. 설치한다는 의미!

* kubelet : 하단의 kubernetes cluster 이미지 참고

쿠버네티스가 설치되려면 Control Plane이 필요하다. 이런 요소도(api, c-m, c-c-m,,) 나중에 컨테이너로 실행된다. 엄밀히 이야기 하면 Control Plane도 worker node이다. 요즘에는 인종차별 논란도 있고 해서 worker라는 이름을 잘 안쓰려고 한다는데, 아무튼 node이다. 실행을 해야 하기 때문인데, 그래서 Control Plane에도 kubelet과 k-proxy가 들어있다. 꼭 기억해야 할 사항이다.

* kubectl : 쿠버네티스를 관리하기 위한 것.

클라우드 컨트롤러 매니저 : kubernetes.io

쿠버네티스 공식 홈페이지에 보면 자세한 설명이 나와있는데, 리눅스 계열 별 설치방법이 각각 따로 존재한다. 호스트가 현재 Ubuntu이기 때문에 데비안 기반 배포판 내용을 참고하여 진행하였다.

설치 시작 (v1.18.18)

1. kube-control1 설치

kube-control1이 control plane이기 때문에 먼저 설치를 한다. enp0s8에 보면 ip 주소는 192.168.100.11이다.

enp0s8 ip 주소 확인

공식 홈페이지에 데비안 기반 배포판을 순차적으로 설치한다.

kubeadm 설치 - 데비안 기반 배포판

설치 내용을 순서대로 살펴보자면 apt update -> 패키지 설치 -> GPG key -> repository 추가 -> 다시 apt update… 가 된다.

* 처음보는 부분) hold라고 하는 것은 apt를 update를 하지 않게 만드는 패키지이다.

왜 업데이트를 하지 않는지? 여러 컴포넌트들이 서로 유기적으로 작용하는데, 각각의 버전이라는 것이 존재한다. 서로 상호 관계가 있기 때문에 잘못 설치하면 쿠버네티스가 죽어버린다. 쿠버네티스 버전을 업데이트 할 때에는 절차라는 것이 존재하는데, 단순하게 패키지를 업데이트 해버리면 안 된다. 그래서 hold를 걸어놓는 것. hold의 반대는 unhold해주면 풀어준다.

vagrant@kube-control1:~$ sudo apt-get update
vagrant@kube-control1:~$ sudo apt-get install -y apt-transport-https ca-certificates curl

vagrant@kube-control1:~$ sudo curl -fsSLo /usr/share/keyrings/kubernetes-archive-keyring.gpg https://packages.cloud.google.com/apt/doc/apt-key.gpg

vagrant@kube-control1:~$ echo "deb [signed-by=/usr/share/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list

vagrant@kube-control1:~$ sudo apt-get update
vagrant@kube-control1:~$ sudo apt install -y kubelet=1.18.18-00 kubeadm=1.18.18-00 kubectl=1.18.18-00
vagrant@kube-control1:~$ sudo apt-mark hold kubelet kubeadm kubectl
kubelet set on hold. 
kubeadm set on hold. 
kubectl set on hold.

위와같이 설치하기 전, 버전을 확인하는 방법은 다음과 같다.

vagrant@kube-control1:~$ apt info kubeadm
Package: kubeadm  
Version: 1.21.1-00  

vagrant@kube-control1:~$ apt-cache madison kubeadm

info는 최신버전을 확인하는 명령어이며, 후자는 설치 가능한 버전을 확인할 수 있도록 출력해주는 명령어이다. kubelet, kubectl도 마찬가지.

apt-cache madison 명령어를 입력하면 kubeadm설치할 수 있는 목록 리스트업이 쫙 나온다. kubeadm 홈페이지 설치 순서 4번의 update까지만 설치를 완료해서 해당 명령어로 확인해보면 버전을 확인할 수 있다. 테스트를 위해 1.18.18-00 설치하기로 한다. 그래서 install 부분의 버전들을 1.18.18--00으로 설치하였다. 이후 버전을 업데이트 할 예정이다.

next..

- Creating a cluster with kubeadm

control-plane node에서는 최초 1회에 한해서 이니셜라이징 작업이 필요하다. control-plane(master구성) 네트워크 구성 및 환경구성을 진행한다.

sudo kubeadm init --control-plane-endpoint 192.168.100.11 --pod-network-cidr 192.168.0.0/16 --apiserver-advertise-address 192.168.100.11

서브넷은 /24 보다도 /16으로 잡아주는 게 컨테이너를 많이 생성할 수 있다. 많이 사용하기 위해 /16, /12정도로도 만든다.

kubeadm init –control-plane-endpoint : ip a s했을 때 알수있는 ip주소. endpoint. 그래서 control-plane인 kube-control1 사용자의 사설ip 주소를 적어주었다. VM을 생성할 때 이 ip대역으로 생성하기도 하였다.

--apiserver-advertise-address : worker node에게 알려 줄 주소

만들고 나서 나오는 To start~로 시작하는 장문의 글을 따로 복사해둔다. 그 순서대로 node join까지 진행할 수 있다. 아래 더보기를 참고하면 된다.

To start using your cluster, you need to run the following as a regular user:

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
//자격증명 구성. master에 kubernetes 컴포넌트들이 생성되는 것인데 출력 결과에서 mkdir, cp, chown 명령을 kubernetes 관리자 계정에서 실행한다. 나오는 내용을 복사 붙여넣기해서 사용하면 편하다.

You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
https://kubernetes.io/docs/concepts/cluster-administration/addons/
// addon 구성

You can now join any number of control-plane nodes by copying certificate authorities
and service account keys on each node and then running the following as root:

kubeadm join 192.168.100.11:6443 --token k~~~@#~~~xr8tz7 \
--discovery-token-ca-cert-hash sha256:6bd28~~b8dcf90a43~~~~~~~72101cb65a15819f351fa \
--control-plane
// control-plane node를 추가하는 값. kubeadm join <token> 은 worker node가 master에 연결될때 필요하다. 별도로 저장해두도록 한다.

Then you can join any number of worker nodes by running the following on each as root:

이미지는 미리 받아놓기(pulling 시간 오래걸림)

vagrant@kube-control1:~$ kubeadm config images pull

vagrant@kube-control1:~$ docker image ls
REPOSITORY TAG IMAGE ID CREATED SIZE 
wordpress 5.7 c2dd1984ad5b 11 days ago 551MB 
k8s.gcr.io/kube-proxy v1.18.19 a5cae4db9292 4 weeks ago 117MB 
k8s.gcr.io/kube-apiserver v1.18.19 d26f380d3e93 4 weeks ago 173MB 
k8s.gcr.io/kube-controller-manager v1.18.19 4b0bf89255ad 4 weeks ago 162MB 
k8s.gcr.io/kube-scheduler v1.18.19 916efc2e1cec 4 weeks ago 96.1MB 
mysql 5.7 2c9028880e58 4 weeks ago 447MB 
k8s.gcr.io/pause 3.2 80d28bedfe5d 16 months ago 683kB 
k8s.gcr.io/coredns 1.6.7 67da37a9a360 16 months ago 43.8MB 
k8s.gcr.io/etcd 3.4.3-0 303ce5db0e90 19 months ago 288MB

이후 진행할 명령어

mkdir ~/.kube 
sudo ls /etc/kubernetes/admin.conf 
sudo cp /etc/kubernetes/admin.conf ~/.kube/config 
sudo chown vagrant:vagrant ~/.kube/config 

ls -l ~/.kube/config 
kubectl get nodes 
cat ~/.kube/config

kubectl get nodes를 통해서 kube-control1이 master노드임을 확인할 수 있다. STATUS가 아직 NotReady로 되어있는데, 일정 시간이 지나면 곧 Ready로 바뀐다.

추가로 network 설정을 도와주는 addon을 설치한다. network addon의 종류는 많이 있는데, 가장 많이 쓰이는 것이 Calico이다. Calico에 관련된 명령어 및 설명은 참고링크를 아래 달아두었다.

curl https://docs.projectcalico.org/manifests/calico.yaml -O
kubectl apply -f calico.yaml

curl~파일 받아서 저장 후 ls하면 calico.yaml파일이 다운로드 된다. vim같은 편집기로 calico.yaml파일에 들어와보면 ip address가 설정되어 있는데, 이 부분을 적절하게 바꿔준다. 192.168.0.0 로 다운로드가 받아져서 따로 바꾸지 않았다.

그 다음 명령어 실행하면 쿠버네티스 사용의 전제조건인 Objectives부분을 만족하게 된다.

2. kube-node1 추가(worker node 구성)

master node(control-plane)을 셋팅하는 데만 꽤나 복잡하고 오래 걸렸지만, 이 셋팅을 최초 1회만 해주면 이제 node를 붙였다 떼는 건 쉽게 진행할 수 있다. 이 작업은 각 노드에서 진행하기 때문에 ssh 원격접속으로 kube-node1에서 작업한다.

vagrant@kube-control1:~$ ssh vagrant@kube-node1

kube-control1 안에서 ssh 원격접속하는 명령어는 호스트에서 접속할 때와 다른 점을 주의하자. 이렇게 이중으로 접속하게 되면 비밀번호를 물어보는데, 기본 셋팅되어 있는 비밀번호는 vagrant이다.

* Add Worker (node1/node2) WorkFlow

1. Docker 설치(사전에 완료해놓았음)

2. kubeadm, kubectl, kubelet=1.18.18-00 설치

3. 설치 후에 join만 해주면 됨. (아까 더보기에 있던 내용의 마지막 부분을 참고하여 token을 포함한 join명령을 실행해야 한다)

1) kubeadm 설치

vagrant@kube-node1:~$ sudo apt-get update
sudo apt-get node1:~$ sudo apt-get install-y apt-transport-https ca-certificates curl

위 2줄은 마스터노드를 구성한 뒤 생략 가능하다.

sudo curl -fsSLo /usr/share/keyrings/kubernetes-archive-keyring.gpg https://packages.cloud.google.com/apt/doc/apt-key.gpg

echo "deb [signed-by=/usr/share/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list

sudo apt-get update
sudo apt install kubectl=1.18.18-00 kubeadm=1.18.18-00 kubelet=1.18.18-00
sudo apt-mark hold kubelet kubeadm kubectl

마스터노드 때와 마찬가지로 kubeadm을 설치한다.

* kube-control1에서 했던 아래 명령은 node에서 진행 XX -> master node에서만 1회 진행하면 된다.

kubeadm config images pull
sudo kubeadm init --control-plane-endpoint 192.168.100.11 --pod-network-cidr 192.168.0.0/16 --apiserver-advertise-address 192.168.100.11

이 명령어는 참고만 하며, node1과 node2는 아래 토큰과 해시값을 추가하여 join만 해주면 된다. 이전에 master node를 생성할 때 나왔던(더보기 참고) 맨 마지막줄의 token, hash값을 참고한다. 혹시 그 값을 잊어버리면 아래 명령어를 통해서 확인해볼 수 있다. master node인 kube-control1에서 아래 명령어를 입력해주면 된다.

vagrant@kube-control1:~$ kubeadm token list
vagrant@kube-control1:~$ kubeadm token create

token list는 토큰값을 출력해주는 명령어이다. token은 24시간 뒤면 만료가 되어 사라지는데 그럴 땐 당황하지 않고 create를 해주면 생성된다.

vagrant@kube-control1:~$ openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outform der 2>/dev/null | \
   openssl dgst -sha256 -hex | sed 's/^.* //'

hash값을 구하는 명령어

hash값 구하기

2) join

따라서 node1에 아래와 같은 문법을 입력할 수 있다.

sudo kubeadm join 192.168.100.11:6443 --token <token값> --discovery-token-ca-cert-hash sha256:<hash값>

sudo kubeadm join 192.168.100.11:6443 --token k457sc.6daeqo~~~~r8tz7 --discovery-token-ca-cert-hash sha256:6bd28d05b8~~~~ae172101cb65a15819f351fa

3. kube-node2 추가

위와같은 작업을 node2에도 반복한다.

4. Control-plane에서 확인

vagrant@kube-control1:~$ kubectl get nodes

kubectl get nodes 하면 node1, node2가 보여야 함.

<결과화면>

NAME            STATUS   ROLES    AGE     VERSION
kube-control1   Ready    master   2d20h v1.18.18
kube-node1      Ready    <none>   2d20h v1.18.18
kube-node2      Ready    <none>   2d19h v1.18.18

원래는 패치 업그레이드, 마이너 업그레이드, 노드 제거, 노드 추가까지 하려고 했는데 내용이 길어져서 다음 포스팅에 이어서 작성을 해볼 예정이다. 위에 설명했던 내용에서 참조했던 링크를 아래 올려두었으니 참고하면 된다.

* 참고자료 *

kubeadm 설치하기

이 페이지에서는 kubeadm 툴박스를 설치하는 방법을 보여준다. 이 설치 프로세스를 수행한 후 kubeadm으로 클러스터를 만드는 방법에 대한 자세한 내용은 kubeadm을 사용하여 클러스터 생성하기 페이

kubernetes.io

Creating a cluster with kubeadm

kubernetes.io

Install Calico networking and network policy for on-premises deployments

Install Calico networking and network policy for on-premises deployments.

docs.projectcalico.org

쿠버네티스란 무엇인가?

심루트 — Thu, 17 Jun 2021 14:00:42 +0900

쿠버네티스란 명칭은 키잡이(helmsman)나 파일럿을 뜻하는 그리스어에서 유래했다. 그래서 공식 마크도 배의 키 모양을 하고 있는 것 같다. K8s라는 표기는 "K"와 "s"와 그 사이에 있는 8글자를 나타내는 약식 표기이다. 구글이 2014년에 쿠버네티스 프로젝트를 오픈소스화했다. 쿠버네티스는 프로덕션 워크로드를 대규모로 운영하는 15년 이상의 구글 경험과 커뮤니티의 최고의 아이디어와 적용 사례가 결합되어 있다.

kubernetes

사실 기본적인 내용은 쿠버네티스 공식 홈페이지에서 확인해볼 수 있다. 그렇지만 내용이 너무 많기 때문에 조금더 이해하기 쉽게 요약을 해보려고 한다.

쿠버네티스가 제공하는 기능으로는 다음과 같다.

- 컨테이너 플랫폼

- 마이크로서비스 플랫폼

- 이식성 있는 클라우드 플랫폼

쿠버네티스는 컨테이너 기반의 분산 클러스터 환경을 제공하며 워크로드를 위해 컴퓨팅, 네트워킹 및 스토리지 인프라를 오케스트레이션(Orchestration)한다. 도커가 한두개의 작은 컨테이너를 작업한다면 쿠버네티스는 아래 이미지처럼 컨테이너를 지휘하는 문어라고 생각하면 된다. (문어가 아니어도 상관 없다ㅎ) 사실 오케스트레이션 도구는 지난 포스팅에서 알 수 있듯 docker swarm이나 아파치 메소스도 있다. 그렇지만 독보적으로 자리잡고 있는 것이 바로 쿠버네티스이다.

이해를 돕기 위한 docker swarm이미지 참고

쿠버네티스가 제공하지 않는 기능들도 존재한다. 쿠버네티스는 클라우드의 Paas(Platform-as-a-service)의 분류에 속한다. 그렇지만 일반적인 Paas의 모든 개념을 포함하고 있지는 않다. 하드웨어 단에서 운영되는게 아니고 컨테이너단에서 운영되기 때문에 PaaS의 일부 기능만 제공한다.

쿠버네티스가 제공하지 않는 주요 기능은 다음과 같다.

- CI/CD(Continuous Integration/Continuous Delivery) 파이프라인

- 애플리케이션 레벨의 서비스

- 로깅, 모니터링, 경고 솔루션

생각보다 제공하지 않는 기능들이 많다. CI/CD 파이프라인이 제공되지 않는 기능이라고 하는데, 사실 쿠버네티스를 한다면 CI/CD 파이프라인 구축에 대한 내용을 들어봤을 수 있다. 사용이 가능한 이유는 바로 별도의 도구로 구현할 수 있기 때문이다. 별도로 add-on해서 다양한 기능들을 활용할 수 있다.

쿠버네티스 관련된 기능과 개념들을 공부해보면서 개인적인 생각으로는, 마크나 로고 디자인이 너무 귀엽다는 것이다.. 쿠버네티스 어원대로 키잡이가 그대로 마크에 반영되고, 도커 스웜도 마찬가지로 물속에 사는 문어인지 오징어인지가 나와서 컨테이너 들고있는 모습들이 너무 귀엽고 센스있는 것 같다. 개인적으로는 도커나 쿠버네티스 티셔츠 한 장 가지고 싶을 정도 ㅎㅎ..

다음 포스팅때에는 도커를 통해 컨테이너를 구축했던 개념을 가지고 앞으로 쿠버네티스 설치부터 시작하여 기초 명령어들을 테스트 해볼 예정이다. kubeadm설치, kubelet, kubectl 설치도 중요한데 함께 다뤄 볼 기회가 있을 것 같다.

<참고>

쿠버네티스란 무엇인가?

쿠버네티스는 컨테이너화된 워크로드와 서비스를 관리하기 위한 이식할 수 있고, 확장 가능한 오픈소스 플랫폼으로, 선언적 구성과 자동화를 모두 지원한다. 쿠버네티스는 크고 빠르게 성장하

kubernetes.io

마이크로서비스와 Devops에 대하여

심루트 — Thu, 17 Jun 2021 08:00:37 +0900

쿠버네티스를 이해하기 위해 먼저 모놀로식 아키텍처와 마이크로서비스 아키텍처의 차이에 대해 살펴보자.

* 모놀리식(Monolithic) 아키텍처 : 레거시 시스템(legacy)이라고도 함. 옛날 느낌이지만 아직도 사용하고 있는 아키텍처이며 대부분 단일 프로세스에서 실행이 되거나 몇개의 프로세스로 실행됨.

- 장점 : 간단한 개발, 배포가 가능하며 단순한 확장성

- 단점 : 코드 품질이 낮아짐, 애플리케이션 시작이 오래걸림, 지속적인 배포가 어려움, 애플리케이션 확장의 어려움, 컴포넌트별 개발의 어려움, 다양한 기술적용의 어려움

* 마이크로서비스(Microservice) 아키텍처 : 모놀로식 아키텍처의 크기가 커지면서 발생하는 문제점을 극복하기 위해 좀더 기능적으로 세분화되고 독립적으로 작동하는 방식.

- 장점 : 크고 복잡한 애플리케이션을 지속적으로 배포할 수 있음, 개발 생산성 높고 배포 속도가 높음, 향상된 장애 격리, 다양한 기술 적용이 가능함.

- 단점 : 분산시스템 설계에 따른 복잡성, 배포 및 관리 운영상의 복잡성, 증가된 리소스 소비

기존의 모놀로식 아키텍처를 사용하다보면 코드가 점점 커질 경우에 실수하기가 쉽다. 그러한 상황들에 대비하기 위해서 마이크로서비스라는 기능적으로 세분화되고 독립적으로 작동하는 방식을 사용하게 되었다. 그렇다고 기존의 모놀리식 아키텍처가 단점만 있는 것도 아니고, 요즘에도 사용하고 있기는 하다. 그러나 마이크로서비스 아키텍처의 장점이 많아서 요즘 많이 사용하고 있는 추세이다. 장점만 있는 것이 아니라 단점도 있는데 마이크로서비스 아키텍처의 단점은 복잡해진다는 것이다.

* Devops

Devops[데브옵스]는 개발 방법이 아닌 하나의 문화이다.

이렇게 한 마디로 정의를 할 수가 있다. 사실 예전에는 데브옵스라고 하면 개발과 운영을 편리하게 해주는 것?으로 나름대로 정의를 내렸었는데, 하나의 문화라는 표현이 더 적절한 것 같다. 하드웨어 뿐만이 아니라 운영, 개발도 알아야 한다. 대부분 운영만 알고있는 경우가 많은데, 전체 프로세스가 어떻게 흘러가는지를 알아야 한다.

devops라 하면 흔히 볼 수 있는 이미지다. 시작이 어디고 끝이 어딘지 모르겠으나 전체적인 프로세스의 흐름을 알아야 하는 것이 devops 엔지니어가 되기 위해서 중요하다.

예전에는 개발팀, QA팀, 운영팀 각각 나눠져서 배포, 관리를 하는 흐름을 가지고 있었다면 최근에는 개발자가 개발만 하는것이 아니라 전반적인 사이클을 알아야 하고 마찬가지로 운영팀 등 모두가 전체적인 작업들을 함께한다는 이야기다. 소통, 협업 및 통합을 강조하는 개발 환경 및 문화를 일컬어 Devops라고 한다.

참고로 docker swarm, Apache Mesos, 쿠버네티스 등등.. 이것들은 도커를 클러스터링(오케스트레이션) 하는 환경이다. 이 중에서 지금까지 남아있는 건 쿠버네티스이다. 쿠버네티스가 시장을 장악한 지는 3년정도밖에 안 되긴 했다. 얼마 되지 않는데 거의 독보적인 개념이니만큼 하나하나 알아가보도록 할 것이다.

Kubernetes는 K와 s 사이에 총 8글자가 들어간다고 해서 약어로 k8s라고 적는다. 이전에는 구글이 만들었지만 현재 CNCF 재단으로 넘어갔다는 건 참고로 알아두도록 하자. 그리고 중요한 것은 컨테이너 개념을 제대로 이해해야 쿠버네티스를 제대로 이해할 수 있다.

Vagrant 가상머신에 docker로 wordpress 구현(Ubuntu 18.04 LTS)

심루트 — Wed, 16 Jun 2021 17:22:51 +0900

Vagrant 설치한 뒤 아래 환경을 구축했다는 전제로 Vagrant 가상머신 각각에 docker를 설치하여 그 안에서 wordpress를 구현을 해볼 예정이다. 아래 내용을 참고하면 된다. 이와 관련하여 궁금한 점은 지난 포스팅을 참고하면 된다.

Ubuntu 18.04 Vagrant 설치 및 기본 사용법, 명령어

simroot.tistory.com

* 준비사항 : Vagrant로 만들었던 3개의 가상머신 kube-control1, kube-node1, kube-node2

wordpress 구현 실습은 kube-control1에서 진행한다.

도커를 사용하는 것 처럼 먼저 도커 레포지토리를 추가하고 패키지를 설치해주어야 한다.

<도커엔진 설치>

Install Docker Engine on Ubuntu

docs.docker.com

위 본문 내용을 참고하여서 도커 레포지토리와 GPG key, 도커엔진을 설치해준다.

docker로 접근하는 경로는 일반 사용자로는 실행되지 않으며, root 계정이어야 한다. 따라서 명령어 앞에 sudo를 사용하거나 일반 사용자도 사용할 수 있도록 docker 그룹을 추가해줘야 한다.

vagrant@kube-control1:~$ sudo usermod -aG docker vagrant
vagrant@kube-control1:~$ id
uid=1000(vagrant) gid=1000(vagrant) groups=1000(vagrant)

docker 보조그룹을 추가해주었다. 권한추가를 하고나서 바로 적용되는 것은 아니고, 재접속을 해줘야 한다.

vagrant@kube-control1:~$ exit
user@test:~/vagrant/kubernetes$ vagrant ssh kube-control1
vagrant@kube-control1:~$ docker ps
CONTAINER ID   IMAGE     COMMAND   CREATED   STATUS    PORTS     NAMES

-> 일반 사용자로도 docker ps 명령이 permission denied 에러가 나지 않고 잘 실행된다.

wordpress

이제 wordpress를 구축할 환경이 마련되었다.

이후 dockerhub에서 wordpress image를 다운로드한다. 참고로 이미지의 버전(tag) 중 latest가 디폴트값으로 설정되어있다. 주의할 점은 오늘의 latest와 내일의 latest는 다를 수 있기 때문에 가능한 latest태그를 사용하는 것이 아니라 버전을 지정해주는 것이 원칙이다. 간단한 실습을 할 거지만 안정적인 구성을 위해 최신버전보다는 나온지 조금 된 버전으로 사용한다. 5.7버전을 이용하도록 하자.

도커허브에 들어가보면 이 이미지들을 어떻게 사용할 수 있는지 가이드들이 나와있다. How to use this image가 적혀져있는 곳을 보면 환경변수들을 지정할 수 있다.

-e WORDPRESS_DB_HOST=...

-e WORDPRESS_DB_USER=...

-e WORDPRESS_DB_PASSWORD=...

-e WORDPRESS_DB_NAME=...

기본적으로 wordpress의 포트는 80번포트이며 dettach인 -d 옵션을 사용하여 동작시키면 된다. 그리고 중요한 것은 run을 할 때 볼륨지정을 해준다는 것이다.

* 볼륨 : /var/www/html

* 워드프레스는 포트포워딩을 해줘야 함.

MySQL

도커허브 MySQL official 이미지에 보면 이것도 8버전과 5버전이 나와있다. 대부분 5버전대를 주로 사용하기 때문에 실습은 5.7버전으로 다운로드 받아서 진행한다. 추가로 자주 사용하는 환경변수 3가지도 있으며 이것 또한 docker run 실행시 -d 모드로 사용한다.

MYSQL_DATABASE

MYSQL_USER

MYSQL_PASSWORD

* 볼륨 : /var/lib/mysql

control plane인 cube-control1에서 아래와 같이 구현한다.

vagrant@kube-control1:~$ docker pull wordpress:5.7
vagrant@kube-control1:~$ docker pull mysql:5.7

vagrant@kube-control1:~$ docker run -d --name wpdb -e MYSQL_ROOT_PASSWORD=toor -e MYSQL_DATABASE=wpdb -e MYSQL_USER=wp -e MYSQL_PASSWORD=wppass -v wp-vol:/var/lib/mysql mysql:5.7

vagrant@kube-control1:~$ docker run -d -p 8080:80 --name wp --link wpdb:wpdb -e WORDPRESS_DB_HOST=wpdb -e WORDPRESS_DB_USER=wp -e WORDPRESS_DB_PASSWORD=wppass -e WORDPRESS_DB_NAME=wpdb  -v wp-vol:/var/www/html wordpress:5.7

wordpress와 mysql 이미지 5.7버전을 pull(다운로드)한 뒤, DB, wordpress 순서로 docker run 해준다.

워드프레스는 80번포트를 사용하기 때문에 8080번으로 지정했을 때 확인할 수 있도록 -p 옵션으로 포트포워딩을 해주었다.

--link를 해줌으로써 db와 연동시켰다.

run할 때 자주 사용하는 환경변수들을 각각 지정해주었고, wp-vol이라는 볼륨을 생성하여 각각 위치를 연결시켰다. 따라서 아래와 같이 확인할 수 있다.

vagrant@kube-control1:~$ docker volume ls
local     wp-vol

wp-vol 확인됨.

이제 새 탭에서 kube-control1의 ip주소를 입력한 뒤, 8080포트로 접근하면 워드프레스 회원가입하는 화면이 등장한다. 아이디와 비밀번호를 입력하고 로그인하면 메인 페이지가 확인된다.

주소탭 검색 : 192.168.100.11:8080 -> 회원가입 진행 -> 로그인 -> 아래 결과화면

wordpress main page

결과적으로 wordpress가 구현되었고, 이제 이 안에서 글을 남기고 댓글을 작성하는 내용들이 mysql db에 저장되게 된다. 간단하게 작업해볼 수 있는 docker로 구현해보는 wordpress 테스트였다. 항상 모든 실습을 마무리할 때에는 vagrant를 halt해서 잠시 멈춰주도록 한다. 그렇지 않으면 호스트 컴퓨터를 종료할 수가 없기 때문이다.

user@test:~/vagrant/kubernetes$ vagrant halt

Ubuntu 18.04 Vagrant 설치 및 기본 사용법, 명령어

심루트 — Tue, 15 Jun 2021 09:20:02 +0900

VMware나 VirtualBox처럼 가상머신에 가상 컴퓨터가 많이 올라가있으면 부팅이 안 되는 현상이 발생할 수 있다. 그렇기 때문에 안 쓰는 가상 컴퓨터는 싹 정리해주는 과정이 사전에 필요하다.

Kubernetes에 대해 들어가기 앞서 필요한 새로운 툴인 Vagrant를 설치해보려고 한다. Vagrant[베이그런트]는 요즘 핫한 HashiCorp[하쉬코프] 회사의 도구 중 하나이며, Terraform이라는 툴 또한 유명하다. 위키백과에 보면 Vagrant는 포터블 가상화 소프트웨어 개발환경이라고 정의하고 있다. 쉽게 말해서 VM을 코드로 만들어주는 도구이며 테스트 환경에서 주로 사용한다. 지금은 2버전인데, 3버전을 계획하고 있으며 2버전은 Ruby로 만들어졌지만 3버전은 Go lang으로 만들어 질 예정이다.

도커처럼 이미지를 받아서 Vagrant를 사용할 수 있다. Vagrant 홈페이지에서 다운로드를 누르면 하단에 시스템 환경에 맞는 버전을 다운받을 수 있다.

Vagrant by HashiCorp

Vagrant enables users to create and configure lightweight, reproducible, and portable development environments.

www.vagrantup.com

HashiCorp 공식 홈페이지

현재 호스트 Ubuntu가 18.04 LTS 버전이기 때문에 여기에 맞게 Debian 64로 받아주었다. Downloads파일에 저장이 되어 있어서 디렉토리 위치를 이동시켜준 뒤 아래 작업을 실행한다.

cd Downloads
sudo dpkg -i vagrant_2.2.16_x86_64.deb
vgrant -v

vagrant로 시작하는 버전은 설치파일명을 작성해주면 되며, 세번째 명령어를 이용하여 현재 설치된 vagrant 의 version을 확인할 수 있다. 작업을 할 디렉토리를 지정해두는 게 편하기 때문에 임의의 폴더를 하나 생성한다.

mkdir -p /vagrant/kubernetes
cd /vagrant/kubernetes/

실습폴더 생성 완료. 만들어준 디렉토리로 이동해준다.

앞서 Vagrant는 이미지를 다운받아 사용할 수 있다고 하였다. 아래의 Vagrant Cloud에서 도커허브처럼 이미지를 확인할 수 있다. 우리는 OS로 ubuntu환경에서 작업을 할 예정이므로 ubuntu/focal64를 다운받을 것이다.

Vagrant Cloud by HashiCorp

app.vagrantup.com

아래는 홈페이지 이미지 다운로드 화면이다. 다른 OS들도 올라와 있으며 명령어로 다운받을 예정이다.

Ubuntu bash 쉘 창에서 아래의 명령어를 진행한다. init은 Vagrant를 초기화해주는 명령어이며 도커에서 Dockerfile을 사용하는 것 처럼 Vagrantfile이 생성되어 편집해서 사용할 수 있다. init을 해주면 현재 위치해있는 디렉토리에 vagrant가 만들어졌다고 안내메세지가 뜨는 게 정상이다. 이 상태에서 ls를 입력해보면 Vagrantfile이 정상적으로 생성된 것을 확인할 수 있다.

vagrant init ubuntu/focal64
ls

vim을 이용해 Vagrantfile에 들어가보면 이런 내용을 확인할 수 있다. configure("2")는 2버전을 의미하며 vm.box는 아까 이미지를 다운로드 했던 버전을 확인해볼 수 있다.

vim Vagrantfile

:q! 를 입력하여 이 창을 나와준다.

생성 및 부팅

이제 이 상태에서 vagrant up을 사용하면 가상환경이 시작된다. 부팅을 하는 것인데, 첫 부팅이면 다운로드도 같이 해주면서 생성된다.

vagrant up

다운로드를 완료하는 데 까지는 시간이 조금 걸린다.

상태확인

상태확인을 하면 현재 러닝중인지 생성만 되었는지 확인할 수 있다. 디폴트 상태로 러닝중이다.

vagrant status

ssh 접속, 종료

가상머신이 생성되면 ssh로 들어갈 수 있으며 빠져나오려면 exit를 사용한다. Vagrantfile을 변경해준 게 없기 때문에 뒤에 가상머신 이름은 따로 넣지 않고 ssh를 사용해보았다.

vagrant ssh <가상머신 이름>
exit

VM 종료

running중인 가상컴퓨터(가상머신)을 끄는 명령어다. VM이 셧다운됨을 알 수 있다.

vagrant halt

VM 삭제

종료는 다시 시작할 수 있지만, 삭제는 아예 없앨 수 있는 명령어다. 그래서 rm 명령어처럼 삭제할 것인지 재 확인하는 문구가 뜨면 y를 입력해줘야 한다. 실습할 때는 눌러주기 귀찮으니 -f 옵션을 사용해서 한방에 삭제해줄 수도 있다.

vagrant destroy -f

버전 업데이트

추가로 vagrant 버전을 업데이트 해 주는 명령어다. 오늘기준으로 최신 버전으로 업데이트하였다.

vagrant box update

6월 10일버전이 현재 최신버전임. 아래 결과가 확인된다.

'ubuntu/focal64' (v20210610.0.0) is running the latest version.

Vagrant 작성

앞서 Dockerfile이나 Docker-Compose.yml 파일을 사용하는 것 처럼 Vagrant도 Vagrantfile을 사용한다고 했다. 현재 디렉토리에 생성되었던 파일을 참고하여서 작성하여 테스트 해보려고 한다. 먼저 네트워크는 100번대를 사용할 예정인데, 이 대역을 다른 가상머신에서 사용하고 있으면 에러가 나므로 사용하던 네트워크 대역을 삭제하거나 겹치지 않는 대역을 사용하는 것이 중요하다.

vim Vagrantfile

파일을 아래와 같이 수정해서 테스트하였다.

# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure("2") do |config|
  # kube-control1 VM
  config.vm.define "kube-control1" do |config|
    config.vm.box = "ubuntu/focal64"
    config.vm.provider "virtualbox" do |vb|
       vb.name = "kube-control1"
       vb.cpus = 2
       vb.memory = 3000
    end
    config.vm.hostname = "kube-control1"
    config.vm.network "private_network", ip: "192.168.100.11"
  end

  # kube-node1 VM
  config.vm.define "kube-node1" do |config|
    config.vm.box = "ubuntu/focal64"
    config.vm.provider "virtualbox" do |vb|
       vb.name = "kube-node1"
       vb.cpus = 2
       vb.memory = 3000
    end
    config.vm.hostname = "kube-node1"
    config.vm.network "private_network", ip: "192.168.100.21"
  end

  # kube-node2 VM
  config.vm.define "kube-node2" do |config|
    config.vm.box = "ubuntu/focal64"
    config.vm.provider "virtualbox" do |vb|
       vb.name = "kube-node2"
       vb.cpus = 2
       vb.memory = 3000
    end
    config.vm.hostname = "kube-node2"
    config.vm.network "private_network", ip: "192.168.100.22"
  end

  # Hostmanager Plugin
  config.hostmanager.enabled = true
  config.hostmanager.manage_guest = true

  # Provision
  config.vm.provision "shell", inline: <<-SHELL
    sed -i 's/ChallengeResponseAuthentication no/ChallengeResponseAuthentication yes/g' /etc/ssh/sshd_config
    sed -i 's/archive.ubuntu.com/ftp.daum.net/g' /etc/apt/sources.list
    sed -i 's/security.ubuntu.com/ftp.daum.net/g' /etc/apt/sources.list
    systemctl restart ssh
    apt update
    apt install -y chrony
  SHELL
end

다음은 위 파일에 대한 설명이다.

1. VM 설정

3개의 VM을 만들기 위해 kube-로 시작하는 VM을 지정해주었다. 그 중에 설명을 돕기 위해 첫 번째 VM에 대한 설명이다.

config.vm.define "kube-control1"

VM 이름

config.vm.box = "ubuntu/focal64"

VM 이미지

config.vm.provider "virtualbox"

도구를 virtualbox를 이용하겠다

vb.name = "kube-control1"

가상컴퓨터의 이름(ssh 뒤에 이 이름을 넣어 접속함)

config.vm.hostname = "kube-control1"

가상컴퓨터 내에 있는 hostname

config.vm.network "private_network", ip: "192.168.100.11"

100번대 네트워크를 만들어줄 것인데 ip address를 지정해주었다.

2. Hostmanager Plugin

plugin에 대한 설정

3. Provision

 config.vm.provision "shell", inline:

AWS에서 인스턴스 생성 후 자동으로 스크립트를 실행할 수 있는 스크립트 입력란이 있다. 그것과 마찬가지로 쉘 스크립트를 의미하며, 최초 생성시 실행할 스크립트다. sed는 대화 형태의 명령어다.

sed -i 's/ChallengeResponseAuthentication no/ChallengeResponseAuthentication yes/g' /etc/ssh/sshd_config

AWS EC2 instance는 password 인증이 되지 않고 키 기반 인증만 가능하다. 그래서 .pem파일을 다운로드 받아서 사용하였다. 그렇지만 위 sed 뒤의 내용은 패스워드 기반 인증을 허용하게 해 주는 부분이다.

sed -i 's/archive.ubuntu.com/ftp.daum.net/g' /etc/apt/sourcees.list
sed -i 's/security.ubuntu.com/ftp.daum.net/g' /etc/apt/sources.list

이 두 줄은 apt 저장소를 바꿔준다. Ubuntu.com으로 셋팅되어 있는데, 이게 한국에서 쓰기에는 꽤 느려서 daum으로 잡아주었다. 빠르게 패키지를 받을 수 있다.

사전 플러그인 설치

Vagrant up을 하기 전 플러그인을 먼저 설치한다.

vagrant plugin install vagrant-hostmanager
vagrant plugin list

vagrant-hostmanager (1.8.9, global) 라는 버전 결과창이 떴다.

vagrant up

up을 함으로 VM이 생성 및 실행된다. VM을 3개나 생성했기 때문에 시간이 조금 걸린다.

* 순서

네트워크 대역 중복 확인 – Vagrantfile수정(스크립트 참고) - vagrant hostmanager install – vagrant up - virtualbox에 가상머신 3대가 띄워져 있는 것을 확인할 수 있음

<결과화면>

확인

현재 상태를 확인해보니 VM 3개가 러닝중이다.

vagrant status

각 VM으로 접속하기 위해 ssh를 사용한다. 추가로 ip설정이 제대로 되었는지는 /etc/hosts에 가보면 알 수 있다. 처음에 만든 kube-control1으로 접속해서 테스트한다.

vagrant ssh kube-control1
cat /etc/hosts

지금까지 Vagrant 설치 및 기본적인 명령어에 대해서 살펴보았다. VM을 GUI가 아닌 CLI에서 사용한다는 점이 신기하기도 하고 생각보다 간단한 명령어라서 사용할 만 한 것 같다(아직까지는ㅎㅎ) HashiCorp사에서 나온 오픈소스 툴을 사용해본 것으로 좋은 경험이라고 생각한다.

다음 포스팅에서는 이 가상머신 안에 도커를 설치하고 wordpress를 구현해 볼 예정이다.

리눅스 컨테이너란? 가상머신과의 차이, Docker Daemon에 대하여

심루트 — Thu, 3 Jun 2021 10:08:50 +0900

앞서 컨테이너 가상화에 대해 언급을 했다. 리눅스 컨테이너는 컨테이너 가상화 기술을 사용한다.

이 리눅스 컨테이너에는 애플리케이션이나 그에 따라 필요한 라이브러리나 설정파일 등이 포함되어 있다. 가상머신과는 다르게 가상화 계층이 없고 커널이 별도로 존재하지 않기 때문에 가상머신에 비해서 가볍고 실행속도도 빠르다.

리눅스 컨테이너는 예전부터 사용되어졌지만 도커가 개발된 후로부터 최근 활발하게 사용되고 있다. 도커는 리눅스 컨테이너를 다루는 도구중의 하나이며 도커와 같은 다른 도구들도 있으나 대부분 도커를 사용한다. 컨테이너 런타임이라고도 한다.

가상머신과 컨테이너 비교

리눅스 컨테이너의 핵심 기술은 2가지가 있는데 cgroup과 namespace이다.

1. cgroup (control group의 약자)

프로세스나 쓰레드를 그룹화해서 관리하는 기능, 시스템의 CPU, 메모리, 디스크I/O 등 리소스의 사용을 제한하는 기술이다. 리눅스 컨테이너는 호스트의 리소스를 공유하여 사용하는데, 이 때 cgroup을 사용하여 컨테이너가 사용하는 리소스의 양을 제한할 수 있다. 또한 같은 호스트에서 동작하는 서로 다른 컨테이너에 영향을 주지 않도록 막아주는 역할도 한다.

2. namespace

space 공간 안에 다수의 오브젝트를 격리(isolation)할 수 있다. 예를 들어서 동일한 호스트에서 동일한 PID(Process ID)를 가질 수 없지만 서로 다른 namespace에서는 동일한 PID 를 가질 수 있다. 격리되어 있다는 것이 포인트다.

추가로 윈도우 운영체제는 도커 컨테이너를 올릴 수 없으니 하이퍼바이저를 이용해서 도커를 사용한다.

Docker Daemon과 Podman

Docker 의 구성요소 중 하나로 Docker Daemon이 있다.

Docker 동작방식

위의 이미지와 같이 도커는 데몬 위에서 동작한다. 또한 프로그램이 동작하려면 방식이 3가지가 있다.

* 데몬 : 부팅시 올라오는 프로그램들

* 프로그램 동작방식 3가지

1) 부팅시 동작

runlevel 같이 부팅할 때 동작하는 개념이다.

2) 런레벨에 의존하지 않고 항시 동작시키는 방식

예를 들어서 systemctl enable 설정처럼 부팅시 실행되도록 동작시킬 수 있다.

3) /etc/rc.local에 올려서 동작시키는 방식

이 방식은 부팅시 부팅 스크립트의 끝자락에 읽어진다. 스크립트가 읽어지게 되면 항시 프로그램을 동작시킬 수 있다. 스크립트를 많이 추가하다보면 복잡해지기도 하고, 여기 올려서 동작시키려면 신뢰할 수 있고 믿을 수 있는 프로그램만 동작시킨다.

<podman>

docker를 사용하다보면 docker daemon이 죽을 가능성이 높다보니 데몬 없이 image, container, kernel에 그냥 던져주기 위해서 나온 것이 바로 podman이다. RHCSA시험이 8버전으로 바뀌면서 podman에 대한 내용이 추가되기도 했다.

docker의 또 한가지 문제는 클러스터링(쉽게 말해서 컨테이너들을 묶어주는 것)을 해주는 쿠버네티스(kubernetes)와는 연동이 잘 안된다. 이미지를 한 개만 올리는 것은 docker나 kubernetes나 어느것을 사용해도 상관이 없지만 보통 일반 회사에서는 컨테이너 이미지를 하나씩 올리는 경우는 거의 없다. docker는 가상화해서 올리는 것도 아니다.

podman은 데몬이 아니라 일종의 커맨드처럼 쓰인다. docker는 가상머신에 올리는 것처럼 사용하는 것이 아니지만 podman은 가상머신처럼 사용한다. 운영체제가 올라가고 ssh로 접근해서 제어할 수도 있다. 서비스를 이용하기 위해서는 포트를 열어줘야 한다. 밖에있는 자원을 이용하기 위해서는 마운트도 시켜주는 등 동일하게 사용한다.

Virtualbox같은 가상머신은 HDD를 장치 디바이스에 인식할 수 있도록 계속 추가했었는데, podman은 외부 리소스를 컨테이너에서 사용하고 있는 tcp, port 관련 영역과 맵핑(연결) 시켜준다. 외부의 디스크를 사용하고 싶다면 관련 명령어도 사용할 수 있다.

다시 컨테이너로 돌아와서..

isolation(격리)적인 부분에서도 우수한 것은 가상머신이지만, 지금 컨테이너같은 경우에는 구조상 동작하는 프로세스가 직접 노출된다. 자원들도 isolation 되어있는 것이 아니라 밖에있는 외부 자원을 그대로 가져다 쓴다. 대표적으로 도커허브(docker hub) 같은 곳에서 image를 가져다가 쓴다. official하게 도커허브 자체에서 제공해주는 이미지들도 있지만 사용자가 수정 보완해서 만들어놓은 이미지 또한 pull 명령어를 이용해 다운받아서 사용할 수 있다.

자원을 공유해 사용한다는 것이 편리하고 장점이 있지만 그에 따른 보안 이슈가 존재한다. 외부 자원을 그대로 가져다 쓰는것에 대한 접근 통제가 그만큼 중요시 되고 있다. 실제로 일부 사용자가 만들어놓은 이미지 안에 비트코인 채굴을 위해 다운받아 사용하는 사용자의 CPU를 사용하게 한다거나 랜섬웨어를 깔아놓는 등의 범죄에도 노출되어 있으며 실제 사례이다. 또한 잘못하면 불필요한 정보에 쉽게 노출된다는 단점이 있다.

그럼에도 불구하고 컨테이너기술과 도커, 쿠버네티스는 여전히 핫한 기술이다.

또한 쿠버네티스는 AWS, GCP를 지원해준다. 쿠버네티스를 접할 기회가 있었는데, 요즘에는 거의 컨테이너 오케스트레이션으로 쿠버네티스가 독보적이라고 한다.

위에서 언급한 Podman은 Pod Manager tool 의 약자로 OCI 표준 container와 런타임을 개발, 관리, 실행할 수 있게 해주는 container engine 이다. 레드햇에서 쿠버네티스에 올릴 수 있도록 만들어 놓은 것이다. 도커와 명령어가 완전히 똑같기 때문에 docker라는 이름 대신 podman으로 변경해서 사용하면 쉽게 익숙해질 수 있다. 요즘엔 또 podman으로 컨테이너를 관리해서 쿠버네티스와 연동한다는데 실제로 쓰는 사람은 아직 본 적이 없다.

글을 쓰면서 주제가 조금씩 바뀌기도 해서 내용이 들쑥날쑥이지만, 앞으로는 개념적인 부분도 쉽게 설명할 예정이다.

* 추천 책

가장 빨리만나는 도커(Docker)

* 출처 및 참고자료

https://www.weave.works/blog/a-practical-guide-to-choosing-between-docker-containers-and-vms

A Practical Guide to Choosing between Docker Containers and VMs

Docker, Kubernetes, and containers are indeed powerful technologies that can bring many benefits to a business. But they are not necessarily the right choice for every workload. In some cases, you’re better off sticking with simple virtual machines.

www.weave.works

https://www.lesstif.com/container/podman-98926748.html

podman 소개 및 설치

www.lesstif.com

도커 입문 : 가상화의 배경과 종류

심루트 — Tue, 1 Jun 2021 17:56:44 +0900

요즘 컨테이너 기술이 발전하면서 도커와 쿠버네티스를 공부하는 사람들이 많아졌다. 도커 입문자들을 위해 기초적인 가상화 개념과 리눅스 컨테이너의 개념들에 대해서 정리해보려고 한다. 리눅스 기초지식이 있는 사람들 대상으로 실습을 하는게 맞다고 생각은 하지만, 비전공자 중 IT회사에서 살아남아야 하는 직장인들을 위해서도 쉽게 설명해보려고 한다.

먼저 도커, 컨테이너, 쿠버네티스, 클라우드 등등. 이름만 아는 개념들이 많이 있을 것이다. 그 개념들을 알아보기 전 가상화 개요에 대해서 생각해보자.

* 배경

하드웨어 산업이 엄청나게 성장하면서 성능이 좋은 하드웨어들을 구하기가 쉬워졌다. 그래서 2000년도부터 가상화 기술이 떠오르고 있다. 활용하지 않는 자원을 낭비하지 않고 잘 쓰기 위해서 현재까지 오게 되었다.

* 종류

가상화의 종류는 많고 클라우드 서비스에서 다양한 가상화 기술들을 사용하고 있다. 대표적으로 크게 4가지로 분류해볼 수 있다.

1. 서버 가상화

하이퍼바이저(windows의 hyper V, VMware, Xen, VirtualBox, KVM 등)

위의 프로그램을 이용하기도 하며 흔히 아는 일반적인 가상화 기술이다. CPU나 메모리 등을 논리적으로 나눠서 사용할 수 있게 해주는 기술이다. 가상 머신을 생성하려면 CPU나 메모리와 같은 시스템 자원을 나눠주는 파티셔닝 기술이 필요하다. 이 파티셔닝 기술은 하드웨어 파티셔닝과 소프트웨어 파티셔닝이 있지만, 현재 소프트웨어 파티셔닝 기술이 주로 사용되고 있다. 소프트웨어 파티셔닝은 소프트웨어를 사용하여 가상 머신에게 시스템 자원을 할당하게 되는데, 이때 사용하는 소프트웨어를 하이퍼바이저라고 한다. 필수도구이며 쉽게 접할 수 있을 것이다.

예전에 내가 알고있던 가상화의 개념이 바로 서버 가상화였다. 아래와 같이 다른 가상화 개념들이 있다는 사실을 알고나니 조금 더 컨테이너 개념에 대해 이해하기가 쉬워진 것 같다.

2. 네트워크 가상화

NFV(Network Function Virtualization), SDN(Software Defined Network)

가상으로 네트워크를 나누어서 자원으로 사용하고 필요하지 않으면 다시 회수하는 형태로 사용할 수 있으며 이 네트워크 가상화를 사용하면 네트워크를 유연하고 빠르게 제공할 수 있다. 이 네트워크 가상화 분야가 요즘 인기가 많다고는 하는데 아직 접해보지는 못했다.

3. 스토리지 가상화

SDS(Software Defined Storage)기술이 주목받고 있으며, 대표적인 오픈소스 SDS 스토리지로 Ceph와 Glusterfs가 있다.

RAID처럼 물리적인 드라이브를 논리적으로 나눠서 사용하는 기술이다.

4. 컨테이너 가상화

Docker가 대표적이다.

컨테이너 가상화는 호스트 운영체제에서 논리적인 구역들을 만들어서 각각 독립적으로 애플리케이션을 실행하는 기술이다. 리소스를 효율적으로 사용하거나 애플리케이션들을 빠르게 배포할 수 있다.

docker logo (귀요미 도커 고래)

다음 포스팅에서는 컨테이너에 대해 정리해볼텐데,

가상화 -> 컨테이너 -> 도커(컨테이너를 다루는 종류 중 하나임) -> 쿠버네티스 순으로 확장되어 나갈 예정이다.

리눅스 기본 명령어

심루트 — Tue, 4 May 2021 18:01:13 +0900

* 리눅스 기본 명령어

1. 복사 : cp

복사를 하기 위한 명령어. 내가 사용하는 CentOS 7 기준으로 alias에는 cp 명령어 입력 시 -i 옵션이 기본으로 적용되어 있다. bash shell 창에 alias 입력할 경우 다음과 같이 뜬다.

alias cp = 'cp -i'

기본적으로 대화형으로 동작을 하겠다는 뜻. 혹시 실수로 눌렀을 수 있고 덮어쓰기를 방지하기 위한 확인 작업으로 yes / no를 입력해줘야 복사가 된다. 파일 복사를 할 경우 cp를 사용하면 되며, 디렉토리 복사를 하기 위해서는 -r옵션을 사용한다.

2. 이동 : mv

파일을 다른 디렉토리로 옮길 수 있다. 복사 붙여넣기는 파일 용량이 많을 경우 오래 걸리는 데 비해 잘라내기 후 붙여넣기는 시간이 오래 걸리지 않는다. 그 원리는 바로 저장되어 있는 파일에 위치만 바뀌기 때문이다. 그렇기에 속도가 빠르고, ls -l로 조회했을 경우 수정시간 등의 졍보도 그대로 조회된다.

3. 파일 생성 : touch

파일을 생성할 때 쓰는 명령어.

쉘에서 man touch를 입력하면 touch의 매뉴얼을 볼 수 있다. 매뉴얼상에 설명된 touch의 기능은 change file timestamp이다. 파일의 수정 시간을 변경해주는 명령어라고도 할 수 있다.

4. 디렉토리 생성 : mkdir

디렉토리를 생성할 때 쓰는 명령어.

여러개의 디렉토리를 한줄로 만들고싶을 때(정확하게는 계층적으로 만들기) mkdir을 사용하면 에러가 뜬다. 각 디렉토리를 순차적으로 하나씩 만드는 것이 원칙이기 때문이다. 그렇지만 -p 옵션 하나만 사용해주면 디렉토리를 동시에 여러개 생성할 수 있다.

5. 파일 삭제 : rm

파일을 삭제해주는 명령어.

1번의 cp나 mv 명령어와 마찬가지로 alias rm을 입력해보면 -i옵션이 기본적으로 적용되어 있음을 알 수 있다. 화면의 yes / no 를 매번 입력해 주는 것이 귀찮다면 -f 옵션을 사용하면 된다. 디렉토리를 생성할때나 옮길 때는 상관 없겠지만, rm 명령어에서는 특별히 주의해야한다. 실수로 루트 디렉토리를 rm 해버린다면 어마무시한 일이 일어날 지도 모름

6. 디렉토리 삭제 : rmdir

디렉토리를 삭제해주는 명령어.

사용이 빈번하지는 않다. 지우려고 하는 디렉토리가 텅 비어있어야 지워지는 명령어이기 때문이다. 그렇기 때문에 뭔가 들어있는 디렉토리를 지우고 싶다면 -r 옵션을 함께 사용한다.

7. 링크 : ln

파일이나 디렉토리에 접근을 쉽게 할 수 있도록 하는 방법이다.

복사랑은 다르게 영어 뜻대로 연결되어있다. C언어를 배운 사람이라면 포인터 개념에 대해 들어봤을 것이다. 포인터와 비슷하다. 링크도 2가지가 있다. 자세한 차이에 대한 내용은 추후 포스팅해볼 예정이다. 마찬가지로 지울 땐 rm 명령어를 사용한다.

-하드링크 : ln

-심볼릭 링크 : ln -s

8. 파일 내용 검색 : grep, egrep, fgrep

- grep : global regular expression print

특정 문자나 패턴들을 검색하는 명령어. 여기서 기능이 추가되어 egrep, fgrep이 나왔다.

- egrep : extended global regular expression print

grep에서 확장된 명령어. 추가적인 기능이 있다.

- fgrep : fixed global regular expression print

위 명령어와 같으나 쉽게 생각해서 특수문자를 escape처리해주는 기능이 있는 명령어다. 귀찮게 백슬래시(\) 사용을 하지 않아도 된다.

11. 파일 및 디렉토리 검색 : find

특정 파일이나 디렉토리를 검색하기 위해 사용하는 명령어.

파일 이름이나 크기, 시간 등 조건을 다양하게 주어서 검색할 수 있다. 옵션도 엄청 많다.

CLI, TUI, GUI 특징과 리눅스 배포판에 대하여

심루트 — Mon, 3 May 2021 17:22:53 +0900

리눅스를 사용하다보면 다양한 명령어를 접할 수 있다. 한 가지 예로 네트워크가 잘 안될 때 명령어가 아래와 같이 3가지가 있다.

nmcli connection up enp0s34

nmtui ~

nm-connection-editor ~

여기서 enp0s34는 이더넷 이름을 말한다. 중요하게 봐야 할 부분은 nm으로 시작하는 명령어다. cli, tui, 그리고 에디터가 나오는데, 세가지의 특징에 대해 살펴보려고 한다.

- CLI : Command Line Interface

- TUI : Text User Interface

- GUI : Graphical User Interface

CLI : Command Line Interface

리눅스 쉘이나 윈도우의 cmd창에서 볼 수 있는 까만색 배경의 글씨를 입력하는 상자를 본 적이 있을 것이다. 이런 텍스트 기반의 형태를 CLI라고 한다. 커맨드 라인 인터페이스인데, interface라는 이름 자체도 무언가 접속할 수 있도록 접근을 도와주는 장치이기 때문에 라인별로 명령어를 입력해서 시스템에 접근할 수 있게 해주는게 CLI이다. 우리는 윈도우의 이미지(그래픽) 형태가 익숙하지만, 엔지니어로 일하기 위해서는 리눅스의 CLI방식에 익숙해져야한다. 명령어를 라인별로, 또는 세미콜론(;)을 사용해서 한 줄로 입력하여 시스템을 동작시킬 수 있다.

TUI : Text User Interface

TUI는 Text User Interface인데 텍스트라는 이름만 보고 글씨를 입력하는건가 싶겠지만, 텍스트 기반의 대화형 인터페이스이다. 리눅스의 기본 쉘인 Bash Shell 창 안에서 nmtui 명령어를 입력하면 아래와 같은 화면을 확인할 수 있다. 키보드 화살표 키랑 엔터키 이용해서 선택할 수 있다. 아래의 화면은 리눅스 쉘 안에서 텍스트형태로 표시되는 것이다. 밑에 있는 모든 문자나 도형스타일도 다 ASCII text로 만든 것이다.

TUI : Text User Interface

GUI : Graphical User Interface

마지막 nm-connection-editor 명령어를 입력하면 그래픽 형태로 네트워크 팝업이 뜨면서 인터넷을 클릭, 엔터 등의 방법으로 선택할 수 있다.

GUI : Graphical User Interface

리눅스 배포판

Ubuntu나 CentOS같은 차이를 의미하는 것을 리눅스 배포판(Distribution)이라고 한다.

- Debian 계열 : Ubuntu

- Redhat 계열 : Redhat Enterprise Linux(RHEL), CentOS, Fedora

앞서 포스팅한 글에서 언급했듯이 리눅스의 계보에 대해서는 구글링 한 번만 하면 이미지로도 확인할 수 있다. 오픈소스라는 개념이 무색하게 레드햇 계열의 리눅스 배포판은 제대로 사용하려면 비용을 지불해야 한다. CentOS나 Fedora같은 경우에는 무료로 사용할 수 있고, RHEL에서 테스트해볼 수 없는 기능들도 들어와있기도 하다. 돈내고 사용하는 사람들한테 새로운 기능을 테스트해보라고 할 수는 없으니 무료 사용자들이 테스트해보고 오류도 보내고 하면서 RHEL버전에 참고하여 업데이트하고 있는 것 같다.

이 많은 가지들을 다 공부하려면 평생이 걸릴 것 같지만, 우선은 리눅스 하나만 제대로 파보는 것이 중요할 것 같다. 마치 C언어를 다 깨우쳤을 때 다른 언어도 쉽게 배울 수 있는 것 처럼?

* 리눅스를 공부하기 전 찾아볼만 한 인물들

리누스 토르발스 - 나무위키

그의 종특은 맘에 안 드는 것은 뭐든지 까는 것으로, 거친 언사도 서슴지 않으며, 일반인들과도 뉴스그룹, 이메일 등지에서 키배를 자주 뜨는 현장을 목격할 수 있다. 특히 리눅스 개발 커뮤니티

namu.wiki

리처드 스톨먼 - 나무위키

namu.wiki

유닉스의 탄생, 기초 및 특징

심루트 — Mon, 3 May 2021 11:35:53 +0900

유닉스, 리눅스, 윈도우 등 우리가 흔히 부르고 있는 이 개념은 크게 "운영체제"라고 불린다. 영어로 하면 Operating System. 줄여서 OS라고 한다.

과거의 컴퓨터인 애니악, 애드박도 많이 들어봤을텐데, 지금 쓰는 컴퓨터와는 달리 빨리 계산하는 측면에서 했던 것들이다. 군사적인 목적, 전쟁 때 사용하던 컴퓨터다. 물론 사람이 할 수도 있겠지만 사람이 계산하기 끝날때 쯤이면 그 암호는 끝나게 된다. 이런 것들을 빨리 해주기 위해 나타난 것이 컴퓨터다. 지금 우리가 사용하는 컴퓨터는 이 때의 컴퓨터의 용도와 다르다.

과거에는 트랜지스터라는 것도 사용하고 칩 같은것들도 발전했다. 이것들은 하드웨어적인 부분에 가깝다. 앞으로 정리해볼 유닉스와 리눅스에 대해서 기초부터 정리를 해 보면서 공부할 예정이다.

유닉스의 탄생

유닉스는 1960년대 중반, 70년대 초반쯤에 켄 톰슨과 데니스 리치라는 사람에 의해 개발되었다. 컴퓨터 공학도라면 꼭 배워보는 C언어를 만든 사람이 바로 아래의 데니스 리치다. C언어든 유닉스든 배우기도 어려운데 만든 사람은 얼마나 똑똑할지?

데니스 리치 - 위키백과, 우리 모두의 백과사전

위키백과, 우리 모두의 백과사전. 데니스 매캘리스테어 리치(영어: Dennis Ritchie, 1941년 9월 9일 ~ 2011년 10월 12일)는 미국의 저명한 전산학자이자 현대 컴퓨터의 선구자이다. C와 유닉스의 개발자로

ko.wikipedia.org

한 운영체제 안에서 멀티로 작업을 수행할 수 있도록 멀틱스(Multics)프로젝트가 시작되었는데, 이 프로젝트가 종료되고 이후 유닉스(Unics)가 등장했다. 유니캐스트는 1:1작업을 할 수 있게 해주는 용어로도 사용되는데, 그런 용어에서도 알 수 있듯 유닉스는 1개의 작업에 집중하자, 멀틱스는 다수의(Multi) 프로세스 기반의 프로그램을 만들자라고 쉽게 생각할 수 있다. 그렇지만 또 막상 이렇게 단순하게 나누기란 쉽지 않으며 유닉스 또한 다중 사용자를 지원하도록 되어있어서 이런 역사를 거쳐서 유닉스라는 용어가 등장했다는 점만 알고 있으면 될 것 같다. 유닉스(Unics)라는 용어에서 우리가 알고있는 유닉스(UNIX)라는 용어가 등장하게 되었다.

유닉스의 종류

유닉스라는 운영체제는 무료로 사용 가능한, 지금 말로 하면 오픈소스이다. 그렇다보니 유닉스에서 착안해내 다양한 OS들이 파생되어져왔다. 지금 제일 많이 사용하는 리눅스(linux) 또한 유닉스 계열의 운영체제이며, Debian 계열의 Ubuntu와 Redhat 계열의 CentOS 등이 유명하다. "유닉스 계보" 및 "linux distribution timeline"을 구글링해보면 엄청나게 파생된 유닉스, 리눅스 계보에 대해 확인해볼 수 있다. 아래 사진은 너무 길어서 확대하지 않으면 보이지도 않는다. 오픈소스라는 점이 집단지성과 맞물려서 엄청난 발전을 이뤄낸 것 같다.

https://ko.wikipedia.org/wiki/%ED%8C%8C%EC%9D%BC:Linux_Distribution_Timeline.svg

유닉스는 IBM, HP, ORACLE, APPLE 등의 기업에서 다양한 이름의 유닉스들을 만들어냈다. 이렇게 제조사도 다 다르고 이름들도 다르지만 유닉스 계열의 운영체제들은 비슷한 명령어를 가지고 있기 때문에 기본적인 개념만 알고 있다면 다른 OS도 쉽게 적응하여 사용할 수 있다.

유닉스의 특징

특히 서버를 만들 때 유닉스와 리눅스를 많이 사용한다. 윈도우 서버도 있지만 가격적인 부분이 너무 비싸다. 유닉스와 리눅스는 오픈소스이기 때문에 가격적인 면에도(물론 서버는 다 비싸다) 부담이 덜 하고, 특히 오랜 기간동안 발전되었기 때문에 안정성이 높아서 보안적인 측면에서도 괜찮다. 그리고 pc를 쓸 때 윈도우 같은 경우 C드라이브나 D드라이브처럼 디스크를 나누는데, 유닉스계열의 운영체제는 이렇게 나누기만 하는 것이 아니라 계층적으로 개발을 했기 때문에 트리구조를 띈다. root라는 시스템은 오직 1개만 존재한다. 더 많은 개념들은 공부를 하면서 누적해나갈 예정이다.

MTU(Maximun Transmission Unit)과 fragmentation(단편화)

심루트 — Thu, 22 Apr 2021 17:35:09 +0900

위키백과에서는 전송할 수 있는 최대 프로토콜 데이터 단위의 크기를 MTU라고 합니다.

다른 말로는 패킷 또는 프레임 기반의 네트워크 전송될 수 있는 최대 크기의 패킷 또는 프레임입니다. Ethernet 프레임을 제외한 IP datagram(OSI 7 Layer 3계층에서 쓰이는 용어)의 최대 크기를 의미합니다. 또한 Maximun Transmission Unit이라는 이름 그대로 최대 전송 단위를 의미합니다.

* Linux Ubunt 환경에서 쉘 창에 ifconfig를 입력하면 MTU를 찾아볼 수 있습니다.

위와 같이 오른쪽에 mtu 1500이라는 내용을 찾아볼 수 있습니다. Ethernet 환경에서는 MTU의 기본값을 1500으로 고정해서 사용합니다. 임의로 사용자가 2000이나 다른 숫자로 변경해서 사용할 수도 있습니다. 한 때 이 MTU값을 크게 늘리면 속도가 더 빨라진다는 루머가 있었는데, 사실 여기서 MTU값을 아무리 늘린다 해도 다른곳으로 패킷이나 프레임을 전송,전송,전송 되어질 때 결국 다른 전송층에서 작게 쪼개야 하는건 변함이 없기 때문에 속도에는 변함이 없습니다. 그래서 기본값 1500을 그대로 사용하고 있습니다.

크기는 byte를 사용하고 있고(위에서는 1500byte네요), 이 MTU지표는 쉽게 말해서 통신을 할 때 데이터의 양이 많을 경우, 그것을 쪼개서 보낼 수 있는데 1500byte로 자르겠다는 의미입니다.

MTU가 1500이면 IP header 20byte를 기본적으로 가져가기 때문에 실제 사용할 수 있는 데이터는 1480byte가 됩니다. 그래서 4000byte인 데이터그램이 있다고 한다면 IP header 20byte를 쓰기 때문에 실제 사용할 수 있는 데이터그램은 3980byte가 됩니다.

* 용어정리

ID : 각 패킷의 ID값(sender)

Flag : fragmentation이 됐는지 안 됐는지 나타내주는 값

- 1 : 뒤에 단편화 된 패킷이 존재한다.

- 0 : 뒤에 단편화 된 패킷이 존재하지 않는다.

Offset : 전체 패킷에서의 위치

- 첫번째 flag의 offset값은 0이다.

- 두번째부터는 flag 전체 패킷값을 8로 나눈다. 이렇게 하는 이유는 양이 너무 많아서 줄이기 위함이다.

이제 MTU에 대한 이해가 어느정도 되었다면, 예시를 통해서 계산해보도록 하겠습니다.

* IP fragmentation 예제

ex. 3980byte의 데이터그램을 1500MTU로 분할해보기.

DATA가 3980byte이면 ip header값은 20byte이므로 전체 길이(lenth)는 4000이 된다.

ID는 sender의 id값인데 임의로 777이라고 설정할 수 있다.

Flag는 아직 fragmentation(분할해주는 작업)이 안 되었기 때문에 뒤에 단편화 된 패킷이 존재하지 않아 0이다.

Offset은 전체 패킷에서 첫번째에 위치해있기 때문에 0이다.

보기 쉽게 아래와 같이 적을 수 있다.

-> DATA 3980byte + ip | length = 4000 | ID=777 | flag = 0 | offset = 0

https://wogh8732.tistory.com/29

이제 1500 MTU로 분할하게 되면 아래와 같이 3개로 분할할 수 있다.

쉽게 생각해서 1500이 넘어서 분할을 해줘야 할 경우 flag가 1이며, 마지막이 0이 되는 것입니다. 더이상 분할할 것이 없기 때문. 그리고 offset은 전체 byte를 8로 나눠줍니다.

서브넷 마스크 : 서브넷팅(Subnetting)과 VLSM(Variable Length Subnet Mask)

심루트 — Wed, 21 Apr 2021 18:23:05 +0900

서브넷 마스크(Subnet Mask)에 대하여 알기 위해서 먼저는 논리적으로 AND(그리고)에 대한 개념을 알아야 한다.

컴퓨터 전공자라면 한번 쯤 배웠을 법한 이 개념.

* AND

0 and 0 = 0

0 and 1 = 0

1 and 0 = 0

1 and 1 = 1

1은 True, 0은 False이다. 이렇게 전자적인 컴퓨터 언어 0과 1을 놓고 보았을 때(bit라 한다) True와 True가 만나야 True가 된다. 비슷한 개념으로 OR(또는)가 있는데, 이것은 한 비트만 True(1)여도 True(1)라는 결과가 출력된다.

한글로 번역하면 AND는 그리고, OR은 또는 으로 볼 수 있다. 말 그대로 그리고는 앞뒤가 같아야 하고 또는은 둘 중에 하나라도 맞으면 맞다라는 의미이다. 이렇게 해서 외우면 쉽게 외울 수 있다.

이 개념을 가지고 서브넷 마스크에 대해 알아보자.

서브넷 마스크는 지난번 포스팅에 클래스 A,B,C에서 호스트 부분을 다시 서브넷과 호스트로 구분하는 역할을 한다고 했다.(참고)

먼저 이 서브넷 마스크를 나누는 가장 큰 이유에 대해서 살펴보려고 한다. IP주소는 한정되어 있다고 지난 포스팅에 작성을 해 두었다. 그렇기 때문에 이 주소를 잘 분배해서 사용하는 것이 중요하고 버려지는 주소가 없도록 아껴야 하기 때문에 서브넷 마스크를 나눈다. 서브넷 마스크는 주어진 IP주소를 네트워크 환경에 맞게 나누어 주기 위해서 씌워주는 이진수의 조합이다.

모든 IP 주소에는 서브넷 마스크가 따라다닌다. 지난시간 포스팅에 적어둔 것 같이 A클래스부터 B, C까지 디폴트 서브넷 마스크는 255.0.0.0 / 255.255.0.0 / 255.255.255.0 으로 정해두었다. 디폴트값은 서브넷을 나누지 않은 상태로, 0~255까지의 ip주소를 다 사용할 경우에는 디폴트 값을 이용해도 상관이 없다. 그러나 그렇지 않은 경우가 대부분이기 때문에 공간의 낭비를 줄이기 위해서 서브넷을 2의 n승만큼 나눌 수 있다. 이렇게 서브넷 마스크를 나누는 것을 서브넷팅(Subnetting)이라고 한다.

먼저, 네트워크 아이디를 얻는 방법에 대하여 한 가지 예시를 들어서 이해해보려고 한다.

ex.

-IP주소 : 192.168.100.10

-서브넷 마스크 : 255.255.255.0

위와같은 전제가 있다고 할 때, 먼저 IP주소가 192로 시작하기 때문에 이 주소는 C클래스에 해당한다.

(192~223으로 시작하는 경우 C 클래스다.)

IP주소와 서브넷마스크 주소를 2진수 비트 형태로 표현해서 AND연산을 하게되면 네트워크 주소(네트워크 아이디)가 나온다.

-IP주소 : 192.168.100.10 -> 1100 0000.1010 1000.0110 0100.0000 1010

-서브넷 마스크 : 255.255.255.0 -> 1111 1111.1111 1111.1111 1111.0000 0000

----------------------------------------AND 연산 결과-----------------------------------------

AND연산 작업을 하고 나면,

11000000.10101000.01100100.00000000라는 값을 얻을 수 있고, 이 2진수를 10진수로 표현하면 192.168.100.0 이라는 네트워크 주소(아이디)를 얻을 수 있다.

앞으로 ip주소와 서브넷마스크만 알고있으면, 네트워크 아이디를 계산해볼 수 있다. 여기서 서브넷 마스크를 변경할 수 있다. 나머지 조건은 동일하고, 서브넷마스크만 255.255.255.128일 경우 네트워크 아이디는 무엇일까? 바로 위의 연산에서 서브넷마스크 부분의 마지막 8비트를 10000000(2진수) 으로 바꿔서 계산하면 된다. 그 결과 네트워크 아이디는 192.168.100.128이 된다.

그럼 처음 문제와 두번째 문제에서 네트워크 아이디가 달라진다. 그렇지만 둘 다 C클래스임에는 변함이 없다. 또한 네트워크 아이디 부분을 알고있다고 한다면 호스트 부분의 범위도 알 수 있다. 네트워크부에서 사용하고 남는 비트를 호스트부에서 사용하기 때문이다.

출처 : https://m.blog.naver.com/PostView.nhn?blogId=pasudo123&logNo=221144305071&proxyReferer=https:%2F%2Fwww.google.com%2F

이러한 서브넷 마스크의 변경을 VLSM(Variable Length Subnet Mask, 가변길이 서브넷 마스크) 라고 한다.

문제풀이를 할 때 아래와 같이 개념을 잡아두는 것이 도움이 될 것 같다.

11111111.11111111.11111111.00000000 : 0~255 전체 다 사용함

11111111.11111111.11111111.10000000 : 서브넷 : 2개(2의n승), 서브넷당 ip(*1/2) : 128개씩

11111111.11111111.11111111.11000000 : 서브넷 : 4개, 서브넷당ip : 64개

11111111.11111111.11111111.11100000 : 서브넷 : 8개, 서브넷당ip : 32개

11111111.11111111.11111111.11110000 : 서브넷 : 16개, 서브넷당ip : 16개

11111111.11111111.11111111.11111000 : 서브넷 : 32개, 서브넷당ip : 8개

11111111.11111111.11111111.11111100 : 서브넷 : 64개, 서브넷당ip : 4개

이해가 안가면 그냥 서브넷은 2의 n승(1이 있는만큼), 서브넷당 ip는 2의 n분의 1을 곱한다고 생각하자.

실제 계산을 해보면 점점 이해가 잘 되는 것 같다. 사실 이런 서브넷을 하나하나 다 계산하는게 실무에 필요할까 싶은데, 실제로 서브넷을 나누는 사람은 '네트워크 설비'쪽이다. 그래도 개념을 이해하기 위해서나 전공수업에서는 이런 조건들을 주고 서브넷마스크, 네트워크 주소, 호스트 범위, 브로드캐스트 주소, 서브넷 수, 호스트 수에 대한 문제를 접할 수 있을 것이다.

추가로 이 부분에 대한 문제풀이는 후니의 쉽게 쓴 시스코 네트워킹 책을 참고하였다.

IP 주소체계 : IPv4와 IPv6의 차이, 공인ip와 사설ip, 클래스, 특수ip 주소 목록, 서브넷 마스크

심루트 — Tue, 20 Apr 2021 18:03:05 +0900

안녕하세요. 오늘은 IP 주소체계와 클래스에 대해 알아보려고 합니다.

먼저 IP주소란? 흔히 알고있는 ip주소의 정의는 인터넷상에 있는 컴퓨터의 고유한 주소로, 이 주소를 바탕으로 인터넷상의 한 컴퓨터에서 다른 컴퓨터로 데이터를 주고받을 수 있습니다.

이 IP 주소는 크게 IPv4(IP버전4), IPv6(IPv6)로 나뉩니다.

IPv4는 X.X.X.X의 형태입니다. 각 X에는 0부터 255까지의 숫자가 올 수 있기 때문에 총 IP주소의 개수는 256를 네번 곱한 약 43억개로 이용할 수 있습니다. 현 시점 전 세계 인구가 70억정도인 점을 감안해볼 때, IPv4의 주소체계는 수량적으로 한계가 있습니다. 그렇기 때문에 미리 대비를 하여 새롭게 만든 주소체계가 바로 IPv6입니다. 이미 오래 전부터 대비가 되어 있었지만 아직도 우리는 IPv4를 사용하고 있습니다. 기술이 발달해서 제한적인 버전4의 주소체계 내에서도 IP를 구분할 수 있는 방법들이 생겨서, 기존의 주소체계를 유지할 수 있게 되었습니다. 버전6으로 넘어가지 않는 이유는 여러이유가 있겠지만, 이미 만들어진 전 세계의 주소체계를 전부 다 옮기기에 가장 큰 문제는 바로 '돈'입니다. 새로운 체계를 사용하기 위해선 장비도 새로 바꿔야 하고 시간적으로나 경제적으로 많은 자원이 필요하기 때문에 기존의 방식을 사용하고 있습니다.

어쨋거나 IPv4를 사용함에 있어서 약 43억개나 되는 IP주소를 체계없이 사용하게 된다면 많은 혼란이 올 것입니다. 그렇기 때문에 클래스 주소 체계의 필요성이 대두됩니다.

IP주소의 클래스는 총 A~E클래스로 나뉩니다. 각 클래스는 네트워크 구분자와 호스트 구분자로 구성되어 있습니다.

* 네트워크 구분자 : 처음 비트를 구분자로 사용(X.X.X.0)

클래스A(X.0.0.0) : 8비트, 클래스B(X.X.0.0) : 16비트, 클래스C : 24비트(X.X.X.0)

* 호스트 구분자 : 네트워크 구분자로 할당되지 않은 나머지 부분

각 네트워크에 연결된 단말기를 구분하는 역할을 함.

https://wogh8732.tistory.com/30

인터넷 주소체계는 인터넷 망에서 컴퓨터간의 통신을 위한 유일한 논리적인 주소를 의미합니다. 숫자를 이용해서 32비트의 주소 체계를 사용합니다. 위의 표에서 범위를 보면서 이해할 수 있습니다. X.X.X.X라는 ip 주소가 있다고 했을 때 하나의 X는 1byte, 즉 8bit입니다. 그렇기 때문에 이진수 표현들을 각각 계산해놓은 범위가 0~126, 128~191과 같은 범위로 정리되어 있습니다.

전공자들이나 시험을 보는 사람들은 이걸 다 외어야 하나, 실무에서 쓸 때가 있을까? 하는데, 처음 시작하는 8비트에 따라서 무슨 클래스인지 구분이 가능합니다. 이 구분은 실무에 들어가서 고객사에 방문하거나 IP주소를 확인할 때 무슨 클래스에 있는지 확인정도는 할 수 있어야한다고 합니다.

연구실에서 무작정 우분투를 써야만 했을 때 ifconfig를 쳤을 경우 ip주소가 공인IP인지 사설IP인지 헷갈리고 개념이 안 잡히는 적이 너무 많았는데, 이번에 공부를 하면서 그 차이점도 알게 되었습니다. 10으로 시작하는 경우, 192로 시작하는 경우에 따라서 공인/사설 ip로 구분하는 줄만 알았는데 그게 아니어서 정리해봤습니다.

* 공인IP

공인ip는 전 세계에서 유일하게 쓸 수 있는 ip입니다. 그렇지만 ip주소체계에서 모든 기기에 할당하기에는 개수가 부족하죠. 한 사람당 컴퓨터를 2대이상 가지고 있는 경우도 있으니까요. 한 사람당 하나의 ip주소로 할당하기에는 컴퓨터, 태블릿pc, 노트북, 핸드폰 등 인터넷이 가능한 모든 기기에 ip주소가 사용되기에 문제가 됩니다.

이러한 ip주소 부족 문제를 해결하기 위해서 등장한 것이 바로 사설ip입니다.

* 사설IP

한 네트워크에 속한 사용자들끼리만 인식할 수 있는 임시ip주소를 사설ip라고 합니다. 같은 네트워크 내에서 홈페이지를 만들어 서비스 또는 파일 주고받기도 가능하지만 이 네트워크망을 벗어나면 사설 ip주소를 그대로 사용할 수가 없습니다.

예를들어 한 회사에서 사용하고 있던 192.168.100.3이라는 주소의 ip가 외부에 나가게 되면 그대로 사용할 수 없게됩니다. 그 대신 회사 공인 ip주소 일련번호를 붙여서 사용할 수 있습니다. (ex. 192.168.100.3:34001) 이런 식으로 뒤에 일련번호를 붙입니다. 여기서 34001은 사용중이던 컴퓨터에 대한 고유번호로, 회사에 설치된 장비에 기억됩니다.

반대로 외부 네트워크에서 내부 네트워크로 들어오게 될 경우도 있는데, 위에서 언급한 회사에 설치된 장비를 통해 다시 사설 ip로 변환하는 작업이 필요합니다. 공인ip로 탈바꿈하는 과정에 NAT(Network Address Translation)라는 기술을 쓰게되는데 이 부분도 함께 공부해보면 좋을 것 같습니다.

사설ip의 장점은 같은 네트워크를 사용하는 수십, 수백명의 사람들이 하나의 공인 ip로 인터넷을 쓸 수 있게되는 점입니다. 현재 우리는 흔히 쓰고있는 공유기라는 장치를 통해서 이 방법을 이용하고 있습니다.

* 특수 IP 주소 목록

다음으로는 특수IP주소 목록에 대한 설명입니다. 이걸 진작 인식하고 있었더라면 회사에서 ip설정할 때 고생을 덜 했을 것 같다는 생각이 드네요. A부터 E까지의 클래스가 있는데, 거의 A~C까지의 클래스를 주로 사용하기는 합니다. 그 클래스 안에서도 사설ip주소로 사용하거나 특수한 목적으로 사용하는 ip주소에 대한 범위가 정해져있는데, 이 부분을 알고있으면 나중에 내가 이용하고 있는 이 ip주소가 사설주소인지 공인 주소인지 쉽게 알아볼 수 있습니다.

- 0.0.0.0~0.255.255.255

어떠한 클래스에도 소속되어 있지 않고 특정 ip주소 대역을 지정하는 데 사용합니다. 0으로 시작하는 주소는 아예 안 쓴다고 보면 됩니다.

- 10.0.0.0~10.255.255.255

위의 표에서 보시면 1~127까지는 클래스 A에 속한다는 것을 알 수 있습니다. 그런데 10으로 시작하는 ip주소는 그 안에 속하기는 하나, 사설ip주소로만 사용하는 주소입니다. 저는 처음에 이 10으로 시작하는 주소가 공인ip주소인 줄 알고 우리 회사에서 B클래스 ip주소를 사용하는건가? 돈이 많나? 라고 생각했었습니다. 여러분들은 이런 착오는 하지 않으시길 ㅎㅎ..

- 127.0.0.0~127.255.255.255

마찬가지로 127로 시작하는 ip주소는 클래스 A에 속하지만 자신의 컴퓨터와 관련된 목적으로만 사용하는 주소입니다. 이 중에서도 127.0.0.1이라는 주소는 항상 자기 자신의 컴퓨터를 가리키는 역할을 하며, 이것을 loopback이라고 말합니다. 리눅스에서 ifconfig 입력 후 확인되는 lo:로 시작하는 정보에 보면 항상 127.0.0.1이라고 적혀있는 것을 볼 수 있었는데, 이 lo가 '로'가 아닌 'loopback'이라는 것에 대해 처음 알게 되었습니다 ㅠㅠ..유레카

- 169.254.0.0~169.254.255.255

ip를 따로 지정하지 않은 상태에서 ip 자동 구성이 실패했을 때 사용한다고 합니다. 이것은 일하면서 접해본 적은 없네요.

- 172.16.0.0~172.31.255.255

클래스 B에 속하지만 사설 ip주소로만 사용합니다.

- 192.168.0.0~192.168.255.255

클래스 C에 속하지만 사설 ip주소로만 사용합니다. 192.168.~는 자주 봤던 ip주소 유형인데, 거의 왠만한 곳에 다 있는 공유기에서 이 주소형태를 주로 띈다고 들었던 것 같습니다.

사실 처음에는 클래스별로 공인ip와 사설ip가 나뉘는 것인가? 하는 생각이 있었는데, 각각의 개념을 정리하고 나서 보니 각 클래스 내에서도 사설ip 대역으로 사용하는 주소가 있다는 사실을 새롭게 정립하게 되었습니다. 특수형태의 ip주소 목록에는 또 아래와 같은 주소들이 있습니다.

-255.255.255.255

이 주소는 제한된 브로드캐스트라는 의미를 갖는 ip주소입니다.

-클래스D와 클래스E에 해당하는 주소

공인ip 주소로 사용되지 않고, 표에서 알 수 있듯 각각의 용도가 따로 있습니다.

* 모든 클래스 내의 ip주소 범위 중 공인ip주소로 사용이 불가능한 ip주소 3가지

아래의 주소는 이미 fix된 주소이기 때문에 공인ip주소로 사용할 수 없습니다.

- 가장 첫 번째 ip주소 : 네트워크 주소

- 가장 마지막 ip주소 : 브로드캐스트 주소

- gateway 주소

* 서브넷 마스크

서브넷 마스크도, 고정ip설정을 할 일이 있어서 공부를 했었다가 개념이 잘 안잡혔던 기억이 납니다. ip주소 뒤에 /26이라는 게 적혀있어서 뭔지 하나도 몰랐는데 이번에 알게되었네요.

A~E까지 총 5개의 클래스로 구분되는 이 IP주소 체계만으로는 IP주소를 세분화하여 관리하기 불가능합니다. 그렇기 때문에 IP의 낭비를 줄이기 위해 등장한 개념이 바로 서브넷 마스크입니다.

서브넷 마스크는 클래스 A, B, C에서 호스트 부분을 다시 서브넷과 호스트로 구분하는 역할을 합니다. 클래스 C로 예를 들어보도록 하겠습니다.

출처 : CCCR

클래스 C에서 마지막 8비트의 호스트 부분을 2비트, 6비트로 구분하였습니다. 제가 지난번에 헷갈렸던 /26 의 의미는 무엇일까? 맨 위에있는 첫번째 사진에서 보면 이러한 것을 '블록'이라고 표현합니다. 의미가 궁금하여 알아보았는데, ip주소 뒤에 그렇게 적혀있는 건 바로 0과 1로 구성된 부분을 1비트라고 봤을 때, 맨 왼쪽부터 서브넷마스크가 있는 부분까지가 26비트로 구성되어있기 때문이었습니다.

서브넷 마스크의 ip주소를 오로지 숫자로 적으면 netmask, /26이나 /18과 같은 형태로 적으면 prefix라고 표현할 수 있습니다. 서브넷 마스크에 대한 개념은 실제 문제를 풀어보거나 깊게 이해하기 위해 더 공부해야 할 개념인 것 같아 기회가 되면 다시한 번 정리해서 개념을 잡아봐야겠네요. 마지막으로 아래의 디폴트 서브넷 마스크도 참고로 알아두시면 좋을 것 같습니다.

* 디폴트 서브넷 마스크

- 클래스A : 255.0.0.0

- 클래스B : 255.255.0.0

- 클래스C : 255.255.255.0

이건 고정ip 설정할 때 써봤던 기억이 있는데, 그 때는 감으로 255.255.255.0 이런 식으로 표현해서 때려 맞췄지만 다음에 설정할 일이 있다면 클래스에 맞게 설정할 수 있을 것 같습니다^^

OSI 7계층 : OSI 7 Layer Model

심루트 — Mon, 19 Apr 2021 21:00:46 +0900

전공수업을 들으며, 또는 일을 하면서 네트워크에 대한 내용이 나올 때마다 OSI 7 Layer라는 개념을 많이 들어보고 시험도 봤는데 항상 날아가는 지식이 되는 것 같아 이번기회에 다시한 번 개념을 잡아보려고 한다.

OSI 7계층이란? 네트워크에서 통신이 일어나는 과정을 7단계로 분류해놓은 것을 말한다. 7계층으로 나누는 이유는 통신을 하려니 자꾸만 부딪히고 잘 안돼서 통신 과정을 단계별로 파악하고, 이상이 생길 때마다 그 단계만 고칠 수 있게 하기 위함이다.

OSI 7계층과 함께 TCP/IP 프로토콜도 함께 알아두면 외우기가 쉽다. 그러기 위해서는 프로토콜이라는 용어도 정리가 필요하다. 프로토콜이란? 복수의 컴퓨터 사이나 중앙 컴퓨터와 단말기 사이에서 데이터 통신을 원활하게 하기 위해 필요한 통신규약이다. 쉽게 말해서 컴퓨터가 사용하는 언어라고 개념을 잡아볼 수 있다. 정확하게는 언어가 아니라 통신규약이다.

인터넷에 OSI 7 Layer라고 치면 쉽게 이러한 표 이미지를 얻을 수 있다. 데이터통신 수업 때 하향식 접근으로 해서 Application Layer(응용 계층)부터 배웠던 기억이 났다. 이번에 다시한 번 공부하게 되면서 제대로 개념을 이해하고, 나중에도 필요하다고 하니 암기까지 할 수 있었다. 이전에는 그냥 막 외우고 다 날아가는 지식이었는데, 역시 한국인은 앞글자만 따서 외우는 요행도 필요한 것 같다. 1계층부터 7계층까지 순서로 "물데네 전세표응" 이라고 앞글자를 따서 외우니까 금방 외워지는 것 같다.

통신에 필요한 기능을 7개의 계층으로 분할해서 꼭 외우도록 하자. 이 계층들은 프로토콜을 단순화하기위한 목적을 가지고 있다. 1977년 OSI계층 모델은 모든 시스템에 통신이 가능하기 위해 개발된 네트워크 아키텍처이다. 실제 네트워크에서는 구현되지 않지만 참조 모델로서 의미를 가졌다.

하향식 접근으로 각 계층별로 알아보자.

* 7계층 : Application Layer(응용계층)

유저가 가장 접근하기 빠른 계층이다. 각종 응용프로그램간의 정보를 전달하기 위한 계층이다. 응용 프로세스간의 정보 교환을 담당하며 FTAM(File Transfer, Access and Manipulation), VT(Virtual Terminal)을 담당한다.

* 6계층 : Presentation Layer(표현계층)

응용계층(Application Layer)에 의해 생성된 데이터나 payload가 네트워크 상에 전송하기 위해 생산되고 소비되는 데이터 형식이나 형태를 번역하는 방법 등을 정의하는 계층이다.

Encode, Encryption, Decode, Decryption 같이 인코딩, 디코딩, 암호화, 해독을 하는 일을 수행하는 계층이다.

* 5계층 : Session Layer(세션계층)

6계층인 표현계층에서 4계층인 전송계층으로 진입하기 위해 개념적이고 추상적인 인터페이스를 제공하는 계층이다. 헤더에서 세션정보를 담고있다.

* 4계층 : Transport Layer(전송계층)

네트워크 상에서 송수신 시스템간의 물리적 위치를 논리적인 주소와 이름을 이용하여 연결하는 방식 및 종료하는 방식 등이 정의되어지는 계층이다.

중요! TCP/UDP, 헤더에 Port정보를 담고있다.

* 3계층 : Network Layer(네트워크 계층)

패킷들이 어떻게 네트워크상에서 라우팅되는지를 정의하고 노드에 전송되는 패킷의 흐름을 통제하고 상태 메세지를 전송하는 계층이다. 데이터를 수신처까지 보내는 역할을 하며 경로 선택의 역할을 한다.

중요! 헤더에 IP주소를 담고있다.

* 2계층 : Data Link Layer(데이터링크 계층)

데이터 링크 계층은 데이터 전송 신호를 규정하고 송수신 시스템간의 데이터에 대한 전기적 신호를 어떻게 처리할 것인지를 규정하는 계층이다.

중요! 헤더에 MAC주소를 담고있다.

* 1계층 : Physical Layer(물리계층)

실제 네트워크의 물리적 형태인 Topology를 규정하여 Data의 전기적 흐름에 따라 전송하는 계층이다.

컴퓨터가 알아들을 수 있는 전기적 신호인 비트(0100101 형태)로 변환하여 전송한다.

각각의 계층별로 특징도 중요하지만 전체적인 흐름과 overview를 먼저 인지하고 있으면 도움이 될 것 같다. TCP/IP주소는 이 계층과 다른게 아니라 비슷한 개념으로, 4개의 계층으로 분류가 된다. 다음에 기회가 되면 TCP/IP 계층에 대해서도 정리를 해 볼 예정이다.

네트워크 접속장치 : 라우터, 스위치, 허브, LAN카드, MAC(Media Access Address)

심루트 — Mon, 19 Apr 2021 17:39:32 +0900

네트워크에 접속 장치는 통신망을 사용하기 위한 가장 기본이 되는 하드웨어이다.

네트워크를 구축하고 접속하기 위해 필요한 장치인 라우터, 스위치, 허브, LAN카드에 대한 정리와, MAC이 무엇인지 한 번 정리해보려고 한다.

라우터(router)

라우터는 패킷의 위치를 추출하며, 그 위치에 대한 최적의 경로를 지정하며, 이 경로를 따라 데이터 패킷을 다음 장치로 전향시키는 장치이다. 위키님이 알려 주신 정의인데, 오히려 정의를 보고 나서 더 어려운 말들이 많이 나와 어려운 느낌이다.

스위치(Switch)

컴퓨터 사이를 연결해주는 역할을 하며 허브와 비슷하게 생기기도 했고 하는 일도 비슷하다. 그래서 육안으로 구분하려고 한다면 모델명을 확인해서 검색해봐야 한다. 그렇지만 허브와 다른 점은 조금 더 효율적인 통신을 가능하게 해준다. 소규모 통신을 위해 허브보다 전송 속도가 개선된 것이다. 요즘에는 허브 가격이나 스위치 가격이나 비슷하다고 해서 그 가격이면 스위치를 사서 사용한다고 한다.

허브(Hub)

말 그대로 컴퓨터와 컴퓨터를 이어주는 역할을 한다. 허브와 허브 사이를 연결해주는 브릿지의 개념도 있다. 앞서 설명한 것과 같이 스위치와 허브는 생긴게 거의 비슷하다. 구글링해서 두개가 어떻게 생겼는지 비교해보는 것도 좋을 것 같다.

LAN 카드(LAN Card)

네트워크에 연결하는 물리적 장치에는 반드시 하나 이상의 LAN카드가 있어야 한다. LAN카드는 전송매체에 접속하는 역할과 데이터의 입출력 및 송수신, 프로토콜의 처리 기능 등을 담당한다. 랜카드의 형태는 노트북이나 PC를 분해해보면 확인해볼 수 있는데, WiFi 기능이 되는 USB 포트 형식의 랜카드도 있다. 이전에 초소형 컴퓨터로 프로젝트를 진행할 때 와이파이 랜카드를 사용해서 인터넷을 끌어 써본 적이 있어 기억이 난다.

MAC(Media Access Address)

각 LAN카드에는 주민등록번호처럼 고유의 식별코드가 있다.

MAC 주소(물리적 주소) 중 앞의 24비트는 LAN 칩셋 제조사를 의미하는 고유 코드고, 뒤의 24비트는 제품의 일련번호와 같이 부여되는 것이므로 전 세계에서 유일한 내 컴퓨터만의 LAN카드 고유번호가 된다. 쉽게 말하면 이 MAC코드를 반으로 나눠서 왼쪽은 자사양식으로 구성된 시리얼 넘버(삼성,엘지 등)이며, 오른쪽은 고유번호라고 생각하면 된다. 비슷한 제조 공정을 거친 노트북이나 휴대폰 등을 보면 앞의 넘버는 비슷하고 끝에만 다른 경우를 찾아볼 수 있다. 예를들어 92-E0-3F. 이런 식으로 적혀있다. 16진수로 표현이 되어 있는 것 같다.

실제로 네트워크 통신을 할 때 하드웨어가 사용하는 주소는 LAN 카드에 할당된 MAC 주소를 이용한다. 통신이 되는 장비는 다 MAC주소가 있다고 보면 된다. 실제로 테스트를 해봤는데 Ubuntu 쉘에서 ifconfig를 입력하고 나서 연결되어 있는 맥주소를 확인해볼 수 있었다. ether 옆에 적혀있는 16진수로 이루어진 숫자가 바로 맥주소고, Window에서도 다른 방법으로 확인이 가능하다.

아래 사이트에서 찾은 휴대폰이나 PC의 MAC주소를 검색해보면 어느 나라에서, 어느 회사에서 제조되었는지 확인할 수 있다. 안드로이드 폰을 사용하고 있어서 휴대폰은 삼성전자 구미 사업장에서 만들어졌고 노트북은 대만인지 태국에서 만든 것 같다. 국가명이 영어로 적혀있어서 궁금하면 찾아보면 좋을듯하다.

* 맥주소 검색해보기 :

uic.win/ko/mac/

MAC 주소 검색

MAC 주소에서 업체 정보를 표시 할 수 있습니다. 업체 정보는 매일 업데이트하고 있습니다.

uic.win

네트워크 형태 : LAN, WAN, PAN, MAN, Intranet(인트라넷)

심루트 — Mon, 19 Apr 2021 17:07:53 +0900

라우팅&스위칭 관리에 대해 하나하나 공부했던 것들을 기록해보려고 처음으로 글을 작성해본다. 가장 기초적인 네트워크 개요에 대한 내용이다.

네트워크의 형태는 노드와 노드가 그물망처럼 연결되어있다.

네트워크의 규모에 따라 형태 분류를 해볼 수 있다.

1. LAN(Local Area Network) : 근거리 영역 네트워크

가까운 거리에 위치한 컴퓨터의 네트워크를 말하며, 유선 케이블, 적외선 링크, 무선 송수신기 등을 이용하여 통신한다. 더 쉽게 설명을 하면 관리자가 직접 관리가 가능한 영역을 LAN 영역이라 한다. 보통 가정이나 학교에서 볼 수 있는 형태이다.

아래 그림을 참고하면서 이미지화 시켜보면 좋다. 사실 가정에서 이용할 수 있다고 한정짓기에는 모든 곳의 거리가 다 다르기 때문에 규모로 보기엔 사실 어렵다. LAN의 경우 10km의 거리 제한이 있으며, 가정에서만 쓸 수 있다고 하는 부분은 이해를 돕기 위한 것이므로 분류를 딱딱 하는 게 아니라 거리로 분류하면 된다.

2. WAN(Wide Area Network) : 광대역 네트워크

두 개 이상의 LAN 영역을 연결한 영역. LAN 영역에 포함되어 있지 않은 멀리 떨어진 컴퓨터 사이에서도 WAN을 통하여 서로 통신이 가능하다.

3. PAN(Personal Area Network) : 개인 영역 네트워크

Personal에서 알 수 있듯 블루투스나 UWB 등의 기술을 이용해서 개인 휴대기기 사이에서 구성된 무선 연결망을 의미한다.

그 외에도 MAN과 인트라넷의 개념이 있다.

4. MAN(Metropolitan Area Network) : 대도시 영역 네트워크

여기서 등장하는 M은 도시를 의미하는 Metropolitan의 약자이다. 여기서 범위는 LAN보다 넓고 50km 거리 내에서 이용할 수 있다. 큰 학교나 건물, 쇼핑센터같은 곳을 예로 들 수 있다.

5. 인트라넷(Intranet)

인터넷에 사용하는 회선 및 기술을 이용하여 구축한 사설 네트워크. 흔히 군대에서 이용하는 외부 사이트에 접속 제한이 걸려있는 인터넷을 인트라넷이라고 생각하면 될 것 같다. ISP까지 연결이 되면 적은 비용으로 사설 네트워크를 이용할 수 있다.

그리고 기업에서 내부망, 외부망을 따로 관리하는 경우가 있는데 이러한 경우 내부망이 바로 인트라넷이다.

* 이미지 출처

pediaa.com/difference-between-lan-man-and-wan/

Difference Between LAN MAN and WAN - Pediaa.Com

The main difference between LAN MAN and WAN is that the LAN is a network that covers a small geographical area such as residence, school or an office building while the MAN is a network that covers an area larger than LAN but smaller than WAN such as a cit

pediaa.com

velog.io/@dnstlr2933/42netWhat

IP address와 network

두 대 이상의 컴퓨터가 논리적 또는 물리적텍스트으로 연결되어 통신이 가능한 상태일방적으로 규모에 따른 네트워크 종류PAN ( Personal Area Network ) : 가장 작은 규모의 네트워크LAN ( Local Area Networ

velog.io

연구실 안전교육 스킵하는 두 가지 방법 (소스코드 포함,업데이트)

심루트 — Thu, 18 Mar 2021 17:18:46 +0900

안녕하세요 :)

또 다시 2021년도 1분기, 연구실 안전교육을 들어야 하는 시기가 찾아왔어요. 이 안전교육은 연구안전법에 따라 매년, 분기별, 반기별로 비슷한 내용의 안전보건교육을 들어야해요. 그렇기 때문에 처음에만 열심히 듣고 이제는 업무를 해야하니 꽤나 번거로운 작업입니다.

* 관련근거

가 . 연구안전-38호(2021.02.01: 2020년도 산업안전보건 및 소방안전 운영계획(안) 승인의 건)

나 . 산업안전보건법 제 29 조 ( 안전보건교육 )

다 . 연구실 안전환경 조성에 관한 법률 제 18 조 ( 교육 ․ 훈련 등 )

라 . 안전보건관리요령 제 39 조 ( 교육계획 )

저는 연구실이 직장이라서 매년 들어야하는데, 대학원생이나 학부생들도 이수증을 가져와야 해서 많은 사람들이 들어야 하는 교육이더라고요. 저희는 해당 시기에 듣지 않으면 개인이 10만원이라는 과태료를 내야하는 부담이 있기 때문에 시기를 놓치지 않고 꼭 듣고 있습니다.

교육의 퀄리티라도 조금 좋았으면 열심히 들었을텐데, 사실 매년 비슷비슷하고 상식적인 내용 위주라서 간단하게 스킵할 수 있는 소스코드를 사용하곤 합니다. 자주 쓰는 코드는 막히기도 하고 또 다음분기 교육 때는 잘 되기도 해서 2021년 1분기 기준으로 작성을 해봤습니다. 추가로 막히면 올려드린 다른 코드도 사용해보시고, 이번에 막힌 코드가 다음에 잘 적용되기도 합니다.

최근에는 링크를 복사해서 수정하는 방법도 사용이 가능한 것 같으니 아래의 두가지 방법 중에 잘 되는것이나 편하신 걸로 선택하시면 될 것 같습니다 :)

"연구실 안전교육 스킵하는 방법"

[첫 번째 방법] 소스코드를 입력하여 스킵

1. 먼저 구글크롬을 사용하여 안전보건교육 사이트에 로그인하여 수강하기를 눌러줍니다.

2. 동영상이 재생되고 있는 상태에서 키보드의 F12 버튼을 눌러 툴을 띄웁니다.

3. 콘솔(Console) 탭을 눌러줍니다.

4. 프롬프트 모양(>) 안에 있는 빈 화면을 클릭해주고 아래의 소스코드를 입력합니다.

* 한 페이지씩 스킵하는 코드

location.href = chapterInfo[nowPageNum].fileName + ".html?passedPage=" + vPassedPage + "&checkurl=" + nextPageNum + "&smProgressNo=" + smProgressNo;

해당 소스코드를 입력하면 다음 페이지로 넘어가지며, 최종 페이지에서 기다렸다가 종료하시면 수강 완료처리가 됩니다.

* 한 번에 스킵하는 코드

var currentPage = nowPageNum;

function goNextPage() {

if (currentPage <= totalPageNum) {

console.log(`${currentPage} 페이지를 수강완료했습니다.`);

currentPage += 1;

setTimeout(function() {

goNextPage();

}, 2000);

} else {

alert('강의 수강이 완료되었습니다!');

}

}

function runKmuMacro() {

console.log(`현재 ${currentPage} 페이지를 수강중입니다.`);

setTimeout(function () {

goNextPage();

}, 1000)

}

runKmuMacro();

이 코드를 입력하고 기다리면 마지막에 최종 페이지를 수강완료하였습니다 라는 안내와 함께 수강이 완료됩니다. 이게 제일 간편한 방법인 것 같은데 자주 막힐 때가 있으니 막히면 위에 코드를 사용하면 됩니다.

[두 번째 방법] 링크를 수정하여 스킵

1. 안전보건교육 사이트에 로그인하여 수강하기를 눌러줍니다.

2. 우측 하단의 총 페이지 수를 확인합니다. 해당 강의는 총 15개의 강의로 이루어져 있는 것을 확인할 수 있습니다.

3. 이 숫자를 기억하고 상단의 링크를 복사합니다.

4. 상단 링크에 노란색 형광펜으로 표시한 숫자를 기억합니다. 01과 1으로 이루어져 있습니다.

5. 새로운 인터넷 창을 열어 링크를 붙여넣기 한 후 위의 두 위치에 최종 페이지인 15를 넣어줍니다. 페이지에 따라 숫자가 달라질 수 있습니다.

5. 마지막 페이지가 나오는데, 10초정도 기다렸다가 강의가 완료되면 다시 본 페이지에서 수강여부에 "수강"이라고 표시되어있는 것을 볼 수 있습니다.

화면결과

이수 완료!!