AKS에 thanos와 prometheus, grafana를 사용하여 모니터링 시스템을 구축하였습니다. 이 내용에서 추가적으로 cicd를 구축해보는 것이 이번 내용입니다. 이전글과 연동하셔도 상관 없으며 따로 구축하셔도 무방한 내용입니다. Azure CLI에 대한 코드도 적어두었습니다. 해당 코드는 vscode에서 powershell로 Azure cli를 사용하고 있습니다.

사전 구축 내용

만약 이미 aks 리소스가 존재한다면 VM(ubuntu)만 한개 생성해주시면 됩니다.

가장 먼저 Azure cli를 사용하기 위하여 login을 합니다. 해당 ID에 여러개의 구독을 가지고 있거나 여러 테넌트에 등록된 계정이라면 구성을 원하는 구독을 세팅하는 작업이 필요합니다.

# use azure cli  
az login

# default subscription check
az group list --output table

# subscription setting
az account set --subscription "Subscription ID"

구독이 설정 되었다면 이후에 jenkins용 vm과 aks를 생성합니다. 이전에 말씀드린 것과 같이 VScode에서 powershell로 azure-cli를 사용중입니다. 또한 아래 작업중에는 ACR 생성 및 ACR로 접근하기 위해 AKS 클러스터에 ACR Role을 할당하는 작업이 들어가 있습니다. 해당 내용은 #Generate acr과 #connect aks to acr (role) 부분이니 참고해주시기 바랍니다. 이 작업을 수행하지 않으면 image에 에러가 나오게 됩니다.

# Variable
$aksrg="rg-krc-dev-aks01"
$aksvnet01="vnet-krc-dev-aks01"
$akssnet01="snet-krc-dev-aks01"
$akscluster="aks-krc-dev-app01"
$aksnodepool="nokrcdaks01"
$aksnoderg="rg-krc-dev-node01"
$vmsnet01="snet-krc-dev-vm01"
$vmnsg01="nsg-krc-dev-vm01"
$vmpip01="pip01-krc-dev-jenkins01"
$vmnic01="nic01-krc-dev-jenkins01"
$vmosdisk="osdisk-krc-dev-jenkis01"
$vmname="vmkrcdevjenkins"
$vmusername="azureuser"
$vmpassword="Password1234"

# config resource group
az group list --output table

# create resource group, virtual network, subnet
az group create -n $aksrg --location koreacentral
az network vnet create -g $aksrg -n $aksvnet01 --subnet-name $akssnet01 --address-prefixes "10.0.0.0/16" --subnet-prefixes "10.0.0.0/24" 
az network vnet subnet create -g $aksrg --vnet-name $aksvnet01 -n $vmsnet01 --address-prefixes "10.0.1.0/24"

# nsg create for vm 
az network nsg create -g $aksrg -n $vmnsg01
az network nsg rule create -g $aksrg --nsg-name $vmnsg01 -n nsgsr-vm-ssh --destination-port-ranges 22 --access Allow --priority 100 --description "ssh" 
az network nsg rule create -g $aksrg --nsg-name $vmnsg01 -n nsgsr-vm-http --destination-port-ranges 80 --access Allow --priority 200 --description "http" 
az network nsg rule create -g $aksrg --nsg-name $vmnsg01 -n nsgsr-vm-jenkins --destination-port-ranges 8080 --access Allow --priority 300 --description "jenkins" 
az network nsg rule create -g $aksrg --nsg-name $vmnsg01 -n nsgsr-vm-go --destination-port-ranges 9000 --access Allow --priority 400 --description "when i make my project, i use this port for golang" 
# connect nsg to subnet
az network vnet subnet update -g $aksrg -n $vmsnet01 --vnet-name $aksvnet01 --network-security-group $vmnsg01

# create vm with pip
az network public-ip create --name $vmpip01  -g $aksrg --sku Standard
az network nic create -g $aksrg -n $vmnic01 --vnet-name $aksvnet01 --subnet $vmsnet01 --private-ip-address 10.0.1.4 --location koreacentral --public-ip-address $vmpip01
az vm create -g $aksrg --name $vmname --image UbuntuLTS --admin-username $vmusername --admin-password $vmpassword --size Standard_D2S_v5 --os-disk-name $vmosdisk --os-disk-size-gb 30 --os-disk-caching ReadWrite --storage-sku StandardSSD_LRS --nics $vmnic01

# Generate aks using azurecni
az aks create --resource-group $aksrg --name $akscluster --network-plugin azure --nodepool-name $aksnodepool --node-vm-size standard_d2s_v5 --node-count 1 --vnet-subnet-id $(az network vnet subnet list --resource-group $aksrg --vnet-name $aksvnet01 --query "[0].id" --output tsv) --node-resource-group $aksnoderg --docker-bridge-address 172.17.0.1/16 --dns-service-ip 10.2.0.10 --service-cidr 10.2.0.0/24 --generate-ssh-keys

# Generate acr
az acr create --name k8scicdacrtest01 -g $aksrg --sku Basic --admin-enabled true

# connect aks to acr (role)
az aks update -n $akscluster -g $aksrg --attach-acr $(az acr list --resource-group $aksrg --query "[0].id" --output tsv)

# connect cluster
az aks get-credentials --resource-group $aksrg --name $akscluster

# config connection
kubectl get nodes

jenkins용 vm를 생성하는 이유는 기존에 jenkins 내부에 플러그인들이 2024-02-29에 사라질 예정입니다. 이에 대안으로 Azure에서 Azure-cli 사용을 권장하고 있습니다. 자세한 내용은 링크를 확인해주세요

Virtual machine

기본적으로 VM에서 jenkins의 서비스를 실행시키기 위해서는 다운로드 받아야 되는 것들이 존재합니다. 기본적인 요소들은 같지만 언어는 사용하는 사람에 따라 다르니 해당 부분은 직접 설치해주시기 바랍니다. 참고로 ubuntu 22.04버전을 사용중입니다.

1. Azure-cli 설치

jenkins 플러그인의 대체로 Azure-cli를 권장하므로 이를 다운로드 받아 사용해야 합니다.

sudo apt-get install ca-certificates curl apt-transport-https lsb-release gnupg -y
sudo mkdir -p /etc/apt/keyrings
curl -sLS https://packages.microsoft.com/keys/microsoft.asc |
    gpg --dearmor |
    sudo tee /etc/apt/keyrings/microsoft.gpg > /dev/null
sudo chmod go+r /etc/apt/keyrings/microsoft.gpg
AZ_REPO=$(lsb_release -cs)
echo "deb [arch=`dpkg --print-architecture` signed-by=/etc/apt/keyrings/microsoft.gpg] https://packages.microsoft.com/repos/azure-cli/ $AZ_REPO main" |
    sudo tee /etc/apt/sources.list.d/azure-cli.list
sudo apt-get update
sudo apt-get install azure-cli -y

2. jenkins 설치

sudo apt install openjdk-11-jre -y
curl -fsSL https://pkg.jenkins.io/debian-stable/jenkins.io-2023.key | sudo tee /usr/share/keyrings/jenkins-keyring.asc > /dev/null
echo 'deb [signed-by=/usr/share/keyrings/jenkins-keyring.asc] https://pkg.jenkins.io/debian-stable binary/' | sudo tee /etc/apt/sources.list.d/jenkins.list > /dev/null
sudo apt-get update && sudo apt-get install jenkins -y
sudo service jenkins restart
sudo systemctl status jenkins.service

3. docker 설치

sudo apt-get install apt-transport-https ca-certificates curl software-properties-common -y
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
sudo apt-key fingerprint 0EBFCD88
sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"
sudo apt-get update
sudo apt-get install docker-ce -y
sudo systemctl status docker.service

4. kubernetes 설치 및 인증

쿠버네티스의 경우 kubectl을 사용하기 위해 필요합니다. 간단하게 설치가 가능합니다. 이때도 구독 확인 필수

az login
sudo az aks install-cli
az aks get-credentials --resource-group rg-krc-dev-aks01 --name aks-krc-dev-app01

(선택)5. 언어 설치

ubuntu에서 Golang을 설치하는 과정입니다. 최신버전은 링크를 확인해주시기 바랍니다

wget https://go.dev/dl/go1.20.5.linux-amd64.tar.gz
sudo tar -xvf go1.20.5.linux-amd64.tar.gz -C /usr/local

# .profile 수정
vi ~/.profile

#마지막 부분에 추가
export GOROOT=/usr/local/go
export GOPATH=$HOME/go
export PATH=$GOPATH/bin:$GOROOT/bin:$PATH

# 환경 변수 적용 
. ~/.profile

# 설치 확인
go version
-- go version go1.20.5 linux/amd64 과 같이 버전이 출력되면 완료

# test 용 ping pong
mkdir -p ~/go/main
cd ~/go/main

vi main.go
-- 아래 코드 입력 간단한 ping pong 예제
package main

import(
        "net/http"
        "github.com/gin-gonic/gin"
)

func main() {
        r := gin.Default()
        r.GET("ping", func(c *gin.Context){
                c.JSON(http.StatusOK, gin.H{
                        "message":"pong",
                })
        })
        r.Run(":9000")
}

---
go mod init main.go
go mod tidy
go run main.go

공인ip주소:9000/ping으로 접근 후 아래 사진과 같이 나오면 완료 혹시 공인 ip 주소가 기억 나지 않는경우

curl ifconfig.me

6. kube 파일 소유권 변경

.kube파일과 docker를 젠킨스로 소유자 및 소유 그룹 변경을 실시합니다.

sudo usermod -aG docker jenkins;
sudo usermod -aG docker azureuser;
sudo touch /var/lib/jenkins/jenkins.install.InstallUtil.lastExecVersion;
sudo service jenkins restart;
sudo cp -R ~/.kube /var/lib/jenkins/
sudo chmod 755 /var/lib/jenkins/
sudo chown -R jenkins:jenkins /var/lib/jenkins

jenkins 설정

공인ip:8080으로 접근하면 jenkins의 초기 화면이 나오는데 initialPassword를 통하여 진입합니다.

sudo cat /var/lib/jenkins/secrets/initialAdminPassword

Select plugins to install 클릭 후 github 선택, install 영겁의 시간을 기다립니다... 계정을 설정합니다. freestyle로 프로젝트 생성 생성 이후 관리 -> system 에서 아래쪽에 Global properties가 존재합니다. 이 부분에 ACR의 주소를 등록시켜줍니다. acr의 주소는 "acr생성시작성된이름.azureacr.io"입니다.

만약 기억이 나지 않는다면 콘솔로 접근하여 확인하시거나 az acr list -g $aksrg 를 입력하여 확인하시기 바랍니다.

이후 jenkins의 자격증명을 위해 acr의 서비스 주체를 생성합니다.

az ad sp create-for-rbac
-- 입력시 아래와 같은 결과물이 나오는데 메모필수
{
  "appId": "",
  "displayName": "",
  "password": "",
  "tenant": ""
}
--
$ACR_ID=$(az acr show --resource-group $aksrg --name k8scicdacrtest01 --query "id" --output tsv)
az role assignment create --assignee "appId값 입력" --role Contributor --scope $ACR_ID

여기까지 진행하면 jenkins의 ACR 접근을 위한 RBAC이 생성됩니다. 이제 jenkins에 해당 id를 등록시킵니다. 관리 -> Credentials -> System -> Global credentials (unrestricted)로 들어가 새로운 자격증명을 생성합니다. 여기서 Username은 appId이며 Password는 서비스 주체의 password입니다. 이 내용은 위에서 메모한 내용을 기반으로 합니다. ID는 acr-credentials와 같이 적당히 적으시면 됩니다.

github로 이동하셔서 Personal access Token을 생성합니다.

생성하며 나온 내용 또한 jenkins에 등록시킵니다

등록 이후 github에서 webhook으로 등록시킵니다.

작업 구성

jenkins의 credencial까지 등록을 완료하였다면 이제 실제 작업을 구성할 차례입니다. 이전에 freestyle로 생성한 프로젝트에서 구성작업을 실시합니다. github 주소 및 등록된 credential을 적용합니다.

Build Steps을 추가합니다.

WEB_IMAGE_NAME="${ACR_SERVER}/ping:${BUILD_NUMBER}"
docker build -t $WEB_IMAGE_NAME ./ping
docker login ${ACR_SERVER} -u ${ACR_ID} -p ${ACR_PASSWORD}
docker push $WEB_IMAGE_NAME

# Update kubernetes deployment with new image.
WEB_IMAGE_NAME="${ACR_SERVER}/ping:${BUILD_NUMBER}"
kubectl set image deployment/ping ping=$WEB_IMAGE_NAME

-- 빌드 이전에 aks cluster에 deployment를 배포하여야 합니다. 필자는 deployment의 이름을 ping으로 설정하였기 때문에 build step에 deployment/ping의 이미지를 변경하는 것으로 설정을 해두었습니다. 이 부분은 각자에 맞게 설정하면 되겠습니다.

ping/deployment

