주간 devtips 1

junto·2024년 6월 2일

목록 보기

1/5

1. 깃랩 다시 설치할 경우 만날 수 있는 에러

1) error=chdir /home/gitlab-runner: no such file or directory

home/gitlab-runner 가 생기지 않음 → 폴더 생성 및 권한 부여

sudo mkdir -p /home/gitlab-runner
sudo chown gitlab-runner:gitlab-runner /home/gitlab-runner

2) new runner has not connected yet

sudo gitlab-runner register 를 통해 러너를 등록했음에도 자동으로 연결이 되지 않을 때

먼저, 기존 러너 캐시와 충돌이 날 수 있으므로 Settings - CI/CD - runners 에서 러너 캐시를 초기화하자. 다음 아래 명령어를 실행한다.

sudo gitlab-runner verify

그럼 바로 runner가 active된다!

2. node build할 때 out of memory

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory

빌드 서버에서 프론트 next.js 빌드할 때 생긴 에러이다.
빌드 서버는 aws-freetier로 메모리 1기가, 스왑 메모리 4기가를 설정한 상태이다.
더 좋은 서버를 구매하는 건 너무나도 당연한 해결책이니 넘어가자.

1) 빌드 서버 힙 메모리 늘리기

아래 명령어로 현재 사용중인 힙 메모리 제한을 확인할 수 있다.

node -e 'console.log(v8.getHeapStatistics().heap_size_limit/(1024*1024))'

// 486.75 약 486MB

아래 명령어로 조금씩 힙 메모리를 늘릴 수 있다. 꼭 1024의 배수를 사용해야 하는 건 아니라고 한다.

export NODE_OPTIONS="--max-old-space-size=3500"

위와 같이 평상 시 사용중인 메모리를 고려해 최대한 늘려봤지만 여전히 힙 메모리가 부족하다. 어떻게 해결할 수 있을까?

2) 로컬에서 빌드하고, 빌드한 결과 깃으로 올려주기

로컬 컴퓨터에서 빌드하고, 빌드 결과물을 깃에 올려주면 빌드 서버에서는 단순히 빌드 결과물을 배포 서버에 옮겨주기만 하면 된다. 해당 작업은 깃랩 파이프라인으로 진행되기 때문에 어느 정도의 자동화는 보장된다.

3) 웹팩 적용하기

웹팩이 뭐지 해서 찾아봤더니, 여러 파일을 하나로 압축하는 등의 작업을 하면 서버에서 빌드할 때 메모리를 절약할 수 있다.

일반적으로 프론트개발자가 웹팩을 해서 최적화를 한다고 한다. 다음날 보니 프론트분이 웹팩을 적용해서 서버에서 힙 메모리 초과로 실패하던게 동작한다!!

3. Nginx, Spring app을 각각 도커로 실행할 때 Nginx에서 reverse proxy를 사용하는 경우

당연하게도 도커 컨테이너는 자원이 격리화되어 있기 때문에 Nginx에서 proxy_pass를 한다고 해서 다른 컨테이너에서 이를 알 수 없다!
도커 네트워크를 사용하여 둘을 같은 네트워크로 묶어준다.
docker-compose를 사용해서 네트워크를 묶어줄 수도 있지만, Nginx와 Spring app은 생명주기가 다르기에 분리한다. spring app은 nginx보다 더 자주 변경되고 gitlab-pipeline에 따라서 새롭게 배포가 되기 때문이다.

// Nginx Makefile

all:
	build

build:
	docker build -t my-nginx:1.25.5 .

run:
	docker run -d -p 80:80 -p 443:443 --name nginx-1 \
       	-v /home/elice/nginx/html:/home/html \
       	-v /etc/letsencrypt:/etc/letsencrypt \
	--network elice \
	my-nginx:1.25.5
	
restart:
	make rm
	make rmi
	make build
	make run

rm:
	docker rm -f nginx-1

rmi:
	docker rmi my-nginx:1.25.5

.phony: all build run rm rmi

default.conf에 변경이 있을 때마다 이를 수정하고, nginx를 restart할 수도 있다. 하지만, 도커 컨테이너에서 default.conf를 직접 수정하려면 curl, editor 같은 패키지를 설치해야 한다. 이는 보안상 좋지 않기에 다시 제거해야 하므로 해당 방식보다 이미지를 다시 빌드하는 방식을 선택했다.

도커 네트워크 추가

docker network create elice

docker network ls로 만들어진 네트워크를 확인해보면 bridge 방식으로 만들어진 걸 확인할 수 있다.

docker network는 여러 방식이 있고, bridge 방식은 같은 네트워크에 있는 컨테이너는 내부에 같은 Gateway를 공유하여 서로 통신할 수 있다.

docker inspect 로 어떤 게이트웨이를 지나고, 부여된 사설 네트워크를 확인할 수 있다.

"Networks": {
                "elice": {
                    "IPAMConfig": null,
                    "Links": null,
                    "Aliases": null,
                    "MacAddress": "02:42:ac:18:00:03",
                    "NetworkID": "6439216b333b04e7b53a9d7035c38d16de15c06b660d7b7465121e05796589cf",
                    "EndpointID": "c0f15df853b2584adb7077a56bd1935c7f11e7b33a64300200f81767bf09bdef",
                    "Gateway": "172.24.0.1",
                    "IPAddress": "172.24.0.3",
                    "IPPrefixLen": 16,

 "Networks": {
                "elice": {
                    "IPAMConfig": null,
                    "Links": null,
                    "Aliases": null,
                    "MacAddress": "02:42:ac:18:00:02",
                    "NetworkID": "6439216b333b04e7b53a9d7035c38d16de15c06b660d7b7465121e05796589cf",
                    "EndpointID": "1497bfe5bd6caa46a0d88e4744ead100729fdc299bf049220c5b429732395581",
                    "Gateway": "172.24.0.1",
                    "IPAddress": "172.24.0.2",
                    "IPPrefixLen": 16,
                    "IPv6Gateway": "",

추가로 포트매핑 정보도 알 수 있다.

 "Ports": {
                "8080/tcp": [
                    {
                        "HostIp": "0.0.0.0",
                        "HostPort": "8080"
                    },
                    {
                        "HostIp": "::",
                        "HostPort": "8080"
                    }
                ]
            },

Nginx default.conf

default.conf

// 기존
location /api {
    proxy_pass http://localhost:8080;
}

// 변경
location /api {
    proxy_pass http://spring-app:8080; 
    // 또는 위에서 확인한대로 도커 컨테이너가 사용중인 사설 네트워크를 입력해도 된다.
}

nginx설정을 위와 같이 변경할 경우 spring app이 같은 도커 네트워크에서 실행중이지 않다면 아래와 같은 에러가 발생한다.
```
nginx: [emerg] host not found in upstream "spring-app" in /etc/nginx/conf.d/default.conf:40
```
spring app을 juny-net 네트워크에서 먼저 실행해주면 nginx가 제대로 동작한다.