Su-per (이주원)

[Kubernetes] kubectl 기본 명령어 정리

Fri, 07 Apr 2023 14:10:54 +0900

kubectl이란?

kubectl은 쿠버네티스 클러스터를 제어하기 위한 CLI툴이다. kubectl의 많은 명령어들 중에서도 가장 기본적인 명령어 몇 가지를 알아보자.

apply (리소스 생성)

리소스가 정의된 YAML 파일을 이용해 쿠버네티스에 리소스를 생성한다. 파일뿐만 아니라 URL도 입력 가능하다. 많은 예제에서 YAML 파일을 URL로 제공하고 있다.

kubectl apply -f [파일명 또는 URL]

get (리소스 목록 보기)

쿠버네티스에서 돌아가고 있는 리소스들을 확인한다.

kubectl get [리소스 타입]

대표적인 리소스 타입엔 pods, nodes, deployments, replicasets, services 등이 있다. 리소스 타입은 po, no, svc 처럼 줄여 쓸 수 있다. 이런 줄임말이나 모든 리소스 타입을 보려면 kubectl api-resources명령어를 통해 볼 수 있다.

인자

-o

출력 포맷을 지정한다. json으로 json형식으로 출력하거나 wide를 통해 더 정확한 정보를 볼 수 있다.

describe (리소스 정보 보기)

쿠버네티스에서 돌아가고 있는 리소스의 상세한 상태를 확인한다.

kubectl describe [리소스 타입]/[이름] 또는 [리소스 타입] [이름]

리소스의 상세 정보나 상태, 혹은 실패한 이유를 확인할 때 주로. 사용한다. 다음은 nginx pod을 생성한 후 describe한 결과이다.

macintosh@Macintoshui-MacBookPro k8s % kubectl get pod
NAME        READY   STATUS    RESTARTS   AGE
nginx-pod   1/1     Running   0          64s
macintosh@Macintoshui-MacBookPro k8s % kubectl describe pod nginx-pod
Name:             nginx-pod
Namespace:        default
Priority:         0
Service Account:  default
Node:             docker-desktop/192.168.65.4
Start Time:       Fri, 07 Apr 2023 13:59:34 +0900
Labels:           <none>
Annotations:      <none>
Status:           Running
IP:               10.1.0.14
IPs:
  IP:  10.1.0.14
Containers:
  nginx-container:
    Container ID:   docker://8fb97bf6a5ae74026ecbb5e6cc865a7afef6040692f531aff8470eb277f65962
    Image:          nginx
    Image ID:       docker-pullable://nginx@sha256:2ab30d6ac53580a6db8b657abf0f68d75360ff5cc1670a85acb5bd85ba1b19c0
    Port:           80/TCP
    Host Port:      0/TCP
    State:          Running
      Started:      Fri, 07 Apr 2023 13:59:42 +0900
    Ready:          True
    Restart Count:  0
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-vzmkw (ro)
Conditions:
  Type              Status
  Initialized       True
  Ready             True
  ContainersReady   True
  PodScheduled      True
Volumes:
  kube-api-access-vzmkw:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       <nil>
    DownwardAPI:             true
QoS Class:                   BestEffort
Node-Selectors:              <none>
Tolerations:                 node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type    Reason     Age   From               Message
  ----    ------     ----  ----               -------
  Normal  Scheduled  75s   default-scheduler  Successfully assigned default/nginx-pod to docker-desktop
  Normal  Pulling    74s   kubelet            Pulling image "nginx"
  Normal  Pulled     67s   kubelet            Successfully pulled image "nginx" in 7.16185317s
  Normal  Created    67s   kubelet            Created container nginx-container
  Normal  Started    67s   kubelet            Started container nginx-container

delete (리소스 삭제)

쿠버네티스에서 돌아가는 리소스를 제거한다.

kubectl delete [리소스 타입]/[이름] 또는 [리소스 타입] [이름] 또는 [yaml 파일]

특이점으로는 apply -f를 통해 생성한 리소스는 생성한 파일 또는 URL로 생성된 리소스를 지울 수 있다.

logs (리소스 로그 확인)

생성된 파드에 로그를 확인한다.

kubectl logs [파드 이름]

인자

-f

파드의 로그를 실시간으로 가져온다.

-c

파드에 여러개의 컨테이너가 있는 경우 컨테이너를 지정할 수 있다.

