이번 포스팅에서는 Terraform에서 생성한 AWS Resource를 수정하는 부분에 대한 내용부터 시작해보려고 한다.
Terraform은 손쉽게 AWS Infrastructure를 구성할 수 있도록 도와줌과 동시에 코드를 통해 전체적인 AWS Infrastructure의 구조를 파악할 수 있다.

Terraform의 동작 방식

만약 실행하고자 하는 *.tf 파일이 이전에 실행을 한 다음에 별도의 수정을 하지 않았다면, $terraform apply명령을 실행하여도 아무런 변화가 일어나지 않는다. 그 이유는 terraform은 기본적으로 $terraform plan명령을 통해 확인할 수 있는 변화된 내용이 있어야 $terraform apply명령을 통해 새롭게 인프라를 구축할 수 있다.

만약 기존 리소스에서 tag에 대한 정보만 추가한 다음에 다시 실행하면, 기존에 생성되었던 리소스는 유지된 상태에서 resource name (Name)이 추가가 된다.

Delete resources

기존에 *.tf파일을 통해 생성하였던 리소스들을 삭제하려면, $terraform destroy 명령을 치면 된다.

1

$terraform destroy

만약 기졵의 .tf 코드에서 일부 리소스를 주석처리하게 되면, apply를 했을때 주석처리된 리소스를 제거한다. (일부 리소스 제거)

Read More

ClusterIP Service 실습

ClusterIP Service를 생성하고, 지정한 selector가 app:pod를 가지는 pod와 연결을 하였다. 그런 다음에 연결된 app:pod label을 가지는 Pod를 삭제하고, 다시 재생성을 한다. 이렇게 되면, 실제 pod에 할당되어있던 IP는 동적으로 할당이 되어 변경이 되지만, ClusterIP Service는 재생성이 되지 않아, 동일한 Service IP로 Pod에 접근이 가능하다.

NodePort Servce 실습

실제 Dashboard의 디스커버리 및 로드 밸런싱 하위의 서비스 항목을 가보면, 내부 엔드 포인트가 두 개 생성된 것을 확인할 수 있는데, 상위에 있는 9000번 포트가 클러스터 내에서 접근할때 사용되는 포트이고, 30000번 포트가 각 각의 노드들에 동일하게 할당된 포트 번호이다. 이 포트를 통해 외부에서 클러스터 내부의 Service를 통해 하위 Pod들에 트래픽을 보낼 수 있다.
실습에서는 외부 터미널에서 curl 명령을 통해 서비스에 접근하여 각 pod에 대한 hostname이 출력되는 것을 확인하였다.

Read More

이번 포스팅에서는 Terraform에 대해 공부한 내용을 정리해두려고 한다. 지금 Docker나 Kubernetes도 데이터 파이프라인 구축시 별도의 서버를 컨테이너로 띄우고 관리하기 위해서 공부를 하고 있지만, 결국에는 반복을 통해서 익숙해지는 것이 최고이기 때문에 Terraform도 빠르게 개념을 정리하고 어떻게 AWS 인프라를 코드로 작성해서 간편하게 관리할 수 있는지에 주안점을 두고 학습을 해보려고 한다.
Terraform을 학습하게 된 계기는 우선 AWS의 서비스로 데이터 파이프라인을 구축할때 웹 페이지나 AWS CLI 상에서 계속 반복적인 작업을 통해 각 컴포넌트를 생성하는데 있어, 비효율적인 것 같다는 생각에서 비롯되었다.
그러던 중 현재 오프라인으로 DE 현직자에게 AWS 클라우드 환경에서 데이터 파이프라인 구축하는 방법에 대해서 수업을 듣고 있는데, Terraform과 같은 IaC(Infrastructure as Code)로 관리를 하게 되면, 좀 더 수월하게 데이터 파이프라인의 AWS 인프라를 빠르게 구축할 수 있다고 해서 개인적으로 공부를 시작하게 되었다.

Terraform ?

Terraform은 IaC로, 인프라를 코드로 정의함으로써, 손쉽게 인프라 전반을 관리할 수 있도록 해주는 툴이다.

