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)

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

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

본 문서는 공식 Documents 를 참고하여 실습한 후 작성된 내용으로 구성되어 있습니다.

https://github.com/PaaS-TA/paas-ta-container-platform/blob/master/use-guide/portal/container-platform-portal-guide.md

컨테이너 플랫폼 포털 URL 은 master 서버 (IP 또는 호스트명) 와 포트 32703 을 이용해 접근이 가능합니다.

http://115.68.142.67:32703

1. 일반 사용자 추가

컨테이너 플랫폼 포털 (이하 '포털') 로그인 화면에서 하단의 'Register' 버튼을 눌러 회원가입을 합니다.

회원가입시 Username 은 로그인 아이디에 해당 되는 부분이므로 영문 작성을 하면 되고, [Register] 버튼을 눌러 가입하면 '관리자의 승인이 필요' 하다는 메세지가 출력됩니다.

관리자는 승인을 기다리는 계정에 Namespace (프로젝트) 를 생성 후 Role (권한) 부여를 해주어야 합니다.

테스트 목적으로 아래와 같이 설정하였습니다.

1) Namespace 및 Role 생성

위치 : Clusters > Namespaces 화면에서 [생성] 버튼 클릭

> Name : mynamespace 입력 (소문자로만 입력해야 합니다)

> Resource Quotas : cp-low-resourcequota 선택

> Limit Ranges : cp-low-limitrange 선택

> [저장] 버튼을 눌러 생성합니다.

2) Namespace 및 Role 할당

위치 : 포털 로그인 > Managements > Users > 'User' 탭 > '비활성' 탭 클릭

> 사용자 계정을 클릭 후, 하단 [수정] 버튼을 누릅니다.

> Authority : [User] 로 선택합니다.

> Namespaces ⁄ Roles 옆에 [선택] 클릭합니다.

> 위에서 생성했던 mynamespace (cp-admin-role) 체크 > [선택 완료] > [수정]

이제 계정이 활성 처리 되었습니다.

admin 을 로그아웃하고 일반 사용자 계정으로 로그인합니다.

2. 응용프로그램 배포

admin 계정으로는 모든 메뉴의 권한이 열려 있기 때문에 K-PaaS 에서 제공하는 기능을 모두 사용할 수 있습니다.

여기에서는 위에서 생성했던 일반 사용자 계정으로 응용프로그램을 배포하는 과정을 설명하겠습니다.

1) Deployment 생성

컨테이너를 다운로드 받고 응용프로그램을 배포할 수 있습니다.

위치 : 포털 로그인 > Workloads > Deployments

> [생성] 버튼을 누릅니다.

> YAML 입력창에 아래 내용을 작성하고 [저장] 버튼을 누릅니다.

저장과 동시에 자동으로 yaml 설정값이 적용되며, Deployments 는 물론이고 Pods 와 ReplicaSets 메뉴에서도 관련 정보가 확인됩니다.

2) Services 생성

서비스를 NodePort 형식으로 생성하면 외부에서 응용 프로그램으로 연결이 가능해집니다.

위치 : 포털 로그인 > Services > Services

> [생성] 버튼을 누릅니다.

> YAML 입력창에 아래 내용을 작성하고 [저장] 버튼을 누릅니다.

* Port 설명

- nodePort: 외부 네트워크에서 접속하는 포트 번호 입니다. (30000~32767 사이의 포트 번호를 사용) 이 포트는 Service Port 로 연결됩니다.

- port: Service 의 포트 번호 입니다. 이 포트는 targetPort 로 연결됩니다.

- targetPort: Pod 의 포트 입니다.

- 기본 80 포트 연결을 원할 경우 type 을 LoadBalancer 로 변경해야 합니다.

3) Ingresses 생성

개인이 소유하고 있는 도메인을 사용하는 방법입니다.

위치 : 포털 로그인 > Services > Ingresses

> [생성] 버튼을 누릅니다.

> Name : myingress 입력 (소문자로만 입력해야 합니다)

> Host : test.sysdocu.kr 입력 (네임서버 설정 IP 는 master node, worker node 어느것이든 상관 없습니다)

> Path : Prefix 선택, / 입력

> Target : 위에서 생성했던 Service 명, Port : 80 입력

> [저장] 버튼을 누릅니다.

4) 응용프로그램 접속

웹브라우저를 통해 준비된 도메인과 포트번호로 접근하면 웹서버 기본페이지가 출력됩니다.

http://test.sysdocu.kr:30001

5) 볼륨 추가

외부 스토리지의 일정 용량을 할당 받아 Pod 에 연결하는 방법입니다.

위치 : 포털 로그인 > Persistent Volume Claims

