AWS 기초 구성
1교시
각 호스팅 모델에 따라 기억할 만한 AWS 서비스
-> AWS SAA 시험 대비용
IaaS : EC2, VPC, EBS
PaaS : AWS Elastic Beanstalk
FaaS : Lambda, API Gateway
SaaS : Google Drive
클라우드의 큰 범주로는
1. Public Cloud
-> 외부 인터넷과 연결되어 있는 클라우드
2. Private Cloud
-> 특정 회사가 On-premise 환경에 데이터센터를 두고, 실제 물리적 서버, 네트워크, 스토리지를 구현하는 것
-> 특정 사용자에게만 인가된 인프라.
3. Hybrid Cloud
-> 위 2개의 조합. 1과 2를 전용 회선(VPN)으로 연결한다.
-> 보안 우선순위에서 중요한 것은 프라이빗(On-premise)에, 그렇지 않은 것은 퍼블릭(Cloud)에 저장하는 방식
Auto Scaling
특정 조건에 따라 자동으로 EC2 인스턴스를 추가 혹은 제거해주는 서비스.
-> 트래픽이 갑자기 줄어들거나 몰렸을 때 자동으로 조절
-> Windows에서 배웠던 클러스터링/장애 처리/부하 분산 등을 생각하면 여러개의 인스턴스를 사용하는 이유를 이해할 수 있다.
Scale up/down과 in/out
-> up과 down은 수직적 오토 스케일링 : 기존 인스턴스의 성능을 높이거나(up) 낮춘다(down).
-> in과 out은 수평적 오토 스케일링 : 성능이 동일한 인스턴스의 개수를 줄이거나(in) 늘린다(out).
-> 수평적 오토 스케일링이 일반적
-> 가동 시 EC2의 최소 개수, 최대 개수 등을 설정
가용영역 1, 2에 인스턴스가 2개씩 있다고 생각해보자. 가용 영역은 DC로 이루어져 있고.
가용 영역 1, 2에 있는 인스턴스를 1 + 1으로 묶어 2개씩 오토 스케일링 그룹으로 만든다.
-> 오토 스케일링 그룹으로 만들려면 다른 가용 영역에 존재해야 한다.
같은 가용영역에 있는 인스턴스끼리 한 그룹으로 묶는 경우는 거의 없다.
-> 가용영역이 다르다 = 지리적으로 떨어져 있다
-> 하나의 가용영역에서 장애가 발생해서 물리적 데이터센터가 망가지면 해당 데이터센터의 리소스를 사용하는 인스턴스는 모두 망가진다.
-> 장애 격리를 위해 서로 다른 가용 영역에 있는 인스턴스를 하나의 그룹으로 묶는다.
AWS 컴퓨팅 서비스 중 핵심 서비스는 EC2(+ Auto Scaling), Lambda 정도?
-> 오토 스케일링은 EC2 안에 있다. '관리 및 거버넌스'의 AWS 오토 스케일링은 EC2 외에 다른 서비스의 오토 스케일링 담당.
EC2 : 컴퓨팅 리소스를 제공하는 서비스
Auto Scaling : EC2 인스턴스의 조건에 따라 자동으로 서버를 추가 혹은 제거해주는 서비스
Lambda - 서버리스 컴퓨팅 : 프로그램을 실행하는 컴퓨터 엔진, 코드 만으로 서비스를 실행할 수 있다.
(서버리스의 단점 : 없던 서비스가 생성될 때 시간이 좀 걸린다 = 딜레이, 갭)
2교시
AWS 코어 서비스? = 대충 가장 많이 사용하는 서비스라는 뜻
Storage 서비스로는
EBS(Elastic BLock Store) : EC2 인스턴스에 연결되어서 사용될 수 있는 블록 스토리지 서비스
S3(Simple Storage Service) : 객체 기반의 무제한 파일을 저장할 수 있는 스토리지. 여러 가용 영역에 걸쳐있어서 뛰어난 내구성을 제공한다.
DB 서비스로는
Amazon RDS(Relational Database Service) : 아마존에서 제공하는 관계형 DB 서비스
Dynamo DB : 아마존에서 제공하는 NoSQL 서비스
ELB(Elastic Load Balancer) : EC2 인스턴스 그룹에 대한 부하 분산 서비스
AWS PrivateLink : 퍼블릭 인터넷에 데이터가 노출되지 않도록 하고, 내부 네트워크를 통해 서비스와 온프레미스 간의 안전한 비공개 연결 제공
Route 53 : AWS에서 제공하는 관리형 DNS 서비스. 도메인 이름 구매를 대행하고, 구매한 도메인 주소에 대한 호스팅 영역 설정을 통해 도메인 질의에 대한 응답을 처리
AWS Transit Gateway : VPC나 온프레미스 등의 네트워크를 단일 지점으로 연결할 수 있는 라우팅 서비스
-> VPC에 인프라를 구축해 놓고, 같은 리전의 다른 VPC와 통신하려면?
-> 각 VPC에 있는 외부 게이트웨이가 외부 인터넷을 통해 통신 : 이게 괜찮은 건가?
-> 어차피 두 VPC가 모두 AWS 서비스고, 같은 리전에 있는데 이럴 필요가 없다 : VPC끼리 연결해주면 되잖아?
-> 외부로 빙 돌아갈 필요가 없어 거리도 짧아지고, 딜레이도 줄어든다.
-> 이럴 때 쓰는 것이 전송 게이트웨이
AWS CloudFront : AWS에서 제공하는 CDN 서비스. 전 세계의 도시에 엣지 POP를 두고 AWS 글로벌 네트워크를 통해 콘텐츠를 캐싱해서 서비스를 제공
CDN(Content Delivery Network) : 컨텐츠 제공자와 사용자 간 지리적으로 떨어져 있는 환경에서 컨텐츠를 빠르게 제공하기 위한 기술. 매번 멀리 있는 제공자에게서 컨텐츠를 가져오긴 좀 그렇잖아?
3교시
실습 : EC2 배포 및 사용
1. AWS 관리 콘솔에서 EC2 인스턴스 배포
2. 사용자 PC에서 SSH EC2 접근
3. EC2 인스턴스에 웹 서비스 설치
4. EC2 인스턴스 삭제
지금은 관리 콘솔 사이트에서 인프라를 생성하지만, 대략 다음 달부터는 yml 코드를 통해 서비스를 구축하게 될 것이다.
-> IaC 템플릿을 스택으로 만들어 배포 -> CloudFormation 서비스가 받아서 인프라 구축
-> 전제 조건 : 콘솔 창에서 인스턴스를 만드는 절차를 잘 기억할 것.
https://docs.ansible.com/ansible/2.9/modules/list_of_all_modules.html
All modules — Ansible Documentation
docs.ansible.com
Ansible 모듈 문서 잘 찾아보기
인스턴스 구성 > 고급 세부 정보 > 사용자 데이터 : 시작 시 실행되는 쉘 스크립트 정보 작성
이래저래 인스턴스를 만들고, 외부에서 접속하려면 오직 SSH
-> 접속 계정은 오직 ec2-user. 루트로도 로그인 불가. 패스워드도 꺼져 있다.
4교시
XShell로 EC2 인스턴스에 접속
-> yum repolist를 쳐보면 저장소 목록이 나온다.
-> 어제 보았듯, epel-release 설치 시에는 yum이 안 먹힌다.
-> ec2-user는 sudo 옵션을 사용할 수 있는 계정이다.
-> sudo su - 실행하면 패스워드 없이 root로 전환 가능(root에는 패스워드 없다). 그냥 su - 실행하면 패스워드를 입력하라고 뜨고, 접속 불가
-> AWS EC2 인스턴스는 SELinux가 비활성화되어 있다(getenforce -> disabled)
-> Amazon Linux에 friewalld, iptables도 없다. 아주 기초적인 내용만 있는 테스트 용도의 AMI OS
아무튼 root로 접속해서 하든, sudo로 하든 httpd 설치하고 서비스 시작하고 외부에서 접속해보면 웹 서버 가동을 확인할 수 있다.
-> 퍼블릭 IPv4 주소로 접속하거나, 퍼블릭 IPv4 DNS로 접속(Route 53이 알아서 해주는 중)
이제 관리 콘솔에서 인스턴스 상태 > 인스턴스 종료 실행하면 삭제된다.
-> 종료 = 삭제. 중지와는 다르다.
VPC(Virtual Private Cloud) : AWS 클라우드 내 논리적으로 독립된 섹션 제공. 사용자가 정의한 가상 네트워크 상에서 다양한 AWS 리소스를 실행할 수 있게 지원
-> 이러나저러나 물리적 인프라는 있어야 한다.
-> 내부 서비스끼리 통신, 외부와 통신 등
모든 리전에는 기본 VPC가 하나씩 있지만, 우리가 사용할 전용 VPC를 만들어 보자.
기본 구성 요소
-> 게이트웨이 : 외부 인터넷과 VPC 네트워크 간의 통신 담당
-> 퍼블릭/프라이빗 서브넷 : 둘 다 게이트웨이는 필요. 전자는 외부에서 그냥 접근 가능. 후자는 게이트웨이만으로는 접근 불가. NAT 게이트웨이가 추가로 필요하다(프라이빗 서브넷 -> NAT 게이트웨이 -> 게이트웨이 -> 외부 인터넷).
-> 가상 라우터 : 라우팅 테이블을 가지고 있다. 퍼블릭이 외부로 나가는 경로와 프라이빗이 외부로 나가는 경로는 다르다. 전자는 게이트웨이로 찍혀 있을 것이고, 후자는 NAT 게이트웨이로 찍혀 있을 것이다. NAT 게이트웨이에서 나오면 게이트웨이로 갈 것이고. 가상 라우터는 개념적으로 존재하는 것. 실제로는 볼 수 없다.
-> 각 클라우드가 패킷을 필터링하는 요소는 2개. 보안 그룹과 네트워크 ACL. 외부에서 들어온 패킷은 네트워크 ACL을 거친 후 서브넷의 보안 그룹을 통과. 네트워크 ACL은 서브넷 보호, 보안 그룹은 인스턴스 보호 용도
- VPC 기초
1. VPC 종류와 성질
기본 VPC : AWS가 만들어 준다. 리전 별로 딱 1개.
사용자 VPC : 사용자가 수동으로 생성. 리전 별 최대 5개 생성할 수 있다. 더 추가하려면 AWS에 따로 문의해야 한다.
- 확장성 : 클라우드 기반에 손쉽게 VPC 자원을 생성, 삭제가 가능. 설정 및 관리에 편의성 제공
- 보안 : 인스턴스 레벨과 서브넷 레벨에서 인바운드/아웃바운드 필터링을 수행할 수 있도록 보안 그룹과 네트워크 ACL을 제공하여 보안 강화
- 사용자 중심 : VPC 내 리소스에 대해 사용자가 원하는 대로 손쉽게 제어 가능. 네트워크 지표 및 모니터링 도구를 활용해 사용자에게 높은 가시성 제공
- 제약 사항 : 전통적인 네트워크 환경에서 사용 가능했던 기능이 제한되어 있거나 일부분만 사용 가능하며, 기술적 제약이 있다.
2. AWS 서브넷 개념
VPC 안에 있는 각 네트워크 장비의 범위.
AWS에서는 서브넷에 할당할 수 있는 IP 대역에서 미리 예약되어 있는 IP 주소가 존재한다. VPC 내 여러 서브넷이 존재할 경우 첫 번째 서브넷의 3번째 주소를 DNS 서버 주소로 사용한다. 나머지 서브넷의 3번째 주소는 AWS에서 예약되어 있다.
* 각 서브넷에서 예약되어 있는 IP 주소 : 사용 불가 주소
1번째 주소 : 네트워크 주소
2번째 주소 : AWS VPC 가상 라우터 주소
3번째 주소 : (첫 번째 서브넷이면) AWS DNS 서버 주소, (나머지 서브넷이면) AWS에서 예약된 주소
4번째 주소 : 향후 새로운 기능에 활용할 주소
마지막 주소 : 네트워크 브로드캐스트 주소
인스턴스는 인터페이스 2개, 공인 IP 1개, 사설 IP 1개 -> 사설 주소는 내부 통신 용도
3. AWS 퍼블릭 서브넷과 프라이빗 서브넷
VPC당 인터넷 게이트웨이는 1개
퍼블릭 서브넷 : 공인 네트워크 개념. 외부 인터넷 구간과 직접적으로 통신이 가능한 네트워크. 인터넷 게이트웨이만 있으면 충분하다.
프라이빗 서브넷 : 라우팅 테이블에서 외부로 나가는 경로가 없다. 그래서 외부와 통신이 안 되는 것. 인터페이스가 사설 IP 1개뿐이라 외부와의 통신 불가. 그래서 외부와 통신하려면 인터넷 게이트웨이를 거치기 전에 NAT 게이트웨이를 통해 나가야 한다.
-> 공인 IP 절약 용도. 공인 IP를 많이 쓰면 비용이 많이 나간다.
-> 애초에 외부와의 통신을 차단시키는 것이 목적이라 NAT 게이트웨이를 두지 않는 경우가 많다.
-> DB같이 중요한 정보를 저장할 예정이라 아예 인터넷과 연결이 안 되도록 한다.
-> 데이터가 필요하면 퍼블릭 서브넷을 통해서 전송
4. 가상 라우터와 라우팅 테이블
라우팅 테이블은 서브넷 당 1개씩 있다. 인터넷 게이트웨이는 VPC당 1개(기본값). 보안 그룹은 여러 개 둘 수 있다.
특정 대역의 VPC를 생성하면 자동으로 가상 라우터 생성(보여주지는 않음). 가상 라우터는 처음에 기본 라우팅 테이블을 가지고 있으며, 로컬 네트워크에 대한 라우팅 경로만 있다.
5교시
- 퍼블릭 서브넷 VPC 구성 실습
1. VPC 생성
AWS 콘솔 > 서비스 열어서 VPC 이동 > VPC 생성 > 이름, 대역대(10.0.0.0/16) 작성 후 생성(16~28)
2. 퍼블릭 서브넷 생성
좌측 목록에서 서브넷 클릭 > 기존 4개 서브넷은 기본 VPC에 있는 것. 서브넷 생성 > VPC 선택, 서브넷 이름 작성
> 현 리전에서 사용할 가용 영역 선택, CIDR 작성(10.0.0.0/24) 후 서브넷 생성
여기까지 서울 리전 안에 내 VPC를 만들고, 그 안에 서브넷을 하나 만든 것이다. 이제 통신을 위해 인터넷 게이트웨이 생성 및 VPC 연결
3. 인터넷 게이트웨이 생성 및 VPC 연결
좌측 목록에서 인터넷 게이트웨이 클릭 > 기존 VPC에 연결된 게이트웨이가 보인다. 인터넷 게이트웨이 생성 > 이름 작성 후 생성 > 다시 목록으로 돌아가서 인터넷 게이트웨이 ID 복사 > 해당 게이트웨이 체크 후 우측 상단의 작업 > VPC에 연결 > 연결할 VPC 선택 후 연결
이제 VPC에 외부와 소통할 수 있는 문을 달았다.
4. 퍼블릭 라우팅 테이블 생성 및 서브넷 연결
좌측 목록에서 라우팅 테이블 클릭 > VPC 만들어질 때 만들어진 기본 테이블 1 + 1개가 있다. > 라우팅 테이블 생성 > 이름 작성, VPC 선택 후 생성 > 목록에서 새로 만든 라우팅 테이블 체크, 명시적 연결을 위해 하단에 서브넷 연결 탭 클릭 > 명시적 서브넷 연결 > 서브넷 연결 편집 > 연결할 서브넷 선택 후 연결 저장
5. 퍼블릭 라우팅 레이블 경로 추가
이제 해당 라우팅 테이블의 라우팅 탭을 가보면 기본 설정이 되어 있다. 외부로 갈 패킷에 대한 경로를 추가해줘야 한다.
라우팅 편집 > 라우팅 추가 > 0.0.0.0/0에 대한 대상을 아까 만들었던 인터넷 게이트웨이 ID로 작성 후 저장
이제 기본 설정 + 새 설정 = 10.0.0.0/16은 로컬로, 0.0.0.0/0은 인터넷 게이트웨이로 보내는 라우팅 테이블 완성.
서브넷 하나당 최소 하나의 라우팅 테이블이 있어야 한다.
6. EC2 인스턴스 생성
예전에 하던 대로 인스턴스 생성 > 생성 도중 '인스턴스 구성'에서 '네트워크'를 생성했던 VPC로 선택, '서브넷'에서 생성했던 서브넷을 선택, '퍼블릭 IP 자동 할당' 활성화(서브넷에서 할당받느냐, Elastic IP로 할당받느냐의 차이) > 나머지는 동일하게 쭉 넘어가고 생성
7. EC2 인스턴스 접근 후 통신 확인
XShell로 접속 후 핑 테스트
특정 인스턴스 유형이 특정 가용 영역에서 지원되지 않는 경우가 있다. d 영역은 공용 서비스류가 들어가고, a/b/c 영역에는 사용자 설정 인스턴스가 들어간다.
6교시
- 프라이빗 서브넷 VPC 구성 실습
1. 프라이빗 서브넷 생성
서브넷 > 서브넷 생성 > VPC 선택, 서브넷 이름 작성, 가용 영역 선택(아까와 다른 가용 영역에 두기), IPv4 CIDR 입력 후 생성(생성 과정 자체는 다를 것이 없다)
퍼블릭과의 차이는 라우팅 정보를 주지 않을 것이라는 점이다.
2. NAT 게이트웨이 생성
인터넷 게이트웨이는 아까 만들어 놨으니 좌측 목록의 NAT 게이트웨이 클릭 > 이름 작성, 서브넷 선택(퍼블릭), 연결 유형은 퍼블릭, 탄력적 IP 할당 클릭 > 생성
서브넷을 프라이빗으로 선택하면 외부에서 NAT로 접근이 안된다. 그림 상으로는 프라이빗 쪽에 있지만 실제 위치는 퍼블릭 쪽에 있다.
프라이빗 서브넷이 외부와 통신할 일이 없다면 NAT 게이트웨이를 만들 필요가 없다. 오히려 실무에서는 프라이빗 서브넷이 외부랑 통신을 못하도록 막는 것이 일반적.
3. 프라이빗 라우팅 테이블 생성 및 서브넷 연결
라우팅 테이블 생성 > 이름 작성, VPC 선택 후 생성 > 서브넷 연결 > 서브넷 연결 편집 > 프라이빗 서브넷 선택 후 저장
4. 프라이빗 라우팅 테이블 경로 추가
라우팅 > 라우팅 편집 > 0.0.0.0/0에 대한 대상을 만들었던 NAT 게이트웨이로 선택 후 저장
5. EC2 인스턴스 생성
이제 EC2 인스턴스 생성 > '인스턴스 세부 정보 구성'에서 '네트워크'는 만들었던 VPC로, '서브넷'은 만들었던 프라이빗 서브넷으로, '퍼블릭 IP 자동 할당'은 서브넷 사용 설정(비활성화)
서브넷 사용 설정(비활성화) 하면 이 서브넷에는 IP가 할당되지 않는다.
네트워크 인터페이스에서 eth0은 내부(사설) 통신 용도, eth1은 외부 통신 용도
#!/bin/bash
(
echo "qwe123"
echo "qwe123"
) | passwd --stdin root
sed -i "s/^PasswordAuthentication no/PasswordAuthentication yes/g" /etc/ssh/sshd_config
sed -i "s/^#PermitRootLogin yes/PermitRootLogin yes/g" /etc/ssh/sshd_config
service sshd restart
위 내용을 고급 세부 정보의 사용자 데이터 부분에 작성.
root 패스워드를 설정하는 코드 + 패스워드 인증 yes로 변경하는 코드 + SSH root 로그인 허용(주석 해제) 하는 코드
-> 퍼블릭에서 프라이빗으로 통신 테스트를 하기 위한 설정
-> 프라이빗에서 나가서 밖에서 응답을 받아올 수는 있지만, 외부에서 프라이빗으로 들어가는 것은 안됨(포트 포워딩 미설정)
6. EC2 인스턴스 접근 후 통신 확인
이제 생성해보면, 퍼블릭 IPv4 주소가 없다. 이 인스턴스에 접근하려면 퍼블릭 인스턴스에서 접근해야 한다.
퍼블릭 인스턴스에서
-> ssh root@[프라이빗 IPv4 주소] 실행해서 접근
-> root 패스워드 입력. 접속 성공
7. 퍼블릭 서브넷과 프라이빗 서브넷의 통신 과정
퍼블릭 라우팅 테이블에서 [프라이빗 IPv4 주소]와 더 많이 일치하는 선택지 선택 > 10.0.0.0/16 로컬로 전송 > [프라이빗 서브넷 주소] 서브넷 탐색 > 전송
-> ping은 보여주지 않으셨다. 안되는게 맞는걸까?
퍼블릭을 통하지 않고 생짜로 NAT 게이트웨이를 통해 들어가려고 하면?
-> NAT 게이트웨이를 가봤자 프라이빗 VPC의 어디로 보낼지에 대한 정보가 없음. 통신 불가.
8. 자원 삭제
만들었던 자원들 역방향으로 삭제
-> EC2 인스턴스 삭제
-> NAT 게이트웨이 삭제
-> 탄력적 IP로 가서 NAT 게이트웨이가 썼던 탄력적 IP 연결 해제(NAT 게이트웨이 삭제되면 자동 해제됨) 후 릴리스
-> VPC 삭제 : 연결되어 있던 서브넷과 라우팅 테이블 함께 삭제됨
7교시
실습 내용 복습. 다시 만들어 보자.
프라이빗 인스턴스 접속 부분에서 에러 발생. 권한 오류라는데 아깐 안 이러던 게 왜 이러지?
-> 나중에 다시 해보자. 어디서 문제가 발생한 것인지 감이 안 온다.
-> EC2 생성 후 완전히 가동될 때까지 기다릴 것.
서브넷 자체는 사설/공인의 차이가 없다. 차이가 발생하는 시점은
1. 인스턴스 생성 시 IP 할당을 어떻게 받는가 : 공인 IP를 할당받는가?
2. 라우팅 테이블이 어디로 연결되었냐 : 0.0.0.0/0이 어디로 매핑되었는가?
8교시
지금까지 배운 것은 VPC 기초.
- VPC 엔드포인트
-> 격리된 프라이빗 서브넷에서도 AWS 퍼블릭 서비스와 프라이빗 네트워크 통신을 사용해 안전한 통신 제공
퍼블릭 서비스 : 공개적으로 운영되는 서비스
어차피 다 AWS 서비스인데, 서로 통신할 때 굳이 외부 인터넷을 거쳐서 통신할 필요가 있나? 낭비잖아?
-> 집 안의 다른 방으로 가겠다고 밖으로 나갔다가 들어갈 필요는 없다.
-> 프라이빗 네트워크 통신을 서비스 간에 연결해 통로를 만든다.
-> 외부 인터넷이 안되더라도 내부적으로 통신
1. 엔드포인트 : AWS 퍼블릭 서비스 대상에 대한 프라이빗 연결
1-1. 게이트웨이 엔드포인트 : AWS 퍼블릭 서비스 중 S3와 DynamoDB에 대한 연결
1-2. 인터페이스 엔드포인트 : 위 대상 외에 나머지 AWS 퍼블릭 서비스에 대한 연결
2. 엔드포인트 서비스 : 사용자가 지정한 특정 서비스 대상에 대한 프라이빗 연결
- 엔드포인트 특징
1. 보안 측면 강화 : 프라이빗 연결을 통해 외부 구간으로 노출이 되지 않음
2. 서비스 제약 : 연결 대상 서비스는 동일 리전에 속한 서비스만 가능
3. VPC 종속 : 오직 하나의 VPC에만 연결 가능(다수의 VPC에 종속 불가)
4. 권한 제어 : AWS IAM 기능을 통해 정책을 수립, VPC 엔드포인트에 대한 권한 부여가 가능
- 게이트웨이/인터페이스 엔드포인트 비교 실습
VPC 안에 퍼블릭/프라이빗 서브넷을 구축하되, NAT 게이트웨이는 두지 않는다.
게이트웨이 엔드포인트를 통해 S3와 VPC 간의 연결 구축
프라이빗 서브넷에 인터페이스 엔드포인트를 만들어 CloudFormation과의 연결 구축
1. 기본 실습환경 구축
2. 게이트웨이 엔드포인트 생성
3. 게이트웨이 엔드포인트 검증
4. 인터페이스 엔드포인트 생성
5. 인터페이스 엔드포인트 검증
6. 자원 삭제
시간 관계상 실습은 내일
어제 듣지 못한 7~8교시 내용은 반드시 다시 들을 것.
1, 2교시는 개념 수업. 다시 한번 듣자
+ 퍼블릭/프라이빗 서브넷/인스턴스 구축 다시 한 번
'교육' 카테고리의 다른 글
| [44일 차] 21.09.23 : AWS 4 (0) | 2021.09.23 |
|---|---|
| [43일 차] 21.09.17 : AWS 3 (0) | 2021.09.22 |
| [41일 차] 21.09.15 : Ansible 5(AWS, VPC), AWS 1 (0) | 2021.09.15 |
| [40일 차] 21.09.14 : Ansible 4(Handler, Templates, vars, Roles) (0) | 2021.09.14 |
| [39일 차] 21.09.13 : Ansible 3(전자 서명 자동 구축, 동적 구성) (0) | 2021.09.13 |
댓글