Paketo Buildpack 빌드팩에서 사용가능한 개발 언어 버전을 확인하는 방법 입니다.
아래는 PHP 를 예로 들었습니다.

1) CF 버전 확인

PHP 빌드팩 버전을 확인합니다.

# 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.11.1
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

2) Distribution 버전 확인
아래 URL 에서 빌드팩 버전중 PHP Distribution 요소의 버전을 확인합니다.

(예: PHP Distribution 2.1.14)
https://github.com/paketo-buildpacks/php/releases

3) PHP 지원 버전 확인

아래 URL 에서 PHP Distribution 버전중 PHP 지원 버전을 확인할 수 있습니다.

또한 컨테이너 배포시 기본으로 설치되는 버전 (Default Dependency Versions) 을 확인할 수 있습니다.

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

참고로, 현재 날짜 기준의 PHP 빌드팩 및 PHP 제공 버전은 아래와 같습니다.

- Buildpack version : 2.11.1

- PHP Distribution : 2.1.14

- Support PHP version : 8.1.23, 8.1.24 (Default), 8.2.10, 8.2.11 (Ubuntu 22.04 - Jammy)

http://phptester.net/

쉘스크립트를 작성할때 가장 다른 점이 주석하는 방법입니다. 한 줄은 쉽게 '#' 를 통해 주석이 가능하지만, 블록을 주석하기 위해서는 아래와 같은 방법을 사용해야 합니다. :<<'END' 이 구간부터 주석이 시작되는 블록입니다. END 로 주석이 끝나는 블록을 명시해 주면 됩니다. 

[ 한줄 ]

# echo "please comment this line"

[ 여러줄 ]

:<<'END'
    if [ "$#" -ne 1 ]; then
        echo 'all'
    else
        VERSION=$1
        echo "$VERSION"
    fi
END

출처: https://ourcstory.tistory.com/117 [불로:티스토리]

MySQL 8.0.32 에서 테스트 하였습니다.

// sysdocu 계정에 전체 DB 의 모든 권한 부여
mysql> grant all privileges on *.* to sysdocu@localhost;

// sysdocu 계정에 전체 DB 의 모든 권한 제거
mysql> revoke all privileges on *.* from sysdocu@localhost;

// sysdocu 계정에 한개 DB 의 모든 권한 부여
mysql> grant all privileges on sysdocudb.* to sysdocu@localhost;

// sysdocu 계정에 한개 DB 의 모든 권한 제거
mysql> revoke select on sysdocudb.* from sysdocu@localhost;

* 추가 테스트
- 계정에 모든 DB 접근 권한을 주고, 하나의 DB 권한을 취소하는건 안됩니다. (쿼리 생략)

- 계정에 모든 DB 접근 권한을 주고, 하나의 액션만 취소하는건 됩니다. (액션 단위는 가능한듯함)

mysql> grant all privileges on *.* to sysdocu@localhost;

mysql> revoke select on *.* from sysdocu@localhost;

sysdocu 계정에 select 권한을 제거한 뒤, sysdocu 계정으로 재 로그인하여 select 쿼리를 실행하면 권한이 없다고 출력됩니다.

mysql> select * from mysql.user;
ERROR 1142 (42000): SELECT command denied to user 'sysdocu'@'localhost' for table 'user'

권한을 부여한 그대로의 룰 ({DB명}.{TABLE명}) 로만 권한 제거가 가능한듯 합니다.

Ubuntu 22.04 서버 한대로 Kind Cluster 를 구성하고 Korifi 를 설치해 애플리케이션 배포하는 방법입니다. Korifi 를 경험해보거나 테스트가 필요한 경우에 간단히 구성하여 사용이 가능합니다.

