从1.x升级¶
现代结构(2+)代表了软件的几乎完全重新实现和重组。已经过去了 broken in two 清理,更明确,等等。在某些情况下,升级只需要基本搜索&replace;在其他情况下,需要做更多的工作。
如果您仔细阅读本文档,它将引导您朝正确的方向前进,直到您完全升级。如果您在Fabric 1中使用的任何功能未在此处列出,请提交一张罚单。 on Github 我们会尽快更新。
警告
从2.0释放线开始,织物2 not 与1.x!的100%功能对等!一些特性已经被显式地删除了,但其他特性还没有被移植,要么是由于时间限制,要么是因为所说的特性需要在现代环境中重新检查。
请查看以下信息,包括 升级详细信息 在提交错误报告之前,包含一个非常详细的列表的部分!
也看到 the roadmap 有关版本控制的其他说明。
为什么要升级?¶
我们不想以任何特定的顺序,呼吁对现代 Fabric 进行一些特定的改进,这可能会使升级值得您花时间。
备注
这些都列在医生的其他部分,所以如果你已经被卖了,就跳过那里。
线程安全-不再要求多处理并发性;
API重新组织
fabric.connection.Connection
对象而不是全局模块状态;对命令行解析器进行了大修,以允许在每个任务的基础上使用常规的GNU/POSIX样式标志和选项(不再使用
fab mytask:weird=custom,arg=format
;任务组织更加明确和灵活/具有更少的“魔力”;
任务可以声明其他任务始终在自己之前或之后运行;
配置大规模扩展,允许多个配置文件和格式、env vars、每个用户/项目/模块配置等;
ssh配置文件加载在默认情况下是启用的,并且已经扩展了:系统/用户/运行时文件选择;
shell命令执行API在本地和远程方法调用之间保持一致-不再区分
local
和run
(当然,除了运行命令的地方!);shell命令更加灵活:交互行为、同时捕获和显示(现在适用于本地子进程,而不仅仅是远程进程)、编码控制和自动响应;
对ssh层使用paramiko的API会更加透明-例如
fabric.connection.Connection
允许控制给予的禁运SSHClient.connect
;网关/跨接主机功能提供
ProxyJump
样式“native”(无代理命令子进程)选项,可以无限嵌套;
要调用的“侧放”¶
我们链接到了上面关于这个的一个注释,但要明确:现代结构实际上是几个独立的库,并且任何与ssh或网络无关的东西 split out into the Invoke project .
这意味着,如果您是一组仅利用结构执行任务的用户,或者 local
,从未使用过 run
, put
或类似的 你不需要再使用布料本身了 并且可以简单地 改为调用“sidegrade” .
您仍然希望阅读此文档以了解情况的变化,但请注意,您可以避开 pip install invoke
不需要结构、参数、密码依赖性或其他任何东西。
从invoke中使用现代结构¶
我们打算增强现代织物,直到它包含织物1的大部分用例,这样您就可以使用 fab
而fabfiles本身并不太关心它是如何建立在invoke之上的。
然而,在这一点之前——对于中级到高级用户来说,这一点非常有用——事实上,现代结构的设计考虑到了库或直接的API使用。 在某些情况下,完全可以使用invoke来满足您的cli需求,并在invoke任务中将结构用作纯API。
换句话说,你可以避开 fab
/除非你发现自己非常需要特别会议的便利设施,比如 --hosts
诸如此类。
同时运行两种结构版本¶
为了帮助逐步升级,现代织物可以安装在名称下 fabric2
(除了“正常”提供2.0+版本的 fabric
)并且可以与1.x版的安装共存。
因此,如果您有一个大的代码库,并且不想一次跳到现代版本,那么可以同时使用两种结构1 (fabric
,就像你以前安装的一样)和现代织物 fabric2
)同时驻留在您的Python环境中。
备注
我们强烈建议您最终使用Fabric1将所有代码迁移到版本2或更高版本,以便您可以返回到 fabric
姓名。 fabric2
作为一个独特的包和模块,它的目的是要有一个权宜之计,而不会有任何 fabric3
或者更高(尤其是因为其中一些名字已经被取了!)
有关如何获取 fabric2
包的版本,请参见 安装现代 Fabric 组件 fabric2 .
创造 Connection
和/或 Config
V1设置中的对象¶
逐段升级时的一种常见策略是生成其内容与当前Fabric 1环境匹配的现代Fabric对象。而Fabric 1存储 all 配置(包括“当前主机”)放在一个地方-- env
对象--现代织物将事物分解成多个(尽管是合成的)对象: Connection
对于每个连接的参数,和 Config
用于常规设置和默认设置。
在大多数情况下,您只需要生成 Connection
使用备用类构造函数创建 Connection.from_v1
,它应该喂给您适当的本地 fabric.api.env
对象;有关详细信息,请参阅其API文档。
一个人为的例子::
from fabric.api import env, run
from fabric2 import Connection
env.host_string = "admin@myserver"
run("whoami") # v1
cxn = Connection.from_v1(env)
cxn.run("whoami") # v2+
默认情况下,此构造函数调用另一个API成员-- Config.from_v1
--内部代表你方。需要更严格地控制现代风格配置选项的用户可以选择显式调用该类方法,并将修改后的结果提交给 Connection.from_v1
,这将导致后者跳过任何隐式配置创建。
V1的映射 env
向现代API成员提供VAR¶
这个 env
VAR及其如何映射到 Connection
论据或 Config
值(当输入到 .from_v1
上述构造函数)如下所示。
V1版 |
V2+用法(以其最终所在的类为前缀) |
---|---|
|
配置: |
|
配置: |
|
配置: |
|
配置: |
|
连接: |
|
Not supported :Fabric 1在将其传递到Paramiko之前对其执行了额外的处理(尝试一组关键类来实例化);现代Fabric更喜欢直接让您处理Paramiko级别的参数。 如果您正在填充您的织物1 如果要将来自其他源的键数据作为字符串加载,则应该知道您的数据是什么类型的键,并手动实例化它,然后将其提供给 from io import StringIO
from fabric.state import env
from fabric2 import Connection
from paramiko import RSAKey
from somewhere import load_my_key_string
pkey = RSAKey.from_private_key(StringIO(load_my_key_string()))
cxn = Connection.from_v1(env, connect_kwargs={"pkey": pkey})
|
|
配置: |
|
配置: |
|
Config: |
|
连接: 备注 自V1以来,S |
|
配置: |
|
配置: |
|
配置: |
|
配置: |
|
配置: |
|
连接: |
|
配置: |
升级详细信息¶
这是一份详尽的 all Fabric1.x功能以及1.x中没有的新to-invoke-or-Fabric-2功能;它指定是否需要升级,如果需要,如何升级,并跟踪尚未在现代版本中实现的功能。
大多数部分以表格形式分解,如下所示:
结构1特征或行为 |
状态,详见下文 |
迁移说明、迁移原理等 |
下面是“状态”列的典型值,尽管其中一些值有点松——请确保在所有情况下都阅读“注释”列!还请注意,事情并不是铁面无私的——例如,如果有足够多的用户请求,任何“删除的”项目都有返回的机会,或者如果使用案例表明解决方法不足。
Ported :已可用,可能已重命名或移动(经常移动到 Invoke CodeBase。)
悬而未决的 :适合,但尚未移植,很适合补丁。 这些条目链接到相应的GitHub票据 -请不要做新的!
远离的 明确地 not 移植(不再符合视力,维护价值比太差等),不太可能恢复。
以下是用于导航的快速本地目录:
一般/概念¶
cli面向任务的工作流仍然是一个主要的设计目标,但是库用例不再是二级公民;相反,库功能是首先设计的,并且在其基础上构建了cli/task功能。
此外,在cli用例中,版本1过分强调了“lazy”交互式提示的身份验证机密,甚至连接参数,部分原因是缺乏强大的配置机制。随着时间的推移,很明显,这不值得折中使用混淆的非交互行为和困难的调试/测试过程。
现代结构采用了一种可以说更干净的方法(基于随着时间推移添加到v1的功能),鼓励用户利用配置系统和/或在 开始 如果系统确定中途缺少信息,则会引发异常而不是提示。
invoke的设计包括 explicit user-facing testing functionality ;如果您以前没有找到使用代码为结构编写测试的方法,那么现在应该更容易了。
我们建议您尽早编写测试;它们将帮助您明确升级过程,并使过程更安全!
API组织¶
高级代码流和API成员关注点。
通过导入所有内容 |
远离的 |
所有有用的导入现在都可以在顶级级别使用,例如 |
全局配置连接参数(通过 |
远离的 |
主API现在正确了oop:实例化 参见
|
强调将序列化的“主机字符串”作为设置用户、主机、端口等的方法 |
移植/移除 |
此外,许多参数/设置等在v1中需要主机字符串,现在需要 |
使用“角色”作为主机字符串的全局命名列表 |
端口 |
这个需求现在由 See the line items for |
任务功能和装饰¶
备注
几乎所有与任务相关的功能都在invoke中实现;有关更多详细信息,请参见 execution 和 namespaces 文档。
默认情况下,任务从 |
端口 |
这种行为在今天基本上是相同的,只做了一些小的修改和增强(例如对加载过程的更严格控制,以及实现自定义加载程序逻辑的API钩子——请参见 loading-collections ) |
“经典”样式的隐式任务函数缺少 |
远离的 |
即使是在v1中,它们也在逐渐消失,现在通过invoke的 |
“新”风格 |
端口 |
基本上是一样的,尽管现在有了超级大国- |
任意任务函数参数(即 |
端口 |
这将获取自己的行项目,因为:任务现在必须 这就牺牲了v1的一小部分“快速DSL”,以换取更清晰、更易于理解/调试和更多用户可重写的API结构。 作为副作用,它减少了“功能模块”和“方法类”之间的区别;用户可以更容易地从“功能模块”开始,并在需求增长/变化时迁移到“方法类”。 |
通过导入爬行隐式生成任务树 |
移植/移除 |
名称空间构造现在更加明确;例如,在 However, the root 我们可以稍后恢复(以可选方式)导入的模块扫描,因为使用显式命名空间对象仍然允许用户控制结果树。 |
|
端口 |
恢复为 |
|
悬而未决的 |
看见 API组织 以了解有关整体“角色”概念的详细信息。当它回来时,这可能会紧随其后 |
|
端口/待机 <https://github.com/pyinvoke/invoke/issues/63>`__ |
并行执行目前在API级别通过 这个问题需要在更高的级别上解决,而不仅仅是ssh目标,因此这将链接到一个调用级别的票据。 |
|
这是重写中最重要的“缺少功能”之一;链接用于调用跟踪程序。 |
|
|
端口 |
虽然没有与v1共享许多实现细节,但现代结构(via invoke)公开了 |
cli参数、选项和行为¶
将任务参数暴露为自定义冒号/逗号分隔的CLI参数,例如 |
远离的 |
cli参数现在是合适的gnu/posix样式的长和短标志,包括将短标志放在一起、空格或等号来附加值、可选值等等。见 invoking-tasks . |
任务定义名称直接镜像在命令行上,例如用于任务 |
远离的 |
任务名称现在从下划线转换为连字符。任务 |
能够在一个命令行中调用多个任务,例如 |
端口 |
工作很棒! |
|
端口 |
移植于2.2。 |
|
远离的 |
要永久禁用代理的使用,请设置配置值 |
|
远离的 |
这个的config和kwarg版本被移植,但目前没有cli标志。通常,“可以在运行时用shell env变量设置配置值”子句有效,因此 may 不被移植,视情况而定。 |
|
远离的 |
请参见有关交互提示离开的注释 一般/概念 . 如果没有中间会话提示,则不需要此选项。 |
|
端口 |
|
|
颜色工作还没有完成,这是可能丢失的部分之一。我们不确定它在v1中的使用频率,所以它可能不会再次出现,但一般来说,我们喜欢使用颜色作为额外的输出向量,所以… |
|
|
端口 |
这是现在的标准 |
|
还没有预告,可能会。 |
|
|
端口/待机 <https://github.com/fabric/fabric/issues/1805>`__ |
已经没有显式连接缓存了,因此不必太急地断开连接。然而,调查和潜在的特征切换仍然悬而未决。 |
|
端口 |
现在分为 |
|
可以设置全局 因此,如果有足够多的用户注意到这一点,我们将考虑一个在很大程度上模仿v1行为的特性add:string成为 |
|
|
远离的 |
这些似乎不够用,不值得移植,特别是因为它们落在了通常的伞下“帕拉米科级连接直通”所涵盖的 |
|
远离的 |
这可以通过配置系统和env vars进行配置。 |
|
端口 |
工作原理与之前基本相同-如果给定,则是每个主机执行一次任何给定任务的简写。 |
|
端口 |
与v1的工作原理相同,包括多次提供构建要尝试的密钥列表的能力。 |
|
端口 |
现在 |
|
端口 |
这是现在 |
|
远离的 |
使用环境变量设置 |
|
还没有移植。 |
|
|
端口 |
现在有了额外的JSON列表格式!顺便说一下,它取代了 |
|
远离的 |
这并不符合现代命令执行代码对世界的看法,所以它已经不复存在了。 |
|
还没有移植。 |
|
|
端口 |
现在是 |
|
远离的 |
首先,这通常不太安全,现在有许多其他的方法来设置相关的配置值,所以至少现在已经不存在了。 |
|
查看周围的注释 |
|
|
远离的 |
我们的直觉说这最好留给配置系统的env var层,或者使用 |
|
还没有移植。 |
|
|
如下所述 API组织 ,角色列表仅部分适用于新的API,我们仍在摸索它们是否/如何在全局或CLI级别上工作。 |
|
|
远离的 |
这在很大程度上被对shell环境变量的新支持所消除(只需做 |
|
远离的 |
为此,请使用配置系统。 |
|
端口 |
见 |
|
还没有移植。 |
|
|
远离的 |
对我们来说,这主要感觉像膨胀,可能需要对重实现进行一些重要的解析器更改,所以现在已经过时了。 |
|
端口 |
这是现在 |
|
Pending 移除 |
这不太可能作为自己的cli标志返回,但它可能作为配置值返回。 |
|
端口 |
现在是时候了 |
|
端口 |
在调用中实现并在 |
|
远离的 |
大多数情况下,配置(env vars for true runtime,或例如用户/项目级的配置文件,视情况而定)都应该用于此目的,但它可能会返回。 |
|
端口 |
照原样移植,没有变化。 |
|
尚未移植,正在等待对全局(vs手工实例化)连接/组选择进行深度重做。 |
|
|
远离的 |
现在已经没有工作队列了,至少现在没有。不管用什么替代它(除了已经实现的线程模型),看起来都可能大不相同。 |
shell命令执行 (local
/运行`/
sudo``)¶
一般¶
任何一方共享的行为 run
/sudo
,或全部 run
/sudo
'''本地''。后面的部分按功能差异进行介绍。
|
远离的 |
所有命令执行现在都是统一的;所有三个函数(现在方法打开 例如,在v1中 |
提示自动响应,通过 |
端口 |
这个 此外, |
|
端口/待机 <https://github.com/fabric/fabric/issues/1752>`__ |
These are now methods on |
|
端口 |
上下文管理器是在任何范围内设置环境变量的唯一方法;在现代结构中,每个调用都可以控制子进程shell环境(直接在 |
通过操作控制子流程输出和其他活动显示文本 |
端口/待机 <https://github.com/pyinvoke/invoke/issues/15>`__ |
“输出级别”的核心概念已经不复存在,很可能在短期内被输出级别重新实现得很差的日志模块(stdlib或其他)所取代。 命令执行方法 |
|
端口 |
现在主要位于调用层,但适用于所有命令执行,无论是本地的还是远程的;请参阅 |
|
端口 |
这已被彻底报告(其行为经常得到改善),包括保存 Fabric0.x和1.x已经改变了这个值;在Fabric1的长生命周期中,很明显默认值对所有用户甚至大多数用户都不起作用,因此我们选择将默认值返回到 |
|
远离的 |
这并不十分有用,而且经常导致概念上的问题 我们建议真正需要合并两个流的用户,或者在命令中使用shell重定向,或者设置 |
|
端口 |
现在只是 |
|
端口 |
这些是现在 |
|
现有的 |
|
返回值是类似字符串的对象,具有 |
端口 |
返回值不再是类似于字符串的半私有API,而是类型为完全成熟的常规对象 但是,它们仍然表现为布尔值——只是反映出退出代码与零的关系,而不是是否存在任何stdout。 |
|
端口 |
不仅是新版本的 |
run
¶
|
远离的 |
非``sudo``远程执行从来没有真正需要一个明确的shell包装器:在几乎所有情况下,远程ssh守护进程都将命令字符串交给连接用户的登录shell。因为包装在其他方面非常容易出错,并且需要令人沮丧的转义规则,所以我们在这个用例中放弃了它。 查看匹配的行项目 |
sudo
¶
除非另有说明,所有常见的 run
+`` sudo``参数/功能(例如 pty
, warn_only
等)在上文的 run
下面是 sudo
具体的。
|
Pending /已删除 |
见上文注释 我们希望升级 |
|
端口 |
这仍然在这里,而且还在叫 |
|
这还没有预告。 |
local
¶
有关新的 local
. 下面是一些具体的附加内容。
|
端口 |
基本上和v1一样,尽管现在有一些情况 |
open_shell
¶
正如主要列表中所指出的,这是现在 shell
,并且行为类似于 open_shell
(如果有退出代码,则忽略;假定为PTY;依此类推)。它也有一些改进,比如返回值(与 run
但这仍然是一大进步 None
)。
|
远离的 |
如果需要,您应该尝试使用现代版本的 |
公用事业¶
错误处理通过 |
端口 |
旧的功能在“一切都是DSL”的方向上倾斜得太远,没有提供足够的价值来抵消它如何阻碍有经验的 Python 。 为了“引发异常”(一个有用的选项是invoke),这些函数已被删除 |
ANSI颜色助手 |
远离的 |
似乎没有必要复制出许多优秀的终端按摩库中的一个(如描述中所列的库)。 #101 )在重写中,我们没有。 这就是说,我们很有可能在将来出售这样一个库来提供内部颜色支持,在这一点上“烘焙”的颜色助手将再次很容易到达。 |
|
端口 |
这是现在 |
|
端口 |
V1需要在您的Sphinx构建管道中的某个位置使用特定于Fabric的‘UNWRAP_TASKS’帮助器函数;现在您只需启用新的 invocations.autodoc Sphinx迷你插件在您的扩展列表中;请参阅链接以了解详细信息。 |
|
远离的 |
与其他与主机字符串相关的工具一样,这些工具已不复存在,而且毫无用处。 |
|
悬而未决的 |
尚未移植;理想情况下,我们只在invoke中提供第三方lib。 |
|
远离的 |
没有为现代结构编写等效的函数;既然连接/客户机对象是显式的,就可以简单地用相同的参数(如果不想手动调用类似于 如果有足够的需求,它返回的可能性很小;如果有,它可能是一个更一般的重新连接相关的 |
|
远离的 |
这还没有被移植,部分原因是维护人员从未自己使用过它,而且不太可能直接重新实现。但是,其核心用例“需要某些数据可用于运行给定任务”可能会在即将到来的依赖关系框架内返回。 |
|
远离的 |
喜欢 |
网络¶
|
端口 |
这是现在 (您可以指定运行时,非ssh配置驱动 |
|
端口 |
这和v1一样继续工作。 |
|
端口 |
这是现在 |
|
远离的 |
在v1中,这只是一个(部分实现的)从原来的“任何错误都只有sys.exit!”行为。现代织物明显更为友好;会引起 |
|
还没有移植。 |
|
|
还没有移植。 |
|
|
端口 |
现在可以通过配置系统(AS)控制连接超时 |
认证¶
备注
一些 env
v1的钥匙只是通过帕拉米科的 SSHClient.connect
方法。现代结构通过 connect_kwargs
configuration 子树,下表将经常引用这种方法。
|
端口 |
使用 |
|
端口 |
使用 还要注意,这用于执行双负载连接 and sudo密码;后者现在位于 |
|
端口 |
使用 |
|
远离的 |
这已被删除,因为对Paramiko级别的API进行了不必要的(易出错)模糊处理;用户应该已经知道他们正在处理的是哪种类型的密钥,并实例化一个 |
|
端口 |
将此设置为的用户 |
|
端口 |
使用 |
|
端口/待机 <https://github.com/fabric/fabric/issues/4>`__ |
各 但是,我们希望用户可以使用一种更简单的方法来设置将变为隐式的配置值。 |
配置 |
端口 |
还有一些新的荣誉 |
文件传输¶
以下功能分解适用于 put
和/或 get
v1的“操作”功能。
传输本地和远程用户拥有的单个文件 |
端口 |
任何方向的基本文件传输都有效,并提供 与v1相比,这些方法的签名已被清除,尽管它们的位置参数本质 ( |
省略隐式“相对于本地上下文”行为的“Destination”参数(例如 |
端口 |
您可能仍然应该是显式的,因为这是Python。 |
使用任一文件路径 or 传输操作任一侧的类似文件的对象(例如上载 |
端口 |
这是一个非常有用且非常简单的技巧。 |
在目的地保留源文件模式(例如,确保将由目的地的umask删除的可执行位被重新添加)。 |
端口 |
这不仅是预告,而且现在是默认行为。如果需要,可以通过Kwarg禁用。 |
捆扎 |
远离的 |
这是v1中最令人讨厌的部分之一,而且从来没有真正做过用户在后续呼叫中不能做的事情。 如果有足够多的用户对它的损失感到担忧,我们 may 重新考虑一下,但是如果我们这样做,我们将认真关注简化和/或不涉及中间文件的方法。 |
递归多文件传输(例如 |
远离的 |
这是 另一个 v1最麻烦的部分之一,随着时间的推移,很明显它的维护负担远远超过了这一事实:它的重新设计很糟糕。 有关一种可能的解决方法,请参阅 |
远程文件路径代字号扩展 |
远离的 |
这种行为最终是不必要的(为了同样的结果,你可以简单地去掉波浪号),而且它本身也有一些有害的错误,所以它已经消失了。 |
以远程目标的某个方面命名下载的文件,以避免在多服务器操作期间覆盖 |
端口 |
添加回(到 |
配置¶
总的来说,配置已经大大改善了 fabricrc
文件;大多数配置逻辑来自 Invoke's configuration system 它提供了一个完整的配置层次结构(在代码配置、多个配置文件位置、环境变量、CLI标志等)和多个文件格式。在现代结构中,结构1中的几乎所有配置通道都变成了配置层次结构中最适合您需要的任何部分的操作。
结构的现代版本只对invoke的设置进行细微的修改(或参数化);请参见 our locally-specific config doc page 有关详细信息。
备注
确保在本文档的其他地方查找任何给定v1的详细信息 env
设置,因为许多已从配置系统外移到对象或方法关键字参数中。
修改 |
端口 |
要真正实现全局范围的配置更改,请使用配置文件、任务集合级别的配置数据或调用shell的环境变量。 |
使本地范围 |
移植/未决 |
周围的大多数用例 剩下的这些用例已经变成了 |
ssh配置文件加载(默认关闭,仅限于 |
端口 |
大大改进了:ssh配置文件加载是 on 默认情况下 can be changed )和OpenSSH一样,加载和合并了多个源,此外还有更多;请参见 ssh-config . 此外,我们还为一些 |
contrib
¶
老年人 contrib
模块表示“最佳实践”函数,这些函数本身不需要其他结构的核心支持,而是使用用户可用的相同原语构建的。
在现代结构中,这种责任已经从核心库转移到其他独立的库中,这些库具有自己的身份和发布过程,通常是 invocations (不使用ssh的面向本地的代码)或 patchwork (主要是面向远程的代码,尽管没有显式地处理连接两端的任何事情都可以在本地正常工作。)
这些库仍然在进行中,尤其是因为我们仍然需要找出弥合它们之间差距的最佳方法(因为许多操作本质上不是本地的或远程的,但可以在任何一端工作)。
由于根据定义,它们是建立在所有用户可用的核心API之上的,因此它们目前的开发重点较少;用户总是可以实现自己的版本,而不会牺牲太多(对于核心库来说,这是不太现实的事情)。一旦核心API稳定下来,我们希望在管理这些集合方面投入更多的工作。
每个单独块的详细信息 fabric.contrib
在下表中:
|
端口 |
搬到 |
|
远离的 |
我们甚至不确定这本书写完十年后是否有用,因为从那以后,姜戈肯定发生了很大的变化。如果你正在阅读,并且对这件事的消失感到悲伤,请告诉我们! |
|
移植/未决 |
这个文件中许多更有用的函数已经移植到 其他,如 |
|
端口 |
现在 |
|
远离的 |
这似乎不值得移植;“远程复制本地位”的总体模式已经可以说是一个反模式(vs可重复部署工件,或者至少远程签出VCS标签),而且如果有人走这条路,rsync是一个更明智的选择。 |
fabric.env
参考¶
v1中的许多/大多数成员 fabric.env
在以上每个主题部分都有介绍;任何 not 在别处,住在这里。所有这些都明确指出为 env.<name>
以便在浏览器或查看器中搜索。
少数env变量从未公开记录,因此是隐式私有的;这些变量在这里没有表示。
|
远离的 |
当一个概念消失后中止,只需向最终用户提出任何看起来最合理的异常,或使用 |
|
织物的 但是,该API的详细信息(例如,通过任务的 |
|
|
参见注释 |
|
|
端口 |
这是现在 |
|
端口 |
这是现在 请注意,尚未设置此数据的远程和本地上下文;请参阅有关 |
|
尚未移植,可能会作为角色/主机列表大修的一部分处理。 |
|
|
端口 |
现在是下的配置选项 |
|
远离的 |
我们不完全确定为什么v1认为这值得在配置中缓存;如果您需要此信息,只需导入并调用 |
|
区分并行stdout/err仍然是一项正在进行的工作;我们可能最终会逐个行地重用日志记录和前缀(最好是通过实际日志记录),或者我们可能会尝试使用更干净的方法,例如按连接流式传输到日志文件。 |
|
|
端口 |
提示自动响应现在公开实现为 |
|
端口 |
加载任务 |
|
移植/移除 |
invoke的中断捕获行为当前为“总是将中断字符发送到子进程并继续”,允许子进程处理 允许用户通过config更改此行为还没有实现,也可能没有实现,这取决于是否有人需要它——出于向后兼容的原因,它被添加为v1中的一个选项。 技术上也可以通过子类化和重写来更改中断行为。 |
|
如中所述 API组织 ,作为一个概念的角色被移植到 我们 may 将其永远委托给userland,但似乎是一个常见的最佳实践选项(例如创建 |
|
|
还没有移植,但应该包括一些可能的小更新 |
|
|
sudo命令构造目前只查看配置中的sudo提示。 |
|
|
端口 |
现在是 |
|
远离的 |
与其他功能一样,织物1的“直接跳到 |
|
端口 |
SSH配置加载现在默认处于打开状态,但仍有一个选项可以禁用它。看见 配置 想要更多。 |
|
远离的 |
只是 |
示例升级过程¶
本节将介绍如何升级一个小型但不平凡的Fabric1FabFile以使用现代Fabric。它并不意味着详尽,只是说明性的;有关如何升级单个功能或概念的完整列表,请参见 升级详细信息 .
原始FabFile示例¶
以下是Fabric1最终教程片段的副本(稍作修改以符合“现代”Fabric1最佳实践),我们将使用它作为升级的测试用例:
from fabric.api import abort, env, local, run, settings, task
from fabric.contrib.console import confirm
env.hosts = ["my-server"]
@task
def test():
with settings(warn_only=True):
result = local("./manage.py test my_app", capture=True)
if result.failed and not confirm("Tests failed. Continue anyway?"):
abort("Aborting at user request.")
@task
def commit():
local("git add -p && git commit")
@task
def push():
local("git push")
@task
def prepare_deploy():
test()
commit()
push()
@task
def deploy():
code_dir = "/srv/django/myproject"
with settings(warn_only=True):
if run("test -d {}".format(code_dir)).failed:
cmd = "git clone user@vcshost:/path/to/repo/.git {}"
run(cmd.format(code_dir))
with cd(code_dir):
run("git pull")
run("touch app.wsgi")
我们将直接把它移植,这意味着结果仍然是 fabfile.py
不过,我们要注意的是,以一种更面向库的方式编写代码——即使函数没有被包装在 @task
-可以使测试和重用代码更容易。
进口¶
在现代结构中,由于强调对象方法而不是全局函数,我们不需要导入几乎相同的函数。我们只需要以下内容:
Exit
更友好的请求方式sys.exit
;@task
,和以前一样,但来自invoke,因为它不特定于ssh;confirm
它现在来自调用库(也不是特定于ssh;尽管调用是fabric.contrib
(不再存在);
from fabric import task
from invoke import Exit
from invocations.console import confirm
主机列表¶
预定义的概念 global 主机列表已不复存在;目前没有直接替代方案。通常,用户可以设置自己的执行上下文,创建显式 fabric.connection.Connection
和/或 fabric.group.Group
对象;核心Fabric正在构建其上的便利助手,但“创建您自己的连接”将始终在那里作为后盾。
说到方便助手:的大部分功能 fab --hosts
和 @hosts
已经被移植过去--前者直接(请参见 --hosts
),后者作为一种 @task
关键字参数。因此,目前我们的例子将是将全球 env.hosts
转换为轻量级的模块级别变量声明,以便在后续调用 @task
**
my_hosts = ["my-server"]
备注
这是一个正在积极发展的领域,欢迎反馈。
测试任务¶
fabfile中的第一个任务使用了API的良好传播。我们将在这里概述这些更改(不过,所有细节都在 升级详细信息 ):
将函数声明为任务几乎与以前相同:使用
@task
装饰符(在现代织物中,它比它的前身可以接受更多可选的关键字参数,包括一些取代了V1的一些S装饰符)。@task
-包装函数现在必须采用显式的初始上下文参数,其值将是fabric.connection.Connection
对象在运行时。使用
with settings(warn_only=True)
可以用一个简单的木匠来代替local
打电话。那
local
调用现在是对fabric.connection.Connection
,fabric.connection.Connection.local
.capture
不再是一个有用的论点;我们现在可以在本地或远程同时捕获和显示。如果你不是真的 want 在运行时镜像其stdout/err的本地子进程,您可以简单地说hide=True
(或hide="stdout"
或其他)结果对象在不同版本之间非常相似;现代结构的结果不再假装是“be”字符串,而是更像布尔值,如果命令干净地退出,则表现为真实,否则则为虚假。就所展示的属性而言,大多数相同的信息都是可用的,而且更多。
abort
不见了;你应该使用你认为合适的例外,或者Exit
对于一个sys.exit
当量。(或者只是打电话sys.exit
如果您不想问任何问题,请立即退出,即使是我们的CLI机器也不会接触。)
结果:
@task
def test(c):
result = c.local("./manage.py test my_app", warn=True)
if not result and not confirm("Tests failed. Continue anyway?"):
raise Exit("Aborting at user request.")
其他简单任务¶
接下来的两个任务是简单的一行程序,您已经看到了什么取代了全球 local
功能:
@task
def commit(c):
c.local("git add -p && git commit")
@task
def push(c):
c.local("git push")
从其他任务调用任务¶
这是另一个在调用级别处于不断变化中的领域,但是现在,我们可以简单地将其他任务作为函数调用,就像在v1中所做的那样。主要区别在于,我们希望传递上下文对象以保留配置上下文(如加载的配置文件或CLI标志)::
@task
def prepare_deploy(c):
test(c)
commit(c)
push(c)
实际远程步骤¶
请注意,到目前为止,还没有真正与织物有关的东西发挥作用。- fabric.connection.Connection.local
只是重新绑定 Context.run
,调用的本地子进程执行方法。现在我们进入实际的部署步骤,它调用 fabric.connection.Connection.run
相反,远程执行(在 fabric.connection.Connection
已绑定到)。
with cd
尚未在远程方面完全实现,但我们预计很快就会实现。目前我们退回到命令链 &&
.值得注意的是,既然我们关心的是选择主机目标,我们就参考了我们早期对默认主机列表的定义-- my_hosts
--声明此任务的默认主机列表时。
@task(hosts=my_hosts)
def deploy(c):
code_dir = "/srv/django/myproject"
if not c.run("test -d {}".format(code_dir), warn=True):
cmd = "git clone user@vcshost:/path/to/repo/.git {}"
c.run(cmd.format(code_dir))
c.run("cd {} && git pull".format(code_dir))
c.run("cd {} && touch app.wsgi".format(code_dir))
整件事¶
现在我们有了整个升级后的FabFile,它将与现代 Fabric 一起使用:
from invoke import Exit
from invocations.console import confirm
from fabric import task
my_hosts = ["my-server"]
@task
def test(c):
result = c.local("./manage.py test my_app", warn=True)
if not result and not confirm("Tests failed. Continue anyway?"):
raise Exit("Aborting at user request.")
@task
def commit(c):
c.local("git add -p && git commit")
@task
def push(c):
c.local("git push")
@task
def prepare_deploy(c):
test(c)
commit(c)
push(c)
@task(hosts=my_hosts)
def deploy(c):
code_dir = "/srv/django/myproject"
if not c.run("test -d {}".format(code_dir), warn=True):
cmd = "git clone user@vcshost:/path/to/repo/.git {}"
c.run(cmd.format(code_dir))
c.run("cd {} && git pull".format(code_dir))
c.run("cd {} && touch app.wsgi".format(code_dir))