정리 블로그

1. 목적

AWS에서 오라클 12버전을 더이상 지원하지 않음에 따라 12버전을 사용하는 경우에는 19버전으로 업그레이드가 필요함. 4월 1일(KST)부로 순차적으로 버전 업그레이드가 강제로 진행되며, 일부 문법이 틀린 함수의 경우 동작하지 않을 수 있으니, 사전에 RDS 스냅샷을 이용하여 업그레이드 테스트가 진행되어야 안전함.

2. 오라클 12버전 설정

3. 작업 진행

AWS 콘솔의 RDS '수정'으로 들어가, 원하는 버전 번호를 확인할 것.

버전을 확인(여기서는 19버전)하였으면 작업 전, 19버전에 맞는 Parameter Group과 Option Group 생성이 필요하다.(Parameter Group의 경우, 12버전에서 사용하던 Parameter Group과 비교하여 기존에 기본값에서 변경하였던 부분은 변경해준다.

Option Group의 경우, 사전에 적용했던 옵션[타임존 등]을 확인하여 변경할 것)

RDS 수정 시, 버전 선택 후 '▼ 추가 구성' 을 확인하여, 사전에 생성하였던 파라미터 그룹과 옵션 그룹으로 변경해준다.

변경되는 값을 확인 후 '즉시 적용'으로 진행할 것!

300GB 크기 기준으로 10시 34분 시작 -> 11시 26분정도에 완료되었으니, 참고하세요.

0. 사용 목적

개발계 인스턴스의 경우, 업무시간 외에 지속적으로 실행시킬 필요가 없으므로, 업무시간 외에 AutoStop/Start를 통해 비용 절감 목적

1. Lambda 함수에서 사용할 IAM 생성

Step 1.

-. IAM -> Role 생성 -> AWS Service -> Lambda 선택(EC2는 확인하려고 클릭한거였는데..저렇게 남아있음)

Step 2.

아래 Permission을 추가.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents"
      ],
      "Resource": "arn:aws:logs:*:*:*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "ec2:Start*",
        "ec2:Stop*"
      ],
      "Resource": "*"
    }
  ]
}

2. Lambda 함수 생성

-. Start용 함수와 Stop용 함수, 두 개를 생성할 것.

-.함수 생성

위와 같이 Author from scratch 선택하며, Python 3.9로 생성하였음.

Role은 위에서 생성한 Role을 추가해줘야 하며, Stop과 마찬가지로 Start도 생성해줘야함.(EventBridge를 따로 사용해야하므로 각 각 생성)

-. Lambda Stop 함수

import boto3
region = 'us-west-1'
instances = ['i-12345cb6de4f78g9h', 'i-08ce9b2d7eccf6d26']
ec2 = boto3.client('ec2', region_name=region)

def lambda_handler(event, context):
    ec2.stop_instances(InstanceIds=instances)
    print('stopped your instances: ' + str(instances))

위 Code에서 'instance, region'은 내 인스턴스 ID, 인스턴스가 위치한 region으로 수정해줄 것

-. Lambda Start 함수

import boto3
region = 'us-west-1'
instances = ['i-12345cb6de4f78g9h', 'i-08ce9b2d7eccf6d26']
ec2 = boto3.client('ec2', region_name=region)

def lambda_handler(event, context):
    ec2.start_instances(InstanceIds=instances)
    print('started your instances: ' + str(instances))

마찬가지로 region, instances 변수 수정해줄 것.

3. EventBridge Rule 생성할 것.

EventBridge 규칙은 Cron을 활용하여 진행할 것이며, Cron의 시간은 GMT 기준이므로 한국시간으로 계산하여 작성 필요.

위 Cron식은 한국시간 기준 19시 55분을 기준으로 설정.

대상과 함수를 지정하여 Rule 생성할 것.

*STOP 함수도 위와 동일하게 생성해주면 됨.

5. Cron 표현식 참고

** 해당 방법으로 ec2 뿐 아니라, rds도 적용 가능할 것으로 보이나, 테스트해보지 않았습니다. 추후 필요하신 분은 테스트해보시면 될 것 같습니다.

