2010-02-25 4 views
0

진부한 제목 죄송합니다.매일 여러 플랫폼에서 이미지 파일을 배포하는 좋은 해결책은 무엇입니까?

나는 매일 (최대 100 개의 이미지가 추가, 수정 및/또는 삭제 된) 제품 이미지 저장소 (약 55,000, 약 1000 년 성장)를 보유하고 있습니다.

위의 변경 작업을 수행하려면 3 명이 필요합니다 (따라서 해당 사용자가 디렉토리를 읽고 쓸 수 있습니다). 그들은 모두 윈도우 비스타 PC를 사용할 것입니다.

또한 벤더가 매일 변경 사항을 최신 상태로 유지할 수 있도록 이미지를 호스팅 할 수 있어야합니다. 약 100 개의 공급 업체가 있습니다.

지금 구현하려는 시스템에는 Subversion을 사용하는 것이 포함됩니다.

트렁크에는 여러 개의 디렉토리와 하위 디렉토리로 분할 된 이미지가 있습니다. 세 사람은 로컬 컴퓨터에서 작업 복사본을 사용하여 필요한 변경 작업을 수행 할 수 있으므로 충돌에 대해 걱정할 필요가 없습니다. 게다가 모든 사람들은 리포지토리 (버전 관리 및 백업의 명백한 이점은 말할 것도 없습니다)를 통해 쉽게 최신 상태를 유지할 수 있습니다.

나는 공급 업체가 체크 아웃 변경 만 할 수 있도록 트렁크에 대한 읽기 전용 공개 URL을 가지고 있습니다. 저장소를 체크 아웃하는 방법과 매일 repo를 업데이트하는 cron을 설치하는 방법에 대한 지침을 제공 할 수 있으므로 항상 유용합니다. 따라서 항상 최신 상태입니다.

모든 공급 업체는 서버에서 cron 작업 및 svn repo를 설정하는 데 충분한 기술 전문 지식을 갖추고 있습니다.

이 모든 것은 약간 해킹 된 것으로 느껴집니다. (해킹을 위해 설계되지 않은 무언가를 사용하려고 할 때 언제든지 생각합니다.)

내 질문에이 솔루션의 단점이 있습니까? 내가하려는 일에 더 도움이 될 수있는 다른 해결책이 있습니까?

Dropbox를 사용하여 모든 서버에서 동기화를 고려했지만 공급 업체가 변경을 원하지 않았습니다.

내 목표는 내 디자이너

  1. 만들기 유지 보수 용이.
  2. 공급 업체에 한 번만 설정하고 이미지는 항상 이미지로 업데이트됩니다.
  3. 괜찮은 백업/복원과 롤백 시스템이 있습니다. 바로이 경우 위기 상황입니다.
+0

FTP, HTML, email? – voyager

+0

공급 업체는 초기 설정을 제외하고는 아무 것도하고 싶지 않습니다. –

+0

당신은 항상 FTP 폴더, 보안 HTTP 서버 또는 생각하고있는대로 SVN에서 적절한 위치로 파일을 다운로드하는 간단한 스크립트를 만들 수 있습니다. 나쁜 방식으로 해킹하지 않습니다. 그것은 유효한 해결책입니다. – voyager

답변

1

당신의 솔루션은 어떤 것처럼 보입니다. 서버에서 클라이언트로 이미지를 검색하는 작은 클라이언트 스크립트 만하면됩니다.

내가 좋아하지 않는 유일한 점은 이미지를 저장하기 위해 전복을 사용하는 것뿐입니다. 작동하지만 모든 변경 사항은 델타로 저장되지 않고 전체 새 파일로 저장됩니다. 이것은 당신에게 중요하지 않을 수도 있습니다.

또한 rsync을 사용하면 변경된 파일 만 쉽게 전송하여 대역폭을 절약 할 수 있습니다. 또한 전송시 SSH 사용을 고려해야 할 수도 있습니다.

한 가지 더 중요한 것은 클라이언트 전체에서 하루 중 서로 다른 시간에 동기화 스크립트를 예약하여로드가 더 빨라지도록 지정하는 것입니다.

+0

변경된 이미지의 좋은 점이지만 전체 저장소의 크기가 완전히 벗어나는 경우가 아니면 큰 문제가되지 않습니다. rsync 접근 방식을 고려했지만 많은 클라이언트에 이미지가 있습니다. 내부 서버에서 이미지를 가져 오는 대신 이미지를 가져 오는 것이 필요합니다. –

1

많은 이미지가있는 저장소의 크기에 대한 우려를 공유하지만 해결책은 전반적으로 적합합니다. 특정 수준에서 이미지를 위해 특별히 고안된 콘텐츠 관리 시스템이 더 적합 할 수도 있습니다 (권장 할만한 정보를 모르지만).

벤더가 실제로 파일을 편집/커밋 할 수 있어야하는 경우가 아니면 파일 시스템으로 내보내는 예약 된 작업을 설정하는 것이 좋습니다 (FTP를 통해 사용 가능하도록 설정하는 것이 좋습니다)./HTTP/etc). 공급 업체가 체크 아웃을 수행하면 작업 복사본의 모든 오버 헤드가 발생하게됩니다. (결국이 ".svn 디렉토리는 무엇이고 다른 파일은 무엇입니까?"라는 질문을 처리하게됩니다.)

+0

그게 정확히 내가 만난 문제입니다. 체크 아웃 프로세스는 정상적으로 작동하지만 .svn 디렉토리 및 파일에 너무 많은 오버 헤드가 추가되어 사용성 측면에서 성능이 저하됩니다. 공급 업체는 리포 변경을 할 수 없어야합니다 (읽기 전용 액세스 권한이 주어짐). 이 문제가 이전에 해결되지 않았다고 생각하기는 어렵습니다. 나는 계속해서 실험하려고한다. 도움 주셔서 감사합니다. –

+0

그 이유는 당신이 체크 아웃 대신에 수출을 사용할 것을 제안했기 때문입니다. 그냥 모호성을 피하기 위해, 내가 제안하는 것은 "svn 체크 아웃"대신 "svn 내보내기"입니다 그것은 모든 삭제를 미러링하지 않지만 모든 것을 복사합니다. 전반적으로, rsync는 더 나은 솔루션입니다 : 대역폭 감소, 삭제 삭제. 나는 이것이 벤더의 내부 시스템 (매우 자주 사용하는 것이 아닌)에서 시작될 수 있다고 생각한다. – ThatBlairGuy

+0

svn export의 문제는 (틀렸다고 나에게 맞다.) export는 호출 할 때마다 repo의 모든 것을 다시 다운로드한다는 것이다. 저는 rsync를 많이 사용했지만 운영체제 (rsync를 지원하지 않는 것들)를 수용 할 수 있어야합니다. 제안 해 주셔서 감사합니다. –

관련 문제