Homebrew를 사용해서 Terraform 설치

package management tool인 homebrew를 사용해서 Terraform을 설치할 수 있다.

1
2

$brew install terraform
$terraform -v # Terraform v1.2.2

Read More

이번 포스팅에서는 세 번째 데이터 파이프라인 구축 오프라인 수업시간에서 배운 내용을 정리하려고 한다. 참고로 첫 번째와 두 번째 수업때도 너무 유익한 내용들이 많았는데, 이번 시간이 정말 너무 유익하고 좋았다.
아마도 이전에 인터넷 강의로 수강을 했을 때 아쉬웠던 부분이 많았는데, 이번에 개별적으로 현직자 분께 오프라인으로 직접 수업을 들으니, 궁금했던 부분이 많이 해소되기도 했고, 강사님이 수업에 필요한 여러 자료나 실제 회사에서 업무했을 때 필요한 부분에 대해 설명을 잘 해주셔서 그런 것 같다.

Read More

이번 포스팅에는 쿠버네티스 클러스터에서 서비스와 관련된 이론내용을 정리하고, 실습한 내용에 대해서 정리하려고 한다.
저번시간에는 실습을 위한 쿠버네티스 클러스터 환경을 구축하고, Container, Label, NodeSchedule에 대한 부분을 학습하고 실습을 해보았다.
컨테이너는 쿼버네티스 클러스터 내의 namespace 상에 존재하는 pod의 내부에 복수로 존재하며, 각 각의 컨테이너들은 복수 개의 IP 할당이 가능하지만, pod 내에서는 IP 충돌로 인해 동일한 IP의 할당이 불가하다는 것을 이론과 실습을 통해 이해했다.
Label은 각 각의 용도에 따라 Pod에 명기된 label로 Pod들을 묶어서 하나의 서비스를 생성하거나, 또 다른 pod 집합으로 생성하기 위해 사용된다는 것을 이론과 실습을 통해 이해하였다.
마지막으로 NodeSchedule 파트에서는 각 각의 Pod들은 Cluster에 연결된 노드들에 할당이 되어야 하는데, 할당하는 방법에 대해서는 직접 Pod를 Node에 할당하는 방법과 스케줄러에 의해 각 각의 노드가 가지고 있는 여유 메모리 공간에 대한 확인으로, 자동 할당되는 방법에 대해서도 이론과 실습을 통해 이해하였다.

아직 개괄적으로 쿠버네티스에 있는 각 각의 요소들의 개념과 원리에 대해서 이해하는 과정이기 때문에 전체적인 그림 안에서 각 각의 요소가 어떤 기능을 하는지에 대해서 이해하면서 학습을 하고 있다.
엇그제 Label을 통해서 용도에 따라 pod(들)을 묶어서 하나의 Service로 만들어서 다른 운영자에게 IP와 Port를 제공한다고 배웠다. (웹 개발자가 웹 화면만 확인하고자 할때 type이 web인 pod들만 service에 연결시켜서 웹 개발자들에게 제공 / 외부에서 원하는 service의 pod들에만 접그하고자 할 때 label이 production으로 지정된 pod들을 묶어서 하나의 service로 생성하고 제공)
이 Service에 대해서 이론적으로 학습을 하고 직접 실습을 해 볼 것이다.

Read More

쿠버네티스 클러스터 실습 구성도

Vagrant 명령(손쉽게 VirtualBox의 VM관리)

host os의 cmd창에서 실행

1
2
3
4

$vagrant up: 가상머신 기동
$vagrant halt: 가상머신 shutdown (클러스터 실습이 끝나고 VM 내리기)
$vagrant ssh: 가상머신 접속 (vagrant ssh k8s-master)
$vagrant destroy: 설치한 가상머신 삭제

Read More

collections의 Counter 활용

