Kernel360 · oxix97 · Feb 19, 2024 · Feb 19, 2024 · Feb 19, 2024 · Feb 19, 2024
@@ -0,0 +1,130 @@
+
+---
+layout: post  
+title: `Github Actions`
+author: `이종찬`
+categories: `기술세미나`
+banner:
+  image: `![](https://github.com/Kernel360/blog-image/blob/main/1208/1.png)`
+  background: "#000"
+  height: "100vh"
+  min_height: "38vh"
+  heading_style: "font-size: 4.25em; font-weight: bold; text-decoration: underline"
+  tags: [`GithubActions`]
+---
+
+목차
+- 목표
+- CI / CD란?
+- GithubActions란?
+	- workflow?
+	- 사용해야하는 이유?
+	- 장점
+	- 단점
+- 정리
+
+## 목표
+
+CI / CD, Github Actions이 무엇이고, 어떻게 사용할 수 있는지, 그리고 어떤 장단점이 있는지를 알고 사용하는 것을 목표로 글을 작성합니다.
+
+## 1. CI / CD란?
+
+CI/CD는 Continuous Integration과 Continuous Delivery 또는 Continuous Deployment의 약자로, 소프트웨어 개발에서 흔히 사용되는 방법론입니다.
+
+### 1-1. Continuous Integration
+
+![](https://github.com/Kernel360/blog-image/blob/main/1208/2.png)
+
+CI는 지속적인 통합이라는 뜻으로, 개발자들이 코드를 자주 병합하고, 빌드하고, 테스트하는 과정을 말합니다. CI를 통해 코드의 품질을 높이고, 버그를 줄이고, 협업을 쉽게 할 수 있습니다.
+
+### 1-2. Continuous Deployment
+
+CD는 지속적인 배포 또는 지속적인 전달이라는 뜻으로, CI의 결과물을 자동으로 배포하거나, 배포 준비 상태로 만드는 과정을 말합니다. CD를 통해 배포의 속도와 안정성을 높이고, 고객의 피드백을 빠르게 반영할 수 있습니다.
+
+![](https://github.com/Kernel360/blog-image/blob/main/1208/3.png)
+
+### 1-3. 장점
+
+CI / CD 환경이 필요한 이유는 반복 작업의 자동화 및 피드백 루프 단축 등을 통해 소프트웨어 릴리스 프로세스의 속도를 개선하는 것 입니다.
+
+![](https://github.com/Kernel360/blog-image/blob/main/1208/4.png)
+
+짧은주기의 개발단위를 반복하며, 많은 협력과 피드백을 필요로 하는 애자일의 원칙을 실현하는 데 핵심적인 역할을 합니다.
+![](https://github.com/Kernel360/blog-image/blob/main/1208/5.png)
+
+## 2. Github Action
+
+Github Actions은 Github에서 제공하는 CI/CD 도구입니다.
+
+Github 저장소에서 발생하는 다양한 이벤트에 따라 원하는 작업을 자동화할 수 있으며 workflow라는 단위로 구성되어있습니다.
+
+![](https://github.com/Kernel360/blog-image/blob/main/1208/1.png)
+
+### 2-1. Workflow
+
+Workflow는 Github Actions에서 자동화할 수 있는 작업의 흐름을 의미합니다. ./github/workflows 폴더에 저장되며 다음과 같은 요소로 구성됩니다.
+
+- name: Workflow의 이름을 지정합니다. (선택 사항)
+- on: Workflow를 트리거할 이벤트를 지정합니다. (필수 사항)
+- jobs: Workflow에서 실행할 Job들을 지정합니다. (필수 사항)   
+- env: Workflow 전체에서 사용할 환경 변수를 지정합니다. (선택 사항)
+
+```yml
+# Workflow 이름
+name: Java CI with Gradle
+
+# workflow trigger
+on:
+  push:
+    branches: [ "develop" ]
+
+# permission
+permissions:
+  contents: read
+
+# Job
+jobs:
+  build:
+
+	# Job 실행 환경
+    runs-on: ubuntu-latest
+
+	# Job Step
+    steps:
+	    # Step Action
+      - uses: actions/checkout@v3
+      - name: Set up JDK 17
+        uses: actions/setup-java@v3
+
+        # Step Input
+        with:
+          java-version: '17'
+          distribution: 'temurin'
+      - name: Run chmod to make gradlew executable
+        # Step 커맨드
+        run: chmod +x ./gradlew
+
+      - name: Build with Test
+        run: ./gradlew clean build test
+
+```
+
+### 2-2. 장점
+
+- Github Actions를 사용하면 다음과 같은 이유로 CI/CD를 쉽고 편리하게 구현할 수 있습니다.
+- Workflow를 YAML 파일로 간단하게 정의하고, 코드와 함께 버전 관리할 수 있습니다.
+- Github 마켓플레이스에서 수많은 Action을 찾아서 사용할 수 있으며, 자신이 만든 Action을 공유하거나 재사용할 수 있습니다.
+- Workflow를 트리거할 수 있는 이벤트의 범위가 넓습니다.
+
+### 2-3. 단점
+
+- Workflow의 실행 시간과 리소스에 제한이 있습니다.
+- Workflow의 실행 환경에 따라서, 도커 컨테이너로 작성한 Action을 사용할 수 없는 경우가 있습니다.
+- Workflow의 실행 결과와 로그를 Github 외부에서 확인하거나, 공유하기 어려울 수 있습니다.
+- Workflow의 테스트와 디버깅을 위한 툴이 부족할 수 있습니다.
+
+## 정리
+
+- CI / CD는 지속적인 통합과 지속적인 배포를 의미하며, 소프트웨어 출시 및 운영에 필요한 반복적인 작업을 빠르게 안정적으로 가져가기 위해 필요
+- Github Action은 CI / CD 환경 구축에 대한 리소스를 최소화 하며 사용할 수 있으며 트리거 할 수 있는 이벤트 범위가 넓기 때문에 사용
+- Github Actions의 단점은 workflow에 대한 테스트 및 디버깅을 할 수 있는 수단이 부족하며 외부에서 로그 확인이 힘듬
@@ -0,0 +1,169 @@
+---
+layout: post  
+title: 배포있게 배포하기 -DB편-
+author: 손민우
+categories: 기술세미나
+banner:
+  image: https://github.com/Kernel360/blog-image/blob/main/2024/0117/1.png?raw=true
+  background: "#000"
+  height: "100vh"
+  min_height: "38vh"
+  heading_style: "font-size: 4.25em; font-weight: bold; text-decoration: underline"
+  tags: [Docker, AWS, DB]
+---
+
+다시 돌아온 Docker 세미나 시간입니다. 어쩌다보니 오픈세미나에 이어서 이번 주제도 Docker와 관련한 주제로 선택을 하게 되었는데요. (정말 파도 파도 공부해야 하는 부분이 계속 나오더라구요.)
+
+이전 오픈 세미나에서는 Docker의 기본적인 내용을 설명을 했다면 오늘 설명드릴 내용은 DB replication을 Docker를 통해서 적용해 보고 이를 쉽게 적용할 수 있도록 나온 서비스인 AWS RDS를
+
+통해서 이해하는 시간을 가져보려고 합니다. 그럼 시작해보겠습니다.
+
+## 1. Docker-Compose는 무엇인가?
+
+<div align="center">
+<img width="692" alt="image" src="https://raw.githubusercontent.com/Kernel360/blog-image/main/2024/0117/2.png">
+</div>
+
+아마 Docker를 공부하다 보면 Docker-Compose에 대해서 이름은 들어보셨을 거라 생각됩니다. 제가 처음 Docker-Compose를 접하게 되었을 때 느꼈던 점은 사용만 할 줄 안다면 좋은 툴이 될 것 
+같은데 그 과정이 쉽지 않을 것 같다는 생각이 정말 많이 들었습니다. 
+
+그래서 이러한 생각을 좀 줄여 보고자 MySQL을 예로 들어 Docker-Compose를 작성해 보겠습니다.
+
+## 2. Docker-Compose로 MySQL 실행하기
+
+<div align="center">
+<img width="692" alt="image" src="https://raw.githubusercontent.com/Kernel360/blog-image/main/2024/0117/3.png">
+</div>
+
+다음 사진은 MySQL을 실행시키기 위한 docker-compose.yml 파일의 내용입니다. 다음은 설명입니다.
+|옵션|설명|
+|------|---|
+|image|docker를 실행할 image:tag를 설정합니다. ex) ubuntu, linux, mysql, postgresql ...|
+|ports|port를 설정하는 옵션으로 [host port]:[container 내부 port]를 의미합니다.|
+|environment|container를 실행할 때 환경 변수를 추가한 상태로 실행할 수 있습니다. 각 이미지마다 환경 변수가 다를 수 있어 확인한 후 사용해야 합니다. ex) MYSQL_ROOT_PASSWORD: 1234 |
+|command|컨테이너를 실행 한 후 내부에서 명령어를 실행해 적용할 수 있습니다.|
+|volumes|마운트를 지정하게 되면 이후 컨테이너가 종료되거나 삭제되더라도 이후 연결되는 컨테이너가 같은 경로에 마운트 된다면 이전 데이터를 받을 수 있습니다.|
+
+어떤가요? 이렇게 보면 docker-compose라는 것은 단순하게 script의 형태를 띄기 때문에 각각의 의미만 안다면 어렵지 않습니다. 이제 간단하게 해봤으니 DB replication도 진행해보도록 하겠습니다.
+
+## 3. MySQL DB replication 구성해보기
+
+DB replication을 진행하기 전에 간단하게 replication에 대해 알아보겠습니다.
+
+DB replication은 데이터 저장과 백업하는 방법에 관련이 있는 데이터를 호스트 컴퓨터에서 다른 컴퓨터(컨테이너)로 복사하는 것을 의미합니다. 그렇다면 왜 필요할까요?
+
+서비스를 운영함에 있어서 읽기에 대한 요청은 읽기 이외의 요청 (생성, 수정, 삭제)에 비해 많은 비중을 가지게 됩니다. 그렇기 때문에 읽기에 대한 요청을 전담하여 맡아줄 DB를 생성해 DB로 하여금 부하를
+감소시킬 수 있도록 역할을 할 수 있습니다.
+
+<div align="center">
+<img width="692" alt="image" src="https://raw.githubusercontent.com/Kernel360/blog-image/main/2024/0117/4.png">
+</div>
+
+다음 사진은 이제 진행할 db replication의 파일 구조입니다.
+위 파일 구조는 master-slave가 1 대 1로 되어 있지만 설정에 따라 N 대 N이 될 수도 있습니다.
+
+![image.jpg1](https://raw.githubusercontent.com/Kernel360/blog-image/main/2024/0117/5.png) ![image.jpg2](https://raw.githubusercontent.com/Kernel360/blog-image/main/2024/0117/6.png)
+
+위의 스크립트는 순서대로 master-db와 slave-db의 Docker-Compose의 내용이다. 위에서 설명하지 않는 옵션은 다음과 같습니다.
+
+|옵션|설명|
+|------|---|
+|build| context는 build를 실행한 경로를 dockerfile은 dockerfile이 위치한 경로를 입력해주면 됩니다.|
+|restart|재시작과 관련한 옵션으로 현재 항상 재시작한다는 옵션으로 지정되어 있습니다.|
+|networks|docker에는 network를 통해 컨테이너 간의 연결을 진행하고 데이터를 주고받을 수 있으며 기본값은 bridge network입니다.|
+
+docker-compose.yml파일 외에도 my.cnf와 Dockerfile이 있는데 이때 Master와 Slave의 차이는 파일 경로와 읽기 전용 옵션 외에는 동일하여 Master를 기준으로 보겠습니다.
+
+<div align="center">
+<img width="692" alt="image" src="https://raw.githubusercontent.com/Kernel360/blog-image/main/2024/0117/7.png">
+</div>
+
+Dockerfile에서 내용은 다음과 같습니다.
+
+|옵션|설명|
+|------|---|
+|FROM|컨테이너의 환경을 지정하는 옵션으로 mysql이미지를 실행한다는 의미입니다.|
+|ADD|host에 위치한 파일을 컨테이너 내부 위치에 추가한다는 의미입니다. mysql의 configure 파일을 교체하여 내가 정한 규칙대로 실행되도록 합니다.|
+
+my.cnf 파일의 내용입니다.
+
+<div align="center">
+<img width="692" alt="image" src="https://raw.githubusercontent.com/Kernel360/blog-image/main/2024/0117/8.png">
+</div>
+
+현재 있는 파일에서 초록색 표시가 되어있는 read_only 옵션은 Slave-db가 가지고 있는 옵션으로 읽기 전용으로 사용하기 위한 옵션입니다.
+
+이렇게 준비가 되었다면 docker-compose up -d 명령어를 통해 실행을 시키면 다음과 같은 log와 설정을 볼 수 있습니다.
+
+<div align="center">
+<img width="692" alt="image" src="https://raw.githubusercontent.com/Kernel360/blog-image/main/2024/0117/9.png">
+</div>
+
+성공적으로 build가 되었다면 이제 db로 접속하여 설정을 진행해주어야 합니다.
+
+<div align="center">
+<img width="692" alt="image" src="https://raw.githubusercontent.com/Kernel360/blog-image/main/2024/0117/10.png">
+</div>
+
+replication에 대한 유저를 생성하고 권한을 부여하는 과정입니다.
+
+<div align="center">
+<img width="692" alt="image" src="https://raw.githubusercontent.com/Kernel360/blog-image/main/2024/0117/11.png">
+</div>
+
+권한 부여 이후에는 Slave DB에서 Master DB로 바라볼 수 있도록 설정을 수정합니다.
+
+<div align="center">
+<img width="692" alt="image" src="https://raw.githubusercontent.com/Kernel360/blog-image/main/2024/0117/12.png">
+</div>
+
+설정을 진행한 이후 아래 명령어를 통해 동일한 내용이 나온다면 성공적으로 설정된 것을 볼 수 있습니다. 
+
+<div align="center">
+<img width="692" alt="image" src="https://raw.githubusercontent.com/Kernel360/blog-image/main/2024/0117/13.png">
+</div>
+
+Docker를 사용하여 replication을 진행하는 과정은 이렇게 마무리할 수 있습니다. 긴 과정일 수 있지만 실제로는 dockerfile과 docker-compose.yml, my.cnf만 여러 개 둔다면
+규모가 큰 DB replication도 가능하기 때문에 오히려 구성하기 어렵지 않았다고 생각됩니다. 
+
+하지만 개발자 입장에서 개발에 더 몰입할 수 있도록 간단하게 구성할 수 있는 서비스가 AWS RDS입니다.  
+
+## 4. AWS RDS란?
+
+AWS RDS(Amazon Relational Database Service)는 aws에서 제공되는 서비스로 MySQL 뿐만 아니라, PostgreSQL, Aurora, Oracle 등 여러 DB를 간단하게 구현할 수 있습니다.
+단일 구성 뿐 아니라 위에서 진행했던 DB replication도 보다 쉽게 구성할 수 있습니다. 그럼 AWS RDS로도 DB replication을 구성해 보도록 하겠습니다.
+
+## 5. AWS RDS replication 구성해보기
+
+처음 AWS에 접속하여 RDS로 이동하면 다음과 같은 화면을 볼 수 있고 데이터베이스 생성 버튼을 누릅니다.
+
+<div align="center">
+<img width="692" alt="image" src="https://raw.githubusercontent.com/Kernel360/blog-image/main/2024/0117/14.png">
+</div>
+
+그 다음 여러 엔진 유형 중 제가 생성하고자 하는 MySQL을 선택하고 Database명, 비밀번호 등을 설정합니다.
+
+<div align="center">
+<img width="692" alt="image" src="https://raw.githubusercontent.com/Kernel360/blog-image/main/2024/0117/15.png">
+</div>
+
+이때 외부에서 접속하고자 한다면 퍼블릭 엑세스를 예로 채크해야 합니다. 이렇게 설정을 마치고 생성을 진행하면 5 ~ 10분 정도를 기다리면 생성이 완료 됩니다.
+
+<div align="center">
+<img width="692" alt="image" src="https://raw.githubusercontent.com/Kernel360/blog-image/main/2024/0117/16.png">
+</div>
+
+생성이 완료되면 생성된 DB를 선택하고 작업에서 읽기 전용 복제본 생성을 진행하고 위의 생성과정을 반복합니다.
+
+<div align="center">
+<img width="692" alt="image" src="https://raw.githubusercontent.com/Kernel360/blog-image/main/2024/0117/17.png">
+</div>
+
+이렇게 하면 자동으로 RDS 내에서 master와 slave가 적용되며 db를 동일하게 백업하고 저장되는 것을 확인할 수 있습니다.
+Docker를 사용하는 것도 간단해 보였지만 AWS RDS를 사용하니 더욱 간단하게 구현을 마무리할 수 있었습니다.
+
+## 6. 마무리
+
+결론은 AWS RDS로 구현하는 것이 간단하다가 아닌 Docker를 통해서 구성하는 것을 토대로 AWS RDS를 이해하는 시간이 되었으면 좋겠습니다. (물론 개념적인 부분에 대한 설명이 부족하지만 ...)
+이러한 과정을 반복하는 것 만으로도 전체적인 흐름을 이해하는데 도움이 될 것이라고 생각합니다. 
+끝까지 읽어주셔서 감사합니다.