Gitpod和Github Codespaces都是基于Visual Studio Code的在线代码编辑器,带有附加的 Linux 开发环境服务器,用于运行终端任务;简单来说,两者都是基于云的代码编辑器,并且可以免费使用。

注意:Github Codespaces 仅在 beta 期间免费供个人使用,未来可能会发生变化,对于 Github 团队和组织,有一个现收现付的定价设置。要访问个人 Github 代码空间,您需要注册beta.

本文详细介绍了我使用 Gitpod 和 Github Codespaces 的个人经历,这些是我的观点,并非绝对的事实,您的经历可能与我的不同。

为什么选择在线IDE?

我对 Gitpod 有更多的经验,因为它比 Github Codespaces 存在的时间要长得多,但是,我在在线代码编辑器和 IDE 方面的经验要长得多。

我第一次使用在线代码编辑器是 2016 年的Cloud9(这是在 Cloud9 被亚马逊收购并成为 AWS Cloud9 之前)。当时 Cloud9 是一项免费服务并且随时可供个人使用,我非常喜欢该服务的便利性,以至于我在短时间内完全从本地编程切换到在线编程。所有好事都结束了,到 2019 年 12 月,Cloud9 宣布他们将关闭其独立服务,取而代之的是,Cloud9 将作为 AWS 的一部分提供,因此,就在我失去对 Cloud9 的访问权限之前,我开始寻找替代方案, 范围从Eclipse Che,Red Hat CodeReady Workspaces,Codeanywhere到StackBlitz, 在所有替代方案中,最胜任的是 Gitpod。

在线 vscode 革命

我寻找替代品的主要原因是当时我正试图使用 Chromebook 来完成我的所有工作。当我发现 Gitpod 时,我喜欢它的一般用户体验,它类似于 vscode,但有一些额外的附加功能在在线环境中更有意义,例如能够在开发时打开网站的小预览等等......另外,在线编辑器是在 Chromebook 上编码的唯一方法(现在已经改变。Chrome OS 现在支持 Linux 作为子系统),所以,🤷u200d♂️。

Gitpod 与代码空间

Gitpod 自己已经写了一篇关于他们对 Github Codespaces 的好处的文章,你可以在这里找到它gitpod.io/gitpod-vs-github-codespaces。我将简要概述两者之间的差异,注意它们夸大了它们的差异和好处的地方,解释如何充分利用每项服务,然后给出我对这两种服务的个人看法。

Gitpod 提出的第一点是它是“瞬间就绪”

Gitpod 通过持续为您的项目预先构建工作区来消除冗长的初始化和构建时间。因此,它允许您随时从任何上下文立即开始编码或调试。

这在技术上是正确的,至少在某种程度上是正确的。 Gitpod 的实际构建过程比 Github Codespaces 花费_slightly_ 长,或者至少感觉是这样,我没有,也不打算提供任何确切的经验性能数据,因为这两种服务都在不断变化,事实上,在我写这篇文章的前一周,Github 引入了github.dev。

FYI(供您参考):github.dev是一个在线的基于 vscode 的网络编辑器,它和 Github Codespaces 的区别在于 Codespaces 带有一个终端,而这个没有

在 Gitpod 的防御中,它可以预构建一个与 Github Codespaces 不同的工作空间,因此您可以立即开始编码,而无需等待漫长的构建过程完成。

Gitpod 提出的另一点是它有“3x more power”,

通过利用容器和 Kubernetes 等云技术,Gitpod 通过在共享的高性能云服务器上运行的可扩展工作空间实现一流的资源效率。

这可能是他们提出的最重要的一点,因为我无法验证他们的服务器配置,也无法验证他们用于测试的计划最终在实际使用中更便宜,特别是因为 Github 只发布了定价方案Github Teams 和 Enterprise,不得用于个人用途。

截至 2021 年 8 月 30 日,Gitpod 有 4 个计划*,它们是,

计划

价格(每用户/月)

特征

开源

自由的

50 小时/月 + 私人和公共回购