> [생성] 버튼을 누릅니다.

> YAML 입력창에 아래 내용을 작성하고 [저장] 버튼을 누릅니다.

볼륨을 위에서 생성했던 Pod 에 붙여 보겠습니다.

위치 : 포털 로그인 > Workloads > Deployments

> Deployments 이름 선택

> 아래 [수정] 버튼을 누릅니다.

> YAML 입력창에 아래 파란색으로 표시한 내용을 추가하고 [저장] 버튼을 누릅니다.

Deployment 를 수정하면 Pod 가 재생성 됩니다.

Pod 이름을 확인하고, Pod bash 쉘에 진입하여 파티션을 확인합니다.

$ kubectl get pod -n mynamespace
NAME                               READY   STATUS    RESTARTS   AGE
nginx-deployment-b5cd59b6c-zj7pg   1/1     Running   0          1m33s

$ kubectl exec -it nginx-deployment-b5cd59b6c-zj7pg -n mynamespace -- /bin/bash

# df -h
Filesystem                                                                        Size  Used Avail Use% Mounted on
overlay                                                                            20G   11G  8.9G  54% /
tmpfs                                                                              64M     0   64M   0% /dev
tmpfs                                                                             3.9G     0  3.9G   0% /sys/fs/cgroup
shm                                                                                64M     0   64M   0% /dev/shm
tmpfs                                                                             795M  5.0M  790M   1% /etc/hostname
172.16.1.32:/data/mynamespace-nginx-pvc-pvc-4bde4a92-4288-415f-bba7-ca99bf4fb7fe   20G  2.7G   18G  14% /backup
/dev/vda1                                                                          20G   11G  8.9G  54% /etc/hosts
tmpfs                                                                             500M   12K  500M   1% /run/secrets/kubernetes.io/serviceaccount
tmpfs                                                                             3.9G     0  3.9G   0% /proc/acpi
tmpfs                                                                             3.9G     0  3.9G   0% /proc/scsi
tmpfs                                                                             3.9G     0  3.9G   0% /sys/firmware

* 참고

PVC 를 1G 로 설정했는데, 20G 로 보이는 이유는 NFS 를 PV (Persistent Volume) 로 사용하기 때문입니다.

NFS 에서는 계정별 Quota 설정이 없으므로 공유디렉토리 총 사용량이 출력됩니다.

할당받은 용량으로 보이길 원할 경우 Ceph, ISCSI, GlusterFS 등 용량 개별 할당이 가능한 PV 로 사용하는 방법이 있습니다.

6) ConfigMaps

ConfigMap 은 어플리케이션의 환경 설정 정보나 구성 값들을 분리하여 저장하는 리소스입니다. 이를 통해 설정 값들을 어플리케이션 코드와 분리하여 관리하고, 환경별로 다른 설정을 제공하거나 변경 사항을 쉽게 적용할 수 있습니다.

다음은 ConfigMap 의 database-url 설정 값을 DATABASE_URL 환경 변수로 설정하여 Pod 에서 사용하는 예시 입니다. 이렇게 설정한 값이 Pod 내의 환경 변수로 주입되어 어플리케이션에서 사용할 수 있습니다.

위치 : 포털 로그인 > ConfigMaps > ConfigMaps

> [생성] 버튼을 누릅니다.

> YAML 입력창에 아래 내용을 작성하고 [저장] 버튼을 누릅니다.

그리고 Pod 에서 ConfigMap 을 사용할 수 있도록 Deployment 설정을 수정해줍니다.

위치 : 포털 로그인 > Workloads > Deployments

> Deployments 이름 선택

> 아래 [수정] 버튼을 누릅니다.

> YAML 입력창에 아래 파란색으로 표시한 내용을 추가하고 [저장] 버튼을 누릅니다.

Pod 에서 변수를 확인해보겠습니다.

Pod 이름을 확인하고, Pod bash 쉘에 진입하여 변수를 잘 받아왔는지 확인합니다.

$ kubectl get pod -n mynamespace
NAME                               READY   STATUS    RESTARTS   AGE
nginx-deployment-799d57d87-zwjsz   1/1     Running   0          25s

$ kubectl exec -it nginx-deployment-799d57d87-zwjsz -n mynamespace -- /bin/bash

# echo $DATABASE_URL
mysql://sysdocu:12345678@db.sysdocu.kr/testdb

7) Managements

Managements 에서는 아래 기능 설정이 가능합니다.

- Roles : 작업에 대한 권한을 정의

- Resource Quotas : 네임스페이스 내의 모든 Pod, 리소스 및 객체의 사용량을 관리

- Limit Ranges : 컨테이너 및 Pod의 리소스 사용을 제한하는 데 사용

