CNC.yml

Configuration

Coherence is powered by the cnc framework, an open-source CLI. The Coherence UI makes it easy to manage your configuration, while retaining power-user level control when you need it. There are 2 tabs in each environment that manage the configuration of the services and other settings.

• The Services tab
• The cnc.yml tab

These can be used interchangably. When you define your services and databases in the Coherence UI, a YAML configuration file named cnc.yml is automatically generated and populates the cnc.yml tab. This file is essential for managing your application infrastructure, such as service definitions, resource allocations, and environment settings.

Customizing cnc.yml

Once generated, the YAML file can be accessed in the cnc.yml tab on your environment homepage to further customize your configuration, accessing cnc settings that are not supported in the UI. Common examples are:

• Migrate commands: Add database migration commands, such as migrate: flask db migrate, directly under the relevant service to automate schema updates during deployment.

• Build processes: Specify custom build commands within the x-cnc annotations to define how assets are compiled or scripts are executed during the build phase.

• Resource and scaling management: Adjust CPU and memory limits, configure auto-scaling rules, and set up health checks to optimize performance and resilience.

Example configuration

Below is an example of a cnc.yml configuration file for a monorepo setup with two services: frontend and backend.

x-cnc:
  build_settings:
    platform_settings:
      # See cloud provider docs for valid types
      machine_type: "E2_HIGHCPU_8"
  resources:
    # Resources can be defined here or as services, interchangeably
    # Some resources (e.g., message queue or bucket) don't always have a server in dev
    # For valid types and options, see flavor docs
    - name: bucket1
      type: object_storage

services:
  # This will become the service name in CNC
  frontend:
    x-cnc:
      # This is required
      type: frontend
      # Within this container, where do built assets end up?
      # We need to know to copy them to the CDN
      assets_path: dist
      # What command do you run in the container to build the assets?
      # This is often different from the docker-compose command to run
      # the dev server
      build: ["yarn", "build"]
      # You can define custom headers for your site
      custom_headers:
        - name: x-frame-options
          value: SAMEORIGIN

    build:
      # For this container, where is the Dockerfile?
      # If you don't have one defined, the default is
      # "Dockerfile" in the current working directory
      # If the Dockerfile does not exist, included flavors
      # will use nixpacks for the build step to produce a container
      dockerfile: frontend/Dockerfile
      # This can be used to set the docker build context
      context: frontend

  backend:
    command: ["npm start"]

    ports:
      # These are ignored by CNC, your app is expected to listen on $PORT
      # Unless you customize the IaC or runtime templates to change behavior
      - "8080:8080"

    deploy:
      # Control the resources deployed
      # Can also specify different specs for scheduled tasks/workers
      # See worker below for an example
      resources:
        limits:
          memory: 2g
          cpus: 2

      # How many minimum instances of the server to run?
      # Any autoscaling rules will still apply and can modify this higher
      # See max_scale in system settings below
      # Optional, default is 1
      replicas: 1

    build:
      # See comments in frontend above
      context: backend
      dockerfile: "backend/Dockerfile"

    x-cnc:
      type: backend
      # Need to define the URL path to route to the service
      # Unless you customize IaC to subdomain routing
      url_path: /api
      # For DB migrations, what command to run?
      # Runs in the container
      migrate: ["prisma", "migrate"]
      # For DB seeding, what command to run?
      # MUST be idempotent!!
      # Runs in the container
      seed: ["prisma", "seed"]

      # CI pipeline timeout limits before failing
      timeouts:
        # default is 20 for both
        deploy: 10
        build: 10

      # System holds infra config info
      system:
        # Health check is required on AWS apps
        # Can be anything that returns 200-399 HTTP code
        health_check: /

        # Control cloud behavior
        platform_settings:
          # The higher value of min_scale and replicas in deploy will be used as the min
          # Optional, default is 1
          min_scale: 1
          max_scale: 4

      workers:
        # Will run a daemon without LB connection
        - name: default queue
          # What command to run? Will run in same container as the service
          command: ["node", "worker.js", "default"]
          # How many instances of this worker to run?
          replicas: 1 # Optional, default is 1
          # Define resources (will default to service definitions if not defined)
          system:
            cpus: 2
            memory: 4g

      scheduled_tasks:
        # CRON jobs go here
        - name: check task statuses
          command: ["node", "statuscheck.js"]
          # Use k8s syntax for all providers/flavors
          # This is every 2 mins (can be expensive)
          schedule: "*/2 * * * *"
          # Define resources (will default to service definitions if not defined)
          system:
            memory: 2g

  redis:
    x-cnc:
      # Will be merged into resources for the whole app in each environment
      type: cache

    # CNC will ignore this and use cloud service (e.g., Elasticache)
    image: redis
    restart: always

  db1:
    x-cnc:
      name: db1
      type: database
      # Any version supported by cloud (e.g., RDS on AWS)
      version: 13
      # Can override protocol in DATABASE_URL here for CNC-managed vars
      adapter: postgresql

    # CNC will ignore this and use cloud service (e.g., RDS)
    image: postgres:13
    restart: always