Jost Do It!

OS 요구 사항 64bit의 우분투 운영체제가 설치돼야 하며, 아래 버전 중 하나여야 한다. Ubuntu Mantic 23.10 Ubuntu Lunar 23.04 Ubuntu Jammy 22.04 (LTS) Ubuntu Focal 20.04 (LTS) 도커 관련 패키지 삭제 설치된 도커 관련 패키지들이 있으면 충돌을 일으킬 수 있으므로 아래 명령어로 삭제를 먼저 진행한다. for pkg in docker.io docker-doc docker-compose docker-compose-v2 podman-docker containerd runc; do sudo apt-get remove $pkg; done 참고> 위 명령어는 설치된 관련 패키지들만 제거하므로 기존 도커 엔진 자체를 제거하고 싶으면 이 링크를 ..

문제상황 컨테이너 내에서 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와의 대화내용] 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에서..

도커 이미지를 생성하는데 사용된 명령어들을 확인하고 싶을 때 docker history를 사용할 수 있다. 명령어는 아래와 같다. docker history 여기서 {:버전명}은 생략 가능하고, 생략 시 가장 최신의 repository의 image history를 가져온다. 옵션 리스트는 아래와 같다. --quite or -q: 이미지의 ID만을 출력한다. --no-trunc: 생략된 부분들을 모두 출력한다. 옵션에서 확인할 수 있듯이 default로 너무 긴 경우는 생략해서 출력한다. 출력 결과 1. 기본 명령을 사용해 출력한 결과 아래와 같다. IMAGE ID, 생성 시간, 생성 이유, 크기, Comment를 출력한다. 생성 이유에서 명령어 (or 이미지) 내용을 확인할 수 있다. 각 명령어들은 하나..

도커 이미지 ID를 이용해 a252344b0747 이미지(A)를 제거하려고 할 때, docker rmi a252344b0747 다음 에러가 발생했다. 즉, 다른 이미지가 A 이미지를 사용해서 이미지가 생성되었기 때문에 제거가 어렵다는 에러이다. 이를 해결하기 위해서 먼저 A 이미지를 부모로 두고 있는 자식 이미지를 확인해야 한다. 아래 명령어를 통해 A 이미지를 포함해 A 이미지 이후 생성된 모든 이미지들의 이미지 ID와 부모 ID를 출력할 수 있다. # a252344b0747 이미지(A)에 대해서 출력 docker inspect --format='{{.Id}} {{.Parent}}' $(docker images --filter since=a252344b0747 -q) 결과는 아래처럼 출력된다. 여기서 ..

docker의 이미지를 생성하다보면 Repository명과 Tag 값이 으로 기재된 dangling image가 생성된다. dangling image는 도커 이미지 생성 과정 중에서 에러가 발생하거나 중간에 중단되게 되면 생기는 이미지로 쓸모없는 부산물이다. 이미지 리스팅 시 보기 불편하기 때문에 정리를 해줄 필요가 있다. none image를 모두 제거하는 코드는 아래와 같다. docker rmi $(docker images -f "dangling=true" -q) 참조 https://web-front-end.tistory.com/102

도커 컨테이너를 detached mode (-d 옵션) 로 실행시킨 경우 백그라운드에서 실행되기 때문에 컨테이너 로그를 확인할 수 없다. 이 경우 아래의 명령어를 사용해 실행된 컨테이너의 지금까지 log 기록을 확인할 수 있다. docker container logs 컨테이너가 실행되었으면 아래와 같이 정상적으로 로그기록이 출력된다.