[TIL] 2022.07.12 (Docker, 도커(2))

오늘은 어제에 이어서 Docker에 대해 공부하는 시간을 가져보았다.

 

여태까지 도커에 대해 명령어를 쳐보면서 container, image, network, volume 등을 만들어보고 공부를 하는 시간을 가졌다.

이제 사용을 하고 난 뒤에 남아있는 Docker 리소스들을 삭제하는 과정을 밟아보도록 하자.

 

이렇게 사용을 하고 더 이상 사용하지 않거나, 연습을 한 뒤 남아있는 Docker 리소스들을 정리해보고자 하는데, 정리를 해야 되는 이유로는 다음과 같다.

 

사용하지 않는 Docker 리소스들을 정리하는 이유
- 사용하지 않는 Docker 리소스들을 남겨두게 된다면 Disk 용량을 많이 사용하게 된다.
- 이를 방지하기 위해 사용하지 않는 리소스들을 주기적으로 정리하는 것이 좋다.

 

우선 리소스들을 삭제하기 전에 어떤 Docker 리소스들이 사용되고 있는지 확인을 해줄 필요가 있다.

 

여태 공부해보고 만들어본 것으로는 container, image, network, volume 등이 있는데 해당 리소스들에 대해 확인을 하는 명령어를 알아보자.

 

container 확인
> docker ps
> docker ps -a
→ -a 옵션을 붙이는 이유 : 삭제되지 않고 사용이 중지된 container가 있을 수 있다.

image 확인
> docker images

network 확인
> docker network ls

volume 확인
> docker volume ls

Docker 리소스 확인

 

현재는 삭제해둔 상태이므로 비어있는 모습을 볼 수 있다.

 

이렇게 명령어들을 사용하여 현재 생성되어 있는 Docker 리소스들을 확인해보았다.

이제 생성된 리소스들 중에서 사용하지 않는 리소스들을 삭제하기 위한 명령어를 알아보도록 하자.

 

container 삭제
> docker rm [container_id]

image 삭제
> docker rmi [image_id]
> docker rmi [image_repository]:[tag]

network 삭제
> docker network rm [network_id]
> docker network rm [network_name]

volume 삭제
> docker volume rm [volume_name]

모든 리소스 삭제 (prune)
> docker system prune
> docker system prune -a

Docker 리소스 전체 삭제

 

Docker 리소스를 삭제하는 방법에는 id 및 name을 지정하여 하나씩 삭제하는 방법도 있으며, 모든 리소스를 삭제하기 위한 명령어도 있었다.

 

모든 리소스 삭제 시 docker system prune -a을 사용하는 경우도 있는데, 이는 image 같은 경우에 다시 사용될 가능성이 있기 때문에 container에서 사용되고 있는 image는 제외하고 정리해달라는 뜻이다.

 

다음은 Docker에서 image를 관리할 때 사용되는 팁에 대해서 알아보자.

 

Docker image 관리 팁
1. Docker Layer Caching 활용하기
2. .dockerignore 활용하기
3. Docker image 크기 줄이기
4. Docker image 축소하기

 

우선 첫 번째로 Docker Layer Caching 활용하기에 대해 알아보도록 하자.

 

다음은 이전에 사용했던 예제인 Dockerfile 파일 내에 설정해준 명령어들에 대한 'Good Exampler'과 'Bad Example'에 대한 내용이다.

 

<Good Example>

<Dockerfile : Good Example>

FROM python:3.9

ADD requirements.txt .

RUN pip install -r requirements.txt

ADD templates ./templates/

ADD app.py .

CMD ["python", "app.py"]

 

<Bad Example>

<Dockerfile : Bad Example>

FROM python:3.9

ADD app.py .

ADD templates ./templates/

ADD requirements.txt .

RUN pip install -r requirements.txt

CMD ["python", "app.py"]

 

두 예제의 차이점을 본다면 Bad Example에서 명령어들의 이름에 맞게 배열이 되어있는 것을 볼 수 있다.

Bad Example의 배열처럼 사용된다면 보기에는 편해 보일지는 모르겠지만 자주 수정되는 부분이 Dockerfile의 상단에 위치하게 된다면 Docker Layer Caching을 활용하지 못하게 된다고 한다.

 

Dockerfile에 적힌 내용은 항상 FROM 명령어로 시작하며, 상단에 적힌 순서에 따라 실행이 된다.

 

두 번째로 .dockerignore를 활용하는 것에 대해 알아보도록 하자.

 

docker image를 빌드할 때 'ADD . .'과 같은 command를 사용할 경우 의도하지 않는 image가 빌드되는 경우가 발생할 수 있다.

이러한 사항을 방지하기 위해 .dockerignore 파일을 생성해준 뒤 빌드를 할 때 제외할 목록 이름을 적어주게 된다면 빌드를 할 때 속도를 향상할 수 있다.

 

앞서 Git-Github에서 사용했었던 .gitignore에 대해 생각해보면 쉽게 이해가 가능하다.

 

.dockerignore 내에 가상환경(venv) 제외하도록 설정

 

세 번째로 Docker image 크기를 줄이는 방법에 대해 알아보자.

 

Docker image 크기를 줄이는 이유는 docker pull 사용 시 속도가 줄어들고, docker container 실행 속도가 향상되기 때문에 image 크기를 줄이는 것이 좋다.

 