따로 필요한 부분만 설정하여 사용이 가능하지만 여기 예제에서는 한 번에 설정하고 적용하도록 하겠습니다.

아래 설정값을 먼저 작성해둡니다.

위치 : 포털 로그인 > Managements > Roles

> [생성] 버튼을 누릅니다.

> YAML 입력창에 아래 내용을 작성하고 [저장] 버튼을 누릅니다.

my-role 이라는 Role 에 pods 리소스에 대한 get, list, watch 명령을 수행할 수 있는 권한을 주었습니다.

이어서 Resource Quotas 를 작성합니다.

위치 : 포털 로그인 > Managements > Resource Quotas

> [생성] 버튼을 누릅니다.

> YAML 입력창에 아래 내용을 작성하고 [저장] 버튼을 누릅니다.

my-resource-quota 라는 Resource Quota 는 네임스페이스 내에서 최대 5개의 Pod 를 생성하며, CPU 및 메모리에 대한 요청과 제한 값을 설정하였습니다.

* 참고 : 권한 상승

YAML 저장시 "해당 리소스에 접근할 수 있는 권한이 없습니다." 라는 메세지가 출력될 경우, 포털 admin 계정으로 현재 계정에 대해 권한을 상승시켜주면 됩니다.

위치 : admin 계정으로 포털 로그인 > Managements > Users > 'User' 탭

> 사용자 계정을 클릭 후 하단 [수정] 버튼을 누릅니다.

> Authority : [Cluster Admin] 으로 변경 후 [저장] 버튼을 누릅니다.

> admin 계정을 로그아웃 하고 다시 일반 계정으로 로그인합니다.

> 위 Resource Quota 를 생성합니다.

이어서 Limit Ranges 를 작성합니다.

위치 : 포털 로그인 > Managements > Limit Ranges

> [생성] 버튼을 누릅니다.

> YAML 입력창에 아래 내용을 작성하고 [저장] 버튼을 누릅니다.

my-limit-range 라는 Limit Range 를 생성하여 컨테이너의 메모리에 대한 제한과 요청 값을 설정하였습니다.

Resource Quota, Limit Range 는 네임스페이스 내에서 생성해 두기만 하면 이후에 생성되는 Pod 에 자동 적용이 됩니다.

그리고 Role 은 일반적으로 Kubernetes 환경에서 사용하려면 Role Binding 과 ServiceAccount 를 추가로 생성해서 Deployment 에 연결시켜줘야 하지만, K-PaaS 에서는 Role 을 만들고 admin 계정으로 특정 계정의 Namespace 와 Role 을 선택해 주기만 하면 됩니다.

위에서 미리 생성했던 Role 을 계정에 적용해 보겠습니다.

우선, 일반 계정을 로그아웃 하고 admin 계정으로 로그인 합니다.

위치 : 포털 로그인 > Managements > Users

> 'Administrator' 탭에서 계정 이름 선택

> 아래 [수정] 버튼을 누릅니다.

> Authority 값을 Cluster Admin 에서 User 로 변경하고

> 바로 아래에 있는 Namespaces ⁄ Roles 의 [선택] 버튼을 누릅니다.

> 만들었던 Namespace 와 Role 을 선택합니다. (예 : mynamespace / my-role)

> [선택 완료] 버튼을 누릅니다.

> 하단의 [수정] 버튼을 누릅니다.

일반 계정에 권한이 적용되었습니다.

절차에서 알 수 있듯이 admin 계정이나 Cluster Admin 권한의 계정은 Role 적용이 되지 않습니다.

현재는 오픈 클라우드 플랫폼 (K-PaaS) 이라는 이름으로 변경 되었지만, 이전에 사용하던 명칭 PaaS-TA 는 "Platform as a Service - 'Thank you' 의 속어인 'TA' 의 의미로, 한국지능정보사회진흥원 (NIA) 의 지원으로 다양한 국내 업체와 협업을 통해 만든 개방형 클라우드 플랫폼입니다. PaaS-TA 는 오픈소스 커뮤니티인 Cloud Foundry 를 기반으로 한 클라우드 플랫폼으로, 애플리케이션을 빠르고 쉽게 배포하고 실행할 수 있는 환경을 제공합니다. 그리고 다양한 기능과 서비스를 제공하여 개발자들이 애플리케이션을 효율적으로 구축하고 관리할 수 있도록 도와줍니다. 몇 가지 주요 기능은 다음과 같습니다.
- 애플리케이션 배포 및 관리 : 애플리케이션을 컨테이너화하여 배포하고, 애플리케이션 스케일링, 로드 밸런싱, 자동 복구 등을 관리할 수 있습니다. 개발자는 애플리케이션의 빌드, 배포, 롤백 등을 간편하게 수행할 수 있습니다.
- 서비스 관리 : 다양한 서비스를 제공하며, 데이터베이스, 메시징, 캐싱 등과 같은 백엔드 서비스를 애플리케이션에서 활용할 수 있습니다. 이를 통해 개발자는 별도의 서비스 구축 없이 필요한 기능을 활용할 수 있습니다.
- 스케줄링 및 자원 관리 : 애플리케이션의 스케줄링 및 자원 관리를 지원하여, 리소스의 효율적인 활용과 애플리케이션의 안정적인 운영을 도와줍니다.
- 모니터링 및 로깅 : 애플리케이션의 상태, 리소스 사용량, 로그 등을 모니터링하고 관리할 수 있는 기능을 제공합니다. 이를 통해 개발자는 애플리케이션의 성능과 안정성을 실시간으로 확인하고 문제를 해결할 수 있습니다.

