[Kubernetes] metrics-server 설치하기 (error: Metrics API not available 조치)

반응형

metrics-server 는 Kubernetes 클러스터 내에서 노드 및 Pod 의 리소스 사용량에 대한 메트릭 데이터를 수집하고 제공하는 서버입니다. 이러한 메트릭 데이터는 Kubernetes API 서버를 통해 조회할 수 있어, 사용자나 다른 Kubernetes 구성 요소들이 클러스터의 성능 및 리소스 사용에 대한 정보를 얻을 수 있습니다.

metrics-server 가 제공하는 주요 메트릭은 다음과 같습니다:
- CPU 사용량 (CPU Usage) : 클러스터 내의 각 노드 및 Pod 가 사용하는 CPU 의 양을 측정합니다.
- 메모리 사용량 (Memory Usage) : 클러스터 내의 각 노드 및 Pod 가 사용하는 메모리의 양을 측정합니다.
- 네트워크 입출력 (Network I/O) : 클러스터 내의 각 노드 및 Pod 가 수행하는 네트워크 입출력을 측정합니다.
- 파일 시스템 사용량 (Filesystem Usage) : 클러스터 내의 각 노드 및 Pod 가 사용하는 파일 시스템의 용량과 사용량을 측정합니다.

이러한 메트릭 데이터는 Kubernetes 의 Horizontal Pod Autoscaling (HPA) 및 기타 리소스 관리 및 모니터링 도구에서 사용됩니다. metrics-server 는 일반적으로 클러스터 내에서 자동으로 배포되며, Kubernetes 버전 1.8 이상에서는 기본적으로 활성화됩니다.

사용자는 kubectl top 명령을 통해 metrics-server 에서 수집된 메트릭 데이터를 조회할 수 있습니다. 예를 들어, kubectl top pods, kubectl top nodes 등을 사용하여 Pod 및 노드의 리소스 사용량을 확인할 수 있습니다.

 

 

1. Metrics-server 설치

 

설치는 한번의 명령으로 끝이 납니다.

아래 URL 은 공식 배포 URL 로써 항상 최신버전의 metrics-server 가 설치 됩니다.

# kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml
serviceaccount/metrics-server created
clusterrole.rbac.authorization.k8s.io/system:aggregated-metrics-reader created
clusterrole.rbac.authorization.k8s.io/system:metrics-server created
rolebinding.rbac.authorization.k8s.io/metrics-server-auth-reader created
clusterrolebinding.rbac.authorization.k8s.io/metrics-server:system:auth-delegator created
clusterrolebinding.rbac.authorization.k8s.io/system:metrics-server created
service/metrics-server created
deployment.apps/metrics-server created
apiservice.apiregistration.k8s.io/v1beta1.metrics.k8s.io created

 

명령이 잘 실행되는지 확인합니다.

아래는 nodes 의 자원 사용률 확인 명령입니다.

# kubectl top nodes
error: Metrics API not available

 

이와 동일한 에러가 출력된 경우, metrics-server Pod 가 잘 생성되었는지 확인합니다.

# kubectl get pod -A |grep metrics
kube-system                                     metrics-server-5d875656f5-vmv66                                 0/1     Running     0          10s

 

설치가 되었으나 Running 중인 Pod 는 0개로 확인 됩니다.

Pod 의 상세 정보에서는 HTTP status code 500 에러가 확인되었습니다.

# kubectl describe pod metrics-server-5d875656f5-vmv66 -n kube-system

...

(생략)

...

Events:
  Type     Reason     Age               From               Message
  ----     ------     ----              ----               -------
  Normal   Scheduled  52s               default-scheduler  Successfully assigned kube-system/metrics-server-5d875656f5-vmv66 to kind-control-plane
  Normal   Pulled     51s               kubelet            Container image "registry.k8s.io/metrics-server/metrics-server:v0.6.4" already present on machine
  Normal   Created    51s               kubelet            Created container metrics-server
  Normal   Started    51s               kubelet            Started container metrics-server
  Warning  Unhealthy  1s (x4 over 31s)  kubelet            Readiness probe failed: HTTP probe failed with statuscode: 500

 

문제 해결을 위해 Deployment 를 수정합니다.

# kubectl edit deployment metrics-server -n kube-system

출력된 내용중에 metric-resolution 문자열을 검색해서 그 다음에 옵션을 하나 더 추가해 주어야 하는데, 문자열을 검색하면 두 군데 나옵니다. 그중에서 아래와 같이 옵션이 행으로 구분된 곳에 --kubelet-insecure-tls 옵션을 추가해 줍니다.

kubelet-insecure-tls 옵션은 공식적으로 발급받은 인증서인지 확인하지 않고 접근하겠다는 의미입니다.

...

(생략)

...

    spec:
      containers:
      - args:
        - --cert-dir=/tmp
        - --secure-port=4443
        - --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname
        - --kubelet-use-node-status-port
        - --metric-resolution=15s
        - --kubelet-insecure-tls
        image: registry.k8s.io/metrics-server/metrics-server:v0.6.4

...

(생략)

...

 

저장 후 시간이 조금 지나야 적용됩니다.

적용이 되면 아래와 같이 자원 사용량 확인이 가능합니다.

# kubectl top nodes
NAME                 CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%   
kind-control-plane   294m         3%     2753Mi          17%  

 

# kubectl top pods
NAME                                                    CPU(cores)   MEMORY(bytes)   
b07a7888-df03-451f-8475-13c6d9bac48d-cf--cb3e18e9fd-0   1m           4Mi             
nginx-665cb6f744-wf5g5                                  0m           6Mi      

 

반응형

댓글()

[Kubernetes] 네임스페이스의 메모리 및 CPU 할당량 구성

반응형

네임스페이스에 일정 용량을 적용하여 그 안의 Pod 가 제한된 용량 안에서만 자원을 나누어 사용할 수 있도록 합니다.

본 매뉴얼은 아래 공식 문서를 참고하여 작성하였습니다.

https://kubernetes.io/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/

 

 

1. 네임스페이스 생성

 

테스트를 위한 네임스페이스를 생성합니다.

# kubectl create namespace sysdocu-ns

 

 

2. 할당량 생성 및 적용

 

네임스페이스에 적용할 할당량을 설정합니다.

# vi rq.yaml

apiVersion: v1
kind: ResourceQuota
metadata:
  name: mem-cpu-limits
spec:
  hard:
    requests.cpu: "1"
    requests.memory: 1Gi
    limits.cpu: "2"
    limits.memory: 2Gi

 

작성한 할당량을 먼저 생성한 네임스페이스에 적용합니다.

# kubectl apply -f rq.yaml -n sysdocu-ns
resourcequota/mem-cpu-limits created

 

설정한 리소스 할당량과 사용량에 대한 정보를 볼 수 있습니다.

# kubectl get resourcequota mem-cpu-limits -n sysdocu-ns --output=yaml
apiVersion: v1
kind: ResourceQuota
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","kind":"ResourceQuota","metadata":{"annotations":{},"name":"mem-cpu-limits","namespace":"sysdocu-ns"},"spec":{"hard":{"limits.cpu":"2","limits.memory":"2Gi","requests.cpu":"1","requests.memory":"1Gi"}}}
  creationTimestamp: "2024-01-11T00:29:34Z"
  name: mem-cpu-limits
  namespace: sysdocu-ns
  resourceVersion: "12801859"
  uid: 98127c56-33bc-4ccc-a55c-1152b7f04128
spec:
  hard:
    limits.cpu: "2"
    limits.memory: 2Gi
    requests.cpu: "1"
    requests.memory: 1Gi
status:
  hard:
    limits.cpu: "2"
    limits.memory: 2Gi
    requests.cpu: "1"
    requests.memory: 1Gi
  used:
    limits.cpu: "0"
    limits.memory: "0"
    requests.cpu: "0"
    requests.memory: "0"

 