이전에는 base image를 빌드해서 가져올 때 python:3.9로 사용했었는데, 이를 예시로 다음과 같은 태그를 사용하여 설정을 해줄 수 있다.

 

태그 종류
1. alpine
- alpine-linux 기반으로 만들어진 image
- 보안에 집중되어 있으며, 보통의 모든 이미지들 중에서 가장 작은 크기를 가진다.
- 예시(python) 기준으로 pip install을 할 때 불리한 점이 존재한다.

2. buster, jessie, stretch
- debian에서 제작한 linux 기반으로 만들어진 image
- buster, jessie, stretch는 os의 codename이다.
- python:3.9와 python:3.9-buster는 동일한 특성을 지닌다.

3. slim
- 실행에 필요한 환경으로만 만들어진 image
- 기본 이미지에 비해 작은 크기를 가지게 된다.
- 보통 python 실행 환경에서 가장 많이 쓰이는 이미지 태그이다.

 

Debian Codename : https://wiki.debian.org/DebianReleases#Codenames

DebianReleases - Debian Wiki

 

<기존>
FROM python:3.9

<태그 사용 예시>
FROM python:3.9-alpine
FROM python:3.9-buster
FROM python:3.9-slim

 

마지막 네 번째로는 Docker image 축소하는 것에 대해 알아보도록 하자.

 

Docker image 축소를 할 때는 multistage build를 활용하여 image 축소를 진행한다고 한다.

해당 방식은 Dockerfile 한 개에 여러 개의 FROM을 사용하는 방식으로, 각 command를 실행하는 과정에서 생성된 것 중 필요한 것만 가져와서 새 이미지를 생성할 수 있게 하는 방식이다.

 

Docker에 대해 공부를 진행하면서 마지막으로 배포에 관련된 부분을 공부해보았다.

우선 Docker 서비스를 제공하는 과정 중 CI/CD라는 자동화 방법에 대해 공부하고자 한다.

 

CI (지속적 통합 : Continuous Integration)
- 여러 개발자들이 함께 개발을 하는 과정에서 코드가 잘 작동하는지 확인하는 것
- 애플리케이션에 대한 새로운 코드 변경 사항이 정기적으로 빌드 및 테스트되어 공유 레포지토리에 통합된다.
- 왜 필요한가?
　: 여러 명의 개발자가 함께 개발하기 위해서
　: 지속적인 통합이 되지 않고 특정한 날에 코드를 병합하고자 할 때, 서로의 작업 영역이 충돌 날 가능성이 있기 때문에
　: 문제가 생긴 경우 수정하는 것이 더욱 복잡해지는 경우가 발생할 수 있기 때문에
- 어떻게 해야 하는가?
　: 테스트 코드 작성하기
　: 자동화된 테스트 실행하기
- 도커와 무슨 연관이 있는가?
　: 도커를 사용하는 이유는 배포를 편리하게 하기 위해서이다.
　: 배포를 하기 전에 배포를 해도 괜찮은 상태인지 확인하기 위해서이다.

CD (지속적 배포 : Continuous Deployment)
- 반영된 소스코드가 실제 서비스에서도 자동으로 반영이 될 수 있도록 하는 것
- Docker를 사용하면 CD 과정이 쉽고 더 빠르게 진행될 수 있다.

 

이러한 CI/CD 도구들 중에서 조금은 익숙한 Github의 Github Action에 대해 알아보도록 하자.

Github Action을 사용하는 이유는 다음과 같다.

 

Github Action을 사용하는 이유
1. Github과의 연동이 쉽다.
2. 무료로 제공하는 기능들이 많다.
3. 사용하기 편리하다.

 

Github Action을 사용할 때 사용되는 기본 문법들에 대해 알아보도록 하자.

 

Github Action 기본 문법
1. Workflows
- 자동화하고자 하는 과정들
- 한 개 또는 여러 개의 job으로 구성되며, event에 의해 시작된다.
- 빌드, 테스트, 릴리즈, 배포 등의 작업을 포함한다.

2. Events
- workflow를 trigger 되는 행동들
- push, pull request, cronjob 등

3. Jobs
- 동일한 runner에서 실행하려고 하는 여러 개의 step 모임

4. Steps
- job을 구성하는 한 개의 command
- action이거나 shell command로 구성된다.

5. Actions
- 다른 곳에서 정의된 command의 모음

6. Runner
- job이 실행되는 환경

 

Github Action 공식 가이드 : https://docs.github.com/en/actions/learn-github-actions

Learn GitHub Actions - GitHub Docs

 

-

 

어제에 이어서 오늘까지 Docker에 대해 짧게나마 알아보는 시간을 가졌다.

 

처음에는 오류도 다소 많이 일어나고 해결하지 못하여서 더디게 공부되는 과정이 있었으나, 추후에 팀장님의 도움으로 인해 진도를 나갈 수 있어서 다행이라고 생각됐다.

 

이제 Docker에 대한 공부를 마쳤으니 다시 프로젝트를 진행하는 시간을 가져보고자 한다.

프로젝트에 대해서는 내일부터 코드를 직접 적어보면서 DB 모델링을 진행하는 것을 일정으로 정하였다.

 

내일부터는 진짜로 마지막 프로젝트를 시작하면서 코드를 구현하는데 힘을 쓸 것 같다.

 

:D