* 본 포스팅은 학습 과정에 대한 기록이므로 정확하지 않은 정보가 많이 포함되어 있을 수 있습니다.
블로그 기반 학습은 정말 위험합니다. 참고용으로만 사용하시고 오류가 있으면 알려주세요.
이 글을 시작하기 전에 이 글은 맨바닥에서 시간을 낭비한 것이 정말 후회되어 나중에 볼 수 있도록 그냥 녹음하는 것을 목적으로 작성되었습니다. 따라서 정확한 정보가 없음을 알려드립니다.
먼저 이 글의 결론부터 말씀드리겠습니다. 차근차근 배우지 않으면
커스텀 EC2 전용
aws Elastic Beanstalk 정말 좋은데 더 추상적이고 단순해서 장난이 아니라서 하루 이틀 써봤습니다. 설정 변경, 로그 보기, 수정, 배포, 권한 부여, AWS 설정 터치무한 반복을 하면서 EC2를 사용하는 방법을 배웠기 때문에 좀 더 일찍 이상한 결론에 도달했다고 생각하십시오.
먼저 aws에 대한 간략한 소개 Elastic Beanstalk는 aws에서 제공하는 클라우드 서비스 중 하나로 모두에게 익숙한 EC2와 같은 IaaS보다 조금 더 추상적인(조금 더 자동화된) 모델입니다. 경쟁사인 GCP의 앱 엔진과 비슷하다고 생각하시면 됩니다. 간단히 말해서 내가 개발한 코드가 별도의 설정 없이 즉시 배포되고 브라우저에 URL을 입력하면 즉시 서비스되는 모델너는 추측 할 수있다.
개발을 공부한다면 대부분 EC2 프리 티어를 한 번쯤은 접하게 될 것입니다. 저도 EC2를 장난감 프로젝트로 경험한 적이 있는데, 설정을 만지작거리며 하루 정도를 보냈던 기억이 납니다. 다만 EC2가 아닌 EB(beanstalk의 약자)를 사용한 이유는 처음에는 쉬웠기 때문입니다. “배포가 더 쉽기 때문에” 보지마.
EC2 쓰시는 분들은 아시겠지만 인스턴스를 생성하고 RDS로 DB에 접속해서 들어가서 설정을 하려면 윈도우 쓰시는 분들도 퍼티를 설치하시고 에디터에 대해 조금 아셔야 합니다. vim 처럼. 괜히 인프라 전문가란 없습니다. 그래서 다음에 장난감 프로젝트를 만들 때는 조금 더 간단한 배포를 해보고 싶다고 생각하고 이번에는 새 프로젝트를 만들면서 배포에 EB를 사용하기로 했습니다!
지난 이틀 동안 나는 이런 식으로 전면과 후면의 개발을 펼치려고 노력했습니다…
EB는 EC2보다 더 추상적인 모델이기 때문에 로드 밸런싱, 자동 확장 및 리소스 관리가 자동화됩니다. 따라서 모니터링도 쉬워지고 로그 보기도 쉬워집니다. 하지만 주관적으로 말하자면 개발 중인 초보자가 다음 단계를 수행하는 데 도움이 될 것이라고는 생각하지 못했습니다.것이 가능하다. 물론 인프라 관련 직종에 종사하시는 분들이라면 이런 것들을 기본 지식으로 알고 계시겠지만, 그렇지 않다면 사실 이 지식이 낯설어서 내가 이 지식을 모르기 때문에 좋지 않고 자동화되어 있기 때문에 좋지 않다는 것은 확실하다..
암튼 이제부터 EB에 대해 알게 되었고 내가 사용하고 있었다면 지금 이 시점에서 사용하고 있을 것이라고 생각했습니다. 정말 주관적이니 그냥 유머글 보듯이 보시고 욕먹고싶은거 아니면 안보시는걸 추천드립니다.
EB에서 생각하고 추천한 불편한점
* 다시 한번 말씀드리지만 지극히 주관적인 의견입니다.
EB는 AWS 공식 문서에 소개되어 있습니다.
Elastic Beanstalk를 사용하면 애플리케이션이 실행 중인 인프라의 세부 정보를 몰라도 AWS 클라우드에서 애플리케이션을 신속하게 배포하고 관리할 수 있습니다… (생략)
보지마. 그리고 정보를 찾을 때 처음으로 개발한 소프트웨어를 배포하는 것만큼 좋은 것도 없습니다. 참조에 사용 방법을 보여주는 YouTube 비디오를 첨부했습니다. 그러니 궁금하신 분들은 확인하시면 됩니다.
하지만 조금 더 깊이 파고들면 그렇게 간단하지 않습니다. 제가 말씀드릴 내용은 제가 이전에 말했듯이 매우 주관적이며 주니어 수준에서 경험하고 글을 쓰기에 정보가 정확하다고 보장할 수 없습니다.
1. Docker를 미리 알고 있어야 합니다(그리고 그것에 대해 조금 더)
사실 이 부분은 학습의 꽤 좋은 부분이 될 수 있습니다. 그러나 그것이 쉬운 사용의 요점이 아니라고 생각하기 때문에 언급합니다. EB에서 애플리케이션을 구축할 때 지원되는 플랫폼, 즉 지원되는 언어가 여러 개 있습니다.
사실 많다면 많다고 할 수 있고, 주로 사용하는 언어는 다 있다. 하지만 문제는 둘 이상의 언어로 된 프로젝트는 사용할 수 없습니다. 그것은 내 프로젝트가 전면에 React로, 후면에 Spring Boot로 개발되었다는 것을 의미합니다. 그렇다면 내 프로젝트는 Node.js와 Java라는 두 가지 언어를 사용했겠죠? 그런데 이 경우 아무리 찾아봐도 EB에 파일을 올릴 수 있는 쉬운 방법이 없습니다.
MSA(Micro Service)에 대해 들어보셨을 수도 있지만 그렇게 멀리 갈 필요는 없습니다. 일반적으로 애플리케이션이 약간 성장하면 모듈이 기능 단위로 분할되고 개발 중에 프런트엔드와 백엔드가 무조건 분리됩니다.
(뭐, Node.js로 서버를 구성하면 같은 언어로 개발할 수 있는데 찾아보니 설정부터 포트까지 일일이 손으로 만져야 할 것 같네요…)
EB는 NginX 웹 서버를 사용합니다. 그래서 그냥 제 프로젝트 기준으로 넣으면 Browser > (React) > NginX > (Spring Boot) > (DB) 순으로 구성되겠죠? 뭐 DB, 자바 내장 DB인 h2 같은 걸 어떻게든 스프링부트에 집어넣거나 따로 RDS를 써도 상관없겠지만 리액트가 아니다.
따라서 이 경우 (아마도) Docker를 플랫폼으로 사용해야 합니다.
Docker는 컨테이너 기반 가상화 플랫폼입니다. 컴퓨터에서 Windows로 가상머신을 한번쯤은 실행해보셨을텐데 정말 간단한 방법으로 가상머신입니다. 컨테이너 기반의 이미지를 사용하고 계층의 개념을 적용하면 가상 머신이 용량을 정말 대폭 줄인다고 쉽게 생각할 수 있습니다.
여하튼 EB에서 Docker를 사용하기 위해서는 Dockers Push and Build의 기초를 알아야 하고, aws.json 파일이나 Dockerfile, docker-compose나 aws ECR을 만드는 방법도 알아야 하므로 기초가 안된 작거나. .
Docker를 아는 것은 물론 매우 유용합니다. Docker 사용법을 알면 자신의 환경에 Docker만 설치하더라도 다른 언어 버전이나 용량이 있는 도구를 설치하지 않고도 빌드하고 테스트할 수 있습니다. EC2를 사용하는 경우에도 Docker 사용 방법을 알면 지루한 설정을 많이 줄일 수 있습니다.
하지만 초보자들은 배포를 가볍게 여기기 위해 EB를 사용하는데, 갑자기 도커 공부를 시작하는 것도 조금 이상해 보이지는 않는다. 도커의 기본은 처음부터 알고 있었고, 이것저것 만져보니 더 많이 배운 것 같은 느낌이 들지만 그렇지 않다면…
아무튼 결론 한 언어로 코드를 쉽게 작성했는데 인프라 관련 지식이 더 없어도 쉽게 사용하고 싶다! 이 사람들은 EB를 강력히 추천합니다하지만 그 이상이면 솔직히 그렇게 생각하지 않습니다. 쉬운 가이드를 위해 참조의 YouTube 비디오를 시청할 수 있도록 업로드했습니다. Docker를 플랫폼으로 사용하는 예는 나중에 언급됩니다.
2. 조금 더 깊이 들어가려고 하면 알아야 할 것은 너무 많은데 관련 자료가 거의 없다.
언급하기 전에 보여드릴 이미지는 제가 AWS IAM 사용자에게 부여한 권한 정책입니다.
이러한 권한을 한 번에 모두 부여하지 않고 배포 프로세스 중에 권한이 거부될 때마다 한 번에 하나씩 추가했습니다. 프리 티어를 사용하는 IAM 사용자에게는 총 10개의 자격이 허용되며 이틀 만에 모두 채웠습니다. 개발할 때 루트권한 같은 정책이 있는지 확인했는데 그런 정책이 있긴 한데 AWS에서 추천하지 않는 정책이고 그것 때문에 수천만 원이 들기 때문에 설정하지 않았습니다. 보안 침해가 발생할 수 있으므로 증가했습니다. 물론 EC2와 마찬가지로 VPC와 S3에 대해 알아야 합니다.
또한 EB를 사용하려면 CLI를 통해 약간 복잡한 명령을 내려야 하므로 aws cli와 eb cli를 모두 설치했습니다. aws CLI를 사용하려면 보안 로그인 키와 자격 증명 암호를 가져와 구성해야 합니다. 그래서 저도 받았습니다. 수동으로 EB를 사용하기 위해 eb cli를 설치했는데 파이썬으로 내장되어 있어서 중간에 virtulalenv 에러가 나서 좀 고생했습니다.
AWS에는 훌륭한 서비스가 많이 있습니다. 물론 우리가 자주 듣는 외부 서비스는 모두 유사한 모델을 가지고 있습니다. EB cli 사용 시 로그를 보니 호환성 때문인지 설정 문제인지 헷갈리네요. 그래서 공부한 것들이 있습니다.
Docker를 사용하는 경우 Docker Hub를 알고 있습니다. 이 Docker Hub를 공개 github 저장소로 쉽게 생각할 수 있습니다. 여기에서 이미지를 푸시하면 Docker가 설치된 모든 곳에서 이미지를 가져와서 사용할 수 있습니다. 그러나 AWS에는 ECR이라는 Docker Hub와 같은 공통 리포지토리가 있습니다. 이 ECR을 사용하는 방법은 Docker Hub와 동일한 태그로 태그를 지정하고 푸시(Push) 및 풀(Pull)하는 것입니다.
똑같은데 다른 설정 명령어가 있어서 이것저것 확인해봤습니다.
물론 깃허브는 다들 알고 계시겠지만, codeCommit은 AWS에서도 가능합니다. 마찬가지로 방법은 일반적인 git push와 동일하지만 다시 설정해야 합니다.
EC2와 S3를 제외하고는 이 AWS 관련 정보에 대한 한국어 레퍼런스가 거의 없습니다. 그래서 지난 이틀 동안 AWS 설명서와 Stack Overflow를 수없이 들락날락했던 것 같습니다. 하지만 이 AWS 관련 정보를 찾는 데 이틀을 허비하지 않았습니다.
로그도 꽤 골칫거리였는데 솔직히 개발하면서 스택 트레이스를 확인해보면 오류나 예외가 발생해도 친절하게 오류 이름과 예상 위치를 알려주고 IntelliJ도 디버깅을 잘한다. 그러나 EB에서 오류가 발생하면 eb-engine.log 파일만 참조할 수 있습니다.
뭐, 로그를 보면 에러를 다 알려준다고 할 수 있는데 도커로 배포할 때 뜨는 에러를 읽어보면 그게 다다. ‘Docker 배포에 문제가 있습니다.’말이 좀 멉니다. 개발과 마찬가지로 예외의 이름과 위치를 알려주지 않습니다.
이러한 프로토콜이 의미있게 변경되는지 확인하기 위해 React를 별도로 빌드 및 배포하고 Spring을 별도로 빌드 및 배포하고 지속적으로 포트를 변경하고 Hub, ECR 및 CodeCommit에서 각 배포 방법과 파일을 직접 가져와서 압축 및 업로드를 시도했습니다. . .
여태까지 내가 부딪힌 장애물에 대해 많이 이야기한 것 같은데 이런 쓸데없는 말을 쓰는 이유는 사전 지식 없이 현장으로 직접 이동하여 EB를 사용하지 마십시오.그렇게 해 주셨으면 합니다. 그래서 EB를 심도 있게 써야 한다면 강의를 차근차근 따라가거나 선배의 도움을 받을 때 하세요.
여전히 EB와 Docker를 사용해야 하는 경우
사실 처음에는 별거 없을 줄 알았고 Docker-Compose로 개발한 모든 코드를 쉽게 배포할 수 있게 하고 싶었는데 CI/CD도 자동화해야 할까요? 그렇게 하다가 이틀이 지난 지금은 그냥 포기하고 EC2를 써보려고 합니다.
EB에서 Docker를 사용할 때 이것이 왜 그렇습니까? EB가 자동화하는 부분에서 오류가 발생하면 피상적인 지식으로는 절대 해결할 수 없으며 문제가 무엇인지 알 수 없습니다(아마도).
내가 아는 EB에서 Docker를 사용하여 배포하는 데는 세 가지 프로세스가 있습니다.
1. 이미지를 Docker Hub 또는 ECR => dockerrun.aws.json으로 끌어서 배포
2. dockerfile => dockerfile로 직접 배포
3. docker-compose.yml로 배포 => 설정 필요
사실 Docker에 익숙한 사람이라면 이 세 프로세스 사이에 교차점이 있다는 것을 알고 있습니다. Docker-Compose를 사용하더라도 허브에서 pull deploy를 하고 Compose에서 직접 Dockerfile을 빌드 및 배포하는 등이 가능합니다. 그런데 3단계로 나눈 이유는 EB에서 인식하는 파일이 되기 때문입니다.
EB에서 Docker를 플랫폼으로 선택하면 처음 두 가지 옵션이 있습니다. 파일을 직접 업로드하고 s3 url을 사용하십시오. 여기에서 s3 URL을 사용하려면 먼저 연결된 AWS 설정을 다시 연구해야 합니다. 그래서 파일을 직접 업로드하는 것에 대해 이야기하고 있습니다.
EB에 업로드할 수 있는 파일 유형에는 제한이 없지만 조건이 필요합니다. 확실히 EB는 dockerfile 또는 dockerrun.aws.json을 인식합니다.당신은 할 수 있어야합니다. 이런 조건 때문에 docker-compose 사용을 사실상 포기했는데 어떻게 설정을 바꿔도 직접 파일을 업로드하면 EB에서 docker-compose.yml을 인식하지 못했습니다. 그래서 Github action이나 Jenkins를 이용해서 코드를 push하는 스크립트를 이용해서 배포를 해봤지만 이것도 계속 오류가 발생했고 이를 해결하기 위해 여러가지 시도를 해보았지만 잘 되지 않았습니다.
* 사실 이 부분은 제 미숙한 부분일 가능성이 높으니 글을 읽어보시고 해결 방법을 아시는 분은 이 문단에 대해 적극적으로 비판해주시면 감사하겠습니다…
그래서 결국 나는 모든 것을 시도했고 내가 얻은 최선의 방법은
1. 필요한 이미지를 Docker Hub에 푸시합니다.
2. dockerrun.aws.json을 작성하여 가져올 이미지를 생성하고 열 포트를 지정합니다.
3..EB에서 작성한 Dockerrun.aws.json 파일만 업로드합니다.
dokrrun.aws.json 파일은 특별하지 않으며 다음과 같습니다.
{
"AWSEBDockerrunVersion": "1",
"Image": {
"Name": "kth1017/testw1", // hub에 올려놓은 image
"Update": "true"
},
"Ports": (
{
"ContainerPort": "8080"
}
)
}작성만 하면 끝입니다. 이렇게 작성하고 아래와 같이 EB에 업로드하면 끝입니다.
이 방법이 최고라고 생각한 이유는 여러가지가 있지만 가장 큰 두가지는
1. 전에 쓴 것처럼 도커 허브에서 이미지를 가져오므로 다른 파일을 압축하여 업로드하지 않고 하나의 docrrun.aws.json 파일만 업로드할 수 있습니다.
2. 업로드된 파일에는 dockerfile과 docker-compose.yml이 포함되어 있지 않으므로 어떤 파일에서 오류가 발생했는지, 어떻게 설정을 변경해야 하는지 검색하지 않고 json만 수정하면 됩니다.
이렇게 될 수 있습니다. 물론 Docker 전문가라면 AWS에서 제공하는 로그를 보고 어디가 문제인지 유추할 수 있지만 그렇지 않다면 이 방법이 가장 좋다고 생각합니다.
앞서 언급한 EB 소개 영상은 공식문서라거나 스택오버플로에서 파편화된 정보라 크게 의미가 없을 것 같아서 올립니다.
나타내다
https://www.youtube.com/watch?v=cOUhREAWJNw