본문 바로가기

혼자하는 프로젝트/Wordpress (워드프레스)

Cloud9 + EKS + Wordpress 구성하기

728x90
반응형

1. Cloud9 환경구성

2021.10.03 - [AWS/Cloud9] - Cloud9 생성 및 터미널 접속

 

Cloud9 생성 및 터미널 접속

- cloud9을 검색하여 새로운 환경을 만든다. - 이름과 간단한 설명을 입력 후 다음으로 넘어간다. - 아래 구성과 유사하게 세팅한다. - 생성되고 있는 모습. - 생성이 완료되고 터미널이 활성화된 모

may9noy.tistory.com

- 구성된 Cloud9 환경에서 SSH를 접속하여 쿠버네테스를 설치하자.

2. Kubernetes Tools 설치

1) kubectl 설치

sudo curl --silent --location -o /usr/local/bin/kubectl \
  https://amazon-eks.s3.us-west-2.amazonaws.com/1.17.7/2020-07-08/bin/linux/amd64/kubectl

sudo chmod +x /usr/local/bin/kubectl

2) awscli 업데이트

sudo pip install --upgrade awscli && hash -r

3) jq, envsubst (GNU gettext utilities), bash-completion 설치

sudo yum -y install jq gettext bash-completion moreutils

4) yaml 프로세싱을 위한 yq 설치

echo 'yq() {
  docker run --rm -i -v "${PWD}":/workdir mikefarah/yq yq "$@"
}' | tee -a ~/.bashrc && source ~/.bashrc

* yq : command-line YAML processor, yaml 파일의 jq 또는 sed가 되는 것이 목적

   jq : command-line JSON processor

  sed : ed 명령어와 grep 명령어 기능의 일부를 합친 명령어

5) 바이너리가 경로와 실행파일에 있는지 확인

for command in kubectl jq envsubst aws
  do
    which $command &>/dev/null && echo "$command in path" || echo "$command NOT FOUND"
  done

설치가 정상적으로 되었다면 아래와같은 화면이 표시된다.

6) kubectl의 bash 쉘 자동 완성 활성화

kubectl completion bash >>  ~/.bash_completion
. /etc/profile.d/bash_completion.sh
. ~/.bash_completion

kubectl completion bash : bash의 kubectl 완성 스크립트 출력

참고 : https://kubernetes.io/ko/docs/tasks/tools/install-kubectl/

7) AWS ALB Ingress Controller 버전 설정

echo 'export ALB_INGRESS_VERSION="v1.1.8"' >>  ~/.bash_profile
.  ~/.bash_profile

3. Workspace를 위한 IAM Role 생성

1) IAM 역할

2) 개체 선택 -> 다음:권한

AWS 서비스, EC2를 선택한다.

3) 권한 정책 연결 -> 다음:태그

AdministratorAccess를 선택한다.

4) 태그 설정(선택) -> 다음:검토  

Name : eksworkshop-admin 태그를 추가한다.

5) 검토 -> 역할 만들기

역할 이름 : eksworkshop-admin 설정한다.

4. IAM Role 적용

1) EC2 > 인스턴스 

[보안] > [IAM 역할 수정] 을 선택한다. 

2) IAM 역할 수정 -> 적용

5. IAM 설정 업데이트

1) workspace > 기어 버튼 > AWS Settings > Credentials 비활성화

2) 기존 creadentials 파일 삭제

임시 credentials 파일이 이미 존재할 수도 있기 때문에,

기존 credentials 파일을 삭제한다.

rm -vf ${HOME}/.aws/credentials

3) aws cli 구성

현재 region을 default로 하여 aws cli를 설정해야한다.

export ACCOUNT_ID=$(aws sts get-caller-identity --output text --query Account)
export AWS_REGION=$(curl -s 169.254.169.254/latest/dynamic/instance-identity/document | jq -r '.region')

4) AWS_REGION 설정 확인 및 MASTER_ARN 설정

AWS_REGION이 원하는 region으로 되었는지 확인한다.

test -n "$AWS_REGION" && echo AWS_REGION is "$AWS_REGION" || echo AWS_REGION is not set

되어 있으면, AWS_RESION is [설정한 region] 형식으로 출력된다.

MASTER_ARN 값을 설정한다. (alias 다음에 나오는 eksworkshop는 KMS 고객관리형 키의 키 값이라고 보면된다. 없으면 새로 생성을 해줘야 한다.)

export MASTER_ARN=$(aws kms describe-key --key-id alias/eksworkshop --query KeyMetadata.Arn --output text)

MASTER_ARN 값 확인