여기에서는 서버 한대로 스크립트를 이용한 설치 방법이 기술되어 있어 세세하게 설정을 하거나 확장을 하고자 할때는 이전 포스팅 (https://sysdocu.tistory.com/1904) 을 기준으로 시스템을 구축, 운영해보면 스스로 시스템을 유지보수 하는데 도움이 될 것으로 보입니다.

본 매뉴얼은 다음 포스팅을 참고하여 재작성 하였습니다.

https://tutorials.cloudfoundry.org/korifi/local-install/

https://dzone.com/articles/deploying-python-and-java-applications-to-kubernet

- 테스트 환경 : Ubuntu 22.04 서버 1대

1. 준비 작업

Korifi 를 설치하기 전에 아래 내용이 서버에 미리 준비되어 있어야 합니다.

- Cf8 cli

- Docker

- Go

- Helm

- Kbld

- Kind

- Kubectl

- Make

이 모든것을 자동 설치하도록 스크립트를 다운로드 받아 실행합니다.

# git clone https://github.com/sylvainkalache/korifi-prerequisites-installation
# cd korifi-prerequisites-installation && ./install-korifi-prerequisites.sh

* go 명령을 실행해보세요. go 명령어가 없거나, 에러 메세지 (permanently dropping privs did not work: File exists) 가 출력될 경우 아래와 같이 go 명령어를 별도로 설치해 줍니다.

공식 홈페이지 (https://go.dev/dl/) 에 접근하여 go1.21.3.linux-amd64.tar.gz 파일을 다운로드 받고, 설치를 진행합니다.

# cd

# wget https://go.dev/dl/go1.21.3.linux-amd64.tar.gz

# tar -C /usr/local -xzf go1.21.3.linux-amd64.tar.gz

# echo "export PATH=/usr/local/go/bin:$PATH" >> /etc/profile

# source /etc/profile

설치된 버전을 확인합니다.

# go version
go version go1.21.3 linux/amd64

2. Korifi 설치

이번에 실행할 스크립트는 아래 작업 과정을 담고 있습니다.

- Korifi 에 대한 올바른 포트 매핑을 사용하여 Kind Cluster 생성
- Twuni helm chart 를 사용하여 로컬 도커 레지스트리 배포
- Cloud Foundry 관리자 생성
- Cluster 내에서 내부 인증서를 생성하고 관리할 수 있도록 cert-manager 설치
- Cloud Native Buildpack 을 사용하여 소스 코드에서 실행 가능한 애플리케이션을 구축하는데 사용되는 Kpack 설치
- Korifi ingress 컨트롤러 Contour 설치
- Service Binding Spec 을 구현한 Service Binding Runtime 설치
- Metrics-server 설치
- Korifi 설치

# cd

# git clone https://github.com/cloudfoundry/korifi
# cd korifi/scripts

1) Registry 변경 (선택)

설치 스크립트에서는 자동으로 로컬에 Registry 를 생성하게 되는데, 별도의 Registry 를 사용하고자 할 경우 deploy-on-kind.sh 실행파일을 편집해서 Registry 관련 변수값을 변경하여 줍니다.

# vi deploy-on-kind.sh

- 8번째줄 : LOCAL_DOCKER_REGISTRY_ADDRESS="registry.az1.sysdocu.kr:5000"

- 89번째줄 : DOCKER_USERNAME="sysdocu"
- 90번째줄 : DOCKER_PASSWORD="12345678"

2) Buildpack 변경 (선택)

설치 스크립트에서는 기본 빌드팩이 'paketobuildpacks/build-jammy-base' 인데, 'paketobuildpacks/build-jammy-full' 로 변경시 PHP 와 Ruby 빌드팩 추가 사용이 가능해 집니다.

- base 지원 언어 : Java, Java Native Image, Go, Python, .NET, Node.js, Apache HTTPD, NGINX, Procfile

- full 지원 언어 : Java, Java Native Image, Go, Python, .NET, Node.js,  Apache HTTPD, NGINX, Procfile, PHP, Ruby

# vi deploy-on-kind.sh

- 179번째줄 : --set=kpackImageBuilder.clusterStackBuildImage="paketobuildpacks/build-jammy-full" \
- 180번째줄 : --set=kpackImageBuilder.clusterStackRunImage="paketobuildpacks/run-jammy-full" \

설치를 시작합니다.

# ./deploy-on-kind.sh korifi-cluster

* make 에러 발생시 --------------------

go 버전이 문제가 되어 설치가 중단되는 경우가 있습니다. 아래 절차대로 진행하면 해결 됩니다.

# cp -arp ../go.mod ../go.mod_1.20

# go mod tidy

# go mod vendor
# go clean -modcache
# go mod download

# cp -arp ../go.mod_1.20 ../go.mod

# ./deploy-on-kind.sh korifi-cluster

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

설치가 완료되었으면 Cloud Foundry API 인증 작업을 진행합니다.
# cf api https://localhost --skip-ssl-validation
# cf auth cf-admin

조직과 공간을 생성합니다.
# cf create-org org1
# cf create-space -o org1 space1
# cf target -o org1 -s space1

3. 애플리케이션 배포

Java 샘플 애플리케이션을 배포해 봅니다.

# cd

# git clone https://github.com/sylvainkalache/sample-web-apps

# cd sample-web-apps/java

언어 종속성을 설치해야 하므로 이 명령을 처음 실행할 경우에만 시간이 좀 걸립니다.
# cf push my-java-app

애플리케이션이 Kubernetes 에 배포되었습니다. 상태 확인은 다음 명령을 사용하면 됩니다.

# cf app my-java-app

애플리케이션에 직접 접근 해봅니다.

# curl --insecure https://my-java-app.apps-127-0-0-1.nip.io
Hello, World!
Java Version: 17.0.9

4. 빌드팩 추가 설치 및 애플리케이션 배포

이번에는 PHP 소스를 배포해보도록 하겠습니다.

paketobuildpacks/build-jammy-full 빌드팩 사용하는 경우에만 PHP 를 올바르게 배포할 수 있습니다.

기본 제공하는 개발 언어 빌드팩은 5개 입니다.

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

position   name                         stack                        enabled   locked   filename
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

PHP 빌드팩을 추가해보겠습니다.

clusterstore 의 빌드팩 리스트를 갱신합니다. (PHP 추가)
# kubectl edit clusterstore cf-default-buildpacks

clusterbuilder 의 빌드팩 리스트를 갱신합니다. (PHP 추가)
# kubectl edit clusterbuilder cf-kpack-cluster-builder

