Jost Do It!

문제 상황 보통 클릭하우스 configuration 파일(config.xml)에서 변수를 변경하면 자동으로 반영이 되지만 xml 파일을 함부로 수정하기엔 문제가 발생할 수 있어 쉽지 않다. 따라서 직접적인 xml 파일 수정 없이 클릭하우스 config를 변경하고, 반영이 잘 되었는지 확인할 방법이 필요했다. 해결 방법 클릭하우스 클라이언트를 이용해 설정할 수 있다. 먼저 클릭하우스 클라이언트의 옵션 정보들을 아래 명령어로 출력할 수 있다. clickhouse-client --help 이를 출력해보면 아래처럼 다양한 옵션을 설정할 수 있는 것을 확인할 수 있다. Main options: --help produce help message -V [ --version ] print version informat..

문제상황 컨테이너 내에서 cat 명령어로 파일 내용을 확인하기 불편해서 텍스트 편집기 vim을 설치하려고 하니 아래의 에러가 나타났다. >> apt-get install vim Reading package lists... Done Building dependency tree... Done Reading state information... Done E: Unable to locate package vim 구글링해보니 아래와 같이 해결가능하다고 한다. 해결방안 apt-get update apt-get install apt-file apt-file update apt-get install vim # now finally this will work !!! 내용을 살펴보니 apt-get으로 설치하는 파일들을 관..

문제 상황 카프카 환경을 구축하면서 confluent 가이드에서 제공하는 `docker-compose.yml` 파일을 이용하게 되었다. 해당 파일은 카프카와 관련된 여러 컴포넌트 이미지들을 포함하는데, 각 이미지들의 세부 사항들을 확인하기 어려웠다. 특히 컨테이너를 띄우면 컨테이너 내부의 파일들을 디스크에 마운트하고 싶었는데, 어떤 내부 파일들을 마운트해야 하는지, 이미지에서 기본적으로 마운트하는 폴더들은 무엇인지 확인하기 어려웠다. confluent에서 제공하는 docker-compose.yml 파일 version: '2' services: zookeeper: image: confluentinc/cp-zookeeper:6.2.1 hostname: zookeeper container_name: zooke..

[chatGPT와의 대화 내용] (1번 질문) `conda run`은 무슨 명령어야? `conda run`은 Conda 환경 안에서 실행할 수 있는 명령어입니다. `conda run` 명령어를 사용하면 Conda 환경 내에서 명령어를 실행하며, Conda 환경 외부의 패키지와 충돌하지 않도록 보호됩니다. `conda run` 명령어의 일반적인 사용법은 다음과 같습니다. conda run [OPTIONS] COMMAND [ARGS] 여기서 `OPTIONS`는 conda run 명령어의 옵션을 나타내며, `COMMAND`와 `ARGS`는 실행할 명령어와 인수입니다. 예를 들어, 다음 명령어는 myenv라는 Conda 환경에서 python 명령어를 실행합니다. conda run -n myenv python m..

너무좋다 챗지피티... 갓갓 [ChatGPT와의 대화내용] airflow의 trigger_rule에 대해 알려줘 Airflow의 trigger_rule은 DAG 내의 작업(Task)간 종속성(Dependency)을 정의하는데 사용됩니다. trigger_rule은 이전 Task의 실행 결과를 기반으로 다음 Task의 실행 여부를 결정하는 규칙(rule)입니다. trigger_rule은 Task 객체의 인수로 설정됩니다. 기본값은 all_success입니다. 다음은 trigger_rule의 종류와 각각의 의미입니다. all_success: 이전 Task가 모두 성공했을 때 실행합니다. 이전 Task 중 하나라도 실패하면 실행하지 않습니다. all_failed: 이전 Task가 모두 실패했을 때 실행합니다. ..

