K0S 는 경량 Kubernetes 배포를 위한 오픈 소스 프로젝트로써 가능한 간소한 배포 및 관리를 목표로 합니다. 이 프로젝트는 Kubernetes 환경을 빠르게 구성하고 유지보수할 수 있도록 설계되었습니다.

K0S 는 다음과 같은 특징을 가지고 있습니다.

- 경량화 : 최소한의 의존성과 경량화된 구성으로 구축되어 있어, 자원 사용이 적습니다.

- 포터빌리티 : 다양한 환경에서 실행되도록 설계되어 있어, 로컬 머신, 가상 머신, 또는 클라우드 환경에서 사용할 수 있습니다.

- 간편한 설치 및 운영 : 설치 및 운영이 간단하며, 개발자나 작은 규모의 프로젝트에 적합합니다.

- 플러그인 시스템 : 필요한 경우 플러그인을 추가하여 기능을 확장할 수 있습니다.

K0S 는 K8S Cluster 를 관리하고 유지보수하는데 더 간편한 옵션을 제공합니다. 하지만 특정 프로젝트의 요구에 따라 다른 Kubernetes 배포 옵션도 고려해볼 필요가 있습니다.

본 내용은 공식 Document 내용을 참고하여 실행해보고 기록하였습니다.

- 공식 Document : https://github.com/k0sproject/k0s/blob/main/docs/install.md

1. 설치

# curl -sSLf https://get.k0s.sh | sudo sh
Downloading k0s from URL: https://github.com/k0sproject/k0s/releases/download/v1.29.1+k0s.1/k0s-v1.29.1+k0s.1-amd64
k0s is now executable in /usr/local/bin

기본 구성으로 컨트롤러 및 작업자 기능을 포함하는 단일 노드 K0S 를 설치합니다.

# k0s install controller --single

참고로 재설치가 필요한 경우 --force 옵션을 사용하면 됩니다.

예) k0s install controller --single --force

2. 구동

K0S 서비스를 시작합니다.
# k0s start

K0S 인스턴스 상태를 확인합니다.
# k0s status
Version: v1.29.1+k0s.1
Process ID: 1787
Role: controller
Workloads: true
SingleNode: true
Kube-api probing successful: true
Kube-api probing last error:  

kubectl 을 사용하면 애플리케이션을 배포하거나 노드 상태를 확인할 수 있습니다.
# k0s kubectl get nodes
NAME            STATUS   ROLES           AGE     VERSION
sysdocu-23890   Ready    control-plane   3m53s   v1.29.1+k0s

참고로 서비스 중지는 다음과 같습니다.
# k0s stop

3. 삭제

중지 후에는 필요에 따라 K0S 를 초기화 할 수 있습니다.

이 명령은 설치된 시스템 서비스, 데이터 디렉터리, 컨테이너, 마운트 및 네트워크 네임스페이스를 모두 정리합니다.

# k0s reset

그리고 리부팅을 해야 하는데, 그 이유는 정리되지 못한 데몬이나 iptables 가 남아 있을 수 있기 때문입니다.

# reboot

여기에서는 Kubernetes Cluster 가 이미 구축되어 있다는 전제 하에 Korifi 설치하는 방법을 설명합니다.

worker node 가 여러대 준비되어 규모를 확장시킬 수 있는 상태에서 korifi 설치를 진행하는 것이므로, 아직 준비되지 않으신 분은 아래 포스팅을 참고하세요.

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

1. 사전 작업

Korifi 설치 및 사용에 필요한 명령어를 우선 설치 합니다.

1) Kubectl

# curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
# install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl

2) 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

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

# tar xvzf helm-v3.12.0-linux-amd64.tar.gz
# mv linux-amd64/helm /usr/local/bin/

2. 설치 진행

1) 환경변수 설정

# export ROOT_NAMESPACE="cf"

# export KORIFI_NAMESPACE="korifi"

# export ADMIN_USERNAME="cf-admin"

# export BASE_DOMAIN="az1.sysdocu.kr"

2) Cert Manager 설치

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

3) Kpack 설치

# kubectl apply -f https://github.com/buildpacks-community/kpack/releases/download/v0.13.2/release-0.13.2.yaml

4) 네임스페이스 생성
# 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

5) Contour 설치

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

6) DNS 설정

서비스에 사용할 도메인 IP 는 Contour 의 Envoy 프록시 외부 IP 로 연결해야 합니다. 외부 IP 를 확인하는 방법은 다음과 같습니다.

# kubectl get service envoy -n projectcontour -ojsonpath='{.status.loadBalancer.ingress[0]}'

{"ip":"115.68.142.130"}

IP 가 출력되지 않을 경우 MetalLB 를 올바르게 설정했는지 확인해보세요. (참고 : https://sysdocu.tistory.com/1854)

MetalLB 없이 사용하고자 할 경우,

- Kubernetes 를 한 대로 구성하여 사용중이라면 현재 마스터 서버의 IP 로 연결시키면 됩니다.

- 여러대로 구성해서 사용중이라면 projectcontour 네임스페이스에 있는 envoy Pod 의 CLUSTER-IP 로 연결 시키면 됩니다. 이 경우는, 공인 IP 가 없는 상태이므로 외부에서 접근은 안되고 내부에서만 접근이 가능합니다.

- API 서버 도메인 : api.az1.sysdocu.kr - 115.68.142.130

- 애플리케이션이 사용할 도메인 : *.apps.az1.sysdocu.kr - 115.68.142.130

7) Secret 생성

여기에서는 실제 사용 가능한 Repository 정보를 입력해야 합니다.

# 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"

8) Korifi 설치

설치할 Korifi 버전에 따라 사용되는 옵션이 다릅니다.

가령 Korifi 0.10.0 버전에서는 옵션에 global. 이라는 명칭이 제거되고, Korifi 0.11.0 에서는 networking.gatewayClass 옵션이 추가됩니다.

Korifi 0.7.1 이후의 버전 설치방법은 확인되면 업데이트 하겠습니다.

아래 Repository 에는 실제 사용 가능한 정보를 입력해야 합니다.

# helm install korifi https://github.com/cloudfoundry/korifi/releases/download/v0.7.1/korifi-0.7.1.tgz \
   --namespace="$KORIFI_NAMESPACE" \
   --set=global.generateIngressCertificates=true \
   --set=global.rootNamespace="$ROOT_NAMESPACE" \
   --set=global.containerRegistrySecret="image-registry-credentials" \
   --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=kpackImageBuilder.builderRepository="registry.az1.sysdocu.kr:5000/kpack-builder" \
   --wait

9) CF 관리자 계정 생성

