GitHub Action에서 AWS OIDC 연동하기
TL DR; 1. Intro 2. 설정과정 2.1. Adding the identity provider to AWS 2.2. Configuring the role and trust policy 2.3. Updating your GitHub Actions workflow 2.4. 실제 파이프라인에 적용 3.Outro
Browse Posts
Tech
인프라, 플랫폼, 운영 기술을 주제별로 정리한 기술 글 모음입니다.
GitHub Action으로 EC2에 블루그린 배포 및 PR 코멘트
TL; DR 1. Intro 최근에 사이드 프로젝트를 하면서 로컬개발된 내용을 실제 배포환경에서도 동일하게 볼 수 있을지 파이프라인을 구성할 필요가 있었다. 프론트엔드부분의 경우 아직은 정적웹페이지 위주라 S3+Cloudfront를 사용한 Object storage+CDN 배포라던가 Vercel/Amplify 같은 SaaS? Managed? 서비스를 통해서 배포도 가능하다. 하지만 처음에 EC2로 시작한 이유는 어느정도 윤곽나오고 실제 배포단에서는 효율적 사용을 위해 S3+CDN으로 넘어갈 부분은 넘기고할듯 2. […]
Minikube service 파헤치기
TL DR; 1. Intro 로컬에서 간단히 Kubernetes 환경을 테스트 할 경우, VM을 생성하여 직접 구성하는 대신 Minikube, Kind 등과 같이 컨테이너 기반의 자동화된 클러스터 구성 도구를 사용하여 테스트 하곤 한다. 해당 도구로 생성된 클러스터의 경우, 클러스터 내부의 동작 (k8s 내 오브젝트 생성 편집 삭제 등)을 확인하고 테스트하기엔 적합하다. 그러나 호스트와 직접 연결된 VM 네트워크 대신 […]
MySQL binlog PITR w/xtrabackup
TL DR; 1. Intro Point-in-Time Recovery (PITR) 시점복구(PITR)은 데이터베이스 백업 및 복원 과정에서, 특정시점을 기준으로 변경사항을 복구하는 것을 의미한다. 일반적인 데이터베이스 백업은 일정 주기 (매일 자정등)를 기반으로 수행된다. 이를통해 장애등의 상황시 최대 24시간 내의 형상으로 복원할 수 있다. 그러나 이는 미리 사전에 수행되어야한다는 문제가 있다. 백업과 복원에 관해서 정책과 다른 다른 시점의 데이터베이스 형상이 필요하다면 […]
Galera SST ready node 추가하기
TL; DR 1. Intro On-prem MySQL 클러스터를 사용하면서, Master-Slave의 구조인 MySQL Replication 대신 Multi-Master 구조인 Galera cluster for MySQL을 사용하였다. M-S 구조의 Replication에서의 Master fail시 Failover하는 경우, Slave에서 완전히 동기화 되어있음/작동 성공의 불안함이 있다. 상대적으로 Multi-Master 구조의 Galera Cluster는 참여하는 노드들이 M/S 여부 상관없이 데이터를 받고 쓸수있다. 또한 binlogs-relaylog replay의 논리적인 방식 대신 rsync, xtrabackup […]
AWS Aurora 5.7에서 MySQL 5.7로 안전하게 데이터 복제하기
1. Intro 2. Syncronization Overview main cluster > target Server – X main RDS 클러스터에, 타겟 MySQL 서버를 추가시켜 필요한 데이터들을 복제 및 동기화하고 클러스터에서 분리하려는 초기의 계획은 버전 이슈로인해 원활히 작동 X main cluster > replica cluster > MySQL Server (instance) CDC (AWS DMS)를 사용해서, 클러스터의 운영에 필요한 테이블들은 제외하고, 실제 데이터가 생성되고 갱신되는 […]
AWS Aurora 5.7에서 MySQL 5.7로 복제 실패기
1. Intro 2. 실패) Aurora 5.7와 MySQL replication 둘다 동일한 MySQL 5.7 기반이므로 최초에는 단순히 두개 클러스터간 binlog replication을 설정하면 될것이라고 생각하였다. Ref) https://hoing.io/archives/2638 그러나.. Aurora 5.7과 설치형 MySQL 5.7간의 binlog replication은 원활히 수행되지 않는다. 3. Aurora 5.7은 MySQL 5.7인가 8.0인가 https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraMySQLReleaseNotes/AuroraMySQL.Updates.2124.html Aurora MySQL 2.12 버전은 MySQL 5.7.44까지 호환됩니다. 동일한 버전의 Database 서버이므로 두 서버간 […]
Github action Tool caching으로 작동시간 줄이기
TL;DR 1. Intro 2. 환경구성 기존의 k8s-runner와 동일한 환경구성에서 시작 기본적인 Runner로 구동시, 필요한 언어 등 환경을 가져오고 구동하는데 일정 시간이 소요된다. 목적은 이 시간을 줄이는 것이다 3. Tool caching to Runner Image Building GitHub Actions Runner Images With A Tool Cache Github Action Runner에서 빌드환경은 actions/setup-* 류의 marketplace action을 사용하여 구성되곤한다. 해당 액션 사용시 […]
Self-hosted Github Action Runner Custom하게 사용하기
1. Intro 이전글을 통해서 Self-hosted ARC 환경을 구성해보았다. 그러나 단순히 환경을 구성하고 동작을 테스트하는것과 실제로 사용가능하게 환경 구성을 설정하는 것은 다르다. GitHub Action 문서에서 또한 기본 구성외에 추가적인 도구 구성은 사용자의 책임으로 정해두고 별다른 가이드라인을 제공하지않는다. Runner의 package는 어떻게 구성해야할까? 관련된 글도 많이 없었고 삽질했던 내용들을 정리해두고자 한다 2. Self-hosted Runner values 배포 이전글에서는 간단히 […]
Self-hosted Github Action Runner로 GitHub 사용 비용 줄이기
TL DR: 1. Intro GitHub 기반의 환경에서 개발 환경을 구축할 경우, CI/CD 파이프라인 도구에 있어 Jenkins와 같은 별도 시스템을 외부에 구축하기도 하나, GitHub 환경과 긴밀히 통합되어있는 GitHub Action의 사용을 고려하기도 한다. 그러나 GitHub이 호스팅하는 GitHub-Hosted Runner의 경우 무료가 아니다. Enterprise 등급을 제외하고는 전체 파이프라인 작동시간에 대해 월간 2,000~3,000시간에 대해서 무료이지만, 그 외의 추가 사용시간에 대해 […]
GitLab Memory 소모량 줄이기
1. Intro GitLab 설치 문서에서 확인할 수 있는 Memory 최소량은 4GB(~사용자 500명)에서 8GB(~사용자 1,000명) 이다. 그러나 실제 내부 환경에서 GitLab을 구축하고 테스트 하는 과정에서, 실제로는 훨씬 더 많은 메모리를 소모하는 것을 확인할 수 있었다. 이런저런 작업을 하던 중 GitLab Web UI가 느려져서 서버 상태를 확인해보니 다음 사진과 같이 서버의 메모리를 거의 최대까지 잡아먹고 있는 것을 […]
Kubernetes etcd 내부의 데이터 까보기
Intro Kubernetes의 기본 아키텍처를 살펴보면 내부 데이터 저장을 위해 etcd라는 별도의 K-V store를 사용한다. k8s의 Pod Scheduling Workflow를 살펴보면, api-server로 요청된 구성을 etcd에 desired state로 등록한뒤, controller가 current state와 desired state를 맞추기 위한 조정을 수행하여 Pod가 생성된다. 일반적으로 명령어(cli)나 구성파일(YAML)의 형식으로 리소스를 정의해 api-server에 전송하여 실행한다. 이때 실제로 etcd에는 data가 어떤식으로 저장되는지 궁금해졌다. 하지만 일반적으로 […]