위 예시의 리소스 할당량 (ResourceQuota : mem-cpu-limits) 이 설정된 네임스페이스에 다음과 같은 제약 사항이 있습니다.
- 네임스페이스의 모든 Pod 에 대해 각 컨테이너에는 메모리 요청, 메모리 제한, CPU 요청 및 CPU 제한이 있어야 합니다.
- 해당 네임스페이스에 있는 모든 Pod 에 대한 메모리 요청 합계는 1 GiB 를 초과해서는 안 됩니다.
- 해당 네임스페이스에 있는 모든 Pod 의 메모리 제한 합계는 2 GiB 를 초과해서는 안 됩니다.
- 해당 네임스페이스에 있는 모든 포드에 대한 CPU 요청 합계는 1 CPU 를 초과해서는 안 됩니다.
- 해당 네임스페이스에 있는 모든 포드의 CPU 제한 합계는 2 CPU 를 초과해서는 안 됩니다.

 

 

3. 첫번째 Pod 생성

 

테스트를 위해 간단한 Pod 를 생성합니다.

# vi pod1.yaml

apiVersion: v1
kind: Pod
metadata:
  name: demo-pod1
spec:
  containers:
  - name: demo-pod1
    image: nginx
    resources:
      limits:
        memory: "800Mi"
        cpu: "800m"
      requests:
        memory: "600Mi"
        cpu: "400m"

 

# kubectl apply -f pod1.yaml -n sysdocu-ns
pod/demo-pod1 created

 

Pod 가 정상 실행되고 있는지 확인합니다.

# kubectl get pod demo-pod1 -n sysdocu-ns
NAME        READY   STATUS    RESTARTS   AGE
demo-pod1   1/1     Running   0          80s

 

설정한 리소스 할당량과 사용량에 대한 정보를 다시 확인합니다.

아래와 같이 사용량이 변경된 것을 확인할 수 있습니다.

# kubectl get resourcequota mem-cpu-limits -n sysdocu-ns --output=yaml

apiVersion: v1
kind: ResourceQuota
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","kind":"ResourceQuota","metadata":{"annotations":{},"name":"mem-cpu-limits","namespace":"sysdocu-ns"},"spec":{"hard":{"limits.cpu":"2","limits.memory":"2Gi","requests.cpu":"1","requests.memory":"1Gi"}}}
  creationTimestamp: "2024-01-11T00:29:34Z"
  name: mem-cpu-limits
  namespace: sysdocu-ns
  resourceVersion: "12805135"
  uid: 98127c56-33bc-4ccc-a55c-1152b7f04128
spec:
  hard:
    limits.cpu: "2"
    limits.memory: 2Gi
    requests.cpu: "1"
    requests.memory: 1Gi
status:
  hard:
    limits.cpu: "2"
    limits.memory: 2Gi
    requests.cpu: "1"
    requests.memory: 1Gi
  used:
    limits.cpu: 800m
    limits.memory: 800Mi
    requests.cpu: 400m
    requests.memory: 600Mi

 

jq 명령어 사용이 가능한 시스템에서는 아래와 같이 필요한 항목만 출력시킬 수 있습니다.

# kubectl get resourcequota mem-cpu-limits -n sysdocu-ns -o jsonpath='{ .status.used }' | jq .
{
  "limits.cpu": "800m",
  "limits.memory": "800Mi",
  "requests.cpu": "400m",
  "requests.memory": "600Mi"
}

 

 

4. 두번째 Pod 생성

 

테스트를 위해 두번째 Pod 를 생성합니다.

# vi pod2.yaml

apiVersion: v1
kind: Pod
metadata:
  name: demo-pod2
spec:
  containers:
  - name: demo-pod2
    image: redis
    resources:
      limits:
        memory: "1Gi"
        cpu: "800m"
      requests:
        memory: "700Mi"
        cpu: "400m"

 

# kubectl apply -f pod2.yaml -n sysdocu-ns
Error from server (Forbidden): error when creating "pod2.yaml": pods "demo-pod2" is forbidden: exceeded quota: mem-cpu-limits, requested: requests.memory=700Mi, used: requests.memory=600Mi, limited: requests.memory=1Gi

 

네임스페이스 내에서 사용 가능한 요청 메모리가 1Gi 인데, Pod1 의 메모리 600MiB 에 Pod2 의 메모리 700MiB 를 추가하려니까 에러가 발생했습니다.

600MiB + 700MiB > 1 GiB.

 

이렇게 ResourceQuota 을 이용해 네임스페이스에 리소스 할당량을 사용하여 제한하는 방법을 알아보았습니다.

 

반응형

댓글()

ab 명령을 이용한 웹서버 로딩 속도 테스트

리눅스/APACHE|2024. 1. 9. 13:57
보호되어 있는 글입니다.
내용을 보시려면 비밀번호를 입력하세요.

Kubernetes Pod 의 CPU 요청 및 제한값 변경하기 (Vertical Pod Autoscaler)

반응형

Autoscaler 종류는 총 세가지 입니다.

1) HPA (Horizontal Pod Autoscaler) : 애플리케이션의 복제본 수를 조정합니다. HPA 는 CPU 활용도를 기반으로 복제 컨트롤러, 배포, 복제본 집합 또는 상태 저장 집합의 포드 수를 조정합니다. HPA 는 또한 사용자 지정 또는 외부 메트릭을 기반으로 스케일링 결정을 내리도록 구성될 수 있습니다.

2) CA (Cluster Autoscaler) : 클러스터의 노드 수를 조정합니다. 클러스터 오토스케일러는 노드가 포드를 실행할 수 있는 자원이 부족하거나 (노드를 추가), 노드의 활용도가 낮은 상태로 있을 때 (노드를 제거), 포드가 다른 노드에 할당될 수 있을 때 (노드를 제거), 클러스터에서 노드를 자동으로 추가하거나 제거합니다.

3) VPA (Vertical Pod Autoscaler) : 클러스터 내 컨테이너의 리소스 요청 및 제한을 조정합니다. 본 매뉴얼에서 다룰 내용입니다.

- 공식 Document : https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler

 

 

1. VPA (Vertical Pod Autoscaler) 배포

 

VPA 사용을 위해 필요한 파일을 다운로드 받고 클러스터에 배포합니다.
# git clone https://github.com/kubernetes/autoscaler.git
# cd autoscaler/vertical-pod-autoscaler
# ./hack/vpa-up.sh

 

배포가 잘 되었는지 확인합니다.

# kubectl get pods -n kube-system |grep vpa
NAME                                         READY   STATUS    RESTARTS   AGE
vpa-admission-controller-754ccfdf99-pkxnl    1/1     Running   0          45s
vpa-recommender-667f9769fb-84rl5             1/1     Running   0          46s
vpa-updater-696b8787f9-6665j                 1/1     Running   0          46s

 

- VPA Admission-Controller : VPA 업데이터가 Pod 를 제거하고 다시 시작할 때마다 새 Pod 가 시작되기 전에 Webhook 를 사용하여 CPU 및 메모리 설정을 변경합니다.

- VPA Recommender : Metric Server 의 정보를 참조하여 적합한 리소스 크기를 추천합니다.

- VPA Updater : 1분에 1회씩 변경 사항을 확인하고 업데이트 합니다.

 

VPA 사용자 지정 리소스 정의가 생성되었는지 확인합니다.
# kubectl get customresourcedefinition | grep verticalpodautoscalers

verticalpodautoscalers.autoscaling.k8s.io             2023-12-29T07:32:30Z

 

 

2. Pod 생성

 

Deployment 로 생성한 Pod 에 적용이 잘 되는지 확인해보겠습니다.

아래와 같이 Deployment 구성 파일을 작성합니다.

# vi deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 1
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginxinc/nginx-unprivileged:latest
        resources:
          limits:
            cpu: 100m
            memory: 256Mi
          requests:
            cpu: 50m
            memory: 128Mi
        securityContext:
          allowPrivilegeEscalation: false
          capabilities:
            drop: ["ALL"]
          runAsNonRoot: true
          seccompProfile:
            type: RuntimeDefault

 

작성한 yaml 파일을 적용합니다.

# kubectl apply -f deployment.yaml

deployment.apps/nginx created

 

생성된 Pod 이름을 확인합니다.

# kubectl get pod

