현재 위와 같은 상태이다.
모든 틀은 잡혀있고 이제 인스턴스를 생성하고 어플리케이션을 배포하면 된다!
(인스턴스를 한개이상 생성하기 때문에 약간의 비용이 청구될 수 있습니다.)
먼저 public subnet에 bastion host를 생성한다.
bastion host는 jumping host라고도 불리며 private instance에 접근하기 위해 거쳐가는 일종의 proxy 역할을 한다.
애플리케이션, DB등 보안이 민감한 것들을 public에 배포할 수 없기 때문에 public에 proxy instance를 두어 한번 더 거쳐서 private instance에 접근하여 보안을 높인다.
Seoul region의 EC2 서비스를 접속하고 Instance 메뉴 > Launch Instace 를 클릭한다.
각 단계 순서대로(프리티어 기준)
Amazon Luinux 2 AMI
t2.micro
를 선택하고 다음과 같이 입력한다.
순서대로 우리가 생성한 VPC를 선택하고 public subnet에 생성되도록 설정한다.
bastion host는 외부에서 접속할 수 있어야 하기 때문이다.
같은 이유로 Auto-assign Public IP를 enable 해줌으로써 public IP를 할당한다.
Storage 단계는 건너뛰고,
가장 중요하다고 할 수 있는 Security Group을 조정한다.
Security Group은 인스턴스단위의 방화벽이며 "Allow"정책만 설정할 수 있다.
인스턴스 가장 가까이에서 보호하는 방화벽 역할을 하기 때문에 무엇보다 중요하다.
bastion host는 ssh로 접속할 것이기 때문에 디바이스 아이피, 22번포트를 허용해주었다.
검토 페이지를 지나 ssh 접속 시 필요한 pem 파일을 생성하고 잘 다운로드하여 보관하도록한다.
몇 분 기다리면 Instance가 Running State로 바뀔 것이다.
이제 애플리케이션을 배포할 Web/WAS 인스턴스를 생성한다.
과정은 비슷하다.
VPC는 일치하고 subnet은 private subnet으로 선택해준다.
외부에서 직접접근하는 것을 차단해야하기 때문이다.
따라서, Auto-assign Public IP도 Disable로 둔다.
그리고 Step6의 Security Group을 다음과 같이 수정한다.
Source에 다른 sequrity group을 설정해주는 것이 가능하다.
이 sg는 방금 bastion host에서 생성한 security group인데,
"bastion host를 통해서 들어온 것만 허용하겠다"라는 의미이다.
AWS는 직접적인 아이피주소 할당보다는 sg를 할당해주는 것을 권장한다.
(뭐라고했더라 무슨 chaining이라고 했던 것 같은데 기억이안난다 ㅎㅎㅎ) 아이피는 계속 변할 수 있으니 그에 대한 예방책이다.
key pair 는 새로 생성하는 것이 안전하겠지만 귀찮으므로 방금 bastion에서 생성한 키페어를 또 사용하기로 한다.
두 인스턴스 생성이 끝났다.
이제 접속해보자. 먼저 bastion host에 접속한다.
(OSX기준입니다)
bastion 인스턴스를 선택하고 Description의 Public IP주소를 복사한 뒤 터미널창에 다음과 같이 입력한다.
chmod 400 pem파일경로.pem 명령어를 먼저 실행하면 sudo를 빼도 된다.
sudo ssh -i pem파일경로.pem ec2-user@ip주소 
위와 같이 들어왔다면 성공한 것이다.
우리는 bastion host에 접속했고, 아까도 말했듯이 이건 proxy 서버일 뿐이며 진짜 접속해야 하는 곳은 private subnet의 web application 인스턴스이다.
접속된 것을 확인했으니 exit를 통해 나가고 다음 명령어로 재접속한다.
sudo ssh -i bastion펨파일경로.pem -L 22:웹서버private아이피:22 ec2-user@bastion서버public아이피로컬 터널링을 설정한 것이다.
-L은 로컬을 의미하는데, 로컬 포트 22번으로 웹서버아이피의 22번 포트를 접속 하겠다 라는 것인데
그 뒤에 나오는 bastion server 접속을 통한다는 의미이다.
bastion host 접속에 성공했다.
이제 우리는 private instance로 접속할 수 있는 길을 뚫어 놓은 것이다. "로컬"로 말이다.
접속을 유지한 채 새창을 띄우고 다음과 같이 입력한다.
++ 만약 "bind [127.0.0.1]:22: Permission denided" 메시지가 뜬다면 로컬 터널링이 되지 않은 것이기 때문에 private instance에 접속할 수 없다. 루트권한으로 명령어를 실행했는지 다시 확인해본다.
sudo ssh -i tistory-docker-bastion.pem ec2-user@127.0.0.1위의 명령어가 성공하면 private instance에 접속한 것이다!!
현재 상태는 다음과 같다.
이제 Web Instance에서 docker를 설치해야 하는데, NAT Gateway가 없기 때문에 인터넷 망으로 나가서 설치파일을 가져올 수가 없다.
VPC 서비스의 NAT Gateway메뉴로 가서 생성한다.(만약 NAT Gateway가 이미 있다면 이 과정은 생략해도 된다.)
인터넷 망으로 나가야 하기 떄문에 서브넷은 Public subnet, EIP는 있으면 있는걸로, 없으면 새로 생성하여 할당하여준다.
NAT Gateway는 생성하는데 시간이 좀 걸리므로(돈도 좀 드는만큼) 인내를 가지고 기다려준다.
NAT Gateway가 available되면 서브넷 메뉴의 private-subnet Route Table을 변경한다.
VPC > Route Tables 메뉴에서 새로 생성한 뒤 아래와 같은 설정을 해준다.
어떤 요청이 들어오든 NAT Gateway로 보낸다는 뜻이다.
해당 라우팅 테이블을 Subnets > private subnet > Route Table > Edit route tabler assoication을 선택하고 위에서 생성한 routing table을 attach 해준다.
NAT Gateway설정이 제대로 되었는지 확인하는 과정은 간단하다.
private instance로 가서 아래의 명령어를 실행해본다
sudo yum -y update
만일 진행되지 않는다면 NAT Gateway설정, 그리고 VPC Dns hostnames enable 설정을 다시한번 확인해본다.
업데이트가 완료되었다! 이제 외부망에서 설치파일을 들고와서 설치할 수 있다 !
우리가 이 인스턴스에 설치해야하는 것은 다음과 같다.
docker
aws cli
먼저 도커를 설치해보자
sudo yum install docker 설치가 완료되면 다음 명렁어로 제대로 설치되었는지 확인한다.
docker --version아래와 같은 결과가 나오면 성공한 것이다.
aws cli는 Amazon Linux2 OS를 선택했다면 자동으로 설치되어있다.
aws --version명령어를 실행했을 때 아래와 같은 결과가 나온다면 성공한 것이다.
이제 해야할 일은 다음과 같다.
ECR setting
Application ECR Push
Docker 배포
이 포스팅에서 모두 끝내려고 했는데 ECR setting 도 꽤나 길게 걸릴 것 같아서 여기까지 진행하는걸로!
최근에 Jenkins를 지겹게 다루고있는데 마무리로 젠킨스 파이프라인을 이용한 CI/CD 배포까지 하지 않을까 싶다.
욕심같아서는 이 모든 과정을 콘솔이 아닌 CLI로 하는 것까지? ㅎ_ㅎ 시간이부족해~
인스턴스 중지 및 NATGateway 삭제를 추천합니다 :)
