You are viewing version 2.22 of the documentation, which is no longer maintained. For up-to-date documentation, see the latest version.

Configuring Gate and Deck to Run on the Same Hostname

Simplify DNS and Ingress management by deploying Gate and Deck to the same host.

Overview

The SpinnakerTM microservice Gate serves as the API gateway for Armory and is leveraged by the Deck microservice to display various Armory data via a user interface. In order to successfully use the Deck UI, both Deck and Gate must be accessible via DNS. The standard approach to configuring access to both Deck and Gate is to set DNS routing to each service on separate hostnames or separate sub-domains of the same hostname. While this approach is typical, it increases the complexity of both DNS management and Ingress management into Kubernetes.

To simplify both DNS management and Ingress management, Armory can be configured to serve the Gate microservice on the same hostname as the Deck UI but located at a sub-path. We recommend configuring the Gate microservice so that it is served from the /api/v1 of the Deck UI hostname when using a single hostname for both Deck and Gate.

Assumptions

  1. Deck is accessible at https://spinnaker.example.com
  2. Gate is accessible at https://spinnaker.example.com/api/v1
  3. Kubernetes Ingress and Service is used to route traffic from these paths to port 8084 on Gate and 9000 on Deck.

Note: Configuring a Kubernetes Ingress and Service is outside the scope of this document.

Operator approach

  1. Set Gate’s server servlet to be aware of its context path at /api/v1 in your SpinnakerService config.

    Add the following under the spec.spinnakerConfig.profiles section:

    gate:
      server:
        servlet:
          context-path: /api/v1
    
  2. Set Gate’s health endpoint to /api/v1/health in your SpinnakerService config.

    Add the following under the spec.spinnakerConfig.service-settings section:

    gate:
      healthEndpoint: /api/v1/health
    
  3. Update Deck’s URL in your SpinnakerService config.

    Add the following under the spec.config.security section:

    uiSecurity:
      overrideBaseUrl: https://spinnaker.example.com
    
  4. Update Gate’s URL in your SpinnakerService config.

    Add the following under the spec.config.security section:

    apiSecurity:
      overrideBaseUrl: https://spinnaker.example.com/api/v1
    
  5. Deploy your SpinnakerService config using either kubectl or kustomize command syntax

Halyard approach

  1. Set Gate’s server servlet to be aware of its context path at /api/v1 by creating a file named gate-local.yml in the profiles directory.

    # Make the profiles directory if it doesn't already exist
    mkdir /home/spinnaker/.hal/default/profiles
    
    # Make the gate-local.yml file in the profile directory
    tee /home/spinnaker/.hal/default/profiles/gate-local.yml <<-'EOF'
    server:
      servlet:
        context-path: /api/v1
    EOF
    
  2. Set Gate’s health endpoint to /api/v1/health by creating a file named gate.yml in the service-settings directory.

    # Make the service-settings directory if it doesn't already exist
    
    mkdir /home/spinnaker/.hal/default/service-settings
    
    # Make the gate-local.yml file in the profile directory
    
    tee /home/spinnaker/.hal/default/profiles/gate-local.yml <<-'EOF'
    healthEndpoint: /api/v1/health
    EOF
    
  3. Update Deck’s URL using Halyard command

    hal config security ui edit --override-base-url https://spinnaker.example.com
    
  4. Update Gate’s URL using Halyard command

    hal config security api edit --override-base-url https://spinnaker.example.com/api/v1
    
  5. Apply the Spinnaker Configuration changes using Halyard command

    hal deploy apply
    

Last modified October 12, 2020: add missing syntax (#254) (4cc9aea)