서버 인프라/DevOps 8

Github action 개선하기

먼저, 현재 프로젝트의 github action은 한개의 step으로 이루어져 현재 진행 단계를 알기가 힘들었다. 이것은 빌드 및 배포를 통합한 github action이다. 그래서 해당 작업을 좀 더 알아보기 쉽게 바꾸어 보기로 했다. 먼저 배포 과정부터 정리해 보았다. tag 입력 확인디펜던시 다운로드빌드배포환경 설정배포성공 또는 실패 결과 슬랙 전송 위의 4가지 단계로 정규화를 시킬수 있었다. 여기서 공통으로 묶을 수 있는 작업을을 function 형태로 묶어보고 싶었다. 그래서 찾아보던 중 function과 비슷하게 사용 가능한 reusable workflows가 있었다. 해당 기능은 말 그대로 workflow를 재사용 가능하게 하는 기능이였다. 출시된지 얼마 안된거 같지만, 내가 원하는 기능이기..

12 Factor App 이란?

개요 개발 경험이 많고 Heroku 플랫폼을 운영한 사람들이 정리한 규칙이다. 현대의 클라우드 애플리케이션 (SaaS)을 효율적으로 운영하기 위한 개발 규칙이다. 주요 내용 1. Codebase 코드베이스와 앱은 일대일 상관관계가 있다. → 코드는 한곳에서 개발 및 배포되어야 한다. 코드베이스가 여러개인 경우 → 분산 시스템으로 간주한다. 각각의 코드베이스는 12 factor를 준수한다. 여러앱이 동일한 코드를 공유하는경우 → 12 factor를 위반한 경우이다. 공유되는 코드를 라이브러리화 하고 각 앱에 종속성을 주입한다. 앱 배포가 여러개인경우 → branch를 활용하여 배포 분리 2. Dependencies 애플리케이션은 전체 패키지의 암묵적인 존재에 절대 의존하지 않는다. 애플리케이션의 모든 종속..

쿠버네티스의 Network Solution에 대하여

쿠버네티스는 컨테이너 애플리케이션을 제어할 수 있는 컨테이너 오케스트레이션 프로그램 중 하나이다. 현재 컨테이너 오케스트레이션 도구 중에서 독보적인 위치를 지니고 있으며, MSA를 사용하는 기업들은 거의 다 쿠버네티스를 사용하고 있다. 쿠버네티스는 각 컨테이너를 다루는 도구이므로, 당연히 그와 관련된 네트워크 설정들이 있을 것이다. 쿠버네티스에서 기본적으로 제공하는 네트워크에 대해서 간단히 알아보자. 쿠버네티스의 기본 네트워크 쿠버네티스의 구조에 대해서 간단히 알아보자. 쿠버네티스의 가장 작은 단위는 파드이다. 한 개의 도커 컨테이너라고 보면 된다. 파드들을 관리하는 상위 단위는 노드이다. 노드는 한 대의 pc라고 생각하면 된다. 이러한 노드들을 관리하는 것이 쿠버네티스 클러스터이다. 그림으로 보면 다음..

Terraform 훑어보기

이번에 회사에서 terraform을 사용해서 간단히 정리해 보았다. Terraform이란 클라우드, 온프레미스 리소스들을 코드로 정의할 수 있는 도구이다. 컴퓨팅 리소스, 스토리지, 네트워킹 리소스, DNS, SaaS 등의 다양한 구성 용소를 코드로 정의할 수도 있다. 테라폼 API를 통해서 앞에서 말한 리소스들을 지정할 수 있다. 코드로 정의하기 때문에 기존의 코드를 작성하는 것처럼 협업이 가능하고 버전 관리가 용이하다. 테라폼의 워크플로에는 주로 3개의 단계가 있다. 먼저 코드를 작성하는 write 단계가 있다. 말 그대로 리소스를 코드로 작성한다. 두 번쨰는 plan이다. 기존에 있던 인프라를 기반으로 이후 변화될 계획을 구상한다. 구상하는 과정은 테라폼 자체적으로 알아서 순서를 정한다. 마지막으로..

