재밌는 코딩세상

배포 자동화 > 한 번의 클릭 혹은 명령어 입력을 통해 전체 배포 과정을 자동으로 진행하는 것 이유: 수동적이고 반복적인 배포 과정을 자동화함으로써 시간이 절약 휴먼 에러(Human Error)를 방지 배포 자동화 파이프라인 배포에서 파이프라인(Pipeline) : 용어는 소스 코드의 관리부터 실제 서비스로의 배포 과정을 연결하는 구조를 뜻함 Source 단계: Source 단계에서는 원격 저장소에 관리되고 있는 소스 코드에 변경 사항이 일어날 경우, 이를 감지하고 다음 단계로 전달하는 작업을 수행 Build 단계: Build 단계에서는 Source 단계에서 전달받은 코드를 컴파일, 빌드, 테스트하여 가공, Build 단계를 거쳐 생성된 결과물을 다음 단계로 전달하는 작업을 수행 Deploy 단계: De..

1. CI 상에서 주어진 Dockerfile을 이용해 Docker 이미지를 빌드하기 1. yaml 파일 작성 on : release 할 때마다 workflow 실행 step: uses: actions/checkout@v3 - github 레파지토리에 있는 파일 확인, 최신 버전 uses: docker/login-action@~ - Docker Hub에 로그인 with: - 'username', 'password'는 환경 변수 / Docker Hub 아이디와 패스워드를 통해 로그인 username: ${{ secrets.DOCKER_USERNAME }} password: ${{ secrets.DOCKER_PASSWORD }} ► github 레파지토리 세팅에서 secret 탭에 환경 변수를 설정해 주어야 ..

1. 처음 github action에 자동으로 docker build 하고 docker hub에 푸쉬하도록 하는 코드를 작성을 했다. > 저장한 후 release하고 action을 실행했다 > 하지만 'Error: buildx failed with: ERROR: denied: requested access to the resource is denied'라는 오류가 났다 뭐가 문제였을까? 1. 에러를 보니 '도커 이미지 업로드 권한 에러' 인 것 같아서, > 빨간색 박스 부분의 name은 본인의 도커 허브 아이디로, repository는 프로젝트 이름으로 바꿔 보았다 > 하지만 여전히 같은 에러가 떴다. 2. docker release를 지웠다가 새로 만들었는데 tag가 존재한다고 나와서 이상했다 > 그래..

1. 도커 공부 중 빨간색 박스 부분의 에러가 났었다. 2. 인터넷에 찾아보니 node 버전이 호환이 안되서 그렇다는 것을 알게된 후, Dockerfile의 코드를 밑에 사진 처럼 바꾸었다. 3. 해결!!

1. 깃허브 홈페이지에 접속 > 로그인 한다 2. repository 생성 후 Actions 클릭 3. 그 다음 ' set up a workflow yourself ' 를 클릭 4. 파일 이름과 yml 파일을 작성한다. name: 필수. 워크플로의 이름. 이것은 사용 가능한 워크플로 목록에 표시 on 블록: push, pull_request할 때마다 workflow를 실행시킨다. jobs: jobs 단위로 개별 서버(정확히는 도커 컨테이너 단위)에서 작업이 수행 ※ 각 작업은 병렬로 실행 run-on: 사용할 운영 체제 예) ubuntu, window, macos 등 strategy: 변수 개념, 'node version'에 배열이 선언 되어 있는데, 배열안에 있는 원소를 순회하면서 반복해서 실행 > m..

지속적 통합이 있기 전에는 어떻게 릴리스를 만들었을까요? 지속적 통합 (Continuous Integration, CI)가 보편화되기 전에는 수동으로 릴리스를 만들었습니다. 릴리스를 만들기 위해서는 개발자들이 작성한 코드를 컴파일하고, 테스트하고, 패키징하는 과정이 필요합니다. 이러한 과정은 수작업으로 수행되었으며, 매우 번거로운 작업이었습니다. 예를 들어, 개발자가 새로운 코드를 작성하면, 이 코드는 개발 환경에서 테스트되어야 합니다. 그리고 이 코드는 버전 관리 시스템 (예: Git)을 사용하여 릴리스 브랜치에 병합되어야 합니다. 이후, 릴리스 브랜치에서 코드를 빌드하고, 패키징하여 배포 가능한 형태로 만들어야 합니다. 이러한 릴리스 과정에서 발생하는 문제들은 수작업으로 해결하기가 매우 어려웠습니다...

내장된 CI 도구: GitHub Action은 깃허브 리포지토리 내부에 내장된 CI 도구로서, 깃허브에서 제공하는 다양한 기능과 API를 사용할 수 있습니다. 이를 통해 깃허브 리포지토리와 완전히 통합되어 있어, 개발자들은 코드와 함께 CI/CD 파이프라인을 쉽게 만들고 유지할 수 있습니다. 쉬운 사용성: GitHub Action은 사용하기 쉽고 직관적인 YAML 파일 형식으로 작성됩니다. 이를 통해 개발자들은 CI 파이프라인을 쉽게 구성하고 유지할 수 있으며, 파이프라인 내에서 다양한 작업을 수행할 수 있습니다. 다양한 통합성: GitHub Action은 다양한 플랫폼과 서비스와 통합될 수 있습니다. 예를 들어, AWS, Azure, Google Cloud Platform과 같은 클라우드 서비스, Do..

> 처음에는 *.sanghyup.click를 생성을 안했었다. 그래서 하위 도메인인 api.sanghyup.click로 들어 갔을 때 https 통신이 안됬었는데, > 추가한 후 https 통신에 성공했다!!

마이크로서비스 아키텍쳐 이해 > 하나의 애플리케이션을 작은 서비스(독립된 서비스)로 쪼개는 것 > 개발 방법론 ,데이터 스토리지, 개발 파이프라인 등 별도로 구축 > 다른 마이크로 서비스와 무관, 독립 > 통신? 표준화된 인터페이스 -> restful API 마이크로서비스 아키텍쳐의 이점 > 빠른 개발 속도 : 개발 언어 선택 자유로움, 서비스 팀의 역량만으로 가능 > 빠른 배포 속도 및 병렬 배포 : 각 마이크로서비스간 독립된 배포 파이프라인(CI/CD) > DevOps팀과 통합된 운영 : 서비스에 대한 Ownership > 확장성, 가용성 : 마이크로서비스 특성에 맞는 확장성/가용성 설계 > 비즈니스 도메인과 밀접하게 연결 : Lean Cycle(빠르게 비지니스 요건 충족) 마이크로서비스 아키텍쳐 공..

1. Certificate Manager를 통한 도메인 인증서 발급 > 사용하고 싶은 클라우드 서비스가 있는 리전에 인증서를 만들어야 한다 예) 서울 리전 1. AWS 홈페이지에 접속 > 로그인 > 오른쪽 상단 서울 클릭 > 자기가 쓰고 싶은 리전 선택 2. 인증서 발급 후 > Route53에 도메인을 생성 > CNAME 데이터를 DNS 클라우드인 Route 53에 생성 했던 도메인 레코드에 등록 ※ 별표(*)는 도메인 이름의 맨 왼쪽에 와야 하며 하나의 하위 도메인 수준만 보호할 수 있음 > *.sanghyup.click는 api.sanghyup.click을 보호할 수 있음 > https로 접속 가능 ※ Route 53은 도메인 네임을 바꿔 주는 클라우드 서비스로 hhtp > https로 바꿔서 접속하..