CF 관리자 계정 cf-admin 을 추가합니다.

생성 명령 절차가 길어 명령어 앞에 프롬프트를 제거하였습니다. 아래 명령을 전체 복사하여 실행하면 됩니다.

cf-admin 이 아닌 계정명으로 변경하고 싶을 경우 아래 내용에서 cf-admin 문자열을 다른 계정 ID 로 치환하여 실행하면 됩니다.

openssl genrsa -out cf-admin.key 2048
openssl req -new -key cf-admin.key -out cf-admin.csr -subj "/CN=cf-admin"
tmp=`cat cf-admin.csr | base64 | tr -d "\n"`
cat <<EOF | kubectl apply -f -
apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: cf-admin
spec:
  request: $tmp
  signerName: kubernetes.io/kube-apiserver-client
  #expirationSeconds: 604800 # 1주일 (옵션 미사용시 : 1년 유효)
  usages:
    - client auth
EOF
kubectl certificate approve cf-admin
kubectl get csr cf-admin -o jsonpath='{.status.certificate}'| base64 -d > cf-admin.crt
kubectl create role developer --verb=create --verb=get --verb=list --verb=update --verb=delete --resource=pods
kubectl create rolebinding developer-binding-cf-admin --role=developer --user=cf-admin
kubectl config set-credentials cf-admin --client-key=cf-admin.key --client-certificate=cf-admin.crt --embed-certs=true
kubectl config set-context cf-admin --cluster=kubernetes --user=cf-admin

3. 애플리케이션 배포

1) Cloud Foundry API 로그인

# cf api https://api.$BASE_DOMAIN --skip-ssl-validation

# cf auth cf-admin

2) 조직 및 공간 생성

# cf create-org org1

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

3) 애플리케이션 배포

준비된 소스 코드가 없다면, 공개된 샘플 소스 코드를 다운로드하고 배포해 봅니다.

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

# cd sample-web-apps/java

# cf push java1

4) 애플리케이션 확인

배포된 애플리케이션에 접근합니다.

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

Hello, World!
Java Version: 17.0.10

애플리케이션의 추가 정보는 아래와 같이 확인이 가능합니다.

CF 로 배포된 애플리케이션 리스트를 확인합니다.

# cf a
Getting apps in org org1 / space space1 as cf-admin...

name    requested state   processes                               routes
java1   started           web:1/1, executable-jar:0/0, task:0/0   java1.apps.az1.sysdocu.kr

특정 애플리케이션의 자세한 정보를 확인합니다.

# cf app java1
Showing health and status for app java1 in org org1 / space space1 as cf-admin...

name:              java1
requested state:   started
routes:            java1.apps.az1.sysdocu.kr
last uploaded:     Fri 16 Feb 07:13:55 UTC 2024
stack:             io.buildpacks.stacks.bionic
buildpacks:        

type:           web
sidecars:       
instances:      1/1
memory usage:   1024M
     state     since                  cpu    memory   disk     logging      details
#0   running   2024-02-16T07:45:20Z   0.0%   0 of 0   0 of 0   0/s of 0/s   

type:           executable-jar
sidecars:       
instances:      0/0
memory usage:   1024M
There are no running instances of this process.

type:           task
sidecars:       
instances:      0/0
memory usage:   1024M
There are no running instances of this process.

GitLab CI/CD 는 GitLab 에서 제공하는 지속적 통합 (CI) 및 지속적 배포 (CD) 서비스를 의미합니다. 이것은 소프트웨어 개발 프로세스를 자동화하고, 코드의 변경 사항을 지속적으로 통합하고 배포함으로써 개발자 팀이 효율적으로 작업할 수 있도록 도와주는 도구입니다.

여기에서 CI (Continuous Integration) 는 개발자들이 작성한 코드의 변경 사항을 지속적으로 통합하고 빌드하는 과정을 의미합니다. 새로운 코드가 저장소에 푸시될 때마다 자동으로 빌드 및 테스트가 수행되어 코드의 품질을 유지하고, 팀 내에서 코드 충돌이나 오류를 미리 발견할 수 있도록 도와줍니다.

CD (Continuous Deployment/Delivery) 는 CI 의 확장으로, 빌드 및 테스트를 통과한 코드를 자동으로 배포할 수 있도록 하는 것을 의미합니다. CD 는 애플리케이션을 테스트 환경, 스테이징 환경, 혹은 실제 운영 환경에 자동으로 배포하는 등의 작업을 지원합니다.

본 매뉴얼에 기술된 예제는 아래 포스팅 내용에 이어서 작성하였습니다.

- Ubuntu 22.04 에서 GitLab CE (Community Edition) 설치 및 사용하기 : https://sysdocu.tistory.com/1892

1. GitLab runner 설치

GitLab 이 설치된 서버에서 GitLab runner 설치를 진행합니다.

# curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh | sudo bash

# apt -y install gitlab-runner

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

# gitlab-runner -v
Version:      16.8.0
Git revision: c72a09b6Enter optional 
Git branch:   16-8-stable
GO version:   go1.21.5
Built:        2024-01-18T22:42:25+0000
OS/Arch:      linux/amd64

2. Runner 생성

- 참고 Document : https://docs.gitlab.com/runner/register/

Pipeline 을 구성하기 위해서는 프로젝트와 하나 이상의 runner 가 있어야 합니다.

runner 를 등록하기 위해 GitLab 웹페이지에서 아래 메뉴로 이동, runner 를 생성합니다.

저는 runner 설치를 진행하기 전에 GitLab 에 미리 root 사용자로 sample 이라는 프로젝트를 생성했었습니다.

그리고 아래 메뉴를 통해 runner 를 생성하였습니다.

1) runner 생성 메뉴 : 프로젝트 (sample) 메인 화면 > Settings > CI/CD > Runners [Expand] > Project runners [New project runner] 클릭

- Platform : Linux 선택

- Tags : test 입력

- Run untagged jobs : 체크

- [Create runner] 클릭하여 생성

2) Shell 명령 실행

위 작업을 마치면 Shell 에서 실행하기 위한 명령 예시가 출력됩니다. 내용을 복사하여 Shell 에서 실행합니다.

# gitlab-runner register  --url http://git.sysdocu.kr --token glrt-1DJKxhPcyNk3dTiVWMcX

Runtime platform                                    arch=amd64 os=linux pid=397821 revision=c72a09b6 version=16.8.0
Running in system-mode.                            
                                                   