echo "export MASTER_ARN=${MASTER_ARN}" | tee -a ~/.bash_profile

- 만약 아래와 같은 오류가 발생한다면, kms키를 새로 생성해 줘야 한다.

seungkim:/ $ export MASTER_ARN=$(aws kms describe-key --key-id alias/eksworkshop --query KeyMetadata.Arn --output text)                                                                                         
An error occurred (NotFoundException) when calling the DescribeKey operation: Alias arn:aws:kms:ap-northeast-2:123456789011:alias/eksworkshop is not found.
더보기

- kms 키 생성 방법 (aws 공식문서 참조)

  1. AWS KMS 콘솔(https://console.aws.amazon.com/kms)을 엽니다.
  2. AWS 리전을 변경하려면 페이지의 오른쪽 위 모서리에 있는 리전 선택기를 사용합니다.
  3. 해당 계정에서 직접 생성하고 관리하는 키를 보려면 탐색 창에서 고객 관리형 키를 선택합니다. AWS에서 계정을 위해 직접 생성하고 관리하는 키를 보려면 탐색 창에서 AWS 고객 관리형 키를 선택합니다.
  4. KMS 키의 키 ID를 찾으려면 KMS 키 별칭으로 시작하는 행을 확인합니다.
  5. 키 ID 열은 기본적으로 테이블에 표시됩니다. 키 ID 열이 테이블에 표시되지 않으면 KMS 키 테이블 사용자 지정 단원에 설명된 절차에 따라 복원합니다. KMS 키의 키 ID는 세부 정보 페이지에서도 볼 수 있습니다.

1. 키생성 
2. 옵션설정

3. 레이블 추가

4. 키 관리 권한 정의에서 자신의 아이디를 선택 후 다음으로 이동, 키 사용 권한 정의에서도 자신의 아이디 체크 후 다음으로 이동.
5. 검토 화면에서 최종적으로 설정된 내역 확인 후 완료 클릭하여 생성을 종료한다.

5) 설정값 bash_profile 저장

설정한 ACCOUNT_ID, AWS_REGION을 bash_profile에 저장한다.

echo "export ACCOUNT_ID=${ACCOUNT_ID}" | tee -a ~/.bash_profile
echo "export AWS_REGION=${AWS_REGION}" | tee -a ~/.bash_profile
aws configure set default.region ${AWS_REGION}
aws configure get default.region

6) IAM Role 확인

GetCallerIdentity CLI command를 사용하여 Cloud9 IDE가 올바른 IAM Role을 사용하고 있는지 확인한다.

aws sts get-caller-identity --query Arn | grep eksworkshop-admin -q && echo "IAM role valid" || echo "IAM role NOT valid"

IAM Role이 정상적으로 유효하다면 아래와같이 출력된다.

이 과정에서 NOT valid라고 출력되면, 이후의 과정을 절대 진행하지 말고 돌아가서 이 과정을 다시 확인하자.

참고로 grep 후에 나오는 아이디는 자신의 계정 아이디를 넣으면된다.

2장. Eksctl을 이용해 cluster 시작하기

1. eksctl 설치

1) eksctl 바이너리 설치

curl --silent --location "https://github.com/weaveworks/eksctl/releases/latest/download/eksctl_$(uname -s)_amd64.tar.gz" | tar xz -C /tmp

sudo mv -v /tmp/eksctl /usr/local/bin

2) eksctl 설치 확인

eksctl 명령이 작동하는지 확인한다.

eksctl version

3) eksctl의 bash 쉘 자동 완성 활성화

eksctl completion bash >> ~/.bash_completion
. /etc/profile.d/bash_completion.sh
. ~/.bash_completion

2. EKS cluster 생성

주의사항

- 1장 맨 마지막 단계인 IAM Role 유효성 검사를 한 후 이 단계를 진행한다.

   왜? EKS cluster가 IAM Role을 사용해 구축되지 않으면 이후 모듈에 필요한 kubectl 명령 실행 불가 

- EKS 1.17을 배포하려면 eksctl 버전 0.24.0 이상이어야 한다.

1) eksctl 배포 파일 생성

배포파일명 : eksworkshop.yaml

cat << EOF > eksworkshop.yaml
---
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: eksworkshop-eksctl
  region: ${AWS_REGION}
  version: "1.17"

managedNodeGroups:
- name: nodegroup
  desiredCapacity: 3
  ssh:
    allow: true
    publicKeyName: eksworkshop

# To enable all of the control plane logs, uncomment below:
# cloudWatch:
#  clusterLogging:
#    enableTypes: ["*"]