++TMI : RDS의 경우, Stop하여도 7일 뒤면 자동 Start가 진행됩니다. 시작되는 일정에 맞춰 AutoStop을 설정하는 것도 하나의 방법

1. 문제 원인

Linux(Amazon Linux2) 환경에서 보안 강화를 하고자 firewalld를 설치 후 실행하였음.

yum install -y firewalld
systemctl enable --now firewalld

firewalld를 수행할 경우, 22번 포트는 막히지 않으나, 보안 강화를 위해... ssh 포트를 변경하여 사용중이었음.

따라서, 22번 포트는 막히지 않았으나, 22번 포트 외 실제 사용하는 ssh 포트 사용 불가.

2. 해결 방법

사용중인 EC2를 Stop 후 user-data에 추가한 뒤 EC2 Start 진행.

Content-Type: multipart/mixed; boundary="//"
MIME-Version: 1.0
--//
Content-Type: text/cloud-config; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="cloud-config.txt"
#cloud-config
cloud_final_modules:
- [scripts-user, always]
--//
Content-Type: text/x-shellscript; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="userdata.txt"
#!/bin/bash
systemctl stop firewalld
systemctl disable firewalld
iptables -F
service sshd restart
--//

3. 유저데이터 값 입력 후 수행

유저데이터 입력 후 EC2 시작

----------------------------------------------------------------------------------

EC2를 다시 시작하면 정상적으로 ssh 접속 되는 것을 확인할 수 있으며, 접속 확인이 완료되면 EC2를 다시 한번 Stop 후 유저데이터를 삭제해줄 것.(Optional이지만, 유저데이터를 지워주지 않을 경우, 재시작할 때, 해당 작업을 또 수행함)

ALB의 경우, WhiteList 방식이 아니라, 전체 허용. 특정 IP에만, 특정 경로를 접근하도록 하고싶었음. 

1. ALB에 규칙

ALB를 생성하면 위 화면과 같이 리스너를 생성하고, 여러개의 리스너를 사용할 경우에는 각 리스너별로 규칙을 생성할 수 있다. 각 리스너 규칙별로 ALB에 접근하는 소스 IP별 분기, 호스트별 분기, 특정 웹 Path별 분기가 가능함. 1개의 규칙에 소스 IP+호스트 분기와 같이 조합을 통해 다양한 방법으로 분기가 가능하니, 익혀두면 도움이 될 것.

2. 규칙 생성하기

위와 같이 규칙을 준 이유.

1) /admin/page.html 이라는 웹서버 경로에 특정 IP가 접근 가능.

2) /admin/page.html 경로로 접속할 경우, 404 응답 반환(에러 코드는 관리자 임의 지정 가능. 444와 같은 커스터마이징된 에러코드도 가능하며, 한글 반환도 가능) - 위에서 허용된 특정 Source가 아닌 경우임

마지막) 두 가지 조건에 해당하지 않는 경우, test라는 타겟 그룹으로 전달됨.

3. 규칙 생성 후 테스트

환경 구성 1) 클라이언트 PC의 IP는 /admin/page.html로 접근이 허용된 IP

환경 구성 2) 클라이언트 모바일 IP는 접근 허용이 되지 않은 IP

1) 클라이언트 PC에서 메인 페이지 접근

2) 클라이언트 PC에서 /admin/page.html 페이지 접근

3) 모바일에서 메인 페이지 접근

4) 모바일에서 /admin/page.html 접근 (허가되지 않은 Source IP)

*접근 권한이 없을 때, 응답 반환은 관리자가 임의로 표기한 문구가 출력

1. RDS Snapshot 생성 시, I/O Suspend.

 -. RDS 스냅샷 생성 시, I/O가 1분까지도 정지될 수 있다고 함. I/O가 정지되는 것은 볼륨에 대한 Input/Output이 일시정지되는 것이라, 운영중인 시스템에 문제가 발생할 수 있는 부분이기도 함.

참고 : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/USER_CreateSnapshot.html

