1. 상황
- 장고 어드민에서 이미지 벌크 업로드 시도
- 413 request entity too large 에러 발생
2. 시행착오
1) .platform
ec2 인스턴스 AMI 가 아마존 리눅스2 인 경우에는
프로젝트 최상단 경로에 .platform 으로 지정해야 한다는 의견이 많았다.
특히,
아래 링크의 한국인 개발자가 적어주신 자료로 인해 .platform 이라는 확신을 갖었었다.
https://whitekiwi.medium.com/413-request-entity-too-large-error-179e52aa6d7a
하지만,
ssh로 ec2 인스턴스에 직접 접속해서
/etc/nginx/conf.d/ 디렉토리 내에
client_max_body_size 관련 내용이 담긴 파일이 반영됐는지 확인했지만,
변함이 없었다.
2. elasticbeanstalk 디렉토리 추가 생성
자료를 보니 .platform/nginx/conf.d/elasticbeanstalk/
elasticbeanstalk 디렉토리를 추가 생성하고 그 안에 config 파일을 저장하라는 의견도 있었다.
하지만 이 역시 나에게 해당되지 않았다.
3. 솔루션
내가 적용하여 해결한 방식은 이렇다.
1) .ebextensions
프로젝트 최상단 경로에 .ebextensions 디렉토리를 생성했다.
그리고 그 디렉토리 내에는 00_nginx.config 파일만 있는 구조다.
- 00_nginx.config 파일
files:
"/etc/nginx/conf.d/01-increase_body_size.conf":
mode: "000644"
owner: root
group: root
content: |
client_max_body_size 50M;
container_commands:
nginx_reload:
command: "sudo service nginx reload"직접적인 도움을 준 출처는
https://medium.com/swlh/using-ebextensions-to-extend-nginx-default-configuration-in-aws-elastic-beanstalk-189b844ab6ad
2) 프론트엔드 빈스톡 파일에도 적용
백엔드 서버의 퍼블릭 주소로 장고 어드민에 접속했다.
그 상태에서 바로 이미지 여러장(9MB)을 업로드하니
업로드가 되는걸 정말 우연히 확인하게 됐다.
그 말은, 백엔드 서버의 reverse proxy의 max_size는 상향됐다는 것이다.
따라서, 프론트엔드 서버의 reverse proxy 역시 동일하게 적용하면 되는 일이다.
프론트엔트 서버의 코드 역시 파일 최상위 경로에
.ebextensions 디렉토리를 생성했다.
그리고 그 안에 백엔드 코드와 동일하게 파일을 생성해주었고
배포했다.
- 00_nginx.config 파일
files:
"/etc/nginx/conf.d/01-increase_body_size.conf":
mode: "000644"
owner: root
group: root
content: |
client_max_body_size 50M;
container_commands:
nginx_reload:
command: "sudo service nginx reload"문제는 해결됐다.
아직 해소되지 않은 의문점이 있다.
아마존 리눅스2 AMI 를 사용하고 있기에
아마존 공식문서에서 말하듯 .platform 폴더를 생성해야 하는 것이
오피셜이다.
하지만 시행착오로는 그렇지가 않았다.
의문점 해소 완료
AWS에 접속해서 beanstalk 서비스를 대시보드에서 클릭해보자.
그리고 확인하고 싶은 beanstalk을 클릭하면 아래 그림과 같이 나온다.
즉, 처음 클라우드 인프라를 구축한 개발자가
초기에 어떤 AMI를 지정하여 구축했는지 확인할 수가 있는 것이다.
아래 그림처럼 Amazon Linux의 2.16.2버전이므로
.ebextensions 디렉토리를 사용해야 하는 것이 맞았다.
