여기에서는 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 웹페이지에서 수동으로 실행해줍니다.

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

GitLab은 Git 저장소 관리, CI/CD, 이슈 트래킹, 웹 IDE 등의 기능을 제공하는 자체 호스팅 가능한 플랫폼입니다. 이를 사용하여 소스 코드를 관리하고 프로젝트를 효율적으로 개발할 수 있습니다.

여기에서는 Ubuntu 22.04 서버에서 GitLab 을 설치하는 가이드를 제공합니다. 이 가이드는 기본적인 설치 방법을 제공하며, 실제 프로덕션 환경에서는 보안 및 성능을 위한 추가 구성이 필요할 수 있습니다.

- 공식 사이트 : https://about.gitlab.com/

1. GitLab 설치

환경을 최신으로 유지합니다.

# apt -y update

# apt -y upgrade

GitLab 에 필요한 패키지를 우선 설치합니다.

# apt -y install curl openssh-server ca-certificates tzdata perl

GitLab 패키지 리포지토리를 추가합니다.

여기에서 추가하는 버전은 CE (Community Edition) 입니다.

그리고 우분투 환경에서 테스트 하기때문에 파일명에 deb 문자가 포함된 스크립트로 추가합니다.
# curl -L "https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh" | sudo bash

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  6865  100  6865    0     0  18730      0 --:--:-- --:--:-- --:--:-- 18756
Detected operating system as Ubuntu/jammy.
Checking for curl...
Detected curl...
Checking for gpg...
Detected gpg...
Running apt-get update... done.
Installing apt-transport-https... done.
Installing /etc/apt/sources.list.d/gitlab_gitlab-ce.list...done.
Importing packagecloud gpg key... done.
Running apt-get update... done.

The repository is setup! You can now install packages.

GitLab CE (Community Edition) 를 설치합니다.

아래와 같이 사용할 도메인을 입력하여 명령을 실행합니다.

도메인은 DNS 에서 GitLab 서버 IP 로 연결해 놓아야 합니다.

# EXTERNAL_URL="http://git.sysdocu.kr" apt -y install gitlab-ce

웹 인터페이스에 접속하기 위해 패스워드를 확인합니다.

아래 패스워드는 24시간 유효합니다.

# cat /etc/gitlab/initial_root_password |grep Password:
Password: q2RIma952BAKFM0xJQKvBTD6009m8cwuiHyxtcjYAUE=

* 참고

패스워드 파일이 없거나 분실하여 재설정이 필요할때는 아래 명령을 사용합니다.

# gitlab-rake "gitlab:password:reset[root]"
Enter password: (신규 패스워드)
Confirm password: (신규 패스워드)
Password successfully updated for user with username root.

웹브라우저를 이용해 GitLab 웹 인터페이스에 접속합니다.

- http://git.sysdocu.kr
- ID : root

- PW : 위에 출력된 Password

* 웹페이지 접근이 되지 않을때

로컬에서 이미 포트를 사용하고 있어서 포트를 변경해야 하거나, 도메인이 아닌 IP 로 접근해야 할 수도 있습니다.

설정 파일에서 접속 URL 에 사용하지 않는 포트를 추가하여 재설정하고 접속하면 됩니다.

# vi /etc/gitlab/gitlab.rb

external_url 'http://git.sysdocu.kr:8090'    // 이렇게 사용하지 않는 포트 추가 후 아래 명령으로 재설정

# gitlab-ctl reconfigure

이제 웹페이지 접근이 될 것입니다.

처음 로그인시 상단에 아래와 같은 경고메세지가 출력됩니다.

"가입 제한을 확인합니다. 당신의 GitLab 인스턴스는 누구나 계정을 등록할 수 있도록 하는데, 이것은 공개적으로 직면한 GitLab 인스턴스의 보안 위험입니다. 공용 사용자가 계정에 등록하지 않을 것으로 예상되는 경우 신규 가입을 비활성화해야 합니다."

[ Deactivate ]  [ Acknowledge ]

여기에서 허용한 사용자만 이용할 수 있게 할 예정이므로, 'Deactivate' 버튼을 눌러줍니다.

그러면 화면이 'Sign-up restrictions' 항목으로 이동되는데 그 중에서 아래 내용만 변경하고 [Save changes] 버튼을 눌러 저장합니다.

- Sign-up enabled : 체크 해제

기본 설정된 패스워드가 길어 불편하므로 아래 메뉴를 찾아 root 패스워드를 변경하도록 합니다.

- 좌측 상단 '동그란 프로필 이미지' 클릭 > Preferences 클릭 > 좌측 메뉴에서 Password 클릭

