첫번째 방법

example-depl.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: example-depl
spec:
  replicas: 1
  selector:
    matchLabels:
      app: example
  template:
    metadata:
      labels:
        app: example
    spec:
      containers:
        - name: example
          image: [docker hub id]/example:0.0.1

1. 코드 변경

2. 도커 컨테이너 이미지 다시 build, 새 이미지 버전으로 바꾸기

docker build -t [docker hub id]/example:0.0.2 .

3. example-depl.yaml 파일 변경

apiVersion: apps/v1
kind: Deployment
metadata:
  name: example-depl
spec:
  replicas: 1
  selector:
    matchLabels:
      app: example
  template:
    metadata:
      labels:
        app: example
    spec:
      containers:
        - name: example
          image: [docker hub id]/example:0.0.2

4. 명령어 실행

kubectl apply -f [deployment file name]

두번째 방법 (추천!!!)

1. 도커 이미지 버전 정보 변경

example-depl.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: example-depl
spec:
  replicas: 1
  selector:
    matchLabels:
      app: example
  template:
    metadata:
      labels:
        app: example
    spec:
      containers:
        - name: example
          image: [docker hub id]/example (or [docker hub id]/example:latest)

2. 코드 변경

3. 도커 컨테이너 이미지 다시 build

docker build -t [docker hub id]/example .

4. 도커 허브에 이미지 push

docker push [docker hub id]/example

주의사항!!

docker push denied requested access to the resource is denied

1) 에러가 발생하면 docker login 으로 도커 허브에 로그인 되어 있는지 확인

2) [docker hub id] 에서 도커 허브 아이디와 동일한지 확인

5. 명령어 실행

kubectl rollout restart deployment [deployment name]

pods와 deployment 상태 확인

kubectl get deployments
kubectl get pods

'Docker, Kubernetes' 카테고리의 다른 글

쿠버네티스 기본 명령어  (0) 2021.02.23
Docker 기본 명령어  (0) 2021.02.23
Commit Message 규칙  (0) 2020.12.27
CI 지속적 통합  (0) 2020.12.27
브랜치 전략 패턴 git-flow, github-flow  (0) 2020.12.26

pod 관련 명령어

kubectl get pods

실행중인 모든 pod 확인

kubectl exec -it [pod name][cmd]

실행중인 pod 안에서 명령어 실행

kubectl logs [pod name]

pod 로그 확인

kubectl delete pod [pod name]

pod 삭제

kubectl apply -f [config file name]

쿠버네티스가 config 파일을 실행하도록 함

예시 kubectl apply -f example.yaml

kubectl describe pd [pod name]

실행중인 pod 정보 확인

deployment 관련 명령어

kubectl get deployments

실행 중인 모든 deployment 확인

kubectl describe deployments [deployment name]

특정 deployment 세부 사항 확인 

kubectl apply -f [config file name]

config 파일에 따라 deployment 생성

kubectl delete deployment [deployment name]

deployment 삭제

'Docker, Kubernetes' 카테고리의 다른 글

쿠버네티스 deployment 업데이트 방법  (0) 2021.02.23
Docker 기본 명령어  (0) 2021.02.23
Commit Message 규칙  (0) 2020.12.27
CI 지속적 통합  (0) 2020.12.27
브랜치 전략 패턴 git-flow, github-flow  (0) 2020.12.26 
docker build -t sangjs/example:version .

현재 폴더에서 도커 파일을 기반으로 이미지 생성

예시 docker build -t sangjs/example:0.0.1 .

docker run [image id or image tag]

image id나 tage 기반으로 컨테이너 생성과 시작 순차적으로 진행

docker run -it [image id or image tag][cmd]

컨테이너 생성 및 시작하고 명령어 실행

docker ps

실행 중인 전체 컨테이너 정보 표시 ( -al 을 붙이면 전체 컨테이너 정보 표시)

docker exec -it [container id][cmd]

컨테이너에서 명령어 실행

docker logs [container id]

컨테이너 로그 표시

'Docker, Kubernetes' 카테고리의 다른 글

