wy_family

디지털 비즈니스는 점점 더 복잡해지고 더 빨라지고 있습니다. 이러한 속도에 적응하기 위해서 인프라가 코드화되면서 코드를 통한 개발과 배포의 통합과 자동화는 CI/CD 라는 이름으로 개발자의 필수 기술 셋이 됐습니다.- 인프라가 코드화가 되었다 --> Cloud- 코드를 통한 개발과 배포 --> Cloud- 통합과 자동화CI/CD! 그래서 Docker, Linux, Cloud, CI/CD Pipeline, GitLab 을 통한 학습을 했다. Docker를 이용해서 애플리케이션을 패키징 할 수 있습니다. 애플리케이션을 위한 라이브러리, 빌드 시스템, 런타임, 코드 뿐만 아니라 운영체제에서 제공하는 PID, USER, Volume, IPC, Network 까지 함께 패키징 할 수 있습니다. 이를 통해서 어디에..

개발자가 feature branch를 만들고 feature branch 에 대한 Merge Request를 하고 승인을 하면파이프라인이 작동해서 새로 배포되는 것까지 확인을 했다.그런데, feature branch 를 push를 하게 될 경우에 GitLab은 새로운 코드의 변경 사항을 확인하고feature branch에 대해서도 파이프라인을 작동시켜버렸다.결과적으로 아직 검증이 끝나지 않은 상태에서 서비스가 업데이트가 되어버린 것이다.이 경우에는 feature branch의 어떤 변화에 대해서는 CI/CD 파이프라인이 작동하지 말아라라는 예외 조건을 줘야 한다.예외조건을 설정하는 것을 보자.--> CI/CD Pipeline를 수정해보면 해결 가능하다. 해당 job 이 main 에서만 실행되도록 조건을 걸..

push를 했더니 에러가 떴다.그러니까 push라는건, 그냥 막 밀어넣겠다는건데,그게 아니라 merge request를 해서 main branch에 변화를 주어야 한다.그럴려면 branch를 생성했었어야 하고, 그 branch에서 코드를 개발해야 한다는 걸 의미한다고 생각한다.그래야 나중에 merge를 요청하지 않을까. MR (Merge Request)우선, branch를 새로 뻗고 기능 개발을 한 뒤에 MR 을 하기 전에,아까 push 하려고 commit 했던 걸 없애버려야 한다.git reset --hard HEAD~1git reset --hard HEAD~1 명령어는 Git에서 이전 커밋 상태로 되돌리고, 현재 작업 중인 파일 변경 사항과 스테이징된 모든 변경 사항까지 모두 삭제하는 강력한 명령어입..

지금까지는 CI/CD 파이프라인 설계하고 구축하는 걸 했지만 '혼자' 작업하는 상황이었다.그런데 현실에서는 함께 일하는 상황일 것. 그러면, Group, project, user, permission 설정이 필요하다.그러니까 Merge Request와 Approve 설정이 있을 것.+Slack을 이용한 CI/CD 모니터링, Slack 연동과 CI/CD 이벤트 메시지 전송을 해볼 것.어찌됐든 지금까지 한 것들은 '혼자' 작업하고 있는 상황이었다보니 간단한 CI/CD 파이프라인을 구축했었다.하지만 실제 협업할 때는 여러 가지 상황들, 여러 조건들이 필요하다. 실제로 서비스 중인 어떤 Main Branch 가 있다고 해보자.개발자가 뭔가를 개발할 때, Main Branch를 가지고 바로 개발/적용을 하면 위험..

GitLab-runner 가 배포를 하게 될 것이다.Gitlab-runner가 배포하는 방식은 gitlab-runner에서 aws 명령어를 실행하게 될 것이다.aws cli, 설치를 안 했으면 하면 된다.aws cli 명령 중에서는 ecs를 컨트롤할 수 있는 명령을 제공한다.ecs의 cluster를 만들거나 service를 새로 실행(running)하거나 하는 등의 작업을 수행할 수 있다.ECR에 새로운 어플리케이션이 올라가있는데, 거기에 코드 내용을 수정하고 새로운 버전의 docker image를 올리고그리고 service를 새로 실행(running)하게 될 것이다.service를 새로 실행하게 되면은 새로 만들어진 docker image를 가지고 와서 service가 올라오게 될 것이다.이 과정을 테..