NAME                                                     READY   STATUS      RESTARTS   AGE
nginx-7f856c878-gbk77                                    1/1     Running     0          7m43s

 

Pod 에 적용된 자원 요청 및 제한값을 확인합니다.

# kubectl describe pod nginx-7f856c878-gbk77 |grep -E 'cpu|memory'
      cpu:     100m
      memory:  256Mi
      cpu:        50m
      memory:     128Mi

 

변경을 위해 Vertical Pod Autoscaler 구성 파일을 작성합니다.

# vi vpa.yaml

apiVersion: "autoscaling.k8s.io/v1"
kind: VerticalPodAutoscaler
metadata:
  name: nginx-vpa
spec:
  targetRef:
    apiVersion: "v1"
    kind: Deployment
    name: nginx
  updatePolicy:
    updateMode: "Auto"
  resourcePolicy:
    containerPolicies:
      - containerName: '*'
        minAllowed:
          cpu: 100m
          memory: 256Mi
        maxAllowed:
          cpu: 200m
          memory: 512Mi
        controlledResources: ["cpu", "memory"]

 

작성한 yaml 파일을 적용합니다.

# kubectl apply -f vpa.yaml

verticalpodautoscaler.autoscaling.k8s.io/nginx-vpa created

 

생성한 VPA 를 확인합니다.

VPA Updater 가 1분 간격으로 변경 사항을 확인하고 업데이트 하기 때문에 조금 기다려야 정확한 내용 확인이 가능합니다.

# kubectl get vpa
NAME        MODE   CPU    MEM     PROVIDED   AGE
nginx-vpa   Auto   100m   256Mi   True       8m28s

 

자세한 VPA 정보를 확인합니다.

# kubectl describe vpa nginx-vpa

...

Status:
  Conditions:
    Last Transition Time:  2024-01-02T05:17:45Z
    Status:                True
    Type:                  RecommendationProvided
  Recommendation:
    Container Recommendations:
      Container Name:  nginx
      Lower Bound:
        Cpu:     100m
        Memory:  256Mi
      Target:
        Cpu:     100m
        Memory:  256Mi
      Uncapped Target:
        Cpu:     25m
        Memory:  262144k
      Upper Bound:
        Cpu:     100m
        Memory:  256Mi

...

 

이미 생성되어 있는 Pod 에는 적용되지 않으므로 Pod 를 삭제하여 재생성 되도록 합니다.

# kubectl delete pod nginx-7f856c878-gbk77

pod "nginx-7f856c878-gbk77" deleted

 

재생성된 Pod 이름을 확인합니다.

# kubectl get pod
NAME                                                     READY   STATUS      RESTARTS   AGE
nginx-75954b4f8d-6g54j                                   1/1     Running     0          62s

 

새로 적용된 자원 요청 및 제한값을 확인합니다.

Deployment 의 설정값보다 VPA 설정값이 우선시 되는것을 확인하였습니다.

# kubectl describe pod nginx-75954b4f8d-6g54j |grep -E 'cpu|memory'

                  vpaUpdates: Pod resources updated by nginx-vpa: container 0: cpu request, memory request, cpu limit, memory limit
      cpu:     200m
      memory:  512Mi
      cpu:        100m
      memory:     256Mi

 

참고로, VPA 에서 Deployment 가 인식되는 시간 (최대 1분) 이 필요한데, VPA 를 먼저 정의한 다음에 Deployment (Pod 자동 생성) 를 생성한다 하더라도 VPA 가 Deployment 를 인식하기 전에 Pod 가 먼저 생성되는 경우가 많으므로 Pod 삭제 작업은 꼭 필요합니다.

삭제 작업 없이 Pod 를 생성하는대로 적용하고 싶으면, Deployment 생성시 replicas: 0 으로 먼저 적용하고, VPA 에서 인식이 되면 replicas: 1 등으로 수정, 적용하세요. Deployment 인식 이후에 생성된 Pod 이므로 VPA 요청 및 제한값에 맞추어 생성됩니다.

 

반응형

댓글()

Kubernetes 에서 Cloud Foundry Service 대체 구성하기

리눅스/PaaS|2023. 12. 27. 09:28
반응형

Cloud Foundry 환경에서는 보통 BOSH 로 Service 를 구현합니다. 하지만 BOSH 를 사용할 수 없는 경우에는 Helm 또는 Kubectl 명령을 이용해 서비스 구성이 가능합니다. 본 매뉴얼에서는 Helm 또는 Kubectl 을 이용해 Cloud Foundry Service (MySQL) 를 구성하는 방법에 대해 설명합니다.

- 목적 : CF 서비스나 Helm, Kubectl 모두 결과적으로 MySQL Pod 를 생성하고 네트워크 연결이 가능하면 되는 것

 

 

[ Helm 을 이용한 방법 ]

 

Helm 은 Kubernetes 애플리케이션을 관리하기 위한 오픈 소스 패키지 관리 도구입니다. Helm 은 애플리케이션을 쉽게 배포하고 업데이트하며, Kubernetes 클러스터에서 애플리케이션의 버전 관리를 지원합니다. OS 에서 자주 사용되는 yum 이나 apt 명령과 같이 Kubernetes 운영이 쉽도록 도와주는 도구라고 생각하면 이해가 쉽습니다.

 

 

1. 네임스페이스 확인

 

MySQL 서비스를 배포할 네임스페이스 이름을 확인합니다.

# kubectl get ns
NAME                                            STATUS   AGE
cert-manager                                    Active   19d
cf                                              Active   19d
cf-org-32cdb0e1-4d3e-40f5-878d-898aacb136ee     Active   19d
cf-space-5fd2f012-5436-4fbd-82b5-e25b701437d3   Active   19d
default                                         Active   19d
korifi-system                                   Active   19d
kpack                                           Active   19d
kube-node-lease                                 Active   19d
kube-public                                     Active   19d
kube-system                                     Active   19d
local-path-storage                              Active   19d
metallb-system                                  Active   19d
projectcontour                                  Active   19d

 

* 참고

작업 편의를 위해 컨텍스트 (네임스페이스) 를 변경해도 됩니다. 그러면 이후의 명령이나 설정에서 네임스페이스를 입력해야 하는 수고를 덜 수 있습니다. 여기에서는 방법을 알려드리지만, 이후의 명령이나 설정에서는 네임스페이스를 추가하도록 하겠습니다.

# kubectl config set-context --current --namespace=cf-space-5fd2f012-5436-4fbd-82b5-e25b701437d3

 

 

2. Helm Repository 추가

 

Helm 명령으로 MySQL 을 설치하기 위해 Repository 를 추가합니다.

# helm repo add bitnami https://charts.bitnami.com/bitnami

 

추가한 Repository 를 확인합니다.

# helm repo list
NAME    URL                               
bitnami https://charts.bitnami.com/bitnami

 

설치 가능한 서비스 목록을 확인합니다.

# helm search repo bitnami

(결과 생략)

 

 

3. MySQL 설치

 

확인된 네임스페이스에 아래와 같이 MySQL 을 설치 합니다.

root 패스워드는 추후 설치 가능하지만 여기에서는 설치할때 같이 적용하였습니다.

패스워드는 숫자만 입력하는 것을 허용하지 않으므로 문자를 반드시 포함해야 합니다.

# helm install my-mysql --namespace cf-space-5fd2f012-5436-4fbd-82b5-e25b701437d3 --set auth.rootPassword="pw12345678bitnami/mysql

 

참고로 MySQL 을 다시 삭제하려면 helm uninstall my-mysql -n cf-space-5fd2f012-5436-4fbd-82b5-e25b701437d3 명령을 사용하면 됩니다.

설치된 Helm 릴리즈 목록을 확인합니다.

# helm ls -n cf-space-5fd2f012-5436-4fbd-82b5-e25b701437d3
NAME     NAMESPACE                                     REVISION UPDATED                                 STATUS   CHART        APP VERSION
my-mysql cf-space-5fd2f012-5436-4fbd-82b5-e25b701437d3 1        2023-12-28 15:30:21.487507655 +0900 KST deployed mysql-9.15.0 8.0.35

 