exec (리소스 명령어 전달)

컨테이너에 명령어를 전달한다.

kubectl exec [파드 이름] -- [명령어]

인자

-it

쉘로 컨테이너에 직접 접속한다.

-c

파드에 여러개의 컨테이너가 있는 경우 컨테이너를 지정할 수 있다.

[MySQL] 네이밍 컨벤션 정리

Mon, 27 Mar 2023 18:00:09 +0900

이 글은 이 포스팅을 번역한 글입니다.

일반 규칙

MySQL은 대소문자를 구분한다. 따라서 소문자로 통일하여 실수를 피할 수 있다.
공백 대신 _ 를 사용한다.
이름에 숫자를 포함하지 않는다. 영문 알파벳만 사용해야 한다.

데이터베이스 규칙

데이터베이스의 이름은 단수 혹은 복수일 수 있지만 일반적으로 단수를 사용해야 한다.

테이블 규칙

마찬가지로 테이블의 이름은 단수 혹은 복수일 수 있지만 일반적으로 단수를 사용해야 한다.

필드 규칙

대소문자, 공백, 숫자를 포함하지 않는다.
두 단어 이하의 짧은 이름을 선택한다.
필드 이름만으로 유추하기 쉬워야 한다.
PK는 id 또는 테이블명_id의 형태를 띄어야 한다.
테이블 이름과 동일하게 하지 않는다.
FK 필드엔 테이블 이름이 있어야 한다.
- 테이블 블로그의 외부 키 id를 나타내려면 blog_id를 사용
약어를 사용하지 않는다.

Docker 네트워크 정리

Mon, 13 Mar 2023 17:47:57 +0900

도커에서 컨테이너는 서로 격리된 환경에서 동작하므로, 기본적으로 컨테이너끼리는 서로 통신할 수 없다. 하지만 여러 컨테이너를 하나의 도커 네트워크에 연결시키면 서로 통신이 가능해진다. 도커 네트워크에 대해 알아보자.

도커 네트워크 조회

먼저 docker network ls 명령어를 통해 현재 생성된 네트워크를 조회해보자.

$ docker network ls
NETWORK ID     NAME      DRIVER    SCOPE
5ff1ee73cdfc   bridge    bridge    local
4bb888e5a996   host      host      local
a0a0b6f89227   none      null      local

이 bridge, host, none은 Docker를 실행하면 자동으로 생성되는 네트워크다. 컨테이너를 생성하면 기본적으로 이 브릿지 네트워크를 사용하게 된다. 이 브릿지 네트워크를 docker0 브릿지라고 하는데, docker0 브릿지는 172.17.0.0/16 CIDR를 갖기 때문에 여기에 컨테이너를 생성하면 172.17.0.1, 172.17.0.2처럼 차례로 IP를 할당받게 된다.

네트워크 종류

도커 네트워크엔 기본적으로 bridge, host, none, container, overlay 네트워크가 있다.

bridge: 호스트 내의 같은 브릿지에 있는 컨테이너끼리 통신을 가능하게 해준다.
host: 호스트의 네트워크 환경을 그대로 사용한다. 따라서 포트포워딩 작업이 필요가 없다.
none: 컨테이너를 완전히 고립시킨다. 어떤 컨테이너와도 통신할 수 없다.
container: 다른 컨테이너의 네트워크 환경을 공유한다.
overlay: 분산된 네트워크(도커 호스트가 여러개)인 환경에서 도커를 사용해야 할 때 사용한다.

컨테이너간 통신

이제 docker-compose와 브릿지를 이용해 두 컨테이너를 생성하고, 컨테이너끼리 ping 통신을 날려보도록 하자. 아래 코드를 docker-compose up 명령어를 통해 실행시키자

version: '3'

services:
  service1:
    image: busybox:latest
    tty: true #바로 종료되는걸 막기 위함
    networks:
      - my_network

  service2:
    image: busybox:latest
    tty: true 
    networks:
      - my_network

networks:
  my_network:
    driver: bridge

실행이 끝났다면, docker ps 명령어를 통해 컨테이너ID를 가져오자.