아래는 필자의 간단한 ping.yaml의 간단한 예제를 적어두었습니다. 이를 이용하여 이미지를 변경하는 형식으로 진행되는 cicd입니다.

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: ping
spec:
  replicas: 4
  selector:
    matchLabels:
      app: ping
  template:
    metadata:
      labels:
        app: ping
    spec:
      containers:
      - name: ping
        image: aak1009/pingpong:latest
        ports:
        - containerPort: 9000
        resources:
         requests:
           memory: "64Mi"
           cpu: "125m"
         limits:
           memory: "128Mi"
           cpu: "250m"
---
apiVersion: v1
kind: Service
metadata:
  name: ping
spec:
  type: LoadBalancer
  ports:
  - port: 9000
  selector:
    app: ping

k8s에서는 Pod 교체 전략을 변경할 수 있습니다. 여기서 교체전략은 Rolling Update와 Recreate 2개의 값이 존재하며 RollingUpdate는 Pod를 하나씩 죽이고 새로 띄우면서 순차적으로 교체하는 방식이고 Recreate는 기존 파드를 모두 삭제한 이후 새로운 파드를 생성하는 방식입니다. k8s deployment의 기본 속성은 RollingUpdate이므로 따로 명시하지 않았습니다. 만약 이를 명시한다면 아래와 같은 yaml파일과 같이 지정하면 됩니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ping
spec:
  replicas: 4
  strategy:
      type: RollingUpdate
    rollingUpdate:
        maxUnvailable: 2
        maxSurge: 4 
... 이하생략

여기서 maxUnvailable은 롤링 업데이트 시 동시에 삭제할 수 있는 파드의 최대 개수를 의미하고, maxSurge 는 동시에 생성될 수 있는 파드의 최대 값을 의미합니다. (기본 25%) 빠르게 업데이트 하는 것도 중요하지만 이후에 벌어질 이펙트를 대비하여 적절한 값을 주는 것이 중요합니다. 이제 이 yaml파일을 이용하여 pod와 svc를 배포하고 빌드를 하시면 됩니다.

build

젠킨스로 이동하여 지금 빌드를 누르면 해당 파일을 빌드할 수 있습니다. 빌드를 실행시키게 되면 Build History가 생기면서 성공과 실패를 확인 할 수 있습니다. 값이 잘 변경됨을 확인 할 수 있었습니다. 이전에 webhook을 등록시켰다면 로컬에서 git으로 main브런치를 이용하여 push하게 되면 github에서 webhook으로 젠킨스에게 해당 내용을 보내게 되고 자동으로 빌드를 하게됨을 볼 수 있습니다.

물론 git의 브랜치를 변경하여 테스트를 진행해도 빌드 진행으로 이어지지 않는 것을 확인할 수 있습니다. git의 브랜치에 대한 명령어는 다음과 같습니다.

브랜치 생성
git branch 이름
브랜치 확인
git branch
브랜치 변경
git checkout 브랜치이름

URL에 get 요청으로 Rollingupdate를 볼 수도 있습니다.

마무리

마지막으로 해당 내용의 과정을 설명하면 깃헙으로 push -> github에서 웹 훅을 젠킨스에게 전달 -> 젠킨스에서 브랜치 확인 및 빌드시작(도커 이미지를 acr에 저장후 aks의 이미지 변경)

지금까지 사용한 모든 리소스를 삭제하며 마무리합시다.

az group delete -g "그룹이름"

이전 AKS front + back 서버 구축(2)을 마친 이후에 작업을 진행해도 되지만 굳이 안해도 상관없는 내용입니다. AKS 클러스터 생성과 노드 확인후 credentials을 얻은 후에 노드를 확인했다고 한다면 큰 문제 없이 진행될 것입니다. 현재 window환경에서 작업 중입니다.

구축

모니터링 시스템을 구축하기 앞서 먼저 helm을 설치해야 합니다. 윈도우 pc의 경우 helm을 설치하기 위해 패키지 매니저인 chocolatey를 설치한 이후 kubernetes-helm을 인스톨 하는 방식으로 진행합니다.

helm설치
1. PowerShell 관리자 모드 실행

2. Get-ExecutionPolicy  (만약 Restricted라면 AllSigned나 Bypass로 설정)
2.2. Set-ExecutionPolicy AllSignedSet-ExecutionPolicy Bypass -Scope Process

3. Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://community.chocolatey.org/install.ps1'))

4. choco

설치 완료후 choco를 입력했을 경우 아래와 같이 나오면 성공입니다. 만약 이상이 생긴다면 chocolatey의 공식 홈페이지로 이동하여 설치 방법을 다시 확인하시면 됩니다. 이후 choco를 이용하여 helm을 설치합니다.

helm 설치

choco install kubernetes-helm

helm version

설치 완료 이후 helm version을 이용하여 설치를 확인합니다. 위와같이 version 정보가 출력되면 설치가 완료된 상태입니다.

이제 간단한 모니터링 시스템을 구축하시면 됩니다. 모니터링 시스템은 prometheus와 grafana를 이용하게 됩니다.

Prometheus 및 Grafana용 Helm 저장소 추가
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts

helm 업데이트
helm repo update

aks에 그라파나, 프로메테우스 배포
helm install prometheus prometheus-community/kube-prometheus-stack --namespace monitoring --create-namespace

설치 확인 
kubectl get all -n monitoring

prometheus의 helm 차트가 궁금하신 분은 prometheus-community/helm-chars에서 확인이 가능합니다.

위와 같이 나오면 성공입니다. 이제 prometheus와 grafana로 접속하여 확인하도록 합니다.

그라파나 접근
kubectl port-forward svc/prometheus-grafana -n monitoring 4000:80 # (localhost 로 접근가능)

- id : admin / passwd : prom-operator
이후 데시보드 확인

prometheus 접근
kubectl port-forward svc/prometheus-kube-prometheus-prometheus -n monitoring 4001:9090 #(localhost 로 접근가능)

localhost로 접근하여 아이디 비밀번호를 입력후 dashboards로 가게될 경우 아래와 같은 모습을 볼 수 있습니다.

Namespace(Pods)를 확인하게 될경우 pod들의 메트릭 값을 볼 수 있습니다. 부하를 걸어 확인해봅시다. 아주 잘 동작함을 볼 수 있었습니다.

정리

prometheus에 접속하는 방법도 동일하게 port-forwarding으로 진행이 가능하며 해당 prometheus에서 alert도 설정이 가능하게 되어 있습니다. 하지만 보기 쉽게 설정되어 있는 것이 grafana이다 보니 grafana로 대부분을 확인을 하였습니다. 또한 prometheus는 더 공부가 필요한 부분이 있기 때문에 더 공부 후에 따로 추가하도록 하겠습니다.

AKS 클러스터 구축 - 이전 자료를 확인하여 주시기 바랍니다. 링크

frontend (react) - 저는 프론트 엔드로 react를 선택하였고 nginx를 이용할 예정입니다. github에 있는 crud를 간단하게 구축해놓은 소스를 이용하여 조금 수정하여 사용하였습니다. 출처는 링크를 참조해 주시기 바랍니다

backend server (go) - gin-gonic과 gorm을 이용한 백엔드 서버를 구축하여 crud api server를 구축하여 사용하였습니다.

DB (Azure Database for mysql)

구축

가장 먼저 해야할 내용은 front와 back 서버를 docker image로 만드는 것입니다. 이를 위해 Dockerfile을 생성합니다.

#Go server Dockerfile

FROM golang:1.18-alpine

WORKDIR /app

COPY . ./

RUN go mod download
RUN go build -o /goserver

EXPOSE 8081

CMD [ "/goserver" ]

프론트 엔드는 먼저 nginx.conf파일과 .env.production 파일을 생성하고 적용한 후에 Docker image로 만드는 작업을 진행하였습니다. .env.production은 package.json과 같은 위치에 두었습니다.

.env.production file

REACT_APP_URL=/api

그리고 이를 적용하기 위해 env-cmd를 이용하여 package.json에 적용하는 방식으로 진행하였습니다. env-cmd는 npm으로 설치하였습니다.

또한 GET 호출을 하는 부분에 URL을 아래 사진과 같이 변경하였습니다. 이렇게 하면 /api/crud로 호출이 진행되게 됩니다.

이제 nginx.conf 파일을 생성합니다. 저는 ./conf/nginx.conf 위치에 두었습니다. 아래 backend:8081 부분은 후에 service를 생성할 때 지정할 svc의 이름과 포트번호 입니다. 또한 /api 부분의 rewrite를 통하여 /api 부분을 제거한 이후 부분으로 백서버와 소통이 진행되게 됩니다. 따라서 실제로 백엔드로 전달되는 부분은 /crud로 진행되게 됩니다.

upstream backend {
    server backend:8081;
}

server {
    listen 80;
    server_name frontend;

    location / {
        root /usr/share/nginx/html;
        index index.html index.htm;
        try_files $uri /index.html;
    }

    location /api {
        rewrite ^/api(.*)$ $1?$args break;
        proxy_pass http://backend;
    }
}

이제 프론트에 대한 Dockerfile을 생성합니다.

FROM node:16.18-alpine as builder

WORKDIR /app

COPY . ./

RUN npm i

RUN npm run build

FROM nginx

COPY conf/nginx.conf /etc/nginx/conf.d/default.conf

COPY --from=builder /app/build/. /usr/share/nginx/html

각각의 Dockerfile을 생성하였다면 docker build 명령어를 이용하여 빌드를 진행합니다. 이후 docker hub로 push까지 진행하였습니다.

docker build -t DockerHubId/이름:태그 Dockerfile위치
docker push DockerHubId/이름:태그

이제 kubernetes에 배포하기 위한 yaml 파일을 생성합니다. 배포해야할 내용은 deployment 2개와 service 2개입니다. 먼저 web server에 대한 deployment 파일입니다. 아래와 같이 replicas로 pod의 수를 결정할 수 있으며 memory와 cpu도 제한할 수 있습니다.

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: frontend
spec:
  replicas: 3
  selector:
    matchLabels:
      app: frontend
      version: v1
  template:
    metadata:
      labels:
        app: frontend
        version: v1
    spec:
      containers:
      - name: frontend
        image: DockerID/name:tag
        ports:
        - containerPort: 80
        resources:
         requests:
           memory: "64Mi"
           cpu: "125m"
         limits:
           memory: "128Mi"
           cpu: "250m"

이후 service.yaml파일을 생성합니다. 서비스는 NodePort, LB, clusterip등으로 구성이 가능하며 default는 clusterip입니다. azure의 서비스를 같이 이용하기 위해 LB로 생성하였고 이 서비스를 apply하게 되면 azure에 LB가 생성되게 됩니다.

apiVersion: v1
kind: Service
metadata:
  name: frontend
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: frontend
    version: v1

이어서 api서버의 yaml파일입니다. yaml파일은 Deployment와 service를 함께 배포할 수 있으며 service의 annotations를 이용하여 internalLB도 생성이 가능합니다.

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: backend
spec:
  replicas: 1
  selector:
    matchLabels:
      app: backend
  template:
    metadata:
      labels:
        app: backend
    spec:
      containers:
      - name: backend
        image: Dockerhubid/name:tag
        ports:
        - containerPort: 8081
          name: app
---
apiVersion: v1
kind: Service
metadata:
  name: backend
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-internal: "true"
spec: 
  type: LoadBalancer
  ports:
  - port: 8081
  selector:
    app: backend

이제 kubectl 명령어로 배포를 진행합니다. 먼저 연결이 되어있는지 확인하기 위해서 node를 확인합니다.

노드가 확인이 된다면 apply를 통하여 배포를 진행합니다.

kubectl apply -f yaml파일

모든 파일을 배포하였다면 get 명령어를 통하여 배포 상태를 확인합니다.

kubectl get svc
kubectl get po -o wide
kubectl describe po pod이름

배포 내용을 보시면 해당 external ip가 생성이 됩니다. 해당 external ip로 접근을 해보면 정상적으로 동작하는 것을 확인할 수 있습니다. 물론 콘솔에서도 LB와 k8s의 리소스들에 대한 확인이 가능합니다.

에러

react를 처음으로 사용하는 것이다보니 여러 문제가 있었는데 그 중 가장 어려웠던 부분이 proxy에 대한 부분이였습니다. 기존에는 package.json에 proxy로 적용을 하여 진행하였었는데 build를 진행하면서 package.json에 대한 proxy가 적용이 되지 않는 것을 모르고 있었습니다. 그래서 npm의 http-middleware를 적용해 보거나 내부에 소통을 확인, request url을 변경, goserver의 문제인것인가 싶어서 goserver의 내용을 변경해보는 등 여러모로 많은 시도를 했었고 모든 시도는 실패하였습니다. 이후 더 찾아보면서 해결 방법을 발견하여 진행하여 성공하였습니다. 성공을 하긴 했지만 이 방법이 가장 좋은 해답인지는 확신하지 못하는 상태입니다.

리소스 제거

