오늘 배운 것🤓

서비스를 Docker로 구동하는 과정

• Github main의 코드가 머지될 때마다 다음의 순서를 수행한다.

1. 테스트 수행
2. Docker Image 빌드
   dockerfile을 repo에 생성
3. Docker Image를 Docker Hub로 푸시

이 과정을 자동으로 수행하기 위해 Github Actions를 사용할 수 있다. Actions를 사용할 때 과정은 아래와 같다.

1. repo에 코드를 push
2. Actions이 실행된다.
3. 테스트를 진행한다.
4. Docker Image를 build하고 Docker Hub에 push한다.
5. 최신 Docker Image를 Production 서버에 배포한다.

Docker 컨테이너와 외부 통신

• Dokcker 내부에서 port를 열어 사용한다고 해도 밖에서 접근할 수 없다.
  (why? 컴퓨터 안에 컴퓨터가 돌아가고 있는 상황)
• 외부에서도 사용하기 위해 port를 열어주는 과정을 port mapping 혹은 port forwarding 이라고 한다.

$ docker run -p 내부포트:외부포트 image-name

CI/CD

software build

• 소프트웨어 빌드 : 개발한 sw를 최종적으로 출시하기 위한 형태로 만드는 것
• 빌드를 진행할 때 '이 코드가 정말 안정적인지', '제대로 돌아가는 것을 보장하는지'가 중요한 포인트이며, 이것이 테스트가 빌드의 중요한 일부로 포함되는 이유이다.
• 이 때 많이 사용되는 패키지 형태가 docker image
• 참여 개발자들이 많을 수록 중요해진다.

CI/CD

• 개발이 끝나기 전부터 빌드를 하면 sw의 안정성이 증대하는데 이를 위해 commit될 때마다 테스트와 빌드를 진행한다. 이것을 Continuous Intergration(CI)라고 한다.
• 하나라도 테스트가 실패하면 빌드는 실패하기 때문에, local에서 먼저 테스트한 후 올리도록 하자. (물론 그래도 실패할수도...)
• CI는 sw egineering practice 중 하나이다.
• CI의 기본 원칙
  • 코드 repo를 하나만 유지(Master/Main)
    빌드는 Main만, 개발은 다른 브랜치를 사용
  • 코드변경을 최대한 자주, 조금씩 반영
  • 테스트를 최대한 추가
    Test Coverage를 80% 채우도록 하자.
  • 빌드를 계속적으로 수행
  • 성공한 빌드의 production release를 자동화하자.
    이것이 Continuous Deploy/Delivery(CD)

느낀 점😊

오늘은 알고 있는 이론을 정리하는 기분으로 들었다. 다시 한번더 머리속에 정리하면서 어떤 질문거리가 나올 수 있을지 생각하는 것도 재미있는 것 같다.
내일 배울 Github Action이 기대된다. 드디어 깃헙을 전문가처럼 사용할 수 있게 되는 것일까?!