个人的

9 美元

100 小时/月 + 4 个并行工作区 + 30 分钟超时

专业的

25 美元

全部在个人 + 8 个并行工作区 + 无限小时 + 团队

释放

39 美元

全部在专业版 + 16 个并行工作区 + 1 小时超时 + 3 小时超时提升

对于 Github Codespaces,定价* 是,

产品

库存单位

测量单位

价格

代码空间计算

2芯

1小时

0.18 美元

4芯

1小时

0.36 美元

8芯

1小时

0.72 美元

16芯

1小时

1.44 美元

32芯

1小时

2.88 美元

代码空间存储

贮存

1 GB/月

0.07 美元

*这两种服务的定价方案中都包含更多详细信息,我建议您仔细阅读这些信息以获取详细和最新的信息。

注意: 您必须为您的 Codespaces 存储支付上述工作空间存在的时间,这包括您没有积极使用工作空间的时间。据我所知,Gitpod 不需要支付存储费用。

来源:Gitpod、GitHub 代码空间。

在 Gitpod 制作的最后一点中,他们以表格形式列出了他们提供的一些好处,我坦率地说,他们遗漏了很多细节,所以,我会以实物形式回答更详细的方式。

Gitpod

Github 代码空间

细节

定价(托管)

开源免费

$$$

同样,这是不确定的,因为它得出的结论是 Gitpod 的价格更便宜,这不是很准确,而且相当具有误导性

执照

开源

所有权

这就是 Gitpod 获胜的地方,他们的代码实际上是open source,实际上他们的扩展商店使用开源OpenVSX 扩展商店,但是,OpenVSX 商店最终既是好处也是坏处.

GitHub 集成

是的

是的

Gitpod 对 Github 有很好的支持,但 Codespaces 有更好的集成。 Gitpod 需要Open in Gitpod 链接或Gitpod 扩展,但 Github Codespaces 可以直接使用,单击 Github 上的任何绿色代码下拉菜单,它只会打开 Codespaces。

GITLAB 集成

是的

不

准确的

位桶集成

是的

不

准确的

GCP 上的自托管

是的

不

准确的

AWS 上的自托管

是的

不

准确的

Kubernetes 上的自托管

是的

不

准确的

预建

是的

不

准确的

快照

是的

不

假设它是准确的。在 Github Codespaces 测试版中,您不能共享工作空间的快照,本质上,每个用户都被迫从头开始构建每个存储库,以用于他们的用例。至少据我所知,我不确定此限制是否适用于 Github 团队和/或组织。

VS 代码扩展

是的*

是的

Gitpod 使用 OpenVSX 存储,问题是 OpenVSX 存储最终对 Gitpod 既有利又不利。 VS Code 是开源的,但它的 store 是闭源的,所以Eclipse创建了Open VSX store,一个开源的替代品,问题是 OpenVSX store 中缺少一堆扩展,范围从Github Copilot到Live Share,甚至还有一些您期望可用的开源扩展。在这种情况下,我认为 Github Codespaces 具有更好的扩展存储,因为它直接使用本地安装 VS Code 将使用的相同扩展存储。

IPAD 支持

是的

是的

准确的

虚拟桌面 (VNC)

是的

是的

准确的

多IDE支持

是的*

不

我_猜_这是准确的。 Gitpod 允许您将他们的服务基础从 VS Code 更改为Theia(VS Code 的完全开源变体),我个人发现Theia与 VS Code 相比低于标准,所以,这并不是一个真正的功能这将在您使用 Gitpod 或 Github 代码空间时增加或删除您的体验。

工作区设置

Gitpod 和 Github Codespaces 都有基于 Docker 的配置文件,用于配置你的整个环境。在 Gitpod 上,他们的配置系统使用一个.gitpod.yml文件来存储您的工作区配置信息和一个.gitpod.Dockerfile文件,该文件设置一个 docker 映像,您可以使用它来运行您的工作区。默认情况下,Gitpod 使用标准 docker 映像作为工作区的基础,标准映像具有开发人员所需的大多数默认工具和程序,此外,您还可以在其上构建以添加一些小的附加功能。