쿠버네티스 deployment 업데이트 방법  (0) 2021.02.23
쿠버네티스 기본 명령어  (0) 2021.02.23
Commit Message 규칙  (0) 2020.12.27
CI 지속적 통합  (0) 2020.12.27
브랜치 전략 패턴 git-flow, github-flow  (0) 2020.12.26

Commit 메시지 규칙은 커밋 로그 가독성, 협업 리뷰 과정, 코드 유지 보수를 위해 진짜 꼭 필요하다.

Commit Message 규칙 8개

  1. 제목 본문 한줄 띄어 분리
  2. 제목 50자 이내
  3. 제목에 마침표 금지
  4. 제목은 구문형 ex) "Somefunction 수정", 본문은 평서문
  5. 제목이 영어이면 첫번째 문자는 대문자로
  6. Github 이슈 번호 붙이기 ex) #123
  7. 본문 72자 마다 줄 바꾸기
  8. 본문은 How 보다 What, Why 에 초첨

Conventional Commits 규칙

이태릭체는 생략할 수 있습니다

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

  • type

    • feat : 새로운 기능 추가 및 수정
    • fix : 버그 픽스
    • build : 빌드 관련 파일 수정 ex) npm, yarn
    • ci : CI 설정 파일 변경
    • docs : 문서 변경
    • style : 코드 구문과 관련 없는 부분 ex) 띄어쓰기, 세미콜론
    • refactor : 리팩토링 관련 수정
    • test : 테스트 생성 및 수정
    • pref : 성능 향상 관련 코드 수정

  • scope

  • subject

    • 왜 무엇을 바꾸었는지 과거 코드와 비교해 현재 시제로 작성

  • footer

    • Breaking Changes 정보를 적는 공간, Breaking Changes는
    • 닫히는 GitHub 이슈 번호를 적음
    BREAKING CHANGE: isolate scope bindings definition has changed and
the inject option for the directive controller injection was removed.

To migrate the code follow the example below:

Before:

scope: {
myAttr: 'attribute',
myBind: 'bind',
myExpression: 'expression',
myEval: 'evaluate',
myAccessor: 'accessor'
}

After:

scope: {
myAttr: '@',
myBind: '@',
myExpression: '&',
// myEval - usually not useful, but in cases where the expression is assignable, you can use '='
myAccessor: '=' // in directive's template change myAccessor() to myAccessor
}

The removed `inject` wasn't generaly useful for directives so there should be no code using it.
    Closes #234

or

Closes #123, #245, #992

예시

feat($browser): onUrlChange event (popstate/hashchange/polling)

Added new event to $browser:

- forward popstate event if available
- forward hashchange event if popstate not available
- do polling when neither popstate nor hashchange available

Breaks $browser.onHashChange, which was removed (use onUrlChange instead)
fix($compile): couple of unit tests for IE9

Older IEs serialize html uppercased, but IE9 does not...
Would be better to expect case insensitive, unfortunately jasmine does
not allow to user regexps for throw expectations.

Closes #392
Breaks foo.bar api, foo.baz should be used instead

브랜치명

브랜치 명은 {type}/{issue number}-{간단한 이슈 설명} 으로 한다.

Reference

'Docker, Kubernetes' 카테고리의 다른 글

쿠버네티스 deployment 업데이트 방법  (0) 2021.02.23
쿠버네티스 기본 명령어  (0) 2021.02.23
Docker 기본 명령어  (0) 2021.02.23
CI 지속적 통합  (0) 2020.12.27
브랜치 전략 패턴 git-flow, github-flow  (0) 2020.12.26

CI 소개

CI (Continuous Integration)는 애자일 개발 방법에 속한다. 통합 작업은 미루지 말고 개발 중에라도 꾸준히 해서 소프트웨어 복잡성을 제거하기 위해 사용한다.

애자일 프로젝트는 스프린트라는 짧은 주기로 설계, 개발, 테스트를 여러 번 실시한다. 스프린트 기간은 2주에서 1개월 정도이다. 스프린트 성과물이 요건을 만족하는지 확인된 프로그램이고 기간이 짧기 때문에 매일 개발, 통합, 테스트를 할 수 없다.

빌드와 테스트 자동화

