跳转至主要内容

开发容器

Overview / 规格 / 开发容器



文件同步的远程目录#

示例:

name: nocalhost-api
serviceType: deployment
containers:
- name: nocalhost-api
dev:
workDir: /home/nocalhost-dev

进入 DevMode 后,用户需要选择一个本地目录。或右键单击目标工作量并选择 Associate Local DIR 来主动关联一个本地目录。 本地选中的目录将与 DevMode 中容器的 workDir 同步。

workDir 默认为 /home/nocalhost-dev

workDir 注意事项

workDir 使用 emptyDir 在 容器中共享 ,所以 这个目录在开始时是空的



开发镜像#

示例:

name: nocalhost-api
serviceType: deployment
containers:
- name: nocalhost-api
dev:
image: codingcorp-docker.pkg.coding.net/nocalhost/dev-images/golang:zsh

DevImage 是 DevMode 的基础,可简单视为一个 “远程 Linux”。 如果你想要正确地编译和运行从本地同步的文件,你必须使用适当的 DevImage。 Nocalhost 提供多个官方 DevImage,如果你在进入 DevMode 之前没有配置此字段。 你需要选择或键入一个 DevImage 才能继续。

官方的 DevImage 没有什么特殊的魔改,就是一个普通的镜像。 除了各个语言的基本环境,如 Java 的 JRE、Maven 等,还内置了一些如 git、openssh-client、zsh、bash、net-tools、tmux 等基本软件。 如果官方的开发镜像不合适,你可以随意的定制自己的开发镜像。 DockerFile 位于 dev-container 中。

定制你的 DevImage

如果你定制了自己的开发镜像,请将它放置在一个你所使用的 K8s 集群可拉取到的仓库。



远程容器中的 Shell#

示例:

name: nocalhost-api
serviceType: deployment
containers:
- name: nocalhost-api
dev:
shell: /bin/zsh

可不进行配置,默认值是 zsh || bash || sh。 使用便捷易用的 Shell 往往能事半功倍,如带有自动补全、历史记录补全的 zsh。

当然,具体支持什么 Shell 依托于 DevImage 本身 如果你的 DevImage 不支持 zsh,这里即使配置了 zsh 也没有作用。 它会依次寻找 zsh、bash 以及 sh,直到找到可用的 Shell。



Dev 容器中的持久化#

示例:

name: nocalhost-api
serviceType: deployment
containers:
- name: nocalhost-api
dev:
persistentVolumeDirs:
- path: /the/path/you/want/to/persistent/in/container
capacity: 10Gi
- path: /other
capacity: 10Gi
storageClass: cbs

我们知道,K8s 容器中,如果没有对目录进行持久化,在容器停止或重启后,原先产生的数据将会丢失,例如已经同步上去的文件、编译产物、构建产物等等。 在开发容器中启用持久化,可以大大减少上述这些时间的损耗。

持久化包括两部分配置:

  • 一个是哪些目录需要被持久化。 可不进行配置,默认值为空。 path 表示需要在容器中持续保存的目录, Capacity 表示分配给此目录的空间。 persistentVolumeDirs 是一个用于配置多个 path/capacity 的数组。
  • storageClass 持久化需要 storageClass 的能力来提供支持 (kubectl get storageclass)。 如果你没有配置 storageClass,Nocalhost 将在集群中使用默认 storageClass 来创建 PVC。 如果你配置了 storageClass,PVC 将由相应的 storageClass 创建。
注意事项

capacity 需要符合 K8s 对资源限定的约定。



开发容器的资源的申请与限制#

示例:

name: nocalhost-api
serviceType: deployment
containers:
- name: nocalhost-api
dev:
resources:
limits:
memory: 4Gi
cpu: "1"
requests:
memory: 2Gi
cpu: "0.5"

Nocalhost 对开发容器的资源设置继承自原容器 如果原始容器中没有配置,且 namespace 中没有 limitranges (kubectl get limitranges) 开发容器将不受资源限制。

一般来说,在进入 DevMode 后,所使用资源的数量将超过原始镜像。 因此,原始容器的资源配置往往导致 DevMode 的失败,例如由于内存不足,OOM。 那么此时就需要通过配置 resource 来为开发镜像提供更多的资源。

注意事项

memorycpu 需要符合 K8s 对资源限定的约定。



Sidecar 镜像定制#

示例:

name: nocalhost-api
serviceType: deployment
containers:
- name: nocalhost-api
dev:
sidecarImage: nocalhost-docker.pkg.coding.net/nocalhost/public/nocalhost-sidecar:sshversion

sidecarImage 是进入开发模式所必须的镜像,用于代码同步、调试连接管理等。 sidecarImage 默认值是 docker.pkg.coding.net/nocalhost/public/nocalhost-sidecar:sshversion,不需要手动配置。

如果你的集群因为网络无法获取此镜像, 你可以拉取此镜像并将其推到你的集群可以访问的制品库,然后将其配置为这个新地址。

Patches#

示例:

name: nocalhost-api
serviceType: deployment
containers:
- name: nocalhost-api
dev:
patches:
- patch: '[{"op": "add","path":"/metadata/annotations/nocalhost-patch","value":"hello-world"}]'
type: json
- patch: '{"spec":{"template":{"spec":{"containers":[{"name":"nocalhost-dev","imagePullPolicy":"IfNotPresent","resources":{"limits":{"cpu":"2"}}}]}}}}'
- patch: '{"spec":{"template":{"spec":{"containers":[{"name":"nocalhost-sidecar","resources":{"limits":{"cpu":"2"}}}]}}}}'
type: strategic

patches 提供了类似于 kubectl patch 的功能。 你可以使用 patches 灵活地对进入 Nocalhost DevMode 的工作负载的 Spec 进行适当的修改。

其中:

  • type:为 patch 的类型。 可选值是 jsonmergestrategic,默认值是 strategic

  • patch:为 patch 的内容。

可以简单地理解为,type 配置项等同于 kubectl patch 命令的 --type 参数,patch 配置项等同于上述命令的 --patch 参数。 关于 kuebctl patch 命令的具体用法,可以参考使用 kubectl patch 更新 K8s API 对象

caution

Nocalhost 不会对 patch 的内容做任何的校验和限制,有可能会因为 patch 的内容不当导致 Nocalhost 进入 DevMode 失败, 所以请确保 patch 的正确性。