생성된 MySQL Pod 의 IP 를 확인합니다.

# kubectl get pod -n cf-space-5fd2f012-5436-4fbd-82b5-e25b701437d3 -o wide

NAME                                                     READY   STATUS      RESTARTS   AGE    IP             NODE                 NOMINATED NODE   READINESS GATES
my-mysql-0                                               1/1     Running     0          104s   10.244.0.205   kind-control-plane   <none>           <none>

 

 

4. 배포된 소스와 연결 확인

 

cf push 명령으로 배포된 PHP 소스에서 MySQL 연결이 잘 되는지 확인해보겠습니다.

PHP 빌드팩이 준비되지 않으신 분은 아래 URL 을 참고해 주세요.

https://sysdocu.tistory.com/1863

 

아래와 같은 소스를 준비하고 cf push 명령으로 배포합니다.

* 주의

- Cloud Foundry 조직과 공간이 설치한 MySQL 의 공간과 동일해야 합니다.

- 소스에 위에서 확인했던 MySQL IP 를 넣어주세요.

# mkdir php-sample

# cd php-sample

# vi index.php

<?php
$host = "10.244.0.205";
$dbname = "mysql";
$username = "root";
$password = "pw12345678";

try {
    $conn = new PDO("mysql:host=$host;dbname=$dbname", $username, $password);
    $serverVersion = $conn->getAttribute(PDO::ATTR_SERVER_VERSION);
    echo "MySQL 연결 성공. 서버 버전 : " . $serverVersion;
} catch (PDOException $e) {
    echo "MySQL 연결 실패 : " . $e->getMessage();
}
?>

 

필요한 PHP 모듈을 추가합니다.

# mkdir .php.ini.d
# vi .php.ini.d/extentions.ini

extension = pdo
extension = pdo_mysql

 

소스를 배포합니다.

# cf push php1

(결과 생략)

 

출력된 URL 로 접근하여 PHP 소스와 MySQL 연결이 잘 되었는지 확인합니다.

# curl --insecure https://php1.apps.az1.sysdocu.kr 

MySQL 연결 성공. 서버 버전 : 8.0.35

 

 

[ Kubectl 을 이용한 방법 ]

 

Kubernetes 에서 기본으로 제공하는 Kubectl 명령으로도 MySQL 배포가 가능한데, Helm 과는 다르게 리소스 제한이 가능합니다. 특정 Pod 의 CPU, 메모리 등의 자원을 제한하기 위해서는 Kubernetes 의 리소스 제한 설정을 사용해야 합니다. 아래는 MySQL 을 실행하는 Pod 에 리소스 제한을 설정하는 예제입니다. 이 예제에서는 CPU 와 메모리, 용량에 각각 제한을 두었습니다.

 

 

1. MySQL Deployment 작성 및 적용

 

아래와 같이 Manifest 파일을 작성합니다.

# vi mysql.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: new-mysql
  namespace: cf-space-5fd2f012-5436-4fbd-82b5-e25b701437d3
spec:
  replicas: 1
  selector:
    matchLabels:
      app: new-mysql
  template:
    metadata:
      labels:
        app: new-mysql
    spec:
      securityContext:
        seccompProfile:
          type: RuntimeDefault
      containers:
      - name: mysql
        image: mysql:latest
        env:
          - name: MYSQL_ROOT_PASSWORD
            value: "12345678"
        resources:
          limits:
            memory: "512Mi"
            cpu: "0.5"
            ephemeral-storage: "5Gi"
          requests:
            memory: "256Mi"
            cpu: "0.25"
            ephemeral-storage: "5Gi"
        securityContext:
          allowPrivilegeEscalation: false
          capabilities:
            drop: ["ALL"]
          runAsNonRoot: true
          runAsUser: 1000

 

작성한 yaml 파일을 적용합니다.

# kubectl appy -f mysql.yaml

deployment.apps/new-mysql created

 

생성된 MySQL Pod 의 IP 를 확인합니다.

# kubectl get pod -n cf-space-5fd2f012-5436-4fbd-82b5-e25b701437d3 -o wide

NAME                                                     READY   STATUS      RESTARTS   AGE     IP             NODE                 NOMINATED NODE   READINESS GATES

new-mysql-9b45cb976-wx8zf                                1/1     Running     0          106s    10.244.0.193   kind-control-plane   <none>           <none>

 

 

2. 배포된 소스와 연결 확인

 

cf push 명령으로 배포된 PHP 소스에서 MySQL 연결이 잘 되는지 확인해보겠습니다.

PHP 빌드팩이 준비되지 않으신 분은 아래 URL 을 참고해 주세요.

https://sysdocu.tistory.com/1863

 

아래와 같은 소스를 준비하고 cf push 명령으로 배포합니다.

* 주의

- Cloud Foundry 조직과 공간이 설치한 MySQL 의 공간과 동일해야 합니다.

- 소스에 위에서 확인했던 MySQL IP 를 넣어주세요.

# mkdir php-sample

# cd php-sample

# vi index.php

<?php
$host = "10.244.0.193";
$dbname = "mysql";
$username = "root";
$password = "12345678";

try {
    $conn = new PDO("mysql:host=$host;dbname=$dbname", $username, $password);
    $serverVersion = $conn->getAttribute(PDO::ATTR_SERVER_VERSION);
    echo "MySQL 연결 성공. 서버 버전 : " . $serverVersion;
} catch (PDOException $e) {
    echo "MySQL 연결 실패 : " . $e->getMessage();
}
?>

 

필요한 PHP 모듈을 추가합니다.

# mkdir .php.ini.d
# vi .php.ini.d/extentions.ini

extension = pdo
extension = pdo_mysql

 

소스를 배포합니다.

# cf push php2

(결과 생략)

 

출력된 URL 로 접근하여 PHP 소스와 MySQL 연결이 잘 되었는지 확인합니다.

# curl --insecure https://php2.apps.az1.sysdocu.kr

MySQL 연결 성공. 서버 버전 : 8.2.0

 

반응형

댓글()

AWS Elastic Beanstalk 으로 PHP 소스 배포하기 (Console / CLI)

리눅스/PaaS|2023. 12. 26. 11:42
반응형

AWS Elastic Beanstalk 는 소스 파일을 업로드하기만 하면 Elastic Beanstalk 가 용량 프로비저닝부터 로드 밸런싱, 자동 크기 조정, 웹 애플리케이션 상태 모니터링에 이르기까지 배포를 자동으로 처리하며, 지속적인 완전관리형 패치 및 보안 업데이트를 제공합니다.

본 매뉴얼은 AWS Elastic Beanstalk 에서 제공하는 많은 기능들을 담은게 아닌 기초적인  소스 배포 방법만 다루었습니다. AWS 에 무료 가입 이후 콘솔에서 아래 절차를 따라 서비스를 이용하면 됩니다.

 

* 사전 작업 : AWS 회원가입 및 Elastic Beanstalk 콘솔 페이지 (https://console.aws.amazon.com/elasticbeanstalk) 이동 

 

 

[ 콘솔에서 배포 ]

 

1. 애플리케이션 생성

 

우측 상단에 잘 보이는 '애플리케이션 생성' 버튼을 클릭하고 아래 절차대로 진행합니다.

테스트 목적이므로 가장 간단한 내용으로 구성했으며 경우에 따라 설정값을 약간씩 조정 가능합니다.

 

1) 환경 구성
- 환경 티어 : 웹 서버 환경

2) 애플리케이션 정보
- 애플리케이션 이름 : sysdocu test

3) 환경 정보
- 환경 이름 : Sysdocutest-env
- 도메인 : sysdocutest (sysdocutest.eu-north-1.elasticbeanstalk.com 완성 도메인)
- 환경 설명 : test

4) 플랫폼
- 플랫폼 유형 : 관리형 플랫폼
- 플랫폼 : PHP
- 플랫폼 브랜치 : PHP 8.1 running on 64bit Amazon Linux 2023
- 플랫폼 버전 : 4.0.4 (Recommended)