PaaS-TA 는 오픈소스이므로 기업이나 개발자들은 소스 코드를 활용하여 자체적으로 구축하거나 커스터마이징 할 수 있습니다.

본 PaaS-TA CP (Container Platform) 설치 매뉴얼은 공식 문서를 기반으로 테스트하고 작성되었습니다.

- PaaS-TA Document : https://github.com/PaaS-TA/paas-ta-container-platform/blob/master/install-guide/Readme.md

- BOSH Document : http://bosh.io

- Cloud Foundry Document : https://docs.cloudfoundry.org

설치하는 PaaS-TA 버전은 6.5 이고, 서비스형 배포 방식이며, IaaS 환경은 Openstack 입니다.

Openstack 환경 구성은 아래 포스팅을 확인해주세요.

- Openstack 환경 구성 : https://sysdocu.tistory.com/1833

- VM 생성 : https://sysdocu.tistory.com/1836

[ 서버 준비 ]

1) Openstack 환경의 VM 4대를 준비합니다.

    - VM (최소) 사양 : 2 CPU / 8GB RAM

    - OS : Ubuntu 20.04

    - VM 4대 : Master node 1대 / Slave node 3대

2) VM 과 같은 내부 네트워크를 사용하는 곳에 NFS 서버를 추가로 준비합니다. (NFS 서버 설치 : 바로가기)

3) 모든 작업은 공식 Documents 에 안내되어 있는대로 ubuntu 계정을 사용합니다. 계정이 없거나 권한이 부족한 경우 아래절차로 설정해주세요.

- useradd -m -d /home/ubuntu -s /bin/bash -G sudo ubuntu
- echo "ubuntu:12345678@#" | chpasswd
- echo "ubuntu  ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers
- mkdir /home/ubuntu/.ssh
- chown ubuntu.ubuntu /home/ubuntu/.ssh

1. Kubespray 설치

먼저, 설치가 잘 될 수 있도록 ufw 방화벽을 중지하고 OS 환경 업데이트를 진행합니다.

(모든 노드에서)

$ sudo systemctl disable --now ufw

$ sudo apt -y update

$ sudo apt -y upgrade

1) 설치 환경 구성

Kubespray 를 이용해 Kubernetes Cluster 를 쉽게 구성할 수 있습니다.

우선 각 서버를 지칭하고, 연결이 수월할 수 있도록 내부 IP 와 호스트명을 설정합니다.

(모든 노드에서)

$ sudo vi /etc/hosts

(각 노드에서)

$ sudo hostnamectl set-hostname master      // master 노드에서

$ sudo hostnamectl set-hostname worker1    // worker1 노드에서

$ sudo hostnamectl set-hostname worker2    // worker2 노드에서

$ sudo hostnamectl set-hostname worker3    // worker3 노드에서

$ sudo hostnamectl set-hostname nfs            // nfs 노드에서

Kubespray 설치를 위해 SSH Key 를 인벤토리의 모든 서버들에 복사합니다.

(Master 노드에서)

$ ssh-keygen -t rsa -m PEM
Generating public/private rsa key pair.
Enter file in which to save the key (/home/ubuntu/.ssh/id_rsa): (엔터)
Enter passphrase (empty for no passphrase): (엔터)
Enter same passphrase again: (엔터)
Your identification has been saved in /home/ubuntu/.ssh/id_rsa
Your public key has been saved in /home/ubuntu/.ssh/id_rsa.pub
The key fingerprint is:
SHA256:7F9X4w2PGnTkju37pueRdcYvZZcDDmci0+hhoEJeOqA ubuntu@master
The key's randomart image is:
+---[RSA 3072]----+
| . . . .         |
|. + o . . o      |
|E  = .   * + +.  |
|    o  .o + *o...|
|        S.  ..++X|
|       .   . =.OX|
|        .   + *++|
|         . . = .+|
|          . . +Bo|
+----[SHA256]-----+