저번과 마찬가지로 az group delete를 이용하여 리소스 그룹을 제거하거나 kubectl delete -f yaml파일이름 을 이용하여 pod를 제거하거나 여러가지 방법이 있습니다. 귀찮으니 그룹을 날립니다

AKS는 Azure kubernetes service의 약자로 managed Kubernetes입니다. 그렇다면 managed와 일반 쿠버네티스의 차이점이 무엇일까요?

• non-managed k8s는 기본적으로 사용자들이 직접 관리를 해야합니다. 서버를 생성하여 마스터 노드와 워커 노드를 구분하고 각각에 k8s 소프트웨어 패키지를 생성하여 연결하는 등 여러가지 작업을 진행해야 사용 가능한 k8s가 완성이 됩니다. 이전 쿠버네티스 테스트 환경 구축을 보시면 해야할 작업들이 생각보다 많다는 것을 알 수 있습니다. 또한 관리적인 측면을 보자면 만약 노드를 늘려야 할 경우가 발생할 수 있는데 자동화를 해놓았으면 다행이지만 만약 아니라고 하면 새로운 워커노드를 생성하여 연결하는 작업들을 해줘야 합니다. 정기적인 업데이트 역시 수동으로 진행해야 하며 모든 유지 관리 작업은 수동으로 수행해야 합니다.

• managed k8s는 공급자가 제공하거나 공급자를 통해 구성하는 k8s를 말합니다. 일반적으로 AWS의 EKS, Azure의 AKS, GCP의 GKE가 있습니다. 해당 리소스를 사용하게 되면 클릭 몇번 혹은 명령어 몇줄로 k8s를 세팅할 수 있습니다. 또한 밴더사의 서비스들을 연결하여 사용할 수 있기 때문에 이부분 또한 장점으로 보인다. 관리적인 측면을 봐도 Auto Scailing Group(ASG)가 있기 때문에 노드의 수를 증가하는 부분도 이상이 없으며 업데이트 또한 수월하게 진행할 수 있다. 기본적으로 노드에 대한 모니터링이 세팅 없이 가능하다는 부분도 장점중 하나이다.

AKS 구축

AKS를 구축하기 앞서 콘솔이 아닌 Azure cli를 이용하여 구축을 진행합니다. 또한 k8s 기본 cni인 kubelet이 아닌 Azure cni를 이용하여 구축을 진행합니다.

az 로그인
az login

구독 확인 
az account list

구독 변경
az account set --subscription 구독id

리소스 그룹 생성
az group create --name k8stest --location koreacentral

vnet snet 생성
az network vnet create --resource-group k8stest --name k8stestvnet --address-prefixes "10.0.0.0/16" --subnet-name "k8ssnet" --subnet-prefixes "10.0.0.0/24"

Azure cni를 이용한 k8s 클러스터 생성
az aks create --resource-group k8stest --name 3tierCluster --network-plugin azure --node-vm-size standard_d2s_v5 --node-count 1 --vnet-subnet-id $(az network vnet subnet list --resource-group k8stest --vnet-name k8stestvnet --query "[0].id" --output tsv) --docker-bridge-address 172.17.0.1/16 --dns-service-ip 10.2.0.10 --service-cidr 10.2.0.0/24 --generate-ssh-keys

kubectl 설치
az aks install-cli

클러스터 연결
az aks get-credentials --resource-group k8stest --name 3tierCluster

클러스터 연결 확인
kubectl get nodes

모든 코드를 입력하게 될경우 위와 같은 결과를 출력할 수 있습니다. 또한 콘솔로 들어가면 잘 생성된 모습과 MC_로 시작하는 k8s nodepool이 있는 Resource group을 확인할 수 있습니다.

결론

간단하게 Managed k8s와 기본 k8s의 차이를 구분하고 AKS의 간단한 구축 방법을 이해하였습니다. 리소스 삭제는 아래 코드로 간단하게 가능합니다 (리소스 그룹을 삭제하는 코드입니다. 리소스 그룹 내에 모든 리소스가 삭제됩니다)

az group delete -g k8stest

AWS 클라우드 엔지니어로서 회사를 다니다가 Azure 회사로 이직을 하면서 그동안 느꼈던 내용을 위주로 작성을 해보았습니다. 특정 클라우드가 더 낫다고 생각하는 것 보다 이런 점이 다르다 라는 것으로 봐주시면 좋을 것 같습니다. Azure와 AWS 두개의 클라우드 모두 장단점이 존재하며 궁극적으로 조직의 특정 요구 사항과 사용 목적에 따라 클라우드를 선택하는 것이 중요하다고 생각합니다.

반박시 반박하신 분이 정답이라고 생각하시고 넘어가주세요..

계층구조

AWS와 Azure 간에 계층 구조가 서로 다릅니다. 또한 에저에서는 기본적으로 테넌트 밑에 구독이 생기는 구조로 이루어져 있으며 AWS에서는 Organization은 선택입니다. 또한 AWS에도 Resource group이 있지만 이 RG는 태그와 cloudformation 기반이며 리소스들을 관리하기 편하게 묶어주는 역활만 하기 때문에 리소스를 모두 생성하고 RG를 생성해도 문제가 없으며 삭제해도 리소스에 영향을 끼치지 않지만 Azure에서는 RG내부에 리소스를 생성하며 이 RG를 삭제하면 내부에 있는 모든 리소스가 삭제되기 때문에 구조가 다른 느낌입니다.

Resource Name

많이 사용하는 Azure와 AWS의 리소스의 이름을 비교한 표입니다. 각각 하나의 리소스 내부에서 모든 부분을 설정할 수 있는 내용들이 존재하며 가장 큰 차이점이라고 생각하는 부분은 LB에 대한 부분이라고 생각합니다. Azure에서는 7계층 - Application Gateway, 4계층 - Load Balancer라고 불리며 AWS에서는 각각 ALB, NLB로 분류됩니다.

Network

AWS에서 네트워크 설정을 할때 VPC를 생성하고 Subnet과 Route table을 생성하며 IGW를 생성해서 Route table에 연결해 주어 IGW가 연결된 Route table의 경우 퍼블릭 서브넷에 연결해 주고 IGW를 연결하지 않은 Route table의 경우는 Private Subnet에 연결해여 각각 Public Subnet과 Private 서브넷을 구성하게 되는데 Azure에서는 기본적인 Vnet을 생성후 Subnet을 생성하여 이용하며 따로 퍼블릭과 프라이빗을 구분하지 않습니다. 또한 Private Subnet에 있는 EC2가 외부와 통신하기 위해서는 NAT Gateway를 사용하여 Route table에 연결하여 이용하지만 Azure에서는 LB의 sNAT기능이 있기 때문에 따로 NAT를 연결할 필요가 없으며 LB를 이용하지 않으면 NAT gateway를 사용합니다. 신기한 부분은 Azure에서 명시적 아웃바운드 연결이 없는 경우 기본 아웃바운드 ip가 붙게되어 외부로 소통이 가능합니다. 이 ip는 고객의 소유가 아니며 변경될 수 있고 종속성에 대해 문제가 발생할 수 있으므로 명시적 아웃바운드를 연결(NAT or LB)을 하는 것이 권장됩니다. 자세한 사항은 docs를 참조하시면 됩니다.

Nameing rule

기본적으로 AWS와 Azure의 리소스 Naming에 대한 부분은 매우 큰 차이가 있습니다. AWS는 태그 기반이며 Azure는 ID 기반입니다. 따라서 AWS는 엔드 포인트를 갖는 경우를 제외한 거의 대부분의 리소스는 UTF-8기준 256자를 지원하며 이름을 변경 가능합니다. 하지만 Azure는 리소스의 이름이 ID 로 사용되기 때문에 리소스 마다 제한사항이 다릅니다. vNET의 경우 2~64글자, 영숫자, 밑줄 마침표 및 하이픈을 사용 가능합니다. 리소스의 이름을 바꾸는 것은 거의 대부분이 불가능하여 만들 당시에 오탈자가 발생하면 삭제후 다시 생성해야 합니다. 리소스에 대한 제한 사항은 docs를 통해 확인이 가능합니다.

결론

Azure와 AWS는 많은 차이점이 존재합니다. AWS 엔지니어를 하다 Azure를 하게 되면서 경험을 통해 이해하기 어려운 점을 위주로 정리를 하였습니다. 더욱 많은 내용을 알고 싶으시면 직접 경험을 해보시거나 링크를 확인하시면서 보시면 좋을 것 같습니다.

Docker 소개

• Docker container 개념

Docker 사용

• Docker 명령어
• Docker로 DB 사용하기

Docker 배포

• Docker를 활용한 어플리케이션 배포

Docker 소개

docker는 리눅스의 프로세스 격리 기술들을 활용하여 컨테이너로 실행하고 관리하는 오픈소스 프로젝트 입니다. docker container는 일종의 소프트웨어 실행에 필요한 모든 것을 포함하는 완전한 파일 시스템 안에 포함시킵니다. 여기에는 코드, 런타임, 시스템 도구, 시스템 라이브러리 등 서버에 설치되는 모든 것입니다. 따라서 실행되는 환경에 상관없이 언제나 동일하게 동작하는 것을 보증합니다.

Docker 명령어

1. docker images 현재 호스트 pc에 다운로드 되어있는 이미지 출력

2. docker ps 실행중인 컨테이너의 목록 확인 -a 옵션을 추가하면 이전에 종료되었던 컨테이너들을 포함하여 목록을 확인

3. docker build docker build -t 이름:태그 Dockerfile위치 docker image를 생성

4. docker rmi docker image 삭제

5. docker rm docker container 삭제 모든 컨테이너를 삭제하려면 docker rm -f $(docker ps -aq)

6. docker inspect docker object의 정보를 확인

7. docker logs docker container의 로그를 확인

8. docker top 실행중인 도커의 프로세스를 확인

9. docker tag 도커 이미지의 테그를 변경

10. docker exec 실행중인 도커 컨테이너 내부로 진입하기 위한 명령어

Docker로 DB 사용

mysql혹은 mariadb의 도커 이미지를 사용하여 db를 생성하는 명령어입니다.

docker run -d -p 3306:3306 -v $(pwd)/volume:/var/lib/mysql --name mariadb --env MARIADB_USER=username --env MARIADB_PASSWORD=password -- MARIADB_ROOT_PASSWORD=password mariadb:latest

저장되는 볼륨과 mariadb의 유저 정보 및 루트 패스워드를 설정하여 진입하기 위한 방법입니다.

golang Dockerfile

FROM golang:1.18-alpine WORKDIR /app COPY . ./ RUN go mod download RUN go build -o /goserver EXPOSE 8081 CMD [ "/goserver" ]

goserver라는 이름으로 빌드 후 해당이름으로 실행합니다. 이제 docker build 명령어를 통하여 go server를 빌드 합니다

docker build -t goserver .

빌드가 완료되었다면 docker run 명령어로 실행합니다

docker run -d -p 8081:8081 goserver

빌드가 성공하였다면 docker ps 명령어로 확인합니다 잘 생성됨을 확인하였습니다.

코멘토 리뷰

4주간의 짧다고 한다면 짧은 시간동안 자신이 얼마나 노력했는지가 가장 중요한 것 같다. 또한 멘토님을 어떻게 이용하였느냐로 코멘토에 대한 모든 리뷰가 갈릴 것 같다. 현업자이신 멘토님을 통해 얻을 수 있는 많은 지식을 얻은 것 같다. 선택은 본인의 몫입니다.

링크 : https://bit.ly/3D9XCOz

• CORS 개념
• Gin 설정
• DB docker로 실행하기
• Client 로 확인하기
• DB 연동(Gorm)
• Front-end 개발 산출물을 이용한 Back-end 개발

CORS

Cross-origin resource sharing의 약자로 Origin이 다른 웹 애플리케이션 간 리소스를 공유할 수 있도록 브라우저에게 알려주는 체제입니다. 브라우저가 보안상의 이유로 Origin이 다른 웹 서버에 리소스를 요청하는 것을 막는다.

# gin-gonic에서의 cors
import "github.com/gin-contrib/cors

func main() {
  router := gin.Default()
  config := cors.DefaultConfig()
  config.AllowOrigins = []string{"http://localhost:3000"}
  router.Use(cors.New(config))
  router.Run()
}

DB docker로 실행하기

• Docker란 : 리눅스의 응용 프로그램들을 프로세스 격리 기술들을 사용해 컨테이너로 실행하고 관리하는 오픈 소스 프로젝트이다.

#도커 설치
sudo apt-get update
sudo apt-get install \
    openssh-server \
    vim \
    tree \
    ca-certificates \
    curl \
    gnupg \
    lsb-release -y

sudo mkdir -p /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
  $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt-get update

sudo apt-get install docker-ce docker-ce-cli containerd.io docker-compose-plugin

도커를 설치한 후 아래와 같은 코드를 입력해 DB를 Docker로 실행하면 mariaDB가 생성된다.