Enter the GitLab instance URL (for example, https://gitlab.com/):
[http://git.sysdocu.kr]: (그냥 엔터)
Verifying runner... is valid                        runner=1DJKxhPcy
Enter a name for the runner. This is stored only in the local config.toml file:
[localhost]: (그냥 엔터)
Enter an executor: parallels, virtualbox, docker-windows, docker-autoscaler, instance, custom, shell, ssh, docker, docker+machine, kubernetes:
shell
Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!
 
Configuration (with the authentication token) was saved in "/etc/gitlab-runner/config.toml"

3. .gitlab-ci.yml 작성 및 Pipeline 실행

GitLab 에서 생성된 프로젝트 최상위 디렉토리에 .gitlab-ci.yml 파일 (옵션에서 파일명 변경 가능) 을 생성하고 가장 심플한 내용으로 작성해 보도록 하겠습니다.

Build > Pipeline editor 메뉴에 가면 제공되는 기본 설정값으로 테스트를 해 볼 수도 있지만 모두 삭제하고 더 간단한 아래 내용으로 작성해 봅니다.

키보드로 글자를 입력할 때마다 Edit Box 위에서 자동으로 Pipeline syntax 체크가 이루어 지는것을 볼 수 있습니다.

그리고 이 파일에서 구성한 내용에 따라 Pipeline 이 실행될 예정입니다.

참고로, Pipeline 을 저장하면 설정한 Pipeline 이 자동 실행되고, 업로드 했던 소스 파일이 /home/gitlab-runner/builds/{runner ID}/0/{git 계정}/{프로젝트 이름} 디렉토리에서도 보이게 됩니다.

1) 간단한 Pipeline

- test : stages: 는 일반적으로 build, test, deploy 의 명칭을 사용하지만 꼭 정해진 명칭은 없습니다.

           아래에 행을 추가해 여러개로 나열 할 수 있으며, 명칭은 하단 stage: 에 꼭 존재해야 합니다.

- test-job : 임의로 정한 작업이름이므로 작업 구분이 가능한 글자로 변경해도 됩니다.

- test : 맨 하단의 test 는 위에서 Project runner 를 생성할때 지정했던 tags 값 입니다.

           tags 는 특정 runner 를 선택하여 작업을 실행할 때 사용됩니다.

           tags 항목이 없다면 'Can run untagged jobs' 옵션이 허용된 모든 runner 가 실행 됩니다.

Pipeline 실행은 간단합니다.

해당 프로젝트에 파일을 push 하면 되는데, push 이후의 Pipeline 진행 상황은 'GitLat 프로젝트 > Build > Pipelines' 에서 확인이 가능합니다.

push 방법은 다른 포스팅을 참고해 주세요. (https://sysdocu.tistory.com/1892 에서 '3. 파일 업로드' 부분 참고)

설정 내용을 변경해 보겠습니다.

2) 다양한 작업의 Pipeline

- variables: 쉘스크립트나 PHP 등에서처럼 변수를 미리 정의합니다. 이는 하단에서 불러올 수 있습니다.

- stages 의 수는 3개이고, 실행될 작업은 4개인데, 이렇게 개수가 달라도 상관없습니다. stage 가 중복되어도 됩니다.

- script 의 행을 추가하면 하나의 작업에서 여러개의 동작을 실행할 수 있습니다.

- 기본적으로 설정된 각 stage 를 순차적으로 실행하며, 만약 어떤 stage 에서 실패하면 다음 stage 는 실행되지 않습니다.

3) 파일 복사

파일 복사는 로컬 개발환경이 아닌 GitLab 프로젝트 내에서 이루어집니다.

GitLab 은 객체와 인덱스로 데이터를 저장하기 때문에, 서버에 원격접속하여 디렉토리 구조를 눈으로 확인할 수 없지만 웹페이지를 이용해 프로젝트에 접근을 하면 일반 파일시스템과 같은 구조로 디렉토리와 파일을 보여주고 있습니다.

그렇게 저장되어 있다고 가정하고, 디렉토리를 만드는 명령어나 복사 명령어를 수행 할 수 있습니다.

위 Pipeline 설정을 처리하기 위해 index.php 파일을 올려놓고 실행하면, destination 디렉토리에도 동일한 파일이 생성됩니다.

# find / -name destination
/home/gitlab-runner/builds/-aRx3myd6/0/root/sample/destination

# ll /home/gitlab-runner/builds/-aRx3myd6/0/root/sample/destination/index.php 
-rw-rw-r-- 1 gitlab-runner gitlab-runner 40 Feb 14 10:48 /home/gitlab-runner/builds/-aRx3myd6/0/root/sample/destination/index.php

* 참고 : 업로드 파일 확인

일반적으로 GitLab 에 올려진 데이터는 객체와 인덱스로 저장되어 있어 서버 내에서 사람의 눈으로 찾아볼 수 없는데, gitlab-runner 를 설치하고 Pipeline 을 설정하면, /home/gitlab-runner/builds/{runner ID}/0/{git 계정}/{프로젝트 이름} 디렉토리 내에 업로드 했던 디렉토리 및 파일 목록이 보여지게 됩니다.

추가로 확인된 내용은 아래와 같습니다.

- 이 디렉토리 내의 파일은 파일시스템에 보이는 사본이므로, 수동으로 수정한다고 해도 GitLab 웹페이지 실제 데이터에 반영되지 않습니다.

- script 내에 설정된 cp 명령이 실제로 사본 디렉토리에서 실행되었지만, GitLab 웹페이지에서 보이지 않는것과 같습니다.

- 프로젝트 디렉토리 (/home/gitlab-runner/builds/{runner ID}/0/{git 계정}/{프로젝트 이름}) 를 기준으로 명령이 실행됩니다.

- 때문에 cp 등의 시스템 명령어를 처리할 경우에도 디렉토리의 고유한 식별자 (runner ID : -aRx3myd6) 이름을 알 필요가 없습니다.

* 참고 : Cloud Foundry 명령 실행

본 참고 내용은 다른 포스팅과 연결하여 동작이 되는지 실험하였으므로 해당 사항이 없는 분은 건너 뛰어도 됩니다.

- 단일 서버에서 CF + korifi > GitLab > gitlab-runner 순서로 설치하였습니다.

- 포트 충돌을 방지하고자 korifi 는 80번 포트, GitLab 은 1000번 포트를 사용 하였습니다.

- gitlab-runner 계정이 cf 명령어를 관리자 권한으로 실행할 수 있도록 설정 하였습니다.

  # echo 'gitlab-runner ALL=(ALL:ALL) NOPASSWD:/usr/bin/cf' >> /etc/sudoers

자동 배포 테스트를 위해 아래와 같이 Pipeline 을 재구성 합니다.

push 이후에 아래와 같이 애플리케이션이 확인되었습니다. (사실, Pipeline 저장시 검증을 위해 한 번 실행하게 됨)

