분류 기타

AWS에 freeCodeCamp 프로젝트를 배포하는 방법 – 클라우드에 대한 초보자 안내서

컨텐츠 정보

  • 조회 614 (작성일 )

본문

2017 년 6 월 어느 날 밤, 나는 freecodecamp.org라는 웹 사이트를 우연히 발견했습니다. 나는 경력 변화를 찾고 있던 당시 교사였습니다. 하지만 프로그래머가 되는 것은 내 손이 닿지 않는 곳이라고 생각했습니다.


결국, 나는 스스로를 수학 전문가라고 생각하지 않았고, 컴퓨터 과학 학교에 가지 않았으며, 코딩을 하기에는 너무 늙었다 고 느꼈습니다.


고맙게도 freeCodeCamp는 제가 개발자가 되기 위한 첫 걸음을 내딛는 데 도움이 되었고, 저는 곧 이러한 자기 제한적인 생각을 모두 버리게 되었습니다.


이제 삼성 소프트웨어 엔지니어이자 3 회 인증 된 AWS 개발자로서 저는 freeCodeCamp 커리큘럼을 통해 작업 한 밤과 주말을 되돌아 보며 성공적인 업무 전환과 프로그래머로서의 업적에 대한 주요 기여자로 간주합니다.


그러나 선생님의 마음이 여전히 남아있는 상태에서 다른 freeCodeCamp 학생들이 학습을 계속하고 freeCodeCamp 커리큘럼을 보완 할 수 있도록 이 게시물을 작성했습니다.


AWS, Azure 또는 Google Cloud와 같은 클라우드 컴퓨팅에 대한 익숙함은 채용 공고에서 점점 더 많이 요구되고 있습니다.


이 게시물은 아직 freeCodeCamp의 커리큘럼을 통해 작업 중인 초보자에게 방대한 클라우드 컴퓨팅 세계에 대한 간단한 소개를 제공합니다. freeCodeCamp 프런트 엔드 프로젝트 중 하나를 가져 와서 다양한 방법으로 AWS에 배포하는 방법을 보여 드리겠습니다.


즐기고 freeCodeCamp에 감사드립니다!


전제 조건 


이 게시물의 요점은 freeCodeCamp 커리큘럼의 프런트 엔드 개발 라이브러리 프로젝트 부분에서 학습 한 내용을 AWS에 배포하여 확장하는 것입니다.


따라서 전제 조건은 다음과 같습니다.


  1. 프런트 엔드 라이브러리 프로젝트 과제 중 하나 완료
  2. AWS 계정 보유 (가입하려면 여기로 이동)

프로젝트를 AWS에 배포하는 이유는 무엇입니까? 


freeCodeCamp 커리큘럼을 통해 작업하고 프런트 엔드 라이브러리 프로젝트를 완료하면 해당 프로젝트를 CodePen을 통해 제출합니다. 여기서 freeCodeCamp에는 일련의 단위 테스트가 있어 사용자 스토리를 올바르게 완료했는지 확인합니다.


색종이가 떨어지면 영감을 주는 문구가 보이면 프로젝트가 매우 자랑스러울 것입니다. 그 성과를 친구 및 가족과 공유하고 싶을 수도 있습니다.


물론 CodePen 링크를 그들과 공유 할 수 있지만 실제로 회사가 프로젝트를 완료하면 CodePen을 통해 사용할 수 있도록 만들지 않고 배포합니다. 그래서 그렇게합시다!


참고 : "배포"라고 말하면 로컬 환경 (컴퓨터, freeCodeCamp 또는 CodePen 편집기)에서 코드를 가져와 서버에 넣는 것을 의미합니다. 그저 또 다른 컴퓨터 인 그 서버는 전 세계가 귀하의 사이트에 액세스 할 수 있도록 네트워크로 연결되어 있습니다.


원한다면 집에 PC를 설치하고 적절한 네트워킹을 통해 프로젝트를 전 세계에 제공 할 수 있습니다. 또는 호스팅 회사에 가입하여 웹 사이트를 제공 할 수 있습니다.


코드를 배포하는 방법에는 여러 가지가 있지만 가장 널리 사용되는 방법 중 하나는 Amazon Web Services (AWS)와 같은 클라우드 컴퓨팅 플랫폼을 사용하는 것입니다. 다음에 더 자세히 설명합니다.


AWS 란 무엇입니까? 클라우드에 대한 간략한 소개 


Amazon Web Services (AWS)는 "클라우드 컴퓨팅 플랫폼"을 제공합니다. 많은 내용이 담긴 작은 전문 용어입니다. 포장을 풀겠습니다.


AWS는 단순히 파일 저장, 서버 실행, 음성을 텍스트로 또는 텍스트를 음성으로 변환, 기계 학습, 프라이빗 클라우드 네트워크 및 약 200 개 이상의 기타 서비스에 이르는 서비스를 제공합니다.


클라우드 컴퓨팅의 기본 아이디어는 주문형 IT 리소스를 확보하는 것입니다. 앞서 언급 했듯이 대안은 이러한 IT 리소스를 소유하는 것입니다.


소유하는 대신 클라우드 컴퓨팅 플랫폼을 사용하면 많은 이점이 있으며, 주요 이점 중 하나는 비용 절감입니다.


AWS가 제공하는 200 개 이상의 서비스를 실행하는 데 필요한 모든 물리적 IT 리소스에 대해 비용을 지불하려고 한다고 상상해보십시오. 초기 비용은 대부분의 기업이 감당할 수 없는 비용이며 엔지니어가 구성하는 데 지불 할 수 있는 비용은 더 적습니다.


또한 리소스가 주문형이므로 클라우드 플랫폼을 사용하면 IT 부서보다 ​​훨씬 빠르게 리소스를 시작할 수 있습니다.


간단히 말해 AWS와 같은 클라우드 컴퓨팅 플랫폼을 사용하면 비용과 배포 시간을 절약 할 수 있을 뿐만 아니라 보안뿐 아니라 더 많은 이점도 얻을 수 있습니다. 말할 필요도 없이 클라우드 컴퓨팅은 IT에 대한 새로운 섹시한 접근 방식이며 AWS가 선두를 달리고 있습니다.


이것이 왜 당신에게 중요합니까? 백엔드, 프런트 엔드, 웹 기술, 모바일 앱, 게임, 데스크톱 애플리케이션 등의 초점에 관계없이 개발 분야에서 경력을 쌓으려는 경우 많은 채용 공고에 클라우드 컴퓨팅 플랫폼 경험에 대한 참조가 포함되어 있습니다.


따라서 AWS와 같은 하나에 익숙해 질수록 다른 후보와 더 많이 분리됩니다.


AWS S3로 freeCodeCamp 프로젝트를 배포하는 방법 


AWS S3 란 무엇입니까? 


이 게시물을 통해 AWS에서 다양한 서비스를 사용하여 freeCodeCamp 프런트 엔드 프로젝트를 배포 할 것입니다.


첫 번째 접근 방식은 S3라는 AWS 서비스를 사용하는 것입니다. S3는 Simple Storage Solution을 의미합니다. 그 이름에서 짐작할 수 있듯이 이 서비스를 사용하면 물건,보다 구체적으로 물건을 간단히 저장할 수 있습니다.


S3에서 몇 시간 및 며칠 동안 진행되는 자습서 및 과정을 찾을 수 있습니다. 하지만 표면적으로는 물건을 보관할 수 있는 곳일 뿐입니다. 개체는 이미지 파일, 비디오 파일, 심지어 HTML, CSS 및 JavaScript 파일과 같은 것일 수 있습니다.


S3에 대해 자세히 살펴보면 S3를 사용하면 이러한 객체에 대해 많은 작업을 수행 할 수 있다는 것을 알게 됩니다. 그러나 우리 프로젝트에서는 객체를 저장하는 방법을 배우고 웹 사이트 호스팅 서비스로 S3를 사용하는 더 깊은 기능 중 하나를 살펴보고 싶습니다


맞습니다. AWS S3는 웹 사이트를 배포하는 데 사용할 수 있는 서비스입니다.


프로젝트 배포 준비 방법 


이 게시물 전체에서 Random Quote Machine 프로젝트를 사용할 것입니다. 지침에 제공된 예제의 코드를 사용하고 있습니다.


CodePen에서 CSS, HTML 및 JS 코드를 가져 와서 텍스트 편집기의 별도 파일에 넣어야 합니다.


IDE 열기 (예 : Visual Studio Code) 


CodePen 환경에서 CodePen은 CSS를 HTML 코드에 연결하고 JS 파일을 HTML에 연결합니다. S3에 배포하기 전에 이를 고려해야 하므로 먼저 로컬에서 테스트 할 것입니다.


선택한 편집기를 열고 CodePen 파일 3 개를 저장할 새 디렉터리 (폴더)를 만듭니다. 나는 무작위 인용 기계를 불렀다. 다음으로 세 개의 새 파일을 만듭니다.


  • index.html
  • styles.css
  • main.js

Visual Studio Code with three empty files 


