Blockchain & Devops, bitetiger

이전 EC2 Dynamic Inventory를 생성하는 테라폼 코드를 활용해서 그 위에 Ansible로 환경설정하는 과정을 진행해보려 한다. Terraform은 Klaytn node의 전체적인 아키텍처의 인프라 리소스를 생성하는 역할, Ansible은 생성된 리소스에 필요한 패키지 설치와 node의 환경설정을 하는 용도로 사용한다. 테스트 용도기 때문에 아래와 같이 간단한 아키텍처로 구성. Controll node로 사용할 EC2 1개 Managed node로 사용할 EC 2개 (Endpoint node, Service chain node) Ansible node EC2에 접근하기 위한 kay-pair, aws dynamic inventory를 구성할 yml을 provisioner로 할당하고, EC2fu..

Ansible을 사용하다보면, 빈번히 삭제되고 생성되는 EC2 인벤토리를 정의하는 것이 쉽지않다. 그러나 Ansible Plugin을 활용해서 Dynamic Inventory를 활용하면 구성된 EC2를 자동으로 인벤토리에 할당하기 때문에 아주 간편하다. 기본적으로 Managed node를 관리하는 Controller node에 다음과 같은 기본설정이 필요하다. Controller node - AmazonEC2FullAccess 권한 - Managed node와 통신을 위한 키페어(.pem) - python과 boto설치 Managed node - 조회 시 사용될 tag를 설정한다. - ssh Port가 열려있어야한다. (Ansible은 ssh 프로토콜을 통해서 통신) Dynamic Inventory 생성..

지금까지 Terraform을 통해서 클라우드 인프라 리소스를 생성하고 관리했다. 그러나 Terraform은 사실상 클라우드 아키텍처를 구성하거나, 새로 생성, 변경하는데 효율적인 인프라 관리 도구다. 생성하고 나서부터, 동작 중인 서버를 효율적으로 관리, 운영하는데 사용될 수 있다. 물론 Terraform과 동일한 기능이 있으나, 이미 생성된 인프라에 application을 구성하고 배포, 관리하는데 아주 효과적이다. 그래서 Terraform과 Ansible은 통합되어 상호보완적으로 활용될 수 있다고 생각한다. Ansible Ansible은 크게 Control Node와 Managed Node로 나뉜다. Python 베이스로 작동하며, Control과 Managed Node 모두 Python이 기본적으로..

DevOps, SRE의 정의에 대해서 간단히 알아보자. DevOps(Development + Operations) 데브옵스는 전체적인 개발 사이클을 빠르게 하고자 하는 소프트웨어 개발 접근방법이다. Continuous delivery이 가능하게 하며, 빈번한 release와 자동화된 소프트웨어와 앱 개발이 가능하도록 하는데 초점을 둔다. 그래서 업무의 빠른 flow가 가능하게 된다. 데브옵스 프로세스의 주요 목표는 프로덕트의 출시를 가속화 소프트웨어의 개발 라이프사이클 단축화 시장 니즈에 빠른 대응 그래서 development와 operation의 융합이자, 코드를 가능한 부드럽고 빠르게 배포될 수 있도록 하는 팀을 의미하기도 한다. 팀은 개발과 운영을 위해 원활한 소통이 요구되며 높은 수준의 자동화를 ..

Helm은 쿠버네티스의 service, deployment, configmap과 같은 다양한 오브젝트들을 결합해주는 쿠버네티스용 패키지라고 보면 된다. Helm은 애플리케이션 컨테이너 배포는 물론이고, 이에 필요한 쿠버네티스 리소스를 모두 배포해주는 역할이라고 보면된다. 왜 굳이 Helm을 사용해야할 까? Deployment 히스토리 기능 제공 Helm에서 배포된 어플리케이션은 Helm release로 관리가 된다. 릴리즈된 버전 기록을 자동으로 유지 관리하고 배포 후에 문제 발생시 롤백하는 것이 간편하다. CI/CD 파이프라인 가능 CI/CD 파이프라인을 이용해서 배포 작업을 구성하고 자동화할 수 있다. 멀티스테이징 배포 중에 어플리케이션 구성이 가능하다. 쉽게 말해서, 스테이킹 운영환경에 따라서 Po..