같은 이름 (php1) 으로 여러번 배포 해도 됩니다. 소스만 업데이트 하는 속도로 빠르게 배포되어 집니다.

# curl --insecure php1.apps-127-0-0-1.nip.io

Good job !!

Updated.

* 참고

script: 내용을 숨기고자 할때 쉘스크립트 파일을 준비하여 인자값으로 데이터를 넣어 실행하도록 하면 처리 내용을 숨길 수 있습니다.

4) 기타 설정

다른 방식으로도 Pipeline 구성이 가능합니다.

가독성을 높이기 위해 before_script, script, after_script 로 나누어 구조화된 방법으로 작업을 실행합니다.

이는 가독성을 높이고 특정 단계의 실패 시 빠르게 파악할 수 있도록 도움을 주는 것이지, 동작을 위해 필수적인 것은 아닙니다.

특정 branch 에서만 실행하도록 합니다.

특정 branch 만 제외하고 실행합니다.

자동으로 실행하지 않고 GitLab 웹페이지에서 수동으로 실행해줍니다.

패키지 설치로 매우 간단히 설치가 가능합니다.

# dnf -y install sendmail sendmail-cf m4

외부 접근 허용과 Submission 포트 사용을 위해 아래 옵션을 변경, 활성화 합니다.

# vi /etc/mail/sendmail.mc

...

DAEMON_OPTIONS(`Port=smtp,Addr=0.0.0.0, Name=MTA')dnl
DAEMON_OPTIONS(`Port=submission, Name=MSA, M=Ea')dnl

...

# m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf

사용할 도메인을 추가 합니다.

# echo "sysdocu.kr" >> /etc/mail/local-host-names

데몬을 재시작하여 설정을 반영합니다.

# systemctl restart sendmail

데몬 가동 상태를 확인합니다.

# netstat -nltp |grep sendmail
tcp        0      0 0.0.0.0:587             0.0.0.0:*               LISTEN      418162/sendmail: ac 
tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN      418162/sendmail: ac 

iptables 와 같은 방화벽에서 포트 25, 587 포트 접근을 허용하면, 기본적인 메일 송수신 설정은 완료가 됩니다.

PHP 를 사용하여 SMTP 를 통해 이메일을 보내는 방법은 PHPMailer 와 같은 외부 라이브러리를 사용하는 것이 편리합니다. 다음은 PHPMailer 를 사용한 간단한 예제입니다.

먼저, PHPMailer 다운로드를 위해 composer 를 설치 합니다.

# apt -y install composer    // Ubuntu 의 경우

메일 발송을 위한 프로젝트 디렉토리를 생성하고 그 안에서 PHPMailer 를 다운로드 합니다.

작성일 기준으로 6.9.1 버전이 설치됩니다.

# mkdir mail_app
# cd mail_app
# composer require phpmailer/phpmailer

Do not run Composer as root/super user! See https://getcomposer.org/root for details
Continue as root/super user [yes]? yes
Using version ^6.9 for phpmailer/phpmailer
./composer.json has been created
Running composer update phpmailer/phpmailer
Loading composer repositories with package information
Updating dependencies
Lock file operations: 1 install, 0 updates, 0 removals
  - Locking phpmailer/phpmailer (v6.9.1)
Writing lock file
Installing dependencies from lock file (including require-dev)
Package operations: 1 install, 0 updates, 0 removals
  - Installing phpmailer/phpmailer (v6.9.1): Extracting archive
7 package suggestions were added by new dependencies, use `composer suggest` to see details.
Generating autoload files
1 package you are using is looking for funding.
Use the `composer fund` command to find out more!

메일 발송을 위해 아래 내용으로 PHP 소스 코드를 작성합니다.

아래는 SSL 를 사용하지 않고 발송하는 예제입니다.

# vi send.php

작성한 php 파일을 실행하여 메일을 발송합니다.

# php send.php

* 참고 1

외부 SMTP 를 사용할 때 아래와 같이 설정하는 경우도 있으니 참고하시기 바랍니다.

    // SMTP 서버 설정
    $mail->isSMTP();
    $mail->Host = 'gw.sysdocu.kr';
    $mail->SMTPAuth = true;
    $mail->Username = 'admin@sysdocu.kr';
    $mail->Password = 'Mm*nBFu2Pt%qjNf@XLc7e9H1V6CIa(zr';
    $mail->SMTPSecure = false;
    $mail->SMTPAutoTLS = false;
    $mail->Port = 587;

* 참고 2

발송이 되지 않을 경우 SMTP 서버에서 메일 발송 IP (send.php 실행 IP : 115.68.142.120) 를 Relay 설정 하였는지 확인합니다.

예) Sendmail 의 경우

# echo "Connect:115.68.142.120 RELAY" >> /etc/mail/access

# makemap hash /etc/mail/access.db < /etc/mail/access

# systemctl restart sendmail

Chrony 는 NTP (Network Time Protocol) 로 시스템 시간을 동기화 해주는 도구입니다.

시간을 변경하기에 앞서 시스템에서 출력되는 시간을 확인합니다.
# date
Wed Feb  7 22:33:24 KST 2024

chrony 를 설치합니다.
# dnf -y install chrony

설정파일에 한국 시간 타임서버 URL 을 추가합니다.

- time.bora.net

- send.mx.cdnetworks.com
# echo -e "server time.bora.net iburst\nserver send.mx.cdnetworks.com iburst" >> /etc/chrony.conf 

chrony 데몬을 실행하고, 추후 부팅시에도 자동 실행되도록 합니다.
# systemctl enable --now chronyd

변경된 시간을 확인합니다.
# date
Wed Feb  7 13:37:38 KST 2024

PHP-FPM (FastCGI Process Manager) 은 PHP FastCGI 의 대안으로 트래픽이 많은 웹 사이트의 경우 php-fpm 풀 관리를 사용하여 웹 사이트의 성능 부하를 개선할 수 있습니다.

PHP 는 보통 웹서버와 같이 설치되지만, 서버 로컬에서만 PHP 코드를 실행할때, 굳이 Apache 나 Nginx 는 설치할 필요가 없습니다.

여기에서는 Rocky Linux 9 환경에서 웹서버 없이 PHP 8.2 및 PHP-FPM 를 설치하는 방법을 기술하고 있습니다.

1. PHP 설치

PHP-FPM 을 사용하려면 먼저 PHP 가 시스템에 설치되어 있어야 합니다.

환경을 업데이트 하고 Epel 리포지토리를 추가합니다.

# dnf -y update

# dnf -y install https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm

Remi 리포지토리를 추가합니다.

# dnf -y install http://rpms.remirepo.net/enterprise/remi-release-9.rpm

