Rocky Linux 9 / Ubuntu 22.04

# timedatectl set-timezone Asia/Seoul

Rocky Linux 9 에서 Docker 설치하는 방법을 기술하였습니다.

1. Docker 설치

# dns -y update

# dnf config-manager --add-repo=https://download.docker.com/linux/centos/docker-ce.repo

# dnf -y install docker-ce docker-ce-cli containerd.io

# systemctl enable --now docker

# docker --version

Docker version 26.0.0, build 2ae903e

2. Docker compose 설치

# curl -L "https://github.com/docker/compose/releases/download/v2.26.0/docker-compose-linux-x86_64" -o /usr/local/bin/docker-compose
# chmod +x /usr/local/bin/docker-compose
# docker-compose --version
Docker Compose version v2.26.0

이미지 용량이 커서 별도의 디스크로 저장하고자 할 경우에 Docker 설정 파일에서 디렉토리를 변경해 주어야 합니다.

물론 같은 디렉토리로 마운트하여 사용이 가능하지만, 여기에서는 추가한 디스크의 마운트 디렉토리로 변경하는 방법을 안내합니다.

1. HDD 추가

SATA 4TB 디스크의 파티션 및 파일시스템을 생성하고 /data 디렉토리로 마운트 해 두었습니다. (방법 생략)

2. Docker 중지

Docker 가 실행중일 경우 중지합니다.

# systemctl stop docker

3. 기존 데이터 복사

신규 디렉토리의 퍼미션을 원래 디렉토리와 동일하게 합니다.

# chmod 710 /data

기존에 사용하던 docker 디렉토리를 신규 디렉토리 아래로 복사해 넣습니다.

# cp -arp /var/lib/docker /data/

4. Docker 설정 변경

Docker 설정 파일을 열고 Docker data root directory 를 변경합니다.

파일이 없는 경우 생성하면 됩니다.

# vi /etc/docker/daemon.json

5. Docker 실행

변경된 디렉토리를 적용하기 위해 Docker 데몬을 가동합니다.

# systemctl start docker

전에 사용하던 이미지가 있었다면, 그대로 출력이 잘 되는지 확인합니다.

# docker images

[증상]

터미널을 열고 방향키를 움직이면 커서가 움직이거나 히스토리가 보이지 않고 ^]]A 등의 문자가 찍힙니다.

이는 sh 쉘의 특징입니다.

[해결]

대부분의 OS 는 bash 쉘을 가지고 있으므로 bash 쉘로 변경하면 해결 됩니다.

# bash

편리하게 사용하도록 추가 조치를 합니다.

서버 로그인할때 마다 자동으로 bash 쉘 환경으로 적용되도록 기본 쉘을 변경합니다.

# chsh -s /bin/bash

또는, /etc/passwd 파일에서 /bin/bash 쉘로 수정하면 됩니다.

* 참고

사용 가능한 쉘 종류 확인 명령어 : cat /etc/shells

< IwinV VDI 상품 전용 >

XRDP 를 구성해서 원격접속 가능하도록 하는 방법입니다.

# apt -y update

# apt -y install xrdp xorgxrdp
# useradd -m sysdocu -p $(openssl passwd 12345678)
# usermod -aG sudo sysdocu

# sed -i '11 a unset DBUS_SESSION_BUS_ADDRESS' /etc/xrdp/startwm.sh
# sed -i '12 a unset XDG_RUNTIME_DIR' /etc/xrdp/startwm.sh

# systemctl restart xrdp

이제 XRDP 포트 (3389) 를 이용해 원격 접근이 가능합니다.

본 내용은 다른 포스팅 (Korifi 설치 매뉴얼) 내용이 생략되었으며, 설치가 다 되었다는 가정하에 설명되었습니다.

Openstack magnum 으로 생성한 Kubernetes 에서는 보안상 ca.key 파일 (CA 루트 인증서) 을 제공하지 않습니다.

그래서 Kubernetes API 계정 추가 필요시 key, crt 파일은 Openstack 에서 생성하고 Kubernetes 에 등록해 주어야 합니다.

[ Kubernetes API 계정 생성 ]

(Openstack 작업 생략)

Openstack 에서 생성한 cf-admin 이라는 계정의 key, crt (pem) 파일을 콘솔로 가져와 Kubernetes 사용자로 등록합니다.

# kubectl config set-credentials cf-admin --client-key=cf-admin.key --client-certificate=cf-admin.pem --embed-certs=true
# kubectl config set-context cf-admin --cluster=kubernetes --user=cf-admin

[ 콘솔 다중 사용자 작업 ]

콘솔 (작업 서버) 에서 여러개의 Kubernetes config 파일을 가지고 있을 경우, 여러 사용자가 동시에 CF 명령을 사용하게 되면, ~/.cf/config.json 파일의 API 및 Kubernetes API 계정 정보가 섞여서 제대로 명령 진행이 되지 않을 수 있습니다.

이때, 환경 설정 파일의 디렉토리를 지정함으로써 설정 파일이 겹치는 문제를 해결 할 수 있습니다.  

# mkdir /root/test
# HOME=/root/test cf api https://api1.$BASE_DOMAIN --skip-ssl-validation
# HOME=/root/test cf login
# HOME=/root/test cf push java1 -p /root/sample-web-apps/java/

처음 명령 (API 연결) 을 실행할 때 /root/test/.cf 디렉토리가 생성되며, CF 에 관련된 기본 환경 설정 파일이 자동으로 생성됩니다.

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 포트 접근을 허용하면, 기본적인 메일 송수신 설정은 완료가 됩니다.