스낵 코드

설치 환경 OS : Centos 7 DB : MariaDB 모든 과정은 root 계정으로 진행합니다. 1. DB 설치 $ yum -y install mariadb-server mariadb $ systemctl enable mariadb.service $ systemctl start mariadb.service 2. DB 보안 설정 # DB 보안 설정 및 관리자 비밀번호 설정 $ mysql_secure_installation 보안 설정은 해당 환경에 따라 알맞게 설정해야 합니다. 3. DB 접속 후 database 생성 및 사용자 생성 # DB 접속 $ mysql -uroot -p # redmine 정보를 저장할 DATABASE 생성 (table 은 자동으로 생성됨) [MariaDB] CREATE DAT..

jenkins 빌드하면서 분명히 소스 빌드가 성공했는데 docker 빌드하면서 빌드한 jar 파일을 사용하려고 할 때 해당 파일을 찾을 수 없다는 에러가 발생했다. 로그를 자세히 보니 @(골뱅이)가 붙은 workspace에서 실행되는 것을 발견했다. 왜 이게 생기나 찾아봤는데 동시 빌드 되면서 생기는 자연스러운 에러라고 했다. 1. 해당 job의 이름을 가진 workspace에서 소스 빌드를 시작하고 성공함 2. 이 때 외부 개입(직접 build 버튼을 누르거나 webhook으로 인해 자동 실행)으로 인해 job이 또 실행됨 3. 중복적으로 실행되면서 이미 실행되던 job은 해당 job의 이름에 @를 붙인 workspace에서 실행됨 (예: testjob@2, wowjob@2 ...) 4. 그렇게 이미 ..

jenkins 작업하면서 파드 초기화를 한 적이 있는데 그때 따로 설정을 보지 않고 돌리다가 NullPointerException 에러가 났었다. Started by upstream project "ZZZ-TEST" build number 1269 originally caused by: Started by user xxxx java.lang.NullPointerException Finished: FAILURE jenkins는 java 기반 서비스라서 java 에러가 발동했는데, 어떠한 자세한 이유도 없이 NullPointerException가 떠서 좀 당황스러웠다. 해당 에러에 대해 찾아보니까 NullPointerException 에러는 주로 jenkins의 에러가 아니라 해당 job의 에러라고 한다. ..

jenkins 작업 중에 쓸모 없는 플러그인들을 정리한 적이 있다. 그러고 나서 끝났다고 생각해서 job을 돌렸는데 빌드 시작하기도 전에 에러가 뜨면서 빌드 실패를 한 적이 있다. java.lang.NoSuchMethodError: No such DSL method 'pipeline' found among steps ~~ 해당 에러는 jenkins가 스크립트를 실행할 때, 'pipeline' 이라는 명령어를 인식할 수 없기 때문에 발생하는 에러이다. 'pipeline' 대신에 여러 단어가 들어갈 수 있지만 해결 방법은 대부분 비슷하다. 해결 방법 1. 오타 확인 스크립트 작성 중에 오타가 있는지 확인한다. 'pipeline' 대신 'pipline' 이라고 오타날 때도 있다. 2. 플러그인 확인 해당 명령..

회사 jenkins 작업 중에 plugin을 수동 업로드 했더니 jenkins가 맛탱이가 갔다. 파드 로그를 보니까 아마 작업하시는 분이 plugin의 버전 정보를 고려하지 않고 업로드해서 충돌이 생겨서 발생한 것 같다. # 에러 로그 확인 kubectl logs [pod-name] -n [namespace] 그래서 원래는 웹에서 플러그인을 삭제하고 jenkins를 재시작하면 되지만 젠킨스가 아예 다운이 돼서 접근이 안되기 때문에 cli로 해결을 해야한다. 젠킨스 plugin 에러로 검색해보니까 수동으로 비활성화 하기 위해서는 disabled 파일을 추가하라고 나온다. 이렇게 하기만 해도 안전하게 삭제하는 것과 같은 효과를 낸다고 한다.. 참고 : https://www.jenkins.io/doc/book..