secretsEncryption:
  keyARN: ${MASTER_ARN}
EOF

2) 작성한 파일로 eksctl cluster 생성

eksworkshop.yaml을 eksctl cluster을 생성할 때 입력한다.

eksctl create cluster -f eksworkshop.yaml

EKS 및 모든 dependency를 시작하는데 약 15분이 소요된다.(생성중인 화면)

만약에 아래와 같은 오류가 발생한다면... 키를 다시 생성해 주면 된다...

Error: cannot find EC2 key pair "eksworkshop"

2021.10.10 - [AWS/EKS] - 실수로 keypair 파일을 삭제 했을 경우

 

실수로 keypair 파일을 삭제 했을 경우

# EKS 실습을 하던중 실수로 키페어를 삭제했다. 더이상 EKS 및 오토스케일링 그룹에서 스케일 아웃과 스케일 인이 정상적으로 진행되지 않고, 오류를 내뱉고 있다. - 해결방법은 생각보다 매우 간

may9noy.tistory.com

- 키 생성하고 다시 빌드를 수행해보자~

만약 keyARN: ${MASTER_ARN} 관련 에러가 발생한다면 아래의 명령어로 확인하자.

5. Configurar nuestra llave de cifrado con AWS KMS

  • Crear una llave KMS:
aws kms create-alias --alias-name alias/eksworkshop --target-key-id $(aws kms create-key --query KeyMetadata.Arn --output text)
  • Exportar la variable:
export MASTER_ARN=$(aws kms describe-key --key-id alias/eksworkshop --query KeyMetadata.Arn --output text)
  • agregarlo al bash profile
echo "export MASTER_ARN=${MASTER_ARN}" | tee -a ~/.bash_profile

- 그리고 만약 위의 명령어를 실행 후 아래의 에러가 발생할 경우 해당 키페어를 생성해 주면 된다.

Error: cannot find EC2 key pair "eksworkshop"

3. EKS cluster 테스트

1) 생성된 노드 확인

kubectl get nodes # if we see our 3 nodes, we know we have authenticated correctly

이상이 없다면 아래와 같이 출력된다.

2) workshop 전체에서 사용할 Worker Role Name을 Export하기 ($STACK_NAME 지정 안되어 있을경우 지정)

STACK_NAME=$(eksctl get nodegroup --cluster eksworkshop-eksctl -o json | jq -r '.[].StackName')
ROLE_NAME=$(aws cloudformation describe-stack-resources --stack-name $STACK_NAME | jq -r '.StackResources[] | select(.ResourceType=="AWS::IAM::Role") | .PhysicalResourceId')
echo "export ROLE_NAME=${ROLE_NAME}" | tee -a ~/.bash_profile

- 클리스터를 생성하고 node 조회 명령어로 조회를 해본결과 아래와 같은 오류가 발생 하였다.

error: You must be logged in to the server (Unauthorized)

- 위의 오류가 발생하면, 내 보안 자격 증명에서 엑세스키를 재 설정 해줘야 한다.

export AWS_ACCESS_KEY_ID="내 IAM ACCESS_KEY_ID"
export AWS_SECRET_ACCESS_KEY="내 IAM SECRET_ACCESS_KEY"

- 재 설정 후 kubectl get nodes 명령어를 실행한 결과 정상적인 조회가 가능하였다.

seungkim:~/environment $ kubectl get nodes
NAME                                                STATUS   ROLES    AGE   VERSION
ip-192-168-24-56.ap-northeast-2.compute.internal    Ready    <none>   22m   v1.21.5-eks-bc4871b
ip-192-168-54-130.ap-northeast-2.compute.internal   Ready    <none>   22m   v1.21.5-eks-bc4871b
ip-192-168-87-102.ap-northeast-2.compute.internal   Ready    <none>   22m   v1.21.5-eks-bc4871b

3장. Helm CLI 설치

1. Helm CLI 설치 전 

Helm CLI란?

Kubernetes를 위한 패키지 매니징 툴, Kubernets용으로 제작된 소프트웨어를 찾고 공유하고 사용하는 툴이다.
node.js의 npm과 비슷한 형태로 Kubernetes의 패키지 배포를 가능하게 하는 툴이라고 보면 된다.
chart라고 부르는 패키지 포맷을 사용하는데 chart는 Kubernetes 리소스를 describe하는 파일들의 집합이다.

1) 설치 전, 상호 작용할 command line 툴 설치

curl -sSL https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 | bash

2) 버전 확인

helm version --short

2. Helm CLI 설치

