동료의 작업물을 리뷰해야할 일이 생길 때, 가장 먼저 보게 되는 것이 코드보다 Pull Request (이하 PR)의 내용이다. PR 내용은 코드를 마주하기 전 내 작업물을 동료에게 소개하는 일종의 제안서라고 볼 수 있다. 그런데 협업을 하다보면 개인의 성향마다 이 내용이 편차가 생기기 마련이다. 개개인별로 PR에 대한 작업 설명이 상이하게 되면, 리뷰어 또한 PR을 확인할 때 해당 작업 결과물에 대한 사전 이해도도 상이하게 된다. 이를 방지하고자 Github에 PR을 올릴 때 공통 Template을 적용하여 작업물에 대한 이해도를 평준화시킬 수 있다. TL;DR Github에 PR 템플릿을 적용하면 작업물에 대한 이해도를 평준화시킬 수 있으며, 리뷰어는 작업자가 어떤 의도로 작업을 했는지에 대해 이해도..
개발
팀의 프로젝트 레포지토리를 살펴볼 때, 협업 인원이 많을수록 코드의 일관성이 깨지는 경우가 많았다. lint 한 번을 돌려봐도 사용하지 않는 변수가 속출하고, 곳곳에 타입이 명시 되지 않는 경우도 있다. 이러한 환경에서 협업 인원이 더 늘어나면 코드 퀄리티를 유지하기가 더욱 어려워질 수 밖에 없었다. 따라서 그라운드 룰을 적용하여 코드 퀄리티를 유지할 수 있는 라이브러리 도입이 필요했다. TL;DR husky를 도입하여 팀에서 정의한 그라운드 룰에 따른 코드 퀄리티를 보장할 수 있다. 이는 팀워크 향상과 버그 감소에도 기여할 수 있고, 새로운 팀원이 합류하게 되어도 쉽게 코드 퀄리티를 유지할 수 있다! 이 글에서 다루는 것 팀의 코드 일관성 보장 과정 husky 설치 git hook의 pre-commit..
언젠가 docker 배포를 했을 때 아래와 같은 에러가 발생하여 당황스러웠던 적이 있었다. ERROR: for failed to register layer: Error processing tar file(exit status 1): write /app/node_modules/typescript/lib/tsserver.js: no space left on device ERROR: failed to register layer: Error processing tar file(exit status 1): write /app/node_modules/typescript/lib/tsserver.js: no space left on device no space left on device 즉, 용량이 부족해서 배포가 되..
도커 컨테이너 내부 파일에 오류가 생기면 컨테이너를 실행할 수가 없다. 이럴 경우 도커 내부에 들어갈 수도 없는 상황이 벌어져서 수습을 하기가 어려운데, 우회적으로 도커 컨테이너의 내부 파일을 수정하는 방법을 안내하고자 한다. 준비물 오류가 난 도커 컨테이너 수정 방법 도커 컨테이너 내부 파일을 수정하기 위해 우선 도커 컨테이너의 파일을 복사하여 다시 도커 컨테이너로 넣는 방식을 이용한다. 1. 우선 도커 컨테이너의 목록을 먼저 확인한다. docker ps -a 2. 도커 컨테이너 ID를 확인 후, 복사할 파일의 경로를 입력하고 현재 호스트에 붙여 넣을 경로를 지정한다. docker cp containerid:컨테이너파일경로/붙여넣을호스트경로 3. 붙여넣을 호스트 경로에 컨테이너 파일이 있는지 확인하고 ..
CI/CD는 이제 조직의 생산성을 위한 필수 요소가 되었다. CI를 구성하기 위해 jenkins, github-actions, gitlab-runner 등이 있다. 이 글에서는 CI를 파이프라인을 구성하기 위한 요소로 gitlab-runner를 등록하는 방법에 대해 작성해보겠다. 여기서는 각 프로젝트 별 Specific runners를 등록하는 방법으로 진행한다. 준비물 1. gitlab 계정과 프로젝트 2. gitlab-runner를 설치할 머신이나 인스턴스 (도커가 설치되어있어야함) 이 글에서의 설치 환경 ubuntu 20.0.4 인스턴스에 gitlab-runner 설치하기 gitlab-runner를 설치하는 방법에는 여러 가지가 있지만 여기서는 dind (docker in docker) 방식으로 설..
Airflow 설치 $ pip install apache-airflow Airflow 세팅 1. AIRFLOW_HOME 환경 변수 세팅 기본으로는 ~/airflow에 환경 세팅이 되기 때문에, 나의 경우에는 현재 경로에 AIRFLOW_HOME 환경 변수를 별도로 지정했다. 경로를 잘 지정하지않으면, airflow의 유저 권한이 없기 때문에 정상적으로 작동하지 않는다. export AIRFLOW_HOME=`pwd` # Airflow 현재 경로에 환경 변수를 설정한다. 2. airflow db 세팅 기본적으로 mysqllite로 세팅이 된다. airflow db init을 여러번 해도 괜찮다고한다.(참고 자료) $ airflow db init 3. 유저 생성하기 airflow users create \\ -..
AWS Cloud watch에서는 인스턴스나 기타 서비스에 대한 성능 지표들을 확인할 수 있다. 하지만 인스턴스 내부 시스템 지표는 수집할 수가 없다. 따라서 이러한 지표를 확인하기 위해 외부 솔루션(datadog, newrelic)이나 AWS에서 제공하는 Cloud watch Agent를 설치하여 확인할 수 있다. 나는 단순히 메모리 지표 확인을 위해, 가장 설치하기 쉬운 Cloud watch Agent를 선택하였다. Cloud watch Agent에서 수집할 수 있는 지표 세부 정보 수준 포함된 지표 기본 Mem: mem_used_percent Disk: disk_used_percent disk와 같은 disk_used_percent 지표에는 Partition의 측정기준이 있는데, 이는 생성된 사용자..
AWS OpenSearch로 document를 쌓다보면 mapper_parsing_exception 에러를 마주할 수 있다. mapper_parsing_exception 에러는 지정한 index에 document를 쌓을 때, 지정된 document의 data type에 새로 넣으려는 data의 type이 parsing되지 않아 발생하는 에러이다. 이 글에서는mapper_parsing_exception 에 어떻게 대처했는지 STAR 기법에 적용하여 작성하고자 한다. Situation (주어진 상황) 현재 개발서버에서 API 통신을 주고 받는 로그를 전부 AWS OpenSearch로 쌓고 있다. 하나의 통신이 끝난 뒤 가장 마지막 과정에서 OpenSearch로 로그를 전송하는 형태이다. 그런데 특정 API를..
OpenSearch란? OpenSearch는 ElasticSearch 기반 오픈 소스 검색 및 분석 제품군이다. 주로 어플리케이션 모니터링, 로그 분석 및 시각화와 같은 곳에서 쓰이고 있다. AWS Opensearch 설치 OpenSearch를 사용하려면, domain을 먼저 세팅해야한다. 여기서 domain은 OpenSearch의 클러스터이다. 콘솔을 활용한 domain 생성 1. AWS 콘솔에 로그인한 후, Amazon OpenSearch Service로 진입한다. 2. Create domain을 클릭한다. 3. domain 세팅에 필요한 정보들을 입력한다.여기서는 테스트용 domain이기 때문에 t3.small.search의 인스턴스 유형을 세팅하고, 퍼블릭 엑세스에 마스터 계정을 생성하였다. 만약..
우선 Airflow에 BigQuery 같은 3rd Party tool을 연동하려면, Airflow의 Providers packages를 설치해야한다. 아래는 지원하고 있는 Provider list이다. 그런데 애초에 Airflow를 설치할 때, 이런 Providers를 같이 설치하는 명령어가 있다. 진작 이걸 쓸 걸 그랬다..... 너무 queck start만 보지말고, 공식 문서를 꼼꼼히 보자 AIRFLOW_VERSION=2.1.2 PYTHON_VERSION="$(python --version | cut -d " " -f 2 | cut -d "." -f 1-2)" CONSTRAINT_URL="" pip install "apache-airflow[async,postgres,google]==${AIRFLO..