지난 시간까지 docker 기반 command나, docker에 mysql image 빌드 후 container실행해보는 것까지 학습했다.
오늘 학습할 내용은 웹서비스를 docker에서 실행해보는 실습을 진행하고자 한다.
flask를 활용해 구현된 코드를 통해 웹으로 노출되어 있는데, 이를 docker기반으로 실행시켜 보고자 한다.
실행 이전의 flask로 웹서비스를 구현한 코드들을 살펴보자. (flask를 말로만 들었기에 부족함.)
🎈 requirements.txt
Flask==2.3.2
Flask-HTTPAuth==4.5.0
Flask-Login==0.6.2
Flask-SQLAlchemy==3.0.3
-> pip3 freeze는 온갖 모듈 전부 설치되기에 오래걸림.
🎈 app.py
from flask import Flask,session
app = Flask(__name__)
# ...
app.secret_key = "Python Study"
if __name__ == 'main':
app.run()
docker 기반으로 python Flask코드로 구현한 웹서비스를 실행시키는 방법.
1. labs.play-with-docker 사이트에 접속해 이전에 설치한 docker desktop과의 계정 연동
2. 리눅스 환경에서 해당 웹서비스가 존재하는 깃 리포 위치 clone
3. 해당 서비스 실행을 위해 필요한 모듈 설치하기
-> pip3 install -r requirements.txt
4. python -m flask run --host=0.0.0.0 --port=4000 실행해 서버 포트 열기< 결과 >
🎈 webservice를 docker image로 구성하기
docker container로 포트 4000에 실행된 flask app이 있을 때 이 app을 HOST OS에서 접근하려면 다음 과정을 거쳐야 한다.
1. docker container 내부 프로세스가 오픈한 포트번호를 외부로 노출해주는 것이 포트맵핑.
-> docker run -p 4000:4000 IMAGE_NAME
-> port forwarding을 통해 외부 포트와 도커 연결.
2. expose 4000 : docker image가 container로 실행될 때 내부에서 4000번 포트를 사용하고 있음을 의미 (동작에는 관여 X)🎈 dockerfile 생성하기
- 아래 Dockerfile을 vscode로 생성하여 리눅스환경에서 원하는 디렉토리에 저장.
FROM python:3.8-slim-buster LABEL Maintainer='taejun3305@gmail.com' WORKDIR /app COPY app.py ./ COPY requirements.txt ./ RUN pip3 install -r requirements.txt EXPOSE 4000 CMD ['python3', '-m', 'flask', 'run', '--host=0.0.0.0', '--port=4000']
- 만든 Dockerfile과 구현하고자 하는 웹서비스를 같은 디렉토리에 지정한 이후
docker build -t 이미지명 .(현 디렉토리) 실행- docker image ls 로 이미지 빌드되었나 확인
- docker run -p 4000:4000 IMAGE_NAME으로 실행해 서버 연결 확인하기
-> 백그라운드에서 실행시키기
-> docker run -p 4000:4000 -d taejun3305/hangman- 결과 확인
핵심은 구현할 웹서비스와 같은 위치에 Dockerfile이란 이름의 텍스트파일 만들기.
💡 추가 사항
docker ps 로 컨테이너 ID 확인 후 docker stop containerID로 컨테이너 중단도 가능
웹 서비스를 container로 실행한 후 hub에 push하기
-> docker push taejun3305/hangman
- SW build : 자신이 개발한 SW를 최종적으로 출시하기 위한 형태로 만드는 것
-> 개발 끝나기 전 빌드를 진행해 SW 안정성 증대CI란 SW Engineering Practice의 하나.
기본원칙은 다음과 같다.
- 코드 Repo는 master로 하나만 유지. (타 branch에서 작업 후 병합
- 코드 변경 최대한 자주 반영, 테스트를 최대한 추가 (Test Coverage)
- Commit Build VS Nightly Build (빌드를 계속적으로 수행 - 자동화)
- CD (성공한 빌드의 프로덕션 릴리스 - 자동화)
수행방식은 다음과 같다.
- 개발자의 Code Commit -> CI(테스트 수행) -> CD (SW 배포) -> 서비스 모니터링
CI Template : Python Application, flake8으로 코딩 스타일 체크
기본으로 pytest를 테스트 프레임워크로 설치 -> unittest로 작성
🎈 Git
- 분산환경을 지원하는 소스 버전 컨트롤 시스템
- (CVS, SVN은 항상 서버에 연결되어 있다는 전제하에서 사용 가능)
- 리눅스를 만든 Linus Torvalds가 개발 (GPL v2 오픈소스)
장점
- 협업으로 코드 충돌 해결 및 코드 변경사항 주기적으로 리뷰, 피드백 가능
- 모든 코드 변경 기록 백업, 스냅샷으로 버전 간 이동 가능
- Git은 repo 호스팅/클라우드 서비스로서 Github는 웹기반 인터페이스도 제공
Git 관련 용어
- Repo : Git으로 관리되는 SW 프로젝트를 지칭
- Master/Main : repo에서 기본이 되는 메인 코드 지칭, Git은 마스터, Github는 main
- Branch : 자신의 repo에서 새 기능 개발 등을 위해 master 또는 타 branch로부터 만든 코드 작업본을 지칭, 작업 후 나중에 원본 branch와 merge하는 목적으로 생성
- clone : 타 계정 repo로부터 새로운 local repo를 만드는 것
- commit : 코드 변경 사항 branch의 local repo에 반영
CI/CD를 Github 위에서 구현하기 위한 서비스를 Github Actions라고 한다.
코드 테스트, 빌드, 배포 자동화 기능 등을 제공한다
- 트리거 이벤트 발생 시 시작되는 일련의 동작들을 Workflow라 부르며 아래 컴포넌트로 구성된다.
-> Events, Jobs, Actions, Runner(Github hosted, Self hosted)
-> 트리거 이벤트 : code commit, PR, 타 Workflow 생성
-> workflow를 위한 명령어들은 yaml 파일로 저장github action을 통해 yaml파일을 생성하고 만든 코드들을 테스팅하거나 docker image를 만드는 dockerization도 가능하다.