5) 애플리케이션 코드
- 코드 업로드 (선택)      // 컴퓨터에서 소스를 업로드 하거나 Amazon S3 에서 복사할 수 있음
- 버전 레이블 : 0.0.1    // 코드에 대한 버전 입력
- 로컬 파일 (선택), 애플리케이션 업로드 (파일 선택)
* 여기에서 업로드 할 파일 (index.zip) 은 아래 내용으로 index.php 파일을 만든 후 zip 으로 압축하였습니다.
<?php
echo "Elastic Beanstalk !!<br>";
phpinfo();
?>

6) 사전 설정
- 구성 사전 설정 : 단일 인스턴스(프리 티어 사용 가능)

 

모든 값을 입력했으면, [다음] 버튼을 누릅니다.

 

 

2. 서비스 액세스

 

- 서비스 역할 : 새 서비스 역할 생성 및 사용
- 서비스 역할 이름 : aws-elasticbeanstalk-service-role
- EC2 키 페어 : https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/create-key-pairs.html 안내를 따라 Key Pair 파일을 생성하고 선택합니다.
- EC2 인스턴스 프로파일 : https://docs.aws.amazon.com/ko_kr/codedeploy/latest/userguide/getting-started-create-iam-instance-profile.html#getting-started-create-iam-instance-profile-console 안내를 따라 IAM 인스턴스 프로파일을 생성하고 선택합니다.

 

3. 네트워킹, 데이터베이스 및 태그 설정

 

아래 항목만 설정해 줍니다.

 

1) Virtual Private Cloud(VPC)

- VPC : 풀다운 메뉴를 누르면 사설대역이 하나 나오는데 이것을 선택합니다.

 

2) 인스턴스 설정

- 퍼블릭 IP 주소 : 활성화됨 (체크), 인스턴스 서브넷에 나온 가용 영역중 한개를 선택합니다. (여기에서는 172.31.0.0/20 을 선택 했습니다)


[다음] 버튼을 누릅니다.

 

4. 인스턴스 트래픽 및 조정 구성

 

아래 항목만 설정해 줍니다.

 

1) 인스턴스 유형 : t2.nano 또는 t3.nano   // 제일 저렴한 상품


[다음] 버튼을 누릅니다.

 


5. 업데이트, 모니터링 및 로깅 구성

 

아무것도 하지 않고 넘어가겠습니다.
[다음] 버튼을 누릅니다.

 

6. 검토


지금까지 선택한 사항이 출력되므로, 한번 훑어보고 잘못된 선택이 포함된경우 [편집] 을 눌러 수정하고, 이상이 없을 경우 [제출] 버튼을 누릅니다.
제출 버튼을 누른 경우 [콘솔] 페이지로 돌아오게 되며, Elastic Beanstalk 가 환경을 시작하기 까지 몇 분정도 소요됩니다.
기다려 봅니다.

 

상단 알림바에서 '환경이 성공적으로 시작되었습니다.' 라는 메세지가 출력되면 정보란에 출력된 도메인을 선택하여 소스코드가 잘 보여지는지 확인합니다.

 

 

* 참고 : Laravel 소스 배포

 

Laravel 소스를 배포할때는 초기 index 페이지가 /public 디렉토리에 존재하므로 위 절차대로 진행시 403 에러가 출력됩니다.

해결 방법으로는, 어플리케이션 '환경' 을 수정하면 되는데 위 '5. 업데이트, 모니터링 및 로깅 구성' 범주에 있는 문서 루트값을 입력해주면 됩니다.

- 문서 루트 : /public

 

 

* 참고 : 데이터베이스 사용

 

데이터베이스를 사용하고자 할 경우 '3. 네트워킹, 데이터베이스 및 태그 설정' 범주의 데이터베이스 부분을 활성화 시키고 아래 내용을 설정합니다. 아래 예시는 임의대로 입력하였으며, 테스트 또는 서비스에 사용에 적합한 값으로 변경, 적용하여 사용하시기 바랍니다.

'인스턴스 클래스' 에서 선택한 상품의 요금이 추가 청구 됩니다.

 

1) 데이터베이스 설정

- 엔진 : mysql

- 엔진 버전 : 8.0.35

- 인스턴스 클래스 : db.t3.micro

- 스토리지 : 5

- 사용자 이름 : sysdocu

- 암호 : 12345678

- 가용성 : 낮음(AZ 1개)

- 데이터베이스 삭제 정책 : 삭제

 

 

[ CLI 에서 배포 ]

 

1. CLI 명령어 설치

 

eb 명령어 설치를 간편하게 하기 위해 스크립트를 제공합니다. 아래와 같이 스크립트를 이용해 설치를 진행합니다.

 

# git clone https://github.com/aws/aws-elastic-beanstalk-cli-setup.git

# python ./aws-elastic-beanstalk-cli-setup/scripts/ebcli_installer.py

 

* eb 명령어는 python 라는 명령어를 사용하므로, python3 이 설치된 시스템일 경우 아래와 같이 링크파일을 생성해주면 됩니다.

# ln -s /usr/bin/python3 /usr/bin/python

 

설치된 eb 명령어 버전을 확인합니다.

# eb --version
EB CLI 3.20.10 (Python 3.10.12 (main, Nov 20 2023, 15:14:05) [GCC 11.4.0])

 

 

2. 애플리케이션 환경 설정

 

php 파일이 준비된 디렉토리에서 실행해야 합니다.

아래는 간단히 php 파일을 생성한 예제 이므로, 개인적인 소스 코드를 가지고 있을 경우 해당 디렉토리로 이동합니다.

# mkdir php-sample

# cd php-sample

# vi index.php

<?php
echo "Elastic Beanstalk !!";
phpinfo();
?>

 

 

애플리케이션 배포를 위한 환경 설정을 먼저 진행합니다.

# eb init

Select a default region
1) us-east-1 : US East (N. Virginia)
2) us-west-1 : US West (N. California)
3) us-west-2 : US West (Oregon)
4) eu-west-1 : EU (Ireland)
5) eu-central-1 : EU (Frankfurt)
6) ap-south-1 : Asia Pacific (Mumbai)
7) ap-southeast-1 : Asia Pacific (Singapore)
8) ap-southeast-2 : Asia Pacific (Sydney)
9) ap-northeast-1 : Asia Pacific (Tokyo)
10) ap-northeast-2 : Asia Pacific (Seoul)
11) sa-east-1 : South America (Sao Paulo)
12) cn-north-1 : China (Beijing)
13) cn-northwest-1 : China (Ningxia)
14) us-east-2 : US East (Ohio)
15) ca-central-1 : Canada (Central)
16) eu-west-2 : EU (London)
17) eu-west-3 : EU (Paris)
18) eu-north-1 : EU (Stockholm)
19) eu-south-1 : EU (Milano)
20) ap-east-1 : Asia Pacific (Hong Kong)
21) me-south-1 : Middle East (Bahrain)
22) il-central-1 : Middle East (Israel)
23) af-south-1 : Africa (Cape Town)
24) ap-southeast-3 : Asia Pacific (Jakarta)
25) ap-northeast-3 : Asia Pacific (Osaka)
(default is 3): 10

 

명령 실행하면 리전 선택 화면이 나옵니다.

Seoul 을 선택하고 진행합니다.


You have not yet set up your credentials or your credentials are incorrect 
You must provide your credentials.
(aws-access-id): AKIATULSZDRUVAVPUM4H
(aws-secret-key): w7L9tc6vtTy5TENKE8YWARz9SqADnuLG1gs02WzL

 

액세스 키는 AWS Identity and Access Management 콘솔에서 생성됩니다. 키가 없는 경우 아래 URL 을 참고하여 생성합니다.

https://docs.aws.amazon.com/ko_kr/elasticbeanstalk/latest/dg/eb-cli3-configuration.html

 

Enter Application Name
(default is "root"): sysdocu-eb
Application sysdocu-eb has been created.

 

생성할 애플리케이션 이름을 입력하고 아래 단계에서 개발언어를 선택합니다.

여기에서는 PHP 소스를 배포하기 위해 7번을 선택하였습니다.

 

