3.0 3주차 워크북 학습 목표
과거 인터넷 사용자가 지금처럼 많지 않았던 경우,
웸사이트 A의 사용자가 10명이었다면
단순히 10개의 html페이지를 만들었다.
하지만 사용자가 기하급수적으로 늘어나면서
모든 웹페이지를 개별적으로 만드는 것이 불가능해졌다.
따라서 미리 정해진 콘텐츠(정적)를 준비한 후
요청이 올 때마다 적절한 콘텐츠를 만들어주는(동적인) 새로운 방식이 도입되었다.
이번 장에서는
정적 콘텐츠 응답과 동적 콘텐츠 응답이 어떻게 다른지 살펴보자.
1) Web Server와 Web application Server의 차이를 이해한다.
2) Reverse Proxy를 이해하고 적용한다.
앞선 2추자 EC2 NGINX 설치 내용에서 실습이 이어진다.
https://wlalsu.tistory.com/113
3.1 Web Server 정적 콘텐츠 호스팅
앞선 2주차의 EC2에서 설치한 NGINX가 웹 서버에 해당된다.
EC2 보안그룹에서 TCP 80번 포트를 열어주면
EC2의 아이피 주소(3.38.222.149)로 EC2를 식별한 후,
80번 포트로 열린 NGINX(3.38.222.149:80) 웹 서버에 요청을 보내는 것이다.
즉 우리가 웹 서버에 아이피주소(3.38.222.149)를 입력하면
자동으로 80번 포트가 붙고 NGINX에 요청이 간 후 응답이 온 것이다.
크롬에서 개발자도구(F12)를 실행해보자.
실제로 NGINX가 미리 정해진 html 코드 (정적 콘텐츠)를
응답으로 반환하는 것을 확인할 수 있다.
그렇다면 여기서 의문점이 생긴다!
어떤 상황에 어떤 응답을 주어야하는지를 어떻게 판단하는 것일까?
3.2 NGINX에서의 정적콘텐츠 호스팅
앞서 운영체제를 ubuntu로 설정하였으므로,
아래의 명령어를 입력하여 디렉토리에 접근하면
nginx의 설정파일을 확인할 수 있다.
(로컬이 아닌 원격 접속 터미널에서 입력해야 한다!)
cd /etc/nginx/sites-available
cat default
설정파일은 다음과 같다.
##
# You should look at the following URL's in order to grasp a solid understanding
# of Nginx configuration files in order to fully unleash the power of Nginx.
# https://www.nginx.com/resources/wiki/start/
# https://www.nginx.com/resources/wiki/start/topics/tutorials/config_pitfalls/
# https://wiki.debian.org/Nginx/DirectoryStructure
#
# In most cases, administrators will remove this file from sites-enabled/ and
# leave it as reference inside of sites-available where it will continue to be
# updated by the nginx packaging team.
#
# This file will automatically load configuration files provided by other
# applications, such as Drupal or Wordpress. These applications will be made
# available underneath a path with that package name, such as /drupal8.
#
# Please see /usr/share/doc/nginx-doc/examples/ for more detailed examples.
##
# Default server configuration
#
server {
listen 80 default_server;
listen [::]:80 default_server;
# SSL configuration
#
# listen 443 ssl default_server;
# listen [::]:443 ssl default_server;
#
# Note: You should disable gzip for SSL traffic.
# See: https://bugs.debian.org/773332
#
# Read up on ssl_ciphers to ensure a secure configuration.
# See: https://bugs.debian.org/765782
#
# Self signed certs generated by the ssl-cert package
# Don't use them in a production server!
#
# include snippets/snakeoil.conf;
root /var/www/html;
# Add index.php to the list if you are using PHP
index index.html index.htm index.nginx-debian.html;
server_name _;
location / {
# First attempt to serve request as file, then
# as directory, then fall back to displaying a 404.
try_files $uri $uri/ =404;
}
# pass PHP scripts to FastCGI server
#
#location ~ \.php$ {
# include snippets/fastcgi-php.conf;
#
# # With php-fpm (or other unix sockets):
# fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;
# # With php-cgi (or other tcp sockets):
# fastcgi_pass 127.0.0.1:9000;
#}
# deny access to .htaccess files, if Apache's document root
# concurs with nginx's one
#
#location ~ /\.ht {
# deny all;
#}
}
# Virtual Host configuration for example.com
#
# You can move that to a different file under sites-available/ and symlink that
# to sites-enabled/ to enable it.
#
#server {
# listen 80;
# listen [::]:80;
#
# server_name example.com;
#
# root /var/www/example.com;
# index index.html;
#
# location / {
# try_files $uri $uri/ =404;
# }
#}
NGINX 웹 서버가 실행될 때는
위의 설정 파일을 읽으면서 실행이 시작된다.
위의 설정파일에서 server 블록을 집중적으로 살펴보자.
1) root
- 정적 콘텐츠를 찾는 시작 디렉토리
2) index
- 기본적인 요청에 대해 index 뒤의 파일을 찾아 보여줌
실제로 아래의 명령어를 입력하여
해당 디렉토리의 파일을 확인해보면 html 코드를 확인해 볼 수 있다.
cd /var/www/html
ls
cat index.nginx-debian.html
이는 앞서 우리가 'Welcome to NGINX" 개발자 도구에서 확인했던
html 코드와 일치한다!
(80번 포트로 요청을 보냈을 때 왔던 응답 코드)
[ 💡NGINX 응답 순서 정리 ]
1) root /var/www/html : 정적 콘텐츠를 찾을 시작 디렉토리 설정
2) index : 기본요청이 온 경우 어떤 파일을 응답할지 설정
3) 응답 : /var/www/html/index.nginx-debian.html 을 응답으로 반환
3.3 NGINX 설정 파일에서의 location 블록
NGINX의 설정파일을 변경하여
(아이피주소)/temp 웹 브라우저에 접속했을 때
새로운 정적 페이지가 뜨도록 실습해보자!
먼저 아래의 명령어를 입력하여
vi에디터에서 /etc/nginx/sites-available/default 코드를 변경해보자.
vi /etc/nginx/sites-available/default
[ 리눅스 vi 에디터 기본 사용법 ]
- vi (파일명) : vi 에디터 실행
- i : 입력모드 실행
- esc : 명령모드 실행
- :wq : 저장 후 종료
vi 에디터를 실행 한 후
아래와 같이 location /temp 코드를 추가해준다.
[ 코드 추가 순서 ]
1) i 를 입력하여 입력모드 실행
2) location /temp 코드 추가
3) esc 를 입력하여 명령모드 실행
4) 명령모드에서 :wq 를 입력하여 저장 후 종료
location /temp{
root /var/www;
index temp.html
try_files $uri $uri/ =404;
}
해당 코드는 /temp 요청에 대해 아래의 요청을 수행해야 한다는 뜻이다.
1) root /var/www
- /temp로 요청이 오는 경우
- /var/www/temp 디렉토리에서 정적 파일을 찾음
2) index temp.html
- /temp로 요청이 오는 경우
- index 뒤에 쓴 temp.html 파일을 찾아서 응답 반환
- 위의 실습의 경우 /var/www/temp/temp.html 반환
[ 참고 ]
vi 에디터를 저장 후 종료하면 아래와 같이 에러 메시지가 뜰 수 있다!
이는 해당 파일이 읽기 모드(read-only) 로만 설정되어 있기 때문인데
$ sudo chmod 777 (filename)
다음의 명령어를 입력하여 쓰기권한을 추가할 수 있다.
다음으로 /var/www 로 이동한 후
temp.html 파일을 만들어보자.
먼저 아래의 명령어를 사용하여 /var/www 디렉토리로 이동한다.
cd /var/temp
다음으로 nginx 설정이 변경되었으므로 재실행 한 후,
temp 라는 디렉토리에 temp.html 파일을 만들어주자!
sudo systemctl restart nginx
sudo mkdir temp
sudo vi temp.html
temp.html 파일의 vi 에디터에서
새로운 html 문서를 만들어준다.
(문서 작성방법은 위의 vi 에디터 사용법과 동일)
파일 생성 후 (EC2 아이피 주소)/temp 에 접속하면
앞서 작성한 temp.html 코드가 실행되는 것을 확인할 수 있다!
(위의 예시의 경우 3.38.222.149/temp)
여기서 temp.html 코드가 실행되어야 하는데
다음과 같이 500 server 에러가 발생하였다...
확인해보니 temp.html 파일을
/var/www 디렉토리의 temp 디렉토리 내에 작성한 것이 아니라
/var/www 디렉토리 바로 아래에 작성해서 생긴 문제였다...!
다시 /var/www/temp 디렉토리로 이동한 후
temp.html 파일을 작성하니 아래와 같이 정상적으로 동작하였다!😀
앞선 예제에서 다른 파일을 한번 더 만들어보자.
/var/www/temp 디렉토리에 test.html을 아래와 같이 만든다.
(vi editor 작성방법은 위의 실습과 동일)
cd /var/www/temp
sudo vi test.html
vi 에디터에서 아래와 같은 html 파일을 작성한다.
<h1> nginx static file hosting practice </h1>
<h2> let's do staic file hosting without index default setting</h2>
(EC2 아이피주소)/temp/test.html 웹 브라우저에 접속하면
아래와 같이 앞서 작성한 html 파일이 출력되는 것을 확인할 수 있다.
3.4 location block으로 여러 경우 다르게 호스팅 하기
두가지 경로에 대해 다르게 호스팅 하는 방법을 살펴보자.
[ 요구사항 ]
1) /web 경로에 대해 기본적으로 welcome! 이 포함된 html을 보여주고 ddol.html 파일을 요청 할 경우 html 문서를 응답으로 주고 그 외의 경우는 에러 응답
2) /text 경로에 대해서는 기본 호스팅이 없고 hello.txt를 요청 시 hello world 문자열을 응답으로 주고 그 외의 경우는 에러 응답
먼저 nginx 설정 파일을 수정해보자.
아래의 명령어를 입력하여 vi 에디터에 들어간다.
vi /etc/nginx/sites-available/default
설정파일에서 아래의 location 을 추가하여
/web 과 /text 호스팅 경로를 지정한다.
location /web{
root /var/www;
index welcome.html
try_files $uri $uri/ =404;
}
location /text{
root /var/www;
try_files $uri $uri/ =404;
}
다음으로 /var/www 디렉토리 아래에
web 이라는 디렉토리를 생성한 후
welcome.html 파일과 ddol.html 파일을 작성한다.
(/var/www/web 디렉토리 아래에 작성해야 함을 유의!)
cd /var/www
sudo mkdir web
sudo vi welcome.html 명령어를 입력한 후
아래의 코드를 작성한다.
(쓰기 권한이 없는 경우 sudo chmod 777 welcome.html 설정 (위의 실습 참고))
동일하게 sudo vi ddol.html 명령어를 입력한 후
아래의 코드를 작성한다.
다음으로 앞선 방식과 동일하게
/var/www/text 디렉토리를 생성한 후
hello.txt. 파일을 아래와 같이 작성한다.
cd /var/www sudo
mkdir text sudo
vi hello.txt
실제로 웹 브라우저에서 실행해보면
location으로 호스팅한 주소에 작성한 파일이 응답되는 것을 확인할 수 있다.
1) (EC2 아이피 주소)/web/
2) (EC2 아이피 주소)/web/ddol.html
3) (EC2 아이피 주소)/text/hello.txt
3.5 Web Server VS Web Application Server(WAS)
앞서 정적인(미리 준비 된) 웹 서버(Web Server) 가 어떻게 동작하는지 살펴보았다.
그렇다면 Node.js 나 Spring Boot와 같은
Web Application Server(WAS) 가 웹 서버와 어떻게 함께 동작할 수 있을까?
그냥 Node.js나 Spring Boot를 실행시키면
Web Server가 없는 모습일 것이다.
그렇다면 네이버가 WAS 를 하나만 두었을 경우
www.naver.com:8080(Spring Boot의 경우) 로 접속해야 한다.
하지만 왜 우리는 그냥 www.naver.com 으로만 접속할까?
즉 그냥 www.naver.com으로 쓰면 www.naver.com:80 으로 접속하게 되는데
이는 웹 서버로 요청하는 것이다.
하지만 어떻게 응답이 WAS에서 가능할까?
어떻게 우리가 원하는 아래와 같은 로직이 가능한지 살펴보자.
3.6 Reverse Proxy
Reverse Proxy 란?
- 클라이언트와 서버간의 통신을 중계
- 클라이언트와 서버의 중간에 위치하여 보안/성능을 개선
- 클라이언트의 요청을 받고 이를 다시 본 서버로 보내주는 대리자 역할
[ 참고 ]
서버가 요청을 받기만 하는 것이 아니다!
connect() 시스템 콜과 같이 서버 프로세스가 내부적으로 요청을 보내는 시스템콜고 가능하다
즉 서버도 다른 서버 프로세스에게 요청이 가능하다!
[ 포워드 프록시 VS 리버스 프록시 ]
1) 포워드 프록시 : 외부 컴퓨터 (다른 컴퓨터) 서버로 요청을 보냄
2) 리버스 프록시 : 내부 컴퓨터 (같은 컴퓨터) 서버로 요청을 보냄
3.7 NGINX 에서 리버스 프록시 설정하기
리버스 프록시를 설정하기 위해
NGINX 설정 파일( /etc/nginx/sites-available/default )에 아래의 프록시 설정 코드를 추가한다.
(설정 파일 변경 방법 위에 참고)
location / {
proxy_pass http://localhost:3000; <- 프록시 설정
# First attempt to serve request as file, then
# as directory, then fall back to displaying a 404.
try_files $uri $uri/ =404;
}
NGINX를 재시작 하기 위해
sudo systemctl restart nginx 명령어를 입력한 후,
브라우저에 EC2 아이피 주소를 입력하면 다음과 같은 화면이 나타난다.
(처음에 proxy_pass 명령어 뒤에 세미콜론을 안붙여서 오류가 났다...🥲)
아직 3000번 포트를 가진 프로세스가 없기 때문에
위의 사진과 같이 502 에러가 뜨면
리버스 프록시 설정을 성공한 것이다!
(정상 작동을 위한 실습은 12주차에 진행된다고 한다!)
최용욱 'UMC Server 3주차 워크북' 내용을 기반으로 작성하였습니다.
'[UMC Ewha 5th] Server - SpringBoot' 카테고리의 다른 글
[UMC Server] Chapter 6. API URL의 설계 & 프로젝트 세팅 (0) | 2023.11.15 |
---|---|
[UMC Server] Chapter 5. 실전 SQL - 어떤 Query를 작성해야 할까? (0) | 2023.11.07 |
[UMC Server] Chapter 4. Database 설계 & AWS RDS 설정 (1) | 2023.11.01 |
[UMC Server] Chapter 2. AWS(VPC & Internet Gateway & EC2) (0) | 2023.10.04 |
[UMC Server] Chapter 1. 서버란 무엇인가(소켓&멀티 프로세스) (1) (0) | 2023.09.27 |