아주 조금씩 천천히 살짝

[FastAPI] SQLAlchemy orm과 schema

PeonyF — Mon, 18 Mar 2024 20:43:25 +0900

ORM(Object-Relational Mapping)

데이터베이스를 사용하려면 SQL 쿼리(query)라는 구조화된 질의를 작성하고 실행하는 등의 복잡한 과정이 필요하다. 이때 ORM(object relational mapping)을 이용하면 파이썬 문법만으로도 데이터베이스를 다룰 수 있다. 즉, ORM을 이용하면 개발자가 쿼리를 직접 작성하지 않아도 데이터베이스의 데이터를 처리할 수 있다.( 점프 투 FastAPI)

데이터베이스의 테이블을 파이썬 객체로 매핑하여 SQL 쿼리 없이 데이터베이스와 상호작용할 수 있게 해주는 방식

-> DB의 테이블과 관계를 파이썬 클래스로 정의

sqlalchemy db model 생성

declarative_base() 로 Base class (sqlalchemy model) 생성
Base class로부터 상속받아 db 에 해당하는 model class(model) 생성

from sqlalchemy import Boolean, Column, Integer, String
from sqlalchemy.orm import declarative_base

from schema.request import CreateToDoRequest

Base = declarative_base()

'''
ORM: DB Table에 mapping 할 수 있는 형태의 객체를 만들어서 관리하는 방식
직접 SQL 쿼리를 작성하지 않고 파이썬 코드로 SQL쿼리를 생성해 자동으로 연결시켜줌
'''


class ToDo(Base):
    __tablename__ = "todo"

    id = Column(Integer, primary_key=True, index=True)
    contents = Column(String(256), nullable=False)
    is_done = Column(Boolean, nullable=False)

    def __repr__(self):
        return f"ToDo(id={self.id},contents={self.contents},is_done={self.is_done}"

    @classmethod
    def create(cls,request:CreateToDoRequest) -> "ToDo":
        return cls(
            contents=request.contents,
            is_done=request.is_done,
        )

Schema(Pydantic 모델)

데이터 파싱 과 검증,직렬화,역직렬화를 위해 사용되는 구조. 입력 데이터의 유효성 검사,데이터 변환 등에 사용

-> API로 부터 받은 데이터가 특정 스키마와 일치하는지, 모델에 정의된 타입과 일치하는지 자동 검증

Pydantic Schema 생성

pydantic의 BaseModel 모듈 이용

from pydantic import BaseModel
from typing import List


class ToDoSchema(BaseModel):
    id: int
    contents: str
    is_done: bool

    class Config: # 외부 클래스의 동작을 구성하거나 커스터마이징하는 데 사용 주로 이름이 Config,Meta
        # orm_mode = True pydatic v1
        from_attributes = True #ORM 모델로부터 Pydantic 모델로 데이터를 변환할 때 필요한 설정


class ToDoListSchema(BaseModel):
    todos: List[ToDoSchema]

ORM과 Schema를 따로 관리하는 이유

ORM은 db의 table구조와 직접적인 상호작용에사용 (ex.db와의 연동)

Schema는 API의 데이터 구조와 유효성 검사(사용자의 입력이나 API 응답 데이터 형식 정의)

이렇게 분리하여 DB의 내부 구조가 변경되더라도 Schema에 영향을 미치지 않아 결합도를 낮출 수 있음

진행과정

1. SQLAlchemy를 사용해서 DB모델 정의 및 DB쿼리 실행

DB 테이블과 맵핑되는 모델 정의
SQLAlchemy세션을 통해 DB쿼리 실행, 결과를 ORM객체로 받음

2. Pydantic모델을 사용하여 데이터 검증 및 직렬화

API로 받은 데이터를 Pydantic 모델로 변환하여 데이터의 유효성을 검사
SQLAlchemy객체를 Pydantic모델로 변환하여 API response로 리턴

from sqlalchemy import create_engine, Column, Integer, String
from sqlalchemy.ext.declarative import declarative_base
from sqlalchemy.orm import sessionmaker
from pydantic import BaseModel

# SQLAlchemy 모델 정의
Base = declarative_base()
class User(Base):
    __tablename__ = 'users'
    id = Column(Integer, primary_key=True)
    name = Column(String)
    age = Column(Integer)

# Pydantic 모델 정의
class UserSchema(BaseModel):
    id: int
    name: str
    age: int

# SQLAlchemy 세션 생성 및 데이터베이스 쿼리
engine = create_engine('sqlite:///mydatabase.db')
Session = sessionmaker(bind=engine)
session = Session()
user = session.query(User).first()

# SQLAlchemy 객체를 Pydantic 모델로 변환
user_schema = UserSchema.from_orm(user)

실전! FastAPI 입문 - 인프런

https://wikidocs.net/175967

https://wikidocs.net/176222

https://fastapi.tiangolo.com/tutorial/sql-databases/#orms

https://velog.io/@crosstar1228/FastapiSQLAlchemy-%EC%9D%B4%EC%9A%A9%ED%95%98%EC%97%AC-DB%EC%99%80-%EC%97%B0%EA%B2%B0%ED%95%98%EA%B8%B0

[Python] API 문법(Response Model), 딕셔너리 언패킹,튜플 언패킹

PeonyF — Mon, 18 Mar 2024 20:19:02 +0900

#Pydantic Schema 
from pydantic import BaseModel
from typing import List, Optional
from fastapi import FastAPI, HTTPException, Depends
from sqlalchemy.orm import Session

app = FastAPI()

class BookSchema(BaseModel):
    id: int
    title: str
    author: str
    is_available: bool
    genre:str|None

#특정 저자의 모든 책 조회
@app.get("/books/author/{author_name}", response_model=List[BookSchema])
def get_books_by_author(author_name: str, session: Session = Depends(get_db)) -> List[BookSchema]:
    books = session.query(Book).filter(Book.author == author_name).all()
    if books:
        return [BookSchema(**book.__dict__) for book in books]
    raise HTTPException(status_code=404, detail="No books found by this author")

1. author_name: str, session: Session = Depends(get_db) 이란?

author_name는 str, session은 get_db()함수로 부터 db세션을 객체로 받아 session 매개변수로 넘긴다.
ex) name: str = "Alice" 이면 name변수가 str타입으로 명시, 초기값이 Alice

2. -> List[BookSchema] 혹은

def get_books_by_author(author_name: str, session: Session = Depends(get_db)) -> BookSchema: 이란?

get_books_by_author의결과값으로 BookSchema의 값을 받는다.
List[BookSchema]의경우 여러개를 받겠다 라는 뜻
위의 코드의 경우 List[BookSchema]: books = ~ 이므로 get_books_by_author의결과값으로 BookSchema값을 받는데 이 BookSchema는 books로 된 객체로 특정 저자의 모든책을 조회한 결과값(session.query(Book).filter(Book.author == author_name).all())이다.

3.books:Book|None = session.query(Book).filter(Book.author == author_name).all() 이란?

Book|None : 특정 저자의 모든책을 조회한 결과값이 Book 객체거나 없을 경우 None으로 전달
session.query(Book).filter(Book.author == author_name).all() : 특정 저자의 모든책을 조회한 결과값

4. [BookSchema(book.dict) for book in books] 이란?**

딕셔너리 언패킹: 객체의 속성을 함수,클래스 생성자에 전달 방식

def print_info(name, city):
    print(f"Name: {name}, City: {city}")

info = {'name': 'chacha', 'age': 25, 'city': 'Seoul'}

#key는 새 딕셔너리에 포함될 각 키(key), info[key]는 해당 키에 대응되는 값을(value) 가져옴
filtered_info = {key: info[key] for key in info if key in ['name', 'city']}
print_info(**filtered_info)

#만약 infos일경우 리스트 컴프리헨션 + 딕셔너리 컴프리헨션을 결합해서 사용
infos = [
    {'name': 'chacha', 'age': 25, 'city': 'Seoul'},
    {'name': 'chacha2', 'age': 26, 'city': 'London'},
    {'name': 'chacha3', 'age': 27, 'city': 'New York'}
]
filtered_infos = [{key: info[key] for key in info if key in ['name', 'city']} for info in infos]

book.__dict__ : book 객체의 속성들을 포함하는 딕셔너리를 반환
** 연산자 : book.__dict__를 언패킹하여 BookSchema에 전달(book 객체의 모든 속성이 전달됨)

# Book 객체 생성
book = Book(id=1,title="python",author="chacha",is_abailable=True,genre="IT")

# Book 객체의 속성을 BookSchema의 인스턴스로 변환
book_schema = BookSchema(**book.__dict__)

*연산자의 경우 튜플 언패킹으로 사용

def print_values(a, b, c):
    print(a, b, c)

values = (1, 2, 3)

#튜플 언패킹
print_values(*values)

BookSchema(*book.__dict__) 가 불가능한 이유 : * 연산자의 경우 위치기반의 언패킹으로 딕셔너리에 사용 불가, ** 연산자는 키-값을 키워드 인자로 언패킹하는데 사용

5. 새 책 추가(Post)

@app.post("/books", response_model=BookSchema)
def add_new_book(book_data: BookSchema, session: Session = Depends(get_db)) -> BookSchema:
    book = Book(**book_data.dict())
    session.add(book)
    session.commit()
    session.refresh(book)
    return BookSchema(**book.__dict__)

열혈 파이썬 중급

https://docs.sqlalchemy.org/en/20/orm/session_api.html#sqlalchemy.orm.Session.query

Session API — SQLAlchemy 2.0 Documentation

Session API Session and sessionmaker() class sqlalchemy.orm.sessionmaker A configurable Session factory. The sessionmaker factory generates new Session objects when called, creating them given the configurational arguments established here. e.g.: from sqla

docs.sqlalchemy.org

[Algorithm] 백준 16933의 메모리 초과

PeonyF — Fri, 23 Feb 2024 10:27:30 +0900

기존 코드

#16933
import sys
from collections import deque

n, m, break_cnt = map(int, input().split())
graph = [list(map(int, input())) for _ in range(n)]
visited = [[[False] * (break_cnt + 1) for _ in range(m)] for _ in range(n)]

dx = [-1, 1, 0, 0]
dy = [0, 0, -1, 1]


def bfs():
    queue = deque()
    queue.append((0, 0, 0, 1, 1))  # 시작 위치, 벽을 부순 횟수, 이동 거리 추가,밤낮여부(낮:1,밤:0)
    visited[0][0][0] = 1
    
    while queue:
        x, y, cur_break_cnt, distance, is_day = queue.popleft()

        # 도착 지점에 도달했을 경우
        if x == (n - 1) and y == (m - 1):
            return distance

        # 인접한 네 방향 탐색
        for i in range(4):
            nx = dx[i] + x
            ny = dy[i] + y

            # 범위 내에 있을 경우
            if 0 <= nx < n and 0 <= ny < m:
                # 벽이 있고, 벽을 부술 수 있으며, 방문하지 않은 경우
                if graph[nx][ny] == 1 and cur_break_cnt < break_cnt and not visited[nx][ny][cur_break_cnt + 1]:
                    if is_day:  # 낮인 경우
                        queue.append((nx, ny, cur_break_cnt + 1, distance + 1, 0))
                        visited[nx][ny][cur_break_cnt + 1] = True
                    else:
                        queue.append((x, y, cur_break_cnt, distance + 1, 1))

                # 벽이 없고 방문하지 않은 경우
                elif graph[nx][ny] == 0 and not visited[nx][ny][cur_break_cnt]:
                    visited[nx][ny][cur_break_cnt] = True
                    if is_day:
                        queue.append((nx, ny, cur_break_cnt, distance + 1, 0))
                    else:
                        queue.append((nx, ny, cur_break_cnt, distance + 1, 1))
    return -1


print(bfs())

수정 코드

#16933
import sys
from collections import deque

n, m, break_cnt = map(int, input().split())
graph = [list(map(int, input())) for _ in range(n)]
visited = [[[0] * m for _ in range(n)] for _ in range(break_cnt + 1)]

dx = [-1, 1, 0, 0]
dy = [0, 0, -1, 1]


def bfs():
    queue = deque()
    queue.append((0, 0, 0, 1, 1))  # 시작 위치, 벽을 부순 횟수, 이동 거리 추가,밤낮여부(낮:1,밤:0)
    visited[0][0][0] = 1
    
    while queue:
        x, y, cur_break_cnt, distance, is_day = queue.popleft()

        # 도착 지점에 도달했을 경우
        if x == (n - 1) and y == (m - 1):
            return distance

        # 인접한 네 방향 탐색
        for i in range(4):
            nx = dx[i] + x
            ny = dy[i] + y

            # 범위 내에 있을 경우
            if 0 <= nx < n and 0 <= ny < m:
                # 벽이 있고, 벽을 부술 수 있으며, 방문하지 않은 경우
                if graph[nx][ny] == 1 and cur_break_cnt < break_cnt and not visited[cur_break_cnt + 1][nx][ny]:
                    if is_day:  # 낮인 경우
                        queue.append((nx, ny, cur_break_cnt + 1, distance + 1, 0))
                        visited[cur_break_cnt + 1][nx][ny] = 1
                    else:
                        queue.append((x, y, cur_break_cnt, distance + 1, 1))

                # 벽이 없고 방문하지 않은 경우
                elif graph[nx][ny] == 0 and not visited[cur_break_cnt][nx][ny]:
                    visited[cur_break_cnt][nx][ny] = 1
                    if is_day:
                        queue.append((nx, ny, cur_break_cnt, distance + 1, 0))
                    else:
                        queue.append((nx, ny, cur_break_cnt, distance + 1, 1))
    return -1


