반응형
SMALL

Setting Latest AMI


data "aws_ami" "ubuntu_latest" {
  most_recent = true
  owners      = ["099720109477"] #Canonical
  filter {
    name   = "name"
    values = ["ubuntu/images/hvm-ssd/ubuntu-bionic-18.04-amd64-server-*"]
  }
  filter {
    name   = "virtualization-type"
    values = ["hvm"]
  }
}

data "aws_ami" "amzn2_lastest" {
  most_recent = true
  owners      = ["amazone"]
  filter {
    name   = "name"
    values = ["amzn2-ami-hvm-*-x86_64-ebs"]
  }

aws_ami

  • AWS 내 ami를 셋팅할 수 있는 명령어입니다.

data

  • Terraform 외부에서 정의되거나 다른 별도의 Terraform 구성에 의해 정의되거나 기능에 의해 수정된 정보를 사용할 수 있습니다.

most_recent

  • 둘 이상의 결과가 반환되는 경우 가장 최근의 AMI를 사용한다는 것을 의미합니다.

owners

  • 검색을 제한할 AMI 소유자 목록. 최소 1개의 값을 지정해야 합니다.

filter

  • 필터링할 하나 이상의 이름/값 쌍입니다

 

Create EC2 (Bastion)


resource "aws_instance" "terraform_bastion" {
  ami                    = data.aws_ami.ubuntu_latsest.id
  instance_type          = "t2.micro"
  key_name               = aws_key_pair.aws_bastion_key.key_name
  vpc_security_group_ids = ["${aws_security_group.terraform_bastion_sg.id}"]
  subnet_id              = aws_subnet.terraform_public_subnet.0.id
  tags = {
    Name = "${var.company_name}-${var.project_name}-${var.environment}-bastion"
  }

}

aws_instance

  • AWS 내 EC2를 생성하는 명령어입니다.
  • AMI, Instance type, key, Subnet(첫 번째로 선택), SG 선택해줍니다.

ami

  • 인스턴스를 생성할 ami의 id입니다.

vpc_security_group_ids

  • 하나의 인스턴스에는 여러개의 SG을 넣는 것이 가능하기 때문에 배열로 생성합니다.

 

Create Launch_Config


resource "aws_launch_configuration" "asg_configuration" {
  image_id        = data.aws_ami.amzn2_lastest.id
  instance_type   = "t2.micro"
  key_name        = aws_key_pair.aws_ec2_key.key_name
  security_groups = [aws.security_group.terraform_sg.id]
  depends_on      = [aws_security_group.terraform_sg]
  lifecycle {
    create_before_destory = true
  }
  name = "${var.company_name}-${var.project_name}-${var.environment}-asg-configuration"

}

aws_launch_configuration

  • Auto Scaling을 통해 생성될 EC2, 생성할 때 각 Instance에 적용할 Launch Configuration을 생성합니다.

depens_on

  • 리소스들의 실행 순서를 정해줄 수 있는 명령어입니다.
  • depens_on을 사용 하는 이유?
  • SG이 생성되기도 전에 resource를 생성하려고 하면, 존재하지 않는다는 에러가 발생할 수 있기 때문에 이와같이 의존성을 부여하는 것입니다.

lifecycle

  • 만일 재생성되어야 한다면 새로운 인스턴스 먼저 생성후 예전 인스턴스를 지우도록 합니다. → 재생성으로 인한 downtime이 없도록 합니다.

 

Create Autoscaling Group


resource "aws_autoscaling_group" "terraform_asg" {
  launch_configuration = aws_launch_configuration.asg_configuration.id
  health_check_type    = "EC2"
  vpc_zone_identifier  = aws_subnet.terraform_private_subnet.*.id

  min_size = 2
  max_size = 5
  tag {
    key                 = "Name"
    value               = "${var.company_name}-${var.project_name}-${var.enviroment}-ec2"
    propagate_at_launch = true
  }
  name = "${var.company_name}-${var.project_name}-${var.enviroment}-asg"
}

aws_autoscaling_group

  • AWS 내 Autoscaling group을 생성하는 명령어입니다.

health_check_type

  • EC2 or ELB 로 작성 가능하며 상태 확인이 수행되는 방식을 선택합니다.

min_size/max_size

  • Autosacaling으로 생성될 인스턴스의 최소/최대 개수를 나타냅니다.

propagate_at_launch

  • ASG를 통해 시작된 Amazon EC2 인스턴스로 태그 전파 활성화

 

Create ELB


resource "aws_lb" "terraform_nlb" {
  internal           = false
  load_balancer_type = "network"
  subnets            = aws_subnet.terraform_private_subnet.*.id
  name               = "${var.company_name}-${var.project_name}-${var.environment}-nlb"

}

aws_lb

  • AWS 내 LB 생성하는 명령어입니다.

internal

  • 외부 LB인지, 내부 LB인지를 구분

load_balancer_type

  • application(default)/network/gateway

 

Create Target Group


resource "aws_lb_target_group" "terraform_lb_tg" {
  port        = 80
  protocol    = "TCP"
  vpc_id      = aws_vpc.terraform_vpc.id
  target_type = "instance"

  health_check {
    port     = "80"
    protocol = "TCP"
  }
  name = "${var.company_name}-${var.project_name}-${var.enviroment}-tg"
}

aws_lb_target_group

  • AWS 내 Target Group을 생성하는 명령어입니다.

target_type

  • Target의 대상을 설정해줍니다. (instance(default)/ip/lambda)

 

Create Listener


resource "aws_lb_listener" "terraform_lb_Listener" {
  load_balancer_arn = aws_lb.terraform_nlb.arn
  port              = 80
  protocol          = "TCP"

  default_action {
    target_group_arn = aws_lb_target_group.terraform_lb_tg.arn
    type             = "forward"
  }
}

aws_lb_listener

  • AWS 내 LB Listener 생성하는 명령어입니다.

Listerner란

  • 로드 밸런서가 등록된 대상으로 요청을 라우팅하는 방법을 결정하는 역할을 합니다.

default_action

  • 기본 작업에 대한 구성 블록입니다.

type

  • 라우팅 작업의 유형입니다.

forward

  • 받아들인 트래픽을 target group으로 전달하라는 명령어입니다.

 

Attatch Loadbalancer to AutoScaling Group


resource "aws_autoscaling_attachment" "name" {
  utoscaling_group_name = aws_autoscaling_group.terraform_asg.id
  alb_target_group_arn  = aws_lb_target_group.terraform_lb_tg.arn

}

  • 생성한 asg과 lb를 연결시킵니다.

 

 

Troubleshooting

  • apply 를하고 destory를 진행하지 않아 생김
  • destory → apply 시 해결

  • key-pair 생성 후 커멘드창에서 aws로 전송하는 작업을 진행하였음
  • 테라폼에서 전송해주므로 따로 aws를 전송할 필요는 없었음
반응형
LIST

'Clould > Terraform' 카테고리의 다른 글

Terraform 실습 #2  (0) 2022.07.28
Terraform 실습 #1  (0) 2022.07.28
Terraform 설치  (0) 2022.07.28
반응형
SMALL

Create Internet Gateway


resource "aws_internet_gateway" "terraform_igw" {
  vpc_id = aws_vpc.terraform_vpc.id
  tags = {
    Name = "${var.company_name}-${var.project_name}-${var.environmet}-igw"
  }
}

resource

  • aws_internet_gateway AWS 내 IGW를 생성하기 위한 명령어입니다.

vpc_id

  • Attatch할 VPC 값을 적어줍니다.

tags

  • internet gateway 이름 지정합니다.

 

Create EIP for NAT


resource "aws_eip" "terraform_ngw_eip" {
  vpc = true
  tags = {
    Name = "${var.company_name}-${var.project_name}-${var.enviroment}-ngw-eip"
  }
}

NAT 게이트웨이를 생성하려면 EIP가 필요하다.

resource

  • aws_eip AWS 내 Elastic IP를 생성하기 위한 명령어입니다.

vpc = true

  • 생성 된 EIP가 VPC의 내부에서 실행된다는 명령어입니다.

tags

  • eip 이름입니다.

 

Create NAT Gateway


resource "aws_nat_gateway" "terraform_ngw" {
  allocation_id = aws_eip.terraform_ngw_eip.id
  subnet_id     = aws_subent.terraform_public_subnet.0.id
  tags = {
    Name = "${var.company_name}-${var.project_name}-${var.environment}-ngw"
  }
}

resource

  • aws_nat_gateway AWS 내 NAT G/W를 생성하기 위한 명령어입니다.

allocation_id

  • 게이트웨이에 대한 탄력적 IP 주소의 ID입니다.
  • 위에서 생성했던 eip를 nat에 할당합니다.

subnet_id

  • NAT가 위치 할 서브넷 지정합니다.
  • ‘0’은 첫 번째 서브넷 값을 뜻합니다.

tags

  • NAT 게이트웨이 이름입니다.

 

Create Route Table


resource "aws_route_table" "terraform_public_route_table" {
  vpc_id = aws_vpc.terraform_vpc.id
  route = [{
    cidr_block = "0.0.0.0/0"
    gateway_id = "aws_internet_gateway.terrform.igw.id"
  }]
  tags = {
    Name = "${var.company_name}-${var.project_name}-${var.environment}-pub-rt"
  }
}

resource "aws_route_table" "terraform_private_route_table" {
  vpc_id = aws.vpc.terrform_vpc.id
  route = [{
    cidr_block = "0.0.0.0/0"
    gateway_id = "aws_internet_gateway.terrform.ngw.id"
  }]
  tags = {
    Name = "${var.company_name}-${var.project_name}-${var.environment}-pri-rt"
  }

}

resource

  • aws_route_table AWS 내 RT를 생성하기 위한 명령어입니다.

vpc_id

  • 참조할 vpc 지정합니다.

route

  • Public은 IGW를 대상으로,
  • Private 은 NGW를 대상으로 0.0.0.0/0 오픈해줍니다.

 

Associate Subnets to Route Tables


resource "aws_route_table_association" "terraform_public_subnet_association" {
  count          = length(var.aws_public_subnets)
  subnet_id      = aws_subnet.terraform_public_subnet.*.id[count.index]
  route_table_id = aws_route_talbe.terraform_public_route_table.id
}

resource "aws_route_table_association" "terraform_private_subnet_association" {
  count          = length(var.aws_private_subnets)
  subnet_id      = aws_subnet.terraform_private_subnet.*.id[count.index]
  route_table_id = aws_route_table.terraform_private_route_table.id
}

resource

  • aws_route_table_association AWS 내 Route table을 Subnet과 연결 시켜주는 명령어입니다.

subnet_id

  • 연결할 서브넷 지정합니다

*

  • 모든 Pub/Pri 서브넷에 대한 index 값을 가져옵니다.

route_table_id

  • 연결할 라우팅 테이블 지정합니다

 

Create bastion Security Group


resource "aws_security_group" "terraform_bastion_sg" {
  vpc_id = aws_vpc.terraform_vpc.id
  name   = "${var.company_name}-${var.project_name}-${var.environment}-bastion-sg"
  ingress = [{
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"] #관리자의 ip를 작성합니다.
  }]

  egress = [{
    from_port   = 0
    to_port     = 0
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }]
}

resource

  • "aws_security_group" AWS 내 Security Group을 생성하는 명령어입니다.

vpc_id

  • 참조할 vpc 지정합니다

ingress

  • 관리자가 22번 port로 접속이 가능합니다.

egress

  • 아웃바운드는 0.0.0.0/0이 기본 값입니다.

from_port / to_port

  • Port의 범위를 나타냅니다. (’0’은 모든 트래픽을 뜻합니다.)

 

Create Security Group


resource "aws_security_group" "terraform" {
  vpc_id = aws_vpc.terraform_vpc.id
  name   = "${var.company_name}-${var.project_name}-${var.environment}-asg-sg"
  ingress {
    from_port       = 80
    to_port         = 80
    protocol        = "tcp"
    security_groups = [aws_security_group.terraform_lb_sg.id]
  }
  ingress {
    from_port       = 22
    to_port         = 22
    protocol        = "tcp"
    security_groups = [aws_security_group.terraform_bastion_sg.id]
  }

  egress = [{
    from_port  = 0
    to_port    = 0
    protocol   = "tcp"
    cidr_block = ["0.0.0.0/0"]
  }]
}

ingress

  • Bastion의 22번 포트와 private 인스턴스의 80포트를 인바운드에 추가해줍니다.

egress

  • 아웃바운드는 0.0.0.0/0이 기본 값입니다.

 

Create Load Balancer Security Group


resource "aws_security_group" "terraform_lb_sg" {
    vpc_id = "${aws_vpc.terraform_vpc.id}"
    nmae = "${var.company_name}-${var.project_name}-${var.environment}-lb-sg"
    ingress {
      from_port = 80
      to_port = 80
      protocol = "tcp"
      cidr_blocks = ["0.0.0.0/0"]
    }

    egress {
      from_port = 0
      to_port = 0
      protocol = "tcp"
      cidr_blocks = ["0.0.0.0/0"]
    }  
}

ingress

  • LB는 IGW에서 트래픽을 받기 때문에 80포트를 열어줍니다.

egress

  • 아웃바운드는 0.0.0.0/0이 기본 값입니다.

 

Create Key-pair


resource "aws_key_pair" "aws_ec2_key" {
  key_name   = "pri-ec2-key"
  public_key = file("~/.ssh/pri-ec2.pub")
}

resource "aws_key_pair" "aws_bastion_key" {
  key_name   = "bastion-key"
  public_key = file("~/.ssh/bastion.pub")
}

aws_key_pair

  • AWS 내 Key를 생성해주는 명령어입니다
  • 키를 미리 생성한 후 생성한 키를 AWS로 복사합니다.
  • PEM Key 생성 명령어→ .ssh 디렉토리에서 확인 가능
  • ssh-keygen -m PEM -f .ssh\[키이름] -q -N “”
  • → .ssh 디렉토리에서 확인 가능

key_name

  • key pair 이름입니다.

public_key

  • 사용할 public key입니다.
반응형
LIST

'Clould > Terraform' 카테고리의 다른 글

Terraform 실습 #3  (0) 2022.07.28
Terraform 실습 #1  (0) 2022.07.28
Terraform 설치  (0) 2022.07.28
반응형
SMALL

1. Architecture


 

2. variables.tf


  • 인프라 생성 전에 입력받는 값으로서 테라폼에서 통칭되는 파일 명입니다. 그렇기 때문에, 메인tf 파일에서 variables.tf 파일에 대한 선언을 따로 하지 않아도 var이라는 명령어를 통해 variables.tf 파일을 자동으로 불러오게 됩니다.
# variable "declarations

variable "company_name" {
  description = "Name of the company"
  type        = string
  default     = "emart"
}

variable "project_name" {
  description = "Name of the project"
  type        = string
  default     = "aiml"
}

variable "environment" {
  description = "Name of the environment"
  type        = string
  default     = "prd"
}

variable "aws_region" {
  description = "AWS region"
  type        = string
  default     = "ap-northeast-2"
}

variable "profile_name" {
  description = "CLI Profile Name"
  type        = string
  default     = "default"
}

variable "aws_public_subnets" {
  default = ["10.224.224.0/25", "10.224.224.128/25"]
}
variable "aws_private_subnets" {
  default = ["10.224.225.0/25", "10.224.225.128/25"]

}

variable "aws_azs" {
  default = ["ap-northeast-2a", "ap-northeast-2c"]
}

variable "zone" {
  default = ["a", "c"]
}

 

3. aws_network.tf


CSP setup

# CSP setup
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 4.14.0"
    }
  }
  required_version = ">= 1.0"
}

