clientconfig.json的簡單介紹

1、如何更改config.json配置
2、服務器參數配置文件config.json該怎麼設置
3、網站serverConfig.json加載失敗
4、概念:動態准入控制
5、config.json是什麼文件

代碼如下：請導入 System.XML命名空間

string file = Server.MapPath(@”~\web.config”);

XmlDocument xmlDoc = new XmlDocument();

xmlDoc.Load(file);

string s1 = “aaa”;

string s2 = “bbb”;

string h = “ccc”;

string user = “ddd”;

string pass = “eee”;

XmlNodeList nodeList = null;

nodeList = xmlDoc.SelectSingleNode(“configuration//connectionStrings”).ChildNodes;

//遍歷所有子節點

foreach (XmlNode xn in nodeList)

{

//將子節點類型轉換為XmlElement類型

XmlElement xe = xn as XmlElement;

if (xe.Name == “add”)

{

if (xe.GetAttribute(“name”) == “acountConnectionString”)

{

xe.SetAttribute(“connectionString”, s1);

}

if (xe.GetAttribute(“name”) == “mailaddress”)

{

xe.SetAttribute(“connectionString”, s2);

}

nodeList = xmlDoc.SelectSingleNode(“configuration//system.net//mailSettings//smtp”).ChildNodes;

foreach (XmlNode xn in nodeList)

{

//將子節點類型轉換為XmlElement類型

XmlElement xe = xn as XmlElement;

if (xe.Name == “network”)

{

xe.SetAttribute(“host”, h);

xe.SetAttribute(“userName”, user);

xe.SetAttribute(“password”, pass);

break;

}

xmlDoc.Save(file);

但實際上通過代碼修改web.config的操作微乎其微

1. web.config的修改可能會導致session等服務器變量的丟失

2. 如果你的頁面是發佈在IIS下面，要通過頁面修改web.config，必須給web.config這個文件添加 Network service (IIS6)或 ASPNET (IIS)用戶的寫權限，這在實際操作中是不可想像的

代碼如下：請導入 System.XML命名空間

string file = Server.MapPath(@”~\web.config”);

XmlDocument xmlDoc = new XmlDocument();

xmlDoc.Load(file);

string s1 = “aaa”;

string s2 = “bbb”;

string h = “ccc”;

string user = “ddd”;

string pass = “eee”;

XmlNodeList nodeList = null;

nodeList = xmlDoc.SelectSingleNode(“configuration//connectionStrings”).ChildNodes;

//遍歷所有子節點

foreach (XmlNode xn in nodeList)

{

//將子節點類型轉換為XmlElement類型

XmlElement xe = xn as XmlElement;

if (xe.Name == “add”)

{

if (xe.GetAttribute(“name”) == “acountConnectionString”)

{

xe.SetAttribute(“connectionString”, s1);

}

if (xe.GetAttribute(“name”) == “mailaddress”)

{

xe.SetAttribute(“connectionString”, s2);

}

nodeList = xmlDoc.SelectSingleNode(“configuration//system.net//mailSettings//smtp”).ChildNodes;

foreach (XmlNode xn in nodeList)

{

//將子節點類型轉換為XmlElement類型

XmlElement xe = xn as XmlElement;

if (xe.Name == “network”)

{

xe.SetAttribute(“host”, h);

xe.SetAttribute(“userName”, user);

xe.SetAttribute(“password”, pass);

break;

}

xmlDoc.Save(file);

但實際上通過代碼修改web.config的操作微乎其微

1. web.config的修改可能會導致session等服務器變量的丟失

網絡連接失敗。網站serverConfig.json對於網絡的需求是非常大的，只要該網站的網絡連接失敗就會導致該網頁加載失敗，用戶可以通過更換新的網絡來回復該網站的加載。

Admission Controllers(准入控制器) 中有兩個特殊的 controllers : MutatingAdmissionWebhook 和 ValidatingAdmissionWebhook .

MutatingAdmissionWebhook 會依次調用匹配請求的 MutatingWebhookConfiguration

ValidatingAdmissionWebhook 並行調用匹配請求的 ValidatingWebhookConfiguration

Admission Webhooks 就是 MutatingWebhookConfiguration 和 ValidatingWebhookConfiguration 中指定的 service

Admission Webhooks 實質上是集群的控制面 , 所以在編寫和部署的時候要及其小心. 需要通過 k8s e2e test

MutatingWebhookConfiguration 和 ValidatingWebhookConfiguration 中定義 rules 和 clientConfig , 以及 admissionReviewVersions 、 sideEffects 、 timeoutSeconds

創建 Configuration 後，系統將花費幾秒鐘來接受新配置

然後當 apiserver 接收到匹配任意rules的請求時 , apiserver 就會發送 admissionReview 請求給 clientConfig 指定的 webhook

admissionReview 請求就是 apiserver 發送給 webhook server 的 POST 請求 , Content-Type: application/json , JSON body 是 apiVersion: admission.k8s.io/? kind: AdmissionReview 對象

可以在 Configuration 中通過 admissionReviewVersions 指定可接受的 apiVersion , 例如 admissionReviewVersions: [“v1”, “v1beta1”]

apiserver 使用可接受的versions列表中的第一個apiserver支持的version,

如果沒有apiserver支持的version, 那麼 Configuration 不會被允許創建.

如果 Configuration 是之前創建的, 而現在 apiserver 不支持其聲明的versions了,那麼請求會按webhook的 failure policy 處理

AdmissionReview Json body 示例:

然後 webhook server 返回 HTTP狀態碼200 , Content-Type: application/json , JSON body 是 apiVersion: admission.k8s.io/? kind: AdmissionReview 對象, AdmissionReview 對象的 apiVersion 和接收到的對象的 apiVersion 相同

webhook server 返回的 Json body 至少應包含如下2個字段:

當拒絕請求時, webhook server 可以自定義返回給用戶的 http code 和 message , 如下所示:

當允許請求時, mutating webhook 可能會修改傳入的對象. 這通過 response 中的 patch 或 patchType 字段表示.

當前支持的 patchType 只有 JSONPatch

對於 patchType: JSONPatch , patch 字段內容為 JSON patch operations 列表, 並使用 base64-encoded , 如下例所示:

通過創建 MutatingWebhookConfiguration or ValidatingWebhookConfiguration API對象註冊 admission webhook .

Configuration 的 name 必須是有效的 DNS subdomain name

每個 Configuration 可以包含一個或多個webhooks, 每個webhook需要指定唯一的名稱

webhook 中定義如下的事情:

(1) rules : 用於如何匹配請求

包括 operations 、 apiGroups 、 apiVersions 、 resources 、 scope

示例:

(2) objectSelector : 用於如何匹配請求

自 v1.15+ 之後, webhooks 可以可選地使用 objectSelector 限制哪些請求被攔截, 它基於對象的 labels

newObject 和 oldObject 中有一個匹配了 objectSelector 都認為是匹配

null object (例如 create operation 中的 oldObject 和 delete operation 中的 newObject ) 被認定為不匹配

同樣, 不可能包含 label 的對象(例如 DeploymentRollback 或 PodProxyOptions )也被認定為不匹配

示例:

(3) namespaceSelector : 用於如何匹配請求

webhooks 可以可選地使用 namespaceSelector 限制哪些請求被攔截, 它基於對象的 namespace 的 labels

對 Namespace 對象的操作也會被考慮匹配, 使用其 .metadata.labels

如果對象是 cluster scoped resource 則該限制對其無效

示例:

(4) matchPolicy : 用於如何匹配請求

因為 apiserver 允許使用多個 apiGroups 和 apiVersions 操作對象, 例如 Deployment 可以通過 extensions/v1beta1 、 apps/v1beta1 、 apps/v1beta2 和 apps/v1 創建

如果 webhook 只指定了 apiGroups:[“apps”], apiVersions:[“v1″,”v1beta1”] , 那麼 extensions/v1beta1 的請求就不會被認定為匹配

自 v1.15+ 之後, webhooks 可以可選地使用 matchPolicy 定義其 rules 如何匹配請求

matchPolicy 的枚舉值有

顧名思義, 如果 webhook 指定了 matchPolicy: Equivalent , 則上面的示例中,請求會被認定為匹配

示例:

(5) clientConfig : 用於如何指定 webhook server

(5.1)使用URL指定webhook server

url的scheme 必須是 https

嘗試使用 user 或 basic auth (例如 user:pwd@ )是不被允許的.

Fragment ( #… ) 和 query parameters ( ?… ) 是不被允許的

示例:

(5.2)使用Service reference指定webhook server

示例:

(6) sideEffects

webhooks 一般只操作 AdmissionReview 中的內容.

但是有一些 webhooks 需要執行 out-of-band changes , 即 sideEffects

sideEffects 的枚舉值有:

如果使用 apiVersion: admissionregistration.k8s.io/v1 , 則 sideEffects 的枚舉值只有 None 和 NoneOnDryRun

示例:

(7) timeoutSeconds

如果超時, 請求按 failure policy 處理

如果使用 apiVersion: admissionregistration.k8s.io/v1 , 則 timeoutSeconds 的默認值為 10s

示例:

(7) reinvocationPolicy

(8) failurePolicy

failurePolicy 定義不識別的錯誤和超時錯誤如何被處理.

failurePolicy 的枚舉值包含:

示例:

apiserver 提供了監控 admission webhooks 行為的方法. 這些監控機制幫助集群管理員回答如下問題:

如果不指定 ClientAuth , 則默認為 NoClientAuth , 這意味着 webhook server 無法認證其 clients , 也就是 apiserver .

如果你需要 mTLS或其他方式認證 clients , 你可以配置 apiserver 使用 basic auth 、 bearer token 或 cert 向 webhook server 認證自己為合法的 client

要完成這個配置,需要 3個步驟:

config.json文件用於工程配置初始化，在程序運行之前配置好。

以下是 cocos2d-x lua 工程的 config.json的文件實例:

{

“init_cfg”:{

“isLandscape”: true,

“isWindowTop”: false,

“name”: “CocosLuaGame”,

“width”: 960,

“height”: 640,

“entry”: “src/main.lua”,

“consolePort”: 6010,

“uploadPort”: 6020,

“debugPort”: 10000,

“forwardConsolePort”: 10089,

“forwardUploadPort”: 10091

“simulator_screen_size”: [

{

“title”: “iPhone 3Gs (480×320)”,

“width”: 480,

“height”: 320

{

“title”: “iPhone 4 (960×640)”,

“width”: 960,

“height”: 640

….

]

}

詳細解釋如下：

“init_cfg”

“isLandscape”

布爾類型

橫豎屏配置，如果為true為橫屏，如果為false為豎屏

“isWindowTop”

布爾類型

窗口置頂配置，如果為true則窗口默認置頂，反之默認不置頂

“entry”

字符串類型

腳本啟動入口文件相對工程根目錄的文件路徑,如:”src/main.lua”

“name”

字符串類型

工程名,顯示在窗口標題中

注:這個參數只在桌面系統下生效

“width”

正整型

窗口寬

注:這個參數只在桌面系統下生效

“height”

正整型

窗口高

注:這個參數只在桌面系統下生效

“consolePort”

正整型

console端口

“uploadPort”

正整形

接收IDE上傳文件的端口

“debugPort”

正整型

調試端口

“forwardConsolePort””

正整形

Android ADB 模式調試時，將這個端口映射到 Android 設備的 consolePort 上

“forwardUploadPort””

正整形

Android ADB 模式調試時，將這個端口映射到 Android 設備的 uploadPort 上

注意事項：所有的端口配置都只在桌面平台下生效。

原創文章，作者：G0Z4D，如若轉載，請註明出處：https://www.506064.com/zh-hk/n/127309.html

clientconfig.json的簡單介紹

相關推薦

發表回復