아래 명령으로 출력된 공개키를 모든 Master node (본서버 포함), Worker node 에 복사합니다.

$ cat ~/.ssh/id_rsa.pub

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDA7lkRlLtIYjeVdLOBCe+jahcDKacVV/hZkAYKEj49pX0EQ2sLRVTdaEkrFws3rBp9MRwI1SeAj3LiqKzpOYeltbIM2v20z1G8EiJIooMdtqlDAbiPlJI4Dz2/UU3KkEOcvP1OLhx9Ctd6xCQTSUuDkb0XenufKHiMFlN0S+fQPeE5YFMe7hpbFuuVTVMqpt1Nev1d2LXfecSj240J7gTC/CysMrdOOG7cyFGdl5CzA8SWKfaI+2R8p19j7fUhc1rYJcJ6CtMuw/jTahSkN+R+6kPvE1+xcTtN/bHJQ/HupTFNXaKs2u6aWrHCUVHe3ghGbyBaAKNVlHxiI2IB1pF98BVsAjfRzDTj2qHv/wVuNTroE0ux0ayu8wDTjNn9Vv6ou2BvfnAoS2qgBdRnKkfnXHcz+eHWl93m+EjfQ2KoEOLD23O91SecU0+SWpWF7egecy/6H7wRsgOlNMeNKMbeRGk9xG0uqE1ip7bsrAOFYYAbQI89Zc5AbzgArVF/j00= ubuntu@master

위 내용을 복사하여 아래와 같이 모든 노드에 저장합니다.

(모든 노드에서 - 본 master 서버 포함)

$ vi .ssh/authorized_keys

그리고 모든 노드에 NFS Client 패키지를 설치합니다.

아래에서 NFS 를 마운트 하기위해 사용할 예정입니다.

$ sudo apt -y install nfs-common

(Master 노드에서 - 이제 Worker 노드에서의 추가 작업은 없음)

Kubespray 설치파일을 다운로드 받고 설치를 이어갑니다.

아래의 branch_v1.4.x 는 특정 버전을 적는것이 아니라 문자 그대로 x 를 입력해야 합니다.

$ git clone https://github.com/PaaS-TA/paas-ta-container-platform-deployment.git -b branch_v1.4.x
Cloning into 'paas-ta-container-platform-deployment'...
remote: Enumerating objects: 11524, done.
remote: Counting objects: 100% (11523/11523), done.
remote: Compressing objects: 100% (5862/5862), done.
remote: Total 11524 (delta 4535), reused 11330 (delta 4347), pack-reused 1
Receiving objects: 100% (11524/11524), 274.90 MiB | 20.39 MiB/s, done.
Resolving deltas: 100% (4535/4535), done.
Updating files: 100% (7807/7807), done.

설치 경로로 이동해서 환경변수 파일을 수정합니다. 변수명에 해당되는 값을 입력하면 됩니다.

worker node 의 수가 더 많을경우 행을 더 추가하여 입력할 수 있습니다.

$ cd paas-ta-container-platform-deployment/standalone/single_control_plane

$ vi cp-cluster-vars.sh

2) 에러 사전 조치

설치 전, 몇가지 에러 방지를 위해 아래와 같은 작업을 진행합니다.

공식 Documents 에서는 아래 내용이 빠져 있으며, 그대로 설치 (deploy-cp-cluster.sh 실행) 할 경우, OS 환경에 따라 여러개의 에러가 발생하는데, 아래는 에러 일부를 사전에 조치하는 방법입니다.

추후, 배포되는 설치 소스가 업데이트 되면서 아래 내용이 필요없게 되거나, 또 다른 조치 방법이 필요할 수 있습니다.

(1) NFS 공유 디렉토리 설정

NFS 를 사용할 경우 아래 파일에서 공유 디렉토리 위치를 변경해줘야 합니다.

파일에 기본 설정된 값은 /home/share/nfs 이므로, 실제 NFS 서버내에 구성한 공유 디렉토리가 /data 일때 아래와 같이 변경합니다.

설치중 deployment.yaml.ori 파일이 deployment.yaml 파일로 복사되므로 deployment.yaml 파일을 수정하지 않도록 주의합니다.

$ sed -i 's/home\/share\/nfs/data/' ../applications/nfs-provisioner-4.0.0/deployment.yaml.ori

또는 아래와 같이 파일을 열어 직접 변경합니다.

$ vi ../applications/nfs-provisioner-4.0.0/deployment.yaml.ori