source = “hashicorp/aws”

  • Lifecycle management of AWS resources, including EC2, Lambda, EKS, ECS, VPC, S3, RDS, DynamoDB, and more. This provider is maintained internally by the HashiCorp AWS Provider team.

version = "~> 4.14.0”

  • Terraform용 AWS 공급자 버전입니다. 버전 3.0.0 이상은 Terraform 0.12 이상에만 자동으로 설치가 가능합니다. 현재는 4.14.0까지 나와 있습니다.

required_version = ">= 1.0”

  • 1.0은 테라폼의 버전입니다. 현재는 1.1.9까지 나와 있습니다.

💡 테라폼의 버전과 프로바이더의 두 버전이 따로 관리되기 때문에 따로 출력됩니다.

 

 

Profile setup


# profile setup(alternate with sso profile)
provider "aws" {
  region  = var.aws_region
  profile = var.profile_name
}

region = var.aws_region

  • variables.tf 파일에서 aws_region 값을 가져옵니다.

profile = var.profile_name

  • variables.tf 파일에서 profile_name 값을 가져오게 되는데 variables 파일에는 CLI에서 설정한 기본값을 가져오게 되어 있으므로 default로 설정해 놓은 profile로 접속하게 됩니다.

Create VPC


# Create VPC
resource "aws_vpc" "terraform_vpc" {
  cidr_block       = "10.224.224.0/21"
  instance_tenancy = "default"
  tags = {
    Name = "${var.company_name}-${var.project_name}-${var.environment}-vpc"
  }
}