It appears you are using Node.js. Is this correct?
(Y/n): n
Select a platform.
1) .NET Core on Linux
2) .NET on Windows Server
3) Docker
4) Go
5) Java
6) Node.js
7) PHP
8) Packer
9) Python
10) Ruby
11) Tomcat
(make a selection): 7

 

플랫폼 버전을 선택합니다.


Select a platform branch.
1) PHP 8.2 running on 64bit Amazon Linux 2023
2) PHP 8.1 running on 64bit Amazon Linux 2023
3) PHP 8.1 running on 64bit Amazon Linux 2
4) PHP 8.0 running on 64bit Amazon Linux 2 (Deprecated)
(default is 1): 1

 

인스턴스에 SSH 접속이 필요한 경우 Y 를 입력합니다.


Cannot setup CodeCommit because there is no Source Control setup, continuing with initialization
Do you want to set up SSH for your instances?
(Y/n): y

 

Key Pair 가 없는 경우 아래와 같이 생성합니다.

 

Type a keypair name.
(Default is aws-eb): sysdocu_keypair

Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase): (엔터)
Enter same passphrase again: (엔터)
Your identification has been saved in /root/.ssh/sysdocu_keypair
Your public key has been saved in /root/.ssh/sysdocu_keypair.pub
The key fingerprint is:
SHA256:Yp/23Lnk4spaDXQWxgH16tsf8Peo0t3Sclx5DWLwfhs sysdocu_keypair
The key's randomart image is:
+---[RSA 3072]----+
|        .+=.     |
|         .oo     |
|        . oo.    |
|       . o .+ .  |
|      o S .o.. .o|
|     . o =  .oE.+|
|        = o..oo*+|
|       + oo*..=+*|
|      ..oo=oB+o+.|
+----[SHA256]-----+
WARNING: Uploaded SSH public key for "sysdocu_keypair" into EC2 for region ap-northeast-2.

 

여기까지 진행하면 현재 디렉토리에 .elasticbeanstalk 디렉토리와 .gitignore 파일이 생성됩니다.

참고로 파일이 생성된 상태에서 위 설정을 다시 선택하고 싶을 경우에는 eb init --interactive 명령을 사용합니다.

이번에는 eb create 명령을 실행합니다.

 

 

3. 애플리케이션 배포

 

# eb create
Enter Environment Name
(default is sysdocu-eb-dev): (엔터)
Enter DNS CNAME prefix
(default is sysdocu-eb-dev): (엔터)

Select a load balancer type
1) classic
2) application
3) network
(default is 2): (엔터)


Would you like to enable Spot Fleet requests for this environment? (y/N): n
Creating application version archive "app-231227_105647010648".
Uploading php-sample/app-231227_105647010648.zip to S3. This may take a while.
Upload Complete.
Environment details for: php-sample-dev
  Application name: php-sample
  Region: ap-northeast-2
  Deployed Version: app-231227_105647010648
  Environment ID: e-ukt3apx7xv
  Platform: arn:aws:elasticbeanstalk:ap-northeast-2::platform/PHP 8.2 running on 64bit Amazon Linux 2023/4.0.4
  Tier: WebServer-Standard-1.0
  CNAME: php-sample-dev.ap-northeast-2.elasticbeanstalk.com
  Updated: 2023-12-27 01:56:49.739000+00:00
Printing Status:
2023-12-27 01:56:48    INFO    createEnvironment is starting.
2023-12-27 01:56:49    INFO    Using elasticbeanstalk-ap-northeast-2-249900375145 as Amazon S3 storage bucket for environment data.
2023-12-27 01:57:15    INFO    Created security group named: sg-03917a84777b4c349
2023-12-27 01:57:31    INFO    Created security group named: awseb-e-ukt3apx7xv-stack-AWSEBSecurityGroup-119R1T01HLB5M
2023-12-27 01:57:31    INFO    Created Auto Scaling launch configuration named: awseb-e-ukt3apx7xv-stack-AWSEBAutoScalingLaunchConfiguration-vyMuxcBrdNwa
2023-12-27 01:57:31    INFO    Created target group named: arn:aws:elasticloadbalancing:ap-northeast-2:249900375145:targetgroup/awseb-AWSEB-S3ZQNDBFXRE4/07a7ad3c4fe8bb6a
2023-12-27 01:57:46    INFO    Created Auto Scaling group named: awseb-e-ukt3apx7xv-stack-AWSEBAutoScalingGroup-FCDZ3L234LAU
2023-12-27 01:57:47    INFO    Waiting for EC2 instances to launch. This may take a few minutes.
2023-12-27 01:57:47    INFO    Created Auto Scaling group policy named: arn:aws:autoscaling:ap-northeast-2:249900375145:scalingPolicy:5b8a67d5-b413-4224-ade6-2e85c25b1417:autoScalingGroupName/awseb-e-ukt3apx7xv-stack-AWSEBAutoScalingGroup-FCDZ3L234LAU:policyName/awseb-e-ukt3apx7xv-stack-AWSEBAutoScalingScaleDownPolicy-nAUVg0sg5nRn
2023-12-27 01:57:47    INFO    Created Auto Scaling group policy named: arn:aws:autoscaling:ap-northeast-2:249900375145:scalingPolicy:d9978a08-e318-484c-a4b3-8368b0276185:autoScalingGroupName/awseb-e-ukt3apx7xv-stack-AWSEBAutoScalingGroup-FCDZ3L234LAU:policyName/awseb-e-ukt3apx7xv-stack-AWSEBAutoScalingScaleUpPolicy-Neqs0FM41Apy
2023-12-27 01:58:02    INFO    Created CloudWatch alarm named: awseb-e-ukt3apx7xv-stack-AWSEBCloudwatchAlarmLow-FJ5YorP1s1Bh
2023-12-27 01:58:02    INFO    Created CloudWatch alarm named: awseb-e-ukt3apx7xv-stack-AWSEBCloudwatchAlarmHigh-uPMubhxbNaq8
2023-12-27 01:59:53    INFO    Created load balancer named: arn:aws:elasticloadbalancing:ap-northeast-2:249900375145:loadbalancer/app/awseb--AWSEB-aeBAFiqHxWdL/92ce8b40aa34ddaa
2023-12-27 01:59:54    INFO    Created Load Balancer listener named: arn:aws:elasticloadbalancing:ap-northeast-2:249900375145:listener/app/awseb--AWSEB-aeBAFiqHxWdL/92ce8b40aa34ddaa/25ced3633c1d40d2
2023-12-27 01:59:58    INFO    Instance deployment: You didn't include a 'composer.json' file in your source bundle. The deployment didn't install Composer dependencies.
2023-12-27 02:00:03    INFO    Instance deployment completed successfully.
2023-12-27 02:01:08    INFO    Successfully launched environment: php-sample-dev

 

맨 마지막 Successfully launched 로그 확인 후, 웹브라우저에서 조금 위에 출력된 CNAME 항목의 도메인으로 접근하면 개발한 소스코드 내용이 출력됩니다.

 

 

4. 애플리케이션 삭제

 

사용하지 않는 AWS 리소스에 대한 요금이 발생하지 않도록 실행 중인 환경을 종료합니다.

그런데 왜인지 CLI 에서 생성한 Elastic Beanstalk 애플리케이션은 콘솔에서 보이지 않습니다.

삭제도 CLI 에서 진행해야 하는데, 배포했던 소스 디렉토리 내에서 아래와 같이 삭제 명령을 실행합니다.

관련 옵션은 Document 를 참고하세요.

https://docs.aws.amazon.com/ko_kr/elasticbeanstalk/latest/dg/eb3-terminate.html

 