docker run -d -p (내부 포트번호):(외부 포트번호) --name (컨테이너 이름) --env MARIADB_USER=(유저이름) --env MARIADB_PASSWORD=(패스워드) --env MARIADB_ROOT_PASSWORD=(root 패스워드) --env MARIADB_DATABASE=(DB 이름) mariadb:latest

내부로 진입하여 확인

docker exec -i -t (컨테이너이름) /bin/bash

혹은

#클라이언트 설치
sudo apt-get install mariadb-client

#client를 이용하여 로그인
mysql -h (host ip) --port (포트번호) -u (유저이름) -p 

GORM으로 DB 연동

# GORM 설치
go get -u gorm.io/gorm

package main

import (
    "fmt"

    "github.com/pkg/errors"
    "gorm.io/driver/mysql"
    "gorm.io/gorm"
)

type Board struct {
    ID       uint   `gorm:"primarykey;autoIncrement" json:"id"`
    Email    string `json:"email"`
    First    string `json:"first"`
    Hobby    string `json:"hobby"`
    Last     string `json:"last"`
    Location string `json:"location"`
    Phone    string `json:"phone"`
}

type DBHandler struct {
    gDB *gorm.DB
}

func main() {

    dbHandler, err := NewAndConnectGorm("(MariaDBusername):(Password)@tcp((ip))/(dbname)?charset=utf8mb4&parseTime=True&loc=Local&tls=true")
    if err != nil {
        fmt.Printf("%+v\n", err)
    }
    a, _ := dbHandler.GetBoradList()
    fmt.Println(a)
}

func NewAndConnectGorm(dsn string) (*DBHandler, error) {
    gormDB, err := gorm.Open(mysql.Open(dsn), &gorm.Config{})
    gormDB.AutoMigrate(Board{})
    dbHandler := &DBHandler{
        gDB: gormDB,
    }

    return dbHandler, err
}

func (h *DBHandler) GetBoradList() ([]Board, error) {
    boardList := []Board{}
    result := h.gDB.Find(&boardList)

    return boardList, errors.Wrap(result.Error, "db handler error2")
}

해당 DB로부터 값을 가져와서 출력해주는 코드입니다.

오픈소스 프론트엔드 게시판을 이용하여 게시판 개발

이번 과제는 오픈 소스 프론트 엔드 게시판을 이용하여 게시판이 동작하도록 백엔드 부분을 개발하는 내용이였습니다. 많은 문제가 있었고 react를 처음으로 접하여 조금 어려움이 있었지만 개발에는 성공하였습니다!

후기

devops로 성장하고 싶은 생각에 golang을 공부하기로 마음을 먹었지만 어떤 부분을 공부해야할지 감이 전혀 안잡혔는데 이번 과제들을 통하여 어느정도 프로젝트에 대한 감이 잡히는 것 같았습니다. 다음 주차가 마지막 이지만 지금까지도 많은 내용을 배운 느낌을 받았습니다.

코멘토 : https://bit.ly/3D9XCOz

2주차 교육 내용은 go의 웹 프레임워크 중 하나인 gin-gonic에 대한 내용을 가지고 교육을 진행하였습니다. gin-gonic을 이용하여 Image Restful API를 만들어 Postman으로 테스트를 진행하였습니다.

http Method

1. GET : 존재하는 자원에 대한 요청
2. POST : 새로운 자원을 생성
3. PUT : 존재하는 자원에 대한 변경
4. DELETE : 존재하는 자원에 대한 삭제

gin을 이용하여 ping 보내는 방법

r := gin.Default()
    r.GET("/ping", func(c *gin.Context) {
        c.JSON(http.StatusOK, gin.H{
            "message": "pong",
        })
    })

Binding

• Binding을 하기 앞서 태그로 바인딩할 대상을 지정할 수 있다.

  type RequestURI struct {
    ImageId string `uri:"id"`
  }
  

type RequestFile struct { File string json:"image" No string json:"no" }

type Response struct { Res string json:"res" }

- 이후에 위에서 정한 태그를 바탕으로 각각의 태그에 맞게 바인딩을 시도한다. 종류 : ShouldBind, ShouldBindJSON, ShouldBindXML, ShouldBindQuery, ShouldBindYAML, ShouldBindHeader

