2025工作项目计划

发表于 2025-03-24 更新于 2025-03-30 分类于生活

这里有东西被加密了，需要输入密码查看哦。

阅读全文 »

2024工作项目计划

发表于 2025-03-24 更新于 2025-03-30 分类于生活

这里有东西被加密了，需要输入密码查看哦。

阅读全文 »

2024 个人小目标

个人工作生活
- Q1每个月安排一天个人时间，学习Optimus核心知识
- 思考下一个COD方向和领域：产品架构，产品经理，后端与运维
- Q1健康作息，不熬夜到12点后，保证基础睡眠
- Q2运动开始计划，通过合理安排作息，每周半小时起养成习惯，并逐步增加
- Q1每周一次睡前花十分钟番茄钟，复盘当周工作、中长期目标调整，减少纠结与内耗，看书增值
家庭生活
- 大宝的小学一年级思考和执行
  - 拼音熟练度联系，朗读训练每日15分钟
  - 汉字识字培训
  - 控笔训练
  - 日常数学加减训练
  - 钢琴读谱，指法练习，肌肉重复训练，流畅背诵弹奏为目标
  - 复习、预习课程习惯
  - 演讲训练，植物节演讲、升旗手演讲、爸爸讲堂介绍
- 小宝幼儿园前期准备
  - 4、5月择校，9月正常入学
  - 语言发展关注，发音纠正
  - 自主如厕练习
  - 自主吃饭习惯培养
  - 自主穿脱衣服袜子入睡练习
  - 认识数字大小数数
  - 认字
职场价值、时间效率提升
- 快速阅读《高效能人士/家庭的七个习惯》，自我效能提升
- 快速阅读《卡耐基人性的弱点》，学会提升别人的效能
- 精读并且实践《How to Lead》，学会面对人工作
个人充电：阅读书籍10本
- 职场、人性相关书籍, 有助平衡心态和目标：
  - 学习领域预判思考方式，快速决策得出可执行尽量正确的选择
  - 学习高效的项目管理方式，对于种类繁多的细碎项目如何高效的管理，并且针对不同的人建立不通的项目profile，合理安排资源
  - 合理授权，对于不同的选择，可以借由别人去实践通过验证
  - 学习衍生品定价规则，交易系统，风险合规服务
  - 管理风格建立，最大化生产力同时建立稳定良好的领导风格，项目进度把控
- 领域相关背景书籍：
  - 阅读CM bitemporal DB设计学习
  - 阅读CM Risk Calc Engine设计学习
  - 阅读CM Risk Storage & Pivot设计学习
  - 阅读CM Entitlements Model设计学习
  - 阅读Kindle《债券投资策略》,了解债券市场基本知识
  - 阅读Kindle《债券组合投资》
  - 阅读Kindle《投资组合绩效测评实用方法》
  - 阅读《国富论》，了解经典生产理论以及劳动者与雇佣者的基本关系
  - 阅读《利率互换通关秘籍》，了解利率基本概念
- 育儿和教育书籍：
  - 父母效能训练
- 技术相关书籍：
  - Kubernetes权威指南: 学习K8S部署技术
- 沟通技巧学习
  - 非暴力沟通
  - 别说你懂交际学
- 情绪控制学习

个人感悟

<< How to lead >>

领导力的基础

专注在人

当我们想要营销我的思想时，往往关注：

提供的功能
带来的好处
希望和美好愿景

但是影响他人的核心原则是，被影响人的需求（恐惧，贪婪，个性，空闲），帮助对方客服所有的困难，就容易影响别人。

传统销售手段

在问题上达成一致
题出解决方案
结束

激励人的原驱动力往往来自恐惧、贪婪和懒惰。

利用恐惧：一种是利用人对惩罚的恐惧，用于规范行为；另一种是消除恐惧，使得事情
进展顺利。
利用贪婪：金钱和同事的认可度。
利用懒惰：对于对方本体是有益于她的本性，比如可以让他有利可图或生活变得容易吧。

向上管理

有潜力的领导者
- 适应性
- 自信
- 主动性
- 可靠性
- 野心
如何有效地向上管理
- 找到合适的老板
- 交付正确的项目
- 合适的反馈行为

保持正能量

让自己每天的生活积极正向

