Coder中的Templates

Templates使用标准Terraform进行编写，并且把基础框架用作工作空间。（例如：aws_instance, kubernetes_pod, or both）。

在大多数情况下，小部分的使用者管理模板。然后其他的使用者从模板中部署他们的开发工作空间。

添加一个模板

# 创建一个本地文件夹存储模板
mkdir -p $HOME/coder/templates
cd $HOME/coder/templates

# 从模板中启动一个例子（初始化）
coder templates init

# 可选择的：修改模板
vim <模板名字>/main.tf

# 把模板增加到Coder部署中
coder templates <create/update> <模板名字>

个性化模板

提供的例子模板并不是用于支持所有使用情况的。我们需要在运行

coder templates init

或

coder templates pull

通过编辑Terraform代码来添加需要的特点。

模板中的概念

模板是使用标准Terraform写的，Coder Terraform Provider被用来定义工作空间的生命周期并且建立从资源到Coder 的连接。

接下来的是模板中的一些关键概念的总览。可以在 Coder Terraform provider docs中查看所有的模板选项。

资源Resource

如果一个Coder的代理被连接到了一个资源，用户就可以通过SSH或者网页应用程序连接直接连接到这个资源。

Coder代理agent

一旦一个Coder的工作空间被创造了，Coder代理会在资源（docker_container）和Coder之间建立一个连接，这样用户就能够从web UI或者CLI中连接到他们的工作空间。模板能够有多种代理去允许用户连接到他们空间中的多种资源。

资源必须下载并且启动Coder代理二进制文件来链接到Coder。这意味着资源必须能够访问Coder的URL。

Coder代理的初始脚本如下：

data "coder_workspace" "me" {
}

resource "coder_agent" "pod1" {
  os   = "linux"
  arch = "amd64"
}

resource "kubernetes_pod" "pod1" {
  spec {
    ...
    container {
      command = ["sh", "-c", coder_agent.pod1.init_script]
      env {
        name  = "CODER_AGENT_TOKEN"
        value = coder_agent.dev.token
      }
    }
  }
}

参数

模板通常包含参数。在Terraform中，这些参数通过variable块来定义的。有两种参数：

• 管理、模板范围的参数是在模板被创造或者更新时设立的。这些值通常是云配置的，例如VPC，同时要在模板的代码中使用sensitive = true进行注释。
• 用户、工作空间参数是在用户创造工作空间时设立的。这些值通常是个性化设置，例如地区偏好或者工作空间图像。

下面的模板样例使用管理员和用户参数去让开发者能从任何图像中建立工作空间，只要它处在恰当的注册表。

variable "image_registry_url" {
  description = "The image registry developers can sele"
  default     = "artifactory1.organization.com`
  sensitive   = true # admin (template-wide) parameter
}

variable "docker_image_name" {
  description = "The image your workspace will start from"
  default     = "base_image"
  sensitive   = false # user (workspace) parameter
}

resource "docker_image" "workspace" {
  # ... other config
  name = "${var.image_registry_url}/${var.docker_image_name}"
}

永久的和短暂的资源

可以使用工作空间的状态来确保在Coder罐中的一些资源是永久的，而其他的是短暂的。

开始、停止

Coder工作空间能够被开始和停止。这通常是用作节省云端花费或者强制实施暂时工作流。当一个工作空间被启动或者被停止，Coder 服务器运行一个额外的terraform apply通知Coder提供器：工作空间有一个新的转换状态。

下面的模板例子有一个永久的资源（docker图标），以及一个暂时的资源（docker volume）。

data "coder_workspace" "me" {
}

resource "docker_volume" "home_volume" {
  # persistent resource (remains a workspace is stopped)
  count = 1
  name  = "coder-${data.coder_workspace.me.owner}-${data.coder_workspace.me.name}-root"
}

resource "docker_container" "workspace" {
  # ephemeral resource (deleted when workspace is stopped, created when started)
  count = data.coder_workspace.me.start_count # 0 (stopped), 1 (started)
  volumes {
    container_path = "/home/coder/"
    volume_name    = docker_volume.home_volume.name
    read_only      = false
  }
  # ... other config
}

在重建工作空间时使用更新后的图标

为了确保Coder在重建一个工作空间时使用更新的图标，管理者最好在模板中更新tag。（例如：my-image:v0.4.2 -> my-image:v0.4.3）或者digest（my-image@sha256:[digest] -> my-image@sha256:[new_digest]）。

可选择地，如果你想从Coder中等待更长的启动次数，你可以设置imagePullPolicy为Always在Terraform 模板中。在设置时，如果有必要的话，Coder会在每一个build和update中检查image:tag。

resource "kubernetes_pod" "podName" {
    spec {
        container {
            image_pull_policy = "Always"
        }
    }
}

删除工作空间

当一个工作空间被删除，Coder服务器最终会运行一个terraform destroy来删除所有和这个工作空间有关联的资源。

Terraform的 prevent-destroy and ignore-changes meta-arguments可以被用作处理意外的数据丢失。

Coder的应用

默认情况下，所有的模板都允许开发者通过SSH或者网页终端进行连接。看Configuring Web IDEs可以知道如何给予用户对于额外的网页应用的访问。

创建以及故障排除的模板

利用Coder可以使用任何Terraform的资源。当在模板上工作时，可以参考以下的资源：

• 本篇文档
• example templates code
• Coder Terraform provider documentation

通常来说，可能会进入代理不能够连接的场景。这意味着开始脚本错误。

$ coder ssh myworkspace
Waiting for [agent] to connect...

尽管故障排除步骤随着资源进行变化，这里有一些通常的最好的操作：

• 确保资源安装了curl
• 确保资源能够访问Coder URL
• 手动连接到资源（例如：docker exec or AWS console）Coder代理的logs通常存储在/var/log/coder-agent.log

改变管理

运行coder templates update