Sites are often distributed across different domains, network accounts and provisioning architecture. 

Recognising this, Darwinium has constructs to achieve the end goal of a single simplified journey view, even when the underlying site and network architecture may be complex: 

• Nodes - Self-contained instances of Darwinium. Each node keeps its data isolated and carries its own permissions, so you can control exactly what each user can do on each node, while still managing everything through your organization's single Darwinium account. Common patterns include:
  • Separate nodes for development, staging, and production.
  • Separate nodes for different brands or channels - typically where ownership is split across teams, or where compliance requires stricter access control.
• Targets - A target comprises of a set of CDN details that act as a deployment destination for the Darwinium journey to deploy to. A target comprises of a reference to a CDN account (eg. Cloudflare, CloudFront),  list of hosts to cover, and the access permissions to push changes to the edge configuration there.
• Hosts & Aliases - A target will have a list of hosts that are covered. Those hosts can be aliased instead, to better support promotion through different environments. (eg. mysite -> mysite.staging.com in staging node, mysite -> mysite.com in production node).
• Git Repositories - Each node has its own repository, where all the configuration files are stored. To support promotion through environments, repositories can be inherited between nodes.

Targets & Valid Hosts

A node can have Edge Deployment Targets. Targets play a crucial role in coordinating the deployment of Darwinium's edge and perimeter assets with host systems.

Each target is associated with a specific set of valid hosts. These valid hosts serve as endpoints or destinations for the edge and perimeter assets. Valid hosts can take one of two forms:

• Fully Qualified Domain Names (FQDNs): These are complete and specific domains names such as www.mysite.com. FQDNs are used to direct traffic to precise locations on the internet
• Host Aliases: Host aliases are pointers that can be substituted for a host name. For example, mysite can act as an alias. Each valid host, whether its an FQDN or an alias, may have 0 or more associated host aliases. This allows for a flexible approach to routing traffic. For example, mysite might possess multiple host aliases, such as mysite.com, www.mysite.com or staging.mysite.com

The First step in setting up Darwinium edge deployment is to determine which CDN vendors are being used on your site that you wish to provide coverage upon with Darwinium journeys.

Edit your journeys.yaml entry to to define targets. To do this you will need to use either the Darwinium Workflow Editor, or manually checkout the node's repo using git, and edit this file.

An example journeys.yaml with targets is shown below:

journeys:
  - example.journey.yaml
targets:
  - name: mysite_cloudflare
    enabled: true
    type: cloudflare
    valid_host_list:
      - mysite_main
  - name: mysite_cloudfront
    enabled: true
    type: cloudfront
    valid_host_list:
      - mysite_images

.. in your journey file (in this case example.journey.yaml) you would create steps that reference mysite_main or mysite_images as the host.

Once your journeys.yaml file has been committed to the master branch of your node's git repository, the next step is to provide credentials for the declared targets. 

Navigate to: Node Settings (left tab) >  Edge Deployment 

Here you can Sync from journeys.yaml to import the targets previously defined in journeys.yaml:

For each target defined, you will need to setup CDN credentials:

• Setup for Cloudflare
• Setup for AWS Cloudfront
• Setup for Akamai / Linode

Configure Host Aliases

In the example above, we used the host aliases mysite_main and mysite_images as part of our valid_host_list entries. In order to get deployment to deploy to appropriate FQDNs, we need to enter possible values as aliases into Darwinium's configuration. If no aliases are provided, the system will fall-back on using the hosts raw value. It is generally encouraged for you to use aliases as they enable broader coverage of the site and are more resilient to changes in domain names or rebranding.

To configure host aliases, go to your node's settings, and click the Git / Journey Settings tab. You will be presented with a section Host Aliases. Enter possible values for these aliases:

Sharing a Git repo between multiple nodes

There exist scenarios where a customer may want to use a single Git repository for multiple nodes in order to operate with environment promotion from staging -> production for example, where the same journey configuration is used in both environments, without changes to journey logic.

Darwinium provides functionality that caters to this usecase. In order to use it:

1. Determine which node's repository you wish to use as a single source of truth. 
   1. Typically Darwinium recommends using your staging node for this purpose.
2. For another node inheriting staging's repository, navigate:
   1. switch to the other node (top right green circle)
   2. open the Node Settings (left tab)
   3. Select the Git / Journey settings tab
   4. Turn on Use another node's git repo and select staging from the dropdown:
      
3. Save settings

You can confirm the node now inherits the  stagingrepo:

• You no longer see Workflows tab in this node - changes should be done in staging node only. Note the node's previous orphaned repository still exists and would be returned to if Use another node's git repo was toggled off in future
• In Deployment Manager (left tab), you will observe commits and builds are inherited now from the staging node. Importantly, those commits are deployed independently on each node.

Configure monitoring

Darwinium includes the ability to periodically monitor your cloud deployment to ensure that workers have been deployed correctly to your CDN, and that no other 3rd parties have deleted or changed the routes Darwinium requires in order to operate. Monitoring uses a separate set of CDN credentials per-target (with read-only access to your CDN vendor). Whilst monitoring details are not required for Darwinium to operate, it is highly recommended that this functionality is configured, even if you are using a 3rd party system such as Terraform to handle Deployment.