#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);

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

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

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

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

몇가지 방법이 더 있겠지만 여기에서는 제가 해본 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/

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