정리 블로그

1. 윈도우 서버

 -. 윈도우 서버는 가정에서 사용하는 윈도우 환경과 매우 비슷한 UI를 가지고 있음. 하지만 일부 오래된 윈도우 서버에서는 NTP 서버가 어떻게 설정되어있는지 확인할 수 없는 경우도 있음.

따라서, 별도로 cmd창을 통해 확인이 가능함.

물론, 가정용 윈도우 환경에서도 동일한 명령어를 통해 확인 가능.

두 가지 경우 모두 time.window.com 을 ntp서버로 보고있음.

w32tm /dumpreg /subkey:parameters

1. fallocate

 -. 해당 명령어는 파일에 공간을 사전할당하여, 원하는 사이즈의 파일을 만들 수 있음.

 -. 실제 내용은 빈칸으로 구성되어있으며, 만들기 매우 간편.

2. fallocate를 통해 100M 생성해보기

fallocate -l 100M '파일명'

여기서 파일 크기 변경하여 생성하면 됨.

-. 생성 결과

3. 참고

fallocate --help

-. 리눅스로 생성한 파일을 윈도우로 옮겨 사용해도, 파일크기 동일(당연한 얘기지만..)하니까 테스트용으로 쓰면 됨

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. Grafana란 무엇인가..

 -. 그라파나는 오픈소스 중 하나로 메트릭 데이터 시각화 도구입니다.(간단하게 생각해서 오픈소스 모니터링 툴)

2. Grafana 구축 환경

 -. 그라파나를 구축할 수 있는 환경 및 방법은 다양합니다. k8s에서 구축하는 경우, Secret Key 외에 Role을 사용하여 구축하는 경우 등.

 -. 본 실습에서는 EC2 + IAM의 Secret Key를 통해 구축하였습니다.

3. Grafana 패키지 다운로드

wget https://dl.grafana.com/oss/release/grafana-8.0.3-1.x86_64.rpm
sudo yum install grafana-8.0.3-1.x86_64.rpm

wget을 통해 패키지를 다운받습니다. yum 은 패키지를 쉽게 설치하는 툴이며, wget을 통해 다운로드 받지 않은 상태에서 설치 진행 시.. 설치 불가...

Private 환경에 구축하였으며, 지난번 테스트 후 원상복구를 안해둬서 해당 인스턴스에서 인터넷 사용이 불가능했습니다. 라우팅 수정 진행하였고, Security Group 정책 추가.

-. 여기서부터 정상적으로 설치된 화면.

yum install 설명할 것이 없기에.. 생략하였습니다.

-. 설치 후 서비스를 기동해줘야 정상적으로 접속이 가능합니다.

systemctl start grafana-server

(Amazon Lin2 환경이며, CentOS 7과 동일하다고 생각하면 됨)

사용 포트는 3000번을 사용하며, Private 환경에 구축하였기에 OpenVPN 접속 후 해당 환경에 접속 가능합니다.

(혹여나..Private IP인지 아닌지를 모르는 분이 해당 IP를 입력할 수 있을 거란 생각에..)

4. Grafana 설치 후 화면

-. 간단하게 범할 수 있는 실수도 같이 넣습니다.

Security Group 인바운드 수정 안하면 안되는거 아시죠..?

-. Inbound 정책 추가 후 초기 화면

초기 접속 정보는 admin / admin 입니다.

5. UI 접속 후 기본 세팅

-. Data sources에 접속

-. Access Key 및 Secret Access Key 입력!

(Access Key를 입력하면 Key의 권한에 따라 많은 것이 뚫릴 수 있기에 가렸습니다...)

위와 같은 에러 발생했으며, 저의 경우는 IAM User 생성 시, 권한 문제였습니다. 권한은 CloudWatchReadOnlyAccess 필요!

권한 변경 후 정상 작동 확인

6. 대시보드 설정

-. New dashboard 설정(add an empty panel)

Query Mode 에서 선택 -> CloudWatch Metric으로 진행하였으므로, 선택.

기타 Region 등을 원하는 것으로 선택하여 진행하면 됩니다.(선택 시, 리스트 확인가능하여 생각보다 쉽습니다.)

Alias를 통해 네이밍을 쉽게 할 수 있습니다.

* 추가 Panel 설정을 통해 위와 같이 점으로 출력되는 부분을 Line으로 변경할 수 있습니다.

Connect null value에서 'Always' 선택하면 위와 같이 우리가 아는 그래프로 출력됩니다.

*추후 k8s 환경에서 Grafana 환경 구축하는 방법도 테스트 후 포스팅 예정입니다.

*******추가로******

Grafana 환경과 같이 자주 언급되는 Prometheus가 있습니다.

Prometheus는 k8s에서 가장 많이 사용되는 오픈소스 기반 모니터링 시스템입니다.

Prometheus -> 모니터링 수집 담당

Grafana -> 시각적 UI 담당

따라서, 프로메테우스는 추후 k8s를 통한 그라파나 환경 구축 진행 시, 다시 언급하도록 하겠습니다.

1. server.xml 설정 변경 및 iptables 설정 추가

-. 톰캣의 server.xml을 수정하여 포트 리다이렉트 하는 방법입니다. 물론 iptables 명령어도 사용해야하지만..

위 화면이 초기에 화면입니다.

테스트를 하기위해 저는 기본 포트도 8080에서 8090으로 변경하였으니, 참고 부탁드립니다 :)

**** proxyPort="81" 추가 (해당 부분은 추가하지 않아도 iptables에서 리다이렉트시키는 것 확인함... 필요 없을 것으로 보이나, 추가 확인 필요.)

**** iptables 정책 추가

iptables -t nat -A PREROUTING -p tcp --dport 81 -j REDIRECT --to-port 8090

#81포트로 들어올 경우, 8090포트로 리다이렉트 처리

2. Tomcat 서비스 포트 확인

포트 8090으로 LISTEN 중인 것 확인됩니다. 포트 81은 작동중이 아님.

서비스 접속은 81포트 동작하는 것으로 보이지만, 실제로 내부에서는 81포트로 들어오는 서비스는 8090포트에서 동작하는 중 입니다.

3. ALB와 Route53 서비스를 사용하여 서비스 확인!

-. ALB의 기능은 사용하지 않고, 81 포트로 인입 시, 81 포트로 Forwarding하는 기능만 사용하였습니다.

위와 같은 리스너만 추가하였습니다!

**해당 작업을 진행하면서 ALB의 Security Group, EC2의 Security Group은 잘 확인하시기 바랍니다.

'www.taek.gq' 레코드를 추가하여, 연결 완료!

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 를 통해 롤백 가능하기 때문.