당신은 홈랩에서 도커를 잘못 사용하고 있습니다—대신 이렇게 하세요

당신은 아마도 Docker를 잘못 사용하고 있을 것입니다. 네, 수년간 사용해 왔더라도 이 목록에 있는 무엇인가를 하지 말아야 하는데 하고 있을 가능성이 있습니다. 그래서, 여기 당신이 아마도 Docker를 잘못 사용하고 있는 네 가지 방법과 대신 해야 할 일을 알려드립니다.

Docker Run 명령어로 컨테이너를 실행하는 것을 중지하세요

Docker Compose가 훨씬 더 낫다

오랫동안 나는 컨테이너를 실행하기 위해 Docker Run 명령어를 사용해 왔다. 나는 실제로 Docker Run을 사용하지는 않았다, 왜냐하면 나는 컨테이너 관리를 위해 Portainer를 사용하지만, Docker Compose를 사용하지 않았고, 그것이 문제였다.

Docker Run을 사용할 때는 실행 중인 컨테이너에 변경을 해야 할 경우 마지막으로 어떤 명령어를 사용했는지 기억해야 합니다. 반면에 Docker Compose를 사용하면 필요한 새로운 설정으로 Docker Compose YAML 파일을 편집한 다음 컨테이너를 다시 실행할 수 있습니다.

내 홈랩에서 Docker Run에서 Docker Compose로 전환하니 Docker 작업 흐름이 크게 개선되었습니다. 이제 나는 Compose 파일에 들어가 간단한 변경을 한 후 몇 초 만에 컨테이너를 다시 실행할 수 있습니다. 과거에는 변경을 하는 데 몇 분이 걸리기도 했습니다.

만약 당신이 여전히 Docker Run(또는 Compose 파일 이외의 다른 방법으로 컨테이너를 실행하는 방법)을 사용하고 있다면, 이제 Compose로 전환할 때입니다—나중에 자신에게 감사하게 될 것입니다.

정말 필요할 때만 Docker 볼륨을 사용하세요

바인드 마운트는 구성 파일에 쉽게 읽기/쓰기 접근을 제공합니다

저는 과거에 사람들이 Docker Volumes를 강력히 추천하는 것을 본 적이 있고, 저도 Docker Volumes를 사용하는 것을 고려해본 적이 있지만, 저는 그냥 그걸 할 수가 없습니다.

명명된 Docker 볼륨은 Docker가 자체적으로 모든 권한을 제어하는 영역에 특별한 폴더를 만드는 경우입니다. Docker가 관리하기에는 더 깔끔하고 쉬울 수 있지만, 사용자가 관리하기에는 항상 직관적이지 않을 수 있습니다.

Docker 볼륨의 문제는 Docker가 어디에 놓기로 결정하느냐에 따라 위치가 달라진다는 것입니다. 일반적으로 이는 /var/lib/docker/volumes/volume_name/_data에 있지만, 실행 중인 시스템에 따라 다를 수 있습니다.

명명된 Docker 볼륨을 사용하는 대신, 나는 바인드 마운트를 사용하기로 선택했다. 바인드 마운트는 Docker에게 파일과 폴더를 사용자가 선택한 특정 위치에 두라고 지시하는 것이다. 나는 내 모든 Docker 컨테이너를 관리하기 위해 Portainer(도커 관리 플랫폼)를 사용한다.

그래서 나는 모든 바인드 마운트를 /portainer 아래에 두었습니다. 이렇게 하면 내 Docker 파일이 정확히 어디에 저장되어 있는지 쉽게 알 수 있고, 백업하기도 쉽습니다. 나는 그 폴더의 권한을 관리할 수 있으며, 어디에 위치할지 내가 결정하기 때문에 어떤 시스템에서든 쉽게 찾을 수 있습니다.

Docker 볼륨과 비교했을 때 Docker 관리를 더 간단하게 만들 수 있으므로 가능한 한 바인드 마운트를 사용하는 것을 확실히 추천합니다.

