作者归档:小笨孩

如何选择一副眼镜

如何选配眼镜是一个近视眼每隔几年就会遇到的问题,刚好最近也需要配眼镜,故在此总结一波。

验光

一个比较尴尬的事实是,国内的眼光流程还是很不规范的,很多验光师并不具备眼科基础知识,短期培训就直接在眼镜店上岗了。而在国外眼光处方是需要有资质的医师才能开具的。

所以,虽然不能说眼镜店等地方的验光师不好,但是如果你第一次配镜,或者是高度近视,或者还是个孩子,那么建议去医院的验光中心验光,那里出具的配镜处方是最保险的。

镜架的选择

选镜架其实就是选镜架的材质。常见的包括板材、TR90(塑胶钛)、合金、钛等等……

材料:

  • 板材硬度大,光泽好,不易变形;
  • Ti-P/Ti-C:Ti是含有钛材料的标识,Ti-P代表纯钛,Ti-C则代表钛合金等等。钛镜架耐腐蚀,重量轻,不过价格嘛,自然是高的。
  • GF/GP:GF为包金架,即将薄金片熔接在其他金属基材上轧制而成的镜架;GP为镀金架,即用电镀法将金镀在其他金属制成的镜架表面。
  • TR90:一种具有记忆性的高分子材料,重量较轻,约少于板材框重量的一半,它可以减少鼻梁、耳朵负担,佩戴更加轻便舒适。升级版本是TR100

小道消息:

  • 目前眼镜架在国内有几个地方会集中出品,其中,低端镜片的产地为有浙江义乌;
  • 其次是江苏丹阳货,台州货,温洲货,等中低端为主,温洲产地相对还好点;
  • 太阳镜一般都是厦门出产,保圣,暴龙,陌生,派丽蒙等精品镜框;
  • 国内最好的眼镜架都是深圳横岗出产的,中国高端产地眼镜,最初发展90年代是有实力的香港眼镜厂,来横岗办厂,有星辉,雅视,雅俊,高雅,高华眼镜厂主要订单就是帮欧美大品牌,如迪奥,香奈儿,保时捷等等代工生产;(龙岗眼镜城)
  • 东莞的高埗镇也是一个眼镜产地中心。

所以如果在遇到特别贵的镜架的时候,可以适当的看一看产地,看看自己选择的镜架值不值。

镜片的选择

材质:

现在一般都是树脂片了

外形:

镜片根据曲率不同分为球面镜和非球面镜,对于度数较低的人,两者的区别不大,对于中高度近视的人来说,建议选择非球面镜片,成像效果更好,看得更清楚。

色散系数:

这是衡量透镜成像清晰度的指标,通常用阿贝数 (色散系数) 表示,数值越大,色散就越小,成像清晰度就越好,当然价格也就越贵。阿贝数多在 30~58 之间,按照自己的承受能力挑选就可以了。

折射率:

常见的折射率有 1.56、1.60、1.67 和 1.74,简单地说,同样度数下,折射率越高镜片就越薄,当然挑选时也不是镜片越薄越好,介意参见下面这个:

  • 小于 200 度可以选 1.50 或 1.56;
  • 200~400 度可以选 1.60;
  • 400~800 度可以选 1.67;
  • 更高度数的建议选 1.74 或者玻璃镜片。

镜片的折射率只要够用就好了,并不是越高越好。

镀膜:

镀膜的作用:减少前表面反光,减少“鬼影” ,减轻眩光 。不镀膜的树脂镜片透光率大概89-92% 。镀膜以后透光率可达98%。清晰度差别明显

  • 蓝膜:镀有蓝膜的镜片具有很好的抗辐射作用,长期面对电脑屏工作的人可以使用蓝膜镜片,防止眼睛疲劳。
  • 绿膜:绿膜对光线的透过率好,绿膜镜片佩戴舒服,看东西清晰自然真实,适合于对色彩要求较高的人士。
  • 黄绿:黄绿膜是在绿膜的基础上进一步提高了透光率(增加2%左右),这种颜色镀膜的镜片非常容易搭配镜架。
  • 黄金膜:镀有黄金膜的镜片透光率特别高,而且还有防水、防尘和防雾的效果,是一种多功能的镀膜层。
  • 紫膜和红膜,主要作用是使镜片看上去更漂亮,属于装饰性镀膜。

镜片品牌

蔡司(Zeiss)

  • 简介:德国品牌1846年创立。研磨精密,精湛的光学曲面设计,透光率和防反光性能卓著,视觉成像品质极佳。是目前镜片领域市场占有率第二的品牌。
  • 特点:膜色柔和,视物舒适度高。
  • 主打产品推荐:铭锐钻立方铂金膜系列,儿童成长乐渐进系列,驾驶型渐进多焦点系列。

依视路(Essilor)

  • 简介:法国品牌。膜层硬度高,耐磨性能卓著,不易刮伤,防水防油污效果优越。是目前镜片领域市场占有率最高的品牌。
  • 主打产品推荐:爱赞数码生活系列,钻晶A4防蓝光系列,万里路渐进多焦点系列。

豪雅(Hoya)

  • 简介:日本品牌,始创于1941年。品质稳定,耐磨性能强,防反光性能优越。目前镜片领域市场占有率第三的品牌。
  • 主打产品推荐:兰御膜防蓝光系列,锐美抗疲劳系列。

精工(Seiko):

  • 简介:日本品牌。研磨精密,人性化曲线设计,佩戴舒适度高。
  • 主打产品推荐:精工双面非球面系列,精工极光变色系列。

高端镜片还有德国品牌罗敦司得(Rodenstock),特点是个性化瞳孔优化技术;中低端镜片中还有凯米(Chemilens),韩国品牌,目前镜片占领第四。

其中蔡司和依视路是第一梯队,日本品牌算是第二梯队,第三梯队韩国品牌,凯米,大明,还有万新、明月等国产品牌。

使用 libfaketime 修改 docker 容器时间

容器的时间问题:

如果想要直接进入容器,使用date -s修改日期,则会出现一个date: cannot set date: Operation not permitted的错误,而且也不会成功。

这是由于docker容器的隔离是基于Linux的Capability机制实现的, Linux的Capability机制允许你将超级用户相关的高级权限划分成为不同的小单元。目前Docker容器默认只用到了以下的Capability.

CHOWN, 
DAC_OVERRIDE, 
FSETID, 
FOWNER, 
MKNOD, 
NET_RAW, 
SETGID,  
SETUID, 
SETFCAP, 
SETPCAP, 
NET_BIND_SERVICE, 
SYS_CHROOT, 
KILL, 
AUDIT_WRITE

而要修改系统时间需要有SYS_TIME权限。使用 --cap-add, --cap-drop 可以添加或禁用特定的权限。--privileged参数也可以达到开放权限的作用, 与--cap-add的区别就是, --privileged是将所有权限给容器.

docker使用--privileged, --cap-add, --cap-drop 来对容器本身的能力进行开放或限制。

那么使用如下命令就可以直接改变时间了:

docker run -it --cap-add SYS_TIME --name centos centos /bin/bash

接着进入容器实行date命令修改时间,如果没有修改成功,,那么可能就是因为宿主机做了共享主机的localtime(比如laradock就做了):

docker run --name <name> -v /etc/localtime:/etc/localtime:ro  .... 
docker cp /etc/localtime:【容器ID或者NAME】/etc/localtime