CI는 빌드와 테스트 자동화에서 중요하다. 프로그램이 제대로 작동하고 있는지 피드백을 주는 통합 자동화 역할을 한다. 스프린트는 CI라는 짧고 빠른 피드백 주기로 구성되어 개발 속도와 품질을 높인다.

비용과 속도

CI는 비용과 시장 변화 속도에서 장점이 있다.

  • 비용

개발 속도가 느려지면 그만큼 비용이 발생한다. 버그 발생은 개발 속도를 굉장히 지연한다. 커밋 전이나 바로 후에 버그를 알아차리고 수정하면 다행이다. 하지만.. 일주일 뒤, 아니면 몇 달 뒤에 버그를 수정하려고 코드를 보면 막막해지고 수정이 정말 어렵다.

  • 속도

시장 변화 속도에 발맞출 수 있다는 것을 의미한다. 가독성, 유지 관리를 하면서 개발 주기가 짧아 시장에 민감하게 반응할 수 있다.

Reference

  • 성공으로 이끄는 팀 개발 실천 기술, 제이펍, 2016

'Docker, Kubernetes' 카테고리의 다른 글

쿠버네티스 deployment 업데이트 방법  (0) 2021.02.23
쿠버네티스 기본 명령어  (0) 2021.02.23
Docker 기본 명령어  (0) 2021.02.23
Commit Message 규칙  (0) 2020.12.27
브랜치 전략 패턴 git-flow, github-flow  (0) 2020.12.26

git-flow

중앙 repository에 메인 branch 2개(develop, master), 개발 멤버 리포지토리에 서포트 branch 3개(feature, release, hotfixes)가 있는 형태이다.

git-flow

  • 브랜치 설명
    • main branch
      1. master : 배포용 브랜치, 배포 시마다 태그 부여
      2. develop : 개발용 브랜치, 배포 전 최신 버전 유지
    • support branch
      1. feature : develop에서 생성, 기능 개발용
      2. release : develop에서 생성, 배포 준비용
      3. hotfix : 배포 제품에서 장애 발생 시 긴급 생성

git-flow 전략은 주기적인 배표 기간이 있는 대규모 프로젝트에 어울린다.

github-flow

  • git-flow 문제점
    • git 사용도 어려운데 브랜치 전략은 더 어렵다
    • GUI 도구를 사용할 때 git-flow 스크립트를 사용할 수 있어 브랜치 전략에 개발자가 익숙해야 한다
    • git-flow 스크립트와 브랜치 전략 모두 이해하기 어렵다

github-flow는 git-flow 보다 단순한 구조이다.

git-flow

  • master는 어떤 때에든 배포 가능하고 항상 최신 상태 유지
  • master에서 직접 브랜치 생성 (기능 추가, 버그 해결)
  • 생성된 브랜치와 커밋 메시지는 명확하게
  • 작성한 브랜치는 로컬 장치에서 커밋하고 원격 레포지토리에도 정기적으로 push 한다
  • 개발이 완료되면 master에 Pull Request 한다
  • Pull Request 검증하고 master에 merge 후 배포한다.

github-flow 주의점

  • master는 배포용이기 때문에 직접 수정하지 않는다
  • 작업 시작 시 브랜치를 생성한다
  • 작업 종료 후 master에 Pull Request 한다

github-flow 보다 좀 더 복잡하게

우크라이나 학습 사이트 개발 프로젝트는 github-flow에서 한 브랜치를 추가하려고 한다. git-flow 브랜치에서 main branch가 develop과 master로 나누어져 있다. develop는 개발/테스트 브랜치로 사용하고 master 브랜치는 배포할 때 사용한다. 그리고 master는 develop에서 머지할 때마다 태그를 바꾸는 식으로 하기로 한다.

어떻게 보면 gitlab-flow와 비슷하다

Reference

'Docker, Kubernetes' 카테고리의 다른 글

쿠버네티스 deployment 업데이트 방법  (0) 2021.02.23
쿠버네티스 기본 명령어  (0) 2021.02.23
Docker 기본 명령어  (0) 2021.02.23
Commit Message 규칙  (0) 2020.12.27
CI 지속적 통합  (0) 2020.12.27

+ Recent posts

티스토리툴바