2. Aurora-Mysql은??

 -. 해당 RDS를 재부팅할 일이 있어, 해당 내용을 AWS Global Support에 문의한 결과, Aurora-Mysql은 다른 RDS와 구조가 달라 I/O Suspend 없이 가능하다고 함.

따라서, 스냅샷 생성 시, 별도의 I/O 정지 없이 진행 가능.

1. Aurora-Mysql Writer / Reader 변경

 -. Cluster 환경에서 재부팅 등으로 인해 Writer - Reader가 변경된 경우, 장애 조치를 통해 Writer를 변경할 수 있음.

2. 변경하는 방법

 -. 위와 같이 Cluster 구성에서 라이터 인스턴스 / 리더 인스턴스로 구성되어 있는 경우, 라이터 인스턴스 클릭 후 장애 조치를 클릭한다.

Writer 클릭 후 장애조치를 실행할 것.

-. 상태값이 '장애 조치 중'으로 변경되며 라이터 인스턴스가 변경될 예정.

-. 변경 완료된 시점.

 작업은 수분내로 종료되며, ro가 붙은 인스턴스가 라이터 인스턴스로 변경

3. 리더 인스턴스가 여러개인 경우?

 -. 리더 인스턴스마다 장애조치 우선순위를 가지고 있음.

-. 리더 인스턴스를 클릭하여, '장애 조치 우선 순위' 값을 변경해줄 수 있음.

1. AWS Cloud9 IDE

 -. Cloud9 IDE는 온라인 통합 개발 환경으로, 수백 가지 프로그래밍 언어를 지원하는 도구입니다. 미리 구성된 워크스페이스로 개발자들이 동일한 코딩 환경을 사용할 수 있으며, 원격 접속하지 않고, 브라우저에서 바로 사용이 가능한 장점이 있습니다.

2. 환경 설정하기

-. Cloud9 으로 들어가기

-. 환경 이름과 설명 작성

-. 컴퓨팅 환경설정

-. Environment type

 콘솔 환경에서 접속하는 환경, 시스템 매니저에서 접속하는 환경, SSH 환경을 통해 접속해서 하는 환경

위 세 가지가 있다.

-. Instance Type

 개발 환경은 성능이 크게 좋을 필요가 없긴 하지만 맞는 타입을 선택할 것.

-. 플랫폼도 원하는 환경으로 할 것.

-. Cost-saving setting

 설정한 시간이 지나면 비용절감을 위해 auto-hibernate 모드로 들어간다. Never도 있으니, 참고할 것.

-. Network setting

 Cloud9 환경을 생성하면 EC2도 생성되는데, 생성되는 EC2가 어떤 VPC, Subnet에 위치할 지 설정할 수 있습니다.

-. We are creating your AWS Cloud9 Environment. This can take a few minutes.

3. Cloud9으로 생성된 EC2

0. eksctl, kubectl의 차이

 -. 기본적으로 EKS를 사용하면서 사용하는 명령어는 eksctl, kubectl을 사용한다.

 -. eksctl : AWS 인프라를 관리한다고 생각하면 된다. Cluster, Node 관리를 한다.

 -. kubectl : Node들을 관리하는 명령어.

 -. 어떠한 환경도 마찬가지겠지만 모르겠으면 --help 명령어를 적극 활용하면 매우 좋다.

 -. EKS 버전 업그레이드는 정해진 버전을 맞춰야 한다. 

1. 순서

 1) kubectl get nodes

 2) eksctl get node

 3) eksctl upgrade cluster --name <my-cluster> --approve --version 1.1x --region ap-northeast-2

 4) 'kube-proxy', 'CoreDNS', 'CNI' 버전 업그레이드

 5) Worker Node Upgrade

크게 위 순서로 작업한다고 생각하면 됩니다.

2. 클러스터, 노드 버전 확인

 -. 클러스터 버전

kubectl version --short

-. 노드 버전

kubectl get nodes

3. 클러스터 업그레이드

eksctl upgrade cluster --name <my-cluster> --approve --region ap-northeast-2 \
--version 1.1x

 > 업그레이드 완료 후 'kubectl version --short'를 통해 확인