CodePen HTML 파일을 index.html로, CodePen JS 파일을 main.js로, CodePen CSS 파일을 styles.css로 복사하십시오.


<body> </ body> 태그 확인 


CodePen에는 <body> 태그가 필요하지 않지만 이를 추가하는 것이 좋습니다. HTML 컨텐츠에 하나가 있는지 확인하십시오. 이것이 어디로 가는지 기억이 나지 않는다면 fCC 커리큘럼을 되돌아보십시오.


<link> 및 <src> 추가 


이제 Style.css 및 main.js를 index.html에 연결해야 합니다. CodePen이 더 이상 이를 수행하지 않기 때문입니다.


<body> 여는 태그 위에 <link rel = "stylesheet"href = "style.css"/>를 추가하면 styles.css의 CSS가 적용됩니다.


<body> 닫는 태그 아래에 <script src = "main.js"> </ script>를 추가하면 main.js 파일의 자바 스크립트가 index.html에 액세스 할 수 있게 연결됩니다.


사이트가 여전히 로컬에서 작동하는지 확인 


코드가 작동하는지 테스트 할 때입니다. 웹 브라우저를 열고 ctrl + o를 입력하여 브라우저에 표시 할 로컬 파일을 선택합니다. 세 개의 파일이 있는 폴더로 이동 한 다음 index.html을 두 번 클릭하여 엽니다.


모든 것이 작동하면 좋습니다! 그래도 그건 아니었어요. 내가 사용한 코드에는 SASS 스타일링이 있었기 때문에 약간의 조정이 필요했습니다.


CodePen을 통해 라이브러리를 가져온 경우 CDN을 통해 가져와야 합니다. 해당 라이브러리의 문서에 대한 간단한 Google 검색은 라이브러리를 가져 오는 방법을 찾는 데 도움이 됩니다.


프로젝트를 제대로 작동하는 데 필요한 사항을 변경하되 이 연습의 목적은 AWS S3에 웹 사이트를 배포하는 방법을 배우는 것임을 기억하십시오. 따라서 작지만 사이트가 대부분 작동하는 것으로 인해 수렁에 빠진 ​​경우 이 튜토리얼을 계속 진행하여 추진력을 유지 한 다음 나중에 CSS 또는 JS 문제를 해결하십시오.


사이트가 로컬에서 작동하면 원하는 대로 100 %는 아니더라도 AWS에 들어가 보겠습니다.


S3 관리 콘솔을 사용하는 방법 


AWS에 로그인 한 후 상단 검색 창에 "S3"를 입력한 다음 "S3 Glacier"가 아닌 "S3"옵션을 선택합니다.


AWS Management Console S3 search 


또는 검색 표시 줄 대신 "서비스"드롭 다운을 확장하여 모든 AWS 서비스 제공을 살펴볼 수 있습니다. 어느 쪽이든 S3를 클릭하겠습니다.


이제 S3 관리 콘솔이 표시됩니다. 이 같은…


The AWS S3 Management Console 



이것이 AWS가 관리 콘솔이라고 부르는 것입니다. AWS와 상호 작용하고 리소스 및 서비스를 생성하기 위한 웹 사이트 인터페이스입니다.


모든 AWS 서비스에 대한 관리 콘솔이 있지만 이 콘솔이 AWS와 상호 작용할 수 있는 유일한 방법은 아닙니다. 또한 원하는 작업을 AWS에 스크립팅 할 수 있는 CLI (명령 줄 인터페이스)도 있습니다.


버튼을 클릭하는 대신 CLI에서 클릭했을 내용을 입력합니다. 우리는 지금 콘솔을 고수 할 것입니다.


여기에서 모든 S3 버킷을 볼 수 있습니다. S3는 버킷으로 구성되며 버킷은 기본적으로 파일을 넣을 수 있는 큰 컨테이너입니다. 버킷을 컴퓨터의 드라이브로 생각하십시오 (예 : C : 드라이브). 기술적으로는 그렇지 않습니다. S3에서 라우팅 하는 방법입니다.하지만 현재로서는 이런 방식으로 버킷을 보는 것이 좋습니다.


S3 버킷 생성 


버킷 생성을 클릭합니다. 그런 다음 버킷의 고유 한 이름을 입력합니다 (공백은 허용되지 않음).


버킷 이름은 전역 적으로 고유해야 합니다. 따라서 이름이 지정된 테스트를 만들려고 한다면 이미 사용했던 사람이 세상에 있을 것이므로 사용할 수 없습니다.

Input form for creating an S3 bucket 


버킷 이름을 입력 한 후이 버킷에 대한 퍼블릭 액세스 설정 차단 섹션까지 아래로 스크롤 합니다. 모든 공개 액세스 차단 확인란의 선택을 취소 한 다음 표시되는 경고 상자를 확인하기 위해 더 아래로 확인합니다.


Public access checkbox options during create S3 bucket process 


AWS의 보안 및 권한은 긴 주제이지만 경고에서 알 수 있듯이 일반적으로 파일에 대한 퍼블릭 액세스 차단을 해제하고 싶지 않습니다.


우리의 경우 웹 사이트 방문자의 웹 브라우저가 우리의 프로젝트를 볼 수 있도록 index.html 파일에 액세스 할 수 있기를 바랍니다.


버킷 콘텐츠에 대한 액세스 차단을 해제하는 데 사용할 수 있는 다른 방법이 있지만 지금은 S3를 소개하고 AWS에 프로젝트를 배포하려는 우리의 목표에 충분합니다.


양식의 맨 아래로 스크롤 하십시오. 하단의 버킷 생성 버튼을 클릭합니다. 이름이 고유 한 경우 첫 번째 AWS S3 버킷을 만들었습니다. 축하합니다!


그 짧은 시간 안에 AWS가 네트워크에 무제한의 데이터를 저장할 수 있는 공간을 마련했다고 생각하면 정말 놀랍습니다. 맞습니다, 무제한!


버킷에 있는 단일 객체의 최대 크기는 5 테라 바이트 (행운을 빕니다)이지만 새 버킷은 원하는 만큼 저장할 수 있습니다.


버킷에 파일 업로드 


그런 다음 S3 콘솔보기로 돌아가서 새로 생성 된 S3 버킷에 대한 링크를 클릭합니다. 안으로 들어가면 업로드 버튼을 클릭합니다. 세 개의 파일 (index.html, styles.css 및 main.js)을 선택하십시오.


업로드 할 항목 목록에 이름이 표시되면 업로드 양식의 맨 아래로 스크롤 하십시오.


추가 업로드 옵션을 확장 한 다음 액세스 제어 목록 (ACL)까지 아래로 스크롤 합니다. 모든 사람 (퍼블릭 액세스)의 읽기 상자를 선택한 다음 버킷을 만들 때와 마찬가지로 아래에 표시되는 확인 상자를 선택합니다.


S3 file upload ACL options 


나머지 부분을 아래로 스크롤하고 업로드 버튼을 클릭합니다.


S3 버킷에서 호스팅 활성화 


이제 S3 버킷이 있고 파일이 있고 공개적으로 액세스 할 수 있지만 아직 완료되지 않았습니다.


기본적으로 S3 버킷은 웹 서버처럼 취급되도록 구성되지 않습니다. 대부분의 기업은 S3 버킷의 콘텐츠를 비공개로 유지하기를 원합니다 (예 : 의료 기록을 저장하는 병원 또는 재무 제표를 저장하는 은행). 버킷이 웹 서버처럼 작동하고 파일에 액세스 할 수 있는 URL을 제공하려면 설정을 조정해야 합니다.


버킷의 기본 메뉴보기로 돌아가서 속성 탭을 클릭합니다.


Main view for S3 bucket 


정적 웹 사이트 호스팅을 찾을 때까지 아래로 스크롤 한 다음 편집 버튼을 클릭합니다. 정적 웹 사이트 호스팅을 사용으로 설정 한 다음 색인 문서 및 오류 문서 유형 index.html에서 그런 다음 변경 사항 저장 버튼을 클릭합니다.


S3 Static Web Hosting Property Settings 


버킷의 속성 탭으로 돌아갑니다. 정적 웹 사이트 호스팅 섹션으로 다시 스크롤 하면 링크가 있습니다.


해당 URL을 읽으면 버킷 이름이 있음을 알 수 있습니다. 구성 중에 두 필드에 index.html을 입력하여 이 버킷의 URL이 열리면 index.html 페이지를 사용하여 로드 할 수 있다고 AWS에 알렸습니다.


S3 Properties' static hosting url 


해당 링크를 클릭하면 이제 프로젝트를 볼 수 있습니다.


문제 해결 


사이트가 로컬에서 작동했지만 S3 웹 사이트 엔드 포인트 링크를 열 때 작동하지 않는 경우 시도하고 해결해야 할 몇 가지 일반적인 문제가 있습니다.


먼저 로컬에서 작동하는 동일한 파일을 선택했는지 확인하십시오. 웹 브라우저에서 로컬 파일을 다시 열어 작동하는지 확인합니다. 로컬에서 작동하지만 S3를 통해서는 작동하지 않는 경우 다시 업로드하고 동일한 파일을 선택했는지 확인하십시오.


