diff --git a/.DS_Store b/.DS_Store index 2f7e02d5f7a2d934be64a5aad10b27ebb3e7ecf5..206695e3e1a5c7f8033077adc72e3d15f037a415 100644 Binary files a/.DS_Store and b/.DS_Store differ diff --git "a/5 NGINX\346\225\217\346\215\267\351\205\215\347\275\256/.DS_Store" "b/5 NGINX\346\225\217\346\215\267\351\205\215\347\275\256/.DS_Store" index c361a40f292f8704ba10ea82dfb41a7381506de4..750d0ce8956302dfda111ede8c096c0e8b178a01 100644 Binary files "a/5 NGINX\346\225\217\346\215\267\351\205\215\347\275\256/.DS_Store" and "b/5 NGINX\346\225\217\346\215\267\351\205\215\347\275\256/.DS_Store" differ diff --git "a/5 NGINX\346\225\217\346\215\267\351\205\215\347\275\256/README.md.bak" "b/5 NGINX\346\225\217\346\215\267\351\205\215\347\275\256/README.md.bak" deleted file mode 100644 index 14fe0c5045dca010cc7c833190bab938d802128f..0000000000000000000000000000000000000000 --- "a/5 NGINX\346\225\217\346\215\267\351\205\215\347\275\256/README.md.bak" +++ /dev/null @@ -1,359 +0,0 @@ -# Lab环境介绍 - -本次实验采用F5 UDF环境，学员只需一个浏览器即可完成实验。UDF需要注册，具体步骤如下： - -## 注册F5 UDF账号 - -如果您还没有F5 UDF环境账号的话，将需要先注册一个用户账号。 -注册活动后，您将收到一封来自 `courses@notify.udf.f5.com` 的邮件，内容大致如下： -![邀请邮件](images/udf_email.png) -点击链接尝试登录： - -You can log into the UDF here: -https://account.f5.com/udf/signin/register?ref=cGluZy54aW9uZ0BhbGl5dW4uY29t - -如果您没有UDF账户，可以使用邮件中提到的您的注册邮箱作为账户名，根据指引直接注册一个新账号。账号建立后，将收到一个激活邮件，点击`activate account`激活账号。 -![激活账号](images/udf_actication.png) - -## 登录UDF环境，访问您的课程 - -使用chrome浏览器访问 https://udf.f5.com/ ，选择 Invited Users： -![登录UDF](images/udf_login.png) -完成登录后，您将见到您的课程： -![课程](images/udf_courses.png) -Lab提供了webshell，如果您需要使用ssh客户端登录，可以点击右上角的人像图标，创建一个ssh key: -![新建sshkey](images/udf_sshkey.png) - -## 启动环境，登录服务器 - -一切就绪后，您可以点击课程右端的`launch` 启动您的课程，您将进入课程文档的界面。 -![课程文档](images/udf_course_doc.png) -该文档详细说明了实验操作步骤。 -您也可以点击`DEPLOYMENT`打开部署环境，您将看到环境正在被拉起，耐心等待，直到各组件前出现绿色三角，表明环境就绪： -![部署环境](images/udf_course_deployment.png) -接下来，您就可以通过webshell访问服务器: -![webshell](images/udf_course_deployment_webshell.png) -如果配置了ssh密钥，也可以使用ssh客户端访问服务器： -![ssh](images/udf_course_deployment_ssh.png) - -本实验共有两台服务器，分别是 - -- NGINX Plus：安装了NGINX Plus的反向代理，同时也是测试客户端 -- k8s-master：提供coffee和tea两个web服务，用做upstream，端口分别是30081和30082 - -## 继续进入后续实验环节 - -# 实验步骤 - -NGINX Plus安装目录为/etc/nginx/，实验配置文件放置在/root/nginx-plus-config目录下，实验时需要将配置文件拷贝到/etc/nginx/conf.d/目录下。 - -确认配置文件 - -```bash -root@nginxplus:/# cd /root/nginx-plus-config -root@nginxplus:/root/nginx-plus-config# ls -abtest.conf api-8000.conf bluegreen.conf canary.conf circuitbreaker.conf ratelimit.conf variable.conf -``` - -服务器*hosts*文件已修改，添加了实验相关域名。 - -## Lab1 变量 - -1. 拷贝 *variable.conf* 文件，执行 `nginx -s reload` ，观察配置文件是否能被加载。 - - ```bash - cp variable.conf /etc/nginx/conf.d/ - ``` - -2. 访问http://variable.will.com/noset 和 http://variable.will.com/set ，观察返回的页面信息。 - - ```bash - root@nginxplus:/root/nginx-plus-config# curl http://variable.will.com/noset - F5: - root@nginxplus:/root/nginx-plus-config# curl http://variable.will.com/set - F5: NGINX is a part of F5 - ``` - -3. 删除 *variable.conf* 中第4行的注释符 - - ```conf - set $f5 "is the best ADC!"; - ``` - - 重复第1、2步。 - -4. 在 *variable.conf* 中第11行增加注释符 - - ```conf - #set $f5 "NGINX is a part of F5"; - ``` - - 重复第1步。 - -## Lab2 蓝绿部署 - -1. 拷贝 *bluegreen.conf* 文件，upstream *blue* 和 *green* 分别为k8s上的coffee和tea服务，执行 `nginx -s reload`。 - -2. 在服务器执行以下命令，观察输出，应该为空。 - - ``` - curl http://127.0.0.1:8000/api/6/http/keyvals/blue-green - ``` - -3. 访问 http://bluegreen.will.com ，应该访问到coffee。 - - ```bash - root@nginxplus:/root/nginx-plus-config# curl http://bluegreen.will.com - Server address: 10.244.0.27:80 - Server name: web-coffee-5975694976-929dg - Date: 29/May/2023:07:32:04 +0000 - URI: / - Request ID: 7e85d39941d77b95048a6b5d8bf1b054 - ``` - -4. 在服务器执行以下命令。 - - ``` - curl -X POST -d '{"environment": "green"}' http://127.0.0.1:8000/api/6/http/keyvals/blue-green - ``` - -5. 访问 http://bluegreen.will.com ，应该访问到tea。 - - ```bash - root@nginxplus:/root/nginx-plus-config# curl http://bluegreen.will.com - Server address: 10.244.0.29:80 - Server name: web-tea-545b5c798b-8bhsv - Date: 29/May/2023:07:33:45 +0000 - URI: / - Request ID: 984fded38b161d2bb705534d5e4897e6 - ``` - -6. 在服务器执行以下命令，观察输出，对比之前的情况。 - - ``` - curl http://127.0.0.1:8000/api/6/http/keyvals/blue-green - ``` - -7. 在服务器执行以下命令，将环境改为*green*。 - - ``` - curl -X PATCH -d '{"environment": "blue"}' http://127.0.0.1:8000/api/6/http/keyvals/blue-green - ``` - -8. 再次访问 http://bluegreen.will.com ，应该又回到coffee。 - - ```bash - root@nginxplus:/root/nginx-plus-config# curl http://bluegreen.will.com - Server address: 10.244.0.27:80 - Server name: web-coffee-5975694976-929dg - Date: 29/May/2023:07:38:43 +0000 - URI: / - Request ID: 69f1b41281af41e038b8f72a676e6f42 - ``` - -## Lab3 AB Test - -1. 拷贝 *abtest.conf* 文件，upstream *abtest_a* 和 *abtest_b* 分别为k8s上的coffee和tea服务，执行 `nginx -s reload`。 - -2. 在服务器通过wrk打压力，参考命令 `wrk -c200 -t8 -d300s "http://abtest.will.com"`，打开Dashboard，观察upstream，所有的request应该都打向abtest_a。 - ![dashboard](images/udf_course_deployment_dashboard.png) - - ![abtest_a](images/abtest_a.png) - -3. 在服务器执行以下命令。 - - ``` - curl -X POST -d '{"bpercentage": 5}' http://127.0.0.1:8000/api/6/http/keyvals/abtest - ``` - -4. 通过Dashboard，观察upstream，应该有5%左右的request打向abtest_b。 - ![abtest_ab](images/abtest_ab.png) - -5. 在服务器执行以下命令。 - - ``` - curl -X PATCH -d '{"bpercentage": 20}' http://127.0.0.1:8000/api/6/http/keyvals/abtest - ``` - -6. 通过Dashboard，观察upstream，应该有20%左右的request打向abtest_b。 - -7. 在服务器执行以下命令。 - - ``` - curl -X PATCH -d '{"bpercentage": 50}' http://127.0.0.1:8000/api/6/http/keyvals/abtest - ``` - -8. 通过Dashboard，观察upstream，应该有50%左右的request打向abtest_b。 - -9. 在服务器执行以下命令。 - - ``` - curl -X PATCH -d '{"bpercentage": 100}' http://127.0.0.1:8000/api/6/http/keyvals/abtest - ``` - -10. 通过Dashboard，观察upstream，应该所有的request都打向abtest_b。 - -## Lab4 灰度发布 - -1. 拷贝 *canary.conf* 文件，upstream v1和v2分别为k8s上的coffee和tea服务，执行 `nginx -sreload`。 - -2. 在服务器多次用curl模拟各种浏览器访问，应该coffee和tea之间轮询。 - - ``` - curl -A 'Chrome' http://canary.will.com - ``` - -3. 在服务器执行以下命令。 - - ``` - curl -X POST -d '{"stage": "b"}' http://127.0.0.1:8000/api/6/http/keyvals/canary - ``` - -4. 在服务器多次用curl模拟各种浏览器访问，应该只会访问到coffee。 - - ``` - curl -A 'Chrome' http://canary.will.com - ``` - -5. 在服务器执行以下命令。 - - ``` - curl -X PATCH -d '{"stage": "c"}' http://127.0.0.1:8000/api/6/http/keyvals/canary - ``` - -6. 在服务器多次用curl模拟**Chrome浏览器**访问，应该只会访问到tea。 - - ``` - curl -A 'Chrome' http://canary.will.com - ``` - -7. 在服务器多次用curl模拟**Firefox浏览器**访问，应该只会访问到coffee。 - - ``` - curl -A 'Firefox' http://canary.will.com - ``` - -8. 在服务器模拟其它浏览器访问，例如Safari，应该也只会访问到coffee。 - -9. 在服务器执行以下命令。 - - ``` - curl -X PATCH -d '{"stage": "d"}' http://127.0.0.1:8000/api/6/http/keyvals/canary - ``` - -10. 在服务器多次用curl模拟各种浏览器访问，应该只会访问到tea。 - -11. 在服务器执行以下命令。 - - ``` - curl -X PATCH -d '{"stage": "a"}' http://127.0.0.1:8000/api/6/http/keyvals/canary - ``` - -12. 在服务器多次用curl模拟各种浏览器访问，应该在coffee和tea之间轮询。 - -## Lab5 动态限流 - -1. 拷贝 *ratelimit.conf* 文件，执行 `nginx -s reload`。 - -2. 在服务器通过wrk打压力，参考命令 `wrk -c200 -t8 -d300s "http://ratelimit.will.com"` ，打开Dashboard观察，此时应该是正常分发流量，没有任何限速。 - -3. 在服务器执行以下命令，打开限速200rps的开关。 - - ``` - curl -X POST -d '{"ratelimit_200": 1}' http://127.0.0.1:8000/api/6/http/keyvals/kv_ratelimit - ``` - -4. 打压力的同时观察Dashboard，应该被限制在了200rps左右，同时观察delay的效果。 - ![ratelimit_delay](images/ratelimit_delay.png) - -5. 在服务器执行以下命令，打开限速100rps的开关。 - - ``` - curl -X POST -d '{"ratelimit_100": 1}' http://127.0.0.1:8000/api/6/http/keyvals/kv_ratelimit - ``` - -6. 打压力的同时观察Dashboard，应该被限制在了100rps左右(由于响应了444代码，因此在server层面request都是被接受的，需要看upstream），同时观察nodelay的效果。 - ![ratelimit_100_upstream](images/ratelimit_100_upstream.png) - - ![ratelimit_nodelay](images/ratelimit_nodelay.png) - -## Lab6 熔断 - -1. 拷贝 *circuitbreaker.conf* 文件，执行 `nginx -s reload`。 - -2. 打开Dashboard，观察健康检查的情况，此时两个节点应该都是down的状态，需要在k8s服务上添加健康检查页面。 - 登录k8s-master服务器 - - ```bash - root@k8s-master:/# kubectl get pod - NAME READY STATUS RESTARTS AGE - web-coffee-5975694976-929dg 1/1 Running 2 (79m ago) 5d - web-tea-545b5c798b-8bhsv 1/1 Running 2 (79m ago) 5d - root@k8s-master:/# kubectl exec -it web-coffee-5975694976-929dg sh - kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead. - / # vi /etc/nginx/conf.d/hello-plain-text.conf - / # nginx -s reload - 2023/05/29 08:35:45 [notice] 39#39: signal process started - / # exit - root@k8s-master:/# - ``` - - 修改coffee和tea容器中NGINX的配置文件，执行`nginx -s reload` - - ```nginx - server { - listen 80; - listen [::]:80; - - location / { - default_type text/plain; - expires -1; - return 200 'Server address: $server_addr:$server_port\nServer name: $hostname\nDate: $time_local\nURI: $request_uri\nRequest ID: $request_id\n'; - } - - location /health { - default_type application/json; - return 200 '{"deadlocks":{"healthy":true},"Disk":{"healthy":true},"Memory":{"healthy":true}}'; - } - } - ``` - -3. 对coffee和tea做相同的操作，完成后再次观察Dashboard，两个节点应该是up的状态。 - -4. 在服务器通过wrk打压力，参考命令 `wrk -c200 -t8 -d300s "http://circuitbreaker.will.com" ，打开Dashboard观察，此时应该是正常分发流量。 - -5. 登录tea容器，修改 */etc/nginx/conf.d/hello-plain-text.conf* 文件，将以下部分中return的值做任意改变，执行 `nginx -s reload`。 - - ``` - location /health { - default_type application/json; - return 200 '{"deadlocks":{"healthy":false},"Disk":{"healthy":true},"Memory":{"healthy":true}}'; - } - ``` - -6. 观察Dashboard，10.1.1.4:30082应该被健康检查标记为down，流量全部打向10.1.1.4:30081。 - -7. 登录tea容器，将 */etc/nginx/conf.d/hello-plain-text.conf* 文件修改为正常值，执行 `nginx -s reload`。 - - ``` - location /health { - default_type application/json; - return 200 '{"deadlocks":{"healthy":true},"Disk":{"healthy":true},"Memory":{"healthy":true}}'; - } - ``` - -8. 观察Dashboard，10.1.1.4:30082连续三次健康检查通过后应该被重新标记为up，并且开始逐步接收流量，最终和30081达到1:1。 - -9. 删除反代 *circuitbreaker.conf* 文件中的slow_start参数，执行 `nginx -s reload`。 - - ``` - upstream circuitbreaker { - server 10.1.1.4:30081; - server 10.1.1.4:30082; - zone circuitbreaker 64k; - } - ``` - -10. 重复5至8步，观察没有slow_start时候的效果。 - -#实验结束 diff --git "a/5 NGINX\346\225\217\346\215\267\351\205\215\347\275\256/Reverse Proxy/.DS_Store" "b/5 NGINX\346\225\217\346\215\267\351\205\215\347\275\256/Reverse Proxy/.DS_Store" index f46da5f2b14dbb10f34205b5f5563ea37f2907cb..291e0a8505ae23c4c3ff282e95167e018e30b573 100644 Binary files "a/5 NGINX\346\225\217\346\215\267\351\205\215\347\275\256/Reverse Proxy/.DS_Store" and "b/5 NGINX\346\225\217\346\215\267\351\205\215\347\275\256/Reverse Proxy/.DS_Store" differ diff --git "a/5 NGINX\346\225\217\346\215\267\351\205\215\347\275\256/Reverse Proxy/conf.d/canary.conf" "b/5 NGINX\346\225\217\346\215\267\351\205\215\347\275\256/Reverse Proxy/conf.d/canary.conf" deleted file mode 100644 index d87a10f73e4ac402925a280344764dae296986fe..0000000000000000000000000000000000000000 --- "a/5 NGINX\346\225\217\346\215\267\351\205\215\347\275\256/Reverse Proxy/conf.d/canary.conf" +++ /dev/null @@ -1,36 +0,0 @@ -keyval_zone zone=canary:64k; -keyval stage $keyval_stage zone=canary; - -map $keyval_stage $canary_upstream { - a all; - b v1_only; - c $canary_release; - d v2_only; - default all; -} - -map $http_user_agent $canary_release { - ~*firefox v1_only; - ~*chrome v2_only; - default v1_only; -} - -upstream all { - server 10.1.1.4:30081; - server 10.1.1.4:30082; -} - -upstream v1_only { - server 10.1.1.4:30081; -} - -upstream v2_only { - server 10.1.1.4:30082; -} - -server { - server_name canary.will.com; - location / { - proxy_pass http://$canary_upstream; - } -} \ No newline at end of file diff --git a/8 NGINX-Ingress-Controller/.DS_Store b/8 NGINX-Ingress-Controller/.DS_Store index fb69e0bfad2ed7c7f3b07e87cd0fcdda7e4537ba..3e91f4369af84ce9cffc54ddf4b9fa45e17869ef 100644 Binary files a/8 NGINX-Ingress-Controller/.DS_Store and b/8 NGINX-Ingress-Controller/.DS_Store differ