修复VALUES值与默认值恢复

Choerodon User Guide-Continuous Delivery
#1

  • Choerodon平台版本：0.24.0

  • 运行环境：自主搭建

  • 问题描述：

    请尽量详细的描述您遇到的问题，以便我们能更快速的提供解决办法。

    如：部署一个应用后，修改VALUE值，将某个值改成非默认值（chart中values.yaml里不同的值），此时gitops的C7NRlease会记录这个值，并应用到集群的部署上。但是如果想再次改会默认值，发现gitops的C7NRlease不会记录这个变量值（因为跟chat中values.yaml给的值相同），导致无法将集群中的部署值修改回默认

  • 执行的操作：

    1. 发布一个应用，其中有一个环境变量SPRING_PROFILES_ACTIVE，值为test
    2. 修改这个值为dev
    3. 检查gitops的文件，发现以下内容
  values: |-
    env:
      open:
        SPRING_PROFILES_ACTIVE: dev
  1. 观察部署，应用了该环境变量
  2. 再次修改这个变量为test（chart包中values.yaml对应的变量的值也是test，即恢复默认值）
  3. 观察gitops文件，上面的内容被删除。 （恢复默认值）
  4. 观察部署， 不会修改该环境变量为默认的test，依然保持为dev。
  • 报错信息(请尽量使用代码块或系统截图的形式展现)：

无法修改该变量的值为默认的test。

  • 建议：

    helm install之后，在upgrade的话，只要是变动的值都需要给出。即对比上一次部署的value而不是初始value值。

#2

我没有复现出这个问题。

等我有空了我再看看整个流程的代码逻辑。

#3

同样遇到了这个问题。
首次部署的时候，初始值
env:
open:
TEST_ENV: test
然后修改values.yaml 将test改为任意值。都可以成功部署。但是如果想将TEST_ENV重新赋值test，则无法改动成功。
就和上面老哥说的一样，似乎修改values。对比差异，对比的不是上一次成功部署的values.yaml文件，
而是对比的是第一次部署时候的values.yaml。
换句话说是不是需要在部署成功后，将values.yaml里的值，回写进数据库版本。

#4

具体复现流程如下，首次部署时，增加环境变量TEST_ENV: test。
然后在界面上点击修改values 改为TEST_ENV: dev。确定部署成功。
此时应该该服务应该有2个部署记录了。
然后再次修改values为TEST_ENV: test 。会发现提示部署成功，但是去POD中查看环境变量，依旧为dev。
你后面修改values 只要不是将TEST_ENV设置成test ，都会生效，唯独对于初始值，不会生效。

#5

好的，这个问题我看看

#6

再详细一点补充说明，具体读取的表是devops_app_service_version和devops_app_service_version_value
devops_app_service_version_value中的value值应该是当该服务新增某个实例版本的时候，就会去读取该版本的chart values.yaml然后存入其中。
上面说的对比也是对比的devops_app_service_version_value中的value值。
目前治标不治本的方式是修改数据库中的value值(例如改为TEST_ENV:testnononono)。
如果偏好一点的方式是不是应该，每当当部署成功时，去修改回写该版本的values值呢。这样每次比较的时候都是上一次成功部署的值了。

#7

我这边测试没有复现问题

#8

这个代码上也可以体现出来，AppServiceInstanceServiceImpl中的getC7NHelmRelease中的getReplaceResult(versionValue, deployValue).getDeltaYaml().trim()。
其中versionValue取自devops_app_service_version_value 该记录是在gitlab-ci发现新版本后就添加了的记录，只新增不修改。每次都和当前版本的初始values进行对比，肯定会有问题啊。

#9

你好，并没有复现这个问题，我是这样操作的：

  1. 添加一个在版本的 values 中不存在的 key：env: test
  2. 修改实例，改为 env: uat
  3. 再次修改，改为 env: test

这三步操作之后，实例是正常的

另外，关于你说的 getC7NHelmRelease 方法，这里是将每次部署或者修改values页面提交的数据和版本的values进行对比，只要你部署的页面提交时候，有这个key，而版本values没有这个key，最终这个key会存在的。这个逻辑是正常的。

#10

第一步不是说版本的values中不存在。而是服务的初始values.yaml里就有一个TEST_ENV: test。

#11

1.创建一个values.yaml里有env:
open:
TEST_ENV: test
的服务。
首次创建服务，gitlab-ci运行完后，devops_app_service_version和devops_app_service_version_value表中就有了对应的数据。value值为TEST_ENV: test。
2.部署该服务。此时该服务的环境变量TEST_ENV: test。
3.还是该实例，修改values，TEST_ENV: uat。部署。此时会对比values和devops_app_service_version_value中的差异为TEST_ENV: test 变更为TEST_ENV: uat。
服务的环境变量变更为TEST_ENV: uat。

4.还是该实例，修改values，TEST_ENV: test。部署。此时会对比values和devops_app_service_version_value中的不存在差异，（原：TEST_ENV: test ，现：TEST_ENV: test。）。则不修改环境变量。部署完后发现环境变量依旧为uat

#12

你可以到集群中用 helm get values 这个命令看看对应实例的 helm release 使用的 values 中这个 TEST_ENV 的值是 uat 还是 test。

#13

我通过腾讯云的集群管理查看yaml文件的，确实是uat。也通过lens工具查看过环境变量，确实是uat。
然后我认为你没有复现到这个问题，上面你说的“只要你部署的页面提交时候，有这个key，而版本values没有这个key，最终这个key会存在的。”
这个key是从版本一开始就有的。
如果方便的话可以加一下我V。15821602409

#14

我理解你的意思了，但是我认为，可能是 chart 里面的 deployment 文件有问题。你不要看 deployment 之类的文件，单纯的用 helm get values 看 helm release 的 values。这里面也是 uat 吗？

#15

以 SERVER_PORT 为例，我并没有复现
chart中的默认值：
image

猪齿鱼的修改values界面：
image

改后的值：

image
image735×73 5.54 KB

再改回原始值进容器看了：

image
image765×180 18 KB

#16

请问能否留个VX呢，我这边方便截图。

#17

可以论坛私信我

#18

如果只改动了一个配置的时候，想改回去会有这个问题。如果改动了超过一个配置的话，要将其中一个改回默认是可以的。这个问题我们看看怎么修复。

#19

好的，收到。