다음으로 버킷의 권한 탭으로 이동하여 모든 공개 액세스 차단이 꺼짐으로 설정되어 있는지 확인합니다.


마지막으로 업로드 한 파일을 삭제하고 다시 업로드하여 위에서 설명한 읽기 확인란과 확인 상자를 선택했는지 확인합니다.


여전히 문제가 있는 경우 문제에 대해 의견을 남겨 주시면 기꺼이 도와 드리겠습니다. 너무 낙심 하지 마십시오. AWS는 학습하는 데 시간이 걸릴 수 있으므로 처음에 문제가 발생하지 않는 경우 스스로 쉽게 처리하십시오.


You Did It! 


이제 CodePen URL을 친구 및 가족과 공유하는 대신 공유 할 고유 한 S3 버킷 웹 사이트 엔드 포인트가 있습니다.


물론, 여전히 나만의 맞춤 도메인은 아니지만 수천 개의 비즈니스와 동일한 방식으로 방금 웹 사이트를 배포했다는 사실을 알게 되어 기쁩니다.


이제 freeCodeCamp의 프런트 엔드 라이브러리 프로젝트와 관련된 프런트 엔드 기술을 배웠을 뿐만 아니라 웹 사이트 배포를 통해 클라우드 컴퓨팅에 대한 첫 단계를 수행했습니다. 당신은 매우 자랑스러워해야합니다!


S3에 대한 추가 정보 


웹 사이트 엔드 포인트가 되도록 S3 버킷을 구성하는 것은 S3를 사용하는 여러 방법 중 하나 일뿐입니다. 또한 S3를 사용하여 애플리케이션으로 가져올 데이터를 저장할 수 있습니다. 예를 들어 Random Quote Machine의 견적은 S3에 JSON 파일로 저장 한 다음 프런트 엔드에서 요청할 수 있습니다.


main.js 파일에 나열 될 수 있는 경우에는 이상한 조정처럼 보일 수 있습니다. 그러나 이러한 견적에 액세스 해야 하는 다른 앱이 있다면 S3가 이를 위한 중앙 저장소 역할을 할 수 있습니다.


이것은 실제로 S3를 애플리케이션 용 데이터 저장소로 사용하는 가장 일반적인 방법입니다. 또한 S3의 Glacier 옵션을 사용하여 자주 액세스하지 않을 것으로 예상되는 객체를 보관할 수 있으므로 표준 S3 버킷 구성에서 비용을 절약 할 수 있습니다.


마지막 아이디어는 S3를 사용하는 마지막 방법은 아니지만 실행 중인 애플리케이션의 로그를 S3 버킷에 저장하여 버그가 있는 경우 해당 로그를 검사하여 문제의 원인을 식별 할 수 있다는 것입니다.


사용 사례가 무엇이든 S3의 개념은 동일합니다. 우리는 객체를 버킷에 저장하고 이러한 객체에는 누가 보고, 편집하거나 삭제할 수 있는지 결정할 수 있는 권한 설정이 있습니다 (파일을 공개적으로 읽을 수 있도록 설정했습니다).


Next Up! 


앞서 언급 했듯이 AWS에는 수백 개의 서비스가 있으므로 작업을 수행하는 여러 가지 방법이 있는 경우가 있습니다. 사이트를 호스팅 하는 한 가지 방법을 살펴 보았지만 전체적으로 AWS에 더 많이 노출되는 데 도움이 되는 두 가지 더 주목할 가치가 있습니다.


AWS Elastic Beanstalk를 사용하여 freeCodeCamp 프로젝트를 배포하는 방법 


이제 AWS 클라우드 플랫폼 서비스에 대해 자세히 알아보고 AWS가 제공하는 더 많은 것을 경험할 수 있도록 코드를 배포하는 대체 방법을 살펴 보겠습니다.


특히 EC2,로드 밸런서, Auto Scaling 그룹 및 보안 그룹과 같은 몇 가지 핵심 AWS 서비스 및 리소스에 대해 소개합니다.


와, 다루어야 할 주제가 많습니다. 위의 첫 번째 부분에서는 S3 만 살펴 보았습니다. 다른 모든 서비스에 대해 어떻게 배울 수 있습니까?


고맙게도 AWS는 웹 애플리케이션의 배포 프로세스를 부트 스트랩하는 Elastic Beanstalk라는 서비스를 제공합니다. Elastic Beanstalk를 통해 freeCodeCamp 프로젝트를 배포하면 이러한 핵심 AWS 서비스 및 리소스에 대한 경험을 빠르게 얻을 수 있습니다.


download.png?resize=400%2C223&ssl=1 

AWS로 돌아 가기 전에 


1 부에서 코드를 "배포"한다는 것은 프로젝트를 수행하고 방문자가 액세스 할 수 있도록 컴퓨터를 구성하는 것을 의미한다고 설명했습니다. 클라우드 컴퓨팅 플랫폼의 좋은 점은 원하는 경우 해당 서버의 구성을 수행 할 수 있다는 것입니다.


잠시 S3 배포를 고려하십시오. 파일은 AWS 소유의 머신에 저장되었으며 AWS는 해당 컴퓨터를 index.html 페이지를 제공하고 프로젝트를 볼 수 있는 엔드 포인트를 제공하도록 구성했습니다.


S3에게 index.html 파일의 이름을 알려주는 것 외에 우리는 해당 구성을 전혀 수행하지 않았지만 여전히 배포 된 프로젝트와이를보기위한 엔드 포인트를 사용했습니다.


Elastic Beanstalk를 사용할 때 이와 유사하게 많은 구성을 처리하는 AWS가 포함됩니다. 하지만 이번에는 우리가 직접 구성하는 작업도 수행 할 것입니다.


이렇게 하면 웹 응용 프로그램을 배포하는 데있어 매우 인기 있는 대체 방법을 볼 수 있습니다. 이번에는 index.html을 "서비스"하는 코드를 추가하지만 AWS에서 하드웨어 시작을 처리하고 프로젝트를 볼 수 있는 엔드 포인트를 제공합니다.


Let’s Configure! 


index.html을 제공하기 위해 프로젝트에 일부 코드를 추가 할 것입니다. S3가 우리를 위해 이 작업을 수행했습니다.


이 튜토리얼을 위해 복제하거나 다운로드하여 사용할 수 있도록 Git 저장소를 만들었습니다. Git에 익숙하다면 자유롭게 리포지토리를 복제하고 코드 붙여 넣기로 이동하십시오. 하지만 Git에 익숙하지 않은 경우 이 저장소 다운로드 지침을 따르세요.


Repo 다운로드 



코드 붙여 넣기 


새로 다운로드 / 복제 된 폴더 (fcc-to-aws-part2 폴더라고 함)에 S3에 업로드 한 index.html, main.js 및 styles.css 파일을 붙여 넣고 싶습니다.


fcc-to-aws-part2 폴더에는 index.html, main.js 및 styles.css 파일이 비어있는 public이라는 다른 폴더가 있습니다. 계속해서 코드를 붙여 넣으십시오.


붙여 넣은 후 지금까지 모든 것이 작동하는지 확인하겠습니다.


새 브라우저 탭을 열고 ctrl + o를 입력하고 fcc-to-aws-part2 / public / index.html로 이동합니다. 새 탭에서 index.html을 엽니다. 이제 앱이 실행 중이어야 합니다.


그렇지 않은 경우 중지하고 올바른 코드를 올바른 .html, .js 및 .css 파일에 붙여 넣었는지 확인하십시오. 또한 S3 배포 중에 작동했던 것과 동일한 코드를 사용하고 있는지 확인하십시오.


이 작업을 통해 이제 fcc-to-aws-part2 폴더에 이 추가 항목이 무엇인지 논의 할 준비가 되었습니다. index.html, main.js 및 styles.css 이외의 파일을 변경하지 마십시오.


Node.js 및 Express.js로 구성 


이번에는 몇 가지 구성을 수행하겠다고 말한 것을 기억하십니까? Node.js (일명 Node)와 Express.js는 이러한 구성을 수행하기 위해 사용하는 것입니다.


freeCodeCamp에는 Node 및 Express에 대한 자습서가 있으므로 일시 중지하고 계속 진행하고 싶다면 부담없이 진행하십시오. 하지만 Node 및 Express를 사용하는 이유와 방법에 대한 간략한 소개도 제공합니다.


왜 노드를 사용합니까? 


Node.js는 서버 측 애플리케이션을위한 JavaScript 런타임입니다. 그것은 많은 전문 용어입니다. 그래서 그것을 조금 분해 해 봅시다.


"노드는 자바 스크립트 런타임입니다"– 프로그래밍 세계에서 런타임은 실행 모델입니다. 즉, 코드 실행 방법을 구현하는 프로세스입니다. 따라서 Node는 JavaScript 코드를 실행하는 방법을 구현하는 프로세스입니다.


다음과 같은 JavaScript 코드가 있을 때 :


console.log("Hello World")

Node는 해당 코드로 무엇을 해야 하는지 알고 있습니다.


