Flynn: 왜 츠 루가 아니야?

이것은 golang-nuts에서 논의되었습니다 . 내 인상은 일부 기능은 비슷하지만 핵심 목표는 다르다는 것입니다.

/ cc @fsouza

@titanous 나는이 스레드를 보았다. tsuru와 flynn 사이의 가장 큰 차이가 tsuru 인 경우 웹에 국한된 경우 약간의 노력으로 수정할 수 있습니다.

두 프로젝트가 합쳐지면이 프로젝트에 더 좋을 것이며 rails + merb에서 일어난 것처럼이 새로운 프로젝트 (tsuru + flynn)를 만들고 유지하기 위해 더 강력한 커뮤니티를 구축하는 것이 더 쉬워 질 것이라고 믿습니다.

현재 계획중인 구성 요소와 목표를 자세히 설명하는보다 완전한 사양을 작업 중입니다. 나는 우리가 그 문서를 푸시 할 때까지이 토론을 건설적으로 연기 할 것이라고 생각합니다.

결론은 이제 차이점이 무엇인지 더 분명하다고 생각합니다.

차이점은 무엇입니까? 명확하지 않습니다. 수행중인 모든 PaaS 작업을 이해할 수있는 추천 할 수있는 소스가 있습니까?

조사를 통해 알아 내려고 노력했지만 Docker로 점점 더 많은 PaaS 시스템이 만들어지는 것에 대해 계속 배우고 있습니다. 따라 잡기가 정말 어렵습니다 ...이 시스템들 각각은 설정하고 시도하는 데 시간과 헌신이 필요합니다. 실제로 그것이 무엇인지 알기 전에 시도해보세요.이 과정에서 일어나는 모든 프로젝트에 대해 더 쉽게 알 수있는 방법이 있습니까? 너무 오래 걸리지 않고 끝없는 토끼 굴이 아닌 공간?

지금까지 본 것에서 Flynn은 꽤 달콤 해 보입니다. 곧 사용해 볼 수있어 기쁩니다.

PS I got here by Googling "tsuru flynn"

@keyvanfatehi 관심을

특히 많은 사람들이 비공개 또는 일관성없는 로드맵을 따르기 때문에 모든 PaaS 프로젝트를 최신 상태로 유지하기가 어렵습니다. 일반적으로 Flynn과 대부분의 다른 PaaS 프로젝트 간의 차이점은 다음과 같습니다 (tsuru와의 직접적인 비교가 아니라 일반적인 공간).

플린 은 더 야심적입니다. Flynn은 상태 저장 서비스를 포함하여 Linux에서 실행되는 모든 것을 실행할 수 있습니다. 우리는이 기능을 이용하여 Flynn과 함께 공통 데이터베이스를 패키징하므로 ​​대부분의 사용자와 프로젝트가 데이터베이스를 다시 수동으로 관리하지 않습니다. Flynn의 구성 요소는 모듈 식이므로 쉽게 재사용, 수정 및 교체하여 요구 사항에 적합한 솔루션을 만들 수 있습니다. 우리는 Flynn이 모든 프로젝트와 조직의 작업을 "해결"하는 단일 툴킷이되기를 바랍니다. 네트워킹 및 개발 워크 플로를위한 차세대 솔루션과 함께 로그 집계, 메트릭, 지속적인 통합을 비롯한 훨씬 더 많은 기능이 제공됩니다.

대부분의 다른 PaaS 프로젝트 는 설정 및 배포가 어렵거나 느리며 특정 종류의 앱에만 유용하며 개발자가 애플리케이션을 다시 설계해야하며 모 놀리 식입니다. 요컨대, Flynn은 어려운 문제를 해결하려고 노력하지만 대부분의 다른 프로젝트는 연령, 기존 사용자 기반 및 디자인 동기로 인해 해결하지 않습니다.

Flynn이 생산 안정성과 기능 완성에 도달하면 프로젝트별로 차이점을 문서화하려고합니다.

@danielsiders 감사합니다! 여러분이이 공간에서 혁신하는 모습을보고 싶습니다. 나는 내 어깨에 너무 많은 작업을 수행하는 데 어려움을 겪습니다 (Docker와 그 주변의 도구를 보는 이유). 나는 작전을 해결할 수 있다고 믿고 싶습니다.

지금까지 내 경험은 deis처럼 보이는 flynn-demo (성공적으로)를 사용했습니다 (직접 시도하지는 않았지만 heroku와 같은 동작을 보여주는 멋진 루핑 비디오가 있습니다). 따라서이 얕은 수준에서 deis, flynn 및 heroku는 동일하게 보입니다.

