낭중지추

글 개요

기존에 EB로 배포된 웹에 SSH로 접속하여 Nginx 설정을 수정하고 SSL 인증서를 수동으로 적용했던 과정을 자동화된 방식으로 전환하였습니다. AWS Elastic Beanstalk에서 SSL 인증서를 자동으로 설정하는 방법과 그 과정에서의 시행착오, 해결 방법을 정리했습니다.

기존 방식

0. 다운로드 받은 pem 키 권한 부여 (SSH초기 접속시)

% chmod 400 YourPemKeyName.pem

1. SSH 접속

% ssh -i ~/Downloads/YourPemkeyName.pem ec2-user@Your-IP

2. SSL 수동 설정

% sudo nano /etc/nginx/conf.d/ssl.conf

server {
    listen 443 ssl;
    server_name YourSeverName;

    ssl_certificate /etc/letsencrypt/live/YourSeverName/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/YourSeverName/privkey.pem;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;

    location / {
        proxy_pass http://localhost:8080;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
    }

    access_log /var/log/nginx/access.log main;
}

이 server 블록은 Nginx가 HTTPS(SSL)를 통해 요청을 수신하고 백엔드 서버로 전달(proxy) 하도록 설정하는 구성입니다.

접근 로그를 /var/log/nginx/access.log에 기록합니다. 

sudo nano /etc/nginx/conf.d/redirect.conf

server {
    listen 80;
    server_name YourServerName;

    return 301 https://$host$request_uri;
}

3.  Nginx 문법 검사, 재시작

sudo nginx -t 
sudo systemctl reload nginx 
sudo systemctl restart nginx

4. 포트 443이 열려 있고 Nginx(또는 다른 서비스)가 이 포트를 리슨 중인지 확인

sudo netstat -tulpn | grep :443

👀 Elastic Beanstalk는 배포할 때 EC2 인스턴스를 처음부터 다시 생성하거나 덮어쓰기 때문에 /etc/nginx/conf.d/ssl.conf 파일을 수동으로 만들고 저장해도 다음 배포 때 사라집니다.

그래서 .platform/hooks/postdeploy/ 스크립트를 사용하여 배포했습니다.

이 스크립트는 배포가 끝난 뒤에 SSL 설정 파일을 /etc/nginx/conf.d/로 다시 복사하고 nginx를 재시작하게 해주는 역할입니다.

개선 방식

0. 파일 구조

/project-backend-root
├── .platform
│   ├── hooks
│   │   └── postdeploy
│   │       └── 01_reload_nginx.sh
│   └── nginx
│       └── conf.d
│           ├── ssl.conf
│           └── redirect.conf

1. 01_reload_nginx.sh 스크립트

#!/bin/bash