关注自己善长的
管理好自己的情绪
具象化自己想要做的事情
做有意义的事情
行动起来

做一个正能量的领导

开会中表达解决方案和机遇，而不是问题
寻找方案中的闪光点
主动寻找合适的项目
允许适当的冒险

不要做：

不抱怨工作
不嚼舌根
不推脱责任

做一个幸运的领导

领导需要持续为自己创造幸运，主要通过以下三个特性：

实践Practice：领导力是需要通过实践总结出的，深耕在一个领域或者一种类型的职能，而不是将注意力放在获取名利上。
坚持不懈Persistence：勤奋努力是成功的必要条件，对待失败，好的领导不会放弃、感到失望，而是感谢自己又少了一次失败的原因，因为它不会发生两次。
洞察力Perspective：幸运的人是在对的时间和对的地点等待幸运的发生，这样的洞察力是机遇对自己机构的了解，同时对对手的了解。对于成功模式的发现并不会太难，难的是对于其的坚持和持久的影响力让更多的人把一个观点实践成巨大的成功。

聪明的还是积极的

聪明人非常擅长看到事物的缺陷和风险，但是好的领导面对挑战具有如下特质：

冷漠的：冷漠的领导很难长时间维系一段很好的领导关系，好的领导需要避免冷漠对待挑战。
分析：聪明人的分析能力可以快速找到问题存在的潜在风险，但是好的领导需要主要找到可能的解决方案让大家的思维活跃起来。
答案：聪明人总是想找到最优的答案，然而好的领导需要用经验和实验去解决实际的问题，而不是找到完美的答案。
行动力：有行动才有机会赢，同事之间相处，请求原谅总是比请求帮忙容易，而人都是在错误中成长，所以不必因为害怕失败而踞足不前。

积极的解决问题

心理学家提出保持正能量方法

保持专业性

实践领导力

掌握领导力

Domain Driven Design Pattern Risk Calc

发表于 2024-11-19 分类于架构，领域模型

这里有东西被加密了，需要输入密码查看哦。

阅读全文 »

Authentication服务鉴权机制

用户在访问系统或者服务时，服务器端需要验证用户是否拥有访问的权力，这个过程称为鉴权。在服务器-客户端架构的软件系统中，当一个没有经过鉴权的用户登录时，服务器可能会返回鉴权请求。鉴权是一种客户端和服务器协同认证的方式，有多种方式可以实现：

HTTP Basic Authentication
session-cookie
Token 验证(JWT)
OAuth(开放授权)

HTTP Basic Authentication

HTTP认证时一种无状态的认证模式，因此用户在提供相关凭据的请求中能够得到认证用户的访问，而服务器本身在接下来的请求中并不能持续保持登录状态。

HTTP基本认证的具体流程如下:

在你访问一个需要HTTP Basic Authentication的URL的时候，如果你没有提供用户名和密码，服务器就会返回401，返回Header中会包含类似”WWW-Authenticate: Basic realm=”test””信息。如果你直接在浏览器中打开，浏览器会弹出对话框提示你输入用户名和密码。

要在发送请求的时候添加HTTP Basic Authentication认证信息到请求中，有两种方法:

在请求头中添加Authorization信息：Authorization: “Basic {用户名:密码}的base64加密字符串”。
在url中添加用户名和密码。

其中，鉴权机制中的身份验证并非一定要依赖Basic方式的用户名密码作为凭据，可以通过如下方式：

“WWW-Authenticate: Negotiate” SPNEGO协议,支持Kerberos, NTLM点对点认证方式完成。在协商过程中：
- 可以请求 Authorization: Negotiate {kerberos票据}进行Kerberos验证
- 或者也能读取返回头中的 Authorization: Negotiate NTLMSSP{八字节质询码} ，并在请求头部中加入 Authorization: Negotiate NTLM{加密的质询码和明码用户名}
“WWW-Authenticate: Digest realm=”test”,qop=”auth”,nonce=”{md5加密时间},opaque=”{不透明字符串}”摘要认证协议，能避免明文传输数据。
- 在请求中需要加入 Authoriztion: Digest username=”guest”,realm=”test”,nonce=”{同上},qop=”auth”,nc=”00000001”,response=”{通过md5加密的user paswd httpmethod uri等信息}”,cnonce=”{客户端提供的非明文字符串}”,uri=”{uri信息}”
- 服务器需要检查时间在允许范围内，而且response匹配本地生成值。使用MD5算法的优势在于可以很快正向哈希，而无法短时间内逆向哈希得出用户密码等信息。