변경 후에는 자동으로 로그아웃이 되며, 다시 로그인 하였을 경우 관리자 초기 페이지가 출력됩니다.

* 참고

1) 설정 파일 : /etc/gitlab/gitlab.rb

    수정 후 반영 : # gitlab-ctl reconfigure

2) GitLab 서비스 재시작 명령 : # gitlab-ctl restart

2. 프로젝트 생성

root 사용자로 로그인 한 경우 다음과 같은 메뉴를 이용할 수 있습니다.

- Create a project

- Create a group

- Add people

- Configure GitLab

이제 Repository 를 만들면 웹 상에서 소스 파일을 만들거나 업로드 할 수 있습니다.

본 매뉴얼에서는 공개 Repository 를 생성하고, CLI 를 통해 소스파일을 업로드, 증분 데이터 업로드 하는 순서로 진행해 보겠습니다.

'Create a project > Create blank project' 메뉴를 순서대로 선택하고 아래 필수 항목만 입력하여 프로젝트를 생성합니다.

나머지는 기본값으로 둡니다.

- Project name : sample

- Project URL & Project slug : http://git.sysdocu.kr/root/sample

- Visibility Level : Private

3. 파일 업로드

1) PC 에서 파일 업로드

로컬 PC 에서 git 명령어를 사용하여 Repository 에 파일을 추가 합니다.

git 명령이 없을 경우 Git 패키지를 설치해야 합니다.

(실습 PC : Ubuntu 22.04)

# apt -y install git

파일을 업로드 하기 위해 소스 파일이 있는 곳으로 이동합니다.

필자는 해당 디렉토리에 업로드 할 샘플 파일을 미리 만들어 두었습니다.

# cd php-sample

# ls -al
합계 1024032
drwxr-xr-x  2 root root      4096  1월 19 16:45 .
drwx------ 25 root root      4096  1월 19 16:45 ..
-rw-r--r--  1 root root 104857600  1월 19 16:44 file01.bin
-rw-r--r--  1 root root 104857600  1월 19 16:44 file02.bin
-rw-r--r--  1 root root 104857600  1월 19 16:44 file03.bin
-rw-r--r--  1 root root 104857600  1월 19 16:44 file04.bin
-rw-r--r--  1 root root 104857600  1월 19 16:44 file05.bin
-rw-r--r--  1 root root 104857600  1월 19 16:44 file06.bin
-rw-r--r--  1 root root 104857600  1월 19 16:44 file07.bin
-rw-r--r--  1 root root 104857600  1월 19 16:44 file08.bin
-rw-r--r--  1 root root 104857600  1월 19 16:44 file09.bin
-rw-r--r--  1 root root 104857600  1월 19 16:44 file10.bin
-rw-r--r--  1 root root        44  1월 19 16:45 index.php

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

# git init -b main

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

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

# git remote add origin http://git.sysdocu.kr/root/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 (최상위-커밋) b3e50c2] First commit

 11 files changed, 4 insertions(+)
 create mode 100644 file01.bin
 create mode 100644 file02.bin
 create mode 100644 file03.bin
 create mode 100644 file04.bin
 create mode 100644 file05.bin
 create mode 100644 file06.bin
 create mode 100644 file07.bin
 create mode 100644 file08.bin
 create mode 100644 file09.bin
 create mode 100644 file10.bin
 create mode 100644 index.php

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

# git push -u origin main

Username for 'http://git.sysdocu.kr': root
Password for 'http://root@git.sysdocu.kr': (계정 비밀번호 입력)
오브젝트 나열하는 중: 5, 완료.
오브젝트 개수 세는 중: 100% (5/5), 완료.
Delta compression using up to 8 threads
오브젝트 압축하는 중: 100% (3/3), 완료.
오브젝트 쓰는 중: 100% (4/4), 99.93 KiB | 157.00 KiB/s, 완료.
Total 4 (delta 0), reused 0 (delta 0), pack-reused 0
To http://git.sysdocu.kr/root/sample.git
   91ee794..4c5d008  main -> main
'main' 브랜치가 리모트의 'main' 브랜치를 ('origin'에서) 따라가도록 설정되었습니다.

[에러 발생시] --------------------

error: 레퍼런스를 'http://git.sysdocu.kr/root/sample.git'에 푸시하는데 실패했습니다

이런 메세지가 출력된 경우는 원격지에는 있는 파일이, 로컬에는 없기 때문에 업데이트가 거부된 것입니다. 이 상황은 보통 처음 push 하거나 또 다른 저장소에서 같은 저장소로 push 할 때 발생합니다.