여지까지 리스트내의 값을 key:value(등장 횟수) 형태인 dictionary 자료형으로 만들때 일일이 for문으로 순회를 하면서 value 값을 증가 시켜주었는데, 이번 커뮤러닝을 통해 참여하신 분 중 한 분이 내 코드에 리뷰를 해주셨는데, collections의 Counter를 활용하면 더 간결하게 코드를 작성할 수 있다고 해서 코드를 다시 작성해보았는데, 리뷰해주신 내용대로 코드가 훨씬 간결해졌다.

Read More

Kubernetes ?

큰 기업은 대규모의 서비스를 운영하고 있기 때문에 최대한 자원을 효율적으로 써야 비용적으로 유리하다. 따라서 서버자원을 효율적으로 쓰기 위해서는 가상화 기술에 대해서 이해해야 한다.

과거에는 리눅스의 자원격리 기술(1991)이 있었다. 이후에 VMware, Xen, openstack VM(Virtual Machine)(2010.7)
가상화를 위해서 띄우고자 하는 가벼운 서비스를 사용하기 위해 더 무거운 OS를 올려야되는 상황이 생겼다.

어려운 자원격리기술을 dotCloud라는 회사에서 쉽게 사용할 수 있도록 container 서비스를 만들었고, 회사를 docker로 변경하면서 만든 서비스를 오픈소스로 공개하였다. (2014.06)
컨테이너 가상화 기술은 서비스간에 자원격리를 하는데 별도의 OS를 안띄워도 되기 때문에 OS 기동시간이 필요없게 되고, 자동화시 엄청 빠르고 자원의 효율도 매우 높아지게 되었다.

이러한 이유로 도커는 유명해졌다. 하지만 도커 자체는 하나의 서비스를 컨테이너로 가상화시켜서 배포를 하는 것이기 때문에 많은 서비스들을 운영할때 일일이 배포하고 운영하는 역할을 해주지 않기 때문에 불편함이 있었다.

Read More

이번 포스팅에서는 EC2 인스턴스의 전반적인 스토리지 옵션들에 대해서 알아본다. 스토리지 옵션에는 EBS, EC2 Instance store가 있으며, 각 각의 세부적인 특징에 대해서 알아본다.

EBS(Elastic Block Storage)

EBS는 EC2 인스턴스가 실행중인 동안 연결이 가능한 네트워크 드라이브이다. EBS 볼륨을 사용하면, 인스턴스가 종료된 후에도 데이터를 지속적으로 유지할 수 있다. 인스턴스를 재생성하고, 이전에 사용한 EBS 볼륨을 마운트하면, 데이터를 다시 받을 수 있다.

이전에 CCP자격시험을 준비할때에는 하나의 EBS는 하나의 EC2 인스턴스에만 마운트 할 수 있다고 배웠다. 그리고 하나의 인스턴스에는 다중 EBS 볼륨의 연결이 가능하다.

EBS는 특정 가용 영역에 제한되서 사용할 수 있다. 따라서 EC2 인스턴스가 생성된 AZ과 EBS의 AZ를 매칭시켜줘야 한다. 단, EBS를 snapshot해주게 되면, 다른 AZ 영역의 EC2 인스턴스에 연결해줄 수 있다.
(Free tier에서는 매달 30GB의 EBS 스토리지 를 범용 SSD나 마그네틱 유형으로 제공)

Read More

실습1) ghost 블로그 docker 컨테이너 생성

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

# Ghost는 무료 오픈소스 블로깅 플랫폼으로, 자바스크립트로 작성되었다고 한다.

# *.yml 파일은 docker-compose 명령을 사용해서 up, down을 할 수 있도록 도와준다.
# 기존의 콘솔에서 명령어 입력할 때 띄어쓰기등의 입력의 불편한 점을 개선하고자 *.yml파일은 유용하게 사용된다.

version: '3' # docker compose에 정의된 버전에 따라 지원하는 docker의 engine도 달라진다.

services: # 실행할 컨테이너를 정의한다. ($docker run -name [name] [service])
  ghost:
    image: ghost:latest
    ports:
      - '60000:2368'
    volumes:
      - ./ghost/content:/var/lib/ghost/content
    environment:
      url: http://localhost:60000

Read More