Page History

...

최근 지속통합은, 브랜치 전략을 단순화하는 방향으로 간다.  브랜치에 여러개의 개발환경을 맞추기보다 

-환경마다(dev,alpha,stage,prod,) 브랜치가 늘어나면 헬이 된다. 그리고 그렇게 복잡한 브랜치가 자동화된것을 본적이 단언코 단 한번도 없다 

배포 플로우가 똑독해짐에 따라 , 1 Master(Tag) - N 환경 으로 가는 추세이다.  또는  Dev한개정도 추가로 구분된 정도이다.

Fork를 하던, 추가 기능에대해 브랜치를 생성하던 머징후 사라질녀석들이기때문에 CI와 상관없이 개발팀의 개발문화에 따르면 되는 사항들이다최소 두개 또는 태그패턴을 통해 1개로도 충분하다.

빌드 플랜 만들기

DockerHub에서는 Github과 연동되어, 빌드에 대한 플랜을 쉽게 적용할수가 있다..

중요 결정 정책은 단 두가지이다. - 위 샘플은 1소스 N 환경으로 갔을때 상황이며 dev를 하나더 만들수 있다.(요즘은 dev를 굳이 안만드는 추세)

• 특정 브랜치에 변경점이 생길때 자동 빌드생성 ( latest)  - 테스트 대상이다.
• 특정 태그가 생성되면 그 시점의 코드를 자동 빌드생성 (v1.0.0) - 배포 대상이다. 

업데이트 적용

DEV같은 경우, 트리거를 연결하여 자동 반영되게 할수도 있지만 ( 각각의 오픈 API를 서로 연결)

...

단지 3가지 사용만으로 심플하고 강력한 배포 파이프라인을 사용할수 있게됩니다.

사설 도커 저장소 만들기

...

도커허브및 깃헙패키기 또는 AWS의 ECR을 통해 빌드된 도커저장소를 배포하여 이용할수 있지만

사설 도커레지스트리 자체를 등록하여 용량에따른 비용제약없이 이용가능합니다.

version: '2'
services:
  registry:
    restart: always
    image: registry:2
    ports:
      - 5000:5000
    environment:
      REGISTRY_AUTH: htpasswd
      REGISTRY_AUTH_HTPASSWD_PATH: /auth/htpasswd
      REGISTRY_AUTH_HTPASSWD_REALM: Registry Realm
    volumes:
      - /opt/registry/data:/var/lib/registry
      - /opt/registry/certs:/certs
      - /opt/registry/auth:/auth
    labels:  
      io.rancher.scheduler.affinity:host_label: server_name=main
      io.rancher.container.hostname_override: container_name

docker run --rm --entrypoint htpasswd httpd:2 -Bbn testuser testpassword | Set-Content -Encoding ASCII auth/htpasswd

# BasicAuth 생성

docker run \
--entrypoint htpasswd \
httpd:2 -Bbn 아이디 패스워드 > /opt/registry/auth

CI/CD

...

지속 빌드및 배포는 결국 다음 사이클이 반복

• 1.빌드 : 도커빌드(docker build)
• 2.빌드배포 : 도커빌드 배포(docker push)
• 3.도커Pull : 구동 서버에서 (docker pull )
• 4.도커Run : 구동 서버에서 (docker run )

1~2의 과정은 Github 액션에 등록하고, 3~4의 과정은 Rancher에서 수행(API제공) 할수 있다.

Github에서 배포도 가능하지만 빌드배포의 책임만 수행하고, Rancher에서 배포트리거를 분리해서 관리할수 있으며

Rancher의 API를 이용해 Github에 모두진행할수도 있습니다.