Creating an EKS Cluster with No Manual Coding
Our customers rely on templates, which we refer to as “blueprints,” to run the applications, infrastructure, services in the context of environments they need on a day-to-day basis.
From one perspective, these blueprints are very basic — they’re simple YAML files used to define the code to deploy infrastructure and application services. In the past we’ve referred to them as “environments as code.”
Depending on the use case, however, these blueprints can be used to execute complex tasks. To create these files, we leverage Infrastructure as Code (IaC) configurations and integrations with other ecosystem tools to define how these resources will be deployed. That means you can create a template that will deploy all infrastructure and application services needed to generate an application.
One of the most popular among our new users is the ability to create a Kubernetes cluster — a common use case that can be cumbersome to execute when needed.
In this article we’ll highlight an example using an Amazon Elastic Kubernetes Service (EKS) cluster in an AWS-based VPC to run a Jenkins server and a Kubernetes dashboard.
Then we will save that template so it can be reused in the future.
Step 1. Connect a Repository to Use IaC Resources in Quali Torque
This starts by adding the public URL for a GitHub, GitLab, Bitbucket or other repository to a Quali Torque account. You can find a free version here.
Through this process, Torque discovers the resource configurations defined in IaC and generates a YAML to wrap each one so it can be provisioned via the Torque platform.
This step normalizes the resource configurations between each asset so the user can add each to the environment blueprint without worrying about compatibility across tools.
For this case, the infrastructure services were initially defined via Terraform, while the applications were defined in Helm. By connecting Torque, they can be used interchangeably to orchestrate the application.
Torque also provides out-of-the-box IaC modules for AWS, Microsoft Azure and Kubernetes services (referred to as community assets), which users can leverage alongside the resources discovered in their repositories.
In this case we’ll use the community asset to define the VPC and Jenkins server release, alongside user-provided configurations for EKS and Kubernetes dashboard.
Step 2. Add and Configure These Resources in Your Template
To create our cluster, we’re going to add a VPC to host the EKS cluster, which will then run the Helm releases for both the Kubernetes dashboard and the Jenkins server.
In Torque’s environment design tool, you can find each resource, add them to your application environment and connect them to define the dependencies.
You’ll also need to define parameters for each asset, such as the cloud regions and instances for infrastructure services, or the Jenkins account for the server.
To define parameters, select “Inputs” and complete the form. Where possible, admins can set pick lists so users can only select an option provided by an admin.
Step 3. Review the Code in YAML and Initiate the Plan
As you add your resources and define the plan, Torque generates a new YAML file defining the infrastructure, services, dependencies, and parameters.
This file allows you to execute the full plan to deploy infrastructure component and application service needed to deliver the output.
For this example, initiating the plan will create the VPC and EKS cluster to generate each of the Helm releases we described earlier.
Step 4. Access Your Cluster Endpoint and Jenkins Server
After initiating the plan, Torque’s UI provides access to the outputs — in this case, the Jenkins server which can now be used in the user’s Jenkins account.
You can also review the logs for every IaC command executed in the plan. For example, clicking into the logs for the Apply command provides access to the cluster endpoint.
Step 5. Save and List the Blueprint on Your Self-Service Developer Platform
To deliver a true platform engineering experience for this use case, you’ll want to make this cluster easy for developers to access when needed.
To accomplish that, a Torque user with administrator permissions (usually DevOps or platform engineers) can save the file defining the plan and choose to list it on Torque’s self-service catalog. This effectively releases it to those with end-user permissions, which allows them to initiate the plan without the ability to modify the code or build any new blueprints. Releasing the blueprint also makes it available for users to integrate it into their CI/CD platform or access it via a developer portal based on Spotify Backstage.
This approach also allows admins to push updates or debug the environment at the blueprint level, automate recurring actions and enforce policies on things like maximum runtimes for the environment. These guardrails can be customized to make the admin more comfortable releasing self-service access to run this environment.
Teams that rely on Kubernetes admit that it’s just as complex as it is critical to day-to-day operations. This approach is just one way to strip out some of that complexity so more developers can take advantage of it.