1) Chart 리포지토리 구성

첫번째로, Chart 리포지토리를 구성한다.
Chart 리포지토리는 Linux에서의 APT 또는 yum 리포지토리와 비슷하거나 macOS에서 Homebrew용 Taps와 유사하다.
stable 리포지토리를 다운로드한다.

#아래 명령어 안먹음(예전에는 됐었는데...)
#helm -n wordpress-cwi install understood-zebu bitnami/wordpress
# 이작업은 안해도 될거 같음
#helm repo add bitnami https://charts.bitnami.com/bitnami
#helm install my-release bitnami/wordpress

2) 설치가능한 charts 출력

설치한 후엔 설치할 수 있는 charts 를 나열할 수 있다.

helm search repo stable

3) helm의 bash 쉘 자동 완성 활성화

helm completion bash >> ~/.bash_completion
. /etc/profile.d/bash_completion.sh
. ~/.bash_completion
source <(helm completion bash)

4장. WordPress 설치

1. WordPress 설치

1) WordPress를 EKS cluster에 설치

bitnami charts 레포지토리를 사용해 WordPress를 EKS cluster에 설치한다.
Cloud9 Workspace 터미널에선 아래와 같은 명령을 실행해 WordPress 및 해당 데이터베이스를 배포하면 된다.

# Create a namespace wordpress
kubectl create namespace wordpress-cwi

# Add the bitnami Helm Charts Repository
helm repo add bitnami https://charts.bitnami.com/bitnami

# Deploy WordPress in its own namespace
helm -n wordpress-cwi install understood-zebu bitnami/wordpress

위의 chart가 생성한 것

- 2개의 persistent volumes
- 다수의 secrets
- MariaDB를 위한 1개의 StatefulSet
- WordPress를 위한 1개의 배포

-# 생성된 pod 상태 확인

seungkim:~/environment $ kubectl get pod
NAME                                    READY   STATUS    RESTARTS   AGE
my-release-mariadb-0                    1/1     Running   0          4m18s
my-release-wordpress-5b47857bbb-xzfct   1/1     Running   0          4m18s

2) 배포 상태 확인

kubectl -n wordpress-cwi rollout status deployment understood-zebu-wordpress

제대로 배포됐다면 아래와같이 화면에 나타난다.

2. WordPress 접속

1) public URL 테스트

* LoadBalancer를 사용할 수 있으려면 몇 분이 소요된다.

WordPress 사이트의 URL을 출력한다.

export SERVICE_URL=$(kubectl get svc -n wordpress-cwi understood-zebu-wordpress --template "{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}")

echo "Public URL: http://$SERVICE_URL/"

2) 시작 페이지 확인

위에 출력된 URL로 들어가보면 샘플 템플릿이 적용된 WordPress 사이트가 나온다.

3) admin 인터페이스 테스트

위의 상태로는 관리자 페이지로 들어갈 수 없다.
관리자 URL과 패스워드를 설정해준다.

export ADMIN_URL="http://$SERVICE_URL/admin"
export ADMIN_PASSWORD=$(kubectl get secret --namespace wordpress-cwi understood-zebu-wordpress -o jsonpath="{.data.wordpress-password}" | base64 --decode)

echo "Admin URL: http://$SERVICE_URL/admin
Username: user
Password: $ADMIN_PASSWORD"

# 아래와 같은 정보가 출력된것을 확인 할 수 있다.
seungkim:~/environment $ export ADMIN_URL="http://$SERVICE_URL/admin"
seungkim:~/environment $ export ADMIN_PASSWORD=$(kubectl get secret --namespace wordpress-cwi understood-zebu-wordpress -o jsonpath="{.data.wordpress-password}" | base64 --decode)
seungkim:~/environment $ echo "Admin URL: http://$SERVICE_URL/admin
> Username: user
> Password: $ADMIN_PASSWORD"
Admin URL: http://a79f8932b5a0942a39b7324883c8a29a-519472971.ap-northeast-2.elb.amazonaws.com/admin
Username: user
Password: bCKcd4Nmwk

4) Admin URL 테스트

위에서 출력된 Admin URL을 들어가면 다음 화면이 표시된다.

5) Admin 페이지 로그인

Username or Email Address : user
Password : 위에 출력된 비밀번호
로그인 이후 아래와 같은 화면으로 이동됐다면 EKS cluster에서 MariaDB가 지원하는 Wordpress 설치를 성공적으로 실행한 것이다.

이로써 AWS EKS에서 Wordpress를 실행하는 구성에 대해서 알아보았다.

- 끝 -

728x90
반응형