기본 PHP 모듈을 재설정합니다.

# dnf -y module reset php

사용 가능한 PHP 모듈을 확인합니다.

여기에서 설치 가능한 PHP 버전이 확인됩니다.

# dnf module list php

PHP 패키지의 기본 설치 버전을 Remi repository PHP 8.2 로 변경합니다.

# dnf -y module enable php:remi-8.2

PHP 를 설치합니다.

# dnf -y install php

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

# php -v
PHP 8.2.15 (cli) (built: Jan 16 2024 12:19:32) (NTS gcc x86_64)
Copyright (c) The PHP Group
Zend Engine v4.2.15, Copyright (c) Zend Technologies
    with Zend OPcache v8.2.15, Copyright (c), by Zend Technologies

2. PHP-FPM 설치

위와 같이 진행했을 경우, 출력된 내용을 살펴보면 php 관련 패키지가 몇가지 자동으로 설치되는데, php-fpm 까지 포함되어져 있습니다.

php

php-cli

php-common

php-fpm

php-mbstring

php-opcache

php-pdo

php-sodium

php-xml

php-fpm 이 설치되었는지 확인합니다.

# rpm -qa |grep php-fpm
php-fpm-8.2.15-1.el9.remi.x86_64

php-fpm 설치가 되지 않았을 경우 아래와 같이 설치합니다.

# dnf -y install php-fpm

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

# php-fpm -v
PHP 8.2.15 (fpm-fcgi) (built: Jan 16 2024 12:19:32)
Copyright (c) The PHP Group
Zend Engine v4.2.15, Copyright (c) Zend Technologies
    with Zend OPcache v8.2.15, Copyright (c), by Zend Technologies

설치된 php-fpm 서비스를 시작하고 부팅할 때마다 자동으로 실행되도록 설정합니다.

# systemctl enable --now php-fpm

3. PHP 확장 모듈 설치

응용 프로그램을 위한 추가 PHP 모듈을 설치할 수 있습니다.

간단히 패키지 설치하듯 (dnf -y install php-curl) 설치가 가능하며, 여러개의 모듈을 설치할때는 아래와 같이 사용할 수 있습니다.

# dnf -y install php-{bcmath,gd,imap,intl,mysqlnd,pear,pecl-zip,process}

설치된 모듈 리스트를 확인합니다.

# php -m

Gogs 는 경량의 Git 서비스로서, 자체 호스팅이 가능한 Git 서버 솔루션 중 하나입니다. Gogs 는 Go 언어로 개발되었으며, 경량성과 빠른 실행 속도를 갖추고 있습니다. Gogs 는 개인 또는 작은 팀이 소규모 프로젝트를 위해 손쉽게 Git 리포지토리를 관리할 수 있도록 설계되었습니다.

[Gogs 의 특징]
- 경량성 : 경량이면서도 빠른 실행 속도를 가지고 있습니다. 이는 작은 환경에서도 쉽게 실행될 수 있도록 설계되었음을 의미합니다.
- 사용 편의성 : 사용자 친화적인 웹 인터페이스를 제공하여 Git 리포지토리를 쉽게 생성하고 관리할 수 있습니다.
- 자체 호스팅 : 자체 서버 또는 호스팅 환경에서 실행할 수 있어, 사용자는 자체 인프라에서 Git 서버를 운영할 수 있습니다.
- 다국어 지원 : 다국어 지원을 통해 전 세계의 사용자들이 Gogs 를 사용할 수 있습니다.
- 이슈 트래킹 : 간단한 이슈 트래킹 시스템을 내장하고 있어, 프로젝트 관리를 용이하게 해줍니다.
- 플러그인 지원 : 다양한 플러그인을 통해 Gogs 의 기능을 확장할 수 있습니다.

Gogs 는 오픈 소스로 제공되어 있어 누구나 소스 코드를 확인하고 개선할 수 있습니다. 주로 작은 규모의 프로젝트나 개발팀에서 사용되며, 쉽게 설치하고 운영할 수 있는 특징이 강점입니다.

그럼, Ubuntu 22.04 기반의 서버에 Gogs 를 설치하고 Client 가 git 명령으로 사용하는 방법을 설명하겠습니다.

1. 사전 설치

1) 데이터베이스
MySQL 5.7 이상의 버전이나 PostgreSQL 이 필요합니다.

여기에서는 설치가 간편하고 많이 사용하는 MySQL 을 설치하겠습니다.

# apt -y update

# apt install -y mysql-server

# mysql -V
mysql  Ver 8.0.36-0ubuntu0.22.04.1 for Linux on x86_64 ((Ubuntu))

utf8mb4 언어셋의 gogs 데이터베이스를 생성합니다.

스크립트 디렉토리에 준비된 쿼리 파일을 실행하면 쉽습니다.

# mysql -p < scripts/mysql.sql
Enter password: (설치 직후 패스워드 없음. 그냥 엔터)

보안 강화를 위해 root 패스워드를 변경합니다.

# mysql -p

Enter password: (설치 직후 패스워드 없음. 그냥 엔터)

mysql> use mysql;

mysql> alter user root@localhost identified by '12345678';

mysql> flush privileges;

그리고 gogs 사용자 계정을 생성하고 gogs 데이터 베이스에 권한을 부여합니다.

mysql> create user gogs@localhost identified by '12345678';
mysql> grant all privileges on gogs.* to gogs@localhost;
mysql> flush privileges;

2) Git Client
1.8.3 버전 이상으로 설치하면 됩니다.

# apt -y install git

# git version
git version 2.34.1

2. Gogs 설치

1) 설치 준비

바이너리 또는 소스파일로 설치하는 두가지 방법이 있습니다.
여기에서는 다운로드 받고 실행이 간편한 바이너리 형식으로 진행해보겠습니다.

자세한 내용은 공식 Document 를 참고하세요.

- 바이너리 설치 : https://gogs.io/docs/installation/install_from_binary

- 소스파일 설치 : https://gogs.io/docs/installation/install_from_source

# wget https://dl.gogs.io/0.13.0/gogs_0.13.0_linux_amd64.tar.gz
# tar xvzf gogs_0.13.0_linux_amd64.tar.gz
# cd gogs
# ./gogs web .

