인덱스

• 검색 속도를 높이기 위한 색인 기술
• JOIN / WHERE 에 사용됨
• 인덱스 없는 데이터 조회 시
  • 전체 데이터 페이지의 첫 레코드 -> 마지막 레코드까지 모두 조회 == FULL SCAN
  • 때문에 속도가 느림
• 그러나 INDEX를 많이 설정한다고 조회 속도가 빨라지지 않음
  • INDEX는 테이블 형태로 저장하는 것임
  • 즉 인덱스가 많아지면 데이터베이스 메모리를 많이 잡아 먹음
  • 인덱스로 지정된 칼럼 값이 변동되면, 인덱스 테이블이 갱신되므로 느려짐
  • 때문에 쿼리문 자체가 빨라질 수도 있지만, 전체적 데이터베이스 부하가 증가함
• SELECT는 빠르지만, UPDATE / INSERT / DELETE 속도는 느림
  • UPDATE / DELETE 시 WHERE을 통해 데이터 조회 자체는 빠름
  • 그러나 데이터 변경 / 삭제 자체는 느림

팁

• 카디널리티 : 카디널리티가 높으면 인덱스 설정에 좋은 칼럼
  • 카디널리티가 높다 == 한 칼럼이 갖고 있는 값의 중복도가 낮음 (대부분 다른 값을 가짐)
  • 인덱스 통해 불필요한 데이터 대부분을 걸러낼 수 있음
• 선택도: 선택도가 낮으면 인덱스 설정에 좋음
  • 선택도가 높다 == 한 칼럼이 갖고 있는 값 하나로 여러 row가 찾아진다.
• 조회 활용도: 조회 활용도가 높으면 인데스 설정에 좋은 칼럼
  • WHERE 문의 대상 칼럼으로 많이 활용되는지
• 수정 빈도: 수정 빈도가 낮으면 인덱스 설정에 좋은 칼럼
  • 인덱스도 테이블
  • 따라서 지정된 칼럼 값이 인덱스 테이블이 새롭게 갱시되어야 함

용어

• HEAP: 데이터 저장 시 내부적으로 아무런 순서 없이 저장된 데이터 저장 영역

  CREATE INDEX user_idx ON user_table (user_name);

UBUNTU에 Go 설치하기

• 항상 컨테이너로 GO 프로그램을 돌렸지만, 불가피하게 로컬에 GO를 설치해 빌드하고 돌려야 할 상황이 와서 해당 내용을 기록한다.

소스 다운 받아서 설치하기

최신 버전 확인

• 공식 사이트의 Golang 버전 확인 후 다운받기 (2024.10.21 시점 1.23.2)
• 공식 사이트

WGET을 이용해 다운로드

• WGET을 이용해 다운받기

  wget https://go.dev/dl/go1.23.2.linux-amd64.tar.gz

압축 해제

• 다운 받은 압축 파일 해제

  sudo tar -C /usr/local -xzf go1.23.2.linux-amd64.tar.gz

경로 설정

vi ~/.profile

# 파일 마지막 줄 아래에 내용 추가
export PATH=$PATH:/usr/local/go/bin
export GOPATH=$HOME/go
export PATH=$PATH:$GOPATH/bin

변경 사항 적용

source ~/.profile

Go 버전 확인

go version

UBUNTU 피키지 매니저로 다운받기

패키지 인덱스 업데이트

sudo apt update

GO 설치

sudo apt-get install golang-go

Go 버전 확인

go version

아래는 Jenkins 도입 과정과, 겪었던 시행 착오들에 대한 과거 기록들이다.

• 배포 과정은 아래와 같다.
  • Master 브랜치에 커밋이 발생함을 감지 (Merge 커밋)
  • Matser 브랜치의 소스 코드를 가져와 Docker 이미지 빌드
  • 빌드된 이미지를 Private Registry에 푸시
  • 배포할 서버에 .env 파일과 docker-compose.yml 파일 전송
  • 배포할 서버에 빌드된 이미지를 pull 하여 컨테이너 구동
• 이를 위해선 Github 연동과 Credentials 생성이 우선이다.

Github 설정

Github SSH KEY 연동

• 배포용으로 사용할 키 새성

ssh-keygen -t rsa -f jenkins

• .pub 키를 복사해서 계정/조직의 ssh 키를 추가해 복사해 넣는다
• Jenkins Credentials 추가
  • Kind: SSH Username with private key
  • ID 임의 설정
  • username: 깃허브 계정명
  • Private key: 생성된 jenkins 키 내용 전체 복사 붙여넣기
  • 이렇게 설정하니, Host key verification failed. 라고 하며 git fetch 실패 에러가 뜨더라
• Jenkins Secure 설정
  • 위 에러를 해결하기 위해 아래처럼 했다
  • Git Host Key Verification Configuration 설정 변경
    • Accep First connection 설정

Github Access Token

• 깃헙 계정 에서 personal access token 생성
  • settings - developer settings - personal access tokens - tokens(classic)
  • Classic Token 생성하기
    • exiration: No expiration
    • repo
    • admin:org
    • admin:repo_hook
  • 생성되는 값 복사해두기

Github WebHook 설정