"… 서버 측 애플리케이션 용"-서버에서 제공 할 코드를 배포하려고 시도하고 있으며 서버는 컴퓨터에 불과하다는 점을 기억하십시오. 또한 서버는 클라이언트와 다르며 웹 사이트의 경우 클라이언트는 웹 브라우저입니다.


웹 브라우저에서 프로젝트를 열면 브라우저가 index.html, main.js 및 styles.css 파일 읽기를 처리합니다. 맞습니다. 브라우저 (클라이언트)는 JavaScript 코드를 읽고 실행하는 방법을 알고 있으므로 console.log ( "Hello World")를 보면 무엇을 해야 하는지 알 수 있습니다.


main.js 파일은 브라우저에 의해 클라이언트 측에서 실행되는 JavaScript 코드입니다. 그러나 Node는 서버 측 JavaScript 용입니다. 그렇다면 귀하의 브라우저는 JavaScript 코드를 실행하는 방법을 알고 있지만 웹 사이트를 제공하는 컴퓨터는 JavaScript를 실행하는 방법을 어떻게 압니까? 마디.


download-4.png?resize=596%2C289&ssl=1 


따라서 "노드는 서버 측 애플리케이션을위한 자바 스크립트 런타임입니다."라는 말은 노드가 웹 브라우저와 같은 클라이언트가 아닌 서버에서 자바 스크립트 코드를 실행하는 방법을 구현하는 프로세스임을 의미합니다.


Node가 없으면 컴퓨터 / 서버는 JavaScript 코드를 실행하는 방법을 모릅니다.


왜 Express를 사용합니까? 


Node는 JavaScript 코드를 실행할 수 있는 환경 인 서버 측 런타임을 제공하지만 Express는 웹 애플리케이션 서비스를 위한 프레임 워크를 제공합니다.


S3를 통해 배포 할 때 제공하고자 하는 파일 이름 (index.html)을 S3에 알렸습니다. 이제 Express에서 제공 할 파일을 구성합니다.


경로가 다른 웹 사이트 (예 : www.example.com/home, / media, / about, / contact)가있는 경우 해당 페이지마다 다른 HTML 파일이 있을 수 있습니다. 웹 브라우저에서 요청한 경우 Express를 사용하여 해당 페이지를 관리합니다.


예를 들어 웹 브라우저가 www.example.com/contact를 요청하면 Express는 브라우저에서 해당 요청을 받고 contact.html로 응답합니다.


app.js 


이제 우리는 Node가 서버에서 JavaScript 코드를 실행할 수 있게 해주고 Express가 브라우저의 요청을 처리한다는 것을 압니다. 따라서 app.js 파일에서 fcc-to-aws-part2를 살펴보고 프로젝트에 추가 한 내용을 이해하기 위해 한 줄씩 읽어 보겠습니다.


먼저…

const express = require("express");

이것은 express라는 변수를 선언하고 = 기호는 값을 할당한다는 것을 의미합니다. 하지만 이것이 필요한 것은 무엇입니까 (“익스프레스”)?


require 함수는 Node가 인식하는 함수일 뿐이며 Node가 이를 인식하면 Node는 동일한 이름의 node_modules 폴더에서 폴더를 찾습니다. 이 node_modules 폴더는 fcc-to-aws-part2 폴더에 있습니다.


Node가 node_modules 폴더에서 express를 찾으면 express 폴더에서 코드를 가져와 선언 한 변수에 할당합니다. 이를 통해 직접 작성하지 않고도 express 폴더에서 가져온 코드를 사용할 수 있습니다. 이 코드를 코드로 가져 오는 것이 모듈의 개념입니다.


모듈은 코드 묶음 일 뿐입니다. 한 줄 또는 훨씬 더 길 수 있습니다. 따라서 NODE_module (노드에 강조 추가됨)은 노드 런타임에서 실행할 수 있는 코드 번들입니다. Express 모듈을 사용 중이거나 필요로 합니다.


express 모듈은 앞서 논의한 Express.js 웹 애플리케이션 프레임 워크입니다.


node_modules 폴더에 모듈을 추가하는 방법은 다루지 않겠습니다.하지만 지금은 express 변수를 선언하고 require ( "express") 구문을 사용하여 해당 Express.js 프레임 워크를 가져 와서 다음을 통해 액세스 할 수 있도록 합니다. 우리가 할당 한 변수.


이전 4 개의 단락에 많은 내용이 담겨 있었기 때문에 속도를 늦추고 다시 읽어보고 정말로 이해했는지 확인하는 것이 좋습니다!


다음…

const path = require("path");

아! 이제 익숙해 보일 것입니다. 이번에는 경로 모듈이라는 다른 모듈을 가져옵니다. 경로 변수에 할당합니다.


우리가 사용하는 변수 이름이 모듈 이름과 일치하는 패턴을 발견했을 것입니다. 그럴 필요는 없습니다. 경로 모듈을 foobar 변수에 할당 할 수 있습니다. 그러나 그것이 무엇인지 명명하는 것이 더 합리적입니다.


경로 모듈은 무엇을 합니까? 파일 및 폴더 경로로 작업 할 수 있는 모듈 (단지 코드 번들)입니다. 이렇게 하면 서버의 파일 / 폴더에 액세스하기 위해 Node가 이해하는 JavaScript 구문을 사용할 수 있습니다. 프로젝트에서 index.html이 있는 위치를 참조 할 때 유용합니다.


좋습니다. 다음으로 넘어갑니다 ...

const app = express();

또 Express? 맞습니다. 처음으로 모듈을 가져 왔을 때 이제 사용하고 있습니다.


Express 프레임 워크를 사용하려면 인스턴스화해야합니다. 즉,이 express 함수 인 express()를 실행해야 하며 이제 앱 변수에 할당합니다.


"와우,하지만 Luke, 왜 이전의 명시적인 코드 라인 바로 뒤에 이 코드 라인이 있지 않습니까?"


좋은 질문. 코드 상단에서 필요한 모든 모듈을 가져오고 (또는 require () 사용) 가져 오기를 완료 한 후 사용하는 것은 일반적인 패턴입니다.


이제 큰 바나나를 위해…

app.use(express.static(path.join(__dirname, "public")));

우와! 이걸 조금 분리 해 보겠습니다.


먼저 app.use() 함수라는 함수를 호출합니다. 이것은 우리의 앱에서 다른 기능을 사용하고 싶다고 Express 애플리케이션에 알려줍니다. 말이 된다.


우리가 실행하고 싶다고 Express에 알리는 함수는 .use () 함수 매개 변수 내부에서 호출되는 express.static () 함수입니다. 따라서 app.use ()는 Express에 앱에서 일부 코드를 사용하길 원하며 특히 여기서는 express.static (path.join (__ dirname, "public"))을 사용하고 싶습니다.


이제 express.static()은 우리가 import하고 express 변수에 할당 한 모듈의 일부이기 때문에 사용할 수 있는 Express 함수입니다.


.static () 함수는 정적 파일 제공을 처리합니다. 귀를 기울이고 눈을 크게 뜨기를 바랍니다! 다시 말 할게요. .static () 함수는 SERVING 정적 파일을 처리합니다. 피복재!


이 배포 접근 방식에서는 프로젝트를 지원하기 위해 좀 더 많은 구성을 처리하고 있음을 기억하십시오. 다음은 "정적 파일을 제공하고 싶습니다"라고 말하는 데 사용하는 Express 함수입니다. 정적 파일은 index.html 파일을 의미합니다.


그래서 app.use ()는“이봐,이 앱에 대한 코드를 내 함수 매개 변수 내에서 실행하고 싶다”고 말했습니다. 특히 "index.html과 같은 정적 파일을 전달하고 싶습니다"라는 express.static ()을 실행하고 함수 매개 변수가 해당 정적 파일을 찾을 위치를 알려줍니다.


이제 path.join (__ dirname, "public")을 살펴보고 정적 파일의 위치를 ​​알려주는 방법을 살펴 보겠습니다.


앞서 서버 / 컴퓨터의 파일에 액세스 할 수 있도록 경로 모듈을 가져 왔습니다.


우리는 공용 폴더 인 index.html 파일에 액세스하려고 합니다. 경로 함수 .join ()을 사용하여 "현재 디렉토리 (또는 폴더)에서 원하는 파일을 찾으려면 공용 폴더로 이동"이라고 말합니다. 그러면 index.html, main.js 및 styles.css가 express.static ()에 반환 되고, 방문자에게 제공 할 파일 (SERVE!)을 처리하는 app.use () 함수로 반환 됩니다.


이제 모두 함께!


app.use () =“브라우저가 앱을 요청할 때 express.static ()을 실행하고 싶습니다. "


express.static () =“정적 파일을 전달할 예정이며 여기에 있습니다… "


path.join (__ dirname,“public”) =“공용 폴더에서 파일 가져 오기”


우리는 해냈다! 누군가가 우리 사이트를 방문 할 때 index.html, main.js 및 styles.css 파일을 제공하도록 Node 런타임에서 실행되는 Express 앱을 구성했습니다.


하지만 기다려주세요…