(2) nf_conntrack 사용

리눅스 커널 4.18 이상의 버전에는 nf_conntrack_ipv4 이름이 nf_conntrack 으로 변경되었습니다. 설치 스크립트에서는 nf_conntrack_ipv4 를 찾지못해 'Module nf_conntrack_ipv4 not found' 메세지가 출력되므로, 모듈명을 수정해 주어야 합니다.

$ sed -i 's/nf_conntrack_ipv4/nf_conntrack/' extra_playbooks/roles/kubernetes/node/tasks/main.yml

$ sed -i 's/nf_conntrack_ipv4/nf_conntrack/' roles/kubernetes/node/tasks/main.yml

(3) Istio 설치 명령어 수정

아래 두개 파일에 잘못된 문자가 있는데 맨 뒤에 å 를 a 로 고쳐줘야 합니다.

curl -L https://istio.io/downloadIstio | ISTIO_VERSION=1.11.4 TARGET_ARCH=x86_64 sh -å

$ sed -i 's/å/a/' extra_playbooks/roles/paasta-cp/istio/tasks/main.yml

$ sed -i 's/å/a/' roles/paasta-cp/istio/tasks/main.yml

3) 설치 및 확인

설치 스크립트를 실행해 설치를 진행합니다.

$ bash deploy-cp-cluster.sh

아래는 설치중 출력되는 에러 메세지 입니다.

에러가 발생하면 무시가 되면서 설치가 계속 진행됩니다.

혹시 방화벽 룰이 설정된 경우, 설치가 제대로 이루어지지 않거나 설치과정에서 멈추는 경우가 있으니 설치가 잘 되지 않는 분은 방화벽을 잠시 내리고 설치해보는 것도 좋습니다.

TASK [etcd : Get currently-deployed etcd version] **************
fatal: [master]: FAILED! => {"changed": false, "cmd": "/usr/local/bin/etcd --version", "msg": "[Errno 2] No such file or directory: b'/usr/local/bin/etcd'", "rc": 2, "stderr": "", "stderr_lines": [], "stdout": "", "stdout_lines": []}
...ignoring

TASK [kubernetes/control-plane : Check which kube-control nodes are already members of the cluster] **************
fatal: [master]: FAILED! => {"changed": false, "cmd": ["/usr/local/bin/kubectl", "get", "nodes", "--selector=node-role.kubernetes.io/control-plane", "-o", "json"], "delta": "0:00:00.046634", "end": "2023-07-20 23:35:05.782368", "msg": "non-zero return code", "rc": 1, "start": "2023-07-20 23:35:05.735734", "stderr": "The connection to the server localhost:8080 was refused - did you specify the right host or port?", "stderr_lines": ["The connection to the server localhost:8080 was refused - did you specify the right host or port?"], "stdout": "", "stdout_lines": []}
...ignoring

TASK [network_plugin/calico : Calico | Get existing FelixConfiguration] *************
fatal: [master]: FAILED! => {"changed": false, "cmd": ["/usr/local/bin/calicoctl.sh", "get", "felixconfig", "default", "-o", "json"], "delta": "0:00:00.060760", "end": "2023-07-24 05:55:32.486934", "msg": "non-zero return code", "rc": 1, "start": "2023-07-24 05:55:32.426174", "stderr": "resource does not exist: FelixConfiguration(default) with error: felixconfigurations.crd.projectcalico.org \"default\" not found", "stderr_lines": ["resource does not exist: FelixConfiguration(default) with error: felixconfigurations.crd.projectcalico.org \"default\" not found"], "stdout": "null", "stdout_lines": ["null"]}
...ignoring

TASK [network_plugin/calico : Calico | Get existing calico network pool] **************
fatal: [master]: FAILED! => {"changed": false, "cmd": ["/usr/local/bin/calicoctl.sh", "get", "ippool", "default-pool", "-o", "json"], "delta": "0:00:00.042520", "end": "2023-07-20 23:36:36.320521", "msg": "non-zero return code", "rc": 1, "start": "2023-07-20 23:36:36.278001", "stderr": "resource does not exist: IPPool(default-pool) with error: ippools.crd.projectcalico.org \"default-pool\" not found", "stderr_lines": ["resource does not exist: IPPool(default-pool) with error: ippools.crd.projectcalico.org \"default-pool\" not found"], "stdout": "null", "stdout_lines": ["null"]}
...ignoring