print(bfs())

차이점

: 메모리 접근 패턴이 다름

# 기존코드
visited = [[[False] * (break_cnt + 1) for _ in range(m)] for _ in range(n)]
 if graph[nx][ny] == 1 and cur_break_cnt < break_cnt and not visited[nx][ny][cur_break_cnt + 1]:
    if is_day:  # 낮인 경우
       queue.append((nx, ny, cur_break_cnt + 1, distance + 1, 0))
       visited[nx][ny][cur_break_cnt + 1] = True
       
# 바뀐코드

visited = [[[0] * m for _ in range(n)] for _ in range(break_cnt + 1)]
 if graph[nx][ny] == 1 and cur_break_cnt < break_cnt and not visited[cur_break_cnt + 1][nx][ny]:
    if is_day:  # 낮인 경우
       queue.append((nx, ny, cur_break_cnt + 1, distance + 1, 0))
       visited[cur_break_cnt + 1][nx][ny] = 1

기존코드 메모리 참조 방식 (불연속적 접근): visited[0][0][0]에서 visited[0][0][1]로 점프해야함 -> 캐시 활용이 덜 효율적임

visited[0][0][0], visited[0][0][1], visited[0][1][0], visited[0][1][1], visited[0][2][0], visited[0][2][1], visited[1][0][0], visited[1][0][1], visited[1][1][0], visited[1][1][1], visited[1][2][0], visited[1][2][1], visited[2][0][0], visited[2][0][1], visited[2][1][0], visited[2][1][1], visited[2][2][0], visited[2][2][1]

바뀐코드 메모리 참조 방식(연속적 접근): cur_break_cnt값에 대해 (x,y)를 순회하며 메모리에 연속 접근함 -> 캐시 효율성을 높일 수 있음

# 벽을 부수지 않고 방문한 경우(0회 부숨): 
visited[0][0][0], visited[0][0][1], visited[0][0][2], visited[0][1][0], visited[0][1][1], visited[0][1][2], visited[0][2][0], visited[0][2][1], visited[0][2][2]
# 벽을 부수고 방문한 경우(1회 부숨): 
visited[1][0][0], visited[1][0][1], visited[1][0][2], visited[1][1][0], visited[1][1][1], visited[1][1][2], visited[1][2][0], visited[1][2][1], visited[1][2][2]

연속된 접근 vs. 불연속적인 접근

연속된 접근: 순차적으로 데이터를 읽을 경우 메모리의 연속된 주소를 차례대로 접근함

-> CPU캐시가 이러한 접근 패턴을 예측하고, 미리 다음에 필요할 데이터를 미리 캐시에 로드함

불연속적인 접근: 빈번하게 점프하며 데이터에 접근하는 경우

-> CPU캐시가 예측을 할 수 없어 미리 데이터를 로드하기 어려움. 캐시미스 발생(CPU가 메인메모리에 직접 접근해, 메모리 대기 시간이 증가시킴)

[DOCKER] Docker compose에 nginx 적용기

PeonyF — Mon, 15 Jan 2024 20:09:19 +0900

Nginx의 필요성

Q. 개발환경 서버와 운영환경 서버가 달라야 하는 이유

개발에서 사용하는 서버(Dockerfile.dev)

소스 변경시 자동으로 전체 앱을 다시 빌드해서 변경 소스를 반영 → 개발환경에 특화

운영환경 서버(Dockerfile)

소스 변경시 변경 소스 반영X →개발에 필요한 기능들이 필요하지 않아 더 깔끔함

Nginx의 장점

Q. Docker에서 nginx를 사용하는 이유는?

nginx(리버스 프록시 서버)는 백엔드 서버 앞에 위치해서 클라이언트 요청을 백엔드 서버로 전달

이로인해 아래와 같은 장점이 있음

백엔드 서버의 주소 숨길 수 있음(리버스 프록시)
들어오는 네트워크 트래픽을 여러 서버에 분산시켜 부하를 균등하게 분배(로드 밸런싱)
자주 요청되는 데이터(예: 이미지, CSS, JavaScript 파일 등)를 캐시에 저장 → 서버 응답시간 단축
SSL(웹사이트-사용자간 통신 암호화, 보안유지 프로토콜) 처리로 안전한 HTTPS 연결 제공

Nginx을 Compose에 적용

1. dockerfile.nginx 파일 생성 및 적용(dockerfile-folder/web/dockerfile.nginx)

FROM nginx:latest
COPY ./default.conf /etc/nginx/conf.d/default.conf
EXPOSE 80

2. default.conf 파일 생성 및 작성(dockerfile-folder/web/default.conf)

default.conf 파일이 Dockerfile.nginx와 같은 디렉토리에 존재해야한다.

default.conf 와 nginx.conf
- nginx.conf
  - nginx.conf는 Nginx의 전역 설정(worker 프로세스의 수, 로그파일의 위치, 클라이언트 요청 방법) 을 정의
  - but 일반적으로 Docker를 사용할 때는 Docker Hub에서 제공하는 Nginx 이미지를 가져와서 사용하고, 이 이미지에는 기본 nginx.conf 파일이 이미 포함되어 있어 이걸 사용함
- default.conf
  - 특정 서버 또는 도메인에 대한 설정을 정의(어떤 포트에서 리스닝할껀지, SSL설정, 리버스 프록시 설정)