session-cookie鉴权

Session是HTTP协议中为了支持有状态的通信而发明的会话机制，本质上是通过服务器为用户建立sessionid从而保证用户的状态信息能够在服务器端保存。用户不需要反复进行登录认证就能保持会话。

而Cookie则是一种特殊的HTTP头部，能够在HTTP通信中保存一定的用户信息，如sessionid从而达到认证用户的目的。由于Cookie本身是针对某一域名而产生的，所以在发送Cookie过程中必须提供正确域名的sessionid才行。

具体流程如下：

cookieAuth

Cookie鉴权常用Single Sign On场景，例如，于对于企业中的不同子域名的验证，可以通过结合SAML, CAS等协议完成。对于不同网络更加广泛的第三方验证则有OIDC协议支持。

Token 验证(JWT)

Token验证方式和Seesion验证方式很类似，不同的是Token本身包含一些有意义的信息：用户名、密码、过期时间等。Token本身由服务器签发，客户端请求的发送中需要包含 Authorization : JWT “{jwt token}”，服务器提取token信息通过相同的算法验证即可。相较于Session验证方式节约了分布式系统中服务器存储sessionid和用户信息的开销，只需要服务器拥有相同的密钥即可。

具体流程如下:

tokenAuth

JWT(json-web-token)算法细节：

JWT由三部分”{header}.{payload}.{signature}’,两种算法生成，公式如下：
signature = sha256(base64(header)+’.’+base64(payload),{服务器密钥})

header包含算法和类别信息,
payload为加密部分，包含公有声明和私有声明，公有声明为约定的key，私有为公司定制key，
signature，算法签名。
sha256为header中写的加密算法，基于服务器密钥生成不同的加密签名,具有不可逆性
base64为编码算法，可逆运算

OAuth2/OIDC认证

OIDC 即Open ID Connect, 是一种基于OAuth2授权流程，并且扩展了身份认证层的一种新的认证机制。

OIDC认证模型主要包含如下四个角色和一个令牌（完整术语参见http://openid.net/specs/openid-connect-core-1_0.html#Terminology）：

EU用户：End User：一个人类用户。
RP客户端：Relying Party ,用来代指OAuth2中的受信任的客户端，身份认证和授权信息的消费方；
OP认证服务器：OpenID Provider，有能力提供EU认证的服务（比如OAuth2中的授权服务），用来为RP提供EU的ID Token身份认证信息和Access Token访问令牌；
UE用户资源服务器：UserInfo Endpoint用户信息接口（受OAuth2保护），当RP使用Access Token访问时，返回授权用户的信息，此接口必须使用HTTPS。
ID Token认证令牌：JWT格式的数据，包含EU身份认证的信息。通过OP提供。

认证流程如下：

OIDCAuth

其中，UserIndo EndPoint是一个受OAuth2保护的资源。在RP得到Access Token后可以请求此资源，然后获得一组EU相关的Claims，这些信息可以说是ID Token的扩展，比如如果你觉得ID Token中只需包含EU的唯一标识sub即可（避免ID Token过于庞大），然后通过此接口获取完整的EU的信息。此资源必须部署在TLS之上。

OIDC的支持的授权流程如下：

Authorization Code(授权码模式)：使用OAuth2的授权码来换取Id Token和Access Token。
Implicit (简化模式)：使用OAuth2的Implicit流程获取Id Token和Access Token。
Hybrid(混合模式)：混合Authorization Code +Implicit。

OAuth2授权模型

OAuth2的授权模型时为了已登录用户通过第三方应用访问资源服务器进行授权的流程，授权模型和OIDC相似，包含如下四个角色:

资源拥有者（User） - 指应用的用户，比如github的一个账户拥有者
认证服务器（Authorization Server） - 提供登录认证接口的服务器，比如：github等
资源服务器（Resources Server） - 提供资源接口及服务的服务器，通常和认证服务器是同一个应用。
第三方客户端（Client） - 第三方应用，希望使用资源服务器提供的资源，比如你的一个支持通过github账户登录的应用
服务提供商(Provider): 认证服务和资源服务归属于一个机构，该机构就是服务提供商，比如github公司