TASK [network_plugin/calico : Calico | Get existing BGP Configuration] ***************
fatal: [master]: FAILED! => {"changed": false, "cmd": ["/usr/local/bin/calicoctl.sh", "get", "bgpconfig", "default", "-o", "json"], "delta": "0:00:00.034705", "end": "2023-07-20 23:36:37.450199", "msg": "non-zero return code", "rc": 1, "start": "2023-07-20 23:36:37.415494", "stderr": "resource does not exist: BGPConfiguration(default) with error: bgpconfigurations.crd.projectcalico.org \"default\" not found", "stderr_lines": ["resource does not exist: BGPConfiguration(default) with error: bgpconfigurations.crd.projectcalico.org \"default\" not found"], "stdout": "null", "stdout_lines": ["null"]}
...ignoring

TASK [kubernetes-apps/ansible : Kubernetes Apps | Register coredns deployment annotation `createdby`] ***************
fatal: [master]: FAILED! => {"changed": false, "cmd": ["/usr/local/bin/kubectl", "--kubeconfig", "/etc/kubernetes/admin.conf", "get", "deploy", "-n", "kube-system", "coredns", "-o", "jsonpath={ .spec.template.metadata.annotations.createdby }"], "delta": "0:00:00.059931", "end": "2023-07-20 23:37:11.974466", "msg": "non-zero return code", "rc": 1, "start": "2023-07-20 23:37:11.914535", "stderr": "Error from server (NotFound): deployments.apps \"coredns\" not found", "stderr_lines": ["Error from server (NotFound): deployments.apps \"coredns\" not found"], "stdout": "", "stdout_lines": []}
...ignoring

TASK [kubernetes-apps/ansible : Kubernetes Apps | Register coredns service annotation `createdby`] *****************
fatal: [master]: FAILED! => {"changed": false, "cmd": ["/usr/local/bin/kubectl", "--kubeconfig", "/etc/kubernetes/admin.conf", "get", "svc", "-n", "kube-system", "coredns", "-o", "jsonpath={ .metadata.annotations.createdby }"], "delta": "0:00:00.061244", "end": "2023-07-20 23:37:12.300058", "msg": "non-zero return code", "rc": 1, "start": "2023-07-20 23:37:12.238814", "stderr": "Error from server (NotFound): services \"coredns\" not found", "stderr_lines": ["Error from server (NotFound): services \"coredns\" not found"], "stdout": "", "stdout_lines": []}
...ignoring

에러가 발생해도 자동으로 넘어가면서 설치가 완료되었습니다. 설치가 잘 되었는지 확인합니다.

$ kubectl get nodes
NAME      STATUS   ROLES           AGE   VERSION
master    Ready    control-plane   16m   v1.25.6
worker1   Ready    <none>          15m   v1.25.6
worker2   Ready    <none>          15m   v1.25.6
worker3   Ready    <none>          15m   v1.25.6

$ kubectl get pods -n kube-system
NAME                                       READY   STATUS    RESTARTS      AGE
calico-kube-controllers-75748cc9fd-5k46h   1/1     Running   0             16m
calico-node-7ldrx                          1/1     Running   0             16m
calico-node-f48sv                          1/1     Running   0             16m
calico-node-nxspr                          1/1     Running   0             16m
calico-node-zb9c2                          1/1     Running   0             16m
coredns-588bb58b94-2bbtm                   1/1     Running   0             15m
coredns-588bb58b94-5prkj                   1/1     Running   0             15m
dns-autoscaler-5b9959d7fc-6qzsr            1/1     Running   0             15m
kube-apiserver-master                      1/1     Running   1             17m
kube-controller-manager-master             1/1     Running   2 (14m ago)   17m
kube-proxy-89x74                           1/1     Running   0             16m
kube-proxy-8nfnp                           1/1     Running   0             16m
kube-proxy-bt478                           1/1     Running   0             16m
kube-proxy-v8hjh                           1/1     Running   0             16m
kube-scheduler-master                      1/1     Running   2 (14m ago)   17m
metrics-server-64c4c5ddbc-t6qq5            1/1     Running   0             15m
nginx-proxy-worker1                        1/1     Running   0             16m
nginx-proxy-worker2                        1/1     Running   0             16m
nginx-proxy-worker3                        1/1     Running   0             16m
nodelocaldns-74st7                         1/1     Running   0             15m
nodelocaldns-9dk9v                         1/1     Running   0             15m
nodelocaldns-c2d5f                         1/1     Running   0             15m
nodelocaldns-rv6cf                         1/1     Running   0             15m

설치 또는 실행이 중지된 Pod 가 있는지 확인합니다.

아무런 결과가 나오지 않아야 합니다.

$ kubectl get pods -A |grep Pending
The connection to the server 127.0.0.1:6443 was refused - did you specify the right host or port?

이와 같은 메세지가 출력될 경우 조금 기다렸다가 다시 확인해보세요. 클러스터 구성이 모두 정상 가동되려면 약간의 시간이 필요합니다.