macintosh@Macintoshui-MacBookPro ~ % docker ps
CONTAINER ID   IMAGE            COMMAND   CREATED         STATUS         PORTS     NAMES
865eaac3a6cf   busybox:latest   "sh"      2 minutes ago   Up 2 minutes             service2-1
7aba153cd49d   busybox:latest   "sh"      2 minutes ago   Up 2 minutes             service1-1

이제 docker exec <컨테이너ID> ifconfig을 통해 IP를 가져와보자.

macintosh@Macintoshui-MacBookPro ~ % docker exec <컨테이너ID> ifconfig
zsh: no such file or directory: 컨테이너ID
macintosh@Macintoshui-MacBookPro ~ % docker exec 865eaac3a6cf ifconfig
eth0      Link encap:Ethernet  HWaddr 02:42:AC:14:00:03  
          inet addr:172.20.0.3  Bcast:172.20.255.255  Mask:255.255.0.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:25 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:1914 (1.8 KiB)  TX bytes:496 (496.0 B)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:36 errors:0 dropped:0 overruns:0 frame:0
          TX packets:36 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:2576 (2.5 KiB)  TX bytes:2576 (2.5 KiB)

컨테이너의 IP가 172.20.0.3인 것을 알았다. 그럼 이제 다른 컨테이너에서 ping 명령어를 날려보자.

macintosh@Macintoshui-MacBookPro ~ % docker exec 7aba153cd49d ping 172.20.0.3
PING 172.20.0.3 (172.20.0.3): 56 data bytes
64 bytes from 172.20.0.3: seq=0 ttl=64 time=0.857 ms
64 bytes from 172.20.0.3: seq=1 ttl=64 time=0.361 ms
64 bytes from 172.20.0.3: seq=2 ttl=64 time=0.557 ms
64 bytes from 172.20.0.3: seq=3 ttl=64 time=0.354 ms
...

정상적으로 통신이 되는것을 볼 수 있다. 추가로, 도커는 서로 같은 네트워크안에선 아이피 주소가 아닌 서비스 이름으로도 서로 통신을 할 수 있다. yaml파일에서 생성한 service1이라는 이름으로 ping 통신을 날려보자.

macintosh@Macintoshui-MacBookPro ~ % docker exec 7aba153cd49d ping service1  
PING service1 (172.20.0.2): 56 data bytes
64 bytes from 172.20.0.2: seq=0 ttl=64 time=0.405 ms
64 bytes from 172.20.0.2: seq=1 ttl=64 time=0.195 ms
64 bytes from 172.20.0.2: seq=2 ttl=64 time=0.395 ms
64 bytes from 172.20.0.2: seq=3 ttl=64 time=0.302 ms

역시 통신이 가능한 것을 볼 수 있다.

AWS CodePipeline으로 Blue/Green 배포하기

Fri, 10 Mar 2023 09:53:48 +0900

이 포스팅은 AWS CodePipeline + ECR + Auto Scaling Group + EC2를 사용하여 Blue Green 배포를 해보는 과정을 담은 글입니다.

아키텍처

이 포스팅에서 구축할 아키텍처 구조는 위 그림과 같습니다.

IAM Role 생성

EC2가 사용할 IAM 역할 생성

사용 사례에 EC2를 선택하고 배포를 위한 AmazonEC2RoleforAWSCodeDeploy, ECR, 파라미터 스토어 접근을 위한 AmazonEC2ContainerRegistryReadOnly, AmazonSSMReadOnlyAccess 정책을 연결한 다음 역할을 만들어 준다.

CodeDeploy가 사용할 IAM 역할 생성

먼저 정책을 만들어 줘야 한다. 이 블로그에 설명되어 있듯, AWS Managed Policy에 Blue / Green 배포에 필요한 Action들이 추가가 안 돼 있어 사용자가 직접 정책을 만든 후 역할에 붙여줘야 한다. 정책 생성 -> JSON 탭으로 이동 후 밑 코드를 붙여넣기 한다.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "iam:PassRole",
                "ec2:CreateTags",
                "ec2:RunInstances"
            ],
            "Resource": "*"
        }
    ]
}

적당히 이름을 붙이고 만들어 준다.

이제 역할을 만들어 준다. 역할 만들기 -> 사용 사례에서 CodeDeploy를 검색하고 선택한 다음 역할을 만든다. 그리고 위에서 만든 정책을 연결해준다.

ECR 레포지토리 생성

빌드한 도커 이미지를 업로드할 ECR 레포지토리를 생성해준다. ECR -> 레포지토리 -> 레포지토리 생성을 누른다.

