[9주차] Docker & K8s (2)

 

🙂 Hangman 프로그램

• hangman 프로그램을 flask를 사용하여 웹으로 노출
  • 포트번호는 어디는 바인딩 가능하며 실행할 때 지정
  • flask 관련 모듈 설치 필요
• 실행 방법
  • python3 -m flask run --host=0.0.0.0 --port=4000
  • app.py 기본사용

✔ Repo 구성

• app.py: flask의 메인 함수가 있고 커맨드라인으로 받은 포트에 바인드하고 요청 대기
• requirements.txt: pip3 install requirements.txt ( pip3 freeze > requirements.txt )
• test.py: app.py에 있는 코드의 유닛 테스트 로직. CI/CD 구성 시 실행되게 설정할 예정
• README.md

🍦 프로그램 실행 데모

• git clone ~
• pip3 install -r requirements.txt
• python3 -m flask run --host=0.0.0.0 --port=4000

✔ Docker 컨테이너 내부 프로세스와 호스트 프로세스간의 통신

docker file 생성  

 

docker 엔진 실행

docker build  

docker run  

-d: detach로 background에서 실행

-p: 포트번호 지정

 

docker inspect

 

docker stop

 

docker login

docker push

 

---

🙂 CI / CD

✔ 소프트웨어 빌드란?

• 자신이 개발한 SW를 최종적으로 출시하기 위한 형태로 만드는 것
• 참여 개발자들이 많을수록 더 중요
• 개발이 끝나기 전부터 빌드를 하면 소프트웨어의 안정성 증대 - Continuous Integration

🍦 Continuous Integration

• SW Engineering Practice의 하나
• 기본 원칙
  • 코드 Repo는 하나만 유지 (Master)
  • 코드변경을 최대한 조금씩 자주 반영
  • 테스트를 최대한 추가 - Test Coverage
  • 빌드를 계속적으로 수행 (자동화) - Commit Build vs. Nightly Build
  • 성공한 빌드의 프로덕션 릴리스 (자동화) - CD: Continuous Delivery

🍦 빌드 실패!

• 새 코드의 커밋으로 인해 테스트가 실패하는 경우
• 많은 회사들이 빌드 실패시 빌드가 다시 성공할때까지 코드 변경을 금지
• 조직이 커지면 빌드만 전담하는 엔지니어가 생김 - 빌드 실패의 주범을 찾는 업무

---

🙂 Git / Github

✔ Git이란?

• Git은 분산환경을 지원하는 소스 버전 컨트롤 시스템
  • SVN/CVS은 항상 서버에 연결되어 있어야 사용 가능 (중앙 개발) - 외부 인터넷 연결 필수
• SVN/CVS에 비해 현저하게 빠르나 사용법은 더 복잡

🍦 장점

• 다수의 개발자가 공동 개발
• 코드 리뷰 가능
• 코드 백업
• 과거 코드로 롤백 가능

🍦 필요한 것

• 직접 git을 사용한다면 git이 설치된 컴퓨터와 저장 공간
• 클라우드 버전 사용 (Github, BitBucket, GitLab 등)

---

✔ Github이란?

• Git repo 호스팅/클라우드 서비스
• Git은 CLI이지만 Github는 GUI도 일부 제공
• 자신이 만든 repo가 모두 public일 경우 무료 - private repo의 수에 따라 가격대 결정

 

🍦 Git 관련 용어

• Repo: Repository. Git으로 관리되는 SW 프로젝트
• Master/Main: 한 Repo에서 기본이 되는 코드. Git - Master / Github - Main
• Branch: 자신의 Repo에서 새로운 기능 개발을 위해 다른 Branch로부터 만든 코드 작업본
• Clone: 다른 계정에 존재하는 Repo로부터 새로운 Local Repository를 만드는 것
• Commit (Check-in): 내가 만든 코드 변경을 Branch의 Local Repo에 반영하는 것
  

  

• 작업은 항상 내 PC의 Local Repo에서 일어나며 Pull과 Push를 통해 서버 상의 Remote Repo와 연결
• Pull: Master와 같은 Remote Repo로부터 마지막 Pull 이후 변경된 것을 다시 가져오는 작업
• Push: 작업중인 Local Repo에서 Remote Repo로 변경사항을 복사
• Merge: Pull이나 Push 했을 경우 두 Branch 간의 충돌을 해결하는 과정

🍦 Push나 Merge 시점이 CI/CD를 실행하기 위한 순간

• 코드가 메인/마스터나 브랜치에 추가되는 순간 CI/CD를 트리거
  • 이를 특정 메인/마스터나 특정 브랜치만 대상으로 하도록 설정 가능
  • 테스트 후 Docker Image 등을 만들도록 하는 것이 가능
  • CI/CD는 Github에 구현하는 것이 자연스러움
• Github에서는 이를 Actions라는 기능을 통해 Workflow라는 이름으로 구현 가능

---

✔ Github Actions이란?

• CI/CD를 Github 위에서 구현하기 위한 서비스
• 코드 테스트, 빌드, 배포 자동화 기능 제공
  • Workflow라 부르며 아래 컴포넌트로 구성
    • Events: Workflow가 Trigger 되는 조건
    • Jobs: 조건이 만족될 경우 어떤 Job이 실행되나
    • Actions
    • Runner: 어떤 서버에서 실행될 것인가

 

🍦 Workflow

• 트리거 이벤트가 발생하면 시작되는 일련의 동작을 지칭
• 이벤트 예시 
  • 코드 커밋(특정 브랜치를 대상으로만 제한 가능)
  • PR 생성
  • 다른 Workflow의 성공적인 실행
• Workflow를 위한 명령어는 YAML 파일로 저장
  • 명령어들로는 환경설정과 scripts 실행들이 대표적
• Workflow는 Job으로 나눠지며 각 Job은 일련의 스텝을 수행
  • 각 스텝은 하나 혹은 그 이상의 명령어 실행
    • actions라고 부르는 명령어의 집합이 될 수도 있음
  • 각 스텝은 윈도우나 리눅스 서버 위에서 runner에 의해 실행
    • Docker Image에서 수행하는 것이 서비스 배포 과정에 따라 더 일반적이기도 함

 

🍦 방법

• 적용하려는 repo에 보면 Actions 메뉴가 있음
• 다음으로 workflow를 하나 생성
• yml 파일을 직접 생성 혹은 템플릿 (CI Templates) 선택 후 수정
  • Python Application 혹은 Docker Image

 

🍦 Docker 관련 스텝

• docker login
  • 이 때 Docker hub ID와 Password를 읽어야함. 하드코딩 X Github 내에 저장
    • secrets.DOCKER_USER
    • secrets.DOCKER_PASSWORD
• docker build
• docker push

=> 위의 과정을 ./github/workflows/docker-image.yml에 기술 (steps 하단에 name)