내 잡다한 노트

Jenkins의 Scripted Pipeline은 Groovy 언어를 기반으로 작성됩니다. Scripted Pipeline은 Jenkins Pipeline의 저수준 구문으로, Jenkins가 Groovy를 사용하여 동작하기 때문에 Scripted Pipeline은 Groovy로 작성해야 합니다. 왜 Groovy만 사용 가능한가?Jenkins의 내부 구현이 Groovy 기반Jenkins는 내부적으로 Groovy를 기반으로 동작하며, Scripted Pipeline은 이를 직접 활용하는 방식입니다.Groovy는 JVM 기반Jenkins는 Java 기반으로 동작하며, Groovy는 JVM(Java Virtual Machine) 위에서 실행되므로 호환성이 뛰어납니다. 다른 언어를 사용할 수 없는 이유는?Jenk..

Jenkinsfile은 Jenkins 파이프라인을 정의하는 스크립트 파일로, CI/CD 작업(Continuous Integration/Continuous Deployment)을 자동화하기 위한 핵심 구성 파일입니다. Jenkinsfile은 Jenkins가 수행할 빌드, 테스트, 배포 등 여러 작업을 명시적으로 작성한 파일입니다.  Jenkinsfile의 두 가지 스타일1. Declarative Pipeline (선언형)Jenkins Pipeline을 직관적이고 읽기 쉽게 작성할 수 있는 고수준 구문 제공.CI/CD 작업 흐름을 pipeline, stages, steps로 구조화.장점:간결하고, 초보자도 사용하기 쉬움.에러 처리가 자동으로 포함됨.예:pipeline {     agent any     st..

1. Active-Standby란?Active-Standby 구성은 하나의 시스템(Active)이 동작 중일 때, 다른 시스템(Standby)은 대기 상태로 유지되는 구조를 의미합니다.목적: 고가용성(HA, High Availability)을 보장하기 위해 준비된 대기 시스템을 마련하는 것.Standby 시스템은 Active 시스템이 실패했을 때 동작을 시작하도록 설계됩니다.이 개념은 수동 또는 자동으로 동작 전환(Failover)을 구현할 수 있습니다. 2. Auto-Failover란?Auto-Failover는 Active 시스템에 장애가 발생했을 때, Standby 시스템으로 자동으로 전환하는 메커니즘을 의미합니다.Auto-Failover는 추가적인 메커니즘이나 소프트웨어(예: 클러스터링 툴, 장애 ..

빌드(Build)란 무엇인가?**빌드(Build)**는 소스 코드를 실행 가능한 상태(프로그램)로 만드는 전체 과정을 말합니다. 이는 소스 코드 파일, 설정 파일 등을 컴퓨터가 이해할 수 있는 형태(바이너리, 실행 파일 등)로 변환하는 작업을 포함합니다. 빌드는 개발자 환경(소스 코드)에서 실제 사용자 환경(배포 가능한 프로그램)으로 옮겨가는 다리 역할을 합니다.  빌드의 주요 단계빌드는 다양한 과정을 포함하며, 사용되는 언어와 환경에 따라 다르지만 보통 아래 단계를 포함합니다.코드 컴파일사람이 작성한 소스 코드(텍스트 파일)를 컴퓨터가 이해할 수 있는 기계어(바이너리)로 변환.예:C언어는 gcc를 사용하여 .c 파일을 실행 가능한 .exe 파일로 변환.Java는 javac를 사용하여 .java를 .cl..

HDFS(Hadoop Distributed File System)와 NFS(Network File System)는 둘 다 파일을 저장하고 액세스하는 시스템이지만, 설계 목적과 작동 방식이 크게 다르기 때문에 NFS와 같은 일반적인 파일 스토리지와는 본질적으로 다른 점이 있습니다. 아래에서 그 차이를 더 자세히 설명하겠습니다.HDFS와 NFS의 주요 차이1. 설계 목적NFS:네트워크 상에서 중앙 서버의 파일을 여러 클라이언트가 공유할 수 있도록 설계된 일반적인 파일 스토리지입니다.주로 POSIX 호환성(일반적인 파일 시스템 표준)을 유지하며, 파일 읽기/쓰기 작업에 적합합니다.워크로드: 일반적인 애플리케이션 파일 접근, 소규모 데이터 공유.HDFS:대용량 데이터를 분산 저장하고 처리하기 위해 설계된 빅데이..

Dockerfile에서 UID를 설정하거나 명시적으로 처리하는 이유는 컨테이너의 사용자 권한 관리 및 보안성을 강화하기 위해서입니다. 아래 주요 이유를 살펴보겠습니다.1. 호스트와의 파일 권한 충돌 방지컨테이너에서 생성된 파일은 기본적으로 컨테이너 내부의 사용자 ID(UID)와 호스트 시스템의 사용자 ID가 다를 수 있습니다. 이 경우, 컨테이너가 생성한 파일이 호스트에서 읽기/쓰기 불가능하거나, 접근 권한 문제를 일으킬 수 있습니다.예: 컨테이너에서 UID가 1001인 사용자가 생성한 파일은 호스트에서 다른 사용자처럼 보일 수 있습니다.해결: Dockerfile에서 컨테이너 내부의 사용자와 UID를 명시적으로 설정하면, 호스트 시스템과의 호환성을 높일 수 있습니다.2. 보안 강화컨테이너는 기본적으로 r..

Git Flow 전략은 제외합니다. 최근에 포스팅을 했기 때문에. 1. GitHub FlowGitHub Flow는 단순하고 가벼운 브랜치 전략으로, 지속적 배포(Continuous Deployment)에 적합합니다.특징main 브랜치만 존재하며, 항상 배포 가능한 상태를 유지.모든 작업은 feature 브랜치에서 이루어지고, 작업 완료 후 main에 병합.병합 시 코드 리뷰와 자동화된 테스트를 반드시 수행.흐름main에서 feature 브랜치 생성.작업 완료 후 Pull Request 생성.코드 리뷰와 테스트 통과 후 main에 병합.병합 후 바로 배포.사용 시기배포 주기가 짧고, 빠른 릴리스가 중요한 프로젝트.단순한 워크플로우를 선호하는 소규모 팀. 2. GitLab FlowGitLab Flow는 Gi..

Git Flow는 Git을 활용한 브랜치 관리 전략 중 하나로, 코드의 개발, 릴리스, 배포 과정을 체계적으로 관리할 수 있도록 설계된 워크플로우입니다. Vincent Driessen이 제안한 방식으로, 프로젝트 개발 단계에 따라 명확한 브랜치 구조와 규칙을 제공합니다.  핵심 아이디어Git Flow는 다음과 같은 주요 브랜치로 구성됩니다:main (또는 master)항상 안정적이고 배포 가능한 코드만 존재.실제 운영 환경에 배포된 코드가 이 브랜치에 포함됩니다.develop새 기능 개발이 완료된 코드를 통합하는 브랜치.개발 진행 중의 최신 상태를 유지합니다.  주요 보조 브랜치Git Flow 전략에서는 기능 추가, 버그 수정, 배포 등을 위한 브랜치를 체계적으로 구분합니다.Feature 브랜치목적: 새..