2024/02/05 12:51:04 [ WARN] Custom config "/root/gogs/custom/conf/app.ini" not found. Ignore this warning if you're running for the first time
2024/02/05 12:51:04 [TRACE] Log mode: Console (Trace)
2024/02/05 12:51:04 [ INFO] Gogs 0.13.0
2024/02/05 12:51:04 [TRACE] Work directory: /root/gogs
2024/02/05 12:51:04 [TRACE] Custom path: /root/gogs/custom
2024/02/05 12:51:04 [TRACE] Custom config: /root/gogs/custom/conf/app.ini
2024/02/05 12:51:04 [TRACE] Log path: /root/gogs/log
2024/02/05 12:51:04 [TRACE] Build time: 2023-02-25 02:30:34 UTC
2024/02/05 12:51:04 [TRACE] Build commit: 8c21874c00b6100d46b662f65baeb40647442f42
2024/02/05 12:51:04 [ INFO] Run mode: Development
2024/02/05 12:51:04 [ INFO] Available on http://localhost:3000/

3000 포트가 열리면서 관리 web 콘솔 접근이 가능해졌습니다.

웹브라우저를 이용해 접근합니다.

예) http://115.68.248.195:3000

2) 설치하기

위 URL 로 접근하면 Gogs 설치를 위한 여러가지 설정 항목이 출력됩니다.

기본값에서 아래 내용만 추가하여 설치를 진행합니다.

모두 기본값으로 두고, 아래 파란색 글자만 변경 또는 입력하였습니다.

- 데이터베이스 유형 : MySQL
- 호스트 : 127.0.0.1:3306
- 사용자 : gogs
- 비밀번호 : 12345678
- 데이터베이스 이름 : gogs

- 애플리케이션 이름 : Gogs
- 저장소 최상위 경로 : /root/gogs-repositories
- 데몬 사용자 계정 : root
- 도메인 : git.sysdocu.kr
- SSH 포트 : 22 (내장 SSH 서버 사용 : 체크 해제)
- HTTP 포트 : 3000
- 애플리케이션 URL : http://115.68.248.195:3000/
- 로그 경로 : /root/gogs/log (콘솔 모드 활성화 : 체크 해제)
- Default Branch : master

- 추가설정 없음

맨 하단의 [Gogs 설치하기] 버튼을 눌러 설치를 합니다.

버튼은 한번만 누르고 잠시 기다려야 합니다.

[에러]

페이지를 찾을 수 없다는 메세지가 출력될때 URL 이 http://localhost:3000/user/login 연결 시도 중이였다면, '애플리케이션 URL' 을 수정하지 않은 것이므로, 접근 가능한 서버 IP 주소로 변경하여 다시 접근하면 됩니다.

페이지가 잘 열렸다면, 계정 생성 후 로그인합니다.

3. 사용하기

1) 저장소 만들기

대시보드 우측에 내 저장소의 '+' 버튼을 눌러 저장소를 추가합니다.

테스트 용이므로 저장소 이름만 입력해보겠습니다.

- 저장소 이름 : sample

[저장소 만들기] 버튼을 눌러 생성합니다.

다음과 같이 저장소 주소가 확인되었습니다.

http://115.68.248.195:3000/sysdocu/sample.git

2) 파일 업로드

Client PC (Ubuntu 22.04) 에서 사용하는 방법입니다.

파일을 업로드 할때 git 명령어가 필요하므로 서버에서 설치한 방법대로 설치합니다.

# apt -y install git

# git version
git version 2.34.1

디렉토리를 만들고 PHP 샘플 파일을 생성합니다.

# mkdir php-sample

# cd php-sample

# echo "<?php
echo 'Good Job !!';
phpinfo();
?>" > index.php

용량 큰 파일도 전송이 잘 되는지 확인하기위해 한개 생성합니다.

# dd if=/dev/zero of=file.bin bs=100M count=10
10+0 레코드 들어옴
10+0 레코드 나감
1048576000 bytes (1.0 GB, 1000 MiB) copied, 3.40629 s, 308 MB/s

로컬 main 저장소를 초기화 합니다.

# git init -b main

/root/php-sample/.git/ 안의 빈 깃 저장소를 다시 초기화했습니다

원격 저장소를 origin 이라는 이름으로 로컬 저장소에 추가 합니다.

# git remote add origin http://115.68.248.195:3000/sysdocu/sample.git

[참고] --------------------

다른 저장소로 연결하기 위해 현재 원격 저장소를 확인하고 해제하는 명령어 입니다.

- 연결 상태 확인 명령어 : git remote 또는 git remote -v

- 연결 해제 명령어 : git remote remove {해제하려는 원격 저장소 이름}

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

현재 작업 디렉토리의 모든 변경 사항을 로컬 저장소의 스테이징 영역 (Staging Area) 에 추가합니다.

변경된 파일들을 Git 이 추적하도록 표시하고, 이후에 이 변경 사항들을 커밋에 포함시킬 수 있습니다.

아직 Git 서버로 전송된 것은 아니며, 커밋 이후에 git push 명령을 사용하여 원격 서버로 변경 사항을 전송할 수 있습니다.
. 은 현재 디렉토리의 모든 파일을 의미합니다.

# git add .

스테이징 영역에 추가된 변경 사항들을 실제로 저장소에 기록 (commit) 합니다.
-m 옵션을 이용하여 커밋에 대한 간략한 설명을 입력합니다.
커밋 메시지는 커밋의 의도를 알 수 있도록 명확하게 작성하는 것이 좋습니다.

# git commit -m "First commit"

[main (최상위-커밋) f78689e] First commit
 2 files changed, 4 insertions(+)

 create mode 100644 file.bin
 create mode 100644 index.php

git push 명령어로 로컬 저장소의 변경 사항을 원격 저장소로 전송합니다.
-u 는 원격 저장소의 브랜치 (분기) 에 로컬 브랜치를 연결하는 옵션입니다. 옵션 사용 이후에는 간단히 git push 만 사용하여 변경 사항을 전송할 수 있습니다.
아래는 로컬 main 브랜치의 변경 내용을 origin 이라는 원격 저장소에 업로드하는 명령입니다.

# git push -u origin main
오브젝트 나열하는 중: 4, 완료.
오브젝트 개수 세는 중: 100% (4/4), 완료.
Delta compression using up to 8 threads
오브젝트 압축하는 중: 100% (2/2), 완료.
오브젝트 쓰는 중: 100% (4/4), 995.59 KiB | 124.45 MiB/s, 완료.
Total 4 (delta 0), reused 1 (delta 0), pack-reused 0
Username for 'http://115.68.248.195:3000': sysdocu
Password for 'http://sysdocu@115.68.248.195:3000': 
To http://115.68.248.195:3000/sysdocu/sample.git
 * [new branch]      main -> main
'main' 브랜치가 리모트의 'main' 브랜치를 ('origin'에서) 따라가도록 설정되었습니다.

파일이 업로드 되었으며, Gogs 웹 콘솔에서도 업로드 된 확인이 가능합니다.