cp .platform/nginx/conf.d/*.conf /etc/nginx/conf.d/
nginx -t && systemctl reload nginx

🔍 각 줄 설명

#!/bin/bash
//이 스크립트가 bash 셸에서 실행되어야 한다는 것을 명시합니다 (리눅스 스크립트의 표준 시작 줄)

cp .platform/nginx/conf.d/*.conf /etc/nginx/conf.d/
	•	.platform/nginx/conf.d/ 디렉터리에 있는 .conf 파일들을 Nginx의 설정 디렉터리인 /etc/nginx/conf.d/로 복사합니다.
	•	즉, ssl.conf, redirect.conf 같은 Nginx 설정 파일들을 실제 서버 설정 위치에 반영하는 과정입니다.

nginx -t && systemctl reload nginx
	•	nginx -t: Nginx 설정 파일이 문법적으로 올바른지 테스트합니다.
	•	&&: 앞의 명령어가 성공했을 때만 뒤 명령을 실행합니다.
	•	systemctl reload nginx: 설정이 문제 없으면 Nginx를 재시작하지 않고 리로드해서 설정을 적용합니다 (서비스 중단 없음).

2. ssl.conf, redirect.conf 파일 안에 기존과 동일하게 sever 내용을 작성해주면 됩니다.

3. 해당 스크립트 파일에 실행권한을 부여

chmod +x .platform/hooks/postdeploy/01_reload_nginx.sh

chmod +x .platform/hooks/postdeploy/01_reload_nginx.sh는 Elastic Beanstalk 인스턴스 내에서 이 스크립트를 실행 가능하도록 권한을 부여하는 명령어. 로컬에서 압축 전 한번만 실행해도 됩니다.

이제 수동으로 SSH 접속하여 설정하지 않아도 돼서 훨씬 편하네요.. 😉👍

더 좋은 의견이나 다른 견해가 있으시면 댓글 남겨주세요. 감사합니다!

개발하고 있던 웹프로젝트에 meta API를 라이브 모드로 사용하기 위해서 ssl을 발급받아 https로 변경해주려고 합니다.

1. PEM 키 파일 설정 및 SSH 접속

먼저 AWS에서 발급받은 PEM 키 파일의 권한을 설정합니다:

(.pem키가 다운로드 항목에 있다면)

chmod 400 ~/Downloads/펌키이름.pem

이후 SSH 접속 시도:

ssh -i ~/Downloads/펌키이름.pem ec2-user@e2c퍼블릭IP

2. Certbot 및 Nginx 설치

Amazon Linux 2023 기준으로 Certbot 및 Certbot-Nginx 플러그인을 설치합니다:

sudo yum install -y certbot python3-certbot-nginx

sudo nginx -v으로 설치되어있는가를 확인 후,

3. Nginx 시작 및 부팅 시 자동 실행 설정

sudo systemctl start nginx
sudo systemctl enable nginx

4. SSL 인증서 발급 (Let's Encrypt)

sudo certbot --nginx -d 도메인주소 -d www.도메인주소

저는 www 도메인 등록을 안 해둬서 www는 제외하고 발급받았습니다.

/etc/letsencrypt/live/도메인주소/ 경로에 인증서 저장됨 

5. 인증서 갱신 테스트 및 자동화

갱신 시뮬레이션 테스트

sudo certbot renew --dry-run

Crontab을 이용한 자동 갱신 설정

sudo crontab -e

파일을 만들어 아래 내용 입력 후 저장

0 3 * * * certbot renew --quiet --nginx

매일 새벽 3시에 갱신 시도

6. HTTP -> HTTPS 강제 리디렉션 설정

다음 내용을 /etc/nginx/conf.d/redirect.conf 파일에 작성:

server {
    listen 80;
    server_name 도메인주소;

    return 301 https://$host$request_uri;
}

설정 확인 및 Nginx 재시작:

sudo nginx -t
sudo systemctl reload nginx

도메인으로 보안 연결이 정상 작동하며 인증서 자동 갱신까지 설정 완료

이제 https로 접속 시도해보고 정상 작동함을 확인하면 됩니다 !

AWS Elastic Beanstalk 또는 EC2에 배포한 후 웹사이트를 실행했을 때 502 Bad Gateway 오류가 발생하는 경우가 있습니다. 이번 글에서는 환경 변수 설정 누락으로 인해 발생한 문제의 원인과 해결 방법을 정리하겠습니다.

1️⃣ 문제 상황

📍 배포 후 오류 발생: 배포가 정상적으로 완료되었지만, 웹사이트 접속 시 502 Bad Gateway 오류가 발생함.

📍 로그 확인 (web.stdout.log) AWS 인스턴스 내부의 web.stdout.log 파일을 확인한 결과, 환경 변수를 찾을 수 없다는 오류가 발생.

2️⃣ 문제 원인

1. .env 파일이 포함되지 않음

Mac에서는 .env 파일이 숨김 파일로 처리됩니다. 이로 인해 배포할 때 .zip으로 압축할 때 .env 파일이 포함되지 않으면 환경 변수가 적용되지 않는 문제가 발생할 수 있습니다.

2. AWS Elastic Beanstalk에서 환경 변수가 설정되지 않음

AWS에서는 환경 변수를 별도로 지정하지 않으면 시스템에서 인식하지 못할 수 있습니다.

3️⃣ 해결 방법

✅ 1. AWS 환경 변수 설정하기 (배포 전)

AWS Elastic Beanstalk을 사용할 경우, 배포 전에 환경 변수를 설정하는 것이 가장 좋은 방법입니다.

📌 환경 변수 설정 방법

1. AWS Elastic Beanstalk 콘솔 접속
2. 환경 → 구성(Configuration)
3. 환경 속성(Environment Properties) 섹션에서 KEY=VALUE 형식으로 환경 변수 추가
4. 저장 후 배포 다시 진행

✅ 2. 배포 후 환경 변수 추가하기

만약 .env 파일이 누락된 상태로 배포되었다면, 배포 후 환경 변수를 직접 추가할 수도 있습니다.

📌 배포 후 환경 변수 설정 방법

1. AWS Elastic Beanstalk 콘솔 접속
2. 환경(Environment) → 구성(Configuration) 선택
3. 소프트웨어(Software) → 환경 속성(Environment Properties) 섹션으로 이동
4. 누락된 환경 변수를 추가하고 저장
5. 애플리케이션을 다시 시작 (eb restart 또는 콘솔에서 재시작)

결론

AWS 배포 후 502 Bad Gateway 오류가 발생하는 주요 원인은 환경 변수가 설정되지 않았기 때문입니다. 이를 해결하기 위해:

1. 배포 전에 환경 변수를 AWS Elastic Beanstalk 환경 속성에 추가
2. 배포 후 AWS 콘솔에서 환경 변수를 추가 및 적용
3. .env 파일을 배포 시 포함하거나 .ebextensions/env.config 파일을 활용

대전 빵지도 웹사이트를 개발하고 테스트하는 도중 이미지의 용량이 클 경우 (사실 그렇게 크지도 않음..) 업로드가 실패하는 버그가 발생.

이번 글에서는 AWS Elastic Beanstalk 환경에서 발생한 413 Request Entity Too Large 오류의 원인과 해결 방법에 대해 공유하려 합니다.

1️⃣ 문제 배경

📍 문제 상황: 대전 빵지도 웹사이트를 개발 및 테스트하는 도중, 특정 크기 이상의 이미지를 업로드하면 업로드가 실패하는 문제가 발생했습니다.

• 오류 코드: 413 Request Entity Too Large
• Content-Type: text/html
•  문제: 서버가 JSON이 아닌 HTML을 응답함.

📍 브라우저 네트워크 로그:

Request Method: PATCH
Status Code: 413 Request Entity Too Large
Referrer Policy: strict-origin-when-cross-origin
content-type: text/html

2️⃣ 문제의 원인

1. 파일 크기 제한 (client_max_body_size)

AWS Elastic Beanstalk 환경에서 Nginx의 기본 설정으로 인해, 파일 크기가 1MB를 초과하면 업로드가 제한됩니다.

• Nginx의 기본 client_max_body_size 값이 1MB로 설정됨
• 설정을 변경하지 않으면 AWS에서 기본값이 유지됨

2. Elastic Beanstalk 환경에서 Nginx 설정이 자동으로 덮어씌워짐

• /etc/nginx/nginx.conf를 직접 수정해도 재부팅하면 원래 설정으로 복구될 가능성이 있음
• Elastic Beanstalk 환경에서는 프록시 설정 파일을 수정해야 함 (/var/proxy/staging/nginx/nginx.conf)

3. Node.js (Express) 자체의 요청 크기 제한

• Express의 기본 요청 크기 제한은 100KB
• JSON 요청을 받을 경우 express.json({ limit: "100mb" }) 설정이 필요
• 현재 FormData로 전송 중 → express.urlencoded({ limit: "100mb", extended: true }) 설정 추가 필요

3️⃣ 해결 방법

📌 AWS Elastic Beanstalk에서 Nginx 설정 수정하기

✅ 1. SSH로 Elastic Beanstalk EC2 인스턴스 접속

ssh -i [your-key.pem] ec2-user@[your-ec2-ip]

✅ 2. Nginx 설정 파일 수정

Elastic Beanstalk 환경에서는 다음 두 개의 설정 파일을 수정해야 합니다.

(1) /etc/nginx/nginx.conf 수정

sudo nano /etc/nginx/nginx.conf

설정 파일의 http {} 블록 안에 아래 내용을 추가

http {
    ...
    client_max_body_size 100M;
    ...
}

수정 후 저장: Ctrl + X → Y → Enter

(2) /var/proxy/staging/nginx/nginx.conf 수정 (Elastic Beanstalk 환경 필수)

sudo nano /var/proxy/staging/nginx/nginx.conf

파일에 아래 내용 추가

client_max_body_size 100M;

✅ 3. Nginx 설정 적용 (재시작)

파일 수정 후, Nginx를 다시 로드하면 됩니다.

sudo systemctl restart nginx
sudo nginx -t

4️⃣ Express에서 요청 크기 제한 해제

Nginx 설정을 변경했어도 Express가 요청 크기를 제한하고 있다면 해결되지 않을 수 있습니다.

서버의 server.js 또는 app.js 파일을 수정

const express = require("express");
const app = express();

// 요청 크기 제한 해제
app.use(express.json({ limit: "100mb" }));
app.use(express.urlencoded({ limit: "100mb", extended: true }));

🔥 해결 방법 요약

• Nginx client_max_body_size 값을 100MB로 확장
• Elastic Beanstalk 프록시 설정 파일에도 동일한 설정 적용
• Express의 요청 크기 제한 해제 (express.json() 및 express.urlencoded() 설정)
• Nginx 설정을 저장하고 재시작

대전 빵집 지도 웹사이트 🍞 구경하고 가세요 ㅎㅎ

http://daejeonbread.shop/

참고

AWS Elastic Beanstalk로 생성한 EC2에 SSH 접속하기

https://sig03.medium.com/aws-elastic-beanstalk%EB%A1%9C-%EC%83%9D%EC%84%B1%ED%95%9C-ec2%EC%97%90-ssh-%EC%A0%91%EC%86%8D%ED%95%98%EA%B8%B0-6727dea20775