NCP (CentOS 7.8) 환경에서 프론트 배포하기

OROSY·2021년 10월 29일

Naver Cloud Platform Node centos deployment express

TIL

목록 보기

16/18

🚕 NCP 서버 환경에서 프론트 배포하기

오랜만의 블로그 포스팅으로 돌아왔습니다. 미친듯이 바쁘진 않았지만, 그래도 나름 프로젝트를 진행하느라 바빠서 포스팅을 못했네요. 특히, 이번 기업협업 동안 AWS가 아닌 새로운 배포 환경을 경험해볼 수 있었고 이에 대해서 글을 남겨보고 싶었습니다.

Git의 외부저장소도 GitHub이 아닌 GitLab을 사용했다는 것도 좋은 경험이었습니다. 그렇다면, Naver Cloud Platform에서의 배포는 어떻게 진행되었는지 알아보도록 하겠습니다. 추가적으로 말씀드리면, 백엔드 능력자인 준영님께서 서버 환경을 대부분 구축해주셔서 그 안에서 쉽게 작업할 수 있었다는 점 참고 부탁드립니다.

👨‍💻 서버 컴퓨터엔 아무것도 없다.

실제로 1차 프로젝트를 진행할 당시 AWS EC2로 우분투 서버를 열고, 프론트엔드의 어플리케이션을 배포한 경험이 있습니다. 굉장히 바쁜 프로젝트 시간동안 강의를 보면서 코드를 따라쳤던 경험이었기 때문에 실제로 어떠한 방식으로 서버를 만들고 배포가 진행되는지 제대로 이해할 수 없었던 시간이었던 것 같습니다.

제가 협업을 진행한 회사에서는 NCP라는 여러가지 서버와 DB 등 많은 것을 제공해주는 플랫폼 안에서, 리눅스 기반의 우분투, CentOS 중 CentOS를 사용하고 있었습니다. 저희만을 위해서 따로 서버를 만들어주셨고, 해당 서버에 백과 프론트를 배포해서 맞춰보기로 결정하였습니다.

모두 아시는 사실이겠지만, 서버 컴퓨터에는 node, npm 어떠한 것도 설치되어 있지 않고, 초기 셋팅을 모두 해야만 한다는 것이죠. 그리고 더 중요한 것은 저희는 웹사이트를 개발하고 있기 때문에 해당 서버 컴퓨터를 웹사이트를 제공하는 서버로 만들어주는 소프트웨어를 설치해야하는 것입니다. 그렇다면, 이러한 소프트웨어에 대해서 간단하게 알아보도록 합시다.

🆖 NginX, 아파치

위에서 말한 것처럼 3가지의 서비스는 서버 컴퓨터를 웹사이트를 제공하는 서버로 만들어주는 소프트웨어들입니다.

웹사이트는 크롬, 엣지, 사파리, 파이어폭스와 같은 브라우저에서 돌아갑니다. 서버에서는 해당 브라우저가 읽을 수 있는 파일들인 HTML, CSS, JS 파일과 각종 이미지, 기타 여러 데이터를 사용자의 컴퓨터로 보내줄 수 있어야 합니다.

이 파일들은 원래 서버 컴퓨터에 저장되어 있습니다. 이 서버의 특정 폴더, 디렉토리에 이것들을 넣어두면, 이 폴더를 외부에서 접근 가능하도록 개방해서 서버에 지정된 웹사이트 주소로 접속하면 이것들을 받아갈 수 있도록 하는 것이 바로 이 웹서버의 기본적인 역할 중 하나입니다.

그리고 이 NginX, 아파치라는 프로그램들로 서버 컴퓨터에 있는 어떤 폴더를 개방해서 그 곳에 들어있는 HTML 등의 파일들로 웹사이트를 제공할 수 있는 것입니다. 서버에 정해진 사이트 주소로 접속을 하면 그 파일들로 웹사이트를 띄울 수 있도록 하는 것이죠. 다만, 이러한 방식은 정적 웹 서비스라는 한계가 있습니다.