1. Application Load Balancer2. Target Group3. Listener AWS Cloud 위에 VPC (Virtual Private Cloud)를 만들었다.VPC는 account를 만들때 기본으로 만들어졌던 네트워크VPC는 가상 네트워크, 거대한 가상 네트워크이다.이 네트워크(VPC) 위에 어플리케이션을 구축하는 것.이 네트워크 위에 ECS Cluster를 만들었고그리고 Service 를 하나 만들었다.이 Service는 2개의 Container, task로 구성이 되어 있다. task 1, task2.이 2개의 task는 target group으로 묶었다.그렇게 묶은 이유는, 사용자 클라이언트 요청이 80번으로 들어왔을때,Listener가 연결된 target group으로 사..

일단, AWS ECS로 가보자. 클러스터를 만들어야 한다.일단은 AWS Fargate (serverless) 로 만든다  이제 컨테이너를 실행하기 위해서는 task definition 이 필요하다.왼쪽 바에 보면 정의할 수 있는 버튼이 있다.새로운 task definition을 생성해야 한다.그런데, task role 을 선택할 때 ecsTaskExecutionRole 을 선택해야 하는데 나오지 않는다. 뭐지? AWS ECS에서 ecsTaskExecutionRole을 선택할 수 없는 경우는 보통 해당 역할이 AWS 계정에 아직 생성되지 않았거나, 필요한 권한이 제대로 설정되지 않았기 때문입니다. 아래는 이 문제를 해결하는 단계별 가이드입니다.1. ecsTaskExecutionRole이 무엇인가요?ecsT..

GitLab pipeline 에서 make build, make push 까지 했었다. (make test 의 경우에는 그냥 스테이지만 넣었고 실질적인 test를 넣은 건 아니었다.)ECR까지 docker image가 등록이 된 상태다. 지속적인 통합 과정, CI 과정은 끝이 난 것. 이제 make deploy,그러니까 AWS Cloud로의 배포까지 추가해서 사용자들이 사용할 수 있도록 하면 된다.CI 까지 만들었으니까 CD 를 만든다는 것. 1. GitLab을 이용해서 프로젝트를 만들고2. Docker Image를 빌드해서 ECR에 Push 했고3. 이제 인터넷 사용자가 서비스를 사용할 수 있도록 Docker Image를 배포해야 한다.4. AWS ECS 를 이용해서 우리가 개발한 어플리케이션을 AWS..

파이프라인을 작성을 해봤고 어떻게 작동하는지도 확인해봤다. 이제는 test-app을 직접 CI/CD Pipeline 배포하는 것을 해봐야 한다.실제 빌드를 할 수 있게 해야 한다. 현재 .gitlab-ci.yml 파일(pipeline)에는 stages가 만들어져있다.- build / test / deploy지금은 각각의 stages 에서 echo를 실행하고 있는데,직접 build를 할 수 있도록,docker image를 build 하고 push하고 test 하고 deploy 를 할 수 있도록 수정을 해야 한다. 여러가지 방법 중에 여기서 선택할 방법은, 소스 코드에 make build / make push / make test ... 스크립트를 함께 집어넣을 것이다. 그래서 make build 를 하게 ..

gitlab runner를 구축했었다.gitlab cicd pipeline을 구성을 해볼 것이다.pipeline 이라는 건, 컨베이어 벨트 같은것이다. 각각의 스테이지가 있는데그 스테이지는 컨베이어 벨트로 연결이 되어 있고,각각 스테이지에서 어떤 결과물들을 다음 스테이지로 컨베이어 벨트를 통해서 넘기는 것.최종적으로는 완성된 제품이 튀어나오는 것.GitLab Pipeline도 stages 를 이용해서 관리한다.stages:- build- test- deploy 빌드 스테이지에서는 도커 이미지를 만들고테스트 스테이지에서는 도커 이미지 기반으로 해서 여러 가지 테스트를 수행하고테스트가 끝나면 ECR에 push를 하고,최종적으로 Deploy.  스테이지는 하나 이상의 job 으로 구성된다.스테이지는 각각의 공..