서비스와 인그레스는 같은 네트워크 관련 오브젝트로, 쿠버네티스의 각 컨테이너의 네트워크 포워딩과 설정에 관여한다고 볼 수 있다. 서비스(Service) 위 이미지에서 보는 것처럼, 서비스는 같은 역할과 서비스를 하는 여러 POD를 하나로 묶어서 관리하는 오브젝트라고 볼 수 있다. 파드가 새로 생성될 때마다 동적으로 IP를 할당할 수 있다. 간단히 말해서 서비스는 트래픽을 파드로 전달만하는 역할을 한다. 여기서 서비스는 여러 종류를 가진다. 1) ClusterIP 내부에서만 접근할 수 있는 IP를 할당한다. 그래서 외부에서 접속이 불가능하다. 그러나 kubeproxy를 활용하면 접근할 수 있다 2) NodePort 클러스터의 모든 노드로 외부에서 접근할 수 있는 포트를 개방한다. NodePort가 설정되면..

쿠버네티스의 오브젝트는 컨테이너 워크로드를 처리하는데 사용되는 1) 워크로드용 객체, 네트워크 및 보안을 처리하는 2) 인프라 객체와 구분할 수 있다. 오브젝트 생성을 위해서는 YAML을 활용하고, API 서버를 통해서 요청된다. 그리고 생성전에 유효성 검증이 진행된다. Workload 1) Pod 파드는 작업의 기본 단위면서, k8s에서 생성하고 관리할 수 있는 가장 작은 단위의 유닛이다. 파드는 하나 이상의 컨테이너들의 그룹이며, 모두 스토리지와 네트워크 리소스를 공유한다. 굳이 비유를 하자면 '하나 혹은 여러 컨테이너들을 감싼 얇은 wrapper'다. 2) Deployment 디플로이먼트는 파드와 레플리카셋의 선언적인 설정을 제공한다. Deploy하여 레플리카셋보다 한 단계 높은 관리 오브젝트를 생..

쿠버네티스의 아키텍처는 크게 Control Plane, Node로 나뉜다. 아래 이미지를 보면 클러스터의 아키텍처를 쉽게 파악할 수 있다. Control Plane '마스터노드(Master Node)' 라고 불린다. Control Plane은 클러스터의 Work Node와 Pod를 관리한다. 프로덕션 환경에서, Control Plane은 일반적으로 여러 PC에서 실행되며 하나의 클러스터가 여러 노드들을 관리하여 고가용성과 내결함성을 제공한다. Control Plane CLI와 UI를 통해서 API 서버를 통해 Input 요청받는다. 또한, 마스터 노드에서는 사용자 workload를 사용하지 않는것이 좋다. Node '작업자 노드(Worker Node)'라고 불린다. 컨테이너화된 어플리케이션을 실행하는데 ..

윈도우에 mongodb를 설치하고 나서 실행할 때 아래와 같은 에러가 뜨게된다. 이 에러는 처음 설치할 때, 설정된 DB 디렉토리가 존재하지 않아서 발생하는 오류다. mongodb의 default DB 디렉토리 경로는 C:\data\db 기 때문에 C드라이브에 data/db 디렉토리를 생성하거나, 다시 설치해서 db 디렉토리 경로를 재설정하는 것이 좋다. 만약 Ubuntu일 경우, 아래 명령어로 디폴트 /data/db 생성 후 권한 설정 sudo mkdir -p /data/db sudo chown -R `id -un` /data/db + 윈도우 사용자라면 차라리 클라우드 상에서 만들거나, 도커 이미지를 활용하는 것이 간단함.