정적 웹은 블로그나 회사 소개 페이지처럼 내부의 내용이 바뀔 일이 없는 웹페이지를 고정된 HTML, CSS, JS로 제공하는 사이트라 할 수 있습니다. 반면에 동적 웹은 게시판 페이지와 같이 항상 같은 내용이 아닌 사용자와의 상호 작용으로 페이지 내용이 그때그때 바뀌어서 만들어져서 가지고 와지는 것입니다.

이러한 동적 웹도 NginX, 아파치의 모듈로도 가능합니다. 특히, 이전에 많이 사용되어온 아파치와 PHP, MySQL을 연동시켜서 동적인 PHP 웹사이트를 제공하는 방식 등이 있습니다. 이를 줄여서 APM 조합이라고도 합니다.

🐈‍⬛ 톰캣

요즘은 스프링 부트에 톰캣이 내장되기 때문에 직접 접하는 것은 줄어들었지만, 자바와 JSP로 만든 웹 또는 API 어플리케이션을 실행할 때 이 톰캣과 같은 Web Application Server가 사용됩니다. 줄여서 WAS 또는 와스라고 합니다.

이는 단순히 뭘 갖다주는 것에서 벗어나 프로그래밍된 것을 더한다고 볼 수 있습니다. 이는 동적 사이트를 전문적으로 처리해주는 것이라고 생각하시면 됩니다.

아파치나 NginX와 같은 웹서버도 PHP와 같은 간단한 서비스를 제공할 수 있지만, 스프링과 같은 경우에는 톰캣과 같은 동적 사이트를 전문적으로 처리해주는 WAS의 손을 필요로 하게 되는 것입니다.

결국, 아파치와 NginX는 웹 서버, 톰캣은 WAS라는 것을 기억해주시면 됩니다. 웹 서버를 앞단에 두고, 즉 사용자들을 이 웹서버가 응접실에서 접대하도록 하고 그 뒤에서 WAS든 뭐든 전문 요리사가 요리를 하고 있는 것이라 생각하시면 됩니다.

웹사이트 관련 이론 이야기는 이쯤에서 그만하고, 제가 이번에 경험했던 배포에 대해서 이야기해보도록 하겠습니다.

🖥 실제 배포 관련 코드

저희는 백엔드가 파이썬과 장고로 서버를 개발했습니다. 다만, 웹 서버는 node.js와 express를 통해 진행하게 되었습니다. express 내에서 WAS 기능이 기본적으로 내장되어있기 때문에 쉽게 정적, 동적 웹 가리지 않고 서비스를 제공할 수 있었습니다.

특히, 백엔드 쪽에서 Administrator를 frontend/backend로 나누어주셨고, 이를 통해 저는 frontend라는 사용자 이름으로 접속해서 배포를 진행하면 되는 방식이었습니다.

그렇다면, 이제부터 실제 배포 과정에 대해서 나누어보도록 하겠습니다.

1. 개발 서버 열기

ssh frontend@개발 ip 주소

위와 같이 user 이름으로 개발 ip 주소를 열도록 하였습니다.

2. 개발 서버에 node 다시 깔기

curl -sL https://deb.nodesource.com/setup_14.x | sudo bash -

sudo apt-get update
sudo apt-get install nodejs

위와 같은 방식으로 개발 서버에 node를 설치하려고 했지만, 저희에게 관리자 권한이 주어져있지 않았기 때문에 해당 방식으로는 설치가 불가했습니다.

yum -y install epel-release
yum -y install nodejs

구글링을 통해서 위와 같이 설치했지만, node와 npm의 버전이 각 6.x, 3.x으로 굉장히 낮게 설치가 되게 되어버렸습니다. 결국, 또 다른 구글링으로 아래와 같이 nvm을 설치하고 직접 최신의 LTS 버전으로 설치를 하였습니다.

2.1 nvm 설치

// curl 설치
yum install curl

// nvm 설치
curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.33.8/install.sh | bash

// 재부팅을 해야 nvm 적용
reboot

//nvm 버전확인
nvm --version
//0.33.8 이러한 형식으로 표시되어야 정상 설치된 것

2.2 nodejs, npm 설치

