@huangmingyou 是的，还支持从远程 http 服务拉取配置，以及 git ssh 仓库抽取配置（ renderer 文档部分）

同样的痛点, 我一直觉得 kustomize 的路走错了, helm 更适合需要大量动态调整的复杂部署 (可能是我看问题的高度不够?)

为了解决这个问题, 外加需要管理多个仓库里的 yaml 配置并且实现重用以便统一结果, 我自己开发了一个工具 dukkha, 但是目前还没有实际用到生产环境中 (项目地址: https://github.com/arhat-dev/dukkha )

对应到你的需求可以用 dukkha 这么管理:

首先给不同环境创建 host-alias.yml 文件

production 环境: inventory/production/host-alias.yml

```yaml
- hostnames:
- production-foo
ip: ...
```

dev 环境: inventory/dev/host-alias.yml

```yaml
- hostnames:
- dev-foo
ip: ...
```

```yaml
apiVersion: v1
kind: Pod
spec:
hostAliases@env|file: inventory/${ENVIRONMENT}/host-alias.yml
```

把目录结构建好, 然后在不同环境里面设置好 ENVIRONMENT 变量 (production/dev) 即可使用 `dukkha render` 进行渲染

有进一步了解需求的话, 可以看项目里的文档, 应该是够用的

另外如果想深入讨论相关内容的, 欢迎邮件到 aW5xdWlyaWVzQGFyaGF0LnNvbHV0aW9ucw== , 内容需要注明 v2 用户名以及一个可交叉验证身份的第三方平台链接 (如 github 用户链接)

@thxgod
@fkdtz
@zjccc

docker 直接跑 amd64 的话使用 qemu-static 模拟运行的, 如果主要做 amd64 开发克意考虑用 lima + qemu-system 装 amd64 虚拟机, 个人体验是 qemu-static 经常性出错, qemu-system + hvf 目前还没出过问题

fyi: lima: https://github.com/lima-vm/lima

@taobibi @Tianao @keith1126

如 @keith1126 #3 所说, 主要问题是沟通和安全意识问题, 所以重点在于把敏感操作转移到一个可靠且有判断能力的人手里 (一般就是老人自己的子女), 而且不能让老人知悉真正的登录信息以及支付密码。

我有一个方案是为了代理 oauth2.0 登录流程 (主要是 keycloak) 做的, 感觉可以迁移到这种应用场景, 个人感觉不适合在公共频道讨论, 三位要是有兴趣讨论的话欢迎与我邮件交流

aW5xdWlyaWVzQGFyaGF0LnNvbHV0aW9ucw==

(同时为了安全需要, 需要在邮件中提供能 V2EX 用户名以及能与 V2EX 用户交叉认证第三方平台链接)

有同样的需求，我的解决方案是把单个 secret item 通过 fuse 挂载成一个独立文件，应用程序读取文件会触发授权请求，请求带有 uid, pid, 进程名以及进程调用链等，通过自定义 webhook 服务进行授权，成功授权才能读取文件内容。

@jeffreystoke 补充一下，这个办法并不可靠，ref 里面也提到了部分实现没有遵循这个标准，因为 ietf 虽然在 RFC 里面写了这个标准，但是又不推荐服务端这么实现，所以现实情况就是用 tls 1.3 基本不可能获得服务器时间，tls 1.2 有一定可能性，tls1.1 可能性极高，老旧的 ssl 应该完全可行。

Ref: https://www.acunetix.com/blog/articles/establishing-tls-ssl-connection-part-5/

如果服务器有 tls 服务的话可以通过 tls handshake 过程中的 serverhello 消息推断，random string 的前四个字节是 unix timestamp 。

Ref: https://security.stackexchange.com/questions/71364/tls-reliance-on-system-time#71368

@gjquoiai 感谢推荐，正是我想要的，和这个软件可以配合

我现在是用 git-secret 加密 helm values 文件，用 credentialfs 保存 git-secret 的 seed，大量私密且需要频繁改动的文件这样操作似乎更方便一点

@libook 是的，的确可以把这个 fuse 理解成现有文件系统的 hook，唯一的细节差异在于不会每次都去 bitwarden 里面查询，而是缓存在内存中，也就是为什么开 issue4 说要加内存加密。

@Eleutherios 本地不存任何实体文件, 所有私密信息都在内存里, 也就不涉及到文件加密和 encrypted vault, 不过后续可能会在内存进行加密防 CPU bug, 只是以文件的形式提供数据访问入口.

全盘加密只是对直接读取硬盘有效, 电脑处于开机状态通过操作系统访问等于没有加密, 除了硬件层面的病毒, 一般入侵者好像只对开机并且有操作系统的设备动手吧.

home 同步的方案有很多, 而 home 同步只是一个同步场景, 只是我认为同步时能不带上敏感信息就不带, 而这个软件主要做的是使用时请求授权和文件虚拟化, 能让你尽可能在所有情况下都不上传私密文件而且用得舒服.

@ztechstack 但是这样还是会在本地留存私密配置

@vlitter 😂 可能是我语言组织的问题吧，发帖之前感觉做这个很有用，发完贴之后人都傻了。。

@vlitter 感谢老哥，你是唯一一个 star 的，不知道是不是大家都有更好的解决方案，好像都没什么关注的意愿 🤣

解决了，之前代码有些混乱，整理了一下就可以了

@AndyAO 设置为 auto 会让 git log 先判断 stdout 是不是 tty, 如果是 tty 才会输出 `(HEAD -> master, tag: s2)`

@christopheredwar 做前端页面的话应该算是传统意义上的 lowcode 吧

感谢分享, 感觉是个不错的组合

可否邀请你加入我的 telegram 群组交流? (目前还在建设当中, 要是你用 telegram 且不嫌弃目前群内没啥热度的话, 群组链接就在我的 lowcode 讨论文中)

@agdhole 如果从减少游戏开发代码量角度理解的话好像确实可以算 lowcode. XD