표시 여부 설정: 프라이빗을 선택한다.
레포지토리 이름: ECR 레포지토리 이름이다. 적절히 입력한다.

terraform 설치

terraform.exe를 C:\terraform에 위치 후 아래 스크립트를 실행한다.

$path = [Environment]::GetEnvironmentVariable("Path", "Machine")
if ($path -notlike "*C:\terraform*") {
    [Environment]::SetEnvironmentVariable("Path", "$path;C:\terraform", "Machine")
}

Parameter Store 파라미터 생성

CodeBuild, CodeDeploy에서 ECR에 접근하기 위한 리전, 계정 정보, ECR 레포지토리 정보 등을 접근하기 위한 파라미터를 생성해야 한다. 코드에 직접 하드코딩할 수도 있지만, 보안을 위해 Parameter Store를 사용하는 것을 권장한다. 생성할 파라미터는 다음과 같다.

/CodePipeline/AWS_DEFAULT_REGION //AWS 리전
/CodePipeline/AWS_ACCOUNT_ID //AWS 계정ID (숫자 12자리)
/CodePipeline/IMAGE_REPO_NAME //ECR 레포지토리 이름 (URI가 아니다)
/CodePipeline/IMAGE_TAG //도커 태그 이름. latest를 입력한다.

System Manager -> 파라미터 스토어 -> 파라미터 생성을 누른 후, 이름과 값에 위 내용을 따라 적절히 입력한다.

시작 템플릿 생성

ASG를 만들기 전에 시작 템플릿이란 것을 만들어야 한다. 시작 템플릿이란 AMI, 키페어, 인스턴스 유형 등 인스턴스를 시작하는데 필요한 정보가 포함된 템플릿이다. ASG는 이 템플릿을 참조해 확장(Scale out)이벤트가 발생할 때 새로운 인스턴스를 만든다.

EC2 메뉴 -> 시작 템플릿 -> 시작 템플릿 생성을 누르자

시작 템플릿 이름: 말 그대로 템플릿 이름이다. 대충 지어준다.
AMI: Quick Start에서 Amazon Linux 2를 선택한다.
인스턴스 유형, 키페어: 알맞게 선택해준다.
네트워크 설정: 서브넷은 시작 템플릿에 포함하지 않음을 선택한다.
보안 그룹: 새로운 보안그룹을 만들고 SSH와 HTTP를 열어준다. (나중에 접속하기 위함)
고급 네트워크 구성: 네트워크 인터페이스를 추가해주고 퍼블릭 IP 자동 할당을 활성화 해준다. 이걸 활성화 해줘야 EC2에 외부에서 접근할 수 있다.
IAM 인스턴스 프로파일: 고급 세부정보를 열고 위에서 만든 IAM Role을 선택한다.
사용자 데이터: 아래 명령을 입력한다 EC2가 실행될 때 Docker와 CodeDeploy를 자동으로 설치하게 하기 위함이다.

#!/bin/bash
sudo yum install docker -y
sudo service docker start
sudo usermod -a -G docker ec2-user
sudo chmod 666 /var/run/docker.sock
yum install -y ruby
wget https://aws-codedeploy-ap-northeast-2.s3.ap-northeast-2.amazonaws.com/latest/install
chmod +x ./install
sudo ./install auto
sudo systemctl start codedeploy-agent

생성 후 ASG 생성 창으로 이동한다.

ASG 생성

ASG(오토스케일링 그룹)은 트래픽 혹은 하드웨어 사용량에 따라 인스턴스의 개수를 조정해주는 서비스이다. EC2 -> Auto Scaling 그룹 -> Auto Scaling 그룹 생성을 누르자.

Auto Scaling 그룹 이름: ASG의 이름이다. 대충 지어준다.
시작 템플릿: 위에서 만든 템플릿을 선택해 준다.
가용 영역 및 서브넷: 여러 가용영역에 걸쳐 public 서브넷을 선택한다. 여러 가용영역을 지정해야 ASG에서 확장(Scale out)할 때 여러 가용영역에 걸쳐 고르게 인스턴스를 생성한다.
로드밸런싱: 새 로드밸런서에 연결을 선택한다.
로드밸런서 유형: Applicaiton Load Balancer를 선택한다.
로드 밸런서 체계: 외부에서 접근하기 위해 Internal-Facing을 선택한다.
대상 그룹: 새 대상 그룹 생성을 누른다.
원하는 용량: 처음 실행될 인스턴스의 개수이다.
최소 용량: 인스턴스가 최대로 축소됐을 때의 개수이다.
최대 용량: 인스턴스가 최대로 확장됐을 때의 개수이다.
크기 조정 정책: 대상 추적 크기 조정 정책을 선택한다.

