JavaScript 의 Alert 와 같이 리눅스 Desktop 사용시 화면 중앙에 메세지를 띄우는 방법입니다.

첫번재 방법

# apt -y install zenity

# zenity --info --title="알림" --text="Sysdocu 프로세스가 실행 중입니다."

두번째 방법

# apt install libnotify-bin

# notify-send "알림" "Sysdocu 프로세스가 실행 중입니다."

디스크 부족 등의 이유로 디렉토리를 변경해야 할 경우가 있습니다.

설정파일을 통해 간단히 변경이 가능합니다.

1. 확인

현재 Docker 기본 root 디렉토리를 확인합니다.

# docker info |grep Root
 Docker Root Dir: /var/lib/docker

2. 디렉토리 설정 변경

Docker 의 설정 파일을 수정하여 디렉토리를 변경할 수 있습니다.

아래는 기본 디렉토리를 /data 로 변경한 예 입니다.

(파일이 없을경우 생성하면 됩니다)

# vi /etc/docker/daemon.json

3. 적용하기

Docker 데몬을 재시작 하면 변경한 설정이 적용되고, 디렉토리를 조회하면 새로 구성된 파일이 생성 되었음을 알 수 있습니다.

# systemctl restart docker

# ls -al /data
total 52
drwx--x--- 12 root root 4096 Apr  1 05:56 .
drwxr-xr-x 20 root root 4096 Mar 31 23:30 ..
drwx--x--x  4 root root 4096 Apr  1 05:56 buildkit
drwx--x---  2 root root 4096 Apr  1 05:56 containers
-rw-------  1 root root   36 Apr  1 05:56 engine-id
drwx------  3 root root 4096 Apr  1 05:56 image
drwxr-x---  3 root root 4096 Apr  1 05:56 network
drwx--x---  3 root root 4096 Apr  1 05:56 overlay2
drwx------  4 root root 4096 Apr  1 05:56 plugins
drwx------  2 root root 4096 Apr  1 05:56 runtimes
drwx------  2 root root 4096 Apr  1 05:56 swarm
drwx------  2 root root 4096 Apr  1 05:56 tmp
drwx-----x  2 root root 4096 Apr  1 05:56 volumes

Ubuntu 22.04 에서 Apache2 와 Tomcat9 를 연동하는 방법입니다.

본 매뉴얼의 목적은 PHP 와 JSP 를 함께 사용하용하는데 있습니다.

설명은 최소화 하고 명령어 실행 절차만 기록하였습니다.

1. Apache 설치

# apt -y update

# apt -y install apache2

2. PHP 설치

# apt -y install php libapache2-mod-php php-mysqli

3. Tomcat 설치

# apt -y install default-jdk tomcat9 tomcat9-admin tomcat9-user

4. Mod JK 설치

Apache Tomcat 연결 모듈을 설치합니다.

# apt -y install libapache2-mod-jk

5. Apache 설정

아래 속성 파일을 생성합니다.

# vi /etc/apache2/workers.properties

생성한 파일을 지정합니다.

# vi /etc/apache2/mods-available/jk.conf

VirtualHost 설정을 변경합니다.

(Tomcat 웹소스 디렉토리로 변경, Tomcat 처리할 확장자 추가)

# vi /etc/apache2/sites-available/000-default.conf

Tomcat 웹소스 디렉토리에 접근할 수 있도록 디렉토리 옵션을 추가합니다.

# vi /etc/apache2/apache2.conf

6. Tomcat 설정

# vi /var/lib/tomcat9/conf/server.xml

Apache2 와 Tomcat9 를 재시작하여 설정을 적용합니다.

# systemctl restart apache2

# systemctl restart tomcat9

7. 테스트

테스트를 위해 PHP, JSP 샘플 파일을 생성하고 접속해 봅니다.

# cd /var/lib/tomcat9/webapps/ROOT/

# vi index.php

# vi index.jsp

서버 도메인이나 IP 로 생성한 파일에 접근해 봅니다.

# curl http://sysdocu.kr/index.php

Good Job, PHP !!

# curl http://sysdocu.kr/index.jsp

Good Job, JSP !!<br>

The current time is: Fri Mar 29 14:05:22 KST 2024

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

[증상]

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

이는 sh 쉘의 특징입니다.

[해결]

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

# bash

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

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

# chsh -s /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) 를 이용해 원격 접근이 가능합니다.

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 로 연결시키면 됩니다.

- 여러대로 구성해서 사용중이라면 master 서버의 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 웹페이지에서 수동으로 실행해줍니다.