aws_vpc

  • AWS 내 VPC를 생성하는 명령어입니다.
  • aws_vpc로 정하고 terraform에서 정의하는 이름으로 terraform_vpc로 정해줍니다.
  • 이 이름은 aws에서 사용되는 이름이 아니고 테라폼 내부에서 참조하기 위한 이름입니다.

cidr_block

  • VPC가 사용하는 IP대역이며, Subnet의 CIDR 값보다 큰 값이어야 함

instance_tenancy = "default"

  • 호스트에서 인스턴스를 공유합니다. →여러 AWS 계정이 동일한 물리적 하드웨어를 공유할 수 있습니다.

instance_tenancy = "dedicated"

  • 인스턴스가 단일 테넌트 하드웨어에서 실행됩니다.

Profile setup


# profile setup(alternate with sso profile)
provider "aws" {
  region  = var.aws_region
  profile = var.profile_name
}

region = var.aws_region

  • variables.tf 파일에서 aws_region 값을 가져옵니다.

profile = var.profile_name

  • variables.tf 파일에서 profile_name 값을 가져오게 되는데 variables 파일에는 CLI에서 설정한 기본값을 가져오게 되어 있으므로 default로 설정해 놓은 profile로 접속하게 됩니다.

 

Create VPC


# Create VPC
resource "aws_vpc" "terraform_vpc" {
  cidr_block       = "10.224.224.0/21"
  instance_tenancy = "default"
  tags = {
    Name = "${var.company_name}-${var.project_name}-${var.environment}-vpc"
  }
}

