1. Google cloud 제품 및 서비스의 목적과 가치 파악
2. 인프라 구성 제어 방법 정의

실무형 실습 - Handson-lab

GCP 소개

1. 클라우드 컴퓨팅 개요
   • 클라우드 컴퓨팅 소개:
     • 고객은 주문형 및 셀프 서비스형 컴퓨팅 리소스를 확보함
       • 어디서나 인터넷을 통해 리소스 액세스 가능
     • 해당 풀의 리소스를 사용자에게 할당
     • 리소스는 탄력적, 고객 역시 유연함의 해택을 누림
     • 고객은 사용 및 예약한 만큼의 비용만 지불함
   • 역사:
     • 1세대: 코로케이션
       • 2세대: 가상 데이터 센터
         • 여전히 인프라를 유지하는 기업
           • 사용자 제어 환경
           • 사용자 구성 환경
     • 3세대: 컨테이너 기반 아키텍쳐
2. IaaS Paas
   • IaaS: Infra as a Service
     • 원시 컴퓨팅, 스토리지, 네트워크 기능 제공.
   • PaaS: Platform as a service
     • 모든 HW와 SW 제공 및 관리. ex) 라이브러리 까지 제공
   • 결제 모델: IaaS는 할당 리소스에 대한 비용 지불, Paas는 사용 리소스에 대한 비용 지불
3. Google Cloud 네트워크
   • 인프라 위치: 북미, 유럽, 아시아, 남미, 오스트레일리아
   • 리전 및 영역: 위치, 리전, 영역
     • 각 위치는 다양한 리전과 영역으로 나뉨
     • 리전은 독립적인 지리적 구역을 나타내며 영역으로 구성됨.
     • 영역은 클라우드 리소스가 배포되는 곳
     • 리소스는 여러 리전에서 실행 가능
     • 일부 서비스는 멀티 리전 지원
   • 39개 리전, 118 영역 지원
4. 친환경적
   • 핀란드 해수 사용 냉각 시스템
5. 보안
   • 서비스 배포: RPC(리포트 프로시져 콜)을 사용해 통신.
   • 스토리지: 저장 데이터 암호화
   • 인터넷 통신 수준: GFE, DoS
6. 개방형 API 및 오픈 소스
   • 호환 오픈소스: TensorFlow, k8s
7. 가격 책정 및 결제
   • 초당 청구
   • 지속 사용할인 제공: 월 25% 이상 실행시 증분 시간에 대해 자동 할인 제공
   • 커스텀 가상 머신 유형: 워크로드에 맞게 가격 조정 가능
     • 예산 책정 및 모니터링: 예산, 알림, 보고서, 할당량 제공
       • 할당량: 비율 할당량, 배정 할당량

GCP의 리소스 및 액세스

계층적인 구조 리소스

• 4가지 수준으로 구성: 리소스, 프로젝트, 폴더, 조직 노드 (오른쪽 방향으로 상위 계층)
  • 리소스
  • 프로젝트
  • 폴더
  • 조직 노드
• 개별 리소스에 정책 적용 가능

• 고유성과 변경 가능성 측면에서 상이한 프로젝트 속성

• 프로젝트: API 관리, 결제 사용 설정, 공동 작업자 추가 제거 등 서비스 사용 및 설정하기 위한 기반
  • 조작 노드 아래에 있는 개별 항목
  • 프로젝트에는 리소스가 있으며, 각 리소스는 하나의 프로젝트에만 존재
  • 프로젝트의 소유자와 사용자가 다를 수 있음
  • 프로젝트는 별도로 청구

IAM

Identity and Access Management 정책 적용

실습

개요

오후 강의

VPC

다른 네트워크에 연결할 수 있는 Google VPC 네트워크

• cloud VPN, 다이렉트 피어링, 이동통신사 피어링, Dedicated Interconnect, Partner Interconnect, Cross-Cloud Interconnect
• Cloud VPC: VPN 터널 연결을 생성. Cloud Router를 사용해 연결을 동적으로 만듦

DNS는 Domain Name System으로, 도메인 주소(예: www.google.com)를 IP 주소(예: 127.0.0.1)로 변환하는 역할을 한다. 비유하자면 일종의 전화번호부로, 사람이 복잡한 IP 주소를 일일이 외우고 다니지 않아도 해당 웹 서비스의 도메인 이름만 입력해도 올바른 서버에 연결할 수 있도록 도와준다. DNS는 '시스템'로써 도메인을 IP로 변환하는 과정 전체를 의미하기 때문에 여러 계층과 구성 요소로 이루어져 있으며, 전 세계적으로 분산된 서버 네트워크를 포함한다.

또한 서버 IP 변경에 쉽게 대처할 수 있으므로 네트워크 통신에서 DNS의 역할이 매우 중요하며, 특히 최근 클라우드 기반 인프라 구성이 많아지면서 인프라가 빈번히 변경되고, MSA(Micro Service Architecture) 기반의 서비스 설계가 많아지면서 다수의 API를 이용하다보니 사용자의 호출뿐만 아니라 서비스 간 API 호출이나 인터페이스가 많아져 DNS의 역할은 더 중요해지고 있다.

용어 정리 IP: 서버 실제 주소 (예: 127.0.0.1) 도메인: 사이트 이름 (예: www.example.com) DNS: 도메인을 통해 실제 IP에 접속하는 프로세스 일체 DNS 서버: 사이트 이름의 IP를 가리켜주는 서버

참고 인터넷은 전 세계 컴퓨터 네트워크가 상호 연결되어 있는 거대한 네트워크입니다. 이 네트워크 상에서 각 장치(예: 웹 서버, 사용자의 컴퓨터)는 고유한 IP 주소를 가지고 있습니다. 이 IP 주소는 인터넷 상에서 데이터를 전송하고 받을 때 장치를 식별하는 데 사용됩니다. 즉, 웹 서비스를 이용하려면 해당 서비스가 호스팅되고 있는 서버의 IP 주소를 알아야만 데이터를 올바른 목적지로 보낼 수 있습니다.

특징

• OSI 7 Layer에서 7 Layer(Application Layer, 응용 계층)에 해당하는 프로토콜
• 데이터 프로토콜이 잘 동작하도록 도와주는 컨트롤 프로토콜. 통신에 직접 관여하지 않지만 처음 통신하거나 통신을 유지하는데 큰 역할을 함
• Port
  • DNS는 속도가 중요하기 때문에 기본적으로 UDP/53를 사용
    • 특수한 경우(로드가 많은 경우)에는 TCP/53 사용
  • 데이터가 512 byte를 넘는 경우(예: 많은 수의 리소스 레코드가 포함된 경우) - UDP는 데이터 크기가 512 byte로 제한되기 때문
  • Zone Transfer(DNS 서버간 동기화를 위해 DNS Zone을 전송하는 경우) - 이 때는 속도보다 신뢰성이 중요하기 때문
• 상위/하위 기관과 같은 '계층 구조'를 갖는 분산 데이터베이스 구조

DNS 구조와 명명 규칙

도메인은 역 계층 구조로 이루어져 수많은 인터넷 주소 중에서 원하는 주소를 효율적으로 찾아갈 수 있다. 역트리 구조로 최상위 루트부터 TLD(Top-Level Domain, 최상위 도메인), SLD(Second-Level Domain, 차상위 도메인), Third-Level Domain과 같이 하위 레벨로 주소를 단계적으로 찾아간다. 도메인 주소를 사용할 때 각 계층의 경계를 .으로 표시하고 뒤에서 앞으로 해석한다.

도메인과 URL URL(Uniform resource Localator)은 도메인을 포함한 경로로, 사용자가 도메인 서버로 접속을 원할때 프로토콜 + 도메인 + 경로 등을 통합적으로 나타내는 주소이다.

DNS 구현 요소

1. Domain Name Space: DNS가 관리하는 계층적 데이터 베이스(= 트리구조로 구성된 분산 데이터 베이스 ).
2. Name Server: DNS에서 도메인 및 그 데이터에 관한 정보를 보유/관리하는 DNS 서버(또는 서버용 프로그램)
   • 기능: 도메인 정보의 저장 및 관리 + 변환 요청에 대한 응답 수행(DNS 질의에 대한 응답)
3. Resolver: Resolver = Recursive DNS Server = Local Server(of ISP) = Recursor

DNS 서버 종류

모든 DNS 서버는 네가지 카테고리로 분류된다.

• DNS 리커서(Recursor, 재귀확인자) - 리커서는 도서관의 어딘가에서 특정한 책을 찾아달라고 요청받는 사서로 생각할 수 있습니다. DNS 리커서는 웹 브라우저 등의 애플리케이션을 통해 클라이언트 컴퓨터로부터 쿼리를 받도록 고안된 서버입니다. 일반적으로, 리커서는 클라이언트의 DNS 쿼리를 충족시키기 위해 추가 요청을 수행합니다.
• 루트 이름 서버 - 루트 서버는 사람이 읽을 수 있는 호스트 이름을 IP 주소로 변환(확인)하는 첫 번째 단계입니다. 도서관에서 책장 위치를 가리키는 색인으로 생각할 수 있으며, 일반적으로 다른 더욱 특정한 위치에 대한 참조로 사용됩니다.
• TLD 이름 서버 - TLD(Top-Level Domain, 최상위 도메인) 서버는 도서관의 특정 책장으로 생각할 수 있습니다. 이 이름 서버는 특정 IP 주소 검색의 다음 단계이며 호스트 이름의 마지막 부분을 호스팅합니다(example.com에서 TLD 서버는 “com”입니다).
• 권한 있는 이름 서버(Authorative Name Server) - 최종 이름 서버로서, 책장에 있는 사전처럼 특정 이름을 해당 정의로 변환합니다. 권한있는 이름 서버는 이름 서버 쿼리의 종착점입니다. 권한있는 이름 서버가 요청한 레코드에 대한 액세스 권한이 있다면, 요청한 호스트 이름의 IP 주소를 초기 요청을 한 DNS 리커서(사서)에게 돌려 보냅니다.

DNS 동작 과정

DNS 조회 단계

0. 사용자의 도메인 입력 -> 브라우저 캐시 확인(DNS 쿼리) -> OS 캐시 확인(systemcall) -> 라우터 캐시 확인 -> ISP(Internet Service Provider, 인터넷 서비스 제공자) 캐시 확인

(캐싱된 정보가 없는 경우, 아래 단계 진행)

1. 쿼리가 인터넷으로 이동 -> DNS 재귀 확인자에서 수신
2. 확인자가 DNS 루트 이름 서버(.)를 쿼리
3. 루트 서버가 TLD DNS 서버(예: .com, .net) 주소로 확인자에 응답.
4. 확인자가 .com TLD에 요청
5. TLD 서버가 도메인 이름 서버의 IP 주소로 응답
6. 재귀 확인자가 도메인 이름 서버로 쿼리 전송
7. IP 주소가 이름 서버에서 확인자에게 반환
8. DNS 확인자가 처음 요청한 도메인의 IP 주소로 웹 브라우저에 응답

(IP 주소가 반환되면, 브라우저가 웹 페이지를 요청할 수 있음.) 9. 브라우저가 IP 주소로 HTTP, HTTPS 요청 전송 -> 해당 IP의 서버에서 렌더링할 웹 페이지 반환

레코드

가장 일반적인 DNS 레코드 유형

• A 레코드 - 도메인의 IP 주소를 갖고 있는 레코드. A 레코드에 대해 자세히 알아보세요.
• AAAA 레코드 - 도메인의 IPv6 주소를 포함하는 레코드(IPv4 주소를 나열하는 A 레코드와 반대).AAAA 레코드에 대해 자세히 알아보세요.
• CNAME 레코드 - 하나의 도메인이나 하위 도메인을 다른 도메인으로 전달하며, IP 주소를 제공하지는 않습니다. CNAME 레코드에 대해 자세히 알아보세요.
• MX 레코드 - 이메일을 이메일 서버로 전송합니다. MX 레코드에 대해 자세히 알아보세요.
• TXT 레코드 - 관리자가 레코드에 텍스트 메모를 저장할 수 있습니다.이 레코드는 종종 이메일 보안에 사용됩니다.TXT 레코드에 대해 자세히 알아보세요.
• NS 레코드 - DNS 항목의 이름 서버를 저장합니다. NS 레코드에 대해 자세히 알아보세요.
• SOA 레코드 - 도메인에 대한 관리자 정보를 저장합니다. SOA 레코드에 대해 자세히 알아보세요.
• SRV 레코드 - 특정 서비스에 대한 포트를 지정합니다. SRV 레코드에 대해 자세히 알아보세요.
• PTR 레코드 - 리버스 조회에서 도메인 이름을 제공합니다. PTR 레코드에 대해 자세히 알아보세요.

CDN과 GSLB

CDN (Content Delivery Network)

• 정의: 데이터 사용량이 많은 애플리케이션의 웹 페이지 로드 속도를 높이는 상호 연결된 서버 네트워크(지리적으로 분산된 여러 개의 서버). 전 세계에 분산된 서버 네트워크를 통해 컨텐츠를 사용자에게 빠르게 전달하는 시스템으로써, 컨텐츠를 사용자에게 물리적으로 가까운 서버에서 제공함으로써 로딩 시간을 줄이고 성능을 향상시킨다.
• 장점
  • 성능 향상: 컨텐츠 캐싱을 통해 렌더링, 버퍼링 시간 단축 -> 사용자에게 고품질의 빠른 웹 경험 제공 가능
  • 가용성 보장: 분산되어 있기 때문에 하나의 서버에 장애가 발생해도 컨텐츠 제공이 가능함
  • 보안성 강화: DDoS 완화, 보안 인증 개선 등
  • 대역폭 비용 절감: 사용자와 더 가까운 서버에서 컨텐츠를 전송함으로써 대역폭 소비와 관련 비용 절감 가능

GSLB (Global Server Load Balancing)

• 정의: 트래픽을 전 세계에 걸쳐 분산된 서버에 배포하는 방식. 사용자의 위치 뿐만 아니라 서버의 상태, 네트워크 지연 등 다양한 요소를 고려해 최적의 서버로 사용자의 요청을 라우팅한다.
• 특징: CDN이 컨텐츠 전송에 최적화 되어있다면, GSLB는 글로벌 트래픽 관리와 라우팅에 초점을 맞추고 있다.

VMware 환경에서 사용하던 VM을 AWS로 옮길 수 있을까?

쿠버네티스 공부겸 cka 시험을 준비하면서 데스크탑에 VMware를 설치하고 쿠버네티스 환경을 구성했다. 하지만 사람 일이란게 스터디카페 등 다른 곳에서 공부해야하는 상황이 생길 수 밖에 없었고, 그렇다고 데스크탑을 들고 다닐 수 없었기에 늘 아쉬움이 있었다. 그래서 생각한 방안들이 외장 하드 디스크에 VM을 설치해서 사용하기, 노트북에 설치하기, Google Chrome의 Remote Control Desktop을 이용해 데스크탑에 원격으로 접속하는 방법 등을 고려했었다. 하지만 데스크탑(램: 32 GB, CPU: i7-6700k)에 설치된 가상 환경은 각각 2GB의 램과 2개의 CPU 코어를 사용하는 7개의 VM을 운영 중이었고, 내 램 8GB짜리 M2 MacBook Air로는 이를 구현하기 어려웠다. 원격 접속은 데스크탑을 계속 켜둬야 하고, 이 경우 다른 사람이 사용하기 어려워 이 방법도 버려야 했다. 그러다 VM을 AWS로 마이그레이션해서 사용할 수 없을까? 라는 생각을 했고, AWS VMware import 방법을 발견했다. 이번 글은 VM import 과정을 적어볼까 한다.

사전 준비