# eb terminate
The environment "php-sample-dev" and all associated instances will be terminated.
To confirm, type the environment name: php-sample-dev
2023-12-27 02:23:35    INFO    terminateEnvironment is starting.
2023-12-27 02:23:36    INFO    Validating environment's EC2 instances have termination protection disabled before performing termination.
2023-12-27 02:23:36    INFO    Finished validating environment's EC2 instances for termination protection.
2023-12-27 02:23:54    INFO    Deleted CloudWatch alarm named: awseb-e-ukt3apx7xv-stack-AWSEBCloudwatchAlarmLow-FJ5YorP1s1Bh 
2023-12-27 02:23:54    INFO    Deleted Load Balancer listener named: arn:aws:elasticloadbalancing:ap-northeast-2:249900375145:listener/app/awseb--AWSEB-aeBAFiqHxWdL/92ce8b40aa34ddaa/25ced3633c1d40d2
2023-12-27 02:23:54    INFO    Deleted CloudWatch alarm named: awseb-e-ukt3apx7xv-stack-AWSEBCloudwatchAlarmHigh-uPMubhxbNaq8 
2023-12-27 02:23:54    INFO    Deleted Auto Scaling group policy named: arn:aws:autoscaling:ap-northeast-2:249900375145:scalingPolicy:5b8a67d5-b413-4224-ade6-2e85c25b1417:autoScalingGroupName/awseb-e-ukt3apx7xv-stack-AWSEBAutoScalingGroup-FCDZ3L234LAU:policyName/awseb-e-ukt3apx7xv-stack-AWSEBAutoScalingScaleDownPolicy-nAUVg0sg5nRn
2023-12-27 02:23:54    INFO    Deleted Auto Scaling group policy named: arn:aws:autoscaling:ap-northeast-2:249900375145:scalingPolicy:d9978a08-e318-484c-a4b3-8368b0276185:autoScalingGroupName/awseb-e-ukt3apx7xv-stack-AWSEBAutoScalingGroup-FCDZ3L234LAU:policyName/awseb-e-ukt3apx7xv-stack-AWSEBAutoScalingScaleUpPolicy-Neqs0FM41Apy
2023-12-27 02:23:54    INFO    Waiting for EC2 instances to terminate. This may take a few minutes.
2023-12-27 02:24:55    INFO    Deleted load balancer named: arn:aws:elasticloadbalancing:ap-northeast-2:249900375145:loadbalancer/app/awseb--AWSEB-aeBAFiqHxWdL/92ce8b40aa34ddaa
2023-12-27 02:25:25    INFO    Deleted Auto Scaling group named: awseb-e-ukt3apx7xv-stack-AWSEBAutoScalingGroup-FCDZ3L234LAU
2023-12-27 02:25:26    INFO    Deleted target group named: arn:aws:elasticloadbalancing:ap-northeast-2:249900375145:targetgroup/awseb-AWSEB-S3ZQNDBFXRE4/07a7ad3c4fe8bb6a
2023-12-27 02:25:26    INFO    Deleted Auto Scaling launch configuration named: awseb-e-ukt3apx7xv-stack-AWSEBAutoScalingLaunchConfiguration-vyMuxcBrdNwa
2023-12-27 02:25:26    INFO    Deleted security group named: awseb-e-ukt3apx7xv-stack-AWSEBSecurityGroup-119R1T01HLB5M
2023-12-27 02:25:26    INFO    Deleted security group named: sg-03917a84777b4c349
2023-12-27 02:25:29    INFO    Deleting SNS topic for environment php-sample-dev.
2023-12-27 02:25:30    INFO    terminateEnvironment completed successfully.

 

Document 에서는 모든 구성 요소 삭제를 위해 아래와 같은 옵션을 제공합니다.

삭제할 요소가 있는지 한 번 더 확인합니다.

# eb terminate --all
The application "php-sample" and all its resources will be deleted.
This application currently has the following:
Running environments: 0
Configuration templates: 0
Application versions: 1

To confirm, type the application name: php-sample
Removing application versions from s3.
2023-12-27 02:34:31    INFO    deleteApplication is starting.
2023-12-27 02:34:31    INFO    Validating environment before performing delete
2023-12-27 02:34:31    INFO    Invoking Environment Termination workflows.
2023-12-27 02:34:32    INFO    The environment termination step is done.
2023-12-27 02:34:32    INFO    The application has been deleted successfully.

 

 

반응형

댓글()

Ubuntu 22.04 에서 NSD 4.8.0 설치하기

리눅스/DNS|2023. 12. 19. 14:40
보호되어 있는 글입니다.
내용을 보시려면 비밀번호를 입력하세요.

Ubuntu 22.04 에서 MaraDNS 3.5.0036 설치하기

리눅스/DNS|2023. 12. 17. 18:05
보호되어 있는 글입니다.
내용을 보시려면 비밀번호를 입력하세요.

[C++] 파일쓰기 예제

프로그래밍/C, C++|2023. 12. 11. 17:02
반응형

#include<fstream>
#include<iostream>
#include<string>
 
using namespace std;
 
int main() {
    fstream my_file;
    my_file.open("a.txt", ios::out);    // 이 파일이 생성됩니다.
    my_file << "test" << endl;           // test 라는 내용이 들어가며
    my_file.write("12345", 5);           // 이렇게도 추가할 수 있습니다.
    my_file.close();
}

 

 

* 참고로 위 코드는 반복 실행시 계속 새로운 파일로 쓰이게 되며,

파일이 있을때 내용을 추가하고자 할경우 아래와 같이 ios::app (append) 플래그를 사용하면 됩니다.

my_file.open("a.txt", ios::out | ios::app);

 

반응형

댓글()

CloudFoundry Paketo-buildpacks 버전 관리 (빌드팩 내 버전 선택, 구버전 사용, 버전 고정 방법)

리눅스/PaaS|2023. 12. 8. 13:15
반응형

1. 빌드팩 내 PHP 버전 변경하여 배포하기

 

현재 릴리즈된 버전 PHP Buildpack 2.11.1 은 아래와 같은 PHP 버전을 지원합니다.

[8.1.23, 8.1.24 (Default), 8.2.10, 8.2.11]

그냥 cf push 를 하면 기본적으로 Default 라고 표시되어 있는 8.1.24 버전으로 배포되는데,

다른 버전을 지정하여 배포하고 싶을 경우 아래와 같은 작업을 진행합니다.

여기에서는 8.1.23 버전으로 배포해 보겠습니다.