如果修改成功一会就又恢复了,那么就可能要查看一下宿主机是否做了定时校准的任务。

但是如此执行之后,那就是容器时间变更为5月28日之后,宿主机的时间也跟着变更了, 因为上边操作的 --cap-add SYS_TIME是为了将宿主机的内核时间挂载进来与容器共享,因此容器时间更改了,宿主机时间也会跟着更改。

使用 libfaketime

由此可见,直接修改docker容器的时间是比较危险的,所以选择如下方案。

首先在宿主机上安装:libfaketime

git clone https://github.com/wolfcw/libfaketime.git
cd libfaketime  && make install

安装完成之后,把安装后的库文件拷贝到docker中:

docker cp /usr/lib/x86_64-linux-gnu/faketime/libfaketime.so.1 e6e239e5fba7:/usr/local/lib/

然后再进入docker中执行命令改变环境变量:

export LD_PRELOAD=/usr/local/lib/libfaketime.so.1 FAKETIME="-5d"

改变环境变量之后,再执行脚本会发现时间已经改变。若想要恢复,直接把环境变量修改为空即可:

export LD_PRELOAD=

LD_PRELOAD是Linux系统的一个环境变量,它可以影响程序的运行时的链接(Runtime linker),它允许你定义在程序运行前优先加载的动态链接库。这个功能主要就是用来有选择性的载入不同动态链接库中的相同函数。通过这个环境变量,我们可以在主程序和其动态链接库的中间加载别的动态链接库,甚至覆盖正常的函数库。一方面,我们可以以此功能来使用自己的或是更好的函数(无需别人的源码),而另一方面,我们也可以以向别人的程序注入程序,从而达到特定的目的。

如果需要修改容器中的各种web服务的时间,只需要在改变环境变量之后,重启服务即可。但是注意,镜像必须使用比较基础的镜像,因为如果直接使用服务的镜像(例如php镜像),会在重启的时候,整个容器会退出,faketime就会修改无效。

例如:

pkill php-fpm ; /usr/local/php/sbin/php-fpm

修改 faketime 步骤

第一步:需要通过dockerfile把libfaketime拷贝部分制作到基础镜像当中。 第二步:通过uuid来寻找要执行的pod。 第三步:修改pod的yaml文件(容器启动),把export LD_PRELOAD=/usr/local/lib/libfaketime.so.1 FAKETIME="-5d" 加入yaml,重启pod(会自动重启相应服务php、kong、nginx、go等),此时faketime生效。

参考:

时间测试神器libfaketime的使用

在做开发测试的时候,时常会遇到一些需要时间设置的问题,通常的时候,我们就是直接修改系统时间来完成,但是由于一般服务器上会跑着很多服务,一旦修改难免会影响到其他的程序,所以我们得找到一个方便的,只对自己需要使用的服务或进程修改时间,而不影响其他的,且修改方便的神器。好在有这么一款好用的:

根据其官方介绍如下:

 libfaketime会拦截程序用于检索的各种系统调用当前日期和时间。然后报告并修改(伪造)的日期和时间(由您用户指定的)到这些程序。这意味着您可以修改系统时间一个程序不需要改变系统范围内的时间。 libfaketime 允许您指定绝对日期(例如,01/01/2004)和相对日期(如10天前)。 例如,libfaketime可以用于各种目的 -确定构建过程 -调试与时间相关的问题,如过期的SSL证书 -测试软件在2038是否依旧合规

libfaketime附带一个名为“faketime”的命令行包装,易于使用,但不公开libfaketime的所有功能。如果你的 用例没有被faketime命令覆盖到,请确保查看此命令文档它是否可以通过直接使用libfaketime来实现。

当然还有很多的小伙伴,用它来破解一些macos下的有时间限制的软件。

安装使用

    git clone https://github.com/wolfcw/libfaketime.git

    cd libfaketime  && make install

ubuntu用户也可以使用这个:

    sudo apt-get update -y
    sudo apt-get install -y faketime

使用faketime命令

安装完成之后,就可以直接先查看一下faketime命令:

看一下此时的时间

date
2019年 11月 26日 星期二 14:46:25 CST

直接指定时间:

faketime '2018-03-27 21:04:52' date
20180327日 星期二 21:04:52 CST

指定时间从10天前开始

faketime -f '-10d' date
20191116日 星期六 14:48:43 CST

使用环境变量

这里我们使用一下php的脚本来执行测试一下,把php这个脚本的时间指定到15天前

php -r "echo date('Y-m-d H:i:s');"
2019-11-26 14:53:16

LD_PRELOAD=/usr/lib/x86_64-linux-gnu/faketime/libfaketime.so.1 FAKETIME="-15d" php -r "echo date('Y-m-d H:i:s');"
2019-11-11 14:53:16

首先这里要找到并确定libfaketime.so.1的安装位置,才可以直接赋予环境变量。

一些具体的使用方法可以在https://github.com/wolfcw/libfaketime/blob/master/test/test.sh 中查看。

示例

指定绝对日期2003-01-01 10:00:05作为运行测试程序

LD_PRELOAD=/usr/lib/x86_64-linux-gnu/faketime/libfaketime.so.1 FAKETIME="2003-01-01 10:00:05" php -r "echo date('Y-m-d H:i:s');"

# 该时间会一直保持不变

2003-01-01 10:00:05

在指定开始日期@2005-03-29 14:14:14的情况下运行测试程序

LD_PRELOAD=/usr/lib/x86_64-linux-gnu/faketime/libfaketime.so.1 FAKETIME="@2005-03-29 14:14:14" php -r "echo date('Y-m-d H:i:s');"

# 时间会从这里往后递增

2005-03-29 14:14:14

在指定10天前的情况下运行测试程序

LD_PRELOAD=/usr/lib/x86_64-linux-gnu/faketime/libfaketime.so.1 FAKETIME="-10d" NO_FAKE_STAT=1 php -r "echo date('Y-m-d H:i:s');"

# 时间会到10天前

在指定10天后并有加速因子的情况下运行测试程序

LD_PRELOAD=/usr/lib/x86_64-linux-gnu/faketime/libfaketime.so.1 FAKETIME="+10d x1" NO_FAKE_STAT=1 php -r "echo date('Y-m-d H:i:s'); sleep(10); echo PHP_EOL; echo date('Y-m-d H:i:s');"

2019-12-06 15:05:52
2019-12-06 15:06:02

数据迁移工具对比&介绍

1.Tungsten Replicator

简介

Tungsten Replicator是数据库集群和复制供应商 Continuent 推出的高性能、开源的数据复制引擎,是Continuent最先进的集群解决方案的核心组件之一,特别适合作为异构数据库之间数据迁移的解决方案。

Tungsten replicator被定义为是异构数据库复制框架,可实现不同版本,不同种类数据库之间的数据库复制。根据官方的说明,现在可以实现mysql各版本件,以及mysql与oracle间的数据库复制,但是一些函数上限制还是不能避免。

特点

  1. 支持高版本MySQL向低版本复制,如5.1->5.0;
  2. 支持跨数据库系统的复制,如MySQL->Oracle,并且所支持的数据库不仅包括MySQL、PostgreSQL和Amazon RDS等传统关系型数据库,还包括MongoDB等NoSQL数据库以及Vertica、InfiniDB、Hadoop和Amazon RedShift等数据仓库;
  3. 支持多种复制拓扑结构,如Master-Slave、Multi-Master、Direct、Fan-In和Star等。
  4. 数据备份与恢复以及数据库基准测试工具等其他辅助功能点