* 참고 : Kubespray 삭제

$ bash reset-cp-cluster.sh

...

Are you sure you want to reset cluster state? Type 'yes' to reset your cluster. [no]: yes

...

그리고 NFS 서버 공유 디렉토리에 있던 데이터를 모두 지워줍니다.

(NFS 서버에서)

# rm -rf /data/*

2. 컨테이너 플랫폼 포털 설치

컨테이너 플랫폼 포털 (대시보드) 을 이용해 관리자 및 이용자가 쉽게 응용프로그램 등을 생성하고 관리할 수 있습니다.

설치 방법을 알아봅니다.

1) 컨테이너 플랫폼 포털 Deployment 파일 다운로드

(Master 노드에서)

포털 배포 파일 다운로드 경로를 생성합니다.
$ mkdir -p ~/workspace/container-platform
$ cd ~/workspace/container-platform

포털 배포 파일을 다운로드하고 압축을 해제합니다.
$ wget --content-disposition https://nextcloud.paas-ta.org/index.php/s/WtNQn2agk6epFHC/download
$ tar xvzf cp-portal-deployment-v1.4.0.tar.gz

* 참고 : Deployment 파일 디렉토리 구성
├── script                # 컨테이너 플랫폼 포털 배포 관련 변수 및 스크립트 파일 위치
├── images             # 컨테이너 플랫폼 포털 이미지 파일 위치
├── charts               # 컨테이너 플랫폼 포털 Helm Charts 파일 위치
├── values_orig      # 컨테이너 플랫폼 포털 Helm Charts values.yaml 파일 위치
└── keycloak_orig   # 컨테이너 플랫폼 포털 사용자 인증 관리를 위한 Keycloak 배포 관련 파일 위치

2) 컨테이너 플랫폼 포털 변수 정의

$ cd cp-portal-deployment/script

$ vi cp-portal-vars.sh

3) 컨테이너 플랫폼 포털 설치

설치를 하기 전에 root 사용자로 변경합니다.

설치를 반복해보니 컨테이너 플랫폼 포털은 root 사용자로 설치가 잘 되는것을 확인했습니다.

$ sudo su -

# cd /home/ubuntu/workspace/container-platform/cp-portal-deployment/script

파일에 실행권한을 주고 실행합니다.

# chmod +x deploy-cp-portal.sh

# ./deploy-cp-portal.sh 

컨테이너 플랫폼 포털 관련 리소스가 정상적으로 배포되었는지 확인합니다.
리소스 Pod 의 경우 Node 에 바인딩 및 컨테이너 생성 후 Error 또는 Pending 상태에서 시간이 지나 Running 상태로 전환되기도 하므로 시간을 갖고 기다려봅니다.

Harbor 리소스 조회

# kubectl get all -n harbor

>> 정상

MariaDB 리소스 조회

# kubectl get all -n mariadb

>> 정상

Keycloak 리소스 조회

# kubectl get all -n keycloak

>> 정상

컨테이너 플랫폼 포털 리소스 조회

# kubectl get all -n cp-portal

>> 정상

혹시 설치가 잘 안되는 경우 아래 '컨테이너 플랫폼 포털 리소스 삭제' 방법대로 설치된 파일을 삭제한 다음에, deploy-cp-portal.sh 설치 스크립트 파일의 내용을 부분적으로 실행해 서 에러 원인을 찾고 조치하면 문제가 되는 부분이 어디인지 확인을 할 수 있습니다.

4) 컨테이너 플랫폼 포털 접속

컨테이너 플랫폼 포털은 아래 주소와 같이 Master node 의 IP 와 포트 32703 으로 접속 가능합니다.

보안 강화를 위해 로그인 후 제일 먼저 패스워드 변경하는 것이 좋습니다.

http://115.68.142.67:32703

ID : admin

PW : admin

Harbor 오픈 소스 컨테이너 이미지 레지스트리의 대시보드 URL 과 기본 계정입니다.

이것도 마찬가지로 처음 로그인 후 패스워드를 변경하는 것이 좋습니다.

http://115.68.142.84:30002

ID : admin

PW : Harbor12345

Keycloak 소스 싱글 사인온 (Single Sign-On, SSO) 솔루션 대시보드 URL 과 기본 계정입니다.

http://115.68.142.84:32710

ID : admin

PW : admin

* 참고 : 컨테이너 플랫폼 포털 리소스 삭제

# chmod +x uninstall-cp-portal.sh
# ./uninstall-cp-portal.sh

Are you sure you want to delete the container platform portal? <y/n> y

...

# sudo rm -rf ../keycloak