(사전에 Composer 가 설치되어 있어야 하는데, 설치 방법은 https://sysdocu.tistory.com/1874 에서 확인해 주세요)

 

PHP 소스 코드가 있는 디렉토리에서 composer.json 파일을 아래 내용으로 작성합니다.

# vi composer.json

{
  "require": {
    "php": "8.1.23"
  }
}

 

composer.json 파일을 바탕으로 composer.lock 파일을 생성합니다.

# composer install --ignore-platform-reqs

 

이제 배포를 하면 원하는 PHP 버전의 컨테이너로 생성됩니다.

# cf push php-new-app

 

 

2. 빌드팩 버전 변경하기

 

위와 같이 빌드팩을 추가하면 항상 최신버전의 빌드팩이 자동 선택되어 집니다.

그래서 원하는 특정 빌드팩 버전으로 변경하고 싶을때는 아래와 같은 절차를 따르면 됩니다.

(또는 제공하는 서비스 버전을 고정하기 위해 사용)

 

아래 PHP 릴리즈 정보 페이지를 방문합니다.

현재 매뉴얼 작성일 기준으로 최신 PHP 빌드팩은 2.11.1 버전입니다. PHP 빌드팩 2.9.4 로 서비스하기 위해 2.9.4 버전 정보의 다이제스트값 (예: sha256:9b72bd475c4fdcbaf6d8b2c99508798af7fda4029a26022ab3e1c4b62e08c6cf) 을 복사합니다.

https://github.com/paketo-buildpacks/php/releases

 

---------- 또는 ----------

웹브라우저에서 아래와 같은 형태의 URL 로 Google Container Registry 에 접속합니다.

여기에서는 PHP 로 접속하였지만, 다른 언어의 버전 변경을 원할때는 URL 맨 뒤에 개발언어만 바꿔주면 됩니다.
https://gcr.io/paketo-buildpacks/php
현재 매뉴얼 작성일 기준으로 최신 PHP 빌드팩은 2.11.1 버전입니다. PHP 빌드팩 2.9.4 로 서비스하기 위해 태그값이 2.9.4 로 되어 있는 항목의 이름을 클릭해 상세 페이지를 출력시킵니다.

출력된 내용에서 다이제스트값 (예: sha256:9b72bd475c4fdcbaf6d8b2c99508798af7fda4029a26022ab3e1c4b62e08c6cf) 을 복사합니다.

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

 

Kubernetes Cluster 에서 아래와 같이 space 네임스페이스의 ClusterStore 를 수정합니다.

# kubectl edit clusterstore cf-default-buildpacks -n tutorial-space

...

spec:
  sources:
  - image: gcr.io/paketo-buildpacks/java
  - image: gcr.io/paketo-buildpacks/nodejs
  - image: gcr.io/paketo-buildpacks/ruby
  - image: gcr.io/paketo-buildpacks/procfile
  - image: gcr.io/paketo-buildpacks/go
  - image: gcr.io/paketo-buildpacks/php@sha256:9b72bd475c4fdcbaf6d8b2c99508798af7fda4029a26022ab3e1c4b62e08c6cf

...

 

빌드팩 종류 뒤에 @ 와 복사했던 다이제스트값을 추가하고 저장합니다.

cf buildpacks 명령으로 빌드팩 리스트를 확인하면 변경된 버전이 보입니다.

(버전이 반영되기까지 시간이 소요될 수 있음)

# cf buildpacks
Getting buildpacks as cf-admin...

position   name                         stack                        enabled   locked   filename
1          paketo-buildpacks/php        io.buildpacks.stacks.jammy   true      false    paketo-buildpacks/php@2.9.4
2          paketo-buildpacks/java       io.buildpacks.stacks.jammy   true      false    paketo-buildpacks/java@10.3.3
3          paketo-buildpacks/go         io.buildpacks.stacks.jammy   true      false    paketo-buildpacks/go@4.6.1
4          paketo-buildpacks/nodejs     io.buildpacks.stacks.jammy   true      false    paketo-buildpacks/nodejs@2.0.0
5          paketo-buildpacks/ruby       io.buildpacks.stacks.jammy   true      false    paketo-buildpacks/ruby@0.41.1
6          paketo-buildpacks/procfile   io.buildpacks.stacks.jammy   true      false    paketo-buildpacks/procfile@5.6.7

 

이제 변경된 상태에서 cf push 명령으로 앱을 배포하면 해당 버전에서 사용하는 PHP 버전으로 배포가 됩니다.

빌드팩 버전에 따라 제공되는 PHP 버전 확인 방법은 아래 포스팅을 참고해주세요.

https://sysdocu.tistory.com/1873

 

반응형

댓글()

Heroku 에 PHP 애플리케이션 배포하는 2가지 방법 (Web, CLI), Laravel 배포 방법

리눅스/PaaS|2023. 11. 24. 16:33
반응형

몇가지 방법이 더 있겠지만 여기에서는 제가 해본 2가지 방법에 대해 설명합니다.

아래 내용을 진행하기 전에 PC 에 Heroku CLI 와 Git 명령어를 설치해야 합니다. 아래 URL 을 참고해 주세요.

추가로 Heroku 가입, PHP 개발 소스는 미리 준비 하였다는 가정하에 진행합니다.

https://devcenter.heroku.com/articles/heroku-cli

 

 

1. Heroku 웹에서 배포 (with Github)

 

- 방법 : Heroku 웹사이트에서 Github 소스를 배포

 

Heroku 로그인 후 대시보드 (https://dashboard.heroku.com/apps) 에 들어갑니다.

 

[Create new app] 을 클릭

 

App name : php1 입력, Choose a region : United States 선택 후 [Create app] 클릭

 

Deployment method 에서 GitHub 선택

 

Search for a repository to connect to 에서 계정과 repo-name 입력, [Search] 클릭, 출력된 주소 옆에 [Connect] 클릭

 

- Automatic deploys

- Manual deploys

이렇게 두개 섹션이 출력되는데 아래 Manual deploys 에서 [Deploy Branch] 를 클릭하면, Building 결과가 실시간으로 출력됩니다.

 

작업이 완료되면 하단의 [View] 버튼을 눌러 결과를 확인합니다.

 

 

2. Heroku CLI 에서 배포

 

- 방법 : PC CLI 에서 로컬 소스를 배포

 

CLI 에서 PHP소스 디렉토리로 이동해 아래 명령을 순차적으로 실행합니다.

CLI 에서 Heroku 사용자로 로그인을 할때 URL 이 출력되는데 이를 웹브라우저에서 접속해 [로그인] 버튼을 누르면 CLI 에서 로그인 되어집니다.

# heroku login

 

php2 앱을 생성합니다.

# heroku create php2

Creating ⬢ php2... done
https://php2-637bfaa5dd48.herokuapp.com/ | https://git.heroku.com/php2.git

 

추가 명령을 실행합니다.

# git init

# git add .
# git commit -m 'new project'
# heroku git:remote -a php2
# git push heroku mastar    // 에러 발생시 master 대신 main 입력 후, 재실행

 

CLI 에서 현재 디렉토리의 소스가 Heroku 로 업로드 되며 Building 결과가 실시간으로 출력됩니다.

 

작업의 완료되면 아래와 같은 URL 이 출력되는데, 브라우저로 접근해 결과를 확인합니다.

remote:        https://php2-d394c22d4ef6.herokuapp.com/ deployed to Heroku

 

* 소스 업데이트

소스 수정 후에 다시 반영하려면 아래와 같은 절차를 따릅니다.

# git add .

# git commit -m "edited"

# git push heroku master    // 에러 발생시 master 대신 main 입력 후, 재실행

 

 

3. Laravel 배포

 

Laravel 소스를 배포하기 위한 Composer 설치 및 Laravel 프로젝트 생성 방법은 아래 포스팅을 참고해 주세요.

https://sysdocu.tistory.com/1874

이후의 방법은 아래 URL 을 참고하여 재작성 하였습니다.

https://devcenter.heroku.com/articles/getting-started-with-laravel

 

- 방법 : PC CLI 에서 로컬 Laravel 소스를 배포

 

위 포스팅에서와 같이 Laravel 프로젝트 생성 준비가 되었다면, 다음과 같은 과정을 거쳐 배포가 가능합니다.

Laravel 프로젝트를 생성합니다. (예 : laravel_test)

# composer create-project laravel/laravel --prefer-dist laravel_test
# cd laravel_test

 

Git 저장소를 초기화하고 현재 상태를 커밋 합니다.

# git init -b main
# git add .
# git commit -m "laravel project"

 

기본적으로 Heroku 는 프로젝트의 루트 디렉터리에서 응용 프로그램을 서비스하기 위해 PHP 와 함께 Apache 웹 서버를 시작합니다.
아래 내용으로 Procfile 파일을 생성합니다.
# echo "web: heroku-php-apache2 public/" > Procfile
# git add .
# git commit -m "Procfile for Heroku"

 

Push 할 수 있는 새로운 Heroku 애플리케이션을 만듭니다. (예 : php3)
# heroku create php3

 

Laravel 암호화 키를 설정합니다. Larvel 은 애플리케이션의 암호화 키를 사용하여 사용자 세션 및 기타 정보를 암호화합니다.
구성에서 선택한 암호의 규칙을 준수해야 하므로 유효한 키를 생성하는 가장 쉬운 방법은 php artisan key:generate --show 명령어를 사용하는 것입니다.
# php artisan --no-ansi key:generate --show

base64:GZ4rIBZ0MGKFvQro67ytUV4jYb7YheswHn/v0BCjQ5A=

 

출력 결과를 복사하여 아래와 같이 입력 후 실행합니다.
# heroku config:set APP_KEY=GZ4rIBZ0MGKFvQro67ytUV4jYb7YheswHn/v0BCjQ5A=

 

마지막으로, Heroku 애플리케이션에 Push 합니다.
# git push heroku main

 

heroku open 명령을 이용하여 페이지를 확인하거나, 출력된 URL 주소로 접근해보면 Laravel 프로젝트 초기화면이 출력됩니다.

https://php3-2f101eb6942b.herokuapp.com/

 

반응형

댓글()