Hacker News 의견

• 이곳에서 이 주제를 보게 되어 흥미로움. 나는 Tilt를 몇 년간 사용해 왔지만, Docker에 인수된 후 개발 속도가 느려진 것 같음

  • Tilt는 로컬 개발 환경을 만들어주어 서비스가 프로덕션, 테스트, 개발에서 동일하게 실행되도록 해줌
  • 서비스 코드가 크게 단순화되고 품질이 향상되었음
  • 특히 CRD를 다루는 부분에서 개선이 필요함 (k8s_yaml이 CRD에 의존하는 것을 표시할 방법이 없어 tilt up 호출이 자주 깨짐)
  • 새로운 프로젝트를 시작할 때 가장 먼저 하는 일은 "tilt up"을 작동시키는 것임
  • 테스트에 사용한 것들로는 보안 및 관찰 가능성을 위한 eBPF 기반 수집기, 데이터 파이프라인, 헬름 차트 개발, Kubernetes 컨트롤러 등이 있음
  • 매우 유연하고 다양한 개발에 강력함

• 이 피치는 나에게 좀 웃김

  • 현대 앱은 너무 많은 서비스로 구성되어 있음. 이들은 어디에나 있고 끊임없이 소통 중임
  • 그래서 더 많은 서비스를 쉽게 만들 수 있도록 도구를 만들었음

• 속도와 정확성 사이에서 항상 타협이 필요함

  • 로컬 통합 환경을 유지하려고 하면 너무 느리고 비용이 많이 들게 됨
  • 문제는 Kubernetes 자체가 아니라, 의존성이 증가하면서 로컬에서 세계의 복사본을 실행하려고 하면 점점 느려짐
  • 나는 docker-compose 같은 것을 사용하여 빠르고 간결한 개발 환경을 좋아함. 이는 빠른 속도를 유지하기 위해 일부 의존성을 모의로 처리할 수 있음. 로컬 테스트가 통과되면 다른 환경에서는 Kubernetes를 사용함

• "개발 환경"은 정말로 언어의 네이티브 도구로 직접 테스트를 실행해야 한다고 생각함. 예를 들어 cargo test, bundle exec rspec 등

  • Kubernetes를 실행하는 VM을 실행하고, 그 VM이 Docker 컨테이너를 실행하여 테스트를 실행하게 한다면 매우 화가 날 것임
  • 이를 제대로 하고 신뢰성 있게 하는 것은 여전히 많은 작업이 필요함. Docker를 사용하지 않는 것이 목표라면 더 많은 작업이 필요할 수 있음 (macOS에서 네이티브로 실행하려면 반드시 필요함)
  • 이 분야에는 많은 도구가 있는 것 같음. 이들이 "개발 환경"을 위한 도구라고 부르지 않았으면 좋겠음. 이는 "로컬 머신에 앱을 배포하는" 도구에 더 가까움

• nix-shell을 언급하지 않을 수 없음: nix-shell 링크

• Tilt를 실제로 보고 싶다면, 우리 Chroma 오픈 소스 저장소에서 개발 및 CI를 위한 데이터베이스의 분산 버전을 실행하는 데 사용함. 매우 멋짐 - 클론 후 tilt up을 실행하면 작동함

  • Chroma 링크

• 로컬 환경 설정이 문제였던 적은 없음

  • 단일 클러스터 배포는 매우 쉬움
  • 문제는 우리가 프로덕션에서 관리하는 서비스들이 여러 지역(또는 k8s 클러스터)에 걸쳐 배포된다는 것임
  • 분산 애플리케이션을 디버깅하는 것이 문제임

• Tilt는 "skaffold dev"와 어떻게 비교되는가? 우리는 그 목적을 위해 skaffold를 사용함. 클러스터 내에서 개발하기 위해 사용함

• 얼마 전 Tilt를 잠시 사용해 봤음. Tilt, Garden, 아마도 몇 가지 다른 것들도 사용해 봤고, DevSpace로 정착했음

  • 기억에 따르면, 기존의 프로덕션 인프라와 가장 잘 맞았음. 모든 것을 다른 방식으로 다시 작성할 필요가 없었음
  • 즉, 기존의 kustomize+k8s 설정과 잘 맞았음. 포트 포워딩과 실행 중인 컨테이너로의 빠른 파일 동기화를 추가함. 이것이 내가 정말로 원하는 전부임. 변경할 때마다 이미지를 다시 빌드하는 것은 싫음

• 이것은 본질적으로 개발 컨테이너가 아닌가?