Зачем перестраивать команды оболочки построчно в сценарии Fabric?

Question

Fabric - это инструмент для «выполнения локальных или удаленных команд оболочки».

Зачем вам повторять реализацию сценария удаленной оболочки построчно в длинном сценарии Fabric?

То есть почему бы просто не написать короткий скрипт Fabric, который вместо этого запускает длинный скрипт удаленной оболочки?

Answer 1

lobster1234 поднимает вопрос о том, что вам не нужно вручную вставлять длинный сценарий удаленной оболочки на 10 серверах. Однако если вы все же хотите избежать переписывания длинного сценария удаленной оболочки как длинного сценария Fabric, вы можете написать сценарий Fabric, который копирует этот сценарий удаленной оболочки на назначенный сервер, выполняет этот сценарий и затем удаляет сценарий. Таким образом, вы можете одновременно управлять версиями скрипта fabfile и оболочки, но не переписывать скрипт оболочки в скрипт Fabric.

Answer 2

Не будет хорошей идеей, если мне придется запускать один и тот же скрипт на, скажем, 10 серверах. Это означает, что я должен не только прикрепить один и тот же длинный скрипт на 10 серверах, но и убедиться, что если я изменю его на 1 сервере, изменения должны быть применены ко всем серверам. Я знаю, что этого можно избежать, если оставить этот сценарий в общедоступном месте, но он гораздо более организован, чтобы иметь сценарий в файле fabfile, который не только контролируется версией, но и поддерживается единым для всех ролей.

Answer 3

Кроме того, я думаю, что путь, который вы выберете, будет зависеть от того, что вы пытаетесь сделать. В Python некоторые вещи проще (напишите это в своем файле), в то время как другие проще в Shell-Land (используйте один из упомянутых подходов оболочки).

В любом случае, ткань ориентирована на централизацию и переносимость, и на самом деле не имеет значения, что на самом деле делает подъем.