K3S 는 경량 Kubernetes (클러스터 형태의 컨테이너 오케스트레이션) 구현체로, 리소스 사용이 적고 더 빠르게 구동됩니다.

때문에 Korifi 를 테스트 해보기 위한 사용자는 K3S 에서 구현해보고, 실제 서비스 구현 또는 대규모 분산 시스템을 원할 경우 다른 포스팅 (https://sysdocu.tistory.com/1904) 을 참고하여 구축하시기 바랍니다.

여기에서는 Korifi 0.7.1 / 0.10.0 / 0.11.0 세가지 방법으로 구분하여 작성하였으며, 꼭 필요한 명령어만 기술하고 설명을 최소화 하였습니다.

1. 사전 작업

Korifi 설치 및 사용에 필요한 명령어와 운영환경 K3S 를 우선 설치 합니다.

1) Kubectl

# curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
# install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl

2) 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

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

# tar xvzf helm-v3.12.0-linux-amd64.tar.gz
# mv linux-amd64/helm /usr/local/bin/

4) K3S 설치

# curl -sfL https://get.k3s.io | sh -s - --disable traefik --write-kubeconfig-mode 644

# export KUBECONFIG="/etc/rancher/k3s/k3s.yaml"

앞으로 SSH 접속시마다 자동으로 환경이 로드 되도록 하면 편리합니다.

# echo 'export KUBECONFIG="/etc/rancher/k3s/k3s.yaml"' >> ~/.bashrc

2. 설치 진행

1) 환경변수 설정

# export ROOT_NAMESPACE="cf"

# export KORIFI_NAMESPACE="korifi"

# export ADMIN_USERNAME="cf-admin"

# export BASE_DOMAIN="az1.sysdocu.kr"

2) Cert Manager 설치

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

3) Kpack 설치

# kubectl apply -f https://github.com/buildpacks-community/kpack/releases/download/v0.13.2/release-0.13.2.yaml

4) 네임스페이스 생성
# 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

5) Contour 설치

(Korifi 0.7.1 / 0.10.0 설치시)

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

(Korifi 0.11.0 설치시)

정적 프로비저닝 방법으로 contour 를 설치합니다.
# export GATEWAY_CLASS_NAME="contour"
# kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.0.0/experimental-install.yaml
# kubectl apply -f - <<EOF
kind: GatewayClass
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: $GATEWAY_CLASS_NAME
spec:
  controllerName: projectcontour.io/gateway-controller
EOF

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

마지막 파일에 사용하지 않는 example 등의 이름으로 설치되는 요소가 있지만, 동작 여부만 확인할 예정이므로 그대로 설치하였습니다.

6) DNS 설정

본 매뉴얼은 서버 한대로 구성하는 것이므로 DNS 에서 아래 사용할 도메인의 IP 를 현재 서버 IP 로 셋팅해주어야 합니다.

- API 서버 도메인 : api.az1.sysdocu.kr - 115.68.248.245

- 애플리케이션이 사용할 도메인 : *.apps.az1.sysdocu.kr - 115.68.248.245

7) Secret 생성

여기에서는 실제 사용 가능한 Repository 정보를 입력해야 합니다.

# 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"

8) Korifi 설치

여기에서도 실제 사용 가능한 Repository 정보를 입력해야 합니다.

(Korifi 0.7.1 설치시)

# helm install korifi https://github.com/cloudfoundry/korifi/releases/download/v0.7.1/korifi-0.7.1.tgz \
    --namespace="$KORIFI_NAMESPACE" \
    --set=global.generateIngressCertificates=true \
    --set=global.rootNamespace="$ROOT_NAMESPACE" \
    --set=global.containerRegistrySecret="image-registry-credentials" \
    --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=kpackImageBuilder.builderRepository="registry.az1.sysdocu.kr:5000/kpack-builder" \
    --wait

(Korifi 0.10.0 설치시)

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

(Korifi 0.11.0 설치시)

# helm install korifi https://github.com/cloudfoundry/korifi/releases/download/v0.11.0/korifi-0.11.0.tgz \
    --namespace="$KORIFI_NAMESPACE" \
    --set=adminUserName="$ADMIN_USERNAME" \
    --set=defaultAppDomainName="apps.$BASE_DOMAIN" \
    --set=generateIngressCertificates="true" \
    --set=api.apiServer.url="api.$BASE_DOMAIN" \
    --set=containerRepositoryPrefix="registry.az1.sysdocu.kr:5000/" \
    --set=kpackImageBuilder.clusterStackBuildImage="paketobuildpacks/build-jammy-full" \
    --set=kpackImageBuilder.clusterStackRunImage="paketobuildpacks/run-jammy-full" \
    --set=kpackImageBuilder.builderRepository="registry.az1.sysdocu.kr:5000/kpack-builder" \
    --set=networking.gatewayClass="$GATEWAY_CLASS_NAME" \
    --wait

9) CF 관리자 계정 생성

CF 관리자 계정 cf-admin 을 추가합니다.

생성 명령 절차가 길어 명령어 앞에 프롬프트를 제거하였습니다. 아래 명령을 전체 복사하여 실행하면 됩니다.

cf-admin 이 아닌 계정명으로 변경하고 싶을 경우 아래 내용에서 cf-admin 문자열을 다른 계정 ID 로 치환하여 실행하면 됩니다.

openssl genrsa -out cf-admin.key 2048
openssl req -new -key cf-admin.key -out cf-admin.csr -subj "/CN=cf-admin"
tmp=`cat cf-admin.csr | base64 | tr -d "\n"`
cat <<EOF | kubectl apply -f -
apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: cf-admin
spec:
  request: $tmp
  signerName: kubernetes.io/kube-apiserver-client
  #expirationSeconds: 604800 # 1주일 (옵션 미사용시 : 1년 유효)
  usages:
    - client auth
EOF
kubectl certificate approve cf-admin
kubectl get csr cf-admin -o jsonpath='{.status.certificate}'| base64 -d > cf-admin.crt
kubectl create role developer --verb=create --verb=get --verb=list --verb=update --verb=delete --resource=pods
kubectl create rolebinding developer-binding-cf-admin --role=developer --user=cf-admin
kubectl config set-credentials cf-admin --client-key=cf-admin.key --client-certificate=cf-admin.crt --embed-certs=true
kubectl config set-context cf-admin --cluster=kubernetes --user=cf-admin

3. 애플리케이션 배포

1) Cloud Foundry API 로그인

# cf api https://api.$BASE_DOMAIN --skip-ssl-validation

# cf auth cf-admin

2) 조직 및 공간 생성

# cf create-org org1

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

3) 애플리케이션 배포

