2012-05-10 7 views
2

Я хотел бы создать make-файл, в котором цели и зависимости не будут локальными, а скорее будут жить в каком-то везде AWS/S3.Makefile с удаленными объектами (AWS S3)

Рассмотрите следующий пример, который просто скопировал бы файлы 'data_raw' в 'obj1', а затем 'obj2' (вам нужно было бы отредактировать 'bucket' в каком-нибудь ведро, которое у вас есть, и создать файл 'data_raw' перед запуском этого):

# local, works fine 
bucket = /tmp/test/ 
cp = cp 

# remote, does not work 
bucket = s3://bucket/test/ 
cp = s3cmd cp 

all : $(bucket)obj2 

$(bucket)obj2 : $(bucket)obj1 
    $(cp) $(bucket)obj1 $(bucket)obj2 

$(bucket)obj1 : 
    $(cp) $(bucket)raw_data $(bucket)obj1 

Я получаю ошибку с этим:

makefile:9: *** target pattern contains no `%'. Stop. 

, который предназначен для:

all : $(bucket)obj2 

Я подозреваю, что make не понимает удаленные URI («s3: // xxx») вообще.

Весь пример/документация, которую я мог найти, неявно ссылается на локальные файлы для целей и зависимостей. Обширный поиск в googling дал некоторые, казалось бы, незавершенные идеи о создании задач ant для s3 (http://code.google.com/p/awstasks/).

Это в контексте запуска нескольких сложных/сложных заданий MapReduce в Python.

Я предпочел бы использовать GNU make, но обязательно рассмотрю альтернативы.

Я всегда мог создать небольшое локальное зеркало удаленных целей, но, конечно, есть лучший способ?

Заранее благодарен!

Nic

+0

Сделать лучше всего при использовании файлов * там * для сборки файлов * здесь *. Но этот makefile не выглядит слишком плохим; вы пытаетесь уменьшить сложность? Можете ли вы запустить Make изнутри ведра? – Beta

+0

Трудность здесь, вероятно, заключается в том, что вы не принимаете удаленные URI в качестве целей или зависимостей. Я пропустил что-то глупое (убегая?)? Какими URI должны быть способны обрабатывать? Я бы предположил, что в основном он должен быть способен проверять существование и получать дату, которую S3 должен поддерживать? –

+0

Я не знаю AWS/S3, но вы могли бы использовать пару локальных файлов в качестве прокси, просто чтобы «коснуться», чтобы указать, что реальные файлы были изменены, и цель «synch», чтобы обновить их с помощью их праймериз? – Beta

ответ

1

Один из способов, который работает, чтобы установить ведро S3 локально.

Возможно, на Linux можно использовать предохранитель/s3fs. Это может работать и на MacOS, но, похоже, действительно бесполезно устанавливать. Вместо этого я использовал коммерческое программное обеспечение transmit (нажмите «mount as disk»). При том, что приведенный выше пример является функциональным для меня:

bucket = /Volumes/s3.amazonaws.com/bucket/test/ 
cp = cp 

В этом примере мы используем «ф», потому что «s3cmd ф» отвергает местные URIs. В примере (моей) в реальной жизни эта команда будет заменена некоторым скриптом python map-reduce, который потребует фактического ввода-вывода s3.

Чтобы сохранить порядок вещей, вероятно, должна быть одна префиксная переменная («/Volumes/s3.amazonaws.com/») локально смонтированным файлам (для Make to test существование/актуальность) и одна префиксная переменная («s3: //») для команды сборки указывает на фактические данные (данные будут массироваться экземплярами EC2 через mapreduce, мы абсолютно не хотим загружать все локально).

Имейте в виду, что S3 в конечном итоге последователен. Также убедитесь, что для проверки наличия и актуальности весь файл не загружается локально (в этом случае должны использоваться некоторые фиктивные файлы).

Надеюсь, что это поможет.

Если у кого-то есть более прямой подход (нет местного монтажа), мне интересно.

Nic

Смежные вопросы