参考链接

2. Maxwell

简介

Maxwell是一个能实时读取MySQL二进制日志binlog,并生成 JSON 格式的消息,作为生产者发送给 Kafka,Kinesis、RabbitMQ、Redis、Google Cloud Pub/Sub、文件或其它平台的应用程序。它的常见应用场景有ETL、维护缓存、收集表级别的dml指标、增量到搜索引擎、数据分区迁移、切库binlog回滚方案等。

maxwell相对于canal的优势是使用简单,它直接将数据变更输出为json字符串,不需要再编写客户端。maxwell可以看作是canal服务端+canal客户端

特点

  • 支持SELECT*FROM table的方式进行全量数据初始化
  • 支持在主库发生failover后,自动恢复binlog位置(GTID)
  • 可以对数据进行分区,解决数据倾斜问题,发送到kafka的数据支持database、table、column等级别的数据分区
  • 工作方式是伪装为Slave,接收binlog events,然后根据schemas信息拼装,可以接受ddl、xid、row等各种event

参考链接

3.MySQLStreamer

简介

MySQLStreamer 是一个数据库变更捕获和发布系统,它负责捕获数据库的每一条数据变更,将它们打包成消息并发布到Kafka 中。“流表二象性”的概念就是讲述可以重放表中的每一条变更操作来将整张表重建为某个时间点的镜像,或者发送表中的每一条变更来重新生成流。

要理解我们是如何捕获和发布数据变更的,就必须了解我们的数据库基础架构。在 Yelp,我们把绝大多数数据都保存在 MySQL 集群中。为了处理海量访问和管理读请求负载,Yelp 必须维护几十个在地理上按区域分布的读副本。

MySQL 数据复制原理:

要注意的是从库上 SQL 线程执行的事件并不一定是主库二进制文件中的最新事件,这个在上图中表现为复制延迟。Yelp 的 MySQLStreamer 就做为一个从库,把更新操作持久化到 Apache Kafka 中,而不是象普通的 MySQL 从库一样持久化到数据表中。

MySQLStreamer 则负责:

不断从 MySQL 二进制文件中查看最新的日志,读取这两种类型的事件; 根据事件类型不同而进行相应处理,将 DML 事件发布到 Kafka Topic 中; MySQLStreamer 会发布四种不同的事件类型:插入、更新、删除和刷新。前三种对应着相同类型的 DML 操作。刷新事件由我们的初始化 Topic 过程产生

参考链接

4.Camus

简介

linkin开发,目前被 gobblin 取代

5.Gobblin

简介

Gobblin是一个用于批处理和流系统的分布式大数据集成框架(导入,复制,合规性,保留)。 Gobblin是用来整合各种数据源的通用型ETL框架,在某种意义上,各种数据都可以在这里“一站式”的解决ETL整个过程,专为大数据采集而生,易于操作和监控,提供流式抽取支持 Gobblin具有与Apache Hadoop,Apache Kafka,Salesforce,S3,MySQL,Google等的集成。

特点

底层支持三种部署方式,分别是standalone,mapreduce,mapreduce on yarn。可以方便快捷的与Hadoop进行集成,上层有运行时任务调度和状态管理层,可以与Oozie,Azkaban进行整合,同时也支持使用Quartz来调度(standalone模式默认使用Quartz进行调度)。对于失败的任务还拥有多种级别的重试机制,可以充分满足我们的需求。再上层呢就是由6大组件组成的执行单元了。这6大组件的设计也正是Gobblin高度可扩展的原因。

  • Source:主要负责将源数据整合到一系列workunits中,并指出对应的extractor是什么。这有点类似于Hadoop的InputFormat。
  • Extractor:则通过workunit指定数据源的信息,例如kafka,指出topic中每个partition的起始offset,用于本次抽取使用。Gobblin使用了watermark的概念,记录每次抽取的数据的起始位置信息。
  • Converter:顾名思义是转换器的意思,即对抽取的数据进行一些过滤、转换操作,例如将byte arrays 或者JSON格式的数据转换为需要输出的格式。转换操作也可以将一条数据映射成0条或多条数据(类似于flatmap操作)。
  • Quality Checker:即质量检测器,有2中类型的checker:record-level和task-level的策略。通过手动策略或可选的策略,将被check的数据输出到外部文件或者给出warning。
  • Writer:就是把导出的数据写出,但是这里并不是直接写出到output file,而是写到一个缓冲路径( staging directory)中。当所有的数据被写完后,才写到输出路径以便被publisher发布。Sink的路径可以包括HDFS或者kafka或者S3中,而格式可以是Avro,Parquet,或者CSV格式。同时Writer也可是根据时间戳,将输出的文件输出到按照“小时”或者“天”命名的目录中。
  • Publisher:就是根据writer写出的路径,将数据输出到最终的路径。同时其提供2种提交机制:完全提交和部分提交;如果是完全提交,则需要等到task成功后才pub,如果是部分提交模式,则当task失败时,有部分在staging directory的数据已经被pub到输出路径了。

参考链接

6.Open Replicator

Open Replicator是一个用Java编写的MySQL binlog分析程序。Open Replicator 首先连接到MySQL(就像一个普通的MySQL Slave一样),然后接收和分析binlog,最终将分析得出的binlog events以回调的方式通知应用。Open Replicator可以被应用到MySQL数据变化的实时推送,多Master到单Slave的数据同步等多种应用场景。

Open Replicator目前只支持MySQL5.0及以上版本。

简介

参考链接

7.Galera Cluster

简介

- 官网:https://galeracluster.com/

何谓Galera Cluster?就是集成了Galera插件的MySQL集群,是一种新型的,数据不共享的,高度冗余的高可用方案,目前Galera Cluster有两个版本,分别是Percona Xtradb Cluster及MariaDB Cluster,都是基于Galera的,所以这里都统称为Galera Cluster了,因为Galera本身是具有多主特性的,所以Galera Cluster也就是multi-master的集群架构,如图1所示:

特性

  • 真正的多主集群,Active-Active架构;
  • 同步复制,没有复制延迟;
  • 多线程复制;行级别并行复制
  • 没有主从切换操作,无需使用虚IP;
  • 热备份,单个节点故障期间不会影响数据库业务;
  • 支持节点自动加入,无需手动拷贝数据;
  • 支持InnoDB存储引擎;
  • 对应用程序透明,原生MySQL接口;
  • 无需做读写分离;
  • 部署使用简单。

参考链接

8.Group Replication

简介

MySQL Group Replication(简称MGR)是MySQL官方于2016年12月推出的一个全新的高可用与高扩展的解决方案。组复制是MySQL5.7版本出现的新特性,它提供了高可用、高扩展、高可靠的MySQL集群服务。MySQL组复制分单主模式和多主模式,mysql 的复制技术仅解决了数据同步的问题,如果 master 宕机,意味着数据库管理员需要介入,应用系统可能需要修改数据库连接地址或者重启才能实现。(这里也可以使用数据库中间件产品来避免应用系统数据库连接的问题,例如 mycat 和 atlas 等产品)。组复制在数据库层面上做到了,只要集群中大多数主机可用,则服务可用,也就是说3台服务器的集群,允许其中1台宕机。