추가된 PHP 빌드팩이 확인되었습니다.

(빌드팩이 반영되기까지 시간이 소요될 수 있음)

# 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.11.1
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

위에서 다운로드 받아놓은 PHP 소스 디렉토리로 이동합니다.
# cd ~/sample-web-apps/php

애플리케이션을 배포합니다.
# cf push php1

아래와 같이 PHP 페이지를 확인하였습니다.
# curl --insecure https://php1.apps-127-0-0-1.nip.io
Hello, World!
PHP Version: 8.1.24

5. 배포 옵션

1) CLI 명령

CF CLI 명령 옵션으로 메모리, 디스크, 인스턴스 수 등을 옵션으로 지정할 수 있습니다.

# cf push phptest -m 512M -k 1G -i 2

- 애플리케이션 이름 : phptest

- 메모리 제한 : 512Mi

- 디스크 크기 : 1Gi

- 인스턴스 수 : 2개

참고로, 인스턴스 수가 2개 이상일때 kubectl logs 로 확인해보면 도메인 연결시 라운드로빈 방식으로 Pod 에 분배 되는것이 확인됩니다.

2) Manifest

cf push 명령줄에 옵션을 추가하지 않고 파일에 미리 정의한 값을 불러와 적용할 수도 있습니다.

아래 예시로 제공한 옵션은 부분 생략 가능하며, 생략시 기본값으로 자동 설정됩니다.

# vi manifest.yaml

push 할때 -f 옵션을 사용하여 파일을 지정하면 미리 설정한 값에 맞추어 환경이 생성됩니다.

# cf push -f manifest.yaml

3) 운영중 환경 변경

배포시 뿐만 아니라 운영중인 Pod 에도 cf scale 명령을 통해 환경 변경 작업을 할 수 있습니다.

형식) cf scale APP_NAME [--process PROCESS] [-i INSTANCES] [-k DISK] [-m MEMORY] [-l LOG_RATE_LIMIT] [-f]

# cf scale phptest -i 2

이렇게 하면 phptest 라는 애플리케이션 인스턴스 (Pod) 의 수가 2개로 증가됩니다.

- CPU

Cloud Foundry 는 CPU 제한을 명시적으로 설정하는 옵션을 제공하지 않으며, 메모리 제한을 설정하는 -m 옵션만을 지원합니다. CPU 사용은 애플리케이션의 요구 사항에 따라 동적으로 조절됩니다. Cloud Foundry 의 핵심 아이디어는 개발자가 인프라 리소스 관리에 대해 걱정하지 않고 애플리케이션 코드에 집중할 수 있도록 하는 것입니다.

- 포트

Cloud Foundry 는 애플리케이션이 사용할 수 있는 포트 번호를 동적으로 할당하므로 포트 번호를 직접 변경하거나 설정하는 것은 일반적으로 지원되지 않습니다. 애플리케이션의 포트 번호를 변경하려면 환경 변수 또는 애플리케이션 코드 내에서 직접 변경해야 합니다.

다음과 같이 삭제되지 않는 네임스페이스를 강제로 삭제하는 방법입니다.

# kubectl get ns |grep Terminating
cf-org-d550a9c8-9bf1-49db-9887-310bc39261b1   Terminating   29m

방법1

kubectl 명령 옵션으로 삭제합니다.

# kubectl delete namespace cf-org-0ff8cc13-3a8e-47e2-839b-e68f5510583c --grace-period=0 --force

방법2

TARGET 변수에 삭제하고자하는 네임스페이스 이름을 넣고 실행합니다.

jq 명령어가 필요하므로 사전에 jq 패키지를 설치해주세요.

# apt -y install jq

# TARGET="cf-org-0ff8cc13-3a8e-47e2-839b-e68f5510583c"

# kubectl proxy & kubectl get namespace $TARGET -o json |jq '.spec = {"finalizers":[]}' > temp.json

[2] 375218
error: listen tcp 127.0.0.1:8001: bind: address already in use
[2]+  Exit 1                  kubectl proxy

위와 같이 에러가 출력되어도 괜찮습니다. 계속 진행합니다.

# kubectl replace --raw "/api/v1/namespaces/$TARGET/finalize" -f temp.json

[출처] https://mightytedkim.tistory.com/44

Kubernetes 및 MetalLB 가 구축되어 있다는 전제 하에 Korifi 설치하는 방법을 설명합니다.

준비되지 않으신 분은 아래 포스팅을 참고하세요.

- Kubernetes 설치 : https://sysdocu.tistory.com/1851

- MetalLB 설치 : https://sysdocu.tistory.com/1854

본 매뉴얼은 아래 URL 을 참고하여 재작성 하였습니다.

- CF 8 CLI 가이드 : https://cli.cloudfoundry.org/en-US/v8/

- Korifi 공식 문서 : https://github.com/cloudfoundry/korifi/

- 참고 : https://deep75.medium.com/korifi-api-cloud-foundry-v3-exp%C3%A9rimentale-dans-kubernetes-b759ddd38443

[환경]