PV (PersistentVolume) - 관리자가 프로비저닝 했거나 스토리지 클래스를 사용해 동적으로 프로비저닝한 클러스터의 스토리지 - 볼륨과 같은 볼륨 플러그인이지만 PV를 사용하는 개별 Pod와 독립적인 수명 주기를 가짐 PVC (PersistentVolumeClaim) - 사용자가 볼륨을 사용하기 위해 PV에 하는 스토리지 요청 - Pod는 노드 리소스를 소모하고 PVC는 PV 리소스를 소모한다. 1. PV의 Lifecycle 1) Provisioning : PV를 생성하는 단계로 동적 프로비저닝과 정적 프로비저닝이 있다. - 동적 프로비저닝 : 미리 적정 용량의 PV를 만들어두고 사용자의 요청 시, 미리 만들어 둔 PV를 할당함. 제한된 스토리지 용량일 때 유용 - 정적 프로비저닝 : 사용자가..

1. Request / Limit - 파드를 어느 노드에 배포할지 스케쥴링할 때, 해당 노드에서는 충분한 자원이 파드에 할당되어야 함 - cpu/memory와 같은 컴퓨트 리소스 외에도 gpu/storage 리소스에 대한 필요한 양을 명시할 수 있음 - CPU는 ms(밀리세컨드) 단위로 지정하며 CPU 1000ms 가 1vCore(가상 CPU 코어)이며 메모리는 Mb를 사용 apiVersion: v1 kind: Pod metadata: name: frontend spec: containers: - name: app image: images.my-company.example/app:v4 resources: requests: memory: "64Mi" cpu: "250m" limits: memory: "12..

1. ReplicaSet - 파드를 생성 및 복제하고, 복제된 파드 수를 yaml 파일에서 생성된 개수만큼 항상 유지 apiVersion: apps/v1 kind: Replicaset metadata: name: nginx-rs labels: app: nginx-rs tier: nginx-rs spec: replicas: 3 selector: matchLabels: tier: nginx-rs template: metadata: labels: tier: nginx-rs spec: containers: - name: nginx-rs image: nginx - selector: 어떤 label의 파드를 선택하여 관리할지에 대해 설정한다. 위에서는 tier: nginx-rs 라는 라벨을 가진 파드들을 식별하여 ..

Label & Selector 1) Label - 객체에 연결된 key-value 쌍 값 - 리소스를 논리적인 그룹으로 나누거나 식별하기 위해 붙이는 이름 - 객체 생성 시 첨부할 수 있으며 언제든지 추가 및 수정 가능 2) Selector - 특정 Label에 해당하는 객체를 식별하거나 검색할 수 있음 # Node Label 확인 kubectl get nodes --show-labels # Node Label 추가 kubectl label nodes k8s-worker01 svc=web apiVersion: v1 kind: Pod metadata: name: nginx labels: env: test spec: containers: - name: nginx image: nginx imagePullPol..

1. Pod 란? - 쿠버네티스 노드 내에 최소 한 개 이상의 컨테이너를 가진 파드가 실행되고 있으며, 파드마다 다른 IP를 가지고 있고 컨테이너끼리 통신이 가능함 - 파드 내 컨테이너끼리 볼륨(저장소)을 공유하며, 컨테이너가 죽고 재시작해도 파드가 살아있는 한 Shared volume은 유지 됨 - init-container 가 기본적으로 생성되며, 해당 컨테이너의 네트워크 인터페이스(CNI)를 파드 내 다른 컨테이너에서도 공유하여 사용 2. Pod의 Lifecycle - Pending: 파드가 클러스터에 승인되었지만 한 개 이상의 컨테이너가 설정되지 않았고 실행할 준비가 되지 않은 상태 - Running: 파드가 노드에 바인딩(할당)되고 모든 컨테이너가 생성된 상태 - Succeeded: 파드에 있는..