컨테이너화는 실제로 자주 사용되는 메커니즘입니다. 예를 들어, 헤드헌터(headhunter)를 검색하면 오늘 현재 Docker가 언급된 공석 477개를 찾을 수 있습니다. 그러므로 그것이 무엇인지 숙지하는 것은 나쁜 생각이 아닙니다. 이 짧은 리뷰가 첫 번째 아이디어를 형성하는 데 도움이 되기를 바랍니다. 글쎄요, 그는 Udemy 강좌와 같은 추가 자료로 이를 뒷받침할 것입니다.
소개
이 짧은 리뷰에서는 컨테이너화와 같은 주제를 다루고 싶습니다. 그리고 실제로 컨테이너화가 무엇인지 이해하는 것부터 시작해야 합니다. Wikipedia에 따르면 " 컨테이너화 "는 운영 체제 커널이 단 하나가 아닌 여러 개의 격리된 사용자 공간 인스턴스를 유지 관리하는 운영 체제 수준(즉, 하드웨어 가 아닌 ) 가상화입니다. " 사용자 공간 "은 사용자 프로그램을 위해 예약된 운영 체제의 가상 메모리 주소 공간입니다. 사용자 공간 인스턴스(일반적으로 컨테이너라고 함)는 사용자 관점에서 보면 단일 운영 체제 인스턴스와 완전히 동일합니다. 커널은 완전한 컨테이너 격리를 보장하므로 서로 다른 컨테이너의 프로그램이 서로 영향을 미칠 수 없습니다. 컨테이너화는 소프트웨어 가상화, 즉 운영 체제 커널이 담당하는 운영 체제 수준의 가상화인 것으로 밝혀졌습니다. 이 접근 방식의 특징 중 하나는 모든 컨테이너가 호스트 운영 체제(즉, 컨테이너가 위치한 운영 체제)와 동일한 공통 커널을 사용한다는 것입니다. 이를 통해 가상 하드웨어를 에뮬레이트하고 운영 체제의 전체 인스턴스를 시작하는 오버헤드를 제거할 수 있습니다. 이것이 "가벼운" 가상화라고 말할 수 있습니다. 커널은 프로세서 시간, 메모리, 외부 하드웨어, 외부 입력 및 출력 장치와 같은 컴퓨터 리소스에 대한 조정된 액세스를 응용 프로그램에 제공하는 OS의 핵심 부분입니다. 커널은 일반적으로 파일 시스템 및 네트워크 프로토콜 서비스도 제공합니다. 일반적으로 이는 전체 시스템의 핵심입니다. 추가 정보를 보려면 " 컨테이너에 대한 일반 정보 " 자료를 검토하는 것이 유용할 수 있습니다 . 그리고 소개를 완성하기 위해 몇 마디 더 말씀드리겠습니다. 이제 우리는 운영 체제에 커널이 있다는 것을 이해했습니다. 사용자 공간 인스턴스에 대한 격리를 제공합니다. 이런 맥락에서 " cgroups " 라는 용어를 접할 수도 있습니다 . 이는 이를 달성할 수 있는 Linux 커널 메커니즘의 이름입니다. 따라서 컨테이너화의 길은 Linux 시스템에서 시작되었다고 할 수 있습니다. 그러나 Windows 10부터는 컨테이너화 지원도 나타났습니다. 가상화 작업을 수행하려면 컴퓨터의 BIOS에서 가상화 지원을 구성해야 합니다. 이를 수행하는 방법은 컴퓨터에 따라 다릅니다. 예를 들어 다음과 같을 수 있습니다.
Windows에서는 이를 다양한 방법으로 확인할 수 있습니다. 예를 들어, Microsoft 웹사이트에서 특수 유틸리티인 하드웨어 지원 가상화 감지 도구를 다운로드할 수 있습니다 . 음, 또 다른 중요한 개념인 하이퍼바이저(Hypervisor)를 언급할 가치가 있습니다. 하이퍼바이저는 동일한 컴퓨터에서 여러 운영 체제의 병렬 실행을 보장하는 프로그램인 가상 머신 모니터입니다. 하이퍼바이저는 운영 체제가 서로 격리되어 있고 실행 중인 OS 간에 리소스를 공유하도록 보장합니다. 그러한 하이퍼바이저 중 하나가 Oracle VirtualBox 입니다 .
도커
따라서 가상화가 무엇인지는 분명합니다. 하지만 어떻게 사용하나요? 그리고 여기서 Docker가 우리를 도와줍니다. Docker는 컨테이너화된 환경에서 애플리케이션 배포 및 관리를 자동화하는 소프트웨어입니다. Docker가 Docker Enginge와 같은 개념으로 표현된다는 사실부터 시작하는 것이 좋습니다. 그리고 공식 Docker 웹사이트와 “ Docker 개요 ” 섹션부터 시작해야 합니다.
문서에 따르면 도커는 다음으로 구성되어 있습니다.
Docker Daemon 프로세스(dockerd)라고 불리는 Docker 서버입니다.
CLI(docker)라고도 알려진 명령줄 인터페이스입니다.
프로그램이 데몬과 "대화"하고 수행할 작업을 지시하는 방법을 설명하는 REST API입니다.
더 자세히 알아보기 전에 docker를 설치해 보겠습니다. 즉, docker 데몬을 설치해 보겠습니다. Docker 웹사이트에는 " Docker for Windows " 설치 지침이 있습니다. 흥미롭게도 Docker에는 자체 시스템 요구 사항이 있습니다. 그리고 저처럼 오래된 Windows(예: Windows 7)를 사용하는 경우 Docker Toolbox를 사용해야 합니다.
도커 도구 상자
시스템 요구 사항을 충족하지 않는 오래된 컴퓨터에 Docker를 설치합니다. 웹사이트에는 "레거시 데스크탑 솔루션"이라고 나와 있습니다. " Docker Toolbox " 페이지로 이동하여 다운로드해 보겠습니다. 이 세트의 무게는 약 211MB입니다. 우리는 그것을 기본값으로 설치할 것입니다. 즉, 플래그를 재정렬하지 않고 모든 것에 온유하게 동의합니다. 설치 후 모든 것이 정상인지 확인하겠습니다. 미래에는 우리의 전장이 명령줄이 될 것입니다. Windows 명령줄에는 명백한 문제가 있을 수 있으므로 사용하지 않는 것이 좋습니다. bash 쉘을 사용하는 것이 더 좋습니다. Windows에서 이를 얻는 가장 권장되는 방법은 git 버전 제어 시스템을 설치하는 것입니다 . 여전히 유용합니다. 왜냐하면 그것과 함께 "번들"되는 것이 우리에게 필요한 bash가 될 것이기 때문입니다. 이번 리뷰에서는 git bash를 사용하겠습니다. CYGWIN을 사용하여 bash를 설치할 수도 있습니다 . bash나 git bash를 실행해 봅시다. Docker Machine이라고도 알려진 Docker Machine을 설치했는지 확인해 보겠습니다. docker-machine -version 이 Docker Machine은 무엇인가요? Docker Machine은 Docker화된 호스트(Docker 엔진이 설치된 호스트)를 관리하기 위한 유틸리티입니다. 명령을 사용하여 Docket Toolbox view docker 머신을 설치한 직후에 docker-machine ls빈 목록이 표시됩니다.
새로운 머신을 만들어 보겠습니다. 이렇게 하려면 create 명령을 실행해야 합니다 . docker-machine create -- driver virtualbox javarush: 도커 머신 생성 로그가 표시됩니다.
여기서 우리가 관심을 갖는 것은 다음과 같습니다. Boot2Docker란 무엇입니까? 이는 Docker 엔진을 실행하기 위한 최소한의 Linux 배포판입니다. Docker는 Linux 가상화 도구 덕분에 작동하며 Windows에서는 Windows 10부터 필요한 메커니즘이 나타났습니다. 이 배포판은 " Tiny Core Linux " 배포판을 기반으로 합니다 . VirtualBox VM에 대해서도 언급되었습니다. 을 지정했기 때문입니다 --driver virtualbox. Boot2Docker 이미지의 VirtualBox에 새 가상 머신이 생성되었습니다. 생성 후 VirtualBox를 시작하고(VirtualBox는 Docker Toolbox와 함께 설치되므로) Docker 머신에 대해 생성된 가상 머신을 볼 수 있습니다.
생성 후, docker 머신에 연결하기 위해 구성해야 하는 환경 변수를 가져오기 위해 " docker-machine env " 명령을 실행하라는 메시지가 표시됩니다 .
docker-machine을 사용하여 이 명령을 실행한 후, 도커화된 원격 호스트(이 경우 Virtual Box에서 호스팅되는 가상 호스트)에 연결하고 마치 원격 호스트에서 실행하는 것처럼 로컬로 도커 명령을 실행할 수 있습니다. 확인하려면 " docker info " 명령을 실행하면 됩니다. Docker 시스템에 대한 연결이 설정되지 않으면 오류가 발생합니다. 그리고 모든 것이 정상이라면 docker 머신의 docker에 대한 정보입니다. 이제 Docker의 일반적인 작동 방식과 사용 방법을 이해해야 할 때입니다.
도커 컨테이너
그래서 우리는 도커를 가지고 있습니다. 그런데 이 도커는 무엇입니까? Docker 문서와 “ 시작하기 ” 섹션은 이를 이해하는 데 도움이 될 것입니다 . 이 섹션의 소개 부분에서는 Docker 개념을 소개합니다 . Docker는 컨테이너에서 애플리케이션을 개발, 디버깅 및 실행하기 위한 플랫폼이라고 명시되어 있습니다. 따라서 Docker의 가장 중요한 것은 컨테이너입니다. 도커 로고만 봐도 등에 컨테이너를 짊어지고 있는 고래입니다. 그런데 컨테이너란 무엇일까요? 다음 " 이미지 및 컨테이너 " 섹션에는 컨테이너가 이미지의 실행 중인 인스턴스라고 나와 있습니다. 그리고 이미지는 애플리케이션에 필요한 모든 것(코드, 환경, 라이브러리, 설정 등)이 포함된 "패키지"입니다. 이제 직접 시도해 보겠습니다. Docker 웹사이트에는 " 초보자를 위한 Docker "가 포함된 " Docker 샘플 "이라는 섹션이 있습니다 . 여기의 예가 나에게는 더 흥미로운 것 같습니다. 그래서 우리는 갑자기 Alpine Linux 에 대해 알고 싶었고 Docker 컨테이너를 사용하여 이를 수행할 수 있습니다. 이미지를 얻으려면 이미지를 "당겨"거나 "당겨"야 합니다. 따라서 docker pull 명령을 실행합니다 .docker pull apline
이제 우리는 apline 이미지를 갖게 되었습니다. 컨테이너는 실행 중인 이미지 인스턴스이므로 바로 이 이미지를 시작하겠습니다. 명령을 사용하여 컨테이너를 시작하겠습니다 docker run alpine. 보시다시피 아무 일도 일어나지 않았습니다. 모든 활성 컨테이너를 표시하는 명령을 실행해도 docker ps아무것도 얻지 못합니다. 그러나 실행하면 docker ps -a모든 컨테이너가 표시됩니다.
문제는 Docker를 대화형 모드로 시작하지 않았다는 것입니다. 따라서 그는 명령을 실행하고 중지했습니다. 명령은 터미널을 여는 것이 었습니다. 동일한 작업을 수행하되 대화형 모드( -it 플래그 사용 )에서 수행해 보겠습니다.
보시다시피, 한 가지 실수를 극복하고 힌트를 사용하여 컨테이너에 도달하고 작업할 수 있습니다! 작업을 중단하지 않고 컨테이너를 종료하려면 을 누르세요 Ctrl + p + q. 지금 실행하면 docker ps하나의 활성 컨테이너가 표시됩니다. 이미 실행 중인 컨테이너에 들어가려면 docker exec 명령을 실행합니다 .
이 모든 일이 어떻게 발생하는지에 대한 훌륭한 설명을 보려면 Docker 샘플 설명을 읽어보는 것이 좋습니다. " 1.0 첫 번째 컨테이너 실행 ". 모든 것이 매우 접근하기 쉽고 이해하기 쉬운 방식으로 기록되어 있기 때문에 나는 그것을 좋아합니다. 간단히 말하면, docker-machine을 사용하여 Docker Daemon을 실행하는 가상 머신에 연결됩니다. REST API를 통해 CLI를 사용하여 알파인 이미지를 시작하도록 요청합니다. Docker가 이를 찾았으므로 다운로드하지 않습니다. Docker는 새 컨테이너를 생성하고 이 컨테이너에 지정된 명령을 실행합니다. 물론 이 모든 것이 좋습니다. 그런데 왜 이 모든 것이 필요한가요? 그리고 여기서는 docker가 이미지를 생성하는 방법을 알아내야 합니다. 그리고 그는 dockerfile을 기반으로 그것들을 만듭니다.
도커파일
Dockerfile 참조 에 명시된 대로 dockerfile은 이미지를 얻기 위한 모든 명령이 포함된 텍스트 파일입니다. 실제로 우리가 받는 모든 이미지(위 예의 Alpine 포함)는 dockerfile에서 생성되었습니다. Java 애플리케이션을 사용하여 이미지를 빌드해 보겠습니다. 그리고 먼저 이 Java 애플리케이션이 필요합니다. Gradle 빌드 시스템을 사용하는 것이 좋습니다. 이 짧은 리뷰인 " Gradle에 대한 간략한 소개 "에서 자세한 내용을 읽을 수 있습니다. " Gradle Build init 플러그인 " 프로젝트를 만드는 데 도움이 될 것입니다 . Gradle을 사용하여 새 Java 애플리케이션을 생성해 보겠습니다. gradle init --type java-application 이 명령은 템플릿 Java 프로젝트를 생성합니다. 이것은 독립형 애플리케이션이지만 웹 애플리케이션을 만들고 싶습니다. App 및 AppTest 클래스를 제거해 보겠습니다(Gradle Build Init 플러그인에 의해 자동으로 생성됨). 웹 애플리케이션을 빠르게 생성하기 위해 Gradle의 " Java 웹 애플리케이션 구축 " 튜토리얼을 사용하겠습니다 . 튜토리얼에 따르면 다음과 같이 해보자:
plugins {
id 'war'
id 'org.gretty' version '2.2.0'}
HelloServletGretty가 위에서 설명한 오류를 볼 수 없다는 점이 흥미롭습니다 . 이는 애플리케이션이 다양한 환경에서 다르게 동작할 수 있음을 증명합니다. Gretty는 일반 독립형 서버에서 오류가 발생하는 곳에서 작동할 수 있습니다. 남은 것은 응용 프로그램이 올바르게 작동하는지 확인하는 것입니다. 하자:gradle appRun
모든 것이 정상이면 명령을 사용하여 gradle war확장 전쟁(웹 아카이브)으로 아카이브를 수집합니다. 기본적으로 Gradle은 \build\libs. 이제 dockerfile을 작성할 준비가 되었습니다. " Dockerfile 참조 "를 사용하여 Dockerfile을 생성합니다. Java 프로젝트의 루트(빌드 스크립트와 동일한 위치)에 "Dockerfile"이라는 파일을 생성해 보겠습니다. 편집을 위해 열어 보겠습니다. 이 파일에는 " Dockerfile 참조: 형식 " 섹션에 설명된 고유한 형식이 있습니다. 모든 dockerfile은 "기본 이미지"를 나타내는 FROM 문으로 시작됩니다. 이것이 우리가 이미지를 만드는 기반이 되는 상위 이미지라고 말할 수 있습니다. 부모 이미지를 선택하는 것은 매우 쉽습니다. 웹 애플리케이션에는 웹 서버가 필요합니다. 예를 들어 Tomcat 웹 서버를 사용할 수 있습니다. dockerhub 라고 하는 공식 Docker 저장소로 이동합니다 . 필요한 이미지가 있는지 확인하기 위해 거기를 살펴봅니다.
Tomcat 이미지가 호출된다는 점도 이해해 둘 가치가 있습니다. 그러나 이름 외에 태그가 있습니다. 태그는 버전과 같습니다. 다양한 버전의 Tomcat 이미지는 사용되는 Tomcat 버전, jre 버전 및 기본 이미지에 따라 다릅니다. docker pull tomcat:9-jre8-alpine 예를 들어, Tomcat 버전 9, jre 버전 8 및 알파인 이미지를 기본으로 사용하는 이미지를 얻을 수 있습니다 . 이는 이미지 크기를 줄이는 데 중요할 수 있습니다.
보시다시피, 그 차이는 엄청납니다. tomcata alpine을 기반으로 이미지를 빌드하는 경우 600MB가 아닌 100MB로 시작합니다. 따라서 이전에 생성된 dockerfile에 다음 콘텐츠를 추가합니다.
# Базовый образ,"наследуемся" от него
FROM tomcat:9-jre8-alpine
# Копируем из BuildContext'а собранный web archive в каталог томката
COPY build/libs/docker.war /usr/local/tomcat/webapps/docker.war
# Меняем рабочий каталог на томкатовский
WORKDIR /usr/local/tomcat
# Открываем порт 8080 для контейнера, т.к. его слушает томкат
EXPOSE 8080
이제 이미지를 빌드하는 명령을 실행해 보겠습니다 docker build -t jrdocker ..
-t- 이것은 태그, 즉 조립된 이미지를 호출하는 것입니다. 끝에 있는 점은 현재 디렉터리(dockerfile이 있고 명령을 실행한 디렉터리)를 Build context. Build context- dockerfile을 생성할 때 사용할 수 있는 파일의 컨텍스트입니다. 보시다시피, 덕분에 우리는 조립된 war 파일을 우리 이미지, 웹 서버 디렉토리에 복사할 수 있었습니다. 이제 이미지를 실행해 보겠습니다.docker run -d --rm -p 8888:8080 jrdocker
서버가 시작되었는지 여부를 이해하려면 컨테이너의 로그를 보면 됩니다. 로그는 docker log 명령을 사용하여 ID 또는 이름으로 컨테이너를 지정하여 얻을 수 있습니다. 예를 들어:
음, 다음 명령을 사용하면 언제든지 실행 중인 컨테이너에 이름으로 이동할 수 있다는 점을 잊지 마세요. winpty docker exec -it NameКонтейнера sh 이제 남은 것은 연결하는 것뿐입니다. 이전에는 EXPOSE를 지정하여 컨테이너 내부에서 포트 8080에 대한 액세스를 허용했지만, 컨테이너 자체를 시작할 때 -p ( 수신 포트 ) 태그를 지정하여 컨테이너(Tomcat 웹 서버)의 포트 8080을 연관시켰습니다. docker 데몬이 있는 머신의 포트 8888과의 연결을 기다리고 있습니다. 기억하는 것처럼 우리는 docker 데몬을 직접 실행하지 않고 docker-machine을 통해 실행했습니다. 따라서 다시 한 번 docker-machine ls 명령을 사용하여 docker 머신에 대한 데이터를 요청하고 컨테이너의 서버에 연결합니다.
따라서 귀하와 저는 방금 Docker 컨테이너에서 웹 애플리케이션을 시작했습니다! ) 또한 다음 사항에 주목하고 싶습니다. 액세스 문제가 있는 경우 Docker 머신이 무엇보다도 Virtual BOX 가상 머신이라는 점을 기억해야 합니다. 가상 머신의 네트워크 설정에 문제가 있을 수 있습니다. 작동하는 VMBox 구성은 다음과 같습니다.
레이어
우리는 이미 이미지가 dockerfiles에서 생성되고 dockerfiles가 명령 집합이라는 것을 알아냈습니다. 우리는 또한 dockerfile에 부모가 있다는 것을 알아냈습니다. 그리고 이미지의 크기도 다릅니다. 흥미롭게도 docker History 명령을 사용하여 이미지가 어떻게 빌드되었는지에 대한 기록을 볼 수 있습니다 . 예를 들어:
본질적으로 각 이미지는 이미지의 집합이라는 점을 이해하려면 이렇게 말하는 것이 중요합니다. 각 이미지 변경(dockerfile의 각 새 명령)은 자체 ID를 가진 새 레이어를 생성합니다. " Docker: 이미지 및 레이어 " 문서에서 레이어에 대한 자세한 내용을 읽을 수 있습니다 . 또한 Habré의 " Docker 이미지 및 그림의 컨테이너 " 기사를 읽어 보시기 바랍니다 .
결론
이 짧은 개요가 컨테이너화에 관심을 갖는 데 충분했기를 바랍니다. 다음은 유용할 수 있는 추가 자료에 대한 링크입니다.
GO TO FULL VERSION