세상의 모든 데이터

docker 개발 프로세스

• docker화 할 대상과 범위 선택 :  다수의 컴포넌트라면 각각 docker image가 필요할수 있음
• docker 파일 : 기본적으로 텍스트 파일, 기본 소프트웨어(from), 어떤 프로그램 설치할건지(run), 어떻게 실행할건지
  예) 음식의 레시피, 계량법, 요리도구 까지 상세한 정보들 
• docker 파일이 만들어지면 -> docker화 해서 -> image 제작

docker image 구성 요소

• 기본 os(리눅스라면 우분투, 데비안 등) 같은 소프트웨어 실행환경
• 소프트웨어 코드 및 소프트웨어 동작에 필요한 라이브러리
• 파일 시스템 스냅샷 : 특정 시점의 상태를 캡처하여 백업, 데이터 손실을 방지하거나 롤백 및 테스트 목적으로 사용된다. 스텍화된 형태로 구현된다.
• 환경 설정 변수 : 빌드할 때 변수, 실행할때 변수 (ENG, ARB 이후 더 설명)
• 메타데이터 : 이미지 자체에 대한 정보( 버전, 작성자 등 설명)
• docker image ls 명령어로 조회 가능
• image를 다른환경에서 container를 통해 실행
  예) 에어프라이어용 냉동 식품 -> 각 집의 에어프라이어에서 조리 가능 

docker image 공유 하기

• on-prem registry : 기업 내부에서 호스팅되는 도커 이미지 저장소로, 보안 및 데이터 제어를 강화하며 내부 네트워크에서 동작
  
  
• cloud registry : 클라우드 플랫폼에서 제공되는 도커 이미지 저장소로, 확장성과 유연성을 제공하여 클라우드 기반 애플리케이션 배포에 적합 (docker hub가 유명)
  

  

docker hub

• 도커 업계의 깃허브 느낌 , 전체 공유 부분공유 가능
• 레포를 만들고 push , pull 등 가능하다. (docker 데스크탑과 연동)
• 도커 이미지 만드는 과정(소스코드는 깃헙과 공유)
• 만들고 나서는 도커허브 이용 

Docker desktop 설치링크 : http://docs.docker.com/get-docket 

필요한것 : 여유 램 4GB 이상, 윈도우 10 이상, Hyper-v와 container 기능 활성화, wsl 설치

설치 :  설정 기본 값으로 쭉쭉

정상설치 확인 : 

ㅋㅋ 별거 없어 ㅈㅅ

내가 만든 프로그램이 다른 컴퓨터에서는 안돌아간다면?

1. 설치 과정에서 중요한 파일이 빠질수 있음
2. 운영체제가 다르고, 다른 버전이 설치되면 라이브러리 버전간 호환이슈 발생

일정하게 똑같은 환경에서 만들어 주는법 (like 밀키트)

1. 도커 이미지(모듈 버전등 환경변수)와, 도커 컨테이너(도커이미지+운영시스템) 필요
   예) 중화요리 밀키트(도커이미지)를 웍(도커 컨테이너) 에서 센불로 요리해야 제맛!

Virtual Machine(docker 등장 이전의 강자) 

• 예 ) EC2가 대표적인 VM, 맥 컴퓨터 위에서 윈도우, 리눅스들 가상 운영체제를 돌리는 경우
• VM 구조 : 호스트 os(macitosh) 위에 VM 관리 툴( hypervisors) 가 필요하고, 그 위에 운영체제
• VM 장단점
  장점 : 독립적이고 분리된 공간 제공, 다수의 소프트를 각 VM에서 독립적으로 실행가능
  단점 : 각 os 별로 비용, VM끼리 cpu,램, 용량들을 나눠야 해서 성능이 떨어짐

docker container

• docker의 운영체제는 일반 운영체제에 비해서 경량화 됌(필요한 만큼만 사용)
  
  
• Docker 제작시 사용한 호스트 OS와, 그 컨테이너 가 호환되는 OS 
  맥 : 경량화 리눅스 / 윈도우 : 윈도우, 리눅스 / 리눅스 : 리눅스 only
  +리눅스는 어디서 만들든 다 사용할수 있음
  
  
• 장점
  1) 각 컨테이너 별로 독립적이고 분리된 공간, 소프트 각각 실행도 가능
  2) 수십 수백 컨테이너 사용시 , 각각 따로 구현에 비해 자원소비가 적음
  3) 별도의 os 라이센스 비용 필요없고, 경량화 os라 빠르게 실행됨
• 단점
  1) 많은 컨테이너 관리 쉽지 않음
  2) 컨테이너 제작 os, 동작 os 간의 호환성 이슈
  3) GUI 소프트 개발에 적합치 않음(VM이 더 적합)

airflow를 운영할때 운영상의 어려움

1. dag 늘어날수록, 모듈들간의 호환성 출돌 이슈
   + 수가 늘어날수록 해결하기가 불가능에 가까워짐
   
   
2. dag 늘어날수록 worker 부족
   +싱글노드에서 멀티노드로 변화(서버증가)
   
   
3. 바쁠때와 아닐때의 차이에 의해 서버낭비 발생 (내돈!!)
   +docker와 쿠버네티스가 도움이 될것임

위 문제들을 해결하는 방법

1. 충돌이슈 : dag, task 코드를 docker image로 만들고 독립공간(docker 컨테이너) 을 만들어 실행
   +개발환경과 프로덕션 환경을 동일하게 유지 가능
2. worker 부족 :
   서버 사양 높이기(scale up),
   
   서버분리후 증가(scale out)는 보통 aws 같은 클라우드 서비스,
   
   쿠버네티스(k8s) 컨테이너 기술(필요할때 받아서 사용하고 반납)
   +전용 서버를 할당할 필요가 없음(배민라이더 인해 배달원 따로 고용 x)
3. 서버낭비 : 쿠버네티스(k8s) 를 사용!
   
   

그래서 구체적으로 어떻게 해결하는데?  (airflow에서 다음 방식으로 문제들을 해결하자)

1. airflow operator로 kubernetespod operator, dockeroperator  사용
   KubernetesPodOperator : ubernetes 클러스터에서 실행되는 작업을 정의하는 데 사용, 각 작업은 Kubernetes Pod 내에서 실행되며, 컨테이너 이미지, 리소스 할당 및 다른 Kubernetes 설정을 지정할 수 있다.
   
   dockeroperator : 로컬 또는 원격 Docker 환경에서 실행되는 작업을 정의하는 데 사용, 각 작업은 Docker 컨테이너 내에서 실행되며, 사용할 이미지, 환경 변수 및 다른 Docker 설정을 지정할 수 있다
   
2. airflow executor(task들을 관리하고 실행)을 아래를 3개 사용
   kubernetes Executor: Kubernetes의 강력한 컨테이너 오케스트레이션 기능을 활용하여 확장성이 뛰어나며 동적으로 자원을 할당
   
   celerykubernetes E :  Celery의 확장성과 Kubernetes의 컨테이너 관리 기능을 모두 활용
   
   localKubernetes E : 로컬 개발 머신에서 Kubernetes 클러스터를 모사하여 실행하는 에어플로우 실행자
   
   + 그외 Executor 들
   sequential executor : 병렬 처리가 없어 단일 프로세스 내에서 작업이 실행, 성능이 낮지만, 테스트 및 디버깅 용이
   local executor : 로컬에서 병렬로 여러 작업을 실행하는 에어플로우 실행자
   celery executor : Celery는 분산 작업 큐 시스템으로, 여러 워커에서 동시에 작업을 처리할 수 있도록 지원