자동 배포 환경 Github Action으로 이전하기

현재 서버 배포 환경은 Jenkins를 사용해서 하고 있다. 처음에는 내가 직접 인스턴스를 만들어 상세히 커스텀을 할 수 있다는 점이 좋았는데, 이게 시간이 지날수록 서버를 직접 관리해야 한다는 점이 단점으로 크게 다가왔다. 그래서 자동 배포 관련한 기능을 찾아보니, 나의 목적에 잘 맞는 Github Action이라는 서비스가 있어서, Jenkins에 있는 배포 환경을 Github Action으로 이전하기로 했다. Github Action이란 간단히 말하면 테스트, 빌드, 배포 등의 활동들을 Github 내에서 자동으로 설정할 수 있는 도구이다. 그냥 CI/CD 도구 중 하나인데, Github와의 연동성이 매우 좋은 도구라 보면 된다. 거기에 다양한 플러그인 및 확장 프로그램까지 지원하여 꽤 괜찮은 도구..

Jenkins를 이용하여 Docker 애플리케이션 배포하기 [3]

이전 게시물에서는 elastic beanstalk에 배포하는 플로우까지 제작해 보았다. 하지만 배포가 끝났을 때 알려주는 로직이 있으면 조금 더 확실히 배포에 대해서 인지할 수 있지 않을까? 라는 생각이 들었다. 배포가 정상적으로 이루어지면 좋은거고, 만약 배포에 예상치 못한 원인으로 실패했을 때도 알람을 주면 좋겠다는 아이디어가 있어 찾아보니, jenkins에는 slack과 연동해서 slack에 message를 보낼 수 있었다. 이를 이용해서 배포 결과를 slack으로 보내 보겠다. 참고로 모든 슬랙 메시지와 채널의 이름은 영어로 하는 게 좋다. slack 설정 먼저 기존에 이용중인 슬랙이 있어야 한다. 슬랙에 메시지를 전송받을 채널을 만든 후, 좌측 하단의 앱 -> 앱 추가 버튼을 눌러야 한다. 추가..

Jenkins를 이용하여 Docker 애플리케이션 배포하기 [2]

저번 글에서는 Jenkins와 Github를 연결해 보았다. 연결하는 순간 Github에 Jenkins 파일이 생성될 것이다. 젠킨스 파일을 이용해서 파이프라인을 구성하면 배포 과정을 비교적 쉽게 알아챌 수 있다. 3번부터 6번까지의 과정은 Jenkins파일 안에서 스크립트로 진행될 예정인데, 이를 작성하기 위해서는 3번부터 6번까지의 과정을 cli 명령어로 구성할 줄 알아야한다. Docker Image 빌드하기 도커 이미지를 로컬에서 빌드해야 한다. 먼저 다음 설명서를 읽고 도커를 설치하자. https://docs.aws.amazon.com/AmazonECS/latest/developerguide/docker-basics.html Docker basics for Amazon ECS - Amazon El..

Jenkins를 이용하여 Docker 애플리케이션 배포하기 [1]

현재 우리 회사의 배포환경은 절반은 자동, 절반은 수동으로 배포를 하는 중이다. 대략적인 플로우는 github에 push를 하게 되면 dockerhub에서 자동으로 빌드가 되고, 이 이미지를 수동으로 elastic beanstalk에 배포하는 방식이다. 테스트 환경은 상관없는데 프로덕션 환경에서는 상당히 거추장스럽다는 생각이 들게 되었다. 그래서 자동 배포 툴을 찾아보다가 Jenkins 라는 CI/CD 툴을 발견하게 되었다. 내가 사용하는 환경에서 상당히 적합하다는 느낌을 많이 받아서 Jenkins를 사용하기로 했다. 구상하기 구상한 환경은 다음과 같다. 내가 대강 구상한 플로우는 번호 순서대로 따라가면 된다. 1. 로컬에서 코드 작성 후 Github에 push한다. 2. webhook을 통해서 코드 저..