1교시
지금까지는 테스트를 위해 Vagrant 환경에서 실습했지만, 실제 상황에서는 AWS 환경에서 하게 될 것이다.
앤서블 노드는 AWS 인스턴스가, 앤서블 서버는 AWS 인스턴스나 호스트 PC로 하게 될 것이다.
-> 앤서블을 Windows에서 사용하기는 어렵다. 그래서 Windows에서 앤서블을 사용하는 방법 중 하나로 WSL을 사용하는 방법이 있다.
-> Windows Subsystem for Linux
Windows 기능 켜기/끄기로 들어가서
-> Linux용 Windows 하위 시스템
-> 가상 머신 플랫폼
2개 체크하고, 재부팅 후 설치 완료.
AWS SAA 자격증을 슬슬 준비하는 것이 좋을 것이라고 하셨다.
뜨끔.
받은 VCE 파일 중 manager 실행하면 덤프 문제 풀기 가능.
2교시
비대면 학생들은 별 문제없는데, 대면 강의실 장비 문제로 시간이 꽤 날아갔다.
Windows PowerShell로 접속
-> 기본 설치를 진행하면 wsl로 설치가 되는데, wsl2로 업그레이드해야 한다.
-> wsl --set-default-version 2 실행
-> https://wslstorestorage.blob.core.windows.net/wslblob/wsl_update_x64.msi
-> 따로 문제가 있다면 위에서 wsl_update를 다운로드하여서 업데이트
-> MS Store에서 Ubuntu 20.04 LTS 받아서 실행/설치
-> 사용자명은 ansuser, 패스워드는 p@ssw0rd로 했다.
-> 파일 탐색기에서 \\wsl$\Ubuntu-20.04\home를 입력하니 ansuser의 홈 디렉터리로 바로 접근 가능했다.
-> 실제 경로는 C:\Users\JUNWOO KANG\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu20.04onWindows_79rhkp1fndgsc\LocalState
인데, Windows에서 직접 접근해서 수정하는 것은 위험하니 이 방법은 자제하자.
3교시
이번에는 대면 강의실 쪽에서 WSL을 위한 Ubuntu 설치에서 에러가 발생했다.
너무 오래 걸려서 말로 설명 진행...
우분투는 기본적으로 데비안 계열이라 apt로 패키지 관리
버전이 20.04라 따로 저장소 등록은 안 해도 된다고 한다.
어쨌거나 시작하면 root 사용자가 아니니까 필요할 경우에는 sudo 붙여서 실행할 것.
explorer.exe . : 치면 현 디렉터리의 파일 탐색기가 나온다.
-> sudo apt-get update
-> sudo apt install python-pip
-> sudo apt install python3-pip
-> sudo pip3 install ansible : 고급 기능 사용을 위해 pip3로 받았다.
이러면 명령어 설치 경로가 /usr/local/lib/python3.8/dist-packages/ansible가 된다.
그냥 apt-get install ansible로 설치하면 예전에 썼던 경로(/usr/bin/ansible)에 설치된다.
설치 및 업데이트(python-pip나 python3-pip 둘 중 하나만 설치해도 상관없다)
이제 ip add를 실행해서 ip 정보 값 확인
이러면 앤서블 서버가 만들어졌다. 이제 앤서블 노드들을 만들어 보자.
AWS 콘솔 접속/로그인
-> 일단 루트 사용자로 로그인
좌측 상단의 서비스 탭을 열어서 AWS가 제공하는 서비스들을 볼 수 있다.
EC2로 들어간다.
좌측의 목록을 대시보드, 우측을 작업창이라고 한다.
4교시
일단 인스턴스를 만들기 전에 키 필요.
-> 외부에서 인스턴스에 접근하려면 그냥은 불가능. 로컬 접속은 불가, 원격 접속만 가능(SSH)
-> 기본적으로 패스워드 인증 기능이 꺼져 있어서 무조건 전자 서명 방식을 사용해야 한다.
-> 키를 만들어 보자. 대시보드의 '키 페어' 클릭
-> 키 페어 생성
-> 이름은 공백 없이, 키 페어 유형은 RSA, 프라이빗 키 파일 형식은 원격 접속 시 사용하는 프로그램에 따라 체크.
(Putty가 아니라면 pem)
우리는 리눅스를 사용하니 pem으로 체크하고 키 페어 생성
-> 키 페어 저장 위치 기억할 것.
-> 다운로드한 것이 AWS 인스턴스 원격 접속 시 사용할 개인 키
공개 키가 만들어질 인스턴스의 .ssh 아래에 있을 것이다.
이제 인스턴스를 2대 만들자.
화면 우측 상단에 계정명, 리전(지역)이 있다.
-> 대시보드에서 '인스턴스' 클릭 : 인스턴스를 VM이라 생각하면 된다.
-> '인스턴스 시작' 클릭
AMI(Amazon Machine Image) : 인스턴스에 들어갈 OS
보통 HW 위에 OS, 미들웨어, App을 올리는데, OS/미들웨어/App을 묶어서 새로운 AMI로 만들 수도 있다.
프리 티어 AMI들은 거의 기본적인 OS만 설치되어 있다. 미들웨어가 설치되어 있는 AMI들은 보통 유료.
-> Amazon Linux 2 AMI (HVM), SSD Volume Type x64 선택
-> 인스턴스 유형은 t2.micro(프리 티어용)으로 선택
※ 프리 티어 인스턴스라고 해도 무료 사용 시간은 정해져 있다.
------
우리가 인스턴스를 하나 만들면, 해당 리전에 있는 IDC에 있는 서버 하나를 턱 쓰는 게 아니다. 여기저기에서 조금씩 자원을 긁어모아서 만드는 것(클러스터링).
-> 인스턴스 유형 선택 시 보이는 vCPUs는 하나의 CPU가 아니라는 것.
------
-> 기본 설정 그대로 쭉 검토하면서 넘어간다
※ 태그 : 인스턴스를 구분할 수 있도록 이름을 붙이는 것.
-> 키와 값이 있는데, 키는 마음대로 붙이는 것이 아니다
-> 보안 그룹 구성 : Nginx를 위한 규칙 추가(HTTP, TCP, 80, ipv6는 지우고)
-> 이제 검토 후 생성 : 만들었던 키 페어 선택하고 시작
-> 인스턴스 작업창으로 돌아와서, 해당 인스턴스의 상태가 '실행 중' 이면 작동 중인 것.
-> 동일하게 인스턴스 하나 더 생성
SSH 접속이 가능한지 확인해 보자.
-> 아까 받아놨던 pem 개인 키를 우분투 서버(= 앤서블 서버)의 홈 디렉터리 쪽으로 넣어주자.
-> 전자 서명 방식을 적용해 보자.
-> EC2 인스턴스의 ec2-user라는 계정의 ~/.ssh/authorized_key에 공개 키가 있을 것이다.
-> /etc/ansible/hosts 파일 하단에 Vagrant에서 했던 것처럼 그룹명과 노드명을 지정하고, 정보를 입력한다.
[aws]
node01 ansible_host=*** ansible_user=ec2-user ansible_private_key_file=/home/ansuser/ansible.pem
node02 ansible_host=*** ansible_user=ec2-user ansible_private_key_file=/home/ansuser/ansible.pem
그룹명은 aws로 했고, ansible_host는 인스턴스 정보에 있던 ip 주소를 입력했다.
ansuble_user는 aws 인스턴스가 기본적으로 사용하는 계정인 ec2-user를 입력
ansible_private_key_file에는 아까 옮겨온 키 파일의 경로를 작성한다.
5~6교시
앤서블 서버에 Vagrant에서 했던 것처럼 ansible_env_ready.yml 파일을 만들었다.
-> 우분투에는 vim-enhanced가 없다.
-> AWS 인스턴스에서 OS를 AWS Linux를 넣었었는데, Redhat 계열 리눅스라고 보면 된다. CentOS 명령어 쓰면 됨.
-> 작성 후 실행할 때
이런 에러가 발생했는데, sudo를 붙여서 실행하니 에러가 뜨지 않았다.
-> 원래 붙여서 해야 하는지, 어딘가에서 잘못 작성해서 문제가 발생한 것인지 모르겠다.
-> 강사님도 sudo 붙여서 실행하셨다고 한다. 어차피 /etc/ansible/hosts 파일을 수정해야 해서...
핑 테스트 때마다 WARNING 뜨는 건 파이썬 문제다. /etc/ansible/hosts 파일의 그룹 정보 하단에
[aws:vars]
ansible_python_interpreter=/usr/bin/python3
를 작성해 준다. 그럼 WARNING이 더 이상 뜨지 않는다.
Nginx 설치 실습
-> 현재 인스턴스는 텅 빈 상태다. epel-release부터 설치해주고, Nginx를 설치해 준다.
-> AMI를 amazon-linux로 설치했으니, 처음부터 yum으로 설치하면 에러가 발생한다.
-> 예전에 작성했던 nginx_install.yml에서 epel-release을 yum으로 설치하지 않고,
이 부분을 변경 후 실행해 주면 성공.
WSL은 더 이상 쓰지 않을 것이라고 한다(?)
Vagrant가 아닌 실제 호스트에서 앤서블을 AWS와 연동하는 것에 의미가 있는 실습이라고 한다.
이제 AWS 코어 서비스를 배운다. WSL 실습은 따로 해봐야겠다. 이거 위험하네...
AWS 코어 서비스가 동작하려면 네트워크가 필요하다. IT 시스템은 동작을 위해서 다른 시스템과의 통신이 필수.
그러니 AWS 자체 서비스들도 네트워크 망을 이루고 있다. 이것이 VPC(Virtual Private Cloud).
-> AWS 내부 서비스들이 통신하기 위한 네트워크/가상의 통로.
-> 이것을 기반으로, VPC 네트워크를 서브넷 단위로 쪼갠다.
-> 각 서브넷에 역할을 부여 : 외부에 공개할 것인가? 감출 것인가?
-> 서브넷에 인스턴스/서비스 등을 배치
지금까지 배운 것의 종합이다. 이미지화해서 생각할 것.
네트워크가 연결되어 있다는 것 = 네트워크 망이 구축되어 있다는 것 = VPC
-> 물리적 개념으로 보면 : 아마존이 IDC에 무수히 많은 물리적 장비를 갖추어 놓고, 네트워크를 연결해 놓았다.
-> IDC 안에 라우터 스위치 등이 존재하지만 우리가 쓰는 VPC, 인터넷 게이트웨이 등은 물리적으로 존재하지 않는다.
-> 인스턴스, 서버 등도 그렇다. 하나의 서버를 통째로 쓰는 것이 아니다. 해당 가용 영역(또는 리전)에 있는 여러 장비 여기저기에서 조금씩 가져온 것이다.
7~8교시
On-Premise -> Colocation Facilities(= IDC) -> Cloud
On-Premise : 서버 장비를 회사가 사서 소유 + 네트워크 망을 구입해 연결/구축 + 전원 관리 + 시설/공간 관리
-> 1년 365일 작동을 위한 관리 필요.
-> 짧은 기간 필요해도 장비를 모두 구매해야 한다.
-> 장점 : 보안성이 좋다.
-> 단점 : 비용이 많이 든다(구축, 유지 보수 비용)
Co-location Facilities(= IDC) : 공간과 네트워크, 전원 시설, 관리 시설을 갖춰 놓고 회사들이 본인들이 사용할 서버를 갖다 놓고 관리를 위탁
-> 시설 사용 비용만 지불. 관리는 알아서 해줄 것이다.
-> 기반 시설 하에 관리를 위탁할 뿐이므로 비용 절감.
-> 그럼 서버 장비만 확인하면 된다.
Cloud : 서버 장비 관리도 하기 싫다. 서비스만 운영하고 싶다.
-> 클라우드 회사가 만들어 놓은 인프라를 사용만 할 뿐, 관리/유지는 클라우드 회사에서 알아서 해 준다.
-> 고객은 서비스/Application 개발에만 집중할 수 있다. 서버가 어디 있는지는 신경 쓸 필요가 없다.
전통적 시스템은 On-Premise/Co-located : 전자는 모든 것을 고객(회사) 측에서 구성해야 한다. 후자는 데이터센터만 제공받아 나머지를 회사가 구성.
- 클라우드 인프라 구조(Cloud Native Patterns) : XaaS(Everything as a Service). 온 프레미스 환경부터 SW까지 서비스 제공의 형태가 바뀌는 것을 의미
IaaS(Infrastructure as a Service) : 인프라 관련 내용(장비 : 서버, 네트워크, 저장소 등)을 대여, 관리해준다.
-> EC2처럼 구성은 사용자가 알아서 해야 한다.
CaaS(Container as a Service) : HW 위의 OS, 관리 도구까지 하나의 컨테이너로 만들어 대여해준다.
-> 개발 관계자들 간의 환경 차이로 인해 발생하는 문제 방지.
PaaS(Platform as a Service) : 인프라 + OS/관리 도구 + 런타임/미들웨어 모두를 제공. 고객은 Application과 함수만 관리하면 된다.
FaaS(Function as a Service) : 가장 최근에 나온 개념. Serverless의 개념이다. Application을 제외한 모든 것을 대여해준다. App을 구성하는 함수마저도 이미 만들어진 것을 가져다 사용한다.
-> 다른 서비스들은 대여한 이후 항상 작동한다. 하지만 FaaS/Serverless는 서비스를 사용할 때에만 대여한 구성들을 사용하지 않는다.
-> 서비스가 코드로 구성되어 있어 접근/요청을 받는 순간 착착착 만들어져 서비스를 제공. 접근이 없어지면 다시 가상화되어 제공된 인프라들을 해제
-> 요청 후 제공까지 걸리는 딜레이를 줄이는 것이 핵심
SaaS(Software as a Service) : 일상에서 가장 많이 사용하는 서비스. 만들어진 SW를 서비스로 사용하는 것.
-> 구글 드라이브처럼 이미 만들어진 SW를 사용한다.
-> 당연히 이런 것으로 회사에서 서비스를 구성하지는 않는다.
어떻게 대여해주건 간에 클라우드 회사 측은 물리적 인프라를 자체적으로 갖추고 있어야 한다.
Region > 가용 영역 > IDC
리전은 대충 물리적 인프라가 위치하고 있는 국가라고 생각하면 된다.
-> 클라이언트의 접속 위치와 리전이 너무 멀면 딜레이가 발생할 것이다.
-> AWS는 그래서 전 세계에 리전을 뿌렸다.
하나의 리전은 여러 가용 영역으로 나누어져 있다.
-> 가용 영역은 달라도 리전이 같으면 딜레이가 적을 것이다.
가용 영역은 여러 IDC들을 묶은 것이다.
-> 클라이언트에게 보이는 것은 리전과 가용 영역 뿐이다.
우리가 AWS를 들어가 보면, 기본 VPC와 기본 서브넷이 구성되어 있다.
기본 설정값으로 EC2 인스턴스를 만들어 보면 기본 VPC의 기본 서브넷 중 하나에 들어가 있다.
가상화의 개념을 유의할 것.
하나의 물리적 네트워크 망이 있다. 여기엔 수많은 라우터와 스위치들이 구축되어 있을 것이다.
-> 리전 내의 수많은 IDC에서 조금씩 가져와서 라우터, VPC, 스위치 등을 구현한다.
다른 사람들은 다운로드하였던 Ubuntu 20.04를 실행해서 진행했는데, Windows Terminal을 다운로드하여 진행해 봤다.
탭 형식으로 보기 편해서...
WSL + AWS EC2 실습 다시 해보기
-> 기본 환경 구축, Nginx/Apache 설치, 전자 서명 설정 등
7, 8교시(16:30 ~ 18:10) 다시 듣기. 배가 아파서 집중을 못했다.
'교육' 카테고리의 다른 글
| [43일 차] 21.09.17 : AWS 3 (0) | 2021.09.22 |
|---|---|
| [42일 차] 21.09.16 : AWS 2 (2) | 2021.09.16 |
| [40일 차] 21.09.14 : Ansible 4(Handler, Templates, vars, Roles) (0) | 2021.09.14 |
| [39일 차] 21.09.13 : Ansible 3(전자 서명 자동 구축, 동적 구성) (0) | 2021.09.13 |
| [Ansible/Vagrant] 정리 1 (0) | 2021.09.12 |
댓글