지난 coolify 관련 글은 로컬서버에 설치하는 방법이었다. https://blog.1day1.org/717

coolify 는 로컬서버 뿐 아니라, 원격지 서버를 등록해서 앱을 배포해서 사용할 수 있다.
서버 사양을 분산하거나, 프로젝트별로 분리해서 관리하는 등 여러가지 이유로 원격서버에 설치할 필요가 생긴다.
서버는 여러개가 될 수 있지만, 전체를 coolify 에서 통합관리하기에 불편하지는 않다.

원격서버는 클라우드 서버일 수도 있고, 리얼서버일 수도 있다. 인터넷 접속할 수 있다면 모두 등록 가능하다.
원격서버 등록은 크게 어렵지는 않다. 단, 원격접속 설정 한가지만 사전 등록해준다.

coolify 가 원격서버에 접속할 수 있도록 ssh key 등록을 해준다.(아래 이미지의 localhost's key )

ssh key 를 원격지서버에 등록해준다.

어떤 key 를 등록해줘야 하는가? (publick key 등록)

coolify 의 Keys & tokens 메뉴에서 아래 이미지의 표시한 부분에서 Public Key 를 복사한다.(아래는 일부지만, 전체를 복사)

원격지 서버에 접속해서 .ssh/authorized_keys 에 해당 Public Key를 입력해준다.

형식은 아래와 비슷한데, 맨끝의 coolify 는 구분용으로 임의로 입력한 값이다.

# cat .ssh/authorized_keys
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5A-퍼블릭키값-NDZbYm-전체-AuLg3 coolify

사전 준비는 끝. (coolify => remote 접속이 가능하면 OK)

주의!!

다음 진행하기 전에 원격서버가
웹(80/443 포트)서버로 이미 사용중이라면 정상설치가 안될 수 있다.

원격 서버에 도커엔진 설치하기

위 Validate Server & Install Docker Engine 버튼을 클릭하면,
서버에 접속가능한지 체크하고, 필요한 도커관련 설치를 한다.

특별한 이상이 없다면, 위처럼 단계가 처리된다.

원격 서버를 등록한 후에는 coolify 앱 등록 / 배포등을 진행하면 된다.

Products => Resources => (앱 또는 서비스) => [서버선택시 등록한 원격 서버 선택] => Configuration => Deploy

위와 같은 단계로 진행하는데, 중간단계에 설치/배포할 서버를 원격지 서버로 선택하면 된다.

[활용방안]

이 작업을 하는 이유는 기존의 단독으로 운영되는 스프링프로젝트 서버가 있다.
접속이 많을 때 서버가 다운되는 현상이 있어서 어떻게 조치할 까 생각중인데, 스프링앱을 일부 분리해서 도커에 올려 부하 분산을 할려고 구상중이다. 접속이 많은 현상이 항상 그런 것이 아니라, 간헐적으로 나타나기 때문에 앱을 신규 등록 했다가 다시 삭제 하는 형태로 유동적으로 운영할려고 한다.

[추가]

혹시 위 원격서버 등록시 다음과 비슷한 에러를 만난 경우

기존에 nginx 로 80/443 포트를 사용하던 원격서버에 세팅하는 경우 위와 같은 에러를 만나게 된다.
관련 조치는 nginx 설정을 다른포트(8080/8443 등)로 바꾸고 coolify 쪽에서 proxy 설정을 연동해줘야한다.
즉, coolify 가 80 / 443 포트를 컨트롤 하도록 해줘야 한다. 이 부분은 별도로 포스팅 하도록 하겠다.

지난글에 nestJS 앱을 dockerfile 을 사용해서 배포하는 방법을 정리했다. https://blog.1day1.org/719

그런데, dockerfile 내에서 git clone 으로 소스를 가져와서 하는 방법이다보니, github webhook 를 처리하기 어려운 부분이 있다.

그래서 coolify 에서 github app 을 세팅해서 사용하는 방법을 사용하기로 한다.

# coolify 프로젝트 ( + New Resource )

with GitHub App 으로 선택한다.

처음에는 +Add GitHub App 으로 앱등록을 해준다.(해당 방법은 아래에 따로 설명)

등록된 앱을 선택하고, Load Repository 를 하고, Build Pack 을 Dockerfile 으로 선택하고 다음으로 넘어간다.

기존에 봤던 설정화면 - 본인에 맞는 입력사항을 입력하고 Save

이전 글의 Dockerfile 이 차이가 있는데,
그 부분은 아래 깃허브 앱 등록 부분을 정리 후에 마지막에 설명한다.

# GitHub App 등록

Create a new Application 에서 +Add GitHub App 를 클릭하거나,
Coolify 좌측메뉴의 Sources 메뉴를 들어간다.(+Add)

적당한 이름을 입력하고, Continue ..

Webhook Endpoint 부분에 github 쪽에서 접근가능한 URL 을 선택하고, Regiser Now

깃허브로 이동한다. ( 앱을 생성하는 절차 )

다시 coolify 로 이동해서, Install Repositories on GitHub  를 클릭한다.(세부 정보 입력으로 이동)

그러면 다시 깃허브로 이동해서 세부적인 설정을 하게 된다.

본인 깃허브 계정의 전체 저장소 또는 프로젝트를 선택할 수 있다. (Install 으로 Github App 을 생성한다.)

다시 coolify 로 이동하면, 설정된 앱을 확인할 수 있다.(아래에서 따로 추가 설정할 것은 없고, 완료 화면)

해당 App 등록이 완료되면,  초기에 Create a new Application 부분에 해당 앱이 나오게 된다(선택하여 다음 진행)

# Dockerfile 설정.(깃허브 프로젝트 소스내에 포함)

예전 글(https://blog.1day1.org/719)에는 Dockerfile 내에 git clone 으로 소스 다운로드하는 형태였는데,
Github App 연동 방식은 저장소를 연결해서 소스에 접근할 수 있어, 다운로드 단계를 제거 한다.

# 빌드 스테이지
FROM node:22 AS builder

# 작업 디렉토리 설정
WORKDIR /usr/src/app

# pnpm 설치
RUN npm install -g pnpm

# 모든 소스 파일 복사
COPY . .

# 의존성 설치
RUN pnpm install

# 앱 빌드
RUN pnpm run build


# 프로덕션 스테이지
FROM node:22-slim

# 작업 디렉토리 설정
WORKDIR /app

# pnpm 설치
RUN npm install -g pnpm

# 빌드 스테이지에서 필요한 파일들만 복사
COPY --from=builder /usr/src/app/package*.json ./
COPY --from=builder /usr/src/app/pnpm-lock.yaml ./
COPY --from=builder /usr/src/app/dist ./dist

# 프로덕션 의존성만 설치
RUN pnpm install --prod


# 프로덕션 모드로 실행
CMD ["pnpm", "run", "start:prod"]

# 포트 설정 (NestJS 기본 포트는 3000)
EXPOSE 3000

도커의 이미지 빌드시 두단계를 거치도록 분리했다. (multi-stage 빌드 라고 하는 듯 하다.)

빌드 단계 + 프로덕션 단계.  코드가 복잡하지는 않아 쭈욱 한번 보면 파악이 될 것이다.

깃허브 webhook 설정해서 git push 하면 자동으로 배포하게 되도록 설정한다.
일단 여기까지... webhoook 설정은 다음에...

Github App 방식으로 하니, 따로 webhook 설정 안해도 되네. 패스... 끝.

coolify 를 써보다 보니 재밌다.

처음이라 좀 헤맨 부분이 있지만 ... 익숙해지면 정말 편해질 것 같다

세팅하려는 대략적인 흐름도는 아래와 같다

# Docker - nestJS 부분

projects 메뉴에서 새프로젝트를 만들어 준다.

적당한 이름을 입력하고, continue ( New Resource )

여러 방법이 있지만, Dockerfile 방법으로 하도록 한다.

중간 부분의 git clone 본인의 프로젝트소스를 가져오도록 한다.

# 베이스 이미지로 Node.js 사용
FROM node:22

# 작업 디렉토리 설정
WORKDIR /usr/src/app

# git clone
RUN apt-get update && apt-get install -y git

RUN git clone https://github.com/your-account/nestjs-practice-netflix .

# pnpm 설치
RUN npm install -g pnpm

# 의존성 설치
RUN pnpm install

# 앱 빌드
RUN pnpm run build

# 프로덕션 모드로 실행
CMD ["pnpm", "run", "start:prod"]

# 포트 설정 (NestJS 기본 포트는 3000)
EXPOSE 3000

프로젝트에 접속할 주소를 적절하게 적어준다.

저장(Save) 한 후 deploy 하면 도커이미지를 만들어주고, 앱이 실행된다.

# 디비 postgres 부분

내가 테스트 한 프로젝트는 postgres 를 사용하기에 DB도 세팅해준다.

프로젝트에서 ( New Resource ) 로

PostgreSQL 을 선택해준다.

PostgreSQL 16 을 선택해줬다.

세팅에 암호를 정해준다.

중간 부분의 Postgres URL (internal) 으로 접속할 것이니, 해당 값을 nestjs 에서 사용할 것이다.
DB 를 Start 해준다.

그리고, 다시 nestJS 설정으로 와서.

위 처럼 설정값을 적어준다.
(DB_HOST 부분의 값이 - Postgres URL (internal) 에 있던 주소)

프로젝트에 따라 저 환경변수 값이 다를 수 있으니, 본인의 프로젝트에 맞게 수정해준다.

프로젝트를 Deploy 한다. 이미 프로젝트를 Deploy 했다면, Restart 해주면 입력한 설정값이 적용된다.

이제 프로젝트가 동작하는지 확인해본다. (정상적으로 응답된다)

아마도 다음 단계는 프로젝트 수정하고 git push 하면
자동으로 coolify 에서 자동 빌드 + 재배포 하는 프로세스를 만들어 봐야 겠다.

도커는 주로 우분투(리눅스)에서 사용하고 있다. 그래야 제대로된 성능이 나오기 때문이다.

그런데, 개발/테스트 등을 위해 맥os 에서 사용하고자 한다.

설치는 쉽다. https://www.docker.com/products/docker-desktop 에서 다운로드 후 설치하면 된다.

도커를 실행하면, 로그인은 꼭 필수는 아니다.(본인의 도커 이미지등을 docker hub에 등록하고자 하면 필요)
그냥 로컬에서 실행/테스트 할때는 굳이 필요없다.

끝.

도커를 연습해 보고자 한다면, https://docs.docker.com/get-started/ 를 참조한다.

도커 데스크탑 이 쿠버네티스도 지원하는 듯 하다. 설정을 해봤다. 쓸만한 지는 체크해봐야겠다.

간단한 golang 어플을 도커 이미지를 사용해서 배포하려 한다.(배포는 kubernetes 를 사용한다)

docker hub 등 온라인 방식으로 해도 되지만, microk8s 의 registry 서비스를 이용한다.
방법은 그리 어렵지 않다.  https://microk8s.io/docs/registry-built-in 를 참조 한다.

일종의 registry 서비스를 로컬에 가동하여 도커 이미지를 등록 하는 것이다.

1. 이미지 빌드

$ sudo docker build . -t localhost:32000/prod-api:registry

Sending build context to Docker daemon  4.608kB
Step 1/6 : FROM golang:latest
latest: Pulling from library/golang
dc65f448a2e2: Pull complete 
346ffb2b67d7: Pull complete 
dea4ecac934f: Pull complete 
8ac92ddf84b3: Pull complete 
7ca605383307: Pull complete 
f47e6cebc512: Pull complete 
530350156010: Pull complete 
Digest: sha256:fe6b1742d48c4d6d360c6fac1e289e8529aaab924fa0e49a330868be50c0f2f4
Status: Downloaded newer image for golang:latest
 ---> 297e5bf50f50
Step 2/6 : RUN mkdir /app
 ---> Running in 2a6795d86353
Removing intermediate container 2a6795d86353
 ---> 541dbb10344e
Step 3/6 : ADD . /app/
 ---> c60e6e741cb4
Step 4/6 : WORKDIR /app
 ---> Running in 5de0b590c65d
Removing intermediate container 5de0b590c65d
 ---> 24c7788d1b8e
Step 5/6 : RUN go build -o main .
 ---> Running in 5e44a7f53909
Removing intermediate container 5e44a7f53909
 ---> 56462a496eac
Step 6/6 : CMD ["/app/main"]
 ---> Running in bdde4584ff89
Removing intermediate container bdde4584ff89
 ---> dbba71be4f83
Successfully built dbba71be4f83
Successfully tagged localhost:32000/prod-api:registry

등록체크 

$ sudo docker images

REPOSITORY                 TAG                 IMAGE ID            CREATED             SIZE
localhost:32000/prod-api   registry            dbba71be4f83        5 minutes ago       810MB

2. 이미지 registry 등록

$ sudo docker push localhost:32000/prod-api

The push refers to repository [localhost:32000/prod-api]
44006ff06569: Pushed 
203febf79d4f: Pushed 
2ec821486852: Pushed 
cae11887bc90: Pushed 
729c3ac48990: Pushed 
8378cd889737: Pushed 
5c813a85f7f0: Pushed 
bdca38f94ff0: Pushed 
faac394a1ad3: Pushed 
ce8168f12337: Pushed 
registry: digest: sha256:7c8fe99287f680f23e611c4113834c5c8343aa102a49a3584a65888205604609 size: 2420

3. kubernetes 로 배포

배포코드는 https://github.com/yusufkaratoprak/kubernetes-gosample 를 참조

$ vi config/deploy.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: prod-api-dep
spec:
  replicas: 1
  selector:
    matchLabels:
      app: prod-api
  template:
    metadata:
      name: prod-api
      labels:
        app: prod-api
    spec:
      containers:
      - name: prod-api-dep
        image: localhost:32000/prod-api:registry
        ports:
        - containerPort: 8090

$ vi config/service.yaml

apiVersion: v1
kind: Service
metadata:
  name: prod-api-service
spec:
  selector:
    app: prod-api
  ports:
    - name: http
      protocol: TCP
      port: 8070
      targetPort: 8090
  externalIPs:
    - 192.168.0.111

배포/가동 : kubectl apply -f config/

$ curl 192.168.0.111:8070  으로 체크

추후 LoadBalance 로 설정 - golang 파드는  replicas 로 여러대로 동작

btrfs 를 쓰고 있는데, 뭔가 이상하다.

내가 잘못 쓰고 있는 것인지?

오늘 생긴일은 다음과 같다.

40G 정도 되는 파일을 원격지에서 전송받는 것이었다.

btrfs 를 쓰고있는 파티션이 80G 정도 남아있어서 괜찮겠다 싶어 전송하였다.

그런데, 30기가 정도 받고 나니 시스템이 다운된다.

이유가 뭘까?

혹시나 네트웍디바이스가 무리가 간것인가 다시 해봐도 동일현상.

그냥 ext4 의 다른 파티션으로 해보니 정상적이다.

btrfs 의 뭔가 특성이 있는 것인가?

커널로그를 살펴봤다.

다음과 같은 메시지가 눈에 띈다.

df 로 확인한 용량과 BTRFS 의 용량계산은 차이가 있는 것인가?

아직 잘 모르겠다.

docker 쪽이 btrfs 를 쓰는듯 한데, 특성을 찾아봐야 겠다.

요즘 서버 자동화에 대한 구상을 하고 있다.

여러가지 방법이 있어 상황에 맞는 좋은 방법을 찾고 있다.

docker / vagrant / chef / puppet 등을 체크하고 있다.

관리해야 하는 서버가 수십대 규모에서 수백대 규모로 넘어가는 상황에서는 수작업/스크립트 만으로는 처리가 어렵다. 미리 미리 체크해서 상황이 발생했을 때 빠른 대처를 할 생각이다.

# digital ocean 의 서비스를 활용.

서비스쪽에서는 amazon 이 최고이긴 하지만, 비용문제가 있다. 계산법 복잡한 부분도 있다.
설정 부분도 그렇고, 초보가 접근하기에는 좀 부담스럽다.

디지털오션은 그 부분에서 간략화되어 있다는 느낌이다.

디지털오션 서비스를 체험하려면 관련글을 참조(2개월무료사용글 => http://blog.1day1.org/498 )

droplet 까지 생성을 해봤다면 다음으로 넘어가보자.

미리 세팅한(OS + your service app) droplet 를 스냅샷(snapshot)으로 만들 수 있다.

기본으로는 해당 지역(San Francisco) 에 생성이 되는데, 다른 지역에도 같은 이미지를 배포하고 싶으면 다른 지역으로 전송할 수 있다. 전송하는 시간이 좀 길다. 20G 정도 밖에 안되는데, 꽤 오랜 시간이 걸린다.
미리 미리 타지역으로 배포를 해놓는 것이 좋다.( 이 시간 때문에 다른 서비스도 고려중이다)

일단 스냅샷을 만든후

# droplet 을 저장이미지를 사용해본다.

  지역을 선택하고 My Images 에 저장된 이미지가 보인다. 그것을 선택한다.
  SSH Key 도 미리 등록해 놓으면 로그인도 바로 할 수 있으니 편하다.

기존에 droplet 생성 -> 서비스 app 세팅 하는데, 스크립트를 이용해서 보통 20~30 / 테스트까지 하면 1시간정도 필요했었다. 그런데, 이미지를 이용하면 거의 5분이내로 서비스 가동이 완료된다. 무지 편해졌다.
서비스 배포 시간을 줄이며 그 만큼 빠른 대응을 할 수 있다.

디지털오션쪽에서는 API 도 제공하기 때문에 위 시간에서 더 줄일 수 있을 듯 하다.
(https://developers.digitalocean.com)

내가 한 방법이 최상이라고는 할 수 없다. 서비스 앱의 종류 / 복잡도에 따라 또 달라질 수 있다.

설정등이 서버마다 바뀌거나, 복잡한 부분은 chef 나 puppet 등을 사용해야 할 것이다.

처음에는 간단한 것부터 조금씩 복잡한 부분에 대한 자동화시스템을 구축해볼 예정이다.

우분투 14.04 시스템에 btrfs 를 사용하고 있다.

SSD raid 에 LVM 으로 나눠서 쓰고 있다. 일반적인 사용형태보다는 좀 복잡할 것이다.
(물론 아주 특이한 케이스는 아니다)

docker 를 테스트 하던 중.

docker pull 로  이미지 몇개 설치하지 않았는데, 디스크가 꽉차는 현상이 발생했다.
크롬이 비정상 종료되길래 왜 그러지 싶었다. 그냥 아무 생각없이 재부팅하니. 정상부팅되지 않았다.

순간 멘붕.

허걱! 다시 OS를 깔아야 하나. 데이터 만이라도 살려야 하는데.
중요데이터는 Dropbox 로 동기화 하고 있으니 별 상관은 없지만, 또 세팅을 다시하려니 힘이 쭉.

single 모드로 다시 부팅을 해보고 점검을 해봤다.

주요 메시지는

이런식의 메시지가 계속 무한루프 된다. 위 메시지를 검색 해봤는데, 별다른 원인을 못찾겠다.

docker 를 테스트 하던중 용량 관련 메시지 No space left on device  => 디스크 full 일때 나오는 익숙한(?) 메시지
를 봤었다. 그것과 관련이 있을 것 같다.

그러나 시스템 용량은 충분했다. 어떤 다른 이유인것 같다.

docker pull dockerfile/mongodb

등의 명령을 내리면, 이미지를 다운로드하고 컨테이너를 생성한다.

이때 docker 는 btrfs 인 경우 subvolume (스냅샷?) 기능 을 이용하는 것 같다.

/var/lib/docker/btrfs/subvolumes 에 생성이 된다.

을 해보면 아무것도 없어야 한다. 그런데, docker pull 후에 다시 명령을 해보면.

위 처럼 많은 subvolume 이 생성된 것을 볼 수 있다.
ID 값이 동일한 것(진한부분)을 보니 ID 당 서브볼륨을 생성해서 관리하나 보다.

파일용량을 체크해보면 다음과 같다.

서브볼륨은 어느 부분에 영향을 주는지 확인해봐야 겠다.

아무튼.

명령으로 docker 이미지를 삭제하면 해당 subvolume 도 삭제된다.

개별적으로 subvolume 을 삭제하려면

으로 삭제해준다.( 부팅이 안되서 usb 우분투 로 부팅하고, 해당 서브볼륨을 위 처럼 하나씩 삭제해줬다)

btrfs 에 좀더 알기전까지는 조심해야 겠다.

다음부터 docker 는 vagrant 기반의 vm 내에서 테스트 해봐야 겠다.

docker 를 어떻게 하면 잘 활용할 수 있을까?

여러가지 방향을 생각해본다.

vagrant 와는 다르게 linux 전용이라 구성에 제약이 따른다.

1. 최대의 성능.

  [필요사항] 배포용 머신이 팀 또는 개인이 보유하고 있어야 한다.

  [장점] linux 머신에 docker 를 바로 세팅해서 최대 성능을 낸다.
  [단점] 리눅스 환경의 개발PC 가 아니면 원격으로 접속해서 개발해야 한다.

2. 관리의 편의.

  [장점] 개발PC 의 OS 에 상관없이 개발환경을 세팅가능하다.(win / mac)
  [단점] vagrant(vm) 을 활용하기 때문에 성능저하가 있다.

# 개발이 완료된 후 서비스용 설정

기본 구성은 다음과 같이 하려 한다.

서비스서버 를 AWS / DigitalOcean / GoogleCloud 등의 가상서버로 세팅해도 되고, 서버호스팅의 리얼서버를 이용해도 된다.

클라우드는 성능저하가 있겠지만, 빠른배포 와 편의성을 잘 따져보고 결정하면 되겠다.

충분한 테스트를 해보고 결정하는 것이 좋겠다.

디지털오션쪽에 2개월정도 무료사용가능하니 먼저 테스트해봐야 겠다.
(512M 짜리 * 2개 => 1개월 , 4개 => 2주? , 8개 => 1주일정도? )

(무료 사용은 => 링크 참조)

테스트 해보고 사용해도 되겠다 판단이 되면, Core 를 늘려서 서비스용으로 활용해도 되겠다.

# 서비스 시나리오.

서비스용으로 10대의 클라우드 서버에 배포하는 시나리오를 만들고 테스트 해봐야 겠다.

그러고 보니 docker 모니터링툴도 필요하겠다. (관련 자료도 찾아봐야 겠네)

자동화에 필요한 사항은 다양한 시나리오 사례가 만들어지면, 재미있을 것 같다.

docker 를 우분투에 설치해봤다. 이제 기본 컨테이너 환경을 구성해보자.

- Centos 를 테스트로 구성해본다.

를 해보면, centos 관련 저장소에 있는 이미지들의 리스트를 보여준다.(무지 많다.)

- 아래 처럼 리스트가 많이 나온다. (docker hub 에 등록된 이미지 인듯함)

- 맨 위의 공식 이미지로 해보자.

- 다음처럼 이미지를 다운받는 화면을 볼 수 있다.

- 완료가 되면 docker 컨테이너 환경으로 들어가 본다.

기본 호스트로 사용하고 있는 구조와 다르다. ubuntu 안에 centos 의 가상환경을 만들어 준것이다.

- 설치된 이미지를 확인해본다.

다음 처럼 로컬에 설치한 이미지들을 볼 수 있다.

참조 : http://blog.nacyot.com/articles/2014-01-27-easy-deploy-with-docker/

docker 를 설치해본다.

우분투 14.04 에서는 간편하다. 이미 우분투 공식패키지로 등록이 되어 있다.

그러나 공식패키지는 버전업이 느리다.

# docker.io --version

빠르게 버전업하는 패키지는 공식사이트의 배포버전을 사용하면 좋다.

한번에 끝내기

위 스크립트를 받아서 실행하는 방법이다.

최신버전으로 설치된다.

간단한 테스트.

다음과 같은 명령을 내리면.. 로컬이미지를 찾고,
없으면 저장소에서 찾아서 설치한 후 echo 'Hello World' 를 실행하게 된다.

하위 버전은 다음을 참조.

http://docs.docker.io.s3-website-us-west-2.amazonaws.com/installation/ubuntulinux/