일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- CRAWL
- container
- Python
- Java
- Prototype
- 크롤링
- 쿠버네티스
- 테이블정의서
- spark
- MariaDB
- MSA
- Data Lineage
- RDD
- REST
- kubernetes
- atlas
- 파이썬
- dataset
- OkHttpClient
- 정규식
- 컨테이너
- replaceAll
- oracle
- microservice
- 스파크
- 도커
- okhttp3
- web crawl
- dataframe
- docker
- Today
- Total
J 의 기록
[Docker] 도커 컨테이너 본문
1. 도커를 이용한 애플리케이션의 컨테이너화
도커는 애플리케이션을 패키지로 만들어 구동하기 위한 세련되고 훌륭한 방법을 제공한다.
그러므로 도커는 현재 가장 인기있는 오픈 소스 프로젝트 중 하나로 자리잡게 되었다.
컨테이너 기술을 활용하면 애플리케이션을 클라우드 환경에 배치할 때 훨씬 효율적으로 처리할 수 있다.
컨테이너를 구동하는 운영체제도 컨테이너처럼 가볍게 만들 수 있다. 이렇게 컨테이너를 호스팅할 운영체제는 애플리케이션에 관련된 모든 의존성을 직접 책임질 필요가 없다. 애플리케이션 구동에 필요한 것들은 대부분 이미 컨테이너에 담겨있기 때문이다.
애플리케이션 컨테이너화의 장단점
도커는 애플리케이션을 컨테이너 안에 설정한 상태로 생성해서 구동한다.
그럼 VM (가상 머신)을 사용할 때에 비해 컨테이너의 장점은 무엇일까?
애플리케이션을 하나의 가상머신마다 구동시킬 때의 단점은 리소스를 많이 사용한다는 점이다.
컨테이너는 애플리케이션을 호스트에서 직접 구동하거나 가상 머신에서 실행할 때보다 훨씬 빠르고 이식성이 좋으며 확장성도 뛰어난 방법을 제공한다.
컨테이너를 이용해 애플리케이션을 구동하면, 유연성이 뛰어날 뿐만 아니라 리소스 사용의 효율성도 높다.
애플리케이션을 구동하는 데 필요한 파일을 모두 컨테이너에 담을 수 있기 때문에 유연성이 뛰어나다.
컨테이너에서는 애플리케이션 실행에 필요한 것과 컨테이너를 구동하는 데 필요한 도구나 소량의 메타데이터만 가지고 있으면 된다.
도커 컨테이너는 가상머신과 달리 별도의 커널을 가지고 있지 않다. 도커 컨테이너에서 실행하는 커맨드는 호스트의 프로세스 테이블에 표시되며, 호스트의 다른 프로세스와 비슷하게 나타난다. 호스트에서 실행되는 애플리케이션과 컨테이너에서 실행되는 애플리케이션의 차이점은 대부분 환경을 바라보는 관점에 관한 것이다.
- 파일 시스템 : 컨테이너는 별도의 파일시스템을 갖고 있으며, 호스트의 파일시스템은 볼 수 없다. 이 원칙에 예외가 있는데, (/etc/hosts 혹은 /etc/resolv.conf 같은) 일부 파일은 컨테이너에 자동으로 마운트된다. 또한 컨테이너 이미지를 구동할때 컨테이너 안에서 호스트의 디렉터리를 명시적으로 마운트할 수 있다.
- 프로세스 테이블 : 리눅스 기반의 호스트 시스템에서는 수백 개의 프로세스가 구동될 수 있다. 하지만 디폴트로는 컨테이너에 안에 있는 프로세스는 호스트의 테이블을 직접 볼 수 없고 프로세스 테이블을 따로 갖고 있다.
따라서 컨테이너를 구동할 때 실행되는 애플리케이션 프로세스는 컨테이너 내부에서 PID 가 1로 할당된다. 컨테이너 내부에 있는 프로세스는 컨테이너에서 구동하지 않은 프로세스를 전혀 볼 수 없다.
- 네트워크 인터페이스 : 기본적으로 도커 데몬은 일련의 사설 IP 주소에 대한 DHCP를 통해 IP 주소를 할당한다. 도커에서는 DHCP 외에 다른 네트워크 모드도 지원하고 있다. 가령 다른 컨테이너의 네트워크 인터페이스를 사용하거나 호스트의 네트워크 인터페이스를 직접 사용하거나 네트워크 인터페이스를 사용하지 않게 설정 할 수도 있다. 원한다면 컨테이너 안에서 호스트에 있는 포트를 같거나 다른 번호로 노출 시킬 수도 있다.
- IPC 기능 : 컨테이너 안에서 구동되는 프로세스는 호스트 시스템에서 제공하는 IPC (Inter-Process Communication) 기능을 직접 사용할 수 없다. 호스트의 IPC 기능을 컨테이너에 노출시키면 되지만, 디폴트 설정에는 꺼져있다. 컨테이너마다 독립적으로 IPC 기능을 갖추고 있다.
- 장치 : 컨테이너 안에 있는 프로세스는 호스트 시스템의 장치를 볼 수 없다. 물론 컨테이너에 권한을 주면 장치에 접근할 수 있다.
이와 같이 도커 컨테이너는 호스트와 유사한 환경을 제공하고 있다. 단 특별히 설정을 바꾸지 않는 한, 컨테이너가 호스트를 볼 수 있는 범위는 제한되어 있다.
도커 구성 요소
도커는 도커 프로젝트에서 개발한 컨테이너 포맷이다. docker 커맨드를 통해 컨테이너를 구동하고, 멈추고, 시작하고, 분석하고, 조작할 수 있다. 또한 docker 커맨드를 서비스 데몬 형태로 실행시켜 도커 컨테이너를 관리하는데 관련된 요청을 받아서 처리하게 할 수도 있다. 이러한 도커 서비스는 요청한 이미지를 도커 허브 레지스트리 (Docker Hub Registry) 에서 가져오도록 설정되어 있다.
- 도커 프로젝트
도커 프로젝트는 도커 개발에 대한 구심점 역할을 하고 있다. 이 프로젝트에서는 도커를 '분산 애플리케이션 개발자와 시스템 관리자를 위한 오픈 플랫폼' 으로 표현하고 있다. 도커 프로젝트는 애플리케이션 개발 및 배포를 간결하게 만드는 것을 목표로 삼고 있다.
도커 프로젝트의 핵심은 소프트웨어 컨테이너에 대한 포맷을 제공하고, 이러한 포맷으로 작성된 소프트웨어를 잘 다룰 수 있도록 특별히 고안된 간결한 인프라스트럭처를 제공하는 것이다.
- 도커 허브 레지스트리
도커 허브 레지스트리는 개인이나 기관이 자체적으로 제작한 도커 컨테이너 이미지를 저장하고 개발하는 공간을 제공한다. 리눅스 시스템에 도커를 설치한 후 현재 시스템에 존재하지 않는 도커 컨테이너 이미지를 요청하면, 도커 허브 레지스트리부터 검색하도록 기본적으로 설정되어 있다.
- 도커 이미지와 컨테이너
컨테이너화의 목적은 애플리케이션을 하나의 컨테이너 단위로 구동하는데 필요한 모든 구성요소를 하나로 엮는데 있다. 도커에서는 이러한 단위를 도커 이미지라 부른다. 도커 이미지는 컨테이너에서 실행하려는 애플리케이션과 이 애플리케이션이 구동하는데 필요한 라이브러리나 설정파일 또는 실행파일 등과 같은 관련 요소로 구성된다.
이미지는 도커가 설치돼 구동할 준비를 하고 있는 로컬 파일시스템, 또는 리포지터리에 저장된 하나의 정적인 단위다. 도커 이미지를 리포지터리가 아닌 파일시스템에 저장하면 tar.gz 형태로 저장된다. 이러한 타볼(tar.gz)은 다른 파일과 동일한 방식으로 전송할 수 있으며, 도커를 실행하고 있는 여러분의 로컬 시스템에 이를 임포트해서 컨테이너로 구동할 수 있다.
도커 컨테이너는 도커 이미지를 구동한 인스턴스를 의미한다. 좀 더 정확히 표현하면 특정한 이미지를 구동한 인스턴스로서 현재 실행중일수도 일시적으로 정지했거나 멈춰있을 수도 있다.
'개발' 카테고리의 다른 글
[ES] Elastic Search - spark (1) (0) | 2020.04.08 |
---|---|
[Python] Python 크롤링 학습 - 1 (0) | 2020.04.08 |
[Kubernetes] 쿠버네티스와 도커 (0) | 2020.03.06 |
VNC 설치 (0) | 2020.03.06 |
Oracle 테이블 정의서 쿼리 (0) | 2020.03.06 |