CodePipeline 생성

CodePipeline -> 파이프라인 -> 파이프라인 생성을 누른다.

파이프라인 이름: 파이프라인 이름이다. 대충 지어준다.
서비스 역할: 새 서비스 역할을 선택한다.
아티팩트 스토어: 빌드 후 코드 파일인 아티팩트를 저장할 곳을 지정할 수 있다. 기본 위치로 지정한다.
암호화 키: 아티팩트를 암호화할 키를 지정할 수 있다. AWS에서 제공해 주는 것과 KMS를 통해 직접 관리할 수 있다. AWS 관리형 키를 선택한다.

Source Stage

이 포스팅에선 이 레포지토리의 소스를 사용한다.

소스 공급자: Github(버전 2)를 선택한다. 버전1은 AWS에서 권장하지 않는다고 한다.
연결: Github에서 데이터를 가져오기 위해 연결을 생성해야 한다. 이 블로그에 자세히 설명되어 있다.
브랜치: 브랜치를 선택한다.

Build Stage

빌드 공급자: CodeBuild를 선택한다.

아직 CodeBuild 프로젝트를 만들지 않았기 때문에 프로젝트 생성을 통해 생성 창으로 이동한다.

프로젝트 이름: CodeBuild 프로젝트 이름이다. 대충 지어준다.
환경 이미지: CodeBuild가 돌아갈 환경을 선택할 수 있다. 자신이 따로 도커 이미지를 만들거나 AWS에서 제공하는 Amazon Linux 2, Ubuntu 중 선택할 수 있다. Amazon Linux 2 를 선택한다.
런타임, 이미지, 이미지 버전: 모두 최신 버전을 선택한다.
권한이 있음: 도커 이미지를 빌드 후 ECR에 업로드하기 위해 활성화해준다.

그리고 빌드 시에 Parameter Store에 접근하고, ECR 레포지토리에 이미지를 푸시하기 위해 생성된 CodeBuild Role에 AmazonSSMReadOnlyAccess, AmazonEC2ContainerRegistryFullAccess 정책을 붙여준다.

Deploy Stage

배포 공급자: CodeDeploy를 선택한다.

아직 CodeDeploy 애플리케이션을 만들지 않았기 때문에 CodeDeploy -> 애플리케이션 -> 애플리케이션 생성을 통해 생성 창으로 이동한다.

이름: CodeDeploy 애플리케이션 이름이다. 적당히 지어준다.
컴퓨팅 플랫폼: EC2/온프레미스 를 선택한다

애플리케이션 생성후엔 배포 그룹을 만들어야 한다. 사실 이게 배포를 어떤식으로 할지 설정하는 본체라고 할 수 있다. 배포 그룹 생성 을 누른다.

배포 그룹 이름: 배포 그룹 이름이다. 적당히 지어준다.
서비스 역할: 위에서 만든 역할을 붙여준다.
배포 유형: 블루/그린 을 선택한다.
환경 구성: Amazon EC2 Auto Scaling 그룹 자동 복사를 선택한 후, 위에서 만든 ASG를 선택한다.
배포에 성공한 다음 원본 환경의 인스턴스를 종료할지 여부와 종료 전 대기 시간 선택: 원본 인스턴스 종료를 선택한 후, 시간을 0분으로 설정한다.
로드 밸런서: Application Load Balancer를 선택하고 ASG를 생성할 때 만든 대상그룹을 선택한다.

이제 CodePipeline으로 넘어와서 애플리케이션과 배포 그룹을 선택한 뒤 생성한다.

배포 성공

이렇게 모두 초록색이 뜬다면 성공이다. 이제 로드밸런서로 접근해 보자.

이렇게 배포된 ASG에 잘 로드밸런싱 되고 있는 모습이다.

AWS CloudFormation으로 IaC 시작하기 - 01

Thu, 23 Feb 2023 15:49:35 +0900