const port = 8080;
app.listen(port);

앱 변수는 Express 프레임 워크의 인스턴스입니다. .listen () 함수는 컴퓨터에 "이봐, 포트 8080에서 요청한 모든 요청을 내 방식대로 가져 오세요!"라고 알려주는 앱입니다.


포트와 소켓은 좀 더 고급 주제이므로 지금은 다루지 않겠습니다. 그러나 컴퓨터 / 서버에는 액세스 포인트와 같은 많은 포트가 있으며 하나의 액세스 포인트 인 8080 만 수신하도록 Node / Express 앱을 구성하고 있습니다.

console.log("listening on port: " + port);

이것은 우리가 실행 중인 포트를 컴퓨터에서 로그 아웃하는 Express 앱의 표준 관행입니다. Express 애플리케이션이 작동하는지 확인할 수 있습니다.


잘 했어! 그것은 살펴볼 많은 코드였습니다.


이제 터미널을 통해 탐색하는 방법에 대해 충분히 알고 있다면 AWS로 이동하기 전에 컴퓨터에서 이 Express 앱을 로컬로 테스트 할 수 있습니다. AWS로 이동하기 전에 로컬에서 작동하는지 확인하면 오류가 Express 앱이 작동하지 않는 것과 관련 될 수 없음을 알 수 있으므로 AWS에 오류가 있는 경우에 도움이 됩니다.


Node / Express.js 앱을 테스트하는 방법 


package.json 파일을 열면 "스크립트"섹션이 표시됩니다. 이 package.json 파일은 Node 애플리케이션의 메타 데이터이며 "스크립트"섹션에서 실행하도록 구성 가능한 명령을 포함 할 수도 있습니다.


Node 환경에서 app.js 파일을 실행하는 "start"스크립트를 포함 시켰습니다. 그러면 방금 설명한 Express.js 코드가 실행됩니다. 이 "시작"스크립트는 우리가 프로젝트를 실행하는 방법입니다.


이를 테스트하려면 터미널에서 fcc-to-aws-part2 폴더로 이동하고 npm start를 입력하여 앱을 시작합니다.


term.png?resize=640%2C28&ssl=1 


해당 명령을 실행 한 후 앱이 포트 8080에서 실행 중임을 알려주는 console.log () 메시지가 즉시 표시됩니다.

term-1.png?resize=640%2C68&ssl=1 


이제 프로젝트를 보려면 웹 브라우저를 열고 주소 표시 줄에 localhost : 8080을 입력하고 Enter를 클릭하십시오. 이제 프로젝트가 실행되는 것을 볼 수 있습니다!


그렇지 않은 경우 올바른 index.html, main.js 및 styles.css 파일을 사용하고 있는지 확인하고 fcc-to-aws-part2에서 코드를 변경하지 않았는지 확인합니다.


Woohoo! 


이제 프로젝트를 지원하도록 Node와 Express를 구성했습니다. 현재 로컬 컴퓨터가 서버 역할을 하고 있지만 전 세계 모든 사람이 프로젝트를 볼 수 있기를 원하며 localhost : 8080 주소를 통해 이를 수행 할 수 없습니다.


따라서 AWS를 사용하여 서버를 호스팅하고 여기에 앱을 배치 한 다음 전 세계가 액세스 할 수 있는 URL 엔드 포인트를 생성하는 데 필요한 구성을 AWS가 관리하도록 할 것입니다. 여기서 Elastic Beanstalk라는 AWS 서비스가 작동합니다. 해보자!


AWS Elastic Beanstalk로 이동 


AWS 계정에 로그인 한 후 상단 검색 표시 줄에서 Elastic Beanstalk 서비스를 검색합니다. 거기에서 애플리케이션 만들기 버튼을 클릭합니다.


Screen-Shot-2021-03-22-at-7.59.43-PM--1-.png 


다음으로 Elastic Beanstalk 애플리케이션의 이름을 추가합니다.


Screen-Shot-2021-03-22-at-8.00.03-PM--1-.png 


태그 섹션을 건너 뛰고 플랫폼 및 애플리케이션 코드 섹션에 대한 정보를 입력하겠습니다.


우리의 플랫폼은 Node.js이고, 플랫폼 브랜치는 64 비트 Amazon Linux 2에서 실행되는 Node.js 14 (즉, Node를 실행하는 서버의 종류를 알려줍니다), 플랫폼 버전은 AWS에서 권장하는 모든 것입니다. 그런 다음 애플리케이션 코드의 경우 코드를 업로드합니다.


Screen-Shot-2021-03-22-at-8.00.34-PM--1-.png 


애플리케이션 생성 버튼을 클릭합니다.


업로드 및 배포 


업로드 및 배포 버튼을 클릭하기 전에 프로젝트를 압축해야 합니다. fcc-to-aws-part2 폴더를 열고 그 안의 모든 파일을 선택하고 압축합니다. fcc-to-aws-part2 폴더 자체를 압축하지 마십시오. 작동하지 않습니다.


Capture-1.png?resize=611%2C217&ssl=1 


이제 파일을 압축 한 상태에서 Elastic Beanstalk 환경에서 업로드 및 배포 버튼을 클릭합니다. 압축 파일을 선택하십시오.


Screen-Shot-2021-03-22-at-8.01.17-PM.png 


코드를 업로드하면 Elastic Beanstalk 애플리케이션을 시작하기 위해 수행되는 단계 인 일련의 로그를 제공하는 블랙 박스가 나타납니다. 각 로그 항목에 대해 이것이 우리가 수행 할 필요가 없는 구성이라는 사실을 기억하십시오.


Screen-Shot-2021-03-22-at-8.01.51-PM--1-.png 


완료되면 앱의 기본보기로 이동합니다. 환경의 Health 상태가 시작시 빨간색 인 것을 볼 수 있습니다.


이것에 놀라지 마십시오. AWS는 이제 우리가 원하지 않는 구성 프로세스, 즉 서버 시작, URL 엔드 포인트 생성, 앱 실행을 거치고 있습니다. 완료하는 데 몇 분 정도 걸립니다.


Elastic Beanstalk가 클라우드 컴퓨팅 플랫폼을 매우 편리하게 만드는 모든 구성을 수행 할 때입니다!


상단에 이미 제공된 URL 엔드 포인트가 있음을 알 수 있습니다. 상태가 개선되면 해당 링크를 열어 프로젝트를 볼 수 있습니다.


Screen-Shot-2021-03-22-at-9.06.33-PM--1-.png 


건강 상태가 주황색으로 바뀌고 녹색으로 바뀌지 않으면 문제가 있는 것입니다. 가장 좋은 방법은 fcc-to-aws-part2를 다시 다운로드하고 코드를 붙여 넣은 다음 fcc-to-aws-part2 폴더 자체가 아닌 fcc-to-aws-part2의 내용을 다시 압축하는 것입니다. , Elastic Beanstalk에 다시 업로드합니다.


상태가 개선되면 링크를 열고 프로젝트를 볼 수 있습니다. 더 중요한 것은 이제 전 세계의 누구나 해당 링크로 프로젝트를 볼 수 있다는 것입니다!


Screen-Shot-2021-04-02-at-11.33.49-AM--1-.png 


You Did It! 


축하합니다!


이것이 S3 배포보다 더 길고 자세한 프로세스라는 것을 알고 있지만 여러분이 그렇게 했습니다.


이번에는 정적 파일을 제공 할 Node / Express 앱을 생성하여 일부 구성을 직접 수행했지만, 여전히 AWS에서 프로젝트를 실행할 수 있도록 서버, 환경 및 엔드 포인트 생성 및 구성을 처리하도록 합니다. 전망.


Express 코드를 처리하는 데 소요 된 시간이 있어도 AWS가 우리를 위해 많은 것을 자동화하므로 이 프로젝트를 배포하는 데 걸리는 시간은 최소화됩니다.


서버를 구입하거나 프로그램을 설치하거나 URL 엔드 포인트를 설정하거나 여기에 프로젝트를 설치하는 데 시간을 할애 할 필요가 없었습니다. 이것이 AWS와 같은 클라우드 컴퓨팅 플랫폼의 이점입니다.


알림 : EC2 인스턴스를 중지 또는 종료하거나 작업이 끝나면 Elastic Beanstalk 애플리케이션을 삭제하십시오. 그렇지 않으면 애플리케이션 실행 시간에 대한 요금이 부과됩니다.


Elastic Beanstalk의 기본 서비스 


이 섹션의 시작 부분에서 Elastic Beanstalk의 장점은 이 서비스를 사용함으로써 실제로 EC2,로드 밸런서, Auto Scaling 그룹 및 Cloud Watch와 같은 많은 서비스를 소개한다는 것입니다.


다음은 AWS 및 해당 서비스에 대해 더 자세히 알아볼 수 있는 간단한 설명입니다.


Elastic Beanstalk가 우리에게 제공 한 구성의 깊이를 더 잘 보려면 구성 링크로 이동하고 페이지를 스크롤 하십시오.

Screen-Shot-2021-04-02-at-11.34.14-AM--2-.png 

