ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • 도커 데스크탑 설명&활용
    DevOps/도커 & 쿠버네티스 2026. 9. 1. 23:29

    도커 데스크톱은 로컬 환경에서 도커를 이용하여 개발할 수 있도록 지원하는 관리 툴 입니다.
    내가 올린 도커 이미지를 실행시킬 수도 있고, 확인할 수도 있고, 에러로그도 확인할 수 있습니다.
    현재 내 피씨(로컬)기준으로 도커 이미지를 실행하고 관리하는 툴이라고 보면 됩니다.

    도커 허브에서는 누군가가 올린 도커 이미지들을 내 피씨에 내려받아, 컨테이너로 실행할수도 있습니다.

     

    1. 도커 데스크톱 (탭 설명)

       

          1) gordon : 도커를 활용할 수 있게 도와주는 어시스턴트 AI 입니다. (질의응답 가능)
    
         
    
          2) containers : 도커 이미지가 실행단위인 컨테이너화가 되어 프로세스로 올라오는 곳입니다. 
    
                          여기서 어떤 이미지가 실행중인지 확인가능합니다.
    
                          도커 허브에서 땡겨받는, 내가 직접 내 어플리케이션을 빌드하든 여기 실행중인 컨테이너가 올라옵니다.
    
         
    
          3) images : 이곳은 나의 로컬 이미지 저장공간입니다. 
    
                      도커 허브에서 내려받은 타인의 이미지, 내가 직접 빌드한 이미지들이 전부 여기에 저장됩니다.
    
         
    
          4) logs : 로컬에서 일어나는 컨테이너 로그, 빌드 로그들을 모두 여기서 확인 가능합니다.
    
          
    
          5) Kubernates, Volume : 쿠버네티스 클러스터 구성과 저장소를 셋업하여 로컬에서 돌려놓고, 
    
                                  테스트용으로 개발할 때 쓰입니다. 실제로 회사의 쿠버네티스 클러스터 서버에 올리려면 환경도
    
                                  환경도 동일해야 겠죠, 그럴 때 로컬에서 구성해놓고 쓰는 탭 입니다. 
    
                                  아마 쿠버네티스를 라즈베리파이와 같은 간이 서버에 별도 구성하셨다면 굳이 필요는 없습니다.
    
    
    
          6) builds : 내가 순수하게 dockerfile에 정의한 내 어플리케이션이 빌드되어 올라오는 곳입니다. 
    
                      도커 허브에서 pull로 타인 이미지 받는거는 여기 안올라옴. (그건 빌드를 거치지 않고 바로 runtime으로 실행함)
    
    
    
         7) docker hub : 좌측 도커허브 메뉴 탭이고, 여기서는 퍼블릭 공간에 있는 타인의 앱 이미지들을 검색하고 받을 수 있습니다.
    
                         앱스토어 같은 느낌. 
    
    
    
         8) docker hub : 상단 톱니바퀴 우측에 메뉴 표시를 클릭하면 나오는 탭인데, 여기서는 도커 리포지토리를 관리할 수 있습니다.
    
                         public 리포는 생성갯수 제한이 없으며, private 리포는 무료플랜에서 딱 1개 제공합니다.
    
                         저장 용량 제한은 공시되어 있진 않고, 오픈소스를 제공하는 만큼 퍼블릭일 경우 넉넉히 사용 가능할 듯 합니다.
    
    
    
         톱니바퀴는 환경설정으로 현재 도커의 설정을 셋업하는 탭입니다. (일반적으로 사용 시, 건들지 않아도 됩니다.)
    
         대략적으로 이 정도만 알고 가도 될듯합니다. 5번도 특수한 경우가 아니라, 순수 도커만 수행한다면 필요 없습니다.

          

         

    2.  도커허브 이미지 실행과 내 이미지 실행 과정 차이점

         1) Docker hub에서 내려받아 실행

    Docker Hub
      ↓ pull
    완성된 Image
      ↓ run
    Container
      ↓
    Runtime

     

        2) Dockerfile 직접 빌드

    Dockerfile + 내 소스코드
          ↓
        build
          ↓
        Image (이미지로 패키징)
          ↓
         run
          ↓
       Runtime (컨테이너화 : 실행단계)

      

    3. 도커 이미지명 규칙과 리포지토리

    보통 도커를 사용하는 이유는 여러 서버에서 동일한 서비스를 실행할 수 있게 하는 것이기도 하지만, 
    요즘 나오는 MSA(마이크로 서비스 아키텍처)의 적용을 위해 용이한 것이라고도 할 수 있습니다. 
    마이크로 서비스는 말그대로 다수의 마켓사이트가 있다고 가정했을 때에, 
    주문, 결제, 장바구니 등등의 백엔드 서비스가 필요합니다. 
    이것을 사이트 만들때마다 코딩하지 않고, 주문서비스 앱, 결제 서비스앱 단위로 분류하여
    작은 컨테이너 단위로 만들어서 여러개의 프론트 사이트를 만들더라도, 주문, 결제 등과 같은
    백엔드 서비스가 기능별로 각각 만들어두고, 재사용하기 위한 구조를 말합니다.
    이렇게 하면 주문 코드를 수정해야 하면 주문코드만 수정해서 다시 빌드하고 업로드하면 됩니다.
    
    도커에서는 리포명이랑, 이미지명이랑 일치해야 합니다. 
    리포명은 작명하는 방법은 여러 방법이 있을 수 있으나, 
    보통 [회사명]/[서비스명]으로 작성하며, 이미지명도 같은 명칭으로 작성합니다.
    [회사명]/[서비스명]:[태그번호(버전번호)]로 주는게 일반적입니다.
    태그번호를 쓰지 않을 경우, latest 버전 1개만이 올라가고 최신화됩니다.
    다양한 버전을 리포에 올리고 싶은경우엔 태그번호를 주시면 됩니다.(release = 태그번호)
    
    예시를 들자면, 
    제이비 컴퍼니/주문서비스
    제이비 컴퍼니/결제서비스
    제이비 컴퍼니/장바구니서비스
    이렇게하면, 3개의 리포가 생성됩니다. 
    
    물론 이건 MSA 구조에 활용한 예시이므로, 프론트엔드/백엔드/DB 서비스를 한꺼번에 묶어서 패키징하여 이미지 1개로 만들어도 상관은 없습니다.
    연습 목적이거나 작은 사이트의 경우에는 이러한 방식으로 구성하는 것도 가능합니다.
    하지만 이는 최근의 서비스 설계 방향과는 다소 거리가 있으며, 수정 시 전체 서비스에 영향을 줄 가능성이 높고 장애 발생 시 확인해야 할 범위도 커질 수 있습니다.
    왜냐하면 모든 서비스가 하나의 이미지와 하나의 실행 단위로 묶여 있어 서비스별로 독립적인 분리가 되어 있지 않기 때문입니다.
    예를 들어 주문 서비스만 수정하더라도 전체 이미지를 다시 빌드하고 배포해야 할 수 있으며, 문제가 발생했을 경우 주문 서비스만 확인하는 것이 아니라 해당 이미지에 포함된 다른 서비스까지 함께 확인해야 할 수 있습니다.
    따라서 규모가 커질수록 기능별로 서비스를 적절하게 분리하여 각각 독립적으로 관리하고 배포할 수 있는 구조가 유지보수 측면에서 유리합니다.

     

    4. 작업 명령어

       GUI가 있긴 하지만, 버튼으로 핵심 작업을 수행 할수는 없습니다. 

       CLI가 필요합니다. 윈도우 cmd를 여시면 되고, 도커 데스크톱을 설치하면서 도커 명령어를 cmd에서 사용하실수 있게 됩니다.

       아마 수행하는 기능이 그렇게 많지 않으므로 명령어로 수행하게끔 한듯 합니다...

       명령어는 그렇게 많지 않으며, 도커 동작 프로세스와 구조를 알면, 고든이라는 어시스턴트에게 물으시면 명령어 뱉어낼겁니다. 
       아니면, 공식 홈페이지의 문서를 찾아보면 나오기도 하구요. 구글 블로그에서도 많은 자료가 있기도 하구요. 

     

       아래에, 핵심 명령어들만 일부 정리하여 보았습니다.

     

    1) docker images : 내 이미지들 확인 (도커 데스크톱 images탭에서도 확인가능)
    2) docker pull [이미지명] : 도커허브에 올라가 있는 외부 이미지를 다운로드
    3) docker rmi [이미지명] : 내 로컬 이미지 중 특정 이미지 삭제
    4) docker run [이미지명] : 내 이미지들 중, 특정 이미지 실행(컨테이너화)
                              서비스 TCP포트가 디폴트로 수행되고 이름도 이미지 이름을 그대로 씀.
    5) docker run -d -p 8080:80 --name [컨테이너명] [이미지명] : 
                               특정 이미지를 내가 지정한 컨테이너명으로 하고, 
                               외부포트는 8080이고 내부포트는 80으로 지정하라.
                               (사용자 브라우저) -> localhost:8080 -> 내부 80서비스앱으로 접근됨.
    6) docker ps [-a] : 실행중인 컨테이너만 출력하라, -a 옵션은 중지된것까지 전부 출력하라. 
    7) docker rm [컨테이너명] : 특정 컨테이너 삭제
    8) docker rmi [이미지명] : 특정 이미지 삭제
    9) docker start [컨테이너명] : 중지된 컨테이너 실행하기. 
    10) docker restart [컨테이너명] : 실행중인 컨테이너 재실행하기.
    11) docker exec [컨테이너명] [내부 앱 명령어] : 실행중인 컨테이너의 내부 명령어를 수행.
    12) docker exec -it mynginx /bin/bash : 해당 컨테이너가 쉘을 지원할 경우 내부 쉘에 진입.
    13) docker stop [컨테이너명] : 컨테이너 실행 중지.
    14) docker build -t [이미지명] . : 현재 위치에서 Dockerfile을 참조하여 이미지로 빌드.
                                             이미지의 이름은 jaybee/myapp:1.0로 만듬.
                                             이미지가 내 컴터에 알아서 저장되고 확인만 하면됨. 
    
    15) docker push [이미지명] : 도커허브에 내 앱이 업로드됨.
                                 나중에 다른PC나 서버에서 docker pull로 내려받으면 됨.
    16) docker inspect [컨테이너명] : 실행중인 해당 컨테이너의 상세설정 및 상태 정보 출력.
                                     Json 포맷으로 출력된다.

     

    5. 상황별 명령어 활용

        1) 도커 허브에서 이미지를 내려받아 컨테이너 실행

    docker pull [이미지명]     > 이미지 다운
    docker images             > 이미지 확인
    docker run [이미지명]      > 컨테이너로 실행
    docker ps -a              > 컨테이너 실행 확인

        

      2) 내 프로젝트를 직접 빌드하여 도커 실행

    cmd에서 프로젝트 폴더로 이동 (프로젝트 폴더에 dockerfile이 정의되어 있어야함)
    docker build -t [이미지명] . : 현재 위치에서 dockerfile을 참조하여, 현재의 위치의 프로젝트를 기반으로
                                  도커 이미지를 만들어라
    docker images : 이미지 생성 확인
    docker run [이미지명] : 이미지를 컨테이너로 실행하여 서비스

     

    6. Dockerfile 작성 관련 예시

    FROM        기반 이미지 (nginx, nodejs, ubuntu, tomcat... 등)
    WORKDIR     작업 위치
    COPY        파일 복사
    RUN         이미지 빌드 중 실행
    EXPOSE      포트 문서화
    CMD         컨테이너 실행 시 옵션 지정
    ENTRYPOINT  컨테이너 실행 시 주명령 지정 (
    =========================================================
    
    주로 위의 명령으로 구성된다. 
    From 뒤에는 기반 이미지를 기입하며, 
    이 이미지는 도커 허브에 있는 이미지가 참조된다. 
    백엔드 서비스를 예시로 들면, 아래와 같다.
    1단계, 빌드
    메이븐 이클립스 테무린이라는 Maven이 설치된 Eclipse Temurin 21 기반의 빌드 이미지를 불러온다.
    결과 출력될 워킹디렉토리를 /app으로 지정한다.
    그리고 pom.xml과 src 디렉토리를 /app 아래에 복사한다.
    RUN 뒤의 명령을 수행하여 Maven으로 애플리케이션을 빌드한다. (target/*.jar 생성)
    
    2단계, 실행
    Eclipse Temurin 21 JRE 기반의 Java 런타임 이미지를 불러온다.
    동일하게 워킹 디렉토리를 지정한 후, 1단계에서 Maven 빌드로 생성된 target/*.jar를
    최종 이미지의 /app/app.jar로 복사한다.
    EXPOSE 8080을 통해 컨테이너가 8080 포트를 사용함을 선언하고,
    ENTRYPOINT를 통해 컨테이너 시작 시 Java 애플리케이션을 실행한다.
    
    
    예시)
    ----------------------------------------------------------
    # 1. 빌드 단계
    FROM maven:3.9-eclipse-temurin-21 AS build
    
    WORKDIR /app
    
    COPY pom.xml .
    COPY src ./src
    
    RUN mvn clean package -DskipTests
    
    # 2. 실행 단계
    FROM eclipse-temurin:21-jre-jammy
    
    WORKDIR /app
    
    COPY --from=build /app/target/*.jar app.jar
    
    EXPOSE 8080
    
    ENTRYPOINT ["java", "-jar", "app.jar"]
Designed by Tistory.