[아래는 ChatGPT와 나눈 대화내용] 파이썬에서 에러 로그가 airflow에서는 INFO정보로 뜨는데 왜그래? Airflow는 기본적으로 로그 레벨이 INFO로 설정되어 있기 때문에, 파이썬에서 발생한 에러 로그도 INFO 레벨로 출력됩니다. 이는 Airflow가 파이썬 코드를 실행하는 방식 때문입니다. Airflow는 DAG(Directed Acyclic Graph)을 기반으로 작업을 스케줄링하며, 각 작업은 PythonOperator, BashOperator, DockerOperator 등의 Operator를 통해 실행됩니다. 이 때, Operator 내부에서 파이썬 코드를 실행하면서 발생하는 에러 로그도 Airflow에서 INFO 레벨의 로그로 처리됩니다. 하지만, 이러한 로그 레벨을 변경할 수..

문제 상황 에어플로우 BashOperator를 통해 작업을 dag에 걸어줬을 때, 에러가 발생했음에도 정상적으로 작동됐다고 체크된 경우가 있었다. 위 경우도 원래 4초짜리 task가 절대 아님에도 4초만에 정상적으로 작동이 완료됐다고 나와 에러 발생이 의심되는 상황이었다. 그래서 로그를 살펴보니 특정 라이브러리 로드를 안해줘서 에러가 발생함을 알 수 있었다. 그럼 왜 Airflow는 해당 dag에서 에러가 발생했음에도 정상적으로 작동했다고 결과를 출력한 것일까? 문제 발생 이유 파이썬같이 우리가 익숙한 프로그래밍 코드는 순차적으로 코드를 실행하다가 특정 line에서 에러가 발생하면 해당 line에서 에러를 발생시키고 실행을 멈추게 된다. 즉, 뒷 line은 실행하지 않는다. 하지만 Bash shell에서..

깃은 디폴트(메인) 브랜치에서 여러 브랜치를 파생할 수 있다. 여러 브랜치로 파생하여 메인 브랜치의 내용들과 충돌 없이 파생된 브랜치에 코드 내용을 수정할 수 있다. 그리고 수정된 코드 내용들을 메인 브랜치와 통합할 때는 PR을 요청하여 깃헙 관리자가 이를 허용/거절하는 구조로 이루어진다. 그러면 이 브랜치를 어떻게 파생할 수 있을까? 깃 브랜치 생성 로컬에서 깃 브랜치를 생성하는 방법은 다음과 같다. 아래 명령어를 쉘의 로컬 깃저장소 위치에서 입력한다. git branch {생성할 브랜치명} 한편 메인 브랜치와의 충돌을 피하려면 메인브랜치의 최신 내용을 pull한 상태여야 한다. 이후에 브랜치에 커밋을 하여야 메인 브랜치와 충돌을 피할 수 있다. 깃 브랜치 변경 위 명령어는 로컬 깃 저장소에 새로운 브..

에러 내용 깃헙에서 workflow 내용을 수정하고 github 저장소에 push하니까 위 에러가 떴다. 내용은 다음과 같다. ! [remote rejected] {원격저장소 branch명} -> {원격저장소 branch명} (refusing to allow a Personal Access Token to create or update workflow `.github/workflows/code-style-check.yaml` without `workflow` scope) error: failed to push some refs to 'https://github.com/{원격저장소 링크}' 메세지 내용을 살펴보면 github에서 발급받은 개인 access token이 workflow를 수정할 수 있는 권한..

보통 회사에서 코드 작성을 마치면 바로 디폴트 브랜치에 코드 내용을 merge하지 않는다. 동료에게 먼저 코드 리뷰를 받는데, 보통은 1명 ~ 3명 내지의 동료들에게 코드 리뷰를 받는다. 코드 리뷰를 통해 내 코드에 이슈가 없는지, 수정하면 좋은 부분이 있는지 검토를 받고 문제가 없으면 디폴트 브랜치에 merge 하는 것을 승인 받는다. 위 과정을 Pull Request (PR)이라고 한다. 그럼 Github에서 PR을 하는 방법에 대해 알아보자. Github에서 Pull Request (PR) 요청 하기 PR전에 변경한 코드 내용들은 별도의 브랜치에 push된 상태여야 한다. 다음으로 PR을 할 Repository에 들어간다. 그리고 아래의 Pull Request 를 클릭한다. 그럼 아래의 화면이 뜬다..