Как развернуть высоко итеративные обновления - PullRequest
Новая
       14

Как развернуть высоко итеративные обновления

0 голосов
/ 18 января 2010

У меня есть набор бинарных ресурсов (SWF-файлов), каждый размером около 150 КБ.Я разрабатываю их локально на своем домашнем компьютере и хочу периодически развертывать их для проверки.Моя текущая стратегия:

  1. Скопируйте файлы .swf в каталог передачи, который также является репозиторием hg (mercurial).
  2. hg push изменения в моем VPN-хосте slicehost
  3. ssh на моем VPN-хосте slicehost
    • cd в моем каталоге передачи и hg up
    • su www и cp измененных файлов в мою общую папку для просмотра.

Я хотел бы автоматизировать процесс.В лучшем случае это что-то вроде:

  1. Скопируйте файлы .swf в каталог "быстрого развертывания"
  2. Запустите один локальный скрипт, чтобы выполнить все вышеперечисленное.

Меня интересует:

  • советы о том, где разместить пароли, поскольку мне нужно su www для передачи файлов в общедоступные веб-каталоги.
  • как обрабатывается разделение ответственности между локальной машиной и сервером.

Я думаю, что использование rsync - лучший инструмент, чем hg, поскольку мне не нужна история изменений этихтипы изменений.Я могу написать это как скрипт на python, как скрипт оболочки или, тем не менее, считается наилучшей практикой.

В конечном итоге я хотел бы встроить это в систему, которая сможет справиться со своими скромными потребностями в развертывании.Возможно, существует система развертывания с открытым исходным кодом , которая обрабатывает этот и другие типы ситуаций?Я, вероятно, буду самодостаточен для этой текущей потребности, но в долгосрочной перспективе я хотел бы что-то относительно гибкое.

Примечание: Мой домашний компьютер разработки - OS X, и целевой сервер -какой-то недавний аромат Ubuntu.Я бы предпочел решение на основе Python, но если это лучше всего сделать из оболочки, у меня не возникнет проблем с его сборкой.

Ответы [ 2 ]

1 голос
/ 18 января 2010

Если вам удобно в Python, я рекомендую Fabric для сценариев автоматического развертывания.

В дополнение к групповым разрешениям или ssh-ing как www (с аутентификацией на основе ключей), третье решение проблемы разрешений - добавить вашего пользователя в / etc / sudoers и использовать sudo (вы можете указать точную команду, для которой вашему пользователю разрешено использовать sudo, поэтому вы можете свести к минимуму последствия для безопасности).

1 голос
/ 18 января 2010

, чтобы избежать su www Я вижу два простых варианта.

  • делает папку доступной для записи и доступной для чтения группой www по некоторому пути, который веб-сервер сможет обслуживатьзатем вы можете выполнить rsync в эту папку где-то на вашем локальном компьютере.

  • поместите ваш открытый ключ ssh в авторизованные ключи www и rsync для пользователя www (возможно, в некоторых настройках немного меньше безопасности, но не намного, и обычно более удобно).

Обойти su www, поместив свой пароль или пароль в какой-либо файл, будет гораздо менее безопасно.

AСкрипт для вызова "rsync -avz --partial /some/path www@server:some/other/path" должен быть быстрым для написания на python (хотя я не очень хорошо пишу на python).

...