OAuth2具有四种授权模式，下文将分述这四种模式具体流程：

授权码模式（authorization code）
简化模式（implicit）
密码模式（resource owner password credentials）
客户端模式（client credentials）

授权码模式(最为常见)

用户访问客户端应用
引导用户到认证服务器进行登录（此步骤需要携带客户端应用的clientId，可以是html直接转发认证服务器），用户输入用户名、密码
认证成功后，认证服务器向客户端应用发一个授权码code
客户端应用拿着授权码code，和clientId，clientSecret，去换取access_token
返回access_token给客户端应用

AuthorizationCodeOAuth

这种场景下，用户名、密码、客户端应用信息，都没有直接暴露在浏览器，是web下是最安全的。

简化模式

授权码模式的简化，用户认证成功后，直接将token返回给浏览器。因为某些应用没有前端服务器，只有一堆静态的html（很少见），这种模式，一般不用。

ImplicitOAuth

密码模式

适用场景：手机app ，这个客户端应用是你完全可以信任的，你的app就是自己公司开发的。但是这个模式并不适合在web场景下用，在web下，用户名密码并不是直接填给自己写的应用的，而是填在浏览器呈现的一个页面上的，这个浏览器是客户端应用的一个代理，浏览器是没法保证安全性的。

PasswordOAuth

客户端证书模式

客户端应用直接发 clientId、clientSecret给认证服务器，发的令牌是针对客户端应用的，不是针对用户的。跟没授权一样，令牌不能识别用户身份。

ClientOAuth

Authentication实战

本章将着重描述如何在java springboot应用中实现相应的认证流程。springboot提供了一站式应用的开发模式，但是认证流程是需要spring security，同时具体的认证核心模块需要spring securty keberos或者spring security oauth组件支持。下文将主要介绍如何利用这两个模块实现具体的基于siteminder/spnego/oauth协议的认证流程。

siteminder sso + preauth

Siteminder是企业级认证产品，它提供了一站式认证中间件，从应用开发者的角度来看，就是采用了外部认证系统，应用不需要重新进行认证而是可以直接从siteminder处理过的http request header中提取SM_USER中拿到userprincipal()。因此从spring securty框架的角度之需要直接读取认证后的信息，而不需要再对request进行认证验证。这通常是一种企业内网用户认证采用的sso机制，因为用户之需要进行简单认证后就能得到对多种内部webapp的访问toekn，而且不需要进行细粒度的鉴权的场景适合大部分内部应用，但是，因为外部网站可容易会被假的header所欺骗，安全性较差而不会采用这种方式进行验证。

spnego auth

SPNEGO是微软设计的一种企业级认证协议，底层支持多种token协议，因此是应用proid常用的一种方式，因为应用的id会常常跑在不同的window/linux环境，而spnego能够支持多种密钥认证从而对跨系统认证能有很好的支持，这种认证方式需要用户自己执行认证检查，所以需要spring-security-keberos模块的相关auth provider进行验证。

oidc oauth2 + ping federate

oauth标准的实现一般是用oidc协议，spring security oauth2拥有对oauth2标准的鉴权模型的实现，并且可以通过适当的配置完成oidc用户验证。oauth单独并不能完成验证鉴权功能，需要部署一个oauth provider例如云服务商azure AD等，企业级内部可以自己部署ping federate服务器完成auth信息提供功能，并且向下兼容sso（即open Id）功能。

Ping Identity是支持OIDC和OAuth2标准的企业化产品

以https://abc.com作为签发域名，PingIdentity具体支持方式如下：

openid配置查询Url：https://abc.com/.well-known/openid-configuration 返回json配置提供相关的认证终端信息，例如：

{
  "issuer": "https://abc.com", // 
  "authorization_endpoint": "https://abc.com/as/authorization.oauth2",
  "token_endpoint": "https://abc.com/as/token.oauth2",
  "revocation_endpoint": "https://abc.com/idp/userinfo.openid",
  "introspection_endpoint": "https://abc.com/as/inrospect.oauth2",
  "jwks_uri": "https://abc.com/pf/JWKS",
  "outh_jwks_uri": "https://abc.ocm/ext/oauth/JWKS",
  
  "scopes_supported" : [
    "address",
    "phone",
    "openid",
    "profile",
    "email"
  ],
  "claims_supported": [
    "email",
    "email_verified",
    "family_name",
    "given_name",
    "name",
    "preferred_username",
    "sub"
  ],
  "grant_types_supported": [
    "implicit",
    "authorization_code",
    "refresh_token",
    "password",
    "client_credentials"
  ]
}