CloudFormation

CloudFormation은 AWS에서 제공하는 IaC툴입니다. 이런 IaC 툴로는 Terraform, Ansible, Puppet 등이 있습니다.

IaC 란?

IaC(Infra as Code, 코드형 인프라) 는 수동 프로세스가 아닌 코드를 통해 인프라를 관리하고 프로비저닝하는 것을 말합니다. 기존의 수동적인 인프라 관리 방식은 쉽고 빠르게 아키텍처를 구축할수 있다는 점에서 유리하지만, 여러 단점도 가지고 있습니다.

서비스를 구축하고 관리할 때 인적오류가 발생할 수 있다
리소스간의 의존성을 파악하기 어렵다
인프라의 변경 사항을 추적하기 어렵다

반면에, IaC는 인프라를 코드로 작성하고 관리합니다. 이러한 IaC로 인프라를 구축하면 다음과 같은 메리트가 있습니다.

인프라를 만드는 과정이 자동화되므로, 오류가 훨씬 덜 발생한다.
쉽게 공유할 수 있고, 버전 관리에 용이하다.
리소스의 일관성을 확보할 수 있다.

클라우드포메이션은 AWS에서 제공하는 IaC툴로, AWS 서비스 이외의 서비스는 지원하지 않지만, AWS에서 높은 수준의 서비스를 보증하는 툴입니다. 클라우드포메이션으로 인프라를 구축해보도록 합시다

CloudFormation 개념

클라우드포메이션은 템플릿, 스택을 사용하여 작업합니다.

템플릿

템플릿은 JSON, YAML 형식의 텍스트 파일입니다. 클라우드포메이션은 이 템플릿을 보고 리소스를 구축합니다. 예를 들어 EC2 인스턴스를 프로비저닝한다면 인스턴스 유형, AMI ID, 키페이 이름 등을 지정할 수 있습니다.

AWSTemplateFormatVersion: 2010-09-09
Description: A sample template
Resources:
  MyEC2Instance:
    Type: 'AWS::EC2::Instance'
    Properties:
      ImageId: ami-0ff8a91507f77f867
      InstanceType: t2.micro
      KeyName: testkey
      BlockDeviceMappings:
        - DeviceName: /dev/sdm
          Ebs:
            VolumeType: io1
            Iops: 200
            DeleteOnTermination: false
            VolumeSize: 20

한 템플릿에서 여러 리소스를 지정할 수도 있습니다. 예를 들어 위 인스턴스에 탄력적 IP를 할당시킬 수도 있습니다.

AWSTemplateFormatVersion: 2010-09-09
Description: A sample template
Resources:
  MyEC2Instance:
    Type: 'AWS::EC2::Instance'
    Properties:
      ImageId: ami-0ff8a91507f77f867
      InstanceType: t2.micro
      KeyName: testkey
      BlockDeviceMappings:
        - DeviceName: /dev/sdm
          Ebs:
            VolumeType: io1
            Iops: 200
            DeleteOnTermination: false
            VolumeSize: 20
  MyEIP:
    Type: 'AWS::EC2::EIP'
    Properties:
      InstanceId: !Ref MyEC2Instance

클라우드포메이션은 템플릿을 적용할 때 입력 파라미터를 추가할 수도 있습니다. 예를 들어, 템플릿을 작성할 때가 아닌, 템플릿을 적용할때 인스턴스 유형이나 AMI ID같은 값들을 지정할 수 있습니다.

스택

클라우드포메이션은 스택이라는 하나의 단위로 관련 리소스들을 관리합니다. 예를 들어 ASG, 로드밸런서, RDS 인스턴스를 포함하는 템플릿을 작성합니다. 이러한 리소스를 생성하려면, 생성한 템플릿을 제출해 스택을 생성하면 클라우드포메이션에서 모든 리소스를 자동으로 프로비저닝 해줍니다. 만약 잘못된 템플릿 작성으로 리소스를 생성할 수 없는 경우, 해당 스택을 롤백하고, 모든 추가된 리소스들을 자동으로 삭제할 수 있습니다.

AWS CodeDeploy 찍먹해보기

Mon, 20 Feb 2023 20:42:39 +0900

CodeDeploy란?

