코딩애플 도커 Docker & Container

26.04.20

성능을 위한 Dockerfile 작성법

 

좋은 관습 1. 캐싱

 

Dockerfile 작성시 "빌드할 때마다 변동사항이 많이 생기는 부분들을 최대한 아래 쪽에 적기"입니다.

그럼 build 시간이 단축될 수 있습니다.

 

빌드 작업할때 COPY, RUN 같은 명령어를 실행하면

도커가 내부적으로 캐싱을 진행함

- 변동사항이 없는건 캐싱으로 사용하고,

- 변동사항이 있는건 캐싱사용 안함

- 그래서 변동사항 있는것들은 아래에 적으면 빨라짐

 

 

 

좋은 관습 2. npm ci

 

RUN ["npm" "install"] 보다 

RUN["npm" "ci"]가 좋다 

ci = clean install

packge.json에 ^4.1.0 버전이 이렇게 정규표현식으로 적힌경우

새로운 버전이 나왔을때 나도 모르게 4.2.0으로 설치될 수 있는데,

ci를 하면 package-lock.json에 있는 버전 그대로 유지 가능

 

 

 

좋은 관습 3. ENV

 

ENV NODE_ENV=production
CMD 어쩌구~

 

ENV 라는 명령어를 쓰면 환경변수를 집어넣어서 이미지를 빌드할 수 있습니다. 

ENV 환경변수이름=값 사용하면 됩니다.

 

이런걸 왜 쓰냐면 옛날부터 존재하던 express 같은 라이브러리들은

NODE_ENV=production을 집어넣어놔야 로그출력양을 좀 줄이고 그래서 성능이 향상되고 그런 케이스가 있습니다.

그래서 Node.js 개발시 설정해두면 나쁠건 없습니다.

참고로 docker run할 때도 -e 옵션으로 환경변수를 그때그때 집어넣어서 이미지를 실행할 수 있습니다.

 

 

좋은 관습 4. 권한 낮추기

 

 

보안적으로 더 나은 습관도 있는데

원래 Dockerfile에 적은 명령어들은 전부 root 권한으로 실행됩니다.

마지막에 서버 띄우는 명령어는 root 말고 권한을 좀 낮춰서 실행하는게 약간 더 안전하고 좋습니다.

그럴려면 유저를 하나 생성하고 그걸로 유저를 바꿔서 실행하라고 코드짜면 되는데

근데 node 공식 이미지의 경우엔 node라는 이름의 유저가 이미 만들어져있습니다. 

그래서 그거 써도 되겠습니다.

 

(Dockerfile)

USER node
CMD 어쩌구~

USER 유저이름 적으면 그 유저로 변경됩니다.

유저가 제공되지 않는 이미지는 직접 유저만드는 명령어 찾아서 씁시다.

 

 

 

 

 

multi-stage build

 

FROM amazoncorretto:21.0.4 AS build
WORKDIR /app
COPY . .
RUN ./gradlew build

# Runtime stage
FROM amazoncorretto:21.0.4 AS runtime
WORKDIR /app
COPY --from=build /app/build/libs/*.jar /app/server.jar
CMD ["java", "-jar", "/app/server.jar"] 

실은 Dockerfile에 FROM을 2번 이상 작성할 수 있는데

FROM을 만날 때 마다 위에 있는 작업내역들이 삭제되고 새로운 마음으로 깨끗하게 시작됩니다.

근데 깨끗하게 시작할 때 위의 작업내역에서 만든 파일들을 몰래 훔쳐올 수 있습니다.

이게 비결임

 

 

26.04.22

Network 2. 컨테이너간 통신

 

1. nginx 리버스 프록시 쓰면 장점이 많음

2. 네트워크 안에 컨테이너 넣으면 서로 통신 가능

 

 

 

26.04.24

Volume 사용법과 PostgreSQL DB 띄우기

 

컨테이너는 중지되거나 삭제되면 DB 데이터가 유실될가능성있기 때문에

volume을 사용하면 영구저장이 가능하다

근데 보통 db를 컨테이너로 만들일이 없고(컨테이너는 껐다 켰다 유용하게하는데 보통 db는 계속 켜져있어야되니까)

웹서버는 영구적으로 저장되어야할일이 없으니

db를 컨테이너로 만든다면 고려해보자

 

 

26.05.06

Orchestration 1. 태스크, 서비스, 클러스터 개념정리

 

마이크로서비스아키텍처의 장점

1. 유저가 많이 몰리는 서비스가 있으면 그거만 확장 가능

자원 사용이 효율적이다

2. 회원기능을 수정했으면 회원기능 서비스만 따로 배포하면 되니까 기능 업데이트도 빨라짐

 

단점

1. 마이크로 서비스끼리 통신해야하면 그게 귀찮아짐

2. 마이크로 서비스가 많아지면 그걸 관리하는데 시간과 인력이 추가로 필요함

3. 서버비도 초반에 비쌈

 

 

 

26.05.08

Orchestration 1. 태스크, 서비스, 클러스터 개념정리

 

클러스터는 하나의 프로젝트

서비스는 하나의 마이크로서비스

태스크는 서로 붙어있어야할 컨테이너들을 묶는 단위

태스크를 docker compose라고 이해해도될듯하다

 

 

 

Orchestration 3. 서비스 만들기

 

배포옵션

롤링 업데이트

새 태스크 띄우고 기존 태스크 하나씩 없애기

 

블루/그린 배포

새 태스트 띄우고 기존 트래픽 전부 새 태스크로 이동