我对这些命令很陌生。我正在尝试对本地文件夹进行 gzip 压缩并在远程服务器上将其解压缩。问题是,gzip 压缩和解压缩必须即时进行。我尝试了很多,我认为最接近的之一是:
tar cf dist.tar ~/Documents/projects/myproject/dist/ | ssh [email protected]:~/public_html/ "tar zx ~/Documents/projects/myproject/dist.tar"
正如您在上面看到的,我尝试将 dist 文件夹发送到远程服务器,但在此之前我尝试动态压缩该文件夹(看起来上面的命令中没有发生这种情况)。
- 本地文件夹:
~/Documents/projects/myproject/dist/
- 远程文件夹
~/public_html
:(直接部署上线)
当然,gzip 创建的文件一定不存在,它应该即时发生。
我的目的是像通过像sh file.command
.换句话说,我正在尝试部署dist
文件夹中已编译的项目,以便在sh
执行命令时运行。我不想每次在项目中进行更改时都手动执行此操作。
答案1
如果您rsync
随后使用它,因为它利用现有文件来允许仅传输差异(即文件的不同部分):
rsync -az ~/Documents/projects/myproject/dist/ [email protected]:public_html/
添加--delete
标志以每次完全覆盖目标目录树。如果您想查看发生了什么,请添加-v
.
如果您没有rsync
,那么使用这种效率较低的解决方案tar
就足够了:
( cd ~/Documents/projects/myproject/dist && tar czf - . ) |
ssh [email protected] 'cd public_html && tar xzf -'
请注意,压缩 tarball 的写入和读取是通过标准输出和标准输入(-
文件名)。如果您使用的是 GNU,tar
您可以-C
在处理之前使用 设置正确的目录,而这里我们使用的是老式(传统?)cd
。添加v
标志(在接收方)以查看发生了什么,即tar xzvf ...
.
答案2
您需要将输出发送tar
到 STDOUT,而不是在磁盘上创建文件,这样就可以使用 ssh 通过线路发送:
$ tar -zcf - /path/to/files | ssh user@host "tar -zx - -C /path/to/destination"
请注意使用文件名时的“-”字符。这些命令告诉发送端的 tar 写入 STDOUT,并告诉接收端的 tar 从 STDIN 读取。归档数据永远不会写入本地磁盘。
使用 ssh 登录时无法指定路径(至少,我从来不知道如何指定),因此您需要告诉tar
接收方在哪里写入其输出 - 这就是它的用途-C /path/to/destination
。
按照目前的编写,该命令将导致文件被写入嵌套在本地目录中的远程端 - 您最终会得到
/path/to/files/index.html --> /path/to/destination/path/to/files/index.html
相反,如果您想要,/path/to/destination/index.html
请这样说:
$ tar -zcf - -C /path/to/files . | ssh user@host "tar -zx - -C /path/to/destination"
答案3
您正在告诉tar
将 tarball 写入文件dist.tar
。使用此命令您不会将 tarball 发送到远程计算机。
您必须将tar
其输出写入stdout
using -f -
。连字符的意思是stdout
.如果您添加一个-z
选项,那么 tar 会在将 tarball 写入 之前对其进行压缩stdout
,这在 99% 将 tarball 发送到远程计算机的所有用例中都是一个好主意。
在远程端,您可以使用 进行提取tar -x
。在您的示例中,您只能-z
在远程端选择。这根本不符合逻辑。两侧必须选择相同的压缩方式,即-z
两侧使用或两侧不使用。
这可能对你有用
tar -czf - ~/Documents/projects/myproject/dist/ | ssh [email protected] "tar -C ~/public_html/ -xzf -"
(免责声明:我没有尝试过。它可能包含错误。)
由于遥控器tar
应该从 读取 tarball stdin
,因此您也不要在这一侧提供文件名。
答案4
您正在尝试完成两件事:
- 将目录树复制到远程站点
- 压缩正在传输的数据
其他答案提到使用 rsync,它可以实现这两个目标(为 rsync 提供“-z”选项可以启用压缩)。
tar 是实现目标 #1 的好工具,并且通过命令行选项(如其他答案中给出的“z”标志),它也可以实现目标 #2。
SSH 连接本身也可用于满足您的压缩目标。 SSH 有一个压缩选项,默认情况下处于关闭状态,但可以在命令行或 ssh_config 文件中启用(请参阅https://linux.die.net/man/5/ssh_config)。启用压缩的 SSH 版本 2 相当于使用“gzip -6”压缩获得的压缩级别。
将所有这些选项组合在一起的好处在于,您可以调整管道以获得最佳结果。您必须进行试验,看看哪一种可以提供更好的性能*:在 SSH 连接中启用压缩,或在 tar/rsync 级别启用压缩。
Tar 可以使用不同的压缩选项(gzip、bzip2、lzma 等),并且使用 rsync 的“-z”选项将启用 gzip 压缩。您还可以在管道的两端添加单独的压缩/解压缩程序来调整压缩级别;以下是添加 bzip2 压缩,同时在 SSH 连接上显式禁用压缩的示例:
tar cf - ~/Documents/projects/myproject/dist/ | bzip2 -c -9 | ssh -o Compression=no [email protected] "bunzip2 -c | tar -C ~/public_html/ -xf -"
*为了衡量“性能”,您需要决定什么对您的应用程序最重要:CPU 负载、网络上的字节数、执行压缩所需的时间等。您可以调整管道并进行测量,以了解如何改变压缩级别以及在管道中应用压缩的位置会影响这些变量。
在管道中的多个位置启用压缩可能不会提高性能。