EC2 


구성 개요에는 인스턴스라는 범주가 있습니다.


Screen-Shot-2021-04-02-at-9.21.24-PM--1-.png 


인스턴스는 서버 또는 컴퓨터에 사용되는 또 다른 단어입니다. 우리는 코드를 서버에 배포하고 있으며 AWS는 이러한 서버를 인스턴스라고 부르며 보다 구체적으로는 EC2 인스턴스라고 합니다.


Elastic Computer Container의 약자 인 EC2는 EC2 인스턴스를 매우 빠르게 시작할 수 있게 해주는 AWS의 서비스입니다. 우리는 EC2를 사용하여 신속하게 서버를 "회전"하고 원하는 것을 배치 할 수 있습니다.


이 경우 Elastic Beanstalk는 우리를 위해 EC2 서비스를 실행하고 우리 애플리케이션이 호스팅 될 EC2 인스턴스를 시작했습니다.


Elastic Beanstalk 앱이 아직 실행 중인 경우 EC2 인스턴스를 살펴볼 수 있습니다. 화면 상단의 AWS 검색 창에 EC2를 입력하고 Enter를 클릭합니다.


다음과 같이 하나의 인스턴스가 실행 중인 것을 확인할 수 있습니다.


Screen-Shot-2021-04-02-at-9.29.37-PM--1-.png 


인스턴스 (실행 중) 링크를 클릭하면 EC2 인스턴스의 세부 사항을 볼 수 있습니다. 다시이 EC2는 코드가 있는 일부 AWS 사이트에서 실행되는 컴퓨터 일 뿐입니다. EC2는 Elastic Beanstalk에서 우리를 위해 시작했습니다.


Load Balancer 


Elastic Beanstalk는 우리를 위해 EC2 인스턴스를 생성했을 뿐만 아니라 로드 밸런서도 생성했습니다. EC2 관리 콘솔의 왼쪽 탐색 패널에서 로드 밸런서까지 아래로 스크롤하고 링크를 클릭하여 사용자를 위해 만들어진 것을 확인합니다.


부하 분산기의 목적은 수신 트래픽을 여러 대상에 분산하는 것입니다. 우리의 경우 대상은 EC2이지만 하나만 실행 중이므로 현재 로드 밸런서가 그다지 유용하지 않습니다.


잠시 우리 앱이 바이러스에 감염되었고 Elastic Beanstalk가 제공 한 엔드 포인트에 액세스하려는 수만 명의 사용자가 있다고 가정 해 보겠습니다. 이 단일 EC2 인스턴스는 트래픽으로 압도 될 것입니다. 요청 시간이 초과되고 방문자가 실망 할 수 있으며 로드를 처리 할 EC2가 충분하지 않기 때문에 사이트가 어려움을 겪게 됩니다.


그러나! 더 많은 EC2 인스턴스를 실행하고 각각 프로젝트를 배포 한 경우 바이러스 확산을 처리 할 수 ​​있습니다.


EC2가 여러 개 있으면 문제가 발생합니다. 동일한 Elastic Beanstalk 엔드 포인트에서 각 EC2 인스턴스에 연결할 수 있어야 하며 이는 까다로운 네트워킹입니다.


이것이 바로 로드 밸런서가 들어오는 곳입니다. Elastic Beanstalk가 대상에 대한 단일 액세스 포인트를 제공하면 로드 밸런서가 서로 다른 EC2와 Beanstalk 사이에서 트래픽을 조직화 하도록 처리합니다.


로드 밸런서 기본 구성을 보면 Elastic Beanstalk 엔드 포인트와 매우 유사한 DNS 이름이 표시됩니다. 열면 앱이 실행됩니다. 이는 Elastic Beanstalk 엔드 포인트가 실제로 여러 엔드 포인트간에 트래픽의 균형을 맞출 수 있는 이 엔드 포인트를 가리 키기 때문입니다.


Screen-Shot-2021-04-02-at-9.36.01-PM--1-.png 


이제 "Luke,이 달콤한 로드 밸런싱 작업을 활용할 수 있도록 더 많은 EC2를 시작하려면 어떻게 해야 합니까?"라고 궁금 할 것입니다. 물어봐 주셔서 감사합니다! 정답은 Auto Scaling 그룹입니다!


Auto Scaling 그룹 


이름에서 알 수 있듯이 이 AWS 서비스는 일련의 기준에 따라 EC2 인스턴스 그룹을 자동으로 조정합니다. 현재 로드 밸런서가 대상으로 하는 EC2 인스턴스가 하나만 실행되고 있지만 Auto Scaling 그룹에는 인스턴스를 추가하거나 제거 할 시기를 결정하는 구성 가능한 임계 값이 있습니다.


Auto Scaling 그룹을 보려면 EC2 Mangement Console의 왼쪽 탐색에서 Auto Scaling 그룹을 찾을 때까지 아래쪽으로 스크롤하고 나열된 단일 Auto Scaling 그룹 옆에있는 확인란을 클릭합니다.


Screen-Shot-2021-04-05-at-9.05.07-AM--1-.png 

탭에 있는 다양한 세부 사항을 자유롭게 정독하되 몇 가지 세부 사항을 지적하고 싶습니다.


먼저 세부 정보 탭을 클릭하고 원하는, 최소, 최대 용량 설정을 확인합니다. 기본값은 각각 1, 1, 4입니다. 이러한 값은 구성 가능하며 실행하려는 EC2 인스턴스 수를 AWS에 알리는 방법입니다.


EC2 인스턴스는 실행하는 데 비용이 들기 때문에 기업은 새 인스턴스를 추가하거나 제거하는 빈도를 미세 조정하려고 합니다. 우리는 하나만 실행하고, 최소 하나의 인스턴스를 실행하고, 최대 4 개를 원한다고 말합니다. 원하는 값을 2로 편집하면 새 인스턴스가 시작되는 것을 볼 수 있습니다.


Screen-Shot-2021-04-05-at-9.06.15-AM--1-.png 


하지만 Auto Scaling Group은 인스턴스 추가 / 제거시기를 어떻게 알 수 있습니까? 자동 확장 탭을 클릭하여 인스턴스 추가 / 제거시기를 결정하기 위한 현재 구성을 확인합니다.


Screen-Shot-2021-04-05-at-9.07.26-AM--1-.png 


여기에는 두 가지 정책이 있습니다. 하나는 확장 용이고 다른 하나는 확장 용입니다. 둘 중 하나를 실행하기 위해 충족해야 하는 현재 임계 값을 강조했습니다.


"5 분 이상 EC2 인스턴스에 네트워크 문제가 있는 경우 최대 용량에 도달하지 않은 경우 EC2를 추가하십시오"및 "5 분 동안 네트워크 문제가 없는 경우 우리가 원하는 용량에 도달하지 않은 경우 EC2. "


마찬가지로 Auto Scaling Group의 구성에 따라 애플리케이션을 확장 / 축소 할 수 있습니다. 우리의 응용 프로그램은 이제 입소문의 추가 부하를 처리 할 수 ​​있습니다!


하지만 마지막 질문입니다. Auto Scaling 그룹은 EC2 네트워크 오류에 대해 어떻게 알 수 있습니까? CloudWatch를 입력하십시오.


CloudWatch 


Auto Scaling 그룹에서 모니터링 탭을 클릭하면 CloudWatch로 이동하는 링크가 표시됩니다. CloudWatch Management Console에 들어가면 다양한 AWS 서비스 및 리소스와 관련 지표가 나열됩니다.


목록을 살펴보면 EC2 및 Auto Scaling 그룹과 각각에 대한 모니터링 세부 정보를 찾을 수 있습니다. 이 모든 측정 항목의 출처는 어디입니까? AWS는이 유용한 대시 보드와 함께 자동으로 제공하므로 개별 지표 또는 Auto Scaling과 같은 복합을 기반으로 매우 멋진 동적 네트워킹 및 프로그래밍을 수행 할 수 있습니다.


Auto Scaling 그룹은 이러한 지표에 액세스 할 수 있으며 EC2 인스턴스의 NetworkOut 지표를 감시하여 확장 작업이 발생해야 하는지 결정합니다.


클라우드 컴퓨팅 플랫폼에서 얻는 또 다른 활용 사례입니다.


ElasticBeanstalk Deployment Recap 


두 번째 애플리케이션 배포 방법 인 Elastic Beanstalk를 살펴 보았습니다. S3 배포와 비교할 때이 경로를 사용하려면 index.html 제공을 구성하기 위한 코드를 더 추가해야 했습니다.


Node.js 웹 애플리케이션 프레임 워크 인 Express.js를 사용하여 프런트 엔드를 제공 한 다음 새로 업데이트 된 프로젝트를 Elastic Beanstalk에 업로드했습니다. 그 결과 수많은 AWS 리소스와 서비스가 시작되었습니다.


우리는 EC2, Load Balancer, Auto Scaling Group 및 CloudWatch에 대해 배웠고, 이들이 함께 작동하여 전 세계적으로 액세스 가능한 URL 엔드 포인트를 통해 프로젝트를 제공하는 방법을 배웠습니다.


