지식창고

특징 1. 개발과 운영의 project가 분리된 환경 2. feature branch의 생성은 master branch에서 checkout 받아서 생성 3. DEV 환경에서 PROD 환경으로 Push하는 branch가 추가됨 1. CI/CD 파이프라인 구성 1.1 Gitlab User 생성 시작 전 Gitlab CI에 Gitlab Runner가 최소 하나는 등록이 된, CI/CD가 실행 가능한 환경이라고 가정하고 설명한다. Prod와 Dev Gitlab 모두에 새로운 User를 생성한다. 이 User는 git clone이나 push시 해당 git project에 인증하는 용도로 사용하는 계정이다. Admin Area에서 'New User'버튼을 통해 git 인증용 user를 생성한다. sample use..

0. 개요 Gitlab Runner는 Job을 수행 시 Docker Conatiner를 띄워서 작업한다. 러너의 Job 실행 소스는 .gitlab-ci.yml에 정의가 되는데, 이 파일에 image를 설정한다. Job을 실행할 때 미리 설치해야 하는 패키지들을 before-script 부분에서 정의하지만, 매번 Job을 수행할 때마다 설치하는 것은 효율적이지 않다. 그래서 미리 패키지들을 설치한 이미지를 ECR에 올린 후 사용하면 보다 효율적인 Pipeline을 구축할 수 있다. 1. Gitlab 설정 방법 1.1 작업 환경 현재 프로젝트에서는 CI 서버인 EC2 인스턴스에 OS는 Ubuntu 18.04 버전이 설치되어 있는 환경이다. 1.2 Docker ECR Credential Helper 설치 우선..

1. 목적 이 글은 Kubernetes 기반 시스템에서 Istio를 이용하여 Blue/Green 배포를 구성하는 방법을 설명하고 있다. 구성 환경은 GCP GKE 1.18.20-gke.501 버전과 Istio 1.10.0 버전으로 Kubernetes Service mesh 환경을 구현하였다. CI/CD 툴은 Gitlab, Gitlab runner를 사용한다. 2. Blue/Green Deployment Blue/Green Deployment는 현재 운영중인 버전(Blue)과 새로운 버전(Green)의 서버들을 동시에 나란히 구성하고 배포 시점이 되면 트래픽을 일제히 전환시키는 배포 방식이다. 운영 환경에 영향을 주지 않고 실제 서비스 환경으로 새 버전 테스트가 가능하고, 빠른 롤백이 가능하다는 것이 장점..

Pod Network: 모든 node의 pod안에 연결되어 있는 클러스터 내부 가상 네트워크. 이 덕분에 pod간 통신이 가능 Service는 pod network에 조인이 불가능함. 이는 실체가 있는 것(Actual thing)이 아니기 때문. Service는 K8S 메모리에만 존재하는 가상의 component. kube-proxy: process that runs on each node in the kubernetes cluster kube-proxy는 새로운 service를 발견하면 각 service 뒤에 매칭되는 pod에 traffic 전달하는 규칙 생성. 각 node에 iptables 생성하여 대응되는 service와 pod IP 저장 kubeadm은 kube-proxy를 daemonset으로 ..

registers the node with the kubernetes cluster master node로부터 pod 생성 요청이 오면 worker node의 container runtime(Docker)에게 image pull해서 instance run하도록 함 monitor Pod & Nodes !!Kubeadm does not deploy Kubelet!! 항상 manually installed ps -aux | grep kubelet

responsible for deciding which pods goes which nodes 실제로 node에 pod을 위치시키지 않음. 그것은 kubelet의 역할 node의 사이즈에 따라 적절한 pod를 위치시킴 2개의 특정한 기준에 따라 pod를 위치시킴 1. Pod의 profile 기준으로 적당한 node만 filter 2. pod를 위해서 적절한 node를 0부터 10으로 rank pod 위치한 후 node의 예상 amount of resources 계산 후 적절한 것에 높은 점수 master node의 kube-scheduler config file 위치 /etc/kubernetes/manifests/kube-scheduler.yaml 실행중 process로 확인 : ps -aux | gre..

manages various manager in K8S process that continuously monitors the state of various components within the system works towards bringing the whole system to the desired functioning state Node-Controller는 주기적으로 node체크하여 문제 있으면 Kube-API 통해서 Node 정상화시킴 Node Monitor Period : 5s Node Monitor Grace Period : 40s Pod Eviction Timout : 5m 여러 components 의 controller들은 하나의 Kube-Controller-Manager로 묶임. ku..

Primary management component in K8S kubectl create pod 실행시 Kube-API 호출 Authenticate User Validate Request Retrieve Data Update ETCD Scheduler로 적절한 Node확인 Kubelet한테 Pod 만들라고함 Pod 생성 후 ETCD 업데이트 Kube-API는 ETCD와 직접 interact하는 유일한 Components 다른 components는 Kube-API를 이용하여 update kubeadm에 의해 설치되었다면, Kube-API는 kubectl get pods -n kube-system 명령어로 보임 config file /etc/kubernetes/manifests/kube-apiserver...

K8S의 distributed reliable Key-Value store 설치를 위해선 binary 받고 extract한 후 run 함 포트 2379가 기본 etcdctl : ETCD를 위한 control cli etcdctl set key1 value1 : Key setting etcdctl get key1 : Key getting kubectl get 명령어를 할 때 나오는 모든 정보들은 ETCD server에서 나옴 etcd contents Nodes Pods Configs Secrets Accounts Roles Bindings Others 저장된 정보에 업데이트가 되면 모두 etcd에서 업데이트됨 업데이트가 되어야 변경사항이 완료되었다고 여겨짐 Scratch 에 설치하면 etcd binary ..

Maven, Gradle 차이 필요한 라이브러리를 땡겨 오고, 빌드 라이프 사이클을 관리해주는 툴 과거에는 Maven 사용하였으나, 요즘은 gradle 사용 Springboot group 보통 Group에 기업명 적어줌 Artifact 빌드 하고 나오는 결과물 이름 Dependencies Spring boot에서 사용할 라이브러리 목록 프로젝트 보면 테스트용 코드를 보관하는 test 폴더가 따로 있음. 이는 요즘 개발 트렌드에서는 테스트가 그만큼 중요하다. resources파일은 실제 코드가 아닌 xml파일 등과 같은 것들이 보관되어 있음 java 파일을 제외한 나머지 build.gradle dependencies: 라이브러리 정의 repositories: 라이브러리를 다운받아오는 경로 gradle 라이..