docker

# 각 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_..

도커 컴포즈는 오케스트레이션 명령 set으로, docker build와 docker run을 대체할 수 있다. docker compose 명령을 사용하여 모든 것을 시작하고 중단할 수 있다. 도커 컴포즈를 사용하면 공유 가능한 config 파일을 가지게 되는 것이다. 도커 컴포즈는 Dockerfile을 대체하지 않는다. 도커 컴포즈는 다수의 호스트에서 다중 컨테이너를 관리하기에는 부적합하다. 도커 컴포즈는 하나의 호스트에서 다중 컨테이너를 관리할 때 편하다. 터미널에서 Docker 명령을 써야하는 거의 모든 것을 컴포즈에서 할 수 있다.

www 통신 기본적으로 컨테이너는 www에 요청을 보낼 수 있다. 도커화된 애플리케이션 내부에서 웹 API 및 웹 페이지와 통신 가능하다. 도커화된 애플리케이션 내부에서 http에 요청을 보낼 수 있다. 컨테이너와 로컬 호스트와의 통신 특수 도메인 host.docker.internal 을 사용해야 하며, 이 도메인은 도커에 의해 인식된다. // mongodb type 'mongodb://host.docker.internal:27017' // http type 로컬호스트에 웹서버가 있고 그것과 통신할 때 'http://host.docker.internal:27017' 도커 컨테이너 내부에서 알 수 있는 호스트 머신의 IP로 변환된다. 도메인이 필요한 곳, IP가 필요한 곳 모두 사용 가능하다. 특수 도메인..

Environment(Runtime) Dockerfile 내에서 혹은 어플리케이션 코드에서 접근 가능 Dockerfile에 ENV로 환경 변수를 설정하면 $를 이용해 변수임을 알려 사용할 수 있다. Dockerfile에서 PORT를 환경 변수로 등록해주었으므로 PORT 번호를 받아와 위와 같이 js 파일에서 사용할 수 있다. --env PORT=8000을 이용해 Dockerfile에서 직접 포트를 변경하지 않고 컨테이너를 실행하면서 포트를 변경할 수 있다. 내부 포트를 8000으로 변경시킨다는 의미이다. 환경변수 파일을 만들 수도 있다. .env 파일에 사용할 환경변수 값을 집어넣은 후 RUN 명령시 --env-file의 옵션값으로 .env 파일을 준다. Argument(build-time) Docker..

dockerfile에서 COPY 할 때 .dockerignore 파일을 이용해 COPY하지 않을 파일 및 폴더를 지정할 수 있다. gitignore와 비슷하게 사용하면 된다. 파일명은 반드시 .dockerignore로 지정해야 한다. 현재 node_modules를 COPY하지 않도록 지정한 것이다. Dockerfile .git 보통 Dockerfile과 .git 폴더가 올라가지 않도록 설정해준다. 올라갈 필요가 없으므로.