server {
    listen 80;
    server_name localhost;

    location / {
        proxy_pass http://web:5000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

3. docker-compose.yaml 추가 (dockerfile-folder/docker-compose.yaml)

services:
  web:
    build:
      context: ./web
      dockerfile: Dockerfile
    ports:
      - "5000:5000"
    depends_on:
      - db
    environment:
      DATABASE_USER: ${MYSQL_USER}
      DATABASE_PASSWORD: ${MYSQL_PASSWORD}
      DATABASE_NAME: ${MYSQL_DATABASE}
    networks:
      - backend


  nginx:
    build:
      context: ./web
      dockerfile: dockerfile.nginx
    networks:
      - backend
    ports:
      - "80:80"
    depends_on:
      - db

4. docker build

docker-compose down
docker-compose up --build
[+] Building 1.1s (17/17) FINISHED                                                                                 docker:desktop-linux
 => [web internal] load build definition from dockerfile                                                                           0.0s
 => => transferring dockerfile: 837B                                                                                               0.0s
 => [web internal] load .dockerignore                                                                                              0.0s
 => => transferring context: 2B                                                                                                    0.0s
 => [web internal] load metadata for docker.io/library/python:3.8-slim                                                             1.0s
 => [nginx internal] load .dockerignore                                                                                            0.0s
 => => transferring context: 2B                                                                                                    0.0s
 => [nginx internal] load build definition from dockerfile.nginx                                                                   0.0s
 => => transferring dockerfile: 159B                                                                                               0.0s
 => [nginx internal] load metadata for docker.io/library/nginx:latest                                                              0.0s
 => [nginx internal] load build context                                                                                            0.0s
 => => transferring context: 398B                                                                                                  0.0s
 => CACHED [nginx 1/2] FROM docker.io/library/nginx:latest                                                                         0.0s
 => [nginx 2/2] COPY ./default.conf /etc/nginx/conf.d/default.conf                                                                 0.0s
 => [nginx] exporting to image                                                                                                     0.0s
 => => exporting layers                                                                                                            0.0s
 => => writing image     0.0s
 => => naming to docker.io/library/dockerfile-folder-nginx                                                                         0.0s
 => [web 1/5] FROM docker.io/library/python:3.8-slim@s     0.0s
 => [web internal] load build context                                                                                              0.0s
 => => transferring context: 2.03kB                                                                                                0.0s
 => CACHED [web 2/5] WORKDIR /app                                                                                                  0.0s
 => CACHED [web 3/5] COPY requirements.txt .                                                                                       0.0s
 => CACHED [web 4/5] RUN pip install --no-cache-dir -r requirements.txt                                                            0.0s
 => [web 5/5] COPY . .                                                                                                             0.0s
 => [web] exporting to image                                                                                                       0.0s
 => => exporting layers                                                                                                            0.0s
 => => writing image                                     0.0s
 => => naming to docker.io/library/dockerfile-folder-web                                                                           0.0s
[+] Running 5/3
 ✔ Network dockerfile-folder_backend    Created                                                                                    0.0s 
 ✔ Network dockerfile-folder_default    Created                                                                                    0.0s 
 ✔ Container mysql-container-web        Created                                                                                    0.1s 
 ✔ Container dockerfile-folder-nginx-1  Created                                                                                    0.0s 
 ✔ Container dockerfile-folder-web-1    Created                                                                                    0.1s 
Attaching to dockerfile-folder-nginx-1, dockerfile-folder-web-1, mysql-container-web

docker-compose logs nginx #에러가 있을 경우

* 참고자료

https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/

https://newwisdom.tistory.com/105

https://medium.com/@rajani103/deploying-a-noteapp-project-by-nginx-920067dca1b5

[DOCKER] Docker Compose

PeonyF — Mon, 8 Jan 2024 19:36:17 +0900

Docker Compose

단일 서버에서 여러개의 컨테이너를 하나의 서비스로 정의해 컨테이너의 묶음으로 관리할 수 있는 작업 환경을 제공하는 관리 도구

Docker Compose 사용 이유

여러 개의 컨테이너가 하나의 어플리케이션으로 동작시, 도커 컴포즈를 사용하지 않는다면, 이를 테스트하기 위해 각 컨테이너를 하나씩 생성해야 하기때문

ex. web application test = web server container,db container 각각 생성

Docker Compose 특징

run 명령어의 옵션을 그대로 사용 가능
각 컨테이너의 의존성,네트워크,볼륨등을 함께 정의 가능

Docker Compose 작성 방법

Compose에서는 YAML파일을 사용하여 application 서비스를 구성(명세)함
Compose 파일의 기본 양식은 compose.yaml 혹은 compose.yml 이다.
Compose는 다음과 같이 3단계 프로세스로 진행됨
1. Dockerfile에 애플리케이션을 작성. → 어디서나 재현가능한 환경을 제공
2. application 서비스들을 compose.yml에 정의하여 함께 실행될 수 있도록 함
3. docker compose up을 통해 전체 앱을 실행

Docker Compose 구조

Version : 지원 버전 확인
Service : 도커 컴포즈로 생성할 각 컨테이너의 옵션을 정의

version: '3'
services:
  web:
    build: . # build 항목에 정의된 도커파일에서 이미지를 빌드해 서비스의 컨테이너를 생성하도록 설정(현재 디렉토리일 경우 .)
    command: npm start # 컨테이너가 시작될 때 실행될 명령어를 지정
    ports: #서비스의 컨테이너를 개방할 포트 설정
      - "8080:80"
    depends_on: # 이 서비스가 의존하는 다른 서비스를 지정
      - db
    links: # 다른 서비스에 서비스명만으로 접근할 수 있도록 설정
      - db:database
    extends: # 다른 yaml 파일이나 현재 yaml 파일에서 서비스 속성을 상속 받도록 설정
      file: common-services.yml # 다른 파일에서 서비스 정의를 상속받음
      service: webbase

  db:
    image: mysql
    ports:
      - "3306:3306"
    environment: # 서비스의 컨테이너 내부에서 사용할 환경변수를 지정, 딕셔너리나 배열 형태로 사용할 수 있음 
      - MYSQL_ROOT_PASSWORD=password
      - MYSQL_USER=user
      - MYSQL_PASSWORD=password
      - MYSQL_DATABASE=demodb
    command: --default-authentication-plugin=mysql_native_password # 데이터베이스를 시작할 때 사용할 명령어 옵션을 지정

Network : Service는 Network를 통해 서로 통신

networks:
  mynetwork:
    driver: overlay
    driver_opts:
      subnet: "255.255.255.0"  # 스웜 모드나 주키퍼를 사용하는 환경이어야만 생성(일반적으로 overlay에선 사용x)
    ipam:
      driver: default  # 'mydriver'는 예시이며, 실제 사용 가능한 IPAM 드라이버를 지정해야 합니다.
      config:
        - subnet: "172.20.0.0/16"
          ip_range: "172.20.5.0/24"
          gateway: "172.20.5.1"

Volume : 서비스는 영구적으로 유지해야 할 데이터를 Volume에 저장하고 공유함

volumes:
  myvolume:
    driver: local  # 'flocker'는 예시이며, 실제 사용할 볼륨 드라이버를 지정해야 합니다.
    driver_opts:
      type: "nfs"  # 이것은 NFS 볼륨을 예로 든 것이며, 사용할 볼륨의 실제 옵션에 따라 달라질 수 있음
      o: "addr=192.168.1.1,rw"
      device: ":/path/to/dir"
    external: true  #원래 프로젝트마다 volumes을 생성, 이때 external 옵션 설정시 기존 volumes을 사용함

실제 연습

1.mysql 설치 및 기본 설정

만약 datagrip을 써도 mysql에 들어가서 user등록을 해줘야한다.. ~~datagrip에서 될줄알고 한참을 했지만 실패했다..~~

https://study-ce.tistory.com/54 참고

1.apt update : sudo apt update

2.mysql 설치 : sudo apt install mysql-server (brew install mysql → brew services start mysql)

3.mysql 이름/password 설정

3-1. sudo mysql -u root -p

3-2. use mysql;

3-3. CREATE USER '{생성할 사용자 이름}'@'%' IDENTIFIED BY '{비밀번호}';

3-4. GRANT ALL PRIVILEGES ON *.* TO '{사용자 이름}'@'%';

3-5. FLUSH PRIVILEGES;

3-6. exit

sudo mysql -u root -p
use mysql;
CREATE USER '{생성할 사용자 이름}'@'%' IDENTIFIED BY '{비밀번호}';
GRANT ALL PRIVILEGES ON . TO '{사용자 이름}'@'%';
FLUSH PRIVILEGES;
exit;

4.mysql 설정 파일 수정(외부 접속 허용)

4-1. brew info mysql → ls /usr/local/etc/my.cnf or ls /usr/local/etc/my.cnf.d/sudo nano → /usr/local/etc/my.cnf

4-2. bind-address = 0.0.0.0 으로 수정(외부접속 허용)

4-3. sudo service mysql restart (or brew services restart mysql)

5.datagrip 연동

2.mysql table 작성

CREATE DATABASE IF NOT EXISTS dockerdb;
USE dockerdb;

CREATE TABLE IF NOT EXISTS users (
    id INT AUTO_INCREMENT PRIMARY KEY,
    username VARCHAR(50) NOT NULL,
    email VARCHAR(50) NOT NULL
);

INSERT INTO users (username, email) VALUES ('chacha', 'chacha@example.com');
INSERT INTO users (username, email) VALUES ('chacha_test', 'chacha_test@example.com')

3.docker-compose.yaml과 dockerfile 작성

/dockerfile-folder/web/app.py

import pymysql
from flask import Flask, jsonify

app = Flask(__name__)


def get_db_connection():
    return pymysql.connect(host='host.docker.internal',
                           user='docker_chacha',
                           password='1q2w3e4r',
                           db='dockerdb',
                           charset='utf8mb4')


@app.route('/')
def hello_world():
    return 'Hello World!'


@app.route('/users')
def list_users():
    connection = get_db_connection()
    cursor = connection.cursor(pymysql.cursors.DictCursor)
    cursor.execute("SELECT * FROM users")
    users = cursor.fetchall()
    cursor.close()
    connection.close()
    return jsonify(users)


if __name__ == '__main__':
    app.run(debug=True, host='0.0.0.0')

/dockerfile-folder/web/requirements.txt

FLASK==3.0.0
# MYSQL==0.0.3
PyMySQL==0.10.1
cryptography

/dockerfile-folder/web/dockerfile

FROM python:3.8-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
EXPOSE 5000
ENV NAME dockertest
CMD ["python", "app.py"]

dockerfile-folder/docker-compose.yaml

*도커 컴포즈의 파일 이름은 꼭 docker-compose로 해줘야 한다.

version: '3.8'

services:
  web:
    build: ./web
    ports:
      - "5000:5000"
    depends_on:
      - db
    environment:
      DATABASE_USER: ${MYSQL_USER}
      DATABASE_PASSWORD: ${MYSQL_PASSWORD}
      DATABASE_NAME: ${MYSQL_DATABASE}
    networks:
      - backend

  db:
    image: mysql:8.2
    container_name: mysql-container-web
    environment:
      MYSQL_ROOT_HOST: ${MYSQL_ROOT_HOST}
      MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD}
      MYSQL_USER: ${MYSQL_USER}
      MYSQL_PASSWORD: ${MYSQL_PASSWORD}
      MYSQL_DATABASE: ${MYSQL_DATABASE}
    ports:
      - "3306:3306"
    command: # 명령어 실행
      - "mysqld"
      - --character-set-server=utf8mb4
      - --collation-server=utf8mb4_unicode_ci
    volumes:
      - ./mysql/conf.d:/etc/mysql/conf.d # MySQL 설정 파일 위치
      - ./mysql/initdb.d/:/docker-entrypoint-initdb.d/  # 데이터베이스 초기화 sql

networks:
  backend:

/dockerfile-folder/.env

MYSQL_ROOT_HOST=localhost
MYSQL_ROOT_PASSWORD=
MYSQL_USER=docker_chacha
MYSQL_PASSWORD=
MYSQL_DATABASE=dockerdb

4. 실행시켜서 확인한다.

docker-compose build
docker-compose up -d # Background로 도커 컴포즈 프로젝트 실행

#파일 수정 시
docker-compose down # 프로젝트 내 컨테이너 및 네트워크 종료 및 제거
docker-compose build --no-cache
docker-compose up

% docker-compose build           
[+] Building 3.0s (11/11) FINISHED                                                                                 docker:desktop-linux
 => [web internal] load .dockerignore                                                                                              0.0s
 => => transferring context: 2B                                                                                                    0.0s
 => [web internal] load build definition from dockerfile                                                                           0.0s
 => => transferring dockerfile: 837B                                                                                               0.0s
 => [web internal] load metadata for http://docker.io/library/python:3.8-slim                                                              2.8s
 => [web auth] library/python:pull token for registry-1.docker.io                                                                  0.0s
 => [web 1/5] FROM http://docker.io/library/python:3.8-slim@sha256:d1cba0f8754d097bd333b8f3d4c655f37c2ede9042d1e7db69561d9eae2eebfa        0.0s
 => [web internal] load build context                                                                                              0.0s
 => => transferring context: 1.80kB                                                                                                0.0s
 => CACHED [web 2/5] WORKDIR /app                                                                                                  0.0s
 => CACHED [web 3/5] COPY requirements.txt .                                                                                       0.0s
 => CACHED [web 4/5] RUN pip install --no-cache-dir -r requirements.txt                                                            0.0s
 => [web 5/5] COPY . .                                                                                                             0.0s
 => [web] exporting to image                                                                                                       0.0s
 => => exporting layers                                                                                                            0.0s
 => => writing image sha256:4012d3f308eda6190aa7e5796bdf1d42ea7d18f16391bf9c62f5db8e2cdb13c6                                       0.0s
 => => naming to http://docker.io/library/dockerfile-folder-web                                                                            0.0s
% docker-compose up -d
[+] Building 0.0s (0/0)                                                                                            docker:desktop-linux
[+] Running 2/2
 ✔ Container mysql-container-web      Running                                                                                      0.0s
 ✔ Container dockerfile-folder-web-1  Started                                                                                      0.6s
(base) choimijung@choemijeong-ui-noteubug ~/Desktop/dockerfile-folder %

웹사이트에서 확인

발생했던 문제상황

문제1. unable to prepare context: path "/dockerfile-folder/web" not found

→ Docker Compose는 ./web 디렉토리에서 Dockerfile을 찾으려고 시도하지만 해당 디렉토리가 존재하지 않아 실패 아래와 같이 디렉토리 변경

/dockerfile-folder/
├── web/
│   ├── Dockerfile
│   ├── app.py
│   ├── requirements.txt
│   └── ... (기타 필요한 파일들)
└── docker-compose.yml

발생 이유 : docker-compose.yaml 파일이 아래와 같이 build가 ./web에서 진행되기 때문

문제2 . local mysql에 있지만 docker mysql에는 값이 없었다.(pymysql.err.ProgrammingError: (1146, "Table 'dockerdb.users' doesn't exist"))

→ docker-compose.yaml에 아래와 같이 추가

    command: # 명령어 실행
      - "mysqld"
      - --character-set-server=utf8mb4
      - --collation-server=utf8mb4_unicode_ci
    volumes:
      - ./mysql/conf.d:/etc/mysql/conf.d # MySQL 설정 파일 위치
      - ./mysql/initdb.d/:/docker-entrypoint-initdb.d/  # 데이터베이스 초기화 sql

→ app.py의 host에 db대신 'host.docker.internal' 로 값 변경

def get_db_connection():
#기존 코드
    return pymysql.connect(host='db',
#바뀐 코드
    return pymysql.connect(host='host.docker.internal',
                           user='docker_chacha',
                           password='',
                           db='dockerdb',
                           charset='utf8mb4')

발생 이유

volume 추가:

hostsystem-container간의 디렉토리 공유를 위해서

./mysql/conf.d:/etc/mysql/conf.d: MySQL 설정 파일을 Docker 컨테이너와 공유

--character-set-server=utf8mb4: 문자 인코딩을 utf8mb4로 설정

./mysql/initdb.d/:/docker-entrypoint-initdb.d/:

→ MySQL 인스턴스가 처음 시작될 때 실행할 SQL 파일이나 스크립트를 담고 있 필요한 데이터베이스, 테이블, 기본 데이터 등을 자동으로 설정(users 테이블을 생성하는 SQL 파일 포함)

'host.docker.internal'로 변경:

'db'라는 호스트 이름은 일반적으로 Docker 네트워크 내에서 다른 컨테이너를 가리킬 때 사용(~~이것 때문에 엄청 고생했다..)~~ 따라서 db라는 이름으로 연결하려고 시도하면 실제 데이터베이스 호스트를 찾을 수 없다.

host.docker.internal : 애플리케이션이 Docker 내부에서 실행되고 있더라도, 이 설정을 통해 Docker 외부에 있는 MySQL 서버에 접근 할 수 있다.

왜? docker container 내부에서 localhost는 container 자신을 의미함(lockerhost = docker conainer 내부)

문제2 발생시 확인 방법

1. docker-compose ps 사용해서 제대로 돌아가고 있는지 확인

% docker-compose ps  # 도커 컴포즈 프로젝트 목록 확인
NAME                     IMAGE       COMMAND                         SERVICE   CREATED          STATUS          PORTS
dockerfile-folder-db-1   mysql:8.2   "docker-entrypoint.sh mysqld"   db        11 minutes ago   Up 11 minutes   3306/tcp, 33060/tcp

2. 정확하게 어느 부분에서 에러가 나고 있는지 확인

% docker-compose logs web
dockerfile-folder-web-1  |  * Serving Flask app 'app'
dockerfile-folder-web-1  |  * Debug mode: on
dockerfile-folder-web-1  | WARNING: This is a development server. Do not use it in a production deployment. Use a production WSGI server instead.
dockerfile-folder-web-1  |  * Running on all addresses (0.0.0.0)
dockerfile-folder-web-1  |  * Running on http://127.0.0.1:5000
dockerfile-folder-web-1  |  * Running on http://172.21.0.3:5000
dockerfile-folder-web-1  | Press CTRL+C to quit
dockerfile-folder-web-1  |  * Restarting with stat
dockerfile-folder-web-1  |  * Debugger is active!
dockerfile-folder-web-1  |  * Debugger PIN: 124-494-128
dockerfile-folder-web-1  | 192.168.65.1 - - [03/Jan/2024 05:22:53] "GET / HTTP/1.1" 200 -
dockerfile-folder-web-1  | 192.168.65.1 - - [03/Jan/2024 05:23:00] "GET /users HTTP/1.1" 500 -
dockerfile-folder-web-1  | Traceback (most recent call last):
...
dockerfile-folder-web-1  |   File "/app/app.py", line 24, in list_users
dockerfile-folder-web-1  |     cursor.execute("SELECT * FROM users")
dockerfile-folder-web-1  |   File "/usr/local/lib/python3.8/site-packages/pymysql/cursors.py", line 163, in execute
dockerfile-folder-web-1  |     result = self._query(query)
...
dockerfile-folder-web-1  |   File "/usr/local/lib/python3.8/site-packages/pymysql/protocol.py", line 223, in raise_for_error
dockerfile-folder-web-1  |     err.raise_mysql_exception(self._data)
dockerfile-folder-web-1  |   File "/usr/local/lib/python3.8/site-packages/pymysql/err.py", line 107, in raise_mysql_exception
dockerfile-folder-web-1  |     raise errorclass(errno, errval)
dockerfile-folder-web-1  | pymysql.err.ProgrammingError: (1146, "Table 'dockerdb.users' doesn't exist")
dockerfile-folder-web-1  | 192.168.65.1 - - [03/Jan/2024 05:23:01] "GET /users?__debugger__=yes&cmd=resource&f=debugger.js HTTP/1.1" 304 -

3-1.Flask 애플리케이션이 실행 중인 dockerfile-folder-web-1 컨테이너의 쉘에 접속 → app 코드 직접 입력

% docker compose ps
NAME                      IMAGE                   COMMAND                         SERVICE   CREATED          STATUS          PORTS
dockerfile-folder-db-1    mysql:8.2               "docker-entrypoint.sh mysqld"   db        11 minutes ago   Up 11 minutes   3306/tcp, 33060/tcp
dockerfile-folder-web-1   dockerfile-folder-web   "python ./app.py"               web       11 minutes ago   Up 11 minutes   0.0.0.0:5000->5000/tcp

#ps로 Name확인 후 해당 container 접속
% docker exec -it dockerfile-folder-web-1 /bin/sh

# Python 실행
python
>>> import pymysql
>>> 
>>> # Use the same credentials and host as in your Flask app
>>> conn = pymysql.connect(
...     host='db',  # This is the service name in docker-compose
...     user='docker_chacha',  # Your database username
...     password='1111',  # Your database password
...     db='dockerdb',  # Your database name
... )
>>> 
>>> # Now, try to execute a simple query
>>> with conn.cursor() as cursor:
...     cursor.execute("SHOW TABLES;")
...     print(cursor.fetchall())
... 
0
()
>>> conn.close()

#"SHOW TABLES;" 쿼리를 실행한 결과 0 ()가 반환됨 ->   해당 데이터베이스(dockerdb)에 테이블이 없다는 것을 의미

3-2. Flask 애플리케이션이 실행 중인 dockerfile-folder-web-1 컨테이너의 쉘에 접속-> mysql 접속 및 실행

dockerfile안에 내용 변경

FROM python:3.8-slim
WORKDIR /app
COPY requirements.txt .
RUN apt-get update && apt-get install -y iputils-ping \
    && apt-get install -y --no-install-recommends default-mysql-client \
    && apt-get clean \
    && rm -rf /var/lib/apt/lists/*
RUN pip install -r requirements.txt
COPY . .
EXPOSE 5000
ENV NAME dockertest
CMD ["python", "app.py"]

docker exec -it dockerfile-folder-db-1 /bin/bash

# MySQL 클라이언트 실행
mysql -u docker_chacha -p

# 패스워드 입력:

*참고자료

따라하며 배우는 도커와 CI환경 강의

https://velog.io/@whattsup_kim/Docker-Compose-Compose-Specification

https://seosh817.tistory.com/387

https://developerbee.tistory.com/236

https://shawn-dev.oopy.io/463a30bf-bf32-44e4-88be-8b4722e5549a

https://stackoverflow.com/questions/44543842/how-to-connect-locally-hosted-mysql-database-with-the-docker-container/61480668#61480668

https://marklee1117.tistory.com/93

[Docker] Docker Volume

PeonyF — Tue, 2 Jan 2024 19:59:52 +0900

Docker Storage 필요성

1. Docker Layer = Container Layer + Image Layer

Image Layer = Read Only : Docker Image는 읽기전용이며 어떠한 경우에도 변경되지 않음(변경사항 적용X)
Container Layer = Writable
Writable Layer : 컨테이너가 생성될때, Dockers는 읽기 전용 이미지 위에 “Writable Layer”를 추가

→ 이 레이어에서 컨테이너 내의 변경사항(파일 추가,수정,삭제 등)이 처리됨

Writable Layer의 휘발성 : Container 삭제시 Writable Layer에 저장된 모든 데이터도 함께 삭제됨

2. Container의 Data 저장 문제점(휘발성)

Container의 Writable Layer에 Data를 저장할 수 있지만 몇가지 문제점이 있음

Container 삭제시 Data 삭제 → 다른 Process에서 Container에 저장된 Data를 사용X
이미지를 통해 Container를 만들면 Container는 읽기 전용이 되고 컨테이너 변경사항만 별도로 저장하여 컨테이너 정보를 보존한다. 이때 이미지는 어떠한 경우로도 변경되지 않는다.
Container의 Writable Layer가 실행중인 host system과 밀접하게 연결 (Writable Layer가 실행 중인 host storage system에 저장되어 관리되기 때문) + Container의 생명주기와 연결되어있어 = 데이터를 다른곳으로 옮기기 힘듦(데이터를 다른 시스템으로 이전시 변환과정 필요 및, 데이터가 지속적으로 있단 보장이 없음)

Docker Storage

컨테이너 상에서 볼륨을 영구적으로 사용할 수 있는 방법은 세가지가 있다.

Docker Volume
Bind Mounts
tmpfs Mounts

Docker Volume

Docker가 제공하는 불륨 관리 기능을 통해서 볼륨을 생성하고 삭제,관리를 할 수 있다.
Volume이란 Host file system에 저장되는 디렉터리나 파일로, Container의 Union 파일 시스템 외부에 존재
Linux 시스템에서 볼륨은 일반적으로 /var/lib/docker/volumes/ 디렉터리 아래에 저장되어 Docker는 이 Volume을 관리하고 Volume에 저장된 데이터는 Host file system의 일부로 존재함

Host file system 이란?

Docker가 실행되고 있는 컴퓨터의 파일 시스템(OS가 파일을 저장하고 관리하는 방식: 파일 저장,삭제,수정)

즉, Docker 환경에서 호스트 파일 시스템은 Docker의 컨테이너, 이미지, 그리고 볼륨을 저장하는 기반

호스트 파일 시스템
│
├── Docker 이미지 (읽기 전용 레이어) : 호스트 파일 시스템에 저장되며 컨테이너를 시작시 사용
│
├── Docker 컨테이너
│   ├── 읽기 전용 레이어 (이미지에서 가져옴)
│   └── 쓰기 가능 레이어 (컨테이너 레이어): 컨테이너 실행시 '읽기 전용 레이어'위에 '쓰기 가능 레이어'를 추가
└── Volumes
    └── 영구적 데이터 저장: 컨테이너에 마운트되어 데이터를 보관

Volume은 Container의 데이터를 영속적으로 저장하고 Container 사이에 데이터를 공유하기 위해 사용, Container가 삭제되어도 Volume에 저장된 데이터는 유지됨

Docker Volume VS COPY

Volume : 로컬머신(Docker가 설치되고 실행되는 기본 시스템)에 있는것을 맵핑(참조)해서 도커 컨테이너에서 실행

개발때 소스 변경시 다시 이미지를 빌드하지 않고 변경한 소스부분이 application에 적용하도록 하기 위해

Copy: 로컬머신에 있는 파일을 도커 컨테이너에 복사

Docker Volume 장점

Volume은 Bind Mount보다 백업, 마이그레이션이 더 쉬움
Volume은 다른 컨테이너 간에 데이터를 공유하는 데에도 사용
Docker CLI 명령, Docker API를 사용해 Volume을 관리 할 수 있음
Docker Desktop의 Volume은 Mac,Window host의 바인드 마운트보다 성능이 훨씬 높다.
Volume은 이를 사용하는 Container크기를 늘리지 않고 Volume의 컨텐츠가 지정된 Container의 수명 주기 외부에 존재해서 Container의 Writable Layer에 데이터를 유지하는 것보다 Volume을 선택하는것이 더 나은 경우가 많다

Docker Volume 사용 사례

실행 중인 여러 Container 간에 Data 공유가 필요한 경우
- 여러 Container가 동일한 volume을 읽기/쓰기 또는 읽기 전용으로 동시에 Mount할 수 있다.
Docker Host가 특정 디렉토리나 파일 구조를 가질 수 없는 경우
- volume은 Container Runtime으로부터 Docker Host의 설정을 분리할 수 있다.
로컬외의 원격 Host 및 Cloud Provider에 Container의 Data를 저장하려는 경우
- A Docker Host → B Docker Host로 백업,복구,migration시 volume을 사용하는게 좋다.
- volume을 사용하여 Container를 중지한 다음 volume의 디렉토리(예: /var/lib/docker/volume/<volume-name>)를 백업할 수 있다.

Docker Volume 코드

% docker volume create testvolume
testvolume

# nginx를 testvolume에 영구 설치함, -d는 백그라운드에서 실행하란 명령어
# -v testvolume:/app/data는 testvolume : 볼륨을 컨테이너의 /app/data 디렉토리에 마운트하라고 명령
% docker run -d -v testvolume:/app/data --name mycontainer nginx

Unable to find image 'nginx:latest' locally
latest: Pulling from library/nginx
24e221e92a36: Pull complete 
58cc89079bd7: Pull complete 
3799b53049f3: Pull complete 
2a580edba2f4: Pull complete 
cfe7877ea167: Pull complete 
6f26751fc54b: Pull complete 
c98494bb3682: Pull complete 
Digest: sha256:2bdc49f2f8ae8d8dc50ed00f2ee56d00385c6f8bc8a8b320d0a294d9e3b49026
Status: Downloaded newer image for nginx:latest
4d16388a956dca7f49b4059d31d84512005653fc242f3720a723e82e64b69e68

 % docker volume ls
DRIVER    VOLUME NAME
local     5f349cb6b961a651e3b2ab8395dfa011e6e6a4284cb1a8d028b9c4b213d1805d
local     23af4fea9ed9bcbdcae9fe69228324bb27714363c3ce3e31e83260793e0fef17
local     testvolume

 % docker volume inspect testvolume
[
    {
        "CreatedAt": "2024-01-02T05:07:59Z",
        "Driver": "local",
        "Labels": null,
        "Mountpoint": "/var/lib/docker/volumes/testvolume/_data",
        "Name": "testvolume",
        "Options": null,
        "Scope": "local"
    }
]

% docker run -d -v testvolume:/app/data --name testcontainer nginx
c9e06651da1b2b067a8ecfefefb18ae4f63b05b5b10197bce6e9721806199018

% docker ps
CONTAINER ID   IMAGE     COMMAND                   CREATED          STATUS          PORTS      NAMES
c9e06651da1b   nginx     "/docker-entrypoint.…"   56 seconds ago   Up 56 seconds   80/tcp     testcontainer
4d16388a956d   nginx     "/docker-entrypoint.…"   4 minutes ago    Up 4 minutes    80/tcp     mycontainer


% docker stop testcontainer
testcontainer
% docker stop mycontainer
mycontainer
% docker rm testcontainer
testcontainer
% docker rm mycontainer
mycontainer
% docker volume rm testvolume
testvolume

Bind Mounts

host file system의 특정 파일이나 디렉토리를 컨테이너의 파일 시스템에 마운트 하는 방법

+---------------------+      +----------------------+
|   호스트 시스템        |      |    Docker 컨테이너      |
|                     |      |                      |
|  /path/to/data      |      |  /app/data           |
|  (실제 데이터)         |      |  (마운트 포인트)        |
|                     |      |                      |
+---------------------+      +----------------------+

Mount(마운트)란?

저장된 데이터를 다른 위치(시스템,프로그램)에서 접근할 수 있도록 연결하는 과정

ex.

로그파일을 호스트의 ‘/var/log/myapp’에 저장
컨테이너의 ‘/app/log’에 마운트

→ /app/log는 마운트 포인트, 실제 호스트는 ‘/app/log’에 있지만 컨테이너는 마치 자신내부에 데이터가 있는것 처럼 ‘/app/log’를 통해 로그 파일에 접근,관리함

즉, ‘/app/log’ 경로로 접근시 실제 호스트 ‘/var/log/myapp’의 내용을 사용

로그파일의 실제 호스트는 ‘/var/log/myapp’에 쓰여짐

Bind Mounts 장점

데이터의 실제 저장 위치와 상관없이 다양한 시스템,프로그램 간에 데이터를 공유하고 접근할 수 있는 유연성을 얻을 수 있다.

Bind Mounts 사용 사례

일반적인 경우, 가능하면 bind Mounts보다 volume을 사용하는게 좋다.
Docker Host 개발환경과 Container 간 소스코드 또는 빌드된 artifact를 공유
1. Maven의 target/ 디렉토리를 Container에 Mount → Docker Host에서 Maven Project를 빌드할 때마다, Container에서 재 작성된 작성된 JAR/WAR에 접근
2. 만약 bind mounts 사용한다면 Production-Ready 아티팩트를 Image에 직접 복사할 수 있다.

Bind Mounts VS Docker Volume

	Volume	Bind Mounts
관리 방식	Docker에 의해 관리 Docker CLI,API를 통해 생성,삭제,관리됨	사용자가 직접 host system file이나 디렉토리 관리
사용시	호스트 시스템의 Docker 저장소 디렉터리 내에 새 디렉터리가 생성되고 Docker는 해당 디렉터리의 콘텐츠를 관리	호스트 파일 시스템 접근 : 호스트 시스템의 절대 경로를 사용해 특정 파일,디렉토리 지정 컨테이너 내 위치 지정: 컨테이너 내부에서 해당 파일이나 디렉토리를 어디에 마운트할 것인지 위치 지정 Q. 컨테이너에 저장되면 컨테이너 삭제시 데이터도 삭제 되는가? A. 컨테이너 내부에서 데이터를 보고 사용할 수 있지만, 실제 데이터는 호스트의 파일 시스템에 존재 ex. 로그파일을 호스트의 ‘/var/log/myapp’에 저장 컨테이너의 ‘/app/log’에 마운트 (해당 경로로 접근시 실제 호스트 ‘/var/log/myapp’의 내용을 사용) 로그파일의 실제 호스트는 ‘/var/log/myapp’에 쓰여짐
저장 위치	Docker가 설정한 특정 경로에 저장	사용자가 지정한 호스트 시스템의 어떤 경로에든 위치
장점	데이터가 컨테이너가 삭제되어도 유지되어 재사용 가능 데이터를 격리할 수 있고 백업이 가능해 보안이 중요시 사용	개발과정에서 실시간으로 데이터를 공유, 업데이트시 사용 (직접 마운트하고 직접 경로 설정을 하기 때문)
관련 코드		docker run -v /home/user/myapp:/var/www/html myimage

tmpfs Mounts

tmpfs(temp orary file system) 임시파일 저장 방식, 데이터를 영구 저장이 아닌 휘발성 메모리에 저장한다.

tmpfs Mounts 특징

tmpfs mounts를 사용하여 컨테이너 생성시 tmpfs 컨테이너는 컨테이너의 쓰기 가능한 레이어 외부에 파일을 생성 할 수 있음
volume, bind mounts와 다르게 tmpfs mounts는 일시적이며 호스트 메모리에만 지속되기 때문에 컨테이너 중지시 tmpfs가 제거되고 데이터도 제거된다.
주로 호스트,Container writable layer에 유지하고 싶지 않은 민감한 파일을 임시로 저장하는데 유용하다.

Q. tmpfs mounts와 컨테이너의 쓰기 가능한 레이어(writable layer) 모두 컨테이너 삭제 시 데이터가 삭제되는데 무슨 차이가 있는건가?

	tmpfs mounts	container writable layer
	호스트 시스템의 메모리(램)에 데이터를 저장	디스크에 저장
장점	기존 디스크에 저장하는 방법보다 더 빠르게 데이터 접근 할 수 있다.	디스크에 저장된 레이어에는 컨테이너 실행 중에 생성되거나 변경되는 파일들이 저장된다.
특징	컨테이너가 중지/삭제되면 메모리에서 데이터가 사라짐	컨테이너가 삭제해야만 해당 레이어에 저장된 모든 데이터도 함께 삭제 (중지시 데이터 그대로 유지)
사용 방식	일시적 사용(세션 데이터,임시 파일 처리) 주로 민감함 데이터의 임시저장시 사용	일반적인 데이터 저장과 어플리케이션의 작업에 사용

tmpfs Mounts 제한사항

tmpfs mounts는 volume, bind mounts와 다르게 컨테이너 간에 마운트를 공유할 수 없다
Linux에서 Docker를 실행하는 경우에만 사용 할 수 있다.

*참고자료

https://docs.docker.com/storage/volumes/

https://docs.docker.com/storage/bind-mounts/

https://docs.docker.com/storage/tmpfs/

https://en.wikipedia.org/wiki/Tmpfs

https://medium.com/dtevangelist/docker-%EA%B8%B0%EB%B3%B8-5-8-volume%EC%9D%84-%ED%99%9C%EC%9A%A9%ED%95%9C-data-%EA%B4%80%EB%A6%AC-9a9ac1db978c

https://seosh817.tistory.com/374

https://velog.io/@hoplin/Docker-docker-volume

https://belowthemalt.com/2021/12/08/mount-volumes-to-persist-data-in-local-initialize-database-in-docker/

https://docs.aws.amazon.com/AmazonECS/latest/bestpracticesguide/storage.html

https://oertx.highered.texas.gov/courseware/lesson/2379/student/?section=5 https://oertx.highered.texas.gov/courseware/lesson/2379/student/?section=5

따라하며 배우는 도커와 CI환경 강의

[Docker] Docker 최적화

PeonyF — Thu, 28 Dec 2023 19:52:06 +0900

1. 생성된 레이어 재사용(캐싱)

기존코드1

문제점

Docker이미지 빌드시 Dockerfile의 각 명령어를 실행 → 해당 결과들을 새로운 레이어로 저장한다.
아래 코드는 소스 코드중 어떤 파일이든 변경되면 COPY ./ ./ 이후의 모든 레이어가 다시 빌드된다

→ 소스의 작은 변경이라도 RUN npm install 가 다시 실행된다.

FROM node:10
WORKDIR /usr/src/app
COPY ./ ./
RUN npm install
CMD ["node","server.js"]

수정코드1

수정된 이유

package.json 먼저 복사
1. package.json에 변경사항이 없다 → RUN npm install 명령어 까지의 모든 레이어 캐싱되어 재사용(npm 재설치 없이 빠르게 빌드 가능)
2. package.json에 변경사항이 있다 → RUN npm install 실행
이후 코드를 수정한 부분이 있는 COPY ./ ./ 를 복사

FROM node:10
WORKDIR /usr/src/app
COPY package.json ./
RUN npm install
COPY ./ ./
CMD ["node","server.js"]

기존코드2

문제점

모든 파일을 한번에 복사한 후 필요한 Python 패키지를 설치하는 방식

FROM python:3.8-slim
COPY . /app
WORKDIR /app
RUN pip install -r requirements.txt
EXPOSE 8080
ENTRYPOINT ["python"]
CMD ["run.py"]

수정코드2

수정된 이유

WORKDIR /app 의 순서 변경 → 작업 디렉토리를 명확히 하고, 모든 파일 경로와 명령 실행의 기준점을 설정하기 위함
requirements.txt를 먼저 복사 → 변경이 없을 경우 pip install 단계를 다시 실행하지 않음(기존 레이어 재사용)
이후 COPY ./app 명령어로 application의 나머지 부분 복사 → 변경이 없을 경우 기존 레이어 재사용

FROM python:3.8-slim
WORKDIR /app
COPY requirements.txt ./requirements.txt
RUN pip install --no-cache-dir -r requirements.txt
COPY ./app
EXPOSE 8080
#ENTRYPOINT : 컨테이너가 시작될 때 실행할 기본 명령을 설정
#컨테이너가 시작될 때 항상 Python 인터프리터를 사용하여 지정된 파이썬 스크립트(CMD에서 지정된 run.py 같은)를 실행
ENTRYPOINT["python"]
CMD["run.py"]

캐싱

변경이 잦은 파일들은 Dockerfile의 뒤에 COPY하는것이 좋고, 의존성 파일(ex.requirements.txt)은 먼저 복사하는게 좋다.

Docker이미지 빌드시 Dockerfile의 각 명령어를 실행하면서 해당 명령어의 결과 캐싱
만약 특정 명령어까지 변경사항이 없다면 Docker는 그 부분까지 캐싱된 결과(layer)를 재사용함
변경사항이 있는 명령어의 경우 이전의 캐시된 레이어를 사용할수 없으므로 그 명령어와 그 이후의 명령어들은 새로 실행되어 결과가 빌드됨

2. Dockerfile 최적화

더 작은 기본 이미지 사용

ex.multi-stage, 완전한 OS(ubuntu)대신 경량 Alpine Linux 이미지를 기본으로 사용

# 변경전
FROM ubuntu:20.04
RUN apt-get update && apt-get install -y python3-pip
...

# 변경후
FROM alpine:3.12
RUN apk add --no-cache python3 py3-pip
...

불필요한 파일 제거

.dockerignore 파일을 사용하여 빌드 컨텍스트에서 파일이나 디렉터리를 제외

# 버전관리 시스템 폴더
.git
.gitignore
.svn
.hg

# 빌드 도구 관련 파일 및 폴더
Dockerfile
Dockerfile.*
*docker-compose.yml
.dockerenv

#종속성 관련 폴더(파이썬)
.pip
.virtualenv
venv
.env

# 로그 파일 및 디렉토리
*.log
logs

# 임시파일 및 캐시파일
*.tmp
*.temp
*.cache

# 개발 도구 설정 파일
.vscode
.idea
*.swp

# 테스트 및 문서파일
tests
docs
doc
README.md

# 빌드 결과물 미 배포파일
dist
build
out

# 운영체제 관련 파일
.DS_Store
Thumbs.db

레이어 수 최소화

문제점 : 각 명령어는 새레이어를 생성함 → 레이어가 많으면 빌드 프로세스 속도 드려짐 → Docker image 크기 늘어남

RUN apt-get update
RUN apt-get install -y package1
RUN apt-get install -y package2

해결점 : RUN 명령을 사용해 여러 주문을 단일 명령어로 결합

RUN apt-get update && \
    apt-get install -y package1 && \
    apt-get install -y package2

ENV,올바른 CMD 및 ENTRYPOINT 사용

#ENV로 환경 설정 지정
FROM node:14
ENV NODE_ENV=production

#ENTRYPOINT로 Nginx 시작하라고 명령함
ENTRYPOINT ["nginx", "-g", "daemon off;"]
CMD ["-c", "/etc/nginx/nginx.conf"]

3. Multi-Stage Build사용

Multi-stage 코드

Builder 단계: Builder 단계에서 빌드된 결과물 생성 및 이 중간결과물을 캐시함
- 이미지에 포함되는 파일(O) : 설치된 Python 패키지, application 코드(/app)
- 이미지에 제거되는 파일(X) :
  - 소스코드 : 빌드를 위해 필요하지만, 실행파일이 생성되면 필요없음
  - 빌드파일 : gradlew,gradle 등 빌드과정을 자동화하는 스크립트,설정파일은 빌드후에는 필요없음
  - 중간 생성파일: 컴파일 과정에서 생성되는 클래스,로그 파일등은 필요없음
Deployer단계 : Builder 단계에서 빌드된 결과물(이미지 레이어)를 가져와서 최종 이미지 구성
- COPY --from=builder 를 통해 Builder 단계에서 필요한 결과물만 가져온다(빌드에 필요한 패키지, 라이브러리, 빌드된 소스 코드 등)

# Builder 단계
FROM python:3.8-alpine AS builder
RUN apk update && apk add --no-cache make && apk add --no-cache libpq-dev g++
WORKDIR /app
COPY requirements* ./
RUN pip install --no-cache-dir -r requirements-prod.txt
COPY Makefile . 
COPY src ./src

# Deployer(배포자) 단계
FROM python:3.8-alpine AS deployer
COPY --from=builder /usr/local/lib/python3.8/site-packages /usr/local/lib/python3.8/site-packages
COPY --from=builder /app /app
RUN apk update && apk add --no-cache make
WORKDIR /app

CMD ["make", "run-server"]

질문1. 만약 Builder 단계 혹은 Deployer(배포자) 단계에서 코드 수정이 생긴다면?

Builder 단계 코드 수정시 : 만약 requirements.txt가 변경시 pip install 를 통해 재설치 및 새로운 중간결과물을 생성한다. 이후 변경된 중간결과물을 Deployer(배포자) 단계에서 재빌드되어 최종 이미지에 반영됨
Deployer(배포자) 단계 코드 수정시 : 캐시된 Builder 단계의 결과물은 그대로 사용, Deployer(배포자) 단계에서 변경된 사항을 반영하기 위해 변경된 부분의 명령부터 이후의 모든 명령을 다시 실행

질문2. Multi-Stage Build에서 중간결과물을 사용해 특정 레이어의 결과물을 이전 단계(builder 단계)에서 가져와서 현재 이미지로 복사하는데, 일반 Docker 빌드와 레이어시에도 동일한가?

일반 Docker빌드시 각 명령어들이 순서대로 실행 → 새로운 레이어가 이전 레이어 위에 순차적으로 쌓임 → 최종 이미지 생성
일반 Docker빌드시 각 단계에서 생성된 레이어들을 건너뛰거나,선택적으로 사용하는게 아닌 모든 레이어가 최종 이미지에 포함됨

Multi-Stage Build

FROM문을 사용해 단계별로 이미지를 구성하고, 마지막 단계에서만 필요한 파일을 가져온다.
그 결과, 최종 이미지를 크게 줄이고, 필요한 부분만 포함시킬 수 있다.

참고문서

https://benriemer.medium.com/speed-up-docker-desktop-d676c9fe82de

따라하며 배우는 도커와 CI환경 강의

https://blog.annotation-ai.com/python-docker-img-optimization/

[Docker] Docker Container2 - 코드로 보는 개념

PeonyF — Tue, 26 Dec 2023 19:16:41 +0900

Docker 컨테이너내에 구성요소들이 적용될수있는 이유는?

Dockerfile을 통해 구성요소들을 설정해 준다.

* Dockerfile 내용

FROM adptopenjdk:8-jdk-hotspot AS builder #베이스이미지+별칭
COPY gradlew . #gradlew 복사
COPY gradle gradle #gradle 복사
COPY build.grade . #build.gradle 복사
COPY settings.gradle #settings.gradle 복사
COPY src src #웹 어플리케이션 소스 복사
RUN chmod +x ./gradlew #gradlew 실행권한 부여
RUN ./gradlew bootJar #gradlew를 사용하여 실행 가능한 jar 파일 생성

FROM adoptopenjdk:8-jdk-hotspot #베이스 이미지
COPY --from=builder build/libs/*/jar app.jar #builder 이미지에서 build/libs/*.jar 파일을 app.jar로 복사

EXPOSE 8080 #컨테이너 Port 노출
ENTRYPOINT ["java","-jar","/app.jar"] #jar 파일 실행

질문 1. gradlew이란?

gradle wrapper의 줄임말로 프로젝트에 gradle을 설치할 필요없이 어디서나 동일한 버전의 gradle을 사용하게 해준다.

gradlew를 사용하면 gradle이 사전에 설치되어있지 않아도 된다. gradlew 스크립트가 필요한 gradle버전을 자동으로 다운로드/실행한다.

질문 1-1. 왜 RUN chmod +x ./gradlew를 해주는가?

- 리눅스 or macOS에서 스크립트 파일을 실행하려면, 해당 파일의 실행권한이 필요함.

- 소스코드를 Docker 컨테이너로 복사시 파일 권한이 유지되지 않을 수 있어 Dockerfile에 명시적으로 실행 권한 부여

질문2. 이 코드는 멀티-스테이지 이다. 어떻게 알아볼수있는가?

- FROM 명령어가 두번 사용됨 (첫번째 FROM : 빌드과정에 사용될 베이스 이미지 정하고 builder라는 별명 붙임, 두번째 FROM : 최종이미지에 사용될 베이스 이미지를 지정-> application을 실행하는데 필요한 환경만을 포함)

# Use multi-stage builds
# syntax=docker/dockerfile:1
FROM golang:1.21
WORKDIR /src
COPY <<EOF ./main.go
package main

import "fmt"

func main() {
  fmt.Println("hello, world")
}
EOF
RUN go build -o /bin/hello ./main.go

FROM scratch
COPY --from=0 /bin/hello /bin/hello
CMD ["/bin/hello"]

- "COPY --from=builder build/libs/*/jar app.jar"를 통해 첫번째 스테이지('builder')에서 생성된 파일(JAR 파일)을 두번째 스테이지로 복사함을 통해 알 수 있다.

질문 2-1. 멀티-스테이지 빌드의 장점은?

- Generated images are smaller : 최종 이미지가 일반적으로 일반 빌드에서 생성된 이미지보다 훨씬 작다. (결과 이미지에는 application에 필요한 내용만 포함되지 때문)

- Faster deployment: 이미지가 작을수록 전송시간, CI/CD 빌드 속도가 빨라지고, 배포시간이 빨라지며 성능이 향상된다.

질문 2-1-1. 그렇게 좋다면 멀티-스테이지 빌드를 모든 dockerfile에서 사용해야 하는거 아닌가?

- 멀티-스테이지 빌드를 사용 O

대규모 또는 복잡한 어플리케이션 : 컴파일이 필요한 언어(Java,C++,Go)를 사용하는 대규모 어플리케이션의 경우 빌드 도구와 런타임 환경을 분리하는것이 좋다.
최적화된 이미지 크기 : 빌드 과정에서 생성되는 임시 파일,도구를 최종이미지에 제거하여 이미지 크기르르 줄이고 싶을때 유용하다.
기본 이미지 빌드 후 이미지 크기 확인하여 예상보다 클경우 멀티-스테이지 빌드 적용을 고민한다.

- 멀티-스테이지 빌드를 사용 X

단순한 어플리케이션, 작은 규모의 이미지 : 사용하는 언어나 프레임 워크가 이미 최소화된 이미지 크기를 제공시

질문 2-1-2. 컴파일이 필요한 언어의 경우 멀티-스테이지 빌드를 사용 O라고 했는데 파이썬은은 그럼 멀티-스테이지 빌드를 사용 X인가?

~~- 파이썬은 인터프리터 언어(컴파일 과정없이 실행 시간에 직접 해석되어 실행)~~

- 파이썬은 간단한 빌드과정 즉 소스코드가 직접 실행되므로 복잡한 빌드과정이 필요하지 않아 대부분 소스코드와 필요한 외부 라이브러리를 이미지에 복사하는 것만으로 충분하다.

~~예외) 파이썬 프로젝트에서 C/C++로 작성된 네이티브 확장 모듈을 컴파일해야 하는 경우~~

크기,상황 에 따라 다른것 같음(구글링시에 찬반의견보단 어떻게 python을 multi-staging build하냐 라는 글들만 있음)

사용 예시 : https://blog.annotation-ai.com/python-docker-img-optimization/

FROM python:3.8-alpine AS builder

RUN apk update && apk add --no-cache make && apk add --no-cache libpq-dev g++

WORKDIR /app
COPY requirements* ./
RUN pip install --no-cache-dir -r requirements-prod.txt
COPY Makefile . 
COPY src ./src


FROM python:3.8-alpine AS deployer
COPY --from=builder /usr/local/lib/python3.8/site-packages /usr/local/lib/python3.8/site-packages
COPY --from=builder /app /app
RUN apk update && apk add --no-cache make
WORKDIR /app

CMD ["make", "run-server"]

질문 2-2. 위의 java dockerfile의 경우 왜 멀티-스테이지를 사용하는가? 각 필요파일을 복사해서 jar파일 만들고 그걸 다시 복사하는건데.

- 불필요한 파일 제거

첫번째 스테이지에서 최종 실행 이미지에 필요없는 것들이 만들어진다.

ex. 소스코드 : 빌드를 위해 필요하지만, 실행파일이 생성되면 필요없음

빌드파일 : gradlew,gradle 등 빌드과정을 자동화하는 스크립트,설정파일은 빌드후에는 필요없음

중간 생성파일: 컴파일 과정에서 생성되는 클래스,로그 파일등은 필요없음

질문 2-2-1. 그럼 'adoptopenjdk:8-jdk-hotspot'를 왜 또하는가?

java application을 실행하는데 필요한 최소한의 java 라이브러리와 도구들이 포함된다.

* Dockerfile build

docker build -t deploy-test:0.0.1

* Dockerfile 실행

docker run -d -p 8080:8080 deploy-test:0.0.1

-python 위의 코드의 경우 (my-running-app : Docker 컨테이너의 이름)

docker run -d --name my-running-app deploy-test:0.0.1

참고자료

https://docs.docker.com/guides/walkthroughs/what-is-a-container/#what-is-a-container

https://docs.docker.com/config/containers/runmetrics/

https://www.netapp.com/devops-solutions/what-are-containers/

https://www.linkedin.com/pulse/cgroups-docker-pavan-shukla/

https://inma.tistory.com/148

https://docs.docker.com/build/building/multi-stage/

https://www.cherryservers.com/blog/docker-multistage-build

https://blog.annotation-ai.com/python-docker-img-optimization/

https://www.vantage-ai.com/vantage101/chapter-9-docker

https://kimjingo.tistory.com/38

https://medium.com/echo-devblog/%EB%8F%84%EC%BB%A4%EB%A5%BC-%EB%8F%84%EC%9E%85%ED%95%98%EB%8A%94-%EC%9D%B4%EC%9C%A0-1-%EC%BB%A8%ED%85%8C%EC%9D%B4%EB%84%88-%EA%B8%B0%EC%88%A0-%EC%9B%90%EB%A6%AC-90a28c14024e

https://stackoverflow.com/questions/51765555/what-namespaces-are-shared-among-containers-in-a-kubernetes-pod

https://platform.sh/blog/the-container-is-a-lie/

[Docker] Docker Image

PeonyF — Tue, 26 Dec 2023 19:01:44 +0900

Docker Image란?

An image is a read-only template with instructions for creating a Docker container. Often, an image is based on another image, with some additional customization. For example, you may build an image which is based on the ubuntu image, but installs the Apache web server and your application, as well as the configuration details needed to make your application run

Docker Container를 만들기 위한 명령이 있는 읽기 전용 템플릿.
어떤 이미지의 경우 다른 이미지 기반 + 추가적인 사용자의 정의 으로 되어있다.
공개 Docker image는 Docker Hub에 있어서 여기서 관련 공개 이미지를 찾는다.

ex.ubuntu image+aphache webserver + application + application을 실행하는데 필요한 세부정보

Docker Container

Docker Image를 통해 application을 실행하기 위해 모든것(코드,런타임,시스템 도구,시스템 라이브러리 설정등)을 포함하고 있는 기술인데, 이 기술을 통해 어느 환경에서나 일관된 방식으로 실행할수 있다.

Docker Container VS Docker Image

Docker Container	Docker Image
Docker Image를 기반으로 실행되는 각각 컨테이너가 그 이미지의 “실행버전” (인스턴스화) (이미지의 상태를 복제하여 실행함)	Docker Image는 Docker Container의 소스 코드
Docker Image는 Docker Container의 전제조건 (Dockerfile로부터 이미지를 빌드한 이미지를 기반으로 컨테이너를 실행)	Dockerfile은 Docker Image의 필수 구성요소 (Dockerfile로부터 이미지를 빌드)
Docker Container는 유저들끼리 공유할수 없다. (컨테이너는 실행 중인 이미지 인스턴스여서 동적이고 일시적이라 공유X)	Docker Image는 Docker Hub를 통해 사용자간에 공유 가능
Docker Container는 컨테이너가 실행중일때 사용자가 컨테이너 내부에 들어가 바로 수정 가능하다. (docker exec 명령어 사용)	Docker Image를 수정하기 위해서는 Dockerfile를 수정해야한다.

Docker Image 특징

이미지는 상태값을 가지지 않고 변하지 않는다.
하나의 이미지는 여러 컨테이너를 생성할 수 있고, 컨테이너가 삭제되더라도 이미지는 변하지 않고 그대로 남아있다.
도커 이미지들은 Docker Hub를 통해 버전 관리 및 배포(push & pull)가 가능하다
다양한 API가 제공되어 원하는 만큼 자동화가 가능하다
도커는 Dockerfile이란 파일로 이미지를 만든다. 이 파일엔 소스와 함께 의존성 패키지등 사용했던 설정 파일을 버전 관리하기 쉽게 명시되어 누구나 이미지 생성과정을 확인,수정이 가능하다.
도커 이미지는 플랫폼에 독립적이다

Docker Image 구성

ex.ubuntu image+aphache webserver + application + application을 실행하는데 필요한 세부정보

Base Image	Dockerfile을 작성시 시작점이 되는 이미지(최소한의 운영체제,필수 구성 요소 포함) ex. base image: ubuntu
Parent Image	base image기반으로 새로운 image를 만드는데 이것을 parent Image라고 한다. 여기서 parent imagesms dockerfile에서 “FROM” 명령어를 사용해서 지정된다 FROM python:3.8 → Python 3.8이 설치된 이미지를 부모 이미지로 사용하겠다는 것을 의미 ex. 만약 Ubuntu image + Apache webserver + Application + Application의 세부 정보를 기반으로 다른 이미지를 만들 경우 Ubuntu image + Apache webserver + Application + Application가 parent Image 만약 다른 이미지를 만드는 기반으로 사용된다면, 그때 그 이미지는 "parent image"
Layers	레이어란 기존 이미지에 추가적은 파일이 필요할때 해당 파일을 추가하는 개념이다. (다시 다운로드 x) 이미지는 여러개의 읽기 전용 layer로 구성 파일 추가시 새로운 layer생성 docker는 여러개의 layer를 묶어 하나의 파일 시스템으로 사용할수있게 함 + Docker Hub 및 개인 저장소에 이미지 공유시 바뀐부분(Layer=image)만 주고받기 가능하다 ex. Aphache webserver Layer : RUN 명령어를 사용해 해당 webserver설치 Application Layer : COPY, RUN 명령어를 사용해 application file 복사및 필요 의존성 설치 Application 세부정보 Layer : ENV, COPY, CMD 명령어를 사용해 환경변수 설정,구성 파일 복사, 실행 명령 정의등 세부 설정 포함
Docker Registry	Docker image를 저장/배포함(ex.Docker Hub) layer 저장 : Docker image를 Docker registry에 push하면 각 layer는 개별적으로 업로드,저장됨 → 필요한 layer만 다운로드해서 이미지를 재구성 가능하게 한다. layer 공유 : 재사용성을 높이기 위해 같은 베이스 이미지 사용시 서로 다른 이미지들을 해당 베이스 레이어를 공유 → 중복 다운로드 방지,저장 공간 절약

의 경우

Base Image

웹 서버용 Dockerfile : FROM nginx:latest : 여기서 "nginx:latest"

데이터베이스 서버용 Dockerfile : FROM mysql:5.7 : 여기서 "mysql:5.7"

백그라운드 작업용 Dockerfile : FROM alpine:latest : 여기서 "alpine:latest

Parent Image

각 Dockerfile에서 지정된 FROM 명령어의 이미지("nginx:latest", "mysql:5.7", "alpine:latest")는 각각의 Dockerfile로 만들어지는 이미지의 "부모 이미지"

여기서 "부모 이미지"는 기본적으로 "베이스 이미지"와 같은 의미로 사용되고 있다.

Layers

웹 서버용 Dockerfile → COPY ./default.conf /etc/nginx/conf.d/default.conf

: 설정 파일을 nginx 설정 디렉토리로 복사하는 레이어

데이터베이스 서버용 Dockerfile → ENV MYSQL_ROOT_PASSWORD=my-secret-pw ,ENV MYSQL_DATABASE=mydatabase

: 환경 변수를 설정하는 레이어

백그라운드 작업용 Dockerfile →

RUN apk add --no-cache dcron : Alpine Linux에 cron 작업 관리자를 설치하는 레이어

COPY crontab.txt /etc/crontabs/root : 크론 작업을 위한 스케줄 파일을 컨테이너에 복사하는 레이어

Docker Image -> Container 순서

1. Dokcerfile 작성

2. Docker build (이미지 생성)

 % docker build -t dockertest:latest .
[+] Building 0.0s (5/5) FINISHED                                                                                   docker:desktop-linux
 => [internal] load .dockerignore                                                                                                  0.0s
 => => transferring context: 2B                                                                                                    0.0s
 => [internal] load build definition from dockerfile                                                                               0.0s
 => => transferring dockerfile: 283B                                                                                               0.0s
 => [internal] load metadata for docker.io/library/alpine:latest                                                                   0.0s
 => CACHED [1/1] FROM docker.io/library/alpine                                                                                     0.0s
 => exporting to image                                                                                                             0.0s
 => => exporting layers                                                                                                            0.0s
 => => writing image sha256:0f2a33b340f39b5580c51c388037157d5596c555aade4f9eb6c9c99e3cb47eac                                       0.0s
 => => naming to docker.io/library/dockertest:latest                                                                               0.0s

What's Next?
  View a summary of image vulnerabilities and recommendations → docker scout quickview

"docker build -t dockertest:latest ." -t는 태그로 dockertest 라는 이름으로 tag하겠다는 뜻이다. 맨마지막에 . 을 찍는걸 실수하지 말자 -> 나중에 해당 이미지를 run돌릴때 tag로 호출하면 편하기 때문

만약 아래와 같이 출력하게 하고싶다면 DOCKER_BUILDKIT=0 로 비활성화를 한다.
- BuildKit : Docker 18.09버전부터 새로운 이미지 빌드 시스템 도입

% DOCKER_BUILDKIT=0 docker build .
DEPRECATED: The legacy builder is deprecated and will be removed in a future release.
            BuildKit is currently disabled; enable it by removing the DOCKER_BUILDKIT=0
            environment-variable.

Sending build context to Docker daemon  6.144kB
Step 1/2 : FROM alpine
 ---> 1dc785547989
Step 2/2 : CMD ["echo","hello"]
 ---> Running in cb16c68a65a8
Removing intermediate container cb16c68a65a8
 ---> ce94e625b2bf
Successfully built ce94e625b2bf

What's Next?
  View a summary of image vulnerabilities and recommendations → docker scout quickview

3. Docker run (이미지로 부터 컨테이너 생성 및 실행) : 이때 컨테이너는 이미지의 상태를 실시간으로 반영

% docker run dockertest:latest
hello

만약 백그라운드로 실행하고 싶다면 -d

질문1. 왜 백그라운드로 컨테이너를 실행하려는 걸까?

멀티테스킹 : 터미널,콘솔이 해당 컨테이너에 계속 연결되어 있지 않아도 된다 -> 사용자가 다른 작업 계속 할 수 있다.
서비스 유지 : 웹서버,DB와 같이 중단없이 백그라운드에서 계속 실행이 필요한 서비스,application의 경우 지속적으로 서비스 제공 가능
환경 분리 : 사용자의 현재 터미널,콘솔세션이 독립적으로 실행되어 다중 작업 수행이 가능하다.(동일한 터미널이나 다른 터미널에서 다른 작업 가능)
로그관리 : 백그라운드 모드의 경우 Docker의 로깅시스템으로 직접 관리됨 (docker logs)

% docker run -d dockertest:latest    
5182fd2a20064c2319e222657e648e1a5f616818cbcf164498a3b3baf2ec8b0d

4. Container 확인

% docker ps -a 
CONTAINER ID   IMAGE               COMMAND                  CREATED              STATUS                          PORTS      NAMES
5182fd2a2006   dockertest:latest   "echo hello"             About a minute ago   Exited (0) About a minute ago              competent_davinci

도커 이미지 명령어

images list 확인

$ docker ls

REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
nginx               latest              0d9c6c5575f5        4 days ago          126MB
ubuntu              18.04               47b199b0cb85        2 weeks ago         64.2MB

registry에서 image pull하기

$ docker pull alpine:3.11

3.11: Pulling from library/alpine
Digest: sha256:9f11a34ef1c67e073069f13b09fb76dc8f1a16f7067eebafc68a5049bb0a072f
Status: Downloaded newer image for alpine:3.11

Docker에서 image 삭제하기

$ docker rmi <image_id>

Untagged: <image_id>
Deleted: sha256:<image_id>

Docker Host의 image VS Registry의 image

Docker Host image

로컬에 저장되며, 해당 시스템에서 직접 사용가능

Registry image

원격 이미지 저장소(Docker Hub)에 저장되며, 공유와 재사용

참고자료

https://docs.docker.com/get-started/overview/

https://www.geeksforgeeks.org/what-is-docker-images/

https://peterica.tistory.com/212

https://hoon93.tistory.com/48

https://velog.io/@bsjp400/Docker-Docker-file%EB%A1%9C-%EC%9D%B4%EB%AF%B8%EC%A7%80-%EC%83%9D%EC%84%B1%EB%B0%A9%EB%B2%95

따라하며 배우는 도커와 CI환경 강의

https://velog.io/@bsjp400/Docker-Docker-file%EB%A1%9C-%EC%9D%B4%EB%AF%B8%EC%A7%80-%EC%83%9D%EC%84%B1%EB%B0%A9%EB%B2%95

[Docker] Docker Container1 - 기본 개념

PeonyF — Thu, 21 Dec 2023 18:10:31 +0900

Containers vs. VMs

containers vs. VMs

컨테이너란?

A container is an isolated environment for your code.

컨테이너가 ~~사용자가 가지고 있는 OS나 파일에 대한 정보 없이~~ Docker Desktop에 제공하는 환경에서 실행한다.

어떻게 컨테이너가 독립적으로 가능할까?

Docker Desktop을 사용하여 컨테이너를 관리, 탐색하고 컨테이너가 기본 OS를 포함한 실행하려는 코드를 위한 모든것을 가지고 있기때문에 가능하다.

질문1. 컨테이너가 코드를 위한 모든, 어떤것을 가지고 있을까?

- 런타임 환경, 실제 실행하려는 애플리케이션의 코드, 애플리케이션의 실행에 필요한 외부 라이브러리와 의존성,시스템 도구 및 유틸리티, 설정파일 및 환경변수 ,기본 운영체제(단 전체이미지가 아님) 등과 같은 구성요소들이 함께 작동해서 컨테이너가 어떤환경에서도 일관된 방식으로 애플리케이션을 실행할 수 있게 한다.

질문 1-1. 컨테이너가 기본 운영체제를 가지고 있는데 왜 전체 이미지가 아닐까?

containers do not contain operating system images. This makes them more lightweight and portable, with significantly less overhead

컨테이너와 가상머신의 주된 차이점 중 하나. 전체이미지를 가지고 있지않아 컨테이너는 가볍고,이식성이 높다.

질문 1-1-1. 그러면 어떻게 운영체제를 가져올까?

docker hub에서 필요한 base operating system를 image로 전달해서 전체 OS 이미지가 필요없다.

질문 1-1-1-1. docker hub가 뭐지?

Docker 이미지를 저장하고 공유하는 서비스, 기본 OS 레이어와 필요한 소프트웨어,라이브러리를 포함하고 있어 컨테이너가 독립적으로 실행 가능.

ex. ubuntu image : Ubuntu OS 기반의 컨테이너를 만들고 싶다면, Docker Hub에서 Ubuntu 이미지를 가져와 사용

어떻게 컨테이너를 격리시킬까?

Linux Containers rely on control groupsopen_in_new which not only track groups of processes, but also expose metrics about CPU, memory, and block I/O usage. You can access those metrics and obtain network usage metrics as well. This is relevant for "pure" LXC containers, as well as for Docker containers.

리눅스에서 쓰이는 Cgroup(control groups)와 namespace로 격리시킨다.

namespace를 통해 프로세스들을 구별, Cgroup을 통해 이 프로세스들의 사용가능한 자원을 제한한다.

Cgroup

프로세스와 스레드를 그룹화하여, 그 그룹안에 존재하는 프로세스와 스레드에 대한 관리를 수행-> 리소스 사용량을 제한,격리가능

Cgroup는 계층 구조를 사용하여 프로세스를 그룹화 하여 관리할수있다.

Cgroup의 주요 서브 시스템

cpu	cpu 사용량을 제한
cpuact	cpu 사용량 통계 정보를 제공
cpuset	cpu나 메모리 배치를 제어
memory	메모리나 스왑 사용량을 제한
devices	디바이스에 대한 엑세스 허가/거부
freezer	그룹에 속한 프로세스 정지/재개
net_cls	네트워크 제어 태그를 부가
blkio	블록 디바이스 입출력량을 제어 블록 디바이스란? 데이터를 고정된 크기로 관리하는(각 블록은 고유한 주소가 있음) 저장장치(HDD,SSD,USB) 블록 디바이스 I/O란? 데이터를 저장/검색하는 방법으로 블록 디바이스를 통한 입력/출력 작업

Cgroup 특징

자원제한 : 중요한 시스템 프로세스의 안정성 보장
- cgroup은 부모 자식 관계에서는 자식이 부모의 제한을 물려받기 때문에 자식은 부모 그룹의 제한을 초과하여 할당할 수 없어 중요한 프로세스라도 영향을 받지 않는다. → 시스템의 중요 부분에 대한 과도한 자원 사용 방지

namespace 격리로 보안과 안정성,자원관리 가능
- 프로세스 그룹이 다른 그룹의 리소스를 볼 수 없도록 분리함
  - 질문1. 프로세스 그룹이 실제 시스템에서 어떻게 활용되는건가?
    - 위에 그림과 같이 웹 서버 그룹(Nginx와 같은 웹서버 실행시), DB서버 그룹(MySQL등 사용시), 백그라운드 작업 그룹(시스템에서 정기적 실행되는 백업 스크립트,로그작업시),사용자별,application 별 그룹 등
    - 실행되는 application의 요구사항,시스템의 전체 리소스,성능,보안 요구사항등의 여러요소들로 Cgroup의 프로세스 그룹화가 결정됨. 따라서 각 시스템과 application마다 Cgroup의 설정이 다르다.
    - ex. Java 계산기 프로그램 : 독립적으로 실행되는 간단한 애플리케이션은 Docker의 기본 설정만으로 가능
    - 스프링 프레임워크를 사용하여 구현된 웹 서버를 실행할 경우, 웹 서버 그룹이나 데이터베이스 서버 그룹 같은 cgroup 설정이 필요할 수 있음
우선 순위 설정 : 다른 Cgroup의 프로세스들이 사용하는 자원들에 비해 얼마나 자원을 사용할 수 있는지 설정
- 자원제한 변경 : 시스템에서 특정 Cgroup에 할당된 CPU나 메모리와 같은 자원제한을 동적으로 조정가능(시스템 부하가 높을떄, 특정 서비스의 리소스 사용량을 제한)
- Cgroup의 cpu 서브시스템을 사용: 특정 Cgroup에 대한 CPU시간의 비율 조절 가능(두개의 Cgroup이 있을때 한 그룹에 CPU 시간을 더 많이 할당시 CPU 가중치를 더 높게 할당-> CPU를 더 많이 사용할수있게 우선순위 간접 설정)
- Cgroup의 memory 서브시스템을 사용: 특정 Cgroup의 메모리 사용량을 제한 → 메모리를 과도하게 사용 방지
- Cgroup의 blkio 서브시스템을 사용: 특저
감시/관리 : Cgroup 단위에서 자원을 얼마나 사용하고 있는지 모니터링/ 모든 프로세스들의 상태를 한번에 변경 가능
- 일시 중지/재개 : 시스템의 유지보수,업데이트 중 특정 application을 일시 중지 시키고 작업이 끝난 후 재개시 사용

Cgroup의 자원 제한으로 인한 이점:

다중 사용자 환경 : 시스템에 여러 사용자,서비스 동시 실행시 한 사용자/서비스가 시스템의 모든 자원 독점 방지
서비스 품질 보장 : 중요 application에 충분한 자원이 할당되도록 하여 성능 보장
시스템 안정성 : 시스템의 전체 자원을 적절히 제어해, 과부하 상태로 인한 시스템 불안정성 방지

Namespace

프로세스 격리(= 프로세스 구별)로 이로인해 충돌가능성을 줄이고, 쉽게 참조할수 있게한다.

(PID를 통해 각 컨테이너에 대해 독립적인 프로세스 번호 공간을 제공)

Docker는 컨테이너라는 독립된 환경을 만들고, 그 컨테이너를 구획화하여 application의 실행환경을 만든다.
여기서 이 컨테이너를 구획화하는 기술을 linux의 namespace라는 기능을 사용한다.
각 namespace는 특정한 시스템 리소스나 속성을 격리하기때문에 프로세스는 여러 namespace에 걸쳐 다양하게 격리되고 환경을 가질 수 있다.(namespace는 프로세스가 필요에 따라 다른 격리된 환경에서 작동할 수 있게 함)

ex. IPC Namespace에서 pid:1과 pid:2가 서로 통신

UTS Namespace에서 pid:1과 pid:3가 함께 격리

Namespace의 주요 서브 시스템

mnt	파일 시스템 마운트 : Host 파일 시스템에 독립적인 파일 시스템 마운트 마운트란? 컴퓨터에 연결된 기기,기억장치를 OS에 인식시켜 이용가능한 상태로 만드는것 monut namespace는 마운트 조작을 하면 namespace안에 격리된 파일 시스템 트리를 만든다. namespace 안에서 수행된 마운트는 호스트 OS,다른 namespace에서는 엑세스 할 수 없게 되어있다. (각 application이 자신만의 파일시스템 구조를 유지 및 은닉,변경 못하도록 하기 위함)
pid	각 프로세스에 할당된 고유한 ID : 독립적인 프로세스 공간 할당
net	네트워크 디바이스, IP 주소, 포트 번호, 라우팅 테이블, 필터링 테이블 등과 같은 네트워크 리소스를 격리된 namespace마다 독립적으로 가질 수 있다 → namespace간의 충돌 방지(중복 포트 바인딩 등)
ipc	IPC는 프로세스간의 통신 오브젝트(공유메모리, 세마포어,메세지큐)로 통신(IPC) 오브젝트를 namespace별로 독립적으로 가질 수 있다
uts	자신만의 호스트이름과 네트워크 도메인 이름을 가질 수 있음
user	독립적인 사용자,그룹ID 할당

mnt(mount)

user

Namespace의 독립적으로 작동하여 얻는 이점

컨테이너가 각각 독립적인 파일 시스템을 가져(자신만의 파일 시스템 마운트 관리) 컨테이너가 별도의 서버인것처럼 작동할 수 있게 해줌
특정상황에 일부 namespace가 불필요한 경우(컨테이너가 networking을 전혀 사용하지 않아 NET namespace가 필요없는 경우, 컨테이너가 단일 프로세스로 실행되어 호스트 이름,도메인 이름에 의존하지 않아 UTS namespace가 필요없는 경우 등) Docker 실행 명령어나 Dockerfile, Docker Compose 파일에서 특정 옵션을 통해 namespace사용을 커스텀 할 수 있다. (단 격리 수준이 낮아짐)
- Docker 명령어 사용(1. NET namespace 사용X시, 2. IPC namespace 사용X시)
- Docker Compose 사용시(3. 해당 서비스가 호스트의 NET namespace를 사용하도록 지정함, 별도의 NET namespace 생성X)

docker run --net=host myimage

docker run --ipc=host myimage

version: '3'
services:
  app:
    image: myappimage
    network_mode: "host"  # 사용할 네트워크 모드 지정

질문1. 격리 수준이 낮아진다는건 무슨 의미인가?

컨테이너가 실행되는 환경과 다른 환경 사이의 경계가 옅어져 아래와 같은 문제 발생

보안위험이 증가 : 만약 , 호스트의 네트워크 네임스페이스로 통일될경우 모든 네트워크 인터페이스에 직접 엑세스 할수있음
리소스 충돌 : 여러 컨테이너나 호스트 시스템이 동일한 리소스를 동시에 사용시 충돌 발생
관리 복잡성 : 시스템의 어떤부분이 문제를 일으키는지 파악하기 어려움

컨테이너 작동과정

Step1. 두프로그램이 각각 다른 Python 버전을 원하는 상황

Chrome -> python2, NodeJs -> python3
해당 하드디스크는 Python2만 접근가능하고 동시에 두개의 동일한 Python 설치 X

Step2. OS의 Namespace 기능 사용

Namespace를 통해 커널은 Chrome과 NodeJS 각각이 필요로 하는 다른 버전의 Python에 접근 가능
1. 프로그램이 요청을 합니다 (시스템 콜 발행) : Chrome -> python2, NodeJs -> python3 필요 요청
2. 커널이 요청을 받아 처리 : 어느 프로그램으로 부터 온 요청(시스템콜) 확인
3. 커널이 리소스 접근을 적절한 곳으로 연결해줍니다 (리디렉션) : 커널은 Chrome이 요청한 Python 버전 2를 사용할 수 있는 하드 드라이브의 특정 영역(세그먼트)으로 연결

Step2. Cgroup 기능 사용

Cgroup은 특정 프로세스가 사용할 수 있는 리소스 수를 제한하는 데 사용한다.
커널은 들어오는 시스템 호출을 보고 이를 하드 드라이브의 특정 부분(RAM CPU 또는 필요한 다른 부분)으로 보낸다.

Step3. 해당 Container의 Image스냅샷 사용 및 Container 시작

namespace와 Cgroup을 통해 하드디스크의 일부분을 격리해 하드디스크의 작은 부분을 컨테이너만 사용하도록 한다.
이미지의 파일 스냅샷을 컨테이너 공간(hard drive segment)에 배치한다. -> 해당 컨테이너 실행시 필요한 파일,설정 포함
구체적인 리소스 그룹 구성 : 세그멘트에 Chrome과 Python만 설치됨 -> 컨테이너가 사용할 독립된 환경 형성
컨테이너 시작 명령 실행 -> Chrome 사용

컨테이너 특징

컨테이너는 이미지 Layer에 읽기/쓰기 Layer를 추가하는 것으로 생성/실행된다. 따라서 여러개의 컨테이너를 생성해도 최소한의 용량만 사용되며 바뀐부분은 읽기/쓰기 Layer에 적는다.
컨테이너는 종료되었다고 메모리에서 삭제되지 않고 남아있다. (삭제하려면 명시적으로 삭제해야 한다.) 즉 종료가 되어도 컨테이너, 읽기/쓰기 Layer 또한 그래도 존재하기 때문에 다시 시작할 수 있다.
컨테이너 삭제란 컨테이너에서 생성한 파일이 사라진다는 것이다. ex. DB 삭제 → DB내의 모든 데이터 삭제
한 서버는 여러개의 컨테이너를 가질 수 있으며 컨테이너는 각각 독립적으로 실행된다.
컨테이너는 kernel공간과 host os자원을 공유한다.

1. host system 의 host 이름이 host-system

2. 두 개의 컨테이너(Container A와 Container B)를 실행

Container A에서 hostname 명령어를 실행하면 "container-A"라는 결과를 얻는다.

Container B에서 hostname 명령어를 실행하면 "container-B"라는 결과를 얻는다.

→ 각 컨테이너가 UTS 네임스페이스를 통해 자신만의 호스트 이름을 가짐을 의미

(컨테이너가 host-system의 커널을 공유해도 UTS namespace는 컨테이너마다 독립적으로 관리함)

docker run -d --name container-A --hostname=container-A ubuntu sleep 3600

-d : 컨테이너를 백그라운드에서 실행

--hostname: 컨테이너의 호스트 이름을 설정

ubuntu : 사용할 베이스 이미지

sleep 3600: 컨에이너가 바로 종료하지 않고 1시간 대기

% docker run -d --name container-A --hostname=container-A ubuntu sleep 3600
5e4b162f3357bfe120ac07a4aff4faacb69de9449b062fcef22051088d90fc34
% docker run -d --name container-B --hostname=container-B ubuntu sleep 3600
21ebf4feb110f799c2457926c6897ad1049cc58b133db86be6d7ef2c8580e871

% docker ps
CONTAINER ID   IMAGE     COMMAND                   CREATED          STATUS          PORTS      NAMES
21ebf4feb110   ubuntu    "sleep 3600"              2 seconds ago    Up 1 second                container-B
5e4b162f3357   ubuntu    "sleep 3600"              20 seconds ago   Up 19 seconds              container-A

Docker Containter lifecycle

컨테이너 생성

docker create --name my-hello-container hello-world

(녹색 박스) : 파일 스냅샷을 하드디스크에 넣어줌.

% docker create --name test-hello-container hello-world
e521b1dd85b5ca60119ac0479c38a473c7ecbc95a54a5f2709b6b74470f46bf1

컨테이너 실행 run(새로운 컨테이너를 이미지로부터 실행: create+start)

docker run my-hello-container

(파란색 박스) : 이미지에서 받아온 시작 명령어 실행.

컨테이너 실행 start (이미 생성된 컨테이너를 시작하려면)

docker start my-hello-container

% docker start -a test-hello-container

Hello from Docker!
This message shows that your installation appears to be working correctly.

To generate this message, Docker took the following steps:
 1. The Docker client contacted the Docker daemon.
 2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
    (arm64v8)
 3. The Docker daemon created a new container from that image which runs the
    executable that produces the output you are currently reading.
 4. The Docker daemon streamed that output to the Docker client, which sent it
    to your terminal.

To try something more ambitious, you can run an Ubuntu container with:
 $ docker run -it ubuntu bash

Share images, automate workflows, and more with a free Docker ID:
 https://hub.docker.com/

For more examples and ideas, visit:
 https://docs.docker.com/get-started/

컨테이너 일시중지 (더 긴 실행 시간이 필요한 ubuntu 이미지로 변경)

$ docker run -d --name ubuntu-container ubuntu sleep 3600
$ docker pause ubuntu-container

0b2a913ec95bdee0b285f603e53dc7800feaf75a877fbc849216a737b3623e70

컨테이너 중지 stop

docker stop ubuntu-container 그동안 하던 작업들을 완료하고 컨테이너를 중지 시킨다.

$ docker stop ubuntu-container
ubuntu-container

컨테이너 중지 kill

docker kill ubuntu-container 어떠한 것도 기다리지 않고 바로 컨테이너를 중지

$ docker kill ubuntu-container
ubuntu-container

컨테이너 재개 :

docker unpause ubuntu-container

컨테이너 삭제(실행중인 컨테이너는 반드시 중지해야 삭제가 가능하다):

docker rm ubuntu-container

$ docker rm ubuntu-container
ubuntu-container

모든 컨테이너 삭제 :

docker rm 'docker ps -a -q'

전체 컨테이너 확인 :

docker ps -a

도커 실행 중 명령어 전달하기

도커 실행중에 명령어를 사용하기 위해서는 컨테이너 안에서 실행을 해야 하기에 컨테이너 아이디를 적어줘야 한다.
(docker ps로 확인)
ex) 터미널 A에서 docker run redis 실행후 터미널 B에서 redis-cli 명령어를 쓰는경우 정상적으로 작동하지 않음.
=> 터미널 A는 redis 컨테이너를 실행되고 있는 중에 터미널 B의 명령어는 redis 컨테이너 밖이기 때문에 명령어가 작동하지 않으므로 다음과 같아야 한다.