• 레포지토리/조직의 설정으로 이동
• 탭 중 webhook 선택
• Add webhook 선택
  • url에 "${jenkins-url}/github-webhook/"입력
  • 생성하면, 성공 시 초록색 체크와 함께 완료된다
  • 실패 시, 이미 실패한 요청을 선택하여 redeliver하면 해결되더라

Jenkins 설정

Credential 설정

• Jenkins 관리로 이동
• Credentials - Stores scoped to Jenkins의 System 클릭 - Global credentials 클릭 -> Add Credentials 클릭
• 깃허브 레포지토리 / 조직 접근 키 설정 - 깃헙 웹훅 사용 용
  • Kind를 Secret Text로 설정
  • Secret에 위에서 복사한 Personal Access Token 값 붙여넣기
  • ID: 마음껏 설정 - 나중에 이 값으로 깃헙 연동해야 하므로 알 수 있게끔 설정
  • Description: 설명
• 개인 계정 - 아이템에서 깃헙 레포지토리 접근 용
  • Kind를 Username with password
  • username: 깃허브 계정 명
  • password: Personal Access Token 값
  • ID: 마음껏 설정
  • Description
• 서버 - 접속 SSH 키 세팅
  • Kind를 Username and SSH
  • private key에 SSH private key 입력
• 환경변수 파일 - 배포시 서버에 파일 전송.
  • Kind: Secret File
  • Id: 서비스 별로 분리할 수 있게끔 설정
  • 환경변수 파일 업로드

Github webhook 설정

• Jenkins 관리로 이동
• System 선택
  • 하단의 Github 탭의 Github Server 클릭
  • Name에 아무거나 임의로 입력
  • API URL은 건들지 말고
  • Credentials 에 위에서 secret text로 생성한 Credentials 선택
  • Manage Hooks 체크
  • Test connection 선택하여 연동 여부 체크

Jenkins Item 설정

• 실질적인 파이프라인 설정 내용
• 새로운 Item 클릭

Jenkinsfile로 사용할 시

• 소스코드 내에 Jenkinsfile을 위치시켜 이를 사용해서 빌드하는 방법
• Jenkinsfile에서 사용할 키는 위의 SSH Credential
• pipeline 선택
  • Github project 체크
    • project url 선택: git@github.com:{브랜치명}
    • Github hook trigger for GITScm polling 선택
    • pipeline 변경
      • Definiton을 Pipeline script from SCM 선택
      • SCM을 Git 으로 변경
      • Repository URL에 깃헙 레포 주소 입력
      • Credentials: 깃허브 SSH Credential 선택
      • Branch Specifier: 연동할 브랜치
• 이제 master 브랜치로 커밋이 감지될 때 마다 Jenkins가 레포 안의 Jenkinsfile을 감지해서 입력된 순서대로 동작할거다

Jenkins 파일 사용 안할 시

• freestyle project 체크
• 소스코드 관리 - Git 체크
• Repository Url: 깃헙 레포 주소 입력
• Credentials
• 깃허브 SSH Credential 선택
  • master: 연동할 브랜치 설정 * 빌드 유발
  • Github hook trigger for GITScm polling 선택 * 저장`
• 이제 Build Steps에 과정을 입력한다.

Plugins

• Docker common: 도커 통합 플러그인
• Docker Pipeline
• SSH Pipeline steps
• SSH Server
• Publish Over SSH

에러 해결 - 1 docker.sock 퍼미션

• Jenkins 빌드 과정에서 도커 이미지 빌드 내용이 있었다
• 여기에서 permission denied while trying to connect to the Docker daemon socket 에러 발생
• 결국 호스트의 var/run/docker.sock을 마운트하고 있기 때문이므로, 이를 수정해주었다.
• # 새로운 계정 생성 sudo adduser jenkins

권한 부여

sudo usermod -a -G docker jenkins

• 그럼에도 해결되지가 않았다
• 누군가는 chmod 666으로 변경하면 된다지만, 이럴 경우 권한이 너무 열려버려서 위험해질 수 있다고 한다.
• 아무튼 확인 결과 컨테이너 내부의 docker.sock은 root:999 으로 잡혀있었다.
  • root:docker 혹은 docker:1000이 되어야 할텐데
• 때문에 컨테이너 내부 접근해서 직접 퍼미션 체크를 해 줬다.

sudo docker exec -it -u root jenkins-host /bin/bash
chown root:docker /var/run/docker.sock

• 차후에 퍼미션 문제 없이 마운트 시키고 싶다

에러 해결 - 2 bad crum

• 사실 이 문제는 왜 해결됐는지 원인 파악이 다 되지 않았다.
• 내가 시도한 방식은 아래와 같다.
  • 아래 CURL 명령어 쏴서 해결해 보기 (참고: https://stackoverflow.com/questions/44711696/jenkins-403-no-valid-crumb-was-included-in-the-request)
  • 결과적으로 위 방식은 별 도움이 되지 않았다.
  • 일단 프록시 해제를 시키래서 시도는 해 봤다. 결과적으로 시간 두니 해결이 됐다.

curl -v -X GET https://{jenkins_url}/crumbIssuer/api/json --user dong:samquinnWkd1

curl -X POST https://{jenkins_url}/job/manage/credentials/store/system/domain/_/createCredentials/build --user dong:samquinnWkd1 -H 'Jenkins-Crumb: 9e107e40a5f7b6597e4020a4680bdda68b6b04c480aba07311166caa3bf98f9f'