Introduction

Backstage is an open-source platform for constructing Internal Developer Portals (IDPs). Internal Developer Portals serve as a one-stop shop, that provides a unified view of all our resources. IDPs enable us to seamlessly create, manage, monitor, and document our software resources from a single location. The primary goal of the IDP is to eliminate the reliance on the connection between DevOps and developers.

Prerequisites

1. Backstage is up and running. If you need assistance with deploying Backstage, please follow this getting started guide.

2. Backstage integration with Github.

3. A working Terraform code is uploaded on the GitHub repo.

4. GitHub action file is created to execute the terraform code.

For the sake of this blog, we are using GitHub and AWS, but you can use any CI/CD tool and cloud provider.

Templates

Backstage provides a software catalog which is used to manage all of our software resources, which include CI-CD, Docs, API, K8s, Websites, microservices etc. To create a new component(entity) in the software catalog we need Templates.

The structure of the template file is almost similar to the kubernetes manifests. This similarity in structure makes it easier for users familiar with Kubernetes to work with Backstage templates.

Below is a backstage template that you can use to create an EC2 instance on AWS.

apiVersion: scaffolder.backstage.io/v1beta3
    kind: Template
    metadata:
      name: sagar
      title: Backstage automation
      description: creating ec2 using backstage and terraform.
    spec:
      owner: guest
      type: service

      parameters:
        - title: backstage demo template
          required:
            - name
          properties:
            name:
              type: string

      steps:
        - id: test
          name: backstage-blog
          action: debug:log
          input:
            message: 'Hello, ${{ parameters.name }}!'

      output:
        links:
          - title: Open in catalog
            icon: catalog
            entityRef: ${{ steps['register'].output.entityRef

1. apiVersion: - is the required field and the latest value of the API version is scaffolder.backstage.io/v1beta3.

2. **Kind: - **template is the entity in the backstage and to configure it, set the value of kind to Template.

3. **metadata: - **Information you will add in metadata will appear on the template card.

4. spec: - It contains the name of the owner/group of the template and the type of template it could be anything for example:- service/ website/app etc.

5. parameters: - These are the list of options you can add to the template to get the information from the user. Parameters must contain these components: -
   5.1. title: - contains the title of the template
   5.2. required: - You can add the parameters which are mandatory for the template so that a user cannot skip it.
   5.3. properties: - It is used to take input from the user.

6. steps: - Here we define actions taken by the template while executing the template.

7. *** Output ***: - This is the final section in the template file. After completing all the actions specified in the ‘steps,’ this part is executed. It is used to display the result of the template execution, although it is not mandatory.

You can find out more about the template format here.

Deploying Custom Template

Now let's see the files which we have created for the demo. In my backstage code, I have created a directory ec2-demo/template inside the template directory I have created a template.yaml file. Also, I have created a content directory where I have created 2 files component-info.yaml, index.json and package.json.

I have added component-info.yaml, index.json and package.json files below. In the component-info.yaml file I have given the reference of the GitHub repo where my Terraform workflow is present.

After adding all these files, navigate to your app-config.yaml file and insert the template path under the catalogue section, as illustrated in the screenshot below. Adjust the target path according to your requirements.

After adding the path, execute the yarn dev command. Now, on the Backstage portal, under the Create option, you will notice the newly created template.

In the template.yaml file, Under the parameter I have added instanceName, region and instanceType. Once you open the ec2-template it will ask you to add these values.

After adding the values on the next page it will ask you to add a repository name and owner. You can give any name to the repo, whatever name you add here the template will create a repo on GitHub with that name. The owner can be a backstage group or users.

Once all the details are filled, the template will ask you to verify the details which you have added.

After reviewing, click on ‘Create.’ It will take a couple of seconds to generate your catalog. In the background, Backstage will trigger the GitHub workflow. This workflow will execute the ‘terraform apply’ command, which will then create an EC2 instance. Below is the screenshot of the GitHub action.

If you check the status of the GitHub action Job you will see the status of the current job and its progress.

Coming back to backstage UI, here you will see that your catalog has been created.

Once done you can click on the catalog link. It will take you to the newly created catalog window.

Here you will see a CI-CD option under that option you can check the status/progress of the GitHub workflow job.

Once the pipeline is completed your ec2 instance will be up and running.

Summary

In this blog post, we have seen how we can use the backstage template to create an AWS EC2 instance. You can also use the template to spin Infra anywhere, to create a CI-CD Pipeline to deploy your application etc.

I hope you found this post informative and engaging. I would love to hear your thoughts on this post, so do start a conversation on Twitter** or LinkedIn.

Integration of Opentelemetry (Auto Instrumentation) with Jaeger

Vcluster — Architecture Overview and Installation

Backup, Restore and Migrate Kubernetes Cluster resources using Velero.

Sealed Secret in Kubernetes