레플리케이션 컨트롤러의 역할

 

1. 장애 극복

Replication contorller 는 단일 POD를 복제해 여러개의 인스턴스로 실행시킨다. 이런 특징 덕분에 어플리케이션의 장애가 발생하더라도, 복제된 인스턴스를 통해 요청을 처리할 수 있다.

 

2. 로드벨런서

Replication controller 는 단일 클러스터 내의 여러 노드에 걸쳐져 있다. 어플리케이션을 사용하는 유저의 수가 급증할때, 트래픽을 분산해주는 역할을 하며 해당 노드의 자원이 고갈 직전이라면, 다른 노드에 포드 배포함으로 트래픽을 효율적이게 분산해준다.

 


다른점: 레플리카 컨트롤러(Replica Controller) vs 레플리카세트(Replica Set)

* 쿠버네티스에서는 Replica Set 의 사용을 권장하고 있다. (Replica Controller 예전 방식)

 

1. Replica Controller 생성 방법(권장하지않음)

#replica-controller-definition.yaml

apiVersion: v1
kind: ReplicationController
metadata:
    name: myapp-rc
    labels:
        app: myapp
        type: front-end
spec:
    template:
        metadata:
            name: myapp-pod
            labels:
                app: myapp
                type: front-end
        spec:
            containers:
                - name: nginx-container
                image: nginx
    replicas: 3

template: 레플리카 컨트롤러에게 어떤 POD 를 기준으로 생성하라고 선언해주어야한다. 포드를 선언할때 사용했던 yaml 파일의 내용을 재사용할 수 있다. POD의정보(metadata ~ spec) 가 레플리카의 spec 아래에 위치한다.

replicas: 단일 포드의 정보를 몇개 복제할지 작성한다. 

* template 과 replicas 는 레플리카컨트롤러 spec 의 자식임으로 같은 level 에 선언되어야한다.(indent 주의)

 

template: 레플리카 컨트롤러에게 어떤 POD 를 기준으로 생성하라고 선언해주어야한다. 포드를 선언할때 사용했던 yaml 파일의 내용을 재사용할 수 있다. POD의정보(metadata ~ spec) 가 레플리카의 spec 아래에 위치한다.

 

 

2. Replica Set 생성방법(권장)

apiVersion: apps/v1
kind: ReplicaSet
metadata:
    name: myapp-replicaset
    labels:
        app: myapp
        type: front-end
spec:
    template:
        metadata:
            name: myapp-pod
            labels:
                app: myapp
                type: front-end
        spec:
            containers:
                name: nginx-container
                image: nginx
    replicas: 3
    selector:
        matchLabels:
            type: front-end

selector(optional): 태그를 통해 어떤 POD 가 레플리카를 통해 관리되고 있는지 선언한다.

matchLabels: 해당 태그에 선언된 label 과 매칭되는 모든 POD 들을 관리한다.

 


 

레플리카 스케일 적용 및 변경하기

1. 명령어

kubectl scale --replicas=6 -f <파일.yml>

kubectl scale --replicas=6 -f replica-definition.yaml



kubectl scale --replicas=6 <오브젝트타입> <레플리카이름>

kubectl sacel --replicas=6 replicaset my-replicaset

 

*명령어를 통한 스케일링 변경은 파일을 자동적으로 업데이트해주지 않는다.

 

2. 선언파일 수정 후 적용

vim replica-definition.yaml

(수정)

kubectl replace -f replica-definition.yaml

 


레플리카세트 CRUD

1. 생성하기

kubectl create -f <레플리카 정의파일.yaml>
kubectl create -f my-replicaset.yaml

 

2. 불러오기

kubectl get replicaset

 

3. 수정하기

kubectl replace -f my-replicaset.yaml

 

4. 삭제하기

kubectl delete <오브젝트타입> <레플리카셋이름>
kubectl delete replicaset my-replicaset

 

'CONTAINER > kubernetes' 카테고리의 다른 글

[Kubernetes] POD 포드란? 생성, 수정, 확인, 삭제  (0) 2021.11.28

 

Kubernetes 는 어플리케이션을 컨테이너 형태로 호스팅하고,

컨테이너들은 POD 라는 곳에 캡슐화되어 배포되어진다.


 

POD 란?

POD는 Kubernetes의 가장 작은 단위의 객체이다. 보통 scaling 을 위해 어플리케이션과 컨테이너를 일대일 관계로 맺어주지만 다수의 컨테이너가 하나의 포드안에 존재하는 경우도 존재한다.

* kuberentes 는 어플리케이션의 스케일링을 위해 더 많은 POD를 배포한다.

 


POD 구성하기

kuberentes 는 YAML 파일 형식으로 작성된 definition file 을 사용해 객체(Pods, Replicas, Deployments, Service, 등)를 구성한다.

apiVersion: v1
kind: Pod
metadata:
    name: <포드이름>
    labels: #원하는 정보를 key, value 형식으로 선언할 수 있다.
        app: <앱이름>
        type: <앱타입: backend>
spec:
    containers:
        - name: <컨테이너이름>
          image: <컨테이너이미지>