aws_vpc

  • AWS 내 VPC를 생성하는 명령어입니다.
  • aws_vpc로 정하고 terraform에서 정의하는 이름으로 terraform_vpc로 정해줍니다.
  • 이 이름은 aws에서 사용되는 이름이 아니고 테라폼 내부에서 참조하기 위한 이름입니다.

cidr_block

  • VPC가 사용하는 IP대역이며, Subnet의 CIDR 값보다 큰 값이어야 함

instance_tenancy = "default"

  • 호스트에서 인스턴스를 공유합니다. →여러 AWS 계정이 동일한 물리적 하드웨어를 공유할 수 있습니다.

instance_tenancy = "dedicated"

  • 인스턴스가 단일 테넌트 하드웨어에서 실행됩니다.

 

Create Subnet


resource "aws_subnet" "terraform_public_subnet" {
  count                   = length(var.aws_public_subnets)
  vpc_id                  = aws_vpc.terraform_vpc.id
  cidr_block              = var.aws_public_subnets[count.index]
  availability_zone       = var.aws_azs[count.index]
  map_public_ip_on_launch = true
  tags = {
    Name = "${var.company_name}-${var.project_name}-${var.environment}-pub-${var.zone[count.index]}-sbn"
  }
}

resource "aws_subnet" "terraform_private_subnet" {
  count                   = length(var.aws_private_subnets)
  vpc_id                  = aws_vpc.terraform_vpc.id
  cidr_block              = var.aws_private_subnets[count.index]
  availability_zone       = var.aws_azs[count.index]
  map_public_ip_on_launch = false
  tags = {
    Name = "${var.company_name}-${var.project_name}-${var.environment}-pri-${var.zone[count.index]}-sbn"

  }
}

resource

  • aws_subnet AWS 내 서브넷을 생성하는 명령어입니다.

count

  • variables.tf 파일에서 서브넷의 갯수를 가져오는 명령어입니다.
  • count란?
  • #count =3 for i := 0; i < 3; i++ { resource "aws_subnet" "terraform_public_subnet" { ... } }

cidr_block

  • 생성한 VPC CIDR 값에 속하는 IP로 구성해야 합니다.

availability_zone

  • variables.tf 파일에 선언 해놓은 가용 영역에 대한 값을 가져옵니다.

map_public_ip_on_launch = true

  • 해당 서브넷에 생성된 인스턴스에 퍼블릭 IP 주소 할당작성하지 않을 시 자동 적용되는 값(default)은 map_public_ip_on_launch = false입니다.

tags

  • subnet 이름 지정합니다.
반응형
LIST

'Clould > Terraform' 카테고리의 다른 글

Terraform 실습 #3  (0) 2022.07.28
Terraform 실습 #2  (0) 2022.07.28
Terraform 설치  (0) 2022.07.28
반응형
SMALL

Terraform이란 무엇인가

  • Terraform은 하시코프에서 만든 IaC 도구, 특히 인프라 선언 도구이다.
  • Terraform은 안전하고 반복적으로 작업하더라도 인프라스트럭처를 구축, 변경할 수 있게 도와준다.
  • 간혹 Ansible이나 Puppet과 같이 비교가 되곤 하는데, 엄밀히 말해서 Ansible과 Puppet은 설정 관리 도구로써 Terraform과는 다른 성격의 도구임을 분명히 알아두는 것이 좋다.

 

IaC와 Terraform


 

  • IaC란, Infrastructure As Code의 약자로써, 코드로 인프라를 관리하는 것을 말한다.
  • 여기서 IaC가 관리하는 것은, 인프라를 이루는 서버, 미들웨어, 서비스 등 인프라를 구성하는 모든 요소들이 그 대상이다. 또한 IaC도구는 크게 다음으로 분류된다.

  • 서버 템플릿(Image Build) 예) Packer, Docker
  • 컨테이너 오케스트레이션(Container Orchestration) ex) Kubernetes, Apache Mesos
  • 서버 설정 관리(Configuration Management) ex) Ansible, Puppet, Chef
  • 인프라 선언(Infrastructure Provisioning) ex) Terraform, AWS CloudFormation
  • Terraform0.x 버전임에도 불구하고 인프라 선언 도구 분야에서 표준으로 자리 잡았다.
  • HCL이라는 도메인 특화 언어를 통해서 쉽고 일관되게 AWSGCP 등의 퍼블릭 클라우드는 물론 여러 프로바이더의 원하는 인프라 구성을 자동화할 수 있다.

 

Terraform의 장점


Terraform의 장점은 다음과 같다.

  1. 코드로써 인프라를 관리하기 때문에, 생산성, 재사용성이 높아지며, 유지보수에 용이하다.
  2. Git과 같은 VCS를 함께 쓰면 작업 이력이 남기 때문에, 문제 원인 파악이 보다 쉽다.
  3. 업계 표준이기 때문에 예제가 풍부하여 배우기 쉽다.

 

Terraform의 구성 요소


Terraform의 구성 요소는 크게 다음과 같다.

  • provider : 테라폼으로 관리할 인프라의 종류를 의미 (ex) AWS, GCP, Azure ...)
  • resource : 테라폼으로 관리할 인프라 자원을 의미 (ex) EC2, IAM, S3, RDS ...)
  • state : 테라폼을 통해 생성된 리소스들의 상태를 의미. (= 테라폼 apply 명령어를 실행한 결과물)
  • output : 테라폼으로 만든 리소스를 변수 형태로 state에 저장하는 것을 의미
  • module : 공통적으로 활용할 수 있는 모듈을 정의하는 것을 의미
  • remote : 다른 경로의 state를 참조하는 것을 의미하며, output 변수를 불러올 때 주로 사용

 

Terraform 설치

테라폼 설치하기

각 컴퓨터에 맞는 OS로 테라폼을 설치합니다.

Downloads | Terraform by HashiCorp

 

Downloads | Terraform by HashiCorp

Terraform is an open-source infrastructure as code software tool that enables you to safely and predictably create, change, and improve infrastructure.

www.terraform.io

테라폼 CLI 다운로드