Kubernetes 버전 : Kubernetes 1.28 (master 1대, worker3대)

OS : Ubuntu 22.04

[Korifi - 소개글 일부]

Korifi 는 빌드, 테스트, 배포 및 모니터링 단계를 지원하는 DevOps 툴체인에 통합되어 애플리케이션 개발자의 배포 환경을 단순화합니다. 또한 팀이 기존 CI/CD, 로깅 및 관찰 가능 도구를 확장할 수 있도록 하는 동시에 Provile, Kpack 과 같은 Kubernetes 네이티브 도구가 포함되어 있습니다. 소프트웨어 엔지니어링 팀은 Korifi 를 통해 포괄적인 Kubernetes 전략을 수립하고 개발, 테스트 및 배포 단계 전반에 걸쳐 모범 사례를 채택할 수 있습니다.

Korifi 는 단일 cf push 명령으로 모든 언어나 프레임워크로 작성된 앱을 배포할 수 있는 기존의 Cloud Foundry 경험을 그대로 유지하고 있습니다. Pak to build pack 을 사용하여 OCI 호환 컨테이너로 앱을 배포함으로써 앱 개발자 경험을 더욱 향상시킵니다. 앱 개발자들은 더 이상 Kubernetes 에 컨테이너화된 배포를 위해 복잡한 YAML 이나 Dockerfile 과 씨름할 필요가 없습니다.

1. Docker 설치

패키지 목록을 최신화하고 업데이트를 진행합니다.
# apt -y update

# apt -y upgrade
# apt -y install apt-transport-https ca-certificates curl gnupg lsb-release

Docker 공식 GPG 를 설치합니다.
# curl -fsSL https://download.docker.com/linux/ubuntu/gpg |gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg

Docker 공식 저장소를 추가합니다.
# echo \
  "deb [arch=amd64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu \
  $(lsb_release -cs) stable" |tee /etc/apt/sources.list.d/docker.list > /dev/null

Docker 를 설치하고 확인합니다.

# apt -y update
# apt -y install docker-ce docker-ce-cli containerd.io
# docker --version

Docker version 24.0.7, build afdd53b

2. Kind 설치

Kind 는 도커 컨테이너 nodes 를 사용하여 로컬 Kubernetes Cluster 를 실행하기 위한 도구입니다.

# wget https://github.com/kubernetes-sigs/kind/releases/download/v0.20.0/kind-linux-amd64

# chmod +x kind-linux-amd64

# mv kind-linux-amd64 /usr/local/bin/kind

# kind version
kind v0.20.0 go1.20.4 linux/amd64

클러스터를 생성합니다.

# cat <<EOF | kind create cluster --config=-
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
  extraPortMappings:
  - containerPort: 80
    hostPort: 80
    protocol: TCP
  - containerPort: 443
    hostPort: 443
    protocol: TCP
EOF

Creating cluster "kind" ...
 ✓ Ensuring node image (kindest/node:v1.27.3) 🖼
 ✓ Preparing nodes 📦  
 ✓ Writing configuration 📜 
 ✓ Starting control-plane 🕹️ 
 ✓ Installing CNI 🔌 
 ✓ Installing StorageClass 💾 
Set kubectl context to "kind-kind"
You can now use your cluster with:

kubectl cluster-info --context kind-kind

Thanks for using kind! 😊

* 참고 : 클러스터 생성 오류

클러스터 재설치 등의 작업으로 아래와 같은 에러가 출력된 경우 기존의 클러스터를 삭제해야 다시 생성이 가능합니다.

ERROR: failed to create cluster: node(s) already exist for a cluster with the name "kind"
클러스터 재설치 전에 'kind delete cluster --name kind' 명령으로 삭제를 먼저 한 뒤에 클러스터 생성 명령을 실행해 주세요.

클러스터가 잘 설치 되었는지 확인합니다.

# kubectl cluster-info --context kind-kind
Kubernetes control plane is running at https://127.0.0.1:40321
CoreDNS is running at https://127.0.0.1:40321/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

3. 환경 변수 설정

설치가 편리하도록 자주 사용하는 이름은 변수에 입력합니다.

# ROOT_NAMESPACE="cf"                             // CF 네임스페이스
# KORIFI_NAMESPACE="korifi-system"          // Korifi 네임스페이스
# ADMIN_USERNAME="kubernetes-admin"    // Admin 계정 아이디
# BASE_DOMAIN="az1.sysdocu.kr"                 // 기본 도메인

4. CF 설치

Cloud Foundry 는 개발자가 애플리케이션 코드를 작성하고 구축한 후 애플리케이션을 클라우드 환경에 배포하고 실행하는 데 도움이 되는 플랫폼입니다.

Ubuntu 계열이 아닐 경우 아래 공식 문서를 참고 하시기 바랍니다.

https://docs.cloudfoundry.org/cf-cli/install-go-cli.html

Korifi 에서는 CF 8.5 이상의 버전이 필요합니다. Ubuntu 계열에서 CF 설치 방법은 아래와 같습니다.

# wget -q -O - https://packages.cloudfoundry.org/debian/cli.cloudfoundry.org.key | sudo apt-key add -

