Fact
- githubAction으로 CI 구현을 했다. CI를 구현 한 이유는 자동 통합을 하기 위해서다. 로컬에서 commit 와 push를 하면 github에서 자동적으로 캐치를 해서 그것을 설정 한대로 실행을 하고 설정한 s3에 자동적으로 배포하게끔 만들었다.
- 아침에 프로그래머스 에 있는 레벨1 문제들을 다수 풀었다. 예전이랑 얼마나 차이가 나는지 확인을 하기 위해서 풀어봤다.
Feeling
-
운영 비용 절감을 위한 CI/CD 구축은 시간도 많이 걸리고 과정이 너무 힘들었다. 왜냐하면 정보들이 일목요연하게 나와있지 않고 요소들의 연결 과정에 필요한 정확한 정보들이 없었기 때문이다. 오직 시행착오를 겪어가며 삽질로만 해결할 수 있었다.
Finding
- git rm -rf —cached (/파일) 하면 git에서 tracked 된 모든 cache을 지운다. 혹시나 gitignore 하기 전에 git add .로 추적을 했었다면 위의 명령어로 추적하던 cache를 remove 함으로써 다시 gitignore에 넣어서 git에 안 들어 가게끔 설정을 할 수 있다.
- CI/CD(Continuous Integration/Continuous Deployment).
-
지속적인 통합(CI)은 개발자가 하루에도 여러 차례 코드를 공유 저장소에 통합해야 하는 개발 관행이다. 그런 다음 각 체크인을 자동 빌드로 확인하여 팀이 문제를 조기에 탐지할 수 있도록 한다. 정기적으로 통합하면 오류를 빠르게 감지하고 더 쉽게 찾을 수 있다. CI는 한국어로 지속적인 통합을 의미한다. 우리가 로컬에서 코드를 작성하고 GitHub 같은 팀 프로젝트 repository에 올릴 시에 이때 설정에 따라(테스트를 넣었을 시 테스트 통과를 할 때만 계속 진행된다) GitHub repository에 있는 코드랑 통합이 된다. 통합이 될 때 자동 빌드를 통해 코드의 문제를 조기 탐지할 수 있다. 이를 통해 오류를 빠르게 감지하고 더 쉽게 찾을 수 있다.
- CD는 한국어로 지속적인 배포다. CI 과정을 거쳐서 GitHub에 올라온 코드 들을 바로 자동적으로 서버에 코드가 옮겨지면서 배포가 된다. CD는 새로운 기능, 구성 변경, 버그 수정 및 실험 등 모든 유형의 변화를 production 또는 사용자의 손에 지속적으로 안전하고 신속하게 전달할 수 있는 기능이다.
-
- CI/CD tools https://medium.com/day34/ci-cd-tool-comparison-f710a4777852 https://stackify.com/what-is-cicd-whats-important-and-how-to-get-it-right/
CD tools
- gitLab - dockerhub=>ec2 https://medium.com/plapadoo/ automatic-deployment-of-docker-containers-to-aws-ec2-using-gitlab-aaccb824cd08
- codeship - dockerhub=>ec2 https://rollout.io/blog/deploying-docker-images-to-amazon-ec2-container-service-with-codeship/
- circlecli - dockerhub=> ecr => ecs
- flightplan - ???
- githubAction - github=> ecr => ecs https://velog.io/@q00/Github-action-aws-ecs-Github-CICD-55k38sf8ik
대략적으로 보자면 이미지 자체를 올리던 게 ec2 안에 이미지를 넣어서 환경 변수를 조정하고 컨테이너를 띄우던가의 차이가 있다.
Future action
- 오늘도 배포 작업에 대한 시도와 공부를 하게 되었는데 이때 너무 엄한 것들을 많이 보게 되었다. 예를 들어서 findings에서 본 cd tools에 대한 목록들. 또한 잘못 이해해서 dockerHub에서 ec2를 내려받으려 했던 행위 등의 시간 낭비를 했다. 이것을 방지하기 위해서 다음부터는 이상하면 빨리 물어보는 게 좋을 것 같다.