[ED01-02] Terraform 설치하기 - CLI 다운로드

 

[ED01-02] Terraform 설치하기 - CLI 다운로드

 2021-04-28 작성완료 개요 본 강의에서는 Terraform 설치방법에 대해 알아보고 실습을 진행해 보도록 하겠습니다. 현재 Terraform 사용가능한 운영체제(OS)는 다음과 같습니다. Linux Solaris Windows Mac OS F..

frostflower-note.tistory.com

Amazon CLI 다운로드

최신 버전의 AWS CLI 설치 또는 업데이트

 

최신 버전의 AWS CLI 설치 또는 업데이트 - AWS Command Line Interface

설치 관리자의 아무 위치에서나 Cmd+L을 눌러 설치에 대한 디버그 로그를 볼 수 있습니다. 이렇게 하면 로그를 필터링하고 저장할 수 있는 로그 창이 열립니다. 로그 파일도 /var/log/install.log에 자

docs.aws.amazon.com

vsCode 설치하기

Documentation for Visual Studio Code

 

Documentation for Visual Studio Code

Find out how to set-up and get the most from Visual Studio Code. Optimized for building and debugging modern web and cloud applications. Visual Studio Code is free and available on your favorite platform - Linux, macOS, and Windows.

code.visualstudio.com

 

Visual Studio Code를 테라폼 추가도구

vsCode를 설치한후 플러그인에서 HashiCorp Terraform 을 설치해줍니다. 테라폼 작업에 용이합니다.

 

 

테라폼 실행

[윈도우 CMD] → terraform 입력

 

테라폼 버전 확인하기

버전을 확인하여 제대로 설치가 되었는지 확인합니다.

$ terraform -version

 

AWS 프로파일 설정하기

테라폼이 리소스를 배포할 계정과 리전을 선택합니다.

$ aws configuration

>> Account ID :
>> Secret Access Key :
>> Region : 
>> file format : → 엔터쳐도 됨

 

Terraform 명령어

$ terraform init

: Terraform을 사용하기 위해, 설정한 provider 나 module 등을 download 받는 initialize 동작을 수행합니다.

 

$ terraform plan

: 정의한 코드가 어떤 인프라를 만들게 되는지 미리 예측 결과를 보여줍니다. → Plan 명령어는 어떠한 형상에도 변화를 주지 않습니다.

 

$ terraform apply

: 실제로 인프라를 배포하기 위한 명령어입니다.

→ 해당 결과는 local의 .terraform 파일에도 저장됩니다.

 

$ terraform destroy

: terraform 으로 생성된 insrastructure resource 들을 모두 제거하고 싶을 때 사용하는 명령어입니다.

 

반응형
LIST

'Clould > Terraform' 카테고리의 다른 글

Terraform 실습 #3  (0) 2022.07.28
Terraform 실습 #2  (0) 2022.07.28
Terraform 실습 #1  (0) 2022.07.28
반응형
SMALL

13. Web 서버


  • 앞서 생성했던 Bastion Host를 통해 Private Subnet에 ssh로 접속해 Web 서버를 설치해주도록 하자.
  • Web 서버를 설치한 뒤에는 EX-ELB를 통해 로드밸런스 테스트까지 해준다.
  • 다음 작업은 Web1과 Web2 모두 동일하게 진행해주도록 하자.

13-1 Private Web 서버 접속

  • Private의 접속하기 위해서는 ".pem" 키 파일을 이용한 ssh로 접속해 주도록 하자

13-2 sudo yum -y install httpd 명령어를 통해서 Web서버인 아파치를 설치해주자

13-3 설치가 되었으면 다음과 같은 명령어를 입력해주자.

sudo systemctl start httpd    // httpd 실행

sudo systemctl enable httpd     // 재부팅 되어도 실행 지속

sudo systemctl status httpd         // httpd 상태 확인

13-4. 다음과 같은 디렉터리로 이동해준 뒤, 로그를 통해 패킷을 확인해보자

cd /etc/httpd/conf
cd /var/log/httpd
tail -f access_log

13-5. Web 서버 확인을 위해 Html파일로 테스트 페이지를 작성해주자.

  • /var/www/html 디렉터리로 이동해준뒤 <파일명>.html 으로 테스트 페이지를 작성해준다.

(Web2서버에서는 테스트 페이지 작성할 때, 로드밸런스 확인할 수 있게 Web1과는 다른 내용으로 작성해주자. )

  • 테스트 페이지 작성 후, systemctl restart httpd 명령어로 아파치를 재실행 해주자.
  • 테스트 페이지를 작성해도 현재 Web서버는 Private 이라서 확인해 볼 수가 없다.
  • 확인하기 위해서는 외부 로드밸런서를 이용해 보도록 하자.

13-6. 앞에서 생성했던 EX-ELB를 통해 Web서버가 제대로 동작하는지 확인해준다.

  • EX-ELB의 DNS name을 통해 접속 가능하다. 주소창에 입력해보자.

13-7. EX-ELB 하나의 주소로 새로고침 할 때마다, 웹페이지가 다르게 보여지는걸 확인할 수 있다.

  • 웹서버와 로드밸런서가 제대로 동작중인 것을 확인해주자.

 

14. 웹 애플리케이션 서버 (WAS) 설치


  • 앞서 생성했던 Bastion Host를 통해 Private Subnet에 ssh로 접속해  WAS 를 설치해주도록 하자.
  • WAS를 설치한 뒤에는 IN-ELB를 통해 로드밸런스 테스트까지 해준다.
  • 다음 작업은 WAS1과 WAS2 모두 동일하게 진행해주도록 하자.

14-1. Private WAS 서버 접속

  • Private의 접속하기 위해서는 ".pem" 키 파일을 이용한 ssh로 접속해 주도록 하자

14-2. WAS 서버인 Tomcat을 설치해주기 전에는 Java가 필요하다.

  • Java가 설치 되어있는지 확인해주자.

14-3. 자바가 설치되어 있지 않아서 설치해주도록 한다.

  • yum 명령어를 통해 설치해주도록 하자.
  • sudo yum install -y java-1.8.0-openjdk.x86_64

14-4. Java가 설치가 되었다면 다음으로 WAS 서버에 Tomcat을 설치해주자

  • Tomcat 홈페이지에서 사용하려는 Tomcat의 버전의 링크를 가져와 wget을 통해 설치해주자

