Introduction to API Gateway and Continuous Deployment (Kong & Jenkins)
Corresponding to the documentation directories "Chapter 2: Introduction to Jenkins" and "Chapter 3: Deploying Services with Jenkins", this article organizes the practical path of Kong and Jenkins in enterprise-level continuous delivery. Even with zero foundation, you can follow the steps to build your own gateway + continuous deployment pipeline.
Pre-class Tour: What is an API Gateway
An API Gateway sits between clients and backend microservices, acting as the system's "unified entry point". It is responsible for receiving external requests, routing them to different backend services based on configuration, and performing a series of common capabilities at the entry layer (authentication, authorization, rate limiting, monitoring, protocol conversion, etc.), thereby simplifying client invocation processes and reducing coupling between services.
graph LR
ClientA[Web 客户端] --> APIGateway[API Gateway]
ClientB[移动端] --> APIGateway
ClientC[第三方合作方] --> APIGateway
APIGateway -->|路由/聚合| ServiceA[用户服务]
APIGateway -->|协议转换| ServiceB[订单服务]
APIGateway -->|安全控制| ServiceC[支付服务]
Core Responsibilities
- Unified Entry and Routing: All requests first go to the gateway, then are forwarded according to rules such as path, domain, and Header.
- Security Protection: Centralized handling of security policies such as authentication, authorization, rate limiting, IP whitelisting, and WAF.
- Protocol and Format Conversion: Supports REST, gRPC, GraphQL, etc., unifying multiple protocols externally.
- Observability and Operations: Collects logs, metrics, tracing, and provides resilience measures such as circuit breaking, retries, and caching.
- Aggregation and Orchestration: Combines multiple backend interfaces to return customized responses, reducing client invocation complexity.
Why an API Gateway is Needed
- Growth in Microservice Count: Clients do not need to care about each service's address and authentication method; the gateway exposes them uniformly.
- Centralized Governance Policies: Rate limiting, circuit breaking, monitoring, and other policies are uniformly implemented at the gateway layer, avoiding redundant implementations across services.
- Facilitates Evolution and Canary Releases: Achieves canary releases, A/B testing, and version switching through routing rules.
- Enhances Security and Compliance: A unified entry point facilitates auditing and risk control.
sequenceDiagram
participant Client as 客户端
participant Gateway as API 网关
participant Auth as 身份验证服务
participant Order as 订单服务
participant Billing as 计费服务
Client->>Gateway: 请求 /v1/order
Gateway->>Auth: 校验 Token
Auth-->>Gateway: 返回用户信息
Gateway->>Order: 调用订单详情
Gateway->>Billing: 查询支付状态
Gateway-->>Client: 聚合后的订单响应
Common products: Nginx + Lua, Kong, Tyk, APISIX, AWS API Gateway, Spring Cloud Gateway, etc.
Chapter 2: Kong Hands-on Introduction
Combine videos 2-1 to 2-6 to master common operations from installation to security hardening.
2-1 Kong's 8001, 8000, and 1337 Port Numbers
Kong opens multiple ports by default, each carrying different responsibilities. Understanding their roles first makes troubleshooting easier.
| Port | Protocol | Role | Common Operations |
|---|---|---|---|
| 8000 | HTTP | External Proxy Entry | Business requests go here |
| 8443 | HTTPS | Proxy Entry (TLS) | Expose HTTPS services |
| 8001 | HTTP | Admin API | Create Service/Route, view status |
| 8444 | HTTPS | Admin API (TLS) | More secure in production environments |
| 1337 | HTTP | Dev Portal/Manager | Visual configuration (Docker quick experience) |
graph TD
subgraph 业务面
Client[客户端流量] --> Proxy[8000/8443 Proxy]
Proxy --> UpstreamPool[上游服务]
end
subgraph 运维面
AdminAPI[8001/8444 Admin API] --> KongCore[Kong 核心]
Portal[1337 Manager] --> KongCore
end
KongCore --> Metrics[日志/指标输出]
Quick self-check commands:
# 确认端口监听状态
docker exec kong netstat -tnlp | grep 800
# 用 Admin API 获取节点信息
curl http://localhost:8001/
2-2 Basic Route Forwarding Configuration
The first thing to do when getting started is to correctly forward a URL to a backend service.
- Register Service: Define the upstream address and protocol.
- Create Route: Determine which requests hit the aforementioned Service.
- Verify Forwarding: Access the proxy entry via
curlor a browser.
# 1. 注册服务
curl -X POST http://localhost:8001/services \
--data "name=user-service" \
--data "url=http://mockbin.org"
# 2. 绑定路由
curl -X POST http://localhost:8001/services/user-service/routes \
--data "paths[]=/users" \
--data "strip_path=true"
# 3. 访问 Kong 代理
curl -i http://localhost:8000/users
Common pitfalls: hosts, paths, methods are "AND" relationships; the more matching conditions, the lower the hit probability; ensure the client Host Header matches the route configuration.
2-3 Kong's Service, Route, Upstream
Service, Route, and Upstream form Kong's core abstractions. Understanding their relationships helps you flexibly combine traffic policies.
- Service: Describes the backend application (protocol, domain, port, timeout).
- Route: Defines how to match requests to a specific Service.
- Upstream: Provides an "instance pool" for a Service, supporting load balancing and health checks.
- Target: A specific instance (IP:Port) within an Upstream.
graph TD
Client --> Route[Route: hosts/paths]
Route --> Service[Service: http://orders.internal]
Service --> Upstream[Upstream: order-upstream]
Upstream --> TargetA[10.0.1.10:9000]
Upstream --> TargetB[10.0.1.11:9000]
Route -- Plugin 链 --> Plugins[认证/限流/日志]
Best practices:
- Create a separate Upstream for each upstream service to facilitate subsequent rolling upgrades.
- Plugins can be attached to Routes, Services, or globally; global policies have the lowest priority.
- Use Tags to group resources for easier operational searching.
2-4 Kong Integration with Consul for Service Discovery and Health Checks
When backend instances change frequently, entrusting health checks to Consul can reduce manual maintenance burden.
- Prepare Consul: Start the Consul Agent and register your application instances (you can use a
service.jsonfile). - Configure Service Discovery: Add a new
hostin the Kong Service in the format ofservice.consul, and enableservice_discoveryinKONG_DATABASEorkong.conf. - Declare Upstream to use Consul:
curl -X POST http://localhost:8001/upstreams \
--data "name=order.consul" \
--data "service=orders" \
--data "healthchecks.active.type=http"
- Consul maintains instances: When instances go online or offline, Consul automatically synchronizes, and Kong reads the latest health status.
graph LR
Consul -->|服务健康| KongUpstream
Jenkins -->|部署后注册| Consul
KongProxy --> KongUpstream --> BackendPods[订单服务实例]
Tip: Ensure Kong and Consul are network reachable, and enable TTL or HTTP health checks in Consul.
2-5 Kong Configuration of JWT for Login Verification
The JWT plugin makes Kong a unified authentication entry point. The typical process is as follows.
- Enable the plugin and create a consumer:
# 添加一个消费者
curl -X POST http://localhost:8001/consumers \
--data "username=mobile-app"
# 为消费者生成密钥对
curl -X POST http://localhost:8001/consumers/mobile-app/jwt
- Enable the JWT plugin on a Route or Service:
curl -X POST http://localhost:8001/services/user-service/plugins \
--data "name=jwt" \
--data "config.claims_to_verify=exp"
- Client constructs and carries the Token:
curl http://localhost:8000/users \
-H "Host: api.example.com" \
-H "Authorization: Bearer <签名后的JWT>"
sequenceDiagram
participant Client as 客户端
participant Kong as Kong 网关
participant JWT as JWT 插件
participant Upstream as 上游服务
Client->>Kong: 带 Authorization 的请求
Kong->>JWT: 校验签名、过期时间
JWT-->>Kong: 校验通过/失败
opt 校验通过
Kong->>Upstream: 转发请求
Upstream-->>Kong: 返回业务响应
Kong-->>Client: 200 OK
end
opt 校验失败
Kong-->>Client: 401 未授权
end
Tip: Combining with key-auth or rate-limiting plugins can further differentiate access permissions and frequencies for different clients.
2-6 Kong Configuration of Anti-Crawler IP Blacklist
Common methods to combat malicious requests are "whitelist + blacklist + rate limiting".
# 开启 IP 限制插件
curl -X POST http://localhost:8001/services/user-service/plugins \
--data "name=ip-restriction" \
--data "config.deny[]=192.168.1.100" \
--data "config.deny[]=203.0.113.0/24"
Combined approach:
- Blacklist: Immediately add malicious IPs to the
denylist upon discovery. - Whitelist: For admin backends and BFF interfaces, an
allowlist can be set, denying other sources by default. - Rate limiting: Use with
rate-limitingorbot-detectionplugins to smooth out traffic spikes. - Auditing: Deliver Kong logs to ELK/Loki to identify abnormal User-Agents and Referers.
graph TD
ClientReq[请求] --> IPCheck[IP 限制插件]
IPCheck -->|黑名单| Block[返回 403]
IPCheck -->|通过| RateLimit[限流插件]
RateLimit --> Backend[上游服务]
Deploying Services with Jenkins
Corresponding to videos 3-1 to 3-11, guiding you from Jenkins installation, plugin selection to Pipeline orchestration and release automation.
3-1 Pain Points of Continuous Integration in Agile Development
- Frequent code merges, manual packaging, and manual releases are inefficient.
- Significant differences in dependencies across environments often lead to "it works on my machine" issues.
- Lack of unified quality gates, leading to missed tests and production rollbacks.
- Deployment results lack traceability, making it difficult to quickly pinpoint failed nodes.
Agile development: We don't really know what to develop, let's take it one step at a time
User story: The boss said this feature needs to go live tomorrow, I don't care how it's implemented
Rapid iteration: The click-through rate of the last feature was too low, change the ad to full screen
User pain point: A user complained yesterday, adjust the ad
Embrace change: The boss has new ideas every day, everyone needs to adapt (don't blame me)
Continuous delivery: Every version has problems, always continuously delivered to testing, delivery interval 10 minutes
Pair programming: Too many bugs, go directly to the tester's desk to test and modify
Code review: You reviewed this code, you will be responsible if problems arise in the future
Flexible work: No fixed quitting time, you can only leave after fixing bugs
Four meetings: (Scrum Meeting) Starts at 9:00 AM every day, no chance to be late for work
The "joke-style" paragraph above satirizes common agile misconceptions in the industry: equating agile with no planning, treating user stories as temporary requirements, packaging rough releases as "rapid iterations", and even neglecting quality gates in the name of continuous delivery. True agile emphasizes:
- Rhythmic Planning: Requirements still need to be sorted out, effort estimated, and deliverable goals synchronized externally before each iteration.
- User Stories Focused on Value: Describes user roles, scenarios, and benefits, helping the team understand "why" something is being done, not just arbitrary feature commands.
- Quality as a Prerequisite for Continuous Delivery: Automated testing, code reviews, and monitoring alerts are fundamental safeguards; frequent delivery is for quickly validating value, not for continuously "throwing defects to testing".
- Embracing Change with Boundaries: Managing changes through product backlog and iteration rhythm, adjusting priorities when necessary instead of inserting ad-hoc tasks.
- Scrum's Four Meetings (Planning, Daily Stand-up, Review, Retrospective) are for synchronizing information, identifying risks, and continuous improvement, not for formalistic check-ins.
Understanding these principles is essential to combine agile and continuous integration, allowing Jenkins pipelines to serve "continuous value delivery" rather than "continuous problem delivery".
3-2 Installing Jenkins and Disabling the Firewall
- Docker installation is the quickest:
docker run -d --name jenkins \
-p 8080:8080 -p 50000:50000 \
-v jenkins_home:/var/jenkins_home \
jenkins/jenkins:lts
- Initialization Wizard: Follow the prompts to enter the unlock password, install recommended plugins, and create an administrator.
- Server Firewall: If using CentOS, you can first disable or allow port 8080.
sudo systemctl stop firewalld
sudo firewall-cmd --permanent --add-port=8080/tcp
sudo firewall-cmd --reload
3-3 Jenkins Building Service Deployment Process
sequenceDiagram
participant Dev as 开发者
participant Git as 代码仓库
participant Jenkins
participant Registry as 镜像仓库
participant K8s as Kubernetes
participant Kong
Dev->>Git: 提交代码
Git-->>Jenkins: Webhook/轮询触发
Jenkins->>Jenkins: 编译 + 测试
Jenkins->>Registry: 推送镜像/制品
Jenkins->>K8s: 滚动更新
Jenkins->>Kong: 调用 Admin API 刷新路由
Jenkins-->>Dev: 通知结果(钉钉/邮件)
Key points of the process:
- Use Credentials to store access keys for Git, Registry, and Kubernetes.
- Timely
emailextor robot notifications at failure stages facilitate immediate handling. - Use
postblocks to specify different notification actions for success and failure.