# echo "deb https://packages.cloudfoundry.org/debian stable main" | sudo tee /etc/apt/sources.list.d/cloudfoundry-cli.list

# apt -y update

# apt -y install cf8-cli

설치된 CF 8 버전을 확인합니다.

# cf version
cf version 8.7.4+db5d612.2023-10-20

5. Helm 설치

Helm 은 Kubernetes Cluster 에서 Kubernetes 애플리케이션을 관리하기 위한 패키지 관리 도구입니다.

Helm 공식 웹사이트에서 운영 체제에 맞는 Helm 바이너리 파일을 다운로드하여 설치를 쉽게 진행할 수 있습니다.

다음 링크를 사용하면 최신 버전의 helm을 다운로드할 수 있습니다.

URL : https://github.com/helm/helm/releases

페이지 중간부에 Download 섹션이 있고, 64bit 리눅스 OS 를 사용하기 때문에 'Linux arm64' 항목의 주소를 복사하여 리눅스 쉘에서 다운로드 하였습니다.

# wget https://get.helm.sh/helm-v3.12.0-linux-amd64.tar.gz

# tar xvzf helm-v3.12.0-linux-amd64.tar.gz

실행파일을 PATH 경로에 포함된 디렉토리로 이동시킵니다.

# mv linux-amd64/helm /usr/local/bin/

버전을 확인합니다.

# helm version

version.BuildInfo{Version:"v3.12.0", GitCommit:"c9f554d75773799f72ceef38c51210f1842a1dea", GitTreeState:"clean", GoVersion:"go1.20.3"}

6. cert-manager 설치

cert-manager는 Kubernetes 클러스터에서 SSL/TLS 인증서를 관리하기 위한 오픈 소스 도구입니다. 이 도구는 Let's Encrypt 와 같은 인증 기관에서 인증서를 자동으로 발급하고 갱신하는 작업을 단순화합니다.

# kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.13.2/cert-manager.yaml

설치를 확인합니다.

# kubectl get pods -n cert-manager
NAME                                       READY   STATUS    RESTARTS   AGE
cert-manager-cainjector-65c7bff89d-kjwpr   1/1     Running   0          24s
cert-manager-cbcf9668d-7gd8w               1/1     Running   0          24s
cert-manager-webhook-594cb9799b-b48w2      1/1     Running   0          24s

7. Kpack 설치

Kpack 은 Cloud Foundry 컨테이너 빌드 도구로, Kubernetes 에서 컨테이너 이미지를 빌드하고 관리하는 오픈 소스 프로젝트입니다. Kpack 은 애플리케이션을 컨테이너 이미지로 변환하는 작업을 자동화하고 단순화하는 데 사용됩니다.
# kubectl apply -f https://github.com/buildpacks-community/kpack/releases/download/v0.12.2/release-0.12.2.yaml

설치를 확인합니다.

# kubectl get pods -n kpack
NAME                                READY   STATUS    RESTARTS   AGE
kpack-controller-7d544645c8-4h92h   1/1     Running   0          19s
kpack-webhook-77c465c879-lmkx6      1/1     Running   0          19s

8. Contour 설치

Contour 는 Ingress 컨트롤러입니다. Ingress 컨트롤러는 클러스터 외부에서 클러스터 내의 서비스로의 HTTP 및 HTTPS 트래픽을 관리하고 라우팅하는 역할을 합니다.

설치를 진행합니다.

# kubectl apply -f https://projectcontour.io/quickstart/contour.yaml

설치를 확인합니다.

# kubectl get pods -n projectcontour
NAME                            READY   STATUS      RESTARTS   AGE
contour-6775896b98-scqgb        1/1     Running     0          46s
contour-6775896b98-tt7v9        1/1     Running     0          46s
contour-certgen-v1-26-1-6jtws   0/1     Completed   0          46s
envoy-2zql9                     1/2     Running     0          46s
envoy-dqjbj                     1/2     Running     0          46s
envoy-xbrqw                     1/2     Running     0          46s

9. Metrics-server 설치

메트릭 서버는 Kubernetes 클러스터 내에서 리소스 사용 및 성능 메트릭을 수집, 저장 및 쿼리하는 데 사용되는 중요한 구성 요소입니다.

여기에서는 간단히 설치하고 넘어가므로, 자세한 내용응 아래 URL 을 참고하시기 바랍니다.

https://github.com/kubernetes-sigs/metrics-server

설치할 메트릭 서버 버전은 Kubernetes 의 버전에 따라 달라집니다.

Kubernetes 가 1.19 이상의 버전이라면 아래와 같이 실행하여 Metrics 를 설치하면 되고, 그 이하일 경우 또는 고가용성 (HA) 을 위한 이중화 구성은 위에 안내된 URL 에서 해당 버전을 확인하여 설치합니다.

# kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

설치를 확인합니다.

# kubectl get pods -A |grep metrics-server
kube-system        metrics-server-fbb469ccc-fwmsn             0/1     Running     0             73s