1. apiVersion(str): 객체를 생성할때 사용될 kuberentes API 버전

2. kind(str): 생성할 객체의 타입(*case sensitive) 포드를 생성하기 위해서는 POD

3. metadata(dict): 객체의 정보, 해당 정보를 사용해 kuberentes 는 필터를 사용하기도한다.

*label에 선언된 정보를 사용해 kuberentes 는 포드를 필터할 수 있다.

4. specs(dict): 객체의 구성 스팩을 담는 필드, 여러개의 컨테이너가 선언될 수 있다.

*containers 블럭안에 - name 은 리스트의 첫번째 객체를 나타낸다.

 


POD 생성하는 법

# 방법 1: cli 로 생성하기
kubectl run <포드이름> --image=<이미지이름>
kubectl run nginx --image=nginx

# 방법 2
kubectl run <포드이름> --image=<이미지이름> --dry-run=clinet -o yaml > <생성할파일이름>
kubectl run nginx --image=nginx --dry-run=client -o yaml > nginx-definition.yaml
kubectl apply -f nginx-definition.yaml

kubernetes 는 입력받은 포드이름으로 포드를 생성하고, 선언된 도커 이미지를 docker hub 에서 다운로드 받는다.

2. 선언된 도커이미지를 docker hub 에서 다운로드한다.

* public, private 이미지 모두 사용할 수 있다.

 


POD 리스트 확인하기

kubectl get pods
kubectl get pods -o wide

* POD의 상태 또한 확인 할 수 있다.


POD 상세정보 확인하기

kubectl describe pod <pod_name>
kubectl describe pod nginx

POD 수정하기

# 방법 1
kubectl edit pod <포드이름>
kubectl edit pod nginx

# 방법 2: 직접 definition 파일 수정
vim ./nginx-definition.yaml
kubectl apply -f <구성파일이름>
kubectl apply -f nginx-definition.yaml

POD 삭제하기

kubectl delete pod <포드이름>
kubectl delete pod nginx

 


프로젝트구조

>node_modules
>publics
  -index.html
>src
  -app.js
  -index.js
package.json

프로젝트 안에 3개의 폴더(node_modules, publics, src)와 1 가지 파일(package.json)이 있다.

 

node_modules

- js 패키지 관련 파일들 위치하는 곳

publics

- index.html 이 위치하는 곳, index.html가 메인이되는 SPA(single page application) 인듯.

src

- 소스코드 위치

- app.js 파일로 publics/index.htlm 파일을 컨트롤 하는곳인듯.

 

 

시작하기!

1. 노드설치 -> https://nodejs.org/en/

 

Node.js

Node.js® is a JavaScript runtime built on Chrome's V8 JavaScript engine.

nodejs.org

2. 버젼 체크

Node >= 14.0.0 그리고 npm >= 5.6

 

3. 설치 -> https://reactjs.org/docs/create-a-new-react-app.html#create-react-app

npx create-react-app <프로젝트이름>
cd <프로젝트 이름>
npm start

 

4. 설정 확인

파일 packaged.json

...
"scripts": {
	"start": "react-scripts start",
	"build": "react-scripts build",
	"test": "react-scripts test",
	"eject": "react-scripts eject"
},
 ...

5. 실행 

npm run start

 

1.  프로젝트에 Dockerfile 만들기

vim Dockerfile

 

2. syntax parser directive 작성

# syntax=docker/dockerfile:1

  • Must appear before any other comment
  • Instructs the Docker builder what syntax to use when parsing the Dockerfile
  • Allows older Docker versions with BuildKit enabled to upgrade the parser before starting the build

3. 베이스 이미지 설정하기

FROM node:12.18.1

  •  use the official Node.js image that already has all the tools and packages that we need to run a Node.js application

4. 환경변수 설정해주기

EMV NODE_NODE=production

어떤 역할을 하는지 잘 모르겠다. 알아보자 

 

5. working directory 설정해주기

WORKDIR /app

  • Instructs Docker to use this path as the default location for all subsequent commands
  • Don't have to type full path, and use relateive apath based on the working directory.

6. package.json 과 package-lock.json 옮겨주기

COPY ["package.json", "package-lock.json*", "./"]

  • npm install 하기 전에 패키지들의 의존성 정보를 담은 package.jon 을 옮겨주자

7. RUN 명령어로 컨테이너가 생성될때 사용할 명령어를 작성

 

RUN npm install --production

 

8. 사용할 소스파일 복사해주기

COPY . .

 

9.  컨테이너를 만들고 난뒤에 실행할 명령어

CMD [ "node", "dev", "start"]

'CONTAINER > docker' 카테고리의 다른 글

[docker] 실행해보자  (0) 2021.02.28
[docker] 가슴이 docker docker...  (0) 2021.02.27

dotenv 를 왜 써야하는가 ? 

프로젝트를 진행할때 개발 대부분 협업으로 진행된다. 하지만 각 개발자가 개발을 하는 환경은 같을 수가 없기 때문에 환경변수를 등록하는 과정에서 의존성 문제가 발생할 수 있다. node에서는 이러한 의존성 문제를 해결하기 위해 dotenv 라는 모듈을 제공한다. 

 

