Rapid Service Onboarding: Multi-Env, Multi-InfraDef, Approvals > Any Service

Hi all!

I wracked my brain on this one a few times trying to figure the whole thing out, but here is the scenario I was working through and the solution (FYI, this is a stop gap, since the fix will be completed relatively soon).

Background

When wanting to rapidly onboard services, we want to limit the amount of work required, which leads to a reduction in both maintenance and time-to-onboarding.

In Harness, there is a lot of templatizing ability in general, but there are some areas where we are improving this capability. Case-in-point, we recently (as of this post) released Infrastructure Definitions, which revamped how we tie Services to Environments/Infrastructure (we will explore InfraDef a bit in this post).

Scenario

Let’s say the you want Harness to orchestrate a current process as a stop gap while you build out a new process on new architecture. The current process would be something like executing a script that would take in certain parameters and then execute on those parameters, but it is relatively manual and has to be individually executed for each artifact:tag combination (imagine having to do this with dozens or hundreds of artifacts each time the artifact version was updated?). Add the complexity of approvals, authorizations and authentications, etc. and you get the industry-standard “It was good when it was originally built, but it doesn’t scale”.

Desired Outcome

For the automation piece, we would like the desired outcome to be setting up the Environment, InfraDefs, and Workflows once and then reuse those for each Service that is onboarded. This would allow onboarding time for new Services to be only a couple of minutes, since everything else is templatized. Finally, we would want the deployment to trigger the deployment automatically when there is a new container image.

First Pass = Failed

My initial thought was to build out a Templatized Workflow and have the Environments and InfraDefs setup, then a Pipeline would be templatized to allow for the approvals and environment promotions to take place. After trying a few different options (cloned workflows, hacking the Config-as-Code YAML, etc.) I found out this is not possible (this is the piece that Harness will be fixing in the near future).

Second Pass = Success

Here are the steps I needed to do to get to the desired outcome:

  1. Go to Setup > Template Library > Add Shell Script
    a. Import the desired script and add the variables as required
  2. Create an SSH Deployment Type service with an Other artifact type
    a. Add the desired Artifact Source
  3. Create an Environment (let’s call it Legacy for now)
    a. In the Environment, create two DataCenter InfraDefs (test and prod)
  4. Create a new Multi-Service Workflow and tie it to the Legacy Environment
    a. Click the three dots to the top right of the Workflow Overview and click editimage
    b. Click the Template icon to the right of Environmentimage
  5. Add an Approval to the pre-deployment step with the appropriate group assigned
  6. In Deployment Phases, add a new Phase, then add the Service from the first step, and put in the InfraDef for the environment
    a. In that deployment phase, select the pencil icon to the right of Phase 1 and click the template icons to the right of the Service and InfraDefimage
    b. Click the three dots to the top right of the Deployment Phase and click editimage
    c. Click the Template icon to the right of Environmentimage
  7. (Leave the Select Nodes section in the deployment phase, or else it won’t work) In the Deploy Service section, add a phase, and select Select from Shared Template Library at the top, then select the script from the first step
    a. Add in the required parameters for the script. For example, if you needed to pass the name of the InfraDef to the script, you would use ${infra.name} and ${artifact.metadata.image} for the image name and tag, etc. (see more options here)
  8. Go back to the Workflow and then clone the first Phase image and edit as needed
  9. If you need to add an approval step between the two options, add it to the end of the first Deployment Phase
  10. Go to the Triggers and create a new trigger
    a. Call it the name of the service you are deploying
    b. Trigger on a New Artifact and point it to the Service that was setup above
    c. Tie the Trigger to the Workflow
    d. Fill in the variables and select From Triggering Artifact Source, then submit

Going forward, the only thing you’ll need to do is clone the Service and create the Trigger (since the Environment, InfraDef, Approvals, and Workflow is already created for you) and follow step 10 above!

Hopefully this helps!

Don’t forget to Comment/Like/Share!

1 Like