4. Kube-proxy, CoreDNS, CNI 버전 업그레이드

-. Kube-proxy 버전 확인

kubectl get daemonset kube-proxy --namespace kube-system -o=jsonpath='{$.spec.template.spec.containers[:1].image}'

-. Kube-proxy 버전 업그레이드

kubectl set image daemonset.apps/kube-proxy \
-n kube-system \
kube-proxy=602401143452.dkr.ecr.ap-northeast-2.amazonaws.com/eks/kube-proxy:v1.15.11-eksbuild.1

-. CoreDNS 버전 확인

kubectl describe deployment coredns --namespace kube-system | grep Image | cut -d "/" -f 3

-. CoreDNS 버전 업그레이드

kubectl set image --namespace kube-system deployment.apps/coredns \ coredns=602401143452.dkr.ecr.us-west-2.amazonaws.com/eks/coredns:v1.8.0-eksbuild.1

-. CNI 버전 확인

kubectl describe daemonset aws-node --namespace kube-system | grep Image | cut -d "/" -f 2

-. CNI 버전 업그레이드

curl -o aws-k8s-cni.yaml https://raw.githubusercontent.com/aws/amazon-vpc-cni-k8s/v1.7.5/config/v1.7/aws-k8s-cni.yaml
sed -i -e 's/us-west-2/ap-northeast-2/' aws-k8s-cni.yaml
kubectl apply -f aws-k8s-cni.yaml

 > yaml파일로 다운로드 후 업그레이드 하는 방식

----------------------------------------

위 버전들은 혼합되어있으나, 실제 버전은 맨 위와 같이 버전을 맞춰야 합니다.

5. Worker Node Upgrade

eksctl create nodegroup \
--cluster <my-cluster> \
--version <version> \
--name <node-name> \
--node-type m5.xlarge \
--nodes 6 \
--nodes-min 6 \
--nodes-max 6 \
--node-ami auto \
--node-private-networking \
--node-volume-size=30 \
--ssh-access --ssh-public-key=<key-name> \
--region ap-northeast-2

 > 10분 이상 소요됩니다. 6개 노드를 기준으로 했을 때.

6. cordon, taint

kubectl cordon ip-10-10-10-10.ap-northeast-2.compute.internal \
ip-10-10-10-11.ap-northeast-2.compute.internal\
ip-10-10-10-12.ap-northeast-2.compute.internal

 > 이렇게 cordon 명령어를 띄어쓰기로 구분하여 한번에 여러개 명령할 수 있습니다.

-. taint 명령 후 'kubectl get nodes'를 입력해보면 아래와 같습니다.

*cordon 명령어는 기존 파드에는 영향을 안주면서 스케줄링을 비활성화 하는 역할을 합니다.

kubectl taint nodes node1 key1=value1:NoSchedule

 -. taint 명령어로 스케줄링을 정지합니다.

 -. cordon은 파드가 스케줄링되지 않도록 하며, taint가 적용된 노드에는 신규 스케쥴은 진행되지 않습니다. 따라서 위 화면을 기준으로 새로 생성된 노드로만 스케쥴이 진행됩니다.

*************

작업간 주의사항 (1)

kubectl get pods -o wide # 해당하는 네임스페이스 내 모든 파드의 상세 목록 조회

kubectl get pods --all-namespaces # 모든 네임스페이스 내 모든 파드의 목록 조회

을 입력하며 정상적으로 pods가 동작하는지 확인할 필요가 있으며,

이상이 있는 pods는

kubectl describe pods <my-pod> 명령어를 통해 어떤 문제가 발생했는지 살펴볼 필요가 있습니다.

작업간 주의사항 (2)

위에서 업그레이드하는 시스템(CoreDNS, CNI, Kube-proxy)과 ingress 설정(위에는 표기하지 않았으며, 추후 공부하며 다시 작성 예정)은 변경 전 kubectl get <블라블라~~~ 조회하고 싶은것> -o yaml > 파일명.yaml 형식으로 백업해두는 것을 추천합니다.

문제 발생 시, apply -f 를 통해 롤백 가능하기 때문.