# docker exec <컨테이너 아이디> <명령어>
docker exec cbba6354bdad ls

실행중인 컨테이너의 터미널로 접근하기

# docker exec -it <컨테이너 아이디> <sh/bash/zsh 등등..>
docker exec -it a096f4bf67f6 redis-cli

docker ps 명령어를 통해 container id를 확인 후 <컨테이너 아이디>에 적어준다.
-it 을 붙여줘야 명령어를 실행한 후 계속 명령어를 적을 수 있다.
실행중인 컨테이너에 여러번 명령어를 실행해야 할 경우 5번에 설명한것과 같이 "docker exec -it <컨테이너 아이디> <명령어>" 방식으로 계속 입력하기에는 비효율적임
실행중인 컨테이니의 터미널로 접근도 가능하다. -> 마지막의 명령어를 redis-cli와 같은것 대신 sh로 바꿔준다.

 % docker ps                      
CONTAINER ID   IMAGE     COMMAND                   CREATED         STATUS         PORTS      NAMES
ea45b6de24b8   alpine    "ping localhost"          4 seconds ago   Up 3 seconds              flamboyant_knuth
 % docker exec -it ea45b6de24b8 ls
bin    dev    etc    home   lib    media  mnt    opt    proc   root   run    sbin   srv    sys    tmp    usr    var
% docker exec -it ea45b6de24b8 echo "hello"
hello

