전체 글

Load Balancing(LB) 트래픽 분산 처리. 하나의 인터넷 서비스에 발생하는 트래픽이 많을 때 여러 대의 서버를 분산처리 하여 서버의 로드율 증가, 부하량, 속도저하 등을 고려하여 분산처리하는 방식 장점 고가의 서버로 확장하지 않고(Scale-up) 저렴한 비용으로 다수의 서버를 증설(Scale-out)하여 경제적으로 비용절감 1대의 서버에 장애가 발생해도 서비스 중단 없이 운영 가능 트래픽이 급증해도 서버 증설로 서비스 중단 없이 운영 가능 ALB(Application LoadBalancer) 7계층 LB Client IP와 서버 사이의 모든 트래픽은 LB와 통신한다. 보안그룹을 통한 보안이 가능하다. Client → LB의 접근 제한 가능 ALB의 IP 주소는 변동되기 때문에 Client에서..

WEB01, 02 Apache 2.4.X WAS01, 02 Tomcat 8.5.X DB01 MySQL 5.7.X 소스 설치 소스설치, 수동설치, 컴파일설치? Linux에서 소스를 직접 다운 받아 컴파일하여 설치하는 것 ↔ 패키지 설치(yum 또는 apt 설치) 패키지 설치는 간편하지만 불필요하게 설치되는 파일들이 있고 패키지 단위로 설치되어 관리가 어렵다. 소스 파일은 /usr/local/src에 보관하고 /usr/local/에 설치하는 것이 관례 소스 설치 순서 소스파일을 내려받고 ./configure로 설정하고 make로 컴파일하고 make install로 설치한다. configure: 소스파일에 대한 환경설정. 서버 환경에 맞춰 makefile을 생성 make: 컴파일 make install: 컴파..

EC2 구성 요구되는 구성 사항에 맞춰서 EC2를 설정한다. Bastion Host 보안그룹에서 먼저 하나 만들고, 내 IP에서 22번 포트로만 SSH 접속을 할 수 있게 인바운드 규칙을 설정했다. 아웃바운드는 아직 안 건드렸다. EC2를 생성하는데, public vpc로 설정해야 외부에서 접근이 가능하다. 외부 접근을 위해 퍼블릭 IP도 자동할당 해준다. 보안그룹은 아까 만든 걸로 설정했다. EC2에 접속 완료! EC2 - WEB01, WEB02, WAS01, WAS02, DB01 private subnet에 넣어주고 퍼블릭 IP는 비활성화 시킨다. 보안 그룹은 새로 생성한다. 보안그룹의 규칙은 소스로 bastion sg를 선택하여 bastion EC2를 통해서만 이 WEB01 EC2에 들어올 수 있도..

Well Architecture를 만들어봅시다 (๑•̀ㅂ•́)و✧ 필요한 요소 Internet gateway: VPC가 인터넷과 연결되기 위한 통로 NAT Gateway: private subnet의 인스턴스가 NAT Gateway를 통해서 외부 인터넷과 연결된다. 이 때 private 인스턴스의 사설 IP가 NAT Gateway의 EIP로 변경된다. 인터넷으로 나가는 통신만 가능하고 들어오는 통신은 불가하다. Public Subnet: Public 내에 있는 인스턴스는 외부에서 접근 가능하다. Private Subnet: Private 내에 있는 인스턴스는 외부에서 접근 불가능하다. Bastion Host: Private 인스턴스에 직접 접근할 수 없으므로 Bastion 호스트를 만들어 각 privat..

# 각 pod에 대한 사양 spec: # 중요. 컨테이너 지정. 여러개 지정 가능. 이름 지정 가능 containers: # 이름 임의로 작성 가능 - name: second-node # 사용할 이미지 image: summer99summer/kub-first-app:2 # 컨테이너가 실행 중인지 확인 livenessProbe: httpGet: path: / port: 8080 # 작업을 수행해야 하는 빈도 periodSeconds: 10 # 기다려야 하는 시간 initialDelaySeconds: 5 k8s에서 yaml 파일 작성 시 spec 아래 livenessProbe 속성을 주면 컨테이너가 실행 중인지 확인하고 아니라면 재시작 시킬 수 있다.