if err := c.ShouldBindJSON(&req); err != nil { //먼저 json으로 바인딩 type = string fmt.Println(err) c.JSON(http.StatusBadRequest, Response{Res: "binding error"}) return }

if err := c.ShouldBindUri(&reqURI); err != nil { //:id 바인딩 fmt.Println(err) c.JSON(http.StatusBadRequest, Response{Res: "binding error"}) return }

### []byte 변환
이번 강의 과제에서 base64로 변환되어 들어오는 이미지를 업로드 하기 위해 아래와 같이 나눈 후 base64, 이후 부분을 byte로 변환후 업로드 시켰다. 초기에는 강의대로 바로 saveuploadfile을 이용하여 업로드 하면 되는 줄 알았지만 base64로 변환된 코드라는 점을 간과하여 실패를 했었다. 이후 멘토님에게 조언을 구한 후 해당 부분을 바로 수정할 수 있었다. 강의에 참여하는 인원수가 적고 이런식으로 바로바로 조언을 구하며 수정을 할 수 있는게 코멘토의 아주 큰 장점으로 생각된다.
![](https://velog.velcdn.com/images/joshua_s/post/651fc86c-e36d-4088-bdf9-9309ab813d9b/image.png)

//코드 data, errBase := base64.RawStdEncoding.DecodeString(strings.Split(req.File, "base64,")[1]) // :"base64, 부분으로 나눈 후 []byte로 변환" if errBase != nil { fmt.Println(errBase) c.JSON(http.StatusBadRequest, Response{Res: "byte conversion error"}) return }

### 이번 강의를 통하여 얻은 부분
- 해당 프래임 워크속 함수들을 이해하기 위한 방법 :
ctrl + 클릭을 통하여 해당 함수가 어떤 구조로 이루어져 있는지 확인하면서 코드를 작성할 수 있어짐!
![](https://velog.velcdn.com/images/joshua_s/post/7d85e023-77fc-4361-b8b8-6398f32fb215/image.png)
![](https://velog.velcdn.com/images/joshua_s/post/8bceadea-8d4f-4b54-ba5a-2db48d50f1f8/image.png)
위에 사진과 같이 해당 함수로 이동하여 확인할 수 있다는 것을 알았다.... 
해당 부분을 이용하여 여러 프레임 워크를 이용하여 혼자서도 어느정도 코드를 짤 수 있게 된 것이 가장 큰 부분인 것 같다.
코멘토 : https://bit.ly/3D9XCOz

클라우드 엔지니어에서 devops로의 전환을 위하여 여러 언어를 찍어먹어 보고 있었고 그러던 와중 같이 일하는 선임이 Golang에 대해 열심히 영업을 하시고 실무에서 자주 사용되는 k8s의 경우도 Golang으로 짠 프로그램인 것을 알게되고 이제 나도 언어 한가지를 좀 딥하게 공부해보고자 하는 생각으로 공부를 시작하게 되었다.

먼저는 tucker의 go언어 강의를 들으며 개념에 대한 공부를 몇번 반복해서 익힌 후 이제 어떤 프로젝트를 진행해 봐야할까? 실제 실무에서는 어떤 식으로 사용하는 언어일까? 라는 고민을 하던중에 코멘토라는 곳에서 실무자가 PT를 해주는 강의가 있는 것을 보고 신청하게 되었다.

강의 내용

1주차 강의의 경우 기본적인 문법에 대한 내용이 많았다. 멘토분이 준비한 자료와 golang.site를 통하여 기초 문법 중 실무에서 사용하는 것을 위주로 강의가 진행 되었다. 기초 문법을 공부하고 오지 않았다면 강의를 따라가기 매우 힘들었을 것으로 생각된다. 에초에 기초 강의를 끝낸 사람들에게 하는 강의라는 생각이 더 강하긴 하다. 고루틴과 sync, mutex에 대한 부분과 각자 다른 환경이여서 환경을 맞추기위해 ubuntu에 go를 설치하는 방법등을 배우고 과제를 해결함으로 개념에 대한 부분을 더 확실하게 하는 느낌이였다.

과제

과제는 1~10억 까지 덧샘, 환율 정보를 10회 가져와서 channel에 push하고 해당 값의 평균값을 출력하는 내용이다.

1~10억 sumation 환율

go routin을 이용하여 해당 내용을 짜긴 했지만 더 go스럽게 코드를 짤 수 있는 방법이 있지 않을까? 라는 고민을 하며 환율에 대한 부분을 조금씩 수정해보고 있는데 처음에는 환율을 가져오는 go routin의 갯수를 늘렸다고 한다면 두번째는 환율을 가져오는 루틴과 값의 결과를 출력하는 부분에 루틴을 주어 환율 정보를 가져오면서 chan에 값이 입력되면 결과를 바로 계산하는 방법으로 코드를 변경하고 있다. 이런 과제가 있고 더 go스럽게 작성하려는 생각을 가지다 보니 개념에 대한 부분이 더 확실하게 정착되는 것 같다.

후기

아직 1주 밖에 되지 않았지만 초반에 갈피를 잡는 부분에 있어서는 도움이 많이 될 것 같다. 아직 시작이니깐...

코멘토 주소

실무자가 강의하는 강의가 많으니 필요하시면 보시길 https://bit.ly/3D9XCOz

1. ubuntu 20.04
2. vmware workstation16

vm에 가상환경 세팅

세팅할때 기본적으로 ram 4GB이상 2코어 이상으로 세팅하는게 편합니다.

우분투 os를 설치 한 후 네트워크 세팅을 먼저 실시합니다. 네트워크 세팅은 설정으로 들어가서 고정 ip를 입력합니다.

고정 ip 설정이 완료되었다면 /etc/hosts와 /etc/hostname을 변경합니다.

sudo vi /etc/hosts

sudo vi /etc/hostname

이 두개를 변경하는데 기본적인 것은 node와 소통을 위한 부분입니다.

hosts

hostname

두가지의 설정이 완료되었다면 아래의 코드를 실행시킵니다.

sudo apt-get update
sudo apt-get install \
    openssh-server \
    vim \
    tree \
    ca-certificates \
    curl \
    gnupg \
    lsb-release -y

sudo mkdir -p /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
  $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt-get update

sudo apt-get install docker-ce docker-ce-cli containerd.io docker-compose-plugin

위에 코드들은 기본적인 설정에 필요한 파일이랑 docker를 설치하는 과정입니다. 자세한 사항은 docs를 확인하세요

sudo systemctl status docker
sudo docker run hello-world

설치가 완료되었다면 상기의 명령어로 도커를 실행이 되는지 확인하시고 docker rm 명령어로 테스트 파일를 지워줍니다.

이후에 vm의 클론 기능을 이용하여 node를 만들어줍니다. 이때 시스템을 종료하시고 클론을 하셔야합니다.

node를 만든 후에 각 노드에 맞게 네트워크 설정을 해줍니다. 저는 각각 130,131,132로 마스터, 노드1, 노드2를 만들었습니다. 위에서 진행한 대로 hosts와 hostname을 확인하시고 모든 설정이 끝났다면 메모리 절약을 위해 멀티유저 모드로 전환합니다.

sudo systemctl set-default multi-user.target

컴퓨터의 성능에 맞게 노드의 메모리도 줄여줍니다.

putty로 각각에 접근하여 ping test를 진행합니다.

정상적으로 수신하는 것을 확인할 수 있습니다. 이제 본격적으로 쿠버네티스를 설치할 시간입니다. 쿠버네티스는 기본적으로 공식 홈페이지에 설치 방법에 대한 가이드가 있습니다. 달라지는 경우도 있기 때문에 공식 홈페이지를 참조하는 것이 바람직합니다. 각 노드와 마스터에 아래의 코드를 실행시켜 쿠버네티스를 설치한다.

sudo swapoff -a && sudo sed -i '/swap/s/^/#/' /etc/fstab

cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
overlay
br_netfilter
EOF

sudo modprobe overlay
sudo modprobe br_netfilter

cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-iptables  = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.ipv4.ip_forward                 = 1
EOF

sudo sysctl --system
sudo ufw disable

sudo apt-get update
sudo apt-get install -y apt-transport-https ca-certificates curl
sudo curl -fsSLo /usr/share/keyrings/kubernetes-archive-keyring.gpg https://packages.cloud.google.com/apt/doc/apt-key.gpg
echo "deb [signed-by=/usr/share/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list

sudo apt-get update
sudo apt-get install -y kubelet kubeadm kubectl
sudo apt-mark hold kubelet kubeadm kubectl

sudo systemctl daemon-reload
sudo systemctl restart kubelet

마스터 노드는 아래의 코드를 추가로 실행시킨다.

sudo rm /etc/containerd/config.toml
sudo systemctl restart containerd
sudo kubeadm init

최종적으로는 kubeadm join 192.168.146.130:6443 --token zx3x0p.prkjwuigxlva8jqj
--discovery-token-ca-cert-hash sha256:ad2ee7cb9bf4378db184a79ed033711ddb9baf9e105142aaf3dfbcda9c08a81d 이것과 비슷하게 토큰이 생긴다.

아래의 코드를 실행시켜 모든 사용자가 kube 명령어를 사용할 수 있게 한다.

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

또한 pod간 네트워크 통신을 위해 weave net works 설치한다.

kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"

이제 노드로 이동하여서 아까 나온 토큰을 등록해주며 마스터와 연결한다.

sudo rm /etc/containerd/config.toml
sudo kubeadm join 192.168.146.130:6443 --token zx3x0p.prkjwuigxlva8jqj \
        --discovery-token-ca-cert-hash sha256:ad2ee7cb9bf4378db184a79ed033711ddb9baf9e105142aaf3dfbcda9c08a81d

마스터로 이동하여 노드들의 상태를 확인한다.

kubectl get nodes -o wide

또한 bash에서 kubectl 명령어를 더 쉽게 사용하기 위해 tab키로 자동완성기능을 추가한다.

source <(kubectl completion bash)
echo "source <(kubectl completion bash)" >> ~/.bashrc

이제 쿠버네티스의 기본적인 설정이 완료되었다

kubectl run nginx --image=nginx:1.14 --port=80
kubectl get pods -o wide

여러가지 실행 명령어를 이용하여 테스트를 진행해보면 됩니다.

마무리

k8s의 기본적인 부분과 명령어들을 익혀 후에 EKS를 활용 및 관리할 수 있도록!

프로메테우스를 이용하면 EC2 내부에 깔려있는 mysql이나 apach와 같은 서비스들의 사용량 체크와 EC2자체의 메모리, 볼륨, CPU와 같은 것들을 확인할 수 있기 때문에 프로메테우스로 모니터링 시스템을 구축해보도록 하겠다.

환경

• ubuntu 20.04
• EC2
• mysql
• apach
• prometheus
• grafana

실행

먼저 EC2를 열어준 뒤 EC2의 내부로 진입한다. 내부로 진입한 EC2에 필요한 요소들을 설치해준다.

sudo apt-get update
wget https://github.com/prometheus/prometheus/releases/download/v2.37.0/prometheus-2.37.0.linux-amd64.tar.gz

wget https://github.com/prometheus/mysqld_exporter/releases/download/v0.14.0/mysqld_exporter-0.14.0.linux-amd64.tar.gz

wget https://github.com/prometheus/node_exporter/releases/download/v1.3.1/node_exporter-1.3.1.linux-amd64.tar.gz

wget https://github.com/Lusitaniae/apache_exporter/releases/download/v0.11.0/apache_exporter-0.11.0.linux-amd64.tar.gz

각각 prometheus와 exporter들입니다. 필요한 정보는 프로메테우스 공식 홈페이지와 원하는 exporter를 다운로드 받으시면 됩니다.

각각의 폴더의 압축을 풉니다.

tar xf apache_exporter-0.11.0.linux-amd64.tar.gz
tar xf mysqld_exporter-0.14.0.linux-amd64.tar.gz
tar xf node_exporter-1.3.1.linux-amd64.tar.gz
tar xf prometheus-2.37.0.linux-amd64.tar.gz

이제 프로메테우스가 위치할 장소를 만들어주고 그 위치로 파일을 옮겨줍니다.

sudo mkdir -p /etc/prometheus
sudo mv prometheus console_libraries prometheus.yml consoles /etc/prometheus

프로메테우스의 유저 및 그룹을 시스템에 생성한다. 계정으로 로그인을 하지 않을거기 때문에 nologin으로 설정한다.

sudo groupadd --system prometheus
sudo useradd --system -s /usr/sbin/nologin -g prometheus prometheus

프로메테우스 유저와 그룹을 생성하였으니 이제 /etc/prometheus의 폴더와 내부 소유권들을 변경한다.

sudo chown prometheus:prometheus /etc/prometheus -R
ll

이제 프로메테우스가 시스템의 서비스로 운영될 수 있도록 systemd에 등록한다. 등록시 루트 계정으로 접근하여야 합니다.

su -
cd /etc/systemd/system
vi prometheus.service

[Unit]
Description=Prometheus
Wants=network-online.target
After=network-online.target

[Service]
User=prometheus
restart=on-failure
ExecStart=/etc/prometheus/prometheus \
        --config.file=/etc/prometheus/prometheus.yml \
        --storage.tsdb.path=/var/lib/prometheus \
        --web.console.templates=/etc/prometheus/console \
        --web.console.libraries=/etc/prometheus/console_libraries \
        --web.listen-address=0.0.0.0:9090 \
        --web.external-url=

[Install]
WantedBy=multi-user.target

이제 storage파일이 적용되어 있는 /var/lib/prometheus 폴더를 생성하고 권한을 prometheus로 변경해준다.

sudo mkdir -p /var/lib/prometheus
sudo chown prometheus:prometheus /var/lib/prometheus

이제 prometheus.service 적용을 위해 리로드를 해주고 status를 확인한다.

sudo systemctl daemon-reload
sudo systemctl status prometheus.service

sudo journalctl -xe

만일 문제가 발생하였다면 가장 밑에 있는 코드인 journalctl -xe로 확인하고 문제를 해결한다. 이제 ip로 접근하여 보면 prometheus가 잘 동작중인 것을 확인할 수 있다.

이제 exporter들을 설정하여 프로메테우스가 mysql과 node, apach로 부터 정보를 가져오도록 설정한다.

mkdir -p /etc/prometheus/exporters
cd /home/ubuntu/node_exporter-1.3.1.linux-amd64
sudo mv node_exporter /etc/prometheus/exporters/
sudo chown prometheus:prometheus /etc/prometheus/exporters/ -R

이제 다시 systemd에 등록해준다.

cd /etc/systemd/system
cp prometheus.service node-exporter.service
vi node-exporter.service

[Unit]
Description=Prometheus - node_exporter
Wants=network-online.target
After=network-online.target

[Service]
User=prometheus
restart=on-failure
ExecStart=/etc/prometheus/exporters/node_exporter 

[Install]
WantedBy=multi-user.target

다시 데몬 리로드 시키고 node_exporter을 확인한다.

sudo systemctl daemon-reload
sudo systemctl restart node-exporter.service
sudo systemctl status node-exporter.service

실제로 실행정보를 확인하려면 node_exporter의 포트 번호를 변경하지 않았다면 9100번으로 접근이 가능하다.

이제 프로메테우스에 등록을 해주면 됩니다. 아래의 코드를 아래의 사진과 같이 추가해주시면 됩니다.

vi /etc/prometheus/prometheus.yml

  - job_name: "node_exporter"
    static_configs:
      - targets: ["localhost:9100"]

이제 프로메테우스를 재시작하고 확인해주시면됩니다.

systemctl restart prometheus.service

같은 방식으로 apach와 mysql을 등록시켜주시면 됩니다. 이제 그라파나를 설치하고 프로메테우스와 연결해봅시다. 그라파나 다운로드는 홈페이지에서 확인 가능합니다.

sudo apt-get install -y apt-transport-https
sudo apt-get install -y software-properties-common wget
wget -q -O - https://packages.grafana.com/gpg.key | sudo apt-key add -
echo "deb https://packages.grafana.com/oss/deb stable main" | sudo tee -a /etc/apt/sources.list.d/grafana.list
sudo apt-get update
sudo apt-get install grafana
sudo systemctl enable grafana-server.service
sudo systemctl start grafana-server.service
sudo systemctl status grafana-server.service

그라파나의 설치가 완료되었다. 이제 3000번 포트로 접근하게 되면 그라파나에 들어가는 것을 확인할 수 있다. 초기 아이디/비밀번호는 admin/admin 이다.

config - datasources - add datasources 로 이동한 뒤 url만 localhost:9090으로 변경한 뒤 test를 진행하면 테스트를 성공한 것을 확인할 수 있다.

이제 데쉬보드를 꾸며주면 되는데 저는 그라파나 공식 홈페이지에 대쉬보드 올려놓은 것을 import 시켜주어 꾸미기로 했습니다.

끝

마무리

필요한 포트는 aws 인바운드 포트를 알아서 열어주셔야 합니다. 또한 port번호는 변경하는 것이 보안상 좋습니다.

Github, jenkins, argoCD를 사용하여 CI/CD 환경의 EKS 구축을 진행한다. CI의 경우 Github -> jenkins -> AWS ECR로 진행되며 CD의 경우 argoCD -> AWS EKS로 진행된다. 필자의 구성 환경은 vmware-ubuntu-docker에서 진행할 예정이다. 이전 내용을 참조하세요

EKS

EKS는 Kubernetes를 실행하는 데 사용할 수 있는 관리형 서비스이다. kubernetes 제어 플레인 또는 노드를 설치, 작동, 유지 관리할 필요가 없다. 또한 오픈소스 Kubernetes 소프트웨어의 최신 버전을 실행하므로 모든 즉 기존에 사용중인 플러그인과 도구들을 사용할 수 있다. EKS에서 실행된느 애플리케이션은 IDC에서 실행중이든 퍼블릭 클라우드에서 실행중이든 상관없이 모든 표준 K8s환경에서 실행되는 앱과 완벽하게 호환된다. 즉 필요한 코드를 수정하지 않고 쉽게 EKS로 마이그레이션이 가능하다. 자세한 설명은 Docs를 확인하자

EKS Server

EKS를 시작하기 앞서서 먼저 서버를 생성해야 한다. EKS 서버는 VM으로 해도 상관없지만 필자는 EC2를 이용하여서 EKS 전용 서버를 생성하였다.

EKS server instance 정보 OS : amazon Linux2 5.10 인스턴스 유형 : t3.small

저는 인스턴스 정보와 같이 진행하였지만 다른 OS혹은 인스턴스 유형을 선택하여 진행하여도 상관 없습니다. EKS 서버 인스턴스가 시작되면 ssh를 통하여 접속한 후 AWS CLI를 삭제합니다. 이는 초기에 AWS cli 1버전이 깔려있기 때문에 이 버전을 AWS CLI 2로 업그레이드 하기 위하여 진행하는 것입니다. 버전 확인은 아래의 코드로 확인할 수 있습니다.

aws --version

제거 방법은 아래와 같습니다

sudo yum remove awscli

이후에 아래의 코드로 AWS CLI버전 2를 다운로드 합니다.

curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install

설치가 완료되었다면 버전을 확인합니다.

/usr/local/bin/aws --version

이제 eksctl을 설치합니다. 설치방법은 docs를 참조하시면 됩니다.

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

버전이 정상적으로 나온다면 설치가 완료된 것입니다. 이제 kubectl을 설치합니다.

curl -o kubectl https://amazon-eks.s3.us-west-2.amazonaws.com/1.21.2/2021-07-05/bin/linux/amd64/kubectl
chmod +x ./kubectl
mkdir -p $HOME/bin && cp ./kubectl $HOME/bin/kubectl && export PATH=$PATH:$HOME/bin
echo 'export PATH=$PATH:$HOME/bin' >> ~/.bashrc
kubectl version --short --client

마찬가지로 완료가 된다면 client버전이 정상적으로 나오게 됩니다. 이제 aws configure 명령어를 이용하여 키를 등록합니다. 만약 계정의 Access key와 Secret key가 없다면 IAM user를 새로 만드는 것을 추천합니다. IAM user생성시 programmatic access를 꼭 체크하셔야 합니다.

aws configure

aws configure를 입력하게 된다면 아래 이미지와 같이 나오게 되는데 이때 region name은 원하는 리전을 입력하시면 됩니다. 서울 리전의 경우 ap-northeast-2입니다. 리전을 확인하는 방법은 이름 console에서 계정옆에 서울 혹은 글로벌로 되어있는 부분에 나와있습니다. 이렇게 하면 관리서버에 계정을 등록하는 부분까지 완료된 상태입니다. 이제 eksctl을 사용하여서 클러스터와 node를 생성하면 됩니다. 제가 사용한 명령어는 아래와 같습니다.

eksctl create cluster \
--name k8s-argocd \
--region ap-northeast-2 \
--with-oidc \
--ssh-access \
--ssh-public-key my-key \
--nodes 2 \
--node-type t3.small \
--node-volume-size=8 \
--managed

여기서 ssh-public-key 부분에 my-key는 본인 키의 이름으로 수정하셔야 합니다. 또한 더 많은 옵션들을 확인하고 싶다면 eksctl create cluster --help 를 이용하시거나 [링크] (https://github.com/weaveworks/eksctl/tree/main/examples)를 확인하시면 더 다양한 예제를 볼 수 있습니다. eks클러스터 생성은 20분 정도 소요되며 생성되고 있는 정보를 확인하고 싶다면 cloudformation에 들어가서 이벤트를 확인하시면 볼 수 있습니다.

EKS argocd

argo cd를 설치하여 eks server에 적용한다.

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/v2.0.4/manifests/install.yaml
sudo curl --silent --location -o /usr/local/bin/argocd https://github.com/argoproj/argo-cd/releases/download/v2.0.4/argocd-linux-amd64
sudo chmod +x /usr/local/bin/argocd
kubectl patch svc argocd-server -n argocd -p '{"spec": {"type": "LoadBalancer"}}'

기본적으로 argocd-server는 공개적으로 노출하지 않지만 테스트 진행상황을 확인하기 위하여 Argo cd를 로드밸런서를 사용하여 사용할 수 있도록 설정한 것이다. ELB를 통하여 접근하기 까지 시간은 대략 2분정도 기다려야한다.

export ARGO_PWD=`kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d`

위 코드를 입력하면 argocd의 초기 비밀번호와 이름이 자동으로 생성된다. ArgoCD는 로드벨런서의 dns주소를 입력해서 접근한다. username은 admin이고 password는 echo $ARGO_PWD 명령어를 이용하여 확인하면 된다.

ArgoCD 접근까지 완료 되었다. 이제 jenkins와 연결만 하면 CI/CD가 완료된다. Manage > repositories 에 들어가서 github url 설정을 합니다. 이 설정은 connect repo using https를 클릭한 후 git repo url을 입력해주고 connect를 연결하였을때 successful이 뜨면 성공입니다. 이후에 메인 화면에 new app을 클릭하고 manifest 파일이 수정되면 저동 배포를 위하여 automatic으로 설정합니다 repository URL 부분에 깃 repo주소를 넣어주고 path부분에 kustomization.yaml파일이 있는 path를 넣어주면 됩니다. kustomization 파일이 없다고 한다면 만들어서 넣으면 되는데 이 파일은 공식 홈페이지를 참조하면 됩니다.

테스트

jenkins에서 bulid now를 클릭하게 되면 ecr에서 태그가 업데이트 되게되고 argocd의 app을 확인하면 새로운 pod가 배포되는 것을 확인 할 수 있습니다.

정리

kubectl delete pod --all
eksctl delete cluster --name cluster-name

이후에 ecr과 eks managed용 ec2를 삭제하면 끝입니다.

사진이 안올라가요.... 그래서 중간부터 짤림...ㅠ

하... 다했는데 사진 왜 안올라가 이게 외않되...?

AWS는 기본적으로 Pay per use이기 떄문에 사용하지 않는 인스턴스는 중지 시키는 것이 좋다. 하지만 이를 신경쓰는 것은 6시에 칼같이 퇴근을 하고 싶은 나의 입장에서는 너무 힘든 일이다. 따라서 미리 구축을 해놓고 퇴근시간에 알아서 정지되도록 구축하려고 한다.

IAM Role

먼저 IAM Role을 생성한다. 사용 사례는 Lambda로 적용한뒤 생성하면 된다. 또한 권한도 나중에 부여할 것이기 때문에 권한을 넣지 않고 이름만 부여해주고 바로 생성을 하면 된다. 역활을 생성하였으면 이제 역활에 권한을 부여해줄 차례이다. 방금만든 Role로 이동한뒤 권한 추가에 인라인 정책 생성으로 이동한다 정책 생성에서 Json으로 변환한 뒤 다음과 같은 코드를 입력하면 된다.

{
    "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": "*"
        }
    ]
}

이후 정책 검토를 누르고 정책의 이름을 지정해주면 된다. 이렇게 하면 IAM Role은 끝이다.

Lambda

Lambda로 이동한뒤 함수 -> 함수 생성을 해준다. 그런 뒤에 이름을 지정하고 권한을 선택해준다. 또한 언어는 python으로 할 것이기 때문에 python을 지정해준다. 함수가 생성되었으면 구성 -> 일반구성으로 가서 제한 시간을 30초로 늘려주도록 하겠다. 이후에 코드로 이동한 뒤 python 스크립트를 넣어주면 끝이다.

import boto3
region = '본인 리전'
instances = ['EC2 인스턴스 ID']

ec2 = boto3.client('ec2', region_name=region)
def lambda_handler(event, context):
    if event['action'] == "start":
        ec2.start_instances(InstanceIds=instances, DryRun = False)
        print("instances start success")
    elif event['action'] == "stop":
        ec2.stop_instances(InstanceIds=instances, DryRun = False)
        print("instances stop success")

리전이랑 인스턴스 부분만 수정하면 된다. 코드에 대한 이야기를 잠깐 하자면 대충 보기만해도 action:start라는 내용이 들어오면 EC2가 실행되고 action:stop이 들어오면 EC2가 중지되는 것을 알 수 있다 이를 바탕으로 간단한 테스트를 진행해보자. Deploy를 한 후에 test를 눌러 테스트 이벤트를 구성한다. 위에서 말한 것과 같이 action:start or action:stop만 있으면된다. 이제 테스트를 진행하면 아주 잘 동작하는 것을 확인 할 수 있다.

EventBridge

원래 Cloudwatch에서 규칙을 지정해주던거 같은데 EventBridge라는 이름으로 옮겨진것 같다.. 먼저 EC2 Start부터 만들겠다. EventBridge에 가서 규칙 -> 규칙생성을 클릭한다. 그 후에 이름을 입력해주고 규칙 유형은 일정으로 변경한다. 이제 cron을 지정해주면 되는데 필자는 09시부터 18시까지로 진행할 것이기 때문에 (0 0 ? * MON-FRI *)로 지정해주었다. 참고로 그리니치 평균시 기준이기 때문에 -9를 해줘야 한국과 시간이 일치한다. 잘 모르겠으면 현지시간대로 선택한 뒤 시간을 계속 바꿔보자. 대상을 선택해주면 되는데 대상 = Lambda 그리고 함수는 방금 만든 Lambda함수, 추가설정에서 대상 입력 구성을 Json으로 변경한 뒤 Json을 만들어 준다. 이후에 대상을 검토하고 생성을 해주면 된다. 같은 방법으로 Stop도 만들어주면 된다. 18시 퇴근 기준으로 시간은 9로 지정해주면 된다. action은 방금과 반대로 "action" : "stop"으로 지정해주면 된다. 이제 모든 것을 검토한 뒤 생성을 눌러주면 끝이난다.

끝

이제 모든 구성이 끝났으므로 퇴근하기전에 EC2를 중지시키는 귀찮은 일은 안해도 된다. 퇴근하고 EC2를 껏나? 라는 생각에 AWS를 접속해보지 않아도 된다. 이제 자유로운 몸이 되었다.그러니 10분 전에 퇴근하자

4. CodeBuild

CodeBuild를 선택하고 프로젝트를 생성한다. 소스를 CodeCommit을 선택하고 자신이 만든 레포지토리를 연결해준후 브랜치를 선택한다. 환경에서 운영체제를 선택한 후에 운영체제의 버전을 선택한다.

이후 IAM Role을 선택해야 하는데 만약 없다고 하면 새 서비스 역활을 선택하여 역활을 생성해주면 된다. VPC와 서브넷은 따로 설정하지 않아도 된다. 후에 Buildspec을 설정해주어야 하는데 이 Buildspec은 모두 설정한 후에 따로 넣어주려고 한다. 이제 빌드 생성하기를 누르면 빌드가 생성된다. 빌드 프로젝트 -> 방금 만든 프로젝트 -> 편집 -> Buildspec으로 이동한다. 이제 Buildspec을 넣어주면 되는데 이 내용은 파일로 만들어서 하여도 상관없지만 직접 입력으로 진행하겠다.

version: 0.2

phases:
  pre_build:
    commands:
      - echo Build Dev prepare on `date`
  build:
    commands:
      - echo Build Dev started on `date`
  post_build:
    commands:
      - echo Build Dev completed on `date`
      - mkdir zip
      - mv ./dist ./zip/dist
      - cp appspec.yml ./zip/
      - cd zip
      - zip -r myapp.zip ./*
      - buildDateTime=$(date +%Y%m%d_%H%M%S)
      - aws s3 cp myapp.zip "s3://testjoshuabu/test/"
      - echo "path=s3://testjoshuabu/test/myapp.zip"

artifacts:
  files:
    - dist
    - appspec.yml

YAML파일 형식으로 작성하면 되며 간단하게 설명한다면 모든 파일을 zip폴더로 이동한 후 zip으로 묶어서 버킷에 업로드한다는 내용이다. 자세한 사항은 여기를 참고하자. 또한 appspec.yml파일은 CodeDeploy에서 사용되며 이 파일은 미리 만들어 놓았다. 이 코드는 다음과 같다.

version: 0.0
os: linux
files:
  - source: dist
    destination: /var/www/html

따로 무언가를 할 필요가 있지 않아서 파일 위치만 지정하였다. 이 내용도 자세한 사항은 Docs를 확인하자.

이제 빌드를 진행하여 보자! 빌드 시작을 누르면 빌드가 진행된다.

5. CodeDeploy

이제 CodeDeploy를 생성한다. 컴퓨팅 플랫폼은 EC2로 지정한다. IAM을 생성한다. IAM은 EC2로 진행하면된다. Role은 AWSCodeDeployRole과 아래의 Json을 넣어주면된다.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "EC2InstanceManagement",
            "Effect": "Allow",
            "Action": [
                "ec2:CreateTags",
                "ec2:RunInstances"
            ],
            "Resource": "*"
        },
        {
            "Sid": "EC2InstanceProfileManagement",
            "Effect": "Allow",
            "Action": [
                "iam:PassRole"
            ],
            "Resource": "*",
            "Condition": {
                "StringLike": {
                    "iam:PassedToService": "ec2.amazonaws.com*"
                }
            }
        }
    ]
}

배포 그룹생성을 누르고 배포 그룹을 입력한 뒤 서비스 역활에 방금 만든 따끈따끈한 IAM Role을 넣어준다. 배포방법은 블루/그린으로 할것이며 자세한 사항은 docs를 확인하자 나머지 조건들도 입력해준다. ALB와 AutoScailing은 만든 것을 넣어주면 된다. 이제 배포를 생성하면 됩니다. 배포생성을 클릭하고 zip위치를 개정위치에 넣어주면된다. 추가 배포 동작 설정에서 콘텐츠 덮어쓰기를 하여서 나중에 다시 배포를 눌렀을때 덮어써질수 있도록 하자. 배포 만들기를 누르면 자동적으로 배포가 실행된다.! 이제 기다리자... 조금 오래 걸린다... 혹시 모를 에러를 위해 에러를 확인하는 방법을 말하자면 배포 수명주기 이벤트에 보면 view events라는 것이 있다. 클릭하여 들어가면 거기에 어디서 실패하였는지, 어떤 에러가 발생하였는지 나와있다. 확인하며 docs와 google, 또는 서포터를 통하여 문제를 해결하면 된다. 크게 건든게 없어서 문제가 발생할지 모르겠지만...

6. CodePipeline

이제 마지막으로 codepipeline만 하면 모든 CI/CD는 종료된다. codepipeline으로 이동한 후 이름을 입력하고 사용자 지정위치로 버킷설정한다. 소스 공급자는 이전에 완료했던 codecommit이며 나머지 내용도 이전과 동일하게 선택한 뒤 넘어간다. 빌드는 codebuild이며 프로젝트 이름도 이전에 설정해두었다. 배포공급자도 마찬가지로 진행하면 된다. 확인하고 파이프라인 생성을 누르면 바로 한번 진행이 시작되고 커밋이 들어올 때마다 파이프라인이 동작하게 된다. 바로 되는것이 싫다고 한다면 후에 code commit에 브런치를 추가하여 특정 브런치가 커밋한 순간 파이프라인이 진행하도록 하거나 먼저 test deploy로 진행하도록 설정한 후 test deploy에서 문제가 없다고 한다면 실 서버에 적용하는 방식으로 진행하면 상당한 부분이 해결될 것으로 생각된다.

대충 완료했다는 내용

사용한 뒤 삭제를 생활화 합시다.

AWS의 서비스들을 활용하여 CICD를 구현려고 한다. 여기서 CI/CD란 지속적인 통합과 지속적인 배포를 의미한다. 다시 말해서 코드 변경이 있을 때마다 사용자가 정의한 프로세스 모델에 따라 코드를 빌드, 테스트, 배포하는 시스템을 만드는 것이다. 빠른 요약은 다음과 같다.

1. EC2에 설정을 마친후 AMI로 만들기
2. S3 생성
3. Codecommit
4. codebuild
5. codedeploy
6. codepipeline

1. EC2 설정

EC2를 만든 후 codedeploy를 위한 에이전트를 설치한다. 필자는 ubuntu 18.04버전으로 진행한다. 인스턴스 유형은 t3.micro로 진행했으며 네트워크는 퍼블릭으로 설정해 놓았고 보안그룹은 SSH와 HTTP, HTTPS 이렇게 3개만 허용한 보안그룹으로 만들었다. 마지막으로 사용자 데이터에 아래와 같은 코드를 삽입하였다.

#!/bin/bash
apt-get update -y
apt-get install nginx -y
apt-get install git -y
apt-get install aws-cli
apt-get install nodejs-dev node-gyp libssl1.0-dev -y
apt-get install npm -y
apt-get install unzip -y
apt install ruby -y
apt install wget -y
cd /home/ubuntu
wget https://aws-codedeploy-ap-northeast-2.s3.ap-northeast-2.amazonaws.com/latest/install
chmod +x ./install
./install auto
cd /etc/nginx/sites-available
cat <<EOF >  test.conf 
server {
    listen 80 default_server;
    listen [::]:80 default_server;

    root /var/www/html/dist;
    index index.html index.htm;
    server_name _;
}
EOF
ln -s /etc/nginx/sites-available/test.conf /etc/nginx/sites-enabled
rm /etc/nginx/sites-enabled/default
service nginx restart

위 코드는 필자가 테스트 할때 쓰는 코드들이며 이 서비스를 이용하는데 필요 없는 것도 존재합니다. (귀차니즘) apt get install ruby부터 ./install auto부분까지가 deploy Agent를 설치하는 내용입니다. 이렇게 만든 인스턴스를 이미지화하여야 한다. 이미지를 생성한 후에 시작 템플릿으로 이동한 후 시작합니다. 적당한 이름을 입력하고 Auto Scaling 지침을 적용한다. 어플리케이션 및 OS 이미지 부분에 아까 만들어둔 AMI이미지를 선택한다. 인스턴스 유형을 선택하고 키페어를 적용한 뒤 서브넷은 AutoScailing에서 선택할 예정이다. 보안그룹은 본인이 필요한 내용으로 생성하시면 됩니다. 마지막으로 IAM Role을 부여한다. 만약 없다면 만들면 됩니다. IAM Role에는 다음과 같은 정책이 부여되어 있어야 한다. 여기까지 입력하고 탬플릿을 생성하면 된다.

이제 AutoScailing으로 이동한 뒤 AutoScailing 그룹 생성을 클릭한다. 이름을 입력하고 시작 템플릿에 방금 만들어둔 것을 적용한다. 본인의 VPC를 적용한 뒤에 서브넷을 설정한다. 다음으로는 로드밸런서를 연결한다. 기존 로드밸런서가 있다면 바로 적용하면 되지만 없다고 한다면 새 로드밸런서에 연결을 클릭해서 만들어둔다. 마지막으로 그룹 크기를 적당히 설정해서 넘어간다.

여기까지 하면 EC2에서 할 모든 것이 끝났다.

2. S3 버킷 생성

S3 버킷생성은 간단하다. S3로 이동한 뒤 버킷생성, 버킷 이름을 입력해준 뒤 버킷을 생성하면 끝이다. 퍼블릭 액세스 설정은 차단으로 해놓아도 문제가 없다. 따라서 보안을 위해 차단으로 해두자.

3. Codecommit 설정

Codecommit으로 이동한 뒤 리포지토리 생성을 클릭하고 리포지토리 이름을 설정하고 생성을 누른다. 이후에 연결단계에서 보이는 순서대로 진행하면 되는데 기본적으로 pc에 git이 설치되어 있어야한다. git이 설치되어 있다는 가정하에 3단계로 넘어가보겠다. iam으로 이동한뒤에 액세스관리에 사용자, 지금 사용중인 계정을 클릭하면 아래와 같은 화면을 볼 수 있다. 여기서 보안 증명으로 이동한뒤 밑으로 내리면 AWS CodeCommit에 대한 HTTPS Git 자격 증명이라는 것을 볼 수 있다. 여기서 자격증명 생성을 클릭하고 Download Credentials를 클릭하면 git에 대한 Access ID와 passwd를 얻을 수 있다. 이제 다시 codecommit으로 돌아와서 3단계 리포지토리 복제분을 보면 git clone 부분을 볼 수 있다. 그 내용을 복사한다. 소스들이 있는 폴더를 연후에 git bash를 실행시키고 그 위치에 복사한 명령어를 실행시키키면 git 자격증명이 나온다. 해당 증명이 나오면 아까 다운로드 받아둔 credential.csv 파일을 연후에 ID와 passwd를 복사하여 붙여넣는다. 이제 git 명령어를 이용하여 커밋이 뒤는지 확인하면 된다. 참고로 git clone을 하면 repo에 해당하는 폴더가 생성되는데 그 폴더에 올리고자 하는 파일 넣어야된다.

git add .
git commit -m "내용"
git push origin master

이렇게 push가 완료되면 codecommit에 코드로 들어가보면 push한 폴더, 파일들이 나온다. 이렇게 되면 codecommit은 종료되었다.

이후의 내용은 다음편에 계속...

Github, jenkins, argoCD를 사용하여 CI/CD 환경의 EKS 구축을 진행한다. CI의 경우 Github -> jenkins -> AWS ECR로 진행되며 CD의 경우 argoCD -> AWS EKS로 진행된다. 필자의 구성 환경은 vmware-ubuntu-docker에서 진행할 예정이다.

CI 구축

1. Jenkins 설치

도커로 jenkins를 다운로드 한다.

sudo docker run -itd --name jenkins -p 8080:8080 -p 50000:50000 -v /docker/jenkins:/var/jenkins_home -v /var/run/docker.sock:/var/run/docker.sock -e TZ=Asia/Seoul -u root jenkins/jenkins:latest

2. Jenkins container에 docker, kustomize 설치

• Docker: docker in docker를 위하여 필요하다.(하지만 docker 측에서 보안때문에 권하지 않는다.)
• Kustomize: 쿠버네티스 구성을 사용자 정의화하는 도구

# docker 시작 명령어, 종료 명령어
docker start (컨테이너 이름 or ID 앞부분)
docker stop (컨테이너 이름 or ID 앞부분)

# Jenkins container 접속 명령어  
docker exec -it jenkins bash 

# docker 설치 명령어  
curl -fsSL get.docker.com -o get-docker.sh 
sh get-docker.sh 

# 확인 명령어 
docker ps 

# kustomize 설치 명령어  
curl -s "https://raw.githubusercontent.com/kubernetes-sigs/kustomize/master/hack/install_kustomize.sh"  | bash 
mv kustomize /usr/local/bin 
kustomize version 

여기까지가 kustomize 까지 설치를 완료한 것이다.

3. ECR 생성

AWS ECR > 레포지토리 생성을 클릭한 뒤 프라이빗으로 생성한다.

생성을 완료했다면 생성된 레포지토리의 URL을 복사한다.

4. Jenkins 환경구성

Jenkins의 환경 구성을 위하여 Sever IP:8080으로 접속한다. jenkins의 초기 비밀번호는 cat 명령어로 찾으면 된다. 필자의 경우 /var/jenkins_home/secrets/initialAdminPassword의 경로에 있었다.

cat /var/jenkins_home/secrets/initialAdminPassword

이제 Jenkins의 화면이 나오면 데쉬보드 -> jenkins 관리 -> 플러그인 메니저에서 docker-build-step, docker plugin, docker pipeline, AWS ECR을 다운로드한다.

이제 Jenkins에서 사용할 인증정보를 등록한다. 데쉬보드 -> jenkins 관리 -> manage Credentials로 이동한다. global을 클릭하고 왼쪽에 add Credentials를 클릭하면 아래와 같은 화면이 출력된다. kind를 AWS Credentials로 변경하고 ID는 임의로 지정하면 된다. Access key, secret key는 ECR 정책이 있는 AWS IAM의 액세스 키와 시크릿 키를 입력하면 된다.

이 작업을 한번 더 하는데 이번엔 github에 접근하기 위한 자격증명이다.

- kind : Username with password
- Username : github name
- password : github password
- ID : 임의 지정하면 된다.

5. Jenkinsfile

Jenkinsfile을 작성한다. VScode를 열고 파일의 이름을 Jenkinsfile이라 부여한다. 이후 작성하는 방법은 공식문서를 참고하면 좋을 것 같다.

node {   
     // git 연동
     stage('Clone repository') { 
         checkout scm
     }     

     // 도커 이미지 build
     stage('Build image') { 
         app = docker.build("YOUR ECR URL")
     }

     // ecr repo 에 도커 이미지 push 
     stage('Push image') {  
         sh 'rm -f ~/.dockercfg ~/.docker/config.json || true'

         docker.withRegistry('YOUR_REGISTRY', 'YOUR_CREDENTIAL'){
             app.push("${env.BUILD_NUMBER}")
         }         
     }

     // updated docker image 태그를 git push 
     stage('Deploy') { 
         // 사전 준비
         sh("""
            git config --global user.name "Your Name"
            git config --global user.email "you@example.com"
            git checkout -B master
         """)
      withCredentials([usernamePassword(credentialsId: 'github-signin', usernameVariable: 'GIT_USERNAME', passwordVariable: 'GIT_PASSWORD')]) {   
            sh("""
               #!/usr/bin/env bash
               git config --local credential.helper "!f() { echo username=\\$GIT_USERNAME; echo password=\\$GIT_PASSWORD; }; f"
               cd prod && kustomize edit set image ECR주소:${BUILD_NUMBER}
               git add kustomization.yaml
               git status
               git commit -m "update the image tag"
               git push origin HEAD:master
            """)   


     }

}

이런식으로 코드를 작성하여 파일을 생성하였다. 다른 필요한 부분이 있으면 공식 문서나 구글링을 통하여 추가하도록 하자.

6. Dockerfile

FROM ubuntu:18.04

RUN ln -sf /usr/share/zoneinfo/Asia/Seoul /etc/localtime

RUN apt upgrade -y && apt-get update -y && apt-get install nginx -y

RUN echo "/ndaemon off;" >> /etc/nginx/nginx.conf

CMD ["nginx"]

EXPOSE 80

도커 파일은 아주 간단한 nginx를 실행시키는 파일로 구성하였습니다.

7. github repo 생성 및 jenkins 연동

github으로 이동한 뒤 레포지토리를 생성하고 제일 상위 파일에 Dockerfile을 올린다. git 명령어 정리는 나중에 하도록 하겠다. github에 올렸으면 이제 Jenkins로 이동한다. 새로운 items 생성에서 pipeline을 선택한다 Advance Project Options로 이동한뒤 Definiton을 SCM으로 변경한후 SCM은 git 그리고 밑에 GIT 레포지토리 URL과 미리 만들어둔 Credentials을 선택해준다. 이후에 git에 설정해둔 branch와 Jenkinsfile의 위치를 지정해주면 끝이다.

8. 확인

확인할떄는 Bulid Now를 클릭하면 자동으로 빌드가 된다.

이렇게 하면 Ci는 끝난다 이제 CD까지 하면 CiCD가 완성된다.

DMS : 데이터베이스 마이그레이션 서비스의 약자로 온프레미스의 데이터 베이스를 클라우드 환경으로 이동하는 서비스이다. AWS SCT를 사용하여 다른 데이터베이스 엔진으로 마이그레이션도 가능하다. 또한 지속적인 변경사항을 복제하여 소스와 타겟을 동기화 시킬 수 있다.

소스DB 생성

온프레미스를 가정하기 위하여 EC2 인스턴스 한개를 생성하겠습니다. 인스턴스의 OS는 ubuntu 18.04를 선택하였으며 t2.micro의 크기를 이용하였습니다. subnet은 퍼블릭이 가능한 서브넷으로 구성하고 퍼블릭 IP 자동할당은 활성화를 해두시면 됩니다. 보안그룹은 22, 3306포트를 열어두시면 됩니다. 22는 보안성을 위하여 내 IP만 허용하시 것을 추천합니다. 인스턴스 한개가 생성되었습니다. putty를 이용하여 인스턴스에 접근을 하겠습니다. EC2를 이용하여 우분투를 생성하였으면 login 아이디는 ubuntu입니다. 이제 mysql과 pip3를 다운로드 하고 pip3로 pymysql을 다운로드합니다. pymysql은 후에 검증을 위해 python을 이용할 예정이기 때문에 다운로드 받는 것입니다. 필요하지 않으시면 다운로드 하지 않으셔도 됩니다.

sudo apt update -y
sudo apt-get install -y mysql-server python3-pip
sudo pip3 install pymysql
sudo ufw allow 3306

ufw allow 3306은 3306의 포트를 열어둔 것입니다. 이제 DB유저를 생성, DB생성, table생성을 해야합니다. mysql은 root의 초기 비밀번호가 없으므로 엔터치시고 넘어가시면 됩니다. 저는 간단하게 테이블을 구성했습니다.

sudo mysql -u root -p
create user 'test'@'%' identified by 'test';
grant all privileges on *.* to 'test'@'%';
FLUSH PRIVILEGES;
create database testdb;
use testdb;

CREATE TABLE member_table (
 NAME    VARCHAR(20),
 AGE     INT,
 PRIMARY KEY(AGE)
) ENGINE=MYISAM CHARSET=utf8;

이제 데이터 베이스의 내부를 채울 시간입니다. 그 전에 앞서서 python 스크립트를 저장할 폴더를 만듭니다.

mkdir script
cd script
vi sc.py

vi로 진입을 하셨으면 인서트 모드로 전환후 내용을 채울 간단한 스크립트를 적어넣습니다.

import pymysql
import time


jh_db = pymysql.connect(
    user="test", 
    passwd="test", 
    host="127.0.0.1", 
    db="testdb", 
    port=3306,
    charset='utf8'
)

cursor = jh_db.cursor(pymysql.cursors.DictCursor)

def insertsql():
    sql_query = """INSERT INTO member_table(NAME, AGE) VALUES (%s, %s)"""
    i = 0
    while i < 100:
        i = i + 1
        cursor.execute(sql_query,('jh'+str(i), i))
        jh_db.commit()
        time.sleep(1)
    jh_db.close()


if __name__ == "__main__":
    insertsql()

이후에 파이썬 스크립트를 동작 시킵니다. python 파일의 내용은 본인이 편하신 방법으로 수정하시면 됩니다.

sudo python3 sc.py

참고로 위에 작성된 파이썬 파일은 1초마다 동작하며 jh0, 0부터 100까지 내용을 채우게 됩니다. 다 동작되기까지 시간이 걸리므로 중간에 취소하셔도 상관없습니다. 이제 내용을 확인합니다.

sudo mysql -u test -p
use testdb;
select * from member_table;

이러한 결과를 얻을 수 있게됩니다. 이제 mysql의 외부 접속을 허용을 시켜야합니다. mysql에서 나와서 mysqld.cnf파일을 수정합니다. 참고로 저는 mysql 5.7버전입니다.

cd /etc/mysql/mysql.conf.d
vi mysqld.cnf

bind-address 부분을 주석처리 

이제 서비스를 다시 시작합니다.

sudo systemctl restart mysql.service

이렇게 하면 소스의 작업은 끝나게 됩니다.

타겟 DB생성

RDS에서 DB를 생성합니다. 엔진은 mysql이며 버전은 맞추는 것이 좋지만 이번에 저는 다르게 할 예정입니다. 이후에 내용대로 쭉 진행하시면 되는데 DB의 VPC가 없으신 분은 만드시면 됩니다. 또한 퍼블릭으로 진행할 것이기 때문에 퍼블릭 액세스를 허용해두셔야 합니다. 이렇게 하고 DB 생성을 누르시면 DB 생성은 끝납니다.

DMS

복제 인스턴스를 생성합니다. 내용이 어렵지 않으니 그냥 보고 입력하시면 됩니다.

엔드포인트를 만듭니다. 엔드포인트는 소스와 타겟 이 두개를 만드셔야 합니다. 사용자 이름과 암호는 db계정을 적으시면 됩니다. 이후 생성을 누르시면 끝납니다. 다시 엔드포인트 생성을 누르시고 대상 엔드포인트, RDS선택을 누르시면 대부분의 정보가 기입되어 있습니다. 활용하시면 됩니다. 마찬가지로 입력하시고 생성누르시면 완료입니다. 이제 타겟 db의 연결테스트를 실시합니다 이름 누르시고 연결에 연결 테스트 하시면 됩니다. 이렇게 나오면 성공한 것입니다. 마찬가지로 소스도 테스트 해줍니다. 성공이 나왔습니다. 이제 마이그레이션 테스크로 이동하여 테스크를 생성한뒤 입력방식에 맞게 입력하시면 됩니다. 테스크 설정에서 필요한 고급테스크 설정을 누르시면 예외적용을 할 수 있습니다. 참고하셔서 하시면 됩니다. 테이블 매핑에서 선택규칙 추가를 누르시고 스키마 입력을 누르시면 스키마 이름이 나옵니다. 이스키마 이름은 db를 적으셔도 되고 와일드카드인 %를 적으셔도 되는데 %를 적으시면 DB의 모든 내용들이 옮겨지기 때문에 필요한 내용만 필터로 추가하셔서 입력하시면됩니다. 반대로 필요없는 부분을 추가하셔서 작업을 제외로 바꾸시면 그 부분을 제외하고 나머지 부분을 마이그레이션 할 수 있습니다. 참고하시면 됩니다. 테스크 생성을 누르시고 생성이 완료되면 테스크가 진행될 것입니다. 이후에 RDS로 접근하셔서 내용을 확인하시면 DB의 내용이 일치할 것입니다.

테스크 진행시 오류 메시지 대처방법

이 내용은 지속적 복제모드를 선택했을때 발생했던 문제와 그 해결에 대해 적어놓은 것이다.

이런 실패 메시지로 나온 경우이다. 내용을 요약하자면 binary logging을 활성화 시켜야 된다는 내용이다.

해결책

1. 바이너리 로그를 활성화 시킨다.

   cd /etc/mysql
   vi my.cnf
   

[mysqld] log-bin server-id=1

아래 부분을 추가시켜주면 된다.

굳이 할 필요는 없지만 편의를 위하여 필자는 ssh를 설치한 후에 모든 작업을 진행하였다.

sudo apt-get install openssh-server
sudo vi /etc/ssh/sshd_config

ssh포트를 열기(적당히 기억할 수 있는 4~5자리 정도의 값으로 입력해도 된다.

sudo service ssh start 
sudo service ssh status
sudo ufw enable
sudo ufw allow 포트번호

이후에 hostnme -I 명령어로 아이피를 확인한 후 putty와 같은 터미널 에뮬레이터로 접속하면 된다.

docker 설치

먼저 패키지들을 설치한다.

sudo apt-get update
sudo apt-get install \
    ca-certificates \
    curl \
    gnupg \
    lsb-release

이후에 공식 GPC키를 추가한다.

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg

아래 명령어로 저장소를 설정한다.

echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu \
  $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

도커 엔진을 설치한다.

sudo apt-get update
sudo apt-get install docker-ce docker-ce-cli containerd.io

• 만약 특정 엔진을 설치하려면 apt-cache madison docker-ce로 버전을 확인하고 sudo apt-get install docker-ce= docker-ce-cli= containerd.io 버전을 입력하면 된다.

도커가 제대로 설치 되었는지 확인하기 위해 hello-world 이미지를 실행하여 본다.

sudo docker run hello-world

설치가 완료 되었다.

Docker 엔진 제거

Docker 엔진 cli 및 containerd 패키지를 제거한다.

sudo apt-get purge docker-ce docker-ce-cli containerd.io

호스트의 이미지, 컨테이너, 볼륨 또는 사용자 지정 구성 파일은 자동으로 제거되지 않습니다. 모든 이미지, 컨테이너 및 볼륨을 삭제하려면 다음의 코드를 입력해야한다.

sudo rm -rf /var/lib/docker
sudo rm -rf /var/lib/containerd

수고하셨습니다.

https://docs.docker.com/engine/install/ubuntu/ 도커 docs에 나와있는 우분투에 설치하는 방법으로 진행하였다.

https://velog.io/@joshua_s/CloudWatch-Agent를-사용하여-EC2-모니터링2

위 내용과 이어지는 내용입니다. 참고사항 : 필자는 amazon linux2를 사용중 입니다.

1. DB설정

mysql을 설치한 후 DB생성, 권한부여를 한다.

sudo yum update -y 
sudo yum install -y mariadb-server 
sudo systemctl enable mariadb 
sudo systemctl start mariadb 
sudo mysql_secure_installation
mysql -u root -p
CREATE DATABASE grafana CHARACTER SET UTF8 COLLATE UTF8_BIN;
CREATE USER 'grafana'@'%' IDENTIFIED BY 'password';
GRANT ALL PRIVILEGES ON grafana.* TO 'grafana'@'%';
quit;

CREATE USER 코드에서 password는 자신이 적으면 됩니다. 필자는 test용도로 password로 입력했습니다.

2. Grafana설치 및 설정

대상 EC2인스턴스에 ssh로 연결한다. ec2 업데이트를 하고 그라파나 다운로드 할 위치를 알 수 있도록 YUM저장소를 추가한다.

sudo yum update -y
sudo vi /etc/yum.repos.d/grafana.repo

grafana.repo의 설정은 다음과 같다.

[grafana]
name=grafana
baseurl=https://packages.grafana.com/oss/rpm
repo_gpgcheck=1
enabled=1
gpgcheck=1
gpgkey=https://packages.grafana.com/gpg.key
sslverify=1
sslcacert=/etc/pki/tls/certs/ca-bundle.crt

그라파나를 설치한다.

sudo yum repolist
sudo yum install -y grafana

새 설정을 로드하고 그라파나 서버를 시작, 부팅시 자동적으로 시작될 수 있도록 설정한다.

sudo systemctl daemon-reload
sudo systemctl start grafana-server
sudo systemctl status grafana-server
sudo systemctl enable grafana-server.service

그라파나 구성파일 grafana.ini을 편집한다. vi /etc/grafana/grafana.ini

데이터 베이스와 세션을 다음과 같이 구성한다.

[database]
type = mysql
host = 127.0.0.1:3306
name = grafana
user = grafana
password = your-password
[session]
provider = mysql
provider_config = `grafana:your-password@tcp(127.0.0.1:3306)/grafana`

그라파나 서비스를 시작한다. sudo servic grafana-server start

3. 인바운드 룰 추가

해당 EC2의 보안그룹으로 이동한 후에 인바운드룰에 tcp 3000번을 추가한다.

4. 그라파나 접속후 설정

해당 EC2의 공인 IP:3000으로 접속한다. 초기 아이디와 비밀번호는 admin/admin이다.

Configuration - Data Sources - add data source로 이동한다.

cloudwatch를 검색한 후 추가한다.

Authentication Provider - Access & secret key로 변경 후 액세스 키, 시크릿 엑세스키, 기본 지역, 사용자 지정 메트릭스(필자는 test로 지정했다)를 설정한다.

이제 저장 및 테스트를 진행하면 설정이 완료된다.

대시보드를 구성하고 빈 패널을 추가한다.

쿼리의 세부 정보를 채운다. 1- Query Mode — CloudWatch 지표 2- Region — 메트릭스의 위치 (제 경우에는 ap-northeast-2) 3- Namespace — 사용자의 네임 스페이스 (필자는 test) 4- Metric Name: 출력하기 원하는 메트릭스의 이름 5- Stats: 평균 6- Dimensions: 아래 사진과 같이 설정

이제 적용을 누르면 완료된 화면을 볼 수 있다.

그래프 모양을 변경하여 보기 편한 방식으로 설정하여 진행하면 됩니다.

https://velog.io/@joshua_s/CloudWatch-Agent를-사용하여-EC2-모니터링

위 링크에서 4번까지는 동일하게 진행하면 된다.

2. 파라미터 스토어

Systems Manger -> 애플리케이션 관리 -> 파라미터 스토어 -> 파라미터 생성

파라미터 이름 설정, 필자는 test로 진행하였다. 값에 지정하는 내용이 중요한데 필자는 메모리 사용량과 disk 사용량을 지정하여 진행하였다. 또한 namespace설정으로 cloudwatch 지표에 나오는 이름도 변경이 가능하다.

{
    "agent": {
        "metrics_collection_interval": 60,
        "run_as_user": "cwagent"
    },
    "metrics": {
        "metrics_collected": {
            "disk": {
                "measurement": [
                    {
                    "name": "disk_used_percent",
                    "rename": "DiskSpaceUtilization",
                    "unit": "Percent"
                    }
                ],
                "metrics_collection_interval": 60,
                "resources": [
                    "*"
                ]
            },
            "mem": {
                "measurement": [
                    {
                        "name": "mem_used_percent",
                        "rename": "MemoryUtilization",
                        "unit": "Percent"
                    }
                ],
                "metrics_collection_interval": 60
            }
        },
        "namespace": "test"
    }
}

필자는 위와 같이 적용을 하였다. 자세한 사항은 AWS 공식문서를 참고하기 바란다. https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-Configuration-File-Details.html 값에 내용을 입력한 후 파라미터 생성을 클릭하면 완료가 된다.

3. 파라미터 스토어에 등록한 명령 실행

Systems Manger -> 노드관리 -> 명령실행으로 이동하여 명령실행을 누른 후 명령 문서를 지정한다. 명령문서는 AmazonCloudWatch-ManageAgent이다. 이후 명령 파라미터에 Optional Configuration Location에 아까전에 파라미터 스토어에 등록한 파라미터 이름을 입력하면 된다. 필자의 경우 test이다. 이후 수동으로 인스턴스 선택, IAM Role을 적용한 인스턴스를 클릭한다. 이후 실행을 누르면 명령이 실행된다.

4. CloudWatch 지표확인

몇분이 지나면 CloudWatch에 지표가 등록이 되는데 이 내용을 확인하면 된다.

목적

이 내용을 하는 목적은 ec2는 기본적으로 모니터링이 가능하지만 메모리를 모니터링 할 수 없다. 따라서 이를 적용함으로써 메모리도 모니터링이 가능하도록 만들 수 있다. 또한 이를 발전시키면 그라파나와 같은 모니터링 오픈소스에 적용하여 이용할 수 있다. 이후에 이 내용을 가지고 진행하도록 하겠다.