CodeDeploy는 AWS에서 제공하는 배포 자동화 서비스이다. ECS, Lambda, EC2, 온프레미스에 코드를 배포할 수 있으며 다운타임을 최소화할 수 있다. 한번 CodeDeploy를 찍먹해 보자.

CodeDeploy를 사용해 EC2 인스턴스에 배포해보자

대략적인 순서는 다음과 같다.

IAM Role 생성
EC2 인스턴스 생성
S3 버킷 생성
CodeDeploy 애플리케이션 생성

차근차근 해보자.

1. IAM Role 생성

먼저 CodeDeploy와 EC2가 사용할 IAM을 만들어야 한다. 배포를 위해선 CodeDeploy가 EC2에게 접근해야 하고, EC2도 S3에서 코드를 받아서 설치해야 한다. 이를 위한 작업이다.

CodeDeploy가 사용할 IAM Role 생성

IAM -> 역할 -> 역할 만들기 -> 사용 사례에서 CodeDeploy 검색 후 선택 -> 다음 -> 자신이 기억할 수 있게 역할 이름과 설명 설정 -> 생성

EC2가 사용할 IAM Role 생성

IAM -> 역할 -> 사용 사례에서 EC2 선택 -> 권한 정책에서 'CodeDeploy'를 검색한 후 'AmazonEC2RoleforAWSCodeDeploy' 정책 추가 -> 자신이 기억할 수 있게 역할 이름과 설명 설정 -> 생성

2. EC2 인스턴스 생성

이제 코드가 배포될 EC2 인스턴스를 만들어 준다. EC2 인스턴스 시작 페이지에서 적절한 이름, 인스턴스 유형, 키페어 등을 지정해주고, 고급 세부 설정의 IAM 인스턴스 프로파일에서 위에서 만든 Role을 지정한다. 그리고 접속을 위해 보안그룹에서 80번 포트를 Anywhere IPv4로 열도록 하자. 이제 CodeDeploy agent를 설치해야 한다. 인스턴스에 SSH 접속 후 아래 코드를 순차적으로 입력한다.

sudo yum update
sudo yum install -y ruby
wget https://aws-codedeploy-ap-northeast-2.s3.ap-northeast-2.amazonaws.com/latest/install
chmod +x ./install
sudo ./install auto

그리고 아래 코드로 Agent를 실행시키고 실행중인지 확인한다.

sudo service codedeploy-agent start && sudo service codedeploy-agent status

3. S3 버킷 생성

이제 CodeDeploy에서 코드를 받아갈 수 있게 S3 버킷을 통해 코드를 저장해줘야 한다. S3 버킷을 하나 만들어 준다. 그리고 코드를 업로드 해야 하는데, 코드는 깃허브에 업로드된 예제 코드를 사용하도록 하겠다. 위 레포지토리의 /applications 에 SampleApp_Linux를 zip으로 압축한 후 S3에 업로드한다.

여기서 MacOS 사용자들은 Finder를 통해 압축하게 되면 오류가 뜬다. 따라서 압축해주는 사이트 등을 이용하자. ~~이거 때문에 1시간동안 삽질했다~~

4. CodeDeploy 애플리케이션 생성

CodeDeploy 애플리케이션과 배포그룹, 배포를 생성할 차례다. 먼저 간단히 CodeDeploy 애플리케이션을 생성해준다. CodeDeploy -> 적절한 이름 입력 -> 컴퓨팅 플랫폼은 EC2/온프레미스 선택 -> 애플리케이션 생성

이제 만든 애플리케이션에서 배포 그룹을 만들어 준다. 배포 그룹 생성 -> 적절한 배포 그룹 이름 -> 서비스 역할에 위에서 만든 CodeDeploy 역할 지정 -> 배포 유형에 '현재 위치' 선택 -> 환경구성에서 위에서 만든 EC2 인스턴스를 지정 -> 로드밸런싱 활성화 끄기 -> 배포 그룹 생성

다음으로 배포를 만들 차례다. 위에서 만든 배포 그룹 선택 후 배포 생성을 클릭한다. 개정 유형에 '애플리케이션을 S3에 저장'을 선택 -> 개정 위치에 S3에 업로드된 .zip 파일에서 S3 URI를 복사 한 후 붙여넣기 -> 배포 만들기

성공!

그럼 이렇게 배포에 성공하게 된다. 한번 EC2로 접속해보자.

정상적으로 접속된다.