tomcat.apache.org/download-10.cgi

 

Apache Tomcat® - Apache Tomcat 10 Software Downloads

Welcome to the Apache Tomcat® 10.x software download page. This page provides download links for obtaining the latest version of Tomcat 10.0.x software, as well as links to the archives of older releases. Unsure which version you need? Specification versi

tomcat.apache.org

14-5. Tomcat이 설치되어 있는것을 확인해주고

  • sudo tar xzf apache-tomcat-10.0.20.tar.gz 명령어를 통해 압축을 풀어주도록 하자.

14-6. 압축 해제된 Tomcat의 폴더로 이동한 후, sudo ./bin/startup.sh 명령어를 통해 톰캣을 실행 시켜주자.

14-7. 설치했던 tomcat의 디렉터리 안에  logs 디렉터리로 이동해주고,

  • tail -f localhost_access_log.2021-02-21.txt  가장 최근의 로그파일이 생성되어있다.
  • 로그를 확인해보자

14-8. WAS 서버 확인을 위해 JSP 파일로 테스트 페이지를 작성해주자.

  • /Tomcat/webapps/ROOT 디렉터리로 이동해준뒤 <파일명>.jsp 으로 테스트 페이지를 작성해준다.
  • (WAS2 서버에서는 테스트 페이지 작성할 때, 로드밸런스 확인할 수 있게 WAS1과는 다른 내용으로 작성해주자. )

14-9. ./shutdown.sh 명령어로 Tomcat을 종료했다가, 다시 시작해주자

14-10. WAS 서버가 타겟으로 등록된 IN-ELB의 상태가 healthy인지 확인해주자.