준비된 소스 코드가 없다면, 공개된 샘플 소스 코드를 다운로드하고 배포해 봅니다.

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

# cd sample-web-apps/java

# cf push java1

배포할때 특이점은, Korifi 0.7.1 의 경우 동작 프로세스가 화면에 잘 출력되는 반면, 0.10.0 부터는 처리과정 출력 없이 마지막에 인스턴스를 시작하는 단계에서부터 출력되므로, 중간에 멈춘것 같은 느낌이 들지만 인내를 가지고 기다려 보시기 바랍니다. timeout 시간이 15분으로, 그 전까지 배포되지 않을 경우 에러가 출력됩니다.

4) 애플리케이션 확인

배포된 애플리케이션에 접근합니다.

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

Hello, World!
Java Version: 17.0.10

GLab 은 GitLab 의 기능을 웹브라우저를 통하지 않고도 터미널에서 사용할 수 있게 해주는 GitLab CLI 도구입니다.

GitLab API 를 이용하여 프로젝트, 이슈, 병합 요청 등을 터미널에서 쉽게 관리하고 조작할 수 있습니다.

본 매뉴얼 내용은 Ubuntu 22.04 환경에서 테스트 되었습니다.

- GitLab CE 설치 : https://sysdocu.tistory.com/1892

- GitLab CLI : https://gitlab.com/gitlab-org/cli

1. GLab 설치

(Client PC 에서)

작성일 기준 GLab 배포 버전은 1.36.0 을 설치 합니다.

- 버전 정보 : https://gitlab.com/gitlab-org/cli/-/releases

- 우분투 환경이므로 deb 파일을 다운로드, 설치합니다.

# wget https://gitlab.com/gitlab-org/cli/-/releases/v1.36.0/downloads/glab_1.36.0_Linux_x86_64.deb

# dpkg -i glab_1.36.0_Linux_x86_64.deb

추후 사용을 위해 gitlab-runner 바이너리 파일도 다운로드 합니다.

gitlab-runner 는 GitLab CI/CD 를 실행하기 위한 러너 서비스를 관리하기 위한 명령어입니다.

# curl -L --output /usr/local/bin/gitlab-runner "https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64"

# chmod 755 /usr/local/bin/gitlab-runner

2. 로그인

1) HTTPS 활성화

(GitLab Server 에서)

GitLab 에서 Let's Encrypt 를 이용해 SSL 인증서를 다운로드 받고 자동으로 HTTPS 포트를 열 수 있습니다.
GitLab 설정 파일을 열고 아래 옵션을 활성화 한다음 값을 입력해줍니다.
# vi /etc/gitlab/gitlab.rb

변경된 설정을 적용하면 HTTPS 포트가 오픈됩니다.
# gitlab-ctl reconfigure
# netstat -nltp |grep 443
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      238181/nginx: maste 

2) 로그인

(Client PC 에서)

GitLab 서버에 인증을 받아야 이용이 가능합니다.

# glab auth login
? What GitLab instance do you want to log into?  [Use arrows to move, type to filter]
  gitlab.com
> GitLab Self-hosted Instance

여기에서 키보드 방향키를 위, 아래로 이동할 수 있습니다. 'GitLab Self-hosted Instance' 를 선택합니다.

GitLab hostname 입력란에 연결하려는 GitLab 호스트명을 입력합니다.

API hostname 입력란에 연결하려는 API 호스트명을 입력합니다.

로그인 방식을 묻는데, 여기에서 Token 을 선택합니다.

개인 액세스 토큰을 생성할 수 있는 URL 이 출력되는데, 웹브라우저로 접속하여 토큰을 생성하고 복사합니다.

> https://git.sysdocu.kr/-/user_settings/personal_access_tokens?scopes=api,write_repository

'Add new token' 클릭 > Token name 입력하고, 테스트중이므로 하단의 Select scopes 는 모두 체크하고 토큰을 생성합니다.

그러면, 토큰이 생성되며 'Your new project access token' 항목 보이고, 눈 모양 옆의 아이콘을 클릭하면 토큰이 클립보드에 복사됩니다.

다시 CLI 로 돌아옵니다.

토큰을 붙여넣고, git 과 API 프로토콜의 연결 방식은 HTTPS 를 선택합니다.

전체적인 로그인 절차는 아래와 같습니다.

# glab auth login
? What GitLab instance do you want to log into? GitLab Self-hosted Instance
? GitLab hostname: git.sysdocu.kr
? API hostname: git.sysdocu.kr
- Logging into git.sysdocu.kr
? How would you like to login? Token

Tip: you can generate a Personal Access Token here https://git.sysdocu.kr/-/profile/personal_access_tokens?scopes=api,write_repository
The minimum required scopes are 'api' and 'write_repository'.
? Paste your authentication token: **************************
? Choose default git protocol HTTPS
? Choose host API protocol HTTPS
- glab config set -h git.sysdocu.kr git_protocol https
✓ Configured git protocol
- glab config set -h git.sysdocu.kr api_protocol https
✓ Configured API protocol
✓ Logged in as root

root 사용자로 로그인 성공 했습니다.

3. 사용 예

간단한 몇개의 명령을 예시로 제공합니다.

아래 내용 외에 더 자세한 명령은 공식 Documents 를 참고하세요.

[에러] --------------------

예제 명령 수행시 직접 구축한 GitLab 서버가 아닌 gitlab.com 을 참조하게 될 경우

GET https://gitlab.com/api/v4/user: 401 {message: 401 Unauthorized}

아래와 같이 현재 인증된 GitLab 호스트를 출력해보고,

# glab auth status

설정 파일을 열어 기본 설정값을 수정하고, 필요없는 호스트를 삭제합니다.

# vi .config/glab-cli/config.yml

- 수정할 곳 : 위 전체 옵션

  ㄴ git_protocol: https

  ㄴ host: git.sysdocu.kr

- 삭제할 곳 : 아래 hosts 항목의 gitlab.com 도메인 영역

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

1) GitLab 리포지토리를 로컬에 복제
# glab repo clone {user}/{repository}

2) GitLab 리포지토리의 이슈 목록 표시
# glab issue list

3) GitLab 리포지토리의 파이프라인 목록 표시
# glab pipeline list

4) GitLab 리포지토리의 머지 리퀘스트(MR) 목록 표시

# glab mr list

5) GitLab 리포지토리에 새 릴리스 생성
# glab release create v1.0

6) GitLab 리포지토리의 레이블 목록 표시

# glab label list

7) GLab 구성 변경

# glab config set editor vim

8) GitLab 스니펫 관리를 위한 명령
# glab snippet create -f file.txt

9) GLab 명령어에 대한 도움말 표시
# glab help