코드프레소 백엔드 개발자 양성 과정

AWS로 서비스 배포하기 3

공공 서브넷에 웹 서버를 구축해본다.

H Lee

10 min readMar 3, 2020

둘째 글에 이어 EC2 인스턴스에 웹 서버를 구축해 보겠다. 이제는 익숙할 아래 그림에서, 공공 서브넷 안에 포개진 주황색 사각형으로 표시된 가상 컴퓨터에 내 프로젝트를 실행할 수 있는 톰캣 서버를 설치한다.

공공 EC2 인스턴스 로그인

우선 공공 EC2 인스턴스에 로그인해 보자.

social_media_project_public_ec2라고 이름 지은 이 인스턴스는 공공 서브넷에 속해 있고, 탄력적 IP 주소를 부여받아 외부와 그리고 외부로부터 통신할 수 있는 가상 컴퓨터이다. 이곳에 내 스프링 프로젝트를 가동할 수 있도록 톰캣 서버를 설치해 보겠다.

대시보드 인스턴스 화면에서 공공 인스턴스를 선택한 후 연결하기 단추를 누른다. 푸티(PuTTY)라는 것으로 접속하라는 설명이 있다.

Auth에서 인증 키 경로를 찾아준다.

세션의 호스트 이름 칸에는 공공 EC2 인스턴스의 공공 IP 주소를 붙여넣는다. 이는 지난 번에 봤듯이 탄력적 IP 주소를 할당 받아 연결해 준 것이다.

그리고 하단에 열기 단추를 누르면 이와 같은 로그인 창이 뜬다.

기본 사용자 이름인 ec2-user로 접속한다.

로그인되었다. sudo yum update를 실행하여 우선 시스템의 패키지 등을 정비하고 갱신해준다.

자바 버전

java -version으로 이미 설치되어 있는 자바의 버전을 확인한다.

자바가 설치되어 있어야만 톰캣과 같은 웹 애플리케이션 서버도 설치할 수 있는데, AMI를 적절히 고르면 손수 설치하는 수고를 덜 수 있다. 이 EC2 인스턴스에 기본으로 설치되어 있는 자바의 버전은 1.7.0_231이다.

배포 과정을 마쳐도 페이지가 호출되지 않는 오류를 수차례 겪은 결과, 자동 설치된 자바의 버전이 문제일 수도 있겠다는 짐작에 내 프로젝트의 버전에 맞춘 자바 1.8을 새로 깔아주기로 했다. 혼선을 피하기 위해 기존에 있는 1.7은 삭제한다.

rpm -qa | grep java를 사용해 설치되어 있는 정확한 패키지 이름을 우선 알아낸다. 그리고 sudo yum remove 1.7.0-openjdk-1.7.0.231–2.6.19.1.80.amzn1.x86_64 명령문으로 삭제한다.

java -version으로 확인 시 버전이 더 이상 표시되지 않는다. 삭제에 성공했다.

yum list java*를 통해 설치할 수 있는 자바 패키지 목록을 열람한다. 내 프로젝트에 맞는 1.8 버전이 있다. java-1.8.0-openjdk-devel.x86_64을 설치해 본다.

sudo yum install java-1.8.0-openjdk-devel.x86_64를 실행한 결과 자바 버전이 1.8.0_242로 바뀌어 나오는 것을 볼 수 있다.

웹 서버

본격적으로 톰캣 서버 설치에 들어간다.

sudo yum list tomcat*을 실행해 설치 가능한 버전의 목록을 확인한다. 아래와 같이 나왔는데, 나는 그중 버전 8을 설치하겠다. 운영 체제와 무관하게 작동할 수 있다는 tomcat8-webapps.noarch를 골라주었다.

sudo yum install tomcat8-webapps.noarch로 설치를 진행한다.

그리고 sudo service tomcat8 start라고 입력해 톰캣 서버를 가동한다.

curl http://127.0.0.1:8080을 입력하면 서버의 로컬 환경에서는 8080번 포트에 성공적으로 접속할 수 있다.