더 많은 설정, 서비스 및 리소스 Elastic Beanstalk가 구성 및 프로비저닝 했지만 논의하지 않았지만 지금은 클라우드 호스팅 제공 업체와 몇 가지 주요 AWS 서비스의 이점에 대한 좋은 첫 걸음을 얻었습니다. 


AWS Lambda를 사용하여 freeCodeCamp 프로젝트를 배포하는 방법 


이 게시물의 마지막 부분에서는 코드를 서버리스 환경에 배포 할 것입니다. 서버리스 인프라는 전용 온 프레미스 서버 또는 호스팅 된 서버 (예 : EC2)보다 점점 인기를 얻고 선호되고 있습니다.


서버리스 경로는 더 비용 효율적일 뿐만 아니라 다른 소프트웨어 아키텍처 접근 방식 인 마이크로 서비스에 적합합니다.


서버리스 세상을 소개하기 위해 Lambda라는 AWS의 서버리스 서비스와 또 다른 AWS 서비스 인 API Gateway를 통해 코드를 배포 할 것입니다. 시작하자!


서버리스 란?! 


뭐라고?! 이번에는 웹 브라우저가 코드를 요청할 때 코드를 제공하는 서버에 대해 이야기 해 왔습니다. 서버리스 란 무엇을 의미합니까?


시작하기 위해 서버가 없다는 의미는 아닙니다. 서버는 컴퓨터이고 우리는 컴퓨터에서 실행되는 프로그램이 필요하기 때문에 하나가 있어야 합니다.


따라서 서버리스가 서버 없음을 의미하지는 않습니다. 이는 코드 배포자 인 귀하와 나는 서버를 전혀 보지 못하고 해당 서버에 대해 설정할 구성이 없음을 의미합니다. 서버는 AWS에 속하며 다른 작업을 수행하지 않고 코드를 실행합니다.


서버리스는 현실적으로 여러분과 저에게는 서버가 없지만 실제로는 있다는 것을 의미합니다.


아주 간단하게 들리죠? 그것은! 구성 할 서버가 없으며 AWS는 서버를 보유하고 모든 것을 처리합니다. 코드를 넘겨 주면 됩니다.


스스로에게 질문 할 수 있습니다. EC2와 어떻게 다른가요? 좋은 질문.


더 적은 구성 


Elastic Beanstalk, EC2 관리 콘솔, Auto Scaling Group 및 Load Balancer에서 처리 할 수 있는 모든 구성 옵션을 기억하십니까?


Screen-Shot-2021-04-02-at-11.34.14-AM-1.png?resize=640%2C306&ssl=1 


그런 다음 Elastic Beanstalk는 로드 밸런서 및 Auto Scaling 그룹과 같은 자체 구성으로 더 많은 리소스를 생성했습니다.


글쎄요, 우리가 그것들을 구성 할 수 있다는 것은 좋은 것입니다. 또한 설정하기가 어려울 수 있습니다. 더 중요한 것은 설정에 더 많은 시간이 걸리므로 실제 애플리케이션을 개발하는 데 소요되는 시간이 필요하지 않습니다.


Lambda (AWS 서버리스 서비스)를 사용하면 "코드를 실행할 Node.js 환경이 필요합니다"라고 말한 다음 서버 자체에 대해 더 이상 구성 할 구성이 없습니다. 더 많은 코드를 작성하는 것으로 돌아갈 수 있습니다.


더 싸다 


또한 EC2가 실행되는 동안 비용이 발생합니다. 이제는 종료하거나 일시적으로 중지하여 비용을 절약 할 수 있으며 일반적으로 실제 서버를 구입하는 것보다 저렴합니다. 그러나 웹 사이트에 접속하려는 사람이 없더라도 하루 종일 실행되는 비용은 여전히 ​​듭니다.


그렇다면 코드가 실행 된 시간 동안 만 요금을 부과하는 옵션이 있다면 어떨까요? 서버리스입니다!


AWS Lambda를 사용하면 언제든지 코드를 실행할 수 있으며 서버에 있습니다. 그러나 요청이 있을 때만 프로그램을 실행하고 실행되는 시간에 대해서만 비용을 지불합니다. 비용 절감은 엄청납니다.


마이크로 서비스 아키텍처 


대부분의 프로그램은 서버에 작성 및 배포되어 실행되기 때문에 해당 응용 프로그램의 모든 코드가 함께 번들되어 해당 서버가 전체 응용 프로그램에 액세스하고 실행할 수 있습니다. 말이 되네요!


그러나 요청한 코드 만 실행하는 서버리스 접근 방식으로 코드를 실행할 수 있는 방법이 있다면 해당 애플리케이션을 여러 애플리케이션으로 나눌 수 있습니다. 애플리케이션을 더 작은 하위 애플리케이션으로 분리하는 것이 마이크로 서비스의 개념입니다.


마이크로 서비스 접근 방식의 주요 이점 중 하나는 업데이트 프로세스입니다. 모 놀리 식 애플리케이션 (모두 EC2에 함께 번들로 제공되는 애플리케이션)이 있고 작은 코드 조각 하나를 업데이트 해야 하는 경우 전체 애플리케이션을 다시 배포해야 하는데, 이는 서비스 중단을 의미 할 수 있습니다.


또는 마이크로 서비스 접근 방식은 작은 코드 조각을 처리하는 전체의 작은 응용 프로그램 만 업데이트한다는 것을 의미합니다. 이는 배포에 대한 덜 갑작스러운 접근 방식이며 AWS Lambda를 통해 수행 할 수 있는 마이크로 서비스 접근 방식의 주요 이점 중 하나입니다.


서버리스에는 자체 단점도 있습니다. 우선, 서버리스를 통한 마이크로 서비스 아키텍처가 있는 경우 서로 통신하기 위해 이러한 마이크로 서비스를 통합하려면 모 놀리 식 애플리케이션이 처리 할 필요가 없는 추가 작업이 필요합니다.


즉, 그것은 매우 인기 있고 사용이 증가하는 접근 방식이므로 알아두면 가치가 있습니다.


면책 조항 : 이제 기술적으로 Part 1의 S3 사용은 서버리스 배포 였지만 일반적으로 사람들이 서버리스와 AWS에 대해 논의 할 때 Lambda에 대해 이야기합니다.


AWS Lambda를 시작하는 방법 


따라서 Lambda를 사용하면 서버 구성이나 비용에 대한 걱정 없이 코드를 실행할 수 있습니다. 그게 다입니다. AWS가 소유하고 AWS에서 구성하고 AWS에서 관리하며 우리가 보지 못한 서버에서 실행됩니다.


대부분의 경우 우리가 제어하고 신경 쓰는 것은 기능뿐입니다. 이를 클라우드 컴퓨팅에서 서비스로서의 기능이라고 합니다. 인프라의 복잡성에 대해 생각할 필요없이 코드에 집중할 수 있습니다.


이제 Lambda가 구성 할 필요가 없는 AWS 서버에서 실행되는 함수라는 것을 알았으므로 이제 시작해 보겠습니다.


Lambda를 생성하는 방법 


AWS Lambda 관리 콘솔로 이동하십시오. 함수 생성 버튼을 클릭합니다. 다음 화면에서는 작성자를 처음부터 선택하지 않고 함수 이름 (일명 Lambda의 이름)을 입력 한 다음 Node.js 14.x 런타임을 선택합니다.


지금까지 해야 할 일은 여기까지입니다. 계속해서 오른쪽 하단의 함수 생성 버튼을 클릭합니다.


Screen-Shot-2021-04-14-at-9.51.24-AM--1-.png 


로드되는 다음 화면은 Lambda를 관리하기 위한 콘솔입니다. 조금 아래로 스크롤 하면 포함 된 코드 편집기와 파일 시스템을 찾을 수 있습니다. Lambda 이름의 디렉터리 (폴더라고도 함)가 이미 index.js 파일과 함께 있습니다. 파일을 클릭하고 index.html이라는 새 파일을 만듭니다.


Screen-Shot-2021-04-15-at-3.51.23-PM--1-.png 


프로젝트 코드 조정 


이 배포의 특성으로 인해 코드를 약간 조정해야 합니다. .css 및 .js 코드를 연결하는 freeCodeCamp 프로젝트의 index.html에서 <link href = "styles.css"/> 태그와 <script src = "main.js"> </ script> 태그를 사용하는 대신 HTML 코드를 HTML 파일에 직접 추가 할 것입니다.


이렇게 하지 않으면 앱을 열려고 할 때 원하는 것과 다른 URL 경로에서 해당 파일을 찾습니다.


Lambda에서 작동하도록 코드를 변경하려면 다음을 수행하십시오.


  1. index.html 파일의 <link href = "styles.css"/> 줄을 <style> </ style>로 바꿉니다 (<body> 여는 태그 바로 위에 있어야 함).
  2. styles.css 파일을 열고 모든 CSS를 복사 한 다음 두 <style> 태그 사이에 붙여 넣으십시오 (예 : <style> 붙여 넣은 코드 </ style>).
  3. main.js에서도 동일한 작업을 수행합니다. 여는 <script> 태그 내에서 src = "main.js"를 제거합니다.
  4. main.js 파일을 열고 모든 JS 코드를 복사 한 후 index.html 파일 하단에 있는 두 개의 <script> 태그 사이에 붙여 넣습니다 (예 : <script> main.js 코드 <script>).