.gitpod.yml文件存储基本配置信息,范围从开放端口到安装后脚本。您的基本.gitpod.yml文件如下所示:

# Commands to start on workspace startup
tasks:
  - init: yarn install
    command: yarn build
# Ports to expose on workspace startup
ports:
  - port: 8000
    onOpen: open-preview

进入全屏模式 退出全屏模式

对于我使用 Gitpod 的大多数项目,我设置了一个像这样的.gitpod.yml文件

# .gitpod.yml
image:
  file: .gitpod.Dockerfile

# List the ports you want to expose and what to do when they are served. See https://www.gitpod.io/docs/43_config_ports/
ports:
  - port: 3000
    onOpen: open-preview
  - port: 3001
    onOpen: ignore

github:
  prebuilds:
    # enable for the master/default branch (defaults to true)
    master: true
    # enable for all branches in this repo (defaults to false)
    branches: true
    # enable for pull requests coming from this repo (defaults to true)
    pullRequests: true
    # enable for pull requests coming from forks (defaults to false)
    pullRequestsFromForks: true
    # add a "Review in Gitpod" button as a comment to pull requests (defaults to true)
    addComment: true
    # add a "Review in Gitpod" button to pull requests (defaults to false)
    addBadge: false
    # add a label once the prebuild is ready to pull requests (defaults to false)
    addLabel: prebuilt-in-gitpod

# List the start up tasks. You can start them in parallel in multiple terminals. See https://www.gitpod.io/docs/44_config_start_tasks/
tasks:
  - init: >
      npm install -g pnpm &&
      pnpm install -g ultra-runner &&
      pnpm install
    command: >
      npm install -g pnpm &&
      pnpm install -g ultra-runner &&
      pnpm build

进入全屏模式 退出全屏模式