authorization_code 授权码流程

用户发起请求到授权码endpoint：

打开chrome.exe，发起 GET https://abc.com/as/authorization.oauth2?client_id=foo&response_type=code&redirect=https%3A%2F%2Fabc.com%2Freal%2Fdocs%2F&scope=openid 请求

Chrome界面 redirect to url: https://abc.com/real/docs/?code=XXXXXXXXXXXXXXXXXX 获得授权码。

用户用返回授权码发起token请求：

1 2	curl -k --data "grant_type=authorization_code" --data "client_id=foo" --data "code=xxxxxxx" --data "redirect_uri=https://abc.com/real/docs/" https://abc.com/as/token.oauth2

返回token json:

{
  "id_token" : "xxxxxxxxxxxxxxxxx",
  "access_token" : "xxxxxxxxxxxxxx",
  "refresh_token": "xxxxxxxxxxxxxxxxxx",
  "token_type": "Bearer",
  "expires_in": 7200
}

用户刷新过期token请求：

1 2	curl -k --data "grant_type=refresh_token" --data "client_id=foo" --data "refresh_token=XXXXXXXXXX" --data "redirect_uri=https://abc.com/real/docs/" https://abc.com/as/token.oauth2

JWT 验证流程：

对于RSA加密算法加密的token，需要公私钥才能进行加解密。 “jwks_uri”: “https://abc.com/pf/JWKS“, 认证服务器会用私钥将内容加密并且作为jwt的签名部分签发给客户端，资源服务器拿到jwt token后，需要用公钥解密签名，并且和明文的payload的进行比较确认没有篡改则为有效。整个算法过程有已有的实现例如jose4j。
对于对称加密算法的token，假设资源服务器和认证服务器都已经知道密钥内容，客户端拿到jwt token后，资源服务器需要利用密钥进行解密，并且验证payload的合法性即可。

Jetty Session Model

Domain Driven Design Pattern Bitemporality

发表于 2024-04-29 更新于 2024-05-16 分类于架构，领域模型

这里有东西被加密了，需要输入密码查看哦。

阅读全文 »

Window Message

发表于 2024-01-31 更新于 2024-02-08 分类于架构， Windows

窗口消息

GUI应用程序必须响应来自用户和操作系统的事件。

来自用户的事件包括用户与程序交互的所有方式：鼠标点击、按键、触摸屏手势等等。
来自操作系统的事件包括程序之外的任何可能影响程序行为的东西。例如，用户可能插入一个新的硬件设备，或者Windows可能进入低功耗状态(睡眠或休眠)。
这些事件可以在程序运行时的任何时间发生，几乎可以按任何顺序发生。如何构造一个不能预先预测执行流（flow）的程序?

为了解决这个问题，Windows使用了消息传递模型。操作系统通过传递消息与应用程序窗口进行通信。消息只是指定特定事件的数字代码。例如，如果用户按下鼠标左键，窗口将接收到具有以下消息代码的消息。

C++

#define WM_LBUTTONDOWN 0x0201

一些消息具有与它们相关联的数据。例如，WM_LBUTTONDOWN消息包含鼠标光标的x坐标和y坐标。

要将消息传递给窗口，操作系统将调用为该窗口注册的窗口过程。(现在你知道窗口程序的作用了。)

https://learn.microsoft.com/zh-cn/windows/win32/learnwin32/your-first-windows-program

窗口句柄

窗口句柄是消息传递的源和目的，在每一个进程空间窗口句柄都是局部的，需要通过窗口名字去发现，对于某个窗口消息队列的监测，可以通过visual studio自带的spy++去定位监听并且调试。

2024年度个人规划

发表于 2024-01-31 更新于 2025-02-23 分类于生活

这里有东西被加密了，需要输入密码查看哦。

阅读全文 »

Azure K8S runbook

发表于 2024-01-31 更新于 2024-03-09 分类于架构， Cloud

