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..

만들었고, 아직 아무런 image가 없다. No images.이 오른쪽 위에, View push commands 를 봐야 한다.이 저장소를 사용하기 위한 다양한 명령어들이 있다.당연히 이것도 마찬가지로, ECR에 대한 접근 권한이 있어야 한다.접근 권한을 생성해줘야 한다.이 명령어를 사용하기 전에 접근 권한을 먼저 설정하는 일을 해봐야 한다. Docker Image는 회사의 중요한 자산이다.Docker Image는 사실상 제품에 대한 정보를 가지고 있는 것이니까.그러니 그걸 저장하고 있는 ECR은 아무나 접근하게 두어선 안 된다.그래서 권한 관리를 해줘야 한다.AWS에서는 IAM 이라는 서비스를 이용해서 권한을 관리를 할 수 있다.IAM을 통해서 access key, secret key 를 가지고 key..

우선, Group 을 만들고, 거기서 project (test-app) 을 생성하는데, 그 안에는 Dockerfile, Makefile 이 있을 것이다.Docker Image가 만들어지고 나면, push 를 해서 AWS ECR에 저장될 것이고 Docker Container를 실행할 수 있게 된다.일단 지금은, AWS ECR 에 push 하기 전까지의 단계까지만 진행해볼 것.GitLab 기반 Docker 이미지 생성 및 AWS ECR 푸시 워크플로--------------------------------------------------1. 그룹 생성: - GitLab에서 새로운 그룹(Group)을 생성. └── 그룹 이름: [그룹 이름]2. 프로젝트 생성: - 그룹 안에 새로운 프로젝트(Pr..