|
| 1 | +### 출처 |
| 2 | +* [nginx 설정](https://phsun102.tistory.com/45) |
| 3 | +* https://thinkj.in |
| 4 | +___ |
| 5 | +### 개요 |
| 6 | +* [[#들어가며]] |
| 7 | +* [[#nginx]] |
| 8 | +* [[#nginx의 설정]] |
| 9 | +* [[#내 블로그 설정하기]] |
| 10 | +* [[#Route53]] |
| 11 | +* [[#SEO를 통해 내 사이트 노출하기]] |
| 12 | +___ |
| 13 | +### 들어가며 |
| 14 | + |
| 15 | +개인 블로그를 생성하고 싶다는 생각을 계속했다. 티스토리나 velog를 활용할 수도있지만, 정적 웹서버나 DNS등의 학습한 내용들을 써먹고 싶다는 생각이 제법 들었다. |
| 16 | + |
| 17 | +프론트엔드 작업이 발목을 잡았지만, 간단한 프론트엔드 작업 정도는 관련 툴이 많이 존재했기 때문에 생각보다 쉽게 사이트를 제작하는 것이 가능했다. 이에따라 정적 웹서버를 활용해 개인 블로그를 제작하기로 결심했다. |
| 18 | + |
| 19 | +블로그 배포를 위해 생각한 방법은 S3를 활용한 방법과 ec2와 Nginx를 활용한 배포로 총 2가지였다. |
| 20 | + |
| 21 | +S3를 활용해 배포를 진행할 경우 https가 자동으로 적용 된다는 점과 가격이 저렴하다는 이점이 존재했다. |
| 22 | +하지만 WAS로의 확장이 어려워 이후 댓글 등의 기능을 추가하기 위해서는 웹서버를 활용해야겠다는 생각이 들어 nginx를 활용하기로 했다. |
| 23 | +___ |
| 24 | +### nginx |
| 25 | + |
| 26 | +[[웹서버와 nginx]]를 참조하면 nginx에 대한 내용이 이미 잘 정리돼 있다. 우리는 정적 웹서버 및 https 적용을 위해 nginx를 활용한다. 별도의 WAS서버가 존재하지 않기 때문에 리버스 프록시라고 부르기에는 부족함이 존재한다. |
| 27 | +___ |
| 28 | +### nginx의 설정 |
| 29 | + |
| 30 | +nginx는 brew를 활용해 손쉽게 설치가 가능하다. 리눅스 환경의 경우 apt나 yum을 활용하면 된다. ec2에서 설치할 경우 AWS Linux를 기준으로 `sudo yum install -y nginx` 명령어로 설치가 가능하다. |
| 31 | + |
| 32 | +nginx를 실행해보자. `127.0.0.1:8080`으로 접속하면 아래와 같은 페이지가 출력된다. mac에서 nginx 실행을 위해서는 `nginx`라고 입력하면 된다. |
| 33 | + |
| 34 | + |
| 35 | + |
| 36 | +위와 같은 이미지가 확인되면 정상적으로 동작하고 있는 것이다. 이제 우리는 설정을 변경해 nginx가 전송 받은 요청에 따른 적절한 페이지를 전송하게 만들면 된다. |
| 37 | + |
| 38 | +설정 파일로 접속해보자. 설정 파일은 mac을 기준으로 `/opt/homebrew/etc/nginx` 에 위치한다. 내용을 확인해보면 다음과 같다. |
| 39 | + |
| 40 | +```txt hl:3,17,35 |
| 41 | +
|
| 42 | +#user nobody; |
| 43 | +worker_processes 1; #사용할 워커 프로세스의 수 nginx 토픽을 참조하자 |
| 44 | +
|
| 45 | +#error_log logs/error.log; |
| 46 | +#error_log logs/error.log notice; |
| 47 | +#error_log logs/error.log info; |
| 48 | +
|
| 49 | +#pid logs/nginx.pid; |
| 50 | +
|
| 51 | +
|
| 52 | +events { |
| 53 | + worker_connections 1024; |
| 54 | +} |
| 55 | +
|
| 56 | +
|
| 57 | +http { |
| 58 | + include mime.types; |
| 59 | + default_type application/octet-stream; |
| 60 | +
|
| 61 | + #log_format main '$remote_addr - $remote_user [$time_local] "$request" ' |
| 62 | + # '$status $body_bytes_sent "$http_referer" ' |
| 63 | + # '"$http_user_agent" "$http_x_forwarded_for"'; |
| 64 | +
|
| 65 | + #access_log logs/access.log main; |
| 66 | +
|
| 67 | + sendfile on; |
| 68 | + #tcp_nopush on; |
| 69 | +
|
| 70 | + #keepalive_timeout 0; |
| 71 | + keepalive_timeout 65; |
| 72 | +
|
| 73 | + #gzip on; |
| 74 | +
|
| 75 | + server { |
| 76 | + listen 8080; |
| 77 | + server_name localhost; |
| 78 | +
|
| 79 | + #charset koi8-r; |
| 80 | +
|
| 81 | + #access_log logs/host.access.log main; |
| 82 | +
|
| 83 | + location / { |
| 84 | + root html; |
| 85 | + index index.html index.htm; |
| 86 | + } |
| 87 | +
|
| 88 | + #error_page 404 /404.html; |
| 89 | +
|
| 90 | + # redirect server error pages to the static page /50x.html |
| 91 | + # |
| 92 | + error_page 500 502 503 504 /50x.html; |
| 93 | + location = /50x.html { |
| 94 | + root html; |
| 95 | + } |
| 96 | +
|
| 97 | + # proxy the PHP scripts to Apache listening on 127.0.0.1:80 |
| 98 | + # |
| 99 | + #location ~ \.php$ { |
| 100 | + # proxy_pass http://127.0.0.1; |
| 101 | + #} |
| 102 | +
|
| 103 | + # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000 |
| 104 | + # |
| 105 | + #location ~ \.php$ { |
| 106 | + # root html; |
| 107 | + # fastcgi_pass 127.0.0.1:9000; |
| 108 | + # fastcgi_index index.php; |
| 109 | + # fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name; |
| 110 | + # include fastcgi_params; |
| 111 | + #} |
| 112 | +
|
| 113 | + # deny access to .htaccess files, if Apache's document root |
| 114 | + # concurs with nginx's one |
| 115 | + # |
| 116 | + #location ~ /\.ht { |
| 117 | + # deny all; |
| 118 | + #} |
| 119 | + } |
| 120 | +
|
| 121 | +
|
| 122 | + # another virtual host using mix of IP-, name-, and port-based configuration |
| 123 | + # |
| 124 | + #server { |
| 125 | + # listen 8000; |
| 126 | + # listen somename:8080; |
| 127 | + # server_name somename alias another.alias; |
| 128 | +
|
| 129 | + # location / { |
| 130 | + # root html; |
| 131 | + # index index.html index.htm; |
| 132 | + # } |
| 133 | + #} |
| 134 | +
|
| 135 | +
|
| 136 | + # HTTPS server |
| 137 | + # |
| 138 | + #server { |
| 139 | + # listen 443 ssl; |
| 140 | + # server_name localhost; |
| 141 | +
|
| 142 | + # ssl_certificate cert.pem; |
| 143 | + # ssl_certificate_key cert.key; |
| 144 | +
|
| 145 | + # ssl_session_cache shared:SSL:1m; |
| 146 | + # ssl_session_timeout 5m; |
| 147 | +
|
| 148 | + # ssl_ciphers HIGH:!aNULL:!MD5; |
| 149 | + # ssl_prefer_server_ciphers on; |
| 150 | +
|
| 151 | + # location / { |
| 152 | + # root html; |
| 153 | + # index index.html index.htm; |
| 154 | + # } |
| 155 | + #} |
| 156 | + include servers/*; |
| 157 | +} |
| 158 | +
|
| 159 | +``` |
| 160 | + |
| 161 | +nginx의 설정 파일은 http 블록과 http 블록 내부의 sever블록으로 구분된 것을 확인할 수 있다. http 블록은 http 프로토콜 요청에 대한 처리 방식을 담고 있고 server 블록은 http 요청을 처리하는 각각의 서버를 의미한다. |
| 162 | + |
| 163 | +#### http 블록 |
| 164 | +http 블록에서는 서버 전체에 포괄적으로 적용되는 속성들을 주로 정의한다. 대표적으로 다음과 같은 옵션들이 존재한다. |
| 165 | +* **keepalive_timeout** |
| 166 | + 지속 커넥션의 유지시간을 결정한다. 해당 시간까지 클라이언트가 명시적으로 연결을 종료하지 않는 이상 연결이 서버에선 계속 유지된다. |
| 167 | +* 파일 전송 허락 여부 |
| 168 | +* 활용 할 MIME 지정 |
| 169 | +* HTTP 바디 및 헤더 크기 지정 |
| 170 | +* gzip 사용 여부 |
| 171 | +#### server 블록 |
| 172 | +서버 블록에서는 각각의 서버에 적용되는 속성들을 정의한다. URL과 포트 등을 여기서 설정한다. 몇가지 주요한 속성들을 살펴볼 필요가 존재한다. |
| 173 | +* **listen** |
| 174 | + 서버에서 요청을 수신하는 서버 명을 설정하는 옵션이다. nginx는 해당 호스트 명으로 전달된 요청을 이 서버 블록으로 전달한다. |
| 175 | +* **root** |
| 176 | + 요청에 따른 응답으로 전달할 정적 파일 폴더의 기본 위치를 설정한다. `servername/a.html` 이라는 요청이 전송되면 루트 디렉토리 하위에 위치한 `a.html`을 반환한다. |
| 177 | +* **index** |
| 178 | + index 페이지로 사용할 페이지를 등록한다. |
| 179 | +* **location** |
| 180 | + 경로 별로 처리할 요청을 지정하기 위해 사용한다. `/`와 같이 입력하며 해당 경로로 들어온 요청을 설정할 때 사용한다. |
| 181 | +* **return** |
| 182 | + 사용자에게 특정 응답 코드를 반환하기 위해 활용한다. 응답 코드와 텍스트를 반환한다. 리다이렉팅이나 에러코드 처리를 위해 주로 활용한다. |
| 183 | +* **rewrite** |
| 184 | + 클라이언트의 요청 URL을 덮어써 다른 경로로 수정할 때 주로 활용한다. 리턴과 달리 반환을 곧장 하지 않고 수정된 URL로 변경후 해당 URL에 적절한 처리를 진행한 후 반환한다. |
| 185 | +* **ssl_certificate_key** |
| 186 | + HTTPS 적용을 위한 SSL 키 파일을 적용하기 위해 사용하는 속성이다. 키 파일의 경로를 입력한다. |
| 187 | + |
| 188 | +___ |
| 189 | +### 내 블로그 설정하기 |
| 190 | + |
| 191 | +설정 파일에 어떠한 요소가 있는지 파악했으니 이에 따른 적절한 설정을 진행해보자. 우리가 설정해야 할 것들은 다음과 같다. |
| 192 | + |
| 193 | +#### 사용할 워커 프로세스 |
| 194 | +nginx는 비동기 방식으로 동작하고 각 워커 프로세스는 이벤트 루프에서 이벤트 드리븐 방식으로 요청을 처리한다. 워커 프로세스는 하나의 커넥션만을 담당하지 않고 이벤트 루프에서 이벤트가 발생한 모든 요청을 처리하므로 하드웨어의 모든 자원을 활용한다. (CPU가 노는 시간이 발생하지 않는다) 따라서 **워크 프로세스의 수는 일반적으로 CPU 코어 수로 결정한다.** |
| 195 | + |
| 196 | +>[!info] |
| 197 | +> **모든 워커는 비동기 방식으로 동작하고 이러한 까닭에 워커의 수를 무작정 늘린다고 해서 웹서버의 성능이 향상 되지는 않는다.** |
| 198 | +
|
| 199 | +우리가 사용할 ec2는 가장 저렴한 t2 micro이기 때문에 워커 프로세스의 수를 1개로 설정한다. |
| 200 | + |
| 201 | +#### 요청 별 반환 파일 지정 |
| 202 | +이제 요청에 따라 전달할 파일의 위치를 지정해보자. 우리는 사용자가 요청을 경로 단위로 아름답게 전송할 것이라 가정하기 때문에 (`thinkj.in/aws/s3.html` 이러한 방식으로) 루트만 잘 설정해주고 사용자의 요청에 따른 적절한 파일만 반환 해준다. |
| 203 | + |
| 204 | +``` |
| 205 | +root /home/ec2-user/my_blog; |
| 206 | +location / { |
| 207 | + if (-d $request_filename) { |
| 208 | + rewrite ^(.*)$ /readme.html redirect; |
| 209 | + } #만약 요청이 디렉토리 명이면 인덱스로 리다이렉팅 |
| 210 | + index readme.html; |
| 211 | + autoindex off; #자동 생성 인덱스 페이지를 비활성화한다. |
| 212 | +} |
| 213 | +``` |
| 214 | + |
| 215 | +이렇게 설정해두면 모든 요청은 해당 로케이션으로 전달된다. 이때 루트는 `/home/ec2-user/my_blog` 이므로 `https://thinkj.in/aws/s3.html`과 같은 요청이 전달되면 `/home/ec2-user/my_blog/aws/s3.html`을 반환한다. |
| 216 | + |
| 217 | +#### HTTPS |
| 218 | +현재 사이트에 접속하려고 하면 사이트가 안전하지 않다는 문구와 함께 접속이 제한될 것이다. 이는 HTTPS를 제공하지 않기 때문으로 해결을 위해서는 인증서를 발급받고 SSL 프로토콜을 지원해야한다. |
| 219 | +CA 인증서는 일반적으론 유료 지만 [let's encrypt](https://letsencrypt.org/certificates/) 등을 활용하면 쉽게 무료 인증서를 발급 받을 수 있다. |
| 220 | + |
| 221 | +발급받은 인증서와 키를 nginx 설정에 입력하면 HTTPS 접속을 제공할 수 있다. |
| 222 | + |
| 223 | +```txt hl:4,5 |
| 224 | +server { |
| 225 | + listen 443 ssl http2; |
| 226 | + server_name thnikj.in www.thinkj.in; |
| 227 | + ssl_certificate /etc/letsencrypt/live/thinkj.in/fullchain.pem; |
| 228 | + ssl_certificate_key /etc/letsencrypt/live/thinkj.in/privkey.pem; |
| 229 | + root /home/ec2-user/my_blog; |
| 230 | + charset utf-8; |
| 231 | +
|
| 232 | + # Load configuration files for the default server block. |
| 233 | + include /etc/nginx/default.d/*.conf; |
| 234 | + index readme.html; |
| 235 | +
|
| 236 | + location / { |
| 237 | + if (-d $request_filename) { |
| 238 | + rewrite ^(.*)$ /readme.html redirect; |
| 239 | + } |
| 240 | + index readme.html; |
| 241 | + autoindex off; |
| 242 | + } |
| 243 | +``` |
| 244 | + |
| 245 | +443 포트만 제공할 경우 80번 포트로 접속하면 접속이 아예 불가하므로 만약 80번 포트로 접속할 경우 443으로 리다이렉팅을 진행해 HTTPS로 접속을 진행하게 하자. 앞에서 배운 return을 활용해 리다이렉팅을 진행한다. |
| 246 | + |
| 247 | +```text hl:4 |
| 248 | + server { |
| 249 | + listen 80; |
| 250 | + server_name thinkj.in www.thinkj.in; |
| 251 | + return 301 https://$host$request_uri; #host와 request는 그대로 https만 적용해 리다이렉트한다. |
| 252 | + } |
| 253 | +``` |
| 254 | + |
| 255 | +> [!info] |
| 256 | +> **이제 원하는 정적 파일을 요청에 따라 반환하고 이를 HTTPS 위에서 진행하는 것이 가능해졌다.** |
| 257 | +
|
| 258 | +___ |
| 259 | +### Route53 |
| 260 | + |
| 261 | +블로그를 다 만들었다고 해도 과언이 아니지만, 아직까지 ip 주소를 기반으로 접속을 진행해야 한다는 불편이 존재한다. 이를 해결하기 위해 적절한 도메인을 구매하고 이를 DNS 레코드에 추가하는 작업을 수행해보자. |
| 262 | + |
| 263 | +우선적으로 가비아나 Route53에서 제공하는 도메인을 구매하자. 결제는 어렵지 않으니 생략한다. 결제를 진행하고나면 해당 도메인을 route53등의 DNS 서비스에 등록하면 된다. |
| 264 | + |
| 265 | +호스팅 영역을 추가하자. |
| 266 | + |
| 267 | + |
| 268 | + |
| 269 | +영역을 추가하고 나면 레코드를 추가하면 된다. 내가 보유하고 있는 도메인 명을 입력하고 이와 매핑할 EC2의 퍼블릭 ip를 넣어준다. 이제 접속을 진행해보자. |
| 270 | + |
| 271 | + |
| 272 | + |
| 273 | +[링크](https://thinkj.in/readme.html)를 눌러보면 도메인을 통해 정상적으로 접속이 진행되는 것을 확인해볼 수 있다. |
| 274 | +___ |
| 275 | +### SEO를 통해 내 사이트 노출하기 |
| 276 | + |
| 277 | +사이트를 배포했다면 이제 검색엔진 등을 통해 사람들이 접속 가능하게 해야한다. 내 사이트를 검색엔진에 노출 시키기 위해선 다음과 같은 작업을 진행해야 한다. 우선 구글 [웹 마스터](https://search.google.com/search-console?hl=ko&resource_id=sc-domain:thinkj.in)도구로 이동한다. |
| 278 | + |
| 279 | +특정 사이트에 대한 웹 마스터 권한을 확보하기 위해서는 도메인에 TXT 레코드를 추가해 구글에서 명시한 별도의 값을 입력해주면 된다. (복잡하지 않다) |
| 280 | + |
| 281 | +이제 색인을 생성해보자. 구글이 내 사이트를 찾게 하기 위해선 색인을 등록해주면 된다. 색인 등록을 위해선 웹 마스터 도구에서 상단에 위치한 상단 바 메뉴를 활용하면 된다. |
| 282 | + |
| 283 | + |
| 284 | + |
| 285 | +내가 색인 생성을 원하는 URL을 검색한 후 구글에 색인을 생성해 달라 요청하면 구글이 색인을 생성 해준다. |
| 286 | +문제는 이러한 작업을 사이트에 존재하는 모든 페이지에 대해 진행할 수는 없다는 것이다. 이에 따라 **구글 크롤러가 자동으로 페이지를 수집할 수 있게 해야하는데 이를 위해선 사이트 맵을 작성할 필요가 있다.** |
| 287 | + |
| 288 | +>[! 사이트 맵이란?] |
| 289 | +>**사이트 맵은 크롤러가 사이트의 구조를 파악 가능하게해 더 명확한 크롤링을 가능하게 해준다.** |
| 290 | +
|
| 291 | +```xml |
| 292 | +<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.sitemaps.org/schemas/sitemap/0.9 http://www.sitemaps.org/schemas/sitemap/0.9/sitemap.xsd"> |
| 293 | +<!-- created with Free Online Sitemap Generator www.xml-sitemaps.com --> |
| 294 | +<url> |
| 295 | +<loc>https://thinkj.in/readme.html</loc> |
| 296 | +<lastmod>2024-07-11T07:26:23+00:00</lastmod> |
| 297 | +</url> |
| 298 | +</urlset> |
| 299 | +``` |
0 commit comments