MGR提供了single-primary和multi-primary两种模式。其中,single-primary mode(单写模式) 组内只有一个节点负责写入,读可以从任意一个节点读取,组内数据保持最终一致;multi-primary mode(多写模式),即写会下发到组内所有节点,组内所有节点同时可读,也是能够保证组内数据最终一致性。尤其要注意:一个MGR的所有节点必须配置使用同一种模式,不可混用!

  • 在单主模式下, 组复制具有自动选主功能,每次只有一个 server成员接受更新;
  • 在多主模式下, 所有的 server 成员都可以同时接受更新;

参考链接

对比

平台 开发厂商 语言 stars active
Tungsten Replicator Continuent Java
Maxwell zendesk Java 1.8k 6 days ago
MySQLStreamer Yelp Python 332 3 years ago
Camus linkdin Java 837 4 years ago
Gobblin linkdin Java 1.6k 4 days ago
Open Replicator person Java 440 4 years ago
Group Replication
Galera Cluster

相关链接

解决 protobuf 3 PHP 中枚举值报错问题

前两天在项目中突然遇到一个protobuf php库报错,报错为:

"Undefined offset: 8","context"

这个一看就是直接是索引下标,找不到值就超出报错了,再往前回溯一下报错,发现这个错误是

Google\\Protobuf\\Internal\\Message

报出的。后来看了项目的.proto文件,发现是其他项目的同事更新了这个proto文件,把一个结构体的枚举值添加了一个,导致我们这边项目在收到这个结构体的时候无法识别。此时其实只要更新proto文件就可以解决问题,但是这样并不能一劳永逸,下一次遇到了枚举值增加的时候依旧会出现。

不过按说谷歌的protobuf php库用了这么多年应该没什么大问题,回溯一下代码发现在

https://github.com/protocolbuffers/protobuf/blob/master/php/src/Google/Protobuf/Internal/EnumDescriptor.php

这行代码的问题,这里直接使用的是,没有做异常处理。

  return $this->value[$number];

再接着经过同事的发现,这个问题已经解决了,也已经有人提了pr

https://github.com/protocolbuffers/protobuf/pull/6155#issuecomment-493795218

只需要把依赖升级一下即可,之前使用的是3.6.*,直接升级到3.10.*就可以解决问题。

Kong 1.4 发布!自动检测Cassandra Topology 更改,自定义Host Header以及更多功能!

原文地址:https://konghq.com/blog/kong-gateway-1-4-released-auto-detect-cassandra-topology-changes-custom-host-header-much/

我们很高兴地宣布1.4系列的第一个版本已经发布! 我们的工程团队和出色的社区成员在此版本中添加了许多新功能,改进和修复。

请阅读以下内容,了解Kong Gateway 1.4中最相关的更改以及如何充分利用这些新增功能。 有关完整的详细信息,请参阅更改日志;有关如何从以前的Kong版本进行升级的说明,请参阅升级路径

自动检测Cassandra Topology 更改

从Kong Gateway 1.4开始,将自动检测对Apache Cassandra群集拓扑所做的任何更改,从而避免Kong重新启动。

如何利用此新功能:

新的配置cassandra_refresh_frequency设置在检查Cassandra集群拓扑结构更改之前,Kong必须等待多长时间。默认频率是每60秒检查一次,但是可以根据需要增加、减少甚至禁用这个值。

上游的Hostname属性

Kong中定义的任何上游现在都可以使用一个名为hostname的可选属性,该属性定义在通过Kong服务器代理连接时将使用的Host header。

主要优点:

服务器通常会监听与解析名称不同的服务器名称,并且此新属性可以保证Kong在代理连接和积极检查主机的运行状况时将使用正确的名称。

DAO属性的新变更

新的属性转换已添加到DAO模式中,使开发人员能够添加在插入或更新数据库条目时运行的函数

新的状态接口

通过新的状态接口,插件可以将端点添加到已经存在的/status端点,从而公开不敏感的健康数据,从而避免公开Kong的管理API。

主要优点

  • 用户可以同时公开Kong的健康数据并保护Kong的Admin API。
  • 对于使用禁用的管理界面运行的Kong节点,执行基于HTTP的运行状况检查更加容易。

Kong Gateway 1.4中的其他新功能

新的Admin API响应headerX-Kong-Admin-Latency

  • 这个新的响应header报告了对Kong的Admin API的每个请求处理了多长时间。

新的配置选项router_update_frequency

  • 这个新的配置选项允许设置检查路由器和插件更改的频率。
  • 这样可以避免在频繁更改Kong路由或插件时性能下降。
  • 此选项使管理员可以选择延迟路由器和插件配置更改的可用性,还是增加数据库负载。

限速插件中的Service-level 支持

  • 除了使用者,凭证和IP级别外,限速插件现在还具有服务级别的支持。

Kong Gateway 1.4中的其他改进和错误修复

Kong Gateway 1.4还改善了限速插件内存的使用,使用共享字典的TTL终止了其local策略计数器,以避免在内存中保留不必要的计数器。

此版本中存在一些重要的错误修复,例如服务网格弃用的开始,它将被替换为Kuma(kuma.io)向前发展。 已知服务网格会导致向上游的HTTPS请求忽略proxy_ssl *指令,因此在Kong Gateway的下一个主要版本中将停止使用该服务网格。 在此版本中,默认情况下禁用此功能,以避免出现此问题,并且仍可以使用新的配置选项service_mesh启用它。

另一个相关的修复与使用日志插件记录NGINX产生的错误有关,该错误过去曾错误地将某些请求属性报告为请求方法,并且现在可以正常工作。

我们还解决了一个问题,即在删除所有Kong workers时,目标不能在所有Kong员工中正确更新的情况下,在频繁使用情况下,将流量与这些被删除目标进行了平衡。

与往常一样,此处提供Kong Gateway 1.4的文档。 此外,我们将在后续帖子和社区电话中讨论1.4中的关键功能,敬请期待!

感谢我们的用户,贡献者和核心维护者社区,感谢您对Kong开源平台的持续支持。

请尝试一下Kong Gateway 1.4,并确保让我们知道您的想法

Kong社区

像往常一样,随时在我们的社区论坛Kong Nation上提问。 从您的反馈中吸取教训,将使我们能够更好地了解关键任务用例并不断改进Kong。

Happy Konging!

在 CentOS 安装 Kong

安装包

首先下载配置的相应软件包:

企业试用用户应从其欢迎电子邮件中下载其包,并在步骤1之后将其许可保存到/etc/kong/license.json

YUM Repositories

你也可以通过YUM安装Kong;按照下面“Set Me Up”部分中的说明进行操作。

注意:确保生成的.repo文件的baseurl字段包含您的CentOS版本;例如:

baseurl=https://kong.bintray.com/kong-rpm/centos/6

或者

baseurl=https://kong.bintray.com/kong-rpm/centos/7