비밀과 변수를 .env 파일에 넣으세요

Docker Compose 파일이나 Docker Run 명령어에 그것들을 넣는 것을 그만두세요

저는 우리 모두가 그런 경험이 있다고 생각합니다—Docker Compose 파일이나 Docker Run 명령을 만들면서 비밀 API 키, 비밀번호 또는 다른 보안 변수를 모두가 볼 수 있도록 평문으로 넣는 경우가 있죠. 편리하지만, 안전하지 않습니다.

비밀을 Compose 파일 안에 직접 넣는 대신, 더 안전한 .env 파일 안에 넣을 수 있습니다. 이것은 환경 변수를 보호하는 전통적인 방법이며, 매우 쉽게 할 수 있습니다.

예를 들어, .env 파일에서 변수 이름을 OPENAI_API_KEY=mysupersecretopenaikey로 지정할 수 있습니다. 그런 다음 Compose 파일에서 $ {OPENAI_API_KEY}로 해당 변수를 호출하면 .env 파일에서 가져오도록 인식합니다.

이러한 워크플로우에 익숙해지는 데는 약간의 시간이 걸리며, Portainer와 같은 것을 사용하는 경우에는 조금 더 복잡하지만, Compose 파일에 비밀을 직접 입력하는 것보다 확실히 안전합니다.

여러 관련 서비스에 대해 개별 Compose 파일 사용을 중단하세요

관련 서비스를 하나의 Compose 파일 안에 배포하는 것이 더 간단합니다

Compose 파일을 사용하는 것은 훌륭한 첫 번째 단계이지만, 그것들을 완전히 익히기 시작할 때 비로소 Docker의 진정한 힘을 완전히 실감하게 됩니다.

예를 들어 WordPress, MariaDB, Nginx Proxy Manager와 같은 여러 관련 서비스를 사용하고 싶다고 합시다. 세 가지 서비스를 모두 각각 다른 Compose 파일로 실행하는 대신, 하나의 파일 안에서 모두 실행할 수 있습니다.

관련된 서비스를 결합하는 것은 많은 이점을 제공합니다. 첫째, 시스템을 더 깔끔하고 정돈되게 유지할 수 있습니다. 둘째, 스택의 한 부분을 수정해야 할 때 여러 부분을 수정해야 하는 경우가 많으므로 한 개 이상의 파일을 열 필요가 없게 해줍니다.

또한, 동일한 Compose 파일에서 생성된 컨테이너들은 자동으로 내부 네트워크를 공유하여 컨테이너끼리 쉽게 통신할 수 있습니다. 따라서 WordPress를 MariaDB 인스턴스의 IP 주소로 지정하려고 시도하는 대신, 컨테이너 이름을 변수로 사용하여 호출하면 자동으로 작동합니다.

도커는 매우 강력하지만 잘못 사용하기도 쉽다

저는 5년 넘게 Docker를 광범위하게 사용해왔지만, 최근에서야 Docker가 제공하는 많은 숨겨진 기능들을 정말로 발견하기 시작했습니다. 문제는, 이 기능들이 비밀로 숨겨져 있는 것이 아니라, 때때로 그 혜택이 명확하게 드러나지 않을 뿐입니다.

예를 들어, Docker Compose는 제가 몇 년 동안 알고 있었던 것이지만, 제가 하고 있던 예전 방식보다 얼마나 더 나은지 전혀 깨닫지 못했습니다. 이제 와서야 훨씬 일찍 Compose로 전환했으면 좋았을 것이라는 생각이 듭니다. 지금 사용하고 있다는 사실만으로도 기쁩니다.

그러니까, 만약 당신이 아직 이 목록에 있는 일들을 하고 있지 않거나(혹은 여전히 잘못된 일을 하고 있다면), 이번 여름을 계기로 당신이 하고 있는 일을 바꾸고 업계의 기준에 더 맞추도록 하세요.