목록DevOps (91)
우노
들어가기 앞서, 예제 코드를 통해, Github Workflows 파일의 주요 필드에 대해서 다뤄보겠습니다. 예제 코드 develop branch 업데이트 시, 태그 및 릴리즈를 자동 생성하는 코드입니다. # Workflow 이름입니다. name: Release Tag # 어떤 조건에 Workflow를 Trigger 시킬지를 의미합니다. on: # push(Branch or Tag), pull_request, schedule 등을 사용할 수 있습니다. push: branches: - develop # Workflow가 실행할 작업입니다. # 여러 Job이 있을 경우, 병렬 실행이 기본이며, 해당 예제에선 하나의 job만 있습니다. jobs: Test: # job을 실행할 환경입니다. runs-on: ub..
들어가기 앞서, repository의 버전을 tag를 통해 관리하고 있을 경우, 업데이트(merge)마다 수동으로 tag를 생성한다면 매우 번거로운 작업이 됩니다. 따라서, 해당 포스트에서는 Github Actions을 활용해, Main Branch Merge 시 Tag/Release를 자동으로 생성하는 방법을 다뤄보겠습니다. 자동화 방법 해당하는 Repo의 .github/workflows 폴더에, 아래 yml 파일을 저장하면 됩니다. name: Release Tag on: push: branches: - main # main branch로 push될 때 아래 action이 실행됩니다. jobs: build: runs-on: ubuntu-latest steps: # 깃헙 코드 내려받기 - uses: ac..
들어가기 앞서, 일반적으로 Github Actions에서 보안이 중요한 환경변수들은 github secrets 기능을 사용해 관리합니다. 해당 포스트에선, github secrets을 통한 환경변수 사용 방법에 대해서 다뤄보겠습니다. Secrets 생성 방법 secrets를 등록하고 싶은 github repo에 접근합니다. 우측 상단 Settings > 좌측 하단 Secrets and variables > Actions 탭에 접근합니다. 우측 상단 New repository secret을 클릭합니다. 사용하고자하는 환경변수의 이름을 Name에, 값을 Secret에 작성합니다. Secrets 사용 방법 .github/workflows 내부 yml 파일에서 아래와 같이 사용할 수 있습니다. name: Tes..
git pull error 힌트: You have divergent branches and need to specify how to reconcile them. 힌트: You can do so by running one of the following commands sometime before 힌트: your next pull: 힌트: 힌트: git config pull.rebase false # merge 힌트: git config pull.rebase true # rebase 힌트: git config pull.ff only # fast-forward only 힌트: 힌트: You can replace "git config" with "git config --global" to set a defaul..
Label 사용자가 특정 객체를 구분하기 위해 사용하는 기능입니다. Controller들은 특정 Label에 해당하는 Pod들을 관리합니다. 생성된 이후 언제든지 수정이 가능하고, 코어 시스템에 직접적인 영향은 없습니다. Selector 특정 Label에 해당하는 객체를 관리하기 위해 사용하는 기능입니다. Annotation 쿠버네티스 시스템이 필요한 정보들을 표시하거나, 주석의 목적으로 사용하는 기능입니다. 일반적으로 쿠버네티스에 새로운 기능을 추가할 때 사용됩니다. 다음과 같은 메타데이터를 기록할 수 있습니다. 사용자 지시 사항 필드 이미지 정보 (타임 스탬프, 릴리즈 ID, 빌드 버전, git 브랜치, 이미지 해시, 레지스터리 주소 등) 디버깅에 필요한 정보 (이름, 버전, 빌드정보) 참고 http..
들어가기 앞서, 해당 포스트에서는, Kubernetes에서 Service 생성 시 사용되는 port 유형을 정리합니다. 매번 볼 때마다 헷갈려서.. Nodeport Node에 접근할 때 사용되는 포트입니다. Port Cluster 안에서 내부적으로 Service 객체에 접근하기 위해 사용되는 포트입니다. Targetport Service 객체로 전달된 요청을 Pod로 전달할 때 사용되는 포트입니다. 전체적인 서비스 흐름 NodePort -> Port -> TargetPort 순서로 트래픽이 전달됩니다. deployment.yml과 service.yml 예제 참고 https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=freepsw&logN..
들어가기 앞서, 해당 포스트에선, Istio의 트래픽 구조와 트래픽 주요 컴포넌트인 Gateway, Virtual Service, Destination Rule에 대해서 간단히 다뤄보겠습니다. 예제 코드는 https://istio.io/latest/docs/examples/bookinfo/ 를 참고했습니다. Istio 트래픽 구조 실습 환경엔 Istio가 사전 설치되어 있다고 가정하겠습니다. Istio 설치 시, 외부 IP가 할당된 LoadBalancer 타입의 Service가 자동으로 생성됩니다. istio-system이라는 Namespace의 istio-ingressgateway라는 Service로 생성됩니다. 따라서, 상단 그림에선 생략되어 있지만, Client는 istio-ingressgatewa..
들어가기 앞서, Terraform은 아래와 같이 kubernetes provider를 선언할 수 있습니다. provider "kubernetes" { config_path = "~/.kube/config" config_context = "my-context" } 이때, 클러스터 액세스 정보를 담은 kubeconfig 파일이 필요합니다. 만약, kubeconfig 파일에 클러스터 액세스 정보가 없을 경우, 아래와 같은 에러가 발생하게 됩니다. Error: Provider configuration: cannot load Kubernetes client config 따라서, 해당 포스트에선 kubeconfig 파일 작성을 위한 사전 작업에 대해서 다뤄보겠습니다. kubeconfig 파일에 클러스터 연결 정보 ..
요약 CMD 컨테이너를 생성할 때만 실행됩니다. (docker run) 컨테이너 생성 시, 추가적인 명령어에 따라 설정한 명령어를 수정할 수 있습니다. ENTRYPOINT 컨테이너를 시작할 때마다 실행됩니다. (docker start) 컨테이너 시작 시, 추가적인 명령어 존재 여부와 상관 없이 무조건 실행됩니다. CMD, ENTRYPOINT 명령어 작성 방법 CMD ["", "", ""] CMD ENTRYPOINT ["", "", ""] ENTRYPOINT CMD 예제 Dockerfile FROM ubuntu CMD ["/bin/echo", "Before"] docker run 실행 (추가 명령어가 없을 때) docker run --name # Before docker run 실행 (추가 명령어가 있을 ..
들어가기 앞서, 해당 포스트는, Terraform state로 관리되고 있는 자원 정보 확인 관련 명령어들을 정리합니다. 모듈을 포함한 모든 자원들의 세부 정보 출력 terraform show 모듈을 포함한 모든 자원들을 리스트형식으로 출력 terraform state list