安装

  1. 安装Kong 如果要下载程序包,请执行:
     $ sudo yum install epel-release
     $ sudo yum install kong-1.3.0.*.noarch.rpm --nogpgcheck
    

    如果您正在使用存储库,请执行:

      $ sudo yum update -y
      $ sudo yum install -y wget
      $ wget https://bintray.com/kong/kong-rpm/rpm -O bintray-kong-kong-rpm.repo
      $ export major_version=`grep -oE '[0-9]+\.[0-9]+' /etc/redhat-release | cut -d "." -f1`
      $ sed -i -e 's/baseurl.*/&\/centos\/'$major_version''/ bintray-kong-kong-rpm.repo
      $ sudo mv bintray-kong-kong-rpm.repo /etc/yum.repos.d/
      $ sudo yum update -y
      $ sudo yum install -y kong
    
  2. 准备数据库或声明性配置文件 无论是否有数据库,Kong都可以运行。使用数据库时,您将使用 kong.conf 配置文件在启动时设置Kong的配置属性,并将数据库用作所有已配置实体的存储,例如Kong代理所在的 Routes 和 Services 。

    不使用数据库时,您将使用kong.conf的配置属性和kong.yml文件来将实体指定为声明性配置。

    使用数据库

    配置Kong以便它可以连接到您的数据库。Kong支持PostgreSQL 9.5+Cassandra 3.x.x作为其数据存储。

    如果您使用Postgres,请在开始Kong之前配置数据库和用户,即:

     CREATE USER kong; CREATE DATABASE kong OWNER kong;
    
    然后执行Kong的数据迁移:
    
      $ kong migrations bootstrap [-c /path/to/kong.conf]
    

    对于Kong 小于0.15的注意事项:如果Kong版本低于0.15(最高0.14),请使用up子命令而不是bootstrap。另请注意,如果Kong 小于0.15,则不应同时进行迁移;只有一个Kong节点应该一次执行迁移。对于0.15,1.0及以上的Kong,此限制被取消。

    不使用数据库

    如果要在无DB模式下运行Kong,则应首先生成声明性配置文件。以下命令将在当前文件夹中生成kong.yml文件。它包含有关如何填写它的说明。

     $ kong config init
    

    填写kong.yml文件后,编辑您的kong.conf文件。将数据库选项设置为off,将declarative_config选项设置为kong.yml文件的路径:

     database = off
      declarative_config = /path/to/kong.yml
    
  3. 启动Kong
     $ kong start [-c /path/to/kong.conf]
    
  4. 使用Kong Kong正在运行
      $ curl -i http://localhost:8001/

微服务 API 网关 Kong 插件 AWS Lambda 中文文档

从Kong调用 AWS Lambda函数。它可以与其他请求插件结合使用以保护,管理或扩展功能。

注意:此插件与0.14.0之前的Kong版本和0.34之前的Kong Enterprise捆绑在一起的功能与此处记录的功能不同。 有关详细信息,请参阅CHANGELOG

术语

  • plugin: 在请求被代理到上游API之前或之后,在Kong内部执行操作的插件。
  • Service: 表示外部 upstream API或微服务的Kong实体。
  • Route: 表示将下游请求映射到上游服务的方法的Kong实体。
  • Consumer: 代表使用API的开发人员或机器的Kong实体。当使用Kong时,Consumer 仅与Kong通信,其代理对所述上游API的每次调用。
  • Credential: 与Consumer关联的唯一字符串,也称为API密钥。
  • upstream service: 这是指位于Kong后面的您自己的 API/service,转发客户端请求。

配置

此插件与具有以下协议的请求兼容:

  • http
  • https

此插件与无DB模式兼容。

在 Service 上启用插件

使用数据库:

通过发出以下请求在Service上配置此插件:

$ curl -X POST http://kong:8001/services/{service}/plugins \
    --data "name=aws-lambda"  \
    --data-urlencode "config.aws_key=AWS_KEY" \
    --data-urlencode "config.aws_secret=AWS_SECRET" \
    --data "config.aws_region=AWS_REGION" \
    --data "config.function_name=LAMBDA_FUNCTION_NAME"

不使用数据库:

通过添加此部分在服务上配置此插件执行声明性配置文件:

plugins:
- name: aws-lambda
  service: {service}
  config: 
    aws_key: AWS_KEY
    aws_secret: AWS_SECRET
    aws_region: AWS_REGION
    function_name: LAMBDA_FUNCTION_NAME

在这两种情况下,{service}是此插件配置将定位的RouteID或名称。

在 Route 上启用插件

使用数据库:

通过发出以下请求在 Route 上配置此插件:

$ curl -X POST http://kong:8001/routes/{route}/plugins \
    --data "name=aws-lambda"  \
    --data-urlencode "config.aws_key=AWS_KEY" \
    --data-urlencode "config.aws_secret=AWS_SECRET" \
    --data "config.aws_region=AWS_REGION" \
    --data "config.function_name=LAMBDA_FUNCTION_NAME"

不使用数据库:

通过添加此部分在 Route 上配置此插件执行声明性配置文件:

plugins:
- name: aws-lambda
  route: {route}
  config: 
    aws_key: AWS_KEY
    aws_secret: AWS_SECRET
    aws_region: AWS_REGION
    function_name: LAMBDA_FUNCTION_NAME

在这两种情况下,,{route}是此插件配置将定位的 route 的idname

在 Consumer 上启用插件

使用数据库:

您可以使用http://localhost:8001/plugins在特定的Consumers上启用此插件:

$ curl -X POST http://kong:8001/consumers/{consumer}/plugins \
    --data "name=aws-lambda" \
     \
    --data-urlencode "config.aws_key=AWS_KEY" \
    --data-urlencode "config.aws_secret=AWS_SECRET" \
    --data "config.aws_region=AWS_REGION" \
    --data "config.function_name=LAMBDA_FUNCTION_NAME"

不使用数据库:

通过添加此部分在Consumer上配置此插件执行声明性配置文件:

plugins:
- name: aws-lambda
  consumer: {consumer}
  config: 
    aws_key: AWS_KEY
    aws_secret: AWS_SECRET
    aws_region: AWS_REGION
    function_name: LAMBDA_FUNCTION_NAME

在这两种情况下,{consumer}都是此插件配置将定位的Consumeridusername
您可以组合consumer_idservice_id 。 在同一个请求中,进一步缩小插件的范围。

全局插件

  • 使用数据库:可以使用http://kong:8001/plugins/配置所有插件。
  • 不使用数据库:可以通过plugins:配置所有插件:声明性配置文件中的条目。

与任何 Service ,Route 或 Consumer (或API,如果您使用旧版本的Kong)无关的插件被视为“全局”,并将在每个请求上运行。有关更多信息,请阅读插件参考插件优先级部分。

参数

以下是可在此插件配置中使用的所有参数的列表:

