Page History

통합시나리오

Image Added

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

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

Fork를 하던, 추가 기능에대해 브랜치를 생성하던 머징후 사라질녀석들이기때문에 CI와 상관없이 개발팀의 개발문화에 따르면 되는 사항들이다.

빌드 플랜 만들기

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

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

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

업데이트 적용

Image Added

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

란쳐에 이미 등록된 Stack이라고 하면 Upgrade 버튼을 한번누르는것으로 무중단 배포가 시작되며 최신버젼및 특정버젼 지정가능하다.

다양한 배포환경은 환경변수를 다르게 주입하여 코드/빌드 단계가 아닌 배포단계에 할수 있어야할것이다.

CI구성을 위해

• GitHub
• Rancher
• DockerHub 

단지 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에 모두진행할수도 있습니다.