apisix/doc/getting-started.md

Chinese

Quick Start Guide

The goal of this guide is to get started with APISIX and to configure a secured public API with APISIX. By the end of this guide, you will have a working APISIX setup and a new service which will route to a public API, which is secured by an API key.

The following GET endpoint will be used for the purpose of this tutorial. This will act as an echo endpoint and will return the parameters which are sent to the API.

$ curl --location --request GET "https://httpbin.org/get?foo1=bar1&foo2=bar2"

Let's deconstruct the above URL.

• Scheme: HTTPS
• Host/Address: httpbin.org
• Port: 443
• URI: /get
• Query Parameters: foo1, foo2

Prerequisites

• This guide uses docker and docker-compose to setup APISIX. But if you have already installed APISIX in other ways, you can just skip to step 2.
• Curl: The guide uses curl command for API testing, but you can also use any other tool of your choice (Eg- Postman).

Step 1: Install APISIX

APISIX is available to install in multiple operating environments. The following document shows the installation steps in multiple platforms. For the quick start let's use the docker based set up. To start the APISIX server, clone the following repository and navigate to the example folder and execute the following commands.

This command will start the APISIX server and the admin API will be available in 9080 port (HTTPS port: 9443).

$ git clone https://github.com/apache/apisix-docker.git
$ cd apisix-docker/example
$ docker-compose -p docker-apisix up -d

It will take a while to download the source for the first time. But the consequent loads will be very fast. After the docker containers have started visit the following link to check if you are getting a successful response.

$ curl "http://127.0.0.1:9080/apisix/admin/services/" -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1'

The following will be the response from the Admin API.

{
    "node": {
        "createdIndex": 6,
        "modifiedIndex": 6,
        "key": "/apisix/services",
        "dir": true
        },
    "action": "get"
}

Step 2: Create a Route in APISIX

APISIX provides a powerful Admin API and a dashboard for configuring the routes/services/plugins. The quickstart guide will use the Admin API for configuring the routes.

A micro-service can be configured via APISIX through the relationship between several entities such as routes, services, upstream, and plugins. The route matches the client request and specifies how they are sent to the upstream (backend API/Service) after they reach APISIX. Services provide an abstraction to the upstream services. Therefore, you can create a single service and reference it in multiple routes. Check out the architecture document for more information.

Technically all this information(upstream or service, plugins) can be included inside a route configuration. The route consists of three main parts.

• Matching Rules:

  Let's take the following scenario. http://example.com/services/users

  The URL above hosts all the micro services related to the users(getUser/ GetAllUsers) in the system. For example the GetAllUsers endpoint can be reached via the following URL (http://example.com/services/users/GetAllUsers) Now you want to expose all the GET endpoints(micro-services) under the users path. The following will be the route configuration for matching such request.

  {
      "methods": ["GET"],
      "host": "example.com",
      "uri": "/services/users/*",
      ... Additional Configurations
  }
  

  With the above matching rule you can communicate to APISIX via the following command.

  curl -i -X GET "http://{apisix_server.com}:{port}/services/users/getAllUsers?limit=10" -H "Host: example.com"
  

• Upstream information:

  Upstream is a virtual host abstraction that performs load balancing on a given set of service nodes according to configuration rules. Thus a single upstream configuration can comprise of multiple servers which offers the same service. Each node will comprise of a key(address/ip : port) and a value(weight of the node). The service can be load balanced through a round robin or consistent hashing (cHash) mechanism.

  When configuring a route you can either set the upstream information or use service abstraction to refer the upstream information.

• Plugins

  Plugins allows you to extend the capabilities of APISIX and to implement arbitrary logic which can interface with the HTTP request/response lifecycle. Therefore, if you want to authenticate the API then you can include the Key Auth plugin to enforce authentication for each request.

Create an Upstream

Execute the following command to create an upstream with the id of '50' in APISIX. Let's use the round-robin mechanism for load balancing.

curl "http://127.0.0.1:9080/apisix/admin/upstreams/50" -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "type": "roundrobin",
    "nodes": {
        "httpbin.org:443": 1
    }
}'

Add a Route to Access the Upstream

By default APISIX proxies the request via the HTTP protocol. As our backend is hosted in a HTTPS environment, let's use the proxy-rewrite plugin to change the scheme to HTTPS.

curl "http://127.0.0.1:9080/apisix/admin/routes/5" -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "uri": "/get",
    "host": "httpbin.org",
    "plugins": {
        "proxy-rewrite": {
          "scheme": "https"
        }
    },
    "upstream_id": 50
}'

Call APISIX

Now lets call APISIX to test the newly configured route.

curl -i -X GET "http://127.0.0.1:9080/get?foo1=bar1&foo2=bar2" -H "Host: httpbin.org"

The API is available via the HTTPs(9443) endpoint as well. If you are using a self signed certificate then use the -k parameter to ignore the self-signed certificate error by the curl command.

curl -i -k -X GET "https://127.0.0.1:9443/get?foo1=bar1&foo2=bar2" -H "Host: httpbin.org"

Step 3: Add authentication for the service

Now lets protect the newly created APISIX endpoint/route as it is currently open to the public. Execute the following command to create a user called John with a dedicated api-key.

Note: APISIX supports multiple authentication mechanism, view the plugin docs to learn more.

curl http://127.0.0.1:9080/apisix/admin/consumers -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "username": "john",
    "plugins": {
        "key-auth": {
            "key": "superSecretAPIKey"
        }
    }
}'

Now, let's configure our endpoint to include the key-auth plugin.

curl http://127.0.0.1:9080/apisix/admin/routes/5 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "uri": "/get",
    "host": "httpbin.org",
    "plugins": {
        "proxy-rewrite": {
          "scheme": "https"
        },
        "key-auth": {}
    },
    "upstream_id": 50
}'

As the route is secured by the key-auth plugin the former curl command to access the API will produce an unauthorized access error. Use the command below to securely access the endpoint now.

curl -i -X GET http://127.0.0.1:9080/get -H "Host: httpbin.org" -H 'apikey: superSecretAPIKey'

Add a prefix to the route

Now lets say you want to add a prefix (eg: samplePrefix) to the route and do not want to use the host header then you can use the proxy rewrite plugin to do it.

curl http://127.0.0.1:9080/apisix/admin/routes/5 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "uri": "/samplePrefix/get",
    "plugins": {
        "proxy-rewrite": {
          "scheme": "https",
          "regex_uri": ["^/samplePrefix/get(.*)", "/get$1"]
        },
        "key-auth": {}
    },
    "upstream_id": 50
}'

Now you can invoke the route with the following command:

curl -i -X GET 'http://127.0.0.1:9080/samplePrefix/get?param1=foo&param2=bar' -H 'apikey: superSecretAPIKey'

APISIX Dashboard

As of now the API calls to the APISIX has been orchestrated by using the Admin API. However, APISIX also provides a web application to perform the similar. The dashboard is available in the following repository. The dashboard is intuitive and you can orchestrate the same route configurations via the dashboard as well.

Troubleshooting

• Make sure the required ports are not being used by other systems/processes (The default ports are: 9080, 9443, 2379). The following is the command to kill a process which is listening to a specific port (in unix based systems).

  sudo fuser -k 9443/tcp
  

• If the docker container is continuously restarting/failing, login to the container and observe the logs to diagnose the issue.

  docker logs -f --tail container_id