News KrakenD CE v2.7 released with better rate-limiting and security options

Enterprise Documentation

Recent changes

You are viewing a previous version of KrakenD Enterprise Edition (v2.5) , go to the latest version

CI/CD Deployment on the API Gateway

Document updated on Feb 1, 2024

KrakenD operates with its single binary and your associated configuration. Therefore, your build process or CI/CD pipeline only needs to ensure that the configuration file is correct. These are a few recommendations to a safer KrakenD deployment:

  1. Make sure the configuration file is valid. When using Flexible Configuration, generate the final krakend.json using FC_OUT as the final artifact
  2. Optional - Ensure ther are no severe security problems using the audit command.
  3. Optional - Generate an immutable docker image
  4. Optional - Run integration tests
  5. Deploy the new configuration

There are several ways to automate KrakenD deployments, but you must always test your configuration before applying it in production. You’ll find a few notes that might help you automate this process in this document.

For the first step, the check command is a must in any CI/CD pipeline or pre-deploy process to ensure you don’t put a broken setup in production that results in downtime. The check command lets you find broken configurations before going live. Add a line like the following in your release process:

Recommended file check for CI/CD 
$krakend check --lint -t -d -c /path/to/krakend.json

The command above will stop the pipeline (exit 1) if it fails or continue if the configuration is correct. Make sure to always place it in your build/deploy process.

Read more about the check command

Gitlab pipeline example

Here you have an example pipeline for Gitlab. You can add more steps like the audit command, but it serves as an example that you can start with. You can also adapt this workflow to other CI/CD systems by looking at the actions performed:

# This file is a template, and needs editing before it works on your project.
# In your first run you should check in what
# Build a Docker image with CI/CD and push to the GitLab registry.
# Docker-in-Docker documentation:
# This template uses one generic job with conditional builds
# for the default branch and all other (MR) branches.
  - license
  - test
  - build

# This step is only needed in Enterprise
  stage: license
  image: krakend/krakend-ee:2.6.4
    # Checks if the LICENSE file (must exist in the path) is valid for the next 90 days.
    # If it isn't, the deployment will fail, just to draw your atention. Lower the value afterwards.
    - krakend license valid-for 90d

# Example to check the configuration using flexible configuration
  stage: test
  image: krakend/krakend-ee:2.6.4
    FC_ENABLE: 1
    FC_PARTIALS: $CI_PROJECT_DIR/config/partials
    FC_SETTINGS: $CI_PROJECT_DIR/config/settings/prod
    FC_TEMPLATES: $CI_PROJECT_DIR/config/templates
    FC_OUT: /tmp/krakend.json
    KRAKEND_FILE: $CI_PROJECT_DIR/config/krakend.tmpl
    KRAKEND_AUDIT_IGNORE: $CI_PROJECT_DIR/.krakend_audit_ignore
    - echo "FC_ENABLE is set to $FC_ENABLE"
    - echo "Runner working on path $(pwd)"
    - krakend check -tdc $KRAKEND_FILE
    - krakend check --lint -c $FC_OUT
    - krakend audit -c $FC_OUT --ignore-file=$KRAKEND_AUDIT_IGNORE --severity CRITICAL,HIGH
    - echo "--------------------------------------------------"
    - echo "------ YOU ROCK! KrakenD config looks good! ------"
    - echo "--------------------------------------------------"
    - job: check-license
      optional: true

# Create an immutable Docker image
  image: docker:cli
  stage: build
    - docker:dind
  # All branches are tagged with $DOCKER_IMAGE_NAME (defaults to commit ref slug)
  # Default branch is also tagged with `latest`
    - docker build --pull -t "$DOCKER_IMAGE_NAME" .
    - docker push "$DOCKER_IMAGE_NAME"
    - |
      if [[ "$CI_COMMIT_BRANCH" == "$CI_DEFAULT_BRANCH" ]]; then
        docker tag "$DOCKER_IMAGE_NAME" "$CI_REGISTRY_IMAGE:latest"
        docker push "$CI_REGISTRY_IMAGE:latest"
  # Run this job in a branch where a Dockerfile exists
        - Dockerfile

Unresolved issues?

The documentation is only a piece of the help you can get! Whether you are looking for Open Source or Enterprise support, see more support channels that can help you.