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- Instances of Darwinium. Each has self-contained data and its own repository, but are still accessed through your single organization's Darwinium account.  Common patterns are to:
  • use seperate nodes for development, staging and production.
  • use seperate nodes for different brands/channels (usually only where ownership is fragmented or compliance dictates 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 has one or more Edge Deployment Targets. Targets play a crucial role in coordinating the deployment of Darwinium's edge and perimeter assets with host systems. This coordinates the utilization of multiple CDN vendors, such as Cloudflare or AWS Cloudfront; even different accounts on the same CDN vendor to support a collection of journeys.

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.

The following step involves editing 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 Admin > Nodes. Locate your note and click settings:

...Click the Edge Deployment tab:

Click 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

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. Typically Darwinium recommends using your staging node for this purpose.
2. For each node you wish to use staging's repository for, open the node's settings (in admin > nodes) and select the Git / Journey settings tab.
3. Turn on Use another node's git repo and select staging from the dropdown:
   
4. Save settings
5. Confirm that the other node's repo is being used by observing the node table, and by clicking Deployment - you will observe that commits and builds from the staging node are present in the node:
   

Note that in order for deployment to work successfully, both nodes must declare targets of the same name (although deployment configuration will differ).

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.