documentation - www.npmjs.com/package/dotenv


1. dotenv 설치

npm install -S dotenv

2. .env 파일 만들어주기

vim .env
// .env 
PORT= 3000

 

프로젝트 환경변수로 사용할 키, 값을 작성해준다.


3.  import 시켜주기 

import 'dotenv' from 'dotenv';
dotenv.config()

프로젝트 루트에 위치한 .env 파일을 로드 시켜준다.


 

4. .env 파일 사용하기 

process.env.<변수명>

const port = process.env.PORT

process.env.<환경변수이름> 을 통해 .env 파일에 위치한 환경변수를 가져올 수 있다.


 

* .env 파일에는 데이터베이스 비밀번호와 같은 민감한 정보가 담겨있음으로 꼭 .gitignore 파일에 넣어주도록하자

 

 

 

'BACKEND > node.js' 카테고리의 다른 글

[Node.js] nodemon, ts-node 로 서버 자동 재시작  (0) 2021.04.20

<배경>

본격적으로 프로젝트를 진행하기 앞서, 코드를 수정할때마다 서버가 자동으로 시작되는 방법을 찾기 시작했다.

코드를 수정할때마다 서버를 수동으로 재시작한다면 무척이나 번거로운 일이 될것임을 잘 알기에..

 

코드를 수정하고 서버를 띄우는 일련의 과정을 생각해보면 이러한 과정이 되겠지만

  • ts 파일이 수정된다.
  • ts 파일을 컴파일 한다.
  • 만들어진 js 파일로 서버를 시작한다.

프로젝트 규모가 커지면 컴파일과정이 길어질테고 코드한줄만 수정이되면 모든 ts 파일이 컴파일됨으로 비효율적이라고 판단했다.

그래서 ts-node 를 사용해 사전컴파일 없이 서버를 띄우는 방법으로 방향을 잡았다.

 

자동으로 서버를 재시작하는 여러가지 방법이 있지만, 이 포스트에서는 Nodemon 으로 프로젝트 내의 변경사항을 감지하고 ts-node 를 사용하여 사전컴파일 작업없이 빠르게 서버를 재시작해주는 과정을 기록할 것이다.

 

* 문제 접근방법이 잘못되었다면 피드백남겨주시면 감사하겠습니다.


Nodemon 이란 ?

Nodemon 은 node.js 기반으로 만들어진 애플리케이션의 파일 시스템을 지켜보며 변경사항이 생기면 프로세스를 자동으로 재시작 시켜주는 CLI 유틸리티이다.

 

* documentation - github.com/remy/nodemon#nodemon


1. Nodemon 설치하기

npm install -D nodemon

nodemon 을 global 혹은 local 에 설치할 수 있다. 해당 글에서는 로컬에 설치 해주었다.

*로컬로 설치할경우 직접 nodemon 에 접근할 수 없다. npx 를 사용해주어야한다. 

 


 

2. ts-node 설치하기

npm install -D ts-node

 

ts-node 는 사전 컴파일 없이 즉시 typescript런타임 환경에서 실행시켜준다. 이 패키지를 사용해 컴파일 없이 서버를 띄울것이다.

 

* documentation - www.npmjs.com/package/ts-node


3. 스크립트 작성

build: 컴파일을 수행

start:  js 로 컴파일된 파일을 사용하여 서버 실행

dev:server: ts 파일만 사용해 서버를 실행

  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "build": "tsc",
    "start": "node ./dist/app.js",
    "dev:server": "nodemon --watch src --exec 'npx' 'ts-node' src/app.ts"
  },

* nodemon --watch <감시할 디렉터리> 

* npx ts-node <실행할 ts파일>


4. 명령어

ts 파일을 js 파일로 컴파일 작업 수행

npm run build

js 파일을 런타임에서 서버 시작

npm run start

ts 파일만을 가지고 런타임에서 서버 시작

npm run dev:server

 

'BACKEND > node.js' 카테고리의 다른 글

[node.js] dotenv 환경변수 관리하기  (0) 2021.04.25

프록시 서버  | Setting Up a Simple Proxy Server

Nginx의 또 다른 기능은 프록시 시버를 세팅하는 것이다. 클라이언트서버중계자 역활을 하는 서버를 프록시 서버라고 한다.

(정적 파일을 반환하는 web server 의 역할은 NGINX 정적(static)파일 연결하기 참조하면된다)

 

http {
    server {
        listen 8080;
        root Users/Documents/dev/server/;
        ...
    }
    
    server {
        listen 9000;
        
        location / {
            
            proxy_pass http://localhost:9000/;
            
        }
    }
}

event { }

 

원래라면 nginx 는 8080 포트로만 들어오는 요청만을 처리할 수 있겠지만,  proxy_pass 를 사용해 9000 포트를 설정해준다면 9000으로 요청이 들어와도 처리할 수 있다.

'WEB SERVER > nginx' 카테고리의 다른 글

1. NGINX 정적(static)파일 연결하기  (2) 2021.03.19
NGNIX 개념과 구성  (0) 2021.03.13

+ Recent posts