개요
바이러스가 만연한 현재에 개발자로써 주변사람들을 도울 수 있는 방법이 없을까 고민을 하다가, 마스크 재고를 알려주는 사이트를 만들어야 겠다 결심하였고 프로젝트에 대해 정리하는 글을 작성하였습니다.
프로젝트 글은 총 5편으로 나뉘어 작성될 예정이며 이번 글은 초기 서버세팅에 대한 내용을 담습니다.
서버세팅은 크게 2가지로 다룰 예정입니다. AWS로만 세팅하는 방법 하나와 일부분은 AWS로 세팅하고 나머지는 다른 tool 을 이용해 세팅하는 방법입니다. 후자의 경우 과금을 피하기 위한 절충안으로 전자의 방법보다 좀 더 많은 과정을 거칩니다.
그래서 이번 글은 AWS 위주로 세팅하는 방법을 먼저 설명합니다. 글을 읽으시면서 필요한 부분만 참고하시길 바랍니다.
목차
- 서버세팅
- 작업 목록
- EC2 인스턴스 구동하기
- 도메인 구매하기
- Elastic IP로 연결하기
- Route 53으로 도메인 연결하기 (선택)
- 네임 서버와 도메인 연결하기
- A 레코드, CNAME 레코드 등록하기
- 웹 서버 세팅하기 (Nginx)
- 모듈 세팅하기
서버 세팅
현재 많이 사용되고 비용이 덜 들어가는(?) AWS의 EC2 인스턴스를 이용해 서버를 구축하였다. (프리티어는 1년동안 무료이므로). 그러나 Geolocation API를 사용하는 것은 HTTPS 를 적용해야하고, 이는 도메인을 구입해야하는 것을 의미했다.
이처럼 간단할 줄 알았던 작업이 꽤나 복잡한 작업이라는 것을 깨닫는 것은 오래 걸리지 않았다.
작업 목록
- EC2 인스턴스 구동하기
- 도메인 구매하기
- 웹 서버 세팅하기 (nginx)
- 모듈 세팅하기
EC2 인스턴스 구동하기
개념
EC2 (Elastic Computing Cloud) 서비스는 클라우드에서 확장식 컴퓨팅을 제공한다. (즉 가상 컴퓨터를 임대해주는 개념)
인스턴스는 가상 컴퓨팅 환경을 의미한다. 그래서 EC2 인스턴스를 쓴다는 것은 클라우드에서 가상 컴퓨팅 환경을 쓴다는 것을 의미한다.
기능
- Amazon 머신 이미지(AMI) : 템플릿(서버에 필요한 운영체제와 여러 소프트웨어들이 적절히 구성된 상태)으로 제공되는 되어 인스턴스를 쉽게 만들 수 있음
- 인스턴스 구성 : 인스턴스를 위한 CPU, 메모리, 스토리지, 네트워킹 용량 등
- 키 페어를 사용하여 인스턴스 로그인 정보 보호 (사용자 : 개인키, AWS : 공개키)
- Windows / Linux 등 운영체제 선택 가능
- 보안 그룹을 사용한 방화벽 기능 : 인스턴스에 연결할 수 있는 프로토콜, 포트, 소스 IP 범위를 지정
- 사용한 만큼 요금 지불
구동방법
(EC2 인스턴스를 구동하는 방법에 대해선 관련하여 좋은 글들이 많고 자칫 내용이 길어질 것을 우려하여 일부 생략하겠습니다. 또한 앞으로 다룰 프로젝트 세팅은 Ubuntu 16.04 LTS 운영체제를 기반으로 설명합니다. 이 점 양해부탁드립니다..대신 참고할만한 좋은 글들을 첨부합니다)
https://goddaehee.tistory.com/179
https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/EC2_GetStarted.html
인스턴스 구동시 보안 그룹 구성과 관련해서 한 가지 언급하자면,
위와 같이 SSH, HTTP, HTTPS 프로토콜을 지정하고 각 소스 부분의 설정을
- SSH : 내 IP (Putty와 같은 SSH 클라이언트를 통해 서버에 접근할 때 자신만 접근할 수 있도록 함)
- HTTP : 위치 무관 (모든 사용자가 접근 가능한 웹 사이트를 배포할 것이므로 위치 무관으로 설정)
- HTTPS : 위치 무관 (HTTP와 동일)
Geolocation API이 동작할 수 있도록 하기 위해서 HTTPS 를 추가하였다.
EC2 인스턴스를 구동했다면, 이제 도메인을 구입해서 EC2 인스턴스와 연결시켜보자.
도메인 구매하기
도메인 구입에 앞서서 도메인에 대해 간략히 알아보자.
개념
도메인이란, 사이트에 접속하기 위해서 필요한 IP에 이름을 부여한 것이다.
설명
각 사이트는 IP 주소를 가지고 있는데(192.0.0.1, 218.112.69.110..) 숫자로만 구성된 이들을 외워서 사이트에 접속하는 것은 상당히 불편한 일이다. 그래서 www.naver.com 과 같이 특정 문자로 구성된 도메인은 숫자보다 훨씬 편하게 각 사이트에 접근할 수 있게 해준다.
여기서 DNS 서버에 대해서도 알아볼 필요가 있다.
개념
DNS 서버는 네임 서버라고도 하며 도메인에 연결된 서버의 IP를 찾아준다.
앞선 설명처럼, 도메인으로 서버 주소를 등록할 수 있게 됨으로써 실제 IP를 찾아주는 서비스의 필요성이 생겼는데 DNS 서버는 그 IP를 찾아내는 역할을 한다.
이제 도메인을 구입해보자.
도메인 구매
도메인을 구매해야 하는 이유는 아래와 같다.
- 사이트에 SSL 인증서를 등록해서 HTTPS 로 접속할 수 있고
- 이를 통해 Geolocation API를 사용할 수 있기 때문
도메인 없이 IP만 가지고도 HTTPS 사이트를 적용할 수도 있지만, 서비스 런칭을 하고 사용자의 편의성을 위해선 도메인을 구비하는 것이 좋다.
필자는 도메인을 goDaddy 라는 사이트에서 구매를 하였다. 대략 13,000원 정도 들었는데 구성으로는
- 도메인 구입(.world 가 붙어서 3,000원 가량)
- 보안 서비스(호스팅 제공자에 대한 정보 보호)
였다. 도메인만 구입해도 되지만 보안 서비스를 드는 것을 추천한다. 보통 호스팅 업체를 통해 도메인을 구입하면 자신의 email을 등록해야 되고 이러면 이메일이 외부에 노출되는데, 도메인 종료기간이 다가올 때쯤(혹은 중간중간에) 각종 이상한 메일이 날라온다. 이런 부분이 내키지 않는다면 보안 서비스를 드는 것을 추천한다.
Elastic IP로 연결하기
Elastic IP(탄력적 IP)란?
- AWS에서 제공하는 고정 IP 서비스로, AWS EC2 인스턴스의 public IP 주소가 안 바뀌도록 고정하게 해줌
- public IP 주소가 고정되므로 웹 서비스를 제공시 사용자가 빠른 속도로 접근할 수 있음
(IP 주소가 바뀌게 되면 DNS 서버가 바뀐 IP 주소를 다시 검색해야 되므로 그만큼 접속하는데 시간이 지연됨)
Comment
굳이 Elastic IP를 사용하지 않아도 큰 문제는 없는 것으로 보인다. 마스크 재고 서비스를 서버에 올린지 한달이 지났지만 public IP 주소가 자동으로 바뀌진 않았다. 다만 아래와 같이 연결버튼을 눌러서 SSH로 접속하기 위한 public DNS 주소를 확인할 때는 IP주소가 변경되었다.
이런 측면에서 Elastic IP를 사용하는 것이 서비스를 안정적으로 제공하는 방법이므로 Elastic IP를 세팅하는 과정를 거치는 것이 맞다. 다음 과정을 따라하자.
먼저 EC2 서비스에 들어온 후 왼쪽 사이드바에서 네트워크 및 보안 - 탄력적 IP를 클릭한다.
탄력적 IP 주소 할당 버튼을 클릭한다.
아래와 같은 화면이 뜨면 'Amazon의 IPv4 주소 풀' 이 선택되는데, 이는 IPv4 주소를 Amazon의 IP 주소 풀에서 할당하는 것이다. 할당버튼을 눌러 계속 진행한다.
이제 아래와 같이 탄력적 IP가 할당되고 이를 인스턴스와 연결만 해주면 된다. Action 드롭다운 버튼을 눌러 '탄력적 IP 주소 연결' 을 클릭한다.
아래와 같은 화면에서 인스턴스와 프라이빗 IP 주소를 선택해준다(프라이빗 IP 주소 연결은 선택사항 - 직접 선택하지 않아도 자동 연결됨). 연결 버튼을 클릭하면 탄력적 IP가 연결된다.
Route 53 으로 도메인 연결하기
개념
Route 53은 AWS에서 제공하는 DNS 웹 서비스로 아래 3가지를 수행할 수 있다.
- 도메인 이름 등록
- 인터넷 트래픽을 도메인의 리소스로 라우팅
- 주소로 도메인 이름만 쓰거나 하위 도메인을 붙여서 입력했을 때 해당 웹 애플리케이션으로 연결해줌
- 리소스 상태 확인
- 웹 서버에 접근 및 사용이 가능한지
- 정상 작동 중인지 확인
- 리소스가 사용할 수 없는 상태면 알림 수신 후 인터넷 트래픽을 다른 곳으로 라우팅 해줌.
Route 53을 써야 하는 이유?
사실 goDaddy 등과 같은 도메인 구매 대행업체에서도 DNS 웹 서비스를 해주는 네임 서버(DNS 서버)를 제공한다. 그러면 굳이 AWS 의 DNS 서비스를 써야할까? 라는 의문이 들 수 있는데, 결론적으로 다른 AWS 서비스 - ELB (로드 밸런서), ACM(인증서 관리자) 등을 같이 사용하기 위해서 써야한다.
좀 더 정리하자면 아래와 같다.
Route 53 을 써야하는 주된 이유
- ACM (인증서 관리자) : 웹 애플리케이션에 대한 공인 SSL/TLS 인증서를 만들어 관리해줌 (즉 HTTPS가 적용됨)
- ACM을 사용해서 HTTPS 적용을 하기 위해선 로드 밸런서가 있어야 한다.
- 즉 로드 밸런서를 생성하지 않으면 HTTPS 서비스를 제공할 수 없다
- 그러므로 Geolocation API 또한 사용이 불가능해진다
Route 53 을 써야하는 부차적인 이유
- ELB (로드 밸런서) : 인스턴스 앞단에서 트래픽을 분산시켜 인스턴스(들)에게 나눠줌
- 실질적으로 사용자들이 접속하게 되는 곳은 로드 밸런서
- 도메인을 적용한다는 것은 인스턴스가 아닌 로드 밸런서에 적용함을 의미함
- Route53 을 사용해서 로드 밸런서에 호스트 네임이 붙는 도메인을 부여할 수 있다. 즉,
- shop.mask-stock.world 도 되고
- mask-stock.world 도 된다
Q) 근데 저는 여러 개가 아닌 한개의 인스턴스만 쓰는데, 로드 밸런서를 쓰는게 크게 효용성이 있나요?
A) 두 가지면에서 답을 할 수 있다.
- 인스턴스가 하나이면 굳이 로드 밸런서를 쓰지 않아도 됨.
- 그러나 ACM을 사용한다면 결국 로드 밸런서를 써야함 (쓸 수 밖에 없도록 되어있음!! ㅠ)
하지만 ELB 을 썼을 때 생기는 이점도 있으니 알아보도록 하자. 서버에 문제가 생겼을 때 ELB는 다음과 같이 동작한다.
- auto-scaling이 새로운 교체 인스턴스를 시작
- 새 인스턴스가 로드 밸런서 뒤에 생김
- 사용자 트래픽이 새 인스턴스로 흐름
- 이와 같은 과정은 자동으로 이뤄짐
DNS를 변경할 필요도 없을 뿐만 아니라 Elastic IP (인스턴스 주소에 할당할 수 있는 고정 IP)를 수동으로 다시 할당할 필요가 없다 - 애플리케이션에서 더 많은 성능을 요구하게 되었을 때 DNS 구조를 변경할 필요 없이 autoscaling 그룹의 min/max 값을 간단히 조절해주면 됨
- 쉬운 SSL / TLS 구성 (앞서 얘기한 ACM 적용을 의미)
- 특정 서비스 거부 공격으로 부터 방어
이런 점들 때문에 대부분의 사용자는 ELB, Route 53의 사용을 선호한다. 하지만 좋은 기능인 만큼 과금도 있기 때문에 유의해서 사용하자.
+ 두어달 동안 서버를 운영해 본 결과 주로 로드밸런서의 동작으로 인해 과금이 많이 되는 것을 알 수 있었다(한달에 최대 3만원 가량). 참고하길 바람.
Route 53 도메인 등록하기
Route 53 서비스를 들어가서 왼쪽 배너 중 호스팅 영역을 클릭한다. 그리고 호스팅 영역 생성버튼을 클릭한다.
화면 오른쪽 측면에 입력창이 아래와 같이 뜰 것이다. 각각 다음과 같이 입력하자
- 도메인 이름 - 도메인 이름만 입력
- 설명 - 호스팅 영역에 대한 설명 기입 (생략 가능)
- 유형 - 퍼블릭 호스팅 영역 으로 선택
이 후 하단의 생성버튼을 클릭하여 생성한다
이제 아래와 같이 Hosted Zone이 생성되었다. Hosted Zone을 생성하면 항상 두 개의 리소스 레코드가 생성되는데 이들은 네임서버 세팅에서 필수적인 레코드들이다.
각각을 살펴보자.
NS 레코드 (NS : Name Server의 약자)
- Name Server(네임서버)란?
- 사용자가 도메인으로 접속을 했을 때 도메인의 IP 주소를 찾아서 반환해줌
- DNS 서버, 도메인(Domain) 서버 라고도 불림
- NS 레코드는 특정 도메인에 대한 처리를 다른 도메인 서버에게 위임해주는 역할을 함
SOA 레코드
- 권한 게시 정보를 의미
그리고 레코드의 이름 영역을 자세히 보면 mydomain.com. 처럼 맨 끝에 .(점)이 붙어 있다. 이게 뭔지 살펴보자.
.(점) 은 무엇인가?
원래 도메인을 표현할 때는 맨 끝에 점을 붙이는데, 우리가 흔히 보는 도메인들은 이를 생략한 것이다.
이처럼 뒤에 점이 붙은 도메인들을 Root name server(루트 네임 서버)라고 부른다.
점을 왜 생략할까?
흔히 URL 에서 점이 붙으면 뒤따라 붙는 어떤 이름이 있는 것을 의미한다
- mydomain.com.이름
(이름에 루트 네임 서버 값이 들어간다)
그러나 도메인은 계층적이고 루트 네임 서버는 도메인에 공통적으로 적용되기에 이름이 없다. 그러므로 점도 불필요하게 표현하지 않으려고 생략하는 것이다. 이해를 위해 아래와 같이 그림을 첨부한다. 맨 오른쪽이 앞서 설명한 루트 네임 서버 이다.
A 레코드, CNAME 레코드 등록하기
이제 Route 53에서 A 레코드, CNAME 레코드를 각각 등록해줄 건데 각각의 개념을 알아보자.
A 레코드 (A : Address의 약자)
- 도메인(또는 호스트 네임이 붙은 도메인)과 도메인을 호스팅하는 컴퓨터의 IP 주소를 서로 매핑해줌.
- 이를 통해 사용자가 주소창에 도메인 이름을 입력했을 때 매핑된 IP 주소로 변환되면서 웹 사이트에 접근할 수 있게 됨
CNAME 레코드 (CNAME : Canonical Name의 약자)
- 정식 이름이라는 뜻으로 도메인에 별명을 지정한다고 보면 됨
- 구매한 도메인 주소와 CNAME 값으로 지정한 주소를 매핑해줌
A 레코드와 CNAME 레코드에 대해 나타내는 그림을 보면 더욱 이해가 잘 될 것이다.
Route 53 화면으로 돌아와서 맨 처음에 추가한 Hosted Zone 에 들어가 레코드 세트 생성 버튼을 클릭한다. 새로 추가할 레코드 유형은 A - IPv4 이다.
다음과 같이 세팅한다.
- 이름 : 생략 (루트 도메인을 세팅하는 것이므로 이름을 적을 필요 없음)
- TTL(Time to Live) 는 캐시를 의미하는데, DNS 서버가 A 레코드로 지정한 값을 얼마나 기억하고 있을지를 설정하는 부분이다. IP 주소가 자주 바뀐다면 TTL을 짧게, 자주 바뀌지 않는다면 길게 설정하는게 좋다.
- 값에는 인스턴스의 public IP를 입력해준다. public IP는 EC2 인스턴스 설명란에서 확인할 수 있다.
마지막으로 CNAME 레코드를 생성하기 위해 유형을 CNAME 으로 지정한다. 이 때 CNAME 레코드 세트를 만드는 방법과 ALIAS(별칭)을 사용하는 방법 두 가지가 있는데, 여기선 CNAME을 사용하는 방법에 대해 설명한다. 두 방식의 차이 대한 자세한 내용은 아래 링크 참고.
Choosing between alias and non-alias records
다음과 같이 세팅한다.
- 이름 : www 를 입력 (이를 통해 www.mydomain.com 으로도 접근할 수 있음)
- TTL은 A 레코드에서 언급한 것과 비슷하다. 적절히 설정해주거나 기본값을 사용한다.
- 값에는 구매한 도메인 주소를 입력한다 (예: mydomain.com)
여기까지가 Route 53에서 세팅하는 과정이었고 다음으로 네임 서버와 도메인을 연결해주자.
네임 서버와 도메인 연결하기
구매한 도메인과 네임서버를 연결할 것이다. 위에서 봤던 4개의 네임서버들을 전부 도메인 구입 대행업체에 등록을 해주자.
(goDaddy 사이트를 기준으로 설명)
goDaddy에서 아래 화면과 같이 생긴 DNS 관리 페이지로 들어온다.
도메인을 구매하고 처음 설정에 들어갔다면 Records 부분에 A 레코드, CNAME 등의 설정값이 나타나 있을 것이다. (필자는 이미 Nameservers 에 주소 등록을 해서 Records 가 가려진 상태)
Nameserver 섹션에서 Change 버튼을 누른다.
좀전에 Route 53에서 생성된 4개의 네임서버를 등록해야 한다.
그런데 네임서버의 도메인 이름만 알지만 IP 주소는 모르는 상태이다. 이 때는 직접 ping을 날려주면서 IP 주소를 알아낼 수 밖에 없다 (goDaddy에서 2019년도 말부터 사용자가 직접 IP 주소를 입력하도록 바꾼 것으로 보임)
아래 그림 처럼 cmd 창에서 `ping 네임서버 도메인 주소` 를 입력해 IP 주소를 알아내고 이를 goDaddy 사이트에 입력하자.
4개의 네임서버에 대해 모두 등록한 뒤 저장을 누른다.
저장을 누르고 나면 DNS 관리 화면에서 Records 부분이 갑자기 사라질 것인데 이는 레코드 관리를 AWS에서 하도록 설정했기 때문이다. 다만 동작에는 전혀 지장없고 네임서버를 초기화하면 다시 뜨게되므로 걱정할 필요 없다. 유저마다 시간은 상이하지만 설정이 완전이 될 때까진 대략 5분정도 소요된다.
여기까지가 Route 53을 세팅하는 방법이다. 사실 ACM, ELB 를 쓰지 않고 자체적으로 로드 밸런서 기능과 HTTPS를 생성할 수 있다(이 경우에도 Route 53은 사용해야 한다). 아래 포스팅을 참고하길 바람
웹 서버 세팅하기 (Nginx)
웹 서버는 크게 Apache, Nginx 두개가 있는데 Apache는 전 세계적으로 많이 사용되고 있으며 그 만큼 커뮤니티도 크다. Nginx는 그에 비해 사용자수는 적지만 늘어가는 추세이고 이벤트 드리븐 방식을 사용하기 때문에 메모리 측면에서 System resource 를 적게 가져가는 장점이 있다. 이 글에서는 Nginx 로 서버세팅하는 방법에 대해 설명한다.
먼저 Putty를 사용하여 EC2 인스턴스에 접속하자.
Nginx 세팅 과정
Nginx 서버를 세팅하는 방법은 Open source Nginx를 사용하는 방법과 Nginx Plus를 사용하는 방법으로 나뉘어 지는데 전자는 무료이고, 후자는 유료이다. 전자에 대한 과정은 아래와 같다.
아래 명령어를 입력해서 NGINX Signing key를 다운받는다.
sudo wget http://nginx.org/keys/nginx_signing.key
다운받은 키를 패키지 목록에 추가한다.
sudo apt-key add nginx_signing.key
/etc/apt 경로로 이동한다
cd /etc/apt
sources.list 파일을 수정하여 파일의 맨 하단에 아래 텍스트들을 붙여넣는다. nano sources.list 를 입력하여 수정하자
deb http://nginx.org/packages/ubuntu xenial nginx
deb-src http://nginx.org/packages/ubuntu xenial nginx
여기까지 했으면 우선적으로 아래 두 명령을 차례대로 입력해줘야 한다.
sudo apt-get update
sudo apt-get upgrade
(혹은 두 명령을 아래와 같이 한꺼번에 입력가능)
sudo apt-get update && apt-get upgrade
apt-get update : 사용가능한 패키지들과 각 패키지들의 버전을 업데이트한다. 패키지의 버전을 실제로 업데이트하는 것은 아니다. 다만 미리 설치된 패키지들에 대한 최신 버전이 있는지를 확인하고 package 매니저에게 알려준다.
apt-get upgrade : ubuntu OS에 있는 패키지들을 최신버전으로 업그레이드 한다. 이 때 버전은 apt-get update를 통해 알게된 최신 버전이다.
이제 nginx 를 설치하자. 아래 명령어를 입력한다
sudo apt-get nginx
명령어를 입력하면 nginx를 설치할 것인지를 물어본다. y를 입력해서 계속 진행한다.
nginx를 설치했다면 이제 nginx를 실행해보자. nginx 를 제어하는 명령어 목록은 아래와 같다.
- service nginx start : 시작
- service nginx stop : 정지
- service nginx restart : 재시작
- service nginx reload : 설정파일을 리로드
- service nginx status : 현재 상태 출력
nginx를 실행하고 상태를 확인하면
sudo service nginx start
sudo service nginx status
active (running) 이라고 뜬다. 인터넷 주소창에 인스턴스의 public IP 주소 또는 구매한 도메인 이름을 입력하면 아래와 같이 Welcome 페이지가 뜬다.
모듈 세팅하기
모듈 세팅에 앞서 올리고자 하는 프로젝트가 있다면 git 저장소를 이용하는 것을 추천한다. git 저장소에 올려서 git clone 명령어를 사용하면 쉽게 프로젝트 파일을 서버에 옮길 수 있다. 그러므로 우리에게 필요한 패키지는 아래와 같다.
- git
하나하나 명령어를 입력해서 설치하자
git 설치
sudo apt install git-all
git version
git version이 뜬다면 잘 설치된 것이다.
yarn 설치
yarn 공식 홈페이지에 들어가서 명령어를 복사해서 실행시키자 (https://classic.yarnpkg.com/en/docs/install#debian-stable)
( 2020-04-03 기준 명령어)
아래 명령어들을 모두 복사해서 실행해야 한다. 따로따로 실행하지 말고 한번에 복사해서 실행하도록 한다.
curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | sudo apt-key add - echo "deb https://dl.yarnpkg.com/debian/ stable main" | sudo tee /etc/apt/sources.list.d/yarn.list
그리고 yarn 을 설치한다.
sudo apt update && sudo apt install yarn
yarn 버전을 확인해 뜬다면 잘 설치된 것이다.
yarn --version
parcel 설치
parcel 설치는 비교적 간단하다. parcel 공식 홈페이지에 들어가서 설치 명령어를 복사해서 실행하거나 아래 명령어를 실행한다.
yarn global add parcel-bundler
parcel 까지 설치했다면 필요한 모듈은 모두 설치했다. 이제 프로젝트 디렉토리를 지정하고 git 으로 받는 것만 남았다.
프로젝트 디렉토리
보통 명령어를 입력할 때의 현재 위치는 /home/ubuntu 로 되어 있을 것이다. 즉 이 상태일 것이다.
현재 위치인 /home/ubuntu 에서 바로 프로젝트 디렉토리를 생성해도 되고 또는 다른 폴더에 생성해도 된다. 지금 글에선 추가로 디렉토리를 생성할 것이다.
아래와 같이 명령어를 입력해 server 및 application1 디렉토리를 만들자
sudo mkdir server
cd server
sudo mkdir application1
cd application1
그럼 현재 디렉토리가 아래와 같이 되어있을 것이다.
이 상태에서 git 명령어를 사용해 git 프로젝트를 다운받자
git clone Git 저장소 URL
저장소 디렉토리로 이동해 아래 명령어들을 실행한다. 다른 저장소로 이동하는 방법은 저장소 이름 앞에 cd 를 붙이면 된다.
cd 저장소 이름
yarn init -y
마지막으로 프로젝트 파일을 빌드하는 것만 남았다. 우리는 Geolocation API를 사용하기 때문에 https 를 지원하도록 해야한다. 아래 명령어를 입력한다.
parcel entry-file --https
entry-file은 자신의 웹 페이지가 시작할 때 최초 보여지는 파일을 지정하면 된다. (현재 프로젝트에선 index.html 파일을 entry-file로 지정한다) 'ls -a' 명령어로 파일들이 잘 생성되었는지 확인해보자.
dist 폴더와 .cache 폴더가 생성되었다면 정상적으로 빌드된 것이다.
이제 남은 것은 dist 폴더의 내용을 웹 서버인 nginx 가 읽도록 하는 것이다.
먼저 아래 명령어를 입력해서 이동한다
/etc/nginx/conf.d
nano default.conf 명령어를 입력한다. 그러면 아래와 같은 화면이 뜨는데 다음과 같이 한다.
- location / { root ... } 부분의 위치를 좀 전에 git 명령어로 받은 저장소 폴더 명으로 바꿔준다.
여기까지 했다면 사용자가 웹 사이트에 접근하기 위한 모든 세팅은 끝이 났다.
마지막으로 nginx을 리로드 해주자
sudo nginx -s reload
이제 인스턴스 IP 주소 또는 도메인 이름을 입력하면 작업한 페이지가 뜨는 것을 확인할 수 있다. 다음 글에서 다룰 SSL 인증서 생성, 로드 밸런서 설정만 해주면 웹 서버를 구동시키는 모든 작업은 마무리 된다.
여기까지가 마스크 재고 프로젝트와 관련된 초기 서버세팅 작업이었고, 다음 글에는 Full AWS 서버세팅에 관하여 다뤄보겠습니다. 감사합니다.
출처
https://m.blog.naver.com/wool613/221286931692
https://git-scm.com/book/ko/v2/%EC%8B%9C%EC%9E%91%ED%95%98%EA%B8%B0-Git-%EC%84%A4%EC%B9%98
https://classic.yarnpkg.com/en/docs/install
https://taetaetae.github.io/2018/06/27/apache-vs-nginx/
https://askubuntu.com/questions/94102/what-is-the-difference-between-apt-get-update-and-upgrade
https://medium.com/@datapath_io/elastic-ip-static-ip-public-ip-whats-the-difference-8e36ac92b8e7
https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html
'강의 | 대외활동 | 개인플젝 > 마스크 재고 관리_개인플젝' 카테고리의 다른 글
| 마스크 재고 관리 프로젝트 - 5 (AWS + 다른 서비스) (0) | 2020.04.14 |
|---|---|
| 마스크 재고 관리 프로젝트 - 4 (Full AWS) (0) | 2020.04.03 |
| 마스크 재고 관리 프로젝트 - 2 (0) | 2020.03.30 |
| 마스크 재고 관리 프로젝트 - 1 (0) | 2020.03.27 |
댓글