그것은 개인 로드맵에 대한 좋은 점입니다. 모든 것을 둘러싼 내 머리를 감쌀 것으로 기대하는 것은 조금 이르다고 생각합니다. 추적하고, 차이점을 분별하고, 각 노력을 판단하려고 노력하는 것보다 한 가지 노력에만 전념하는 것이 훨씬 쉬워 보입니다. 각 노력은 혁신적이고 흥미 롭습니다!

어쨌든, 흥미 진진한 시간들-아직 완전히 이해하지 못하더라도이 모든 일이 일어나게 해주셔서 감사합니다. :)

@keyvanfatehi 대부분의 PaaS는 애플리케이션의 Heroku 스타일 (git push) 배포를 지원합니다. 정말 다른 점은 배포 할 수있는 애플리케이션 유형과 앱 배포 후 발생하는 일입니다.

(nb : Flynn은 또한 docker pull 및 git pull 및 빌드하려는 다른 모든 배포 패러다임을 지원합니다. FTP도 어렵지 않습니다.)

@keyvanfatehi , Tsuru에서는 환경 별 구성 및 정적 파일에 대한 개체 저장소 사용과 같은 작은 응용 프로그램 변경을 요구하는 것이 더 효율적이라고 생각합니다. 예 : 문제없이 수평으로 확장해야합니다.) 그러나 우리는 사용자들이 매우 빠른 속도로 그것을 얻을 수있을 정도로 잘 해냈고, 이미 여기 (Globo.com에서) 생산중인 제품을 가지고 있습니다.
서비스에 관해서는 단일 애플리케이션으로 잘 처리하기에는 너무 구체적입니다 (데이터베이스, nosql, redis, memcached, elasticsearch, 개체 스토리지 등을 처리하는 것이 얼마나 어려울 지 상상해보십시오). 우리는 서비스 api (서비스를 처리하는 비즈니스 로직이 배치 될 위치)를 지정하는 것을 선호했으며 tsuru는 어떤 서비스 든 동일한 방식으로 처리합니다. 아무리 다르더라도 상관 없습니다.

우리는 매우 친절하며 기여와 새로운 아이디어에 전적으로 열려 있습니다. 우리는 여전히 단일 솔루션으로 flynn과 함께 작업하는 것이 좋을 것이라고 생각하지만 (미래에 flynn 이상을 충족시키기 위해 tsuru를 확장 할 수 있음), 우리와 같은 야망이기 때문에 그들의 의견과 비전을 전적으로 존중합니다 :-)

TL; DR
우리는 서비스가 얼마나 중요한지 알고 있으므로 이러한 요구 사항을 처리하는 우아한 방법을 개발합니다. Tsuru는 잘 정의 된 서비스 API (생성, 제거, 바인딩, 계획과 같은 간단한 진입 점 포함)로 모든 서비스를 처리 할 수 ​​있습니다. 따라서 특정 서비스의 모든 복잡성은 자체 서비스 API에 의해 처리됩니다. Redis API에 대한 예를 들어 보겠습니다. # tsuru service-add redis (servicename) redis_blognews (serviceinstancename) plus (plan)을 실행하면 redis_blognews라는 이름으로 redis 인스턴스가 생성되고 plan plus (2 개의 인스턴스를 제공하는)가 생성됩니다. 고 가용성을 가진 redis의). Tsuru는 그것이 어떻게 만들어 질지 모르지만 (고 가용성을 가질지라도), 그것은 전적으로 service-api에 의해 처리 될 것입니다. 또한 tsuru 코드를 건드리지 않고도 서비스 API를 생성하는 것만으로도 외부 (독점적 인) 서비스를 사용할 수 있습니다. 따라서 서비스를 처리하는 것이 훨씬 더 유연하고 Tsuru의 복잡성 증가를 피할 수 있습니다. 그런 다음 # tsuru bind redis_blognews --app yourblognewsapp를 사용할 수 있으며 tsuru는 서비스 자격 증명을 애플리케이션에 삽입합니다.

저는 PaaSes를 처음 사용하며 혼란 스럽습니다. 나는 츠루를 골 랐고 나는 그것을 조금 엉망으로 만들었다. 플린의 목표와 크게 다르지 않은 것 같습니다. 서비스 API를 사용하여 상태 저장을 실행할 수 있으며 tsuru-api, docker-cluster, gandalf 등이있는 매우 모듈 식입니다.

노력을 합치면 더 좋은 제품이 나올지 궁금합니다.

여기서 @msabramo에 동의해야합니다. Tsuru의 모든 기능을 포함하는 새로운 PaaS를 구축하는 이유에 대해서는 여전히 좋은 점이 없습니다. 나는 또한 노력을 결합하면 멋진 제품이 될 것이라는 데 동의합니다.