Gitpod 预构建部分为每个分支设置预构建,并拉取请求,并留下带有预构建链接的评论,查看 Gitpod 预构建](https://www.gitpod.io/docs/prebuilds)的[文档以了解更多信息。

但是,有趣的是在任务部分。init任务在工作区启动时运行一次,command任务在工作区启动时运行,然后在每次工作区重新启动时运行。

真正的问题是init任务即使它在启动时运行,也不会存储任何全局安装的包,据我所知,这是因为每个终端环境都基于 Gitpod docker 映像,如基本上强制新创建的终端使用 Gitpod docker 镜像,我建议通读Gitpod 的文档关于此事。

.gitpod.Dockerfile是直接为您提供管理员访问权限的文件,使您能够在工作区安装/执行任何您想做的事情。根据我的经验,您很可能不需要在这里更改任何内容,除了VNC之外,即便如此,文档也非常清楚。

# .gitpod.Dockerfile
FROM gitpod/workspace-full:latest

# Install custom tools, runtime, etc. using apt-get
# For example, the command below would install "bastet" - a command-line tetris clone:
#
# RUN sudo apt-get -q update && 
#     sudo apt-get install -yq bastet && 
#     sudo rm -rf /var/lib/apt/lists/*
#
# More information: https://www.gitpod.io/docs/config-docker/

进入全屏模式 退出全屏模式

另一方面,为 Github Codespaces 设置工作空间是动手操作。选择一个默认容器很容易*,您只需遵循 VS Code](https://code.visualstudio.com/docs/remote/containers)上的[文档,真正的问题是 Github Codespaces 的设置非常庞大。

对于 Codespaces,您需要创建一个.devcontainer.json文件并将其存储在.devcontainer/文件夹中。.devcontainer.json文件是一个 json 文件,其中包含设置工作区所需的信息。.devcontainer.json文件如下所示:

// For format details, see https://aka.ms/devcontainer.json. For config options, see the README at:
// https://github.com/microsoft/vscode-dev-containers/tree/v0.162.0/containers/typescript-node
{
  "name": "Node.js & TypeScript",
  "build": {
    "dockerfile": "Dockerfile",
    // Update 'VARIANT' to pick a Node version: 10, 12, 14
    "args": {
      "VARIANT": "16"
    }
  },

  // Set *default* container specific settings.json values on container create.
  "settings": {
    "npm.packageManager": "pnpm"
  },

  // Add the IDs of extensions you want to be installed when the container is created.
  "extensions": [
    "bierner.jsdoc-markdown-highlighting",
    "yzhang.markdown-all-in-one",
    "shd101wyy.markdown-preview-enhanced",
    "visualstudioexptteam.vscodeintellicode"
  ],

  // Use 'forwardPorts' to make a list of ports inside the container available locally.
  "forwardPorts": [3000],

  // Use 'postCreateCommand' to run commands after the container is created.
  "postCreateCommand": "pnpm install",

  // Comment out connect as root instead. More info: https://aka.ms/vscode-remote/containers/non-root.
  "remoteUser": "node"
}

进入全屏模式 退出全屏模式

您还需要创建一个Dockerfile存储在.devcontainer/文件夹中。Dockerfile包含 docker 信息,因此您可以在此处设置工作区所需的任何配置,如下所示:

# See here for image contents: https://github.com/microsoft/vscode-dev-containers/tree/v0.187.0/containers/typescript-node/.devcontainer/base.Dockerfile

# [Choice] Node.js version: 16, 14, 12
ARG VARIANT="16-buster"
FROM mcr.microsoft.com/vscode/devcontainers/typescript-node:0-${VARIANT}

# [Optional] Uncomment this section to install additional OS packages.
# RUN apt-get update && export DEBIAN_FRONTEND=noninteractive \
#     && apt-get -y install --no-install-recommends <your-package-list-here>

# [Optional] Uncomment if you want to install an additional version of node using nvm
# ARG EXTRA_NODE_VERSION=10
# RUN su node -c "source /usr/local/share/nvm/nvm.sh && nvm install ${EXTRA_NODE_VERSION}"

# [Optional] Uncomment if you want to install more global node packages
# RUN su node -c "npm install -g <your-package-list -here>"

RUN su node -c "npm install -g pnpm"

进入全屏模式 退出全屏模式

此示例基于我的 Github 项目之一okikio/native,这是为您自己的项目设置工作区的良好起点。

注意:Github Codespaces 配置可能会让您失望的主要事情是您无法在 docker 配置中安装本地包(我说的是node_modules)。当然,这可能是我对 Docker 缺乏经验,但到目前为止,我一直无法让它正常工作。

_FYI:Gitpod 团队计划添加对 Github Codespacesdevcontainer.json格式的支持,因此,将来,您可能能够轻松地在 Github Codespaces 和 Gitpod 之间切换而不会费力。 _

合作

我个人没有在 Gitpod 或 Github Codespaces 上与任何人合作过,但每项服务都提供了一种与他人合作的方式。一方面,Gitpod 允许您与他人共享工作空间,另一方面,Github Codespaces 允许您使用 Live Share 在同一个项目上进行协作。

我觉得 Live Share 是一个更好的协作工具,当然使用 Gitpod 你可以与其他人共享工作空间,但是使用 Codespaces,你可以在同一个项目上工作,而不会跳过一个节拍,从技术上讲,它与与其他人共享工作空间非常相似开发人员,所以...我将把最终的判断留给你。

文档

Github Codespaces 有非常详细的文档,但它的内容非常密集并且有点压倒性。另一方面,Gitpod 的文档更简单,更侧重于基础知识,这是开始使用在线编辑器的好方法。 Github Codespaces 基本上假设您已经非常有经验,而 Gitpod 假设您是在线代码编辑器世界的新手,并在此基础上慢慢构建。

VNC

Gitpod 和 Github Codespaces 都支持 VNC。根据我的经验,两者在 VNC 的工作方式方面大致相同,但是,使用 VNC 设置 Gitpod 更容易。

虚拟网络计算 (VNC) 是一个图形桌面共享系统,它使用远程帧缓冲协议 (RFB) 来远程控制另一台计算机。它将键盘和鼠标输入从一台计算机传输到另一台计算机,通过网络传递图形屏幕更新。阅读更多关于维基百科

不久前,我尝试尝试是否可以在我的 Windows 笔记本电脑上设置Webkit(Safari 的浏览器引擎)......我失败了,我不知道如何在 Windows 上构建 Webkit 源代码(它非常困难),所以,我尝试了下一个最好的东西,“云”,它也失败了,但有趣的是,原因完全不同。

对于这个实验,我使用了 Github Codespaces(在之前的实验中我已经尝试过将 Gitpod 与 VNC 一起使用,所以,我想这次我会尝试使用 Github Codespaces)。我能够使 VNC 正常工作,但无法设置 Webkit,因为 Docker 在 Webkit 使用的一些库方面存在问题。在我放弃之前,我尝试了大约 16 个小时。我最终找到了另一种选择,Playwright。

Playwright是一个端到端的框架,用于在多个浏览器上测试网络应用程序,它是测试网络应用程序的好工具。

在试用 Playwright 时,我发现它只能在 Windows 上运行(这是因为 Webkit 和 Docker 的库问题)。

让我们回到最初的话题,VNC。在我的实验中,我发现在 Github Codespaces 上设置 VNC 很困难,而且上述工作空间的构建过程很长,我实际上是计时的,使用 VNC 的 Github Codespaces 的构建过程大约需要 6 分钟,而在 Gitpod 上它要快得多(我不记得确切花了多长时间,但我记得不到 5 分钟),此外,Gitpod 的文档更容易消化并且刚刚开始。

对于 Gitpod 上的 VNC,请查看gitpod.io/blog/native-ui-with-vnc。

对于 Github 代码空间上的 VNC,请查看github.com/microsoft/vscode-dev-containers/blob/main/script-library/docs/desktop-lite.md。

烦恼

在 Gitpod 工作区中,每个终端都是从最初的 docker 镜像构建的,理论上,这听起来很棒,但是,根据我的经验,最终解决它是一个巨大的痛苦。比如我发现如果你用nvm(节点版本管理器)安装新版本的node,比如说v16替换Gitpod标准镜像节点,v14,你创建的每一个新终端都会使用node set的版本在标准图像中,这似乎是一个非常小的问题,但它可能会导致一堆问题,并且随着时间的推移会让您非常恼火,而且它只会减慢您的开发速度。

互联网问题

通过使用 Gitpod 和 Github Codespaces,您会变得依赖互联网,如果您无法访问互联网,则无法使用这两种服务。对于大多数开发人员来说,这并不是一个真正的问题,因为在大多数情况下,他们需要访问互联网来提交对 Github、Bitbucket 等的更改......

对于您无法访问 Internet 的情况,假设您的 ISP 在某个地方出现问题,并且您在几天内无法访问(我是根据个人经验在这里发言),那么您将根本无法进行任何编程。

对于那些担心互联网连接的人来说,最好的办法是确保您始终拥有一个本地副本,其中已经安装了所有工具和依赖项,因此,当您无法访问时,您至少可以取得一些进展。

对于您可能失去连接一两分钟的小实例,Github Codespaces 和 Gitpod 会保留所有打开文件的本地副本,并在重新建立连接时将它们合并到在线副本中,所以不用担心。

警告:需要注意的一点是,如果您在使用 Gitpod 时长时间无法访问互联网,您可能会失去工作空间,必须重新开始。这实际上不适用于 Github Codespaces,因为您必须主动删除一个工作区,Codespaces 会关闭一个工作区,但它不会为您删除它。

其他

Gitpod 和 Github Codespaces 之间的一个细微差别是 Github Codespaces 支持使用您本地安装的 VS Code 版本来使用您熟悉和喜爱的 VS Code 继续开发,以及将远程端口转发到 localhost 端口等等,所有这些都是 Github Codespaces允许开发人员在与本地开发非常相似的环境中进行开发,但资源使用较少(因为大部分处理都发生在远程服务器上),并且对互联网的依赖程度稍高,请阅读Github 的文档以了解更多信息。

Gitpod 支持类似的东西,如果您将 Gitpod 应用程序安装为 PWA(据我所知,只有 Edge 允许您强制将网站安装为应用程序),然后您可以将服务器上的远程端口转发到您计算机的本地主机端口,在Gitpod 的文档上阅读更多相关信息。

FYI:Gitpod 正在努力支持local VS Code,所以,当你阅读这篇文章时,它可能已经上线了。

我不知道这对开发人员有多重要,但 Github Codespaces 会自动在 VS Code 和自身之间同步设置。要在 Gitpod 中使用此功能,您需要对 VS Code 安装进行一些设置,通读 Gitpod](https://github.com/gitpod-io/gitpod/issues/3733#issuecomment-813917147)打开的[问题以了解更多信息。

何时使用 Github 代码空间?

Github Codespaces 是一个易于使用且可靠的 VS Code 服务,它与 Github 的集成非常方便,并且很难正确量化,它的扩展支持是顶级的,它的编码体验很难传递,特别是对于已经使用 Github 的其他服务。 Github Codespaces 非常适合需要高资源工作空间且无需在其他平台上自托管的开发人员。

Github Codespaces 很好,但它并不是适合所有人的完美解决方案。 Github 的计费模式有点费劲,因为工作空间存储不是免费的,所以,如果你想专业地使用 Github Codespaces,你最终可能会在无意中付出相当多的费用,另外,取决于你使用每个 Github Codespace 的小时数,你的每月的账单可能是一个相当痛苦的药丸。

什么时候用Gitpod?

Gitpod 是一个易于使用且非常可靠的 VS Code 服务,它的开源设计允许您参与其中,甚至可以在问题出现时进行修复。 Gitpod 非常适合开源项目、需要可靠且一致的月度定价方案的项目、寻找非专有 VS Code 工作区的开发人员或想要使用 Bitbucket、Gitlab 等的开发人员。和/或使用AWS、GCP 等上的自托管选项... 真的 Gitpod 很棒,原因与 Github Codespaces 相同,只是它与 Github 的集成少了一点,这使得 Github Codespaces 与 Github 一起使用时体验更好。

结论

这两种服务都很棒,因为它们通过 Web 为开发人员带来了一致且可靠的 VS Code 体验。然而,它们并不是每个人的完美解决方案,因为它们都有自己的起起落落。

我已经陈述了我对这两种服务的个人体验,我建议使用您认为最适合您的一种。就个人而言,我经常在两种服务之间切换,但是,我更喜欢 Github Codespaces。我发现它对我来说是最好的选择,因为它可以同步我的设置,支持本地 VS Code,并且与 Github 和 VS Code 扩展有很好的集成(我什至可以在 Github Codespaces 中使用Github Copilot)。

**注:**我其实是用Github Codespaces 和Github Copilot一起写这篇文章的。当我说它是一个优秀的写作伴侣时,相信我,它几乎就像 Gmail 自动完成功能,但更好,因为它还可以识别代码语法,并且可以相当有效地应用它们。

为了对这两种服务进行更中立和客观的比较,我建议阅读Nader Dabit 在 FreeCodeCamp 上比较两者的文章。

本文的想法来自推文byNik Molnar @nikmd23和Stephan Meijer @meijer_s。

照片由Okiki Ojo拍摄,您可以在Dropbox上找到图片。

最初发表于blog.okikio.dev

此外,发表于Hackernoon

# github # javascript # vscode # docker
Logo
云原生

云原生社区为您提供最前沿的新闻资讯和知识内容

更多推荐

cover

本地Docker部署Navidrome音乐服务器与远程访问听歌详细教程

avatar 云原生
cover

【docker系列】docker删除指定容器

avatar 云原生
cover

【Docker系列】制作基础镜像

avatar 云原生