14-11.Web 서버와 WAS 서버를 연결해주는 작업이 별도로 필요하다. Apache 설치 시 같이 설치되는 mod_proxy 모듈을 이용해서 두 서버를 연결해주도록 하자.

  • WAS 서버가 설치되었고 로드밸런서도 작동중이지만,
  • 현재는 Web과 WAS가 연결되어 있지 않은 상태이기 때문에, EX-ELB를 타고 들어왔던 트래픽이 Web에서 WAS로 전달 불가능하다.
  • cd /etc/httpd/conf/httpd.conf 파일을 열어서
  • Include conf.modules.d/*.conf 구문 밑에 다음과 같이 추가해주자.

LoadModule proxy_connect_module modules/mod_proxy_connext.so

LoadModule proxy_module modules/mod_proxy.so

LoadModule proxy_http_module modules/mod_proxy_http.so

14-12. 그 후, 파일 맨 끝에 다음과 같은 구문을 작성해주자.

  • Web에서 받은 트래픽을 IN-ELB:8080으로 넘겨주는 작업

14-13. 파일 내용이 적용 될 수 있도록 Apache를 재실행 해주자

14-14. Web과 WAS가 제대로 연결되었다면, EX-ELB의 DNS Name/<파일명>.jsp 를 통해 접속하면 다음과 같이 로드밸런서가 작동되는 WAS 서버 테스트 페이지를 확인할 수 있다.

  • 새로고침 할 때마다 WAS1, WAS2 가 계속 바뀌는 것과 현재 시간 데이터를 받아올 수 있다.

 

15. WAS와 DB 연동


  • WAS와 DB를 연결하려면 WEB과 연결할 때 처럼 별도의 연결모듈이 필요하다.

mvnrepository.com/artifact/mysql/mysql-connector-java/8.0.23

  • 위의 링크에서 mysql-connector-java/8.0.23.jar 파일을 다운받아 주었다.

15-1. /tomcat/lib 디렉터리에 mysql-connector-java.8.0.23.jar 파일을 넣어주도록 하자

15-2. DB 연동 확인을 위해 JSP 파일로 새로 테스트 페이지를 작성해주자.

  • /Tomcat/webapps/ROOT 디렉터리로 이동해준뒤 <파일명>.jsp 으로 테스트 페이지를 작성해준다
  • String Url="jdbc:mysql://DB의 Endpoint/DB명";
  • String Id="DB사용자명";
  • String Pass="패스워드";

 

15-3. 위의 모든 준비를 마쳤으면, EX-ELB의 DNS Name/<파일명>.jsp 를 통해 DB와 연동된 jsp 테스트 페이지를 확인해보자

15-4. RDS DB 인스턴스는 Multi AZ를 사용해서 Active - Stand by 형태로 이중화 구성을 해준다.

  • 평소에는 ap-northeast-2a 영역을 Master DB로 사용하다가 장애 발생 시, 대기 상태였던 ap-northeast-2c 가 자동으로 Master로 승격되어 작업을 계속 수행하도록 한다.
  • Multi AZ는 동기식으로 복제되기 때문에, 데이터를 유지한 채 지속적인 작업을 수행할 수 있다.
반응형
LIST

'Clould > Amazon Web Service' 카테고리의 다른 글

[AWS] 3-Teir Architecture 실습 #3  (0) 2022.07.28
[AWS] 3-Teir Architecture 실습 #2  (0) 2022.07.27
[AWS] 3-Teir Architecture 실습 #1  (0) 2022.07.27
[AWS] 3-Teir Architecture 그리기  (0) 2022.07.27
[AWS] 3-Tier 란?  (0) 2022.07.27
반응형
SMALL

11. ELB 생성 (ALB)


11-1. External ELB 생성 (ALB)

💡 External ELB는 IGW로부터 들어온 트래픽들을 Web1, Web2로 분산해준다.

  • EX-ELB는 인터넷에 연결하고, HTTP 80번 포트를 이용해 연결 요청을 확인한다.

11-2. 각 가용영역의 Public 서브넷에 위치하도록 한다.

11-3. EX-ELB의 보안그룹은 HTTP 80번 포트에서 오는 모든 트래픽을 허용해 주도록 설정한 EX-ELB를 선택해주자.

11-4. ELB를 통해 들어온 트래픽들은 각각 web1, web2로 보내주도록 하자

11-5. ELB가 생성되었으면 타겟그룹에서 연결된 인스턴스들의 상태가 healthy인지 확인해주자.

11-6. Internal ELB 생성 (ALB)

 💡 IN-ELB는 web을 통해 들어온 트래픽들을 was1, was2로 분산해서 보내주는 역할을 한다.

  • EX-ELB 생성할 때와는 다르게 internal로 체크해주자.

11-7. IN-ELB는 WAS에 위치하도록 해주자

11-8.  IN-ELB는 web을 통과한 트래픽들만 허용해주자

11-9. IN-ELB는 8080를 타고 다음 타겟을 찾아가도록 해주자.

11-10. IN-ELB를 통해 들어온 트래픽은 각각 was1, was2로 보내주도록 하자

11-11. 생성된 IN-ELB의 대상 인스턴스의 상태가 healthy인지 확인해주자.

 

 

12. RDS 생성


 💡 3티어 아키텍처에서 데이터베이스 계층을 담당하는 부분이다.

 

  • RDS DB 인스턴스를 생성해 DB를 관리해주도록 하자

12-1. 서브넷 그룹 생성

  • RDS를 생성하기 전에 먼저 서브넷 그룹을 생성해주자.

12-2. RDS DB 인스턴스 생성

17. [AWS] RDS에 대해서 알아보자

12-3. AWS Console에서 RDS로 들어와서, 'Create database'를 눌러 DB 인스턴스를 생성해주자.

12-4. 직접 세부 설정해 줄 것이기 때문에 Standard Create 체크하고, DB 엔진으로는 사용하기 쉬운 MySQL를 선택해주자

12-5. MySQL의 버젼은 8.0.20 으로 선택해주었다. DB 인스턴스는 프리티어로 만들어 주도록 하자

12-6. DB 인스턴스의 이름을 정해주고, Master의 이름과 패스워드 설정을 해주자.

12-7. DB 인스턴스에 사용할 VPC와 서브넷 그룹을 선택해주자.

12-8. VPC 보안그룹과 가용영역을 설정해주고 MySQL의 포트인 3306을 지정해주자

12-9. 다른 설정들은 기본값으로 해준뒤 potato라는 이름의 DB 인스턴스를 생성해주었다.

  • 현재 상태가 Creating 이라서 Endpoint가 나타나지 않는다. 완전히 생성되려면 시간이 좀 걸리기 때문에 느긋하게 기다려주자.

12-10. 현재 상태가 Available로 변하면서 Endpoint 주소가 나타났다. 이후에 Endpoint 주소를 통해 DB에 접속하면 된다.

12-11. Security Group - 인바운드 규칙에서 MySQL의 포트를 허용해주자.

12-12. 생성했던 DB 인스턴스의 Endpoint 주소와 패스워드로 EC2에서 접속해 보았다.

12-13 RDS DB 인스턴스 구성

  • 다음과 같이 RDS DB인스턴스를 생성해 주도록 하자
DB Engine MySQL 8.0.20
DB 사이즈 t2.micro
DB 인스턴스 식별자 db
데이터베이스 이름 db
Master 이름 admin
passwd 생성 시 설정해둔 것 기억.
Mulil-AZ 사용
서브넷 그룹 위에 생성해준 db-subnet group

12-14 RDS 보안그룹

  • RDS의 보안그룹 설정은 다음과 같이 3306 포트를 열어주도록 하자
  • Source는 WAS를 바라보게끔 해서 WAS를 통해 들어온 트래픽만 접근할 수 있다.

반응형
LIST

'Clould > Amazon Web Service' 카테고리의 다른 글

[AWS] 3-Teir Architecture 실습 #4  (0) 2022.07.28
[AWS] 3-Teir Architecture 실습 #2  (0) 2022.07.27
[AWS] 3-Teir Architecture 실습 #1  (0) 2022.07.27
[AWS] 3-Teir Architecture 그리기  (0) 2022.07.27
[AWS] 3-Tier 란?  (0) 2022.07.27
반응형
SMALL

7. 라우팅 테이블 생성


  • 네트워크 통신이 이루어질 때, 데이터들은 라우터를 거쳐가게 된다. 라우터는 해당 데이터들의 경로를 지정해주는 역할을 하고, 경로들을 라우팅 테이블에 저장시킨다.
  • 데이터들은 라우팅 테이블의 저장되어 있는 경로를 따라 원하는 목적지를 찾아가게 된다.

 

7-1. 퍼블릭 서브넷용 라우팅 테이블을 생성하고 모든 트래픽은 인터넷 게이트를 통해 외부와 연결할 수 있게 한다.

7-2. 2개의 퍼블릭 서브넷과 연결시켜 퍼블릭 서브넷들의 경로를 지정해준다.

7-3. 마찬가지로, 프라이빗 서브넷들은 모든 트래픽은 NAT 게이트웨이로 향하는 경로를 지정해준다.

7-4. 6개의 프라이빗 서브넷과 연결시켜 프라이빗 서브넷들의 경로를 정해주자.

 

8. 보안그룹 생성


  • 보안그룹은 AWS 인스턴스에 접근하거나, 인스턴스가 접근하려고 하는 패킷을 포트번호로 제어하기 위한 설정이다.
  • 인바운드, 아웃바운드 규칙을 통해 어느 포트를 허용/차단할지를 정한다.
  • 인바운드 규칙 - 기본 규칙은 모든 트래픽에 대해서 차단한다. 허용해 줄 포트만 열어주는 Whitelist 방식
  • 아웃바운드 규칙 - 기본 규칙은 모든 트래픽에 대해서 허용한다. 차단해 줄 포트만 닫아주는 Blacklist 방식
  • 이 아키텍처에서는 다음과 같이 보안그룹을 생성해준다.
이름  타입  포트  대상
Bastion SSH 22 0.0.0.0/0
EX-ELB HTTP 80 0.0.0.0/0
WEB SSH,HTTP 22,80 Bastion, 0.0.0.0/0
IN-ELB HTTP 80 WEB
WAS SSH,HTTP 22,8080 Bastion, IN-ELB
DB MySQL 3306 WAS

Bastion - 22 - SSH - 모든 ip에서 접속 가능
EX-ELB - 80 - HTTP - 모든 ip에서 접속 가능
WEB - 80 - HTTP - 모든 ip에서 접속 가능
IN-ELB - 8080 - HTTP - WEB을 통과한 ip만 접속 가능
WAS - 8080 - HTTP - IN-ELB를 통과한 ip만 접속 가능
DB - 3306 - MySQL - WAS를 통과한 ip만 접속 가능
80 - Apache 포트번호
8080 - Tomcat 포트번호
22 - SSH 포트번호
3306 - MySQL 포트번호

 

9. EC2 인스턴스 생성


  • Private 서브넷에 WEB, WAS를 설치해줄 EC2 인스턴스를 생성해 주어야 한다.
  • 하지만 Private 서브넷에 위치한 EC2 인스턴스들은 외부에서 접근할 수가 없다. 그래서 Bastion Host를 통해서 ssh접속을 해서 외부접근이 가능하도록 해주자

💡 Bastion Host?

  • Bastion Host란 Private 환경에 접근하기 위해 Proxy 역할을 해주는 서버이다.
  • Private 서브넷에 위치한 EC2 인스턴스들은 외부에서 접근할 수가 없기 때문에, 관리자는 Bastion Host를 통해 SSH 접속을 할 수 있다.
  • Bastion Host를 통해서만 인스턴스로 접근할 수 있기 때문에, 보안성을 높일 수 있고, Bastion Host의 log만 관리하면 Private 서브넷에 접속하는 모든 기록을 관리할 수 있다.
  • 반대로, Bastion Host가 공격당하면 Private 네트워크가 모두 노출되므로, Bastion Host를 철저히 관리해주자. 

 

10. Bastion Host 생성


  • 만들어 두었던 VPC안에 Bastion Host를 생성해주자.
  • Bastion Host는 Public subnet에 위치하고 Public IP를 할당해 줌으로써, 외부에서 ssh를 통해 접근할 수 있도록 해주자.

10-1. Public Subnet에 위치하고, Elastic IP를 할당해주어 외부에서 ssh접근을 통해 접속할 수 있도록 Bastion Host를 생성해준다.

10-2. Bastion Host의 인바운드 규칙을 모든 트래픽에서 접근할 수 있도록 0.0.0.0/0 을 주었다.

(실제로 웹서버를 관리할 때는 관리자의 고유IP만 접근할 수 있도록 규칙을 만들어 보안성을 강화할 수 있다.)

10-3. 퍼블릭IP로 접속한 Bastion Host에서 Private 서브넷으로 접속해주자.

💡  SCP를 통하여 Bastion 안에 Key-pair를 전송하여 퍼블릭 서버 → 프라이빗 서버 통신 가능

반응형
LIST

'Clould > Amazon Web Service' 카테고리의 다른 글

[AWS] 3-Teir Architecture 실습 #4  (0) 2022.07.28
[AWS] 3-Teir Architecture 실습 #3  (0) 2022.07.28
[AWS] 3-Teir Architecture 실습 #1  (0) 2022.07.27
[AWS] 3-Teir Architecture 그리기  (0) 2022.07.27
[AWS] 3-Tier 란?  (0) 2022.07.27
반응형
SMALL

1. 3티어 아키텍처 (3 tier architecture)


  • 3티어 아키텍처는 어떤 플랫폼을 3개의 계층으로 물리적/논리적으로 나누어 운영하는 것을 뜻한다.
  • 웹 서버를 운영할 경우 1대의 서버에 전부 구축하지 않고 각각 웹 서버, WAS , DB로 3개로 나누어 운영한다.
  • 각각의 계층들은 서로 독립적이므로 서로간에 영향을 끼치지 않기 때문에 각 계층을 담당하는 인원을 나누어 업무 분담을 가능하게 해주거나, 1대의 서버에서 하던 작업을 3대로 나누었기에 서버의 부하를 줄여주는 장점을 가지고 있다.
  • 그리고 2개의 가용영역으로 나누어 하나의 인스턴스에서 작동이 중단되어도 다른 인스턴스에서 작동할 수 있게끔 해주자
  • 아래 그림은 AWS로 구축하는 3티어 아키텍처를 그려보았다.
  • 다음과 같은 아키텍처를 통해서 웹 서버를 구축하는 것이 목표이다.

 

2. 전체 구조 (Draw.io)


1. 실습 전 아키텍처

2. 실습 후 아키텍처

 

3. VPC 생성


  • VPC는 AWS에서 가상의 네트워크를 제공해주는 서비스이다. 사용자의 상황에 맞게 VPC를 생성하고 서브넷, 라우팅 테이블, 게이트웨이 등 네트워크 자원들을 가상으로 생성하고 사용할 수 있다. 먼저 VPC를 생성해 주도록 하자.

 

  • 다음과 같이 VPC를 생성해주자.
    VPC Name WOONG-VPC
    IPv4 CIDR 10.0.0.0/16

 

 

4. IGW 생성


  • IGW (인터넷 게이트웨이)는 VPC가 외부 인터넷과 연결할 수 있게 해주는 관문이다. IGW를 통해 VPC는 인터넷과 통신할 수 있게 된다.

 

5. 서브넷 생성


  • 서브넷은 하나의 네트워크가 분할되어 나눠진 작은 네트워크이다. IP주소를 효율적으로 사용하기 위해 적절한 단위로 네트워크를 분할하는 것이다.
  • 다음과 같이 서브넷을 생성해주자.
ap-nothest-2a ap-notheast-2b
PUB-1 10.0.0./24 PUB-2 10.10.0./24
WEB-1 10.0.1.0/24 WEB-2 10.0.11.0/24
WAS-1 10.0.2.0/24 WAS-2 10.0.12.0/24
DB-1 10.0.3.0/24 DB-2 10.0.13.0/24

 

 

6. NAT 게이트웨이 생성


  • NAT 게이트웨이는 프라이빗 서브넷에서 외부로 통신하기 위한 관문이다.
  • 프라이빗 서브넷이 외부와 통신하기 위해 NAT 게이트웨이에 EIP를 할당받아서 연결한다.

반응형
LIST

'Clould > Amazon Web Service' 카테고리의 다른 글

[AWS] 3-Teir Architecture 실습 #3  (0) 2022.07.28
[AWS] 3-Teir Architecture 실습 #2  (0) 2022.07.27
[AWS] 3-Teir Architecture 그리기  (0) 2022.07.27
[AWS] 3-Tier 란?  (0) 2022.07.27
AWS 클라우드 용어 #9 CDN, #10 Management  (0) 2022.07.27

+ Recent posts