dev-jaesoon

자동 배포(CD) 왜 필요한가? 프로젝트를 진행 중 일정 단위의 개발이 완료된다면, 변경 내용을 실제 서버에 반영하기 위한 Deployment 를 진행하게 된다. 하지만, 이러한 Deploy 작업이 무언가 특별한 새로운 과정이 있는 것이 아니라 늘 같은 과정을 반복하는 것이기 때문에, 개발 이외에 많은 공수를 잡아먹는 작업 중 하나이다. 그리고, 실제 애플리케이션을 운영함에 있어서도 이러한 Deploy 작업을 인간이 수동으로 실시하다보면, 애플리케이션의 변경 내용과 관계없이 사람의 실수로 인한 장애가 발생하기도 한다. 이렇게 Deploy 작업에 불필요하고 비효율적으로 많은 시간을 소모한다면, 이는 유저에 대한 새로운 기능과 서비스 제공이 늦어짐을 의미한다. 그래서 이러한 문제를 해결하기 위한 노력으로 많..

Web application 기본 구성 Client와 Server로 구성되어 있다. 누구나 인터넷에만 연결되어 있다면, 제한 없이 Server에 접속할 수 있다. 일반적인 Port 80 을 사용하는 Web Server라는 전제하에 User 가 브라우저에 URL 을 입력하면, Client는 Server 에 Request를 보낸다. 그리고 Server 는 이에 대한 Response로 다양한 정보를 Client에게 보낸다. HTML, CSS, JS Image, Video etc... Web Application Architecture 서비스의 구성이 단순하고, 이용자 수가 적을 때 서비스의 구성이 복잡하고, 이용자 수가 많을 때 서비스가 다양하고 복잡해질수록 Web application을 안정적으로 운영하기 ..

Pull Request Labeler 적용 이번에는 Pull Request Labeler plugins을 사용하여, 변경된 파일 또는 디렉터리를 확인하고 자동으로 label 이 추가되도록 할 것이다. .github/workflows/labeler.yml : Pull Request Labeler 가 실행될 조건에 대한 workflows를 작성 .github/labeler.yml : 지난번에 사용한 설정 파일에 이어서 작성해도 무방 실행 조건 정의 .github/workflows/labeler.yml pull request 가 opened 또는 reopened 되었을 때, 그리고 PR에 새로운 Commit 이 Push 되었을 때 실행되도록 하기 위해 아래와 같이 코드를 작성하였다. 지난번과 다른 점이 있다면..

GitHub Labels 이란? GitHub Label 은 Pull Requests (이하 PR) 또는 Issues 에서 카테고리를 분류하기 위해 사용된다. GitHub 에서도 이미 기본적으로 9개의 Labels 를 제공하고 있다. 팀 프로젝트를 하고 있다면 여러 명의 팀원이 각자의 작업 내용을 여러 개의 PR 을 만들어 병합할텐데, 이 때 Labels 을 사용한다면 보다 효율적으로 작업 내용(PR)들을 관리할 수 있다. Auto Labeler 적용 GitHub actions 에 Auto Labeler plugins 을 적용하여 사용할 것이다. 그 중에서도 Auto Labeler 를 사용하여 PR 의 Title 이나 Description 에 특정 내용이 추가 되었을 때 GitHub actions 가 작동..

개발용 IAM 사용자 생성 그렇다면, 실제로 개발을 하면서 AWS 를 사용할 팀원들에게는 어떻게 IAM 사용자를 만들어 주면 될까? 기본적으로는 특정 서비스 또는 특정 동작에 대해서 사용자 별로 따로 권한을 설정할 수 있지만, 먼저 모든 서비스에 액세스 할 수 있도록 하는 PowerUserAccess 권한을 부여하여 IAM 개발용 IAM 사용자를 만들어 볼 것이다. (지난 번에 만든 Administrators 계정과 달리 유저 관리만 할 수 없다.) PowerUser (IAM 사용자) 추가 IAM 콘솔로 이동하여, 왼쪽의 대시보드에서 Users - Add User 를 눌러 사용자 추가 화면으로 이동한다. 그리고 아래와 같이 User name 과 access type 을 설정한다. 본 글에서 선택한 Acc..

지난 글에 이어서 실제로 관리용 IAM 사용자를 생성해 볼 것이다. 이렇게 생성한 관리용 IAM 사용자는 실제로 Root 사용자와 같이 AWS 서비스를 관리하기 위하여 사용되어 질 수 있다. 관리용 IAM 사용자 생성 IAM 사용자 추가 화면으로 이동 상단의 탐색 표시줄에서 IAM 를 검색하여, IAM 대시보드로 이동한다. 그리고 좌측의 Users 를 클릭하고 Add users 를 클릭하여, IAM 사용자 추가를 시작한다 관리자 역할을 할 사용자를 추가할 것이기 때문에 User name 을 [Administrator] 로 입력해주고, access type 은 [Password - AWS Management Console access] 을 선택하여, AWS 의 웹 페이지를 통해 로그인 할 수 있도록 해준다..

IAM 사용자의 필요성을 느끼다! AWS를 팀 프로젝트에서 사용하고 싶다... 현재 웹 서비스 개발을 공부하고 있다면, 누구나 한 번 쯤은 프로젝트를 하게 될 것이고, 자기가 직접 만든 서비스를 여러 사람에게 공유해보고 싶다고 생각한다면 AWS 와 같은 클라우드 컴퓨팅 서비스를 사용하게 될 것이다. 이 때, 1인 프로젝트를 한다거나 팀이더라도 한 명만 서버 관리를 담당하고 있다면, AWS 계정 하나만으로도 충분히 클라우드 환경들을 관리할 수 있을 것이다. 하지만, 팀 내에서 여러 사람이 Back End 를 역할 분담하여 담당하게 된다면, 하나의 AWS 계정에 여러 사람이 접근할 필요성을 느끼게 될 것이다. 하지만, 개인 계정을 팀원들과 공유하기에도 찝찝하고, 그렇다고 AWS 를 사용할 팀원 모두가 계정을..

시작하기 전에 도입하게 된 계기 현재 나는 부동산 정보를 게시 웹 서비스를 운영하는 부서에서 근무하고 있다. 과거부터 현재까지 집적된 수없이 많은 부동산 정보를 게시하고 있기 때문에, 부동산 회사나 건물 관리 회사 등으로부터 정보 수정 요청이 다양하게 들어온다. 이러한 정보 수정 요청들은 고객 대응 부서에서 사용하는 사내 툴에 접수되는데, 이 사내 툴 프로젝트를 운영하고 유지 보수하는 것도 당연히 내가 소속된 부서에서 담당하고 있다. 일부 소수 유저만 사용하는 사내 툴이기 때문에, 기능 추가나 소스 코드 변경도 자주 없다. 그렇기 때문에 프로젝트에 Linter Check 나 Unit test, 자동 배포 등은 전혀 도입되어 있지 않았다. 하지만, 장기적인 개발 생산성의 향상을 위해 CI/CD 도입이 필요..