//nodejs 버전들을 확인
nvm ls-remote

//최신 LTS로 설치(버전들을 확인 후, 원하는 버전 설치)
//nvm 으로 설치하게 되면 원하는 nodejs 버전과 함께 npm이 자동으로 함께 설치
nvm install 16.13.0

//nodejs 버전 확인
node --version
v16.13.0 <--- 버전이 제대로 뜨는지 확인

//npm 버전 확인
npm --version
v6.13.4

이렇게 CentOS 환경 속에서 개발 서버에 node 설치를 완료하였습니다. 그렇다면, 이제 프로젝트를 clone을 해오고 npm install을 해주시면 됩니다.

3. 프로젝트 clone 및 install

git clone 프로젝트_repo_주소
cd 프로젝트_repo_주소
npm install

4. server.js

그리고 server.js라는 파일을 생성해준 뒤 아래의 코드를 복사해줍니다.

vi server.js

// insert 모드로 아래 코드 복사 붙여넣기

const http = require("http");
const express = require("express");
const path = require("path");

const app = express();

const port = 8000;

app.get("/ping", (req, res) => {
  res.send("pong");
});

app.use(express.static(path.join(__dirname, "build")));

app.get("/*", (req, res) => {
  res.set({
    "Cache-Control": "no-cache, no-store, must-revalidate",
    Pragma: "no-cache",
    Date: Date.now()
  });
  res.sendFile(path.join(__dirname, "build", "index.html"));
});

http.createServer(app).listen(port, () => {
  console.log(`app listening at ${port}`);
});

위와 같이 express 서버설정 코드를 입력합니다. 순서는 상관없지만, 이후 express를 설치해주도록 하겠습니다.

npm install express --save

5. build 후 run server

npm run build
node server.js

이것은 우리가 작업한 소스코드를 컴파일을 진행하게 하는 명령어입니다. 프로젝트 폴더 바로 아래 build라는 폴더가 만들어지고, 그 안에 배포를 위한 파일들이 생성되게 됩니다.

그리고 아래 명령어를 통해, 개발 모드로 제작한 웹 사이트를 열 수 있도록 해줍니다.

⛑ 오류 발생

사소한 오류긴 하지만, 실제로 배포 과정에서 오류가 발생했던 적이 없어서 굉장히 당황했습니다. 백엔드와의 소통하는 API 주소를 config.js에서 모두 관리했었기 때문에 백엔드에서 배포한 개발 서버로 수정했을 때에 BASE_URL만 바꿔도 동작이 되어야 했습니다.

그런데 계속해서 개발 서버로 API를 요청하는 것이 아니라 이전 로컬 주소로 요청을 하는 것이었습니다. 백엔드와의 소통으로 계속해서 문제를 찾아보려고 했지만, 저는 로컬에서도 해보고 그랬을 때에 위 방식으로 계속 진행되었기 때문에 백엔드의 문제라고만 생각했습니다. 프론트, 백 모두 약 이틀 간의 구글링과 고민 속에서 시간은 계속해서 지나가고 있었습니다.

하지만, CTO님께서 한 번에 문제를 해결해주셨는데 이는 바로 npm run build에 정답이 있었습니다. 위에서 말한 것처럼 해당 명령어는 빌드가 진행되고 배포 버전으로 파일들이 만들어집니다.

그러나 이후 아무리 코드를 GitLab으로 pull을 받아오거나 직접 vi로 수정을 한다하더라도 배포 버전으로 파일을 만들어진 시기는 이전 시기가 되어버렸던 것입니다.

그래서 이후 npm run build를 통해 다시 배포 버전으로 파일을 만들어서 진행하니 백엔드 개발 서버와 잘 맞춰져서 결국 배포까지 완료할 수 있었습니다.

이번 일을 통해서 프론트엔드 개발자로서 단순히 리액트나 타입스크립트, 리덕스 등의 기술도 중요하지만 개발 서버 환경에서 빌드/배포 과정 그리고 여기서 더 나아가 테스트나 CI/CD에 대한 지식도 굉장히 중요한 요소라는 것을 깨닫게 된 좋은 계기였습니다.