LogoLogo
  • Technical Direction
  • Technical overview
    • Technical Implementation
    • API Design Guide
      • Data Definitions and Standards
      • Data Transfer Objects
      • Documentation
      • Environments
      • Error Handling
      • Example API Service
      • GraphQL Naming Conventions
      • Methods
      • Naming Conventions
      • Once Only Principle
      • Pagination
      • Resource Oriented Design
      • REST Request
      • REST Response
      • Security
      • Versioning
    • Ísland.is Public Web Data Flow
    • Code Reviews
    • Code Standards
    • Monorepo
    • Project Management
    • Teamwork
    • Architectural Decision Records
      • Use Markdown Architectural Decision Records
      • Use NX
      • Continuous Integration
      • CSS
      • Branching and Release Strategy
      • Error Tracking and Monitoring
      • What API Management Tool to Consider
      • Viskuausan Static Site Generator
      • Use OAuth 2.0 and OpenID Connect As Protocols for Authentication and Authorization
      • Unified Naming Strategy for Files and Directories
      • CMS
      • Open Source License
      • What Chart Library Should We Use Across Island.is?
      • What Feature Flag Service/application Should We Use at Island.is?
      • Logging, Monitoring and APM Platform
      • ADR Template
    • Log Management Policy
  • Products
    • Island.is Authentication Service
      • Terminology
      • Integration Options
      • Authentication Flows
      • Authorising API Endpoints
      • Session Lifecycle
      • Scopes and Tokens
      • Delegations
      • Configuration
      • Tools and Examples
      • Environments
      • Test IAS with Postman
      • Using the IAS admin portal
    • Notifications / Hnipp
      • New Notification Setup Guide
      • Notifications service workflow overview
      • Email notifications
    • Pósthólfið
      • Security Checklist
      • Introduction
      • Skjalatilkynning API
      • Skjalaveita API
      • Sequence Diagram
      • Interfaces
    • Straumurinn (X-Road)
      • Architecture Guidelines for Service Providers and Consumers
      • Setting up an X-Road Security Server
        • Network Configuration
      • X-Road - Uppfærsla á öryggisþjónum
      • Straumurinn - Notkun og umsýsla
      • X-Road Central - current version
  • Development
    • Getting Started
    • Generating a New Project
    • Definition of done
    • Devops
      • Continuous Delivery
      • Database
      • Dockerizing
      • Environment Setup
      • Logging
      • Metrics
      • NextJS Custom Server
      • Observability
      • Operations Base Principles
      • Security
      • Service Configuration
      • Support
    • AWS Secrets
    • Feature Flags
    • Documentation Contributions
    • Defining Monorepo Boundaries With Tags
    • OpenAPI
    • Code Generation
    • Workspace Settings (Deprecated)
    • External Contributions
  • REFERENCE
    • Problems
      • 400 Validation Failed
      • 400 Attempt Failed
      • 403 Bad Subject
      • 400 500 Template API Error
    • Glossary
  • Misc
    • Guide: Adding a Payment Step to an Application
    • Guide: Enable Organisations to Make Requests to an Application
    • README Template
Powered by GitBook
On this page
  • Deploying our services
  • Server-side feature flags
  • Turning the features on and off
  • Using the features in the code
  • Cleaning up

Was this helpful?

  1. Development
  2. Devops

Service Configuration

PreviousSecurityNextSupport

Last updated 1 year ago

Was this helpful?

Deploying our services

The services we are developing are deployed to Kubernetes using Helm. We have developed a mini DSL in TypeScript to help us with the configuration of the services as well as allow us some flexibility when creating feature deployments compared to the static YAML. The configuration for each service is part of the source code for the service, in a separate folder named infra.

The DSL is helping us enforce certain conventions and responsibilities. For example it helps us make sure that secrets values are present in all environments that we are deploying to. Same for environment variables' values.

Server-side feature flags

We already have a method to roll out to users, so you might be wondering what are these "server-side" features all about. These are features that are not specific to users or groups of users. They are intended for features that are not ready for production (or staging) yet usually due to:

  • lack of configuration information

  • incomplete implementation

Using these features you can deploy the code all the way to production without having to provide secret or environment variables values for the env where the feature is not turned on.

Currently the feature-specific configuration that can be specified is environment variables and secrets. For an example please see .

Here is an example of how to use these:

  const sut = service('api')
    .namespace('test')
    .image('test')
    .env({
      B: 'A',
    })
    .features({
      'integration-A': {
        env: {
          A: {
            dev: 'B1',
            staging: 'B',
            prod: MissingSetting, // this allows us to specify that we still do not know that the value is
          },
        },
        secrets: { KEY: '/k8s/secret' },
      },
    })
    .initContainer({
      containers: [{ command: 'go' }],
      features: {
        'integration-A': {
          env: {
            C: 'D',
          },
          secrets: {
            INIT: '/a/b/c',
          },
        },
      },
    })

Turning the features on and off

Using the features in the code

Cleaning up

After the feature is in use on prod, please remove all references to it in the code.

The features are turned off by default and need to be turned on explicitly in the using the field featuresOn.

The only usage of the features is to check whether a flag is "on". To do that, use the ServerSideFeatureClient object .

feature flags
this file
environment configuration
exported in the feature flags library