일단, 당연하게도 VM 환경과 AWS cli 설치가 필요하다. 여기서는 Windows 10, CMD, AWS CLIv2, VMware Workstation을 기준으로 작성하였다. 또한, 사용하려는 AWS 계정에 S3와 EC2에 대한 권한 역시 필요하다. root 계정인 경우는 상관 없지만, 사용자를 생성해서 사용하는 경우, 아래 권한을 추가해야한다. ({{대상 버킷}}을 사용하려는 버킷의 이름으로 변경 필요) S3 관련 권한: 특정 S3 버킷과 그 안의 객체에 대한 읽기 및 쓰기 작업 허용 EC2 관련 권한: 인스턴스 및 이미지 작업 취소, 생성, 설명, 태그 생성, 이미지 가져오기 및 내보내기, 인스턴스 상태 제어(시작, 중지, 종료) 등

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetBucketLocation",
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": ["arn:aws:s3:::{{대상 버킷}}","arn:aws:s3:::{{대상 버킷}}/*"]
    },
    {
      "Effect": "Allow",
      "Action": [
        "ec2:CancelConversionTask",
        "ec2:CancelExportTask",
        "ec2:CreateImage",
        "ec2:CreateInstanceExportTask",
        "ec2:CreateTags",
        "ec2:DescribeConversionTasks",
        "ec2:DescribeExportTasks",
        "ec2:DescribeExportImageTasks",
        "ec2:DescribeImages",
        "ec2:DescribeInstanceStatus",
        "ec2:DescribeInstances",
        "ec2:DescribeSnapshots",
        "ec2:DescribeTags",
        "ec2:ExportImage",
        "ec2:ImportInstance",
        "ec2:ImportVolume",
        "ec2:StartInstances",
        "ec2:StopInstances",
        "ec2:TerminateInstances",
        "ec2:ImportImage",
        "ec2:ImportSnapshot",
        "ec2:DescribeImportImageTasks",
        "ec2:DescribeImportSnapshotTasks",
        "ec2:CancelImportTask"
      ],
      "Resource": "*"
    }
  ]
}

VM 내보내기(VM Export)

VM을 AWS로 가져오기(Import)를 하려면, 먼저 해당 VM의 OVA 파일이 필요하다. 따라서 VM을 OVA 파일로 Export하는 과정이 필요하다. 이 과정에서 주의할 점은 확장자를 OVA로 지정해주지 않는 경우 OVF 파일로 Export 되기 때문에 확장자를 OVA로 지정해줘야한다는 점이다. 물론 OVF 파일로 다운 받아도 OVA 파일로 패키징하면 되지만, 단계가 하나 더 생기는거라 매우 귀찮아진다.

1-1. VM Export

내보내기할 VM 선택 -> File -> Export to OVF... 클릭

파일 이름 및 확장자 지정 후 설치

윈도우 환경에서 파일 확장자 확인하는법 파일 탐색기 화면 상단 보기 클릭 -> 오른쪽 '표시/숨기기' 항목들 중 '파일 확장명' 체크 표시.

1-2. 변환 (위 과정에서 OVA로 export한 경우 생략)

만약 OVF 파일로 Export 했다면, ovftool을 이용해서 OVA 파일로 패키징하는 과정이 필요하다. VMware Workstation의 경우에는 ovftool이 자동으로 설치되기 때문에 따로 설치할 필요는 없지만(ovftool이 없는 경우 설치 필요), 대신 변수 설정이 안되어 있다면 cmd 창에서 사용시 ovftool 응용프로그램이 설치된 파일로 위치를 이동하거나 경로를 지정해줘야한다. 보통 C:\Program Files (x86)\VMware\VMware Workstation\OVFTool 에 위치한다.

cmd 창에서 ovftool [원본 OVF 파일 경로] [대상 OVA 파일 경로]를 입력하면 ovf 파일을 ova 파일로 변환 해준다.

S3 생성

2-1. 버킷 생성

S3 -> 버킷 만들기 선택

이름 설정(버킷 이름은 고유해야되므로 안겹치게 만들어야됨) 및 옵션 선택 -> 버킷 만들기

생성한 버킷으로 이동 -> 업로드 클릭 -> 파일 추가 클릭 후 ova 파일 업로드

업로드 후 모습

필요한 IAM 권한 설정

AWS에서 OVA 파일을 실행하려면, 해당 파일을 AWS EC2 인스턴스로 변환하고 실행해야한다. 하지만 VM Import/Export 작업을 수행하려면 적절한 IAM(Identity and Access Management) 역할과 권한이 필요하므로, AWS cli 또는 AWS Management Console을 통해 이를 설정해야 한다.

3-1. IAM 역할 생성

IAM -> 역할 -> 역할 생성 클릭

엔터티 유형 AWS 서비스 선택 -> 서비스 또는 사용 사례 EC2 선택 -> 다음 클릭

권한 추가 선택 X(권한은 나중에 직접 생성할 예정) -> 다음 클릭

역할 이름 설정 -> 역할 생성 클릭

3-2. 역할에 권한 추가

IAM -> 역할 -> 생성한 IAM 역할 검색

대상 IAM 역할 클릭 -> 권한 -> 인라인 정책 생성(Inline Policies)

권한 지정 -> 정책 편집기 JSON 선택 -> 내용 입력 -> 다음 클릭

JSON 내용({{대상 버킷}}을 사용하려는 버킷 이름으로 변경 필요)

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetBucketLocation",
                "s3:GetObject",
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::{{디스크 이미지용 버킷}}",
                "arn:aws:s3:::{{디스크 이미지용 버킷}}/*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetBucketLocation",
                "s3:GetObject",
                "s3:ListBucket",
                "s3:PutObject",
                "s3:GetBucketAcl"
            ],
            "Resource": [
                "arn:aws:s3:::{{내보낸 이미지용 버킷}}",
                "arn:aws:s3:::{{내보낸 이미지용 버킷}}/*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "ec2:ModifySnapshotAttribute",
                "ec2:CopySnapshot",
                "ec2:RegisterImage",
                "ec2:Describe*"
            ],
            "Resource": "*"
        }
    ]
}

고객 관리형 정책(Customer Managed Policies)을 생성하고 역할에 해당 정책을 부여해도 되지만, 개인이 쓸거고 특정 IAM에 특정 버킷에 대한 접근 권한을 부여할 생각이었기 때문에 인라인 정책을 생성했다. 재사용이 필요한 경우 관리형 정책을 생성하는 것이 좋다.

인라인 정책이란? 단일 IAM 자격 증명(사용자, 그룹 또는 역할)에 대해 생성되는 정책입니다. 인라인 정책은 정책과 자격 증명을 정확히 1대 1 관계로 유지합니다. 이는 자격 증명을 삭제하면 삭제됩니다. 자격 증명을 생성하거나 이후에 생성할 때 정책을 생성하여 자격 증명에 삽입할 수 있습니다. 정책이 둘 이상의 엔터티에 적용될 수 있는 경우 관리형 정책을 사용하는 것이 좋습니다. 출처: https://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies

AWS cli 사용하는경우

1. trust-policy.json 파일 생성 - 역할 생성에 필요

   {
   "Version": "2012-10-17",
   "Statement": [
      {
         "Effect": "Allow",
         "Principal": { "Service": "vmie.amazonaws.com" },
         "Action": "sts:AssumeRole",
         "Condition": {
            "StringEquals":{
               "sts:Externalid": "vmimport"
            }
         }
      }
   ]
   }

2. 역할 생성 aws iam create-role --role-name {{역할 이름}} --assume-role-policy-document "file://{{trust-policy.json 파일의 절대 경로}}"

3. role-policy.json 파일 생성 - 정책 생성에 필요. 내용은 AWS Console 사용 방법에서 쓴 json 파일과 동일

4. 정책을 역할에 연결 aws iam put-role-policy --role-name {{역할 이름}} --policy-name {{정책 이름}} --policy-document "file://{{role-policy.json 파일의 절대 경로}}"

OVA 파일 AMI로 변환

자, OVA 파일도 준비가 됐고 역할에 권한도 부여했으니 이제 S3에 저장된 OVA 파일을 AMI로 변환하는 과정만 진행하면 된다.

4-1. JSON 파일 작성

OVA 포맷의 가상 머신 이미지를 EC2 AMI로 변환하기 위해서는 구체적인 설정이 필요하다. 즉, '어디'에 있는 '어떤 형식'의 '무슨 파일'을 변환할 것인가에 대한 정보가 필요한데, 이를 위해서 변환하고자하는 OVA 파일에 대한 정보를 JSON 파일을 통해 제공해야한다.

JSON 파일 내용

[
    { 
        "Description": "{{변환될 이미지에 대한 설명}}", 
        "Format": "ova", 
        "UserBucket": { 
            "S3Bucket": "{{대상 버킷}}", 
            "S3Key": "{{변환할 OVA파일 이름}}.ova" 
        } 
    }
]

작성한 json 파일들. 여러개의 VM을 변환할 것이었기에 VM당 하나의 JSON 파일을 작성했다.

4-2. OVA 파일 AMI로 변환

이제 아래 AWS CLI 명령어로 파일을 변환해주면 된다. aws ec2 import-image --disk-containers "file://{{4-1.에서 작성한 json파일의 경로}}" --role-name {{역할 이름}} 명령어를 입력하면 다음과 같은 출력과 함께 변환이 시작된다.

이미지로의 변환 과정 현황은 다음 명령어를 통해 모니터링 할 수 있다. AMI ID 값은 위에서 출력된 값을 입력하면 된다. aws ec2 describe-import-image-tasks {{import 중인 AMI의 ID값}}

4-3. 다수의 OVA 파일 변환

필자의 경우 총 7개의 VM을 변환해야했는데 aws cli 명령어를 일일이 치기 귀찮아서 윈도우의 bat 파일을 이용했다. txt 파일에 변환할 VM에 대응하는 JSON 파일 이름들을 저장하고, bat 파일에 반복문을 사용해서 모두 실행하도록 만들었다.

목록 작성

bat 파일 작성(txt로 작성 후 bat로 확장자 변경)

@echo off
for /f %%i in (ovafiles.txt) do (
    set FILENAME=%%i
    aws ec2 import-image --description "Imported from %%i" --disk-containers "file://%%i.json" --role-name {{역할 이름}}
)

모든 이미지의 변환 모니터링 명령어 aws ec2 describe-import-image-tasks

4-3. 변환 확인

변환된 이미지는 AWS Management Console에서 확인이 가능하다.

EC2 -> 이미지 -> AMI -> 목록 확인

TMI 1.) OVA 파일 변환은 OVA 파일을 EBS 스냅샷으로 변환하고, 이 스냅샷에서 AMI를 생성하는 과정을 거치게 된다. 따라서 EBS 스냅샷 목록에서도 변환된 목록을 확인할 수 있다.

EC2 -> Elastic Block Store -> 스냅샷

TMI 2.) aws ec2 import-image 명령어를 사용할 때 직접적으로 스냅샷과 AMI의 이름을 지정하는 옵션은 제공되지 않는다. 따라서 Name 항목은 따로 입력하는 과정이 필요하다.

2023.10.23 AWS 네트워크 소모임

개요

• AWS 라우팅을 이해하기 위한 라우팅이 무엇인지, (아주) 가볍게 알아보기!
• AWS에서 라우팅이 어떻게 사용되는지 알아보기
  • Routing Table, Peering, Transit Gateway 등.

라우팅이란?

컴퓨터 네트워크는 노드라고 하는 여러 시스템과 이러한 노드를 연결하는 경로 또는 링크로 구성됩니다. 상호 연결된 네트워크에서 두 노드 간의 통신은 여러 경로를 통해 이루어질 수 있으며, 라우팅은 이처럼 상호 연결된 네트워크에서 미리 정해진 규칙을 이용해 최상의 경로를 선택하는 프로세스입니다.

요약하자면, 어떤 목적지(네트워크)로 가려면 여기(Next Hop)로 가세요.

라우팅의 필요성

장비의 역할

경로 학습 및 사용자 경로 지정

Routing 동작 출발지 -> 목적지로 가기 위한 단계. Hop by Hop 라우팅이라고도 부름

Routing 경로

• direct
• static: 양쪽 라우팅 테이블에 상대에 대한 주소가 각각 있어야됨.
• dynamic: static이 dynamic 보다 높은 우선 순위를 가진다.

AWS에서 사용하는 라우팅: BGP AWS의 라우팅 우선 순위: 다이렉트 커넥트 > VPN

목적지(네트워크): Destination = destination = Address prefix 도착지(): gateway = target = next hop

10.0.0.0/16에 10.0.0.0/24 서브넷이 존재한다고 할 때, On-premise에서는 10.0.0.0/24만 Local Network로 잡히지만, AWS에서는 CIDR에 의해 VPC 전체가 하나의 Local Network로 잡힘.

VPC 간의 연동: Peering

VPC간의 Private 연결 필요 라우팅을 통한 통신 중복되지 않는 IP 주소 설계 필요 Peering 생성 후 라우팅 설정이 필요함.

다수 VPC 연동: AWS Transit Gateway

다수의 VPC를 연동해야하는 경우, VPC는 transit 기능이 없기 때문에 VPC마다 각각의 Peering 연결이 필요하다(ex. ABC 연결 시, A-B, B-C, C-A 각각 Peering 연결 필요). 따라서 다수의 VPC를 연결할 때에는 Peering 대신 AWS Transit Gateway를 사용해서 다수의 VPC를 HUB에 연결한 것처럼 사용이 가능함. AWS Transit Gateway끼리 연결에서는 Propagation(전파)이 새로 필요함. 라우팅 테이블을 이용해 통신 분리가 가능함.

IP 중복시

중간계층을 생성해서 중복된 IP를 연결할 수도 있음.

Peering과 Transit Gateway 사용에 관하여...

클라우드 설계시 비용 측면에서 구성할 필요가 있다. 대용량 데이터 처리의 경우, transit gateway를 사용하는 경우 Peering과 달리 통신 마다 비용이 발생하기 때문에 On-premise 및 다수 VPC 연결시 비용 측면에서 구성을 고민할 필요가 있다.

EC2 시작 템플릿 -> 시작 템플릿 생성 클릭

Auto Sclaing Group 생성

Auto Sclaing Group 생성 클릭

인스턴스 시작 옵션에서 VPC와 AZ 및 서브넷 선택

고급 옵션 구성에서 로드 밸런싱 및 대상 그룹 선택

추가 설정에서 CloudWatch 활성화 선택. Auto Scaling을 위해 필요.

그룹 크기 및 크기 조정 정책 구성 설정

태그 추가

검토 후 생성

DB의 고가용성 구성

읽기 추가 클릭

생성

inventory-cluster 아래에 replica가 생성된다.

생성 후 구조

NAT Gateway 생성

생성

Routing Table 생성 및 구성

라우팅 테이블 생성 클릭

VPC 선택 및 생성

리우팅 편집 클릭

라우팅 대상에 새로 생성한 NAT gateway 추가

서브넷 연결 편집

서브넷 연결 편집 클릭

연결할 서브넷 선택

Auto Sclaing 테스트

실행중이던 인스턴스를 종료하면

최소 개수를 맞추기 위해 인스턴스가 다시 생성된다.

DB 가용성 테스트

DB replica 인스턴스가 정상상태로 올라온 뒤

primary 인스턴스를 삭제하면

Reader 역할이었던 replica 인스턴스가 Writer 역할로 Role이 변환되면서 장애조치가 완료되는 것을 볼 수 있다.

Architecting 기본 사항

• 보안 - AWS 보안모범사례를 사용하여 데이터와 자산을 보호할 수 있는 정책 및 프로세스를 구축합니다. 감사 및 추적 기능을 사용할 수 있습니다. 작업 및 환경 변경 사항을 실시간으로 모니터링하고 알리고 감사합니다.
  • 다계층 보안 중요
  • WAF - 엣지에서 동작
• 비용 최적화 - 이 기능은 변동이 심한 리소스 요구를 고려하면서 비용 효율성을 달성하는데 도움이 됩니다.
• 신뢰성 - 잘 정의 된 애플리케이션 운영 임계 값을 충족하는 각 시스템 아키텍처 설계를 보장합니다. 여기에는 장애복구, 수요증가처리, 중단 완화에 대한 지원이 포함됩니다.
  • 가용성
• 성능 효율성 - 인스턴스, 스토리지, 데이터베이스, 공간 및 시간과 같은 리소스 세트에 대해 효율적인 성능을 제공하는 시스템 아키텍처설계를 보장합니다.
• 운영 우수성 - 사업가치를 창출하는 시스템을 실행하고 모니터링할 수 있습니다. 지원 프로세스 및 절차를 지속적으로 개선합니다.
  • 코드로 운영 수행 -> IaC
• 지속 가능성 – 클라우드 워크로드를 실행할 때 환경 영향을 최소화하고 이해합니다.

보안 주체

보안 주체: AWS 리소스에 대한 작업 또는 운영을 요청할 수 있는 엔터티. 사용자, Application, idP 또는 페더레이션 사용자. 권한을 줄때는 사용자에게 주는것이 아니라 역할을 통해 준다.

IAM

IAM 사용자 생성 선택시 콘솔 암호 필요함.

필요에 따라 자동 생성 암호 또는 사용자 지정 암호 선택 가능.

역할

신뢰할 수 있는 엔터티 유형 선택이 가능함.

사용자 뿐만 아니라 서비스에도 부여할 수 있음.

필요에 따라 웹 자격 증명 등 다양한 유형 선택이 가능함.

엑세스 키 사용

그러나 엑세스 키를 그대로 사용하는 것 역시 보안적으로 취약(키 값 노출시 누구나 자원 사용이 가능)하기 때문에 엑세스 키 대신 role(역할) 사용. 따라서 엑세스 키 대신 역할을 사용

IAM 정책 배정

사용자에게 직접 권한을 주지 않는 이유: 권한을 직접 빼앗기전까지 권한이 계속 유지되기 때문에 역할을 만들고 권한이 있는 역할을 부여하므로써 관리. 지정된 시간동안만 권한을 가지고 있으며, 이후에는 토큰 재발급이 필요함.

리소스 기반 정책

명시적 허용 및 명시적 거부

IAM 정책에는 명시적 허용 또는 명시적 거부가 포함되며, 같은 정책에 대한 허용과 거부가 동시에 존재한다면, 거부가 높은 우선 순위를 가짐.

AWS Organization

조직적 계정 관리

SCP

조직의 권한을 관리하는 데 사용할 수 있는 조직 정책 유형. Organization 엔터티에 SCP를 연결하면 가드레일이 정의됨.

네트워킹

멀티테넌트: 하나의 자원을 여러명이 사용함.

AWS에서는 서브넷 CIDR 블록마다 5개의 주소가 예약됨(처음 4개의 IP + 마지막 IP)

NAT: Network Address Translation. public IP와 private IP를 변환해줌. private subnet은 외부로 직접 접속이 안되므로 NAT gateway를 통해 외부로 통신함.

VPC당 하나의 LoadBalance로 여러개의 AZ로 Load Balancing이 가능함.

보안 그룹

트래픽이 상위 티어에서 하위 티어로만 흐른 후 다시 반대로 흐를 수 있도록 인바운드와 아웃바운드 규칙이 설정됩니다. 보안그룹은 특정 티어의 보안 위반 시 손상된 클라이언트가 서브넷 전체에서 모든 리소스에 자동으로 액세스할 수 있게되는 현상을 방지하는 방화벽 역할을 합니다.

목표 구조

사용자 지정 보안 그룹은 인바운드 규칙이 없고 아웃바운드 트래픽을 허용함.

컴퓨팅

CSP -> 반도체 설계 기술이 필요함

AWS 컴퓨팅의 발전 과정

• EC2
• EBS
• Lambda

EC2

EC2를 서버가 아니라 인스턴스라고 부르는 이유: 필요할 때만 생성하고 종료시키기 때문

EC2 옵션:

• 이름 및 태그
• Application 및 OS 이미지
• Instance 유형 및 크기
• 인증 및 키 페어
• 네트워크 설정 및 보안
• 스토리지 구성
• 배치 및 테넌시
• 스크립트 및 메타 데이터

AMI

클라우드의 가상 서버인 인스턴스를 시작하는데 필요한 정보를 제공함.

키페어

테넌시

전용 인스턴스는 Host Hardware 수준에서 물리적으로 격리되는 EC2 인스턴스이다. 전용이 아닌 인스턴스와 다른 AWS 계정에 속하는 인스턴스로 부터 격리됨.

배치그룹

사용자 데이터

EBS

EBS란? Amazon Elaxtic Block Store. EC2 인스턴스용 스토리지로, 인스턴스가 생성될 때 같이 생성되는 Intance store는 인스턴스 삭제 시 함께 삭제되기 때문에 보관이 필요한 정보의 경우 EBS를 사용해서 정보를 저장. 인스턴스 생성 시 Configure Volume(스토리지 구성)은 EBS를 생성하는 옵션이며, 인스턴스 자체 스토리지는 지원하는 인스턴스가 따로 있음.

인스턴스:EBS = 1:N

EBS Volume 유형

EBS Volume 특성

Instance Store Volume

Amazon EC2 구매 옵션

Lambda

AWS의 대표적인 서버리스 컴퓨팅 서비스. 서버리스 컴퓨팅 서비스를 통해 사용자가 서버를 프로비저닝, 크기 조정, 관리할 필요가 없음. 따라서 서버리스 어플리케이션에서는 개발자가 서버 또는 런타임 관리와 운영에 대해 걱정하기보다는 핵심 제품에 집중할 수 있기 때문에 개발자가 확장성 및 안정성이 향상된 뛰어난 제품을 개발하는데 사용한 시간과 에너지를 회수할 수 있음.

Instance 역할 부여

IAM Role을 인스턴스에 바로 부여할 수 없기 때문에 한번 Mapping하여 역할을 부여함. 실제 역할에 부여된 Role은 AmazonEC2RoleforSSM이며

aurora.cluster-cygzzazbffvv.us-east-1.rds.amazonaws.com

LAB 01. Amazon VPC 인프라 구축

LAB 02. DB 계층 생성

ALB에 대상 그룹 추가 후 화면 ALB의 DNS 이름을 웹 브라우저에 입력했을 때의 출력

위 화면에서 Settings 클릭 후 설정 값 입력 및 save.

save 직후 화면

Add Inventory도 가능함.

rds 만들고 엔드포인트 받기(mydb.chtn61fibgt9.us-west-1.rds.amazonaws.com) (표준생성 - mysql(엔진버전 8.0.28 제일 낮은) - 프리티어 - 식별자(mydb) - 자격증명(root) - 마스터암호(It12345!) - 버스터블클래스(t2마이크로) - vpc 선택

• 퍼블릭액세스(아니오) - 보안그룹(만들어둔것) - 가용영역 설정 - 추가구성 클릭
• 초기데이터베이스 이름(wordpress) - 백업 활성화 체크 해제 - 스냅샷 체크해제
• 마이너 버전 업그레이드 해제 - 만들기

워드프레스 홈페이지 다운로드(5.7.8버전 tar.gz) 홈페이지 - all releases - 5.7.8 tar.gz 링크 복사

Install php + httpd

#! /bin/bash
wget https://ko.wordpress.org/wordpress-5.7.8-ko_KR.tar.gz
tar xvfz  wordpress-5.7.8-ko_KR.tar.gz
yum install -y httpd
cp -r wordpress/* /var/www/html/
amazon-linux-extras enable php8.0
yum install -y php php-fpm php-pdo php-mysqlnd
cp /var/www/html/wp-config-sample.php /var/www/html/wp-config.php
sed -i 's/DirectoryIndex index.html/DirectoryIndex index.php/g' /etc/httpd/conf/httpd.conf
sed -i 's/database_name_here/root/g' /var/www/html/wp-config.php
sed -i 's/user_here/root/g' /var/www/html/wp-config.php
sed -i 's/password_here/root/g' /var/www/html/wp-config.php
sed -i 's/localhost/{ endpoint 주소 }/g' /var/www/html/wp-config.php
systemctl enable --now httpd

코드 작성

명령어들은 코드에 하드 코딩하지 않는것이 좋으므로 따로 파일에 저장하여 사용.

sh 파일 생성

코드 수정

엔드포인트가 없는 경우, 실행하면 DB 연결 오류 화면이 출력됨 -> DB 서버 생성 후 엔드포인트를 추가해 주면 wordpress 화면이 정상적으로 출력됨.

ELB 생성

공식 문서: https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/lb

tmi: AWS는 frontend와 backend를 리스너와 타겟그룹으로 부른다. 접속 구조는 리스너(Front-end) -> LB -> target group(Back-end)
ALB 생성시 target group은 listener 보다 먼저 생성되어야 한다. health check는 html로만 가능하기 때문에 health check용 html 생성이 필요할 수 있음.

tf code 작성

생성됨

ALB Target Group 생성

공식 문서: https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/lb_target_group

tf code

health check를 위해 sh파일에 health.html을 생성하는 코드 추가.

apply

user data가 추가 되면 기존 인스턴스는 종료되고 새로운 인스턴스가 생성됨

코드 수정후 health.html 내용이 정상 출력됨.

aws console에서 확인

ALB listener 생성

공식 문서: https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/lb_listener

tf code

apply

auto scale 및 attachment 필요. auto scaling 그룹 -> 시작 템플릿 필요

ami 생성

공식 문서: https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/ami_from_instance

depens_on 명령어 사용

코드

aws console 확인

AutoScale 생성

Launch configuration 평문으로 입력하면 안됨 -> filebase64 사용해서 암호화 필요

공식 문서(Launch template): https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/launch_template

tf code

Auto Scaling Group 생성

공식 문서: https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/autoscaling_group

tf code 작성

concat을 이용해서 한번에 여러개의 resource를 처리하는것도 가능함.

Auto Scaling group 생성 확인

Auto Scaling Attachment 작성

공식 문서: https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/autoscaling_attachment

tf code 작성

RDS 생성

공식 문서(DB instance): https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/db_instance

tf code

RDS 생성됨

VCSA 설치 후 웹 사이트 접속 - 인증서 오류 화면 출력됨

VCSA 인증서 추가

접속을 선택

CA인증서 다운로드 클릭

인증서

다른이름 저장

바탕화면 저장

필요한 OS 선택

인증서 Open

인증서 내용 확인

인증서 설정 필요

신뢰할 수 있는 인증서 목록에 해당 인증서가 없음을 확인

인증서에서 install 선택

설치 위치를 Local Machine로 설정

인증서 설치 위치를 Trusted Root Certification Authorities로 지정

설치됨.

웹 브라우저 확인 - 사이트 주소 입력으로 접속해도 접속 거부 알림이 나오지 않음.

Lanch vSphere Client 선택

즐겨찾기에 추가

접속 화면

VMware vCenter Server 관리: 배포한 서버 appliance를 관리

내부 화면

컨테이너 기반의 웹서비스에서 신뢰할 수 있는 인증서 사용하기

https://hyeo-noo.tistory.com/267 https://docs.docker.com/storage/volumes/ https://zinirun.github.io/2021/03/31/docker-nginx-certbot/

VCSA 설정

Manage Your Licenses 선택

License Key 입력

License name 설정

목록에 나옴

Licenses 항목

License 설정

Assign License 선택

기능 둘러보기

Inventory - Configure

General

Mail, SNMP

Database

Statics: 통계 데이터 기록에 대한 설정.

General

• Mail: 알림을 Mail로 수신할 수 있는 서비스
• Runtime settings: Unique ID를 통해 중복되지 않고 여러대의 vCenter를 생성할 수 있음. vCenter Server avilable -> Active-Standby 개념의 가용성 보장(백업과 다름)
• Database: postgress

Licnesing

Message of Day

Advenced Setting

Authentication Proxy

vCenter HA

Witness vCenter는 두 서버(active, passive) 사이에서 감시하는 서버.

Security

Trust Authority

Key Providers

vCenter의 Key 관리 시스템. 저장소에 저장할때 암호화가 필요하다면 이 기능이 필요함

Window 11은 TMP 사용이 가능해야 사용할 수 있기 때문에 Window Server 11을 설치하기 위해서는 TMP 사용이 가능해야함.

Alarm Definition

error 알림 종류에 따라 On/Off 가능.

알람 추가 및 삭제 가능

알람 추가 1. 알람의 대상 type을 잘 정해야함.

알람 추가 2. Alarm Rule 설정

VCSA에 ESXi 추가

Datacenter 생성

이름 설정 - 보통 지역 또는 지사를 입력함

서버 추가

서버 이름 복사

Host 이름 / IP 추가

생성

Cluster 생성

생성 클릭

이름 및 기능 설정 - 업무적인 내용을 추가하는 것이 좋음(업무단위 그룹으로).

생성

생성 후 Quickstart 화면이 나옴. -> 서비스를 사용하기 위한 전제조건을 확인하는 work flow가 설정되어있음.

HA의 전제 조건: 여러 서버들이 공유 스토리지를 가지고 있음 -> 자신이 어떤 volume을 가지고있는지 등의 정보를 Master Server와 공유함.

Cluster에 Host 추가

Storage True NAS

yaml 파일을 작성한 뒤 실행.

생성됨

주요 옵션

• paravirtual: 반가상화

---
- hosts: localhost
  vars_files: ./vars.yaml

  tasks: 
    - name: Create TrueNAS Storage VM
      community.vmware.vmware_guest:
        hostname: "{{ vcenter_hostname }}"
        username: "{{ vcenter_username }}"
        password: "{{ vcenter_password }}"
        validate_certs: 'false'
        datacenter: '{{datacenter_name}}'
        folder: '{{ folder_prefix + student_ID }}'
        name: "{{ student_ID + '-Storage' }}"
        state: poweredoff
        guest_id: freebsd13_64Guest
        esxi_hostname: "{{ esxi_hostname }}"
        hardware:
          num_cpus: 2
          nested_virt: yes
          memory_mb: 8192
        disk:
        - size_gb: 40
          controller_type: 'paravirtual'
          controller_number: 0
          unit_number: 0
          type: thin
          datastore: '{{ datastore_name }}'
        - size_gb: 100
          controller_type: 'paravirtual'
          controller_number: 0
          unit_number: 1
          type: thin
          datastore: '{{ datastore_name }}'
        - size_gb: 100
          controller_type: 'paravirtual'
          controller_number: 0
          unit_number: 2
          type: thin
          datastore: '{{ datastore_name }}'
        - size_gb: 100
          controller_type: 'paravirtual'
          controller_number: 0
          unit_number: 3
          type: thin
          datastore: '{{ datastore_name }}'
        - size_gb: 100
          controller_type: 'paravirtual'
          controller_number: 0
          unit_number: 4
          type: thin
          datastore: '{{ datastore_name }}'          
        networks:
        - name: "{{ student_ID + '-SA-Storage' }}"
          device_type: vmxnet3
        cdrom:
        - controller_number: 0
          unit_number: 0
          state: present
          type: iso
          iso_path: '[RECA3-05]\ISOs\TrueNAS-13.0-U4.iso'
      delegate_to: localhost
      register: deploy_vm

설치 후

필요에 따라 DC 서버에 Edit Setting 가능

vSphere에서 확인 가능

목표 구성.

DC 서버에서 웹 브라우저로 10.10.11.10 접속

인증서 신뢰 접속

NAS UI 화면

Storage Pools 생성

Stripe 방식 선택시 위험 알림이 나옴.

Raid-z 선택 후 생성

생성된 Pool 확인

UI에 포함된 Shell 서비스로 생성된 Pool에 접속 가능

Quota: 계정별 용량 제한 기능.

iSCSI

• Target Global Configuration
• Targets
• Associated Targets

Wizard 선택

서비스 실행중인지 확인이 필요함 -> iSCSI ON

vSphere UI에서 Adapter 확인 -> iSCSI Software Adapter가 없으므로 이후 추가 필요함.

Rescan Adapter을 클릭하면 NAS 장치가 목록에 나타남.

iSCSI 연결을 위한 Best Practice

참고 자료: https://core.vmware.com/resource/best-practices-running-vmware-vsphere-iscsi#section2

라우터 -> 라우터를 거치지 않는것이 속도가 더 빠름. 스위치 -> 안정성을 위해 uplink를 두개 연결.

ansible로 AWS, VMware 제어 가능함

분산 스위치 Distributed Switch

Data Center Level의 스위치는 Data Center에서 설정해야 함.

New Distributed Switch 선택

Version 선택

Uplink 개수 설정 -> 최소 2개를 권장.

설정 확인

생성

Host 추가

추가할 서버(Host)들 선택

Adapter 선택

스위치로 사용중이지 않은 vmnic을 찾아서

Uplink로 선택

생성

Port Group 생성

Configure setting - port binding, allocation, Number of ports 설정 가능

P1, P2 생성 후 우클릭 -> Edit setting 클릭

Teaming and failover에서 Uplink를 Failover할지 여부 선택.

P1 -> Uplink 2를 비활성 P2 -> Uplink 1을 비활성

생성됨

위 과정을 각 서버에서 반복.

참고: https://blog.naver.com/ka10787 가상화: 실제 물리적으로 존재하는 것을 논리적으로 추상화되어 만들어진 것. 종류

• 가상 컴퓨터 하드웨어 플랫폼(Virtual Computer Hardware Platform): = Virtual Machine
• 가상 스토리지 장치(Virtual Storage Device): RAID(Reduntent Array Idependent Disk), LUN(Logical Unit Number)
• 가상 네트워크 자원(Virtual Network Resource): = Virtual Local Area Network

VPN이란?

참고: http://www.ktword.co.kr/test/view/view.php?nav=2&no=342&sh=VPN VPN: Virtual Private Network.

도커/컨테이너

JVM

Hypervisor

Hypervisor: 커널의 커널 역할을 하는 소프트웨어(프로세스). 가상머신(Virtual Machine)에 필요한 자원을 할당/관리하는 역할을 함. Host: Hypervisor가 동작하는 물리적 시스템 Guest: Host상에서 동작하는 가상머신 Supervisor: OS의 커널(Guest에서 동작하는 커널)

Hypervisor 종류

• Type 1. native(bare metal): Hypervisor가 HW위에서 직접 동작. HW들을 제어하며 VM을 관리하는 형태.
• Type 2. hosted: Hypervisor가 OS위에서 다른 프로그램처럼 하나의 프로그램으로 동작하는 형태.

반가상화

입출력(I/O, Input/Output)이 시뮬레이션 되지 않고, 하이퍼콜(Hypercall)이라는 시스템콜(System call)을 처리하도록, Guest OS가 수정되어 동작하는 것을 의미. I/O이 시뮬레이션되지 않고 하이퍼콜을 통해서 Host에서 처리하도록 하기 때문에 성능이 뛰어남.

VMware vSphere 참고 영상: https://www.youtube.com/@VMwarevSphere/videos

VMware 환경 구축

1. vars.yaml -> 변수 설정
2. Switching yaml
3. Routing yaml
4. Window Server for Data Center yaml
5. Make Domain Controller yaml
6. Add DNS record yaml
7. ...

YAML을 이용한 Server 구축

YAML of Switching

VMware의 vSwitch Module에 대한 ansible 공식 문서: https://docs.ansible.com/ansible/latest/collections/community/vmware/vmware_vswitch_module.html

ansible을 통해 설정할 수 있는 주요 항목:

• esxi_hostname
• nics
• password
• port
• proxy_host
• switch
• teaming
• load_balancing
• network_failure_detection
  • beacon_probig:
• standby_adapters

위 설정값들을 UI에서 설정하는법

log 보는 법

grep -i error /var/log/hostd.log | tail grep -i error /var/log/vpxa.log | tail tail /var/log/vmkwarning.log

grep -i error: error가 포함된 것들을 출력 /var/log/hostd.log: log가 기록되는 디렉토리중 하나 -> 여러 파일 확인을 통해 오류 확인이 필요함. tail: log를 최신순 정렬

TMI

1. OS에 따라 TTL 값이 다르게 나옴

2. 이미 실행된 yaml파일을 시작하는 경우 결과가 changes가 아닌 ok만 출력

Switching

vlan_id: 4095 : 4095 -> 0번과 같이 system이 쓰는 vlan

Routing

Window Server

윈도우 서버 설치 - Domain Controller로 사용. yaml 파일 내용: datacenter 이름, folder 위치, 인증서 확인 여부, Network 설정

yaml 실행

yaml 실행 후 DataCenter가 생성된 모습.

Window Server 입장.

Yes 선택

Domain Controller

Window Server가 Domain Controller 동작을 할 수 있도록 기능을 활성화.

특징: Window Server OS를 사용하기 때문에 PowerShell의 명령어를 사용함

powershell 위치

## https://docs.ansible.com/ansible/latest/collections/community/vmware/vmware_vm_shell_module.html#ansible-collections-community-vmware-vmware-vm-shell-module 

---
- hosts: localhost
  vars_files: ./vars.yaml

  tasks: 
    - name: Install_WindowsFeatures_AD-DS
      community.vmware.vmware_vm_shell:
          hostname: '{{ vcenter_hostname }}'
          username: '{{ vcenter_username }}'
          password: '{{ vcenter_password }}'
          validate_certs: 'false'
          vm_id: "{{ student_ID + '-DC' }}"
          vm_id_type: vm_name
          vm_username: 'Administrator'
          vm_password: 'VMware1!'
          vm_shell: 'c:\windows\system32\windowspowershell\v1.0\powershell.exe'
          vm_shell_args: '-command "(Install-WindowsFeature -Name AD-Domain-Services -IncludeManagementTools)"'
          vm_shell_cwd: 'c:\Users\Administrator'
          wait_for_process: True
          timeout: 180
      delegate_to: localhost
      register: shell_command_with_wait_timeout

    - name: Import_Module_ADDSDeployment
      community.vmware.vmware_vm_shell:
          hostname: '{{ vcenter_hostname }}'
          username: '{{ vcenter_username }}'
          password: '{{ vcenter_password }}'
          validate_certs: 'false'
          vm_id: "{{ student_ID + '-DC' }}"
          vm_id_type: vm_name
          vm_username: 'Administrator'
          vm_password: 'VMware1!'
          vm_shell: 'c:\windows\system32\windowspowershell\v1.0\powershell.exe'
          vm_shell_args: '-command "Import-Module ADDSDeployment"'
          vm_shell_cwd: 'c:\Users\Administrator'
          wait_for_process: True
          timeout: 180
      delegate_to: localhost
      register: shell_command_with_wait_timeout


    - name: Install_First_ADDSForest
      community.vmware.vmware_vm_shell:
          hostname: '{{ vcenter_hostname }}'
          username: '{{ vcenter_username }}'
          password: '{{ vcenter_password }}'
          validate_certs: 'false'
          vm_id: "{{ student_ID + '-DC' }}"
          vm_id_type: vm_name
          vm_username: 'Administrator'
          vm_password: 'VMware1!'
          vm_shell: 'c:\windows\system32\windowspowershell\v1.0\powershell.exe'
          vm_shell_args: '-command "(Install-ADDSForest -CreateDnsDelegation:$false -DatabasePath C:\Windows\NTDS -DomainMode WinThreshold -DomainName vclass.local -DomainNetbiosName VCLASS -ForestMode WinThreshold -InstallDns:$true -LogPath C:\Windows\NTDS -NoRebootOnCompletion:$false -SysvolPath C:\Windows\SYSVOL -Force:$true -SafeModeAdministratorPassword (ConvertTo-SecureString -AsPlainText "VMware1!" -force)")"'
          vm_shell_cwd: 'c:\Users\Administrator'
          wait_for_process: True
          timeout: 180
      delegate_to: localhost
      register: shell_command_with_wait_timeout
      ignore_errors: yes      

DSRM: Directory Services Remote Mode

Additional Options

yaml로 설정

yaml 작성

yaml 실행: 붉은 글씨로 출력되는 부분이 있지만, failed가 아닌 error 메세지이므로 설정은 정상적으로 진행됨.

실행 후 Domain Controller 서버 확인

서버의 시간 설정

DNS 추가 방법

정방향, 역방향...

1. yaml
2. dnsmgmt.msc 에서 직접 추가

yaml

powershell 파일 생성 - 주의 사항: 주석을 한글로 작성한 경우, 마지막에 빈칸(space bar)을 추가하지 않으면 아래 줄 내용이 올라오는 경우가 있음.

DNS 복사를 위해 폴더 생성

yaml 실행

생성되고

사라짐

DNS Manager에서 확인(before)

(after)

ps파일 내용을 DNS 추가가 아니라 AD User 추가로 바꿔도 스크립트는 실행되기 떄문에 오류가 발생하지 않음

ps파일 수정

yaml 실행

직접 추가

DNS Manager에서 New Host 클릭

Host 정보 입력

생성

User 설정 가능.

vSphere에서 Admin 계정으로 로그인하면 Acrive Direstory Domain 목록 확인 가능.

ESXi 생성

방법 1) ESXi 옵션을 직접 설정

주요 옵션

nvme 설정 시 unit_number를 추가하는 이유: vSAN에서 사용하기 위해

---
- hosts: localhost
  vars_files: ./vars.yaml

  tasks: 
    - name: Create ESXi VMs
      community.vmware.vmware_guest:
        hostname: "{{ vcenter_hostname }}"
        username: "{{ vcenter_username }}"
        password: "{{ vcenter_password }}"
        validate_certs: 'false'
        datacenter: '{{datacenter_name}}'
        folder: '{{ folder_prefix + student_ID }}'
        name: '{{ item.vmname }}'
        state: poweredoff
        guest_id: vmkernel7Guest
        esxi_hostname: "{{ esxi_hostname }}"
        hardware:
          num_cpus: 2
          nested_virt: yes
          memory_mb: 8192
        disk:
        - size_gb: 200
          controller_type: 'paravirtual'
          controller_number: 0
          unit_number: 0
          type: thin
          datastore: '{{ datastore_name }}'
        - size_gb: 50
          controller_type: 'nvme'
          controller_number: 0
          unit_number: 0
          type: thin
          datastore: '{{ datastore_name }}'
        - size_gb: 50
          controller_type: 'nvme'
          controller_number: 0
          unit_number: 1
          type: thin
          datastore: '{{ datastore_name }}'
        - size_gb: 200
          controller_type: 'nvme'
          controller_number: 0
          unit_number: 2
          type: thin
          datastore: '{{ datastore_name }}'
        - size_gb: 200
          controller_type: 'nvme'
          controller_number: 0
          unit_number: 3
          type: thin
          datastore: '{{ datastore_name }}'
        networks:
        - name: "{{ student_ID + '-SA-Mgmt' }}"
          device_type: vmxnet3
        - name: "{{ student_ID + '-SA-Mgmt' }}"
          device_type: vmxnet3
        - name: "{{ student_ID + '-Trunk' }}"
          device_type: vmxnet3
        - name: "{{ student_ID + '-Trunk' }}"
          device_type: vmxnet3
        cdrom:
        - controller_number: 0
          unit_number: 0
          state: present
          type: iso
          iso_path: '[RECA3-05]\ISOs\VMware-VMvisor-Installer-7.0U3n-21930508.x86_64.iso'
      with_items:
      - {vmname: "{{ student_ID + '-SA-ESXi-01' }}" }
      - {vmname: "{{ student_ID + '-SA-ESXi-02' }}" }
      - {vmname: "{{ student_ID + '-SA-ESXi-03' }}" }      
      delegate_to: localhost
      register: deploy_vm

방법 2) 이미 있는 ESXi를 복제

주요 내용 Full Clone에 대한 내용

Network 설정

powershell script 실행

yaml 실행 완료

---
- hosts: localhost
  vars_files: ./vars.yaml

  tasks: 
  - name: Clone multiple esxi vms from Template
    community.vmware.vmware_guest:
      hostname: "{{ vcenter_hostname }}"
      username: "{{ vcenter_username }}"
      password: "{{ vcenter_password }}"
      validate_certs: no
      name: "{{ item }}"
      state: "poweredoff"
      datacenter: '{{ datacenter_name }}'
      folder: "{{ folder_prefix + student_ID }}"
      esxi_hostname: '{{ esxi_hostname }}'
      datastore: "{{ datastore_name }}"
      template: "{{ sa_esxi_template_name }}"
    loop:
      - "{{student_ID+'-SA-ESXi-01'}}"
      - "{{student_ID+'-SA-ESXi-02'}}"
      - "{{student_ID+'-SA-ESXi-03'}}"
    delegate_to: localhost


# https://stackoverflow.com/questions/59626587/how-to-change-vmware-network-adapter-with-ansible
  - name: Adding ESXi VMs Network Interfaces - Mgmt
    community.vmware.vmware_guest_network:
      hostname: "{{ vcenter_hostname }}"
      username: "{{ vcenter_username }}"
      password: "{{ vcenter_password }}"
      validate_certs: no
      name: "{{ item[0] }}"
      label: "{{ item[1] }}"
      network_name: "{{ student_ID + '-SA-Mgmt' }}"
      state: present
      force: yes
    with_nested:
      - [ "{{student_ID+'-SA-ESXi-01'}}", "{{student_ID+'-SA-ESXi-02'}}", "{{student_ID+'-SA-ESXi-03'}}" ]
      - [ "Network adapter 1", "Network adapter 2" ]
    delegate_to: localhost

# https://stackoverflow.com/questions/59626587/how-to-change-vmware-network-adapter-with-ansible
  - name: Adding ESXi VMs Network Interfaces - Trunk
    community.vmware.vmware_guest_network:
      hostname: "{{ vcenter_hostname }}"
      username: "{{ vcenter_username }}"
      password: "{{ vcenter_password }}"
      validate_certs: no
      name: "{{ item[0] }}"
      label: "{{ item[1] }}"
      network_name: "{{ student_ID + '-Trunk' }}"
      state: present
      force: yes
    with_nested:
      - [ "{{student_ID+'-SA-ESXi-01'}}", "{{student_ID+'-SA-ESXi-02'}}", "{{student_ID+'-SA-ESXi-03'}}" ]
      - [ "Network adapter 3", "Network adapter 4" ]
    delegate_to: localhost



# https://docs.ansible.com/ansible/latest/collections/community/vmware/vmware_guest_module.html
  - name: Power on ESXi VMs
    community.vmware.vmware_guest:
      hostname: "{{ vcenter_hostname }}"
      username: "{{ vcenter_username }}"
      password: "{{ vcenter_password }}"
      validate_certs: no
      name: "{{ item }}"
      state: "poweredon"
    loop:
      - "{{student_ID+'-SA-ESXi-01'}}"
      - "{{student_ID+'-SA-ESXi-02'}}"
      - "{{student_ID+'-SA-ESXi-03'}}"
    delegate_to: localhost


  - name: Waiting boot-up
    wait_for:
      timeout: 120
    delegate_to: localhost


  - name: Configure ESXi VM
    community.vmware.vmware_vm_shell:
      hostname: '{{ vcenter_hostname }}'
      username: '{{ vcenter_username }}'
      password: '{{ vcenter_password }}'
      validate_certs: 'false'
      datacenter: '{{ datacenter_name }}'
      folder: "{{ folder_prefix + student_ID }}"
      vm_id: "{{ item.vm_name }}"
      vm_id_type: vm_name
      vm_username: 'root'
      vm_password: 'VMware1!'
      vm_shell: /bin/sh
      vm_shell_cwd: "/tmp"
      vm_shell_args: |
        echo "Don't remove this line. Write your ESXi configuration commands below."
        esxcli system settings advanced set -o /Net/FollowHardwareMac -i 1
        sed -i 's#/system/uuid.*##' /etc/vmware/esx.conf
        esxcli network vswitch standard uplink add -u vmnic1 -v vSwitch0
        esxcli network ip interface ipv4 set -i vmk0 -t static -I {{ item.ipaddr }} -N 255.255.255.0 -g 10.10.10.1
        esxcli network ip route ipv4 add -n 0.0.0.0 -g 10.10.10.1
        esxcli network ip dns server add -s 10.10.10.2
        esxcli system hostname set --host {{ item.host_name }}
        esxcli system hostname set --domain vclass.local
        esxcli system ntp set -e yes -s 10.10.10.1
        vim-cmd hostsvc/enable_ssh
        vim-cmd hostsvc/enable_esx_shell
        vim-cmd hostsvc/advopt/update UserVars.SuppressShellWarning long 1
        /sbin/generate-certificates
        /sbin/auto-backup.sh
      wait_for_process: True
    with_items:
    - { vm_name: "{{student_ID+'-SA-ESXi-01'}}", host_name: sa-esxi-01, ipaddr: 10.10.10.11 }
    - { vm_name: "{{student_ID+'-SA-ESXi-02'}}", host_name: sa-esxi-02, ipaddr: 10.10.10.12 }
    - { vm_name: "{{student_ID+'-SA-ESXi-03'}}", host_name: sa-esxi-03, ipaddr: 10.10.10.13 }
#        esxcli network vswitch standard portgroup set -p 'Management Network' -v 10
#        esxcli network vswitch standard portgroup set -p 'VM Network' -v 10


  - name: Reboot ESXi VM
    community.vmware.vmware_guest_powerstate:
      hostname: "{{ vcenter_hostname }}"
      username: "{{ vcenter_username }}"
      password: "{{ vcenter_password }}"
      validate_certs: 'false'        
      folder: "{{ folder_prefix + student_ID }}"
      name: "{{ item }}"
      state: reboot-guest
    loop:
      - "{{student_ID+'-SA-ESXi-01'}}"
      - "{{student_ID+'-SA-ESXi-02'}}"
      - "{{student_ID+'-SA-ESXi-03'}}"
    delegate_to: localhost

VCSA 설치

직접

stage 1. Deploy new vCenter Server

VCSA-all iso 파일 선택

Connected 선택

Window DC Server 접속 VMware VCSA 생성 확인

vCenter-Server-Appliance 이미지 파일 확인

win32 선택

installer 선택

install 순서

설치할 위치 확인: cmd -> nslookup 입력 -> 주소 확인

vCenter 배포 위치 입력

폴더 지정

Deployment size 선택(경우에 따라 Storage size도 변경 가능)

Data Store 설정

FQDN 주소 확인

Network setting

Common Ports 설정시 80과 443 포트는 너무 잘 알려져있는 포트라 변경할 필요가 있을 수 있음. 하지만 생성 후 변경은 불가능 하기 때문에 포트 번호의 변경 필요성은 생성 전에 확인해야함.

생성전 옵션 확인

생성

stage 2. Set up vCenter Server

서버 시간 설정 - NTP 서버로 설정, SSH access는 Enabled

SSO Configuration 설정

옵션 확인

설치 진행

yaml 사용

---
- hosts: localhost
  vars_files: ./vars.yaml

  tasks:
  - name: Deploy vCenter Server Appliance VM from Template
    community.vmware.vmware_guest:
      hostname: "{{ vcenter_hostname }}"
      username: "{{ vcenter_username }}"
      password: "{{ vcenter_password }}"
      validate_certs: no
      name: "{{ student_ID + '-VCSA' }}"
      state: "poweredoff"
      datacenter: '{{ datacenter_name }}'
      folder: "{{ folder_prefix + student_ID }}"
      esxi_hostname: '{{ esxi_hostname }}'
      datastore: "{{ datastore_name }}"
      template: "{{ vcsa_template_name }}"
      linked_clone: True
      snapshot_src: "{{ vcsa_snapshot_src_name }}"
    delegate_to: localhost

  - name: Change Network Interfaces
    community.vmware.vmware_guest_network:
      hostname: "{{ vcenter_hostname }}"
      username: "{{ vcenter_username }}"
      password: "{{ vcenter_password }}"
      validate_certs: no
      name: "{{ student_ID + '-VCSA' }}"
      label: "Network adapter 1"
      network_name: "{{ student_ID + '-SA-Mgmt' }}"
      state: present
      force: yes
    delegate_to: localhost

  - name: Poweron VCSA VM
    community.vmware.vmware_guest:
      hostname: "{{ vcenter_hostname }}"
      username: "{{ vcenter_username }}"
      password: "{{ vcenter_password }}"
      validate_certs: no
      name: "{{ student_ID + '-VCSA' }}"
      state: "poweredon"
      state_change_timeout: 60
    delegate_to: localhost

NFS 관련 git: https://github.com/kubernetes/examples/tree/master/staging/volumes/nfs HCI - 서버와 스토리지의 결합. ansible을 이용한 자동화

사용 서버: DELL - Integrated DEll Remote Access Controller 8.

사전 상식: 예약 IPv4

웹 브라우저에서 서버의 UI에 접속하기 위해서는 사전에 설정해놓은 서버의 IP 주소를 입력이 필요하다. 외부의 침입을 방지하기 위해 사설 IP로만 접속할 수 있어야 하며, 내부 네트워크간의 접속만을 허용한다.

사용 IP: 172.16.x.x -> 사설 네트워크.

특징: 서버에 한번에 여러명의 사용자가 접근하면 접근이 거부됨.

ESXi Host Client

내부 구성

Physical Disks

Physical Disk 설정하는 옵션 화면 Hotspare: 문제가 생긴 서버를 대체하는 서버 Non-RAID: RAID에 포함시키지 않음

Virtual Disk

Virtual Disk에 대한 옵션을 설정할 수 있는 화면 Controller, Layout(RAID 설정), Read/Write Policy에 대한 설정이 가능함

RAID란? 참고자료: https://devocean.sk.com/blog/techBoardDetail.do?ID=163608

Virtual Console 화면

DELL의 서버 UI에서는 console을 통해 서버 설정이 가능함.

Ventoy

Ventoy: OS 설치 USB를 제작하기 위한 서비스. 이 서비스를 이용해서 USB에 ISO 파일을 저장해 놓으면, USB로 부팅을 통해 사전에 준비한 OS를 설치할 수 있다. 사이트 주소: https://www.ventoy.net/en/index.html Ventoy 사용 이유: https://hjm79.top/ventoy-os-usb-install/

서버에 USB를 연결하고 USB 부팅을 실행한 화면

BIOS 설정

OS설치 위치 선택 화면

keyboard 설정

선택한 언어에 따라 키보드 구성이 바뀌기 때문에 주의 필요.

Log 화면

설치 과정에서 F12키를 눌러서 로그 화면을 확인할 수 있다. 로그 내역은 서버 문제에 대한 내용 및 해결과 직결되기 때문에 매우 중요함.

문제 발생시 덤프가 제대로 안 떨어지는 경우 로그 확인이 불가능 할 수 있기 때문에 절대 재부팅을 하면 안됨.

설치 완료 화면

설치 완료 직후의 화면을 보면, DHCP 주소값을 받아오는 것을 알 수 있다. 실무에서는 DHCP를 사용하지 않으며, DHCP 사용여부는 설정을 통해 변경 가능.

보통 1(or 2)를 GW로 사용. 2(or 3)은 DNS로 사용함. 2bit 단위로 용도에 따라 나눠서 사용.

Network Adapter 설정 화면

기업환경에서는 서비스 안정성을 위해 반드시 2개 이상의 vmnic 연결이 필요함. 또한, on-board 연결 1개, 외부 1개 처럼 서로다른 카드에 연결함.

VLAN: 같은 스위치에 연결 되어있더라도 논리적으로 구분하여 보안성을 높임.

설정 완료 후 재가동 필요

재가동 후 DHCP에서 STATIC으로 변경된 것을 확인 할 수 있음.

Host Client

네트워크 설정 후 Host Client 접속

Host Server UI

ls -alht host* vpx*

Enter maintenance mode

내부 업데이트를 위한 일시 정지?(Drain과 비슷)

LockDown

강한 Lockdown은 오히려 불편하기 때문에 자주 사용하지 않음

Manage Permissons

esxi 서버를 하나만 사용하는 경우는 거의 없기 때문에 esxi에 직접 role 지정 대신, 주로 vShpere에 지정하여 사용.

Manage - System - Advanced settings

System의 다양한 setting 확인 가능

Command 창에서 Log 확인

1. PuTTY 실행
2. IP, 포트 입력
3. Accept
4. ID, Password 입력
5. cd /var/log ls -alht | more

Log 관련 파일

Memory 공유에서의 Salting

Memory 공유 편해짐. 하지만 보안 측면에서는 위험. Memory 공유 시 자주 사용하는 옵션 - ShareForceSalting, AllowGuestLargePage FakeSCSIReservations

esxcli system settings advanced list -o /Mem/ShareForceSalting
esxcli system settings advanced set -o /Mem/ShareForceSalting -i 0
esxcli system settings advanced list -o /Mem/ShareForceSalting

esxcli system settings advanced list -o /Mem/AllocGuestLargePage
esxcli system settings advanced set -o /Mem/AllocGuestLargePage -i 0
esxcli system settings advanced list -o /Mem/AllocGuestLargePage

esxcli system settings advanced list -o /VSAN/FakeSCSIReservations
esxcli system settings advanced set -o /VSAN/FakeSCSIReservations -i 1
esxcli system settings advanced list -o /VSAN/FakeSCSIReservations

실무에서는 자주 사용하지 않지만, LAB환경에서는 가끔 사용함.

명령어 입력시 출력되는 화면

Setting - System의 나머지 옵션들

Autostart

가상 머신 별로 On/Off 가능 DB -> WAS -> WEB 처럼 순서대로 켜져야하는 경우에 실행 설정이 가능함.

Swap

Memory와 Disk의 Swap 설정 가능

Time & date

NTP 설정 가능.

NTP 서비스 설정 후 서비스의 실행이 필요함. 서비스를 실행 하지 않으면 ntpq -p 명령어가 실행되지 않음.

NTP 실행 전 모습

NTP 실행 후 모습.

통신 확인: 8진수로 표현하며, 통신이 모두 성공하면 377으로 표현됨.

PCI Devices

Passthrough: 커널에서 가상 머신으로 가상 Switch을 거치지 않고 바로 접속할 수 있도록 만드는 옵션.

SR-IOV

Power Management

데이터 센터는 전기 사용량이 아주 크기 때문에 효율적인 자원 사용이 필요하기 때문에 용도에 따라 설정이 필요함.

퍼포먼스 옵션 목록.

Licensing

Packages

package 목록 확인 가능.

필요에 따라 package 업데이트 가능.

Services

서비스 목록 확인 가능

Security & Users

Certificates

인증서

윈도우에서 인증서 확인하기

certmgr.msc 입력

필요에 따라 신뢰할 수 있는 루트 인증 기관의 인증서 목록에 인증서를 추가하면 https 접속 시에도 위험 문구가 뜨지 않음.

Monitor

Performance

각 자원 사용량 확인 가능

Hardware

시스템의 센서들 확인 가능

Events

Tasks

Logs

프로세스에 대한 로그의 종류, 내용, 위치에 대한 정보 확인 가능

초기 투자 비용은 클라우드 서비스가 더 저렴하지만, 서비스가 커지거나 이후에는 클라우드나 서버를 사서 자체 클라우드를 만드는 거나 비용이 비슷함

Storage

Datastores

가상 머신 저장소

Adapters

연결된 장치들 확인 가능

NFS 서버 연결 경험은 필수

Devices

Disk 장치 확인 가능

장치별 세부 정보 확인 가능

Command 창에서도 확인 가능함

Persistent Memory

Networking

vSwitch의 구조: VMkernel NICs -> Port Group -> Virtual switches -> Physical NICs

VMkernel NICs

Port groups

Port group의 세부정보

Virtual switches

vSwitch의 세부 정보

Physical NICs

TCP/IP stacks

프로세스의 메모리 정보 확인 가능. 통신 분리에 사용.

Firewall rules

방화벽 정책 확인 가능

Datastore 설정

Datastores에서 목록 확인 가능

Datastore 선택: 세부정보 확인 가능

Datastore browser로 확인

vCenter Server Management

Firewall

방화벽 규칙 확인 가능

방화벽 규칙 설정시 주의사항: 큰 범위의 규칙을 상위로 지정하는것이 좋음. Longest Match: 방화벽 규칙을 범위가 긴 것(CIDR)을 높은 우선 순위로 둠 Short Match:

vSphere

접속 화면

vCenter

Permission

Storage

VM 생성...?

서버 설치 후 Command 창에서 확인

VMware 서비스 설명

ESXi 설정

컴퓨터 네트워크 설정 창 확인

Server ISO 설치

https://www.microsoft.com/en-us/evalcenter/download-windows-server-2022

Datastore에 ISO파일 추가

ESXi UI에서 Virtual Machines 선택 및 설치 진행

CPU hot plug 옵션: Hardware(vCPU) 설정 변경시 전원 Off 없이 변경이 가능하도록 만든 옵션

반가상화

설치할 ISO 선택 total video memory 설정 값이 8MB = 거의 모든 색감 표현 가능

생성 전 설정 확인

이후 CD/ROM 부팅으로 VM 실행

VMware Remote Controle가 설치됨 -> Window Server 제어 가능

웹 콘솔 접속 화면

MobaXterm 사용: xShell은 기업 환경에서 사용하면 비용이 지불되지만, MobaXterm은 개인이 따로 사용하는거면 기업 환경에서도 사용 가능.

PowerShell에서 Ubuntu 설치

VM 설정 순서

• 네트워크 설정
  • Switche
  • Routing

실행 완료

yaml 파일 사용

Storage 참고: https://kubernetes.io/docs/concepts/storage/volumes/

• Volume Mount - emptyDir -> 연결된 대상이 모두 삭제되면 같이 삭제됨.
• Volume Mount - hostPath -> 연결 대상이 삭제되어도 지워지지 않음. 경로는 다를 수 있지만, 이름은 같아야 함.
• Storage Class
• Persistent Volume -> pv라고 부름
• Persistent Volume Claim -> pvc라고 부름

emptyDir volume

• emptyDir 볼륨은 빈 디렉토리로 시작.
• Pod 내부에서 실행중인 애플리케이션은 필요한 모든 파일을 작성.
• 컨테이너 간 데이터 공유, Pod를 삭제하면 볼륨 내용이 손실됨.
• 동일한 pod에서 실행되는 컨테이너 간에 파일을 공유할 때 유용.

hostPath

• 노드의 파일 시스템의 디렉토리나 파일을 컨테이너에 마운트
• 노드에 디렉토리나 .......

pvc

emptyDir Volume을 공유하는 multi-pod 운영

작업 클러스터 : k8s

다음 조건에 맞춰서 nginx 웹서버 pod가 생성한 로그파일을 받아서 STDOUT으로 출력하는 busybox 컨테이너를 운영하시오. Pod Name: weblog Web container: - Image: nginx:1.17 - Volume mount : /var/log/nginx - Readwrite Log container: - Image: busybox - args: /bin/sh, -c, "tail -n+1 -f /data/access.log" - Volume mount : /data - readonly emptyDir 볼륨을 통한 데이터 공유

kubectl config use-context k8s
kubectl run weblog --image=nginx:1.17 --dry-run=client -o yaml > weblog.yaml
vi weblog.yaml 
kubectl apply -f weblog.yaml 
kubectl get pv

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: weblog
  name: weblog
spec:
  containers:
  - image: nginx:1.17
    name: weblog
    volumeMounts:
    - mountPath: /var/log/nginx
      name: weblog
  - image: busybox
    name: log
    args: [/bin/sh, -c, 'tail -n+1 -f /data/access.log']
    volumeMounts:
    - mountPath: /data
      name: weblog
      readOnly: true
  volumes:
  - name: weblog
    emptyDir: {}

HostPath Volume 구성

1./data/cka/fluentd.yaml 파일을 만들어 새로은 Pod 생성하세요. (신규생성 Pod Name : fluentd, image : fluentd, namespace : default) 2. 위 조건을 참고하여 다음 조건에 맞게 볼륨마운트를 설정하시오. 1) Worker node의 도커 컨테이너 디렉토리 /var/lib/docker/containers 동일 디렉토리로 pod에 마운트 하시오. 2) Worker node의 /var/log 디렉토리를 fluentd Pod에 동일이름의 디렉토리 마운트하시오.

Persistent Volume 만들기

참고: https://kubernetes.io/docs/concepts/storage/persistent-volumes/

작업 클러스터 : hk8s pv001라는 이름으로 size 1Gi, access mode ReadWriteMany를 사용하여 persistent volume을 생성합니다. volume type은 hostPath이고 위치는 /tmp/app-config입니다.

history

kubectl config use-context hk8s 
vi pv001.yaml
kubectl apply -f pv001.yaml
kubectl get pv
kubectl describe pv pv001 

PVC를 사용하는 애플리케이션 Pod 운영하기

사전 조건

• kubectl config use-context k8s
• 다음의 조건에 맞는 새로운 PersistentVolumeClaim 생성하시오. Name: pv-volume Class: app-hostpath-sc Capacity: 10Mi
• 앞서 생성한 pv-volume PersistentVolumeClaim을 mount하는 Pod를 생성하시오. Name: web-server-pod Image: nginx Mount path: /usr/share/nginx/html Volume에서 ReadWriteMany 액세스 권한을 가지도록 구성합니다.

kubectl describe pod 명령어로 확인

history

kubectl config use-context k8s
vi pvc.yaml
kubectl get node
kubectl apply -f pvc.yaml 
kubectl get pvc,pv
vi pvc-pod.yaml
kubectl apply -f pvc-pod.yaml 
kubectl describe pod web-server-pod

pvc.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pv-volume
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 10Mi
  storageClassName: app-hostpath-sc

pvc-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: web-server-pod
spec:
  volumes:
    - name: weblog
      persistentVolumeClaim:
        claimName: pv-volume
  containers:
    - name: web-server-pod
      image: nginx
      volumeMounts:
        - mountPath: "/usr/share/nginx/html"
          name: weblog

Troubleshooting

Node 동작 문제 해결

kube-proxy 정상적인지 Docker 데몬이 정상적인지 Kubelet 데몬이 정상적인지 coreDNS 정상적인지

참고 사항: https://kubernetes.io/docs/reference/kubectl/cheatsheet/

app Log 모니터링 kubectl logs PODNAME -c CONTAINER_NAME

Pod가 사용하는 CPU나 Memory 리소스 정보 보기

Node가 사용하는 CPU나 Memory 리소스 정보 보기

Application Log 추출하기

kubectl config use-context hk8s Pod custom-app의 로그 모니터링 후 'file not found' 오류가 있는 로그 라인 추출(Extract)해서 /var/CKA2022/custom-app-log 파일에 저장하시오.

Persistent Volume 정보 보기

kubectl config use-context k8s 클러스터에 구성된 모든 PV를 capacity별로 sort하여 /var/CKA2022/my-pv-list 파일에 저장하시오. PV 출력 결과를 sort하기 위해 kubectl 명령만 사용하고, 그 외 리눅스 명령은 적용하지 마시오.

history

kubectl config use-context hk8s
kubeclt top pods -l name=overloaded-cpu --sort-by=cpu
echo '`가장 높은 점유율을 가진 pod의 이름`' > /var/CKA2023/custom-app-log 

Worker Node 동작 문제 해결

kubectl config use-context hk8s hk8s-worker2 라는 이름의 worker node가 현재 NotReady 상태에 있습니다. 이 상태의 원인을 조사하고 hk8s-worker2 노드를 Ready 상태로 전환하여 영구적으로 유지되도록 운영하시오.

영구적으로 유지해야하므로 start가 아닌, enable --now를 사용해야 함.

history

kubectl config use-context hk8s
ssh hk8s-worker2 
sudo systemctl status kubelet
sudo systemctl enalbe --now kubelet
exit

Worker Node 동작 문제 해결

kubectl config use-context hk8s Worker Node 동작 문제 해결 hk8s-worker2 라는 이름의 worker node가 현재 NotReady 상태에 있습니다. 이 상태의 원인을 조사하고hk8s-worker2 노드를 Ready 상태로 전환하여 영구적으로 유지되도록 운영하시오.

UPgrade

주의 사항: upgrade는 반드시 Master Node에서 작업해야함.

cluster upgrade 참고: https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/

순서:

1. 업그레이드 - kubeadm upgrade
2. 버전 확인 - kubeadm version
3. plan - kubeadm upgrade plan

Cluster upgrade

작업 클러스터 : hk8s 마스터 노드의 모든 Kubernetes control plane및 node 구성 요소를 버전 1.27.1 버전으로 업그레이드합니다.
master 노드를 업그레이드하기 전에 drain 하고 업그레이드 후에 uncordon해야 합니다. "주의사항" 반드시 Master Node에서 root권한을 가지고 작업을 실행해야 한다.

tip: upgrade 관련 명령어 실행시 vi 편집기로 파일을 생성하여 작업하는 것이 좋음.

# replace <node-to-drain> with the name of your node you are draining
kubectl drain <node-to-uncordon> --ignore-daemonsets

# replace x in 1.27.x-00 with the latest patch version
apt-mark unhold kubelet kubectl && apt-get update && apt-get install -y kubelet=1.27.x-00 kubectl=1.27.x-00 && apt-mark hold kubelet kubectl 
sudo systemctl daemon-reload
sudo systemctl restart kubelet
# replace <node-to-uncordon> with the name of your node
kubectl uncordon <node-to-uncordon>

history

# Find the latest 1.27 version in the list.
# It should look like 1.27.x-00, where x is the latest patch.
apt update
apt-cache madison kubeadm
apt-mark unhold kubeadm && apt-get update && apt-get install -y kubeadm=1.27.1-00 && apt-mark hold kubeadm
kubeadm version
kubeadm upgrade plan
sudo kubeadm upgrade apply v1.27.1 -y

kubeadm upgrade node
kubeadm upgrade apply

# replace <node-to-drain> with the name of your node you are draining
kubectl drain hk8s-worker1 --ignore-daemonsets

# replace x in 1.27.x-00 with the latest patch version
apt-mark unhold kubelet kubectl && apt-get update && apt-get install -y kubelet=1.27.1-00 kubectl=1.27.1-00 && apt-mark hold kubelet kubectl 
sudo systemctl daemon-reload
sudo systemctl restart kubelet
# replace <node-to-uncordon> with the name of your node
kubectl uncordon hk8s-worker1

kubectl get nodes

노드 비우기

-> drain, cordon

작업 클러스터 : k8s k8s-worker2 노드를 스케줄링 불가능하게 설정하고, 해당 노드에서 실행 중인 모든 Pod을 다른 node로 reschedule 하세요.

drain: node를 schedule 불가능하게 만들고, 해당 node에 있는 pod들을 다른 node로 reschedule. cordon: node를 schedule 불가능하게 만듦. uncordon: drain 및 cordon로 인해 schedule 불가능하게 된 node를 다시 schedule 가능하도록 만듦.

history

kubectl config use-context k8s
kubectl drain k8s-worker2 --ignore-daemonsets --force --delete-emptydir-data 
kubectl get nodes 

drain 후 스케줄링 가능하도록 바꾸기

-> uncordon 사용

kubectl uncordon k8s-worker2

On-Premise OCP 구성 순서: 개발/검증 OCP 환경에서 Test 후 실제 구축

Hybird Cloud 구조 사용 이유: Front 부분은 Flexible해야하므로 Cloud 환경을 사용함.

K8S: Container Orchestration Tool. 대량의 컨테이너를 자동 배포하는 도구.

K8S 실습 환경 준비

1. 가상 머신 생성(CPU: core 2, RAM: 2GiB, OS: ubuntu 20.0)

2. ubuntu 설치

3. 화면 조정 - 1280 & 800.

4. ubuntu setting에서 IPv4 설정 + 전원 사용안함 설정. IP : 10.100.0.105, 서브넷마스크 : 255.255.255.0(24), 게이트웨이 : 10.100.0.1 , DNS : 10.100.0.1

5. terminal에서 sudo passwd root 명령어로 root 계정의 암호 설정. (sudo su - 명령어로 root 계정 접속 후에 암호 변경이 가능함)

6. ping 8.8.8.8로 인터넷 연결 확인

7. sudo apt-get update

8. sudo apt-get install -y openssh-server curl vim tree 명령어로 ssh 다운로드 + sudo systemctl start sshd

9. xShell 에서 원격 터미널 접속. (호스트: 127.0.0.1 -> 포트번호 : 105로 설정.)

10. /etc/hostname 파일 내용 변경

    Master

    

11. /etc/hosts 파일 내용 변경. IP, 이름 추가

12. docker 설치

13. 스냅샷 생성

sudo rm /etc/containerd/config.toml
sudo systemctl restart containerd

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
kubectl apply -f https://github.com/weaveworks/weave/releases/download/v2.8.1/weave-daemonset-k8s.yaml

worknode 생성

1. Master Node를 Stop 후 복제본 생성 -> work node로 만듦 옵션: 복제 설정 -> 완전 복제

2. work1의 /etc/hosts 파일과 /etc/hostname 파일 내용 수정

swapon && cat /etc/fstab
swapoff -a && sed -i '/swap/s/^/#/' /etc/fstab
setenforce 0
ufw disable
systemctl stop firewalld
systemctl disable firewalld
modprobe br_netfilter
cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
EOF 
sudo sysctl --system
sysctl net.bridge.bridge-nf-call-iptables
sysctl net.bridge.bridge-nf-call-ip6tables
apt install selinux-utils
setenforce 0
cat /etc/apt/sources.list.d/kubernetes.list
sudo apt-get update
sudo apt-get install -y apt-transport-https ca-certificates curl
sudo curl -fsSLo /usr/share/keyrings/kubernetes-archive-keyring.gpg https://packages.cloud.google.com/apt/doc/apt-key.gpg
echo "deb [signed-by=/usr/share/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
sudo vim /etc/apt/sources.list.d/kubernetes.list
cat /etc/apt/sources.list.d/kubernetes.list
sudo apt-get update
sudo apt-get install -y kubelet kubeadm kubectl kubernetes-cni
sudo apt-mark hold kubelet kubeadm kubectl
sudo mkdir /etc/docker
cat <<EOF | sudo tee /etc/docker/daemon.json
{
  "exec-opts": ["native.cgroupdriver=systemd"],
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "100m"
  },
  "storage-driver": "overlay2"
}
EOF
sudo systemctl enable docker
sudo systemctl daemon-reload
sudo systemctl restart docker

현재 실행중인 pod를 -o yaml 옵션으로 yaml파일 저장이 가능함

K8S 주요 명령어

cordon: 장애 발생시 스케쥴링을 중지하는 명령어

uncordon: 스케줄링 재시작

drain: 노드의 pod들을 옮기는 명령어 -> 부하 문제가 발생하지 않음

kubectl get pod -n kube-system 의미 : kube-system 의 pod 조회

kubectl get nodes 의미 : node 상태확인

kubectl get nodes -o wide 의미 : node 에 대한 자세한 정보

kubectl get pod --all-namespaces 의미 : 모든 네임스페이스 pod 리스트

kubectl get pods -n green (특정한 네임스페이스에서 정보를 볼떼) 의미 : green 이란 이름의 pods 조회

watch kubectl get pods -o wide 으미 : 2초 간격으로 상태 모니터링 하겠다.

kubectl get pods -n green -o wide (상세정보볼때) 의미 : green 이란 이름의 pods 상세조회

kubectl apply -f obj.yaml 의미 : obj.yaml 파일로 pod,deployment,service 등 생성하겠다.

kubectl delete -f obj.yaml 의미 : obj.yaml 파일로 만들어진 pod,deployment,service 삭제

kubectl create deployment demo-deployment --image=nginx:1.14 의미 : demo-deployment 란 deployment 를 배포하고 컨테이너 이미지는 nginx:1.14 를 사용

kubectl create deployment demo-deployment --image=nginx:1.14 --replicas=5 의미 : demo-deployment 란 deployment 를 배포하고 컨테이너 이미지는 nginx:1.14 를 사용하고 5개의 레플리카를 사용

kubectl scale deployment demo-deployment --replicas=10 의미 : demo-deployment 의 레플리카 개수를 10개로 변경

kubectl get deployment 의미 : 배포 목록 확인

kubectl get deployment.apps demo-deployment -o yaml 의미 : demo-deployment 의 .yaml 파일을 확인

kubectl get deployment.apps demo-deployment -o yaml > demo-deployment.yaml 의미 : demo-deployment 의 .yaml 파일을 demo-deployment.yaml로 저장

cat(vi) demo-deployment.yaml 의미: demo-deployment.yaml를 본다

kubectl delete deployments.apps demo-deployment 의미: demo-deployment 를 지운다

kubectl get po 의미 : get pods 과 같은 의미(현재 네임스페이스의 pods 리스트 )

kubectl get rs 의미 : get replicaset 과같은 의미(현재 네임스페이스의 replicaset 리스트)

kubectl get deploy 의미 : kubectl get deployment 와 같은 의미(배포 목록 확인)

watch kubectl get po -o wide 의미 : pod 의 상세정보를 실시간 확인

kubectl delete pod pod-exam 의미 : pod-exam pod 삭제

kubectl delete rs demo-deployment-6d8dbd56d7 의미 : demo-deployment-6d8dbd56d7 replicaset 삭제

kubectl delete deploy demo-deployment 의미 : demo-deployment deployment 삭제

========================================================3/28 kubectl cordon node3.example.com 의미 : node3.example.com 노드의 포드들이 더이상 스케쥴링 실행 x

kubectl drain node2.example.com 의미 : node2.example.com 노드의 포드들을 다른곳으로 이동

kubectl get nodes 의미 : node 상태확인

kubectl uncordon node3.example.com 의미 : node3.example.com 노드의 포드들이 정상적으로 스케쥴링

kubectl drain node2.example.com --ignore-daemonsets 의미 : node2.example.com 노드의 데몬셋을 이용한 포드들을 제외한 다른포드들이 다른곳으로 이동

kubectl delete nodes node3.example.com 의미 : node3.example.com 노드 제거

kubeadm token list 의미: token 값 조회

kubeadm token create 의미 : token 생성

worker node 에서 설정

kubeadm reset 의미 : kubeadm 초기화

kubeadm join --token 4gun4p.v..b 10.100.0.104:6443 --discovery-token-unsafe-skip-ca-verification 의미 : token 을 워커노드에 join

docker build -t hub.example.com/nginx . 의미 : hub.example.com/nginx 테그를 이용해 도커 생성

docker push hub.example.com/nginx 의미 : hub.example.com/nginx 이미지

kubectl create deployment nginx --image=nginx1.14 의미 : nginx 란 deployment 를 배포하고 컨테이너 이미지는 nginx:1.14 를 사용

kubectl expose deploy nginx --type=ClusterIP --port 80 의미 : nginx 란 deployment 를 80포트로 외부 노출

docker version 의미 : docker 버전확인

watch kubectl get pods -o wide 의미 : pods 의 상세정보를 실시간 확인

kubectl drain nodeX.example.com --dry-run=client 의미 : nodeX.example.com 노드의 포드들을 다른곳으로 이동할 정보를 미리보기

kubectl drain nodeX.example.com --ignore-daemonsets 의미 : nodeX.example.com 노드의 데몬셋을 이용한 포드들을 제외한 다른포드들이 다른곳으로 이동

kubectl drain nodeX.example.com --force 의미 : nodeX.example.com 노드의 포드들을 다른곳으로 이동할떄 중요한역할을 하는 포드의 경우 삭제되지 않아서 drain 이 진행되지않기때문에 --force 옵션을 주면 강제로 삭제

kubectl uncordon nodeX.example.com 의미 : nodeX.example.com 노드의 포드들이 정상적으로 스케쥴링

kubectl drain nodeX.example.com --ignore-daemonsets 의미 : nodeX.example.com 노드의 데몬셋을 이용한 포드들을 제외한 다른포드들이 다른곳으로 이동

kubectl delete node nodeX.example.com 의미 : nodeX.example.com 노드 제거

kubectl logs multipod -c nginx-container 의미 : 멀티pod 내의 컨테이너 로그 출력

kubectl get pods --show-labels 의미 : pods 의 레이블 정보 확인

kubectl get pod -L 의미 : pods 의 레이블 타입 확인

kubectl get pod 의미 : 현재 네임스페이스의 pods 조회

kubectl get pod --show-labels 의미 : pod 의 레이블 정보 확인

kubectl label pod redis-pod app=db 의미 : redis-pod 에 app=db 라는 레이블 부여

kubectl label pod nginx-pod app=web-services type=frontend 의미 : nginx-pod 에 app=web-services 라는 레이블 부여 타입은 frontend

kubectl label po label-pod app=web-services --overwrite 의미 : label-pod 에 app=web-services 라는 레이블 로 변경

kubectl get pod --show-labels 의미 : pod 의 레이블 조회

kubectl get pod -L app,type 의미 : pod 의 레이블의 app,type 정보 조회

kubectl get nodes --show-labels 의미 : nodes 의 레이블 정보 확인

kubectl get nodes -L beta.kubernetes.io/arch 의미 : 레이블이 beta.kubernetes.io/arch 라는 nods 조회

kubectl delete pod nodeselector-pod 의미 : nodeselector-pod 삭제

kubectl label node node2.example.com ssd- 의미 : node2.example.com 노드에 디스크가 ssd 인 레이블 추가

kubectl create -f pod-nodeselector.yaml 의미 : pod-nodeselector.yaml 파일 생성

kubectl label node node1.example.com ssd=true 의미 : node1.example.com 노드에 디스크가 ssd 인 레이블 추가

kubectl get pods nodeselector-pod -o wide 의미 : nodeselector-pod 란 pod 의 상세정보 확인

kubectl describe pod nginx-pod 의미 : nginx-pod 의 full 정보 확인

kubectl delete pod testpod 의미 : testpod 삭제

kubectl delete pod -l release=canary 의미 : release=canary란 레이블을 가진 pod 삭제

kubectl create -f pod-liveness.yaml 의미 : pod-liveness.yaml 생성

kubectl describe pod liveness-pod 의미 : liveness-pod 의 full 정보 확인

kubectl get pod testpod 의미 : testpod 조회

kubectl get pod testpod -o yaml 의미 : testpod 의 yaml 상세정보 확인

kubectl get pod testpod -o json 의미 : testpod 의 json 상세정보 확인

kubectl logs testpod 의미 : testpod의 로그 확인

kubectl logs testpod -c appjs-container 의미 : testpod 의 appjs-container 로그 확인

kubectl port-forward testpod 8888:8080 의미 : testpod 888:8080 으로 포트 포워딩

curl localhost:8888 의미: localhost:8888 연결 확인

kubectl label pod testpod2 env=debug --overwrite 의미 : testpod2 에 env=debug 라는 레이블 로 변경

kubectl get po -L app,env 의미 : pod 의 레이블의 app,type 정보 조회

kubectl get po -l app=hpe 의미 : 레이블이 app=hpe 인 pod 조회

kubectl get po -l '!env' 의미 : 레이블이 '!env' 인 pod 조회

kubectl delete pod test-gpu 의미 : test-gpu 삭제

kubectl delete po -l app=hpe 의미 :레이블이 app=hpe 인 pod 삭제

kubectl delete po --all 의미 : 모든 포드 삭제

kubectl get rc 의미 : replication controller 정보 조회

kubectl get pods 의미 : pods 조회

kubectl get pods -o wide 의미 : pods 의 상세정보 조회

kubectl delete pod nginx-rc-jm99k 의미 : nginx-rc-jm99k pod 삭제

kubectl delete replictioncontroller nginx-rc 의미 : replictioncontroller nginx-rc 삭제

kubectl edit replicationcontroller nginx-rc 의미 : replicationcontroller nginx-rc 수정

kubectl create -f rs-nginx.yaml 의미 : rs-nginx.yaml 파일 생성

kubectl get rs 의미 : replicaset 조회

kubectl get pods 의미 : pods 조회

kubectl describe pod rs-nginx-XXXX 의미 : rs-nginx-XXXX full 정보 확인

kubectl get all 의미 : 모든 pod,service,deployment,replicaset 조회

kubectl scale deployment nginx-deploy --replicas=2 의미 : nginx-deploy의 replicas 를 2로 변경

kubectl delete deployments.apps nginx-deploy 의미 : nginx-deploy 삭제

kubectl get daemonsets.apps -n kube-system 의미 : default 로 존재하는 데몬셋 확인

kubectl get pods -n kube-system -o wide | grep -e proxy -e weave 의미 : kube-system 네임스페이스에 속하고 proxy 왕 weave 가 들어간 상세정보 조회

kubectl get pod -o wide 의미 : pod 의 상세정보 조회

kubectl get daemonsets.apps 의미 : 데몬셋 정보 조회

kubectl edit daemonsets.apps fluentd 의미 : 데몬셋을 fluentd(로그수집기)로 업데이트

kubectl rollout history daemonset 의미 : daemonset 변경내역 확인

kubectl rollout undo daemonset fluentd 의미 : 바로 직전버전으로 롤백

kubectl rollout status daemonset fluentd 의미 : daemonset fluentd 의 rollout status 확인

kubectl describe pod fluentd- 의미 : fluentd- 상세정보 확인

kubectl delete daemonsets.apps fluentd 의미 : daemonsets.apps fluentd 삭제

kubectl apply -f job-centos.yaml 의미 : job-centos.yaml 수행

kubectl get pods --watch 의미 : pods 실시간 확인

kubectl get events 의미 : events 확인

kubectl create deployment my-first-deploy --image=nginx:1.14 의미 : my-first-deploy 란 deployment 를 배포하고 컨테이너 이미지는 nginx:1.14 를 사용

kubectl scale deployment my-first-deploy --replicas=2 의미 : my-first-deploy 의 replicas 를 2로 변경

kubectl get pods 의미 : pods 확인

kubectl get pods -o wide 의미 : pods의 상세확인

kubectl describe replicaset my-first-deploy-zzz 의미 : replicaset my-first-deploy-zzz의 full 정보 확인

kubectl get deployment 의미 : 배포목록 확인

kubectl expose deployment my-first-deploy --port=80 --type=NodePort 의미 : my-first-deploy 란 deployment 를 80포트로 외부 노출 타입은 nodeport

kubectl get svc 의미 : 서비스 확인

kubectl describe svc my-first-deploy 의미 : my-first-deploy란 서비스의 full 정보 확인

kubectl delete deployment my-first-deploy 의미 : my-first-deploy 삭제

kubectl delete svc my-first-deploy 의미 : my-first-deploy 삭제

kubectl create -f replicationcontroller-definition.yaml 의미 : replicationcontroller-definition.yaml 파일 생성

watch kubectl get pods 의미 : pods 목록 실시간 확인

kubectl get rc 의미 : replication controller 정보 조회

kubectl describe rc myapp 의미 : myapp란 replication controller 의 full 정보 확인

kubectl get pod --show-labels 의미 : pod의 label 정보 조회

kubectl label pod myapp-rc-XXX app=nginx --overwrite 의미 : myapp-rc-XXX pod 에 app=nginx 라는 레이블로 변경

kubectl get pods --show-labels 의미 : pod의 label 정보 조회

kubectl get pod -L app,type 의미 : pod 의 레이블의 app,type 정보 조회

kubectl scale rc myapp-rc --replicas=5
의미 : myapp-rc 라는 replication controller 의 replicas를 5로 변경

kubectl edit rc myapp-rc 의미 : myapp-rc 수정

kubectl scale rc myapp-rc --replicas=3 의미 : myapp-rc 라는 replication controller 의 replicas를 3으로 변경

kubectl get pods -L app 의미 : pod 의 레이블의 app 정보 조회

kubectl describe pod myapp-rc-xxx 의미 : myapp-rc-xxx 의 full 정보 확인

kubectl get rs 의미 : replicaset 조회

kubectl get pods -L app,type 의미 : pods 의 레이블의 app,type 정보 조회

kubectl delete rs myapp-rs 의미 : myapp-rs 라는 replicaset 삭제

kubectl delete pod --all 의미 : 모든 포드 삭제

kubectl label nodes node1.example.com ssd=true 의미 : node1.example.com 노드에 디스크가 ssd 인 레이블 추가

kubectl label nodes node3.example.com ssd=true 의미 : node3.example.com 노드에 디스크가 ssd 인 레이블 추가

kubectl get nodes --selector ssd=true 의미 : ssd=true 인 nodes 확인

kubectl get node --show-labels 의미 : node의 레이블 확인

kubectl get nodes -L ssd 의미 : ssd 라는 레이블의 nodes 확인

kubectl label nodes node1.example.com ssd 의미 : ssd 라는 레이블을 node1.example.com node 에 추가

kubectl get pods -o wide 의미 : pods 의 상세정보 확인

kubectl get pod -o wide 의미 : pods 의 상세정보 확인

kubectl get svc 의미 : service 정보 확인

iptables -t nat -S | grep 80 의미 : nat 테이블 중 80이들어간 목록 확인

kubectl get pod --show-labels -o wide 의미 : pod의 레이블 상세정보 확인

kubectl get svc 의미 : service 정보 확인

kubectl describe svc appjs-service 의미 : appjs-service 라는 service 의 full 정보 확인

kubectl get endpoints 의미 : endpoints 정보 확인

kubectl describe svc my-service 의미 : my-service 라는 service 의 full 정보 확인

cp svc-appjs.yaml svc-node.yaml 의미 : svc-appjs.yaml 라는 파일을 svc-node.yaml이름으로 현위치에 복사

cat svc-node.yaml 의미 : svc-node.yaml 확인

systemctl start nginx && systemctl enable nginx 의미 : nginx(웹서버) 실행 / nginx(웹서버) 자동 시작 등록

systemctl status nginx 의미 : nginx 상태 확인

firewall-cmd --add-service=http 의미 : http service 추가

firewall-cmd --add-service=http --permanent 의미 : http service 추가 [시스템 재부팅 이나 방화벽 재시작후에도 적용되도록 설정]

setsebool -P httpd_can_network_connect 1 의미 : httpd 프로세스에서 네트워크 연결 허용

systemctl restart nginx 의미 : nginx 재시작

kubectl get pod -n kube-system -l k8s-app=kube-dns 의미 : kube-system 의 pod 중 레이블이 k8s-app=kube-dns 인 pod 확인

kubectl get service 의미 : service 확인

kubectl exec -it centos-pod -- /bin/bash 의미 : centos-pod 에 접속

kubectl expose deploy ev237 --port 80 의미 : ev237 란 deployment 를 80포트로 외부 노출

kubectl get service 의미 : service 확인

kubectl get endpoints 의미 : endpoints 확인

kubectl edit service ev237 의미 : ev237 란 service 를 수정

cp rs-appjs.yaml readiness-appjs.yaml 의미 : rs-appjs.yaml 라는 파일을 readiness-appjs.yaml 이름으로 현위치에 복사

vim readiness-appjs.yaml 의미 : readiness-appjs.yaml 조회

kubectl get namespaces 의미 : namespaces 확인

kubectl delete pod nginx-pod-request 의미 : nginx-pod-request pod 삭제

vim nginx-pod-request.yaml 의미 : nginx-pod-request.yaml 조회

kubectl create -f nginx-pod-request.yaml 의미 : nginx-pod-request.yaml 파일 생성

kubectl get pods 의미 : pod 확인

kubectl get ns

의미 : namespaces 확인

kubectl get pod --namespace kube-system 의미 : kube-system 라는 namespace 의 pod 확인

kubectl create namespace custom-namespace 의미 : custom-namespace 라는 namespaces 생성

kubectl create -f testpod.yaml -n custom-namespace 의미 : testpod.yaml 파일과 namespace custom-namespace 를 생성

kubectl get namespaces 의미 : namespaces 확인

kubectl delete namespace custom 의미 : custom 이란 namespace 삭제

kubectl get pod -o wide --watch 의미 : pod 상세정보를 실시간 확인

kubectl delete deployments.apps stressful 의미 : deployments.apps stressful 제거

kubectl get pod -n ingress-nginx 의미 : ingress-nginx pod 확인

kubectl exec -n ingress-nginx ingress-nginx-controller-69fb496d7d-hrmrb -- /nginx-ingress-controller --version 의미 : ingress-nginx ingress-nginx-controller-69fb496d7d-hrmrb 를 실행시키고 nginx-ingress-controller의 버전 확인

kubectl get svc -n ingress-nginx 의미 : ingress-nginx 란 이름의 service 확인

kubectl config current-context 의미 : 현재 context 확인

kubectl config set-context ingress-nginx --namespace=ingress-nginx --cluster=kubernetes --user=kubernetes-admin 의미 : ingress-nginx 란 context 를 생성하고 namespace 는 ingress-nginx cluster는 kubernetes user는 kubernetes-admin 으로 세팅한다

kubectl config view 의미 : kubeconfig 확인

kubectl config use-context ingress-nginx 의미 : ingress-nginx context 를 사용한다

kubectl config current-context 의미 : 현재 context 확인

dynamic-web Pod 내의 web-server 컨테이너의 마운트 디렉토리를 사용해보자. touch 명령으로 파일을 생성할 수 있는가?

kubectl exec dynamic-web -c web-server -- ls /usr/share/nginx/html 의미 : dynamic-web파드에 접속하여 [container은 web-server] /usr/share/nginx/html 경로에있는 파일 목록을 보여준다

kubectl exec dynamic-web -c web-server -- touch /usr/share/nginx/html/test.html 의미 : dynamic-web파드에 접속하여 [container은 web-server] /usr/share/nginx/html 경로에 test.html 파일을 생성한다

kubectl get pods -o wide -n kube-system 의미 : kube-system란 namespace를 가지고있는 pods의 상세정보

kubectl exec -n kube-system -it fluentd-elasticsearch-2dqfp -- bash 의미 : fluentd-elasticsearch-2dqfp 포드에 접근

ls /var/log 의미 : ls /var/log 경로의 파일 목록 확인

ls /var/lib/docker/containers 의미 : ls /var/lib/docker/containers 경로의 파일 목록 확인

exit 의미 : 나가기

kubectl create -f pv1.yaml -f pv2.yaml -f pv3.yaml -f pv4.yaml 의미 : pv1.yaml , pv2.yaml , pv3.yaml , pv4.yaml 파일 생성

kubectl get pv 의미 : Persistent Volume 확인

kubectl create -f pvc.yaml 의미 : pvc.yaml 파일 생성

kubectl get pvc 의미 : Persistent Volume Claim 확인

kubectl create -f pod-mongodb.yaml 의미 : pod-mongodb.yaml 파일 생성

kubectl exec -it mongodb-pod -- mongo 의미 : mongodb-pod pod 에 접근

kubectl delete pod mongodb-pod 의미 : mongodb-pod 삭제

kubectl delete pvc mongo-pvc 의미 : mongo-pvc 삭제

kubectl get pv,pvc 의미 : Persistent Volume,Persistent Volume Claim 확인

ㅍ

nameserver 등록 = 도메인

버전 배포 종류

• rolling update
• blue-green
• canaria

EC2는 VM 단위이므로 무거움, 요즘에는 컨테이너(이미지) 단위로 만들어서 배포함.

RDS EC2 연동

1. DB용 보안그룹(실습용이므로 0.0.0.0/0으로 설정함), 서브넷 필요

ACM으로 인증서 발급

1. ACM을 통해 도메인의 인증서 발급. HTTPS 프로토콜 사용시 필요.

2. ALB 보안그룹, WEB 보안그룹 인바운드 그룹에 HTTPS 추가.

3. ALB 리스너 대상 그룹으로 HTTPS 선택

인증서 발급, 도메인 등록 후 도메인 접속을 시도하면 WEB 서버에 정상적으로 연결됨

AWS CLI 사용

1. AWS CLI 설치 참고 자료: https://inpa.tistory.com/entry/AWS-%F0%9F%93%9A-AWS-CLI-%EC%84%A4%EC%B9%98-%EC%82%AC%EC%9A%A9%EB%B2%95-%EC%89%BD%EA%B3%A0-%EB%B9%A0%EB%A5%B4%EA%B2%8C#%EC%9C%88%EB%8F%84%EC%9A%B0_windows

2. 설치 후 계정 Accesse Key 값을 입력한 뒤, aws configure list를 입력해서 확인.

3. CLI를 이용해 인스턴스를 원격으로 실행/중지 시킬수 있음.

4. 이제 aws 콘솔 접속 대신 CLI로 서비스 제어가 가능함

S3 Browser

설치 사이트: https://s3browser.com/

버킷 생성시 주의할 점: 이름에 대문자 불가, 이미 사용중인 이름 사용 불가.

S3는 파일 업로드가 가능함

CloudFront

CloudFront = 온프라미스에서의 CDN 서비스로 볼 수 있음. 전송 가속기 역할을 함.

CDN이란?

CDN = Content Delivery Network의 약자. 데이터 사용량이 많은 애플리케이션의 웹 페이지 로드 속도를 높이는 상호 연결된 서버 네트워크로, 지리적 제약 없이 전 세계 사용자에게 빠르고 안전하게 콘텐츠를 전송할 수 있는 콘텐츠 전송 기술을 의미함.

사용이유

웹페이지는 다양한 미디어를 제공하기 때문에 무겁다. 따라서, 보다 빠른 서비스 제공을 위해 CDN을 사용함. 넷플릭스, 왓챠, 유튜브 등 다양한 콘텐츠 제공 서비스에서 활용함.

CloudFront 생성

원본도메인 = ALB의 도메인

Cache policy and origin request policy (recommended) 선택. Legacy cache settings

한국리전에서 발급받은 인증서는 안됨

생성.

Route53에서 레코드 생성

배포 프로토콜을 HTTPS로 선택하면 아래와 같은 에러 화면이 출력됨. HTTP로 선택해야 정상 화면이 출력됨.

CloudFront 3대 원칙

• 이미지와 같은 정적 컨텐츠는 클라우드 프론트에 오래도록 캐시한다.
• 웹페이지와 같은 동적 컨텐츠는 클라우드 프론트의 전송 최적화 기능을 활용한다.
• 썸네일 이미지 같은 재사용 가능한 동적 컨텐츠는 클라우드 프론트의 기능을 활용

따라서

• 자주 쓰는 데이터를 저장
• 통신경로를 최적화 할 때
• 편의점 느낌 - 사용자가 많이 드나드는 입지에 자주 오는 사용자의 기호에 맞춰, 인기있는 상품을 빠르게 검색 할 수 있도록 해준다. (즉 한마디로 표현하면 편의점 또는 ATM 기기라고 할 수 있다.)
• 서울리전에는 2곳의 엣지 로케이션이 있고, 글로벌적으로는 53개의 엣지 로케이션이 있다.

aws DB 종류

• Amazon Aurora - Mysql, postgres 호환
• Aurora severless
• NoSQL
• ...

사용자 > 1000명 -> 부하 분산을 위한 로드밸런싱 필요, db 이중화 필요

이중화: 두개의 AZ에 위치하는 DB중 하나는 active, 다른 하나는 standby로 구분. Active db가 다운되면, Standby db를 Active로 변경. standby는 읽기 불가능

ELB: 부하 분산을 위한 로드밸런서 - HTTPS 통신을 위한 보안 인증 필요 = 인증서 다운로드를 위한 DNS 필요

• ALB

사용자 > 10000 -> 읽기 전용 복제본(Read Replica) 필요.

• active와 standby는 동기 방식(변경사항 바로 복제)
• active와 read replica는 비동기 방식

정적 컨텐츠 = S3와 CloudFront 활용.

• S3: 오브젝트 기반 스토리지 = 이미지와 같은 미디어 저장 가능
• CloudFront: 컨텐츠 전달을 위한 캐싱

보다 많은 보하 분산 = 캐시 사용(섹션 유지)

• AWS ElastiCache: 사용자의 섹션을 유지, DB의 부하를 줄여줌.
  • 관리형 Memcached(단일 AZ 서비스), Redis(다중 AZ 서비스) 사용
  • 인메모리 기반이므로 DB보다 빠른 읽기 속도
  • 사용 비용이 매우 높음

사용자 > 5000000 -> 오토 스케일링 필요 오토 스케일링: 효율적인 운영을 위해 트래픽에 따라 컴퓨터 클러스터의 용량을 자동 조절

사용자 > 1백만 -> interner elb 사용

AWS RDS 생성

순서: RDS 선택 - 데이터베이스 생성 선택 - 설정 및 생성 - MySQL WorkBench 설치 및 연결

mysql은 크게 두가지 방식으로 사용할 수 있다. -> 워크밴치 or 서버에서 자체 설치

Workbench 사용법:

https://m.blog.naver.com/nieah914/221815212859

aws EC2(Linux)에 mysql 설치하는법:

https://blogshine.tistory.com/322

server에 mysql 설치 직후에는 mysql -u root -p로 연결이 안됨.

이는 IP가 없기 때문에 생기는 문제로, DB 인스턴스와 연결하기 위해선 mysql -u '관리자계정명' -p -h 'aws db 인스턴스의 엔드포인트 주소'

설치 이후 설정 1. 시간대 변경

select now()를 통해 시간을 확인해보면, RDS의 현재 시간이 시간대가 UTC로 설정되어있음을 알 수 있다. 정상적인 시스템 운영을 위해서는 올바른 시간대(Asian/Seoul)를 사용해야되므로 AWS RDS의 시간대 수정 및 재부팅 필요함. 참고 사이트: https://programforlife.tistory.com/52

Workbench에서 신간대 변경 확인

ubuntu에서 시간대 변경 확인

설치 이후 설정 2. UTF 변경

데이터가 영어 값으로만 저장되는 것이 아니기 때문에(한국은 한국어 입력이 필요 = 2byte 단위 저장) UTF 설정 변경이 필요함. 참고: hevton.tistory.com/521

저장후 마찬가지로 저장 및 인스턴스의 수정, 재부팅 진행.

VPN이란 Virtual Private Network의 약자로 가상 사설망을 의미한다. 인터넷을 마치 확장된 전용 사설 네트워크처럼 사용하는 방식으로, 인터넷을 통해 사적인 트래픽을 비교적 안전하게 통신할 수 있다.

AWS의 VPN 서비스

AWS는 AWS Client VPN와 AWS Site-to-Site VPN 두가지 방식의 VPN 서비스를 제공한다. 사용자는 두 서비스를 통해 네트워크 트래픽을 보호하는 탄력적이고 고가용성 관리형 클라우드 VPN 솔루션을 이용할 수 있다. IPsec(인터넷 프로토콜 보안) VPN 연결을 통해 On-Premise 환경의 사내망을 AWS의 VPC와 연결할 때 또는 서로 다른 리전에 위치하는 VPC간의 연결(원격 액세스)을 생성해준다.

AWS Client VPN

완전관리형의 탄력적 VPN 서비스서, 사용자 요구 사항에 맞추어 자동으로 확장하거나 축소 가능. 클라우드 VPN 솔루션이므로, 하드웨어나 소프트웨어 기반 솔루션을 설치 및 관리하거나 한 번에 지원할 원격 사용자 수를 예측하지 않아도 된다는 장점이 있음.

AWS Site-to-Site VPN

데이터 센터 또는 지점과 AWS 클라우드 리소스 사이에서 보안 연결을 생성. 글로벌로 분산된 애플리케이션에 대해 AWS Global Accelerator와 함께 Accelerated Site-to-Site VPN 옵션을 사용하여 성능을 향상 가능.

출처: https://aws.amazon.com/ko/vpn/

AWS Site-to-Site VPN을 이용한 서로 다른 리전 연결의 예시

연결 과정

xShell 설정 - xShell에서 Bastion 인스턴스와 Ubuntu 인스턴스에 SSH 접속하도록 설정

ubuntu 서버에 nginx 설치

sudo apt update
sudo apt upgrade
sudo apt autoremove

sudo service nginx start
sudo service nginx status

nginx 동작 확인 - 브라우저 창에서 Ubuntu 서버의 퍼블릭 IP로 접속 및 Status 명령어로 서비스 상태 확인

Bastion 서버와 Ubuntu 서버의 핑 확인 - Ubuntu 서버의 Private IP 주소로 Ping 전송. 보안 규칙에서 ICMP 통신을 허용해놔서 핑이 도달함을 확인 가능.

Xftp 프로그램으로 ssh키를 Bastion 서버와 Ubuntu 서버로 복사

ssh 연결 확인 - 각 서버에서 반대편 서버로 ssh 접속

chmod 400 ssh키.pem
ssh -i "ssh키.pem" "user이름"@"대상의 public IP"

설정 표

cluster ip, nodeport, loadbalance(metalib 사용), external name

service를 yml파일로 만들기

kubectl get pod,svc,deploy --all-namespaces : 모든 namespace의 pod, service, deployment 확인 가능

---
apiVersion: v1
kind: Service
metadata:
  name: svc-nginx
  labels:
    run: nginx
spec:
  type: NodePort
  ports:
  - port: 8080
    targetPort: 80
    nodePort: 30080
    protocol: TCP
  selector:
    app: web

replicaset: pod의 복제 deployment: replicaset 관리 외부 서비스는 pod, deployment만 가능, 보통 replicaset 관리가 가능한 deployment를 서비스함

Pod의 Replicaset 생성

다수의 pod를 생성하기 위해 replica를 사용하는것이므로 템플릿이 필요함.

clusterIP - 일종의 부하 분산 서비스. 어떤 노드에 연결될지 모름. = /ㅍ1 nodeport -

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: dep-apache
  labels: 
    dep: apache
spec:
  replicas: 3
  selector:
    matchLabels:
      app: rep-apache
  template:
    metadata:
      name: tem-apache
      labels:
        app: rep-apache
    spec:
      containers:
      - name: apache
        imange: httpd
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80

연습

조건

1. 1개의 pod를 mysql5.7로 생성
2. wordpress5.6을 depolyment로 생성해서 3개의 rep pod 생성
3. nodeport => 32080로 외부에 서비스
4. 개별 pod의 ip 접속, clusterip접속, node의 ip 접속

해설

1. mysql pod 생성을 위한 yml 파일 작성

2. wordpress service 하는 yml 파일 작성

3. 각 yml 파일을 순서대로 실행 후 kubectl get 명령어로 확인

4. kubectl describe로 wordpress service 상태 확인

5. pod 상태 확인

6. curl 명령어로 ip 접속. 오류 메세지가 나오지는 않지만, wordpress container를 배포하기 때문에 apache나 nginx와 달리 출력값이 나오지 않음.

7. 보다 확실한 접속 확인을 위해 lynx 설치 후 lynx로 pod, cluster ip 접속

7. 웹 브라우저에서 Host IP 접속

nginx공부: https://nginxstore.com/training/

cni 비교

참조 자료: https://ykarma1996.tistory.com/179 weaveNet: 같은 lan으로 인식 calico: 라우팅 가능 dummy0 = docker0: weav랑 datapath가 기능을 대신하기 때문에 사용되지 않음.

Volume

참고: https://virtualtech.tistory.com/339

k8s Volume은 크게 세가지로 분류.

• emptydir: life cycle이 pod와 동일
• hostpath:node 단위로 관리
• persistent Volume: cluster 단위로 관리

1. 마운트 경로를 /usr/sharenginx/html 디렉토리로 지정

2. 위 코드에서 alpine 이미지 실행을 포함시킨 코드. nginx 컨테이너와 달리 alpine의 마운트 경로는 아직 존재하지 않는 디렉토리인 /test로 설정.

3. Volume Mount를 존재하지 않는 경로로 지정하면 상태 값이 ContainerCreating에서 멈추고 정상 동작하지 못한다.

4. describe 명령어로 확인했을 때 출력된 오류 정보

5. 

nodeName을 이용해 pod가 실행될 node 지정 가능 type이 Directory인 경우, 위치에 path에서 지정한 디렉토리가 없으면 정상적으로 동작하지 못함.

type을 DirectoryOrCreate로 바꾸면, 디렉토리가 없으면 디렉토리를 생성함.

persistant volume - 다른 노드에 위치해도 vol 사용이 가능해짐

persistant volume yml 파일 실행

deployment yml파일 작성

yml 파일 실행

curl 명령어로 각 노드에 배포된 pod의 IP로 접속. 사전에 index.html 파일을 작성해놓은 노드(나는 node1에 작성함)외의 노드에 존재하는 pod들은 html 파일이 변경되지 않음을 확인할 수 있다.

다른 노드에 /test 디렉토리가 있는지 확인

persistant만 사용하면 node간의 디렉토리 동기화는 되지만, 디렉토리 내부 파일까지 동기화 되지 않음. 디렉토리 내부 Data까지 동기화하기 위해서는 nfs 사용이 필요.

참고 사이트: https://zgundam.tistory.com/179

Ingress

설치 사이트1: https://github.com/kubernetes/ingress-nginx 설치 사이트2: https://kubernetes.github.io/ingress-nginx/deploy/

설치 순서: 사이트1에서 started 링크 클릭 -> 사이트2로 이동함 -> vmware를 사용중이므로, baremetal 선택 -> 코드 복사 -> kubectl apply -f 를 지우고 wget으로 먼저 설치한 뒤 kubectl apply -f 사용해서 설치

Ingress: Cluster 내의 서비스에 대한 외부 접근을 관리하는 API 오브젝트이며, 일반적으로 HTTP를 관리함. Ingress 는 LoadBalancer, SSL Terminated, Named 기반의 가상 호스팅을 제공할 수 있다. ex) bsbo.com/svc1과 babo.com/svc2 의 화면을 다르게 출력함

1. Ingress-nginx 설치

2. ingress-nginx에 포함된 yml 파일의 내용

3. 필요한 것들이 설치 됐는지 확인

4. ingress를 사용하는 yml 파일 작성

5. ingress 실행 확인

....

5번 서버에 nginx + PHP(wordpress)를 설치하고 mysql이 설치되어있는 4번서버와 연동시켜보자.

조건:

• 1번 서버에서 ansible로 yml을 파일을 실행시켜서 원격으로 서버를 설정
• wordpress 디렉토리 내부 파일들을 nginx/html/ 디렉토리로 복사
• php-fpm이 nginx을 인식하도록 www.conf 파일 내용 수정(apache를 nginx로 수정)
• DB 서버에 연결시키기 위해, nginx 디렉토리에 복사된 wp-conf.php의 내용 수정 필요

실행 전 준비: yum으로 rdate 설치 후 시간 설정 필요.

참고자료: https://docs.ansible.com/ansible/2.9/modules/blockinfile_module.html#blockinfile-module

초기 코드

---
- name: nginx + wordpress + mysql
  hosts: nginx
  tasks:
  - name: install wget + yum utils + epel-release
    yum:
      name: "{{ item }}"
      state: latest
    loop: 
      - wget
      - yum-utils 
      - epel-release
      - http://rpms.remirepo.net/enterprise/remi-release-7.rpm

  - name: install php7.4 
    yum: 
      name: "{{ packages }}"
      state: present
    vars:
      packages:
        - php
    - php-common
    - php-cli
    - php-curl
    - php-mcrypt
    - php-gd
    - php-opcache
    - php-fpm
    - php-mysqlnd

  - name: url file download - wordpress
    get_url: 
      url: https://ko.wordpress.org/wordpress-5.8.6-ko_KR.tar.gz
      dest: ./

  - name: unarcive tar file
    unarchive:
      src: wordpress-5.8.6-ko_KR.tar.gz
      dest: ./
      remote_src: yes

  - name: copy wordpress to nginx
    copy:
      src: "{{ item.src }}"
      dest: "{{ item.dest }}"
      remote_src: yes
    loop:
      - {src: "./wordpress/", dest: "/usr/share/nginx/html/"}
      - {src: "/usr/share/nginx/html/wp-config-sample.php", dest: "/usr/share/nginx/html/wp-config.php"}

  - name: port 80/tcp open
    firewalld:
      port: 80/tcp
      permanent: yes
      immedinate: yes
      state: enabled

  - name: nginx + php started 
    service:
      name: "{{ item }}"
      state: started
    loop: 
      - nginx
      - php-fpm

이 yml파일을 적용했을 때, 정상적인 동작이 되지 않음.

문제: /etc/nginx/nginx.conf 파일에 내용 추가를 위해 blockinfile 모듈을 사용했는데, 내용이 의도대로 추가 되지 않음

원인: blockinfile 모듈은 동일 파일에 중첩이 안되기 때문에 문제가 발생함.

해결 방안: 함수 내부에 있으면 위치는 상관없는 코드들이므로, 두 개의 blockinfile 모듈의 내용을 하나로 통합해서 작성.

  - name: block in /etc/nginx/nginx.conf - 1
    blockinfile:
      path: /etc/nginx/nginx.conf
      insertafter: '^(\s+server_name\s+)_;'
      block: |
    #
            index   index.php;
            location ~ \.php$ {
                    try_files $uri =404;
                    fastcgi_pass unix:/run/php-fpm/www.sock;
                    fastcgi_index   index.php;
                    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
                    include fastcgi_params;
                }

1차 수정

오류 수정 + mysql 연결 추가한 코드

blockinfile 모듈 사용시 regexp 대상이 여러개인 경우, 이상한 위치에 입력되므로 유일한 대상('^(\s+error_page\s+)404 /404.html;')을 지정해서 해당 라인의 윗 줄에 추가 하도록 코드 수정(insertafter를 insertbefore로 변경).

---
- name: nginx + wordpress + mysql
  hosts: nginx
  tasks:
  - name: install wget + yum utils + epel-release
    yum:
      name: "{{ item }}"
      state: latest
    loop:
      - wget
      - yum-utils
      - epel-release
      - http://rpms.remirepo.net/enterprise/remi-release-7.rpm
      - nginx

  - name: install php7.4
    yum:
      name: "{{ packages }}"
      state: present
    vars:
      packages:
        - php
        - php-common
        - php-cli
        - php-curl
        - php-mcrypt
        - php-gd
        - php-opcache
        - php-fpm
        - php-mysqlnd

  - name: url file download - wordpress
    get_url:
      url: https://ko.wordpress.org/wordpress-5.8.6-ko_KR.tar.gz
      dest: ./

  - name: unarcive tar file
    unarchive:
      src: wordpress-5.8.6-ko_KR.tar.gz
      dest: ./
      remote_src: yes

  - name: copy wordpress to nginx
    copy:
      src: "{{ item.src }}"
      dest: "{{ item.dest }}"
      remote_src: yes
    loop:
      - {src: "./wordpress/", dest: "/usr/share/nginx/html/"}
      - {src: "/usr/share/nginx/html/wp-config-sample.php", dest: "/usr/share/nginx/html/wp-config.php"}

  - name: change /etc/php-fpm.d/www.conf
    replace:
      path: /etc/php-fpm.d/www.conf
      regexp: "{{ item.src }}"
      replace: "{{ item.dest }}"
    loop:
      - {src: 'apache', dest: 'nginx' }
      - {src: ';listen.owner = nobody',dest: ';listen.owner = nginx'}
      - {src: ';listen.group = nobody',dest: ';listen.group = nginx'}
      - {src: 'listen = 127.0.0.1',dest: ';listen = 127.0.0.1'}

  - name: block in /etc/nginx/nginx.conf - 1
    blockinfile:
      path: /etc/nginx/nginx.conf
      insertafter: '^(\s+server_name\s+)_;'
      block: |
    #
            index   index.php;
            location ~ \.php$ {
                    try_files $uri =404;
                    fastcgi_pass unix:/run/php-fpm/www.sock;
                    fastcgi_index   index.php;
                    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
                    include fastcgi_params;
                }

  - name: change wp-config.php
    replace:
      path: /usr/share/nginx/html/wp-config.php
      regexp: "{{ item.src }}"
      replace: "{{ item.dest }}"
    loop:
      - {src: "database_name_here", dest: "wordpress" }
      - {src: "username_here", dest: "root" }
      - {src: "password_here", dest: "It12345@" }
      - {src: "localhost", dest: "10.0.0.4" }

  - name: install mysql
    shell: "yum install -y http://dev.mysql.com/get/mysql57-community-release-el7-11.noarch.rpm"
    ignore_errors: yes

  - name: mysql client repo gpg_check disable
    yum:
      name: "{{ item }}"
      disable_gpg_check: yes
      state: present
    loop:
        - mysql-community-client
        - mysql-community-server

  - name: mysql port open
    firewalld:
      port: "{{ item }}"
      permanent: yes
      immediate: yes
      state: enabled
    loop:
      - 80/tcp

  - name: nginx + php + mysql started
    service:
      name: "{{ item }}"
      state: started
    loop:
      - nginx
      - php-fpm
      - mysqld

yml 파일이 정상적으로 실행됨 확인

5번 서버의 nginx.conf 파일 역시 지정한 위치에 입력됨을 확인

2차 수정

• 입력되는 위치가 마음에 들기 때문에 입력 위치 변경.
• mysql는 다른 서버에 설치하고 사용할 것이므로 mysql 설치 코드는 제거.
• php7.4 사용을 위한 코드 추가.

---
- name: nginx + wordpress
  hosts: nginx
  tasks:
  - name: install wget + yum utils + epel-release
    yum:
      name: "{{ item }}"
      state: latest
    loop:
      - wget
      - yum-utils
      - epel-release
      - http://rpms.remirepo.net/enterprise/remi-release-7.rpm
      - nginx

  - name: install php7.4
    yum:
      name: "{{ packages }}"
      state: present
    vars:
      packages:
        - php
        - php-common
        - php-cli
        - php-curl
        - php-mcrypt
        - php-gd
        - php-opcache
        - php-fpm
        - php-mysqlnd

  - name: install php74
    shell: yum-config-manager --enable remi-php74

  - name: url file download - wordpress
    get_url:
      url: https://ko.wordpress.org/wordpress-5.8.6-ko_KR.tar.gz
      dest: ./

  - name: unarcive tar file
    unarchive:
      src: wordpress-5.8.6-ko_KR.tar.gz
      dest: ./
      remote_src: yes

  - name: copy wordpress to nginx
    copy:
      src: "{{ item.src }}"
      dest: "{{ item.dest }}"
      remote_src: yes
    loop:
      - {src: "./wordpress/", dest: "/usr/share/nginx/html/"}
      - {src: "/usr/share/nginx/html/wp-config-sample.php", dest: "/usr/share/nginx/html/wp-config.php"}

  - name: change /etc/php-fpm.d/www.conf
    replace:
      path: /etc/php-fpm.d/www.conf
      regexp: "{{ item.src }}"
      replace: "{{ item.dest }}"
    loop:
      - {src: 'apache', dest: 'nginx' }
      - {src: ';listen.owner = nobody',dest: ';listen.owner = nginx'}
      - {src: ';listen.group = nobody',dest: ';listen.group = nginx'}
      - {src: 'listen = 127.0.0.1',dest: 'listen =  /run/php-fpm/www.sock'}

  - name: block in /etc/nginx/nginx.conf
    blockinfile:
      path: /etc/nginx/nginx.conf
      insertbefore: '^(\s+error_page\s+)404 /404.html;'
      block: |
    #
            index   index.php;
            location ~ \.php$ {
                    try_files $uri =404;
                    fastcgi_pass unix:/run/php-fpm/www.sock;
                    fastcgi_index   index.php;
                    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
                    include fastcgi_params;
            }

  - name: change wp-config.php
    replace:
      path: /usr/share/nginx/html/wp-config.php
      regexp: "{{ item.src }}"
      replace: "{{ item.dest }}"
    loop:
      - {src: "database_name_here", dest: "wordpress" }
      - {src: "username_here", dest: "root" }
      - {src: "password_here", dest: "It12345@" }
      - {src: "localhost", dest: "10.0.0.4" }

  - name: mysql port open
    firewalld:
      port: 80/tcp
      permanent: yes
      immediate: yes
      state: enabled

  - name: nginx + php started
    systemd:
      name: "{{ item }}"
      state: started
      enabled: yes
    loop:
      - nginx
      - php-fpm

결과 화면

정상적으로 DB서버와 연동되어 nginx 화면이 아닌 wordpress 화면이 정상적으로 출력됨.

Linux 명령어 공부 - diff 명령어

diff 파일1, 파일2: 두 파일의 내용을 비교하는 명령어

사용자 생성(useradd = usermod)과 연관된 파일들

1. /etc/passwd
 1.1. 원본 root:x:0:0:root:/root:/bin/bash
 1.2. 분석
     root         - ID
    :x            - 패스워드
    :0            - UID            -u
    :0            - GID            -g(기본그룹) -G(추가그룹) 
    :root        - comment        -c
    :/root        - 홈디렉토리        -d
    :/bin/bash    - Login shell    -s(/bin/bash, /bin/sh, /bin/false(로그인 불허 이유 설명 X), /sbin/nologin(로그인 불허 이유 설명 O))

/etc/shadow
/etc/group
/etc/default/useradd
/etc/login.defs
/etc/skell/

UID, GID 확인

/etc/login.defs 파일을 통해 UID 및 GID 설정값 확인 가능 기본적으로 1000으로 저장되어있지만, 값을 변경하면 useradd 시 사용자의 uid랑 gid 값이 설정값이 파일의 설정값에 따라 바뀜.

주의점: GID는 UID 생성시 자동적으로 생성되기 때문에 없는 useradd할 때 없는 GID를 생성하면(useradd -u 옵션과 -g 옵션을 동시에 사용하면) 오류가 발생(-u 사용시 group은 자동적으로 생성됨).

UID 설정

옵션 없이 useradd 실행 시 마지막으로 추가된 사용자의 UID 뒷 번호로 추가됨.

useradd 설정.

• 옵션을 통해 사용자의 'UID', '저장 위치', '설명(comment)', '로그인 할 shell' 및 '거부 설명 표시 여부'를 설정할 수 있음
• /home_1 디렉토리를 만들고 user a를 추가 후, tail 명령어를 이용해서 a에 대한 useradd 설정 확인 가능.

-s 옵션을 /sbin/nologin 지정하면

로그인 거부에 대한 설명을 출력함.

-s 옵션을 /bin/false 지정하면

로그인 거부에 대한 설명을 출력하지 않음.

cat /etc/shells를 통해 어떤 shell이 있는지 확인할 수 있음

로그인하는 shell 지정

CentOS에서는 chsh 명령어를 통해 다음 로그인하는 shell을 지정 가능

사용자의 shell 지정

/etc/default/useradd 파일 설정을 통해 추가되는 사용자의 shell 설정을 변경 가능.

참고 자료: https://docs.ansible.com/ansible/2.9/modules/lineinfile_module.html#lineinfile-module

lineinfile 모듈을 이용해 파일 안의 내용을 변경해보자.

inven.list에 정의된 web1에 포함된 모든 서버의 selinux라는 파일의 내용을 변경해보자.

사용한 코드> ansible -i inven.list web1 -m lineinfile -a "path=/etc/sysconfig/selinux regexp='^SELINUX=enforcing' line='SELINUX=disabled'"

입력은 되지만 내용을 변경하는게 아니라 마지막 줄에 추가 되는 모습...

Lineinfile 모듈은 regexp에 입력된 패턴과 일치하는 라인의 내용을 line에 입력된 값으로 변경하는 동작을 한다. 하지만 파일에 일치하는 라인이 없는 경우, 파일의 마지막 라인에 해당 내용을 저장한다. 따라서 지금처럼 SELINUX의 설정값이 이미 disable로 설정되있는 경우에는 SELINUX 파일 마지막줄에 SELINUX=enforcing이 추가 된다.

Ansible 명령어를 yml 파일로 만들어 보기

연습) httpd 설치 + 방화벽 80/tcp 열기 + health.html 복사

(/etc/httpd/conf/httpd.conf -> index.html를 controller의 /root 디렉토리에 health.html로 이름 변경 후 복사.)

오류 화면 1) 실행은 되지만 html 파일이 적용이 안됨

-> 원인: yml 파일에 lineinfile 명령어 부분이 'DirectoryIndex index.html'이 아니라 '^DirectoryIndex index.html'로 입력되어 정상적으로 라인 입력이 안됨.

-> 이유: httpd.conf 파일에서 DorectoryIndex 앞에 띄어쓰기가 있기 때문에 yml파일의 lineinfile에서^을 앞에 포함시키면 해당 라인을 인식하지 못함.

-> 해결 방법: 각 서버의 httpd.conf 파일에 잘못 추가된 줄을 지우고, yml 파일 수정(^ 제거) 후 yml 실행 및 각 서버의 httpd 재시작

수정한 yml 파일 내용

httpd 재시작 모습

최종 ansible 코드

ansible -i inven.list -m yum -a "name=httpd state=latest" ansible -i inven.list -m firewalld -a "port=80/tcp state=enabled" ansible -i inven.list -m lineinfile -a "path=/etc/httpd/conf/httpd.conf regexp='^DirectoryIndex index.html' line='DirectoryIndex health.html'" ansible -i inven.list -m copy -a "src=httpd.html dest=/var/www/html/health.html"

최종 yml파일 코드

---
- name: install httpd & open port 80/tcp & change name index.html to health.html & copy health.html
  hosts: test
  tasks:
  - name: install httpd
    yum:
      name: httpd
      state: latest
  - name: firewall port open 80/tcp
    firewalld:
      port: 80/tcp
      state: enabled
  - name: change name index.html
    lineinfile: 
      path: /etc/httpd/conf/httpd.conf
      regexp: 'DirectoryIndex index.html'
      line: 'DirectoryIndex health.html'
  - name: copy health.html file
    copy:
      src: httpd.html
      dest: /var/www/html/health.html
  - name: httpd deamon restart
    service:
      name: httpd
      state: restarted