파일 이름은 아무거나 가능하다. # 사용할 버전 apiVersion: apps/v1 # 객체의 종류 kind: Deployment # 이름 같은 중요 데이터(객체 생성시에 정의해주어야 함) metadata: # 이름은 임의로 작성 가능 name: second-app-deployment # 레이블을 붙여 객체의 구별성 주기 labels: group: example # 중요. deployment에 대한 사양 spec: # 복제하여 생성할 pod갯수 replicas: 1 # deployment에서 관리할 pod를 정의 selector: # 관리할 pod의 label. 여러개 가능 # 설정한 label이 모두 맞아야 관리함. 하나라도 다르면 안 함 matchLabels: app: second-app tier: ..

명령적 방식(imperative)과 선언적 방식(declarative)으로 객체를 생성한다. 명령적 방식 imperative - kubectl 명령 사용 - 작업을 위해 개별적인 명령 실행 - docker run으로 모든 명령을 하는 것과 비슷함 선언적 방식 declarative - apply 명령을 사용하여 yaml로 작성한 설정(config) 파일을 읽어옴 - config 파일에 원하는 상태를 정의한다. - Docker Compose와 비슷하다. Pod 쿠버네티스와 상호작용 하는 가장 작은 단위 한 개 이상의 컨테이너를 보유하고 실행시킨다. 일반적으로 한 개를 가진다. 다른 pod들과 공유하는 공유 리소스를 가진다. (e.g. volume) 기본적인 내부 IP 주소를 가진다. localhost 주소를..

Kubernetes를 사용해야하는 이유 보안성과 환경 구성 문제 이전에, 수동 배포는 운영이 어렵다. 컨테이너 내부에서 문제가 발생하여 전체 컨테이너의 충돌이 발생하고 다운되어 교체가 필요할 수 있다. > 수동 배포에서는 충돌이 발생할 대마다 수동으로 모니터링하고 컨테이너도 수동으로 다시 시작시켜야 한다. > 애플리케이션이 크거나 중요할 경우 문제가 커질 수 있다. > 컨테이너 상태 확인과 재배포 필요 트래픽 급증에 따른 컨테이너 인스턴스의 증가가 필요할 수 있다. > 트래픽이 줄어들면 컨테이너의 감소도 필요하다. > 오토스케일링 필요 들어오는 트래픽에 대해서 실행 중인 컨테이너의 인스턴스에 균등한 분배가 필요하다. > 로드 밸런서 필요 특정 CSP(Cloud Service provider)사를 이용하여..

Dockerfile만 사용하기 바인드 마운팅을 이용해 로컬에 node 설치 없이 도커만 사용하여 간편하게 node를 사용할 수 있다. # Dockerfile FROM node:14-alpine WORKDIR /app # CMD [ "npm", "start" ] # ENTRYPOINT [ "npm" ] Dockerfile에 사용할 노드 버전과 work directory(WORKDIR)를 지정해주고 이미지를 빌드한다. # image build docker build -t node-util . # 바인드 마운팅 docker run -it -v 'C:\study\utility:/app' node-util npm init 현재 디렉토리를 노드 컨테이너와 바인드 마운팅하여 로컬에 npm init(npm 의존성 설치..

docker-compose 파일 파일 이름: docker-compose.yaml 작성 시 주의할 점 커맨드를 다르게 적으면 안 된다. 두 칸 공백을 주면 하위 요소로 들어가는 것이다. 들여쓰기를 이용해 각 명령의 수준(레벨)을 정한다. compose 파일 예시 version: "3.8" services: mongodb: image: 'mongo' volumes: - data:/data/db environment: MONGO_INITDB_ROOT_USERNAME: max MONGO_INITDB_ROOT_PASSWORD: secret backend: build: ./backend ports: - '80:80' volumes: - logs:/app/logs - ./backend:/app - /app/node_..