jeffreystoke

jeffreystoke

V2EX 第 299670 号会员,加入于 2018-03-13 15:14:39 +08:00
根据 jeffreystoke 的设置,主题列表被隐藏
二手交易 相关的信息,包括已关闭的交易,不会被隐藏
jeffreystoke 最近回复了
2021-10-29 22:15:15 +08:00
回复了 huangmingyou 创建的主题 Kubernetes 老问题,现在流行什么方法管理多个环境下的 k8s 项目
@huangmingyou 是的,还支持从远程 http 服务拉取配置,以及 git ssh 仓库抽取配置( renderer 文档部分)
2021-10-29 18:41:38 +08:00
回复了 huangmingyou 创建的主题 Kubernetes 老问题,现在流行什么方法管理多个环境下的 k8s 项目
同样的痛点, 我一直觉得 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 用户链接)
2021-10-14 20:40:12 +08:00
回复了 ysoseriousC 创建的主题 MacBook Pro 用 M1 开发的兄弟们
@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 用户交叉认证第三方平台链接)
2021-08-22 20:54:34 +08:00
回复了 HarryYu 创建的主题 程序员 如何统一管理应用中第三方的 APIs?
有同样的需求,我的解决方案是把单个 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
2021-06-14 16:37:12 +08:00
回复了 jeffreystoke 创建的主题 分享创造 私密配置管理及同步工具链
@gjquoiai 感谢推荐,正是我想要的,和这个软件可以配合

我现在是用 git-secret 加密 helm values 文件,用 credentialfs 保存 git-secret 的 seed,大量私密且需要频繁改动的文件这样操作似乎更方便一点
2021-06-10 12:35:44 +08:00
回复了 jeffreystoke 创建的主题 分享创造 私密配置管理及同步工具链
@libook 是的,的确可以把这个 fuse 理解成现有文件系统的 hook,唯一的细节差异在于不会每次都去 bitwarden 里面查询,而是缓存在内存中,也就是为什么开 issue4 说要加内存加密。
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1078 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 11ms · UTC 19:08 · PVG 03:08 · LAX 11:08 · JFK 14:08
Developed with CodeLauncher
♥ Do have faith in what you're doing.