현재까지는 Docker Hub에서 제공하는 이미지를 pull하여 사용하였는데 누군가를 통해 완성된 이미지를 가져오는 것은 간편하고 유용한 기능들이 포함되어 있지만 직접 배포 및 운영을 해야하는 개발자의 경우 불필요한 프로세스는 제거해야 하고, 배포 용량에 대한 고민도 충분히 필요하다. 지속적인 개발로 인해 컨테이너는 용량이 늘어나게 되고 어디서 문제가 발생했는지 확인하기가 힘들어지는데, 직접 이미지 설정이 어떻게 되어있는지 알고 개선 할 점을 찾기 위해서는 Dockerfile을 직접 작성해보는 게 도움이 될거라고 생각하고 이후 다루게 될 이미지 경량화의 이해를 위해서 정리를 하게 되었다. Dockerfile? Dockerfile은 Docker Image를 생성하기 위한 설정 파일이다. Dockerfile..

도커를 활용하여 컨테이너를 이미지화하여 손쉽게 컨테이너를 배포하여 실 서버에 적용 할 수 있게 되었다 그런데 실 서버 적용 시 해당 컨테이너에서 사용 중인 이미지, 엑셀파일 등의 첨부파일들은 컨테이너가 교체 됨에 따라 기존에 사용자들이 올려놓은 정보가 사라지게 된다. DB와 같이 파일 시스템도 별도로 공간을 만들어서 보관해야 할 필요성이 느껴졌다. 해당 구조를 운영 서버에 적용했다가, 컨테이너를 교체했다고 생각해보자. 담당자는 바로 개발자를 호출 할 것이다. " 제가 홈페이지에 올려놓은 아주 중요한 파일이 사라졌는데요? " 이후의 일은 상상에 맡기겠다. 그런 일은 존재해선 안되므로 여러가지 방안을 찾아보았다. Docker에서는 이러한 상황에 이미 대처 할 수 있는 시스템을 확보해두었는데. 아래는 Dock..

앞서 개발 PC에서 운영 서버로 이미지를 옮겨 설치하는 데까지 성공하였다면 이제 해당 컨테이너가 실제로 운영되고 있다는 것을 가정했을 때 어떻게 패치가 진행될지에 대해 고민을 해보았다. 위 구성도로는 컨테이너를 교체하는 과정 서비스 가용성을 해칠 가능성이 굉장히 높다. 무중단 배포를 하기 위해서는 별도로 동일한 apache 웹 서버 컨테이너를 생성해야 할 것으로 보여 아래와 같이 구성도를 변경하였다. 1. 모든 웹 요청은 Container 1의 Nginx로 들어오게 된다. 2. Nginx는 현재 Active인 Container로 해당 요청을 전달한다. 3. 현재 Active인 Container 2는 Conatiner 4와 통신하며 요청에 대한 결과를 반환한다. 위 동작방식을 토대로 무중단 배포 시나리오는..

현재 패치 및 가용성 문제를 해결하기 위해 docker를 설치해야 하는 서버는 dmz망과 같이 특정 대역에서의 접속만 허용이 되어있는 상태 yum install 불가 직접 rpm 파일을 받아서 패치하기로 결정 먼저 아래 링크를 통해 3가지 파일을 다운 받는다. https://download.docker.com/linux/centos/7/x86_64/stable/Packages/ Index of linux/centos/7/x86_64/stable/Packages/ download.docker.com ce, ce-cli, container.io 를 다운로드 받으면 된다. 그리고 아래와 같이 입력한다. yum install -y ce.rpm 내 서버의 경우 의존성 문제가 발생한다. container.io >>..