때문에 git pull 명령으로 원격지의 파일을 가져와서 로컬의 파일과 합치고, 다시 git push 하면 해결이 됩니다.

(pull 은 원격지 파일을 다운로드 하여 현재 디렉토리에 저장하므로 주의할 것)

명령어를 실행할 때 기본적으로 리베이스 (rebase) 전략을 사용하도록 설정합니다.

# git config pull.rebase true

그리고 다시 다운로드, 업로드 명령을 수행합니다.

# git pull origin main

# git push -u origin main

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

2) PC에서 증분 파일 업로드

파일을 한개 추가하고 업로드 할때, 모든 파일을 다시 업로드 하는것이 아니고 한개의 추가된 파일만 업로드 되는지 확인해 봅니다.

# cp -arp file10.bin file11.bin

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

# git add .

최근 커밋을 수정하고 새로운 커밋을 생성합니다.

# git commit -m "Second commit"

[main 1cf3b17] Second commit
 1 file changed, 1 insertion(+)
 create mode 100644 file11.bin

다시 push 를 하게되면, 추가된 file11.bin 파일만 업로드 됩니다.

이 명령은 변경된 소스 또는 새로운 소스 파일만 업로드 하며, 로컬 디스크에 삭제된 파일이 있을 경우 원격지에서도 삭제하는 동기화 명령입니다.

-u 옵션은 위에서 한번 실행했으므로, 이번에는 생략해 보겠습니다.

# git push origin main
Username for 'http://git.sysdocu.kr': root
Password for 'http://root@git.sysdocu.kr': (계정 비밀번호 입력)
오브젝트 나열하는 중: 3, 완료.
오브젝트 개수 세는 중: 100% (3/3), 완료.
Delta compression using up to 8 threads
오브젝트 압축하는 중: 100% (2/2), 완료.
오브젝트 쓰는 중: 100% (2/2), 244 바이트 | 244.00 KiB/s, 완료.
Total 2 (delta 1), reused 0 (delta 0), pack-reused 0
To http://git.sysdocu.kr/root/sample.git
   3054f87..6943ce1  main -> main

GitLab 웹페이지에서 확인해보면 새로운 파일이 업로드 된것을 확인할 수 있습니다.

또한 올려진 파일리스트를 보면, 업로드 시간이 다른것으로 확인됩니다. 이로써 추가된 파일만 업로드 했음을 알 수 있습니다.

4. 커밋 변경

1) 로그 활용

실수로 로컬 파일을 삭제하거나 잘못 수정하였을때 이전 커밋 시점으로 돌리는 방법입니다.

테스트를 위해 다시 위 예제와 동일한 상태로 만들고 진행하였습니다.

복원이 잘 되는지 확인하기 위해 로컬의 file11.bin 파일을 삭제하였습니다.

# rm file11.bin

로컬의 변경사항을 되돌리기 위해 마지막으로 Git 원격 저장소에 업로드했던 해시를 확인합니다.

(최신 일시 순으로 정렬됩니다)
# git log
commit cfefa5fede689a7004f022f711d749fe8c79bfe1 (HEAD -> main, origin/main)
Author: SYSDOCU <root@sysdocu.kr>
Date:   Tue Jan 23 08:56:08 2024 +0900

    Second commit

commit 4c5d008cec251e152b5a197a6117b7d576611003
Author: SYSDOCU <root@sysdocu.kr>
Date:   Tue Jan 23 08:54:29 2024 +0900

    First commit

commit 91ee7943e944edb6f62a65d1036fb055fbf66753
Author: Administrator <admin@example.com>
Date:   Mon Jan 22 23:53:38 2024 +0000

    Initial commit

로컬의 현재 위치 (커밋) 를 file11.bin 파일이 존재했던 시점으로 변경하면 로컬에 삭제된 파일이 복원 됩니다.

작업량이 많은 경우 더 이전의 커밋 상태로 돌아갈 수도 있습니다.

# git reset --hard cfefa5fede689a7004f022f711d749fe8c79bfe1
HEAD의 현재 위치는 cfefa5f입니다 Second commit

# ls -al
합계 1024032
drwxr-xr-x  2 root root      4096  1월 19 16:45 .
drwx------ 25 root root      4096  1월 19 16:45 ..