Az Setup for a oc cluster in single node

PS C:\Users\loginid> az login
A web browser has been opened at https://login.microsoftonline.com/organizations/oauth2/v2.0/authorize. Please continue the login in the web browser. If no web browser is available or if the web browser fails to open, use device code flow with `az login --use-device-code`.
[
  {
    "cloudName": "AzureCloud",
    "homeTenantId": "85cb24e4-0bcf-4767-b44b-39eae544706e",
    "id": "bd435e85-b401-48c5-90ad-96dbefac1503",
    "isDefault": true,
    "managedByTenants": [],
    "name": "Visual Studio Professional",
    "state": "Enabled",
    "tenantId": "85cb24e4-0bcf-4767-b44b-39eae544706e",
    "user": {
      "name": "sunny_hll@hotmail.com",
      "type": "user"
    }
  }
]

Az Terraform example

PS C:\Users\loginid> az ad sp create-for-rbac --role="Contributor" --scopes="/subscriptions/bd435e85-b401-48c5-90ad-96dbefac1503"
Creating 'Contributor' role assignment under scope '/subscriptions/bd435e85-b401-48c5-90ad-96dbefac1503'
The output includes credentials that you must protect. Be sure that you do not include these credentials in your code or check the credentials into your source control. For more information, see https://aka.ms/azadsp-cli
{
  "appId": "414b5739-2c30-4cea-adff-d5c8ff1c6470",
  "displayName": "azure-cli-2022-12-09-06-36-24",
  "password": "if48Q~Wd6aUHekpKNLrgJWeC3Pr-sstzZHRXfa90",
  "tenant": "85cb24e4-0bcf-4767-b44b-39eae544706e"
}

PS C:\Users\loginid> $Env:ARM_CLIENT_ID = "414b5739-2c30-4cea-adff-d5c8ff1c6470"
PS C:\Users\loginid> $Env:ARM_CLIENT_SECRET = "if48Q~Wd6aUHekpKNLrgJWeC3Pr-sstzZHRXfa90"
PS C:\Users\loginid> $Env:ARM_SUBSCRIPTION_ID = "bd435e85-b401-48c5-90ad-96dbefac1503"
PS C:\Users\loginid> $Env:ARM_TENANT_ID = "85cb24e4-0bcf-4767-b44b-39eae544706e"

Az 手动创建VM

查询VM配置的地区Spot资源不太可用

1	az vm list-skus --location centralus --resource-type virtualMachines --zone --all --output table

VM Login

1	ssh -i ~/.ssh/oc_key.pem loginid@20.100.44.77

Az 部署oc

CRC setup guide: https://crc.dev/crc/getting_started/getting_started/using/

Maybe install for ubuntu OS:

1
2
3

sudo apt install gnome-keyring
sudo apt install dbus-x11
sudo snap install kubectl --classic

下载CRC

1 2	wget https://developers.redhat.com/content-gateway/rest/mirror/pub/openshift-v4/clients/crc/latest/crc-linux-amd64.tar.xz -o /var/tmp/crc-linux-amd64.tar.xz

VPN env network setting:

https://github.com/crc-org/crc/wiki/VPN-support--with-an--userland-network-stack

!!reset Disk size t0 128G as crcbundle took more than 30G space.

启动CRC

Started the OpenShift cluster.

The server is accessible via web console at:        
  https://console-openshift-console.apps-crc.testing

Log in as administrator:
  Username: kubeadmin
  Password: i4GM8-VqA42-8Eqix-pAg7h

Log in as user:
  Username: developer
  Password: developer

Use the 'oc' command line interface:
  $ eval $(crc oc-env)
  $ oc login -u developer https://api.crc.testing:6443

创建oc hello项目

环境变量

# crc 命令
echo 'export PATH=$PATH:$HOME/bin' >> ~/.bashrc
# oc 命令
echo 'export PATH="/home/loginid/.crc/bin/oc:$PATH"' >> ~/.bashrc
echo 'alias k=kubectl' >> ~/.bashrc
echo 'oc login -u developer https://api.crc.testing:6443' >> ~/.bashrc

# create project 
oc new-project my-project

# create http server
kubectl create deployment hello-node --image=registry.k8s.io/e2e-test-images/agnhost:2.43 -- /agnhost  netexec --tls-cert-file /home/loginid/test.crt --tls-private-key-file /home/loginid/test.key