参数 默认值 描述
name 要使用的插件的名称,在本例中为aws-lambda
service_id 此插件将定位的 Service 的ID。
route_id 此插件将定位的 Route 的ID。
enabled true 是否将应用此插件。
consumer_id 此插件将定位的Consumer的id
config.aws_key 调用功能时要使用的AWS密钥凭证。
config.aws_secret 调用功能时要使用的AWS秘密凭证
config.aws_region Lambda函数所在的AWS区域。支持的区域是:us-east-1,us-east-2, ap-northeast-1,ap-northeast-2, ap-southeast-1, ap-southeast-2, eu-central-1, eu-west-1
config.function_name 要调用的AWS Lambda函数名称
config.qualifier 
optional
调用功能时要使用的 Qualifier 
config.invocation_type 
optional
RequestResponse 调用函数时要使用的 InvocationType。可用类型为RequestResponseEventDryRun
config.log_type 
optional
Tail 调用函数时要使用的LogType。默认情况下,不支持noneTail
config.timeout 
optional
60000 调用该函数时的可选超时(以毫秒为单位)
config.keepalive 
optional
60000 可选值(以毫秒为单位),用于定义空闲连接在关闭之前将存活多长时间
config.unhandled_status 
optional
200,202  204 Unhandled Function Error时使用的响应状态代码(而不是默认的200202204
config.forward_request_body 
optional
false 一个可选值,用于定义是否在JSON编码请求的request_body字段中发送请求正文。如果可以解析正文参数,则将在请求的单独的request_body_args字段中发送它们。正文参数可以针对application/jsonapplication/x-www-form-urlencodedmultipart/form-data内容类型进行解析。
config.forward_request_headers
optional
false 一个可选值,用于定义是否将原始HTTP请求标头作为映射发送到JSON编码请求的request_headers字段中。
config.forward_request_method
optional
false 一个可选值,用于定义是否在JSON编码请求的request_method字段中发送原始HTTP请求方法动词。
config.forward_request_uri 
optional
false 一个可选值,用于定义是否在JSON编码请求的request_uri字段中发送原始HTTP请求URI。请求URI参数(如果有)将在JSON主体的单独的request_uri_args字段中发送。
config.is_proxy_integration 
optional
false 一个可选值,它定义是否将从Lambda接收的响应格式转换为此格式。请注意,未实现参数isBase64Encoded

提醒: 默认情况下,curl将发送带有application/x-www-form-urlencoded MIME类型的有效负载,该负载自然会由Kong进行URL解码。 为确保正确解码可能出现在您的AWS密钥或机密中的特殊字符(如+),您必须对其进行URL编码,因此如果使用curl,请使用--data-urlencode。 这种方法的替代方法是使用其他MIME类型(例如application/json)发送有效负载,或使用其他HTTP客户端。

发送参数

与请求一起发送的任何表单参数也将作为参数发送到AWS Lambda函数。

已知的问题

使用伪造的上游服务

使用AWS Lambda插件时,响应将由插件本身返回,而无需将请求代理到任何上游服务。 这意味着服务的host, port, path属性将被忽略,但仍必须为由Kong验证的实体指定。 主机属性尤其必须是IP地址,或者是由名称服务器解析的主机名。

响应插件

系统中存在一个已知限制,该限制会阻止执行某些响应插件。 我们计划将来删除此限制。

分步指南

步骤

  1. 以允许用户使用lambda函数操作以及创建用户和角色的用户身份访问AWS Console。
  2. 在AWS中创建执行角色
  3. 创建一个将通过Kong调用该功能的用户,对其进行测试。
  4. 在Kong中创建一个Service&Route,添加链接到我们的aws函数的aws-lambda插件并执行它。

配置

  1. 首先,让我们为lambda函数创建一个称为LambdaExecutor的执行角色。在IAM控制台中创建一个选择AWS Lambda服务的新角色,将没有任何策略,因为本示例中的函数将简单地执行自身,从而返回硬编码JSON作为响应,而无需访问其他AWS资源
  2. 现在,我们创建一个名为KongInvoker的用户,由我们的Kong API网关用来调用该函数。在IAM控制台中,创建一个新用户,必须通过访问和秘密密钥向其提供编程访问权限;然后将直接附加现有策略,尤其是预定义的AWSLambdaRole。确认用户创建后,将访问密钥和秘密密钥存储在安全的地方。
  3. 现在我们需要创建lambda函数本身,将在弗吉尼亚北部地区(代码us-east-1)进行。在Lambda Management中,创建一个新函数Mylambda,将没有蓝图,因为我们将在下面粘贴代码。对于执行角色,我们选择一个以前专门创建的LambdaExecutor角色使用下面的内联代码来返回简单的JSON响应,请注意,这是Python 3.6解释器的代码。
      import json
    def lambda_handler(event, context):
      """
        If is_proxy_integration is set to true :
        jsonbody='''{"statusCode": 200, "body": {"response": "yes"}}'''
      """
      jsonbody='''{"response": "yes"}'''
      return json.loads(jsonbody)
    

    从AWS控制台测试lambda函数,并确保执行成功。

  4. 最后,我们在Kong中设置了Service&Route,并将其链接到刚刚创建的功能。

使用数据库

curl -i -X POST http://{kong_hostname}:8001/services \
--data 'name=lambda1' \
--data 'url=http://localhost:8000' \

该Service并不需要真正的URL,因为我们不会对上游进行HTTP调用,而需要由函数生成的响应。

还要为 Service 创建一条 Route :

curl -i -X POST http://{kong_hostname}:8001/services/lambda1/routes \
--data 'paths[1]=/lambda1'

添加插件

curl -i -X POST http://{kong_hostname}:8001/services/lambda1/plugins \
--data 'name=aws-lambda' \
--data-urlencode 'config.aws_key={KongInvoker user key}' \
--data-urlencode 'config.aws_secret={KongInvoker user secret}' \
--data 'config.aws_region=us-east-1' \
--data 'config.function_name=MyLambda'

不使用数据库

将 Service, Route and Plugin 添加到声明性配置文件中:

services:
- name: lambda1
  url: http://localhost:8000

routes:
- service: lambda1
  paths: [ "/lambda1" ]

plugins:
- service: lambda1
  name: aws-lambda
  config:
    aws_key: {KongInvoker user key}
    aws_secret: {KongInvoker user secret}
    aws_region: us-east-1
    function_name: MyLambda

创建所有内容后,请调用服务并验证正确的调用,执行和响应:

curl http://{kong_hostname}:8000/lambda1

附加标题:

x-amzn-Remapped-Content-Length, X-Amzn-Trace-Id, x-amzn-RequestId

JSON响应:

{"response": "yes"}

充分利用AWS Lambda在Kong的强大功能,尽享乐趣!

使用源码安装 Kong

无论是否有数据库,Kong都可以运行。

使用数据库时,您将使用kong.conf配置文件在启动时设置Kong的配置属性,并将数据库用作所有已配置实体的存储,例如Kong代理所在的 Routes 和 Services 。

不使用数据库时,您将使用kong.conf的配置属性和kong.yml文件来将实体指定为声明性配置。

使用数据库

  1. 安装依赖项OpenResty 1.15.8.1。作为一个OpenResty应用程序,您必须遵循OpenResty安装说明。您将需要OpenSSL和PCRE来编译OpenResty,并至少使用以下编译选项:
      $ ./configure \
        --with-pcre-jit \
        --with-http_ssl_module \
        --with-http_realip_module \
        --with-http_stub_status_module \
        --with-http_v2_module
    

    您可能必须指定--with-openssl,并且可以添加任何其他您想要的选项,例如其他Nginx模块或自定义--prefix目录。

    OpenResty可以方便地捆绑LuaJITresty-cli,它们对于Kong来说是必不可少的。将nginx和resty可执行文件添加到$ PATH

      $ export PATH="$PATH:/usr/local/openresty/bin"
    

    Luarocks 3.1.3,使用与OpenResty捆绑的LuaJIT版本编译(请参阅--with-lua--with-lua-include配置选项)。例:

      ./configure \
        --lua-suffix=jit \
        --with-lua=/usr/local/openresty/luajit \
        --with-lua-include=/usr/local/openresty/luajit/include/luajit-2.1
    
  2. 安装 Kong现在已经安装了OpenResty,我们可以使用Luarocks来安装Kong的Lua源:
      $ luarocks install kong 1.3.0-0
    

    或者

      $ git clone git@github.com:Kong/kong.git
      $ cd kong
      $ [sudo] make install # this simply runs the `luarocks make kong-*.rockspec` command
    
  3. 添加kong.conf

    注意:如果您使用的是Cassandra,则需要执行此步骤;它是Postgres用户的可选项。

    默认情况下,Kong配置为与本地Postgres实例通信。 如果您使用的是Cassandra,或者需要修改任何设置,请下载kong.conf.default文件并根据需要进行调整。 然后,以root身份将其添加到/etc

      $ sudo mkdir -p /etc/kong
       $ sudo cp kong.conf.default /etc/kong/kong.conf
    
  4. 准备数据库配置Kong以便它可以连接到您的数据库。Kong支持PostgreSQL 9.5+Cassandra 3.x.x作为其数据存储。如果您使用的是Postgres,请在启动Kong之前配置数据库和用户:
     CREATE USER kong; CREATE DATABASE kong OWNER kong;
    

    接下来,运行Kong迁移:

      $ kong migrations bootstrap [-c /path/to/kong.conf]
    

    对于Kong < 0.15的注意事项:如果Kong版本低于0.15(最高0.14),请使用up子命令而不是bootstrap。另请注意,如果Kong < 0.15,则不应同时进行迁移;只有一个Kong节点应该一次执行迁移。对于0.15,1.0及以上的Kong,此限制被取消。

  5. 启动Kong
     $ kong start [-c /path/to/kong.conf]
    
  6. 使用KongKong正在运行
      $ curl -i http://localhost:8001/
    

不使用数据库

  1. 按照上面的列表中的步骤1和2(安装依赖项,安装Kong)。
  2. 写声明性配置文件以下命令将在当前文件夹中生成kong.yml文件。它包含有关如何填写它的说明。执行此操作时,请遵循[声明配置格式]:/1.3.x/db-less-and-declarative-config/#the-declarative-configuration-format说明。
      $ kong config init
    

    我们假设该文件名为kong.yml

  3. 添加kong.conf下载kong.conf.default文件并根据需要进行调整。特别是,确保将database配置选项设置为off,并将declarative_config选项设置为kong.yml的绝对路径
      database = off
      ...
      declarative_config = /path/to/kong.yml
    
  4. 启动Kong
     $ kong start [-c /path/to/kong.conf]
    
  5. 使用KongKong正在运行
      $ curl -i http://localhost:8001/

第二十八年中秋

第二十八年中秋

生日刚刚过去,第二十八年就这样猝不及防的来到了,这个思想汇报系列也走到了第七个年头,不过还好,总算也是也坚持下来了,一百多篇博客,不算多也不算少,持续不断的写博客,也算是一种自我总结和反思吧。去年的这个时候定了一个小小的目标:接下来的一年时间里,平均每个月要写五篇博客,查看了一下归档记录,基本算是达到了,给自己一个小小的掌声,其中大部分的还是自己的一些学习和记录。也免得以后需要使用到相关技能的时候,记不起来。这个博客是一直使用wordpress搭建的,2015年的时候虚拟空间买两年送三年,一直到2020年到期,等到过期的时候,就把这个博客挪个位置,至于还是使用cms系统还是使用静态博客,到时候做一个抉择。

2019年比较重要的一件事儿是驾照终于考了,《如何成为一个合格的逮虾户》,考完整个驾照之后反思了一下,其实也没有想象的那么困难,最开始练车的时候总是一直担心考不过怎么怎么之类的,后来总结了一个道理是,越担心就越去练习。才开始上车的时候觉得开车好害怕,怕这怕那,练到科目三的时候感觉练习的越多心越定,觉得心里有谱,所以科三科四满分。所以人生中有些事儿啊,越怕就越是要上,越上心才越定。拿了驾照之后,后面就可以带着小马儿兜兜风赶赶海去了。

来这个公司之后,除了做之前的本职工作php,最大的收货是学习了新的技术,就是基于openresty的微服务api网关 Kong,可以看到的是我之前的很多博客,基本都是围绕着这个kong写的,一些技术总结,一些翻译文档。说到翻译文档,基本上花了两三个月,把Kong的中文文档全部都翻译了一遍,详情看我的这篇博客《微服务 API 网关 Kong 中文文档发布》 ,后续也会慢慢不断完善的。说起来,翻译文档确实是一个学习新技术的好方法,至少你可以把整个文档都过一遍,也不求你能全部记住,但是这个技术所拥有的哪些功能,哪些特性,脑子里基本都有个书,遇到相关的问题可以立马索引的到,知道大体的解决方向,而且还锻炼了自己的英语能力。做项目还用到了go的相关技术,用go的一个框架写了一个简单的项目,目前还没有那么深入的使用,后面还是要把go学的更深入一些。使用了一些k8s,也是后续的学习目标之一。

2019年貌似没有出去玩耍,整个年度基本都有忙忙碌碌的感觉,想着到年底还有几个月,假期调休都还剩了很多,看看能不能找个地方去度个假期,放松放松,毕竟我和媳妇儿平常上班时候还是挺辛苦的。十一国庆七天假期准备把爸妈接到深圳来玩一下,来深圳这么多年了,爸妈都还没来过,他们也没出过这么远的门儿,不过基本都安排妥当,没啥大问题。还有个事儿就是马上就可以住我们自己的房子了,来深第七年的一个小小阶段。

10.7 续

爸妈国庆节来的这几天,主要带他们在深圳转了转,每天都是两三万步,主要也是让他们知道这边的生活是什么样子的,他们也是第一次出这么远的门儿,本以为这一千公里的路程会状况百出,不过得益于国家强大的基建,所以路上没什么问题,一路畅通。来了深圳之后,虽然车没有往常多了,但是景点都还依旧到处是人山人海,所以有一些景点就没有去。不过有些景点没去,但是吃的却毫不含糊,基本上广东本地特色的大菜全部都尝了一遍,虽然在内地的爸妈有点吃不习惯,但是他们还是能感受到这边饮食滋味的。希望爸妈能身体健康,多多享受生活。

在 Kubernetes 上安装 Kong 和 Kong Enterprise

Kubernetes Ingress Controller for Kong

使用官方Kubernetes Ingress控制器安装Kong或Kong Enterprise。

通过README文件了解更多信息。要运行本地概念证明,请按照Minikube和Minishift教程进行操作。

Kubernetes Ingress Controller for Kong发布公告在Kong Blog上。

如有问题和讨论,请访问Kong Nation。 有关错误报告,请在GitHub上打开一个新问题

通过 Google Cloud Platform Marketplace 安装 Kong

也许在Kubernetes上尝试Kong的最快方法是通过Google Cloud Platform Marketplace和Google Kubernetes Engine - 以及Google Cloud Platform的Free Tier 和 credit,,您可以免费使用。

  1. 访问 https://console.cloud.google.com/marketplace/details/kong/kong
  2. 单击“Configure”,然后按照屏幕上的提示进行操作
  3. 有关公开Admin API的重要详细信息,请参阅https://github.com/Kong/google-marketplace-kong-app/blob/master/README.md,以便您可以配置Kong。

如果您只是在尝试使用,请考虑在完成实验后删除Google云资源,以避免持续使用Google Cloud使用费。

通过 Helm 安装 Kong

使用官方Helm chart 安装Kong或Kong Enterprise。

如有问题和讨论,请访问 Kong Nation

通过 Manifest 文件安装 Kong

可以通过Kong Kubernetes存储库中提供的清单文件在Kubernetes集群上配置Kong或Kong Enterprise的试用版。

准备

  1. 下载或克隆Kong Kubernetes存储库
  2. 一个Kubernetes集群

安装步骤

Kong Kubernetes存储库包括 Make tasks run_cassandrarun_postgresrun_dbless 以便于使用,但我们将详细说明任务在此处使用的特定YAML文件。

对于所有变体,创建Kong命名空间:

$ kubectl apply -f kong-namespace.yaml

下一步取决于您是否要使用Kong与Cassandra,Postgres或没有数据存储区:

Cassandra Backed Kong

使用此存储库中的cassandra-service.yamlcassandra-statefulset.yaml文件在集群中部署Cassandra服务和StatefulSet

$ kubectl apply -f cassandra-service.yaml
$ kubectl apply -f cassandra-statefulset.yaml

使用此存储库中的kong-control-plane-cassandra.yaml文件运行所需的迁移并部署Kong控制平面节点,包括Kong admin api

$ kubectl -n kong apply -f kong-control-plane-cassandra.yaml

使用此存储库中的kong-ingress-data-plane-cassandra.yaml文件运行Kong数据平面节点

$ kubectl -n kong apply -f kong-ingress-data-plane-cassandra.yaml

PostgreSQL Backed Kong

使用存储库中的postgres.yaml文件在集群中部署postgreSQL服务和ReplicationController

$ kubectl create -f postgres.yaml

使用此存储库中的kong-control-plane-postgres.yaml文件运行所需的迁移并部署Kong控制平面节点,包括Kong Admin API:

$ kubectl -n kong apply -f kong-control-plane-postgres.yaml

使用此存储库中的kong-ingress-data-plane-postgres.yaml文件运行Kong数据平面节点

$ kubectl -n kong apply -f kong-ingress-data-plane-postgres.yaml

Using Datastore Backed Kong

首先,让我们确保Kong控制平面和数据平面成功运行

kubectl get all -n kong
NAME                           READY   STATUS
pod/kong-control-plane         1/1     Running
pod/kong-ingress-data-plane    1/1     Running

访问Kong Admin API端口(如果运行minikube,则以下内容应该有效):

$ export HOST=$(kubectl get nodes --namespace default -o jsonpath='{.items[0].status.addresses[0].address}')
$ export ADMIN_PORT=$(kubectl get svc --namespace kong kong-control-plane  -o jsonpath='{.spec.ports[0].nodePort}')

Using Kong without a Database

对于declarative / db-less,使用此存储库中的declarative.yaml示例文件创建配置映射

$ kubectl create configmap kongdeclarative -n kong --from-file=declarative.yaml

现在使用此存储库中的kong-dbless.yaml文件部署Kong数据平面

$ kubectl apply -f kong-dbless.yaml

Using Declarative / DB Less Backed Kong

要更新declarative / db-less Kong,请编辑声明性文件,然后替换配置映射

$ kubectl create configmap kongdeclarative -n kong --from-file=declarative.yaml -o yaml --dry-run | kubectl replace -n kong -f -

现在使用声明性Kong yaml文件的md5sum进行滚动部署

$ kubectl patch deployment kong-dbless -n kong -p "{\"spec\":{\"template\":{\"metadata\":{\"labels\":{\"declarative\":\"`md5sum declarative.yaml | awk '{ print $$1 }'`\"}}}}}}"

访问Kong Admin API端口(如果运行minikube,则以下内容应该有效):

$ export HOST=$(kubectl get nodes --namespace default -o jsonpath='{.items[0].status.addresses[0].address}')=
$ export ADMIN_PORT=$(kubectl get svc --namespace kong kong-control-plane  -o jsonpath='{.spec.ports[0].nodePort}')

Kong Enterprise 试用用户的附加步骤

  1. 将Kong Enterprise Docker映像发布到容器注册表

    由于Kong Enterprise映像在公共Docker容器注册表中不可用,因此必须将其发布到私有存储库以与Kubernetes一起使用。虽然任何私有存储库都可以使用,但此示例使用Google Cloud Platform容器注册表,该注册表在其他步骤中自动与Google Cloud Platform示例集成。

    在下面的步骤中,将 <image ID> 替换为与docker images输出中已加载图像关联的ID。将 <project ID> 替换为您的Google Cloud Platform项目ID。

      $ docker load -i /tmp/kong-docker-enterprise-edition.tar.gz
      $ docker images
      $ docker tag <image ID> gcr.io/<project ID>/kong-ee
      $ gcloud docker -- push gcr.io/demo-cs-lab/kong-ee:latest
    
  2. 添加您的Kong Enterprise许可文件

    编辑kong_trial_postgres.yamlkong_trial_migration_postgres.yaml,将YOUR_LICENSE_HERE替换为您的Kong Enterprise License File字符串 – 它应如下所示:

      - name: KONG_LICENSE_DATA
      value: '{"license":{"signature":"alongstringofcharacters","payload":{"customer":"Test Company","license_creation_date":"2018-03-06","product_subscription":"Kong Only","admin_seats":"5","support_plan":"Premier","license_expiration_date":"2018-06-04","license_key":"anotherstringofcharacters"},"version":1}}'
    
  3. 使用Kong Enterprise图像

    编辑kong_trial_postgres.yamlkong_trial_migration_postgres.yaml并将image:kong替换为image:gcr.io/<project ID> / kong-ee,使用与上面相同的项目ID。

  4. 部署Kong Enterprise

    使用Kong Enterprise Trial目录中的kong_trial_* YAML文件,从上面的Manifest Files指令继续执行Kong或Kong Enterprise中的步骤4。 一旦Kong Enterprise运行,您应该能够通过<kong-admin-ip-address>:8002https:// <kong-ssl-admin-ip-address>:8445访问Kong Admin GUI。

 

Kong 无法使用 lua-openssl

目前在写一个kong的插件的时候想要使用一下 lua-openssl 的ecc加密功能,ecc是一个相对较新的加密算法(椭圆加密算法)。

lua-openssl 的项目地址为:https://github.com/zhaozg/lua-openssl 然后按照文档中的步骤,先安装:

luarocks install openssl

然后直接根据 https://github.com/zhaozg/lua-openssl/blob/master/test/ec.lua 中的例子来使用:

local openssl = require "openssl"
local pkey = require "openssl.pkey"

local nec = {'ec',"prime256v1"}
local ec = pkey.new(unpack(nec))
local k1 = pkey.get_public(ec)
print(k1)

执行然后发现报错:

/usr/local/share/lua/5.1/kong/plugins/init/handler.lua:33: bad argument #2 to 'new' (invalid option 'prime256v1')

发现这个是不支持这个算法,但是不对啊,分明已经按照文档上的来了为什么不可以,然后就怀疑,问题出在local openssl = require "openssl"这个上面。然后一顿google发现,原因是kong里面也有自带一个类似的项目,叫做 luaossl,然而,他们的包名称都叫做openssl,所以其实虽然我以为我引用了的是lua-openssl这个项目,但其实使用的还是kong自带的 luaossl(项目地址:https://github.com/wahern/luaossl) 。但是 luaossl 暂时还没有支持ecc这个比较新的算法,这个功能就用不了。

真相大白,原来是资源包名称相同导致的。详情可点击此链接:https://github.com/zhaozg/lua-openssl/issues/72 。目前暂时还没有很好的解决方案,lua-openssl的作者说联系 luaossl 商量改名的事宜,但暂还没有下文。

那么最后的解决方案就是先在lua中调用系统命令生成ecc相关密钥。