이번에는 공공 EC2 인스턴스의, 탄력적 IP 주소로 발급받은 공공 IP 주소를 복사하여 (공공 IP 주소):8080의 형태로 브라우저 창에 요청해본다.

접근할 수 없음을 볼 수 있다. 지난 글에서 언급했던, 인스턴스를 감싸 보호한다는 보안 그룹이 8080번 포트를 통한 HTTP 형태의 통신을 허용하고 있지 않기 때문이다.

보안 그룹 (Security Group)

보안 그룹(Security Group)이란 인스턴스를 드나드는 통신을 제어하기 위한 가상 방화벽이다. VPC에는 두 겹의 보안층이 있다고 했는데, 보안 그룹은 그중 인스턴스 단계를 감싸는 것이다. 다른 보호막으로는 서브넷 단계를 감싸는 네트워크 제어 목록(Network Access Control List, NACL)이라는 것이 있다.

톰캣 서버가 설치된 공공 EC2 인스턴스에 접근하는 것을 막는 social_media_project_public_security_group의 보안 설정을 살펴보자.

EC2 대시보드의 사이드 메뉴에서 보안 그룹에 관한 정보를 연다. 보다시피 공공 EC2 인스턴스를 보호하고 있는 보안 그룹이 이미 존재함을 볼 수 있다. EC2 인스턴스 생성 시 지정해주었기 때문이다. 수동으로 설정하지 않았더라도 마법사가 자동으로 만들어주니 어떤 보안 그룹이 공공 EC2 인스턴스를 감싸고 있는지만 파악하면 된다.

상세 정보란에서 유입되는 통신에 대한 규칙을 본다. 현재는 22번 포트로 들어오는 SSH 규약만 받아들이게 되어 있다. 그래서 푸티를 사용해 22번 포트로 이 리눅스 인스턴스에 로그인할 수 있었던 것이다.

편집하기 단추를 눌러 인스턴스에 접근하는 규칙을 추가해 본다.

포트 범위에는 8080번 포트를 열어두겠다고 선언하고, 출처는 기본 설정인 0.0.0.0/0로 일단 둔다. 유입되는 모든 통신을 받겠다는 뜻이다.

규칙을 추가하고 브라우저에서 다시 접속을 시도하면 톰캣 서버의 기본 창이 출력됨을 볼 수 있다. 외부로부터 공공 EC2 인스턴스 내에 설치된 웹 서버에 접근한 것이다.

참고 : sarc.io

WAR 파일

그럼 이제 통합 개발 환경으로 가서 개발한 소스 코드를 WAR 파일로 압축하고 내려받는다.

이클립스의 경우 파일 메뉴에서 이출하기가 있다.

이름은 프로젝트 이름 그대로 socialMedia로 정하고, 이 socialMedia.war 파일을 내려 받을 위치도 지정해 준다.

지정해줬던 내 문서 폴더로 성공적으로 저장되었다.

파일질라 (FileZilla)

파일 전송 규약(File Transfer Protocol)용 소프트웨어인 파일질라를 이용해 가상 리눅스 인스턴스에 방금 생성한 WAR 파일을 전송해 보겠다. 그곳에 설치된 톰캣 서버로 프로젝트를 돌려야 배포를 할 수 있기 때문이다.

좌측 상단 호스트에는 공공 EC2 인스턴스의 공공 IP 주소, 사용자명은 기본 사용자 이름인 ec2-user, 포트 번호는 22번을 입력하고 빠른 연결 단추를 누른다. 따로 설정한 적이 없다면 비밀 번호는 없으니 빈 칸으로 둔다.

그러면 연결이 성공했다는 로그 메시지와 함께 좌측에는 로컬 컴퓨터, 우측에는 클라우드 상의 리눅스 인스턴스의 내부가 표시된다. 로컬 컴퓨터에서 socialMedia.war 파일이 저장된 내 문서 폴더로 이동한다. 파일을 더블 클릭하면 우측의 리눅스 인터페이스에서 ec2-user 폴더 안으로 socialMedia.war 파일이 전송된다.