# expose as service
oc expose deployment hello-node --port=8080

# https://www.baeldung.com/openssl-self-signed-cert
# prepare self-signed key remove -des3
openssl genrsa -out test.key 2048

# create csr
openssl req -key test.key -new -out test.csr

# sign
openssl x509 -signkey test.key -in test.csr -req -days 365 -out test.crt

# upload
scp -i ~/.ssh/oc_key.pem /mnt/d/Git/mypages/test.key loginid@hostip:/home/loginid/test.key

scp -i ~/.ssh/oc_key.pem /mnt/d/Git/mypages/test.crt loginid@hostip:/home/loginid/test.crt

# create secret https://www.baeldung.com/openssl-self-signed-cert
oc create secret generic my-cert --from-file=/home/loginid/test.crt --from-file=/home/loginid/test.key

# mount secret for deployment pods
oc apply -f deploy.yaml

# create route on haproxy from hostName=oc-dev.centralus.cloudapp.azure.com
oc create route passthrough test-pass --service=hello-node --port=8080 --hostname=oc-dev.centralus.cloudapp.azure.com.crc.testing

本地服务测试


# pod DNS

curl https://hello-node-7556f558d-psbrp:8080 -k

# service DNS

curl https://hello-node-svc.optimus.svc.cluster.local -k

# cluster DNS

curl https://oc-dev.centralus.cloudapp.azure.com.crc.testing -k -v

远程连接admin console

https://www.redhat.com/en/blog/accessing-codeready-containers-on-a-remote-server

在服务器端，需要利用haproxy做外部网卡IP的端口转发到内部地址127.0.0.1，建立外网网卡与内网之间的网桥.

sudo apt install haproxy

sudo cp /etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.cfg.bak

# 加上一下端口转发规则

frontend apps
    bind SERVER_IP:80
    bind SERVER_IP:443
    option tcplog
    mode tcp
    default_backend apps

backend apps
    mode tcp
    balance roundrobin
    option ssl-hello-chk
    server webserver1 CRC_IP check

frontend api
    bind SERVER_IP:6443
    option tcplog
    mode tcp
    default_backend api

backend api
    mode tcp
    balance roundrobin
    option ssl-hello-chk
    server webserver1 CRC_IP:6443 check

# 更改IP地址

export SERVER_IP=$(hostname --ip-address)
export CRC_IP=$(crc ip)
sudo sed -i "s/SERVER_IP/$SERVER_IP/g" haproxy.cfg
sudo sed -i "s/CRC_IP/$CRC_IP/g" haproxy.cfg

# 启动服务haproxy
sudo ststemctl start haproxy

# 诊断

sudo apt install net-tools

Java API创建Route资源

Useful Code example

https://github.com/kubernetes-client/java/wiki/3.-Code-Examples

Leader Election Example

https://github.com/kubernetes-client/java/blob/master/examples/examples-release-18/src/main/java/io/kubernetes/client/examples/LeaderElectionExample.java

2023年度个人规划

发表于 2023-10-08 更新于 2024-10-24 分类于生活

这里有东西被加密了，需要输入密码查看哦。

阅读全文 »

2024 个人小目标

个人感悟

<< How to lead >>

领导力的基础

专注在人

传统销售手段

向上管理

保持正能量

让自己每天的生活积极正向

做一个正能量的领导

做一个幸运的领导

聪明的还是积极的

积极的解决问题

保持专业性

实践领导力

掌握领导力

Authentication服务鉴权机制

HTTP Basic Authentication

session-cookie鉴权

Token 验证(JWT)

OAuth2/OIDC认证

OAuth2授权模型

授权码模式(最为常见)

简化模式

密码模式

客户端证书模式

Authentication实战

siteminder sso + preauth

spnego auth

oidc oauth2 + ping federate

Ping Identity是支持OIDC和OAuth2标准的企业化产品

Jetty Session Model

窗口消息

窗口句柄

Az Setup for a oc cluster in single node

Az Login

Az Terraform example

Az 手动创建VM

Az 部署oc

下载CRC

启动CRC

创建oc hello项目

本地服务测试

远程连接admin console

Java API创建Route资源

Useful Code example

Leader Election Example