'''
위와 같이 매번 "docker exec -it ea45b6de24b8" 를 입력하는게 번거로우므로 
맨 마지막에 sh를 붙여 쉘환경으로 진입하여 반복 코드 없앰
터미널 종료 방법은  control + D
'''

 % docker exec -it ea45b6de24b8 sh          
/ # ls
bin    dev    etc    home   lib    media  mnt    opt    proc   root   run    sbin   srv    sys    tmp    usr    var
/ # echo hello
hello
/ #

Docker Container VS Docker Image

Docker Container	Docker Image
Docker Image를 기반으로 실행되는 각각 컨테이너가 그 이미지의 “실행버전” (인스턴스화) (이미지의 상태를 복제하여 실행함)	Docker Image는 Docker Container의 소스 코드
Docker Image는 Docker Container의 전제조건 (Dockerfile로부터 이미지를 빌드한 이미지를 기반으로 컨테이너를 실행)	Dockerfile은 Docker Image의 필수 구성요소 (Dockerfile로부터 이미지를 빌드)
Docker Container는 유저들끼리 공유할수 없다. (컨테이너는 실행 중인 이미지 인스턴스여서 동적이고 일시적이라 공유X)	Docker Image는 Docker Hub를 통해 사용자간에 공유 가능
Docker Container는 컨테이너가 실행중일때 사용자가 컨테이너 내부에 들어가 바로 수정 가능하다. (docker exec 명령어 사용)	Docker Image를 수정하기 위해서는 Dockerfile를 수정해야한다.