이 글 감사합니다! 제가 이해한 정도로는 이 기술이 제게 매우 흥미로울 수 있다는 걸 알겠는데, 실제로 이 기술이 무엇을 하는지, 그리고 어떻게 활용할 수 있는지를 제대로 이해하려면 아직 몇 가지 지식 블록이 부족한 것 같아요.
개발자가 아닌 관점에서 조금 더 배경 설명을 해주실 수 있을까요? (저는 조립과 실험을 좋아하는 사람이에요. 이 분야의 제 실력을 어떻게 표현해야 할지 늘 확신이 없긴 하지만… 코딩으로는 능숙하지 않지만, 기본 원리를 충분히 ‘이해’해서 예전에 몇 가지 기본적인 WordPress 플러그인을 어렵게나마 작성해 본 적이 있고, 명령줄 사용법도 좀 알며, 간단한 코딩과 서버 관리도 이해합니다… 지금 AI를 보고 있으니, 드디어 제 프로젝트 중 일부에 실제로 접근할 수 있게 될지도 모른다는 꿈을 꾸게 됩니다!)
이것은 정말 좋은 것 같습니다, Sam. 아직 설치하지 않았습니다. Ubuntu 서버에서 Docker를 사용하여 여러 Discourse 인스턴스를 실행하는 데 상당한 어려움을 겪었습니다. 저는 리버스 프록시로 Caddy를 사용하고 있습니다.
제 주요 목표는 라이브 Discourse 인스턴스를 DEV 환경에 미러링하여 커스텀 항목을 작업한 후 라이브에 배포하는 것입니다. 가능하면 별도의 도메인 이름을 사용하는 것이 좋습니다.
이것은 먼저 설치한 후 새로운 Discourse 인스턴스를 설치하고 설정해야 하는지, 아니면 기존 설치 환경에서 작동하도록 설치한 후 더 많은 인스턴스를 추가할 수 있는지 궁금합니다. 이 구성을 사용할 때 DNS 관리를 위해 Caddy가 최적인지, 아니면 다른 도구가 더 나은 선택인지 확실하지 않습니다.
dv는 끝에서 끝까지(end-to-end) 도구를 지향합니다. 예를 들어, 저는 인스턴스를 XYZ.home.arpa에 유지하면서 프록시와 모든 것을 관리합니다.
dv를 사용하여 여러 컨테이너를 구성하고, dv catchup을 사용하여 최신 버전으로 업데이트할 수 있습니다. 이 명령은 플러그인과 코어 업데이트를 처리해 줍니다.
결국 모든 것은 docker 컨테이너일 뿐이며, 데이터 가져오기, 사용자 정의 명령 실행 등을 포함하여 필요한 어떤 형태로든 다듬을 수 있습니다.
이것은 매우 주도적으로 “개발자/디자이너 우선” 환경입니다. dv build → dv new something → dv ra codex 순서로 진행하며 주변을 살펴볼 수는 있지만, 이것은 엔지니어링을 대중에게 보급하려는 시도가 아닙니다. 이는 엔지니어/디자이너를 위한 파워 유저 기능으로, 사용자의 머신에 격리된 개발 팟(pod)을 많이 생성하려는 시도입니다.
).