Using Kong API Gateway with Qovery

[r4881t (r48Bit)]

I want to deploy Kong API gateway (in db mode) in my apps. So I thought of two approaches.

1. Use kubectl and helm to install kong in the cluster. But this seemed odd because I won’t be able to use a repository and also I wasn’t sure how would my external domain map to the internal IP. So I didn’t went ahead with this.
2. Create a repo with a Dockerfile that is deployed using Qovery. This Dockerfile would contain kong and relevant details. This seems to make more sense.

So I went ahead and created a dockerfile inspired from kong/docker-kong’s implementation of Dockerfile and the corresponding docker-entrypoint.sh.

My Dockerfile looks like below:

# When you update this file substantially, please update build_your_own_images.md as well.
FROM alpine:3.17

LABEL maintainer="Kong Docker Maintainers <docker@konghq.com> (@team-gateway-bot)"

ARG KONG_VERSION=3.3.0
ENV KONG_VERSION $KONG_VERSION

ARG KONG_AMD64_SHA="494522d5ef9baf674272bbb7075e406a4515a7475253fd3026cc7ca9451612a2"

ARG KONG_PREFIX=/usr/local/kong
ENV KONG_PREFIX $KONG_PREFIX

ARG ASSET=remote
ARG EE_PORTS

RUN set -ex; \
    apk add --virtual .build-deps curl tar gzip ca-certificates; \
    export ARCH='amd64'; \
    KONG_SHA256=$KONG_AMD64_SHA ; \
    if [ "$ASSET" = "remote" ] ; then \
      curl -fL "https://download.konghq.com/gateway-${KONG_VERSION%%.*}.x-alpine/kong-${KONG_VERSION}.${ARCH}.apk.tar.gz" -o /tmp/kong.apk.tar.gz \
      && echo "$KONG_SHA256  /tmp/kong.apk.tar.gz" | sha256sum -c -; \
    fi \
    && tar -C / -xzf /tmp/kong.apk.tar.gz \
    && apk add --no-cache libstdc++ libgcc perl tzdata libcap zlib zlib-dev bash yaml \
    && adduser -S kong \
    && addgroup -S kong \
    && mkdir -p "${KONG_PREFIX}" \
    && chown -R kong:0 ${KONG_PREFIX} \
    && chown kong:0 /usr/local/bin/kong \
    && chmod -R g=u ${KONG_PREFIX} \
    && rm -rf /tmp/kong.apk.tar.gz \
    && ln -sf /usr/local/openresty/bin/resty /usr/local/bin/resty \
    && ln -sf /usr/local/openresty/luajit/bin/luajit /usr/local/bin/luajit \
    && ln -sf /usr/local/openresty/luajit/bin/luajit /usr/local/bin/lua \
    && ln -sf /usr/local/openresty/nginx/sbin/nginx /usr/local/bin/nginx \
    && apk del .build-deps \
    && kong version

COPY docker-entrypoint.sh /docker-entrypoint.sh

USER kong

ENTRYPOINT ["/docker-entrypoint.sh"]

USER root
RUN kong migrations bootstrap -v

USER kong

EXPOSE 8000 8443 8001 8444 $EE_PORTS

STOPSIGNAL SIGQUIT

HEALTHCHECK --interval=60s --timeout=10s --retries=10 CMD kong-health

CMD ["kong", "docker-start"]

Then I go ahead and create a Postgres DB in container mode. I set the accessibility to public. As shown in below image.

Then I set the necessary env variables for kong as below

Now, when I deploy this app, I keep getting the following error

At it’s face, the Kong App is unable to access the postgres db. When I searched online, some people talk about creating a docker network (ex: this SO post, while others are able to solve by ensuring that their pg db is started and ready to accept connections when kong is initialised. In my case, the db is already running and I can not update docker network.

Any ideas on what to do here? Or is there any other API Gateway that you suggest? I have tried KrakenD and it doesn’t fit by needs. I also searched on AWS API Gateway but it seems like networking/connecting b/w Qovery apps and the gateway might be tricky.

[rophilogene (Romaric Philogene)]

Hi @r4881t ,

@r4881t

Or is there any other API Gateway that you suggest?

I will respond to this question You can take a look at this guide I made which is using an NGINX instance as an API gateway.

Use an API gateway in front of multiple services | Qovery

---

Now coming back to your original question, I notice the following:

You are running the migration during the build of the container

RUN kong migrations bootstrap -v

It will not work since the build nodes are running on Qovery instances without access to your infrastructure. So, I recommend running this command inside your Entrypoint file /docker-entrypoint.sh. Then it will be executed at the runtime (on your infrastructure) instead of build time (our infrastructure).

I think this may solve your issue

---

One more thing, I would recommend not exposing your database publicly.

[rophilogene (Romaric Philogene)]

@r4881t one more question: Do you run on an AWS EKS cluster or AWS EC2 (K3S) instance?

[r4881t (r48Bit)]

I am running this on AWS EKS.

Thanks for the tip on security. I initially thought this has something to do with public/private access because I have faced similar issues in past. Ref: Unable to access private postgres - #5 by r4881t I will try this again after the issue is resolved and update you.

[r4881t (r48Bit)]

I can confirm the said solution worked for me. Thanks a lot.

[r4881t (r48Bit)]

@rophilogene - As a followup question, Kong listens on many ports - 8000 8443 8001 8444. I have mapped 8000 - 443 in the app section. Is there a way to map other ports as well? I will be using a CloudFlare Zero Trust to set up access control on the other ports.

[rophilogene (Romaric Philogene)]

Yes, you can add as many ports as you want. Here is an example with one of my app.

[r4881t (r48Bit)]

My apologies, I meant with public access. I want to access these ports on the deployed URL like sub.domain.com:8081. When I set them to public, it takes 443 as the default port.

[rophilogene (Romaric Philogene)]

Unfortunately, you can’t change the exposed port, but we plan to add it. Is it a hard requirement for your use case? Can you explain why you would prefer exposing your service with 8081 instead of 443?

[r4881t (r48Bit)]

Hi @rophilogene , the requirement comes because of how [Kong]( is built. Kong exposes the API Gateway (for public access) on 8080 (regular http) and 8333 (ssl http). It has an Admin API that it exposes on port 8081. People typically use a UI (ex:: King) to visually make changes to Kong configs.

Hope that clarifies the use case.

–
Now in order to bypass the current limitation, I created a simple nodejs proxy service and deployed it as an application in my environment. This proxy service is set to use the “kong-app-internal-host:8081” as the upstream application.

So now, I can use the URL exposed by Qovery “PHPNET - Nom de domaine something.fr en parking” and make my admin commands. Since this is public, it’s no good. So I have mapped this to a custom domain “admin.mysite.com” and used CloudFlare Access Rules to specify only certain emails to get this. ow this is working when someone tries to use “admin.mysite.com” but the original url “something.fr” is still accessible. so I am figuring out how to achieve this.

[rophilogene (Romaric Philogene)]

Ok it’s clear, but what you want is basically exposing the admin api and getting access to it via your web admin panel.

It’s possible out of the box with Qovery if your web admin can target the port 443 of your long admin api.