완료되면 웹 브라우저에서 index.html을 로컬로 열어 프로젝트가 계속 작동하는지 확인하십시오.


Lambda에 프로젝트 코드 추가 


업데이트 된 index.html 페이지가 작동하면 Lambda 콘솔로 돌아갑니다. 여기에서 모든 index.html 코드를 Lambda에서 생성 한 index.html 파일에 붙여 넣습니다. 모든 코드를 복사 / 붙여 넣기 했는지 다시 확인하세요.


index.js Lambda 파일 업데이트 


좋습니다. index.html이 있지만 ElasticBeanstalk 배포에서 만든 Express.js 앱과 마찬가지로 웹 브라우저에 전달하려는 파일의 위치를 ​​Lambda에 알려야 합니다.


다음 코드를 Lambda의 index.js 파일에 복사하여 붙여 넣은 다음 논의하겠습니다.


const fs = require('fs');

exports.handler = async (event) => {
    const contents = fs.readFileSync(`index.html`);
    return {
        statusCode: 200,
        body: contents.toString(),
        headers: {"content-type": "text/html"}
    }
};

ElasticBeanstalk 배포를 완료 한 경우 이 코드의 맨 위가 익숙해 보일 것입니다. 파일 시스템의 약자 인 fs라는 노드 모듈을 가져옵니다. 우리의 경우 index.html 파일을 찾기 위해 파일 시스템을 탐색 할 수 있습니다.


이 Lambda가 찾도록 구성되어있는 기본 기능인 exports.handler 함수를 볼 수 있습니다.


이 Lambda가 트리거 되면 (자세한 내용은 잠시 후) 실행할 지정된 파일 및 함수 이름을 찾습니다. 함수 생성을 클릭하면 index.js 파일에서 핸들러 함수를 찾도록 미리 구성되어 있습니다.


원하는 경우 이를 변경할 수 있지만 지금은 이 핸들러 함수가 Lambda 함수라는 사실을 아는 것으로 충분합니다.


이 함수는 index.html 파일을 읽고 콘텐츠라는 변수에 할당 한 다음 반환합니다.


반환하는 방식은 API 요청에 따라 다릅니다. 이것이 Lambda가 트리거 되는 방식입니다. 브라우저에서 프로젝트를 열면 브라우저는 이 Lambda를 트리거하여 index.html을 브라우저에 반환하는 엔드 포인트에 GET 요청을 합니다.


Lambda를 트리거하여 index.html 파일을 브라우저에 반환하는 API를 만들어 보겠습니다.


중요 : 계속 진행하기 전에 변경 사항 배포 버튼을 클릭하십시오. 이렇게 하면 Lambda가 저장됩니다.


AWS API Gateway 


AWS 서비스 검색 창에 API Gateway를 입력하고 링크를 엽니다. 이제 API Gateway 콘솔에 있으며 API 생성을 클릭하겠습니다.


다음으로 REST API 옵션을 선택하고 빌드를 클릭하십시오.


Screen-Shot-2021-04-16-at-9.55.55-AM--1-.png 


API 이름을 입력하고 원하는 경우 설명을 추가 한 다음 API 만들기를 클릭합니다.


Screen-Shot-2021-04-16-at-9.56.18-AM--1-.png 


API를 생성하면 이 API에 대한 관리 콘솔로 리디렉션됩니다. 이제 Lambda를 트리거하기 위한 API 엔드 포인트를 생성하기 만하면 됩니다.


GET 메소드 생성 


API 메서드에 익숙하지 않은 경우 발생하는 작업을 설명하는 동사입니다. 웹 브라우저가 index.html 파일을 가져 오려고 시도하고 있으며 이 API 엔드 포인트는 Lambda의 도움을 받아 수행 할 수 있습니다.


따라서 API에 GET 메서드를 만들어야 합니다. 이렇게 하려면 Actions를 클릭 한 다음 Create Method를 선택합니다.


Screen-Shot-2021-04-16-at-9.56.57-AM--1-.png 


그런 다음 GET을 선택하고 확인란을 클릭합니다.

Screen-Shot-2021-04-16-at-9.57.07-AM--1-.png 


Lambda를 트리거로 선택 


이제 API에 GET 메서드가 있으며 이 메서드가 적중 될 때 트리거 될 Lambda를 연결할 수 있습니다.


리소스 목록에서 새로 생성 된 GET 메서드를 클릭합니다. 그러면 메서드 통합을 만들기 위한 양식이 표시됩니다. Lambda를이 API 엔드 포인트에 페어링 하는 것입니다.


통합은 다음과 같아야 합니다.


  • 통합 유형 : Lambda 함수
  • Lambda 프록시 통합 사용 : 활성화 됨
  • Lambda 함수 : Lambda의 이름
  • 기본 시간 초과 사용 : 활성화 됨


Screen-Shot-2021-04-14-at-10.08.10-AM--2-.png 


Lambda를 채우려면 첫 글자를 입력해야 합니다. 채워지지 않는 경우 Lambda가 다른 Lambda 리전에 있을 수 있습니다.


이 경우 Lambda로 이동하고 화면 오른쪽 상단에서 리전 (예 : us-east-2 인 Ohio)을 확인한 다음이 단계에서 적절한 리전을 다시 선택합니다.


저장 버튼을 클릭합니다. 이제 마지막으로 할 일은 Lambda를 트리거하는 GET 메서드 추가가 라이브 되도록 API Gateway를 배포하는 것입니다.


API Gateway 배포 


GET 메서드를 만드는 데 사용한 것과 동일한 드롭 다운 인 Actions 드롭 다운을 다시 클릭합니다.


API 배포 옵션을 선택합니다.


배포 단계 드롭 다운에서 [새 단계]를 선택합니다.


prod와 같은 단계 이름, 원하는 경우 설명을 입력 한 다음 배포를 클릭합니다.


Screen-Shot-2021-04-14-at-10.03.25-AM--1-.png 


그게 다야! 끝났습니다. 이제 테스트 해 보겠습니다.


Run It! 


S3 및 Elastic Beanstalk가 프로젝트를 볼 수 있는 엔드 포인트를 제공 한 것처럼 API Gateway도 엔드 포인트를 제공합니다. 이번에는 배포 단계의 GET 메서드와 이름을 지정하여 엔드 포인트 생성을 지원했습니다.


엔드 포인트를 보려면 왼쪽 탐색 메뉴에서 단계를 선택한 다음 오른쪽 상자에 단계 이름이 표시되어야 합니다. 단계를 확장하고 GET 메서드를 클릭합니다.


!! 올바른 URL을 얻으려면 GET 방법을 클릭하십시오!


이제 오른쪽에 Invoke URL이 표시되며 클릭하면 프로젝트로 이동합니다.


Screen-Shot-2021-04-16-at-10.15.40-AM--1-.png 


축하합니다! 이제 AWS를 사용하는 세 번째 배포 접근 방식에서 프로젝트가 시작되는 것을 볼 수 있습니다.


프로젝트가 작동하는 것을 보는 데 문제가 있는 경우 다시 확인해야 할 몇 가지 사항은 다음과 같습니다.


  • index.html을 추가하고 index.js를 편집 한 후 Lambda에서 변경 사항 배포를 클릭 했습니까?
  • GET 메서드를 생성 할 때 Lambda 프록시 통합 사용을 클릭 했습니까? (확인하려면 메서드를 삭제하고 다시 만들어야 합니다)?
  • 프로젝트 코드가 <style> 및 <src> 태그에 올바르게 복사 되었습니까?

AWS Lambda의 사용 사례 


Lambda는 제 생각에 우리가 사용할 수 있는 가장 다재다능한 AWS 리소스입니다. Lambda의 사용 사례는 끝이 없어 보입니다. 그것으로 우리는 할 수 있습니다 :


  • 프런트 엔드 제공 (방금처럼)
  • 실시간 처리
  • S3에 업로드 된 프로세스 객체 (이미지, 비디오, 문서 등)
  • 작업 자동화
  • 애플리케이션을위한 서버리스 백엔드 구축
  • 그리고 더 많은!

결론 


이 튜토리얼을 마치 신 것을 축하드립니다! 이제 S3, EC2, Auto Scaling Group, Load Balancer, API Gateway, CloudWatch 및 Lambda와 같은 기본 AWS 리소스 및 서비스에 대한 기본적인 이해가 있어야 합니다.


freeCodeCamp 이상에서 만든 프로젝트를 배포하는 방법을 이해하는 데 큰 진전을 이루었습니다. 이 정보가 도움이 되었기를 바랍니다. 의견, 질문 또는 제안 사항이 있으시면 언제든지 문의 해주세요.


https://www.freecodecamp.org/news/how-to-deploy-your-freecodecamp-project-on-aws/



AWS