drwxr-xr-x  8 root root      4096  1월 23 09:03 .git
-rw-r--r--  1 root root 104857600  1월 19 16:44 file01.bin
-rw-r--r--  1 root root 104857600  1월 19 16:44 file02.bin
-rw-r--r--  1 root root 104857600  1월 19 16:44 file03.bin
-rw-r--r--  1 root root 104857600  1월 19 16:44 file04.bin
-rw-r--r--  1 root root 104857600  1월 19 16:44 file05.bin
-rw-r--r--  1 root root 104857600  1월 19 16:44 file06.bin
-rw-r--r--  1 root root 104857600  1월 19 16:44 file07.bin
-rw-r--r--  1 root root 104857600  1월 19 16:44 file08.bin
-rw-r--r--  1 root root 104857600  1월 19 16:44 file09.bin
-rw-r--r--  1 root root 104857600  1월 19 16:44 file10.bin

-rw-r--r--  1 root root 104857600  1월 19 16:44 file11.bin
-rw-r--r--  1 root root        44  1월 19 16:45 index.php

2) 스테이시 활용

경우에 따라 git stash 명령을 사용해도 됩니다. 현재 작업 디렉토리의 변경사항을 일시적으로 저장하는 기능을 수행하는데, 이는 현재 브랜치에서 아직 커밋하지 않은 변경사항이 있을 때, 브랜치를 변경하거나 다른 브랜치로 이동할 때 유용합니다.
git stash 명령을 실행하면 현재 변경된 파일들을 스태시 스택에 저장하고, 작업 디렉토리는 이전 커밋의 상태로 돌아갑니다. 스태시는 나중에 필요할 때 다시 적용할 수 있습니다.

# git stash

명령 한 번이면 이전 커밋 상태로 돌아갑니다.

5. 전체 다운로드

공개된 Git 소스를 다운로드 받을 때 많이 사용하는 방법으로, 항상 전체 파일을 다운로드 합니다.

로컬에 같은 디렉토리가 있을 경우 다운로드가 되지 않습니다.

# git clone http://git.sysdocu.kr/root/sample.git

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

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

[ Helm 을 이용한 방법 ]

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

1. 네임스페이스 확인

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

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

* 참고

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

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

2. Helm Repository 추가

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

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

추가한 Repository 를 확인합니다.

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

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

# helm search repo bitnami

(결과 생략)

3. MySQL 설치

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

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

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

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

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

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

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

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

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

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

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

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

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

https://sysdocu.tistory.com/1863

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

* 주의

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

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

# mkdir php-sample

# cd php-sample

# vi index.php

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

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

소스를 배포합니다.

# cf push php1

(결과 생략)

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

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

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

[ Kubectl 을 이용한 방법 ]

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

1. MySQL Deployment 작성 및 적용

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

# vi mysql.yaml

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

# kubectl appy -f mysql.yaml

deployment.apps/new-mysql created

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

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

NAME                                                     READY   STATUS      RESTARTS   AGE     IP             NODE                 NOMINATED NODE   READINESS GATES

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

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

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

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

https://sysdocu.tistory.com/1863

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

* 주의

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

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

# mkdir php-sample

# cd php-sample

# vi index.php

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

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

소스를 배포합니다.

# cf push php2

(결과 생략)

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

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

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

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

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

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

[ 콘솔에서 배포 ]

1. 애플리케이션 생성

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

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

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

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

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

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

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

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

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

2. 서비스 액세스

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

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

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

1) Virtual Private Cloud(VPC)

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

2) 인스턴스 설정

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

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

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

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

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

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

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

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

6. 검토

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

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

* 참고 : Laravel 소스 배포

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

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

- 문서 루트 : /public

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

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

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

1) 데이터베이스 설정

- 엔진 : mysql

- 엔진 버전 : 8.0.35

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

- 스토리지 : 5

- 사용자 이름 : sysdocu

- 암호 : 12345678

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

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

[ CLI 에서 배포 ]

1. CLI 명령어 설치

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

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

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

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

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

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

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

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

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

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

# mkdir php-sample

# cd php-sample

# vi index.php

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

# eb init

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. 애플리케이션 배포

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

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


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

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

4. 애플리케이션 삭제

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

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

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

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

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

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

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

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

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

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

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

3. 빌드팩 버전 업그레이드

빌드팩은 새로운 버전이 릴리즈 될때마다 자동으로 업그레이드 됩니다.

그래서 이를 막고자할때 위와 같이 다이제스트값으로 버전을 고정시켜 놓거나, 빌드팩에 lock 을 걸어놓으면, 새로운 빌드팩 버전이 릴리즈되어도 자동으로 업그레이드 되지 않습니다.

다이제스트값으로 버전 고정하는 방법은 위에 설명하였으므로 여기에서는 빌드팩에 lock 을 걸어놓는 방법을 설명 드립니다.

예) cf update-buildpack paketo-buildpacks/php --lock (확인중)