Overview 2022년, 모던 프론트엔드 개발 생태계를 주도하고 있는 React와 Next는 각각 새로운 Major 버전(React 18, Next13)을 Release 했습니다. React18에서는 Server Component와 Streaming HTML이라는 개념이 등장했고, 이를 FrameWork Level에서 지원하기 위해 Next13에서는 (아직은 Beta 버전인) App Directory라는 개념을 선보였습니다. 이 기능이 출시되자마자 이를 바로 작은 프로젝트에 적용해 보시면서 Pros / Cons를 이야기해 주시는 사내 시니어 프론트엔드 개발자분의 이야기를 듣다가. "어 그러면 기존의 React Application Component 일부분이 Server Component로 대체되면 기..

Networking background (for beginners) 애플리케이션을 도커 컨테이너에 배포했다면, 외부에서 애플리케이션을 사용할 수 있도록 해당 컨테이너로의 접근을 허용해주어야 합니다. 이 전반적인 과정들을 이해하기 위해서는 도커가 컨테이너의 네트워크를 어떻게 관리하는지를 알아야 하며, 이를 위해 기본적으로 "네트워크"에 대한 기본적인 지식들을 짚고 넘어가도록 하겠습니다. Basics: Protocols, interfaces, and ports 프로토콜(Protocol)은 컴퓨터나 네트워크 장비가 서로 통신하기 위해 미리 정해놓은 "규약"을 의미합니다. 쉽게 이야기해서 비트 스트림을 어디서 어떻게 끊어서 어떤 의미를 부여해서 해석할 것인지를 정해놓은 것으로써, Sender와 Receiver가..

Shared mount points and sharing files 여러 개의 컨테이너에서 동일한 File Set(set of files)을 공유할 수 있도록 하는 기능은 매우 유용합니다. 파일 공유는 이전 포스팅에서 설명한 "Bind Mounts"와 "Docker Volume"의 2가지 방법을 통해 사용할 수 있습니다. Bind Mounts 다음 명령어를 순차적으로 실행해보겠습니다. // Host Machine에 디렉터리를 생성합니다. LOG_SRC=~/web-logs-example mkdir ${LOG_SRC} // plath 라는 이름의 컨테이너를 실행합니다. // Host Machine의 path와 컨테이너의 path를 바인딩합니다. // 로그를 기록합니다. docker run --name pla..

Overview 도커 컨테이너를 통해 애플리케이션을 운영하다 보면, "데이터"를 적절하게 관리할 방법 이 필요합니다. 이를테면 데이터베이스 인스턴스를 컨테이너 안에서 동작시키는 상황에서 인스턴스나 호스트 머신에 문제가 생겨서 데이터베이스 컨테이너를 내려야 하거나, 업데이트를 위해 컨테이너를 재시작해야 한다면, 그러한 경우에도 불구하고 기존에 저장되어 있던 데이터는 유지되어야 합니다. 또한 여러 개의 웹 애플리케이션을 운영하는 경우, 모니터링이나 성능 최적화 등을 위해 다양한 로그들을 남겨야 할 텐데 마찬가지로 이 로그들은 컨테이너가 내려갈 때 같이 사라져서는 안 되기 때문에 별도의 관리 방법이 필요할 것입니다. 이번 포스팅에서는 도커가 파일 시스템을 다루는 방법들을 살펴봄으로써, 실제로 데이터를 어떻게 ..

Identifying Software 특정한 프로그램을 설치하기 위해서는 프로그램을 유일하게 식별할 수 있는 식별자가 필요합니다. 이 식별자는 프로그램의 이름, 사용하려고 하는 프로그램의 버전, 그리고 프로그램을 가져올 위치(Source)를 포함해야 합니다. (You would need a way to name the progam, specify the version that you want to use, and specify the source that you want to install it from.) 이전 포스팅에서 살펴보았듯, 도커는 이미지로부터 컨테이너를 생성합니다. 이 이미지는 컨테이너에서 사용 가능한 "파일"과 이미지의 정보를 가리키는 "메타데이터"로 구성됩니다. 이 메타데이터는 레이블, ..

Eliminating metaconflicts: Building a website farm 이전 포스팅에서 도커가 Process Namespace를 통해 프로세스를 격리시켜 컨테이너 안에서 동작하는 소프트웨어 간의 의도치 않은 충돌(conflicts)을 방지한다는 것을 살펴보았습니다. 하지만 컨테이너 간의 프로세스가 잘 격리되더라도 컨테이너의 이름과 같은 "metadata"끼리 충돌이 발생할 가능성이 여전히 존재하며, 이를 "metaconflicts" 라고 합니다. 예를 들어, 이전 포스팅에서 살펴보았던 Web, Mailer, Watcher(Agent) 구조에서 Web과 Watch를 Scale up 하는 경우, 각각의 컨테이너는 동일한 이름을 가질 수 없습니다. 컨테이너를 관리하기 위해서는 특정 컨테이너..