이상태로 사용해도 문제가 없으나 kubectl top nodes 등 Metrics 를 이용한 자원 사용량 등을 확인하고 싶은 경우 Running 중인 Pod 가 1개 이상 있어야 합니다. 아래 추가 포스팅을 참고하여 진행하시면 됩니다.

https://sysdocu.tistory.com/1890

10. Namespace 생성

root 및 korifi 네임스페이스를 생성합니다.

# cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Namespace
metadata:
  name: $ROOT_NAMESPACE
  labels:
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/enforce: restricted
EOF

# cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Namespace
metadata:
  name: $KORIFI_NAMESPACE
  labels:
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/enforce: restricted
EOF

11. Secret 생성

Korifi 와 Kpack 이 컨테이너 레지스트리에 연결할 수 있도록 secret 을 생성합니다.

Registry 서비스를 이용하지 않거나 새로 구축해야 하는 경우 별도 포스팅 (https://sysdocu.tistory.com/1855) 을 참고하고,

도커 허브를 사용하는 경우 --docker-server 는 생략하고 --docker-username 에 사용자 이름, --docker-password 에 암호 또는 개인 액세스 토큰을 입력합니다.

# kubectl --namespace "$ROOT_NAMESPACE" create secret docker-registry image-registry-credentials \
    --docker-username="sysdocu" \
    --docker-password="12345678" \
    --docker-server="https://registry.az1.sysdocu.kr:5000"

12. 네임서버 도메인 설정

Korifi API 및 Korifi 에서 실행할 앱에 대한 DNS 등록을 해야 합니다.

아래 내용을 참고하여 네임서버에 master node IP 로 설정해주세요.

- Korifi API 서버 : api.az1.sysdocu.kr / 115.68.142.120

- Apps : *.apps.az1.sysdocu.kr / 115.68.142.120

- 추후 서비스로 제공할 경우 {app_name}.apps.az1.sysdocu.kr 과 같은 개별 도메인은 배포되는 worker node IP 로 연결되도록 하는것도 방법입니다. (하지만 Cluster 구성이기 때문에 master node 에서도 응답은 합니다)

13. Korifi 설치

Korifi 는 빌드, 테스트, 배포 및 모니터링 단계를 지원하는 DevOps 툴체인입니다.

설치는 Helm 명령어로 합니다.

# helm install korifi https://github.com/cloudfoundry/korifi/releases/download/v0.5.0/korifi-0.5.0.tgz \
    --namespace="$KORIFI_NAMESPACE" \
    --set=global.generateIngressCertificates=true \
    --set=global.rootNamespace="$ROOT_NAMESPACE" \
    --set=adminUserName="$ADMIN_USERNAME" \
    --set=api.apiServer.url="api.$BASE_DOMAIN" \
    --set=global.defaultAppDomainName="apps.$BASE_DOMAIN" \
    --set=global.containerRepositoryPrefix=registry.az1.sysdocu.kr:5000 \
    --set=kpack-image-builder.builderRepository=registry.az1.sysdocu.kr:5000/kpack-builder

--set=global.containerRepositoryPrefix 옵션에는 업로드 할 수 있는 Repository 주소를 적어야 합니다.

--set=kpack-image-builder.builderRepository 옵션에도 동일한 Repository 주소를 적어주고 뒤에 kpack-builder 디렉토리 하나 더 추가해주세요.

여기에서 약간의 시간이 소요됩니다.

설치를 확인합니다.

# kubectl get pods -n korifi-system
NAME                                                           READY   STATUS    RESTARTS   AGE
korifi-api-deployment-5c747f489d-rc4dd                         1/1     Running   0          49s
korifi-controllers-controller-manager-6b7cdd98c-4h59q          1/1     Running   0          49s
korifi-job-task-runner-controller-manager-f799b99fc-d26vb      1/1     Running   0          49s
korifi-kpack-build-controller-manager-7cdc7fcc9-4r9rv          1/1     Running   0          49s
korifi-statefulset-runner-controller-manager-c49c9997d-ccfvk   1/1     Running   0          49s

참고로 helm 으로 설치된 Korifi 삭제는 helm uninstall korifi -n $KORIFI_NAMESPACE 입니다.

14. 조직 및 공간 생성

조직과 공간 생성 후 그 안에서 애플리케이션이 배포 됩니다.

아래와 같이 Cloud Foundry API 를 통해 조직과 공간을 생성하고 타겟 (작업공간으로 적용) 설정을 합니다.

Cloud Foundry API 인증 작업을 진행합니다.

# cf api https://api.$BASE_DOMAIN --skip-ssl-validation
# cf login
API endpoint: https://api.az1.sysdocu.kr

1. kind-kind
2. kubernetes-admin

Choose your Kubernetes authentication info (enter to skip): 1

Authenticating...
OK

Warning: The client certificate you provided for user authentication expires at 2024-12-07T02:35:20Z
which exceeds the recommended validity duration of 168h0m0s. Ask your platform provider to issue you a short-lived certificate credential or to configure your authentication to generate short-lived credentials automatically.
API endpoint:   https://api.az1.sysdocu.kr
API version:    3.117.0+cf-k8s
user:           kubernetes-admin
No org or space targeted, use 'cf target -o ORG -s SPACE'

위 명령은 'cf auth kind-kind' 로 대체할 수 있습니다.

조직과 공간을 생성하고 타겟 설정을 합니다.

# cf create-org org1
# cf create-space -o org1 space1
# cf target -o org1 -s space1

15. 빌드팩 추가

처음 cf 를 설치하고나서 기본적으로 제공되는 빌드팩은 아래와 같습니다.

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

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

여기에 PHP Buildpack 을 추가해 보겠습니다. 아래 위치에 내용 추가 후 저장합니다.
# kubectl edit clusterstore cf-default-buildpacks

clusterbuilder 의 빌드팩 리스트를 갱신합니다.

여기에서도 PHP Buildpack 을 추가합니다. 추가 위치에 따라 빌드팩 순번이 결정됩니다.
# kubectl edit clusterbuilder cf-kpack-cluster-builder

추가된 빌드팩을 확인합니다.

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

position   name                         stack                        enabled   locked   filename
1          paketo-buildpacks/php        io.buildpacks.stacks.jammy   true      false    paketo-buildpacks/php@2.11.1
2          paketo-buildpacks/java       io.buildpacks.stacks.jammy   true      false    paketo-buildpacks/java@10.3.0
3          paketo-buildpacks/go         io.buildpacks.stacks.jammy   true      false    paketo-buildpacks/go@4.6.0
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

16. 애플리케이션 배포

위에서 추가한 PHP Buildpack 을 이용해 애플리케이션을 배포해 보도록 하겠습니다.

간단한 소스를 만듭니다.

# mkdir php-source

# cd php-source
# vi index.php

PHP 소스를 배포 합니다.

# cf push php1

...

* 참고 (소스 디렉토리 지정)

소스를 배포할때는 해당 소스 디렉토리에서 cf push 명령을 실행해야 하지만, 디렉토리가 다를 경우 -p 옵션 (-p {소스 경로}) 을 추가하면 됩니다.

배포된 애플리케이션 정보는 아래 명령으로 확인됩니다.

# cf app php1

정상 동작하는지 curl 명령으로 접근해 봅니다.

# curl --insecure https://php1.apps.az1.sysdocu.kr
Hello, World!
PHP Version: 8.1.24

* Laravel 프로젝트 배포

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

https://sysdocu.tistory.com/1874

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

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

# composer create-project laravel/laravel --prefer-dist laravel-app

생성된 Laravel 프로젝트 디렉토리로 이동 후, 배포를 위해 꼭 필요한 설정파일 2개를 생성합니다. (project.toml, extentions.ini)

# cd laravel-app

# vi project.toml

* 설명

- 웹서버를 httpd 로 사용하고 싶은 경우 nginx 대신 httpd 를 입력합니다.

- nginx 의 추가 설정이 필요한 경우 (예: DirectoryIndex) .nginx.conf.d/location-server.conf 파일을 생성하고 아래와 같이 필요한 설정을 넣으면 됩니다.

location / {

  try_files $uri $uri/index.html;

}

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

* 참고

다른 PaaS 서비스를 제공하는 사이트에서는 소스코드가 어떤 모듈을 사용하는지 모르기 때문에, 모든 모듈을 추가하여 제공합니다. CF 환경에서 테스트 결과 아래 모듈이 사용 가능했습니다.

Laravel 프로젝트를 배포합니다.

# cf push laravel-app

간단히 curl 명령으로 확인이 가능하며,

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

위에서 네임서버 설정을 미리 해두었으므로 웹브라우저에서도 출력된 도메인으로 접속하여 Laravel 초기 페이지 확인이 가능합니다.

> https://laravel-app.apps.az1.sysdocu.kr

* 참고

새로운 세션에서 API 연결은 되었지만, CloudFoundry 로그인 시도 할때 아래와 같이 인증 실패 메세지가 출력되었다면

# cf api https://api.az1.sysdocu.kr--skip-ssl-validation
Setting API endpoint to https://api.az1.sysdocu.kr...
OK

API endpoint:   https://api.az1.sysdocu.kr
API version:    3.117.0+cf-k8s

Not logged in. Use 'cf login' or 'cf login --sso' to log in.

root@master:~# cf login
API endpoint: https://api.az1.sysdocu.kr

API endpoint:   https://api.az1.sysdocu.kr 
API version:    3.117.0+cf-k8s
Not logged in. Use 'cf login' or 'cf login --sso' to log in.
Unable to authenticate.
FAILED

Kubernetes 환경 변수를 불러오지 않았을 경우가 있으므로 아래 명령을 통해 KUBECONFIG 환경 변수를 설정합니다.

# export KUBECONFIG=/etc/kubernetes/admin.conf

Flavor 를 변경하는 방법과 disk 파일의 크기를 직접 늘려주는 방법이 있는데, 여기에서는 disk 파일 크기를 바로 변경하는 더 쉬운 방법을 안내 드리겠습니다.

변경하고자 하는 master 라는 이름의 VM 이 어느 컴퓨트 노드에 있는지 확인합니다.

(Controller 서버에서)

# openstack server show master |grep hostname
| OS-EXT-SRV-ATTR:hypervisor_hostname | compute1                                                 |

(해당 컴퓨트 노드에서)

사용중인 VM 의 PID 값 확인 후 종료합니다.

# ps -ef|grep disk
root        1110       1  0 02:37 ?        00:00:00 /usr/libexec/udisks2/udisksd
libvirt+    2788       1 99 02:38 ?        00:00:08 /usr/bin/qemu-system-x86_64 -name guest=instance-00000006,debug-threads=on -S -object {"qom-type":"secret","id":"masterKey0","format":"raw","file":"/var/lib/libvirt/qemu/domain-1-instance-00000006/master-key.aes"} -machine pc-i440fx-6.2,usb=off,dump-guest-core=off,memory-backend=pc.ram -accel kvm -cpu Skylake-Client-IBRS,ss=on,vmx=on,pdcm=on,hypervisor=on,tsc-adjust=on,clflushopt=on,umip=on,md-clear=on,stibp=on,arch-capabilities=on,ssbd=on,xsaves=on,pdpe1gb=on,ibpb=on,ibrs=on,amd-stibp=on,amd-ssbd=on,rsba=on,skip-l1dfl-vmentry=on,pschange-mc-no=on,hle=off,rtm=off -m 8192 -object {"qom-type":"memory-backend-ram","id":"pc.ram","size":8589934592} -overcommit mem-lock=off -smp 4,sockets=4,dies=1,cores=1,threads=1 -uuid f6aa6879-0ea4-4be8-a610-d1abcd60c9ab -smbios type=1,manufacturer=OpenStack Foundation,product=OpenStack Nova,version=25.2.0,serial=f6aa6879-0ea4-4be8-a610-d1abcd60c9ab,uuid=f6aa6879-0ea4-4be8-a610-d1abcd60c9ab,family=Virtual Machine -no-user-config -nodefaults -chardev socket,id=charmonitor,fd=31,server=on,wait=off -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -blockdev {"driver":"file","filename":"/var/lib/nova/instances/_base/bf15376deac35c8c707e130fb5d70882999b77d2","node-name":"libvirt-2-storage","cache":{"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"} -blockdev {"node-name":"libvirt-2-format","read-only":true,"cache":{"direct":true,"no-flush":false},"driver":"raw","file":"libvirt-2-storage"} -blockdev {"driver":"file","filename":"/var/lib/nova/instances/f6aa6879-0ea4-4be8-a610-d1abcd60c9ab/disk","node-name":"libvirt-1-storage","cache":{"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"} -blockdev {"node-name":"libvirt-1-format","read-only":false,"cache":{"direct":true,"no-flush":false},"driver":"qcow2","file":"libvirt-1-storage","backing":"libvirt-2-format"} -device virtio-blk-pci,bus=pci.0,addr=0x4,drive=libvirt-1-format,id=virtio-disk0,bootindex=1,write-cache=on -netdev tap,fd=34,id=hostnet0,vhost=on,vhostfd=36 -device virtio-net-pci,host_mtu=1450,netdev=hostnet0,id=net0,mac=fa:16:3e:cb:7e:47,bus=pci.0,addr=0x3 -add-fd set=3,fd=33 -chardev pty,id=charserial0,logfile=/dev/fdset/3,logappend=on -device isa-serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0,bus=usb.0,port=1 -device usb-kbd,id=input1,bus=usb.0,port=2 -audiodev {"id":"audio1","driver":"none"} -vnc 127.0.0.1:0,audiodev=audio1 -device virtio-vga,id=video0,max_outputs=1,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 -object {"qom-type":"rng-random","id":"objrng0","filename":"/dev/urandom"} -device virtio-rng-pci,rng=objrng0,id=rng0,bus=pci.0,addr=0x6 -device vmcoreinfo -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny -msg timestamp=on
root        2836    2649  0 02:38 pts/1    00:00:00 grep --color=auto disk

# kill -9 2788

인스턴스 디렉토리로 들어가 disk 파일의 사이즈를 20G 더 늘려줍니다.

# cd /var/lib/nova/instances/f6aa6879-0ea4-4be8-a610-d1abcd60c9ab

# qemu-img resize disk +20G

Image resized.

(Controller 서버에서)

중지되었던 VM 을 다시 가동합니다.

# openstack server start master

(VM 에서)

용량 확인 명령으로 초기 20GB 에서 20GB 더 늘린 40GB 사용이 확인되었습니다.

root@master:~# df -h
Filesystem      Size  Used Avail Use% Mounted on
tmpfs           794M  1.7M  793M   1% /run
/dev/vda1        39G   19G   21G  48% /
tmpfs           3.9G     0  3.9G   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
/dev/vda15      105M  6.1M   99M   6% /boot/efi
tmpfs           794M  4.0K  794M   1% /run/user/1000

기존 history 는 남기고 현재 세션의 명령 history 만 삭제하는 방법은 아래와 같습니다.

- 목적 : 특별한 작업 로그를 남기지 않을 경우 사용

- 명령어 : # unset HISTFILE